Intelligent cockpit cross-level log management system, method and vehicle

Abstract

The application relates to the technical field of data communication of intelligent cockpits, in particular to an intelligent cockpit cross-level log management system and method and a vehicle, which comprises a hardware driver layer, an operating system layer, an intermediate layer, an application layer and middleware, the middleware provides a first interface, a second interface, a first script, a second script and a target communication mechanism, wherein the middleware acquires first log data of the hardware driver layer by using the first interface and the first script; the middleware acquires second log information of the operating system layer by using the second script; the middleware acquires third log data of the intermediate layer by using a log viewing instruction of a Linux system; the middleware acquires fourth log data of the application layer by using the second interface; and the first, second, third and fourth log data are transmitted through the target communication mechanism provided by the middleware. Therefore, the problems of difficult unified management, single storage architecture and insufficient customized collection and adaptation in the related technology of the log management system are solved.

Description

Technical Field

[0001] This application relates to the field of data communication technology, and in particular to a smart cockpit cross-level log management system, method, and vehicle. Background Technology

[0002] In the development of related middleware code, the log data generated at various layers (hardware driver layer, kernel layer, operating system layer, middleware layer, application layer, etc.) is massive and complex, with different collection strategies, making unified management difficult. Similarly, in terms of storage, related technologies struggle to meet the storage needs of diverse log data types. Therefore, traditional log management systems suffer from problems such as difficulty in unified management, a single storage architecture, and insufficient adaptation to customized collection methods. Summary of the Invention

[0003] This application provides a smart cockpit cross-level log management system, method, and vehicle to solve problems such as difficulty in unified management, single storage architecture, and insufficient adaptation for customized collection in related log management system technologies.

[0004] A first aspect of this application provides a cross-layer log management system for an intelligent cockpit, comprising: a hardware driver layer, an operating system layer, a middleware layer, an application layer, and middleware. The middleware provides a first interface, a second interface, a first script, a second script, and a target communication mechanism. The middleware uses the first interface and the first script to obtain first log data from the hardware driver layer and transmits the first log data through the target communication mechanism provided by the middleware. The middleware uses the second script to obtain second log information from the operating system layer and transmits the second log data through the target communication mechanism provided by the middleware. The middleware uses Linux system log viewing commands to obtain third log data from the middleware layer and transmits the third log data through the target communication mechanism provided by the middleware. The middleware uses the second interface to obtain fourth log data from the application layer and transmits the fourth log data through the target communication mechanism provided by the middleware.

[0005] According to one embodiment of this application, the first log data includes at least one of the first operating data and the first error data of the hardware device; the second log data includes at least one of the operating system's resource usage data, process scheduling data, and the second error data; the third log data includes at least one of the kernel data, manager data, and software data; and the fourth log data includes at least one of the startup data, shutdown data, user operation data, and the second operating data of the functional modules.

[0006] According to one embodiment of this application, the target communication mechanism is a Binder communication mechanism or a JNI communication mechanism.

[0007] According to one embodiment of this application, when the middleware transmits log data through the target communication mechanism, it compresses and converts the log data before transmitting it to the log module.

[0008] According to one embodiment of this application, the log module stores log data in at least one local storage device and a cloud storage device based on the importance level of the log data. If the importance level is greater than a preset level, the log data is synchronized to the local storage device and the cloud storage device.

[0009] According to one embodiment of this application, the local storage device stores log data in directories based on the time, hierarchy, and type.

[0010] According to one embodiment of this application, a local storage device and a cloud storage device establish an index based on target information of the log data, and query and retrieve the log data based on the index. The target information includes at least one of timestamp, log level, and module name.

[0011] According to one embodiment of this application, both the local storage device and the cloud storage device include a visual interface. The visual interface provides a query condition input area, which generates a query instruction based on the user's query operation, and uses the query instruction to query log data.

[0012] A second aspect of this application provides a vehicle including the aforementioned intelligent cockpit cross-level log management system.

