Log data processing method and computer readable storage medium, vehicle

Abstract

This application discloses a log data processing method, a computer-readable storage medium, and a vehicle, relating to the field of data processing technology. The log data processing method includes: receiving log data and writing the log data into a first data buffer in memory; in response to meeting a preset trigger condition, initiating a background write operation to write the log data in the first data buffer into the storage medium; and when initiating the background write operation, writing new log data into a second data buffer in memory. This method can reduce the IO pressure on the storage medium, avoid IO anomalies and disk jitter under high load, and ensure the overall performance and stability of the system.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a log data processing method, a computer-readable storage medium, and a vehicle. Background Technology

[0002] In the process of processing log data in a vehicle's intelligent cockpit system, to ensure stable system operation and facilitate subsequent problem diagnosis, it is typically necessary to write the operational logs generated by key modules such as Bluetooth HCI (Host Controller Interface) to the vehicle's non-volatile storage medium (hereinafter referred to as storage medium) in real time and completely. This requirement aims to ensure that in the event of faults such as Bluetooth connection anomalies, effective problem localization and analysis can be performed based on complete log records.

[0003] Currently, a common approach to handling this type of continuously generated, high-frequency log data is to perform full real-time writing and full shutdown. This means initiating storage operations immediately after log data generation, regardless of system load. However, if log output is disabled, missing logs will prevent troubleshooting and problem location when Bluetooth-related issues arise. Because these logs are characterized by small data packets and high generation frequency, full real-time writing essentially submits a large number of frequent small-scale input / output requests to the storage system. When the intelligent cockpit system is operating under high load, such as simultaneously performing core functions like navigation and audio / video playback, system input / output resources (IO resources) are already strained. At this time, the numerous small-scale input / output operations generated by log writing will fiercely compete with core application requests for limited storage bandwidth, processing queues, and CPU interrupt resources, easily leading to input / output congestion and latency.

[0004] Therefore, enabling full logging to ensure log integrity can lead to overall system performance degradation under high load due to input / output resource contention, impacting the responsiveness of core business operations and user experience. Conversely, disabling logging to avoid performance impact can prevent problem analysis due to a lack of valid logs in the event of a failure. As intelligent cockpit systems become increasingly complex and performance requirements rise, ensuring both smooth operation of core business operations and the preservation of critical logs under high load conditions has become a pressing technical challenge. Summary of the Invention

[0005] This application aims to at least partially address one of the technical problems in related technologies. To this end, the first objective of this application is to propose a log data processing method. This method receives log data and preferentially writes it to a first data buffer in memory. Only when specific conditions are met is a background write operation initiated, batch-writing the accumulated log data in the first buffer to the storage medium, while simultaneously directing subsequent new log data to a second data buffer. This core mechanism integrates numerous scattered and frequent small I / O operations into fewer, larger-volume batch I / O operations, thereby significantly reducing the occupation and contention of critical I / O resources such as storage media, system bus, and CPU (Central Processing Unit). Therefore, it effectively reduces overall system I / O latency, ensures the smooth operation of core business applications, and improves resource utilization efficiency and response speed.

[0006] The second objective of this application is to provide a computer-readable storage medium.

[0007] The third objective of this application is to propose a vehicle.

[0008] To achieve the above objectives, a first aspect of this application proposes a log data processing method, the method comprising: receiving log data and writing the log data into a first data buffer in memory; in response to satisfying a preset trigger condition, initiating a background write operation to write the log data in the first data buffer into a storage medium; and writing new log data into a second data buffer in memory when the background write operation is initiated.

[0009] According to the log data processing method of this application embodiment, log data is received and written into a first data buffer in memory. In response to the satisfaction of a preset trigger condition, a background write operation is initiated to write the log data in the first data buffer into the storage medium. When the background write operation is initiated, new log data is written into a second data buffer in memory. Thus, by receiving log data and preferentially writing it into the first data buffer in memory, and only initiating the background write operation when specific conditions are met, the accumulated log data in the first buffer is written into the storage medium in batches. This significantly reduces the occupation and contention of critical I / O resources such as storage medium, system bus, and CPU. The second data buffer seamlessly takes over the task of receiving new log data, avoiding data reception blocking caused by waiting for disk I / O to complete in the traditional single-buffer mode. This design allows the generation and consumption of log data to overlap in time, ensuring uninterrupted log writing, avoiding buffer overflow problems, eliminating write waiting gaps, and significantly improving the throughput and real-time performance of the log system. Furthermore, this method achieves fine-grained control over the writing timing through flexible configuration of preset trigger conditions.

[0010] According to one embodiment of this application, the method further includes: monitoring a target load, wherein the target load includes at least one of a central processing unit load and an input / output load; and dynamically adjusting the preset triggering conditions based on the target load.

[0011] According to one embodiment of this application, the preset triggering condition includes the data volume of the first data buffer reaching a preset capacity threshold and / or reaching a preset write duration. The step of dynamically adjusting the preset triggering condition based on the target load includes: increasing the preset capacity threshold and / or increasing the preset write duration when the target load is higher than a first preset load threshold.

[0012] According to one embodiment of this application, the method further includes: when the target load is lower than a second preset load threshold, reducing the preset capacity threshold and / or reducing the preset write duration, wherein the second preset load threshold is less than the first preset load threshold.

[0013] According to one embodiment of this application, before the preset triggering condition is met, the method further includes: in the event of detecting an abnormal event, initiating a background write operation to write the log data currently written to the first data buffer to the storage medium.

