Vehicle data upload method and apparatus

Abstract

The present disclosure relates to a vehicle data uploading method and device, relates to the technical field of data communication, and is used for improving the completeness of vehicle data uploading. The method comprises the following steps: according to the running scene of a vehicle, an adaptive uploading strategy is adopted to upload each Ethernet message to the cloud, so that the on-demand uploading of the whole vehicle data in different scenes is realized, the uploading load is reduced, and through mirror image collection and format conversion of each network segment message of the whole vehicle, the Ethernet message in a unified format is obtained. Therefore, while reducing the uploading load, the completeness of the vehicle data uploaded to the cloud is improved, and effective monitoring of the vehicle state is realized.

Description

Technical Field

[0001] This disclosure relates to the field of data communication technology, and more specifically, to a method and device for uploading vehicle data. Background Technology

[0002] With the rapid development of intelligent connected vehicles, it is necessary to collect vehicle operation data and upload it to the cloud platform in order to monitor the vehicle status.

[0003] However, because vehicle operation data contains network segment data with different protocols, relevant solutions for vehicle data collection and uploading can usually only collect and upload specific and single-type network segment data. Therefore, the data range collected by these solutions does not cover all vehicle operation data, resulting in incomplete vehicle data uploaded to the cloud, and thus failing to achieve effective monitoring of vehicle status. Summary of the Invention

[0004] The purpose of this disclosure is to provide a vehicle data uploading method and device to improve the integrity of vehicle data uploading.

[0005] Firstly, this application provides a vehicle data uploading method, applied to a data uploading node, comprising: Obtain at least one Ethernet packet forwarded by the vehicle gateway node; the at least one Ethernet packet is obtained through the vehicle data upload method of the first aspect; Local caching of at least one Ethernet packet; Based on the vehicle's operating scenario, a target upload strategy is determined, and at least one cached Ethernet packet is uploaded to the cloud using the target upload strategy. The target upload strategy is used to indicate the packet upload strategy adopted to suit the corresponding operating scenario.

[0006] In one possible implementation, the target upload strategy is determined based on the vehicle's operating scenario, including: If a vehicle experiences a preset fault, the target upload strategy is determined to be the fault data upload strategy. The fault data upload strategy is used to indicate that at least one fault message related to the preset fault is identified in at least one Ethernet message, and at least one fault message is uploaded to the cloud. If the vehicle does not experience a preset fault, but triggers a preset scenario, the target upload strategy is determined to be a specific scenario upload strategy. The specific scenario upload strategy is used to indicate that at least one scenario message related to the preset scenario is identified in at least one Ethernet message, and at least one scenario message is uploaded to the cloud. If the vehicle does not trigger the preset scenario, and the cloud issues a data upload command, the target upload strategy is determined to be the command upload strategy. The command upload strategy is used to instruct at least one target message corresponding to the data upload command in at least one Ethernet message, and to upload at least one target message to the cloud. If no data upload instruction is issued from the cloud, the target upload strategy is determined to be a fixed-period upload strategy. The fixed-period upload strategy is used to instruct at least one cached Ethernet packet to be uploaded to the cloud according to a preset period.

[0007] In one possible implementation, the preset scenario includes at least the scenario where the vehicle's driver assistance function is activated; Identifying at least one scenario message related to a preset scenario within at least one Ethernet message, including: In at least one Ethernet packet, packets that are within a preset time period before or after the activation time of the driving assistance function are marked as scenario packets; The driving assistance functions include at least one of automatic emergency braking, forward collision warning, lane departure warning, lane keeping assist, and intelligent navigation assist.

[0008] In one possible implementation, the preset fault is a failure of any one of the vehicle's multiple preset subsystems; Identify at least one fault message associated with a preset fault in at least one Ethernet message, including: In at least one Ethernet packet, the packet associated with the failed subsystem is marked as a fault packet; The pre-defined subsystems include at least one of the following: anti-lock braking system, electronic parking system, vehicle controller, electric drive system, power battery system, on-board charging system, DC-DC converter system, fuel cell system, low-voltage lithium battery system, shifting system, and electronically controlled air suspension system.

[0009] In one possible implementation, the data upload instruction carries target data range information, which includes at least one of target time period, target network segment, and target data length. Determining at least one target message corresponding to a data upload instruction within at least one Ethernet message, including: The target packet is determined by matching it with the target data range information based on at least one of the Ethernet packet header timestamp, network segment status, and data length.