[0013] A third aspect of this application provides a method for cross-layer log management in an intelligent cockpit, comprising the following steps: obtaining first log data of the hardware driver layer through a first interface and a first script of the middleware, and transmitting the first log data through a target communication mechanism provided by the middleware; obtaining second log information of the operating system layer through a second script of the middleware, and transmitting the second log data through a target communication mechanism provided by the middleware; obtaining third log data of the middle layer through the log viewing instructions of the Linux system of the middleware, and transmitting the third log data through a target communication mechanism provided by the middleware; obtaining fourth log data of the application layer through a second interface of the middleware, and transmitting the fourth log data through a target communication mechanism provided by the middleware.

[0014] Therefore, this application has the following beneficial effects: This application embodiment utilizes standardized interfaces, scripting tools, and target communication mechanisms provided by middleware to achieve unified collection, transmission, and management of log data across all levels of the cockpit. It covers the entire log collection and transmission chain, including the hardware driver layer, operating system layer, middleware layer, and application layer. Differentiated collection methods are employed to address the log output characteristics of different levels; for example, the hardware driver layer uses a first interface and a first script, while the operating system utilizes a second script, achieving cross-layer, customized collection. All levels transmit data through a unified target communication mechanism provided by the middleware. Real-time compression and conversion of logs from different external modules and devices are performed during transmission, improving transmission standardization. A distributed architecture is used for unified management, with directory-based storage, memory allocation, and a log indexing system. This allows users to quickly locate the root cause of faults, improving the operational efficiency of the intelligent cockpit. Therefore, this solves the problems of difficult unified management, single storage architecture, and insufficient adaptation for customized collection in related log management system technologies.

[0015] 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

[0016] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is an architecture diagram of a cross-level log management scheme for an intelligent cockpit according to an embodiment of this application; Figure 2 This is an example diagram of an intelligent cockpit cross-level log management device according to an embodiment of this application; Figure 3 This is a diagram illustrating the interaction between the log module and external modules and devices according to embodiments of this application. Figure 4 This is a flowchart of a cross-level log management method for an intelligent cockpit according to an embodiment of this application; Figure 5 This is a structural schematic diagram of a vehicle according to an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application are described in detail below. Examples of the 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.

[0018] like Figure 1As shown, the intelligent cockpit log management system has a layered architecture that enables log collection, processing, and management from the hardware to the application layer. The architecture consists of five layers from bottom to top: the bottom layer, hardware, is the hardware driver layer, containing physical devices such as cameras and Bluetooth. The next layer, Hal (Hardware Abstraction Layer), is the hardware abstraction layer, which encapsulates hardware details through components such as BTHAL (Bluetooth Hardware Abstraction Layer), CameraHAL (Camera Hardware Abstraction Layer), AudioHAL (Audio Hardware Abstraction Layer), and IPCHAL (Inter-Process Communication Hardware Abstraction Layer), while also collecting hardware logs; the next layer, Kernel, is the kernel layer, generating operating system kernel-level logs.

[0019] The core framework layer is divided into a Native layer and a Java sublayer. The Native layer collects underlying logs through shell scripts such as `trace_system.sh` (system log collection script) and `trace_kernel.sh` (kernel log collection script), and uses `SomeIPManager` (SOME / IP protocol management component) to achieve log transmission across ECUs (Electronic Control Units) and / or OSs (Operating Systems). It manages local / cloud-based tiered storage through `StorageManager`. The Java layer uses the `LogService` core service, `FileUtil` (file operation utility class), and `Ziputil` (compression utility class) to perform preprocessing such as log compression and format conversion, as well as directory-based storage. The top layer is the application layer. `LogAPP` (log management application) provides a visual query interface, while `OtherAPP` uploads its own application logs.

