Abnormity recording method of vehicle, vehicle-mounted cabin system and storage medium

Abstract

The embodiment of the invention relates to a vehicle abnormity recording method, a vehicle-mounted cabin system and a storage medium, the vehicle abnormity recording method is applied to the vehicle-mounted cabin system, and the method comprises the steps that when an abnormal event occurs, abnormal event information is coded into an event frame through an SOC module, and the event frame is stored in a first storage unit; reading a system frame representing state information of the SOC module through the SOC module, compressing the system frame into a first state brief report and compressing the event frame into a second state brief report, and transmitting the first state brief report and the second state brief report to a microcontroller unit; storing the received first state brief report and the second state brief report in a second storage unit through the microcontroller unit; according to the invention, after the exception occurs, the exception information can be quickly recorded without occupying a large storage space and depending on the cloud.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of vehicle control, in particular to an abnormal recording method of a vehicle, a vehicle cabin system and a storage medium. BACKGROUND

[0002] As the core hub of the interaction between the driver and the vehicle, the underlying software of the vehicle cabin system covers the operating system kernel, the driver program, the middleware and other core components, therefore, the stability of the underlying software of the vehicle cabin system is directly related to the driving safety red line and the user core experience.

[0003] However, the existing analysis tools are difficult to efficiently locate the underlying software abnormality reason due to technical characteristics or technical defects, which are as follows: The LOG log system records the process state, function call, error code and other information in the running process of the underlying software in real time, providing a basis for problem tracing, but due to its large data volume, high UFS storage space occupation and untimely disk landing, it cannot record the log at the moment of death; Ramdump saves the full data in the DDR memory at the moment of system exception, which can theoretically restore the running state of the underlying software at the moment of exception, but due to its long time consumption of saving DDR full data, usually more than 20 minutes, and large space occupation, it cannot cover the sudden exception scene; The point system sets a point in the key module of the underlying software, collects the occurrence time, state code, execution result and other simplified data of the specific event, and then uploads them to the cloud for statistical analysis, which is designed to achieve lightweight monitoring, but also leads to less data, difficult to analyze complex problems, and dependence on cloud statistics.

[0004] In summary, when a sudden underlying software exception occurs, the existing tools cannot save the key information in time, resulting in many after-sales problems that cannot be solved due to lack of information, and occupying a large storage space, which cannot save effective key data at the moment of exception and relies on cloud statistics. SUMMARY In view of the above problems, the embodiments of the present application provide an abnormal recording method of a vehicle, a vehicle cabin system and a storage medium, which are used to solve the problems in the prior art that when a sudden underlying software exception occurs, the existing tools cannot save the key information in time, resulting in many after-sales problems that cannot be solved due to lack of information, and occupying a large storage space, which cannot save effective key data at the moment of exception and relies on cloud statistics.

[0005] According to one aspect of the embodiments of the present application, an abnormal recording method of a vehicle is provided, which is applied to a vehicle cabin system, and the method comprises: When an abnormal event occurs, the SOC module encodes the abnormal event information into an event frame, and stores the event frame into a first storage unit; The SOC module reads a system frame representing state information of the SOC module itself, and transmits the system frame compressed into a first state brief and the event frame compressed into a second state brief to a microcontroller unit; The microcontroller unit stores the received first state brief and second state brief into a second storage unit; When the SOC module is restarted, the microcontroller unit transmits the first state brief and second state brief stored in the second storage unit back to the SOC module, and the SOC module stores the first state brief and second state brief into a third storage unit.

[0006] In some optional embodiments, the system frame is obtained through the following sub-steps: The SOC module is called to collect state information of itself at a regular time; The state information collected each time is encoded into a system frame; The system frame is stored in the first storage unit.

