Method for storing logs, electronic control unit, vehicle and storage medium

Abstract

Embodiments of the present application provide a log storage method, an electronic control unit, a vehicle and a storage medium. The method comprises: determining a target data block ID corresponding to the current MPU unit startup from a circular data link list after the micro computing unit (MPU) is started, wherein the circular data link list comprises a plurality of data block IDs connected in a logical ring, and different data blocks corresponding to different data block IDs are used to store log information corresponding to different startup rounds of the MPU unit; and storing log information after the current startup of the MPU unit to a data block corresponding to the target data block ID.

Description

Technical Field

[0001] This application relates to the field of log data processing technology, and in particular to a log storage method, an electronic control unit, a vehicle, and a storage medium. Background Technology

[0002] In existing technologies, during the early stages of software system startup and operation, the microprocessor unit (MPU) of an electronic control unit (ECU) typically stores generated log information temporarily in synchronous dynamic random access memory (DDR) because persistent storage media is not yet mounted. However, when the software system restarts or experiences an abnormal reset, the data stored in DDR is lost when the memory is reset. This results in the system only being able to record the real-time status of the current operating cycle, making it impossible to store log information for multiple MPU unit startup and operation processes, severely impacting the reliability and maintainability of the log information. Summary of the Invention

[0003] This application provides a log storage method, an electronic control unit, a vehicle, and a storage medium, aiming to improve the problem that it is impossible to store log information during multiple MPU unit startup and operation processes, which seriously affects the reliability and maintainability of log information.

[0004] A method for storing logs, comprising: After the microcomputing unit (MPU) starts, the target data block ID corresponding to this MPU unit startup is determined from the circular data linked list. The circular data linked list includes multiple data block IDs that are logically connected in a ring. The data blocks corresponding to different data block IDs are used to store log information corresponding to different startup rounds of the MPU unit. The log information of the MPU unit after this startup is stored in the data block corresponding to the target data block ID.

[0005] An electronic control unit, comprising an MPU unit; After the MPU unit starts, the target data block ID corresponding to this MPU unit startup is determined from the circular data linked list. The circular data linked list includes multiple data block IDs that are logically connected in a ring. The data blocks corresponding to different data block IDs are used to store log information corresponding to different startup rounds of the MPU unit. The log information of the MPU unit after this startup is stored in the data block corresponding to the target data block ID.

[0006] A vehicle, comprising an electronic control unit or an MPU unit for implementing the method as described in any of the preceding claims.

[0007] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any of the preceding claims.

[0008] In one of the solutions provided in this application, after the MPU unit starts, it determines the target data block ID corresponding to the current startup from the circular data linked list and stores the log information of the current running cycle into that specific data block. By introducing a static circular linked list data structure, the data storage area is logically divided into multiple independent and circularly connected data blocks, and indexing is performed using the data block ID. This allows the MPU unit to automatically redirect the current log stream to the next free or overwriteable data block during each independent restart. Since the logs from different rounds are stored in isolation in different nodes of the circular linked list, when an occasional circular restart or startup anomaly occurs, the log information of the previous failed round is retained in the previous data block and will not be overwritten by the startup data of the new round. This solves the problem mentioned in the background art of data loss due to DDR reset during system restart. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a log storage method according to an embodiment of this application; Figure 2 This is a schematic diagram of a frame of an electronic control unit provided in one embodiment of this application; Figure 3 This is a schematic diagram of a data structure for a log storage area provided in an embodiment of this application; Figure 4 This is a schematic diagram of the storage process of log information during the operation of a software system, provided in an embodiment of this application. Detailed Implementation

[0010] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0011] With technological advancements, the hardware architecture of vehicles and other equipment is constantly evolving. To meet the complex and diverse application demands, the electronic control units (ECUs) on these devices often employ heterogeneous computing architectures. This heterogeneous architecture integrates different types of processors, such as microcontroller units (MCUs) and multi-processor units (MPUs), leveraging their respective strengths through optimized task allocation to achieve more efficient computing and processing capabilities. Furthermore, it utilizes various storage media, including NOR flash memory, standby random access memory (Standby RAM), DDR memory, and embedded multimedia cards (eMMC), to meet the diverse storage and performance requirements of this heterogeneous computing architecture. During the operation of the MPU's software system, data is stored on different storage media based on the differences in the software system. For example, in-vehicle ECUs in vehicles frequently employ this heterogeneous computing architecture.

