Vehicle-mounted intelligent cabin log system and vehicle-mounted intelligent cabin log management method

Abstract

The invention discloses a vehicle-mounted intelligent cabin log system and a vehicle-mounted intelligent cabin log management method, and relates to the field of vehicle machine logs, and the vehicle-mounted cabin system comprises an MCU and an SOC; the MCU runs an AutoSAR real-time operating system and is responsible for CAN signal receiving and transmitting, communication diagnosis, sleep awakening and power management of the whole vehicle; the SOC runs dual systems through a Hypervisor virtual machine monitoring program, and the dual systems comprise an instrument system and a central control system; wherein the instrument system end runs a QNX / Linux system to realize quick response, and the central control system end runs an Android system to process intelligent interaction and cockpit entertainment functions; wherein the cabin log system is established based on the vehicle-mounted cabin system of the vehicle infotainment device 1 and the vehicle-mounted cabin system of the vehicle infotainment device 2; the cabin log system is used for log generation and storage of the vehicle-mounted cabin system of the vehicle infotainment device 1 and the vehicle-mounted cabin system of the vehicle infotainment device 2.

Description

Technical Field

[0001] This application relates to the field of vehicle logs, and more particularly to in-vehicle intelligent cockpit log systems, in-vehicle intelligent cockpit log management methods, electronic devices, and storage media. Background Technology

[0002] The automotive intelligent cockpit is evolving from a traditional, single central control system to a domain control system integrating instrument cluster, central control, HUD, co-pilot entertainment, and intelligent driving functions. The increasing complexity of both hardware and software in intelligent cockpit systems makes them more prone to software problems. Furthermore, as the human-machine interface between the user and the vehicle, software issues in the intelligent cockpit system can severely impact user experience, leading to user complaints and customer grievances. Due to the high software complexity, locating and resolving problems during development and after-sales service is extremely difficult. Therefore, this invention focuses on the design method of an in-vehicle intelligent cockpit log system. This invention can comprehensively and automatically collect logs from all functional modules of the intelligent cockpit system, providing effective solutions for troubleshooting during development and after-sales issues. Summary of the Invention

[0003] The purpose of this invention is to provide an in-vehicle intelligent cockpit log system, an in-vehicle intelligent cockpit log management method, an electronic device, and a storage medium, thereby solving at least one of a number of technical problems.

[0004] The high complexity of smart cockpit hardware (MCU / SOC) and software (multi-system / multi-vehicle infotainment systems) makes problem localization and resolution difficult and inefficient during development and after-sales phases. MCU logs before QNX / Linux system startup are easily lost, leading to time gaps in fault tracing. Logs from multiple vehicle infotainment systems (vehicle infotainment system 1 / 2) and multiple systems (QNX / Linux / Android) are stored in a scattered manner, making cross-device collection cumbersome and inefficient. Log files lack a unified standard, with inconsistent names and unlimited sizes, resulting in difficult retrieval and redundant storage. Obtaining logs during development and after-sales requires complex operations, large log files are inconvenient to transfer, and redundant data is present when not all logs are needed. Real-time acquisition of logs from multiple vehicle infotainment systems and multiple systems is impossible during development, making debugging and connection complex and extending the troubleshooting cycle. Log data is disorganized, with invalid information interfering with core fault localization and resulting in low filtering efficiency. The lack of a unified mechanism for transmitting logs from different systems easily leads to log loss and corruption.

[0005] This invention provides the following solution:

[0006] According to a first aspect of the present invention, an in-vehicle intelligent cockpit log system is provided, the in-vehicle intelligent cockpit log system comprising an in-vehicle cockpit system and a cockpit log system:

[0007] The in-vehicle cockpit system includes an MCU and a SOC;

[0008] The MCU runs the AutoSAR real-time operating system and is responsible for the vehicle's CAN signal transmission and reception, communication diagnostics, sleep wake-up and power management.

[0009] The SOC runs a dual system via a Hypervisor virtual machine monitoring program, which includes an instrumentation system and a central control system.

[0010] The instrument system runs QNX / Linux to enable rapid response, while the central control system runs Android to handle intelligent interaction and cockpit entertainment functions.

[0011] Among them, a cockpit log system is established based on the vehicle-mounted cockpit system 1 and the vehicle-mounted cockpit system 2;

[0012] The cockpit log system is used for the generation and storage of logs from the vehicle infotainment system 1 and the vehicle infotainment system 2.

[0013] Furthermore, the cockpit log system includes:

[0014] Log module with ringbuf, DLT serial port adapter module (dlt-uart-adaptor), DLT daemon module (dlt-daemon), standard log processing system (dlt-system), standardized log output component (Slog), core log service component module (Log service), and log output service module (Android logcat service).

[0015] The log module with a circular buffer is located on the MCU side;

[0016] The DLT serial port adapter module, DLT daemon module, standard log processing system, standardized log output component, and instrumentation system located on the SOC side;

[0017] The core log service component module and log output service module are located in the central control system on one side of the SOC.

[0018] According to a second aspect of the present invention, a method for managing vehicle-mounted intelligent cockpit logs is provided, the method comprising:

[0019] Step 1: Log generation and partitioned storage;

[0020] Each system outputs logs through a dedicated channel of the log generation and storage module;

[0021] Among them, the log module with a ring buffer on the MCU side first temporarily stores the MCU log before the QNX / Linux system starts. After the QNX / Linux system starts, the cached log is transmitted to the subsequent DLT serial port adapter module and DLT daemon module through the UART serial port, and finally stored in the designated log partition to achieve full life cycle coverage of the log.

[0022] Among them, the MCU logs before the QNX / Linux system starts up and the logs of the standardized log output component are stored together in the instrument log partition of the instrument system to which the instrument belongs;

[0023] Logs from the log output service module are stored in the log storage partition of the parent control system via the core log service component module.

[0024] Furthermore, it also includes:

[0025] Step 2: Centralized summary of logs;

[0026] Among them, the Android system of vehicle-mounted system 2 is deployed with an NFS server;

[0027] The Android system of vehicle infotainment system 1 is mounted via NFS to access the QNX / Linux system of vehicle infotainment system 1 / vehicle infotainment system 2 and the NFS server deployed on the Android system of vehicle infotainment system 2 and extract the corresponding logs. These logs are then combined with the logs of the Android system of vehicle infotainment system 1 to form a complete device log set.

[0028] Furthermore, it also includes:

[0029] Step 3: Log level filtering;

[0030] Based on the target log's classification, log data corresponding to the classification level is retained.

[0031] Furthermore, it also includes:

[0032] Step 4: Logs are automatically retrieved;

[0033] Place the "AutoLog" identification file on the USB flash drive connected to the USB interface of the vehicle's central control system;

[0034] After the vehicle's central control system detects the USB drive, it filters the corresponding logs from the log set based on the "AutoLog" identifier file and packages them into a ZIP format for output.

[0035] Furthermore, it also includes:

[0036] Step 5: Online debugging log transmission;

[0037] The QNX / Linux system on the MCU side outputs diagnostic logs and trace logs based on the TCP protocol, which are then transmitted to the DLT client via the DLT node and DLT gateway.

[0038] The Android system connects to the PC debugger via adb usb on vehicle infotainment system 1 or adb shell on vehicle infotainment system 2 to enable real-time log viewing.

[0039] Furthermore, it also includes:

[0040] Step 6: Log file naming and size control process:

[0041] This includes determining the number of startups: based on the number of IG ON cycles, the count is cyclically based on a 3-digit decimal number, and reset to 0 after a factory reset or log clearing;

[0042] Serial number determination: After system startup, read the maximum serial number from the historical log, add 1, and then assign it in a cyclical manner as a 4-digit decimal number;

[0043] Determining time information: Prioritize extracting the time of the last line of the log; if reading fails, use the current system time.

[0044] Filename generation and size control: The filename is generated according to the naming format of the corresponding system. When the file size reaches 10MB, the current file writing is automatically terminated and a new file is generated. The serial number is updated and storage continues.

[0045] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0046] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps such as the in-vehicle intelligent cockpit log management method.

[0047] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps such as those of a vehicle-mounted smart cockpit log management method.

[0048] The above solution achieves the following beneficial technical effects:

[0049] This application achieves comprehensive collection of logs from the entire system and all functional modules through a log system that collects logs by module (MCU / QNX / Linux / Android), partitioned storage (instrument log partition / log storage partition), and standardized transmission links (DLT mechanism / Slog / logcat service). The log storage structure is clear, providing complete data support for troubleshooting and significantly improving the efficiency of development and after-sales problem solving.

[0050] This application configures a log module with a ring buffer (ringbuf) on the MCU to temporarily store logs before startup. After startup, the logs are transmitted to the dlt-daemon storage via UART serial port + dlt-uart-adaptor, filling in the log gaps during the startup phase and achieving full-cycle log coverage without omissions. This provides a basis for tracing startup-related faults and improves the completeness of problem localization.