[0007] In some optional embodiments, the following steps are further included: The SOC module is called to collect state information of itself at a regular time; The microcontroller unit stores the received first state brief into the second storage unit; When the SOC module is restarted, the microcontroller unit transmits the first state brief and second state brief stored in the second storage unit back to the SOC module, and the SOC module stores the first state brief and second state brief into a third storage unit.

[0008] In some optional embodiments, the abnormal event at least includes a program crash event, a driver abnormal event, and a preset operation event; The state information at least includes CPU state, memory state, driver state, power supply state, and temperature state.

[0009] In some optional embodiments, the event frame is stored in a region with a fixed starting address in the first storage unit; The system frame is stored in a region with a fixed starting address in the first storage unit.

[0010] According to another aspect of the example of the present application, a vehicle-mounted cabin system is provided, including a SOC module and a microcontroller unit; The SOC module comprises a core monitor, which is configured to encode an abnormal event information into an event frame when an abnormal event occurs, store the event frame into a first storage unit, read a system frame representing state information of the SOC module itself, compress the system frame into a first state brief and the event frame into a second state brief, and transmit the first state brief and the second state brief to a micro controller unit (MCU) through the SOC module; The micro controller unit is configured to store the received first state brief and second state brief into a second storage unit, and configured to transmit the first state brief and the second state brief stored in the second storage unit to the SOC module when the SOC module is restarted, and store the first state brief and the second state brief into a third storage unit through the SOC module.

[0011] In some optional embodiments, the core monitor comprises at least a system information collection subunit and an MCU communication subunit. The system information collection subunit is configured to receive the abnormal event information and collect state information of the SOC module at a fixed time interval. The MCU communication subunit is configured to compress the system frame into a first state brief and the event frame into a second state brief, and transmit the first state brief and the second state brief to the micro controller unit.

[0012] In some optional embodiments, the MCU communication subunit transmits the first state brief and the second state brief to the micro controller unit through a serial peripheral interface (SPI) interface.

[0013] In some optional embodiments, the first state brief comprises a message header, data content and a check code.

[0014] According to another aspect of the example of the present application, a storage medium is provided, wherein at least one executable instruction is stored in the storage medium, and the executable instruction, when executed on the in-vehicle cabin system as described above, causes the in-vehicle cabin system to perform the operations of the abnormal recording method of the vehicle as described above.

[0015] The present application provides an abnormal recording method of a vehicle, an in-vehicle cabin system and a storage medium, which have the following beneficial effects: This invention encodes abnormal event information into an event frame when an abnormal event occurs. The SOC module reads the system frame representing its own state information, compresses the system frame into a first state summary, and compresses the event frame into a second state summary before transmitting them to the microcontroller unit. The microcontroller unit stores the received first and second state summaries in a second storage unit, ensuring a 100% success rate. This effectively reduces the number of after-sales issues with no information to analyze, and the state summary occupies little storage space. The total time from abnormal triggering to microcontroller unit storage completion is less than 3 seconds. After an abnormality occurs in the vehicle cockpit system, the abnormality can be quickly recorded and the system reset, greatly reducing the impact of system abnormalities on user experience. When the SOC module restarts, the microcontroller unit sends the first and second state summaries stored in the second storage unit back to the SOC module, which then stores them in a third storage unit. This facilitates after-sales issue analysis without relying on cloud statistics, reducing bandwidth costs.

[0016] The above description is merely an overview of the technical solutions of this invention. In order to better understand the technical means of the embodiments of this invention, it can be implemented in accordance with the contents of the specification. Furthermore, in order to make the above and other objects, features and advantages of the embodiments of this invention more apparent and understandable, specific embodiments of this invention are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 The flowchart of the vehicle anomaly recording method provided in Embodiment 1 of the present invention Figure 1 ; Figure 2 This is a schematic diagram of the event frame format provided in Embodiment 1 of the present invention; Figure 3 This is a sub-step of step 200 provided in Embodiment 1 of the present invention; Figure 4 This is a schematic diagram of the system frame format provided in Embodiment 1 of the present invention; Figure 5 The flowchart of the vehicle anomaly recording method provided in Embodiment 1 of the present invention Figure 2 ; Figure 6 This is a system block diagram of the vehicle cockpit system provided in Embodiment 2 of the present invention; Figure 7 This is a schematic diagram of the format of the status briefing provided in Embodiment 2 of the present invention. Detailed Implementation

