Multi-system collaboration log management method, device, equipment and storage medium

Abstract

This invention discloses a multi-system collaborative log management method, apparatus, device, and storage medium. This invention belongs to the technical field of log management for single-chip cockpit-driver integrated platforms. The method includes: acquiring real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driver integrated platform; storing the operation logs of each microcontroller unit domain into corresponding dedicated log areas in shared memory according to preset rules; wherein, the shared memory is physical memory shared by all functional domains, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain; reading the operation logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument panel domain and the advanced driver assistance system domain, respectively, and each domain persistently stores the read logs together with its own generated operation logs. This achieves the technical effect of ensuring complete retention of logs during the microcontroller unit startup phase and realizing orderly storage and integration of multi-domain logs.

Description

Technical Field

[0001] This invention relates to the field of log management technology for single-chip cockpit-driver integrated platforms, and particularly to multi-system collaborative log management methods, devices, equipment, and storage media. Background Technology

[0002] In in-vehicle computing platforms, the logging system is a key component for fault diagnosis and performance optimization. In traditional discrete architectures, the cockpit domain controller and the autonomous driving domain controller operate independently, each with its own logging system. Since the MCU (Microcontroller Unit) lacks its own storage system, it uploads logs to the domain controller via bus transmission, where they are then centrally stored and uploaded to a cloud server. The log processing flow includes:

[0003] After the MCU generates logs, it transmits them directly to the domain controller via SPI / UART or other bus communication interfaces. The cockpit domain controller's Android or intelligent driving domain controller's Linux system receives the logs and stores them locally. The Android and intelligent driving domain controllers periodically upload logs to the server via their respective log export or cloud upload modules. Independent storage of cockpit, intelligent driving, and instrument cluster logs makes unified analysis of cross-domain issues impossible; it also increases the complexity of cloud integration. The MCU boots quickly (approximately a few seconds), while Android boots slowly (approximately tens of seconds). During Android boot, logs generated by the MCU are lost because the receiving device (Android) is not ready, resulting in missing critical diagnostic data during the MCU boot phase. For example, hardware initialization error logs cannot be captured, increasing the difficulty of fault location. The communication between the MCU and the cockpit Android or intelligent driving Linux SOC is typically via an SPI / UART channel, which transmits both logs and vehicle control and device information, posing a risk of insufficient bandwidth due to large log volumes, impacting business operations. Summary of the Invention

[0004] This invention provides a multi-system collaborative log management method, apparatus, device, and storage medium to solve the technical problems of log loss during startup caused by fast startup of microcontroller units and slow startup of high-performance domains in traditional architectures, and the difficulty in unified management of independent storage of cross-domain logs.

[0005] According to one aspect of the present invention, a multi-system collaborative log management method is provided, the method comprising:

[0006] Obtain the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform;

[0007] The operation logs of each microcontroller unit domain are stored in the corresponding dedicated log area in the shared memory according to preset rules; wherein, the shared memory is the physical memory shared by each functional domain, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain.

[0008] The operating logs of the corresponding microcontroller unit domains in the shared memory are read by the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operating logs.

[0009] According to another aspect of the present invention, a multi-system collaborative log management device is provided, the device comprising:

[0010] The operation log acquisition module is used to acquire the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform;

[0011] The log partitioning storage module is used to store the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules; wherein, the shared memory is the physical memory shared by each functional domain, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain.

[0012] The log management module is used to read the operation logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operation logs.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor;

[0015] and memory that is communicatively connected to at least one processor;

[0016] The memory stores a computer program that can be executed by at least one processor, which enables the at least one processor to execute the multi-system collaborative log management method of any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the multi-system collaborative log management method of any embodiment of the present invention.

