Instrument log data transmission method and system

Abstract

The invention discloses an instrument log data transmission method and system, and the method comprises the steps: enabling vehicle equipment to judge whether a historical breakpoint pointer exists in a log file region or not when the network state of a current vehicle meets a preset triggering condition, and enabling the historical breakpoint pointer to be determined according to a historical transmitted log data block; when the historical breakpoint pointer exists, the in-vehicle machine equipment reads the to-be-transmitted log data block at the historical breakpoint pointer, packages the to-be-transmitted log data block into a to-be-transmitted data frame, and sends the to-be-transmitted data frame to the cloud server; and the cloud server restores the to-be-transmitted data frame into the to-be-transmitted log data block, and obtains an original log file of the current vehicle based on the to-be-transmitted log data block. The transmission can be recovered from the historical breakpoint pointer after the transmission is interrupted, so that the log data which is successfully uploaded is prevented from being repeatedly sent, and the log data transmission efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a method and system for transmitting instrument log data. Background Technology

[0002] In the field of automotive electronics, electronic control units (ECUs) such as vehicle instrument clusters generate a large amount of log data during operation. This log data is crucial for post-fault diagnosis, system status monitoring, and user experience optimization. As vehicles become increasingly intelligent, the total amount of log data also continues to increase. Since the storage space of the log file area within the vehicle instrument cluster is limited and requires cyclic overwriting, the log data can be transferred to a cloud server for storage.

[0003] Currently, common log transmission solutions typically rely on traditional vehicular network protocols for data transmission and employ a restart and retransmission mechanism to recover after transmission interruptions. However, due to frequent starts and stops of vehicles in actual use, unstable power supply can easily lead to transmission interruptions. Traditional methods often require re-initiating transmission from the data start point after power is restored, which not only wastes network bandwidth and time but also reduces the efficiency of log data transmission. Summary of the Invention

[0004] The main purpose of this application is to provide an instrument log data transmission method and system, which aims to solve the technical problem that the log data transmission efficiency is low when the vehicle log data is recovered by restarting and retransmitting after the transmission is interrupted.

[0005] To achieve the above objectives, this application proposes an instrument log data transmission method, which is applied to an instrument log data transmission system. The system includes: an in-vehicle infotainment device and a cloud server communicatively connected to the in-vehicle infotainment device; the method includes: When the network status of the current vehicle meets the preset triggering conditions, the vehicle-mounted device determines in the log file area whether there is a historical breakpoint pointer. The historical breakpoint pointer is determined based on the historically transmitted log data blocks. When a historical breakpoint pointer exists, the vehicle-mounted device reads the log data block to be transmitted at the historical breakpoint pointer, encapsulates the log data block to be transmitted into a data frame to be transmitted, and sends the data frame to be transmitted to the cloud server. The cloud server restores the data frame to be transmitted into the log data block to be transmitted, and obtains the original log file of the current vehicle based on the log data block to be transmitted.

[0006] In one embodiment, the step of the vehicle-mounted device determining whether a historical breakpoint pointer exists in the log file area when the current network status of the vehicle meets a preset trigger condition includes: Monitor the network status of the current vehicle and determine whether the network status of the current vehicle meets the preset trigger conditions. The preset trigger conditions include: application layer idle condition, bus low load condition, and pre-sleep condition. When the network status of the current vehicle meets the preset triggering conditions, a data transmission command is generated; In response to the data transmission instruction, determine whether a historical breakpoint pointer exists in the log file area of ​​the current vehicle.

[0007] In one embodiment, the step of the vehicle-mounted device reading the log data block to be transmitted at the historical breakpoint pointer and encapsulating the log data block to be transmitted into a data frame to be transmitted when a historical breakpoint pointer exists includes: When a historical breakpoint pointer exists, the log data block at the historical breakpoint pointer is identified as the log data block to be transmitted. The log blocks to be transmitted are encapsulated into data frames to be transmitted based on the preset CAN FD bus protocol. The data frames to be transmitted are constructed based on the CAN FD frame structure, which includes a frame header, a transmission counter, and a data payload.

[0008] In one embodiment, the step of sending the data frame to be transmitted to the cloud server includes: Obtain the current load rate of the CAN FD bus, determine whether the current load rate is less than the preset maximum load value, and obtain the determination result; The transmission interval is adjusted according to the judgment result, and the data frame to be transmitted is sent to the cloud server through the CAN FD bus and the preset communication network based on the adjusted transmission interval.

[0009] In one embodiment, the data frame to be transmitted is constructed based on the CAN FD frame structure, including: a frame header, a transmission counter, and a data payload; the step of the cloud server restoring the data frame to be transmitted into the log data block to be transmitted, and obtaining the original log file of the current vehicle based on the log data block to be transmitted, includes: The data payload of the data frame to be transmitted is parsed to determine the corresponding frame sequence number, and the data frame to be transmitted is spliced ​​together according to the frame sequence number to obtain the log data block to be transmitted. The original log file of the current vehicle is obtained by writing the log data blocks to be transmitted and the historically transmitted data blocks into the initialization file in the order of the transmission counter.

[0010] In one embodiment, before the step of writing the log data blocks to be transmitted and the historically transmitted data blocks into the initialization file according to the sending counter order, the method further includes: When the cloud server receives the data frame to be transmitted, it determines the transmission counter corresponding to the data frame to be transmitted. Obtain the transmission counter corresponding to the transmitted data frame, and determine whether there is a data block loss based on the transmission counter corresponding to the transmitted data frame and the transmission counter corresponding to the data frame to be transmitted. The transmitted data frame corresponds to a historically transmitted data block. If it is determined that no data block is lost, a feedback message indicating that the log data block to be transmitted has been successfully transmitted is sent to the vehicle-mounted device, and the process returns to the step of writing the log data block to be transmitted and the historically transmitted data blocks into the initialization file in the order of the transmission counter.

