Data transmission method, vehicle-mounted terminal, vehicle and storage medium

Abstract

The invention relates to the technical field of automotive electronics, in particular to a data transmission method, a vehicle-mounted terminal, a vehicle and a storage medium. The method comprises the steps that a target vehicle energy data packet sent by the controller is received through a serial port, and the energy data packet is obtained through coding of a COBS algorithm; analyzing each energy data packet of the target vehicle according to a decoding rule of the COBS algorithm to obtain original energy data of the target vehicle; and after successful login of the far-end server is confirmed, according to a preset time interval, the original energy data of the target vehicle is sent to the far-end server through a TCP / IP link. Therefore, the problems of data loss, poor acquisition time stability and the like existing in data transmission in an existing TBOX product can be effectively solved.

Description

Technical Field

[0001] This application relates to the field of automotive electronics technology, and in particular to a data transmission method, an in-vehicle terminal, a vehicle, and a storage medium. Background Technology

[0002] EMMC (Embedded Multi Media Card) is an embedded memory standard specification established by the MCC Association for electronic products such as mobile phones or tablets. EMMC includes a controller, flash memory, and a multimedia card interface. The controller is configured with firmware, which controls the operation of EMMC.

[0003] The TBOX product serves as a bridge connecting the backend system and the vehicle network. It communicates directly with the vehicle network via a CAN transceiver, acquiring data from the entertainment CAN and diagnostic CAN systems. The TBOX is primarily used for interconnection and communication with the backend system and mobile app, enabling the display and control of vehicle information through these systems and apps.

[0004] However, TBOX products generally collect and report energy data according to the requirements of GBT32960 Technical Specification for Remote Service and Management System for Electric Vehicles. The technical specification uses TCP / IP connection to transmit data, which has problems such as data loss and poor stability of collection time. Summary of the Invention

[0005] In view of this, embodiments of this application provide a data transmission method, an in-vehicle terminal, a vehicle, and a storage medium, which can effectively solve the problems of data loss and poor data acquisition time stability in existing TBOX products.

[0006] In a first aspect, embodiments of this application provide a data transmission method applicable to a communication module in a vehicle-mounted terminal TBOX, wherein the vehicle-mounted terminal includes a controller, and the controller and the communication module are connected via a serial port; the method includes: The system receives target vehicle energy data packets sent by the controller via a serial port, wherein the energy data packets are encoded using the COBS algorithm. The target vehicle's energy data packets are parsed according to the decoding rules of the COBS algorithm to obtain the target vehicle's original energy data. After confirming successful login to the remote server, the raw energy data of the target vehicle is sent to the remote server via TCP / IP link according to a preset time interval.

[0007] In some embodiments, the method further includes: A keep-alive request is sent to the controller at preset detection time intervals, and it is confirmed whether keep-alive feedback information from the controller is received within the set waiting time range.

[0008] In some embodiments, the confirmation of successful login to the remote server includes the following steps: A login request is sent to the remote server; the login request includes vehicle terminal identity authentication information; the vehicle terminal identity authentication information is used by the remote server to verify the identity of the login requester. If a verification response is received from the remote service after successful identity verification within the set verification waiting time, then the login to the remote server is confirmed to be successful. If the verification response is not received within the set verification waiting time, the login request is resent until the login request is resent N times consecutively and the verification response is still not received, then the login is confirmed to have failed.

[0009] In some embodiments, the vehicle terminal further includes an EMMC memory; When a communication anomaly is confirmed with the remote server, the original energy data of the target vehicle is cached in the EMMC memory, and the EMMC memory stores the original energy data of the target vehicle for the most recent N days, where N > 0; the communication anomaly includes network anomaly and data transmission anomaly. Once communication with the remote server is confirmed to have returned to normal, the original energy data of the target vehicle cached in the EMMC memory and the received real-time original energy data of the target vehicle are sent to the remote server according to the set transmission priority.