[0010] Secondly, this application provides a vehicle data uploading method, applied to an on-board gateway node, including: Mirroring the packets from each network segment in the vehicle; The formats of the packets from each network segment are converted to obtain the corresponding Ethernet packets. The Ethernet packets include a header and a data segment. The header is used to indicate the metadata of the packets in the corresponding network segment, and the data segment contains the mirror data of the packets in the corresponding network segment. Each Ethernet packet is forwarded to the data upload node so as to upload each Ethernet packet to the cloud using the method described in the first aspect.

[0011] In one possible implementation, the metadata includes the protocol version, sequence number, header timestamp, and data length. Among them, the protocol version is used to indicate the format protocol used to implement the image encapsulation; the sequence number is used to indicate the generation number of the corresponding Ethernet packet; the header timestamp is used to indicate the time when the corresponding Ethernet packet was generated; and the data length is used to indicate the length of the corresponding data segment.

[0012] In one possible implementation, the data segment includes a data header and a payload segment, with the payload segment used to carry the mirrored data; The header contains a network segment status validity identifier, a message identifier validity identifier, and a payload validity identifier; When the network segment status validity indicator is valid, the mirrored data carries a network segment status field. When the message identifier validity indicator indicates that the message identifier is valid, the mirrored data carries a message identifier field; When the payload validity identifier indicates that the data is valid, the mirrored data carries a payload field.

[0013] In one possible implementation, the header also includes a time offset timestamp, which indicates the time elapsed from the time the network segment's packets were collected to the time the corresponding Ethernet packet was generated.

[0014] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the methods of the first and second aspects described above.

[0015] The technical solution provided in this application offers at least the following benefits: This application converts the format of packets from various network segments acquired through mirroring within the vehicle, obtaining corresponding Ethernet packets including headers and data segments. These Ethernet packets are then forwarded to data upload nodes, which then upload them to the cloud. Thus, this application adopts an adaptive upload strategy based on the vehicle's operating scenario to upload Ethernet packets to the cloud, enabling on-demand uploading of vehicle data in different scenarios and reducing upload load. Furthermore, by mirroring and converting packets from various network segments within the vehicle, this application can losslessly preserve packet information from different network segments without parsing the packet content and convert it into a unified Ethernet packet format. This unified Ethernet packet format enables comprehensive collection of cross-network segment packets across the entire vehicle, reducing upload load while improving the integrity of vehicle data uploaded to the cloud, thus achieving effective monitoring of vehicle status.

[0016] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a topology diagram of a vehicle data upload system provided in an embodiment of this application; Figure 2 A flowchart illustrating a vehicle data uploading method provided in this application embodiment. Figure 1 ; Figure 3 A schematic diagram of an Ethernet packet format provided for an embodiment of this application; Figure 4 A schematic diagram of a message header format provided for an embodiment of this application; Figure 5 A schematic diagram illustrating the format of a data segment provided in an embodiment of this application; Figure 6 A flowchart illustrating a vehicle data uploading method provided in this application embodiment. Figure 2 ; Figure 7 This application provides a schematic diagram of the routing interaction for a vehicle data uploading method according to an embodiment of the present application. Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0019] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0020] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0021] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0022] With the rapid development of intelligent connected vehicles, the real-time, efficient, and comprehensive collection and uploading of vehicle operation data to the cloud platform has become an important technical requirement for realizing vehicle status monitoring, fault diagnosis, optimization of driver assistance functions, and meeting national regulatory requirements.

[0023] The existing vehicle electronic and electrical architecture contains multiple bus networks (such as Controller Area Network (CAN), Local Interconnect Network (LIN), Ethernet, etc.), which are isolated from each other and have significantly different data protocols and transmission rates. Different types of network segments (such as powertrain CAN segment, body CAN segment, lighting LIN segment, and wiper LIN segment) are established based on different types of bus networks to transmit corresponding vehicle operation data.

[0024] For vehicle data acquisition and uploading solutions, there are typically two approaches: direct TBOX (Telematics-BOX, remote communication terminal) acquisition and uploading, or traditional gateway-routing signal solutions. The direct TBOX acquisition and uploading solution involves directly connecting the TBOX to a small number of specific CAN network segments to collect data. This solution has a limited acquisition range, lacks a unified global time reference across network segments, makes cross-segment timing analysis difficult, and requires modification of the TBOX hardware interface when adding new network segments, resulting in poor scalability. The traditional gateway-routing signal solution utilizes a gateway to route specific signals for TBOX acquisition. This solution requires parsing, extracting, and reassembling messages, resulting in a high processing load. Furthermore, due to the inconsistent formats of multi-source data, signal routing may discard original message information, making it impossible to obtain the complete message context.

