Log storage method and system and intelligent driving domain controller
By preparing the log channel before the SOC starts using the MCU module, and by adopting a dual-channel isolation and dynamic protocol selection mechanism, the problem of log information loss in the early stage of intelligent driving domain controller startup is solved, and complete log capture and adaptive transmission are achieved.
Patent Information
- Application Number
- CN202510890658.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-30
- Publication Date
- 2025-11-21
AI Technical Summary
In existing technologies, intelligent driving domain controllers cannot achieve real-time storage and monitoring during the initial startup of the SOC, resulting in the loss of log information.
The MCU module receives a wake-up signal, wakes up the SOC module and determines the connection status. It adopts a dual-channel isolation design and a dynamic protocol selection mechanism, and caches or transmits log information through the first and second protocols respectively to ensure complete log capture.
It achieves complete capture of SOC module startup phase logs, adapts to the switching between on-board and off-board debugging scenarios, alleviates bus congestion under high load scenarios, meets the real-time requirements of offline debugging, and ensures the stability of signal transmission.
Smart Images

Figure CN120997922A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The embodiment of the present application relates to the field of automobile communication technology, in particular to a log storage method, system and intelligent driving domain controller. BACKGROUND
[0002] The intelligent driving domain controller of the automobile has the characteristics of high hardware complexity, heavy software load and high core safety redundancy requirement, and a large number of logs are generated during its running process, which is much larger than other vehicle controllers. Usually, the SOC module responsible for the algorithm application needs to monitor the logs in the whole process of the start-up stage and the working process.
[0003] The traditional monitoring scheme only uses the running logs for local debugging or stores them in the UFS storage, and the specific storage method needs to be determined manually. In particular, the log volume generated by the intelligent driving domain controller is much larger than that of the T-BOX controller and the like. In order to achieve full-process monitoring, the recording requirement needs to reach the nanosecond level. Therefore, it is very challenging for the MCU module to process data in real time, especially in the start-up stage of the SOC module. Since the domain controller has two different log acquisition methods, namely, the off-car debugging and the on-car debugging, the requirements for the log signals are different. Using the traditional log information direct output method, it is difficult to achieve real-time storage and monitoring in the initial stage of the SOC start-up, resulting in the loss of the log information of the SOC module in the initial start-up stage. SUMMARY
[0004] In view of the above problems, the embodiment of the present application provides a log storage method, system and intelligent driving domain controller to solve the problem that the log information of the SOC module in the initial start-up stage is lost due to the difficulty in achieving real-time storage and monitoring in the initial stage of the SOC start-up.
[0005] According to one aspect of the embodiment of the present application, a log storage method is provided, which comprises: receiving a wake-up signal through an MCU module; waking up an SOC module through the MCU module, determining the connection state of the intelligent driving domain controller, and preprocessing the original log information of the SOC module to obtain working log information; when the intelligent driving domain controller is in a first connection state, caching the working log information through the MCU module and transmitting the working log information to the outside through a first protocol; and when the intelligent driving domain controller is in a second connection state, transmitting the working log information to the outside through a second protocol.
[0006] In an optional manner, preprocessing the original log information of the SOC module to obtain working log information comprises the following sub-steps: establishing a first transmission channel and a second transmission channel which are isolated from each other; performing first level conversion on the original log information to access the first transmission channel, and performing second level conversion on the original log information to access the second transmission channel; According to the connection state of the intelligent driving domain controller, a first output channel or a second output channel is selected to output the original log information after level conversion, so as to form output of the working log information.
[0007] In an optional manner, when the intelligent driving domain controller is in a first connection state, the working log information is cached through the MCU module, and the working log information is transmitted to the outside through a first protocol, including the following sub-steps: The working log information is obtained through the MCU module; The working log information is compressed and encrypted; The working log information after compression and encryption is cached in a storage space dedicated to the MCU module; The working log information in the storage space is forwarded to a cloud server through the vehicle-mounted communication module through a first transmission protocol.
[0008] In an optional manner, the working log information is transmitted to the outside through a second protocol, including the following sub-steps: The working log information is transmitted to a DEBUG interface through a second protocol, and the working log information is transmitted to an upper computer through the debug interface.
[0009] In an optional manner, the first protocol is an Ethernet protocol, and the second protocol is a UART protocol.
[0010] In an optional manner, the first connection state is that the intelligent driving domain controller is in a system online working connection state, and the second connection state is that the intelligent driving domain controller is in a system offline debugging working connection state.
[0011] In an optional manner, the connection state of the intelligent driving domain controller is determined, including: CAN bus transmission data is called through the MCU module; The load rate of the CAN bus transmission data is detected; When the load rate is higher than a preset value, it is determined that the intelligent driving domain controller is in a first connection state, otherwise it is determined that the intelligent driving domain controller is in a second connection state.
[0012] According to a second aspect of an embodiment of the present application, a log storage system is provided for storing working log information generated by an intelligent driving domain controller, including: an SOC module configured to respond to the wake-up signal and generate original log information of the intelligent driving domain controller; a data backfilling module configured to receive the original log information and preprocess the original log information of the SOC module to obtain working log information according to a connection state of the intelligent driving domain controller; an MCU module configured to wake up the SOC module and determine the connection state of the intelligent driving domain controller, cache the working log information through the MCU module when the intelligent driving domain controller is in a first connection state, and transmit the working log information to the outside through a first protocol; and transmit the working log information to the outside through a second protocol when the intelligent driving domain controller is in a second connection state.
[0013] In an optional manner, the data backfilling module comprises: a data switching and shunting unit configured to establish a first transmission channel and a second transmission channel which are isolated from each other; a level conversion unit configured to perform first level conversion on the original log information to access the first transmission channel and perform second level conversion on the original log information to access the second transmission channel; a control unit configured to select and control conduction of the first transmission channel and the second transmission channel according to a preset instruction and control a level conversion mode of the level conversion unit.
[0014] In an optional manner, the log storage system further comprises an interface protection unit connected to the first transmission channel and the second transmission channel and configured to protect the backfilling module.
[0015] According to a third aspect of the embodiment of the present application, an intelligent driving domain controller is provided, comprising: a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete communication with each other through the communication bus; the memory is configured to store at least one executable instruction, and the executable instruction enables the processor to perform the steps of the log storage method as described above when executed to store logs.
[0016] According to a fourth aspect of the embodiment of the present application, a computer readable storage medium is provided, and the computer readable storage medium stores a computer program, wherein when a device where the computer readable storage medium is located executes the computer program, the log storage method as described above is implemented.
[0017] The application completes log channel preparation before SOC starts through the MCU module front-end processing mechanism, and ensures complete capture of logs in the starting stage. The dynamic protocol selection mechanism can intelligently switch transmission modes according to the actual CAN bus load rate, for example, adopts buffer compression transmission to reduce bus pressure in the loading scene, and enables direct transmission protocol to improve the debugging efficiency in the unloading scene. The log loss problem in the initial stage of the SOC module start is effectively avoided, and adaptive switching of the loading and unloading debugging scenes is realized; the preprocessing mechanism of the data backfill module adapts the log format to the requirements of different transmission protocols, the buffer strategy alleviates the bus congestion in the high-load scene, and the direct transmission mode meets the real-time requirements of offline debugging; the dual-channel isolation design guarantees the stability of different level signal transmission, and solves the problem of SOC module log information loss in the initial stage of the traditional scheme.
[0018] The above description is only a summary of the technical solutions of the embodiments of the application. In order to more clearly understand the technical means of the embodiments of the application, the content of the specification can be implemented, and in order to make the above and other purposes, characteristics and advantages of the embodiments of the application more obvious and easy to understand, the specific embodiments of the application are described below. BRIEF DESCRIPTION OF DRAWINGS
[0019] The drawings are only used to show the embodiments and are not considered as limitations of the application. Moreover, the same reference signs are used to represent the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of a first embodiment of a log storage method provided by the application is shown; Figure 2 A flowchart of sub-steps of the log storage method provided by the application in step 120 of the first embodiment is shown; Figure 3 A flowchart of sub-steps of the log storage method provided by the application in step 130 of the first embodiment is shown; Figure 4 A structural schematic diagram of an embodiment of a log storage system provided by the application is shown; Figure 5 A structural schematic diagram of an embodiment of a data backfill module provided by the application is shown; Figure 6 An implementation flowchart of the log storage method provided by the application is shown. DETAILED DESCRIPTION
[0020] Exemplary embodiments of the application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the application are shown in the drawings, it should be understood that the application can be implemented in various forms and should not be limited by the embodiments described herein.
[0021] Example 1: Figure 1 A flow chart of a first embodiment of the log storage method of the present application is shown, which is executed by an intelligent driving domain controller for storing work log information generated by the intelligent driving domain controller. As shown in the figure, Figure 1 The method comprises the following steps: Step 110: receiving a wake-up signal through an MCU module.
[0022] The MCU module refers to a microcontroller unit with low-power wake-up function, which can be implemented by a chip supporting ARM instruction set, and is used to establish a log processing channel before the SOC module starts. The wake-up signal can be a level signal sent by the vehicle power supply system, which is used to trigger the MCU module to enter the working state.
[0023] Step 120: waking up the SOC module through the MCU module, determining the connection state of the intelligent driving domain controller, and preprocessing the original log information of the SOC module to obtain work log information.
[0024] Specifically, after the MCU module receives the wake-up signal, it immediately initializes the log transmission channel and determines the specific connection state of the intelligent driving domain controller.
[0025] The connection state of the intelligent driving domain controller can have multiple ways, which can be determined by judging whether there is a typical signal unique to the on-vehicle state, such as a vehicle unique identification code, a chassis signal, or a power system signal, etc. It can also be determined by monitoring the load rate of the vehicle CAN bus.
[0026] For example, when the CAN bus load rate is detected to be more than 10% within a preset time period, it is determined to be the first connection state, and when the load rate is less than 10%, it is determined to be the second connection state. The data backfill module preprocesses the original log information of the SOC module to obtain work log information, which can include conversion of original data electrical signal, and / or data format conversion and protocol encapsulation, etc.
[0027] Specifically, before the SOC module completes the start, the preprocessing unit, i.e. the data backfill module, has established a physical connection with the host computer. The connection state of the intelligent driving domain controller can be determined by monitoring the CAN bus load rate in real time, and the log information directly output by the SOC module can be preprocessed by the data backfill module to obtain work log information.
[0028] Step 130: when the intelligent driving domain controller is in the first connection state, the work log information is cached through the MCU module, and the work log information is transmitted externally through the first protocol; when the intelligent driving domain controller is in the second connection state, the work log information is transmitted externally through the second protocol.
[0029] The first protocol and the second protocol are different transmission protocols.
[0030] Specifically, by monitoring the CAN bus load rate in real time, when a sustained high load is detected, it is determined that the intelligent driving domain controller is in the first connection state, that is, it is determined that the intelligent driving domain controller is in the vehicle-mounted debugging state, at which time the work log will be uploaded to the outside through the first protocol. When a low load rate is detected, it is determined that the intelligent driving domain controller is in the second connection state, that is, it is determined that the intelligent driving domain controller is in the debugging state of dismounting, and the original log is directly output to the outside after level conversion through the second protocol.
[0031] In the preprocessing process of the data backfill module, a double-channel isolation mechanism is adopted to ensure the signal integrity of different transmission paths, for example, an optocoupler device is used to isolate the high-low level conversion circuit. Compared with the prior art, the traditional scheme adopts a single storage path and a fixed transmission protocol, which cannot meet the real-time requirements at the initial stage of SOC startup, and ignores the transmission differences between the first connection state, that is, the vehicle-mounted debugging state, and the second connection state, that is, the dismounting debugging state.
[0032] The above method completes log channel preparation before SOC startup through the MCU module front-end processing mechanism, ensuring complete capture of logs during the startup stage. The dynamic protocol selection mechanism can intelligently switch the transmission mode according to the actual CAN bus load rate, for example, in the vehicle-mounted scene, the cache compression transmission is used to reduce the bus pressure, and in the dismounting scene, the direct transmission protocol is enabled to improve the debugging efficiency. The problem of log loss at the initial stage of the SOC module startup is effectively avoided, and adaptive switching between the vehicle-mounted and dismounting debugging scenes is realized; the preprocessing mechanism of the data backfill module adapts the log format to the requirements of different transmission protocols, the cache strategy alleviates the bus congestion in the high-load scene, and the direct transmission mode meets the real-time requirements of offline debugging; the double-channel isolation design ensures the stability of different level signal transmission, solving the problem of log information loss of the SOC module at the initial stage of startup in the traditional scheme.
[0033] Please refer to Figure 2 , Figure 2 A flowchart showing the sub-steps of the log storage method of the application in step 120 is shown.
[0034] In step 120, the original log information of the SOC module is preprocessed to obtain work log information, including the following sub-steps: Step 121: Establish a first transmission channel that is isolated from each other.
[0035] The first transmission channel and the second transmission channel isolated from each other refer to signal transmission paths independent from each other in the physical layer, and can be specifically implemented by combining a differential signal line and a single-ended signal line, and isolated by different wiring layers or shielding layers. The design can avoid signal crosstalk between different devices.
[0036] Specifically, in the SOC module startup phase, the original log information is sent to two independent transmission channels at the same time.
[0037] Step 122: The original log information is subjected to first level conversion to access the first transmission channel, and second level conversion to access the second transmission channel.
[0038] The first level conversion refers to adjusting the voltage amplitude of the original log signal to adapt to the specification of the MCU module input interface, and can be specifically implemented by using a level shift chip to convert 1.8V logic level to 3.3V level. The second level conversion refers to adjusting the voltage amplitude of the original log signal to adapt to the specification of the host computer debugging interface, and can be specifically implemented by using an RS-232 level conversion circuit to convert TTL level to ±12V differential signal.
[0039] Specifically, the first transmission channel transmits the 1.8V logic signal output by the SOC to the MCU module after converting it to 3.3V level by a level shift chip, and the second transmission channel connects to the host computer after converting the signal to ±12V differential level by an RS-232 converter.
[0040] Step 123: According to the connection state of the intelligent driving domain controller, the first output channel or the second output channel is selected to output the original log information subjected to level conversion, to form the output of the working log information.
[0041] The connection state determination basis refers to determining whether the device is in a first connection state or a second connection state by monitoring the bus load rate in real time, and can be specifically implemented by using a CAN bus load rate threshold comparator. This mechanism ensures that the channel switching matches the actual working condition.
[0042] Specifically, when the CAN bus load rate is detected to be higher than 10%, it is determined to be in the first connection state, at which time the first transmission channel is enabled to transmit log data to the MCU, and the physical layer power supply of the second transmission channel is turned off. When the bus load rate is lower than 10%, it is determined to be in the second connection state, at which time the electrical connection of the first transmission channel is cut off, and the second transmission channel is activated to output log data to the host computer. The dual-channel isolation design ensures that the signal transmission paths are not cross-interfered under different working conditions, and the level conversion operation is completed before the signal enters the transmission channel, avoiding signal distortion caused by mismatched receiving end level in the traditional scheme. It can be understood that the first connection state is a vehicle-mounted debugging state, and the second connection state is a vehicle-dismounted debugging state.
[0043] In some embodiments, the average CAN bus load rate of a preset time period can be detected to avoid misjudgment caused by fluctuations. At the same time, in order to avoid the loss of log content caused by misjudgment, when the connection state of the intelligent driving domain controller is not determined, the first connection state is defaulted, at this time the data will be cached by the MCU module in advance, and after the connection state is determined, the cached log information is processed by the second level conversion, and after meeting the output requirements of the second protocol, it is transmitted externally. The log information is integrated and spliced on the receiving equipment through the second protocol output, to ensure the integrity of the log information. It can be understood that the integration process can be sorted and integrated according to the timestamp information.
[0044] Please combine Figure 3 , Figure 3 The flowchart of the sub-steps of the log storage method of the application in step 130 is shown.
[0045] In step 130, when the intelligent driving domain controller is in the first connection state, the working log information is cached by the MCU module, and the working log information is transmitted externally through the first protocol, including the following sub-steps: Step 131: obtaining the working log information by the MCU module; Step 132: compressing and encrypting the working log information; Among them, the compression processing refers to the volume reduction of log data by using lossless compression algorithm, which can be realized by using LZ77 algorithm or Huffman coding, and is used to reduce the transmission bandwidth occupation.
[0046] Step 133: caching the working log information after compression and encryption processing in the storage space dedicated to the MCU module; Among them, the dedicated storage space refers to an independent cache area physically isolated from the SOC module storage area, which can be realized by using SRAM or NOR Flash memory, and is used to avoid storage resource conflict in the start-up stage of SOC module. Among them, the encryption processing refers to the irreversible encryption operation of log data, which can be realized by using AES-256 algorithm or SM4 national encryption algorithm, and is used to meet the intelligent driving data security transmission specification.
[0047] Step 134: forwarding the working log information in the storage space to the cloud server through the vehicle-mounted communication module by the first transmission protocol.
[0048] In the embodiment, after uploading to the cloud server through the first transmission protocol, the cloud server can be monitored in real time, data reorganization technology based on time stamp and event marking is used, and cloud resources are used for rapid data analysis. This method can improve the fault positioning speed, and the cloud log real-time analysis shortens the diagnosis time from the traditional 1 hour to 5 minutes.
[0049] Specifically, in the initial stage of the SOC module startup, the MCU module directly captures the original log data generated by the SOC through a hardware interface. The captured log data is sent to a compression engine for streaming compression. A sliding window mechanism is used in the compression process to maintain the processing delay at the microsecond level. The compressed data stream is block-encrypted by an encryption chip. The encryption key is dynamically generated by the vehicle-mounted security module. The processed data is written to a separate buffer area of the MCU module. The buffer area uses a ring buffer structure to implement a data overwrite protection mechanism. When the vehicle-mounted communication module detects that the network is available, the data in the buffer area is forwarded to the cloud server through the vehicle-mounted communication module. In step 130, the work log information is transmitted externally through the second protocol, including the following sub-steps: The work log information is transmitted to the DEBUG interface through the second protocol, and the work log information is transmitted to the host computer through the DEBUG interface.
[0050] In the embodiment, the DEBUG interface refers to a debugging port with physical signal direct connection capability, which can be implemented by JTAG interface or SWD interface, and supports level matching circuit and signal isolation function. The host computer refers to a computing device with log receiving capability, which can be implemented by a notebook computer installed with debugging software, and a physical connection is established between the DEBUG interface and the host computer through a USB-to-serial module.
[0051] Specifically, when the intelligent driving domain controller is in a system offline debugging state, the original log information generated by the SOC module is transmitted to the MCU module in the form of differential signals after level conversion. The MCU module performs protocol encapsulation processing on the log data and outputs it to the receiving end of the DEBUG interface through the TX pin of the second protocol. The physical connection line of the DEBUG interface directly transmits the TTL level signal to the serial communication module of the host computer. The debugging software running in the host computer reads the serial buffer data to realize real-time analysis and storage of the log information. This process does not need to rely on the vehicle-mounted network communication link, and a physical level signal transmission channel can be established in the SOC module startup stage, avoiding the risk of log loss caused by network protocol stack initialization delay.
[0052] In some embodiments, the first protocol is an Ethernet protocol, and the second protocol is a UART protocol.
[0053] The Ethernet protocol is a network communication protocol conforming to the IEEE 802.3 standard, and can be implemented by using a 100MBASE-T1 vehicle Ethernet physical layer interface. The protocol supports high-speed data transmission and has anti-electromagnetic interference capability, and is suitable for establishing a stable connection with a cloud server in a state where the intelligent driving domain controller is installed in a vehicle.
[0054] The UART protocol is a universal transceiver interface protocol based on asynchronous serial communication, and can be implemented by using an RS-232 level conversion chip in cooperation with a DB9 debugging interface. The protocol can realize point-to-point communication without handshake signals, and is suitable for directly connecting a host computer through a physical interface during dismounting debugging.
[0055] Specifically, when the intelligent driving domain controller is in an online working state, the Ethernet protocol carries the nanosecond-level time precision log data generated by the SOC module through a transmission rate of up to 100 Mbps, and uses the routing function of the vehicle gateway to upload the encrypted and compressed log information to the cloud server in real time. When the intelligent driving domain controller switches to an offline debugging state, the UART protocol directly transmits the original log data to the host computer through the debugging interface, avoiding log transmission interruption caused by the handshake process of the protocol.
[0056] The two protocols are automatically switched according to the CAN bus load rate detection results, and the data transmission bandwidth is preferentially guaranteed when the system is online, and the physical reliability of the interface connection is preferentially ensured when the system is offline.
[0057] In some embodiments, the first connection state is a connection state in which the intelligent driving domain controller is in an online working state, and the second connection state is a connection state in which the intelligent driving domain controller is in an offline debugging working state.
[0058] The connection state in which the system is online working refers to a working state in which the controller is physically connected to the vehicle network through the CAN bus and performs vehicle operation tasks, and can be implemented by detecting whether the CAN bus load rate is higher than a preset threshold. This state corresponds to a high-load working condition in which other vehicle-mounted device data interaction exists in the vehicle debugging scene.
[0059] The connection state in which the system is offline debugging working refers to a working state in which the controller is disconnected from the vehicle network and is connected only through a local debugging interface, and can be implemented by detecting whether the CAN bus load rate is lower than a preset threshold or the physical connection state of the DEBUG interface. This state corresponds to a low-load working condition in which there is no other data transmission in the dismounting debugging scene.
[0060] The division of the two states is based on the bus load characteristics generated by the difference in physical connection environment, and provides a judgment basis for subsequent transmission protocol selection.
[0061] Specifically, in the truck-mounted debugging working condition, the CAN bus transmission data load rate is significantly increased due to the vehicle network interaction, and the system is determined to be in an online working state at this time; in this state, the log transmission needs to avoid occupying too much bus bandwidth, the MCU module is used to cache the log and the Ethernet protocol is used for asynchronous transmission, so as to ensure that the log generated in the starting stage of the SOC module can be completely saved. In the dismounted debugging working condition, the CAN bus load rate is reduced to below the preset threshold due to the disconnection of the vehicle network, and the system is determined to be in an offline debugging state; at this time, the log is directly transmitted to the debugging device connected to the DEBUG interface in real time through the UART protocol, so as to eliminate the processing delay caused by the cache link. The automatic identification mechanism of the two states is realized by monitoring the bus load rate in real time, and the transmission path switching can be completed without manual intervention.
[0062] In some embodiments, the determining the connection state of the intelligent driving domain controller comprises: The MCU module calls the CAN bus transmission data.
[0063] The MCU module calling the CAN bus transmission data refers to the microcontroller unit actively accessing the controller area network bus to obtain data transmission information, which can be realized by using a polling mechanism or an interrupt triggering mode, and its function is to provide real-time data source for connection state determination.
[0064] Detecting the load rate of the CAN bus transmission data.
[0065] The detection of the load rate of the CAN bus transmission data refers to the calculation of the ratio of the actual transmission data amount of the bus in a unit time to the theoretical maximum transmission amount, which can be realized by using a bus analyzer or an internal counter, and its function is to quantify the communication load of the system to distinguish different debugging scenarios.
[0066] When the load rate is higher than a preset value, the support domain controller is determined to be in a first connection state, otherwise the intelligent driving domain controller is determined to be in a second connection state.
[0067] The preset value refers to a critical threshold value for dividing high and low load states, which can be set by statistically analyzing the typical load range of the truck-mounted debugging and the dismounted debugging through experiments, and its function is to establish an objective standard for automatically judging the connection state. The first connection state and the second connection state correspond to the truck-mounted debugging and the dismounted debugging respectively, and the transmission strategy can be automatically switched by comparing the bus load rate with the preset value, and its function is to adapt to different debugging environments.
[0068] Specifically, the MCU module starts the CAN bus communication monitoring function immediately after the system is powered on, and calculates the load rate by periodically collecting bus data traffic. When it is detected that the load rate continuously exceeds the preset threshold, it is determined that the current is in the loading debugging state, at which time the log generated by the SOC module will be uploaded to the cloud in real time through a high-priority channel; when the load rate is lower than the preset threshold, it is determined to be in the unloading debugging state, and the log is directly output to the local debugging interface. This process starts at the start-up stage of the SOC module, ensuring that the correct log transmission path is established from the system initialization stage, without waiting for manual state confirmation.
[0069] Embodiment 2: As Figure 4 shown, Figure 4 The structure diagram of the embodiment of the log storage system of the application is shown. Based on embodiment 1, the log storage system is provided for storing the working log information generated by the intelligent driving domain controller, which can execute the log storage method as described in embodiment 1. Specifically, it includes: an SOC module 10, a data backfill module 20 and an MCU module 30.
[0070] The SOC module 10 is used to respond to the wake-up signal and generate the original log information of the intelligent driving domain controller. The data backfill module 20 is used to receive the original log information and preprocess the original log information of the SOC module 10 to obtain working log information according to the connection state of the intelligent driving domain controller. The MCU module 30 is used to wake up the SOC module 10 and determine the connection state of the intelligent driving domain controller. When the intelligent driving domain controller is in a first connection state, the working log information is cached through the MCU module 30, and the working log information is transmitted externally through a first protocol; when the intelligent driving domain controller is in a second connection state, the working log information is transmitted externally through a second protocol.
[0071] Specifically, the SOC module 10 refers to the main control chip loaded with application algorithms, which can be implemented by a system on chip integrated with a multi-core processor. It is connected to sensors such as radars and cameras of the vehicle 50, processes the original data of the cameras and radars, and is also connected to a navigation system for positioning calculation, etc. The log information also comes from the above-mentioned cameras, radars and navigation system. In this embodiment, the original log information generated by the SOC module 10 is output externally in the UART protocol. At the same time, the SOC module 10 can be awakened by the MCU module 30 during the sleep process to enter the working state and generate the original log information.
[0072] The data backfilling module 20 refers to a hardware circuit with signal conversion and channel switching functions, and can be implemented by using an FPGA chip in combination with a level conversion circuit. In the embodiment, the data backfilling module 20 is controlled by the MCU module 30. The MCU module 30 pre-processes the preset log signals of the data backfilling module 20 through an IIC protocol, and controls the output through different signal transmission channels.
[0073] The MCU module 30 refers to a microcontroller unit, and can be implemented by using a low-power processor with an ARM architecture. The MCU module 30 can obtain the connection state of the current intelligent driving domain controller through a CAN bus 40 protocol connected to a vehicle 50. Specifically, the connection state of the intelligent driving domain controller can be detected by monitoring the load rate of the CAN bus 40 in real time, and detecting specific typical signals such as a vehicle unique identification code, a chassis signal or a power system signal.
[0074] In some embodiments, the connection state is determined by detecting the load rate of the CAN bus 40. When a continuous high load is detected, it is determined that the intelligent driving domain controller is in a first connection state, that is, it is determined that the intelligent driving domain controller is in a vehicle-mounted debugging state, and at this time, the working log is uploaded to the outside through a first protocol. When a low load rate is detected, it is determined that the intelligent driving domain controller is in a second connection state, that is, it is determined that the intelligent driving domain controller is in a vehicle-dismounted debugging state, and the original log is directly output to the outside through a second protocol after level conversion. In the embodiment, the first protocol is an Ethernet protocol, and the second protocol is a UART protocol.
[0075] When the intelligent driving domain controller is in the first connection state, the MCU module 30 obtains the pre-processed working log information of the intelligent driving domain controller through the data backfilling module 20, compresses and encrypts the working log information, and caches the compressed and encrypted working log information in a storage space dedicated to the MCU module 30, and then transmits the working log information in the storage space to the cloud server 70 through the vehicle-mounted communication module T-BOX 60.
[0076] When the intelligent driving domain controller is in the second connection state, the working log information is transmitted to the DEBUG interface through the second protocol, and the working log information is transmitted to the host computer 80 by using the DEBUG interface. The working log can be collected in real time in the host computer 80 to start data monitoring and working process debugging data analysis.
[0077] Please combine Figure 5 , Figure 5 The structure of the data backfilling module 20 of the application is shown.
[0078] In some embodiments, the data backfilling module 20 includes a data switching and shunting unit 22, a level conversion unit 21 and a control unit 23.
[0079] The data switching and shunting unit 22 is configured to establish the first transmission channel COM1 and the second transmission channel COM2 which are isolated from each other. The level conversion unit 21 is configured to cooperate with the data switching and shunting unit 22 to perform first level conversion on the original log information to access the first transmission channel COM1 and perform second level conversion on the original log information to access the second transmission channel COM2. The control unit 23 is configured to select and control the conduction of the first transmission channel COM1 and the second transmission channel COM2 according to a preset instruction, and control the level conversion mode of the level conversion unit 21.
[0080] Specifically, the level conversion unit 21 refers to an interface circuit for adjusting the signal voltage range, which can be implemented by using multiple level conversion chips or a voltage dividing resistor network. Under different control instructions, the level conversion unit 21 can perform different level conversions. The data switching and shunting unit 22 refers to a hardware circuit for creating a physically isolated transmission path, which can be implemented by using a multiplexer or an isolated signal distributor. Under the control of the control unit 23, the first transmission channel COM1 or the second transmission channel COM2 is selectively opened.
[0081] The control unit 23 refers to a processor module for executing channel switching logic, which can be implemented by using a microcontroller or a programmable logic device.
[0082] The preset instruction can be an IIC communication instruction. When the intelligent driving domain controller is in a vehicle-mounted debugging state, the control unit 23 receives a CAN bus 40 load rate detection result as the preset instruction, triggers the conduction of the first transmission channel COM1, and activates the first level conversion mode. At this time, the original log signal is converted into a format conforming to the input level of the MCU module 30, and is directly transmitted to the MCU through the isolated first transmission channel COM1 for cache processing. When it is detected that the system is switched to an offline debugging state, the control unit 23 automatically switches to the second transmission channel COM2, and the level conversion unit 21 adjusts the signal to conform to the TTL level standard of the UART interface, so that the log information can be transmitted to the host computer 80 in real time through the DEBUG interface.
[0083] In some embodiments, the data backfilling module 20 further includes an interface protection unit 24.
[0084] The interface protection unit 24 is connected to the first transmission channel COM1 and the second transmission channel COM2, and is configured to protect the backfilling module.
[0085] Specifically, the interface protection unit 24 refers to a circuit protection component arranged on the data transmission path, which can be implemented by using a combination of a TVS diode and a filter capacitor, and is configured to suppress voltage surges and electromagnetic interference in the transmission process.
[0086] The above system completes log channel preparation before SOC starts through the MCU module front-end processing mechanism, ensures complete capture of logs in the starting stage. The dynamic protocol selection mechanism can intelligently switch transmission modes according to the actual CAN bus load rate, for example, adopts buffer compression transmission to reduce bus pressure in the loading scene, and enables direct transmission protocol to improve the debugging efficiency in the unloading scene. The problem of log loss in the initial stage of the SOC module start is effectively avoided, and adaptive switching of the loading and unloading debugging scenes is realized; the preprocessing mechanism of the data backfill module adapts the log format to the requirements of different transmission protocols, the buffer strategy relieves the bus congestion in the high-load scene, and the direct transmission mode meets the real-time requirements of offline debugging; the dual-channel isolation design guarantees the stability of different level signal transmission, and solves the problem of SOC module log information loss in the initial stage of the traditional scheme.
[0087] Embodiment 3 Figure 6 The structure diagram of the embodiment of the intelligent driving domain controller is shown, and the specific implementation of the intelligent driving domain controller is not limited in the specific embodiments of the application.
[0088] As shown in Figure 6 An intelligent driving domain controller can include a processor 601, a communications interface 602, a memory 603, and a communications bus 604.
[0089] The processor 601, the communications interface 602, and the memory 603 can communicate with each other through the communications bus 604. The communications interface 602 is configured to communicate with network elements such as an intelligent driving domain controller or other servers. The processor 601 is configured to execute the program 610, and when executed, implements the steps of the log storage method described above to store the log.
[0090] Specifically, the program 610 can include program code including computer executable instructions.
[0091] Specifically, the processor 601 can be a central processing unit CPU, or an application specific integrated circuit ASIC, or one or more integrated circuits configured to implement embodiments of the application. The one or more processors of the intelligent driving domain controller can be the same type of processor, such as one or more CPUs; or can be different types of processors, such as one or more CPUs and one or more ASICs.
[0092] A memory 603 for storing a program 610. The memory 603 can include a high-speed RAM memory, and can also include a non-volatile memory, such as at least one disk memory.
[0093] The program 610 can specifically be called by the processor 601 to make the intelligent driving domain controller perform the following operations: Receive a wake-up signal through the MCU module; Wake up the SOC module through the MCU module, and determine the connection state of the intelligent driving domain controller, and pre-process the original log information of the SOC module to obtain working log information; When the intelligent driving domain controller is in a first connection state, cache the working log information through the MCU module, and transmit the working log information externally through a first protocol; when the intelligent driving domain controller is in a second connection state, transmit the working log information externally through a second protocol.
[0094] The above data flow is consistent with the data flow of Embodiment 1, and specific reference can be made to the description of Embodiment 1, which will not be described here.
[0095] In an optional implementation, the program 610 is called by the processor 601 to make the intelligent driving domain controller perform the specific sub-steps of steps 120 and 130 in Embodiment 1.
[0096] The above intelligent driving domain controller uses an MCU module front-end processing mechanism to complete log channel preparation before the SOC starts, and ensures complete capture of logs in the starting stage. A dynamic protocol selection mechanism can intelligently switch transmission modes according to the actual CAN bus load rate, for example, using cache compression transmission to reduce bus pressure in the vehicle installation scene, and enabling direct transmission protocol to improve debugging efficiency in the vehicle removal scene. The problem of log loss in the initial stage of the SOC module is effectively avoided, and adaptive switching of the vehicle installation and removal debugging scenes is realized; the preprocessing mechanism of the data backfill module adapts the log format to the requirements of different transmission protocols, the cache strategy alleviates the bus congestion in the high-load scene, and the direct transmission mode meets the real-time requirements of offline debugging; the dual-channel isolation design ensures the stability of different level signal transmission, and solves the problem of log information loss of the SOC module in the initial stage of the traditional scheme.
[0097] Embodiment 4: The embodiment of the application provides a computer readable storage medium, the storage medium stores at least one executable instruction, the executable instruction runs on the intelligent driving domain controller, and makes the intelligent driving domain controller execute the log storage method in any method embodiment.
[0098] The executable instruction can be specifically used to make the intelligent driving domain controller perform the following operations: receive the wake-up signal through the MCU module; wake up the SOC module through the MCU module, and determine a connection state of the intelligent driving domain controller, and pre-process original log information of the SOC module to obtain working log information; when the intelligent driving domain controller is in a first connection state, cache the working log information through the MCU module, and transmit the working log information to the outside through a first protocol; and when the intelligent driving domain controller is in a second connection state, transmit the working log information to the outside through a second protocol.
[0099] Through the MCU module pre-processing mechanism, log channel preparation is completed before the SOC starts, ensuring complete capture of logs in the starting stage. The dynamic protocol selection mechanism can intelligently switch the transmission mode according to the actual CAN bus load rate, for example, using cache compression transmission to reduce bus pressure in the vehicle installation scene, and enabling direct transmission protocol to improve debugging efficiency in the vehicle disassembly scene. The problem of log loss in the initial stage of the SOC module is effectively avoided, and adaptive switching of the vehicle installation and disassembly debugging scenes is realized; the preprocessing mechanism of the data backfill module adapts the log format to the requirements of different transmission protocols, the cache strategy alleviates the bus congestion in the high-load scene, and the direct transmission mode meets the real-time requirements of offline debugging; the dual-channel isolation design ensures the stability of different level signal transmission, solving the problem of SOC module log loss in the initial stage of the traditional solution.
[0100] The algorithms and displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Furthermore, embodiments of the application are not described with reference to any particular programming language.
[0101] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the application can be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been described in detail in order to avoid obscuring the application. Also, the description occasionally mentions specific implementation of the application as a method, an apparatus, and / or a computer program product. It is understood that various
[0102] As will be appreciated by one skilled in the art, aspects of the embodiments can be embodied as a device, a method or a computer program product. Accordingly, aspects of the present embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present embodiments can take the form of a computer program product embodied in one or more computer- readable medium(s) having computer readable program code embodied thereon.
[0103] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of both hardware and software, and any combination thereof. In a unitary claim, several devices, systems or means can be listed, comprising means for carrying out a certain task. The use of the term'means' in a claim is intended to refer to a combination of devices, systems or means for performing a task. The word 'first','second', 'third', etc. do not imply any order. The use of these terms is to be construed as use of the terms 'first','second', 'third', etc. to name the names. The steps of the above-described embodiments, unless otherwise specified, are not to be construed as limiting the order of execution.
Claims
1. A log storage method, characterized in that, Used to store the working log information generated by the intelligent driving domain controller, including: Receive the wake-up signal via the MCU module; The MCU module wakes up the SOC module and determines the connection status of the intelligent driving domain controller. The original log information of the SOC module is preprocessed to obtain the working log information. When the intelligent driving domain controller is in the first connection state, the working log information is cached by the MCU module and transmitted to the outside via the first protocol; when the intelligent driving domain controller is in the second connection state, the working log information is transmitted to the outside via the second protocol.
2. The log storage method according to claim 1, characterized in that, The raw log information of the SOC module is preprocessed to obtain working log information, including the following sub-steps: Establish a first and second transmission channel that are mutually isolated from each other; The original log information is subjected to a first level conversion to access the first transmission channel, and the original log information is subjected to a second level conversion to access the second transmission channel; Based on the connection status of the intelligent driving domain controller, the first output channel or the second output channel is selected to output the original log information after level conversion, so as to form the output work log information.
3. The log storage method according to claim 1, characterized in that, When the intelligent driving domain controller is in the first connection state, the MCU module caches the work log information and transmits the work log information externally through the first protocol, including the following sub-steps: The work log information is obtained through the MCU module; The work log information is compressed and encrypted; The compressed and encrypted work log information is cached in the dedicated storage space of the MCU module; The working log information in the storage space is forwarded to the cloud server via the vehicle communication module through the first transmission protocol.
4. The log storage method according to claim 1, characterized in that, The step of transmitting the work log information externally via the second protocol includes the following sub-steps: The work log information is transmitted to the DEBUG interface via the second protocol, and then transmitted to the host computer via the debug interface.
5. The log storage method according to claim 1, characterized in that, The first protocol is the Ethernet protocol; the second protocol is the UART protocol.
6. The log storage method according to claim 1, characterized in that, The first connection state is when the intelligent driving domain controller is in a connected state where the system is online, and the second connection state is when the intelligent driving domain controller is in a connected state where the system is offline for debugging.
7. The log storage method according to claim 1, characterized in that, Determining the connection status of the intelligent driving domain controller includes: The MCU module invokes the CAN bus to transmit data. Detect the load rate of the data transmitted on the CAN bus; When the load rate is higher than a preset value, the bracket domain controller is determined to be in the first connection state; otherwise, the intelligent driving domain controller is determined to be in the second connection state.
8. A log storage system, characterized in that, Used to store the working log information generated by the intelligent driving domain controller, including: The SOC module is used to respond to the wake-up signal and generate the raw log information of the intelligent driving domain controller; The data feedback module is used to receive the original log information and, based on the connection status of the intelligent driving domain controller, preprocess the original log information of the SOC module to obtain working log information. The MCU module is used to wake up the SOC module and determine the connection status of the intelligent driving domain controller. When the intelligent driving domain controller is in the first connection state, the MCU module caches the work log information and transmits the work log information to the outside through the first protocol. When the intelligent driving domain controller is in the second connection state, the work log information is transmitted to the outside through the second protocol.
9. The log storage system according to claim 8, characterized in that, The data feedback module includes: The data switching and distribution unit is used to establish a first and second transmission channel that are mutually isolated from each other. A level conversion unit is used to perform a first level conversion on the original log information to access the first transmission channel, and to perform a second level conversion on the original log information to access the second transmission channel; The control unit is used to select and control the conduction of the first transmission channel and the second transmission channel according to preset instructions, and to control the level conversion mode of the level conversion unit.
10. The log storage system according to claim 9, characterized in that, It also includes an interface protection unit, connected to the first transmission channel and the second transmission channel, for protecting the recharge module.
11. A smart driving domain controller, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the log storage method as described in any one of claims 1 to 7 to store the log.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the device containing the computer-readable storage medium executes the computer program, it implements the log storage method as described in any one of claims 1 to 7.