Log storage method based on vehicle MCU and related equipment

Abstract

The invention discloses a log storage method based on a vehicle machine MCU and related equipment, and relates to the technical field of data processing, and the method comprises the steps: responding to a log storage instruction, obtaining multi-source log data, based on a preset heartbeat mechanism, checking the working state of an SOC, the heartbeat mechanism is constructed based on the SOC and the MCU, and if the working state is normal, the multi-source log data is stored in the multi-source log data, and if the working state is normal, the multi-source log data is stored in the multi-source log data; sending the multi-source log data to the SOC, so that the SOC executes a data storage operation; and if the working state is abnormal, storing the multi-source log data in an EEP space of the MCU. Based on the characteristics of high capacity of the SOC and good stability of the MCU, the data is preferentially stored in the SOC, and further, by combining with a heartbeat mechanism, when the SOC works abnormally or is unstable, the storage path is dynamically adjusted, so that all log data can be completely and stably stored.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a log storage method and related equipment based on an in-vehicle MCU. Background Technology

[0002] In the context of automotive intelligence and connectivity, the in-vehicle infotainment system (IVS), as a core component of the cockpit, is becoming increasingly complex, leading to higher requirements for system stability and log management. Traditional IVS MCU log management suffers from drawbacks such as high resource consumption and difficulty in accurate location. When the IVS system malfunctions, especially when the SOC (System-on-a-Chip) fails, the MCU's own logging capabilities are limited, making it difficult to comprehensively record the system status. This results in difficult and inefficient troubleshooting, affecting the stable operation of the IVS system and subsequent optimization and improvement.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is related technology. Summary of the Invention

[0004] The main purpose of this application is to provide a log storage method and related equipment based on vehicle MCU, aiming to solve the technical problem of how to stably store logs.

[0005] To achieve the above objectives, this application proposes a log storage method based on an in-vehicle MCU, the log storage method based on an in-vehicle MCU comprising: Retrieve log data from multiple sources in response to log storage commands; The operating status of the SOC is checked based on a pre-set heartbeat mechanism, which is built based on the SOC and the MCU. If the operating status is normal, the multi-source log data is sent to the SOC for the SOC to perform data storage operations; if the operating status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0006] In one embodiment, the step of acquiring multi-source log data further includes: Data from various control modules in the vehicle is acquired to obtain multi-source data. Multi-source log data is generated based on the preset log data generation strategy and the multi-source data.

[0007] In one embodiment, the step of generating multi-source log data based on a preset log data generation strategy and the multi-source data further includes: Based on a preset log data generation strategy, a classification operation is performed on multiple sets of data from the multi-source data to obtain multiple sets of classification results. Based on the classification results, a classification label is assigned to each group of data in the multi-source data. Based on the classification labels, multi-source log data is constructed.

[0008] In one embodiment, after the step of storing the multi-source log data in the EEP space of the MCU if the operating state is abnormal, the method further includes: Real-time monitoring of the SOC's operating status; When the SOC's working state changes from abnormal to normal, the multi-source log data stored in the EEP space is sent to the SOC for the SOC to perform data storage operations.

[0009] In one embodiment, after the step of sending the multi-source log data to the SOC if the working state is normal, so that the SOC can perform data storage operations, the method further includes: In response to log analysis commands, read multi-source log data from the SOC; Based on a preset log data generation strategy, the multi-source log data is parsed to determine the vehicle data corresponding to the multi-source log data; Based on a preset log parsing strategy, the vehicle data is parsed to obtain the log data parsing results.

[0010] In one embodiment, the step of parsing the multi-source log data based on a preset log data generation strategy to determine the vehicle data corresponding to the multi-source log data further includes: Based on a preset log data generation strategy, the mapping relationship between the multi-source log data and vehicle data is determined; Based on the mapping relationship, the vehicle data corresponding to the multi-source log data is determined.

[0011] Furthermore, to achieve the above objectives, this application also proposes a log storage device based on an in-vehicle MCU, the log storage device based on the in-vehicle MCU comprising: The acquisition module is used to acquire multi-source log data in response to a log storage command; The inspection module is used to inspect the working status of the SOC based on a pre-set heartbeat mechanism, which is built based on the SOC and the MCU. A storage module is configured to send the multi-source log data to the SOC when the operating state is normal, so that the SOC can perform data storage operations; and to store the multi-source log data in the EEP space of the MCU when the operating state is abnormal.