[0025] In summary, current solutions for vehicle data collection and uploading typically only collect and upload specific and single-type network segment data. Furthermore, the collected data does not cover all vehicle operation data, or complete message context cannot be obtained, resulting in incomplete vehicle data uploaded to the cloud. Consequently, effective monitoring of vehicle status cannot be achieved. Moreover, these solutions usually upload all collected vehicle data at once, leading to a massive data volume upload in a short period, increasing the upload load, causing communication delays between the vehicle and the outside world, and increasing the access pressure on the cloud server.

[0026] To address the aforementioned technical issues, this application provides a vehicle data uploading method. The gateway node performs format conversion on the packets from various network segments mirrored within the vehicle, obtaining corresponding Ethernet packets including headers and data segments. These Ethernet packets are then forwarded to the data upload node, which uploads them to the cloud. Thus, this application adopts an adaptive upload strategy based on the vehicle's operating scenario to upload Ethernet packets to the cloud, enabling on-demand uploading of vehicle data in different scenarios and reducing the upload load. Furthermore, by mirroring and converting the packets from various network segments within the vehicle, this application can losslessly preserve packet information from different network segments without parsing the packet content and convert it into a unified Ethernet packet format. This unified Ethernet packet format achieves full coverage collection of cross-network segment packets for the entire vehicle, reducing the upload load while improving the integrity of the vehicle data uploaded to the cloud, enabling effective monitoring of the vehicle's status.

[0027] Figure 1 This is a topology diagram of a vehicle data upload system provided in an embodiment of this application. Figure 1 As shown, the vehicle data upload system includes an on-board gateway node 101, a domain controller 102, a data upload node 103, a cloud 104, and multiple ECUs (Electronic Control Units) with different functions.

[0028] The vehicle gateway node 101 is connected to the domain controller 102 and the data upload node 103 respectively. The domain controller 102 is connected to multiple ECUs with different functions. The data upload node 103 and the cloud 104 realize data uploading and downloading.

[0029] In this embodiment, the vehicle gateway node 101 mirrors and collects messages from various network segments in the ECUs of different functions in the vehicle through the domain controller 102. Of course, the vehicle gateway node 101 itself can also obtain network segment messages uploaded by the corresponding controller. The vehicle gateway node 101 converts the format of each network segment message to obtain the corresponding Ethernet message, and then forwards each Ethernet message to the data upload node 103, i.e., TBOX, so that the data upload node 103 can upload each Ethernet message to the cloud 104. The messages of each network segment include received messages and transmitted messages. The network segments include at least the CAN network segment, J1939CAN network segment, LVDS network segment, LIN network segment, CAN FD network segment, and Ethernet network segment.

[0030] After obtaining at least one Ethernet packet forwarded by the vehicle gateway node 101, the data upload node 103 caches the at least one Ethernet packet locally, determines the target upload strategy according to the preset upload conditions, and uploads the cached at least one Ethernet packet to the cloud 104 through the target upload strategy.

[0031] The vehicle data uploading method provided in this application embodiment will be described in detail below with reference to the accompanying drawings.

[0032] The vehicle data uploading method provided in this application embodiment is applied to Figure 1 The vehicle data upload method shown is implemented using the vehicle gateway node 101 in the system.

[0033] Figure 2 A flowchart illustrating a vehicle data uploading method provided in this application embodiment. Figure 1 . Figure 3 This is a schematic diagram of an Ethernet message format provided in an embodiment of this application. Figure 4 This is a schematic diagram of a message header format provided for an embodiment of this application. Figure 5 This is a schematic diagram illustrating the format of a data segment provided in an embodiment of this application. (In conjunction with...) Figures 2 to 5 The following describes the vehicle data uploading method provided in the embodiments of this application: S201, Mirror collects packets from each network segment in the vehicle.

[0034] In one possible implementation, the vehicle-mounted gateway node can collect packets within each network segment connected to it. These packets can include both sent and received packets within each network segment. That is, packets sent by the gateway node itself to the network segment and packets received from the network segment can both be collected, thereby ensuring full coverage of data in each network segment. All packets within each network segment can be collected without filtering or discarding them.

[0035] In one possible implementation, mirror acquisition can be understood as not parsing the message content and extracting signals, but rather preserving and recording the original information of the message completely.

[0036] Specifically, the vehicle-mounted gateway node can perform mirroring by integrating the following information: message identifier, data field length, data field content, network segment type, network segment identifier, and network segment status. It may also include information such as the message's receive / send timestamp. Among these, the message identifier, data field length, and data field content represent the original information of the message itself; the network segment type, network segment identifier, and network segment status represent the network segment to which the message belongs and its status; and the receive / send timestamp represents the time the message was collected.

