Vehicle log storage method and vehicle

Abstract

The invention provides a vehicle log storage method and a vehicle, and the method relates to the field of data management, and the method comprises the steps: obtaining the feature information of a target log when it is detected that the target log to be stored exists in the vehicle; based on the feature information, a target score is determined, and the target score is used for representing the storage priority of the target log; determining a target storage strategy based on the target score; and processing the target log based on the target storage strategy. The method can ensure that the key logs in the vehicle are stored.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data management, and more particularly, to a storage method of a vehicle log and a vehicle in the field of data management. BACKGROUND

[0002] With the development of vehicle technology, the functions integrated in the vehicle are increasingly complex. The log data generated by the electronic control unit (ECU) in the vehicle has the characteristics of multi-source, mass and large value difference. However, in the prior art, the ECU can generate a large amount of data under some working conditions, resulting in an explosive increase in the log data generated by the ECU, which can cause the loss of other key log data when storing the log data.

[0003] Therefore, how to ensure the storage of the key log in the vehicle is a technical problem to be solved at present. SUMMARY

[0004] The present application provides a storage method of a vehicle log and a vehicle, which can ensure the storage of the key log in the vehicle.

[0005] In a first aspect, a storage method of a vehicle log is provided, and the storage method comprises: when it is detected that there is a target log to be stored in the vehicle, acquiring feature information of the target log; determining a target score based on the feature information, the target score being used to represent a storage priority of the target log; determining a target storage strategy based on the target score; and processing the target log based on the target storage strategy.

[0006] In the embodiments of the present application, compared with the prior art, the First In First Out (FIFO) storage strategy is unified for all logs, and the value difference of the logs cannot be distinguished, so in a complex vehicle-mounted environment, the key data in the vehicle may be lost due to being covered by a large amount of low-value data, and the fault positioning and reliability guarantee of the vehicle are affected. When the target log to be stored is detected in the vehicle, the characteristic information of the target log is obtained, and based on the characteristic information, the target score representing the storage priority of the target log is determined, which can quantify the characteristics of the target log into a specific numerical index corresponding to the storage value of the log. Finally, the target storage strategy is determined based on the target score and executed, which can determine the physical storage action according to the specific numerical index corresponding to the storage value of the log and execute it, so as to realize the storage of the target log to prolong its retention time. Since the score is determined based on the characteristic information of the log in the present scheme, and the corresponding storage strategy is determined according to the score corresponding to the storage priority of the log, the present scheme can filter the logs according to their characteristic information when the storage strategy is executed, and ensure that the logs with high storage priority are stored, so as to store the key logs in the environment with limited resources, and improve the reliability of the key log storage in the vehicle.

[0007] In a second aspect, a storage device for vehicle logs is provided, and the storage device comprises: The acquisition module is configured to, when a target log to be stored is detected in the vehicle, acquire characteristic information of the target log. The processing module is configured to determine a target score based on the characteristic information, the target score being used to represent a storage priority of the target log; determine a target storage strategy based on the target score; and process the target log based on the target storage strategy.

[0008] It should be understood that the expansion, limitation, explanation and description of the related content in the above first aspect also apply to the same content in the second aspect.

[0009] In a third aspect, a vehicle is provided, which comprises a memory and a processor; the memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, so that the vehicle executes the storage method of the vehicle logs in the above first aspect or any possible implementation manner of the first aspect.

[0010] In a fourth aspect, a computer program product is provided, which comprises computer program code, when the computer program code runs on a computer, so that the computer executes the storage method of the vehicle logs in the above first aspect or any possible implementation manner of the first aspect.

[0011] Fifthly, a computer-readable storage medium is provided, which stores computer program code that, when executed on a computer, causes the computer to perform the vehicle log storage method of the first aspect or any possible implementation thereof. Attached Figure Description

[0012] Figure 1 This is a schematic flowchart illustrating a prior art method for storing vehicle logs, as provided in an embodiment of this application. Figure 2 This is a schematic diagram of a vehicle log storage architecture provided in an embodiment of this application; Figure 3 This is a schematic flowchart illustrating a method for storing vehicle logs provided in an embodiment of this application; Figure 4 This is a schematic flowchart illustrating another method for storing vehicle logs provided in an embodiment of this application; Figure 5 This is a schematic flowchart illustrating another method for storing vehicle logs provided in an embodiment of this application; Figure 6 This is a schematic flowchart of a feedback method for a vehicle log storage system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a vehicle log storage device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0014] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0015] With the development of vehicle technology, the functions integrated into vehicles are becoming increasingly complex. The log data generated by the ECUs (Electronic Control Units) in vehicles is characterized by multiple sources, massive volume, and significant differences in value. Taking the Telematics Unit (T-Box) as an example, it needs to simultaneously run multiple services, including cellular communication (4G / 5G), Global Navigation Satellite System (GNSS) positioning, Controller Area Network (CAN) or Ethernet (ETH) gateway, Application Processor (AP), Bluetooth or Wi-Fi, and Hardware Security Module (HSM). This results in the log data generated by a single ECU exhibiting characteristics of multi-source heterogeneity, huge differences in value density, and varying timeliness requirements.

[0016] An ECU, also known as an electronic control unit or vehicle controller, is an embedded computer system used to control one or more electrical systems or subsystems of a vehicle. For example, an ECU may include a smart cockpit domain controller, an Advanced Driver Assistance Systems (ADAS) controller, or a telematics unit (T-Box).

[0017] During operation, the volume of critical operation logs generated by the ECU is typically tens of MB per hour. However, under conditions such as deep diagnostics, capturing complete CAN / ETH messages, or buffering video streams, the instantaneous raw data generation can surge to several GB per hour, posing a challenge to the limited storage and computing resources within the ECU. This results in the following problems with existing technologies when dealing with vehicle log storage: Issue 1: There is a risk that critical logs may be overwritten by low-value logs. For example, such as... Figure 1 As shown in (a), existing solutions generally use a uniform FIFO strategy to manage storage space, which cannot identify and distinguish the value of different logs. When an error log, application processor debugging log, or global navigation satellite system positioning log is detected due to an emergency call system trigger failure, it is uniformly stored in a first-in-first-out (FIFO) storage pool. If the storage pool is full, the data with the longest storage time in the FIFO storage pool needs to be deleted. If it is not full, the log is stored in the FIFO storage pool.

[0018] The above strategy has the following drawbacks: Drawback 1: Loss of conventional value; when storage is full, an error log containing a failed emergency call system trigger may be overwritten by thousands of subsequent low-value application processor debug logs because it was generated earlier. Drawback 2: Instantaneous surge; when the ECU enters diagnostic mode and generates "several GB / hour" of low-value debug logs, causing a data surge, it will instantly overwrite all high-value, low-volume critical fault logs accumulated over the past few hours or even days, resulting in the permanent loss of important historical data and depriving fault tracing and safety analysis of crucial evidence.

[0019] Problem two: Low resource utilization efficiency. For example, existing solutions typically use the same generic compression algorithm (such as Zstandard compression algorithm (ZSTD)) for all log data. Figure 1 As shown in (b), when H.264 video data or CAN frame structured data is detected, ZSTD is uniformly used for compression without considering the content characteristics of the data itself, resulting in significant resource waste. The compression of already compressed data (such as H.264 video data) is further compressed, resulting in an extremely low compression rate (e.g., only 2%), while consuming a large amount of central processing unit (CPU) resources. For highly structured data (such as CAN frame structured data), the general algorithm fails to make full use of its pattern characteristics and cannot achieve the optimal compression rate, resulting in a compression rate of only 65%. In addition, for highly random data (such as encryption keys or digests), compression is completely ineffective and increases processing latency.

[0020] In addition, existing ECUs are susceptible to temperature fluctuations, such as the significant decrease in Flash write performance at high temperatures (e.g., above 85°C), but the storage strategy cannot be dynamically adjusted based on temperature changes; and after the vehicle is turned off, the ECU needs to enter a low-power mode, and the complex compression algorithm can cause the backup battery to be depleted quickly.

[0021] Therefore, the main problem with existing technologies is their inability to ensure the storage of critical logs in vehicles. The root cause of this problem lies in the lack of multi-dimensional perception capabilities regarding log data content, business value, historical access patterns, and the physical state of the ECU itself; and the absence of a collaborative mechanism based on multi-dimensional perception, adaptive decision-making, and execution.

[0022] In view of this, this application provides a method for storing vehicle logs. When a log to be stored is detected, the method obtains its feature information and calculates a quantified value score to identify its storage priority. Then, a differentiated storage strategy is generated and executed based on the score to ensure that logs with high storage priority are stored. This enables the storage of critical logs in a resource-limited environment and improves the reliability of critical log storage in vehicles.

[0023] In the embodiments of this application, an adaptive hierarchical storage architecture driven by a multi-dimensional data perception engine is adopted. Through three inputs—content feature analysis, dynamic value priority assessment, and environmental state perception—collaborative intelligent decision-making on compression strategies, storage hierarchies, and lifecycle management is achieved, thereby solving the problems existing in the prior art and ensuring the storage of critical logs in vehicles.

[0024] For example, such as Figure 2 As shown, Figure 2 A vehicle log storage architecture 200 is provided. The vehicle log storage architecture 200 may include an application layer 210, a perception and analysis layer 220, an intelligent decision-making layer 230, an adaptive execution layer 240, a physical storage layer 250, and a monitoring and feedback layer 260.

[0025] The application layer 210, also known as the data source layer, service layer, or producer layer, can be used to generate native log data for various services and functional modules of the ECU during operation. The application layer 210 may include communication service 211, global satellite navigation system positioning service 212, application processor service 213, and microcontroller service 214.

[0026] Communication service 211, also known as cellular communication module or network access service, can be used to process data communication between the vehicle and external networks (such as 4G / 5G) and generate related connection, transmission and exception logs.

[0027] The Global Navigation Satellite System Positioning Service 212, also known as GNSS service or positioning module, can be used to provide real-time location, speed, and time information for vehicles, and generate logs related to positioning status, accuracy, and timing.

[0028] Application processor service 213, also known as AP service or high-performance computing service, can be used to run operating systems and complex upper-layer applications (such as infotainment and ADAS algorithms) and generate a large number of application status, business logic and debug trace logs.

[0029] Microcontroller Service 214, also known as MCU Service or Real-time Control Service, can be used to perform real-time control tasks at the vehicle's underlying level (such as bus management and power control) and generate logs related to hardware interaction, timing control, and device status.

[0030] The perception and analysis layer 220, also known as the feature extraction layer, data analysis layer, or perception engine layer, can receive raw logs and extract multi-dimensional features such as metadata, deep content, historical access patterns, and environmental conditions at the time of generation in parallel, providing standardized input for intelligent decision-making. The perception and analysis layer 220 may include a data perception module 221, a content analysis module 222, a background learning module 223, and an environmental monitoring module 224.

[0031] The data perception module 221, also known as a multidimensional data perception engine or feature orchestrator, can serve as a unified entry point for all logs, responsible for coordinating and aggregating features from other perception modules to generate structured feature vectors.