[0011] In one embodiment, after the cloud server obtains the original log file of the current vehicle by writing the log data blocks to be transmitted and the historically transmitted data blocks into an initialization file according to the sending counter order, the method further includes: The cloud server reads the original log file through a preset log content parser and parses the original log file into plaintext log according to a preset parsing format; In response to a user-triggered log query command, the plaintext log is displayed to the user.

[0012] In one embodiment, after the step of determining whether data block loss has occurred, the method further includes: When the cloud server determines that a data block is lost, it generates a retransmission command and sends the retransmission command to the vehicle-mounted device. When the vehicle-mounted device receives the retransmission instruction, it determines the log data block to be retransmitted and sends the log data block to be retransmitted to the cloud server.

[0013] In addition, to achieve the above objectives, this application also proposes an instrument log data transmission system, the system including a vehicle-mounted device and a cloud server communicatively connected to the vehicle-mounted device; The vehicle-mounted device is used to determine whether there is a historical breakpoint pointer in the log file area when the current network status of the vehicle meets the preset trigger conditions. The historical breakpoint pointer is determined based on the transmitted data log blocks. The vehicle-mounted device is used to read the log data block to be transmitted at the historical breakpoint pointer when a historical breakpoint pointer exists, encapsulate the log data block to be transmitted into a data frame to be transmitted, and send the data frame to be transmitted to the cloud server. The cloud server is used to restore the data frame to be transmitted into the log data block to be transmitted, and to obtain the original log file of the current vehicle based on the log data block to be transmitted.

[0014] This application discloses an instrument log data transmission method, applied to an instrument log data transmission system including a vehicle-mounted device and a cloud server. The method includes: when the network status of the current vehicle meets a preset trigger condition, the vehicle-mounted device determines whether a historical breakpoint pointer exists in the log file area, the historical breakpoint pointer being determined based on historically transmitted log data blocks; when a historical breakpoint pointer exists, the vehicle-mounted device reads the log data block to be transmitted at the historical breakpoint pointer, encapsulates the log data block to be transmitted into a data frame to be transmitted, and sends the data frame to be transmitted to the cloud server; the cloud server restores the data frame to be transmitted into a log data block to be transmitted, and obtains the original log file of the current vehicle based on the log data block to be transmitted.

[0015] Because this application can resume transmission from the historical breakpoint pointer after a transmission interruption, it avoids retransmitting successfully uploaded log data, thereby improving data transmission efficiency and reducing network resource and time consumption caused by frequent vehicle starts and stops. Simultaneously, by encapsulating the log data blocks to be transmitted into data frames, and having the cloud server restore them to the original log file, it ensures the integrity and order of data during transmission and reassembly, thus improving the accuracy and usability of the log files obtained by the cloud server. Attached Figure Description

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

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

[0018] Figure 1 This is a flowchart illustrating the first embodiment of the instrument log data transmission method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the instrument log data transmission method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the instrument log data transmission method of this application; Figure 4 This is a schematic diagram of the data processing flow of the cloud server in this application; Figure 5This is a schematic diagram of data interaction in the instrument log data transmission system of this application.

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

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

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

[0022] This application provides a method for transmitting instrument log data, referencing... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the instrument log data transmission method of this application. In this embodiment, the method is applied to an instrument log data transmission system, which includes a vehicle-mounted device and a cloud server. The method includes steps S10-S30: Step S10: When the network status of the current vehicle meets the preset triggering conditions, the vehicle-mounted device determines whether there is a historical breakpoint pointer in the log file area. The historical breakpoint pointer is determined based on the historically transmitted log data blocks.

[0023] It should be noted that the in-vehicle infotainment system can include a data source and an in-vehicle hub. The data source can be the instrument cluster ECU, which integrates intelligent transmission client software responsible for log generation, storage, encapsulation, and transmission. The in-vehicle hub can be a gateway device (in-vehicle T-Box) with integrated T-Box functionality, used to receive data from the instrument cluster ECU and send it to the cloud server. Within the in-vehicle infotainment system, data transmission between the instrument cluster ECU and the in-vehicle T-Box can be achieved using a CAN FD bus. Compared to traditional CAN bus routing, this improves data transmission efficiency.

[0024] A cloud server can be a large computing service device used to receive data streams from a large number of vehicles. It can also persistently store the received raw data and implement parsing functions such as protocol parsing, data reconstruction, verification and text parsing through a pre-configured core computing engine, and finally output a readable log file.

[0025] It should be understood that the network status can refer to the current management status of the vehicle's internal communication network (CAN network), such as whether it is in "Repeat Message" state, the bus load rate, whether the application layer is idle, or whether it is about to enter sleep mode. The preset trigger conditions are a set of pre-defined logical rules used to determine when it is a safe and efficient time for instrument log transmission, ensuring that log data transmission does not interfere with critical vehicle control commands.

[0026] For example, the preset triggering condition can be: the vehicle's state machine is in the Repeat Message state and simultaneously meets the conditions of application layer idle, CAN FD bus load rate low, and about to enter sleep mode.

[0027] Understandably, the log file area can be a specific storage space allocated in non-volatile memory by the vehicle's infotainment system for cyclically recording vehicle operation logs. When the instrument cluster ECU in the vehicle starts, it can allocate a cyclic log file area in non-volatile memory and initialize the current write pointer, the real-time upload breakpoint pointer, and the global continuous transmission counter (Tx_Counter).

[0028] Accordingly, the historical breakpoint pointer can be a location marker (such as a memory address or file offset) that has been stored in the vehicle's infotainment system at a historical moment. It can point to the position where the last successful transmission of the log file ended in the log file area. The historically transmitted log data block is the data block corresponding to the log file that was successfully sent to the cloud at a historical moment. The historical breakpoint pointer is determined based on this historically transmitted log data block.

[0029] In practice, each time the vehicle-mounted device starts a transmission task, it can first check whether there is a historical breakpoint pointer in the log file area. If it exists, it means that the previous log file transmission was not completed, and the transmission can start from the log file at the breakpoint; otherwise, the log file transmission will start from the beginning.