[0012] Currently, to ensure the retention of log information in the MPU unit's software system, the following methods are generally combined: The software system's log information is stored in DDR, and after the MPU unit's operating system successfully boots, the log information is forwarded to an external system or written to eMMC; alternatively, the eMMC's file system is loaded at each stage of the software operation to persistently store the log information in eMMC; or, the software system loads a network communication driver module to send the log information to an external processing device for processing via the network. In other words, it mainly combines two methods: storage in eMMC or real-time network transmission. However, in the above approach, persistent storage is not mounted during some startup phases of the software system. Log information captured throughout the process needs to be stored in DDR. If DDR fails to initialize successfully or if an error occurs during DDR, log information cannot be recorded. Before eMMC initialization, log information needs to be stored in DDR, and then transferred to eMMC once it becomes available. If an error occurs during this process, log information may also fail to be recorded. If the software system mounts and stores data in eMMC throughout the entire process, the data software complexity is high, and system performance is significantly reduced. If all log data is stored via network external transmission, it not only increases the complexity of the MPU unit software system but also significantly increases the size of each software image, severely affecting the performance of the MPU unit. It is clear that the traditional solution cannot guarantee the integrity of log information during the operation of the MPU unit software system, is prone to log information loss, and affects the operating performance of the MPU unit.

[0013] To address this issue, this application provides a log storage method, an electronic control unit (ECU), a vehicle, and a storage medium. These are primarily used to ensure the integrity of log information during the operation of the MPU unit software system within the ECU, resolving the problem of not being able to store log information for multiple MPU unit startups and operations, and improving the reliability and maintainability of the log information. The ECU includes, but is not limited to, vehicle-mounted controllers using a heterogeneous SOC architecture, and can also refer to ECUs applied to other equipment products; specific embodiments of this application are not limited thereto. The embodiments of this application are described below through various examples.

[0014] Example 1 In one embodiment, such as Figure 1 As shown, a method for log storage is provided, which includes: S10. After the MPU unit starts, the target data block ID corresponding to this MPU unit startup is determined from the circular data linked list. The circular data linked list includes multiple data block IDs that are logically connected in a circular manner. The data blocks corresponding to different data block IDs are used to store log information corresponding to different startup rounds of the MPU unit. S20. Store the log information of the MPU unit after this startup to the data block corresponding to the target data block ID.

[0015] In this embodiment, as an example, the MPU unit can be an MPU unit within an ECU unit, or an in-vehicle ECU unit; the specific type is not limited. In this embodiment, a circular data list is pre-configured. The circular data list includes multiple data block IDs logically connected in a circular manner. Data blocks corresponding to different data block IDs are used to store log information corresponding to different startup cycles of the MPU unit. The target data block ID can be the node number of the data block used during the current MPU unit startup, assigned by the MCU unit.

[0016] A circular linked list represents the usage characteristics of each data block, and the data block ID represents the usage order of the data blocks, forming a chain structure. In other words, a chain-based data structure is used. Each time a new MPU unit is started, new data blocks are used sequentially according to the data block IDs indicated by the circular linked list. For example, multiple data blocks include data block 1 to data block n, used in chain order: data block 1 → data block 2 → data block 3… , where node n, data block 1 to data block n, represent the data blocks used from the first to the nth time the MPU unit is started.

[0017] like Figure 3As shown, the data structure of the data blocks in the log storage area is explicitly defined as a circular chain structure, i.e., a closed loop from tail data block to head data block. For example, in a circular chain of 5 nodes, the tail pointer with tail identifier = 5 points to the head pointer with head identifier = 1. In practical applications, the header of the log storage area needs to record the identifier of the data block and the number of nodes to facilitate data block ID navigation.

[0018] For example, such as Figure 3 As shown, after the MCU unit starts, it divides the log storage area of ​​the first volatile memory unit into 5 data blocks; these blocks are linked in a circular chain according to the identifiers 1→2→…→5, and the tail pointer of the tail node 5 is set to point to the head node 5, completing the circular loop. The header of the log area records the header identifier = 1, the tail identifier = 5, and the total number of nodes = 5, assigning an initial data block ID of 1 (pointing to the head node) to ensure the circular structure is identifiable. During the 1st to 5th startups of the MPU unit, the MCU unit increments the data block ID in a chained order (1→2→…→5), and the MPU unit uses the corresponding data block to store log information. During the 6th startup of the MPU unit, the data block ID jumps back to identifier 1, and this process repeats. In other words, during each startup of the MPU unit, the data blocks are recycled through node switching, enabling the collection of log information from multiple restart processes and ensuring the storage mechanism for historical data. Furthermore, by retrospectively checking the stored timestamps, the process of each software startup and operation can be traced, ensuring a traceability mechanism for software faults and improving product reliability.

[0019] It should be noted that, in this embodiment, the number of data blocks in the log storage area and the depth of the data bit width of each data block can be determined in advance through verification testing based on the storage space size and storage requirements of the first volatile storage unit, thereby ensuring that the log storage performance and memory space usage reach the optimal solution. No specific limitation is made. For example, the number of data blocks and the size of the space can be determined according to the actual memory size. Furthermore, an evaluation is conducted based on the storage size of the first volatile storage unit, the historical tracing requirements of the software system, and other characteristics to avoid impacting the electronic control unit (ECU) due to excessive storage usage, or to avoid impacting the control equipment using the ECU.