[0010] In some embodiments, the method further includes: if no data packet reception response is received from the remote server within a set waiting period after sending the original energy data packet of the target vehicle to the remote server, then resending the original energy data packet corresponding to the previous packet.

[0011] In some embodiments, the target vehicle energy data packets sent by the controller are collected according to a preset collection time interval, and then detected and cached. If a Level 3 alarm data is detected, the original energy data of the target vehicle within a preset time period before and after the time point of the corresponding fault occurrence of the Level 3 alarm is collected according to the preset sampling interval, and then sent to the remote server according to the sending priority.

[0012] In some embodiments, the method further includes: sending a response signal to the controller after receiving the target vehicle energy data packet; The response signal is used to prevent the controller from retransmitting the energy data packet corresponding to the previous packet after a set retransmission time according to the retransmission mechanism.

[0013] Secondly, embodiments of this application provide an in-vehicle terminal, which includes a controller and a communication module, wherein the controller and the communication module are connected via a serial port; the controller is used to connect to a CAN bus to collect vehicle energy data; The vehicle-mounted terminal is used to implement a data transmission method provided in accordance with the first aspect of this application.

[0014] Thirdly, embodiments of this application provide a vehicle, which includes a vehicle body and an in-vehicle terminal provided in the second aspect of this application.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed on a processor, implements a data transmission method provided according to the first aspect of this application.

[0016] The embodiments of this application have the following beneficial effects: This application acquires target vehicle energy data packets encoded using the COBS algorithm sent by the controller via a serial port; parses each target vehicle energy data packet according to the encoding rules of the COBS algorithm to obtain the original energy data of the target vehicle; after confirming successful login to the remote server, the original energy data of the target vehicle is sent to the remote server via a TCP / IP link at preset time intervals. This application uses the COBS algorithm to generate efficient, reliable, and clear packet framing without considering packet content, thereby enabling the receiving application to easily recover from malformed packets. The COBS algorithm uses a specific byte value (e.g., zero) as a packet delimiter, which is a special value indicating the boundary between packets. When zero is used as a delimiter, the algorithm replaces each zero data byte with a non-zero value, so that zero data bytes that are mistaken for packet boundaries will not appear in the packet. Thus, this application solves the problem of data loss during data transmission. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of the structure of an in-vehicle terminal according to an embodiment of this application is shown; Figure 2 A schematic flowchart of a data transmission method according to an embodiment of this application is shown; Figure 3 A schematic diagram of a data transmission device according to an embodiment of this application is shown.

[0019] Explanation of key component symbols: 100 - Communication module; 200 - Controller; 300 - Remote server; 310 - Data acquisition module; 320 - Data parsing module; 330 - Data transmission module. Detailed Implementation

[0020] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0023] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0024] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0025] As new energy vehicles continue to rise, accurate and reliable reporting of energy data is crucial. This allows for monitoring the operational status of all other ECUs (Electronic Control Units) during the operation of new energy electric vehicles. Furthermore, after an alarm occurs, the server can monitor the status of other ECUs during the fault process, providing real-time feedback on the actual operational status of other devices over the effective time period.

[0026] Existing TBOX products typically collect energy data and report it to a remote server 300 according to the requirements of GBT32960 Technical Specification for Remote Service and Management System for Electric Vehicles. However, this method suffers from data loss and poor data acquisition stability. Therefore, this application proposes a data transmission method, an in-vehicle terminal, a vehicle, and a storage medium, which can effectively solve the problems of data loss and poor data acquisition stability in existing TBOX products.

[0027] The data transmission method of this application embodiment is applicable to a communication module 100 in a vehicle-mounted terminal (TBOX), such as... Figure 1 As shown, the vehicle-mounted terminal includes a controller 200 and a communication module 100. The controller 200 is used to connect to the CAN bus to collect energy data of the target vehicle. The controller 200 and the communication module 100 are connected via a serial port, preferably via a UART (Universal Asynchronous Receiver / Transmitter) serial port. The communication module 100 communicates with a remote server 300 via a TCP / IP link. The 4G / 5G module is used to implement multi-task management, such as collecting data sent by the controller 200; opening a TCP / IP link to connect to the remote server 300; and packaging and sending real-time data to the remote server 300. Specifically, the communication module 100 is used to implement the data transmission method of the embodiments of this application. For example, the communication module is a 4G / 5G module. The controller is an MCU.