[0014] According to one embodiment of this application, when initiating the background write operation, the method further includes: updating the status identifier of the first data buffer to a write identifier and updating the status identifier of the second data buffer to a read identifier, wherein the status identifier update operation is implemented through atomic operations.

[0015] According to one embodiment of this application, initiating a background write operation to write log data from the first data buffer to a storage medium includes: organizing all accumulated log data in the first data buffer into a single input / output request for sending to the storage medium; or, sending all accumulated log data in the first data buffer in batches to the storage medium.

[0016] According to one embodiment of this application, the log data is Bluetooth log data of an intelligent cockpit system, and the first data buffer and the second data buffer are circular buffers, with the first data buffer and the second data buffer having the same or different buffer capacities.

[0017] To achieve the above objectives, a second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the above-described log data processing method.

[0018] The computer-readable storage medium according to the embodiments of this application, by implementing the above-described log data processing method during execution, can reduce the IO pressure of the storage medium, avoid IO anomalies and disk jitter under high load, and ensure the overall performance and stability of the system.

[0019] To achieve the above objectives, a vehicle is provided in a third aspect of this application, including a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described log data processing method.

[0020] According to the vehicle embodiment of this application, by executing the above-described log data processing method, the IO pressure on the storage medium can be reduced, IO anomalies and disk jitter under high load can be avoided, and the overall performance and stability of the system can be guaranteed.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] Figure 1 This is a flowchart of a log data processing method according to an embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating a specific example of a log data processing method according to this application.

[0024] Figure 3 This is a block diagram of a vehicle according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0026] In the development and operation of intelligent cockpit systems, to achieve traceability and analysis of system behavior and faults, the common practice is for each functional module within the system (such as the Bluetooth communication module) to generate real-time log data recording its operational status, and to immediately and synchronously write each newly generated log data entry to an onboard non-volatile storage medium (such as eMMC (Embedded MultiMediaCard) or solid-state drive). This approach is widely adopted primarily to ensure the timely persistence of log information, thereby enabling the acquisition of the most complete and timely on-site data when system anomalies or faults occur, to assist in problem localization.

[0027] However, this solution performs poorly when applied to complex scenarios involving high-load operation of intelligent cockpit systems. To optimize the real-time performance and integrity of log data, its inherent real-time synchronous writing design inevitably compromises the overall input / output performance and responsiveness of the system. For example, in specific application scenarios where users simultaneously utilize high-definition navigation, play online audio and video streaming media, and connect and interact with multiple Bluetooth devices, the challenge of the Bluetooth module continuously generating massive amounts of high-frequency small data block logs leads to the storage medium interface being frequently occupied by a large number of small write operation requests. This results in input / output queue congestion, a sharp increase in storage medium response latency, and excessive load on the central processing unit due to handling numerous write operation interruptions. These phenomena ultimately manifest as operational stuttering and response latency in core intelligent cockpit services (such as navigation screen rendering and audio decoding playback), severely impacting the user experience.

[0028] In-depth analysis revealed that the continuous generation of log data and the data access needs of core business operations fiercely compete for the same limited set of input / output resources under high system load. These resources include the storage medium's read / write operation processing capacity per second, system bus bandwidth, CPU interrupt handling overhead, and the operating system kernel's input / output stack lock resources. The frequent small-scale input / output operations in the traditional real-time synchronous write mode are precisely the least efficient operation mode in consuming these resources and causing the greatest interference to system performance. To address these issues, this application proposes a log data processing method that introduces a dual data buffer for temporary storage and transfer of log data, and asynchronously initiates batch write operations based on preset trigger conditions. This improves the key bottleneck in log data persistence, significantly reducing the contention pressure on system input / output resources without significantly sacrificing the final integrity of the log data, thus avoiding system performance degradation caused by log writing. This solves the technical problem of intense competition for system input / output resources and overall performance degradation caused by frequent synchronous log data writing, achieving the technical effect of ensuring smooth operation of the core business of the intelligent cockpit while guaranteeing no loss of log information.

[0029] In one embodiment of this application, such as a smart cockpit system, the system includes a central processing unit, memory, and non-volatile storage media. The system runs multiple application processes, such as a navigation application, a media playback application, and a Bluetooth protocol stack service. During operation, the host controller interface module in the Bluetooth protocol stack continuously generates log data recording its protocol interactions, state transitions, and event information. This log data needs to be reliably stored for subsequent analysis. The log data processing method of this application can be executed by an independent logging service process or thread. This service runs at the software level of the aforementioned smart cockpit system and can access system memory and call file system interfaces to write data to the storage media.

[0030] The log data processing method, computer-readable storage medium, and vehicle proposed in this application are described below with reference to the accompanying drawings.

[0031] Figure 1 This is a flowchart of a log data processing method according to an embodiment of this application.

[0032] like Figure 1 As shown, the log data processing method of this application embodiment may include the following steps: S1 receives log data and writes the log data into the first data buffer in memory.

[0033] Specifically, once the logging service starts, it receives real-time log data from a log data source (such as a Bluetooth host controller interface module). As a specific implementation, log data can be passed to the logging service via inter-process communication, shared memory, or callback function interfaces. Upon receiving the log data, the service does not immediately call the file system interface to write it to the storage medium. Instead, it first appends the data to the end of a first data buffer pre-allocated in memory. This first data buffer is initially designated as a foreground write buffer, specifically for receiving newly arriving log data. Thus, this approach transforms the slow input / output operations to the storage medium into high-speed write operations to memory, fundamentally avoiding the immediate triggering of an actual physical input / output request for each log entry.