[0037] The above-mentioned mirror acquisition method can completely preserve the original message information without parsing the message content, avoiding the problem of message information loss in the signal routing method. At the same time, since there is no need to extract and reassemble the signal, the processing load of the gateway node can be reduced.

[0038] In another possible implementation, the conditions for the vehicle gateway node to initiate mirror data collection may include: the vehicle being powered on and meeting any of the following conditions: the vehicle-to-everything (V2X) service platform (i.e., the cloud) issues a data collection start command; or a preset scenario trigger event is detected. That is, when the vehicle is powered on and receives the data collection start command issued by the cloud, or when the vehicle is powered on and a preset scenario trigger event is detected, the vehicle gateway node can begin mirroring and collecting packets from each network segment.

[0039] By setting data collection initiation conditions, invalid data collection can be avoided, saving in-vehicle network and storage resources. The preset scenario trigger events can include scenarios such as the activation of driver assistance functions, as described in the embodiments below.

[0040] S202. Convert the format of the packets from each network segment to obtain the corresponding Ethernet packets.

[0041] Ethernet packets consist of a header and a data segment. The header indicates the metadata of the packet for the corresponding network segment, and the data segment contains the mirror data of the packet for the corresponding network segment.

[0042] Specifically, the collected network segment packets are converted into Ethernet packets, which can be Ethernet UDP (User Datagram Protocol) packets. Compared with Transmission Control Protocol (TCP), Ethernet UDP packets do not require establishing a connection and have a smaller header overhead, making them suitable for high-frequency, high-volume data mirroring transmission scenarios that allow for a small amount of data loss.

[0043] Combination Figure 3 As shown, a formatted Ethernet packet can include a header and data segments (consisting of multiple Data segments). The header indicates the metadata of the corresponding network segment packet, and the data segments carry mirror data for each network segment packet. The "Eth" field in the Ethernet packet indicates the Ethernet protocol used for transmission at the data link layer; the "IP" field indicates the protocol used at the network layer, such as IPv4 or IPv6; and the "UDP" field indicates the protocol used at the transport layer.

[0044] In one possible implementation, combined with Figure 4 As shown, the metadata indicated by the message header includes the Protocol Version, Sequence Number, Header Timestamp, and Data Length.

[0045] The protocol version indicates the format protocol used to implement encapsulation, i.e. format conversion. The protocol version field can be 1 byte, and the current default value is 1. Values ​​2 to 127 can be used for future extensions of the AUTOSAR standard, and values ​​128 to 255 can be used for user-specific protocols.

[0046] The sequence number is used to indicate the generation number of the corresponding Ethernet packet. The sequence number field can be 1 byte. The value of the sequence number can start from 0 and increment with each transmission of the packet. When it reaches 255, it can start polling again from 0. Packet loss can be detected by the continuity of the sequence number.

[0047] The header timestamp is used to indicate the time when the corresponding Ethernet message was generated. The header timestamp field can be 10 bytes, which can represent the absolute time reference in seconds and nanoseconds since January 1, 1980. This absolute time reference can be determined by time synchronization information, which can include satellite time synchronization information or network time synchronization information, such as Global Positioning System (GPS) time synchronization, Network Time Protocol (NTP) synchronization, etc. Unified time synchronization can ensure time consistency between different network segments and different acquisition nodes.

[0048] The data length field is used to indicate the length of the corresponding data segment. The data length field can be 2 bytes and is encoded with the most significant bit (MSB). When a data segment contains multiple mirror data, the receiving end can determine the number of mirror data carried by the data segment based on the data length.

[0049] In another possible implementation, combined with Figure 5 As shown, the data segment includes a data header and a payload segment. The payload segment is used to carry the mirrored data. The data header contains the Network State Available identifier, the Frame ID Available identifier, and the Payload Available identifier.

[0050] Specifically, when the network segment status validity indicator is valid, the mirrored data carries a network segment status field. The network segment status validity indicator is used to indicate whether the network segment status field exists in the data header and can be 1 bit. When the packet identifier validity indicator is valid, the mirrored data carries a packet identifier field. The packet identifier validity indicator is used to indicate whether the packet identifier field exists in the data header and can be 1 bit. When the payload validity indicator is valid, the mirrored data carries a payload field. The payload validity indicator is used to indicate whether the payload length field and the payload field exist in the subsequent payload segment and can be 1 bit.

[0051] In another possible implementation, the data header also includes a time offset timestamp, which indicates the time elapsed from the time the packet of the network segment is collected to the time the corresponding Ethernet packet is generated. In other words, it reflects the time offset between the source packet reception and the header timestamp. The time offset timestamp field can be 2 bytes and the value can be a multiple of 10 microseconds.

