Whole vehicle data acquisition method and device, storage medium and electronic equipment
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ANHUI DEEPWAY TECHNOLOGY CO LTD
- Filing Date
- 2024-07-30
- Publication Date
- 2026-07-10
Smart Images
Figure CN119094624B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of vehicle communication, and in particular relates to a method, device, storage medium and electronic device for collecting vehicle data. Background Technology
[0002] Existing real-time vehicle data acquisition methods primarily rely on in-vehicle terminals such as TBOX (Telematics Box) to directly acquire CAN (Controller Area Network) bus data from the vehicle's internal bus system. However, this method has several drawbacks: When using TBOX to directly acquire vehicle data, the TBOX must be directly connected to each CAN bus to achieve full vehicle data acquisition. However, due to the increasing functionality of vehicles, the volume of data transmitted on the in-vehicle CAN bus is growing, placing higher demands on the CAN interface resources of the TBOX. Furthermore, the larger the data volume, the more CAN data the TBOX receives, the higher the computational requirements for its MCU. However, upgrading the TBOX's MCU specifications simply to acquire full vehicle data is not cost-effective. Summary of the Invention
[0003] This application aims to address at least one of the technical problems existing in the related art. To this end, this application proposes a whole-vehicle data acquisition method that can improve the flexibility and efficiency of whole-vehicle data acquisition without increasing the cost of TBOX hardware.
[0004] Firstly, this application provides a method for acquiring vehicle data, applied to various domain controllers of a vehicle system, the method comprising:
[0005] Collect CAN messages from the vehicle's CAN bus, wherein each CAN message contains multiple message frames and network segment identification information for each message frame;
[0006] The CAN message is converted into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1;
[0007] The big data message is sent to the remote communication terminal.
[0008] According to the vehicle data acquisition method of this application, each domain controller acquires CAN messages in its local area network and converts N first message frames with the same network segment identification information from CAN format to N SOMEIP protocol format SOMEIP data items according to the network segment identification information. Then, the N SOMEIP data items are combined into a large data message and finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0009] Secondly, this application provides a method for collecting vehicle data, applied to a remote communication terminal of a vehicle system, the method comprising:
[0010] The system receives large data packets sent by each domain controller. These large data packets are obtained by converting CAN packets collected by each domain controller from the vehicle's CAN bus into SOMEIP protocol format packets based on the network segment identification information of each packet frame in the CAN packets. Each large data packet includes N SOMEIP data items, which are obtained by converting N first packet frames with the same network segment identification information in the CAN packets. Each large data packet also includes the first network segment identification information corresponding to the first packet frame, where N is an integer greater than or equal to 1.
[0011] According to the vehicle data acquisition method of this application, each domain controller acquires CAN messages in its local area network and converts N first message frames with the same network segment identification information from CAN format to N SOMEIP protocol format SOMEIP data items according to the network segment identification information. Then, the N SOMEIP data items are combined into a large data message and finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the remote communication terminal only needs to receive the large data message. Therefore, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0012] Thirdly, this application provides a vehicle data acquisition device, which includes:
[0013] The acquisition module is used to acquire CAN messages in the vehicle's CAN bus. The CAN message contains multiple message frames and network segment identification information for each message frame.
[0014] The conversion module is used to convert the CAN message into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1;
[0015] The sending module is used to send the big data message to the remote communication terminal.
[0016] Fourthly, this application provides a vehicle data acquisition device, which includes:
[0017] The receiving module is used to receive large data messages sent by each domain controller. The large data messages are obtained by converting the CAN messages in the vehicle CAN bus collected by each domain controller into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN message. Each large data message includes N SOMEIP data items, which are obtained by converting N first message frames with the same network segment identification information in the CAN message. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
[0018] Fifthly, this application provides a domain controller that is communicatively connected to a remote communication terminal in a vehicle system. The domain controller includes:
[0019] The acquisition module is used to acquire CAN messages in the vehicle's CAN bus. The CAN message contains multiple message frames and network segment identification information for each message frame.
[0020] The conversion module is used to convert the CAN message into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1;
[0021] The sending module is used to send the big data message to the remote communication terminal.
[0022] Sixthly, this application provides a remote communication terminal that is communicatively connected to various domain controllers in a vehicle system. The remote communication terminal includes:
[0023] The receiving module is used to receive large data messages sent by each domain controller. The large data messages are obtained by converting the CAN messages in the vehicle CAN bus collected by each domain controller into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN message. Each large data message includes N SOMEIP data items, which are obtained by converting N first message frames with the same network segment identification information in the CAN message. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
[0024] In a seventh aspect, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the vehicle data acquisition method described in the first aspect above.
[0025] Eighthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the vehicle data acquisition method described in the first aspect above.
[0026] Ninthly, this application provides a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the vehicle data acquisition method as described in the first aspect.
[0027] In a tenth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the vehicle data acquisition method described in the first aspect above.
[0028] The technical solutions described in the embodiments of this application have at least the following technical effects:
[0029] The vehicle data acquisition method, apparatus, storage medium, and electronic device of this application embodiment involve each domain controller acquiring CAN messages from its local area network (LAN), and converting N first message frames with the same LAN identifier from the acquired multiple message frames into N SOMEIP protocol format SOMEIP data items according to the LAN identifier information. Then, the N SOMEIP data items are combined into a large data message, which is finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the remote communication terminal only needs to receive the large data message. Therefore, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0030] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description
[0031] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:
[0032] Figure 1 This is one of the flowcharts illustrating the method for collecting vehicle data provided in the embodiments of this application;
[0033] Figure 2 This is a schematic diagram of the architecture of the domain controller vehicle network system provided in the embodiments of this application;
[0034] Figure 3 This is a schematic diagram of the format of the SOMEIP data item after conversion by Standard CAN provided in the embodiments of this application;
[0035] Figure 4 This is a schematic diagram of the format of the SOMEIP data item after conversion by Extended CAN provided in the embodiments of this application;
[0036] Figure 5 This is a schematic diagram of the structure of a large data packet in the SOMEIP protocol format provided in the embodiments of this application;
[0037] Figure 6 This is a schematic diagram of the header structure of a big data message provided in an embodiment of this application;
[0038] Figure 7 This is a schematic diagram of the structure of the header referencing absolute time provided in the embodiments of this application;
[0039] Figure 8 This is a second schematic flowchart of the vehicle data collection method provided in the embodiments of this application;
[0040] Figure 9 This is one of the structural schematic diagrams of the vehicle data acquisition device provided in the embodiments of this application;
[0041] Figure 10 This is a second schematic diagram of the structure of the vehicle data acquisition device provided in the embodiments of this application;
[0042] Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0043] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.
[0044] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0045] The following description, in conjunction with the accompanying drawings, details the vehicle data acquisition method, apparatus, electronic device, and readable storage medium provided in this application through specific embodiments and application scenarios.
[0046] The method for collecting vehicle data can be applied to the terminal, specifically executed by the hardware or software within the terminal.
[0047] The vehicle data acquisition method provided in this application embodiment can be executed by an electronic device or a functional module or entity in an electronic device that can implement the vehicle data acquisition method. The electronic devices mentioned in this application embodiment include, but are not limited to, mobile phones, tablets, computers, cameras, and wearable devices. The vehicle data acquisition method provided in this application embodiment will be described below using an electronic device as the execution subject.
[0048] like Figure 1 As shown, this method for acquiring vehicle data is applied to various domain controllers within the vehicle system, including:
[0049] Step S100: Collect CAN messages from the vehicle's CAN bus. The CAN messages contain multiple message frames and the network segment identification information of each message frame.
[0050] S200, the CAN message is converted into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1.
[0051] S300, the big data message is sent to the remote communication terminal TBOX.
[0052] The vehicle data acquisition method provided in this application is compatible with current mainstream domain controller vehicle network systems (i.e., vehicle systems). It includes multiple data communication modules (DCMs) – namely, a domain controller, a gateway module (GW) with Ethernet switching capabilities, and a remote communication terminal (TBOX). Each DCM connects to its corresponding acquisition node via its own private CAN network and communicates with the GW. The GW communicates with the TBOX, and the TBOX communicates remotely with the TSP (cloud) via a 4G / 5G network. Figure 2 The vehicle system shown includes two DCMs, one GW, and one TBOX. Each DCM is connected to multiple acquisition nodes via a CAN bus, and the GW is also connected to multiple acquisition nodes via a CAN bus. The two DCMs communicate with the GW via Ethernet, and the GW communicates with the TBOX via Ethernet and a CAN bus. The TBOX communicates remotely with the TSP (cloud) via a 4G / 5G network.
[0053] The vehicle data acquisition method provided in this application embodiment can be executed by each domain controller in the vehicle system. Each domain controller will collect CAN messages from each communication node connected to its CAN bus. It can be understood that the CAN messages collected by each domain controller include multiple message frames and network segment identification information of each message frame. That is, each domain controller can collect multiple message frames from different network segments, and the multiple message frames are converged into a CAN message at the domain controller. To address the increased hardware costs of existing TBOX systems that require handling and processing different CAN message formats when forwarding CAN messages, a new approach is proposed: converting CAN messages into large data messages in the SOMEIP (Scalable Service-Oriented Middleware over IP protocol, an Ethernet-based communication protocol for service-oriented interaction) format within the domain controller. Since these large data messages enable remote interaction, they eliminate the need for remote terminals to perform conversion and analysis when forwarding them, thus saving potential hardware costs. Furthermore, each domain controller handles the conversion of the acquired CAN message frames independently, eliminating the need for centralized processing at the TBOX, resulting in high acquisition efficiency and flexibility. Specifically, N first message frames with the same network segment identifier information from multiple collected message frames can be converted from CAN format into N SOMEIP protocol format SOMEIP data items, and then N SOMEIP data items can be combined into a large data message. It can be understood that message frames from the same network segment usually have data with the same or similar characteristics, such as vehicle air conditioning temperature, humidity, air outlet direction control parameters, and vehicle forward, reverse, left turn, right turn, etc., which all come from the same network segment. Therefore, the large data message formed by converting N first message frames with the same network segment identifier into N SOMEIP data items can usually reflect communication data that can reflect certain driving characteristics of the vehicle, which is convenient for subsequent analysis after vehicle data collection.
[0054] Furthermore, it is worth noting that in the vehicle data acquisition method provided in this application embodiment, CAN messages can be converted into multiple large data messages. For example, if a CAN message includes multiple CAN message frames containing m network segment identification information, then m large data messages can be formed, and each large data message can contain at least one first message frame. Thus, each domain controller acquires CAN messages from its local area network and converts its own large data messages according to the network segment identification information, and then sends its converted large data messages to the remote communication terminal, achieving efficient acquisition of vehicle data.
[0055] The vehicle data acquisition method provided in this application involves each domain controller acquiring CAN messages from its local area network (LAN). Based on the network segment identification information, N first message frames with the same network segment identification information from the acquired message frames are converted from CAN format to N SOMEIP protocol format SOMEIP data items. These N SOMEIP data items are then combined to form a large data message, which is finally forwarded to the remote communication terminal. Since the message format conversion occurs within each domain controller, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are minimal, meaning there is no need to increase the hardware cost of the remote communication terminal. Furthermore, each domain controller can simultaneously acquire and convert CAN messages containing different types of vehicle data from its local area network, achieving efficient and flexible acquisition of vehicle data.
[0056] It should be noted that because CAN message frames include Standard CAN and Extended CAN, and their lengths differ, the format of the SOMEIP data item after conversion from Standard CAN is as follows: Figure 3 As shown, the format of the SOMEIP data item after conversion by Extended CAN is as follows: Figure 4 As shown. To accommodate different types of CAN frames.
[0057] In some embodiments, the CAN message further includes the acquisition timestamp of each message frame. Step S200 includes: sorting the N SOMEIP data items according to the acquisition timestamp, and combining each SOMEIP data item with the acquisition timestamp of the corresponding first message frame to obtain a message data segment (Data); recording the first network identification information and the reference absolute time (Time Stamp) in the message header (Header), wherein the reference absolute time corresponds to one of the N acquisition timestamps, and is used to determine the absolute acquisition time of each SOMEIP data item; and obtaining the big data message from the message data segment (Data) and the message header (Header).
[0058] The absolute acquisition time of each message frame / SOMEIP data item is determined by introducing the acquisition timestamp and reference absolute time of the message frame, so as to facilitate subsequent analysis of vehicle data collected in a certain time period or time-domain analysis of vehicle data. Specifically, the N SOMEIP data items are sorted according to the acquisition timestamp, and each SOMEIP data item is combined with the acquisition timestamp of the corresponding first message frame to obtain a message data segment. The first network identification information and reference absolute time are recorded in the message header, and the big data message is obtained from the message data segment and the message header. That is, the big data message in this embodiment of the application includes at least a message data segment and a message header. The structure of the big data message in the SOMEIP protocol format is as follows: Figure 5 As shown.
[0059] It is understandable that when sorting the N SOMEIP data items according to the collection timestamps, they can be sorted in ascending or descending order according to the order of collection timestamps. Correspondingly, the N corresponding timestamps are also sorted in ascending or descending order. The N SOMEIP data items sorted in ascending order are combined with the N corresponding timestamps sorted in ascending order, in the form of [Data1, Data2, Data3…DataN; T1, T2, T3…TN]. Alternatively, the N SOMEIP data items sorted in descending order are combined with the N corresponding timestamps sorted in descending order, in the form of [DataN, DataN-1, DataN-2,…Data2, Data1; TN, TN-1, TN-2…T2, T1]. Or, the N SOMEIP data items sorted in ascending order are combined with the N corresponding timestamps sorted in descending order, in the form of [Data1, Data2, Data3…DataN; TN, TN-1, TN-2…T2, T1]. This yields the message data segment. It should be noted that the combination of N SOMEIP data items and N corresponding timestamps is not limited to the combination shown in the example above. Any combination of N SOMEIP data items and N corresponding timestamps should be within the protection scope of this technical solution.
[0060] Preferably, the N SOMEIP data items are sorted sequentially according to their acquisition time, and the acquisition timestamps of the N first message frames are combined sequentially with each SOMEIP data item to obtain the message data segment. That is, each SOMEIP data item is combined in a one-to-one correspondence with each acquisition timestamp, in a combination format such as: [Data1, T1, Data2, T2, Data3, T3…DataN, TN] or [T1, Data1, T2, Data2, T3, Data3…TN, DataN], etc. This recording method of the message data segment facilitates the subsequent calculation of the absolute acquisition time of each SOMEIP data item.
[0061] At the same time, the absolute time is also recorded in the header of the big data message to determine the absolute time of acquisition of the CAN message frame / SOMEIP data item.
[0062] In some embodiments, the reference absolute time preferably corresponds to the first or last acquisition timestamp after sorting the N acquisition timestamps in chronological order, or it can correspond to one of the acquisition timestamps in the middle. When calculating the acquisition absolute time, the reference absolute time is obtained by adding or subtracting each acquisition timestamp. For example, in case one: if the reference absolute time corresponds to the first acquisition timestamp, and the N SOMEIP data items are sorted in ascending order of acquisition time, then the acquisition absolute time T of the i-th CAN message frame / SOMEIP data item is... i =TimeStamp+(LocalTimeStamp) i -LocalTimeStamp1), where TimeStamp is the reference absolute timestamp, LocalTimeStamp i Let `LocalTimeStamp1` be the timestamp of the acquisition of the i-th CAN message frame / SOMEIP data item, and `LocalTimeStamp1` be the timestamp of the acquisition of the 1st CAN message frame / SOMEIP data item. In another case: if the reference absolute time corresponds to the last acquired timestamp, and the N SOMEIP data items are sorted in reverse order of acquisition time, then the absolute acquisition time T of the i-th CAN message frame / SOMEIP data item is... i =TimeStamp-(LocalTimeStamp) N -LocalTimeStamp N-i+1 ), where LocalTimeStamp N The last collected timestamp, LocalTimeStamp N-i+1This is the timestamp of the i-th CAN message frame / SOMEIP data item. For example, if the reference absolute time corresponds to a certain collection timestamp (target collection timestamp) located in the middle, and the N SOMEIP data items are sorted in ascending order of collection time, then the absolute collection time of each SOMEIP data item before the target collection timestamp is calculated according to the calculation method in case 2 above, and the absolute collection time of each SOMEIP data item after the target collection timestamp is calculated according to the calculation method in case 1 above.
[0063] In some embodiments, the reference absolute time recorded in the header is in the form of a timestamp in NTPv3, representing the time from 00:00 UTC on January 1, 1990 to the present. The length of this reference absolute time is 8 bytes, such as... Figure 7 As shown, the high 4 bytes are in seconds, and the low 4 bytes are in 1 / 2 to the power of 32 seconds, both using MSB (Most Significant Bit) bytes.
[0064] In some embodiments, such as Figure 6 As shown, the header of a large data message also includes a reserved field and a protocol version field. The reserved field is for future expansion and improves the continuity of the solution. In some embodiments, the reserved field is 2 bytes long. The protocol version field records the protocol version of the large data message to facilitate understanding the conversion method between the CAN message frame and the SOMEIP data item. In some embodiments, the protocol version field is 1 byte long, with the high 4 bits representing the major version and the low 4 bits representing the minor version. For example, if the current version is V1.0, then Version = 0x10. In some embodiments, the protocol version field is encoded in BCD (Binary Coded Decimal). In some embodiments, the network segment identifier field (Nw ID) in the header records network segment identification information. This network segment identifier identifies the network segment where the CAN message frame / SOMEIP data item resides. This network segment identifier field is 1 byte long, and only one network segment identifier is recorded in a single large data message.
[0065] In some embodiments, step S300 includes: sending the big data message to the remote communication terminal according to a preset sending period / set length data segment.
[0066] When sending large data packets to a remote communication terminal, the sending method can be either a preset sending cycle to ensure timely delivery, or a set-length data segment method. This means the large data packet is sent to the remote communication terminal only when the length of a data segment reaches the preset length, preventing the packet from being fragmented due to excessive length. Alternatively, a combination of both methods can be used: sending the large data packet only when either the preset sending cycle or the set-length data segment is met. For example, if the preset sending cycle hasn't arrived, but the length of a data segment in the large data packet has reached the set length, the large data packet is immediately sent to the remote communication terminal, and the next SOMEIP data item is written into the new large data packet. The set-length data segment can be 1400 bytes.
[0067] In some embodiments, before step S100, the process includes: receiving time synchronization messages sent by the remote communication terminal according to a set period, and synchronizing the time of each collection node under its jurisdiction with the remote communication terminal according to the time synchronization messages. If, after receiving the time synchronization message sent by the remote communication terminal for the first time, no time synchronization message is received from the remote communication terminal within the set period, local clock synchronization is initiated until the time synchronization message is received again.
[0068] Before collecting vehicle data, time synchronization messages sent by remote communication terminals are used to synchronize each data acquisition node in the vehicle system to ensure the time accuracy of the collected data. Simultaneously, if each domain controller encounters a situation where the remote communication terminal fails to send a time synchronization message in a timely manner during time synchronization, it initiates local clock synchronization to ensure the time accuracy of the entire vehicle system, allowing the cloud to completely reconstruct the collected data for a specific period of time.
[0069] like Figure 8 As shown in the embodiment of this application, the method for collecting vehicle data is applied to a remote communication terminal of a vehicle system, including:
[0070] S100' Receive big data messages sent by each domain controller, wherein the big data messages are obtained by converting the CAN messages in the vehicle CAN bus collected by each domain controller into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN messages. Each big data message includes N SOMEIP data items, and the N SOMEIP data items are converted from N first message frames with the same network segment identification information in the CAN messages. Each big data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
[0071] According to the vehicle data acquisition method provided in this application embodiment, each domain controller acquires CAN messages from its local area network. Based on the network segment identification information, N first message frames with the same network segment identification information in the acquired multiple message frames are converted from CAN format to N SOMEIP protocol format SOMEIP data items. Then, the N SOMEIP data items are combined into a large data message, which is finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the remote communication terminal only needs to receive the large data message. Therefore, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0072] In some embodiments, the big data message includes a message data segment and a message header. The message data segment is obtained by sorting the N SOMEIP data items according to the collection timestamp of each of the first message frames and combining the N SOMEIP data items with the collection timestamps of the corresponding N first message frames. The message header records a reference absolute time for determining the absolute collection time of each SOMEIP data item and the first network segment identification information. The reference absolute time corresponds to one of the N collection timestamps.
[0073] In some embodiments, the message data segment is obtained by sequentially sorting the N SOMEIP data items according to the acquisition time of each first message frame and sequentially combining each SOMEIP data item with the acquisition timestamp of the corresponding first message frame, and the reference absolute time in the message header corresponds to the first or last acquisition timestamp.
[0074] In the above embodiments, the absolute acquisition time of each message frame / SOMEIP data item is determined by introducing the acquisition timestamp of the message frame and the reference absolute time, so as to facilitate subsequent analysis of vehicle data acquired in a certain time period or to perform time-domain analysis on the vehicle data. The sorting and combination methods of each SOMEIP data item and each acquisition timestamp are as described in the previous embodiments, and will not be repeated here.
[0075] In some embodiments, before step S100', the process includes: performing external time synchronization with the cloud, and after completing the external time synchronization, sending time synchronization messages to each of the domain controllers according to a set period.
[0076] Before synchronizing with each domain controller, the remote communication terminal first synchronizes with an external network or GPS to ensure the time accuracy of the entire vehicle system.
[0077] Specifically, the Master (remote communication terminal) should complete time synchronization with the network or GPS within 30 seconds after network wake-up; after external synchronization is completed, it should start periodically broadcasting time synchronization messages and have the ability to respond to large data messages; the domain controller should have the ability to receive broadcast time synchronization messages within 30 seconds after wake-up, and within 100ms of receiving the first frame of broadcast time synchronization message, it should start creating and sending large data messages. At the same time, the domain controller should be able to fill in the correct acquisition timestamp and record the correct reference absolute time in the large data messages; at the same time, after receiving the broadcast time synchronization message from the Master, if it is unable to receive the broadcast time synchronization message after a period of time, the domain controller should use the local crystal oscillator to maintain time until the Master resumes sending broadcast time synchronization messages.
[0078] In some embodiments, after step S100', the process includes: uploading the big data message to the cloud according to a preset rule and / or calculating the absolute collection time of each SOMEIP data item based on the reference absolute time and each collection timestamp.
[0079] In this embodiment, the calculation of the absolute collection time of each SOMEIP data item based on the reference absolute time and each collection timestamp can refer to the calculation method in the previous embodiment, and will not be repeated here. It is worth noting that uploading big data packets to the cloud and calculating the absolute collection time of each SOMEIP data item can be performed in parallel, or only one of the two can be performed as needed.
[0080] In this embodiment, uploading big data packets to the cloud according to preset rules includes at least the following methods:
[0081] First, the received large data packets are cached. When the caching time reaches a preset limit or the number of cached packets reaches a preset limit, the cached large data packets are uploaded to the cloud. This upload method is suitable for scenarios with low real-time requirements, saving data bandwidth while ensuring the accuracy of the uploaded data. The preset caching time can be 1 minute.
[0082] Second, determine if the transmission link is functioning properly (e.g., if its load is less than the set communication load). If the transmission link is confirmed to be functioning properly (its load is less than the set load), then upload the received large data packets to the cloud. This upload method ensures that large data packets are uploaded accurately and avoids upload failures due to network issues.
[0083] Third, determine whether a predefined event has occurred, such as an emergency braking event or a sharp turn event. If the predefined event is confirmed to have occurred, upload large data packets within a specific time period before and after the event (e.g., 15 seconds before and after). This upload method can save data traffic and reduce the transmission of unnecessary data.
[0084] Fourth, configure the upload enable of the remote communication terminal. Responding to the user's enable selection, large data packets are uploaded when upload enable is enabled, and not when upload enable is disabled. Specifically, this can be achieved by writing DID 0x0908 using the 2E service (TBD), where writing 0x1 enables large data upload and writing 0x0 disables it. This method can meet the user's flexibility and personalization needs.
[0085] Furthermore, it should be noted that flexible upload protocols can be used when uploading large data packets to the cloud, such as MQTTT (Message Queuing Telemetry Transport) and HTTP (Hypertext Transfer Protocol). The large data packet upload protocol should use a separate port number, such as 30500 for the Agent and 30550 for the Master.
[0086] The vehicle data acquisition method provided in this application can be executed by a vehicle data acquisition device. This application uses the vehicle data acquisition device executing the vehicle data acquisition method as an example to illustrate the vehicle data acquisition device provided in this application.
[0087] This application also provides a vehicle data acquisition device, such as... Figure 9 As shown, the vehicle data acquisition device includes: an acquisition module 100, used to acquire CAN messages from the vehicle's CAN bus, wherein the CAN messages contain multiple message frames and network segment identification information for each message frame; a conversion module 200, used to convert the CAN messages into large data messages in SOMEIP protocol format according to the network segment identification information of each message frame; wherein each large data message includes N SOMEIP data items, the N SOMEIP data items are obtained by converting N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1; and a sending module 200, used to send the large data messages to a remote communication terminal.
[0088] According to the vehicle data acquisition device provided in the embodiments of this application, each domain controller acquires CAN messages in its local area network, and converts N first message frames with the same network segment identification information from CAN format to N SOMEIP protocol format SOMEIP data items according to the network segment identification information. Then, the N SOMEIP data items are combined into a large data message, which is finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the remote communication terminal only needs to receive the large data message. Therefore, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0089] This application also provides a vehicle data acquisition device, such as... Figure 10 As shown, it includes: a receiving module for receiving large data messages sent by each domain controller, wherein the large data messages are obtained by converting CAN messages collected by each domain controller from the vehicle CAN bus into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN messages. Each large data message includes N SOMEIP data items, and the N SOMEIP data items are converted from N first message frames with the same network segment identification information in the CAN messages. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
[0090] According to the vehicle data acquisition device provided in the embodiments of this application, each domain controller acquires CAN messages in its local area network, and converts N first message frames with the same network segment identification information from CAN format to N SOMEIP protocol format SOMEIP data items according to the network segment identification information. Then, the N SOMEIP data items are combined into a large data message, which is finally forwarded to the remote communication terminal. Since the message format conversion occurs in each domain controller, the remote communication terminal only needs to receive the large data message. Therefore, the requirements for CAN interface resources and hardware computing power of the remote communication terminal are small, that is, there is no need to increase the hardware cost of the remote communication terminal. Moreover, each domain controller can simultaneously complete the acquisition and conversion of CAN messages of different types of vehicle data in its local area network, realizing efficient and flexible acquisition of vehicle data.
[0091] The vehicle data acquisition device in this application embodiment can be an electronic device or a component of an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the specific device.
[0092] The vehicle data acquisition device in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit it.
[0093] The vehicle data acquisition device provided in this application embodiment can realize all the processes implemented in the aforementioned method embodiments, and will not be described again here to avoid repetition.
[0094] This application embodiment also provides a domain controller, which is communicatively connected to a remote communication terminal in a vehicle system, including:
[0095] The acquisition module is used to acquire CAN messages from the vehicle's CAN bus. The CAN messages contain multiple message frames and network segment identification information for each message frame. The conversion module is used to convert the CAN messages into large data messages in SOMEIP protocol format according to the network segment identification information of each message frame. Each large data message includes N SOMEIP data items, which are obtained by converting N first message frames with the same network segment identification information. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1. The sending module is used to send the large data messages to the remote communication terminal.
[0096] This application embodiment also provides a remote communication terminal for communicating with various domain controllers in a vehicle system, including: a receiving module for receiving large data messages sent by various domain controllers, wherein the large data messages are obtained by converting CAN messages in the vehicle CAN bus collected by various domain controllers into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN messages, each large data message includes N SOMEIP data items, the N SOMEIP data items are obtained by converting N first message frames with the same network segment identification information in the CAN messages, and each large data message also includes first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1.
[0097] The domain controller and remote communication terminal provided in this application embodiment can implement the various processes implemented in the foregoing method embodiments, and will not be repeated here to avoid repetition.
[0098] In some embodiments, such as Figure 11 As shown, this application embodiment also provides an electronic device 800, including a processor 801, a memory 802, and a computer program stored in the memory 802 and executable on the processor 801. When the program is executed by the processor 801, it implements the various processes of the above-described vehicle data acquisition method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.
[0099] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.
[0100] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described vehicle data acquisition method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.
[0101] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0102] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for collecting vehicle data.
[0103] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0104] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described vehicle data acquisition method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0105] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.
[0106] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0107] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0108] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
[0109] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0110] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.
Claims
1. A method for collecting vehicle data, characterized in that, Applied to various domain controllers in the vehicle system, including: Collect CAN messages from the vehicle's CAN bus, wherein each CAN message contains multiple message frames and network segment identification information for each message frame; The CAN message is converted into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1; Send the big data message to the remote communication terminal; The CAN message also includes the acquisition timestamp of each message frame; the step of converting the CAN message into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame includes: sorting the N SOMEIP data items according to the acquisition timestamp, and combining each SOMEIP data item with the acquisition timestamp of the corresponding first message frame to obtain a message data segment; recording the first network segment identification information and the reference absolute time in the message header, wherein the reference absolute time corresponds to one of the N acquisition timestamps and is used to determine the absolute acquisition time of each SOMEIP data item; The big data message is obtained from the message data segment and the message header; Before acquiring CAN messages in the vehicle's CAN bus, the method further includes: receiving time synchronization messages sent by the remote communication terminal according to a set period, and synchronizing the time of each acquisition node under its jurisdiction with the remote communication terminal according to the time synchronization messages; if, after receiving the time synchronization messages sent by the remote communication terminal for the first time, no time synchronization messages are received within the set period, local clock synchronization is initiated until the time synchronization messages are received again. Within 30 seconds of network wake-up, the remote communication terminal completes time synchronization with the network or GPS. After external synchronization is completed, it begins periodically broadcasting the time synchronization message and has the ability to respond to large data messages. The domain controller should have the ability to receive the broadcast time synchronization message within 30 seconds of wake-up. Within 100ms of receiving the first frame of the broadcast time synchronization message, it should begin creating and sending the large data message. At the same time, the domain controller should be able to fill in the correct acquisition timestamp and record the correct reference absolute time in the large data message. If the domain controller cannot receive the broadcast time synchronization message after receiving it from the remote communication terminal for a period of time, it should use the local crystal oscillator to maintain time until the remote communication terminal resumes sending the broadcast time synchronization message.
2. The method according to claim 1, characterized in that, The step of sorting the N SOMEIP data items according to the collection timestamp, and merging each SOMEIP data item with the collection timestamp of the corresponding first message frame to obtain a message data segment includes: The N SOMEIP data items are sorted in chronological order of collection time, and the collection timestamps of the N first message frames are combined with each SOMEIP data item in chronological order to obtain the message data segment.
3. The method according to claim 2, characterized in that, The reference absolute time recorded in the message header corresponds to the first or last acquisition timestamp.
4. The method according to claim 1, characterized in that, The message header also includes a reserved field and a protocol version field.
5. The method according to any one of claims 1-4, characterized in that, Sending the big data message to the remote communication terminal includes: The big data message is sent to the remote communication terminal according to a preset sending period / set length data segment.
6. A method for collecting vehicle data, characterized in that, A remote communication terminal applied to a vehicle system, used to implement the method as described in any one of claims 1-5, comprising: The system receives large data packets sent by each domain controller. These large data packets are obtained by converting CAN packets collected by each domain controller from the vehicle CAN bus into SOMEIP protocol format packets based on the network segment identification information of each packet frame in the CAN packets. Each large data packet includes N SOMEIP data items, which are obtained by converting N first packet frames with the same network segment identification information in the CAN packets. Each large data packet also includes the first network segment identification information corresponding to the first packet frame, where N is an integer greater than or equal to 1. The big data message includes a message data segment and a message header. The message data segment is obtained by sorting the N SOMEIP data items according to the collection timestamp of each of the first message frames and combining the N SOMEIP data items with the collection timestamps of the corresponding N first message frames. The message header records a reference absolute time for determining the absolute collection time of each SOMEIP data item and the first network segment identification information. The reference absolute time corresponds to one of the N collection timestamps. Before receiving large data packets from each domain controller, the process also includes: Synchronize with the cloud's external time, and after completing the external time synchronization, send time synchronization messages to each of the domain controllers according to a set period; and After receiving large data packets from each domain controller, the process also includes: The big data messages are uploaded to the cloud according to preset rules and / or the absolute collection time of each SOMEIP data item is calculated based on the reference absolute time and each collection timestamp.
7. The method according to claim 6, characterized in that, The message data segment is obtained by sorting the N SOMEIP data items in order of their acquisition time in the first message frame and combining each SOMEIP data item with the acquisition timestamp of the corresponding first message frame in sequence. The reference absolute time in the message header corresponds to the first or last acquisition timestamp.
8. A vehicle data acquisition device, characterized in that, For implementing the method according to any one of claims 1-5, comprising: The acquisition module is used to acquire CAN messages in the vehicle's CAN bus. The CAN message contains multiple message frames and network segment identification information for each message frame. The conversion module is used to convert the CAN message into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1; The sending module is used to send the big data message to the remote communication terminal.
9. A vehicle data acquisition device, characterized in that, For implementing the method according to any one of claims 6-7, comprising: The receiving module is used to receive large data messages sent by each domain controller. The large data messages are obtained by converting the CAN messages in the vehicle CAN bus collected by each domain controller into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN message. Each large data message includes N SOMEIP data items, which are obtained by converting N first message frames with the same network segment identification information in the CAN message. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
10. A domain controller, communicatively connected to a remote communication terminal in a vehicle system, characterized in that, For implementing the method according to any one of claims 1-5, comprising: The acquisition module is used to acquire CAN messages in the vehicle's CAN bus. The CAN message contains multiple message frames and network segment identification information for each message frame. The conversion module is used to convert the CAN message into a large data message in SOMEIP protocol format according to the network segment identification information of each message frame; wherein, each large data message includes N SOMEIP data items, the N SOMEIP data items are converted from N first message frames with the same network segment identification information, and each large data message also includes the first network segment identification information corresponding to the first message frame, wherein N is an integer greater than or equal to 1; The sending module is used to send the big data message to the remote communication terminal.
11. A remote communication terminal, communicatively connected to various domain controllers in a vehicle system, characterized in that, For implementing the method according to any one of claims 6-7, comprising: The receiving module is used to receive large data messages sent by each domain controller. The large data messages are obtained by converting the CAN messages in the vehicle CAN bus collected by each domain controller into SOMEIP protocol format messages according to the network segment identification information of each message frame in the CAN message. Each large data message includes N SOMEIP data items, which are obtained by converting N first message frames with the same network segment identification information in the CAN message. Each large data message also includes the first network segment identification information corresponding to the first message frame, where N is an integer greater than or equal to 1.
12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method for collecting vehicle data as described in any one of claims 1-5 or 6-7.
13. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for acquiring vehicle data as described in any one of claims 1-5 or 6-7.