[0034] The first data buffer written to memory can be implemented in several ways. For example, it can include, but is not limited to, copying log data to the current write pointer position of the buffer and updating the pointer using a memory copy function; or performing lock-free writing through a ring buffer interface that supports atomic operations. At the hardware level, a direct memory access controller can be used to assist in high-speed data movement; at the software or logic level, it can be implemented by executing a sequence of instructions that copies the contents of the source data address to the target buffer address. It should be noted that writing log data to the first data buffer in memory provides a prerequisite for subsequent batch asynchronous writes. By first aggregating scattered log data in memory, it allows for the subsequent merging and processing of this data, thereby reducing the frequency of input / output operations.

[0035] It should be noted that, in this application, memory refers to a volatile storage medium with high-speed random access capabilities, which differs from non-volatile storage devices such as disks and flash memory, and can complete data read and write operations with nanosecond-level latency. Specifically, the memory involved in this application includes, but is not limited to, dynamic random access memory, static random access memory, or on-chip cache integrated within the processor chip. Log data refers to any information data unit that records the operating status, events, errors, or operation processes of a system, module, or application. Specifically, it can refer to the protocol data packet records generated by the Bluetooth host controller interface module in the intelligent cockpit system, and can also cover debugging and operating information generated by other vehicle electronic control units, applications, or operating system kernels. Data buffer refers to a continuous or non-contiguous area in memory reserved for temporary storage of data streams. For example, it may include, but is not limited to, a first-in-first-out queue buffer implemented based on an array or linked list structure, or a circular buffer with head and tail pointers.

[0036] S2, in response to the fulfillment of a preset trigger condition, initiates a background write operation to write log data from the first data buffer to the storage medium.

[0037] Specifically, a preset trigger condition refers to any logical judgment rule or threshold that can be detected and used to decide whether to initiate subsequent operations. For example, it may include, but is not limited to, time conditions (such as timer timeout), space conditions (such as the amount of data in the buffer reaching a threshold), or event conditions (such as a system state change). For instance, it could refer to the amount of data occupied in the first data buffer reaching a preset capacity threshold. Specifically, the logging service can periodically or after each log write check the remaining space in the current first data buffer. When the amount of data written reaches or exceeds the preset threshold (e.g., 80% of the total buffer size), the trigger condition is determined to be met. A preset trigger condition can also be reaching a preset write duration. For example, the system can maintain a timer that starts counting after the last background write operation. When the timer reaches a preset time interval (e.g., 100 milliseconds), regardless of whether the first data buffer is full, the trigger condition is determined to be met, and background writing is initiated. Using both capacity full and timed arrival trigger conditions can balance data accumulation efficiency and the timeliness of log writes to disk. When data is generated quickly, the "buffer full" event is triggered first to achieve a high merging rate; when data is generated slowly, the "timed arrival" event is triggered to prevent logs from being lost due to prolonged retention in memory.

[0038] In response to the fulfillment of any preset trigger condition, the logging service initiates an asynchronous task. The goal of this task is to write all log data temporarily stored in the current first data buffer to a specified log file on the onboard storage medium (such as eMMC). Initiating a background write operation can be achieved by: creating a new thread or submitting a task to a thread pool, which is responsible for performing the actual file writing; or by calling the asynchronous file write application programming interface provided by the operating system, passing the buffer pointer and data length to the kernel, which then performs the actual disk write operation in the background. A background write operation refers to a non-blocking, asynchronous process of transferring data from volatile memory to non-volatile memory. This operation is typically executed in a separate thread, process, or asynchronous input / output interface provided by the operating system, ensuring that the time-consuming process of writing data to the storage medium does not hinder the continuous reception and temporary storage of new log data.

[0039] Therefore, multiple scattered small-scale input / output requests can be merged into one or a few large-scale data block write requests, greatly reducing the actual number of input / output operations.

[0040] S3 writes new log data to the second data buffer in memory when a background write operation is initiated.

[0041] Specifically, when initiating a background write operation, new log data can be written to a second data buffer in memory. That is, when the background write operation is initiated in step S2 due to the fulfillment of the triggering condition, or within a very short time afterward, the logging service needs to immediately switch the role of the first data buffer and activate the second data buffer to handle subsequently generated log data. Specifically, the first data buffer, which was originally the active write area, is marked as pending persistence, and all log data temporarily stored within it is locked, no longer accepting new write requests, to ensure that the background write thread can read complete and consistent data. Simultaneously, the second data buffer is activated as the new active write area, and all new log data subsequently received by the logging service will be appended to this buffer.

[0042] This dual-buffer alternation mechanism completely decouples the log data reception and persistence processes. Since background write operations typically involve time-consuming operations such as mechanical seeks on the storage medium or erasing and writing flash pages, their execution cycles can reach tens or even hundreds of milliseconds. If the reception of new log data is paused during this period, it will cause upper-layer application threads to be blocked or log data to be lost. By instantly switching to the second data buffer, the logging service can maintain continuous responsiveness to external log data streams throughout the entire background write operation, thus meeting the stringent real-time and data integrity requirements of the vehicle system.

[0043] Once the background write operation is successfully completed—that is, all log data in the first data buffer has been reliably written to the designated log file on the vehicle storage medium—the logging service resets the first data buffer to an empty state and sets it to standby. If the second data buffer subsequently meets the triggering conditions, a buffer switch can be performed again, using the second data buffer as the buffer to be persisted, while the cleared first data buffer is reactivated as the active write area. This forms a continuous, alternating operation mechanism between the two buffers.