[0018] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Example 1: Figure 1 An embodiment of a vehicle anomaly recording method of the present invention is shown, applied to an in-vehicle cockpit system, the method comprising: 100. When an abnormal event occurs, the abnormal event information is encoded into an event frame by the SOC module, and the event frame is stored in the first storage unit.

[0020] The abnormal events referred to here are those occurring in modules other than the SOC module, such as driver exceptions or program crashes.

[0021] Specifically, for some peripheral drivers within the vehicle cockpit system, including drivers for cameras, microphones, and displays, when an abnormal event occurs in a peripheral driver, this abnormal event information is encoded into an event frame. For example, if the display fails to initialize, renders lags, displays malfunctions, or displays abnormal colors; or if the microphone experiences noise, audio stuttering, or volume malfunction, the abnormal event information is encoded into an event frame when these peripheral driver abnormal events occur.

[0022] Encoding abnormal event information into an event frame is a way to standardize and efficiently process abnormal data, addressing the core pain points of data transmission, storage, and analysis in vehicle scenarios, and facilitating the investigation and analysis of abnormal events.

[0023] After receiving abnormal event information from other modules, the SOC module performs redundancy removal, standardization, and parsable encoding processing on the abnormal event information to generate event frames suitable for storage and analysis. Redundancy removal involves eliminating duplicate and descriptive information, retaining only core data; standardization involves using a unified field structure and encoding rules to ensure consistent event frame format across different abnormal events; and parsability involves adding checks and identifiers to avoid data errors or parsing confusion.

[0024] After the SOC module encodes abnormal event information into event frames, it can also launch corresponding applications such as real-time response, hierarchical storage, and subsequent analysis. For example, the SOC module can trigger a corresponding response within a preset time according to the abnormality level field of the event frame; and perform hierarchical storage of event frames to ensure data security.

[0025] refer to Figure 2 , Figure 2 The format of an event frame is as follows, and the pseudocode for an event frame is as follows: "event_frame_header": { "frame_type": "1", "frame_size": "56", "prev_frame_offset": "0", "next_frame_offset": "112", "time_stamp": "Mon Aug 11 20:21:24 2025", "content_size": "24", } "event_frame_content": { "event_type": "DRIVER_ERROR", "error_code": "DISPLAY_LINK_ERROR", "param0": "1", "param1": "0", "param2": "0", "param3": "0", } Here, "event_frame_header" represents the event frame header, "event_frame_content" represents the event frame body, "frame_type" represents the frame type (1 indicates the current frame is an event frame), "frame_size" represents the size of the entire frame, "prev_frame_offset" represents the offset of the previous frame (can be used to index the previous frame backward), "next_frame_offset" represents the offset of the next frame (can be used to index the next frame backward), "time_stamp" represents the timestamp, and "conten" represents the content. "t_size" indicates the size of the message body, "event_type" indicates the event type (e.g., SYSTEM_ERROR system exception event, DRIVER_ERROR driver exception event, HARDWARE_ERROR hardware exception event, etc.), "error_code" indicates the exception code (e.g., DISPLAY_LINK_ERROR indicates a display link error), "param0" indicates exception parameter 0 (e.g., in the example above, it indicates an error occurred on display 1), "param1" indicates exception parameter 1, "param2" indicates exception parameter 2, and "param3" indicates exception parameter 3.

[0026] 200. The system frame representing the state information of the SOC module itself is read through the SOC module, and the system frame is compressed into a first state brief and the event frame is compressed into a second state brief before being transmitted to the microcontroller unit.