[0020] The following description, with reference to the accompanying drawings, describes an intelligent cockpit cross-layer log management system, method, and vehicle according to embodiments of this application. Addressing the problems of inconsistent management, limited storage architecture, and insufficient customized collection adaptation in log management systems mentioned in the background, this application provides an intelligent cockpit cross-layer log management system, comprising: a hardware driver layer, an operating system layer, a middleware layer, an application layer, and middleware. The middleware provides a first interface, a second interface, a first script, a second script, and a target communication mechanism. The middleware uses the first interface and the first script to obtain first log data from the hardware driver layer and transmits the first log data through the target communication mechanism provided by the middleware. The middleware uses the second script to obtain second log information from the operating system layer and transmits the second log data through the target communication mechanism provided by the middleware. The middleware uses Linux system log viewing commands to obtain third log data from the middleware layer and transmits the third log data through the target communication mechanism provided by the middleware. The middleware uses the second interface to obtain fourth log data from the application layer and transmits the fourth log data through the target communication mechanism provided by the middleware. This solves the problems of inconsistent management, limited storage architecture, and insufficient customized collection adaptation in log management systems.

[0021] Specifically, Figure 2 This is a framework diagram of a smart cockpit cross-level log management system provided in an embodiment of this application.

[0022] like Figure 2 As shown, the intelligent cockpit cross-layer log management system 10 includes: a hardware driver layer 110, an operating system layer 120, a middleware layer 130, an application layer 140, and middleware 150.

[0023] Middleware 150 provides a first interface, a second interface, a first script, a second script, and a target communication mechanism. Middleware 150 uses the first interface and the first script to obtain first log data from the hardware driver layer 110 and transmits the first log data through the target communication mechanism provided by middleware 150. Middleware 150 uses the second script to obtain second log information from the operating system layer 120 and transmits the second log data through the target communication mechanism provided by middleware 150. Middleware 150 uses Linux system log viewing commands to obtain third log data from the middleware layer 130 and transmits the third log data through the target communication mechanism provided by middleware 150. Middleware 150 uses the second interface to obtain fourth log data from the application layer 140 and transmits the fourth log data through the target communication mechanism provided by middleware 150.

[0024] Understandably, due to the permission characteristics of Android middleware and the independence of logs at each level, this embodiment of the application is designed to uniformly collect log information across the hardware driver layer 110, operating system layer 120, middleware layer 130, application layer 140, and middleware 150 of the smart cockpit Android system for unified management. Middleware 150 is configured with a first interface, a second interface, a first script, a second script, and a target communication mechanism. Middleware 150 serves as a unified log collection and unified log data transmission channel. By employing differentiated data collection methods, the system adapts to the hardware driver layer 110 through a first interface and a first script, to the operating system layer 120 through a second script, to the middleware layer 130 through Linux log viewing commands, and to the application layer 140 through a second interface. This achieves full coverage collection of log data across all levels of the intelligent cockpit, efficiently handling customized collection of various types of log data. Simultaneously, the middleware 150 incorporates a target communication mechanism to transmit the collected log data from the hardware driver layer 110, operating system layer 120, middleware layer 130, and application layer 140 using its unique communication mechanism, enabling real-time transmission and processing of logs from different external modules and devices.

[0025] According to one embodiment of this application, the first log data includes at least one of the first operating data and the first error data of the hardware device; the second log data includes at least one of the operating system's resource usage data, process scheduling data, and the second error data; the third log data includes at least one of the kernel data, manager data, and software data; and the fourth log data includes at least one of the startup data, shutdown data, user operation data, and the second operating data of the functional modules.

[0026] It is understood that the first log data refers to the data collected from the hardware driver layer 110, including at least one of the first operating data and the first error data of the hardware device. The first operating data includes the operating status, etc., and the first error data includes sensor data anomalies or hardware communication failures, etc. The second log data refers to the data collected from the operating system layer 120, including at least one of the operating system resource usage data, process scheduling data, and the second error data, including system error logs, etc. The third log data refers to the data collected from the middleware layer 130, including at least one of the kernel data, manager data, and software data, as well as the operating status and error information of each module of the middleware 150, etc. The fourth log data refers to the data collected from the application layer 140, including at least one of the application startup data, shutdown data, user operation records, and functional module operating status.