[0051] This application uses the Android system of vehicle infotainment system 1 as a unified interface, and deploys an NFS server on the QNX / Linux system of vehicle infotainment system 1 / 2 and the Android system of vehicle infotainment system 2. It supports cross-device log access and aggregation, realizes centralized management of logs from multiple vehicle infotainment systems and multiple systems, eliminates the need for manual physical copying, reduces the cost of log aggregation operations, and improves log collection efficiency.

[0052] This application adopts standardized log naming rules (including module / category, startup count, serial number, and time) and a fixed log file size of 10MB. The logs can be quickly traced to their source, generation scenario, and device status, facilitating cross-startup cycle fault correlation analysis. It avoids storage redundancy and transmission delays caused by excessively large files, balancing log integrity and storage efficiency.

[0053] This application utilizes an automatic log acquisition module (triggered by the "AutoLog" identifier file on the USB drive) + module-based log filtering + USB dump with ZIP packaging output. Log acquisition requires no professional operation, supports precise filtering of target module logs, and reduces transmission and storage costs after compression, significantly improving the convenience of log acquisition.

[0054] This application achieves real-time log monitoring during the development process through an online debugging solution (DLT over TCP + DLT-node / DLT-gateway on the MCU / QNX side; cross-network connection via adb usb / adb shell on the Android side), adapts to multi-system / multi-vehicle debugging scenarios, simplifies the debugging connection process, and shortens the problem-solving cycle during the development phase.

[0055] This application supports four log level settings (Error / Warning / Info / Debug), allowing users to select and store logs as needed, filter invalid log information, focus on core fault-related logs, improve the accuracy of problem localization, and reduce log analysis time costs.

[0056] This application achieves standardized transmission through the DLT-system (Slog+dlt-daemon) on QNX / Linux systems and the logcat service+Log service on Android systems. The log transmission path is standardized, reducing the risk of log loss and corruption, and ensuring the integrity and reliability of log data. Attached Figure Description

[0057] Figure 1 This is a result diagram of an in-vehicle intelligent cockpit log system provided by one or more embodiments of the present invention.

[0058] Figure 2 This is a flowchart of a vehicle-mounted intelligent cockpit log management method provided by one or more embodiments of the present invention.

[0059] Figure 3 This is a schematic diagram of the framework of an intelligent cockpit system provided in a specific embodiment of the present invention.

[0060] Figure 4 This is a schematic diagram of a log architecture design provided in a specific embodiment of the present invention.

[0061] Figure 5 This is a schematic diagram of log selection provided in a specific embodiment of the present invention.

[0062] Figure 6 This is a schematic diagram of real-time log debugging provided in a specific embodiment of the present invention.

[0063] Figure 7 This is a block diagram of an electronic device for an in-vehicle intelligent cockpit log management method provided in one or more embodiments of the present invention. Detailed Implementation

[0064] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only one module of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0065] Figure 1 This is a result diagram of an in-vehicle intelligent cockpit log system provided by one or more embodiments of the present invention.

[0066] like Figure 1 The in-vehicle intelligent cockpit log system shown includes an in-vehicle cockpit system and a cockpit log system.

[0067] The in-vehicle cockpit system includes an MCU and a SOC;

[0068] The MCU runs the AutoSAR real-time operating system and is responsible for the vehicle's CAN signal transmission and reception, communication diagnostics, sleep wake-up and power management.

[0069] The SOC runs a dual system via a Hypervisor virtual machine monitoring program, which includes an instrumentation system and a central control system.

[0070] The instrument system runs QNX / Linux to enable rapid response, while the central control system runs Android to handle intelligent interaction and cockpit entertainment functions.

[0071] Among them, a cockpit log system is established based on the vehicle-mounted cockpit system 1 and the vehicle-mounted cockpit system 2;

[0072] The cockpit log system is used for the generation and storage of logs from the vehicle infotainment system 1 and the vehicle infotainment system 2.

[0073] Specifically, CP AutoSAR OS is an automotive-specific operating system based on Classic AUTOSAR (the classic platform). It's a real-time in-vehicle operating system developed in accordance with the "classic platform" standard defined by the AUTOSAR (Automotive Open Systems Architecture) organization. Its core purpose is to support control scenarios in automotive electronics that have high requirements for real-time performance and functional safety but relatively low computational power demands. In the smart cockpit, it is the core operating system of the MCU, responsible for basic control functions such as CAN signal transmission and reception, communication diagnostics, sleep / wake-up, and power management. It is also widely used in in-vehicle scenarios with stringent safety and real-time requirements, such as body control, chassis control, and powertrain systems.