[0027] 300. The microcontroller unit stores the received first status report and second status report into the second storage unit.

[0028] Specifically, system frames record the status information of the SOC module, while event frames record abnormal events. Although the first storage unit of the SOC module can store system frame and event frame data, it has a single point of failure risk. If the SOC module itself fails, all the system frame and event frame data it stores may be lost, making it impossible to trace the anomaly. As a control unit independent of the SOC module, the microcontroller unit transmits the system frames compressed into first status reports and the event frames into second status reports to the microcontroller unit and stores them in the second storage unit. This can form a disaster recovery system, solving the problem of data loss caused by the failure of a single storage node. The compressed system frames and data frames will significantly reduce the storage pressure and avoid storage overflow or operation lag of the microcontroller unit due to excessive data volume.

[0029] 400. When the SOC module restarts, the microcontroller unit sends the first status report and the second status report stored in the second storage unit back to the SOC module, and the SOC module stores them in the third storage unit.

[0030] To prevent the loss of all system frame and event frame data stored in the first storage unit due to a fault in the SOC module itself, which would leave no basis for anomaly tracing, the microcontroller unit sends the first and second status reports stored in the second storage unit back to the SOC module when the SOC module restarts, and then stores them in the third storage unit through the SOC module.

[0031] In this embodiment, the first storage unit is the DDR memory of the SOC module, the second storage unit is the EEPROM storage device of the microcontroller unit, and the third storage unit is the EMMC / UFS storage device of the SOC module.

[0032] DDR memory serves as a temporary data processing platform for the SOC module, employing double data rate transmission technology to enable instantaneous data access and avoid computational lag. EEPROM storage devices are non-volatile, permanently retaining data even after power failure. They do not require continuous power to save data; even if the microcontroller unit loses power or the device is shut down, stored configuration parameters, operation logs, and other information will not be lost. EMMC / UFS storage devices meet the persistent storage requirements for large-capacity data. System frames are compressed into first-state briefs, and event frames are compressed into second-state briefs before being transmitted to the microcontroller unit and stored on the EEPROM storage device. This prevents the in-vehicle cockpit system from failing to save data in a timely manner due to sudden power outages or other anomalies. When the SOC module restarts, the microcontroller unit sends the first and second-state briefs stored in the EEPROM storage device back to the SOC module, which then stores them on the EMMC / UFS storage device, thus meeting the persistent storage requirements for large-capacity data.

[0033] like Figure 3 As shown, in some implementations, the system frame is obtained through the following sub-steps: 210. Call the SOC module to periodically collect its own status information; 220. Encode the collected status information into a system frame each time; 230. Store the system frame in the first storage unit.

[0034] As the core of computing power in the underlying software of the vehicle cockpit system, the SOC module's operating status directly determines the stability of the vehicle cockpit system. Regularly collecting SOC status information, such as CPU status, memory status, and driver status, can compensate for the inherent defects of existing tools such as LOG logging systems, Ramdump, and event tracking systems.

[0035] Specifically, the data lost during the crash of the LOG log system can be deduced by using the status information of the SOC module collected periodically. For example, when the instrument panel goes black, the LOG log system only records the normal data for the 10 seconds before the black screen. However, based on the status information of the SOC module collected periodically, it shows that the memory usage of the SOC module surged within 3 or 5 seconds before the black screen, and there were memory allocation failures. Therefore, the cause of the black screen can be quickly analyzed and after-sales issues can be resolved by using the status information of the SOC module.

[0036] Ramdump is difficult to trigger due to its long processing time, but the status information of the SOC module collected periodically can replace part of the full memory information. For example, if a vehicle experiences an occasional restart after a period of time, Ramdump cannot be triggered in time, but the status information of the SOC module collected periodically shows that the CPU usage reached 100% before the restart. Therefore, the cause of the anomaly can be quickly analyzed through the status information of the SOC module without waiting for Ramdump data.