[0020] As can be seen, this embodiment introduces a static circular linked list data structure, logically dividing the data storage area into multiple independent and circularly connected data blocks. Using data block IDs for indexing and redirection, the MPU unit can automatically redirect the current log stream to the next free or overwriteable data block during each independent restart. Since logs from different rounds are stored isolated in different nodes of the circular linked list, when an occasional circular restart or startup anomaly occurs, the log information from the previous failed round is retained in the previous data block and is not overwritten by the new round's startup data. This solves the problem mentioned in the background art of data loss due to DDR reset during system restarts.

[0021] In one embodiment, the software system operation phase of the MPU unit software system includes a boot initialization phase and an operating system operation phase that run sequentially; in step S20, storing the log information of the MPU unit after this startup into the data block corresponding to the target data block ID includes: Before the log service is started during the operating system runtime phase, the log information of the software system is encoded and stored in the data block corresponding to the target data block ID in the first volatile storage unit; After the log service starts, it de-encodes the encoded data in the data block corresponding to the target data block ID to extract log information. The de-encoded log information is then stored in the second volatile storage unit and transferred to the non-volatile storage unit. In this embodiment, multiple types of storage media are introduced to relay the storage of log information. These multiple types of storage media include a first volatile storage unit, a second volatile storage unit, and a non-volatile storage unit. This allows the ECU unit to meet the different storage needs of different functional chips, saving various types of system data and business data. The multiple types of storage media communicate with each other through a read / write data communication bus.

[0022] As an example, please refer to [link / reference]. Figure 2 As shown, the first volatile memory unit includes Standby RAM, the second volatile memory unit includes DDR, and the non-volatile memory unit includes eMMC. It should be noted that the first volatile memory unit, the second volatile memory unit, and the non-volatile memory unit can also be other memories with similar properties; this application does not limit the specific embodiments therein. It should also be noted that the above three types of storage media can be internal or external storage media of the electronic control unit; this application does not limit the specific embodiments therein.

[0023] The software system operation phase of the MPU unit software system includes the boot initialization phase and the operating system operation phase, which run sequentially. These will be described separately below.

[0024] The boot initialization phase refers to the initial process of the software system after the MPU unit starts up. For example, the boot initialization phase may include the BL2 phase, which is used to initialize the second volatile memory unit (such as DDR), clock and serial port and other hardware, as well as load and verify the BL31 / 32 / 33 software image to the memory area of ​​the specified second volatile memory unit. It also includes the BL31 / 32 / 33 phase and the BL31\BL32\BL33 phase, which belong to the intermediate running phase of the software system.

[0025] The operating system runtime phase is the later process after the MPU unit starts up. Taking Linux as an example, it includes the Linux Kernel phase, the Linux init script phase, and the Linux Systemd system service phase, which includes the log service phase, etc.

[0026] In this embodiment, as an example scenario, after the controller of the electronic control unit (ECU) is powered on, the MCU unit is started first. The MCU unit initializes various hardware, including initializing the first volatile memory unit, dividing the first volatile memory unit into an independent area as a log storage area, formatting the header of the log storage area, resetting the log storage area to its initial value, assigning values ​​to parameters such as the data block ID (CurrentBlockID) of the data block used by the current MPU unit startup, and triggering the MPU unit startup.

[0027] After the MPU unit starts, the MPU unit software system runs the boot initialization phase and the operating system running phase in sequence. In the log storage area of ​​the first volatile storage unit, the data block corresponding to the target data block ID of this startup is selected. Before the log service starts in the operating system running phase, the log information of the software system is encoded and stored in the data block. After the log service starts, the encoded data in the data block is decoded into log information through the log service. The decoded log information is stored in the second volatile storage unit. Finally, the decoded log information is transferred to the non-volatile storage unit.

[0028] As can be seen, in this embodiment, by relaying multiple storage media such as the first volatile storage unit, the second volatile storage unit, and the non-volatile storage unit, a storage strategy for log information generated during the operation of the MPU unit software system at each stage is implemented. Before the log service starts during the operating system operation stage, a data block corresponding to a specified data block ID is selected, and the log information is encoded and stored in the data block of the first volatile storage unit (such as Standby RAM). After the log service starts, the encoded data in the data block is de-encoded into log information through the log service, and the de-encoded log information is stored in the second volatile storage unit and then transferred to the non-volatile storage unit. This approach has the following advantages: During the startup phase of the MPU unit software system, it is not necessary to store the log information captured throughout the entire process in the second volatile storage unit (such as DDR). However, if the second volatile storage unit (DDR) is successfully initialized or if an abnormality occurs during the process, the log information of the corresponding stage can still be recorded. Before the initialization of the non-volatile storage unit (such as eMMC), it is also not necessary to store the log information in the second volatile storage unit (such as DDR). This avoids the inability to record log information during this process, solves the problem of data loss caused by the collection of log information at different stages, and effectively ensures the integrity of the log information of each software function during the operation of the MPU unit software system.