[0027] For example, middleware 150 collects first log data of this layer through a first interface and a first script. The first log data includes at least one of the first operating data of the hardware device and first error data. After collection, it is transmitted using a target communication mechanism. Middleware 150 collects second log data of this layer through a second script. The second log data includes at least one of the operating system's resource usage data, process scheduling data, and second error data. After collection, it is transmitted using a target communication mechanism. Middleware 150 calls the Linux system's log viewing command to collect third log data of the middleware layer 130. The third log data includes at least one of the kernel data, manager data, and software data. After collection, it is transmitted using a target communication mechanism. Middleware 150 collects fourth log data of this layer through a second interface. The fourth log data includes at least one of the startup data, shutdown data, user operation data, and second operating data of the functional module. After collection, it is transmitted using a target communication mechanism.

[0028] According to one embodiment of this application, the target communication mechanism is a Binder communication mechanism or a JNI communication mechanism.

[0029] Understandably, the intelligent cockpit cross-level log management system utilizes the middleware 150's special communication mechanism to transmit logs, achieving cross-level transmission. The target communication mechanism transmits log data collected from various levels through the middleware 150. This target communication mechanism can be either the Binder communication mechanism or the JNI communication mechanism provided by the middleware 150. The target communication mechanism solves the communication problem between different levels, unifying the log transmission standard. Binder is a cross-process communication mechanism unique to the Android system, offering high transmission efficiency, built-in verification, and security. JNI (Java Native Interface) is a cross-language interaction interface provided by the Java language, enabling cross-level log communication within the same process and improving call performance.

[0030] For example, smart cockpits involve sensitive data such as vehicle control and user privacy, requiring secure management of the corresponding logs. Binder's built-in identity verification mechanism can restrict only authorized middleware processes to access logs at each level, preventing logs from being stolen by malicious processes; JNI reduces the risk of log leakage during cross-process transmission through in-process local calls.

[0031] According to one embodiment of this application, when the middleware 150 transmits log data through the target communication mechanism, it compresses and converts the log data before transmitting it to the log module.

[0032] Understandably, the middleware 150 collects raw log data from a four-layer architecture, including the hardware driver layer 110 and the operating system 120, through the first interface, the second interface, the first script, the second script, and Linux instructions. The raw data has problems such as heterogeneous format and data redundancy. In order to reduce the amount of data transmission and improve the transmission efficiency, the middleware 150 performs preliminary compression and format conversion on the log data during transmission, realizing real-time synchronization of compressed transmission. After being transmitted to the log module, the log data is classified and stored according to its type and level for easy subsequent querying and analysis.

[0033] For example, middleware 150 collects raw logs by calling the log data of hardware driver layer 110 through the first interface and the first script; it then compresses and converts the raw log data; and finally, middleware 150 uses a target communication mechanism to transmit the compressed log data to the log module. The logs are then categorized and stored according to their type and level.

[0034] According to one embodiment of this application, the log module stores log data in at least one local storage device and a cloud storage device based on the importance level of the log data. If the importance level is greater than a preset level, the log data is synchronized to the local storage device and the cloud storage device.

[0035] Understandably, the log storage and management adopts a distributed storage architecture, combining local storage and cloud storage. Local storage uses high-speed solid-state drives, which are suitable for storing logs that require fast querying, with fast read and write speeds and low latency. Cloud storage uses object storage services, which interact with the cloud storage application programming interface through the service management core component of the middleware 150 to ensure data security and reliability. Cloud storage devices are suitable for storing high-value logs, with large storage capacity and support for long-term storage.

[0036] Log data is categorized into priority levels with preset thresholds. These levels include DEBUG, INFO, WARN, and ERROR. The preset thresholds distinguish between high-priority and low-priority logs. The log module stores log data hierarchically based on its importance level. If the importance level of log data exceeds the preset level, it is considered high-priority data and requires simultaneous storage on both local and cloud storage devices. Synchronizing important log data for cloud backup ensures data retrieval even if local storage is damaged, enhancing data security. Dual-end storage for high-priority log data satisfies both rapid local troubleshooting needs and long-term cloud storage. Low-priority log data is stored locally only for short periods, reducing cloud storage costs and balancing efficiency and cost in log storage and management.