[0018] The technical solution of this invention obtains the real-time operation logs generated by each microcontroller unit domain in a single-chip cockpit-driver integrated platform; stores the operation logs of each microcontroller unit domain into a corresponding dedicated log area in shared memory according to preset rules; wherein, the shared memory is physical memory shared by all functional domains, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain; the operation logs of the corresponding microcontroller unit domains in the shared memory are read by the digital instrument panel domain and the advanced driver assistance system domain, and each domain persistently stores the read logs together with its own generated operation logs. This solves the technical problems of log loss during the startup phase caused by the fast startup of microcontroller units and the slow startup of high-performance domains in traditional architectures, and the difficulty in unified management of independent storage of cross-domain logs, achieving the technical effect of ensuring the complete retention of microcontroller unit startup phase logs and realizing the orderly storage and integration of multi-domain logs.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0021] Figure 1 A flowchart illustrating a multi-system collaborative log management method provided in an embodiment of the present invention;

[0022] Figure 2a A flowchart illustrating another multi-system collaborative log management method provided in an embodiment of the present invention;

[0023] Figure 2b A schematic diagram of the internal functional module structure of the integrated cockpit-driver chip for another multi-system collaborative log management method provided in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of a multi-system collaborative log management device provided in an embodiment of the present invention;

[0025] Figure 4 A schematic diagram of the structure of an electronic device for implementing a multi-system collaborative log management method according to an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] Figure 1 This is a flowchart illustrating a multi-system collaborative log management method provided in an embodiment of the present invention. This embodiment is applicable to log management in a chip-cabin-driver integrated platform. The method can be executed by a multi-system collaborative log management device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method specifically includes the following steps:

[0029] S110: Obtain the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform.

[0030] Among them, the single-chip cockpit-driving integrated platform can be understood as an in-vehicle computing platform that integrates the automotive cockpit domain and the intelligent driving domain onto a single chip, realizing hardware resource sharing and deep functional integration; the microcontroller unit domain can be understood as a microcontroller unit; and the operation log can be understood as the data recorded during the operation of the microcontroller unit domain, digital instrument panel domain, and advanced driver assistance system domain, recording information such as their own operating status and operation behavior.

[0031] Specifically, after each microcontroller unit domain starts running, it will record its own running status, operation and other information in real time and generate running logs, collecting the running log data generated in real time.

[0032] In some optional embodiments, each microcontroller unit domain includes a cockpit microcontroller unit domain, a functional safety microcontroller unit domain, and an intelligent driving microcontroller unit domain, and the operation log includes a cockpit operation log, a safety operation log, and an intelligent driving operation log.

[0033] The cockpit microcontroller unit domain can be understood as a functional area equipped with microcontroller units, responsible for implementing cockpit-related control functions and inter-core communication functions within the chip; the functional safety microcontroller unit domain can be understood as a functional area equipped with microcontroller units, responsible for implementing functional safety, power management, and other related functions; the intelligent driving microcontroller unit domain can be understood as a functional area equipped with microcontroller units, responsible for implementing advanced driver assistance system-related control functions; the cockpit operation log can be understood as logs generated during the operation of the cockpit microcontroller unit domain; the safety operation log can be understood as logs generated during the operation of the functional safety microcontroller unit domain; and the intelligent driving operation log can be understood as logs generated during the operation of the intelligent driving microcontroller unit domain.

[0034] S120. Store the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules.

[0035] The shared memory is physical memory shared by all functional domains, and it is pre-allocated with a dedicated log area corresponding to each microcontroller unit domain. The shared memory can be understood as physical memory shared by all functional domains, used to temporarily store the operation logs of each microcontroller unit domain; the dedicated log area can be understood as an independent storage area pre-allocated in the shared memory, corresponding to each microcontroller unit domain, specifically used to store the operation logs of the corresponding microcontroller unit domain.

[0036] Specifically, since the microcontroller unit domain lacks large-capacity persistent storage and its startup speed is much faster than some high-performance domains, the logs are first stored in the corresponding dedicated area in shared memory according to preset rules to avoid log loss. The shared memory is physical memory shared by all functional domains, and a dedicated log area has been pre-allocated for each microcontroller unit domain.

[0037] In some optional embodiments, before storing the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules, the method further includes: partitioning the shared memory, allocating a corresponding dedicated log area for each microcontroller unit domain, and dividing each dedicated log area into a high-priority log sub-area and a normal-priority log sub-area.

[0038] Partition configuration can be understood as the operation of dividing and planning shared memory; high-priority log sub-area can be understood as an area within the dedicated log area specifically used to store critical logs; ordinary-priority log sub-area can be understood as an area within the dedicated log area specifically used to store non-critical logs.