[0074] In this embodiment, the cockpit log system includes:

[0075] Log module with ringbuf, DLT serial port adapter module (dlt-uart-adaptor), DLT daemon module (dlt-daemon), standard log processing system (dlt-system), standardized log output component (Slog), core log service component module (Log service), and log output service module (Android logcat service).

[0076] The log module with a circular buffer is located on the MCU side;

[0077] The DLT serial port adapter module, DLT daemon module, standard log processing system, standardized log output component, and instrumentation system located on the SOC side;

[0078] The core log service component module and log output service module are located in the central control system on one side of the SOC.

[0079] Specifically, the Log module with ringbuf refers to a log module with a ring buffer, which is the core log collection component on the smart cockpit MCU (microcontroller).

[0080] The circular buffer is a circular memory space. This module first temporarily stores the MCU logs before the QNX / Linux system starts (to avoid log loss during the startup phase). After the QNX / Linux system starts, the cached logs are transmitted to the subsequent adaptation layer and daemon process via the UART serial port, and finally stored in the specified log partition to achieve full lifecycle log coverage.

[0081] The dlt-uart-adaptor refers to the DLT serial adapter, a log transmission adapter component in the intelligent cockpit that connects the MCU and the QNX / Linux system. Acting as a "communication bridge," it receives logs buffered in the MCU's circular buffer via the UART serial port, converts the logs to the DLT (Diagnostic Log and Trace) standard format, and then transmits them to the dlt-daemon (DLT daemon) of the QNX / Linux system, ultimately enabling the storage of MCU logs in the QNX / Linux system log partition.