[0012] In one embodiment, the acquisition module further includes: The acquisition unit is used to acquire data from various control modules in the vehicle to obtain multi-source data. The generation unit is used to generate multi-source log data based on a preset log data generation strategy and the multi-source data.

[0013] In one embodiment, the acquisition module further includes: The classification unit is used to perform classification operations on multiple sets of data in the multi-source data based on a preset log data generation strategy, and obtain multiple sets of classification results. A setting unit is used to set classification labels for each group of data in the multi-source data based on the classification results; The construction unit is used to construct multi-source log data based on the classification labels.

[0014] In one embodiment, the log storage device based on the vehicle MCU further includes a data migration module, which further includes: The detection unit is used to detect the working status of the SOC in real time; The sending unit is used to send the multi-source log data stored in the EEP space to the SOC when the working state of the SOC changes from abnormal to normal, so that the SOC can perform data storage operations.

[0015] In one embodiment, the log storage device based on the vehicle MCU further includes a data parsing module, which further includes: The reading unit is used to read multi-source log data from the SOC in response to log analysis commands; The first parsing unit is used to parse the multi-source log data based on a preset log data generation strategy to determine the vehicle data corresponding to the multi-source log data. The second parsing unit is used to parse the vehicle data based on a preset log parsing strategy to obtain log data parsing results.

[0016] In one embodiment, the data parsing module further includes: The first determining unit is used to determine the mapping relationship between the multi-source log data and the vehicle data based on a preset log data generation strategy; The second determining unit is used to determine the vehicle data corresponding to the multi-source log data based on the mapping relationship.

[0017] In addition, to achieve the above objectives, this application also proposes a log storage device based on an in-vehicle MCU, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the log storage method based on the in-vehicle MCU as described above.

[0018] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the log storage method based on the vehicle MCU as described above.

[0019] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the log storage method based on the vehicle MCU as described above.

[0020] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a log storage method and related equipment based on an in-vehicle MCU, relating to the field of data processing technology. Compared to related technologies, traditional in-vehicle MCU log management suffers from drawbacks such as high resource consumption and difficulty in accurate location. When the in-vehicle system malfunctions, especially when the SOC (System-on-a-Chip) fails, the MCU's own logging capabilities are limited, making it difficult to comprehensively record the system status. This leads to difficulties in troubleshooting, low efficiency, and affects the stable operation of the in-vehicle system and subsequent optimization and improvement. In contrast, this application first responds to a log storage command by acquiring multi-source log data. Then, based on a pre-set heartbeat mechanism, the working status of the SOC is checked. This heartbeat mechanism is built upon the SOC and the MCU. Finally, if the working status is normal, the multi-source log data is sent to the SOC for data storage operations; if the working status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0021] Understandably, this application prioritizes storing data in the SOC, taking advantage of the large capacity of the SOC and the good stability of the MCU. Furthermore, by combining a heartbeat mechanism, the storage path is dynamically adjusted when the SOC malfunctions or becomes unstable, so that all log data can be stored completely and stably. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1This is a flowchart illustrating an embodiment of the log storage method based on an in-vehicle MCU in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the log storage method based on the vehicle MCU of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the log storage method based on the vehicle MCU of this application; Figure 4 This is a schematic diagram of the module structure of the log storage device based on the vehicle MCU in an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the log storage method based on the vehicle MCU in the embodiments of this application.

[0025] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] The main solution in this application embodiment is: In this embodiment, for ease of description, the following description will focus on the log storage device based on the vehicle's MCU.

[0029] Due to limitations in related technologies, traditional in-vehicle MCU log management suffers from high resource consumption and difficulty in accurately locating faults. When the in-vehicle system malfunctions, especially when the SOC (System-on-a-Chip) fails, the MCU's own logging capabilities are limited, making it difficult to comprehensively record the system status. This leads to difficulties in troubleshooting, low efficiency, and impacts the stable operation of the in-vehicle system and subsequent optimization and improvement.