[0052] In one possible implementation, the data header may also include a Network Type field and a Network ID field. The Network Type field identifies the bus type of the network segment to which the packet belongs and can be 5 bits; the Network ID field identifies the network segment to which the packet belongs and can be 8 bits. The specific values ​​can be defined according to the Ethernet configuration specification. The combination of the Network Type field and the Network ID field can uniquely identify the network segment to which the packet belongs, enabling traceability of data sources across multiple network segments.

[0053] In one possible implementation, the data header may further include a Frame ID field and a Payload Length field. The Frame ID field is associated with the bus determined by the Network Type field and the Network Identifier field. When the source bus status changes, the Frame ID field can be omitted, and its presence can be indicated by the Frame Identifier Validity field. Similarly, the Payload Length field can be omitted when the source bus status changes, and its presence can be indicated by the Payload Validity field.

[0054] The optional field mechanism described above avoids redundantly filling all fields for each mirrored data, reducing the byte overhead of Ethernet packets and improving bandwidth utilization efficiency.

[0055] In one possible implementation, multiple payload segments within a data segment can carry one or more mirrored data entries. When a data segment contains multiple mirrored data entries, these entries can be arranged in chronological order according to the time offsets indicated by their respective time offset timestamps, allowing the receiving end to reconstruct the original message in chronological order.

[0056] S203. Forward each Ethernet packet to the data upload node so that each Ethernet packet can be uploaded to the cloud through the data upload node.

[0057] In one possible implementation, the vehicle-mounted gateway node forwards the received Ethernet packets to the data upload node via its internal switch function (Switch node). This switch forwarding enables network isolation and bandwidth management between the acquisition and upload sides, and supports the aggregation and transmission of multiple mirrored packets.

[0058] In one implementation, each Ethernet packet can be aggregated by the same switch and then forwarded to the data upload node to adapt to the evolution of the vehicle network architecture and the expansion of network segments.

[0059] In one implementation, the data uploading node can be a remote communication terminal (TBOX), which can package and upload relevant data to the cloud platform. It should be noted that the cloud in this embodiment may include a vehicle networking service platform, or other cloud platforms that require vehicle data.

[0060] In this embodiment, the packets from each network segment acquired through mirroring within the vehicle are format-converted to obtain corresponding Ethernet packets including headers and data segments. These Ethernet packets are then forwarded to a data upload node, which uploads them to the cloud. Thus, by mirroring and format-converting packets from each network segment of the vehicle, this application can preserve packet information from different network segments without parsing the packet content and convert it into a unified Ethernet packet format. This unified Ethernet packet format enables comprehensive acquisition of cross-network segment packets across the entire vehicle, improving the integrity of vehicle data uploaded to the cloud and thereby achieving effective monitoring of vehicle status.

[0061] Another vehicle data uploading method provided in this application embodiment is applied to... Figure 1 The vehicle data upload method shown is represented by data upload node 103 in the system.

[0062] Figure 6 A flowchart illustrating a vehicle data uploading method provided in this application embodiment. Figure 2 Combining Figure 6 The following describes the vehicle data uploading method provided in the embodiments of this application: S301. Obtain at least one Ethernet packet forwarded by the vehicle gateway node.

[0063] In one possible implementation, the data upload node can be a remote control terminal (TBOX). The data upload node can receive at least one Ethernet packet forwarded by the vehicle gateway node via a switch.

[0064] The format of the Ethernet packet can refer to the aforementioned embodiment, including a packet header and a data segment. The packet header may contain metadata such as protocol version, sequence number, header timestamp, and data length. The data segment may contain mirror data of packets from each network segment, which will not be elaborated here.

[0065] S302. Locally cache at least one Ethernet packet.

[0066] In one possible implementation, the data upload node can store at least one received Ethernet packet on a local storage medium for local caching. Local caching can prevent data loss in the event of communication failure between the data upload node and the cloud platform, ensuring the integrity of the vehicle's data.

[0067] In one possible implementation, the data upload node can also compress Ethernet packets in the local storage medium into tar.gz format archive files. Since the total vehicle data volume is large, compression using the tar.gz format can reduce the compression ratio to approximately 30%, decreasing storage usage and upload bandwidth consumption. The compressed archive files can be directly parsed by the backend host computer, which can directly parse files in .asc or .blf formats.

[0068] In another possible implementation, the data uploading node can delete the uploaded Ethernet packet from the local cache after it has been successfully uploaded to the cloud, in order to free up cache space, avoid cache backlog, and ensure that there is still sufficient cache capacity to carry new data during network outages.

[0069] In one possible implementation, the conditions for the data upload node to receive and cache Ethernet messages may include: the vehicle is powered on and meets any of the following conditions: the vehicle network service platform issues an upload command; or a specific scenario upload event is detected.