[0032] The content analysis module 222, also known as the content feature analyzer or deep parser, can be called by the data awareness module 221 to perform deep scanning of log data blocks, analyze their data type, information entropy, whether they contain sensitive information, and provide compression suggestions.

[0033] The background learning module 223, also known as the access pattern analyzer or background learning engine, can be used to analyze historical logs that have been retrieved in the background, and to uncover the true value and relevance of the logs.

[0034] The environmental monitoring module 224, also known as an environmental status monitor or context sentinel, can be used to monitor the physical environment (such as temperature and voltage) and operating status (such as driving mode and network connection) of the ECU in real time, and generate environmental characteristics and strategies.

[0035] The intelligent decision-making layer 230, also known as the strategy generation layer or arbitration layer, can calculate the value score of logs based on all the features provided by the perception and analysis layer 220 through core algorithms, and make the final storage management decision by integrating multiple strategies. The intelligent decision-making layer 230 may include a value assessment module 231 and a strategy fusion module 232.

[0036] The value assessment module 231 can also be called a value priority evaluator or a scoring engine; the value assessment module 231 is the core algorithm module in this application embodiment, used to calculate the final value score (i.e., target score) of each log.

[0037] The strategy fusion module 232, also known as the strategy fusion decision engine, can be used to combine the final value score of the value assessment module 231, the content features obtained by the content analysis module 222, and the environmental strategies obtained by the environmental monitoring module 224 to determine the final storage and compression decisions.

[0038] The adaptive execution layer 240, also known as the instruction execution layer, operation layer, or physical proxy layer, can be used to execute complex instructions issued by the intelligent decision layer 230, and complete practical operations such as physical compression, storage routing, and space reclamation of log data. The adaptive execution layer 240 may include a dynamic compression module 241, a hierarchical scheduling module 242, and a memory management module 243.

[0039] The dynamic compression module 241, also known as the dynamic compression executor, can be used to select the optimal compression algorithm (such as a dedicated algorithm, a general algorithm, or no compression) based on the instructions output by the strategy fusion module 232 to process log data.

[0040] The hierarchical scheduling module 242, also known as the hierarchical storage scheduler, can be used to route logs to the corresponding physical level (i.e., logical storage area) according to the instructions output by the policy fusion module 232.

[0041] The memory management module 243, also known as the lifecycle manager or intelligent garbage collector, can be used to execute memory management mechanisms (Garbage Collection, GC) and can be used to identify and release the space occupied by data that is no longer in use.

[0042] The physical storage layer 250, also known as the data persistence layer or storage medium layer, can be used to provide the actual storage medium for log data. The physical storage layer 250 can be logically divided into four layers by the adaptive execution layer 240 according to performance, cost, and security requirements: transient cache layer 251, high-frequency hot storage layer 252, normal temperature storage layer 253, and persistent archive layer 254.

[0043] The transient cache layer 251 can also be called the memory cache layer or RAM layer; it can be implemented by volatile memory and is used to temporarily buffer the log data stream being processed.

[0044] The high-frequency hot storage layer 252, also known as the Hot Tier, high-speed hot layer, high-performance storage area, critical data layer, or priority storage area, features low write latency, high read / write lifespan, and small capacity. It can be used to store data with the highest value rating and the most frequent access. It is usually implemented by high-speed, high-durability media (e.g., high-performance FALSH).

[0045] The standard warm storage layer 253, also known as the Warm Tier, standard storage layer, mainstream storage area, regular data layer, or balanced storage area, features large capacity, low cost, moderate read / write performance and lifespan. It can be used to store medium-value, regularly accessed data and is usually implemented with general-purpose media that offer a more balanced capacity and cost.

[0046] The persistent archiving layer 254, also known as the Archive Tier, compliance archiving layer, long-term storage area, cold data layer, or compliance storage area, offers high security and can prevent data from being tampered with or accidentally deleted. It can be used to store "cold" data that needs to be retained for a long time for auditing or traceability but is accessed very infrequently, and usually has higher security or reliability protection.

[0047] The monitoring feedback layer 260, also known as the system observation layer, closed-loop feedback layer, or self-optimization layer, can be used to continuously monitor the health status, performance indicators, and log access behavior of the physical storage layer, and use this data as feedback information for system self-optimization. The physical storage layer 250 may include a performance monitoring module 261, a storage health module 262, and a log recording module 263.

[0048] The performance monitoring module 261, also known as the system performance monitor, can be used to monitor performance indicators such as read / write speed, latency, and CPU utilization of the storage system.

[0049] The storage health module 262, also known as a storage health monitor, can be used to monitor the remaining lifespan and other health status of storage media.

[0050] The logging module 263, also known as the policy / access logger, can be used to record all retrieval and reading operations on stored logs, generating detailed access logs as input to the background learning module 223.

[0051] For example, logs are generated by various services within the application layer 210, enter the perception and analysis layer 220 for feature extraction, and the resulting feature vector is passed to the intelligent decision layer 230 for scoring and policy fusion. The generated decision instructions are issued to the adaptive execution layer 240 for compression and storage scheduling, and finally the data is written to the corresponding area of ​​the physical storage layer 250.

[0052] Optionally, the monitoring feedback layer 260 continuously collects the performance, health status, and access records of the physical storage layer 250. Performance and health data are fed back to the environment monitoring module 224 in the perception and analysis layer 220 for updating environmental perception; access records are provided to the background learning module 223 in the perception and analysis layer 220 for analysis. The background learning module 223 feeds back the optimization patterns derived from the analysis (such as new value weights and more accurate lifecycles) to the intelligent decision-making layer 230, the adaptive execution layer 240, and the physical storage layer 250, thereby dynamically optimizing the system's future decision-making and execution strategies, forming a continuously self-optimizing intelligent closed loop.

[0053] It should be noted that the above-described layered architecture (including the application layer, perception and analysis layer, intelligent decision-making layer, adaptive execution layer, physical storage layer, and monitoring and feedback layer) and its internal module divisions, as well as the logical structure of the physical storage layer (such as the instantaneous cache layer, high-frequency hot storage layer, normal temperature storage layer, and persistent archiving layer), are all illustrative. This application does not limit the specific number of layers in the vehicle log storage architecture, the specific naming of each layer, or the specific division of functional modules or storage areas contained within each layer. Any equivalent structural transformation or implementation method based on the above core concept should fall within the protection scope of this application.

[0054] The following is combined with Figure 3 This application provides a detailed description of a method for storing vehicle logs according to embodiments. For example, Figure 3 The method 300 shown can be executed by the vehicle TBOX.

[0055] S310: When a target log to be stored is detected in the vehicle, the characteristic information of the target log is obtained.

[0056] The target log refers to the data records generated by the software services inside the vehicle's ECU during operation and that need to be persistently saved. It is typically used to refer to objects to be processed in the decision-making process of the storage management system. Feature information is used to represent the information extracted from the target log to support intelligent decision-making. For example, feature information may include source information, content information, time information, environmental information, and accessed information, and its form can be a feature vector.

[0057] It should be understood that feature vectors, also known as feature profiles or standardized feature packages, are used to describe the comprehensive characteristics of logs in multiple dimensions such as source, content, time, environment, and access patterns in the form of structured data vectors, and can provide standardized input for intelligent decision-making.

[0058] In the embodiments of this application, when a new log event is detected generated by any service running inside the ECU, the log is determined to be the target log to be processed, and the content structure of the target log itself is parsed to obtain its characteristic information.

[0059] For example, when a "positioning function failed" error log is generated by the Global Navigation Satellite System (GNSS) positioning service within the T-Box due to continuous timeouts caused by signal loss, its characteristic information is obtained: the source information is gnss_service, the log level is ERROR, and the event type is hardware_timeout; content analysis shows that its data type is structured text, with low information entropy, making it easy to compress, and it does not contain sensitive location information, so the compression recommendation is ZSTD; the environmental monitor synchronously provides context: the current vehicle is in normal driving mode, the ECU temperature is 65°C, and the remaining storage space is 45%. All these characteristics are encapsulated into a standardized feature vector and passed to the lower-level decision module.

[0060] For example, such as Figure 2 As shown, when an error log is detected generated by the Global Navigation Satellite System Positioning Service 212 in the application layer 210, the application layer 210 sends the raw data of the error log along with its metadata to the data perception module 221. After receiving the error log, the data perception module 221 initiates a parallel perception task: the data perception module 221 analyzes the metadata of the error log to obtain easily accessible metadata features; while the data perception module 221 analyzes the metadata of the error log, it also sends the raw, unstructured data blocks of the error log to the content analysis module 222 for in-depth analysis; the content analysis module 222 parses the data within the error log and returns the content features to the data perception module 221.

[0061] Optionally, the metadata can be descriptive information inherent to the log protocol layer. That is, the analysis object of the data awareness module 221 is the header of the target log, and it extracts the source module name, timestamp, severity level, etc., from the header. In other words, the data awareness module 221 extracts the protocol metadata features of the target log. For example, the data awareness module 221 extracts the source module name as "T-Box_App", the timestamp as "2023-10-27 10:00:00", and the severity level as "DEBUG".

[0062] Optionally, the raw, unstructured log data blocks can be the log body or payload. That is, the content analysis module 222 analyzes the target log's data body. The content analysis module 222 performs a deep unstructured scan of the target log's data body to extract deep features that cannot be obtained from protocol tags, such as compression potential, true data category, and information value density. These deep features may include the target log's data type, entropy value, and whether it contains Personally Identifiable Information (PII). In other words, the content analysis module 222 extracts the target log's semantic features. For example, the content analysis module 222 might parse the data body as an encrypted binary stream with an entropy value of 0.9 and contain a PII, determine a compression suggestion, and feed back the target log's data type, entropy value, PII, and compression suggestion to the data awareness module 221.

[0063] For example, after receiving the results returned by the content analysis module 222, the data perception module 221 constructs a feature vector based on all features and sends the constructed feature vector to the value assessment module 231 and the strategy fusion module 232.

[0064] PII refers to identifying personally identifiable information (such as vehicle identification numbers, location coordinates, user information, etc.) contained in logs through a preset pattern matching algorithm, and using it as the basis for evaluating the value of data compliance, thereby automatically triggering specific encrypted storage strategies or lifecycle management logic.

[0065] It should be noted that entropy is based on the concept of Shannon entropy in information theory, and is expressed by the formula... Calculated, of which, Discrete random variables (i.e., the possible values ​​of each byte or symbol in a data block). Used to represent No. i One possible value, Used to represent this value The probability of an element appearing in the entire data block is typically logarithmically base 2. In log storage scenarios, entropy is considered a hard indicator of "compressibility".

[0066] Optionally, the environmental monitoring module 224 in the perception and analysis layer 220 will synchronously send the acquired real-time environmental policies (e.g., whether it is currently in high temperature mode, low power mode or collision mode) to the policy fusion module 232 in the intelligent decision layer 230.

[0067] In one embodiment, the perception and analysis layer 220 is the core of data input and feature extraction in this application. Its responsibilities include perceiving the raw logs, environment, and context, and providing standardized five-dimensional feature vectors for the intelligent decision-making layer 230. .