[0030] This application provides a solution in which: first, in response to a log storage instruction, multi-source log data is acquired; then, based on a pre-set heartbeat mechanism, the operating status of the SOC is checked, the heartbeat mechanism being built upon the SOC and the MCU; finally, if the operating status is normal, the multi-source log data is sent to the SOC for the SOC to perform data storage operations; if the operating status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0031] Understandably, this application prioritizes storing data in the SOC, taking advantage of the large capacity of the SOC and the good stability of the MCU. Furthermore, by combining a heartbeat mechanism, the storage path is dynamically adjusted when the SOC malfunctions or becomes unstable, so that all log data can be stored completely and stably.

[0032] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a log storage device based on an in-vehicle MCU. The following description uses a log storage device based on an in-vehicle MCU as an example to illustrate this embodiment and the subsequent embodiments.

[0033] Based on this, this application provides a log storage method based on a vehicle-mounted MCU, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the log storage method based on the vehicle MCU of this application.

[0034] In this embodiment, the log storage method based on the vehicle MCU includes steps S10~S30: Step S10: In response to the log storage instruction, obtain multi-source log data; In this embodiment, the system begins execution after receiving a specific instruction. Here, the "log storage instruction" is a trigger signal indicating that the system needs to start collecting and storing log data.

[0035] It should be noted that instructions can be transmitted to the system via software interfaces (such as APIs) or hardware signals (such as level changes on GPIO pins). Upon receiving the instruction, the system will activate the log collection module.

[0036] After receiving instructions, log information is collected from multiple different data sources. These data sources can be different modules within the system or external devices. The sources of multi-source log data can be: Logs generated by internal system modules, such as hardware modules like CPU, GPU, memory, and sensors.

[0037] Software modules: Logs generated by operating systems, applications, middleware, etc.

[0038] External devices: such as servers connected via a network, other vehicle modules (such as ECUs), or external sensors.

[0039] Step S20: Based on a pre-set heartbeat mechanism, check the working status of the SOC. The heartbeat mechanism is built based on the SOC and the MCU. It's important to note that the heartbeat mechanism is essentially a "periodic handshake protocol." The sender (SOC) sends a short, fixed-format data frame (heartbeat packet) to the receiver (MCU) at fixed intervals. The receiver (MCU) must receive this frame within an agreed-upon time window and immediately acknowledge it (either implicitly or explicitly). If no heartbeat is received for N consecutive cycles, it is considered a "heartbeat loss," indicating a malfunction of the SOC.

[0040] It should be noted that the heartbeat link is directly connected to the physical channel between the SOC and the MCU (such as UART, SPI, shared memory Mailbox, GPIO toggling, etc.) and does not rely on an external network. The protocol stack runs on the Linux / Android side of the SOC and the RTOS / bare metal side of the MCU, respectively.

[0041] It should be noted that the MCU judges whether the system is frozen (no heartbeat at all), whether it is stuck (period exceeds tolerance), or whether it is out of control (frame header / verification error) through three dimensions: presence or absence of heartbeat, period jitter, and frame content legality.

[0042] Understandably, once a signal is interrupted or abnormal, it is immediately recorded and a protective action is triggered, thus forming a reliable, low-cost, and auditable data storage path in the complex vehicle system.

[0043] Step S30: If the working state is normal, the multi-source log data is sent to the SOC for the SOC to perform data storage operation; if the working state is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0044] Understandably, the current working status of the SOC has already been determined through a heartbeat mechanism in the previous steps. If the heartbeat arrives on time and its content is correct, it indicates that the working status is normal; if the heartbeat is lost / times out / the content is incorrect, it indicates that the working status is abnormal.

[0045] If the operating status is normal, the MCU will package and upload all logs collected in this round (power status, task timeout bit, temperature, voltage, etc.) via SPI / UART / shared memory.

[0046] It's worth noting that the SOC side has a Linux / Android file system, which offers large capacity and high speed. Logs can be written to eMMC / UFS, and even compressed before being uploaded to the cloud. Its advantages include ample storage space, convenient retrieval, and support for subsequent big data analysis.