[0030] Furthermore, to specifically explain how to determine the triggering time of the transmission task, step S10 specifically includes: steps S101~S103: Step S101: Monitor the network status of the current vehicle and determine whether the network status of the current vehicle meets the preset triggering conditions.

[0031] It should be noted that the vehicle's infotainment system can continuously monitor the Network Management (NM) state machine of the Vehicle Controller Area Network (CAN). This NM state manages the communication sleep and wake-up of the Electronic Control Units (ECUs) on the entire CAN network. By monitoring the NM state machine, it is possible to capture, for example, the state transition of the CAN network from normal operating mode to sleep preparation mode.

[0032] It should be understood that the preset triggering conditions may include: application layer idle conditions, bus low load conditions, and pre-sleep conditions. The vehicle-mounted device can determine to start the transmission task only when the current network status of the vehicle meets the above three conditions simultaneously, thereby not affecting the normal operation of the current vehicle and ensuring seamless log transmission.

[0033] Specifically, the application-layer idle condition means that the main applications running on the vehicle's infotainment devices (such as the instrument cluster ECU) (e.g., vehicle speed, RPM display, warning light control, etc.) are not performing high-priority, real-time critical tasks. This ensures that log transmission tasks do not compete with the vehicle's core display and alarm functions for CPU and memory resources, thus avoiding impacting driver experience and driving safety.

[0034] The low-load condition for the bus refers to a condition where the real-time communication load rate of the CAN FD bus is lower than a set safety threshold. The load rate is an indicator of the data traffic saturation on the CAN FD bus. This ensures that log transmission does not consume excessive bus bandwidth, thereby avoiding interference with the timely transmission of life-threatening or safety-critical real-time control messages such as engine control, anti-lock braking system (ABS), and electronic stability program (ESP).

[0035] The pre-sleep condition typically refers to the CAN network management state machine entering the "Repeat Message" state or a similar state after the vehicle is turned off or parked. This indicates that all ECUs within the vehicle have completed their current work cycle, are synchronizing, and are preparing to collectively enter a low-power sleep mode. This ensures that the vehicle is stopped, the power supply is relatively stable (not completely cut off), and the network is about to become idle, providing a safe, dedicated, and low-power window for transmitting large amounts of log data.

[0036] Step S102: When the network status of the current vehicle meets the preset triggering conditions, a data transmission instruction is generated.

[0037] In practice, when the current network status of the vehicle simultaneously meets the above-mentioned application layer idle condition, bus low load condition, and pre-sleep condition, the vehicle-mounted equipment can generate a data transmission command to determine the start of the log transmission task.

[0038] Step S103: In response to the data transmission instruction, determine whether there is a historical breakpoint pointer in the log file area of ​​the current vehicle.

[0039] It should be understood that when determining to start the log transmission task, the vehicle-mounted device can check whether there are historical breakpoint pointers in the fixed storage area (log file area) used for cyclic recording of logs in the vehicle's non-volatile memory (such as Flash).

[0040] It should be noted that the historical breakpoint pointer can be calculated by the vehicle's device based on the position of the historically transmitted log data blocks before the last log file was successfully sent or entered hibernation, and is persistently stored in the log file area.

[0041] It should be understood that if a historical breakpoint pointer exists, it indicates that the historical transmission was not completed, meaning that the current log transmission task should continue from the breakpoint. If no historical breakpoint pointer exists (e.g., the historical breakpoint pointer is initially NULL, or the log file is brand new), it means that this log transmission task is the first transmission or does not need to be continued, and the transmission can start from the initial data block of the log file within the log file area.

[0042] Step S20: When a historical breakpoint pointer exists, the vehicle-mounted device reads the log data block to be transmitted at the historical breakpoint pointer, encapsulates the log data block to be transmitted into a data frame to be transmitted, and sends the data frame to be transmitted to the cloud server.

[0043] It should be noted that the vehicle-mounted device can start reading the next segment of log data to be transmitted, i.e., the log data block to be transmitted, from the corresponding position in the log file area based on the historical breakpoint position.

[0044] It should be understood that in order to send log data blocks from the instrument cluster ECU to the vehicle T-Box, the data blocks can be encapsulated into CAN FD frames according to a dedicated application layer protocol, so as to realize the transmission of log data blocks between the instrument cluster ECU and the vehicle T-Box based on the CAN FD bus.

[0045] The frame structure of a CAN FD frame can include a frame header, a transmit counter (Tx_Counter), and a data payload. If the log data block is large, it can be split into a first frame (FF) and multiple consecutive frames (CF), with all frames sharing the same Tx_Counter value.

[0046] In a practical implementation, the data frames encapsulated from the log data blocks in the vehicle's infotainment system can be sent from the instrument cluster ECU to the vehicle's T-Box via the CAN FD bus; and then forwarded by the vehicle's T-Box to the cloud server via, for example, a pre-configured communication network (such as a cellular network).

[0047] Step S30: The cloud server restores the data frame to be transmitted into the log data block to be transmitted, and obtains the original log file of the current vehicle based on the log data block to be transmitted.

[0048] It should be noted that after receiving a data frame, the cloud server can perform a reverse operation: parse the data frame to obtain information such as the frame sequence number and Tx_Counter; then group the data frame according to the Tx_Counter, and then splice all the consecutive frames in the correct order according to the frame sequence number in the group to restore the complete log data block to be transmitted.

[0049] It should also be noted that after the vehicle-mounted device sends the data frame to be transmitted to the cloud server, the method further includes: when the vehicle-mounted device receives feedback information that the log data block to be transmitted has been successfully transmitted, it determines that the log data block to be transmitted is the latest transmitted log data block, and updates the position of the historical breakpoint pointer according to the latest transmitted log data block.

[0050] It should be noted that this feedback information can be the information that the cloud server sends back to the vehicle's infotainment system when it receives the data frame to be transmitted.