[0068] Optionally, feature vector The dimensions can be adjusted according to different high demands, hardware resources or application scenarios. That is, the information of each vector can be deleted or added. The dimension of the feature vector can be adjusted to one-dimensional, two-dimensional, three-dimensional, four-dimensional, six-dimensional or any other multi-dimensional structure.

[0069] In this embodiment, the data perception module 221 serves as the core scheduling and coordination center of the perception and analysis layer. Its core function is not deep computation, but rather organizing and standardizing feature information from various sources. Technically, this module first receives the raw log data stream and its metadata from the application layer. After receiving the data stream and metadata, the data perception module 221 extracts shallow features from the structured information such as the log's protocol header, generating two basic dimensions of the standard feature vector: the source dimension (such as information including the log level and the specific service module that generated the log) and the time dimension (such as the log's precise generation timestamp and initial lifecycle suggestion). Simultaneously, it entrusts the raw unstructured data body of the log to the content analysis module 222 for deep parsing. Finally, the perception and analysis layer 220 is responsible for collecting and fusing features from four main sources: its own extracted shallow features, the deep content features returned by the content analysis module 222, the real-time environmental features reported by the environment monitoring module 224, and the background learning feedback features provided by the background learning module 223. It assembles and packages these features into a five-dimensional feature vector with a uniform format and complete structure, and forwards it as a standardized input for intelligent decision-making to the value assessment module 231 of the value priority evaluator.

[0070] In the above embodiment, the input of the data sensing module 221 is the original log stream (i.e., the target log); the output is a feature vector. and feature vectors The output target is the value assessment module 231 in the intelligent decision layer 230.

[0071] Feature vector In Used to represent source information, also known as source dimension; Used to represent type information, it can also be called type dimension, content dimension, or content information; Used to represent time information, it can also be called a time dimension; Used to represent environmental information, also known as environmental dimensions; This is used to represent the accessed information, and can also be called the access dimension; among which, and Provided by data sensing module 221, Provided by content analysis module 222, Provided by the backend learning module 223. Provided by environmental monitoring module 224.

[0072] For example, the data awareness module 221 extracts source information and time information from structured information such as the protocol header of the log. (Source information) Log level: Error, Source application: Application processor; Time information {Generation time: T, Lifetime (TTL) recommended: 7 days}.

[0073] For example, the content analysis module 222 can extract type information from the data payload of the target log sent by the data awareness module 221. Type information {Data type: BINARY, Entropy: 7.8, PII: True, Compression suggestion: None}.

[0074] It should be understood that type information, also known as content dimension, is used for data type analysis, entropy analysis, PII scanning, and compression suggestion analysis.

[0075] Furthermore, data type analysis can identify the type and format of the target log, such as whether it is text, binary stream, or JavaScript Object Notation (JSON); entropy analysis is used to calculate the data entropy value to determine the compression potential; PII scanning is used to scan whether the data contains privacy information; compression suggestion analysis is to determine the optimal compression algorithm based on the results of entropy analysis, such as determining whether the optimal compression algorithm is Gzip compression, ZSTD compression, or no compression.

[0076] For example, the environmental monitoring module 224 is responsible for monitoring the physical and software environments of the ECU to provide environmental information for storage decisions. This can include driving status and resource status. Driving status: {Mode: Normal driving / Collision / Diagnostic mode}; Resource status: {Battery: 80%, Remaining space: 60%}.

[0077] Specifically, the environmental monitoring module 224 can maintain the status of the ECU in real time and generate environmental information by subscribing to CAN bus signals, Scalable Service-Oriented Middleware over IP (SOME / IP) messages, or system interfaces. .

[0078] For example, the environmental monitoring module 224 can periodically (e.g., once per second) actively call the underlying interface, CAN signal, or diagnostic commands to obtain environmental data (e.g., CPU utilization, remaining memory, and remaining Flash space).

[0079] It should be understood that environmental information and environmental data refer to the physical or software environment in which the ECU is located.

[0080] In another implementation, a lightweight pre-trained model can be used to classify the target logs.

[0081] For example, when T-Box processes mixed log streams (such as CAN frames, text logs, and video frames), a lightweight pre-trained model (such as TinyML) can be used to classify data blocks in real time and make a preliminary judgment on their compressibility.

[0082] Optionally, small batches of typical log samples (such as CAN message formats specific to new vehicle models) can be periodically encrypted and uploaded to a cloud-based analysis platform. The cloud platform utilizes its powerful computing capabilities to train an optimal compressed dictionary or dedicated classification model for the data characteristics of that vehicle model, and then distributes it to the vehicle's local analysis module via over-the-air download technology, thereby achieving continuous improvement in compression ratio and reduction in CPU overhead.

[0083] S320 determines the target score based on feature information.

[0084] The feature information can be a feature vector extracted and output by the perception and analysis layer 220 to describe the target log. The target score is used to represent a scalar value obtained based on the feature information, which indicates the storage priority of the target log.

[0085] In one implementation, the method further includes: obtaining the scoring function corresponding to the feature information and the weight corresponding to the feature information; determining the target score based on the feature information, including: obtaining a first score based on the scoring function corresponding to the feature information and the feature information; and obtaining the target score based on the first score and the weight.

[0086] In the embodiments of this application, after receiving the feature information of the target log, a first score corresponding to the feature information is obtained based on the scoring function corresponding to the feature information, and a target score is obtained according to the weight corresponding to the first score and the feature information.

[0087] For example, the value assessment module 231 in the intelligent decision-making layer 230 receives feature vectors (i.e. feature information) provided by the data perception module 221. It also receives optimization rules from the background learning module 223 and the environment monitoring module 224 to obtain the final value score (i.e., the target score). (For example, 0 to 100 points), and The policy is sent to the strategy fusion module 232 in the intelligent decision-making layer 230.

[0088] Among them, the value assessment module 231 in the intelligent decision-making layer 230 is implemented based on a dynamically adjustable weighted scoring model.

[0089] Specifically, the input to the value assessment module 231 in the intelligent decision-making layer 230 is... , For source information, For type information, For time information, For environmental information, The accessed information can also be referred to as source dimension, type / content dimension, time dimension, environment dimension, and access dimension. The value assessment module 231 receives data from the data perception module 221. Then, this multi-dimensional and complex feature vector is "dimensionality reduced" into a single, standardized final value score. .

[0090] in, , , and For details, please refer to the relevant description in S310, which will not be repeated here. This can be referred to as the accessed information or access dimension, which can be obtained through backend learning module 223. For example, {Historical visit frequency: low, expected visitors: cloud}.

[0091] For example, for In this five-dimensional vector, the value assessment module 231 predefines a scoring function for each dimension. The scoring function is responsible for converting the raw features of that dimension (e.g., text, Boolean values, or enumerations) into a standardized numerical score (i.e., the first score) (e.g., between 0 and 1). After obtaining the numerical score for each dimension, a set of weights is used to perform a weighted summation with the numerical score to obtain the final score. .

[0092] Optionally, ,in, Used to represent the weights corresponding to the source dimension. Used to represent the numerical score corresponding to the source dimension. The weights corresponding to the content dimensions in the final value score. The final value score corresponds to the numerical score for each content dimension. The weighting of the time dimension in the final value score. The final value score corresponds to the numerical score in the time dimension. The final value score corresponds to the weight of the environmental dimension. The final value score corresponds to the numerical score in the environmental dimension. The final value score corresponds to the weight of the access dimension. The final value score corresponds to the numerical score of the access dimension.

[0093] It should be understood that , , , and The sum can be normalized to 1.

[0094] It should be noted that the scoring function in this embodiment adopts an architecture combining a pre-set mapping table and a dynamic feature function. For discrete features (such as log level and driving mode), mapping is performed through a pre-calibrated score matrix, and real-time weight shifting is supported based on rules fed back by the background learning module 223. For continuous features (such as TTL duration, remaining space percentage, and access frequency), a proportional mapping function (such as a linear function, logarithmic function, or sigmoid function) is used to normalize the original physical quantities to a value score in the [0, 1] interval. Based on the above-mentioned scoring function adopting an architecture combining a pre-set mapping table and a dynamic feature function, it can not only meet the preset business logic (such as mandatory storage in case of collision) but also automatically adjust the allocation priority of storage resources according to the ECU operating status (such as space, battery level, and hotspot access behavior).

[0095] Optionally, the scoring function corresponding to the source dimension can be a pre-defined mapping table related to the log level.

[0096] For example, log levels can include DEBUG, INFO, WARN, ERROR, and FATAL levels. The DEBUG level is typically used for detailed development and debugging information and has the lowest business value, so it is mapped to a low score (e.g., 0.1 points). The INFO level records normal operating status and has moderate value, so it can be mapped to, for example, 0.3 points. The WARN level indicates potential anomalies that require attention and can be mapped to, for example, 0.5 points. The ERROR level indicates a clear operational failure or error and is a key basis for diagnosis, so it is mapped to a higher score (e.g., 0.8 points). The FATAL level represents a serious error that causes the system or critical functions to stop, has the highest priority, and is usually mapped to a full score (e.g., 1.0 points).

[0097] Optionally, the numerical scores corresponding to the different log levels mentioned above can be remotely upgraded or adjusted by the background learning module 223.

[0098] For example, if a certain error log is found to be a false alarm or has no substantial impact, the backend learning module 223 can issue a rule to reduce its corresponding first score from 0.8 to 0.3.

[0099] Optionally, the scoring function corresponding to the content dimension can be a step function related to the PII recognition result. For regular data that does not contain sensitive information, its value weight is lower than that of data containing sensitive privacy information (such as vehicle trajectory, mobile phone number, or vehicle identification number).

[0100] For example, for logs with {PII: True}, The score is 0.9; for the logs of {PII: False}, The score is 0.1.

[0101] It should be understood that if a log has a PII detection result of False (i.e., a log with {PII: False}), its score will be very low under the weighting of that dimension.

[0102] Optionally, the scoring function corresponding to the time dimension, This can be a mapping function that is positively correlated with survival time. For example, a scoring function may have a logarithmic or linear relationship with survival time.

[0103] For example, ; in, The scoring function is used to represent time information / time dimension; TTL is used to represent the lifespan of the log (in days). The longer the TTL, the higher the "expected value" of the log in the time dimension. Therefore, the scoring function needs to give the log a higher score to ensure that it can be stored.

[0104] Optionally, the TTL mentioned above can be the initial lifecycle assigned to the log, or it can be the lifecycle adjusted and updated based on the background learning module.

[0105] Optionally, the numerical score corresponding to the environmental dimension can be a pre-defined mapping table related to different modes, and the scoring function can be a pre-defined mapping table.

[0106] For example, different scores can be pre-defined based on the vehicle's operating mode. For instance, normal driving mode indicates the vehicle is in normal operating condition, where no additional environmental value weighting is generated, and is typically mapped to a baseline score (e.g., 0.1 points); collision-triggered mode signifies a vehicle accident, and all logs generated in this mode have the highest value for accident analysis, therefore they should be assigned full marks (e.g., 1.0 points); deep diagnostic mode is usually triggered by external tools, and the debugging and status data generated in this mode are important for problem localization, so it can be mapped to a higher score (e.g., 0.9 points); extreme high-temperature mode, when the ECU temperature exceeds the safety threshold, prioritizes writing core data and reduces storage load, appropriately increasing the scoring weight of critical logs while strategically discarding low-value data, and can be mapped to a medium score (e.g., 0.5 points); low-voltage protection mode, when the vehicle is powered by a backup battery after engine shutdown, requires streamlined storage operations to save power, and the environmental score of the logs in this mode is adjusted accordingly (e.g., 0.4 points).