[0070] S303. Based on the vehicle's operating scenario, determine the target upload strategy and upload at least one cached Ethernet packet to the cloud using the target upload strategy.

[0071] The target upload strategy is used to indicate the message upload strategy adopted to suit the corresponding operating scenario.

[0072] In one possible implementation, before determining the target upload strategy, the data upload node checks the communication status between itself and the cloud (such as a vehicle network service platform). If the communication status is normal, the target upload strategy is determined. If the communication status is abnormal, Ethernet packets can continue to be cached, and the cached Ethernet packets can be uploaded to the cloud after the communication status is restored to normal, thereby ensuring that the data is not lost.

[0073] The vehicle's operating scenarios include scenarios where the vehicle malfunctions, scenarios where driver assistance functions are triggered, and scenarios where data upload instructions are received from the cloud.

[0074] In one possible implementation, it is detected whether a preset fault has occurred in the vehicle. If a preset fault has occurred, the target upload strategy is determined to be a fault data upload strategy. The fault data upload strategy is used to indicate that at least one fault message related to the preset fault is identified in at least one Ethernet message, and at least one fault message is uploaded to the cloud.

[0075] Among them, the preset fault is any one of the vehicle's multiple preset subsystems malfunctioning.

[0076] Specifically, in at least one Ethernet message, a message related to the failed subsystem is marked as a fault message. Preset subsystems include at least one of the following: Anti-lock Braking System (ABS), Electronic Park Brake (EPB), Vehicle Control Unit (VCU), Electric Drive System, Battery System, On-board Charging System, DC-DC Converter System, Fuel Cell System, Low-voltage Lithium Battery System, Shift System, and Electronically Controlled Air Suspension (ECAS).

[0077] When any preset subsystem fails, the data upload node can collect continuous messages within preset time periods before and after the failure according to the original message frequency, and upload them to the cloud for storage. The preset time period can be 5 seconds or other values ​​configured by the cloud.

[0078] The fault data upload strategy extends the fault scope of the fault data upload strategy to multiple preset subsystems of the vehicle, enabling targeted collection and tracing of vehicle-level fault data.

[0079] In one possible implementation, if the vehicle does not experience a preset fault, it is detected whether a preset scenario is triggered. If the preset scenario is triggered, the target upload policy is determined to be a specific scenario upload policy. The specific scenario upload policy is used to indicate that at least one scenario message related to the preset scenario is identified in at least one Ethernet message, and at least one scenario message is uploaded to the cloud.

[0080] The preset scenarios include at least those in which the vehicle's driver assistance functions are activated. These driver assistance functions include at least one of the following: Automatic Emergency Braking (AEB), Forward Collision Warning (FCW), Lane Departure Warning (LDW), Lane Keeping Assist (LKA), and Intelligent Cruise Assist (ICA).

[0081] Specifically, in at least one Ethernet packet, packets within a preset time before and after the activation of the driving assistance function are marked as scenario packets. The preset time can be 5 seconds. That is, when the driving assistance function is activated, consecutive packets within 5 seconds before and after the activation can be marked as scenario packets and uploaded to cloud storage.

[0082] In one possible implementation, the scenario triggering event may also include the state transition of the driving assistance function, such as the intelligent navigation assistance function transitioning from active to fault, from active to suppressed, or from active to standby. When the state transition occurs, consecutive messages within 5 seconds before and after the state transition can be marked as scenario messages.

[0083] The specific scenario upload strategy uploads scenario messages associated with the activation or state transition of driving assistance functions to the cloud, which can provide complete scenario data for behavior analysis, false trigger analysis, and function calibration of driving assistance functions.

[0084] In one possible implementation, if the preset scenario is not triggered, it is detected whether a data upload command is issued from the cloud. If so, the target upload strategy is determined to be the command upload strategy. The command upload strategy is used to instruct at least one target packet corresponding to the data upload command in at least one Ethernet packet, and to upload at least one target packet to the cloud.

[0085] The data upload command carries target data range information, which includes at least one of the following: target time period, target network segment, and target data length.

[0086] Specifically, the target packet is determined by matching it with the target data range information based on at least one of the Ethernet packet's header timestamp, network segment status, and data length. For example, when the target data range information includes a target time period, Ethernet packets with header timestamps within that time period can be identified as target packets; when the target data range information includes a target network segment, Ethernet packets whose network segment status matches the target network segment can be identified as target packets; and when the target data range information includes a target data length, Ethernet packets whose data length matches the target data length can be identified as target packets.

[0087] The command upload strategy sends data upload commands to the cloud along with the target data range information, enabling remote on-demand retrieval of vehicle data from the cloud and avoiding bandwidth waste caused by full retransmission.