[0037] For example, the logging module categorizes log data into importance levels, such as based on the scope of impact and the severity of the fault. The system first pre-sets an importance level threshold as the boundary between local and cloud storage. After receiving and decompressing the pre-processed log data, the logging module reads the importance field from the log and compares it with the preset importance threshold. If the log level is greater than the preset threshold, it indicates that the log is high-priority data and needs to be stored simultaneously on both local and cloud storage devices; if the log level is not greater than the preset threshold, it indicates that the log is of low importance and is only stored on local storage.

[0038] According to one embodiment of this application, the local storage device stores log data in directories based on the time, hierarchy, and type.

[0039] Understandably, local storage devices store logs in directories based on their time, level, and type, and process them through the StorageManager module. At the same time, memory is allocated as needed according to different levels, making the log storage structure clear and orderly, and improving the efficiency of subsequent log retrieval and fault location.

[0040] For example, logs are stored in directories based on their time, level, and type. First, the directory is named with a specific year, month, and day to provide a clear date for troubleshooting. Second, they are stored hierarchically, such as cameras belonging to hardware driver layer 110, making it easy to locate the hierarchical directory. Finally, they are stored by type, such as a subdirectory for "camera". The subsequent order for retrieving log files is: quickly locate the date, find the corresponding level, and finally determine the type.

[0041] According to one embodiment of this application, a local storage device and a cloud storage device establish an index based on target information of the log data, and query and retrieve the log data based on the index. The target information includes at least one of timestamp, log level, and module name.

[0042] Understandably, the intelligent cockpit cross-layer log management system constructs a log indexing system to facilitate the management of massive log data. This system indexes key log information such as time, log level, and module name, accelerating log querying and retrieval. It also provides multiple query methods, supporting precise and fuzzy searches based on time range, log level, module name, and keywords. CRUD operations are performed via an interface calling the FileUtil (file operation) module of the middle layer 130. The query function, implemented based on the log indexing system, can quickly locate log records that meet the specified conditions.

[0043] For example, after log data has been preprocessed and categorized, the storage device extracts preset target information fields from each log entry as index keywords. For instance, timestamps are used to limit the time range of the logs, log levels are used to filter logs of specific severity, and module names are used to locate logs from specific functional modules, thus narrowing the search scope. When querying, the storage device carries query conditions related to the target information, such as time, module driver layer camera module, and log level. Based on the parsed query conditions, the storage device quickly matches the corresponding keywords in the index table, directly locating the log storage location that meets the conditions, then reads the log data and returns the results.

[0044] According to one embodiment of this application, both the local storage device and the cloud storage device include a visual interface. The visual interface provides a query condition input area, which generates a query instruction based on the user's query operation, and uses the query instruction to query log data.

[0045] Understandably, the visual interface is integrated into LogAPP, providing an intuitive input area for query conditions. It supports combined queries based on multiple dimensions such as time range, log level, log source, module name, and custom keywords, enabling precise problem localization and improving troubleshooting efficiency. Log levels include DEBUG, INFO, WARN, and ERROR, and log sources include hardware driver layer 110, operating system layer 120, middleware layer 130, and application layer 140.

[0046] For example, if the vehicle's infotainment system indicates a camera malfunction, the user can use LogAPP to troubleshoot the problem, aiming to locate the ERROR-level log of the 110 camera module in the hardware driver layer. First, open LogAPP, click on local storage in the visual interface, and prioritize checking the local real-time logs. Next, configure the query conditions, define the time range, select the ERROR log level, the hardware driver layer, and enter "camera". Then, execute the query and view the visual results; let's assume the problem is a camera sensor reading failure causing an initialization timeout. Thus, the user successfully located the fault log data by performing a query through the visual interface.

[0047] like Figure 3 As shown, the interaction process between the intelligent cockpit cross-level log management system and external module devices is illustrated in the following example: 1. Interaction between Apps and the Log Module: Apps 1, 2, and 3 act as log generators, sending log data generated during operation to the log module via data transmission. While inter-process communication (IPC) is typically used, this solution utilizes Android's Binder mechanism for cross-process communication, while also leveraging Intents (message carriers) to transmit data. Each app generates logs (such as business operation logs and error logs) during runtime and proactively pushes this log data to the log module for unified collection and management.