[0044] Thus, through the collaboration of the first and second data buffers, asynchronous batch writing can be completed efficiently without blocking the producer (log source), thereby jointly solving the technical problem of log writing competing with system input and output resources, achieving the dual effect of reducing input and output pressure while ensuring that logs are not lost.

[0045] Therefore, by firstly, temporarily storing log data in a memory buffer, high-frequency, scattered write operations are transformed into low-frequency, batch write operations, significantly reducing the actual number of physical input / output operations and effectively alleviating the write pressure on the storage medium. Secondly, the instant switching mechanism of the dual buffers ensures complete parallelism between log reception and persistence processes. Even during background write operations, newly generated log data can still be continuously received, avoiding upper-layer application blocking or data loss due to disk write latency, and meeting the real-time requirements of the vehicle system for millisecond-level response. In addition, the conditional judgment of preset trigger conditions ensures sufficient data accumulation to improve merging and writing efficiency, while the timeout mechanism prevents logs from remaining in memory for too long, achieving an optimal balance between data integrity and timely writing. Finally, without increasing additional hardware costs, only through software-level buffer management and asynchronous scheduling optimization, the log throughput and system stability can be improved simultaneously, providing reliable data support for the efficient operation and maintenance and fault tracing of the intelligent cockpit system.

[0046] According to one embodiment of this application, the log data processing method further includes: monitoring target load, wherein the target load includes at least one of central processing unit load and input / output load; and dynamically adjusting preset triggering conditions based on the target load.

[0047] Specifically, to further optimize the rationality of system resource allocation in the above embodiments and enable the log writing strategy to adaptively adjust according to the real-time system load, this application also provides the following preferred solution: Monitoring the target load, where the target load includes at least one of CPU load and I / O load. Specifically, a log recording service or a dedicated monitoring module can periodically collect system performance indicators. CPU load can be quantified by calculating parameters such as CPU utilization, average load, or task queue depth per unit time, while I / O load can be obtained by monitoring indicators such as storage device read / write queue length, bandwidth utilization, or latency. The collection frequency of these performance data can be flexibly set according to the actual system needs, for example, sampling once every 100 milliseconds to 1 second, to balance the real-time monitoring with system overhead.

[0048] Based on the monitored target load, the system further dynamically adjusts the preset trigger conditions. The specific adjustment strategy can be designed as a multi-level adaptive mechanism: when the CPU load is high and the I / O load is relatively low, the buffer capacity threshold can be appropriately increased or the timeout period extended to fully utilize the CPU's idle periods for batch aggregation of log data, thereby reducing the preemption of CPU resources by frequent disk write operations and avoiding log accumulation caused by I / O bottlenecks. Conversely, when the I / O load is high and the CPU load is light, the buffer capacity threshold can be reduced or the timeout period shortened, allowing log data to be flushed to the storage medium faster and alleviating the pressure on the memory buffer. Furthermore, a more refined load grading strategy can be introduced, such as dividing the CPU load into four levels: idle, normal, busy, and overload, and the I / O load into four levels: low, medium, high, and saturated. A two-dimensional matrix can be used to map sixteen different load combination states, each state corresponding to a set of optimized trigger condition parameters. In actual operation, the system can quickly match and apply the corresponding parameter configuration by querying the current load status in real time, achieving smooth transition and dynamic optimization of trigger conditions. This adaptive adjustment mechanism not only improves the robustness of the log processing system under different load scenarios, but also ensures resource coordination between critical business loads and log recording services, avoiding adverse effects on the overall system performance due to log writing.

[0049] This enables the log writing strategy to be intelligently adaptive, achieving dynamic and elastic allocation of system resources between core business (navigation, audio and video) and background maintenance tasks (log writing to disk).

[0050] According to one embodiment of this application, the preset triggering conditions include the data volume in the first data buffer reaching a preset capacity threshold and / or reaching a preset write duration. The preset triggering conditions are dynamically adjusted based on the target load, including: increasing the preset capacity threshold and / or increasing the preset write duration when the target load is higher than a first preset load threshold. The first preset load threshold can be determined according to actual conditions. The preset capacity threshold and preset write duration can also be determined according to actual conditions.

[0051] Specifically, the preset trigger conditions include the amount of data in the first data buffer reaching a preset capacity threshold or reaching a preset write duration, or both the amount of data in the first data buffer reaching a preset capacity threshold and reaching a preset write duration. In other words, the preset trigger conditions can be set to trigger a write operation when either the data amount condition or the time condition is met, or they can be set to trigger a write operation only when both conditions are met simultaneously. The specific logical combination can be flexibly configured according to the different requirements of the system for data real-time performance and write efficiency.

[0052] The system assesses the relationship between the target load and a first preset load threshold. When the target load exceeds the first preset load threshold, it indicates that the system is currently operating under medium to high load. In this case, increasing the preset capacity threshold allows more log data to be temporarily stored in the memory buffer, reducing disk write frequency. Alternatively, increasing the preset write duration extends the duration of a single buffer cycle, further aggregating log data and improving batch write efficiency. Furthermore, both the preset capacity threshold and the preset write duration can be increased simultaneously. This strategy of coordinating the increase of these two parameters effectively reduces the time taken up by input / output operations in high-load scenarios, freeing up more computing resources for critical tasks such as navigation calculations and audio / video encoding / decoding.