[0088] If no data upload instruction is issued from the cloud, the target upload strategy is determined to be a fixed-period upload strategy. The fixed-period upload strategy is used to instruct at least one cached Ethernet packet to be uploaded to the cloud according to a preset period.

[0089] The preset period can be a configurable period. The data upload node can receive the period configuration information sent from the cloud and update the preset period according to the period configuration information, so as to adapt to the data reporting needs of different working conditions and different vehicle models.

[0090] In another possible implementation, when multiple upload strategies simultaneously meet the triggering conditions, uploads can be executed according to a preset priority. For example, the priority of the command upload strategy can be higher than that of the fixed-period upload strategy, and the priorities of other upload strategies can be set according to actual needs. By using preset priority rules, urgent data retrieval needs can be prioritized, avoiding bandwidth contention and data conflicts caused by concurrent uploads.

[0091] In one implementation, the data uploading node can upload data to the vehicle-to-everything (V2X) service platform via wireless communication. The wireless communication can be cellular communication methods such as fourth-generation (4G) or fifth-generation (5G), or other wireless communication methods; this disclosure does not limit the specific method used.

[0092] In this embodiment, the data upload node receives the Ethernet packets encapsulated by the gateway node and performs local caching and compression. When the upload conditions are met, the vehicle data is uploaded to the cloud according to the target upload strategy. This enables on-demand uploading of vehicle data in different scenarios, ensuring data integrity while avoiding the massive data volume caused by uploading all collected vehicle data for a long time. It also effectively collects the real-time operating status of the vehicle, balancing the amount of uploaded data and real-time performance, and reducing the upload load.

[0093] Figure 7 This is a schematic diagram of the routing interaction for a vehicle data uploading method provided in an embodiment of this application.

[0094] Combination Figure 7 As shown, after the domain controller mirrors and collects messages (such as CAN messages and LIN messages) from various network segments in the ECUs of different functions in the vehicle, it forwards the collected messages to the vehicle gateway node. The vehicle gateway node converts the message format of each network segment to obtain the corresponding Ethernet message, and then forwards each Ethernet message to the data upload node, i.e., TBOX. The data upload node can execute the steps of the vehicle data upload method described above, namely, locally caching at least one Ethernet message, determining the target upload strategy according to preset upload conditions, and uploading the cached Ethernet message to the cloud wirelessly through the target upload strategy. The cloud can receive and store the data uploaded by the data upload node, and can also issue data upload commands to the data upload node to realize remote on-demand data retrieval.

[0095] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device includes: a processor 801, a memory 802, a communication interface 803, and a bus 804. The processor 801, the memory 802, and the communication interface 803 can be connected via the bus 804.

[0096] Processor 801 is the control center of the communication device. It can be a single processor or a collective term for multiple processing elements. For example, processor 801 can be a general-purpose central processing unit (CPU) or other general-purpose processors. Among them, the general-purpose processor can be a microprocessor or any conventional processor.

[0097] As one embodiment, processor 801 may include one or more CPUs, for example Figure 8 CPU0 and CPU1 are shown in the diagram.

[0098] The memory 802 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0099] In one possible implementation, the memory 802 can exist independently of the processor 801. The memory 802 can be connected to the processor 801 via a bus 804 and is used to store instructions or program code. When the processor 801 calls and executes the instructions or program code stored in the memory 802, it can implement the vehicle data uploading method provided in the following embodiments of this application.

[0100] In another possible implementation, the memory 802 can also be integrated with the processor 801.

[0101] Communication interface 803 is used for connecting the communication device to other devices via a communication network, such as Ethernet, wireless access network, or wireless local area network (WLAN). Communication interface 803 may include a receiving unit for receiving data and a transmitting unit for sending data.

[0102] The 804 bus can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0103] As one possible implementation, the memory 802 can exist independently of the processor 801. The memory 802 can be connected to the processor 801 via a bus 804 and is used to store instructions or program code. When the processor 801 calls and executes the instructions or program code stored in the memory 802, it can implement the vehicle data uploading method provided in this embodiment of the invention.

[0104] In another possible implementation, the memory 802 can also be integrated with the processor 801.

[0105] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

Claims

1. A method for uploading vehicle data, characterized in that, Applied to data upload nodes, the method includes: Obtain at least one Ethernet packet forwarded by the vehicle gateway node; the at least one Ethernet packet is a corresponding packet obtained after format conversion of packets from different network segments in the vehicle. Local caching of the at least one Ethernet packet; Based on the vehicle's operating scenario, a target upload strategy is determined, and the cached at least one Ethernet packet is uploaded to the cloud using the target upload strategy; the target upload strategy is used to indicate the packet upload strategy adapted to the corresponding operating scenario.