[0051] Specifically, after the cloud server reconstructs the complete log data block to be transmitted, it sends a feedback message to the vehicle's T-Box via a preset communication network. The vehicle's T-Box then transmits the feedback message to the instrument cluster ECU via the CAN FD bus. This feedback message may include the Tx_Counter value of the aforementioned log data block to be transmitted.

[0052] It should be understood that when the vehicle-mounted device receives feedback information, it can parse the Tx_Counter value, identify the corresponding log data block in the log file area as the latest transmitted log data block, and determine the starting address of the next data to be transmitted based on the end position of the log data block in the log file area, thereby determining the position of the new historical breakpoint pointer.

[0053] It should also be noted that the updated historical pointer can be written to the vehicle's non-volatile memory (such as Flash), ensuring that the log file transmission progress is not lost after the vehicle is completely powered off. When the log transmission task is triggered again, the updated historical breakpoint pointer is read to determine where to continue sending log data, thus achieving breakpoint resumption and avoiding the duplication of successfully transmitted log data.

[0054] Next, the cloud server can perform file reconstruction based on the log data blocks to be transmitted: following the order of Tx_Counter, the restored log data blocks are written to a cloud file in sequence, and the final cloud file is consistent with the original and complete log file in the vehicle device in terms of content.

[0055] It should also be noted that during the aforementioned reconstruction process, the cloud server can check the continuity of Tx_Counter. If there is a sequence number jump (for example, receiving data blocks with Tx_Counter values ​​of 1, 2, and 4, but missing 3), then data block 3 is determined to be lost. In this case, the cloud server can send a retransmission request to the vehicle's infotainment system via the downlink, specifying the lost Tx_Counter value, thereby forming a closed-loop control system to ensure data integrity.

[0056] Ultimately, the reconstructed file can be used as the original log file for fault diagnosis and analysis.

[0057] This embodiment can resume transmission from the historical breakpoint pointer after a transmission interruption, avoiding the retransmission of successfully uploaded log data, thereby improving data transmission efficiency and reducing network resource and time consumption caused by frequent vehicle starts and stops. Simultaneously, by encapsulating the log data blocks to be transmitted into data frames, and having the cloud server restore them to the original log file, the integrity and order of data during transmission and reassembly are ensured, thus improving the accuracy and usability of the log files obtained by the cloud server.

[0058] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the instrument log data transmission method of this application.

[0059] In this embodiment, to illustrate how to encapsulate log data blocks into data frames and send them to the cloud server, step S20 includes: steps S201~S204: Step S201: When a historical breakpoint pointer exists, the log data block at the historical breakpoint pointer is determined as the log data block to be transmitted.

[0060] It should be noted that the vehicle-mounted device can use the log data block at the historical breakpoint pointer as the starting point for this log transmission task. The log data block can be the smallest unit of log transmission.

[0061] In a practical implementation, if a historical breakpoint pointer exists in the log file area, then the log data block corresponding to the historical breakpoint pointer can be determined as the log data block to be transmitted at the starting point of this log transmission task.

[0062] Step S202: Based on the preset CAN FD bus protocol, the log blocks to be transmitted are encapsulated into data frames to be transmitted, and the data frames to be transmitted are constructed based on the CAN FD frame structure.

[0063] It should be understood that the default CAN FD bus protocol can be an application layer protocol designed based on the CAN FD network that communicates between the instrument cluster ECU and the vehicle's T-Box. It specifies how log data blocks are adapted to the physical and data link layers of CAN FD for transmission, defining frame formats, segmentation rules, control fields, etc.

[0064] It should be noted that the CAN FD frame structure may include: a frame header, a transmit counter (Tx_Counter), and a data payload.

[0065] The frame header may include a standard or extended CAN ID (to identify this frame as a log transmission frame), a Data Length Code (DLC) (indicating the number of bytes in the data segment; CAN FD allows a maximum of 64 bytes), and control bits specific to CAN FD, such as Bit Rate Switching (BRS) and Error Status (ESI) flags. It is used to provide network addressing, frame attribute definition, and basic control functions.

[0066] Tx_Counter can be located at the beginning of the data payload portion of a frame and is part of the application layer protocol header. Tx_Counter is a globally continuously incrementing counter value, and all subframes obtained from splitting the same log data block share the same Tx_Counter value.

[0067] Regarding the data payload, for the first frame (FF), in addition to Tx_Counter, the data payload may also include information such as the total length of data blocks, the total number of segments, and the specific log data. For consecutive frames (CF), the data payload may mainly include the segment sequence number and the subsequent specific log data.

[0068] It should be understood that if the log data block to be transmitted is large and exceeds the payload capacity of a single CAN FD frame, the log data block can be segmented and encapsulated: it can be split into one FF and several CFs; all subframes (FF and CF) use the same CAN ID and the same Tx_Counter; each subframe is distinguished by the segment sequence number in the application layer protocol header to determine its order within the log data block.

[0069] Step S203: Obtain the current load rate of the CAN FD bus, and determine whether the current load rate is less than the preset maximum load value, and obtain the determination result.

[0070] It should be noted that the current load rate represents the percentage of time the CAN FD bus is actually used for data transmission within a specific time window. This reflects the CAN FD bus's activity level and remaining bandwidth. Vehicle-mounted equipment can obtain the current CAN FD bus load rate in real time by monitoring the CAN controller status or using bus analysis tools.

[0071] It should be understood that the preset maximum load value can be one or more pre-defined safety thresholds (e.g., 30% or 60%). By setting this safety threshold, sufficient low-latency bandwidth can be reserved for high-priority vehicle control messages (such as braking and steering commands), ensuring that vehicle functional safety is not affected by log transmission.

[0072] In the specific implementation, the current load rate is compared with the security threshold. If the load rate is less than the security threshold, the result is to allow sending or send at high speed; if the load rate is greater than or equal to the security threshold, the result is to pause sending or send at low speed.

[0073] Step S204: Adjust the transmission interval according to the judgment result, and based on the adjusted transmission interval, send the data frame to be transmitted to the cloud server through the CAN FD bus and the preset communication network.