[0047] If the operating status is abnormal, and the SOC is either dead or restarting and unable to receive data, the MCU immediately switches to "self-rescue mode": it writes the log to the on-chip EEPROM / Data-Flash (typically in the 4kB~32kB range, which is not lost even after power failure). After the log is full, it cyclically overwrites the oldest record, ensuring that the "last piece of critical information before the failure" is always preserved. Its advantages are: it is completely independent of the SOC, and 100% of the abnormal situation is preserved; staff can simply read the EEPROM log via CAN or USB flash drive commands to locate the root cause.

[0048] Specifically, after the step of storing the multi-source log data in the EEP space of the MCU if the working state is abnormal, the method further includes steps S40~S50: Step S40: Real-time detection of the operating status of the SOC; Step S50: When the working state of the SOC changes from abnormal to normal, the multi-source log data stored in the EEP space is sent to the SOC so that the SOC can perform data storage operations.

[0049] In this embodiment, the MCU continuously monitors the SOC's operating status. Once the SOC's operating status returns to normal, the MCU packages all the abnormal situation logs (power supply, task timeout, temperature, reset reason, etc. at the last moment before the crash) that were previously saved to the EEPROM. This is then sent back to the newly recovered SOC via SPI / UART / shared memory. Upon receiving this, the SOC writes these logs to the eMMC / UFS as if it were in normal operation, or even uploads them to the cloud. The local EEPROM is marked as "data migrated back" and can continue to be used cyclically.

[0050] Understandably, this method ensures that the black box (EEPROM) data during a system crash is ultimately returned to the large database, thus ensuring that there is no lack of log data and that the MCU's valuable EEPROM space is not wasted.

[0051] Understandably, in this embodiment, if the SOC is normal, the "big data center" stores the logs; if the SOC fails, the MCU immediately locks the logs into its own "black box" to ensure that it can obtain the data from the accident site no matter what.

[0052] This application proposes a log storage method and related equipment based on an in-vehicle MCU, relating to the field of data processing technology. Compared to related technologies, traditional in-vehicle MCU log management suffers from drawbacks such as high resource consumption and difficulty in accurate location. When the in-vehicle system malfunctions, especially when the SOC (System-on-a-Chip) fails, the MCU's own logging capabilities are limited, making it difficult to comprehensively record the system status. This leads to difficulties in troubleshooting, low efficiency, and affects the stable operation of the in-vehicle system and subsequent optimization and improvement. In contrast, this application first responds to a log storage command by acquiring multi-source log data. Then, based on a pre-set heartbeat mechanism, the working status of the SOC is checked. This heartbeat mechanism is built upon the SOC and the MCU. Finally, if the working status is normal, the multi-source log data is sent to the SOC for data storage operations; if the working status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0053] Understandably, this application prioritizes storing data in the SOC, taking advantage of the large capacity of the SOC and the good stability of the MCU. Furthermore, by combining a heartbeat mechanism, the storage path is dynamically adjusted when the SOC malfunctions or becomes unstable, so that all log data can be stored completely and stably.

[0054] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The step of obtaining multi-source log data further includes steps A100 to A200: Step A100: Obtain data from various control modules in the vehicle to obtain multi-source data; It should be noted that "multi-source" refers to: MCU, SOC, BMS, EPS, ADAS, T-Box, air conditioning controller, gateway, etc. Data types include: voltage, temperature, task cycle, heartbeat status, CAN messages, fault codes, and sensor sample values. Ultimately, a raw, real-time, and complete "raw data" cache is obtained.

[0055] Step A200: Generate multi-source log data based on the preset log data generation strategy and the multi-source data.

[0056] It should be noted that the preset log data generation strategy is a set of predefined rules or templates that tell the system "what data to record, how to record it, and in what format".

[0057] Multi-source data refers to data from different systems, devices, or platforms, such as server logs, sensor data, and user operation records.

[0058] In this embodiment, data from different sources are formatted and integrated into a standardized log according to preset rules.

[0059] Specifically, the step of generating multi-source log data based on the preset log data generation strategy and the multi-source data further includes steps A210 to A230: Step A210: Based on a preset log data generation strategy, perform classification operations on multiple sets of data in the multi-source data to obtain multiple sets of classification results; It should be noted that the preset log data generation strategy is a "blueprint" that specifies the classification rules. In this embodiment, raw records from different sources and with different formats are broken down into the smallest independently processable units: "groups".