[0028] The data transmission method will be described below with reference to some specific embodiments.

[0029] Figure 2 A flowchart of a data transmission method according to an embodiment of this application is shown. Exemplarily, the data transmission method includes the following steps: S10, receive the target vehicle energy data packet sent by the controller 200 via the serial port, wherein the energy data packet is encoded using the COBS algorithm.

[0030] The controller 200 is connected to an external CAN bus to collect energy data (also known as new energy data) from the target vehicle, obtaining the raw energy data of the target vehicle. The collected raw energy data is then encoded and packetized using the COBS algorithm to obtain various energy data packets for the target vehicle. The raw energy data of the target vehicle includes: drive motor data, vehicle data, fuel cell data, engine data, vehicle location data (GPS module, parsing raw NEMA data), extreme value data, alarm data, and temperature data of the rechargeable energy storage device.

[0031] COBS (Consistent Overhead Byte Stuffing) is a data frame synchronization algorithm used to define data frames by adding special markers to a sequence of data. Specifically, it distinguishes the boundaries between data frames by replacing zero bytes (0x00) with non-zero bytes as special markers. The principle of the COBS algorithm is as follows: Initialize a byte counter and an output buffer; iterate through the input data, writing the counter value to the output buffer at each non-zero byte and resetting the counter to 1; at each zero byte, write the counter value following the previous non-zero byte to the output buffer and reset the counter to 1; for example, if the counter value is 0xFF, write 0xFF to the output buffer and reset the counter to 1; finally, write 0x00 to the output buffer to indicate the end of the data frame. After COBS encoding, the starting byte of each data frame is 0x00, thus defining the data frame. During decoding, according to the rules of COBS encoding, the data frame can be restored to the original data.

[0032] Consistent Overhead Byte Stuffing (COBS) encoding is used to encapsulate underlying data packets. COBS is an algorithm for encoding data bytes that produces efficient, reliable, and unambiguous packet framing regardless of packet content, allowing the receiving application to easily recover from malformed packets. The algorithm uses a specific byte value (e.g., zero) as a packet delimiter, a special value indicating the boundary between packets. When zero is used as a delimiter, the algorithm replaces each zero data byte with a non-zero value, thus preventing zero data bytes from being mistaken for packet boundaries within a packet. Therefore, this application solves the problem of data loss during data transmission.

[0033] In this embodiment, the COBS algorithm itself does not directly "packetize." Instead, the controller (MCU) divides the collected new energy data into logical data blocks according to business logic, performs COBS encoding on each block, and encapsulates it into a physical frame that can be reliably transmitted via UART using a strong synchronization frame structure. Its core is a three-in-one approach: business-driven packetization + COBS anti-interference encoding + frame structured encapsulation. Packetizing new energy data includes the following steps: (1) Determine data blocks according to business rules: The controller collects a complete set of new energy raw data (including drive motor, vehicle, GPS, alarm, etc.) from the CAN bus according to a preset period (e.g., 1 second) or event trigger (e.g., detection of a level 3 alarm), forming a logical data block to be sent.

[0034] (2) Perform COBS encoding on the data block: Process the data block byte by byte: replace all original `0x00` bytes with non-zero `code` bytes, and add a `0x00` at the end as the COBS segment terminator—ensuring that there is only one 0x00 in the encoded data, and that it is used exclusively to mark the end of the COBS content.

[0035] (3) Add a strong synchronization frame header: Before the COBS encoded result, a fixed two-byte frame header `0xAA 0x55` is added—as a unique, interference-resistant frame start identifier for the TBOX UART receiver to avoid noise-induced parsing.