[0107] Optionally, the vehicle's battery level can be inversely proportional to the numerical score, and the remaining storage space can also be inversely proportional to the numerical score, for example, through an inverse proportional function or a step function.

[0108] It should be understood that when remaining storage space decreases, the scoring function will assign a higher "entry threshold score" to all logs to be stored, i.e., further filtering to store more important data. When the battery is low, the score for "core system logs" needs to be increased, while the score for "application layer logs" needs to be decreased to ensure that the last data before the battery runs out is core fault data.

[0109] Optionally, when the ECU is in a high-temperature environment, if the temperature is at a critical temperature threshold, it may cause a sudden change in the strategy. Fuzzy logic can be used to process environmental parameters. For example, the input variable "temperature" can be defined as a fuzzy set such as "too low," "normal," "too high," and "severely overheated," each corresponding to a different membership function. Based on the membership degree of the current temperature (e.g., 82°C) to "too high" and "severely overheated," an adjustment coefficient for the environmental dimension score is smoothly calculated, thereby achieving a continuous and gentle influence on the value score and avoiding drastic changes in the strategy near the critical temperature.

[0110] Optionally, the scoring function corresponding to the access dimension can be a mapping function that is positively correlated with the access frequency.

[0111] For example, ; in, This represents the number of times the target log has been accessed / read within a preset time period, where K represents a constant. That is, with the constant fixed, The larger the score, the greater the value of the log entry. Therefore, the scoring function needs to assign a higher score to the log entry to ensure that it can be stored.

[0112] In the above implementation, the scoring function and weights corresponding to the feature information are obtained, and the feature information is quantified into a first score based on the scoring function. Then, the final target score is obtained through weighted summation, thus outputting a comprehensive and balanced final score. Compared with existing technologies that lack multi-dimensional quantitative evaluation of log value and usually rely on a single, fixed rule for coarse storage, failing to reflect the value of logs, this solution defines a quantifiable scoring function and a weight representing its importance for each value dimension, and generates a target score through weighted fusion. Therefore, this solution can provide an accurate and reliable basis for subsequent storage decisions and provide a data foundation for intelligent and differentiated resource allocation in storage systems.

[0113] In one implementation, the feature information includes environmental information and source information. The storage method further includes: determining the current mode of the vehicle based on the environmental information and source information; when the current mode is a preset mode, adjusting the weights of the environmental information and the corresponding weights of the source information. The preset mode includes a collision mode and a diagnostic mode.

[0114] The weights corresponding to the feature information can be dynamically adjusted. The current mode of the vehicle can be determined based on the environmental information and the source information. If the current mode is a collision mode or a diagnostic mode, it can be determined that the data under the current working condition is of high value, and the weights corresponding to the environmental information and the source information can be adjusted to ensure that the logs under the current mode are stored.

[0115] For example, the environment monitoring module 224 in the perception and analysis layer 220 can provide real-time environmental context. When the environment monitoring module 224 detects a "vehicle collision," it notifies the value assessment module 231 in the intelligent decision-making layer 230 to assign weights to the environmental features. Source weight Dynamic boosting ensures that all logs related to collisions receive the highest value score and are therefore stored.

[0116] It should be understood that, assuming total score The upper limit is 100. When the environmental monitoring module 224 detects a "vehicle collision", it will... Increase it to a sufficiently high value (e.g., 0.95), so that even if other dimensions (such as source and content) score low, as long as the environmental score remains high. (Representing collision), final score The score will be raised to 95 or higher, thus ensuring that the corresponding logs can be stored.

[0117] In the strategy fusion module 232 of the intelligent decision-making layer 230, a scoring threshold is set, and the final score is determined. Target logs that are greater than or equal to the scoring threshold will not be discarded.

[0118] Optionally, if a large number of duplicate invalid DEBUG logs are generated during a collision, embodiments of this application can perform secondary filtering and save the "collision data" by weighting differences.

[0119] For example, after a collision mode is triggered, the weight of the source dimension is increased to 0.9. Although all logs share this high weight, their base value (e.g., the default score for ERROR level = 0.8, and the default score for DEBUG level = 0.1) remains unchanged. When calculating the final value score using weighted calculation, the score difference between high-value and low-value logs will widen due to the amplified weight. For example, a collision ERROR log has a score of 0.8 * 0.9 = 0.72, while a collision DEBUG log has a score of only 0.1 * 0.9 = 0.09. The policy engine will execute a tiered storage strategy based on the amplified score difference: high-scoring logs are immediately saved to the high-speed protected storage area, while low-scoring logs are considered invalid data and are preferentially discarded when storage space is scarce.

[0120] In the embodiments of this application, the environmental monitoring module 224 can generate high-priority environmental policies, which are mandatory enforcement constraints for the current mode / current operating condition.

[0121] The following examples further illustrate the generation and specific content of high-priority environment policies.

[0122] For example, when the environmental monitoring module 224 detects a collision signal, the environmental monitoring module 224 determines the strategy to route all subsequent logs to the storage partition of non-volatile storage and to stop all compression logic that consumes time, so as to ensure that critical data storage is completed in a short time before the system may lose power.

[0123] Optionally, in one embodiment, if the current mode is detected to be in a preset mode (e.g., collision mode, power failure mode, diagnostic trigger mode, etc.), emergency storage is directly triggered to force the relevant logs to be stored in the high-frequency hot storage layer, skipping the value assessment and compression calculation steps.

[0124] Alternatively, in another embodiment, when the vehicle is detected to have entered an extreme high temperature mode, frequent writing to Flash will cause damage to the hardware lifespan or even crash. In this case, logs with a target frequency division lower than the first preset threshold will be directly discarded. In order to reduce CPU heat, compression operations will be prohibited, and the logs will be stored in the memory buffer first to reduce the number of Flash writes.

[0125] For example, if the environmental monitoring module 224 detects that the current temperature exceeds 95°C, the environmental monitoring module 224 sends a set of specific policy packets (target storage policies) to the policy fusion module 232. The format of the policy packet can be: Policy_Override: {Action_Limit: "Drop_Below_Score_50", Compression_Preference: "None", Target_Tier: "RAM"}. Here, Action_Limit is "Drop_Below_Score_50", indicating that the value score is below 50, the log entry has low value, and it is directly discarded and writing is prohibited; Compression_Preference is "None", indicating that compression is not performed (at this time, to reduce CPU heat, all compression operations are prohibited); Target_Tier is "RAM", indicating that it needs to be stored in the memory buffer first to reduce the number of Flash writes.

[0126] It should be understood that when the policy fusion module 232 receives any of the aforementioned high-priority environmental policies sent by the environmental monitoring module 224, that policy will immediately receive the highest execution priority. The policy fusion module 232 will interrupt the current decision calculation based on the conventional value scoring process and force the use of the received environmental policy instructions to directly override and generate the final target storage policy, which will then be sent to the adaptive execution layer 240 for execution. This mechanism ensures that, in emergency or extreme conditions, priority can be given to ensuring the storage of core data and the safe operation of the system itself.

[0127] In the above implementation, the vehicle's current mode is determined based on environmental and source information. When a preset mode is identified, the weights of environmental and source information are adjusted, allowing the value assessment model to prioritize the storage of log data under dangerous or critical conditions. Compared to existing technologies where logs with extremely high timeliness and importance (such as sensor data streams and diagnostic debugging instructions at the moment of a collision) generated in critical scenarios are stored in the same way as other low-value logs, regardless of whether the vehicle is in an accident or undergoing in-depth diagnostics, this approach avoids the possibility of deleting stored critical logs when storage space is full or preventing the storage of critical logs altogether. Because this solution increases the weights of relevant dimensions (environment and source) when a preset mode is detected, it improves the corresponding score of the log in the value scoring calculation. Therefore, it ensures that relevant log data is prioritized for storage when the vehicle is in special conditions, thus providing reliable data support for subsequent critical needs such as system fault backtracking.

[0128] S330 determines the target storage strategy based on the target score.

[0129] The target score is output by the value assessment module. The target storage policy refers to the set of executable instructions (final decision instructions) generated by the policy fusion module to guide the adaptive execution layer in physically processing the target log.

[0130] For example, the structured final decision instruction generated by the strategy fusion module can be in the format of: {"Action": "Save", "TargetTier": "Warm", "Compression": "ZSTD", "ValueScore":85, "AssignedTTL": "7d"}.

[0131] Optionally, based on the vehicle's navigation or map information, when it is detected that it is about to enter an area without network or with poor network signal, the strategy fusion module 232 can be notified to make a decision in advance, and the compression level of all logs received in the subsequent preset time can be improved.

[0132] For example, when the vehicle navigation system detects that it has planned a route through a long tunnel (without network coverage), the environmental perception module combines this route with a real-time network signal map to predict that the vehicle will enter a network-free area in 10 minutes. The policy fusion module 232 initiates the highest level of compression (such as ZSTD maximum compression ratio) on all subsequently generated logs (especially data that needs to be uploaded), and uploads the compressed data when a network connection is available, thereby maximizing the use of bandwidth before the network outage and ensuring that critical information is not lost due to subsequent network outages.

[0133] In one implementation, the method includes: determining a target storage strategy based on a target score, including: when the target score is greater than or equal to a first score threshold, obtaining a target storage area based on the target score, and determining the target storage strategy as storing the target log in the target storage area; when the target score is less than the first score threshold, determining the target storage strategy as discarding the target log.

[0134] In the embodiments of this application, a target score is determined based on feature information. When the target score is greater than or equal to a first score threshold, a target storage area for storing the target log is determined based on the target score, and a storage strategy is determined to store the target log in the target storage area. When the target score is less than the first score threshold, there is no need to store the target log.

[0135] In the above implementation, a first scoring threshold is set. When the target score is greater than or equal to the first scoring threshold, a target storage area is further obtained based on the target score, and a target storage strategy for storing the target log in that target storage area is determined. This allows for precise routing of logs to physical storage locations with different performance levels based on their value after quantifying their value, achieving refined utilization of storage media. Simultaneously, when the target score is less than the first scoring threshold, the target storage strategy is determined to discard the target log, filtering and discarding low-value log data to avoid occupying storage space and processing resources. Compared to existing technologies that indiscriminately use a uniform first-in-first-out (FIFO) storage strategy for all logs, resulting in storage space being filled with a large number of low-value logs and forcing the flushing of previously stored high-value critical logs, this solution determines the log storage strategy based on a comparison between the target log's score and the first scoring threshold. This allows for dynamic allocation of storage resources according to different log value scores, reducing the writing of invalid data and matching appropriate storage performance for logs of different values. Therefore, in resource-constrained vehicle environments, this prevents high-value logs from being flushed by low-value data, improving the effective capacity utilization of the storage system and the reliability of critical data access.