[0060] Step A220: Based on the classification results, assign classification labels to each group of data in the multi-source data; In this embodiment, the classification result obtained in step A210 is converted into a readable, structured "label". The label can contain two levels of "major category - subcategory" or additional semantic fields. For example, if the detected power supply voltage is 5V, the voltage is labeled as U, and the data with voltage in the range of 4-6V is labeled as 1. The final classification label is U1.

[0061] Step A230: Construct multi-source log data based on the classification labels.

[0062] In this embodiment, after obtaining the tags, the tags are concatenated to obtain concise log data, i.e., multi-source log data. Its advantages are: using tags to represent classification results reduces data resource consumption. For example, the original data is "battery voltage is 5V," which in this application can be directly represented by "U1," reducing resource consumption and storage costs; the same storage space can store more log data.

[0063] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After the step of sending the multi-source log data to the SOC for data storage operation if the working state is normal, the system further includes steps B100~B300: Step B100: In response to the log analysis command, read the multi-source log data in the SOC; In this embodiment, the log analysis command is an external trigger signal, which may be the UDS0x19 service sent by the diagnostic instrument, the diagnostic task sent by the OTA cloud, or the expiration of the vehicle's self-test timer.

[0064] It should be noted that multi-source logs in a System-On-Chip (SOC) are generally stored in the / var / log / partition of eMMC / ufs or a dedicated NVM log buffer, containing kernel dmesg, Android logcat, CAN message logs uploaded by the MCU via SPI, and debug frame metadata output by the camera / LiDAR driver.

[0065] It should also be noted that multi-source logs refer to multi-source log data obtained after high-level simplification.

[0066] In this embodiment, after receiving the log analysis command, the multi-source log data in the SOC is read to prepare for the next step of processing.

[0067] Step B200: Based on a preset log data generation strategy, the multi-source log data is parsed to determine the vehicle data corresponding to the multi-source log data; In this embodiment, the simplified multi-source log data is converted into ordinary statement descriptions, thereby determining the vehicle data corresponding to the multi-source log data. For example, if the multi-source log data records "U1", then it can be determined that "the battery voltage is 4-6V".

[0068] Specifically, the step of parsing the multi-source log data based on a preset log data generation strategy to determine the vehicle data corresponding to the multi-source log data further includes steps B210 to B220: Step B210: Based on a preset log data generation strategy, determine the mapping relationship between the multi-source log data and vehicle data; Within the device itself, the mapping relationship between the multi-source log data and vehicle data is determined according to the preset log data generation strategy. For example, during the process of generating log data, if the power supply voltage is detected to be 5V, the voltage is marked as U, and the data with voltage in the range of 4-6V is marked as 1. The final classification label is U1, that is, voltage corresponds to "U", and voltage 4-6V corresponds to "1".

[0069] Step B220: Based on the mapping relationship, determine the vehicle data corresponding to the multi-source log data.

[0070] In this embodiment, the original vehicle data corresponding to the multi-source log data is deduced based on the mapping relationship determined in step B210. For example, voltage corresponds to "U", and voltage 4-6V corresponds to "1". If the log data is "U1", it means "battery voltage is 4-6V".

[0071] Step B300: Based on a preset log parsing strategy, the vehicle data is parsed to obtain the log data parsing result.

[0072] It should be noted that the preset log parsing strategy refers to the pre-defined logic for judging abnormal vehicle data.

[0073] In this embodiment, after obtaining the vehicle data, the log data parsing result is finally obtained based on the vehicle data anomaly judgment logic, that is, the data anomaly judgment result is obtained.

[0074] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the log storage method based on the vehicle MCU. Any simple modifications based on this technical concept are within the protection scope of this application.

[0075] It should be noted that all user-related data involved in this application (such as user attribute data, user behavior data, and user geographical location, etc., the data types here should be modified according to the adaptability of the solution content) were obtained with the user's permission or consent; that is to say, when this application is applied to specific products or technologies, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0076] For example, when it is necessary to obtain a user's current geographical location, a location acquisition prompt can be displayed on the user's terminal. After receiving confirmation from the user regarding the location acquisition prompt, the terminal can obtain the user's current geographical location.