[0048] 2. Interaction between Services and the Logging Module: Services transmit their generated log data to the logging module via data transfer. This solution relies on system-level inter-process communication mechanisms, specifically Binder service calls, and real-time transmission through callback interfaces between Android components. Services generate logs while executing background tasks and then send the log data to the logging module for log aggregation.

[0049] 3. Interaction between underlying components and the logging module: The underlying components (Hardware, OS, MCU) send hardware operation, system operation, and microcontroller-related log data to the logging module via data transmission. Hardware transmits logs through the device driver interface; after capturing hardware state changes, the driver writes the log data to a designated buffer for the logging module to read. The OS uses the kernel-level logging interface to pass logs to the logging module. The MCU transmits its control logs, such as instruction execution and status feedback, to the logging module via serial communication or internal bus. Hardware records device status logs, the operating system generates system operation logs, and the microcontroller generates control logic logs; all three transmit their logs to the logging module for integration.

[0050] 4. Interaction between the logging module and the packaging and compression module: The logging module transmits the collected raw log data to the packaging and compression module via inter-process communication. After aggregating logs from all sources, the logging module passes the unprocessed log data to the packaging and compression module for compression to reduce data size.

[0051] 5. Interaction between the Packaging and Compression Module and Storage: The packaging and compression module sends the compressed log data to the storage module via data transmission. After compressing the log data, the packaging and compression module transfers the compressed package to a high-speed solid-state drive for local storage, and simultaneously synchronizes it to cloud storage (object storage service) via API interface, achieving long-term data preservation and off-site backup.

[0052] The intelligent cockpit cross-layer log management system proposed in this application covers the entire chain of log collection and transmission, including the hardware driver layer, operating system layer, middleware layer, and application layer. Through standardized interfaces, script tools, and target communication mechanisms provided by middleware, it achieves unified collection, transmission, and management of log data at all levels of the cockpit. Differentiated collection methods are adopted to address the log output characteristics of different levels; for example, the hardware driver layer uses a first interface and a first script, while the operating system utilizes a second script, achieving cross-layer, customized collection. All levels transmit data through a unified target communication mechanism provided by the middleware, and real-time compression and conversion of logs from different external modules and devices are performed, improving the standardization of transmission. A distributed architecture is adopted for unified management, with directory-based storage, memory allocation, and a log indexing system, allowing users to quickly locate the root cause of faults and improve the operational efficiency of the intelligent cockpit. This solves the problems of traditional log management systems, such as difficulty in unified management, a single storage architecture, and insufficient adaptation for customized collection.

[0053] Next, with reference to the accompanying drawings, a cross-level log management method for intelligent cockpits proposed according to embodiments of this application is described.

[0054] Figure 4 This is a flowchart of a smart cockpit cross-level log management method according to an embodiment of this application, including the following steps: In step S101, the first log data of the hardware driver layer is obtained through the first interface and the first script of the middleware, and the first log data is transmitted through the target communication mechanism provided by the middleware.

[0055] In step S102, the second log information of the operating system layer is obtained through the second script of the middleware, and the second log data is transmitted through the target communication mechanism provided by the middleware.

[0056] In step S103, the third log data of the middle layer is obtained through the log viewing command of the Linux system of the middleware, and the third log data is transmitted through the target communication mechanism provided by the middleware.

[0057] In step S104, the fourth log data of the application layer is obtained through the second interface of the middleware, and the fourth log data is transmitted through the target communication mechanism provided by the middleware.

[0058] It should be noted that the foregoing explanation of the embodiment of the intelligent cockpit cross-level log management system also applies to the intelligent cockpit cross-level log management method of this embodiment, and will not be repeated here.

[0059] The intelligent cockpit cross-level log management method proposed in this application achieves unified collection, transmission, and management of log data at all levels of the cockpit through standardized interfaces, script tools, and target communication mechanisms provided by middleware. Differentiated collection methods are adopted to address the log output characteristics of different levels, such as using a first interface and first script for the hardware driver layer and a second script for the operating system, achieving cross-level, customized collection. All levels transmit data through a unified target communication mechanism provided by the middleware, and real-time compression and conversion of logs from different external modules and devices are performed, improving the standardization of transmission. A distributed architecture is used for unified management, with directory-based storage, memory allocation, and a log indexing system, allowing users to quickly locate the root cause of faults and improving the operational efficiency of the intelligent cockpit. This solves the problems of traditional log management systems, such as difficulty in unified management, a single storage architecture, and insufficient adaptation to customized collection.