[0074] It should be understood that the transmission interval can be the time delay between two consecutive data frames sent from the instrument cluster ECU to the vehicle's T-Box. Based on the judgment results obtained from the comparison between the current load rate and the safety threshold, the transmission interval can be dynamically adjusted.

[0075] For example, under low load (e.g., current load rate <30%): the instrument ECU can use shorter transmission intervals (high rate) to quickly utilize idle bandwidth and improve transmission efficiency.

[0076] At medium loads (e.g., 30% < current load rate < 60%): the instrument ECU uses a longer transmission interval (lower rate) to gently utilize the CAN FD bus and avoid pushing up the load.

[0077] Under high load (≥ maximum load value): the instrument ECU can pause transmission and immediately relinquish CAN FD bus resources to prioritize the protection of critical vehicle messages.

[0078] It should also be noted that the default communication network is the communication connection network between the vehicle-mounted device (vehicle-mounted T-Box) and the cloud server, which can be a cellular network, such as 4G / 5G network.

[0079] In practice, the instrument ECU can send the data frame to be transmitted to the vehicle T-Box via the CAN FD bus to realize in-vehicle data transmission; then the vehicle T-Box can forward the data frame to be transmitted to the cloud server through a preset communication network, thus realizing data transmission between the vehicle and the cloud.

[0080] This embodiment uses historical breakpoint pointers to determine the starting position of the log data block to be transmitted and encapsulates it based on a dedicated CAN FD frame structure containing a transmission counter, achieving breakpoint resumption and precise identification of data blocks. Simultaneously, by acquiring the CAN FD bus load rate in real time and dynamically adjusting the transmission interval, adaptive rate control is achieved. This avoids duplicate data transmission caused by vehicle start-stop, improving transmission efficiency; ensures that data blocks can be correctly sorted and reassembled in the cloud, guaranteeing data integrity; and by yielding bus bandwidth priority, prevents log transmission from interfering with critical vehicle control messages, enhancing system security.

[0081] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the instrument log data transmission method of this application.

[0082] In this embodiment, to specifically illustrate how to reconstruct the log file, step S30 includes: steps S301~S302: Step S301: Parse the data payload of the data frame to be transmitted to determine the corresponding frame sequence number, and splice the data frame to be transmitted according to the frame sequence number to obtain the log data block to be transmitted.

[0083] It should be noted that the data frame to be transmitted is constructed based on the CAN FD frame structure, which includes: frame header, transmission counter and data payload.

[0084] Therefore, the transmit counter (Tx_Counter) in the data frame to be transmitted can distinguish different log data blocks; the data payload of the data frame to be transmitted can contain segment sequence numbers (e.g., first frame FF / sequential frame sequence numbers), i.e., frame sequence numbers, which are used to indicate the order of the data frame within the same log data block identified by Tx_Counter.

[0085] In the specific implementation, the cloud server can parse the Tx_Counter and frame sequence number from the data frame to be transmitted. First, the data frame to be transmitted is grouped according to Tx_Counter. Then, under the same Tx_Counter, the data frames to be transmitted in the group are arranged in order according to the frame sequence number. Finally, the specific log data in the data payload of each frame is extracted in order and concatenated end to end to form a complete log data block to be transmitted.

[0086] Step S302: Write the log data blocks to be transmitted and the historically transmitted data blocks into the initialization file according to the sending counter order to obtain the original log file of the current vehicle.

[0087] It should be understood that the log data block to be transmitted is the newly received data block in this transmission session obtained from the aforementioned reassembly; while the previously transmitted data block is the data block that the cloud server has previously successfully received from the same vehicle and stored.

[0088] Understandably, the send counter (Tx_Counter) in the vehicle's infotainment system can be strictly continuously incremented (the counter increments by 1 when the vehicle's infotainment system successfully sends a log data block). Therefore, Tx_Counter can be used to determine the absolute time order and logical order in which log data blocks are generated on the cloud server.

[0089] It should be noted that, firstly, the Tx_Counter of the log data block to be transmitted obtained from this restoration can be compared with the maximum Tx_Counter of historically transmitted data blocks. Under normal log data transmission conditions, the current Tx_Counter and the historical maximum Tx_Counter should be consecutive values.

[0090] If the Tx_Counters are consecutive, the log data blocks to be transmitted and the historically transmitted data blocks can be written to the end of the initialization file in the order of their respective Tx_Counters. This initialization file can be a blank cloud file for the current vehicle or a partially reconstructed cloud file.

[0091] Furthermore, if Tx_Counter is not continuous, it indicates that log data blocks are missing. In this case, the cloud server can trigger a retransmission request mechanism to request the vehicle's infotainment system to retransmit the lost data blocks. Only after ensuring that all data blocks are continuous according to Tx_Counter can the final log file reconstruction be completed.

[0092] Finally, after all log data blocks are written to the cloud file in their original Tx_Counter order, the cloud file can be an exact copy of the original log file of the current vehicle, with its byte content and data order being consistent with the logs recorded locally by the current vehicle.

[0093] It should be noted that by relying strictly on the Tx_Counter generated by the vehicle's infotainment system and having a strict order, the cloud server can restore log data blocks that have been transmitted multiple times and may arrive out of order into the original file, ultimately forming a reliable and usable log file asset to facilitate subsequent fault diagnosis and analysis.

[0094] Furthermore, to specifically illustrate how to ensure the correctness of the log files reconstructed by the cloud server when Tx_Counter is discontinuous, steps S01~S03 are included before step S302: Step S01: When the cloud server receives the data frame to be transmitted, it determines the transmission counter corresponding to the data frame to be transmitted.

[0095] It should be noted that when the cloud server receives a data frame to be transmitted, it can parse it and extract the send counter (Tx_Counter) field from the frame structure. Tx_Counter is a unique identifier for different log data blocks. Step S02: Obtain the transmission counter corresponding to the transmitted data frame, and determine whether there is a data block loss based on the transmission counter corresponding to the transmitted data frame and the transmission counter corresponding to the data frame to be transmitted. The transmitted data frame corresponds to a historically transmitted data block.