[0036] (4) Additional integrity verification field: After the COBS encoded block (including the 0x00 at the end), append a 2-byte CRC16 checksum (overlaying the frame header + COBS block) and a 1-byte fixed frame tail `0x7E` to form a complete and verifiable physical frame.

[0037] (5) Send via UART and wait for confirmation: The controller sends the physical frame to the TBOX; the TBOX completes frame header identification → COBS decoding → CRC and frame tail verification → and immediately returns ACK after all verifications are successful; the controller confirms the successful transmission of this packet upon receiving the ACK, otherwise it will retransmit.

[0038] The “COBS sub-packet” in this application is actually: the controller segments the data at the granularity of business requirements, uses COBS to eliminate 0x00 ambiguity, and then uses 0xAA0x55 as the anchor point, 0x00 as the COBS terminator, and CRC+0x7E as the shield to construct a TBOX UART physical frame that can be unambiguously, self-synchronized, and highly robustly resolved.

[0039] As an example, the present application embodiments employ the following method to resolve the packet merging problem based on the header and footer of the data packet: (1) Strong synchronization start: The receiver continuously scans the UART byte stream. Only when the preset double-byte frame header `0xAA 0x55` is continuously detected will a frame parsing process be started. Any other single byte (such as isolated `0x00` or `0x7E`) will not trigger parsing, effectively filtering noise and false triggering.

[0040] Therefore, a unique and interference-resistant frame start point is established to avoid erroneous segmentation caused by random bytes.

[0041] (2) Unambiguous definition: Starting from the frame header, COBS decoding is performed: the `code` field and subsequent non-zero data are parsed byte by byte, strictly following the RFC 7042 rules, and the first occurrence of `0x00` byte is uniquely identified as the end symbol of the frame (and this `0x00` appears only once in the entire frame); the decoding process does not rely on the length field or timeout mechanism. Thus, the semantic confusion between "0x00 in the data" and "frame boundary 0x00" is completely eliminated, and internal boundary self-synchronization is achieved.

[0042] (3) Integrity verification: At the end of the payload obtained by COBS decoding, the following 2 bytes of CRC16 (covering the frame header + COBS block) and 1 byte of frame tail `0x7E` are checked; if any check fails (CRC error, missing `0x7E`, `0x7E` position error), the byte segment is determined to be invalid and discarded immediately, without proceeding to subsequent processing. This ensures that the received logical frame is complete and not truncated or tampered with, and blocks cross-frame pollution caused by half-frame residue.

[0043] (4) Closed-loop confirmation to prevent retransmission: Only when all three steps above are passed (correct header + complete COBS structure + valid CRC and frame tail) will the TBOX send an acknowledgment signal (ACK) to the controller; this ACK is both a confirmation of successful transmission and a legal basis for the controller to stop retransmission. Thus, the repeated transmission caused by the MCU not receiving the ACK is cut off at the source, eliminating the source of artificially created packet splicing.

[0044] (5) Error self-recovery: If a frame fails to be parsed due to interference (such as premature termination of a false `0x00` or failure of CRC check), the receiver automatically abandons the current segment and continues to scan the subsequent byte stream. Once `0xAA 0x55` is captured again, parsing is restarted without delay, achieving millisecond-level synchronous recovery. Thus, the impact of packet fragmentation is strictly limited to a single frame, ensuring the long-term stability of the entire data stream.

[0045] The communication module 100 and the controller 200 communicate via serial port. The serial port communication requires the communication module 100 to perform protocol packet splitting, packet merging, and packet loss in order to avoid energy data loss.

[0046] S20, according to the decoding rules of the COBS algorithm, the energy data packets of the target vehicle are parsed to obtain the original energy data of the target vehicle.

[0047] S30, after confirming successful login to the remote server 300, the original energy data of the target vehicle is sent to the remote server 300 via TCP / IP link according to a preset time interval. The preset time interval is less than or equal to 30 seconds.