[0136] In one implementation, the method includes: obtaining a target storage area based on a target score, including: when the target score is greater than or equal to a second score threshold, obtaining the target storage area as a first storage area; when the target score is less than the second score threshold, obtaining the target storage area as a second storage area; wherein the storage write speed of the second storage area is lower than the storage write speed of the first storage area, and the first score threshold is lower than the second score threshold.

[0137] In the embodiments of this application, when the target score is greater than or equal to the second score threshold, the target storage area is obtained as the first storage area; when the target score is less than the second score threshold, the target storage area is obtained as the second storage area. The first storage area can be a high-frequency hot storage layer 252, used to ensure the deterministic and non-volatile write performance of extremely valuable data under extreme conditions (such as the instant before a power outage). The second storage area can be a normal-temperature storage layer 253, responsible for storing routine business data required for daily system diagnostics, balancing storage costs and data retention. The storage write speed of the second storage area is lower than that of the first storage area, and the first scoring threshold (e.g., 50) is lower than the second scoring threshold (e.g., 90).

[0138] For example, if The target storage strategy is determined to be to store the target log in the high-frequency hot storage layer 252; if The target storage strategy is determined to be to store the target logs in the regular warm storage layer 253; if Discard the target log.

[0139] Optionally, in one embodiment, under non-emergency conditions, the value assessment module obtains... The system determines which range the score falls into. If the score is less than 50, it is discarded, and the process ends without executing any further steps. If the score is greater than or equal to 50, the system further determines its target storage area.

[0140] Optionally, if a new storage medium (such as a new type of non-volatile memory) is introduced, a new storage level definition needs to be added in the configuration and its performance parameters need to be set, and the hierarchical scheduling module 242 can automatically adapt; if a new compression algorithm for specific data (such as LiDAR point cloud) needs to be added, it also needs to be registered in the algorithm library of the dynamic compression module 241.

[0141] It should be understood that the core parameters of the entire value assessment model (including the weights of each feature dimension, the triggering conditions and actions of the environmental strategy) exist in the form of a structured configuration file. This allows vehicle manufacturers to update the weights of the value assessment and the environmental strategy via over-the-air (OTA) download technology.

[0142] Optionally, the capacity boundaries of the physical storage layer can be dynamically adjusted based on real-time load.

[0143] For example, during a long diagnostic session in a vehicle, the write load on the Hot Tier surges, and the remaining space rapidly decreases. At this time, the tier scheduler can dynamically move the logical capacity boundary between the Hot Tier and the Warm Tier towards the Warm Tier according to preset rules. For example, the Hot Tier capacity can be temporarily increased by 20% to accommodate more high-value diagnostic data, and the original boundary can be restored after the session ends.

[0144] Optionally, an additional storage layer can be added: a cloud storage layer (Cloud Tier), which can automatically archive historical regular logs with a score of medium (e.g., 70 to 80) to cloud object storage via a 4G network, thereby freeing up local space.

[0145] Alternatively, in another embodiment, when there is sufficient storage space (e.g., the remaining storage space is greater than or equal to a preset space threshold), the policy fusion module can lower the first scoring threshold (e.g., from 50 to 20) to ensure that as much data as possible is recorded.

[0146] Alternatively, in another embodiment, when storage space is low (e.g., the remaining storage space is less than a preset space threshold), the policy fusion module can increase the first scoring threshold (e.g., from 50 to 70) to ensure that higher-value data can be stored.

[0147] In the above implementation, a second scoring threshold and a first scoring threshold are set. When the target score is greater than or equal to the second scoring threshold, the target storage area is determined as the first storage area; when the target score is less than the threshold, it is determined as the second storage area. The first storage area has a higher storage write speed, realizing fine-grained allocation of storage resources with different performance based on log value scores. It can prioritize storing critical logs with high value scores in the high-speed first storage area to ensure fast write and read performance, while storing logs with relatively high value scores in the second storage area with a slightly slower write speed. Since this solution allocates storage resources based on quantified value scores and dynamically matches data value with the performance characteristics of storage media, this solution can improve the utilization efficiency of high-performance storage areas under limited total resources, ensuring that critical business logs can be accessed in a timely manner. While ensuring the storage of critical logs in the vehicle, it further ensures that critical logs are stored in high-performance storage areas for subsequent access, thereby improving the reliability of the storage system in the vehicle.

[0148] In one implementation, the feature information includes type information, and also includes: determining the target compression method of the target log based on the type information; processing the target log based on the target storage strategy, including: compressing the target log based on the target compression method to obtain the target compressed log; and storing the target compressed log in the target storage area.

[0149] In the embodiments of this application, the appropriate compression strategy is determined based on the content information of the target log obtained by the content analysis module.

[0150] For example, the content analysis module 222 can perform entropy analysis on the data body of the target log to obtain the entropy value of the target log, and determine an appropriate compression strategy based on the entropy value of the target log. For instance, if the target storage strategy of the target log is detected as storage, and the data type of the target log is a binary stream or the entropy value is high, then compression will not be performed.

[0151] It should be understood that the content analysis module 222 obtains the entropy value of the target log by performing entropy analysis on the data volume of the target log. Entropy analysis refers to calculating the information entropy by statistically analyzing the probability distribution of symbols appearing in the data payload of the target log, and using this as a feature dimension to evaluate the physical compression potential of the data, thereby realizing on-demand allocation of CPU computing resources (i.e., high-entropy data is not compressed, and low-entropy data is deeply compressed).

[0152] Based on this, low-entropy data refers to data that exhibits high regularity and has extremely high repetition in log content (e.g., most data consists of repeated 0x00s or continuously looping identical error strings). For low-entropy data, deep compression (e.g., using the ZSTD algorithm) is typically prioritized to achieve a high compression ratio (e.g., over 90%). Therefore, for this type of data, the preferred compression method is: compression. High-entropy data refers to data with random distribution, complex log content, or data that has already been processed. For example, high-entropy data may exhibit the following characteristics: Case 1: The data has already been compressed (e.g., H.264 video streams, compressed packets, etc.); Case 2: The data has already been encrypted (the encrypted ciphertext is statistically close to a random distribution). For high-entropy data, general compression algorithms are almost ineffective (compression ratio may be 1-2%). Forced compression will waste ECU CPU resources and increase power consumption. Therefore, for this type of data, the preferred compression method is: no compression (skip compression).

[0153] In the above implementation, the target compression method is determined based on the type information of the target log, and the log is compressed accordingly before being stored in the target storage area. It can dynamically select the most suitable compression algorithm or not compress at all based on the content and structural characteristics of the log data (such as whether it is a compressed video stream, structured bus frame, or text log). This achieves the determination of an appropriate compression strategy based on different log types. Compared to existing technologies that use a fixed compression algorithm to process all log data, which may lead to additional compression of already compressed video streams or files that do not need compression, resulting in wasted storage system resources and reduced efficiency, this solution can effectively perform targeted and efficient compression of different data because it can perform different compression processes based on the log type, saving storage space and improving storage utilization.

[0154] S340 processes target logs based on the target storage strategy.

[0155] In the embodiments of this application, after determining the target storage strategy based on the target score, a final decision instruction is sent to the adaptive execution layer so that the adaptive execution layer performs the corresponding processing.

[0156] For example, the policy fusion module 232 generates a final decision instruction (e.g., {store in Warm Tier, use ZSTD compression, value 85 points}) based on the feature vector provided by the data perception module 221, the environmental policy provided by the environmental monitoring module 224, and the value score provided by the value assessment module 231, and sends the instruction to the adaptive execution layer 240; after receiving the instruction sent by the policy fusion module 232, the adaptive execution layer 240 calls its sub-modules dynamic compression module 241 and hierarchical scheduling module 242 to execute the instruction, and finally writes the processed log data into the corresponding medium of the physical storage layer 250.

[0157] It should be understood that the dynamic compression module 241 is responsible for performing specific compression operations (such as ZSTD compression, Gzip compression, or no compression) on the log data blocks according to the compression corresponding field in the final decision instruction provided by the policy fusion module 232. The hierarchical scheduling module 242 is responsible for writing the compressed / raw data blocks to the target storage area (i.e., the physical storage layer (such as a high-frequency hot storage layer, a regular warm storage layer, or a persistent archiving layer)) according to the target storage area corresponding field in the final decision instruction provided by the policy fusion module 232.

[0158] In one embodiment, when storing target logs, if the storage space of the target storage area is detected to be full, a storage strategy is determined based on the target score of the logs already stored in the target storage area and the target score of the target log.

[0159] For example, when it is detected that the target log needs to be stored, and the storage space of the target storage area is full, the existing logs are scanned. If the target log is detected ,in, Used to represent the target score of the target log. The target score is used to represent the value of existing logs. If the value of the target log is greater than the value of the existing logs, it is deleted. The corresponding logs are then stored in the target log.

[0160] Optionally, to prevent stored logs with high target scores from continuously occupying storage space, a decay function is introduced to adjust the scores of stored logs so that their corresponding target scores decrease as the storage time increases.

[0161] In one implementation, after storing the target log in the target storage area, the access information of the target log is retrieved again; based on the access information, the weight corresponding to the access information is adjusted. The access information refers to historical behavioral data recorded by the monitoring feedback layer after the target log is written to the physical storage layer, regarding the log's retrieval and reading by external tools (such as cloud diagnostic platforms) or internal services. This data may include access time, visitor identity, and access frequency.

[0162] In the embodiments of this application, the management of logs does not end after they are successfully stored. Instead, the access information generated in a delayed manner is collected periodically or triggered periodically and analyzed. Based on the analysis results (such as frequent access to a certain type of log), targeted optimization rules are generated, and the weights corresponding to the access dimensions / accessed information are dynamically adjusted based on the optimization rules. This allows the solution to make future storage decisions more in line with real operation and maintenance needs.

[0163] For example, the storage health module 262 and performance monitoring module 261 in the monitoring feedback layer 260 continuously monitor the health and performance of the physical storage layer 250 and continuously report the health status and performance data of the physical storage layer 250. When any external tool or internal service is detected to be reading or accessing the logs in the physical storage layer 250, the logging module 263 captures and records this behavior, generating a detailed access log, such as: {Time: T, Visitor: Cloud, Log: GUID-XYZ, Operation: Read}.

[0164] Optionally, the performance / health data stored in the health module 262 and the performance monitoring module 261 are sent to the environment monitoring module 224 to update its understanding of the environment; the historical access logs accumulated in the log recording module 263 are sent to the background learning module 223 as key learning data.

[0165] It should be understood that the background learning module 223, as a background learning engine, can analyze a large number of access logs provided by the log recording module 263 offline (e.g., when the ECU is in an idle state), thereby discovering hidden patterns and rules of data access, and transforming the learned rules into executable optimization rules, which are then injected back into the intelligent decision layer 230 and the adaptive execution layer 240.

[0166] For example, if the logging module 263 discovers, based on the access logs, that a specific type of GNSS log is read by the cloud once every 3 hours after its generation, or that the access frequency of logs related to the embedded MultiMediaCard (eMMC) is much higher than expected, then the logging module 263 will notify the value assessment module 231 to dynamically increase the weight corresponding to the accessed information / access dimension when calculating the value of the GNSS logs or eMMC-related logs next time. .