[0039] Specifically, the shared memory is first partitioned and configured, and a dedicated log area is allocated to each microcontroller unit domain. Each dedicated log area is further divided into high-priority and normal-priority log sub-areas. Logs of different importance are classified and stored to avoid the loss of critical logs due to buffer fullness and improve the reliability of log storage.

[0040] In some optional embodiments, the preset rules include log priority partitioning rules; correspondingly, storing the operation logs of each microcontroller unit domain into their respective dedicated log areas in shared memory according to the preset rules includes:

[0041] Based on the log priority division rule, the operation logs of each microcontroller unit domain are divided into high-priority logs and ordinary-priority logs;

[0042] The high-priority logs are stored in the high-priority log sub-area of ​​the corresponding dedicated log area in the shared memory, and the ordinary-priority logs are stored in the ordinary-priority log sub-area of ​​the corresponding dedicated log area in the shared memory.

[0043] The log priority classification rule can be understood as a preset rule used to distinguish the importance of logs and divide them into different priorities; high-priority logs can be understood as low-frequency logs that are of high importance and are of great significance to key scenarios such as fault diagnosis; ordinary priority logs can be understood as logs that are of average importance and are generated more frequently.

[0044] Specifically, based on the log priority classification rules, the operation logs of each microcontroller unit domain are divided into two categories: high priority and normal priority. High priority logs are stored in the high priority sub-area of ​​the corresponding dedicated log area, and normal priority logs are stored in the normal priority sub-area. This achieves accurate classification and storage of logs and ensures the secure retention of critical logs.

[0045] In some optional embodiments, storing the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules includes: storing the operation logs of the same microcontroller unit domain continuously into the corresponding dedicated log area in the order of their generation time.

[0046] Specifically, the operation logs generated by the same microcontroller unit domain are continuously stored in their respective dedicated log areas in chronological order of generation to ensure the timeliness of the logs. Subsequent log analysis can accurately reconstruct the order of events, providing clear time clues for fault diagnosis and problem investigation.

[0047] S130. The operation logs of the corresponding microcontroller unit domains in the shared memory are read through the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operation logs.

[0048] Among them, the digital dashboard domain can be understood as a high-performance functional domain that runs digital dashboard-related functions and has a fast startup speed; the advanced driver assistance system domain can be understood as a high-performance functional domain that runs advanced driver assistance-related functions; and persistent storage can be understood as storing log data in the local storage area for a long time.

[0049] Specifically, after the digital instrument cluster domain and the advanced driver assistance system domain start up, they read the logs of the corresponding microcontroller unit domains in the shared memory, and then store these logs together with the logs generated by their own operation in the local storage area for long-term preservation to ensure that the logs are completely preserved.

[0050] In some optional embodiments, reading the operation logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument cluster domain and the advanced driver assistance system domain respectively includes: when the digital instrument cluster domain is started, reading the operation logs in the dedicated log areas corresponding to the cockpit microcontroller unit domain and the functional safety microcontroller unit domain through the shared memory read interface; and when the advanced driver assistance system domain is started, reading the operation logs in the dedicated log area corresponding to the intelligent driving microcontroller unit domain through the shared memory read interface.

[0051] The shared memory read interface can be understood as the interface for data reading between the digital dashboard domain, the advanced driver assistance system domain, and the shared memory.

[0052] Specifically, after the digital instrument cluster domain starts up, the operating logs of the dedicated log areas of the cockpit microcontroller unit domain and the functional safety microcontroller unit domain are read through the shared memory read interface; after the advanced driver assistance system domain starts up, the operating logs of the dedicated log area of ​​the intelligent driving microcontroller unit domain are read through this interface. Taking advantage of the faster startup of the digital instrument cluster domain, the logs can be backed up earlier, avoiding log loss due to buffer fullness.