[0029] In addition, during certain stages of booting and operating system startup, no file system is mounted. If the data is stored in DDR, the runtime logs for this stage cannot be collected and persistently stored. Furthermore, since some stage data is only stored in DDR, data loss can occur when the system malfunctions, making it impossible to trace the source. This embodiment enables persistent storage of the aforementioned stages, improving the stability and reliability of the system.

[0030] Furthermore, it avoids mounting the software system entirely on non-volatile storage units (such as eMMC), reducing the overall system complexity. It also avoids storing log data entirely via network outbound methods, reducing the complexity of the MPU unit software system, significantly reducing the size of each software system and each software image, and improving the operating performance of the MPU unit.

[0031] In one embodiment, the data block corresponding to the target data block ID includes multiple data sub-blocks. Different data sub-blocks are used to store log information corresponding to different running stages before the software system's log service starts. Encoding and storing the software system's log information into the data block corresponding to the target data block ID in the first volatile storage unit includes: Log information corresponding to different running stages before the software system's log service starts is encoded and stored in different data sub-blocks.

[0032] like Figure 3As shown, Figure 3 This represents the overall data structure of the log storage area in the first volatile storage unit. `LogZone Ring` represents the ring-chain structure of the log storage area. `LogZone Header` represents the header of the log storage area. `LogData Block` represents the data block of the log storage area. Each data block is divided into multiple data sub-blocks. Each data sub-block is used to store log information corresponding to different running stages before the software system's log service starts. For example, `BlockHeader` represents the header of the encoded data in the data sub-block; `BL2 LogData` represents the encoded data stored in the BL2 stage; `BL31\BL32\BL32 LogData` represents the encoded data stored in the BL31\BL32\BL32 stage; `Kernel LogData` represents the encoded data stored in the Linux Kernel stage; `initShellLogData` represents the encoded data stored in the init script stage; and `systemd LogData` represents the encoded data stored in the Linux systemd system service stage. In other words, in different software system operation phases, the data areas corresponding to the operation data blocks are filled with separate data sub-blocks in each operation phase, without interfering with each other. The memory size required for a specific area can be determined according to the number of operation nodes of each software system (reflecting the data size requirement to be stored).

[0033] It should be noted that, depending on the different MPU unit software systems, the above software systems may have different operating phases, and the stored log information may also be different. No specific restrictions are made here.

[0034] As an illustrative example only, taking the aforementioned software system operation phases as an example, the MPU unit operates according to the following path: MCU BootLoad → MPU BL2 phase → MPU BL31 / BL32 / BL33 phases → MPU Linux Kernel phase → MPU Linux init script → MPU Linux Systemd system service. This example is used to illustrate the log information storage process during the startup of the MPU unit in this embodiment.

[0035] The initialization phase includes: In the BL2 phase, the basic initialization work of the MPU unit is mainly carried out, including the initialization processing of hardware such as the second volatile memory unit, clock and serial port, and sequentially loading and verifying the software image of the subsequent running stages (such as BL31, BL32 and BL33 phases) to the memory area of ​​the designated second volatile memory unit; and writing the log information of the preset running node of the BL2 phase to the data sub-block corresponding to the target data block ID in the data block corresponding to the BL2 phase.

[0036] The BL31, BL32, and BL33 stages are intermediate operation stages of the software system. The log information corresponding to the preset operation nodes of each stage is encoded and stored in the corresponding data sub-blocks of each stage in the data block corresponding to the target data block ID. The operating system runtime phase includes: The Linux Kernel stage mainly implements operating system initialization, loading of various driver modules, and parameter configuration; the log information corresponding to the preset running node of this process is encoded and stored in the data sub-block of the data block corresponding to the target data block ID; During the Linux init script phase, the Kernel executes the init script, mounts the file system of non-volatile storage units, initializes the file system environment, and starts the systemd service process; it also encodes and stores the log information corresponding to the preset running node of this process into the data sub-block of the data block corresponding to the target data block ID. During the Linux systemd system service phase, various business functions are provided based on parallel multi-system services. This process continues until the journal service is started. The operating system's journal service has not yet started working. The log information corresponding to the preset running node of this process is encoded and stored in the data sub-block of the data block corresponding to the target data block ID. In the Systemd logging service phase, once started, the logging service can begin working. The logging service can capture log information in data blocks, store it in the second volatile storage unit, and then transfer it to the non-volatile storage unit. Successfully working with the non-volatile storage unit, the logging service completes the persistent storage of log information.

[0037] In one embodiment, log information corresponding to different operational stages before the software system's log service starts is encoded and stored in different data sub-blocks, including: Before the log service starts, when it reaches the preset running node at different running stages, the corresponding storage bits of different data sub-blocks corresponding to the running node are set from the initial value to the target value to identify the running status of the running node.

[0038] In this embodiment, the preset running nodes refer to the software running nodes at each stage of the software system's operation. The stored bit values ​​represent the running status of the software running node. For example, initial value = 0 (running node not executed or failed, etc.), target value = 1 (running node executed successfully, etc.). For example, software functions such as successful DDR initialization or failed serial port initialization can have their preset running nodes set according to requirements; no specific limitations are made here.