[0167] Optionally, TTL optimization can be performed on logs that are accessed frequently.

[0168] If the exemplary logging module 263 discovers that the GNSS log is accessed only within 3 hours after it is stored, then the logging module 263 notifies the memory management module 243 to dynamically shorten the TTL of the GNSS log from the current value (e.g., the default value of 7 days) to 4 hours.

[0169] Specifically, the memory management module 243 periodically (e.g., when the ECU is idle or at fixed intervals) activates and scans the physical storage layer 250. Based on the initial TTL allocated by the policy fusion module 232 and the TTL optimization rules notified by the log recording module 263, the memory management module 243 selectively performs physical deletion operations on the log data stored in the physical storage layer 250.

[0170] Physical deletion refers to executing resource release instructions on the corresponding storage object in the physical storage layer based on the dynamically adjusted Effective Time-To-Live (TTL). This operation includes: first, marking the log as "reclaimable" in the metadata index; then, calling the underlying file system or Flash driver interface to perform the actual file deletion, sector erasure, or space reclamation.

[0171] Based on the above operations, the triggering of the deletion operation can be made independent of fixed time parameters, but is a dynamic result jointly determined by the optimization rules fed back by the backend learning module 223 and the initial rules of the frontend decision allocation.

[0172] For example, if the background learning module 223 discovers that a log originally set to expire in 7 days (i.e., TTL is 7 days) has been queried very frequently in the cloud recently, the background learning module 223 will push a TTL optimization rule to the memory management module 243: "Extend TTL". At this time, even if the log has been stored for 8 days, the memory management module 243 will withdraw / not issue a deletion command when performing a scan because the new rule overrides it.

[0173] Optionally, if a debug log is originally scheduled to expire in 7 days, the background learning module 223 determines that it will be worthless after 3 hours, and the memory management module 243 will issue a deletion instruction in advance to release physical space in advance.

[0174] In the embodiments of this application, when a log entry is written for the first time, the policy fusion module 232 will, in its final decision instruction, determine the policy fusion method based on the log entry's... An initial TTL is allocated (e.g., AssignedTTL: "7d"), and the memory management module 243 records this TTL. When the background learning module 223 discovers a better TTL through background learning, it pushes TTL optimization rules to the memory management module 243. The memory management module 243 is periodically activated to scan the physical storage layer 250, determine the logs applicable to the TTL optimization rules, and make adjustments.

[0175] It should be understood that the initial TTL is not a preset maximum value, but rather allocated based on the value score of the log. During subsequent storage, the background learning module 223 will issue TTL optimization rules to overwrite or modify the initial TTL based on the actual utilization rate of this type of log: if the actual utilization rate is extremely low, the optimization rules tend to shorten the TTL to free up space; if the actual utilization rate is extremely high, the optimization rules tend to extend the TTL to protect hot data.

[0176] For example, when a log is generated, the policy fusion module 232 will determine the policy fusion method based on the log data. An initial TTL can be allocated and calculated using a predefined mapping function. For example, if... If the value is greater than or equal to 95, the log entry is considered valuable and can be assigned an initial TTL of 30 days; if... If the value is between 55 and 95, the log entry has moderate value and can be assigned an initial TTL of 3 days.

[0177] Optionally, the initial TTL duration can be related to... The values ​​are positively correlated, meaning the predefined mapping function can be a linear function, a piecewise linear function, or a logarithmic function, etc. For example, the initial TTL can be equal to the scaling factor and The product of and , the proportionality coefficient can be 0.3.

[0178] Optionally, the TTL of the log can be adjusted based on the access information and space occupied by the log.

[0179] For example, the initial TTL of Class A debug logs is set to 7 days. If it is subsequently detected that Class A debug logs have not been accessed within 1 hour of their generation and that their occupied space exceeds a preset space threshold, then the TTL optimization rule for generating Class A debug logs is: "Shorten TTL to 12 hours".

[0180] For example, the initial TTL of the Class B health status log is set to 7 days. If an anomaly is subsequently detected in the vehicle, the cloud continues to track the Class B health status log. If the Class B health status log is still being read on the 6th day after it is stored, then the TTL optimization rule for the Class B health status log is generated: "Delay TTL to 15 days".

[0181] Specifically, the memory management module periodically traverses the physical storage layer, and when processing each specific log entry, it queries the latest rule table pushed by the background learning module in real time. This ensures that even if the B3 rules are updated, they will still be effective on the remaining logs in the next scan cycle.

[0182] It should be understood that the backend learning module 223 can maintain a rule table, which is updated when a TTL optimization rule is detected.

[0183] Furthermore, updating the rule table (running the background learning module 223) usually involves high computational overhead, so it is necessary to choose an appropriate time to do so.

[0184] Optionally, the rule table can be updated based on fixed time intervals, such as once every 12 hours or once every 24 hours.

[0185] Optionally, the background learning module 223 can trigger the learning process when it detects that the CPU utilization rate of the ECU is lower than a preset threshold.

[0186] Optionally, the background learning module 223 can trigger the learning process when it detects that the number of access records in the log recording module 263 exceeds a preset threshold.

[0187] Optionally, the background learning module 223 can trigger the learning process based on specific events, such as after a large-scale remote upgrade or after connecting to an external diagnostic instrument.

[0188] For example, when the memory management module is triggered periodically (e.g., when the ECU is idle or at a fixed interval), it iterates through all log metadata in the physical storage layer. While iterating through each log entry, it queries the rule table maintained by the background learning module. For instance, it checks if there are any new optimization rules for the relevant logs of the current T-Box module in the rule table. If there are new optimization rules, it calculates the TTL based on the updated rules; otherwise, it manages the logs according to the TTL built into the system at the time of writing.

[0189] In another implementation, refined management of storage space is achieved through the collaborative efforts of the intelligent garbage collection function of the memory management module and the emergency backup mechanism of the physical storage layer. Under normal conditions, the memory management module, acting as the core intelligent garbage collector, is responsible for refined lifecycle management of stored data based on log value scores and optimization rules issued by the background learning module, aiming to retain high-value data for longer periods. To prevent storage space from being rapidly exhausted due to sudden data surges during the intervals between the memory management module's periodic scans, the physical storage layer can be configured with an emergency backup logic triggered by a water level: when the remaining storage space is detected to be below a preset critical threshold (e.g., less than 5%), this backup mechanism is activated, temporarily bypassing the intelligent decision-making rules of the memory management module. It employs the most basic yet efficient strategy (such as FIFO or Least Recently Used (LRU) algorithm) to forcibly clean up data to quickly release space, ensuring the system does not crash due to storage overflow. Meanwhile, to ensure system stability, the memory management module determines a "safe time" before performing physical deletion operations. For example, it only performs deletion tasks when the CPU load is below 30% and the disk I / O is idle, thus avoiding garbage collection from occupying resources for critical vehicle services (such as high-speed network transmission or collision data recording).

[0190] In the above implementation, after the target log is stored in the target storage area, its access information is retrieved again. The weights corresponding to the access information of the target log are adjusted, allowing for continuous collection of access data throughout the log's entire lifecycle and adjustment of the corresponding weights accordingly. In contrast, existing technologies fix the log storage strategy at the time of writing, making optimization based on access data generated during vehicle operation impossible. This solution continuously monitors access behavior to the log after storage and uses the access information as feedback signals to optimize the core parameters of value scoring. Therefore, this solution can identify frequently retrieved log types or sources in actual operation and maintenance, increasing their weight in scoring to ensure high-value logs receive better storage strategies. This ensures critical logs are stored in high-performance storage areas for subsequent access.

[0191] In one implementation, based on the accessed information, the number of times the target log is accessed within a preset time period is determined; if the number of accesses exceeds a preset threshold, the weight corresponding to the accessed information is adjusted from a first weight to a second weight. The second weight is greater than the first weight.

[0192] For example, if the background learning module 223 detects that the frequency of access to GNSS-related logs within a preset time period exceeds a preset threshold, then the background learning module 223 increases the access frequency of the GNSS-related logs. and .

[0193] For example, the logging module 263 records every read operation of each application / service on the physical storage layer 250 (e.g., cloud diagnostics, local service fetching), and the background learning module 223 periodically retrieves these historical access logs recorded by the logging module 263. The background learning module 223 receives the raw log streams from the logging module 263, such as {T1, Cloud, Read, Log_A}, {T5, AP, Read, Log_B}, and performs frequency analysis, time-series correlation analysis, visitor correlation analysis, etc., on the raw log streams.

[0194] Specifically, frequency analysis is used to statistically analyze the absolute frequency and relative popularity of different types of logs (e.g., by source dimension). For example, the frequency analysis result might be: "The eMMC health log was accessed 150 times in the past 7 days, while the GNSS track log was accessed only 3 times."

[0195] Time-series correlation analysis can be used to discover the relationship between access behavior and log generation time. For example, the result of time-series correlation analysis is: "95% of CAN-FD debug logs are accessed within 2 hours of their generation. After 2 hours, the access probability approaches 0".

[0196] Visitor correlation analysis can be used to discover the correlation between specific visitors (such as cloud and on-premises access points) and specific log types. For example, the result of visitor correlation analysis might be: "The Cloud_Diagnostic service always reads Modem logs and Network logs in pairs."

[0197] It should be understood that after performing the above analysis, the background learning module 223 obtains the value optimization rules and outputs the value optimization rules to the value assessment module 231.

[0198] For example, when the background learning module 223 finds that the access frequency of the eMMC log is greater than the preset access frequency threshold, the background learning module 223 will notify the value evaluation module 231: "When evaluating the eMMC log next time, please dynamically increase its access weight by 30%." This will automatically increase the target score of high-popularity logs in the future.

[0199] It should be noted that the backend learning module performs periodic statistical analysis on the access logs. When the access frequency (number of reads / unit time) of a specific attribute log exceeds a set threshold, it determines that the log has higher potential application value, thereby triggering a weight optimization instruction.

[0200] For example, the background learning module 223 can maintain a statistics window (sliding window). If it is detected that the number of times N of logs of type L are read is greater than the preset number threshold within a preset time T, an optimization instruction is generated and sent to the value assessment module 231.

[0201] Optionally, the background learning module 223 can perform access density anomaly detection on various types of logs. For example, if the access frequency of a certain type of log suddenly exceeds the historical average by 2 standard deviations, it is considered a "popularity jump," thereby triggering a weight adjustment.

[0202] Alternatively, in one embodiment, the weights can be adjusted based on the health of the storage medium, the success rate of cloud retrieval, and the vehicle network cost / bandwidth status.

[0203] For example, if the storage health module 262 detects that the write lifespan of a Flash partition is nearing its limit, the background learning module 223 will send rules to the value assessment module 231 to dynamically reduce the write weight of that partition, or send instructions to the policy fusion module 232 to forcibly redirect logs to another healthy storage layer. For instance, upon detecting that the eMMC lifespan is nearing its limit, the feedback loop automatically tightens the admission score, allowing only... The logs are written to this eMMC.