[0053] The technical solution of this invention obtains the real-time operation logs generated by each microcontroller unit domain in a single-chip cockpit-driver integrated platform; stores the operation logs of each microcontroller unit domain into a corresponding dedicated log area in shared memory according to preset rules; wherein, the shared memory is physical memory shared by all functional domains, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain; the operation logs of the corresponding microcontroller unit domains in the shared memory are read by the digital instrument panel domain and the advanced driver assistance system domain, and each domain persistently stores the read logs together with its own generated operation logs. This solves the technical problems of log loss during the startup phase caused by the fast startup of microcontroller units and the slow startup of high-performance domains in traditional architectures, and the difficulty in unified management of independent storage of cross-domain logs, achieving the technical effect of ensuring the complete retention of microcontroller unit startup phase logs and realizing the orderly storage and integration of multi-domain logs.

[0054] Figure 2a This is a flowchart illustrating another multi-system collaborative log management method provided by an embodiment of the present invention. Based on the above embodiments, this embodiment is a further optimization, and its specific implementation can be found in the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here. Figure 2a As shown, the method specifically includes the following steps:

[0055] S210. Obtain the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform.

[0056] S220. Store the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules; wherein, the shared memory is the physical memory shared by each functional domain, and is pre-divided into dedicated log areas corresponding to each microcontroller unit domain.

[0057] S230. The operation logs of the corresponding microcontroller unit domains in the shared memory are read through the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operation logs.

[0058] S240: Collect persistent logs from all functional domains through the in-vehicle infotainment domain, package the collected persistent logs, and then export them locally through the universal serial bus interface or upload them to the cloud server through the cloud upload module.

[0059] The in-vehicle infotainment domain can be understood as the domain that runs in-vehicle navigation, entertainment, and other related functions, and is responsible for collecting and processing logs from various functional domains in a unified manner; the vehicle log management module can be understood as the module deployed in the in-vehicle infotainment domain, used to collect and process logs from various functional domains; the universal serial bus interface can be understood as the interface used to export the packaged logs from the vehicle's infotainment system to external devices; and the cloud upload module can be understood as the functional module used to upload the packaged logs to the cloud server.

[0060] A cloud server can be understood as a server used to remotely store logs for subsequent analysis and troubleshooting.

[0061] Specifically, after the persistent storage of logs is completed in each domain, the persistent logs of all functional domains are collected through the in-vehicle infotainment domain. After being packaged and processed by the vehicle log management module, they can be exported to external devices through the universal serial bus interface or uploaded to the cloud server through the cloud upload module, so as to realize the unified management and subsequent analysis and use of logs and reduce the complexity of cloud integration.

[0062] The technical solution of this invention collects and packages persistent logs from all functional domains in the vehicle infotainment domain, and then exports them via a universal serial bus interface or uploads them to a cloud server via a cloud upload module. This solves the technical problem of scattered storage of multi-domain logs, making unified management and subsequent utilization difficult. It achieves the technical effects of unified log integration, convenient export and remote storage, and facilitates subsequent fault diagnosis and performance optimization.

[0063] Figure 2b A schematic diagram of the internal functional module structure of the integrated cockpit-pilot chip for another multi-system collaborative log management method provided in this embodiment of the invention is shown below. Figure 2b As shown, the functional modules inside the cockpit-driver integrated chip include: the cockpit domain (IVI), the intelligent driving domain (ADAS), and the instrument cluster domain (DB), which run in a high-performance CPU (such as an ARM A core), while the MCU functional software related to the traditional cockpit MCU (switch domain), intelligent driving MCU (realtime domain), and functional safety MCU (safety domain) will run in a high real-time, high-safety CPU (such as an ARMR core). These functional domains share DDR physical memory.

[0064] Since MCUs typically lack large-capacity persistent storage capabilities, in order to quickly and reliably dump logs to the high-performance domain (DB / ADAS), different log shared memory areas are allocated in DDR memory for different MCUs. When the MCU starts up, it can record the running logs in the shared memory area. After the instrument domain and ADAS domain start up, the logs can be read from the shared memory area and persisted in the local storage area (such as UFS) as files.

[0065] The size of the DDR shared memory can be estimated in advance to determine the maximum number of logs that different MCUs need to cache at startup, and the memory size can be allocated in advance (with a margin of 1). For example, if it is estimated that the MCU will generate a maximum of 4k logs when it starts running in the high-performance domain and reads logs from the memory area, and a margin of 4k is reserved, the buffer can be set to 1M. Assuming that each log is 128 bytes on average, a total of 1M / 128 bytes = 8K logs can be cached.