[0096] It should be understood that the send counter corresponding to the transmitted data frame can be the largest (or latest) Tx_Counter among all log data blocks that the cloud server has successfully received and processed, which can reflect the log reconstruction progress of the cloud file.

[0097] It should be noted that if the Tx_Counter value corresponding to the transmitted data frame is the maximum recorded Tx_Counter value plus 1, it indicates that no data block is lost. For example, if the historical maximum Tx_Counter value is 5 and the new frame's Tx_Counter value is 6, then the log data blocks are transmitted sequentially.

[0098] If the value of Tx_Counter corresponding to the transmitted data frame is greater than the maximum recorded Tx_Counter value plus 1, it indicates that a data block has been lost. For example, if the historical maximum Tx_Counter value is 5 and the new frame's Tx_Counter value is 7, then the log data block with a Tx_Counter value of 6 was completely lost during transmission.

[0099] It should also be noted that since the data frames corresponding to the same log data block share the same Tx_Counter, the cloud server can trigger a data block continuity check when it receives any data frame of the log data block to determine whether there is a data block loss.

[0100] Furthermore, if a data block loss is detected, the cloud server can generate a retransmission command and transmit it to the vehicle's T-Box via a preset communication network. The T-Box then sends the command to the instrument cluster ECU via the CAN FD bus. This retransmission command may include the Tx_Counter value of the log data block that needs to be retransmitted.

[0101] When the vehicle-mounted device receives a retransmission command, it parses the command to determine the Tx_Counter value that needs to be retransmitted, and then reverses to locate the physical location of the log data block to be retransmitted corresponding to the Tx_Counter in the local log file storage area. Then, it reads the log data block to be retransmitted from the located physical location and sends it to the cloud server according to the aforementioned steps S202~S204 to realize the retransmission of the lost log data block.

[0102] Step S03: If it is determined that there is no data block loss, send feedback information that the log data block to be transmitted has been successfully transmitted to the vehicle-mounted device, and return to the step of obtaining the original log file of the current vehicle based on the log data block to be transmitted.

[0103] It should be understood that when it is determined that no data block is lost, the cloud server can send feedback information to the vehicle's infotainment system indicating that the latest log data block to be transmitted has been successfully transmitted. This feedback is sent to the vehicle's T-Box via a pre-defined communication network, and then transmitted by the T-Box to the instrument cluster ECU via the CAN FD bus. This feedback information may include the Tx_Counter value of the aforementioned log data block to be transmitted.

[0104] After receiving the above feedback information, the vehicle-mounted device can confirm that the log data block has been transmitted and update the historical breakpoint pointer in the log file area, thereby achieving state synchronization between the vehicle and the cloud.

[0105] Next, when the feedback information is sent, the cloud server can write the latest log data block to be transmitted (as well as the previously transmitted historical data blocks that have not been written to the cloud file) to the cloud file, and finally restore the original log file of the current vehicle in the vehicle's infotainment system.

[0106] Furthermore, to facilitate remote vehicle fault diagnosis by users based on log data at the front end of the cloud server, after step S30, the following steps are also included: S401~S402: Step S401: The cloud server reads the original log file through a preset log content parser and parses the original log file into plaintext log according to a preset parsing format.

[0107] It should be understood that the raw log file can be a cloud-based binary file whose content is completely identical to the log data stored in the vehicle's infotainment system's log file area. It can contain all log records arranged in chronological order. Since the format of these log records is machine-encoded, they can be parsed using a preset log content parser for user reading.

[0108] It should be noted that the preset log content parser can be a dedicated software module or service running on a cloud server. It can have a built-in parsing program for the raw log files of the vehicle's infotainment system, used to parse the binary structure of each log record, such as: the encoding method of the timestamp (such as Unix timestamp), the identifier code of the event type, the length and meaning of the associated parameters, etc.

[0109] The default log content parser can predefine field segmentation rules and decoding rules for binary log records. Specifically, the field segmentation rules can identify several independent log records from the original log file in binary stream format, and the decoding rules can convert the binary value of each field into a user-readable form, i.e., the default parsing format.

[0110] For example, a 32-bit integer can be decoded into a date and time in the format "2023-10-27 14:30:05"; the event code "0x1001" can be mapped to the text "CAN communication timeout"; and parameter values ​​can be converted into strings with units, etc.

[0111] In practice, the cloud server can read the original log file byte by byte using a preset log content parser, identify record boundaries according to field division rules, extract the binary data of each field, and apply decoding rules to convert it into readable types such as strings, numbers, and dates (preset parsing format); then, the converted fields are concatenated into a complete and readable log entry according to a predetermined text template; finally, multiple log entries are combined to form a plaintext log and stored in the storage area of ​​the cloud server.

[0112] Step S402: In response to a log query command triggered by the user, display the plaintext log to the user.

[0113] It should be understood that users can issue log query commands for vehicles through the interactive interface, API interface, or client software provided by the cloud server. The log query command values ​​can include: vehicle identifier (VIN), time range, event type, log level, etc.

[0114] When the cloud server receives a log query command, it can first query the plaintext logs of the current vehicle from the storage area that stores plaintext logs of different vehicles based on the VIN and time range. It can also further filter the relevant log entries in the plaintext logs according to the event type and log level, and arrange them in reverse or ascending order of time to generate a list of plaintext log entries. Finally, the processed list of plaintext log entries that meet the query conditions is returned and presented to the user in the form of a graphical user interface (GUI), API response data packet, or report file.

[0115] Furthermore, this can be referenced here. Figure 4 The process of receiving and parsing data on the cloud server is explained. Figure 4 This is a schematic diagram of the data processing flow of the cloud server in this application.

[0116] Depend on Figure 4 It can be seen that the data processing flow of the cloud server can be divided into three stages: data reception and preprocessing, data reconstruction and parsing, and anomaly handling operations.