[0082] dlt-daemon refers to the DLT daemon (Diagnostic Log and Trace Daemon), a core background process in the QNX / Linux intelligent cockpit system responsible for receiving, forwarding, and storing logs, running continuously without interruption. On one hand, it receives DLT format logs from dlt-uart-adaptor (converted MCU logs) and Slog (QNX / Linux system's own logs); on the other hand, it forwards and stores these logs uniformly to the instrument log partition, making it a key component connecting the log transmission link and the storage terminal.

[0083] The dlt-system refers to a log processing system based on the DLT (Diagnostic Log and Trace) standard. It is the core system responsible for standardized log transmission, reception, and management within the QNX / Linux intelligent cockpit system. It integrates components / transmission methods such as dlt-uart-adaptor (DLT serial adapter), dlt-daemon (DLT daemon process), and DLT overTCP. On one hand, it receives logs output by the QNX / Linux system itself via Slog; on the other hand, it receives MCU logs converted to DLT format by the dlt-uart-adaptor. Then, it stores the logs in the instrument log partition through a unified mechanism, or transmits them to the client via a DLT gateway / node during debugging. It is the core support for achieving standardized log processing for the QNX / Linux system and associated MCUs.

[0084] Slog is a standardized log output component that comes with the QNX / Linux system. Its core function is to collect and output logs generated during the operation of the QNX / Linux system (such as instrumentation-related logs). Its key role is to directly output logs generated during QNX / Linux system operation (such as instrumentation-related logs) to the dlt-daemon (DLT daemon) within the same system. The dlt-daemon then stores these logs uniformly in the instrumentation log partition, making it the core entry point for QNX / Linux system logs to access the dlt-system (DLT log processing system).

[0085] The Log service is the core log service component of the in-vehicle intelligent cockpit log system. Primarily deployed on the Android system side, it serves as the "central hub" connecting logs from various systems and enabling centralized log processing. Its core functions include: 1. Receiving logs output from the Android system via the logcat service and storing them in the log storage partition; 2. Receiving DLT format logs from the MCU and QNX systems via dlt-receive and synchronously storing them in the corresponding log partitions; 3. Real-time detection of USB drive access, triggering the packaging of all logs from Vehicle 1 and Vehicle 2, outputting ZIP format logs only through the USB drive interface of Vehicle 1; 4. Providing NFS server mounting services for the system of Vehicle 2, supporting access to logs from the Android system of Vehicle 1; 5. Carrying the core execution logic for automatic system log acquisition and responding to filtering instructions for identified files.

[0086] The Android logcat service is a built-in log output service of the Android system. Its core function is to collect and output the runtime logs of the Android system and related applications (such as the intelligent interaction and entertainment function logs of the Android system in the smart cockpit). As the "output entry point" of the Android system logs, it directs various logs generated during system operation (including error, warning, debugging information, etc.) to the Log service, which then stores them uniformly in the log storage partition. It is the core bridge for the Android system logs to access the entire cockpit log system.

[0087] NFS, or Network File System, is the core network protocol for cross-device log sharing in smart cockpits and a key technological support for centralized log management. Its core function is as follows: In the smart cockpit log system, the QNX / Linux systems of vehicle infotainment system 1, vehicle infotainment system 2, and Android system deploy an NFS server to share their generated log files to the network. The Android system of vehicle infotainment system 1 acts as the unified log interface, mounting these shared directories via the NFS protocol to directly access and retrieve logs from other systems. Ultimately, this achieves centralized aggregation of logs from all devices in vehicle infotainment systems 1 and 2, enabling cross-device log collection without physical copying.

[0088] The DLT-gateway, or Diagnostic Log and Trace Gateway, is a core component responsible for centralized log forwarding in intelligent cockpit online debugging scenarios. This role is undertaken by the dlt-daemon (DLT daemon process) of the vehicle's QNX / Linux system. As the "log forwarding hub," it receives DLT-formatted logs from the vehicle's own QNX / Linux system and DLT logs transmitted from the vehicle's QNX / Linux system (acting as a DLT-node / DLT node). Then, it sends both types of logs to the DLT client (such as a development PC) via Ethernet, enabling centralized online output of logs from multiple vehicle systems and supporting real-time debugging during the development phase.

[0089] DLT over TCP refers to a diagnostic log and trace transmission method based on the TCP protocol, which is the core log transmission link for online debugging during the development phase of a smart cockpit. In development and debugging scenarios, DLT format logs from the MCU and QNX / Linux systems are transmitted via the TCP network protocol. The dlt-daemon of the QNX / Linux system in vehicle 2 acts as a DLT-node to send logs, while the dlt-daemon of the QNX / Linux system in vehicle 1 acts as a DLT-gateway to receive and aggregate the logs. Finally, the logs are uniformly sent to the DLT client (such as a development PC) via Ethernet, enabling real-time log debugging across multiple systems and vehicle systems.

[0090] The DLT-node, or Diagnostic Log and Trace Node, is a core component responsible for log initiation and transmission in intelligent cockpit online debugging scenarios. This role is undertaken by the dlt-daemon (DLT daemon process) of the vehicle's QNX / Linux system. As a "log sender," it collects DLT-formatted logs from the vehicle's own QNX / Linux system and associated MCUs, transmits the logs over the network to the DLT-gateway (DLT gateway) of the vehicle's QNX / Linux system, and finally aggregates and sends them to the DLT client (such as a development PC), supporting centralized real-time debugging of logs from multiple vehicle systems.

[0091] "USB dump with ZIP" refers to the USB packaging and export function of the smart cockpit logs, which is the core output method of the automatic log acquisition module. When the system detects the "AutoLog" identified file in the USB drive, the Log service triggers the log packaging logic to compress the logs (full module or specified module) filtered by Vehicle 1 and Vehicle 2 into ZIP format, and then export them to the USB drive through the USB interface of Vehicle 1. This allows development or after-sales personnel to quickly obtain the complete log package, reducing file transfer and storage costs.

[0092] adb via USB (Android Debug Bridge) refers to an Android debugging bridge connection method implemented through a USB interface. It is a core link for online debugging of the Android system in a smart cockpit. The Android system of vehicle infotainment system 1 is directly connected to a PC debugger via a physical USB interface, transmitting system operation logs (such as logs related to intelligent interaction and cockpit entertainment functions) to the PC in real time for developers to view and debug. This is a key method for quickly troubleshooting Android system logs.

[0093] In this embodiment, the in-vehicle intelligent cockpit log management method includes:

[0094] Step 1: Log generation and partitioned storage;

[0095] Each system outputs logs through a dedicated channel of the log generation and storage module;

[0096] Among them, the log module with a ring buffer on the MCU side first temporarily stores the MCU log before the QNX / Linux system starts. After the QNX / Linux system starts, the cached log is transmitted to the subsequent DLT serial port adapter module and DLT daemon module through the UART serial port, and finally stored in the designated log partition to achieve full life cycle coverage of the log.

[0097] Among them, the MCU logs before the QNX / Linux system starts up and the logs of the standardized log output component are stored together in the instrument log partition of the instrument system to which the instrument belongs;

[0098] Logs from the log output service module are stored in the log storage partition of the parent control system via the core log service component module.

[0099] In this embodiment, it also includes:

[0100] Step 2: Centralized summary of logs;

[0101] Among them, the Android system of vehicle-mounted system 2 is deployed with an NFS server;

[0102] The Android system of vehicle infotainment system 1 is mounted via NFS to access the QNX / Linux system of vehicle infotainment system 1 / vehicle infotainment system 2 and the NFS server deployed on the Android system of vehicle infotainment system 2 and extract the corresponding logs. These logs are then combined with the logs of the Android system of vehicle infotainment system 1 to form a complete device log set.

[0103] In this embodiment, it also includes:

[0104] Step 3: Log level filtering;

[0105] Based on the target log's classification, log data corresponding to the classification level is retained.

[0106] In this embodiment, it also includes:

[0107] Step 4: Logs are automatically retrieved;

[0108] Place the "AutoLog" identification file on the USB flash drive connected to the USB interface of the vehicle's central control system;

[0109] After the vehicle's central control system detects the USB drive, it filters the corresponding logs from the log set based on the "AutoLog" identifier file and packages them into a ZIP format for output.

[0110] In this embodiment, it also includes:

[0111] Step 5: Online debugging log transmission;

[0112] The QNX / Linux system on the MCU side outputs diagnostic logs and trace logs based on the TCP protocol, which are then transmitted to the DLT client via the DLT node and DLT gateway.

[0113] The Android system connects to the PC debugger via adb usb on vehicle infotainment system 1 or adb shell on vehicle infotainment system 2 to enable real-time log viewing.

[0114] In this embodiment, it also includes:

[0115] Step 6: Log file naming and size control process:

[0116] This includes determining the number of startups: based on the number of IG ON cycles, the count is cyclically based on a 3-digit decimal number, and reset to 0 after a factory reset or log clearing;

[0117] Serial number determination: After system startup, read the maximum serial number from the historical log, add 1, and then assign it in a cyclical manner as a 4-digit decimal number;

[0118] Determining time information: Prioritize extracting the time of the last line of the log; if reading fails, use the current system time.

[0119] Filename generation and size control: The filename is generated according to the naming format of the corresponding system. When the file size reaches 10MB, the current file writing is automatically terminated and a new file is generated. The serial number is updated and storage continues.

[0120] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0121] In one specific embodiment, the following is disclosed: Figure 1 The intelligent cockpit system framework shown includes:

[0122] Mainstream smart cockpits are mainly divided into two parts in terms of hardware controller: MCU and SOC. On the software side, the MCU runs a real-time operating system and is responsible for vehicle-level CAN signal transmission and reception, communication diagnostics, sleep and wake-up, power management, etc. The mainstream cockpit product SOC generally runs a dual system based on a Hypervisor virtual machine monitoring program. One version of the instrument panel runs a QNX or Linux system to achieve fast response of instrument functions, and the other version of the virtual machine system runs an Android system to handle intelligent interaction and realize cockpit entertainment functions.

[0123] In another specific embodiment, based on Figure 1 , obtain Figure 2 The log architecture shown is used for log management.

[0124] 1. Log generation and storage methods:

[0125] 1) MCU Log Collection and Storage: The MCUs of Vehicle 1 and Vehicle 2 each implement their own log collection. The MCU system needs to implement a log with a circular buffer. The logs before the QNX system starts are saved to the buffer. After the QNX system starts, the logs in the MCU buffer are output to the QNX dlt-uart-adaptor through the UART serial port. Finally, the dlt-daemon daemon process receives the logs and stores them in the log partition.

[0126] 2) Collection and storage of QNX / Linux systems in vehicle infotainment systems 1 and 2: DLT (Diagnostic Log and Trace) is a standardized logging and tracing mechanism that is widely supported in QNX / Linux systems. The QNX / Linux systems of vehicle infotainment systems 1 and 2 need to use Slog to output to the dlt-daemon daemon process, which then receives and stores the logs in the log partition.

[0127] 3) Collection and storage of Android system logs for vehicle infotainment systems 1 and 2: The Android system logs of vehicle infotainment systems 1 and 2 are output through the Android logcat service, collected by the log service and stored in the log storage partition.

[0128] 4) Log collection: The Android system of vehicle infotainment system 1 serves as the unified interface for the log system. Logs from the QNX system of vehicle infotainment system 1, the QNX system of vehicle infotainment system 2, and the Android system of vehicle infotainment system 2 are all collected by the Android system of vehicle infotainment system 1. The QNX system of vehicle infotainment system 1, the QNX system of vehicle infotainment system 2, and the Android system of vehicle infotainment system 2 need to implement an NFS server for vehicle infotainment system 1 to access and obtain logs.