[0066] Furthermore, to avoid the loss of critical logs due to a full buffer in extreme cases, two priorities can be set for the shared cache: high-priority critical logs (low frequency) and normal-priority logs (high frequency).

[0067] Specifically, the MCU domain starts up quickly, while high-performance domains such as DB / ADAS / IVI domains start up more slowly. Using shared memory to transmit logs ensures that logs are cached in DDR memory and not lost when the instrument cluster / driving system domain is not started. Traditional SPI / UART methods, on the other hand, rely on the high-performance domain to complete startup. Before startup is complete, logs generated by the MCU cannot be transmitted. Furthermore, due to limited MCU memory, even with local cache, the available space is small, and too many logs generated by the MCU can lead to log loss.

[0068] Specifically, in the integrated cockpit-driver platform, the planning of hardware CPUs and domain functions based on high-performance domains may result in situations where a certain domain runs independently (exclusively using the CPU), or where certain functional domains run through virtualization (allocating different cores of the physical CPU to different functional domains). These different approaches can lead to different methods for unified log management.

[0069] For domains deployed in a dedicated manner (such as instrument domains), the logs stored therein can be obtained periodically or in real time by deploying an SFTP server in the corresponding domain (or enabling NFS network sharing, etc.), and then accessing the IVI side through an SFTP client (or NFS access) for subsequent unified export and management.

[0070] For domains managed in a virtualization manner (such as the ADAS domain and IVI domain in the attached diagram), the physical storage devices used (UFS in the attached diagram) are also partitioned and allocated to each domain. Therefore, to avoid network interactions between domains, the ADAS domain can be configured to write logs to the ADAS partition, and then the log partition can be shared with the IVI domain in read mode. In this way, the IVI domain can directly read the logs on the ADAS side, improving efficiency.

[0071] For example, the communication process is described as follows:

[0072] S1. When running in the switch domain (running cockpit MCU functions and chip internal inter-core communication functions), the real-time generated logs are stored in the switch log shared area of ​​DDR memory through the DDR write interface.

[0073] S2. When running in the safety domain (running functional safety, power management and other related functions), the real-time generated logs are stored in the safety log shared area of ​​DDR memory through the DDR write interface.

[0074] S3. When running in the realtime domain (running ADAS domain MCU functions), the real-time generated logs are stored in the realtime log shared area of ​​DDR memory through the DDR write interface.

[0075] S4. After the instrument domain starts up, the corresponding logs are read from the switch domain log shared memory area and the safety domain log shared memory area via the DDR read interface, and then written to the instrument domain's log file for persistent storage via the log interface. Simultaneously, the instrument's own logs are also written to log files for persistent storage via the log interface. The log files of each domain are partitioned and stored separately. The instrument domain is chosen to read logs from the DDR shared cache instead of the IVI domain because the instrument domain typically starts up faster, allowing for earlier log backup and preventing potential log loss due to a full buffer.

[0076] S5. After the ADAS domain starts, logs are read from the realtime domain log shared memory area via the DDR read interface and written to the ADAS domain log file for persistent storage via the log interface. The ADAS domain's own logs are also written to log files for persistent storage via the log interface.

[0077] Logs on the S6 and IVI sides are recorded to persistent storage via the logcat mechanism.

[0078] S7. Deploy a vehicle log management module on the vehicle's IVI side. For log files stored on the instrument panel, the IVI can access the log files in the instrument panel / switch domain / safety domain via network access methods such as SFTP or NFS.

[0079] S8. For ADAS logs and real-time logs stored on the ADAS side, log partitions can be shared with IVI in read mode through virtualization configuration, allowing IVI to directly read the log files on the ADAS side. For logs stored on the IVI, the IVI itself can read them directly.

[0080] After obtaining the logs from all domains of S7-S8, the vehicle log export module of S9 and IVI packages the logs as needed to complete the persistent log export or upload the logs to the cloud for subsequent log analysis.