[0117] First, in the data reception and preprocessing stage, when the cloud server receives the data frame to be transmitted (CAN FD frame) through the preset communication network, it can filter out the log frame according to the CAN ID and perform preliminary parsing; then, it sorts and groups all frames according to the parsed transmission counter (Tx_Counter) and frame sequence number.

[0118] Next, it can be determined whether the received Tx_Counter values ​​are continuous. If they are continuous, the steps in the data reconstruction and parsing stage are executed; otherwise, it is determined that a data block has been lost, and the steps in the exception handling operation stage are triggered.

[0119] During the data reconstruction and parsing phase, the cloud server can splice data frames under the same Tx_Counter to restore them into complete log data blocks; the restored log data blocks, together with historically transmitted data blocks, are written into the initialization file in the order of Tx_Counter to finally obtain the original log file; then the original log file is parsed by a preset log content parser according to a preset parsing format, and finally readable log text (plaintext log) is output.

[0120] During the exception handling operation phase, which serves as a bypass, when the cloud server determines that Tx_Counter is discontinuous (i.e., there is a data block loss), it can generate a retransmission instruction and initiate a retransmission request to the vehicle device; thereby waiting for and receiving the specified data block (the data block to be retransmitted) resent by the vehicle device, and then the data will be returned to the aforementioned data reception and preprocessing phase for processing.

[0121] This embodiment verifies the continuity of data frames received by the cloud server by comparing its transmission counter with the transmission counters of historically transmitted data blocks. Based on the verification result, it sends a success feedback or generates a retransmission command with a specified loss counter value to the vehicle's infotainment system, enabling the system to perform targeted retransmissions. This proactively detects and corrects data block-level loss errors, ensuring the integrity and correctness of the final log file. Furthermore, by replacing full retransmissions with precise retransmissions, transmission efficiency and network resource utilization are significantly improved. Moreover, the cloud server uses a preset log content parser to decode the reconstructed original log file into plaintext logs according to a preset parsing format completely corresponding to the vehicle's infotainment system, and displays it in response to user query commands. This transforms unreadable binary log data into structured text information that can be directly viewed and analyzed by humans, achieving ultimate log data usability and providing direct and effective data support for remote fault diagnosis and vehicle status monitoring.

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

[0123] This application also proposes an instrument log data transmission system, which includes: a vehicle-mounted device and a cloud server that is communicatively connected to the vehicle-mounted device.

[0124] The vehicle-mounted device is used to determine whether there is a historical breakpoint pointer in the log file area when the current network status of the vehicle meets the preset trigger conditions. The historical breakpoint pointer is determined based on the transmitted data log blocks. The vehicle-mounted device is used to read the log data block to be transmitted at the historical breakpoint pointer when a historical breakpoint pointer exists, encapsulate the log data block to be transmitted into a data frame to be transmitted, and send the data frame to be transmitted to the cloud server. The cloud server is used to restore the data frame to be transmitted into the log data block to be transmitted, and to obtain the original log file of the current vehicle based on the log data block to be transmitted.

[0125] It should be noted that this can be used as a reference. Figure 5 The data interaction process between the vehicle's infotainment system and the cloud server in the aforementioned instrument log data transmission system is explained. Figure 5 This is a schematic diagram of data interaction in the instrument log data transmission system of this application.

[0126] Depend on Figure 5As can be seen, in the instrument log data transmission system, the vehicle-mounted equipment can include two core components: the instrument ECU and the vehicle-mounted T-Box. The instrument ECU can act as the data source, responsible for the generation, storage, encapsulation, and transmission of logs; the vehicle-mounted T-Box can act as an in-vehicle hub, responsible for receiving data from the instrument ECU and forwarding it to the cloud.

[0127] The cloud server can be divided into a cloud service module, a data storage module, and a parsing module. The cloud service module receives data streams from numerous vehicle in-vehicle infotainment systems (T-Boxes) via cellular networks and can also send downlink control commands (such as retransmission requests) to the in-vehicle systems; it serves as the cloud server's external communication interface. The data storage module persistently stores received raw data frames, intermediate data during processing, and the final generated log file. The parsing module acts as the core computing engine of the cloud server, performing protocol parsing, data reassembly (grouping data according to Tx_Counter and sequence number), integrity verification, triggering retransmission requests, file reconstruction, and finally, text parsing to generate a readable plaintext log file.

[0128] In the instrument cluster log data transmission system, network transmission can include the in-vehicle network and the vehicle infotainment network. The in-vehicle network can use a CAN FD bus to connect the instrument cluster ECU and the vehicle infotainment T-Box for high-speed data transmission; the vehicle-to-cloud network can use a cellular network (4G / 5G) to connect the vehicle infotainment T-Box and cloud services for remote communication.