[0129] 5) Core function of log service:

[0130] Receive the output logs from Android Logcat and save them to the log partition;

[0131] Receive DLT logs from the MCU and QNX via dlt-receive and save them to the log partition;

[0132] Detect the USB drive, package all logs from vehicle infotainment system 1 and vehicle infotainment system 2, and output them (output only through the USB drive interface of vehicle infotainment system 1).

[0133] Implement NFS server mounting and provide access to vehicle infotainment system 1 (vehicle infotainment system 2 only).

[0134] Implement automatic system log acquisition function

[0135] 6) Supports log level settings: Error, Warning, Info, Debug. Select the log level according to your needs.

[0136] 2. Log naming rules

[0137] 1) QNX / Linux system log file naming format:

module name_serial number_year / month / day_hour / minute / second.dlt

[0138] 2) Android system log file name format:

Category_Startup Count_Serial Number_Year / Month / Day_Hour / Minute / Second.log

[0139] 3) Number of boot attempts: This indicates the number of times the system has booted (after factory reset or log clearing). The number is determined by the number of IG ON attempts, and the sequence number consists of three decimal digits, ranging from 0 to 999. The system starts from 0 after booting, and if the sequence number exceeds 999, it cycles back to 0.

[0140] 4) Serial Number: The serial number consists of four decimal digits, ranging from 0 to 999. After system startup, it starts from 0, reads the serial number from the log file in the log partition, obtains the maximum value, and adds 1 to it. This is the log serial number to be set. When the serial number exceeds 999, it starts cycling from 0 again.

[0141] 5) Read the time of the last line in the log file as the year, month, day, hour, minute, and second information of the log file name. If reading fails or the correct time is not recorded in the log, use the current system time.

[0142] 6) Each log file is 10MB in size;

[0143] 3. Automatic acquisition of system logs:

[0144] During development and after-sales service, in order to facilitate the automatic acquisition of system logs, it is necessary to design an automatic log acquisition method to improve work efficiency. The automatic log acquisition method is as follows:

[0145] 1) Place a specified file on the USB drive, using the file name and content as identifiers. For example, if the file name is AutoLog, the system will detect the fixed file name and assume that system logs need to be retrieved.

[0146] 2) Because the log files are large, to facilitate file retrieval, you can specify which part of the logs to retrieve within the automatic file retrieval function. For example, the retrieved logs can be distinguished by module (MCU, QNX, Android). If AutoLog is selected, all logs will be retrieved by default. Figure 5 As shown.

[0147] 4. Online log debugging, such as Figure 6 As shown.

[0148] 1) During development, online debugging needs to be supported. The MCU and QNX sides output through dlt over TCP; the dlt-daemon of the QNX system on vehicle 2 side acts as a dlt node, and the dlt-daemon of the QNX system on vehicle 1 side acts as a dlt gateway, sending the dlt logs of this system and vehicle 2 to the dlt client connected via Ethernet.

[0149] 2) The Android system of vehicle infotainment system 1 is connected to the PC debugger via adb USB; the Android system of vehicle infotainment system 2 is connected to the PC debugger via adb shell of vehicle infotainment system 1 across Ethernet and via USB of vehicle infotainment system 1.

[0150] Figure 7 This is a block diagram of an electronic device for an in-vehicle intelligent cockpit log management method provided in one or more embodiments of the present invention.

[0151] like Figure 7 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0152] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of an in-vehicle intelligent cockpit log management method.

[0153] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the in-vehicle smart cockpit log management method.

[0154] This application also provides a vehicle platform, including:

[0155] Electronic devices used to implement the steps of a method for managing logs in an in-vehicle intelligent cockpit;

[0156] The processor runs a program, and when the program runs, it executes the steps of the in-vehicle intelligent cockpit log management method based on data output from electronic devices.

[0157] Storage medium for storing programs that, when running, execute steps of the in-vehicle intelligent cockpit log management method based on data output from electronic devices.

[0158] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0159] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0160] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0161] Electronic devices can also obtain reset commands corresponding to storage media. These reset commands are provided by the supplier, and the reset commands for different storage media can be the same or different, which is not limited here.