[0053] It's important to note that the target load can be at least one of CPU load and I / O load. When the target load is CPU load, the first preset load threshold can be determined comprehensively based on the number of CPU cores, clock speed, and current task queue depth. For example, in a multi-core processor architecture, the range where the average utilization of each core exceeds 70% to 85% can be set as a high-load warning range. When the target load is I / O load, the first preset load threshold can be quantified based on disk queue length, I / O operations per second, and bandwidth utilization. For example, when the disk queue length continuously exceeds the threshold or the bandwidth utilization exceeds 80%, the I / O load is determined to be in a high-level operating state. Furthermore, the target load can also encompass a weighted combination of CPU load and I / O load. By constructing a comprehensive load index, a comprehensive perception of the system resource contention situation can be achieved. When any dimension or comprehensive index reaches the first preset load threshold, a dynamic adjustment mechanism based on preset trigger conditions is triggered, ensuring that the log processing strategy is accurately adapted to the real-time operating status of the system.

[0054] For example, suppose the preset capacity threshold is 80% of the buffer size (e.g., triggering when an 8KB buffer is filled to 6.4KB), and the preset write duration is 100 milliseconds. The first preset load threshold can be set to a CPU utilization greater than 70% and an I / O wait queue length greater than 5. When the current CPU utilization reaches 80% and the I / O wait queue length reaches 8, the system is determined to be in a high-load state. At this time, the dynamic adjustment strategy will take effect: the preset capacity threshold will be increased to 90% of the buffer size (i.e., triggering only when 7.2KB is filled), and the preset write duration will be extended from 100 milliseconds to 200 milliseconds. This means that the amount of log data accumulated required to trigger a batch write to disk is greater, or the logs are allowed to remain in memory for a longer period of time.

[0055] Therefore, during periods of high load, the frequency of log write-to-disk operations is proactively reduced, thereby allocating more valuable input / output bandwidth and CPU interrupt processing time to core user tasks such as navigation map loading and audio decoding, effectively alleviating system lag.

[0056] According to one embodiment of this application, the log data processing method further includes: reducing a preset capacity threshold and / or reducing a preset write duration when the target load is lower than a second preset load threshold, wherein the second preset load threshold is less than a first preset load threshold.

[0057] Specifically, the system assesses the relationship between the target load and the second load threshold. If the target load is lower than the second preset load threshold, it indicates that the system is currently operating under low load, with sufficient processing capacity in both the CPU and I / O subsystems. In this case, the system adopts a dynamic adjustment strategy opposite to that used in the high-load scenario, proactively adjusting the preset capacity threshold downwards, for example, from 7.2KB to 4KB or even lower, while simultaneously shortening the preset write duration from 200 milliseconds to 100 milliseconds or less. This adjustment allows log data to trigger disk write operations at a higher frequency and in smaller batches.

[0058] Therefore, the high-frequency, small-batch write strategy under low load conditions offers multiple technical benefits. Firstly, the residence time of log data in the memory buffer is significantly shortened, reducing the risk of data loss due to unexpected system power outages or abnormal process termination, and improving the persistence and reliability of log records. Secondly, more timely disk synchronization operations ensure the accuracy of log timestamps and the integrity of event sequences, providing a high-fidelity data foundation for subsequent fault tracing, performance analysis, and user behavior auditing. Furthermore, due to ample input / output bandwidth and CPU resources during low load periods, frequent small-batch writes will not cause perceptible performance interference to core services such as navigation and audio, allowing the system to achieve an optimal balance between log processing efficiency and data security while ensuring user experience.

[0059] For example, the second preset load threshold can be set when the CPU utilization is below 30% and the I / O wait queue length is less than 2. When the system is under light load, resources are plentiful. In this case, the capacity threshold can be reduced to 50% of the buffer size (e.g., triggering when 4KB is full), or the preset write duration can be shortened to 50 milliseconds. The benefit of doing so is that log data can be persisted to the storage medium more frequently and faster, improving the real-time performance of log writes to disk. This ensures that in the event of a failure, the log data available for analysis has less latency and is closer to the state at the time of the failure. It should be noted that the specific parameter values ​​for dynamic adjustment are not limited to the example values ​​above and can be adjusted and configured within a wide range according to the hardware performance, software architecture, and user experience requirements of different vehicle models.

[0060] Therefore, by dynamically adjusting the preset capacity threshold and preset write duration, intelligent adaptation between system load status and log writing strategy is achieved. Under high load scenarios, a large-capacity, long-cycle batch write mode is adopted to ensure core business performance; under low load scenarios, a small-capacity, short-cycle high-frequency write mode is switched to improve data persistence reliability. This bidirectional adaptive mechanism allows the log processing system to dynamically balance performance optimization and data security based on real-time operating conditions, avoiding the one-size-fits-all problem commonly found in traditional fixed-parameter configuration schemes. It solves the problem of either overly conservative parameters causing system lag under high load or overly aggressive parameters increasing the risk of data loss under low load.

[0061] According to one embodiment of this application, before a preset triggering condition is met, the log data processing method further includes: in the event of detecting an abnormal event, initiating a background write operation to write the log data currently written to the first data buffer to the storage medium.

[0062] Specifically, to address the more specific sub-problem of potential loss of temporarily stored logs in memory during unexpected system events, this application also provides the following preferred solution. Before the preset triggering conditions are met, an exception protection step is added to enhance the reliability of the asynchronous batch write mechanism, ensuring that critical log information is not lost in the event of sudden exceptions.