[0129] In the data uplink path ( Figure 5 (Represented by solid lines in the image) Log data originates from the instrument cluster ECU, is transmitted via the CANFD bus to the vehicle's T-Box, and then uploaded to the cloud server via the cellular network. The cloud service module on the cloud server receives the data, either temporarily storing it or transferring it to the data storage module, and drives the parsing module for processing. The parsing module reads data from the data storage module when needed and writes the processing results (such as a Log File) back to storage. Finally, the server processes the data to generate the Log File (the original log file). In controlling the downlink path ( Figure 5 (represented by dashed lines). When the cloud server determines that there is a data block loss, it can generate a retransmission command through the parsing program module, and send the retransmission command to the vehicle's T-Box through the cellular network, and then notify the instrument ECU via the CAN FD bus.

[0130] This instrument log data transmission system constructs an end-to-end transmission architecture consisting of vehicle-mounted devices (instrument ECU and vehicle-mounted T-Box), an in-vehicle CANFD network, a vehicle-to-cloud cellular network, and a cloud server, and sets up bidirectional paths for data uplink and control downlink. This achieves reliable end-to-end data transmission and closed-loop control from the vehicle to the cloud, providing a solid system foundation for complete log data upload, cloud processing, and reverse retransmission commands.

[0131] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other elements in the process, method, article, or system that includes that element.

[0132] The above embodiment numbers are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. They are only some embodiments of this application and do not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for transmitting instrument log data, characterized in that, The method is applied to an instrument log data transmission system, the system comprising: a vehicle-mounted device and a cloud server communicatively connected to the vehicle-mounted device; the method comprising: When the network status of the current vehicle meets the preset triggering conditions, the vehicle-mounted device determines in the log file area whether there is a historical breakpoint pointer. The historical breakpoint pointer is determined based on the historically transmitted log data blocks. When a historical breakpoint pointer exists, the vehicle-mounted device reads the log data block to be transmitted at the historical breakpoint pointer, encapsulates the log data block to be transmitted into a data frame to be transmitted, and sends the data frame to be transmitted to the cloud server. The cloud server restores the data frame to be transmitted into the log data block to be transmitted, and obtains the original log file of the current vehicle based on the log data block to be transmitted.

2. The method as described in claim 1, characterized in that, When the network status of the current vehicle meets the preset triggering conditions, the step of the vehicle-mounted device determining whether a historical breakpoint pointer exists in the log file area includes: Monitor the network status of the current vehicle and determine whether the network status of the current vehicle meets the preset trigger conditions. The preset trigger conditions include: application layer idle condition, bus low load condition, and pre-sleep condition. When the network status of the current vehicle meets the preset triggering conditions, a data transmission command is generated; In response to the data transmission instruction, determine whether a historical breakpoint pointer exists in the log file area of ​​the current vehicle.

3. The method as described in claim 1, characterized in that, When a historical breakpoint pointer exists, the vehicle-mounted device reads the log data block to be transmitted at the historical breakpoint pointer and encapsulates the log data block to be transmitted into a data frame to be transmitted, including: When a historical breakpoint pointer exists, the log data block at the historical breakpoint pointer is identified as the log data block to be transmitted. The log blocks to be transmitted are encapsulated into data frames to be transmitted based on the preset CAN FD bus protocol. The data frames to be transmitted are constructed based on the CAN FD frame structure, which includes a frame header, a transmission counter, and a data payload.

4. The method as described in claim 3, characterized in that, The step of sending the data frame to be transmitted to the cloud server includes: Obtain the current load rate of the CAN FD bus, determine whether the current load rate is less than the preset maximum load value, and obtain the determination result; The transmission interval is adjusted according to the judgment result, and the data frame to be transmitted is sent to the cloud server through the CAN FD bus and the preset communication network based on the adjusted transmission interval.

5. The method as described in claim 1, characterized in that, After the step of sending the data frame to be transmitted to the cloud server, the method further includes: When the vehicle-mounted device receives feedback information that the log data block to be transmitted has been successfully transmitted, it determines that the log data block to be transmitted is the latest transmitted log data block, and updates the position of the historical breakpoint pointer according to the latest transmitted log data block.

6. The method as described in claim 1, characterized in that, The data frame to be transmitted is constructed based on the CAN FD frame structure and includes: a frame header, a transmission counter, and a data payload; The steps of the cloud server restoring the data frame to be transmitted into the log data block to be transmitted, and obtaining the original log file of the current vehicle based on the log data block to be transmitted, include: The data payload of the data frame to be transmitted is parsed to determine the corresponding frame sequence number, and the data frame to be transmitted is spliced ​​together according to the frame sequence number to obtain the log data block to be transmitted. The original log file of the current vehicle is obtained by writing the log data blocks to be transmitted and the historically transmitted data blocks into the initialization file in the order of the transmission counter.

7. The method as described in claim 6, characterized in that, Before the step of writing the log data blocks to be transmitted and the historically transmitted data blocks into the initialization file in the order of the transmission counter, the method further includes: When the cloud server receives the data frame to be transmitted, it determines the transmission counter corresponding to the data frame to be transmitted. Obtain the transmission counter corresponding to the transmitted data frame, and determine whether there is a data block loss based on the transmission counter corresponding to the transmitted data frame and the transmission counter corresponding to the data frame to be transmitted. The transmitted data frame corresponds to a historically transmitted data block. If it is determined that no data block is lost, a feedback message indicating that the log data block to be transmitted has been successfully transmitted is sent to the vehicle-mounted device, and the process returns to the step of writing the log data block to be transmitted and the historically transmitted data blocks into the initialization file in the order of the transmission counter.

8. The method as described in claim 7, characterized in that, After the step of the cloud server writing the log data blocks to be transmitted and the historically transmitted data blocks into an initialization file according to the sending counter order to obtain the original log file of the current vehicle, the method further includes: The cloud server reads the original log file through a preset log content parser and parses the original log file into plaintext log according to a preset parsing format; In response to a user-triggered log query command, the plaintext log is displayed to the user.

9. The method as described in claim 7, characterized in that, After the step of determining whether data block loss has occurred, the method further includes: When the cloud server determines that a data block is lost, it generates a retransmission command and sends the retransmission command to the vehicle-mounted device. When the vehicle-mounted device receives the retransmission instruction, it determines the log data block to be retransmitted and sends the log data block to be retransmitted to the cloud server.

10. An instrument log data transmission system, characterized in that, The system includes an in-vehicle infotainment device and a cloud server that is communicatively connected to the in-vehicle infotainment device. The vehicle-mounted device is used to determine whether there is a historical breakpoint pointer in the log file area when the current network status of the vehicle meets the preset trigger conditions. The historical breakpoint pointer is determined based on the transmitted data log blocks. The vehicle-mounted device is used to read the log data block to be transmitted at the historical breakpoint pointer when a historical breakpoint pointer exists, encapsulate the log data block to be transmitted into a data frame to be transmitted, and send the data frame to be transmitted to the cloud server. The cloud server is used to restore the data frame to be transmitted into the log data block to be transmitted, and to obtain the original log file of the current vehicle based on the log data block to be transmitted.

Images