[0037] For tracking systems, they only record the results of abnormal events and do not involve the process of how the abnormal events occur. However, periodically collecting the status information of the SOC module can record the status of the abnormal event process, solving the problem of insufficient dimensions in tracking analysis, and does not require reliance on the cloud.

[0038] The status information of the SOC module is collected periodically, and each collected status information is encoded into a system frame, which facilitates the storage and retrieval of the collected status information and the analysis of abnormal events.

[0039] refer to Figure 4 , Figure 4 The format of a system frame is as follows, and the pseudocode for a system frame is as follows: "system_frame_header": { "frame_type": "0", "frame_size": "76", "prev_frame_offset": "0", "next_frame_offset": "152", "time_stamp": "Mon Aug 11 17:08:20 2025", "content_size": "44", } "system_frame_content": { "cpu_temp": "40", "cpu_usage": "30", "cpu_freq": "1200", "mem_total": "2048", "mem_used": "1024", "gpu_freq": "1024", "power_state": "NORMAL", "system_err_occured": "false", "system_err_type": "E_OK", } In this table, "system_frame_header" represents the header of a system frame, "system_frame_content" represents the body of a system frame, "frame_type" represents the frame type (0 indicates the current frame is a system frame), "frame_size" represents the size of the entire frame, "prev_frame_offset" represents the offset of the previous frame (can be used to index the previous frame backward), "next_frame_offset" represents the offset of the next frame (can be used to index the next frame backward), "time_stamp" represents the timestamp, "content_size" represents the size of the body, "cpu_temp" represents the CPU temperature, "cpu_usage" represents the CPU usage, "cpu_freq" represents the CPU frequency, "mem_total" represents the total size of system memory, "mem_used" represents the amount of memory used, "gpu_freq" represents the GPU frequency, "power_state" represents the current power state, "system_err_occured" indicates whether a serious system exception has occurred, and "system_err_type" represents the type of the last serious system exception.

[0040] The system frame is stored in the first storage unit, which is the DDR memory of the SOC module. The DDR memory is the temporary data processing workbench of the SOC module. It adopts double data rate transmission technology to realize instantaneous data access and avoid computational lag.

[0041] See Figure 5 In some embodiments, the present invention further includes the following steps: 500. The SOC module periodically compresses the system frame into a first status briefing; 600. The microcontroller unit stores the received first status briefing into the second storage unit; 700. When the SOC module restarts, the microcontroller unit sends the first status summary stored in the second storage unit back to the SOC module, and the SOC module stores it in the third storage unit.

[0042] In the absence of any abnormal events, the SOC module periodically collects its own status information and periodically encodes the collected status information into a system frame. The system frame is then compressed into a first status report, which is stored in the second storage unit by the microcontroller unit.

[0043] As can be seen from the foregoing, when an abnormal event occurs, the SOC module encodes the abnormal event information into an event frame and stores the event frame in the first storage unit. The SOC module reads the system frame representing the SOC module's own state information, compresses the system frame into a first state summary and the event frame into a second state summary, and then transmits them to the microcontroller unit. The microcontroller unit stores the received first and second state summaries in the second storage unit.

[0044] As can be seen from the above, regardless of whether an abnormal event occurs, the SOC module continuously collects its own status information periodically, and periodically encodes the collected status information into a system frame, compresses it into a first status report, and sends it to the microcontroller unit. In this way, through the mechanism of timestamp synchronization and storage address binding, it can be ensured that each event frame can accurately match the system frame sequence before and after the abnormal event. That is, it can be ensured that when an abnormal event occurs, the status information of the SOC module before and after the abnormal event can be traced, facilitating the analysis of the cause of the abnormal event.

[0045] When the SOC module restarts, the microcontroller unit sends the first status summary stored in the second storage unit back to the SOC module, and the SOC module stores it in the third storage unit to meet the persistent storage requirements of large-capacity data.