[0048] In one implementation, to further prevent data loss, a keep-alive mechanism is provided between the controller 200 and the communication module 100. Specifically, the method further includes: A keep-alive request is sent to the controller 200 at preset detection time intervals, and it is confirmed whether keep-alive feedback information from the controller 200 is received within the set waiting time range; if the keep-alive feedback information is received, it is confirmed that the controller 200 is working normally; if the keep-alive feedback information is not received, it is confirmed that the controller 200 is malfunctioning, and a malfunction prompt message for the controller 200 is output.

[0049] In one embodiment, to prevent energy data loss, the vehicle terminal further includes an EMMC memory connected to the communication module 100 to cache energy data. The method in this application embodiment also includes: (1) When it is confirmed that there is a communication error with the remote server 300, the original energy data of the target vehicle is cached in the EMMC memory, and the EMMC memory stores the original energy data of the target vehicle for the most recent N days, where N > 0; preferably, N = 7. The communication error includes network error and data transmission error.

[0050] Methods for confirming network anomalies include: if dialing is normal, it confirms there is a network and normal communication with the remote server 300 is possible; or if the connection interface feedback is normal, it confirms normal communication with the remote server 300. Data transmission anomalies include: no feedback when sending data to the remote server 300, or data transmission failure. That is, in the event of network anomalies or data transmission failure, the system supports caching the target vehicle's original energy data to the EMMC storage device, but the maximum caching time is no more than 7 days; after 7 days, it will be overwritten by the latest data or automatically deleted.

[0051] (2) Upon confirming that communication with the remote server 300 has returned to normal, the target vehicle's original energy data cached in the EMMC memory and the received real-time target vehicle's original energy data are sent to the remote server 300 according to the set sending priority. For example, the sending priority is set to send the real-time target vehicle's original energy data first. The cached target vehicle's original energy data is uploaded to the remote server 300 in the form of retransmission. When real-time data needs to be sent to the remote server 300 during the retransmission process, the real-time data takes priority. The retransmission is performed by the retransmission thread, which detects and obtains the EMMC memory data.

[0052] In step S30, the confirmation of successful login to the remote server 300 includes the following: (1) Send a login request to the remote server 300; the login request includes vehicle terminal identity authentication information; the vehicle terminal identity authentication information is used by the remote server 300 to verify the identity of the login requester.

[0053] (2) If the verification response information returned after the successful verification of the remote service is received within the set verification waiting time, the login to the remote server is confirmed to be successful; if the verification response information is not received within the set verification waiting time, the login request is resent until the login request is resent N times and the verification response information is still not received, then the login is confirmed to be unsuccessful.

[0054] Specifically, the TBOX initiates a communication connection to the remote server 300. After a successful connection, the TBOX needs to carry relevant authentication information (vehicle terminal authentication information) to log in to the remote server 300. The remote server 300 receives the vehicle terminal authentication information and performs identity verification. If the verification is successful, the remote server will respond with a corresponding ACK; if the verification fails, the remote server 300 ignores the received data. For the TBOX, if no ACK is received, the TBOX will automatically re-initiate the login after three minutes.

[0055] Furthermore, after the vehicle is turned off, the TBOX enters sleep mode, sends a logout message to the remote service before going into sleep mode, and does not send new energy-related data to the remote service during the sleep process.

[0056] In one embodiment, a retransmission mechanism is provided between the communication module 100 and the controller 200, and between the communication module 100 and the remote server 300.

[0057] On the controller 200 side, upon receiving the target vehicle's energy data packet, a response signal is sent back to the controller 200. This response signal prevents the controller 200 from retransmitting the energy data packet corresponding to the previous packet after a set retransmission time, according to the retransmission mechanism. Otherwise, the controller 200 retransmits the energy data packet corresponding to the previous packet to the communication module 100 after the set retransmission time. Naturally, if the communication module 100 sends a request message to the controller 200 and does not receive a response signal within the set retransmission time, it will retransmit the same request message to the controller 200 after the set retransmission time.