[0039] Continuing with the above software system operation phase as an example, the MPU unit follows the collaboration and security verification strategy for each software function phase. The operation phase path is: MCU BootLoad → MPU BL2 phase → MPU BL31 / BL32 / BL33 phase → MPULinux Kernel phase → MPU Linux init script → MPU Linux Systemd system service, illustrating the data storage process.

[0040] The initialization phase includes: In the BL2 phase, the basic initialization of the MPU unit is mainly performed, including hardware such as the second volatile memory unit, clock, and serial port. The software images of subsequent running phases (BL31, BL32, and BL33) are loaded and verified sequentially to the designated memory area of ​​the second volatile memory unit. Log data of the preset running nodes in the BL2 phase is written to the storage location corresponding to the data sub-block of that BL2 phase. For example, the preset running nodes in the BL2 phase include operation records (whether they were executed) and execution status (success / exception). The BL31, BL32, and BL33 stages are intermediate operation stages of the software system, mainly involving data collection operations in the corresponding data areas; and storing the log information corresponding to the preset operation nodes of each stage into the corresponding storage locations of the data sub-blocks of each stage in BL31, BL32, and BL33; for example, the preset operation node package operation results (yes / no) of the BL31, BL32, and BL33 stages. The operating system runtime phase includes: The Linux Kernel stage primarily handles operating system initialization, loading of various driver modules, and parameter configuration. Log information corresponding to the preset running nodes of this process is stored in the corresponding storage location of the data sub-block for this stage. This includes, for example, the results of each operation (execution / failure) and any exceptions (success / error) that occur at the preset running nodes of this stage. During the Linux init script phase, the Kernel executes the init script, mounts the file system on non-volatile storage units, initializes the file system environment, and starts the systemd service process. It stores the log information corresponding to the preset execution nodes of this process in the corresponding storage location of the data sub-block for this phase. For example, the log information corresponding to the preset execution nodes of this phase includes the results of each operation (whether it was executed or not) and any exceptions (success / exception). During the Linux systemd system service phase, various business functions are provided based on parallel multi-system services. The operating system's log service does not start working until the journald service is started. The log information corresponding to the preset running nodes of this process is stored in the corresponding location of the data block. The log information corresponding to the preset running nodes in this phase includes the operation results (execution / failure) of various business functions and the abnormal status (success / abnormality) that occurs. In the Systemd logging service phase, once started, the logging service can begin working. The logging service can capture log information in data blocks, store it in the second volatile storage unit, and then transfer it to the non-volatile storage unit, successfully completing persistent storage in conjunction with the non-volatile storage unit.

[0041] As an example, assume that each preset running node corresponds to one or more storage bits, without any specific limitation. To facilitate understanding of the logging information storage process described above, the following table is used as an example.

[0042] Taking the above table as an example, when the MPU unit runs to the preset running node, it performs point storage: After the DDR initialization is completed in the BL2 stage, it is determined to be successful, and Bit4 is set from 0 to 1 (target value); after the serial port initialization is completed in the BL2 stage, it is determined to be unsuccessful (such as poor hardware contact), and Bit5 remains at 0 (target value); after the sensor driver is loaded in the Kernel stage, it is determined to be successful, and Bit8 is set from 0 to 1.

[0043] As can be seen, in this embodiment, the bit-level dotted storage encoding method enables comprehensive information collection from multiple operational stages, from MPU unit startup to shutdown, thus improving system availability. Furthermore, the bit-level dotted storage method significantly reduces the amount of data to be stored, eliminating the need to encode the entire operational process, thereby improving storage efficiency and utilization. Moreover, this dotted storage method, where storage bits correspond to the running status of operational nodes, facilitates the rapid and accurate location of fault causes. For example, the status of a corresponding operational node (whether it is executing, normal / abnormal, etc.) can be deduced from the values ​​of certain storage bits.

[0044] It should be noted that in other embodiments, there are other ways to encode log information into data blocks. This application embodiment does not limit these methods. For example, the log information can be directly encoded. No specific method is limited.

[0045] In one embodiment, storing the decoded log information in a second volatile storage unit and transferring the decoded log information to a non-volatile storage unit includes: The decoded log information is serialized, and the serialized log information is stored in the second volatile storage unit and then transferred to the non-volatile storage unit.

[0046] In this embodiment, after the log service starts, the encoded data of the data block in the first volatile storage unit is read through the log service, de-encoded into log information, and serialized to form structured log information. The serialized log information is stored in the second volatile storage unit. Then, the log service triggers a transfer task to read the serialized log information in the second volatile storage unit and transfer the read log information to the log file in the non-volatile storage unit.

[0047] For example, as an example, the serialized data can be formatted visualization data. The serialized and visualized log information is stored in a second volatile storage unit and then transferred to a non-volatile storage unit.