[0063] Specifically, the logging service or a separate anomaly monitoring module continuously or intermittently detects whether preset abnormal events have occurred. Abnormal events may include, but are not limited to: the system detecting an impending power loss (e.g., a sudden drop in vehicle battery voltage), a serious error in the operating system kernel (e.g., a watchdog reset precursor), a Bluetooth module reporting a fatal failure (e.g., a complete connection loss, protocol stack crash), or the user triggering a specific emergency diagnostic mode. Once such an abnormal event is detected, regardless of whether the first data buffer is full or the preset timer has expired, the system immediately interrupts the normal triggering logic, initiating a background write operation to write the log data currently written to the first data buffer to the storage medium. Specifically, this can be achieved by sending a high-priority forced disk write signal to the batch write control module, which preempts the normal triggering logic. During the forced disk write process, the system can use synchronous writing to ensure that the data is completely written to storage before the system crashes, or accelerate the asynchronous write process as much as possible.

[0064] Therefore, by employing the aforementioned method of forcibly triggering abnormal events, the risk of losing a large amount of valuable on-site logs due to memory power failure during sudden system failures, where the asynchronous batch write mechanism has not yet met its triggering conditions, can be effectively avoided. This provides crucial data support for subsequent root cause analysis, thereby greatly enhancing the reliability of this log processing solution.

[0065] According to one embodiment of this application, when initiating a background write operation, the log data processing method further includes: updating the status identifier of the first data buffer to a write identifier and updating the status identifier of the second data buffer to a read identifier, wherein the status identifier update operation is implemented through atomic operations.

[0066] Specifically, to ensure the correctness and data consistency of the double buffer during role switching and to avoid race conditions in multi-threaded or asynchronous operation environments, this application also provides the following preferred solution: When initiating a background write operation, it also includes a step of updating the buffer state flag through atomic operations, aiming to guarantee the atomicity and thread safety of the buffer role switching operation.

[0067] In other words, each data buffer (first data buffer and second data buffer) is associated with a status flag to indicate whether it is currently serving a "write" role or a "read / disk write" role. For example, a boolean variable or an enumeration type variable can be used as the status flag. When it is necessary to switch buffer roles (i.e., at the moment a background write operation is initiated), the status flags of both buffers must be updated simultaneously: the flag of the original first data buffer is updated from "read flag" to "write flag," and the flag of the original second data buffer is updated from "write flag" to "read flag." That is, after updating the flag of the first data buffer to the write flag, the log data in the first data buffer is available for subsequent memory write operations; after updating the flag of the second data buffer to the read flag, the second data buffer is used to receive new log data.

[0068] These two update operations must be implemented using atomic operations. An atomic operation, in a multi-threaded environment, means that an operation, from start to finish, cannot be interrupted by other threads; it either executes completely or not at all, thus preventing intermediate states from being observed by other threads. Specific implementation methods can include using atomic read / write instructions provided by the processor, or using synchronization primitives such as mutexes and semaphores to wrap the two update operations into a critical section. By adopting the specific limiting characteristics of the atomic operation update state flags described above, it can be ensured that the log writing thread and the background disk persistence thread have an instantaneous and consistent understanding of "which buffer is currently used for writing" and "which buffer is used for reading."

[0069] Therefore, by implementing synchronous updates of status flags through atomic operations, concurrent access conflicts caused by time windows during buffer role switching can be effectively prevented. Furthermore, the log writing thread and the background disk write thread can quickly locate the currently available target buffer based on the status flag without traversing or querying complex metadata structures, thereby improving the efficiency and reliability of buffer management.

[0070] According to one embodiment of this application, initiating a background write operation to write log data from a first data buffer to a storage medium includes: organizing all accumulated log data in the first data buffer into a single input / output request for sending to the storage medium; or, sending all accumulated log data in the first data buffer in batches to the storage medium.

[0071] Specifically, to maximize the effect of input / output merging, this application also provides a preferred scheme for the specific execution method of the background write operation. When initiating a background write operation to write log data from the first data buffer to the storage medium, two highly optimized methods can be included, aiming to ensure optimal input / output merging for each trigger from an operational perspective.

[0072] In the first implementation, all accumulated log data in the first data buffer is organized into a single input / output request and sent to the storage medium. This means that regardless of the number of independent log data packets in the first data buffer, the background write module treats them as a single, continuous, and complete data block. Specifically, when initiating a system call, the passed buffer pointer points to the starting address of the data block, and the passed data length parameter is the total number of bytes in the data block. The operating system kernel's file system and block device driver then send this single request to the storage device. This approach achieves complete merging at the system call level.

[0073] In the second parallel implementation, all accumulated log data in the first data buffer can be sent to the storage medium in batches. That is, the batch method can organize the log data into multiple input / output requests, but these requests are sent continuously within a very short time window to fully utilize the queue depth and parallel processing capabilities of the storage device. Specifically, the background write module can divide all log data in the first data buffer into several evenly sized sub-data blocks according to the characteristics of the storage medium (such as maximum queue depth, optimal request size, etc.), with each sub-data block corresponding to an independent input / output request. These requests can be submitted to the operating system kernel asynchronously and non-blockingly. The kernel's I / O scheduler will merge them into a more efficient sequence of physical operations, which will then be sent to the storage device for execution.