[0077] This application also provides a log storage device based on an in-vehicle MCU, please refer to... Figure 4 The log storage device based on the vehicle MCU includes: Acquisition module 10, the acquisition module is used to acquire multi-source log data in response to log storage instructions; Inspection module 20, the inspection module is used to inspect the working status of SOC based on a pre-set heartbeat mechanism, the heartbeat mechanism is built based on SOC and MCU; Storage module 30 is used to send the multi-source log data to the SOC when the working state is normal, so that the SOC can perform data storage operations; and to store the multi-source log data in the EEP space of the MCU when the working state is abnormal.

[0078] In one embodiment, the acquisition module further includes: The acquisition unit is used to acquire data from various control modules in the vehicle to obtain multi-source data. The generation unit is used to generate multi-source log data based on a preset log data generation strategy and the multi-source data.

[0079] In one embodiment, the acquisition module further includes: The classification unit is used to perform classification operations on multiple sets of data in the multi-source data based on a preset log data generation strategy, and obtain multiple sets of classification results. A setting unit is used to set classification labels for each group of data in the multi-source data based on the classification results; The construction unit is used to construct multi-source log data based on the classification labels.

[0080] In one embodiment, the log storage device based on the vehicle MCU further includes a data migration module, which further includes: The detection unit is used to detect the working status of the SOC in real time; The sending unit is used to send the multi-source log data stored in the EEP space to the SOC when the working state of the SOC changes from abnormal to normal, so that the SOC can perform data storage operations.

[0081] In one embodiment, the log storage device based on the vehicle MCU further includes a data parsing module, which further includes: The reading unit is used to read multi-source log data from the SOC in response to log analysis commands; The first parsing unit is used to parse the multi-source log data based on a preset log data generation strategy to determine the vehicle data corresponding to the multi-source log data. The second parsing unit is used to parse the vehicle data based on a preset log parsing strategy to obtain log data parsing results.

[0082] In one embodiment, the data parsing module further includes: The first determining unit is used to determine the mapping relationship between the multi-source log data and the vehicle data based on a preset log data generation strategy; The second determining unit is used to determine the vehicle data corresponding to the multi-source log data based on the mapping relationship.

[0083] The log storage device based on a vehicle-mounted MCU provided in this application, employing the log storage method based on a vehicle-mounted MCU in the above embodiments, can solve the technical problems of log storage based on a vehicle-mounted MCU. Compared with related technologies, the beneficial effects of the log storage device based on a vehicle-mounted MCU provided in this application are the same as those of the log storage method based on a vehicle-mounted MCU provided in the above embodiments, and other technical features in the log storage device based on a vehicle-mounted MCU are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0084] This application provides a log storage device based on a vehicle-mounted MCU. The log storage device based on a vehicle-mounted MCU includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the log storage method based on the vehicle-mounted MCU in the above embodiment 1.

[0085] The following is for reference. Figure 5 This document illustrates a structural schematic diagram of a log storage device based on an in-vehicle MCU suitable for implementing embodiments of this application. The log storage device based on an in-vehicle MCU in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The log storage device based on the vehicle MCU shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 5As shown, the log storage device based on the vehicle-mounted MCU may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the log storage device based on the vehicle-mounted MCU. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the vehicle-mounted MCU-based log storage device to wirelessly or wiredly communicate with other devices to exchange data. Although the figure shows a vehicle-mounted MCU-based log storage device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0087] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0088] The log storage device based on a vehicle-mounted MCU provided in this application solves the technical problem by employing the log storage method based on a vehicle-mounted MCU in the above embodiments. Compared with related technologies, the beneficial effects of the log storage device based on a vehicle-mounted MCU provided in this application are the same as those of the log storage method based on a vehicle-mounted MCU provided in the above embodiments, and other technical features of this log storage device based on a vehicle-mounted MCU are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0091] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the log storage method based on the vehicle MCU in the above embodiments.

[0092] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having 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 fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0093] The aforementioned computer-readable storage medium may be included in a log storage device based on an in-vehicle MCU; or it may exist independently and not be installed in a log storage device based on an in-vehicle MCU.