[0046] In some implementations, abnormal events include at least program crash events, driver abnormal events, and preset operation events.

[0047] Program crash events can include system service crashes, file system crashes, and kernel process crashes.

[0048] Specifically, system service crashes include: process management service crashes (e.g., during vehicle startup, the process management service loads a list of startup applications; if invalid process paths exist in the list and are not caught, the service crashes, preventing subsequent applications from starting); power management service crashes (e.g., when the vehicle is turned off, the power management service executes the cockpit device power-off sequence; a bug in the device power-off status detection function causes duplicate power-off commands, triggering a service crash); and time synchronization service crashes (e.g., when the vehicle connects to the cloud to synchronize time, network interruptions lead to incomplete time data reception, timestamp overflow during service parsing, causing a crash and resulting in incorrect application time display). File system crashes include file index corruption, disk space exhaustion, and abnormal mount point unmounting. Kernel process crashes include thread scheduling deadlocks, memory management anomalies, and terminal processing errors.

[0049] Driver-related abnormal events may include camera driver abnormalities, microphone driver abnormalities, and display abnormalities.

[0050] Specifically, camera driver anomalies may include image data anomalies, data transmission interruptions, and sleep / wake failures.

[0051] Microphone driver malfunctions can include abnormal voice signal acquisition and interruption of audio data transmission.

[0052] Display screen malfunctions may include initialization failures, rendering stutters, display errors, or color anomalies.

[0053] Preset operation events may include vehicle start operation, Bluetooth connection operation, and air conditioning adjustment operation.

[0054] When the peripheral driver module detects an abnormal event during self-testing, it sends the abnormal event to the SOC module. The SOC module encodes the abnormal event information into an event frame. It is understood that in this embodiment, the abnormal event is not limited to program crash events, driver abnormal events, and preset operation events. It can also be other abnormal events that may affect the safety of the vehicle cockpit system.

[0055] Status information includes at least CPU status, memory status, driver status, power status, and temperature status.

[0056] The CPU is the command center of the in-vehicle cockpit system, responsible for scheduling core tasks such as voice interaction, vehicle control, and multi-device collaboration. Its status determines the reliability of the control response of the in-vehicle cockpit system. Therefore, periodically collecting CPU status information can ensure driving safety and facilitate subsequent anomaly analysis. Specifically, analysis can be performed by collecting the CPU load rate.

[0057] Abnormal memory status can lead to data loss and address conflicts, causing problems such as functional malfunctions or system crashes. For example, when memory leaks, critical data cannot be written, and the HIMI interface displays invalid values; when memory address conflicts occur, the screen may go black and control may fail. Specifically, this can be analyzed by collecting memory usage data.

[0058] Abnormalities in the driver state can lead to sensor failure or control malfunction. Specifically, you can query the status of the core driver, including running, stopped, and abnormal states.

[0059] Power status: Abnormal power status can affect driving safety from the functional, safety, and system levels. Specifically, the current power status can be analyzed by querying the power management module.

[0060] Temperature information anomalies may indicate that core hardware is overheating or that temperature monitoring is distorted. Therefore, you can query the current temperature information from the thermal management module for analysis.

[0061] In this embodiment, by periodically collecting the status information of the SOC module, including CPU status, memory status, driver status, power status, and temperature status, driving safety can be ensured and subsequent anomaly analysis can be facilitated. Specifically, the periodic collection can be set to collect data once every 3 seconds or 5 seconds, and the collected SOC module status information is encoded into a system frame for subsequent anomaly analysis.

[0062] In some implementations, the event frame is stored in a region with a fixed starting address in the first storage unit; the system frame is stored in a region with a fixed starting address in the first storage unit.

[0063] Specifically, system frames and event frames are stored in a region with a fixed starting address in the DDR memory of the SOC module. At the beginning of the storage region, a header information in a fixed format is saved, recording information such as the total number of frames and the starting frame address offset, which can be used to index specific system frames or event frames.