[0204] For example, if the cloud reports that a Class C log cannot be parsed due to a lack of context, the background learning module 223 will learn this and notify the value assessment module 231: the next time a Class C log is generated, increase the weight of its associated context logs to ensure they are stored in pairs. For instance, if currently only Error logs are stored, and the cloud reports that the Error log cannot be parsed due to a lack of context, after the feedback loop is closed, the corresponding weights of all Trace logs within 5 seconds before the Error log occurred are automatically increased.

[0205] For example, when network costs are high or the frame status is poor, the weight of compressed logs can be dynamically increased, while the score of logs with medium scores can be decreased, thereby reducing upload pressure.

[0206] In the above implementation, based on the access information, the number of times the target log is accessed within a preset time period is determined. When this number exceeds a preset threshold, the weight corresponding to the access information is increased from a lower first weight to a higher second weight. This transforms the frequency of log access into a feedback adjustment signal in the value scoring model, enabling dynamic parameter calibration and providing feedback adjustment for the judgment of the target log's storage priority. Therefore, this solution can identify high-value logs based on the number of times they are accessed after storage and increase the weight of those logs. Consequently, when these logs are detected again, their higher weight ensures that they are identified as high-priority logs, guaranteeing that higher-value logs are stored within limited storage resources and improving storage space utilization.

[0207] In one implementation, the method further includes: determining a weight adjustment amount based on the number of times the device is accessed, wherein the number of times the device is accessed is proportional to the weight adjustment amount; and determining a second weight based on the first weight and the weight adjustment amount.

[0208] In the embodiments of this application, after counting the number of times the target log is accessed, the number of accesses is mapped to a weight adjustment amount according to a preset mapping relationship. The larger the number of accesses, the higher the value of the log, and the more the weight of the corresponding accessed information / access dimension should be increased.

[0209] For example, the number of visits is positively correlated with the weight adjustment amount, which can be a linear proportional relationship, a logarithmic proportional relationship, or a step-like adjustment relationship.

[0210] In one embodiment, the weight adjustment amount ,in, This is the weight adjustment amount. k This is the proportionality coefficient. This represents the number of times the page has been accessed.

[0211] In another embodiment, the weight adjustment amount ,in, This is the weight adjustment amount. a To adjust the coefficient, This represents the number of times the page has been accessed.

[0212] In another embodiment, multiple threshold ranges can be set. For example, if the number of visits is between 0 and 10, the weight adjustment is 0, i.e., no adjustment is made; if the number of visits is between 10 and 50, the weight adjustment is 0. The weight is 10%, which is an increase of 10% on top of the first weight; the number of visits is greater than 50. It is 20%, which means an increase of 20% on top of the first weight.

[0213] Alternatively, in another implementation, if the number of times the target log is accessed within a preset time is less than or equal to a second preset threshold, the weight corresponding to its accessed information / access dimension is reduced (the weight adjustment amount is negative).

[0214] For example, Class D debug logs are accessed frequently during the system development phase, and their weight is set very high during this phase. After the vehicle is delivered to the user, the cloud no longer accesses Class D debug logs. The background learning module 223 detects that the number of times it is accessed within a consecutive preset time period (e.g., 7 consecutive days) is 0 (less than the second preset threshold, e.g., 5 times), and then sends an instruction to C1: "Reduce the weight of this type of log by 50%".

[0215] Optionally, the amount of weight adjustment for lowering the weight can be positively correlated with the number of times the weight is accessed.

[0216] In the above implementation, the weight adjustment amount is determined proportionally based on the number of times the log is accessed, and this is combined with the first weight to calculate the second weight. This establishes a positive correlation between the magnitude of the weight adjustment and the actual number of times the log is accessed, achieving adaptive optimization. Furthermore, it can determine whether weight adjustment is necessary and decide the adjustment intensity based on the access frequency. Since the weight adjustment amount is proportional to the number of accesses in this scheme, logs with higher access frequencies will receive higher scores for their corresponding features in the scoring. Therefore, this scheme can adjust the storage priority of a log based on its access frequency, ensuring that logs with higher storage priority are stored, thus improving the rationality of resource allocation strategies and storage efficiency.

[0217] The following is combined with Figure 4 Another method for storing vehicle logs is described in detail.

[0218] S401 obtains the current environmental policy after detecting that the ECU is powered on.

[0219] For example, when the vehicle starts, the environmental monitoring module detects that the battery voltage is 11.8V (lower than the nominal value), determines that it enters the "low voltage protection mode", and loads the corresponding environmental policy: restricting compression operations and prioritizing the discarding of low-value logs to save power consumption.

[0220] S402, Get the new log queue.

[0221] For example, while the vehicle is in motion, the CAN bus communication service, GNSS positioning service and application processor debugging service simultaneously generate logs, which are temporarily stored in a shared buffer to form a new log queue to be processed.

[0222] S403, check if there is a log in the new log queue; if yes, execute S404; if no, execute S409.

[0223] For example, if the system checks the buffer and finds that there are 3 log entries to be processed, it will continue to execute S404; if the buffer is empty, it will jump to the background learning and judgment stage and execute S409.

[0224] S404, retrieve the target log from the new log queue.

[0225] For example, the first log entry is retrieved from the queue in a first-in-first-out order. This log entry, generated by the CAN bus service, contains the message "Engine torque output abnormal".

[0226] S405, Extract the feature vector from the target log.

[0227] For example, the log is subjected to multi-dimensional perception: the source is "engine_control" and the level is "ERROR"; content analysis shows that it is structured data with low entropy; the environmental state is "normal driving, temperature 70°C". All features are encapsulated into 5D vectors.

[0228] S406, the final value score is obtained based on the feature vector.

[0229] For example, based on the above features, the scoring model calculates the scores for each dimension and sums them with weights to finally output a value score. =85.

[0230] S407, the storage strategy is derived based on the final value score.

[0231] For example, according to the policy mapping table, a score of 85 falls into the "70~90" range, and the corresponding policy is: store in a general warm storage layer, use ZSTD compression, and allocate an initial TTL of 7 days.

[0232] S408, execute storage policy.

[0233] For example, the dynamic compression module compresses the log using the ZSTD algorithm, the hierarchical scheduling module writes it to a general flash partition, and records the TTL as 7 days in the metadata.

[0234] S409, determine whether background learning has been triggered; if yes, execute S410; if no, execute S411.

[0235] For example, the system is set to trigger learning during the idle period in the early morning. If the current time is 03:00 and the CPU load is below 10%, the trigger condition is met, and the system proceeds to step S410; otherwise, step S411 is executed.

[0236] S410 performs background learning based on access information from logs.

[0237] For example, the backend learning module analyzes the access records of the past week and finds that logs of the "brake system wear warning" category are frequently retrieved. Therefore, it generates a rule to increase the weight of the "access dimension" of this type of log by 20%.

[0238] S411, determine whether the log cleanup process has been triggered; if yes, execute S412; if no, execute S413.

[0239] For example, determine whether the log cleanup process has been triggered. If yes, immediately trigger the log cleanup process and execute S412; otherwise, execute S413.

[0240] S412, intelligent cleanup of execution logs.

[0241] For example, the lifecycle manager scans all logs, calculates their current effective value (combining initial score with time decay), and deletes the 20 logs with the lowest scores to free up space.

[0242] S413, loop ends, waiting for the next trigger.

[0243] For example, once this round of processing is complete, the system enters a low-power sleep state until the next log event or timer expires, waking up for a new processing cycle.

[0244] The following is combined with Figure 5 A method for processing vehicle log data is described in detail.

[0245] S501 obtains raw logs and metadata through the application layer.

[0246] For example, when the application layer detects that the automatic emergency call system (eCall) has failed to trigger, the application layer 210 generates a log entry with the content "eCall Activation Timeout" and includes metadata: {timestamp: 2023-10-27 15:30:05, module: Telematics, log level: ERROR, vehicle VIN: LSVAU123556789012}.

[0247] S502 sends the raw logs and metadata to the data awareness module.

[0248] For example, when the automatic emergency call system (eCall) is detected to have failed to trigger, the application layer 210 generates a log entry with the content "eCall Activation Timeout" and includes metadata: {timestamp: 2023-10-27 14:30:05, module: Telematics, log level: ERROR, vehicle VIN: LSVAU123456789012} and sends it to the data awareness module 221.

[0249] S503 sends the raw logs to the content analysis module.

[0250] For example, the data awareness module 221 extracts the original log text "eCall Activation Timeout" separately and sends it to the content analysis module 222.

[0251] S504 analyzes the raw data through the content analysis module to obtain content features.

[0252] For example, the content analysis module 222 analyzes the log text and extracts content features, such as: ={Data type:BINARY, Entropy: 7.8, PII: True, Compression suggestion: None}.

[0253] S505 sends the content features to the data perception module.

[0254] For example, the content analysis module 222 analyzes the log text and extracts content features, such as: ={Data type:BINARY, Entropy value: 7.8, PII: True, Compression suggestion: None} and send it to the data awareness module 221.

[0255] S506 obtains a five-dimensional feature vector through the data perception module.

[0256] For example, the data awareness module 221 quantizes the logs into a five-dimensional vector according to predefined rules, such as: .

[0257] S507 sends the five-dimensional feature vector to the value assessment module and the strategy fusion module.

[0258] For example, the data sensing module 221 will And send it to the value assessment module 231 and the strategy fusion module 232.

[0259] S508 sends the final value score to the strategy fusion module.

[0260] For example, the value assessment module 231 will, according to the method in S320, Quantified into a final value score And send it to the policy fusion module 232.

[0261] S509 sends environmental policies to the policy fusion module through the environmental monitoring module.

[0262] For example, the environmental monitoring module 224 determines the environmental policy based on the detected environmental information and sends it to the policy fusion module 232.

[0263] S510 integrates the five-dimensional feature vector, environmental policy, and final value score through the policy fusion module to obtain the final decision instruction.

[0264] For example, the policy fusion module 232 determines the target storage policy (final decision instruction) based on the acquired information.

[0265] S511 sends the final decision instruction to the adaptive execution layer.

[0266] For example, the policy fusion module 232 sends the final decision instruction corresponding to the target storage policy to the adaptive execution layer 240.

[0267] S512 executes the final decision instruction through the adaptive execution layer.

[0268] For example, after receiving the final decision instruction, the adaptive execution layer 240 executes the operation corresponding to the final decision instruction.

[0269] S513 writes raw logs and metadata to the physical storage layer through an adaptive execution layer.

[0270] For example, after receiving the final decision instruction, the adaptive execution layer 240 sends log data and storage instructions to the physical storage layer 250 so that the data is written to the physical storage medium.

[0271] In the above embodiments, through multi-level collaborative processing, raw data is transformed into executable instructions with clear value tags and optimal storage strategies, realizing a shift from blind data storage in existing technologies to value-driven management. Compared with existing technologies, this method can not only effectively distinguish and prioritize the protection of high-value critical logs, preventing them from being overwhelmed by data surges, but also adaptively adjust strategies according to real-time environmental conditions, ensuring the reliability and resource utilization efficiency of the system under various complex vehicle operating conditions.