[0060] This application also provides a vehicle including the aforementioned intelligent cockpit cross-level log management system.

[0061] Figure 5 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0062] When processor 502 executes the program, it implements the intelligent cockpit cross-level log management method provided in the above embodiments.

[0063] Furthermore, the vehicle also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0064] The memory 501 is used to store computer programs that can run on the processor 502.

[0065] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0066] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0067] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0068] The processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0069] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0070] 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, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0071] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0072] 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, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. 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 (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0073] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0074] 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. An intelligent cabin cross-layer log management system, characterized in that, include: The system comprises a hardware driver layer, an operating system layer, a middleware layer, an application layer, and middleware. The middleware provides a first interface, a second interface, a first script, a second script, and a target communication mechanism. The middleware uses the first interface and the first script to obtain the first log data of the hardware driver layer, and transmits the first log data through the target communication mechanism provided by the middleware. The middleware uses the second script to obtain the second log information of the operating system layer and transmits the second log data through the target communication mechanism provided by the middleware. The middleware uses Linux system log viewing commands to obtain the third log data of the middleware layer and transmits the third log data through the target communication mechanism provided by the middleware. The middleware uses the second interface to obtain the fourth log data of the application layer and transmits the fourth log data through the target communication mechanism provided by the middleware. 2.The intelligent cabin cross-layer log management system according to claim 1, wherein, The first log data includes at least one of the first operating data and the first error data of the hardware device; the second log data includes at least one of the operating system's resource usage data, process scheduling data, and the second error data; the third log data includes at least one of the kernel data, manager data, and software data; and the fourth log data includes at least one of the startup data, shutdown data, user operation data, and the second operating data of the functional modules. 3.The smart cockpit cross-layer log management system according to claim 1, characterized in that, The target communication mechanism is either the Binder communication mechanism or the JNI communication mechanism. 4.The smart cabin cross-layer log management system according to claim 1, wherein, When the middleware transmits log data through the target communication mechanism, it compresses and converts the log data before transmitting it to the log module. 5.The smart cabin cross-layer log management system according to claim 4, characterized in that, The log module stores the log data in at least one local storage device and a cloud storage device according to the importance level of the log data. If the importance level is greater than a preset level, the log data is synchronized to the local storage device and the cloud storage device. 6.The smart cabin cross-layer log management system according to claim 5, wherein, The local storage device stores log data in directories based on time, hierarchy, and type. 7.The smart cabin cross-layer log management system according to claim 5, wherein, The local storage device and the cloud storage device establish an index based on the target information of the log data, and query and retrieve the log data based on the index. The target information includes at least one of timestamp, log level and module name. 8.The smart cabin cross-layer log management system according to claim 5, wherein, Both the local storage device and the cloud storage device include a visual interface. The visual interface provides a query condition input area, which generates a query command based on the user's query operation. The query command is then used to query log data.

9. A vehicle, characterized in that, The intelligent cockpit cross-level log management system as described in any one of claims 1-8.

10. A method for cross-level log management in an intelligent cockpit, characterized in that, The method is applied to the middleware of the intelligent cockpit cross-level log management system according to any one of claims 1-8, wherein the method includes the following steps: The first log data of the hardware driver layer is obtained through the first interface and the first script of the middleware, and the first log data is transmitted through the target communication mechanism provided by the middleware. The second script of the middleware obtains the second log information of the operating system layer, and transmits the second log data through the target communication mechanism provided by the middleware; The third log data of the middleware is obtained by using the log viewing command of the Linux system in the middleware, and the third log data is transmitted through the target communication mechanism provided by the middleware. The fourth log data of the application layer is obtained through the second interface of the middleware, and the fourth log data is transmitted through the target communication mechanism provided by the middleware.

Images