[0074] It should be noted that the two implementation methods described above can be flexibly selected or combined depending on the actual application scenario. For scenarios with extreme latency sensitivity, the first single-request method should be prioritized to eliminate the scheduling overhead between multiple requests; for scenarios with high throughput, the second batch method can be used to fully leverage the multi-queue parallel processing capabilities of modern storage devices. Regardless of the specific implementation used, the core objective is to ensure that all log data accumulated in the first data buffer can be persisted to the storage medium in the most efficient way, thereby minimizing interference with the system's front-end business processing while ensuring data reliability.

[0075] Therefore, whether using a single request method or a batch method, centralized processing of all log data in the first data buffer is achieved, completely avoiding the context switching overhead and scheduling delay caused by frequent system calls in the traditional log-by-log writing mode. Through innovative background write operation strategies, the technical effects are comprehensively improved in multiple dimensions such as log data processing efficiency, system resource optimization, and data reliability, providing effective technical support for building a high-performance, highly available logging system.

[0076] According to one embodiment of this application, the log data is Bluetooth log data of the smart cockpit system, the first data buffer and the second data buffer are circular buffers, and the buffer capacities of the first data buffer and the second data buffer are the same or different.

[0077] Specifically, the log data refers to the protocol log data generated by the Bluetooth host controller interface module in the intelligent cockpit system. This type of data is characterized by continuous generation, small data packets, high frequency, strong sequentiality, and sensitivity to interference with the system's real-time performance. The first and second data buffers specifically adopt a circular buffer data structure. A circular buffer is a fixed-size buffer whose logical structure is connected end-to-end. It can achieve cyclic overwriting of data by maintaining read and write pointers. When the write pointer reaches the end of the buffer, it will loop back to the beginning to continue writing (provided that the read pointer has moved away the old data).

[0078] In a dual-buffered architecture with asynchronous disk write-to-disk, each circular buffer can be the same size, for example, both set to 8KB or 16KB, which simplifies memory management and state switching logic. As an optional extended implementation, the buffer capacities of the first and second data buffers can also be designed differently; for example, the front buffer can be slightly larger to handle short-term traffic spikes, while the back buffer can be aligned with the file system block size to optimize disk write-to-disk efficiency.

[0079] Therefore, the advantage of using a circular buffer lies in its ability to efficiently and cyclically utilize pre-allocated fixed memory space. In scenarios where log data streams are continuously generated, frequent dynamic memory allocation and release operations are avoided, reducing memory fragmentation, which is particularly important for resource-constrained and high-reliability automotive embedded environments. By combining the method of this application with the specific smart cockpit Bluetooth logging scenario and the efficient circular buffer structure, a general logging optimization approach can be highly optimized and implemented in a high-value, high-pain-point specific field. While obtaining the core advantages of double-buffered asynchronous batch writing, it also conforms to the special constraints of the automotive environment, achieving the best balance of overall performance.

[0080] In summary, as a concrete example, consider a specific user driving scenario: a user is driving a long distance in a vehicle equipped with a smart cockpit, simultaneously using the in-car HD navigation system to view real-time traffic conditions and directions for complex overpasses, and connecting their mobile phone via Bluetooth to play high-bitrate music online. At this time, the system is under high load: the navigation application frequently renders 3D maps and calculates routes, consuming significant amounts of GPU and CPU resources; the audio service needs to continuously decode network streaming data; and at the same time, the mobile phone and the vehicle's Bluetooth maintain stable audio stream transmission and control signal interaction, causing the Bluetooth host controller interface module to continuously generate a large amount of protocol interaction logs.

[0081] After Bluetooth logs are generated, they are quickly written into memory as a circular buffer A, serving as the "first data buffer." Due to low load, the trigger conditions set by the adaptive module are quite sensitive (e.g., a 50-millisecond timer). Soon, the timer expires, and the trigger conditions are met. The system immediately initiates a background write operation: packaging all log data in buffer A and submitting it to the file system via an asynchronous write request. Simultaneously, an atomic operation sets the status flag of buffer A to "write flag" and the status flag of the second data buffer (buffer B) to "read flag," switching buffer B (now idle) to become the new "first data buffer," allowing newly generated Bluetooth logs to begin writing to buffer B. A background thread asynchronously writes the data from buffer A to the vehicle's storage.

[0082] When a user enters a congested area and activates the complex intersection zoom-in feature in the navigation, while simultaneously switching music playlists, the system's CPU and I / O load surge. The adaptive module detects that the load exceeds a high threshold and dynamically adjusts the log write-to-disk trigger conditions: the buffer capacity threshold is increased to 90%, and the timer is extended to 200 milliseconds. During this time, Bluetooth logs continue to be generated and written to the current first data buffer. Because the trigger conditions become more lenient, log data accumulates longer and in greater quantities in the memory buffer. During this high-load period, the navigation application needs to frequently read map tile data from storage, and the audio application also needs to read cached files. Because the frequency of log write-to-disk operations is deliberately reduced, the storage medium's I / O queues and bus bandwidth are primarily used to serve these core business read requests, resulting in smooth navigation screen transitions and uninterrupted music playback for the user.

[0083] When a minor electrical fault in the vehicle causes system voltage instability, triggering a watchdog reset, the anomaly monitoring module immediately detects the abnormal event. The system immediately forces a disk write operation, regardless of whether the current foreground buffer is full or the timer has expired, and immediately initiates a background write operation, synchronously and with all efforts, writing all temporarily stored Bluetooth log data in the current first data buffer that has not yet met the normal trigger conditions to the storage medium. A reset and restart then occurs. After-sales technicians can connect diagnostic equipment to retrieve complete log files, including the Bluetooth interaction logs from the last moment before the reset. By analyzing these logs, the abnormal state of the Bluetooth protocol stack during voltage fluctuations can be quickly located, thus assisting in determining the root cause of the fault. This ensures the smooth operation of the intelligent cockpit system and the completeness of log diagnostics in a coordinated manner. Users enjoy a smooth navigation and entertainment experience under high load, while technicians can obtain complete log information for analysis after a fault occurs.