[0162] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0163] For ease of description, the above devices are described separately according to their functions, divided into various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0164] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0165] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0166] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, or the module that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or certain modules of the embodiments of this application.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to the modules or all technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A vehicle-mounted intelligent cockpit log system, characterized in that, The in-vehicle intelligent cockpit log system includes an in-vehicle cockpit system and a cockpit log system: The in-vehicle cockpit system includes an MCU and a SOC; The MCU runs the AutoSAR real-time operating system and is responsible for the vehicle's CAN signal transmission and reception, communication diagnostics, sleep wake-up and power management. The SOC runs a dual system via a Hypervisor virtual machine monitoring program. The dual system includes an instrumentation system and a central control system. The instrument system runs QNX / Linux to enable rapid response, while the central control system runs Android to handle intelligent interaction and cockpit entertainment functions. The cockpit log system is established based on the in-vehicle cockpit system described in vehicle 1 and vehicle 2. The cockpit log system is used for generating and storing logs of the in-vehicle cockpit system described in vehicle infotainment system 1 and vehicle infotainment system described in vehicle infotainment system 2.

2. The in-vehicle intelligent cockpit log system according to claim 1, characterized in that, The cockpit log system includes: Log module with circular buffer, DLT serial port adapter module, DLT daemon module, standard log processing system, standardized log output component, core log service component module, and log output service module; The log module with a circular buffer is located on the MCU side; The DLT serial port adapter module, DLT daemon module, standard log processing system, standardized log output component, and instrumentation system located on the SOC side; The core log service component module and log output service module are located in the central control system on one side of the SOC.

3. A method for managing in-vehicle intelligent cockpit logs, characterized in that, The in-vehicle intelligent cockpit log management method includes: Step 1: Log generation and partitioned storage; Each system outputs logs through a dedicated channel of the log generation and storage module; Among them, the log module with a ring buffer on the MCU side first temporarily stores the MCU log before the QNX / Linux system starts. After the QNX / Linux system starts, the cached log is transmitted to the subsequent DLT serial port adapter module and DLT daemon module through the UART serial port, and finally stored in the designated log partition to achieve full life cycle coverage of the log. Among them, the MCU logs before the QNX / Linux system starts up and the logs of the standardized log output component are stored together in the instrument log partition of the instrument system to which the instrument belongs; Logs from the log output service module are stored in the log storage partition of the parent control system via the core log service component module.

4. The in-vehicle intelligent cockpit log management method according to claim 3, characterized in that, Also includes: Step 2: Centralized summary of logs; Among them, the Android system of vehicle-mounted system 2 is deployed with an NFS server; The Android system of vehicle infotainment system 1 is mounted via NFS to access the QNX / Linux system of vehicle infotainment system 1 / vehicle infotainment system 2 and the NFS server deployed on the Android system of vehicle infotainment system 2 and extract the corresponding logs. These logs are then combined with the logs of the Android system of vehicle infotainment system 1 to form a complete device log set.

5. The in-vehicle intelligent cockpit log management method according to claim 4, characterized in that, Also includes: Step 3: Log level filtering; Based on the target log's classification, log data corresponding to the classification level is retained.

6. The in-vehicle intelligent cockpit log management method according to claim 5, characterized in that, Also includes: Step 4: Logs are automatically retrieved; Place the AutoLog identification file on the USB flash drive connected to the USB interface of the vehicle's central control system; After the vehicle's central control system detects the USB drive, it filters the corresponding logs from the log set based on the AutoLog identifier file and packages them into a ZIP format for output.

7. The in-vehicle intelligent cockpit log management method according to claim 6, characterized in that, Also includes: Step 5: Online debugging log transmission; The QNX / Linux system on the MCU side outputs diagnostic logs and trace logs based on the TCP protocol, which are then transmitted to the DLT client via the DLT node and DLT gateway. The Android system connects to the PC debugger via adb usb on vehicle infotainment system 1 or adb shell on vehicle infotainment system 2 to enable real-time log viewing.

8. The in-vehicle intelligent cockpit log management method according to claim 7, characterized in that, Also includes: Step 6: Log file naming and size control process: This includes determining the number of startups: based on the number of IG ON cycles, the count is cyclically based on a 3-digit decimal number, and reset to 0 after a factory reset or log clearing; Serial number determination: After system startup, read the maximum serial number from the historical log, add 1, and then assign it in a cyclical manner as a 4-digit decimal number; Determining time information: Prioritize extracting the time of the last line of the log; if reading fails, use the current system time. Filename generation and size control: Generate filenames according to the naming format of the corresponding system. When the file size reaches the preset size threshold, automatically terminate the current file writing and generate a new file, update the serial number and continue storage.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the in-vehicle intelligent cockpit log management method as described in any one of claims 3 to 8.

10. A computer-readable storage medium, characterized in that, The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the in-vehicle smart cockpit log management method as described in any one of claims 3 to 8.

Images