[0064] Example 2: See Figure 6 This embodiment provides an in-vehicle cockpit system, including a SOC module and a microcontroller unit.

[0065] The SOC module includes a core monitor. When an abnormal event occurs, the core monitor encodes the abnormal event information into an event frame through the SOC module, stores the event frame in the first storage unit, and reads the system frame representing the SOC module's own state information through the SOC module. The system frame is then compressed into a first state summary and the event frame is compressed into a second state summary before being transmitted to the microcontroller unit.

[0066] The microcontroller unit is used to store the received first and second status reports into a second storage unit, and to send the first and second status reports stored in the second storage unit back to the SOC module when the SOC module restarts, and then store them into a third storage unit through the SOC module.

[0067] This embodiment develops a core monitor integrated into the SOC module. When an abnormal event occurs, it encodes the abnormal event information into an event frame and a system frame used to read the state information of the SOC module itself. The system frame is compressed into a first state summary and the event frame is compressed into a second state summary before being transmitted to the microcontroller unit. The microcontroller unit stores the received first and second state summaries in a second storage unit, ensuring a 100% success rate in saving. This effectively reduces the number of after-sales issues with no information to analyze, and the state summary occupies little storage space. The total time from abnormal triggering to the microcontroller unit completing storage is less than 3 seconds. After an abnormality occurs in the vehicle cockpit system, the abnormality can be quickly recorded and the vehicle cockpit system can be reset, greatly reducing the impact of system abnormalities on user experience.

[0068] In some implementations, the core monitor includes at least a system information collection subunit and an MCU communication subunit.

[0069] The system information collection subunit is used to receive abnormal event information and periodically collect the status information of the SOC module. In terms of periodically collecting the status information of the SOC module, the status information of the SOC module is queried every 3 or 5 seconds, which may include CPU load rate, querying the CPU utilization rate; memory utilization rate, querying the utilization rate of system content and display; power status, querying the current power status from the power management module; temperature information, querying the current temperature information from the thermal management module; and core driver status, querying the status of the core driver, including running, stopped, and abnormal status.

[0070] The MCU communication subunit is used to compress system frames into first status briefs and event frames into second status briefs before transmitting them to the microcontroller unit.

[0071] Specifically, the MCU communication subunit transmits the first and second status reports to the microcontroller unit via the SPI interface. SPI uses full-duplex synchronous serial communication, without redundant overhead such as start bits and stop bits. The data transmission rate can typically reach several Mbps to tens of Mbps, which is much higher than other low-speed serial interfaces. In this embodiment, the use of the SPI interface for status report transmission can ensure that critical data is transmitted without delay.

[0072] In one example, the status briefing is sent to the microcontroller unit in message format. The status briefing consists of 6 frames of system status data (36 bytes) and 8 frames of event data (24 bytes), for a total length of 64 bytes. The specific format is shown in the attached figure. Figure 7 As shown.

[0073] In some implementations, the first status briefing includes a header, data content, and a checksum. The header is the starting identifier and metadata carrier of the status briefing, and its main function is to allow the receiver to quickly understand the basic attributes of the information and provide prerequisites for subsequent data processing. The data content is used to present the current status, historical changes, or statistical results of the SOC module's status information or abnormal events in a standardized form. The checksum is used to verify whether the information has been tampered with, lost, or erroneous during transmission or storage, ensuring the validity of the information throughout the entire process from sending to receiving.

[0074] Example 3: This embodiment provides a storage medium storing at least one executable instruction. When the executable instruction is executed on the vehicle cockpit system described above, it causes the vehicle cockpit system to perform the operation of the vehicle anomaly recording method described above.