[0081] The technical solution of this invention uses DDR shared memory for log buffering, ensuring that logs are preserved during the MCU startup phase. By partitioning the DDR shared memory, specialized partitions are created for different log types and security domains, ensuring reliable storage of critical logs. The DB / Safety domain reads the cached MCU logs from the DDR memory, achieving log persistence and ensuring that logs are not lost in case of abnormal vehicle system restarts. A virtualized shared ADAS log partition is provided to the IVI, enabling the IVI to directly and efficiently read ADAS logs. The vehicle log export module on the IVI enables unified management, export, and cloud uploading of logs from all domains. This optimizes log storage and transmission efficiency.

[0082] Figure 3 This is a schematic diagram of a multi-system collaborative log management device provided in an embodiment of the present invention. Figure 3 As shown, the device includes: a log acquisition module 310, a log partition storage module 320, and a log management module 330.

[0083] The system includes a log acquisition module 310, which acquires real-time logs generated by each microcontroller unit domain in the single-chip cockpit-driver integrated platform; a log partitioning storage module 320, which stores the logs of each microcontroller unit domain into a dedicated log area in the shared memory according to preset rules; wherein the shared memory is physical memory shared by all functional domains and is pre-divided into dedicated log areas corresponding to each microcontroller unit domain; and a log management module 330, which reads the logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument panel domain and the advanced driver assistance system domain, and each domain persistently stores the read logs together with its own generated logs.

[0084] The technical solution of this invention obtains the real-time operation logs generated by each microcontroller unit domain in a single-chip cockpit-driver integrated platform; stores the operation logs of each microcontroller unit domain into a corresponding dedicated log area in shared memory according to preset rules; wherein, the shared memory is physical memory shared by all functional domains, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain; the operation logs of the corresponding microcontroller unit domains in the shared memory are read by the digital instrument panel domain and the advanced driver assistance system domain, and each domain persistently stores the read logs together with its own generated operation logs. This solves the technical problems of log loss during the startup phase caused by the fast startup of microcontroller units and the slow startup of high-performance domains in traditional architectures, and the difficulty in unified management of independent storage of cross-domain logs, achieving the technical effect of ensuring the complete retention of microcontroller unit startup phase logs and realizing the orderly storage and integration of multi-domain logs.

[0085] In some optional embodiments, each microcontroller unit domain includes a cockpit microcontroller unit domain, a functional safety microcontroller unit domain, and an intelligent driving microcontroller unit domain, and the operation log includes a cockpit operation log, a safety operation log, and an intelligent driving operation log.

[0086] In some alternative embodiments, the apparatus further includes:

[0087] The memory partitioning module is used to partition the shared memory before storing the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules. The module allocates a corresponding dedicated log area to each microcontroller unit domain, and each dedicated log area is divided into a high-priority log sub-area and a normal-priority log sub-area.

[0088] In some optional embodiments, the preset rules include log priority partitioning rules; correspondingly, the log partitioning storage module includes:

[0089] The priority partitioning unit is used to partition the operation logs of each microcontroller unit domain into high-priority logs and ordinary-priority logs based on the log priority partitioning rules.

[0090] The log storage unit is used to store the high-priority logs in the high-priority log sub-area of ​​the corresponding dedicated log area in the shared memory, and to store the ordinary-priority logs in the ordinary-priority log sub-area of ​​the corresponding dedicated log area in the shared memory.

[0091] In some optional embodiments, the log partition storage module is specifically used for:

[0092] The operation logs of the same microcontroller unit domain are stored sequentially in their respective dedicated log areas according to their generation time.

[0093] In some optional embodiments, the log management module includes:

[0094] The first reading unit is used to read the operation logs in the dedicated log areas corresponding to the cockpit microcontroller unit domain and the functional safety microcontroller unit domain through the shared memory read interface when the digital instrument panel domain is started.

[0095] The second reading unit is used to read the running log in the dedicated log area corresponding to the intelligent driving microcontroller unit domain through the shared memory read interface when the advanced driver assistance system domain is started.

[0096] In some alternative embodiments, the apparatus further includes:

[0097] The log upload module is used to persistently store the logs read by each domain together with the operation logs generated by itself, and then collect the persistent logs of all functional domains through the in-vehicle infotainment domain. After packaging the collected persistent logs, they are exported locally through the universal serial bus interface or uploaded to the cloud server through the cloud upload module.

[0098] The multi-system collaborative log management device provided in the embodiments of the present invention can execute the multi-system collaborative log management method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method.

[0099] Figure 4 This is a schematic diagram of the structure of an electronic device for implementing the multi-system collaborative log management method of this invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0100] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0101] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0102] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as multi-system collaborative log management.

[0103] In some embodiments, the method for multi-system collaborative log management can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for multi-system collaborative log management described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method for multi-system collaborative log management by any other suitable means (e.g., by means of firmware).

[0104] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0105] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0106] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0107] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0108] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0109] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0110] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0111] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing collaborative logs across multiple systems, characterized in that, include: Obtain the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform; The operation logs of each microcontroller unit domain are stored in the corresponding dedicated log area in the shared memory according to preset rules; wherein, the shared memory is the physical memory shared by each functional domain, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain. The operating logs of the corresponding microcontroller unit domains in the shared memory are read by the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operating logs.

2. The method according to claim 1, characterized in that, Each microcontroller unit domain includes a cockpit microcontroller unit domain, a functional safety microcontroller unit domain, and an intelligent driving microcontroller unit domain. The operation logs include cockpit operation logs, safety operation logs, and intelligent driving operation logs.

3. The method according to claim 1, characterized in that, Before storing the operation logs of each microcontroller unit domain into their respective dedicated log areas in shared memory according to preset rules, the process also includes: The shared memory is partitioned, and a corresponding dedicated log area is allocated to each microcontroller unit domain. Each dedicated log area is further divided into a high-priority log sub-area and a normal-priority log sub-area.

4. The method according to claim 1, characterized in that, The preset rules include log priority division rules; the step of storing the operation logs of each microcontroller unit domain into the corresponding dedicated log area in shared memory according to the preset rules includes: Based on the log priority division rule, the operation logs of each microcontroller unit domain are divided into high-priority logs and ordinary-priority logs; The high-priority logs are stored in the high-priority log sub-area of ​​the corresponding dedicated log area in the shared memory, and the ordinary-priority logs are stored in the ordinary-priority log sub-area of ​​the corresponding dedicated log area in the shared memory.

5. The method according to claim 1, characterized in that, The step of storing the operation logs of each microcontroller unit domain into a corresponding dedicated log area in shared memory according to preset rules also includes: The operation logs of the same microcontroller unit domain are stored sequentially in their respective dedicated log areas according to their generation time.

6. The method according to claim 1, characterized in that, The step of reading the operation logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument panel domain and the advanced driver assistance system domain respectively includes: When the digital instrument cluster domain is started, the operation logs in the dedicated log areas corresponding to the cockpit microcontroller unit domain and the functional safety microcontroller unit domain are read through the shared memory read interface; When the advanced driver assistance system domain is started, the running log in the dedicated log area corresponding to the intelligent driving microcontroller unit domain is read through the shared memory read interface.

7. The method according to claim 1, characterized in that, After each domain persists the read logs along with its own generated runtime logs, the process also includes: The persistent logs of all functional domains are collected through the in-vehicle infotainment domain. After the collected persistent logs are packaged, they are exported locally through the universal serial bus interface or uploaded to the cloud server through the cloud upload module.

8. A multi-system collaborative log management device, characterized in that, include: The operation log acquisition module is used to acquire the real-time operation logs generated by each microcontroller unit domain in the single-chip cockpit-driving integrated platform; The log partitioning storage module is used to store the operation logs of each microcontroller unit domain into the corresponding dedicated log area in the shared memory according to preset rules; wherein, the shared memory is the physical memory shared by each functional domain, and is pre-divided into dedicated log areas corresponding one-to-one with each microcontroller unit domain. The log management module is used to read the operation logs of the corresponding microcontroller unit domains in the shared memory through the digital instrument panel domain and the advanced driver assistance system domain, respectively. Each domain will persistently store the read logs together with its own generated operation logs.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the multi-system collaborative log management method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the multi-system collaborative log management method according to any one of claims 1-7.

Images