[0094] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the vehicle-mounted MCU-based log storage device, cause the vehicle-mounted MCU-based log storage device to: Retrieve log data from multiple sources in response to log storage commands; The operating status of the SOC is checked based on a pre-set heartbeat mechanism, which is built based on the SOC and the MCU. If the operating status is normal, the multi-source log data is sent to the SOC for the SOC to perform data storage operations; if the operating status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

[0095] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0098] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described log storage method based on a vehicle-mounted MCU, thereby solving the technical problem of log storage based on a vehicle-mounted MCU. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the log storage method based on a vehicle-mounted MCU provided in the above embodiments, and will not be repeated here.

[0099] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the log storage method based on the vehicle MCU described above.

[0100] The computer program product provided in this application can solve the technical problem of log storage based on vehicle-mounted MCU. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the log storage method based on vehicle-mounted MCU provided in the above embodiments, and will not be repeated here.

[0101] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A log storage method based on a vehicle-mounted MCU, characterized in that, Applied to in-vehicle infotainment MCUs, the log storage method based on in-vehicle infotainment MCUs includes: Retrieve log data from multiple sources in response to log storage commands; The operating status of the SOC is checked based on a pre-set heartbeat mechanism, which is built based on the SOC and the MCU. If the operating status is normal, the multi-source log data is sent to the SOC for the SOC to perform data storage operations; if the operating status is abnormal, the multi-source log data is stored in the EEP space of the MCU.

2. The log storage method based on the vehicle MCU as described in claim 1, characterized in that, The step of obtaining multi-source log data also includes: Data from various control modules in the vehicle is acquired to obtain multi-source data. Multi-source log data is generated based on the preset log data generation strategy and the multi-source data.

3. The log storage method based on the vehicle MCU as described in claim 2, characterized in that, The step of generating multi-source log data based on a preset log data generation strategy and the multi-source data further includes: Based on a preset log data generation strategy, a classification operation is performed on multiple sets of data from the multi-source data to obtain multiple sets of classification results. Based on the classification results, a classification label is assigned to each group of data in the multi-source data. Based on the classification labels, multi-source log data is constructed.

4. The log storage method based on the vehicle MCU as described in claim 1, characterized in that, After the step of storing the multi-source log data in the EEP space of the MCU if the working state is abnormal, the method further includes: Real-time monitoring of the SOC's operating status; When the SOC's working state changes from abnormal to normal, the multi-source log data stored in the EEP space is sent to the SOC for the SOC to perform data storage operations.

5. The log storage method based on the vehicle MCU as described in claim 1, characterized in that, After the step of sending the multi-source log data to the SOC for the SOC to perform data storage operations if the working state is normal, the method further includes: In response to log analysis commands, read multi-source log data from the SOC; Based on a preset log data generation strategy, the multi-source log data is parsed to determine the vehicle data corresponding to the multi-source log data; Based on a preset log parsing strategy, the vehicle data is parsed to obtain the log data parsing results.

6. The log storage method based on the vehicle MCU as described in claim 5, characterized in that, The step of parsing the multi-source log data based on a preset log data generation strategy to determine the vehicle data corresponding to the multi-source log data further includes: Based on a preset log data generation strategy, the mapping relationship between the multi-source log data and vehicle data is determined; Based on the mapping relationship, the vehicle data corresponding to the multi-source log data is determined.

7. A log storage device based on a vehicle-mounted MCU, characterized in that, The log storage device based on the vehicle MCU includes: The acquisition module is used to acquire multi-source log data in response to a log storage command; The inspection module is used to inspect the working status of the SOC based on a pre-set heartbeat mechanism, which is built based on the SOC and the MCU. A storage module is configured to send the multi-source log data to the SOC when the operating state is normal, so that the SOC can perform data storage operations; and to store the multi-source log data in the EEP space of the MCU when the operating state is abnormal.

8. A log storage device based on an in-vehicle MCU, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the log storage method based on the vehicle MCU as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the log storage method based on the vehicle MCU as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the log storage method based on the vehicle MCU as described in any one of claims 1 to 6.

Images