[0075] This invention encodes abnormal event information into an event frame when an abnormal event occurs. The SOC module reads the system frame representing its own state information, compresses the system frame into a first state summary, and compresses the event frame into a second state summary before transmitting them to the microcontroller unit. The microcontroller unit stores the received first and second state summaries in a second storage unit, ensuring a 100% success rate. This effectively reduces the number of after-sales issues with no information to analyze, and the state summary occupies little storage space. The total time from abnormal triggering to microcontroller unit storage completion is less than 3 seconds. After an abnormality occurs in the vehicle cockpit system, the abnormality can be quickly recorded and the system reset, greatly reducing the impact of system abnormalities on user experience. When the SOC module restarts, the microcontroller unit sends the first and second state summaries stored in the second storage unit back to the SOC module, which then stores them in a third storage unit. This facilitates after-sales issue analysis without relying on cloud statistics, reducing bandwidth costs.

[0076] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0077] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0078] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for recording vehicle anomalies, characterized in that, Applied to in-vehicle cockpit systems, the method includes: When an abnormal event occurs, the abnormal event information is encoded into an event frame by the SOC module, and the event frame is stored in the first storage unit; The system frame representing the state information of the SOC module itself is read by the SOC module, and the system frame is compressed into a first state brief and the event frame is compressed into a second state brief before being transmitted to the microcontroller unit. The microcontroller unit stores the received first status report and second status report into the second storage unit; When the SOC module restarts, the microcontroller unit sends the first status report and the second status report stored in the second storage unit back to the SOC module, and the SOC module stores them in the third storage unit.

2. The method for recording vehicle anomalies according to claim 1, characterized in that, The system frame is obtained through the following sub-steps: The SOC module is invoked to periodically collect its own status information. The state information collected each time is encoded into a system frame; The system frame is stored in the first storage unit.

3. The method for recording vehicle anomalies according to claim 1, characterized in that, It also includes the following steps: The SOC module periodically compresses the system frame into a first status briefing. The microcontroller unit stores the received first status report into the second storage unit; When the SOC module restarts, the microcontroller unit sends the first status summary stored in the second storage unit back to the SOC module, and the SOC module stores it in the third storage unit.

4. The method for recording vehicle anomalies according to claim 1, characterized in that, The abnormal events include at least program crash events, driver abnormal events, and preset operation events; The status information includes at least CPU status, memory status, driver status, power status, and temperature status.

5. The method for recording vehicle anomalies according to claim 2, characterized in that, The event frame is stored in the region with a fixed starting address in the first storage unit; The system frame is stored in the region with a fixed starting address in the first storage unit.

6. A vehicle-mounted cockpit system, characterized in that, Includes SOC modules and microcontroller units; The SOC module includes a core monitor, which is used to encode abnormal event information into an event frame through the SOC module when an abnormal event occurs, store the event frame in the first storage unit, and read system frames representing the SOC module's own state information through the SOC module, compress the system frames into a first state summary and the event frames into a second state summary before transmitting them to the microcontroller unit. The microcontroller unit is configured to store the received first status report and second status report into a second storage unit, and to send the first status report and second status report stored in the second storage unit back to the SOC module when the SOC module restarts, and then store them into a third storage unit through the SOC module.

7. The vehicle-mounted cockpit system according to claim 6, characterized in that, The core monitor includes at least a system information collection subunit and an MCU communication subunit; The system information collection subunit is used to receive the abnormal event information and periodically collect the status information of the SOC module; The MCU communication subunit is used to compress the system frame into a first status briefing and the event frame into a second status briefing before transmitting them to the microcontroller unit.

8. The vehicle-mounted cockpit system according to claim 7, characterized in that, The MCU communication subunit transmits the first status report and the second status report to the microcontroller unit via the SPI interface.

9. The vehicle-mounted cockpit system according to claim 8, characterized in that, The first status briefing includes a message header, data content, and a checksum.

10. A storage medium storing at least one executable instruction, which, when executed on a vehicle cockpit system as claimed in claim 6, causes the vehicle cockpit system to perform the operation of the vehicle anomaly recording method as claimed in any one of claims 1-5.

Images