[0048] In this embodiment, serialization is used to unify the log format, reducing information confusion and ambiguity during cross-storage media transmission, and visualization facilitates the interpretation of log operation status.

[0049] In one embodiment, the method further includes: After the system services unload the file system from the non-volatile storage unit during the operating system runtime phase, the MPU unit stores log information that cannot be stored in the file system into the first volatile storage unit through the system services.

[0050] It should be understood that when the operating system shuts down, the log information cannot be directly transferred after the file system of the non-volatile storage unit is unloaded. Therefore, in this embodiment, by operating the data blocks currently used by the non-volatile storage unit, log information that cannot be stored in the file system can be saved to the first volatile storage unit so that the log information can be persistently saved after the next startup, thus ensuring that the log running data is not lost and fully guaranteeing that the log information is not lost during the entire software system operation phase.

[0051] As can be seen from the above embodiments, the embodiments of this application provide a log storage method, including the use of multiple types of storage media for relay storage, to realize a log data recording strategy generated during the operation of the MPU unit software system at each stage, ensuring the integrity of the log information of each software function during the operation of the MPU unit software system of the electronic control ECU, fundamentally and effectively solving the problem that the log information and other types of data of the MPU unit software system are easily lost at different stages of operation, thereby improving the overall availability and reliability of the system, and effectively avoiding system availability problems caused by the inability to record log data and loss of data information due to functional abnormalities at different stages of the software system.

[0052] It is also worth noting that the embodiments of this application can be applied to ECU products such as vehicle ECUs that are developed with embedded software systems that have multiple types of storage media. There are no special requirements for the application process. When the ECU with a heterogeneous computing architecture has multiple high-performance computing MPU chips, and it is necessary to collect log information from different software startup and running stages to a unified platform during the startup process, the solution of the embodiments of this application can produce good results in terms of product availability and stability.

[0053] Example 2 Combination such as Figure 1 and Figure 4 As shown in the embodiments, this application also provides a log storage method for, for example... Figure 2 The ECU unit shown includes an MCU unit and an MPU unit, as well as supporting Standby RAM, DDR, and MMC. The ECU typically also includes Nor-Flash and System SRAM. "External" indicates that the DDR is external to the MPU; for example, "External DDR" means the DDR is external to the MPU. This ECU unit is used to implement the following: (1) When the ECU controller is powered on, the MCU unit is started first (POWER_ON). The MCU unit initializes various hardware, including Standby RAM (Init Log Zone), and allocates a separate area with a fixed position and size as the log storage area (Log Data Area). According to the structure definition of the log storage area, the MCU unit formats the header of the log storage area, mainly resetting the initial value of the log storage area, and assigning values ​​to parameters such as the data block ID used by the CPU unit during this startup and the CurrentTimestamp.

[0054] During this process, the entire log storage area of ​​the Standby RAM is initialized. The MCU unit needs to calculate and assign a value to the MPU Run Count, which is used as the count of soft resets of the entire MPU unit, to identify the number of soft resets of the MPU unit after the entire ECU controller is powered on.

[0055] (2) The data structure of the MCU unit initialization log storage area is a circular chain sequence (Setup LogBlockRing). The log storage adopts a circular linked list-based data structure. All data blocks in the data structure can be traversed through the head and tail pointing links, and the operation can continue after returning to the starting data block. This realizes real-time read and write operations with data cyclic coverage, so that the log information of the MPU unit software system can be completely collected. Based on the buffer depth of the log storage area, the data cyclic recording capability of multiple restart processes can be realized, as well as the function of historical saving and backtracking of the software system operation process.

[0056] After the MCU initializes the log storage area data structure, it specifies the ID of the currently used data block. Each time the MPU unit is started, it increments to the next data block. After reaching the end of the linked list, it jumps back to the data block at the head to continue using it. It also refreshes the CurrentTimestamp in real time and triggers the startup process of the MPU unit through the power management PM module. Figure 4 In this context, "Triggeractivation" means triggering the next execution phase.

[0057] The number of data blocks and the size of the node space need to be determined based on the actual device memory size, and evaluated according to the characteristics such as the standby RAM storage size and the software system's historical traceability requirements, in order to avoid the impact on the ECU and vehicle functions due to excessive storage occupation.

[0058] (3) The first stage of the MPU unit operation, BL2, mainly implements the basic initialization work of the MPU unit, including hardware such as DDR, clock and serial port, and loads and verifies the images of BL31\BL32\BL33 of the subsequent operation stages to the specified memory area of ​​DDR in sequence.

[0059] BL2 determines the currently used data block (Get LogBlock) based on the currently used data block ID field in the log storage area header, initializes the data block (init LogBlock), and fills the data structure in the node header. For each data block, the data structure is further subdivided according to different stages of the MPU unit software system, resulting in multiple data sub-blocks. For each data sub-block, the log information for that stage is encoded and stored using a bit-based method (Update Log). The value of each bit corresponds to a specific preset running node, achieving efficient space utilization.