[0058] For the remote server 300, if no data packet reception response is received from the remote server 300 within the set waiting time after sending the original energy data packet of the target vehicle, the original energy data packet corresponding to the previous packet is resent. Naturally, if a request message is received from the remote server 300, a response message will also be sent to confirm that the request message was successfully received.

[0059] In one implementation, step S10 specifically involves collecting the target vehicle energy data packets sent by the controller 200 according to a preset collection time interval, and then detecting and buffering them. Preferably, the preset collection time interval is 1 second. That is, the TBOX will collect the energy data sent by the controller 200 every second.

[0060] If a Level 3 alarm data is received, the system collects the target vehicle's original energy data within a preset time period before and after the fault occurrence time corresponding to the Level 3 alarm, according to a preset sampling interval, and sends it to the remote server 300 according to the sending priority. For example, the system should report data within 30 seconds before and after the fault occurrence time, with a sampling period of no more than 1 second. Preferably, the preset sampling interval is 1 second. Data before the fault occurrence should be sent to the remote server 300 in a supplementary form.

[0061] The data transmission method of this application is described below with an example, including: S110, the controller 200 collects the target vehicle's energy data via the CAN bus and encodes the target vehicle's energy data packet using the COBS algorithm. Finally, it sends the data to the communication module 100.

[0062] S120, the communication module 100 collects the target vehicle energy data packets sent by the controller 200 every second, and sends a response signal back to the controller 200. Then, it parses each target vehicle energy data packet according to the encoding rules of the COBS algorithm to obtain the original energy data of the target vehicle.

[0063] S130, the communication module 100 parses the energy data packets of each target vehicle according to the encoding rules of the COBS algorithm to obtain the original energy data of the target vehicle and performs corresponding caching.

[0064] S140, the communication module 100 activates the keep-alive mechanism, sends a keep-alive request to the controller 200 every preset detection time interval (2 seconds), and confirms that it receives the keep-alive feedback information from the controller 200 within the set waiting time range, so as to confirm that the controller 200 is working normally.

[0065] S150, the communication module 100 sends a login request to the remote server 300; the login request includes vehicle terminal identity authentication information; the remote server 300 verifies the identity of the login requester based on the vehicle terminal identity authentication information.

[0066] If the communication module 100 receives a verification response message returned after successful identity verification by the remote service within the set verification waiting time, it confirms that the communication module 100 has successfully logged into the remote server 300.

[0067] S160, after confirming successful login to the remote server 300, the target vehicle's raw energy data is sent to the remote server 300 via a TCP / IP link every preset time interval, provided the preset time interval is no greater than 30 seconds. Upon receiving the target vehicle's raw energy data, the remote server 300 sends a data packet reception response to the communication module 100.

[0068] Both the TBOX internal controller 200 and the 4G module are connected to the corresponding UART for communication. To prevent data loss, UART data packets (target vehicle energy data packets) are transmitted using methods such as packet segmentation, packet assembly, packet loss detection, and heartbeat detection. Therefore, this application can prevent the loss of collected vehicle CAN data and data reported to the remote service. To better achieve the collection and reporting of new energy-related data, the TBOX can also promptly and accurately report level three alarm information to the remote server 300.

[0069] Figure 3 A schematic diagram of a data transmission device according to an embodiment of this application is shown. Exemplarily, the data transmission device includes: a data acquisition module 310, a data parsing module 320, and a data transmission module 330.

[0070] Data acquisition module 310 is used to acquire target vehicle energy data packets encoded using the COBS algorithm sent by controller 200 via serial port; The data parsing module 320 parses the target vehicle energy data packets according to the encoding rules of the COBS algorithm to obtain the original energy data of the target vehicles; The data sending module 330 is used to send the original energy data of the target vehicle to the remote server 300 via TCP / IP link according to a preset time interval after confirming successful login to the remote server 300.