[0272] The following is combined with Figure 6 A feedback method for a vehicle log storage system is described in detail.

[0273] S601, the physical storage layer obtains status / health data and access information.

[0274] For example, the physical storage layer 250 obtains status / health data and access information from the transient cache layer 251, the high-frequency hot storage layer 252, the normal temperature storage layer 253, and the persistent archive layer 254.

[0275] S602 sends status / health data to the performance monitoring module and the storage health module.

[0276] For example, the physical storage layer 260 sends status / health data to the performance monitoring module 261 and storage health module 262 in the monitoring feedback layer 260. For instance, the vehicle reports its system health status to the cloud every 6 minutes: {CPU utilization: 66%, memory remaining: 612MB, storage utilization: 86%, network signal strength: -86dBm}.

[0277] S603 sends the access information to the logging module.

[0278] For example, the physical storage layer 260 sends access logs to the logging module 263 in the monitoring feedback layer 260. For instance, when a vehicle diagnostic tool reads logs through the OBD interface, the logging module 263 records and reports an access log entry {Time: 2023-10-27 09:16:00, Accessed file: error_log_20231027.bin, Operation type: Read}.

[0279] S604, the performance monitoring module and the storage health module send status / health data to the environment monitoring module.

[0280] For example, the performance monitoring module 261 and the storage health module 262 send status / health data to the environment monitoring module 224 in the perception and analysis layer 220.

[0281] S605 records access information through the log recording module and sends it to the backend learning module.

[0282] For example, the logging module 263 records the access information and sends it to the background learning module 223.

[0283] S606 processes access information through the background learning module to generate value optimization rules and TTL optimization rules.

[0284] For example, after receiving the access information, the background learning module 223 generates value optimization rules and TTL optimization rules.

[0285] S607, send the value optimization rules to the value assessment module.

[0286] For example, the background learning module 223 sends value optimization rules to the value assessment module 231 in the intelligent decision-making layer 230. For instance, after analyzing the access records, the background learning module 223 issues an updated value scoring rule: "When the vehicle is in a post-collision state, the weight score corresponding to the content dimension of the DEBUG log related to 'airbag triggering' is adjusted from 0.3 to 1.0."

[0287] S608 updates the value optimization rules through the value assessment module.

[0288] S609 sends the TTL optimization rules to the memory management module.

[0289] For example, the background learning module 223 sends TTL optimization rules to the memory management module 243 in the adaptive execution layer 240.

[0290] The S610 updates the TTL optimization rules through the memory management module.

[0291] In the above embodiments, by collecting the operational status and access information of the physical storage layer, and dynamically adjusting the value assessment model and lifecycle management strategy based on this, the entire storage management system avoids dependence on static configuration and achieves continuous self-learning and evolution. Compared with static traditional solutions, this feedback loop ensures that the storage strategy provided in this application embodiment can be continuously and accurately optimized according to the actual use and maintenance needs of the vehicle, thereby maintaining the efficiency of resource allocation and the adaptability of decision-making in long-term operation, significantly improving the intelligence level and long-term value of the vehicle storage method.

[0292] The above text combined Figures 1 to 6 This application provides a detailed description of a vehicle log storage method based on an embodiment; the following will be combined with... Figure 7 and Figure 8 The apparatus embodiments of this application are described in detail below. It should be understood that the apparatus in the embodiments of this application can perform the various methods described in the foregoing embodiments of this application, that is, the specific working processes of the various products described below can be referred to the corresponding processes in the foregoing method embodiments.

[0293] Figure 7 This is a schematic diagram of the structure of a vehicle log storage device provided in an embodiment of this application. The vehicle log storage device 700 includes an acquisition module 710 and a processing module 720.

[0294] The acquisition module is used to acquire the characteristic information of the target log when the presence of the target log to be stored in the vehicle is detected; The processing module is used to determine the target score based on feature information, which represents the storage priority of the target log; determine the target storage strategy based on the target score; and process the target log based on the target storage strategy.

[0295] Optionally, as an embodiment, the processing module 720 is specifically used to: when the target score is greater than or equal to the first score threshold, obtain the target storage area based on the target score, and determine the target storage strategy as storing the target log in the target storage area; when the target score is less than the first score threshold, determine the target storage strategy as discarding the target log.

[0296] Optionally, as an embodiment, the processing module 720 is specifically used to: when the target score is greater than or equal to the second score threshold, obtain the target storage area as the first storage area; when the target score is less than the second score threshold, obtain the target storage area as the second storage area; wherein, the storage write speed of the second storage area is lower than the storage write speed of the first storage area, and the first score threshold is lower than the second score threshold.

[0297] Optionally, as an embodiment, the processing module 720 is further configured to: determine the target compression method of the target log based on the type information; process the target log based on the target storage strategy, including: compressing the target log based on the target compression method to obtain the target compressed log; and storing the target compressed log in the target storage area.

[0298] Optionally, as an embodiment, the processing module 720 is further configured to: after storing the target log in the target storage area, obtain the accessed information of the target log again; and adjust the weight corresponding to the accessed information based on the accessed information.

[0299] Optionally, as an embodiment, the processing module 720 is specifically used to: determine the number of times the target log is accessed within a preset time based on the accessed information; if the number of accesses is greater than a preset threshold, adjust the weight corresponding to the accessed information from a first weight to a second weight, wherein the second weight is greater than the first weight.

[0300] Optionally, as an embodiment, the processing module 720 is further configured to: determine a weight adjustment amount based on the number of times the device is accessed, wherein the number of times the device is accessed is proportional to the weight adjustment amount; and determine a second weight based on the first weight and the weight adjustment amount.

[0301] Optionally, as an embodiment, the processing module 720 is further configured to: obtain the scoring function corresponding to the feature information and the weight corresponding to the feature information; determine the target score based on the feature information, including: obtaining a first score based on the scoring function corresponding to the feature information and the feature information; and obtaining the target score based on the first score and the weight.

[0302] Optionally, as an embodiment, the processing module 720 is further configured to: determine the current mode of the vehicle based on environmental information and source information; when the current mode is a preset mode, adjust the weights of the environmental information and the corresponding weights of the source information, wherein the preset mode includes a collision mode and a diagnostic mode.

[0303] It should be noted that the aforementioned vehicle log storage device 700 is embodied in the form of a functional unit. The term "module" here can be implemented in software and / or hardware, without specific limitations.

[0304] For example, a "module" can be a software program, hardware circuit, or a combination of both that implements the above functions. Hardware circuits may include application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0305] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0306] Figure 8 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. For example, the vehicle 800 includes: a processor 810, a memory 820, and executable program code 830.

[0307] For example, vehicle 800 includes one or more processors 810 that can support the vehicle 800 in implementing the vehicle log storage method in the method embodiment. The processor 810 can be a general-purpose processor or a special-purpose processor. For example, the processor 810 can be a CPU, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gates, transistor logic devices, or discrete hardware components.

[0308] For example, the processor 810 can be used to control the vehicle 800, execute software programs, and process data from the software programs. The vehicle 800 may also include a communication unit for receiving and transmitting signals.

[0309] Optionally, the memory 820 may also store data. Optionally, the processor 810 may also read data stored in the memory 820, which may be stored at the same memory address as the executable program code 830, or the data may be stored at a different memory address than the executable program code 830.

[0310] For example, the processor 810 and memory 820 can be configured separately or integrated together, for example, integrated on the system-on-chip (SOC) of the terminal device.

[0311] For example, the memory 820 can be used to store the relevant program of the vehicle log storage method provided in the embodiments of this application, and the processor 810 can be used to call the executable program code 830 stored in the memory 820 when controlling the vehicle to execute the vehicle log storage method of the embodiments of this application. This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the vehicle log storage method of any of the foregoing embodiments.

[0312] The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0313] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the vehicle log storage method in the above embodiments.

[0314] In addition, the electronic device provided in the embodiments of this application may specifically be a chip, component or module. The electronic device may include a connected processor and a memory. The memory is used to store instructions. When the electronic device is running, the processor may call and execute the instructions to make the chip execute the vehicle log storage method in the above embodiments.

[0315] The vehicle, computer-readable storage medium, computer program product or chip provided in this application are all used to execute the corresponding vehicle log storage method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding vehicle log storage method provided above, and will not be repeated here.

[0316] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

Claims

1. A storage method of a vehicle log, characterized by, The storage method comprises: obtaining feature information of the target log when it is detected that there is a target log to be stored in the vehicle; determining a target score based on the feature information, the target score being used to represent a storage priority of the target log; determining a target storage strategy based on the target score; processing the target log based on the target storage strategy.

2. The storage method according to claim 1, wherein, The determining of the target storage strategy based on the target score comprises: when the target score is greater than or equal to a first score threshold, obtaining a target storage area based on the target score, and determining the target storage strategy as storing the target log to the target storage area; when the target score is less than the first score threshold, determining the target storage strategy as discarding the target log.

3. The storage method according to claim 2, wherein, The obtaining of the target storage area based on the target score comprises: when the target score is greater than or equal to a second score threshold, obtaining the target storage area as a first storage area; when the target score is less than the second score threshold, obtaining the target storage area as a second storage area; wherein a storage write speed of the second storage area is lower than a storage write speed of the first storage area, and the first score threshold is lower than the second score threshold.

4. The storage method according to claim 2, wherein, The feature information comprises type information, and the storage method further comprises: determining a target compression mode of the target log based on the type information; The processing of the target log based on the target storage strategy comprises: compressing the target log based on the target compression mode to obtain a target compressed log; storing the target compressed log to the target storage area.

5. The storage method according to claim 3, wherein, In the case that the target storage strategy is to store the target log to the target storage area, the storage method further comprises: after storing the target log to the target storage area, obtaining accessed information of the target log again; adjusting a weight corresponding to the accessed information based on the accessed information.

6. The storage method according to claim 5, wherein, The adjusting of the weight corresponding to the accessed information based on the accessed information comprises: determining a number of times of access of the target log within a preset time based on the accessed information; if the number of times of access is greater than a preset number threshold, adjusting the weight corresponding to the accessed information from a first weight to a second weight, the second weight being greater than the first weight.

7. The storage method according to claim 6, wherein, The storage method further comprises: determining a weight adjustment amount based on the number of times of access, the number of times of access being proportional to the weight adjustment amount; determining the second weight based on the first weight and the weight adjustment amount.

8. The storage method of any one of claims 1 to 7, characterized in that, The storage method further comprises: obtaining a score function corresponding to the feature information and a weight corresponding to the feature information; The determining of the target score based on the feature information comprises: obtaining a first score based on the score function corresponding to the feature information and the feature information; obtaining the target score based on the first score and the weight.

9. The storage method according to claim 8, wherein, The feature information comprises environment information and source information, and the storage method further comprises: determine a current mode of the vehicle based on the environment information and the source information; adjust a weight of the environment information and a weight corresponding to the source information when the current mode is a preset mode, the preset mode including a collision mode and a diagnosis mode.

10. A vehicle characterized by comprising: The vehicle includes: a memory for storing executable program codes; a processor for calling and running the executable program codes from the memory, so that the vehicle executes the storage method as claimed in any one of claims 1 to 9.

Images