[0060] Each time an MPU unit starts up, it uses a data block. By using a circular linked list, log information for each MPU unit startup and operation process can be saved.

[0061] (4) After BL2 is completed, the control of the MPU unit is transferred to BL31, BL32 and BL33. The three stages of BL31, BL32 and BL33 are the intermediate operation stages of the software system. The log information of each function operation of the software in each stage is stored in the corresponding position of the corresponding data sub-block to complete the log collection of this stage. This process also includes the process of determining the data block to be used (Get LogBlock) and encoding data (Update Log).

[0062] (5) After the Linux operating system kernel starts, it will perform operating system initialization and driver loading. At this time, it will record the kernel's start time, the loading status of various driver modules, and the results of functional operations. The kernel executes the init script, mounts the file system, initializes the system environment, and starts the system service systemd process. This process also includes determining the data block to be used (Get LogBlock) and encoding data (Updata Log). The results of each operation and the abnormal status that occurs are marked and stored in the corresponding position of the data sub-block.

[0063] (6) After the Linux systemd system service starts, the parallel multi-system services begin to provide various business functions. During this process, until the journald service is started, all system services fill the corresponding data sub-blocks with the log information of the marked points because the operating system's log service is not yet ready. This process also includes determining the data block to use (Get LogBlock) and encoding the data (Update Log).

[0064] (7) After the journald service of Systemd starts, the journal service can capture and record the exception information to the log file of the file system, and successfully link with eMMC to complete persistent storage; at this time, the system service starts to serialize the data of the log storage area of ​​Standby RAM to DDR, generate formatted visualization data, and store the visualization data in the log file of eMMC (Save_Log_To_eMMC).

[0065] In (3)-(7) above, the corresponding log data area is operated for different software operation stages.

[0066] (8) During the shutdown phase, the Linux operating system will unload the file system. After the file system is unloaded, the system service will save the process information that cannot be stored in the file system to the standby RAM by operating the data blocks currently used by the standby RAM, so that the log information can be persistently saved after the next boot.

[0067] (9) The MCU unit monitors the log information of the Standby RAM through real-time monitoring tasks, obtains the log information currently being recorded, parses the encoding of the written log information, and analyzes the log information of each software system running node; if an abnormal result is found, it initiates the process of reporting abnormal information to external systems such as the cloud platform in real time, thereby realizing the real-time detection of faults in the MPU unit software system.

[0068] (10) Each time the MPU unit restarts independently, it increments to the next data block. At this time, the data block ID variable is incremented. When the data block ID reaches the last node of the linked list, it is moved to the head node of the linked list and used for circular polling traversal. It continues to use the data storage from the beginning.

[0069] As can be seen, during the operation of the MPU unit, through efficient and concise data encoding, the running nodes of different software stages are recorded in the data fields of the Steadby RAM area using bit encoding. The abnormal information of the running nodes (critical functional nodes or other software running processes) of each software running stage is collected and controlled by a log collection interactive strategy of relaying data through multiple storage media and linked list circular data storage. This realizes a complete log information chain across stages of the entire software system. The persistent storage function of log information is achieved through data relay dumping through multiple storage media. At the same time, with the help of the real-time status monitoring of the MCU unit, the functions of real-time reporting and external transmission of abnormal states and faults of the software system are realized. This ensures the integrity of the MPU's software system log information, the timeliness of fault detection, and effectively guarantees the real-time performance, reliability, and stability of ECU products such as vehicle ECUs.

[0070] It should be noted that by storing the start and end timestamps of each stage of the software system's operation, the time consumed by each software stage can be calculated to locate the system's performance indicators and ensure the system's reliability.

[0071] In addition, the use of a ring-based multi-round MPU software system for log storage during startup and operation can ensure the integrity of historical data when external problems occur, and ensure the traceability of the root cause of the problem after a failure, thereby enhancing the availability and maintainability of the system to a certain extent.

[0072] Example 3 In one embodiment, an ECU unit is provided, the ECU unit including an MPU unit; After the MPU unit starts, the target data block ID corresponding to this MPU unit startup is determined from the circular data linked list. The circular data linked list includes multiple data block IDs that are logically connected in a ring. The data blocks corresponding to different data block IDs are used to store log information corresponding to different startup rounds of the MPU unit. The log information of the MPU unit after this startup is stored in the data block corresponding to the target data block ID.

[0073] It should be noted that the relevant descriptions in this ECU unit embodiment can be referred to the relevant descriptions in the aforementioned Embodiment 1 or 2, and will not be repeated here.

[0074] It is worth noting that, in one embodiment, the electronic control unit further includes an MCU unit: The MCU unit monitors the encoded data in the data block corresponding to the target data block ID in real time; When the MCU unit detects an anomaly in real time, it triggers a fault alarm process. The fault alarm process includes: re-encoding the abnormal encoded data into log information and reporting the abnormal log information to an external system.