[0071] It is understood that the device in this embodiment corresponds to the data transmission method in the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0072] This application also provides a vehicle, exemplary in that the vehicle includes a vehicle body and an in-vehicle terminal according to embodiments of this application; the in-vehicle terminal is used to implement the data transmission method according to embodiments of this application.

[0073] It is understood that the vehicle in this embodiment corresponds to the data transmission method in the above embodiment, and the options in the above embodiment are also applicable to this embodiment, so they will not be described again here.

[0074] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the aforementioned data transmission method or data transmission apparatus. Preferably, the terminal device is a communication module 100.

[0075] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0076] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0077] This application also provides a readable storage medium for storing the computer program used in the aforementioned terminal device.

[0078] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0079] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0080] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A data transmission method, characterized in that, A communication module applicable to a vehicle-mounted terminal TBOX, the vehicle-mounted terminal including a controller, the controller and the communication module being connected via a serial port; the method includes: The system receives the target vehicle energy data packet sent by the controller via a serial port, wherein the energy data packet is encoded using the COBS algorithm. The target vehicle's energy data packets are parsed according to the decoding rules of the COBS algorithm to obtain the target vehicle's original energy data. After confirming successful login to the remote server, the raw energy data of the target vehicle is sent to the remote server via TCP / IP link according to a preset time interval.

2. The data transmission method according to claim 1, characterized in that, The method further includes: A keep-alive request is sent to the controller at preset detection time intervals, and it is confirmed whether keep-alive feedback information from the controller is received within the set waiting time range.

3. The data transmission method according to claim 1, characterized in that, The confirmation of successful login to the remote server includes the following: A login request is sent to the remote server; the login request includes vehicle terminal identity authentication information; the vehicle terminal identity authentication information is used by the remote server to verify the identity of the login requester. If a verification response is received from the remote service after successful identity verification within the set verification waiting time, then the login to the remote server is confirmed to be successful. If the verification response is not received within the set verification waiting time, the login request is resent until the login request is resent N times consecutively and the verification response is still not received, then the login is confirmed to have failed.

4. The data transmission method according to claim 1, characterized in that, The vehicle-mounted terminal also includes an EMMC memory; When a communication anomaly is confirmed with the remote server, the original energy data of the target vehicle is cached in the EMMC memory, and the EMMC memory stores the original energy data of the target vehicle for the most recent N days, where N > 0; the communication anomaly includes network anomaly and data transmission anomaly. Once communication with the remote server is confirmed to have returned to normal, the original energy data of the target vehicle cached in the EMMC memory and the received real-time original energy data of the target vehicle are sent to the remote server according to the set sending priority.

5. The data transmission method according to claim 1, characterized in that, The method further includes: If no data packet reception response is received from the remote server within a set waiting period after sending the original energy data packet of the target vehicle to the remote server, the original energy data packet corresponding to the previous packet is resent.

6. The data transmission method according to claim 1, characterized in that, The method further includes: The controller collects the target vehicle energy data packets sent by the controller at preset collection time intervals, and then detects and caches them. If a Level 3 alarm data is received, the original energy data of the target vehicle within a preset time period before and after the time point of the corresponding fault occurrence of the Level 3 alarm is collected according to the preset sampling interval, and sent to the remote server according to the sending priority.

7. The data transmission method according to claim 1, characterized in that, The method further includes: sending a response signal to the controller after receiving the energy data packet of the target vehicle; The response signal is used to prevent the controller from retransmitting the energy data packet corresponding to the previous packet after a set retransmission time according to the retransmission mechanism.

8. A vehicle-mounted terminal, characterized in that, The vehicle-mounted terminal includes a controller and a communication module, the controller and the communication module being connected via a serial port; the controller is used to connect to the CAN bus to collect vehicle energy data; The vehicle-mounted terminal is used to implement the data transmission method according to any one of claims 1-7.

9. A vehicle, characterized in that, The vehicle includes the vehicle body and the vehicle-mounted terminal as described in claim 8.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the data transmission method according to any one of claims 1-7.

Images