2. The vehicle data uploading method according to claim 1, characterized in that, The step of determining the target upload strategy based on the vehicle's operating scenario includes: If the vehicle experiences a preset fault, the target upload strategy is determined to be a fault data upload strategy. The fault data upload strategy is used to instruct at least one fault message related to the preset fault to be identified in at least one Ethernet message, and the at least one fault message to be uploaded to the cloud. If the vehicle does not experience a preset fault, but a preset scenario is triggered, the target upload strategy is determined to be a specific scenario upload strategy. The specific scenario upload strategy is used to instruct at least one scenario message related to the preset scenario to be identified in at least one Ethernet message, and the at least one scenario message is uploaded to the cloud. If the vehicle does not trigger the preset scenario, and the cloud sends a data upload command, the target upload strategy is determined to be a command upload strategy. The command upload strategy is used to instruct at least one target message corresponding to the data upload command to be determined in at least one Ethernet message, and the at least one target message is uploaded to the cloud. If the cloud does not issue a data upload instruction, the target upload strategy is determined to be a fixed-period upload strategy. The fixed-period upload strategy is used to instruct the cached at least one Ethernet packet to be uploaded to the cloud according to a preset period.

3. The vehicle data uploading method according to claim 2, characterized in that, The preset scenarios include at least the scenarios in which the vehicle's driver assistance functions are activated; The step of determining at least one scenario message related to the preset scenario in the at least one Ethernet message includes: In the at least one Ethernet message, the message that falls within a preset time period before or after the activation time of the driving assistance function is marked as the scenario message; The driving assistance functions include at least one of automatic emergency braking, forward collision warning, lane departure warning, lane keeping assist, and intelligent navigation assist.

4. The vehicle data uploading method according to claim 2, characterized in that, The preset fault is any one of the multiple preset subsystems of the vehicle malfunctioning; The step of determining at least one fault message related to the preset fault in the at least one Ethernet message includes: In the at least one Ethernet packet, the packet related to the faulty subsystem is marked as the fault packet; The preset subsystem includes at least one of the following: anti-lock braking system, electronic parking system, vehicle controller, electric drive system, power battery system, on-board charging system, DC-DC converter system, fuel cell system, low-voltage lithium battery system, shifting system, and electronically controlled air suspension system.

5. The vehicle data uploading method according to claim 2, characterized in that, The data upload instruction carries target data range information, which includes at least one of target time period, target network segment, and target data length. Determining at least one target packet corresponding to the data upload instruction from the at least one Ethernet packet includes: The target packet is determined by matching it with the target data range information based on at least one of the Ethernet packet header timestamp, network segment status, and data length.

6. A method for uploading vehicle data, characterized in that, Applied to vehicle gateway nodes, the method includes: The system collects packets from each network segment within the vehicle using a mirror image. The packets of each network segment are formatted to obtain the corresponding Ethernet packets; the Ethernet packets include a packet header and a data segment, the packet header is used to indicate the metadata of the packets corresponding to the network segment, and the data segment contains the mirror data of the packets corresponding to the network segment; Each of the Ethernet packets is forwarded to the data upload node to upload each of the Ethernet packets to the cloud using the method described in any one of claims 1 to 5.

7. The vehicle data uploading method according to claim 6, characterized in that, The metadata includes protocol version, sequence number, header timestamp, and data length; Wherein, the protocol version is used to indicate the format protocol used to implement the image encapsulation; the sequence number is used to indicate the generation number of the corresponding Ethernet packet; the header timestamp is used to indicate the time when the corresponding Ethernet packet was generated; and the data length is used to indicate the length of the corresponding data segment.

8. The vehicle data uploading method according to claim 6, characterized in that, The data segment includes a data header and a payload segment, wherein the payload segment is used to carry the mirrored data; The data header includes a network segment status validity identifier, a message identifier validity identifier, and a payload validity identifier; Wherein, when the network segment status validity identifier indicates that the network segment status is valid, the mirrored data carries a network segment status field; When the message identifier validity indicator is valid, the mirrored data carries a message identifier field; When the payload validity identifier indicates that the data is valid, the mirrored data carries a payload field.

9. The vehicle data uploading method according to claim 6, characterized in that, The data header also includes a time offset timestamp, which indicates the time elapsed from the time the packet of the network segment was collected to the time the corresponding Ethernet packet was generated.

10. An electronic device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the vehicle data uploading method as described in any one of claims 1 to 5, or the vehicle data uploading method as described in any one of claims 6 to 9.

Images