[0084] The following is combined with Figure 2 The method described in this application is used to describe the method.

[0085] As a specific example, the log data processing method of this application may include the following steps: S101 receives log data and writes the log data into the first data buffer in memory.

[0086] S102, determine whether the amount of data in the first data buffer has reached the preset capacity threshold or the preset write duration. If yes, proceed to step S103; if no, proceed to step S101.

[0087] S103, initiate a background write operation to write log data from the first data buffer to the storage medium, and write the new log data to the second data buffer in memory.

[0088] S104. Determine whether the target load is higher than the first preset load threshold. If yes, proceed to step S105; if no, proceed to step S109.

[0089] S105, Increase the preset capacity threshold or increase the preset write duration.

[0090] S106, Continue to initiate the background write operation to write the log data of the corresponding data buffer to the storage medium.

[0091] S107, Determine whether an abnormal event has been detected. If yes, proceed to step S108; if no, proceed to step S106.

[0092] S108, Initiate a background write operation to write the log data that has been written to the corresponding data buffer to the storage medium.

[0093] S109, determine whether the target load is less than the second preset load threshold. If yes, proceed to step S110; if no, proceed to step S101.

[0094] S110, reduce the preset capacity threshold or reduce the preset write duration, and proceed to step S106.

[0095] In summary, the log data processing method according to the embodiments of this application receives log data and writes it into a first data buffer in memory. In response to a preset trigger condition being met, a background write operation is initiated to write the log data in the first data buffer into the storage medium. When the background write operation is initiated, new log data is written into a second data buffer in memory. Therefore, this method can reduce the I / O pressure on the storage medium, avoid I / O anomalies and disk jitter under high load, and ensure the overall performance and stability of the system.

[0096] Corresponding to the above embodiments, this application also proposes a computer-readable storage medium.

[0097] The computer-readable storage medium of this application embodiment stores a program that, when executed by a processor, implements the above-described log data processing method.

[0098] According to the embodiments of this application, by executing the above-described log data processing method, the computer-readable storage medium can reduce the IO pressure of the storage medium, avoid IO anomalies and disk jitter under high load, and ensure the overall performance and stability of the system.

[0099] Corresponding to the above embodiments, this application also proposes a vehicle.

[0100] like Figure 3 As shown, the vehicle 200 in this embodiment may include: a memory 210, a processor 220, and a program stored in the memory 210 and executable on the processor 220. When the processor 220 executes the program, it implements the above-described log data processing method.

[0101] According to the vehicle embodiment of this application, by executing the above-described log data processing method, the IO pressure on the storage medium can be reduced, IO anomalies and disk jitter under high load can be avoided, and the overall performance and stability of the system can be guaranteed.

[0102] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0103] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

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

[0105] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0106] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "joining," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0107] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A log data processing method, characterized in that, The method includes: Receive log data and write the log data into a first data buffer in memory; In response to the fulfillment of a preset trigger condition, a background write operation is initiated to write log data from the first data buffer to the storage medium. When the background write operation is initiated, new log data is written to a second data buffer in memory.

2. The log data processing method according to claim 1, characterized in that, The method further includes: Monitor target load, wherein the target load includes at least one of central processing unit load and input / output load; The preset triggering conditions are dynamically adjusted based on the target load.

3. The log data processing method according to claim 2, characterized in that, The preset triggering conditions include the data volume in the first data buffer reaching a preset capacity threshold and / or reaching a preset write duration. The step of dynamically adjusting the preset triggering conditions based on the target load includes: If the target load is higher than the first preset load threshold, increase the preset capacity threshold and / or increase the preset write duration.

4. The log data processing method according to claim 3, characterized in that, The method further includes: If the target load is lower than the second preset load threshold, the preset capacity threshold and / or the preset write duration are reduced, wherein the second preset load threshold is less than the first preset load threshold.

5. The log data processing method according to claim 1, characterized in that, Before the preset triggering condition is met, the method further includes: In the event of an abnormal event, a background write operation is initiated to write the log data currently written to the first data buffer to the storage medium.

6. The log data processing method according to claim 1, characterized in that, When initiating the background write operation, the method further includes: The status identifier of the first data buffer is updated to a write identifier, and the status identifier of the second data buffer is updated to a read identifier, wherein the status identifier update operation is implemented through atomic operations.

7. The log data processing method according to claim 1, characterized in that, The initiation of the background write operation that writes log data from the first data buffer to the storage medium includes: Organize all accumulated log data in the first data buffer into a single input / output request and send it to the storage medium; or, All log data accumulated in the first data buffer is sent in batches to the storage medium.

8. The log data processing method according to claim 1, characterized in that, The log data is Bluetooth log data from the intelligent cockpit system. The first data buffer and the second data buffer are circular buffers, and the buffer capacities of the first data buffer and the second data buffer may be the same or different.

9. A computer-readable storage medium, characterized in that, It stores a program that, when executed by a processor, implements the log data processing method according to any one of claims 1-8.

10. A vehicle, characterized in that, include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the log data processing method according to any one of claims 1-8.

Images