[0075] In this embodiment, after initializing the first volatile storage unit, the MCU unit can start a real-time log monitoring task. For example, it can set parameters such as the monitoring period to monitor the encoded data of the currently used data blocks in the log storage area in real time, thereby achieving log monitoring. Through the real-time log monitoring task, the MCU unit reads the data blocks currently in use to analyze the current operating phase of the software system and the operational results of each functional node in that phase. For any illegal state or abnormal result recorded by any operating node, it locates the specific operating node position and the related business module, thereby identifying the currently running business functional module and the logical location of the failure, ensuring the overall availability and maintainability of the MPU unit's software system.

[0076] For example, when the MPU unit is running the BL2 stage, the MCU unit monitors and reads the encoded data of the corresponding data block, de-encodes any abnormal encoded data into log information, and reports the abnormal log information to an external system, such as a cloud platform. Monitoring in other stages is similar, and will not be illustrated here.

[0077] In this embodiment, based on the interconnectivity of the first volatile storage unit as a bridge, the MCU can monitor the log information of this first volatile storage unit in real time to detect anomalies in the log information and report faults to the external system (cloud platform) in real time, thereby achieving real-time and rapid fault detection and facilitating problem localization. This improves overall reliability.

[0078] Example 4 In one embodiment, a vehicle is provided, characterized in that the vehicle includes an electronic control unit as mentioned in the embodiments, or an MPU unit of the vehicle for implementing the method of any of the foregoing log storage methods.

[0079] It should be noted that, in addition to vehicles, it can also be other devices that apply the electronic control unit of the embodiments of this application, and there is no specific limitation.

[0080] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in any of the foregoing embodiments.

[0081] In this application, "multiple" refers to two or more.

[0082] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0083] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if any) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0084] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0085] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if a method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if a method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0086] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for storing logs, characterized in that, include: After the microcomputing unit (MPU) is started, the target data block ID corresponding to the start of this MPU unit is determined from the circular data list. The circular data list includes multiple data block IDs that are logically connected in a ring. The data blocks corresponding to different data block IDs are used to store log information corresponding to different start rounds of the MPU unit. The log information of the MPU unit after this startup is stored in the data block corresponding to the target data block ID.

2. The method according to claim 1, characterized in that, The software system operation phase of the MPU unit software system includes a boot initialization phase and an operating system operation phase that run sequentially; storing the log information of the MPU unit after this startup into the data block corresponding to the target data block ID includes: Before the log service is started during the operating system's runtime phase, the log information of the software system is encoded and stored in the data block corresponding to the target data block ID in the first volatile storage unit; After the log service is started, the log service decodes the encoded data in the data block corresponding to the target data block ID to extract the log information, stores the decoded log information in the second volatile storage unit, and transfers the decoded log information to the non-volatile storage unit.

3. The method according to claim 2, characterized in that, The data block corresponding to the target data block ID includes multiple data sub-blocks. Different data sub-blocks are used to store log information corresponding to different running stages before the log service of the software system starts. Encoding and storing the log information of the software system into the data block corresponding to the target data block ID in the first volatile storage unit includes: Log information corresponding to different running stages before the log service of the software system is started is encoded and stored in different data sub-blocks.

4. The electronic control unit according to claim 3, characterized in that, The step of encoding and storing log information corresponding to different running stages before the log service of the software system is started into different data sub-blocks includes: Before the log service starts, when it reaches a preset running node at a different running stage, the corresponding storage bits of different data sub-blocks corresponding to the running node are set from the initial value to the target value to identify the running status of the running node.

5. The method according to claim 2, characterized in that, The method further includes: After the system service unloads the file system of the non-volatile storage unit during the operating system's runtime phase, the MPU unit stores log information that cannot be stored in the file system into the first volatile storage unit through the system service.

6. The method according to claim 2, characterized in that, The step of storing the decoded log information to the second volatile storage unit and transferring the decoded log information to the non-volatile storage unit includes: The decoded log information is serialized, and the serialized log information is stored in the second volatile storage unit and then transferred to the non-volatile storage unit.

7. An electronic control unit, characterized in that, The electronic control unit includes an MPU unit; After the MPU unit is started, the target data block ID corresponding to the start of this MPU unit is determined from the circular data list. The circular data list includes multiple data block IDs that are logically connected in a circular manner. The data blocks corresponding to different data block IDs are used to store log information corresponding to different start rounds of the MPU unit. The log information of the MPU unit after this startup is stored in the data block corresponding to the target data block ID.

8. The electronic control unit according to claim 7, characterized in that, The electronic control unit also includes an MCU unit: The MCU unit monitors the encoded data in the data block corresponding to the target data block ID in real time; When the MCU unit detects an anomaly in real time, it triggers a fault alarm process, which includes: decoding the abnormal encoded data into log information and reporting the abnormal log information to an external system.

9. A vehicle, characterized in that, The vehicle includes an electronic control unit as described in claims 7-8, or the vehicle's MPU unit is used to implement the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images