Data communication method and system for a vehicle

Abstract

The application provides a data communication method and system of a vehicle, for a first end in a vehicle domain controller, the first end being a first domain control module in the domain controller, or the first end being a first execution module controlled by the first domain control module; the method comprises the following steps: obtaining first data to be sent to a second end; the second end being a second domain control module and / or a second execution module; determining a target type of the first data; the target type comprising a real-time type or a non-real-time type; in the case that the target type is the real-time type, adding a time stamp to the first data and then performing cross-layer encapsulation to obtain second data after encapsulation; the cross-layer encapsulation is used for realizing direct encapsulation from an application layer to an Ethernet layer; and sending the second data to the second end through the Ethernet. The scheme improves the encapsulation efficiency for the real-time type data, thereby improving the communication efficiency between the first end and the second end.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to data communication methods and systems for vehicles. Background Technology

[0002] In the present and future, vehicles are becoming increasingly intelligent, and the complexity of in-vehicle platforms is also increasing. The real-time requirements for intra-domain and inter-domain cross-chip communication on in-vehicle platforms are also becoming more stringent.

[0003] Improving the efficiency of intra- and inter-domain Ethernet communication data across chips in a vehicle has become an urgent problem to be solved. Summary of the Invention

[0004] One of the objectives of this application is to provide at least one data communication method and system for vehicles, which improves encapsulation efficiency for real-time data, thereby improving the communication efficiency between the first and second ends.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows: In a first aspect, this application provides a data communication method for a vehicle, applied to a first end in a vehicle domain controller, wherein the first end is a first domain control module in the domain controller, or the first end is a first execution module controlled by the first domain control module; the method includes: acquiring first data to be sent to a second end; the second end being a second domain control module and / or a second execution module; determining the target type of the first data; the target type includes a real-time type or a non-real-time type; if the target type is a real-time type, adding a timestamp to the first data and then performing cross-layer encapsulation to obtain encapsulated second data; the cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer; wherein, if the first end is a first domain control module, the first data with added timestamps is encapsulated across layers through a network connection socket method or a service-oriented method to obtain encapsulated second data; if the first end is a first execution module, the first data with added timestamps is encapsulated across layers through a service-oriented method to obtain encapsulated second data, and the second data is sent to the second end via Ethernet.

[0006] Ethernet communication between the first end and the second end may include, but is not limited to: Ethernet communication between domain control modules, Ethernet communication between domain control modules and execution modules, and Ethernet communication between execution modules.

[0007] Based on the aforementioned technical means, data can be differentiated and processed according to whether it is real-time or not: For real-time data, by adding a timestamp and directly encapsulating it from the application layer to the Ethernet layer, the processing overhead of multiple intermediate layers in the traditional protocol stack is skipped, thereby significantly reducing data transmission latency, improving real-time response speed, and ensuring time synchronization accuracy. At the same time, this method uses Ethernet to achieve efficient communication between the domain control module and the execution module, which not only meets the stringent real-time requirements of vehicle control, but also simplifies the protocol stack design and improves the communication efficiency and determinism within the domain controller and between the domain controller and the execution end.

[0008] When implementing cross-layer encapsulation, different implementations at the first end can be encapsulated using appropriate methods to meet the needs of the first end in various scenarios. The domain control module can encapsulate timestamped data across layers via network connection sockets or a service-oriented approach, while the execution module uniformly adopts the service-oriented approach. This differentiated design leverages the efficiency and lightweight advantages of the socket approach on the domain control module side, while ensuring standardized and interoperable communication on the execution module side through the service-oriented approach. At the same time, regardless of the method used, the combination of timestamps and cross-layer encapsulation (skipping intermediate protocol layers) effectively reduces data encapsulation and transmission latency, improves the efficiency of real-time data transmission from initiation to Ethernet, and thus ensures the rapid and deterministic transmission of time-sensitive control commands and status information in the vehicle domain control system.

[0009] In some embodiments, the first data with added timestamps is encapsulated across layers using a network connection socket to obtain the encapsulated second data, including: setting the trigger type in the first communication data processing type to an event class; setting the target service provider in the first communication data format to the identifier of the second end and the client to the identifier of the first end; setting the communication data length to a variable length; and obtaining the second data based on the first communication data processing type, the first communication data format, and the variable-length first data.

[0010] Based on the aforementioned technical means, when performing cross-layer encapsulation via network connection sockets, the trigger type is set to event-based, the identifiers of both communicating parties are clearly defined (the target service is the second end, and the client is the first end), and the data length is set to variable length. This enables flexible communication oriented towards real-time events: event-based triggers can respond promptly to sudden or periodic real-time data, avoiding invalid polling; clear end-to-end identification ensures accurate addressing between the first and second ends; and the variable length adapts to control commands or status information of different sizes, avoiding bandwidth waste or truncation risks associated with fixed lengths. Combined with cross-layer encapsulation that skips intermediate protocol layers, encapsulation and transmission latency can be further reduced, significantly improving the transmission efficiency and reliability of real-time data from the first to the second end.

[0011] In some embodiments, obtaining second data based on a first communication data processing type, a first communication data format, and variable-length first data includes: obtaining a data pointer in a first terminal for storing the first data; reading the first data based on the data pointer; and processing the first communication data processing type, the first communication data format, and the variable-length first data to obtain the second data.

[0012] Based on the above technical means, by obtaining the data pointer storing the first data in the first terminal and directly reading the first data based on the pointer, the memory overhead and processing delay caused by multiple data copies in the traditional protocol stack are avoided. On this basis, by combining the pre-set first communication data processing type, communication data format and variable length data for encapsulation processing, the second data can be quickly generated in a zero-copy or low-copy manner, which further improves the efficiency of cross-layer encapsulation. It is particularly suitable for the transmission scenarios of control commands or status information in vehicle domain controllers where real-time performance and response speed are extremely important.

[0013] In some embodiments, the first data with added timestamps is encapsulated across layers in a service-oriented manner to obtain the encapsulated second data, including: setting the trigger type in the second communication data processing type to an event class and the data processing method to broadcast or multicast; setting the publisher in the second communication data format to include the identifier of the first end and the subscriber to include the identifier of the second end; and obtaining the second data based on the second communication data processing type, the second communication data format, and the variable-length first data.

[0014] Based on the aforementioned technical means, when the first data with timestamps is encapsulated across layers using a service-oriented approach, the trigger type is set to event type, the data processing method is set to broadcast or multicast, and the publisher is clearly defined as the first end, while the subscribers include the second end. This achieves efficient one-to-many real-time data distribution: event-type triggers can respond promptly to the real-time data generation of the first end, and broadcast or multicast avoids multiple point-to-point repeated transmissions, reducing network bandwidth consumption and sending end processing overhead. At the same time, the use of service-oriented communication makes data exchange more flexible and discoverable. Combined with cross-layer encapsulation that skips intermediate protocol layers, it significantly reduces end-to-end transmission latency and improves the synchronization and real-time performance of the same data (such as control commands or sensor status) being sent to multiple second ends (such as multiple execution modules or domain control modules) in the vehicle domain controller.

[0015] In some embodiments, when the first end is a first domain control module, the first data is timestamped and then encapsulated across layers to obtain the encapsulated second data, including: allocating the timestamped first data to a real-time core for real-time data processing; deploying a real-time runtime environment in the real-time core; and encapsulating the first data across layers by timestamping it through the real-time core to obtain the encapsulated second data.

[0016] Based on the aforementioned technical means, when the domain control module acts as the first end, the first data with added timestamps is allocated to a real-time core dedicated to real-time data processing, and a real-time operating environment is deployed on this real-time core. The real-time core completes the subsequent cross-layer encapsulation, which can physically or logically isolate time-sensitive tasks from non-real-time tasks (such as interface display, file system, etc.), avoiding interference from non-real-time interruptions or scheduling delays. This ensures the determinism and low jitter of the timestamp addition and cross-layer encapsulation process, significantly improving the response speed and time synchronization accuracy of real-time data transmission in the vehicle domain controller.

[0017] In some embodiments, sending second data to a second end via Ethernet includes: determining a target priority for the first data; and sending the second data to the second end in real time via Ethernet based on the target priority.

[0018] Based on the above technical means, before sending the second data via Ethernet, the target priority of the first data is determined first, and the data is sent in real time based on this priority. This enables the differentiated processing of data with different levels of urgency: high-priority critical control commands or status information can be given priority in network transmission scheduling, avoiding delays or blockages caused by low-priority data occupying bandwidth. This ensures that in the complex network environment of the vehicle domain controller, real-time data can still reach the second end in a low-latency and highly deterministic manner, effectively improving the overall reliability and real-time response capability of the system.

[0019] In some embodiments, the method further includes: if the CAN link between the first end and the second end fails, encapsulating the third data across layers to obtain the encapsulated fourth data; the third data is the data that originally needed to be sent to the second end via the CAN link; and sending the fourth data to the second end via the Ethernet redundant link.

[0020] Based on the aforementioned technical means, when a CAN link failure is detected between the first and second ends, the third data that originally needed to be sent via CAN can be converted into fourth data and sent through the Ethernet redundant link by significantly improving Ethernet transmission efficiency through cross-layer encapsulation (such as skipping intermediate protocol layers, using real-time cores, priority scheduling, etc.). This effectively overcomes the problem that the original Ethernet link has low transmission efficiency and cannot be directly used as a CAN redundant link due to protocol stack redundancy and large encapsulation overhead. This allows Ethernet to still undertake high real-time and high-reliability data transmission tasks in emergency fault scenarios, providing true link redundancy for the vehicle domain controller system and greatly improving fault tolerance and functional safety levels.

[0021] Secondly, this application provides a data communication method for a vehicle. The method is applied to a second end in a vehicle domain controller, where the second end is a second domain control module in the domain controller, or a second execution module controlled by the second domain control module. The method includes: receiving second data sent by a first end via Ethernet, and identifying a first identifier of the second data; the first end is a first domain control module and / or a first execution module; if the first identifier of the second data indicates that the second data is of a real-time type, then calling a target tool to perform cross-layer decapsulation on the second data to obtain the decapsulated first data; the cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer; wherein, when the first end is a first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method to obtain the first data; when the first end is a first execution module, the second data is decapsulated across layers using a second tool to obtain the first data; and the first data is fed back to the application layer of the second end.

[0022] Based on the aforementioned technical means, after receiving data via Ethernet at the second end (domain control module or execution module), the real-time type identifier is first identified. For real-time data, the target tool is directly invoked for cross-layer decapsulation (from the Ethernet layer directly to the application layer), thereby avoiding the processing delay and overhead caused by the traditional protocol stack parsing layer by layer. This on-demand decapsulation mechanism, together with the cross-layer encapsulation at the first end, forms an end-to-end low-latency communication link, significantly improving the efficiency and response speed of real-time data from reception to delivery to the application layer. At the same time, by identifying data types, it ensures that non-real-time data is still compatible with conventional processing procedures, meeting the requirements of fast and deterministic reception of time-sensitive control commands and status information in vehicle domain controllers.

[0023] At the second end, the corresponding decapsulation tool is dynamically selected based on the specific type of the first end (domain control module or execution module): when the first end is a domain control module, the first tool corresponding to the network connection socket method or the second tool corresponding to the service-oriented method can be used for cross-layer decapsulation; when the first end is an execution module, the second tool corresponding to the service-oriented method is used uniformly. This adaptive matching mechanism can accurately parse real-time data under different encapsulation paths, avoiding data errors or additional processing overhead caused by inconsistent encapsulation and decapsulation methods. Thus, flexible, compatible, and efficient end-to-end real-time data recovery is achieved in the vehicle domain controller, ensuring the correctness and real-time performance of communication.

[0024] In some embodiments, when the second end is a domain control module, identifying the first identifier of the second data includes: receiving the second data through an interrupt vector table and identifying the first identifier of the second data.

[0025] Based on the above technical means, when the second end is the second domain control module, the second data is directly received and its first identifier is identified through the interrupt vector table, thereby realizing the real-time response of data by utilizing the hardware interrupt mechanism, avoiding the waste of CPU resources and response delay caused by the polling method; the interrupt vector table can quickly trigger the corresponding processing flow according to the arrival of data, significantly shortening the time delay from data reception to type identification, ensuring that real-time data receives the highest priority processing on the domain control module side, and further improving the real-time performance and determinism of cross-layer communication in the vehicle domain controller.

[0026] In some embodiments, when the second end is a second domain control module, if the first identifier of the second data indicates that the second data is of a real-time type, calling the target tool to perform cross-layer decapsulation on the second data to obtain the decapsulated first data includes: if the first identifier of the second data indicates that the second data is of a real-time type, allocating the second data to a real-time core for real-time data processing; a real-time running environment is deployed in the real-time core; and calling the target tool through the real-time core to perform cross-layer decapsulation on the second data to obtain the first data.

[0027] Based on the aforementioned technical means, when the second end is a domain control module and the received data is real-time, the data is allocated to a real-time core (with a deployed real-time operating environment) specifically for real-time processing. This real-time core then calls the target tool to complete the cross-layer decapsulation. By binding the real-time decapsulation task to core resources, physical isolation from non-real-time tasks is achieved, avoiding jitter caused by scheduling contention and interruption delays. This ensures that the entire process from receiving the decapsulation data to delivering it to the application layer is deterministic and has extremely low response latency, significantly improving the vehicle domain controller's processing efficiency and time synchronization accuracy for real-time data.

[0028] In some embodiments, the method further includes: if the CAN link between the first end and the second end fails, receiving the fourth data sent by the first end through the Ethernet redundant link; performing cross-layer decapsulation on the fourth data to obtain the decapsulated third data; the third data is the data that the first end originally needed to send through the CAN link.

[0029] Based on the above technical means, when a CAN link failure is detected between the first and second ends, the fourth data can be received through the Ethernet redundant link, and cross-layer decapsulation can be performed to recover the third data that originally needed to be transmitted via CAN. This provides a highly reliable communication redundancy mechanism for the vehicle domain controller system, ensuring that critical data can still be correctly received and parsed through the Ethernet backup link in the event of failure of the primary CAN bus. At the same time, cross-layer decapsulation avoids the additional delay caused by layer-by-layer processing, effectively ensuring the real-time performance of data and the functional safety of the system in fault scenarios.

[0030] Thirdly, this application provides a data communication device for a vehicle, which is deployed at a first end in a vehicle domain controller. The first end is a first domain control module in the domain controller, or the first end is a first execution module controlled by the first domain control module. The device includes: The acquisition unit is used to acquire the first data to be sent to the second end; the second end is a second domain control module and / or a second execution module. A determining unit is used to determine the target type of the first data; the target type includes real-time type or non-real-time type. The encapsulation unit is used to add a timestamp to the first data and then perform cross-layer encapsulation to obtain the encapsulated second data when the target type is real-time. Cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer. Specifically, when the first end is the first domain control module, the first data with added timestamps is encapsulated across layers through network connection sockets or service-oriented methods; when the first end is the first execution module, the first data with added timestamps is encapsulated across layers through service-oriented methods. The transmitting unit is used to transmit second data to the second end via Ethernet.

[0031] Fourthly, this application provides a data communication device for a vehicle, which is deployed at a second end in a vehicle domain controller. The second end is a domain control module in the domain controller, or the second end is an execution module controlled by the domain control module. The device includes: The receiving unit is used to receive second data sent by the first end via Ethernet and identify the first identifier of the second data; the first end is a domain control module and / or an execution module. The decapsulation unit is used to call a target tool to perform cross-layer decapsulation on the second data if the first identifier of the second data indicates that the second data is of a real-time type, thereby obtaining the decapsulated first data. The cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer. Specifically, when the first end is a first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method; when the first end is a first execution module, the second data is decapsulated across layers using a second tool. The feedback unit is used to feed back the first data to the application layer at the second end.

[0032] Fifthly, this application provides a first-end device, which includes a memory and a processor. The memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, they implement the method provided in the first aspect.

[0033] In a sixth aspect, this application provides a second-end device, the vehicle including at least a memory and a processor, the memory storing a computer program or instructions, which, when executed by the processor, implement the method provided in the second aspect.

[0034] In a seventh aspect, this application provides a data communication system for a vehicle, the system comprising: a first end and a second end; the first end being a domain control module in a vehicle domain controller, or the first end being an execution module controlled by the domain control module; the second end being the domain control module and / or the execution module; The first end is used for: acquiring first data to be sent to the second end; determining the target type of the first data; the target type includes real-time type or non-real-time type; if the target type is real-time type, adding a timestamp to the first data and performing cross-layer encapsulation to obtain the encapsulated second data; cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer; and sending the second data to the second end via Ethernet; wherein, if the first end is a first domain control module, cross-layer encapsulation of the timestamped first data is performed through network connection socket method or service-oriented method; if the first end is a first execution module, cross-layer encapsulation of the timestamped first data is performed through service-oriented method. The second end is used for: receiving second data sent by the first end via Ethernet, and identifying the first identifier of the second data; the first end is a domain control module and / or an execution module; if the first identifier of the second data indicates that the second data is of real-time type, then the target tool is invoked to perform cross-layer decapsulation on the second data to obtain the decapsulated first data; cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer; and feeding the first data back to the application layer of the second end; wherein, when the first end is a first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method; when the first end is a first execution module, the second data is decapsulated across layers using a second tool.

[0035] Based on the aforementioned technical means, an end-to-end low-latency real-time communication link is constructed by adding timestamps to real-time data at the first end and performing cross-layer encapsulation from the application layer to the Ethernet layer, and by performing corresponding cross-layer decapsulation from the Ethernet layer to the application layer at the second end. The combination of timestamps ensures time synchronization and determinism, avoiding the accumulated latency and overhead caused by the traditional layered protocol stack processing layer by layer. At the same time, through target type identification and compatible processing of non-real-time data, efficient, deterministic, and flexible real-time data exchange between the domain control module and the execution module in the vehicle domain controller is realized, significantly improving the system's response speed and reliability to time-sensitive control commands and status information.

[0036] In some embodiments, when the first end includes a first domain control module, the second end includes a first execution module; when the first end includes a first execution module, the second end includes a first domain control module; when the first end includes a first domain control module, the second end includes a second domain control module; and when the first end includes a first execution module, the second end includes a second execution module.

[0037] Based on the aforementioned technical means, this technical solution supports bidirectional communication between domain control modules and execution modules (i.e., from domain control module to execution module, and from execution module to domain control module), as well as communication between modules at the same level (cross-domain communication between domain control modules and between execution modules), thereby enabling flexible and peer-to-peer data exchange between any two ends in the vehicle domain controller. This omnidirectional communication capability breaks the limitations of traditional master-slave or fixed links, and can adapt to complex distributed control architectures, such as collaborative decision-making among multiple domain control modules, state synchronization among multiple execution modules, and efficient closed-loop transmission of control commands and feedback information, further improving the system's scalability, real-time response capability, and architectural flexibility.

[0038] Eighthly, this application also provides a computer-readable storage medium storing a computer program or instructions that, when executed by a processor, implement the methods provided in the first or second aspect above.

[0039] Ninthly, this application also provides a computer program product comprising a computer program or instructions that, when executed by a processor, implement the methods provided in the first or second aspect above.

[0040] It should be noted that the technical effects of aspects three through nine can be found in the detailed descriptions of aspects one and two above, and will not be repeated here. Attached Figure Description

[0041] Figure 1 A schematic flowchart of an optional data communication method for a vehicle provided in an embodiment of this application; Figure 2 A schematic diagram of another optional process for a vehicle data communication method provided in an embodiment of this application; Figure 3 This is a schematic diagram of an optional structure of the SOC-side Ethernet communication optimization architecture provided in the embodiments of this application; Figure 4 This is a schematic diagram of an optional structure of the VIU-side Ethernet optimized communication architecture provided in the embodiments of this application; Figure 5This is an optional schematic diagram of the business data flow for dynamic suspension adjustment provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of the application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0043] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0044] In the following description, the terms "first," "second," and "third" are used only to distinguish different objects and do not represent a specific order of objects, nor are they constituting a chronological order. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0045] Unless otherwise defined, all technical and scientific terms used in these embodiments have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in these embodiments is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0046] This application provides a vehicle data communication method, apparatus, device, computer storage medium, and computer program product. The vehicle data communication method is executed by a vehicle data communication device, which can be deployed in an electronic device. The following describes various embodiments of the vehicle data communication method, apparatus, device, system, computer storage medium, and computer program product provided in this application.

[0047] In a first aspect, embodiments of this application provide a data communication method for a vehicle. This method is applied to a first terminal in a vehicle domain controller, referencing... Figure 1 The process shown may include, but is not limited to, S101 to S104.

[0048] The first end is the first domain control module in the domain controller, or the first end is the first execution module controlled by the first domain control module.

[0049] S101, The first end obtains the first data to be sent to the second end.

[0050] The second end is a second domain control module and / or a second execution module. The second domain control module may be the same as or different from the first domain control module. When the first end is the first domain control module, the second end is a second domain control module that is not used for the first domain control module. When the first end is the first execution module, the second domain control module may be the same as the first domain control module or may be a second domain controller that is different from the first domain controller.

[0051] The first execution module and the second execution module can be the same or different. When the first end is the first execution module, the second end can be a second execution module that is different from the first execution module; when the first end is the first domain control module, the second end can be either the first execution module or the second execution module, and the two can be the same or different.

[0052] In simple terms, the first and second ends can enable communication between two domain control modules, between two execution modules, and between a domain control module and an execution module. Which end acts as the first end (sender) and which acts as the receiver (second end) can be configured according to actual needs.

[0053] The second end can be the first or multiple ends, thus enabling one-to-one or one-to-many communication.

[0054] The first data refers to the data in the first end that is to be sent to the second end.

[0055] The first end: The initiator of communication in the vehicle domain controller can be the domain control module (i.e., the main control unit of the domain controller) or the execution module controlled by the domain control module (such as terminal devices such as motors and sensors).

[0056] The second end: the receiver of communication, which can be a domain control module and / or an execution module, forming various communication relationships with the first end (control module to execution module, execution module to control module, between the same level, etc.).

[0057] Domain Control Module: The core computing and decision-making unit in the domain controller, responsible for handling intelligent control algorithms, communication management, and interaction with other domains. The domain control module can also be called a system-on-chip (SOC).

[0058] Execution module: A physical execution component directly controlled by the domain control module, such as a window motor, valve, or light driver, responsible for performing specific actions and providing status feedback. Execution modules can also be called Electronic Control Units (ECUs), Microcontroller Units (MCUs), or Vehicle Integration Units (VIUs).

[0059] Real-time type: Data with extremely strict time constraints, such as braking commands and torque control signals, must be transmitted and processed within milliseconds or even microseconds, otherwise it may lead to abnormal system function or safety accidents.

[0060] Non-real-time type: Data with relatively relaxed time requirements, such as diagnostic information, firmware upgrade packages, log files, etc., which allow for a certain delay and jitter.

[0061] First, the raw data (first data) to be sent to the second end is acquired. This data may come from application-layer control commands or status feedback. Then, the first end determines the target type—real-time or non-real-time—based on the data's time sensitivity. For example, data related to vehicle safety and power control is classified as real-time, while infotainment or diagnostic data is classified as non-real-time.

[0062] S102, The first end determines the target type of the first data.

[0063] The target type can be either real-time or non-real-time.

[0064] Real-time type: Data with extremely strict time constraints, such as braking commands and torque control signals, must be transmitted and processed within milliseconds or even microseconds, otherwise it may lead to abnormal system function or safety accidents.

[0065] Non-real-time type: Data with relatively relaxed time requirements, such as diagnostic information, firmware upgrade packages, log files, etc., which allow for a certain delay and jitter.

[0066] If the first piece of data is real-time, the receiving end will add a precise timestamp to it, recording the moment the data was generated or sent, so that the receiving end can perform time synchronization and latency measurement. This step is crucial to ensuring the determinism of real-time communication and avoiding timing errors caused by network jitter.

[0067] S103. When the target type is real-time, the first end adds a timestamp to the first data and then performs cross-layer encapsulation to obtain the encapsulated second data.

[0068] Cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer.

[0069] Timestamp: A precise time stamp attached to data to identify the moment the data was generated or sent, facilitating time synchronization, sequence determination, or delay calculation at the receiving end.

[0070] Cross-layer encapsulation: By skipping intermediate layers such as the transport layer and network layer in the traditional network protocol stack, application layer data is directly packaged into Ethernet-transmittable frames (secondary data), thereby reducing processing overhead and latency.

[0071] Application layer: The top layer where vehicle functional logic resides, generating or consuming raw data (first data).

[0072] Ethernet layer: Includes the Media Access Control (MAC) layer and the physical layer, responsible for transmitting data frames over the Ethernet link.

[0073] After adding a timestamp, the first end performs cross-layer encapsulation on the data, that is, it directly skips multiple protocol stacks (transport layer, network layer, etc.) from the application layer and packages the data into second data that meets the requirements of Ethernet transmission. Cross-layer encapsulation significantly reduces the software overhead of protocol header encapsulation and parsing, and shortens the time from data generation to leaving the first end.

[0074] S104. The first end sends the second data to the second end via Ethernet.

[0075] After encapsulation, the first end uses the Ethernet physical layer and MAC layer to send the second data to the second end.

[0076] For real-time data, technologies such as priority scheduling and real-time kernel binding can be combined to ensure that highly urgent data receives priority in transmission bandwidth, thereby further reducing transmission latency and jitter.

[0077] The above steps, by adding timestamps to real-time data and performing cross-layer encapsulation (skipping the intermediate layers of the traditional protocol stack), combined with Ethernet transmission, significantly reduce the end-to-end transmission latency of control commands and status information in the vehicle domain controller, reduce protocol processing overhead and time jitter, and ensure the determinism and predictability of real-time communication, thereby improving the response speed and functional safety level of intelligent vehicles for time-sensitive tasks (such as chassis coordination and power distribution).

[0078] In this embodiment, data can be processed differently depending on whether it is real-time: for real-time data, by adding a timestamp and directly encapsulating it from the application layer to the Ethernet layer, the processing overhead of multiple intermediate layers in the traditional protocol stack is skipped, thereby significantly reducing data transmission latency, improving real-time response speed, and ensuring time synchronization accuracy; at the same time, this method uses Ethernet to achieve efficient communication between the domain control module and the execution module, which not only meets the stringent real-time requirements of vehicle control, but also simplifies the protocol stack design and improves the communication efficiency and determinism within the domain controller and between the domain controller and the execution end.

[0079] Ethernet communication between the first end and the second end may include, but is not limited to: Ethernet communication between domain control modules, Ethernet communication between domain control modules and execution modules, and Ethernet communication between execution modules.

[0080] The following describes the process in S103 of adding a timestamp to the first data and then performing cross-layer encapsulation to obtain the encapsulated second data. This process may include, but is not limited to, the following cases 1 and / or 2.

[0081] Scenario 1: When the first end is the first domain control module, the first data with added timestamps is encapsulated across layers through network connection sockets or service-oriented methods to obtain the encapsulated second data.

[0082] In one possible implementation, the network connection socket method can be Netlink socket method, and the service-oriented method can be SOA service-oriented method.

[0083] Netlink socket mode: A communication mechanism based on the Linux kernel Netlink protocol, typically used for efficient message passing between the kernel and user space or between user space processes. Here, it has been modified for cross-layer encapsulation of real-time data.

[0084] SOA (Service-Oriented Architecture) is a communication approach that is often based on protocols such as SOME / IP in in-vehicle networks. It uses a "publish / subscribe" or "request / response" model for data interaction and supports service discovery, multicast, and flexible service orchestration.

[0085] Second data: The first data, after being timestamped and encapsulated across layers, can be sent directly via Ethernet.

[0086] (Domain control module as the first end): When the first end is the domain control module, the Netlink socket method or SOA service-oriented approach is flexibly selected according to communication requirements. If the Netlink socket method is used, the kernel-user space efficient transmission path of the Netlink protocol is leveraged to directly encapsulate timestamped application data into Ethernet frames across layers, suitable for point-to-point real-time control flows requiring extremely low latency and close interaction with the kernel. If the SOA service-oriented approach is used, based on service discovery and subscription mechanisms (such as SOME / IP), data is encapsulated into service messages and bypasses intermediate layers, suitable for scenarios requiring one-to-many distribution, dynamic service discovery, or integration with service-oriented architectures. Regardless of the method, the timestamp is guaranteed to be written to the data payload before encapsulation.

[0087] Scenario 2: When the first end is the first execution module, the first data with added timestamps is encapsulated across layers through a service-oriented approach to obtain the encapsulated second data.

[0088] (Execution module as the first end): When the first end is the execution module, SOA service-oriented architecture is uniformly adopted for cross-layer encapsulation. Execution modules are usually resource-constrained and have limited functionality. SOA service-oriented architecture can use standardized service interfaces (such as publish / subscribe) to directly package the collected sensor data or status feedback (with timestamps) into Ethernet frames, without the need to maintain complex Netlink socket logic. At the same time, SOA service-oriented architecture supports seamless integration with domain control modules and other service consumers, facilitating broadcast, multicast, or on-demand subscription, and improving the transmission efficiency and scalability of uplink real-time data.

[0089] This differentiated encapsulation strategy allows the domain control module to choose between a more efficient Netlink socket approach (suitable for kernel-level low-latency communication) or a more flexible SOA service approach (suitable for service-oriented architecture) depending on the scenario. Meanwhile, the execution module uniformly uses the SOA service approach to simplify implementation. This reduces the complexity of resource-constrained endpoints while ensuring that real-time data is timestamped, and improves the overall cross-layer encapsulation flexibility and communication efficiency of the system. It further shortens the end-to-end latency of real-time commands and status feedback in vehicle domain control and enhances compatibility with the SOA vehicle communication framework.

[0090] Based on the aforementioned technical means, when implementing cross-layer encapsulation, different implementations at the first end can be encapsulated using appropriate methods to meet the needs of the first end in various scenarios. The domain control module can encapsulate timestamped data across layers via network connection sockets or a service-oriented approach, while the execution module uniformly adopts a service-oriented approach. This differentiated design leverages the efficiency and lightweight advantages of the socket approach on the domain control module side, while ensuring standardized and interoperable communication on the execution module side through the service-oriented approach. Simultaneously, regardless of the method used, the combination of timestamps and cross-layer encapsulation (skipping intermediate protocol layers) effectively reduces data encapsulation and transmission latency, improving the efficiency of real-time data transmission from initiation to Ethernet transmission, thereby ensuring the rapid and deterministic transmission of time-sensitive control commands and status information in the vehicle domain control system.

[0091] The following describes the process of encapsulating the first data with added timestamps across layers using a network connection socket to obtain the encapsulated second data.

[0092] This process may include, but is not limited to, S201 to S204 below.

[0093] S201. The first end sets the trigger type in the first communication data processing type to an event class.

[0094] First communication data processing type: Configuration parameters that define the data transmission triggering method and processing behavior under network connection socket mode, such as indicating whether the data is triggered by an event or periodically.

[0095] Trigger type: Determines when data is sent. Setting it to "event type" means that the data is sent immediately when it is generated or changes, rather than polling at a fixed period.

[0096] Event-based: An event-driven triggering mode suitable for bursty, non-periodic real-time data, such as sensor jumps or control commands.

[0097] The first end sets the trigger type in the first communication data processing type to "event type". This means that as long as the first data is actually generated or its content changes, the subsequent encapsulation and sending operations will be triggered; this avoids the waiting time of the periodic type and improves the transmission efficiency.

[0098] S202. The first end sets the target service provider in the first communication data format to be the identifier of the second end, and the client to be the identifier of the first end.

[0099] The first communication data format describes the layout of the address field in the data frame under network connection socket mode, including the identifiers of the source (client) and destination (target service), and is used for direct addressing at the Ethernet layer.

[0100] Target service provider: The identifier of the second end receiving the data, equivalent to the destination address or service instance ID.

[0101] Client: The identifier of the first end sending data, equivalent to the source address or client ID.

[0102] The first end explicitly fills in the identifier of the target service provider as the second end (receiver) and the identifier of the client as the first end (sender) in the first communication data format. In this way, the end-to-end identity information is directly carried in the address field of the Ethernet frame. The receiving end can quickly determine the data source and the expected processing module based on the identifier, without the need for additional routing table or service mapping, thus achieving accurate addressing.

[0103] S203, The first end sets the communication data length to a variable length.

[0104] Variable length: The length of the communication data frame is not fixed and can be dynamically adjusted according to the actual amount of data, avoiding the bandwidth waste or truncation risk caused by a fixed length.

[0105] The first end sets the communication data length to "variable length" to accommodate the size of the first data actually sent. Then, the first end obtains a pointer to the memory storing the first data, reads the actual payload based on this pointer, and combines the configured first communication data processing type (event type) and first communication data format (including both parties' identifiers) to encapsulate the three parts of information into second data. Variable length allows control instructions or status frames of different sizes to share the same encapsulation logic, improving flexibility.

[0106] S204. The first end obtains the second data based on the first communication data processing type, the first communication data format, and the first data of variable length.

[0107] Second data: Data frames generated after cross-layer encapsulation that can be directly transmitted over Ethernet, containing the above-mentioned types, formats, and raw data.

[0108] The first end processes the configuration information and raw data uniformly to generate second data that can be directly submitted to the Ethernet MAC layer for transmission. This data frame has completed cross-layer encapsulation from the application layer to the Ethernet layer, skipping the protocol header processing of the transport layer and network layer, and retaining only the necessary end identifier and event trigger flag, thereby minimizing protocol overhead and preparing for subsequent low-latency transmission.

[0109] In this embodiment, by setting the trigger type to an event class, explicitly identifying the end-to-end, and supporting variable-length data, the scheme achieves event-driven zero-wait encapsulation of real-time data: avoiding invalid polling and fixed-length waste, directly carrying source and destination addresses within the Ethernet frame, and combining cross-layer encapsulation to skip the intermediate protocol stack, significantly reducing the latency and memory overhead from data generation to becoming a sendable frame, and improving the real-time performance and bandwidth utilization of control commands and status information transmission in the vehicle domain controller.

[0110] Based on the aforementioned technical means, when performing cross-layer encapsulation via network connection sockets, the trigger type is set to event-based, the identifiers of both communicating parties are clearly defined (the target service is the second end, and the client is the first end), and the data length is set to variable length. This enables flexible communication oriented towards real-time events: event-based triggers can respond promptly to sudden or periodic real-time data, avoiding invalid polling; clear end-to-end identification ensures accurate addressing between the first and second ends; and the variable length adapts to control commands or status information of different sizes, avoiding bandwidth waste or truncation risks associated with fixed lengths. Combined with cross-layer encapsulation that skips intermediate protocol layers, encapsulation and transmission latency can be further reduced, significantly improving the transmission efficiency and reliability of real-time data from the first to the second end.

[0111] The process of obtaining second data from the first end in S204 based on the first communication data processing type, the first communication data format, and the first data of variable length will be explained below.

[0112] This process may include, but is not limited to, S2041 to S2043 below.

[0113] S2041. The first end obtains the data pointer used to store the first data in the first end.

[0114] Data pointer: A variable that stores the starting address of a shared memory region. Raw data in the shared memory can be read or written directly through this pointer.

[0115] Shared memory: a communication method between processes or threads that allows multiple execution entities to directly access the same physical memory area without data copying, thereby achieving zero-latency data exchange.

[0116] The first end first obtains a data pointer to store the first data, which points to the shared memory area of ​​the first end. The first data to be sent has already been written into the shared memory by the data producer (such as the upper-level algorithm or driver layer). Obtaining the pointer does not require data copying, but only a reference to the memory address.

[0117] S2042, The first end reads the first data based on the data pointer.

[0118] The first end directly accesses the shared memory based on this data pointer and reads the first data within it. Since the shared memory can be directly mapped and accessed by multiple modules, this process avoids the multiple data copies from kernel space to user space or from send buffer to wrapper buffer in traditional data communication, significantly reducing memory read / write overhead and CPU usage.

[0119] S2043. The first end processes the first communication data processing type, the first communication data format, and the variable-length first data to obtain the second data.

[0120] The first end processes the variable-length first data, the pre-configured first communication data processing type (such as an event-type trigger flag), and the first communication data format (including source and destination identifiers) in a unified manner. These three parts of information are combined and encapsulated into a complete second data that conforms to the Ethernet MAC layer frame format, in which the first data is directly embedded as the payload into the frame tail.

[0121] In the assembly process described above, since the first data is obtained directly from shared memory via a pointer and is not appended with protocol headers from the transport or network layers, the entire encapsulation operation is a cross-layer encapsulation from the application layer to the Ethernet layer. The generated second data already contains all the fields required for Ethernet transmission and can be directly submitted to the MAC layer driver for physical transmission.

[0122] By using a shared memory pointer to read the first data with zero copy and combining it with cross-layer encapsulation, the overhead of data copying and layer-by-layer packaging in the traditional protocol stack is completely eliminated. This makes the process from data generation to the generation of a sendable Ethernet frame almost as efficient as direct memory access, greatly reducing the transmission latency of real-time data and CPU load. It is particularly suitable for high-frequency, short-packet, time-sensitive control flow transmission in vehicle domain controllers.

[0123] In this embodiment, based on the above-mentioned technical means, by obtaining the data pointer storing the first data in the first terminal and directly reading the first data based on the pointer, the memory overhead and processing delay caused by multiple data copies in the traditional protocol stack are avoided. On this basis, by combining the pre-set first communication data processing type, communication data format and variable length data for encapsulation processing, the second data can be generated quickly in a zero-copy or low-copy manner, which further improves the efficiency of cross-layer encapsulation. It is particularly suitable for the transmission scenarios of control commands or status information in vehicle domain controllers where real-time performance and response speed are extremely important.

[0124] The following describes the process of encapsulating the first data with added timestamps through a service-oriented approach to obtain the encapsulated second data. This process may include, but is not limited to, S301 to S303 described below.

[0125] S301. The first end sets the trigger type in the second communication data processing type to event type, and the data processing method to broadcast or multicast.

[0126] Broadcast: A network data transmission method that sends data to all nodes within the same network without specifying a particular recipient.

[0127] Multicast: A network data transmission method that sends data simultaneously to multiple predefined specific receiving nodes, rather than all nodes.

[0128] Second communication data processing type: Defines the configuration parameters for the triggering mode and processing strategy of data transmission under the service-oriented approach, including the triggering type and data processing method.

[0129] The first end first sets the trigger type in the second communication data processing type to "event type" to ensure that data is only sent when it is generated or changed, thus avoiding invalid polling; at the same time, the data processing method is set to "broadcast" or "multicast". Broadcast is suitable for sending all real-time information to any node in the entire network (such as emergency alarms), while multicast is suitable for sending to multiple nodes within a specific set of functions (such as multiple executors in the same domain).

[0130] S302, the first end sets the second communication data format so that the publisher includes the identifier of the first end and the subscriber includes the identifier of the second end.

[0131] Publisher: In a service-oriented communication architecture, the module identifier responsible for generating and publishing data is equivalent to the data source.

[0132] Subscriber: In a service-oriented communication architecture, the module identifier that registers with the publisher in advance and indicates that it needs to receive data is equivalent to the data destination.

[0133] Second communication data format: In a service-oriented approach, this describes the layout of the address field in the data frame, including but not limited to: publisher and subscriber.

[0134] The first end explicitly identifies itself as the publisher in the second communication data format and sets the subscriber identifier to the identifier of the second end. This means that the first end, as the data source, registers as a publisher in the service-oriented communication framework; the second end (which may contain multiple modules), as a subscriber, has been authorized to receive the data stream. This configuration enables data to be efficiently addressed and distributed on Ethernet according to service-oriented protocols (such as SOME / IP).

[0135] S303, the first end obtains the second data based on the second communication data processing type, the second communication data format, and the first data of variable length.

[0136] The first end processes the configured second communication data processing type (including event-triggered and broadcast / multicast modes), the second communication data format (including the identifiers of both publishers and subscribers), and the variable-length first data read from shared memory together to generate the second data. In this process, the first data is directly embedded as the payload without being added through the protocol headers of the transport layer and network layer, thereby achieving cross-layer encapsulation from the application layer to the Ethernet layer.

[0137] By avoiding invalid transmissions through event-triggered methods, combining broadcast or multicast to achieve efficient one-to-many distribution, and utilizing the publish-subscribe mechanism in a service-oriented architecture to clarify end-to-end relationships, this solution further reduces redundant network traffic and sending-end processing overhead on the basis of cross-layer encapsulation, significantly improving the transmission efficiency and synchronization when the same real-time data in the vehicle domain controller needs to be sent to multiple second ends.

[0138] In this embodiment, based on the aforementioned technical means, when the timestamped first data is encapsulated across layers using a service-oriented approach, the trigger type is set to event type, the data processing method is set to broadcast or multicast, and the publisher is explicitly defined as the first end, while the subscribers include the second end. This achieves efficient one-to-many real-time data distribution: event-type triggers can respond promptly to the real-time data generation of the first end, and broadcast or multicast avoids multiple point-to-point repeated transmissions, reducing network bandwidth usage and sending end processing overhead; at the same time, the use of service-oriented communication (such as SOME / IP) makes data exchange more flexible and discoverable, and combined with cross-layer encapsulation skipping intermediate protocol layers, it significantly reduces end-to-end transmission latency and improves the synchronization and real-time performance of the same data (such as control commands or sensor status) being sent to multiple second ends (such as multiple execution modules or domain control modules) in the vehicle domain controller.

[0139] In some implementations, where the first end is the first domain control module, an independent kernel can be allocated to process the first data of real-time type, thereby improving processing efficiency.

[0140] This process may include, but is not limited to, S401 and S402 below.

[0141] S401, The first end allocates the first data after adding the timestamp to the real-time core for real-time data processing.

[0142] The real-time kernel deploys a real-time runtime environment (RTE).

[0143] Real-time core: A processor core in a multi-core processor that is dedicated to running real-time tasks. It is physically or logically isolated from other cores through processor affinity settings or operating system partitioning scheduling.

[0144] For non-real-time data, it can be processed through a non-real-time kernel, which improves processing efficiency and reduces the mutual impact between the two independent processing links.

[0145] Real-time runtime environment: A lightweight execution environment deployed on a real-time kernel, typically a bare-metal program, a real-time thread library, or a real-time operating system kernel. It has deterministic task scheduling and interrupt response capabilities and does not contain components that may introduce uncertain latency.

[0146] Based on the real-time type of the first data, the first end assigns the timestamped data processing tasks to a real-time core dedicated to real-time data processing. This real-time core, through operating system configuration or hardware partitioning mechanisms, ensures that no non-real-time tasks (such as user interfaces, file systems, etc.) are run, thereby eliminating the uncertainty of task scheduling contention and interruption latency.

[0147] S402. The first end adds a timestamp to the first data through the real-time core and then performs cross-layer encapsulation to obtain the encapsulated second data.

[0148] The real-time runtime environment deployed on the real-time core takes over the data with minimal and predictable latency and directly performs cross-layer encapsulation operations: skipping intermediate protocol stacks such as the transport layer and network layer, it encapsulates the timestamped first data from the application layer into second data that can be directly submitted to the Ethernet MAC layer. The entire process runs on an isolated core and is not affected by scheduling jitter from complex operating systems (such as Linux and Android) on other cores.

[0149] In this embodiment, by adding timestamps and binding them to a dedicated real-time core with a lightweight real-time operating environment, hard isolation between real-time processing and non-real-time tasks is achieved. This avoids uncertain delays and jitter caused by operating system scheduling, interrupt handling, or memory management, thereby ensuring the determinism and extremely low latency of the real-time data encapsulation process in the vehicle domain controller and meeting the strict real-time requirements of time-sensitive control flow.

[0150] The process of the first end sending second data to the second end via Ethernet in S104 will be described below. In one embodiment, this process may include, but is not limited to, S1041 and S1042 described below.

[0151] S1041, The first end determines the target priority of the first data.

[0152] Target priority: The transmission priority level assigned by the first end based on the real-time requirements and criticality of the first data. For example, high priority is used for brake control commands, and low priority is used for diagnostic logs.

[0153] Before sending the second data, the first end assesses the time sensitivity and criticality of the first data based on its type, source, or content (e.g., control commands, status feedback, diagnostic information), assigning it a clear target priority. This priority can be encoded in the virtual LAN tag or service protocol header of the data frame for subsequent network scheduling.

[0154] S1042. The first end sends the second data to the second end in real time via Ethernet based on the target priority.

[0155] Ethernet real-time transmission: A real-time communication mechanism based on Ethernet, usually combined with time-sensitive networking or priority queuing technology, to ensure that high-priority data frames get priority scheduling and transmission opportunities in the switch or network card queue.

[0156] The first end submits the second data carrying priority information to the Ethernet transmission interface. Utilizing the network interface card's priority queue or time-sensitive networking mechanism, high-priority data is inserted at the head of the transmission queue or allocated a dedicated transmission time slot. The receiving end also follows the same priority strategy, ensuring that high-priority data receives low-latency forwarding at each node along the path, thereby achieving priority-based real-time transmission.

[0157] In this embodiment, by explicitly assigning target priorities to real-time data and using Ethernet priority queues or time-sensitive networking mechanisms for scheduling, priority transmission of critical data in the shared Ethernet link is achieved, effectively avoiding high latency and jitter caused by low-priority data congestion, thereby improving the real-time performance and determinism of emergency control command transmission in the vehicle domain controller.

[0158] The method provided in this application embodiment can also use the Ethernet communication link between the first and second ends as a redundant link for the Controller Area Network (CAN) communication link. This allows communication to continue via the redundant link in the event of a CAN communication link failure.

[0159] This process may include, but is not limited to, S501 and S502 below.

[0160] S501. If the CAN link between the first and second ends fails, the first end will encapsulate the third data across layers to obtain the encapsulated fourth data.

[0161] The third data is the data that originally needed to be sent to the second end via the CAN link. This third data can be real-time or non-real-time.

[0162] A CAN link refers to a link that transmits data via CAN. A CAN link between the first and second ends can include: a CAN link between a domain control module and an execution module, a CAN link between execution modules, and a CAN link between domain control modules.

[0163] The first end monitors the CAN link status with the second end in real time. When a fault is detected, such as a physical disconnection of the CAN link, communication timeout, or excessively high error frame rate, a redundancy switching mechanism is immediately triggered. Third-party data that originally needed to be sent via the CAN link will no longer attempt to use the faulty CAN bus, but will instead be handled by the Ethernet transmission path.

[0164] Previously, Ethernet had low data transmission efficiency and could not serve as a redundant link in case of CAN link failure. In this embodiment, the efficiency of Ethernet is improved, so it can serve as a redundant link in case of CAN link failure.

[0165] S502, the first end sends the fourth data to the second end through the Ethernet redundant link.

[0166] Redundant link: A backup communication path established in advance in addition to the primary communication link. When the primary link fails, the system can switch to the backup link to maintain the continuity of data transmission.

[0167] The first end performs a cross-layer encapsulation operation on the third data, skipping the transport and network layers, and directly encapsulates it from the application layer into fourth data that can be sent via Ethernet. This fourth data is then sent to the second end via a pre-configured redundant Ethernet link. This redundant link can be a separate physical Ethernet channel or a virtual channel shared with an existing Ethernet network but logically isolated.

[0168] In this embodiment, by encapsulating the original CAN data across layers and switching to the Ethernet redundant link for transmission when the CAN link fails, an effective communication redundancy mechanism is provided for the vehicle domain controller system. This avoids the loss of critical data caused by a single bus failure and significantly improves the system's fault tolerance and functional safety level.

[0169] Secondly, embodiments of this application provide a data communication method for a vehicle. The method is applied to a second terminal in a vehicle domain controller, as described above. Figure 2 The process shown may include, but is not limited to, S601 to S603.

[0170] The second end is either the second domain control module in the domain controller, or the second execution module controlled by the second domain control module.

[0171] S601, the second end receives the second data sent by the first end via Ethernet and identifies the first identifier of the second data.

[0172] The first terminal is the first domain control module and / or the first execution module. The second terminal is the domain control module in the domain controller, or the second terminal is the execution module controlled by the domain control module.

[0173] First identifier: A flag bit embedded in the header or a specific field of the second data frame, used to indicate the type (real-time or non-real-time) and encapsulation method of the data.

[0174] The second end receives the second data sent by the first end through the Ethernet interface, parses its header or metadata area, and extracts the first identifier.

[0175] S602. If the first identifier of the second data indicates that the second data is of real-time type, the second end calls the target tool to perform cross-layer decapsulation on the second data to obtain the decapsulated first data.

[0176] Cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer.

[0177] Target tool: A pre-implemented decapsulation function library or processing module that can perform reverse cross-layer decapsulation operations based on the encapsulation method corresponding to the first identifier (such as Netlink socket method or SOA service method).

[0178] Cross-layer decapsulation: The reverse process of cross-layer encapsulation, which directly extracts the application layer payload from the Ethernet MAC frame, skips the protocol parsing of the transport layer and network layer, and restores the original first data.

[0179] If the first identifier indicates that the second data is of a real-time type, the second end calls the target tool that matches it to perform cross-layer decapsulation on the second data, skipping multiple protocol stacks and directly recovering the first data from the Ethernet frame.

[0180] S603, the second end feeds back the first data to the application layer of the second end.

[0181] The second end delivers the first data (including the timestamp) obtained after decapsulation to the application layer module of this end for use by the upper-layer control logic or actuator driver.

[0182] The second end outputs the first data at the application layer for further processing.

[0183] In this embodiment, by identifying the first identifier to quickly determine the real-time data and calling a dedicated tool to perform cross-layer decapsulation, the single-step restoration of the Ethernet frame to the application layer payload is realized, avoiding the cumulative delay caused by the traditional protocol stack parsing layer by layer, and significantly improving the processing efficiency and response speed of the receiver in the vehicle domain controller for real-time commands or status data.

[0184] The following describes the process in S602 of calling the target tool to perform cross-layer decapsulation of the second data to obtain the decapsulated first data. This process may include, but is not limited to, case 3 or case 4 below.

[0185] Case 3: When the first end is the first domain control module, the second data is decapsulated across layers using the first tool corresponding to the network connection socket method or the second tool corresponding to the service-oriented method to obtain the first data.

[0186] The first tool is a decapsulation processing module corresponding to the Netlink socket method, which can reverse the second data generated by the Netlink cross-layer encapsulation and extract the original first data.

[0187] The second tool is a decapsulation processing module corresponding to the SOA service approach, which can reverse the process to restore the second data generated by the cross-layer encapsulation of service and extract the original first data.

[0188] When the first end is a domain control module, the second end selects to call the first tool (corresponding to the Netlink socket method) or the second tool (corresponding to the SOA service method) to perform cross-layer decapsulation of the second data according to the encapsulation method actually adopted by the first end, so as to obtain the first data.

[0189] Case 4: When the first end is the first execution module, the second tool is used to decapsulate the second data across layers to obtain the first data.

[0190] When the first end is an execution module, the second end uniformly calls the second tool (corresponding to the SOA service approach) to perform cross-layer decapsulation of the second data to obtain the first data.

[0191] In this embodiment, by dynamically selecting a matching decapsulation tool at the second end based on the type and encapsulation method of the first end, accurate restoration of different cross-layer encapsulated data is achieved. This not only accommodates the flexible Netlink or SOA encapsulation methods of the domain control module, but also adapts to the scenario where the execution module uniformly uses SOA encapsulation, thereby ensuring the correctness and flexibility of end-to-end real-time communication in the vehicle domain controller.

[0192] The following describes the process by which the second end in S601 receives the second data sent by the first end via Ethernet and identifies the first identifier of the second data.

[0193] The second data is received through the interrupt vector table, and the first identifier of the second data is identified.

[0194] Interrupt vector table: A table stored at a fixed memory address, where each entry points to the entry address of the corresponding interrupt service routine (ISR). When a hardware interrupt occurs, the processor automatically retrieves the address from the table based on the interrupt number and jumps to execute the interrupt, enabling a fast response.

[0195] The second end (domain control module) is pre-configured with the interrupt vector table entry corresponding to the Ethernet receive completion interrupt. When the second data arrives at the Ethernet controller, the hardware triggers an interrupt. The processor jumps directly to the pre-registered receive processing function according to the interrupt vector table. This function reads the second data from the network card buffer and extracts its first identifier to complete the type identification.

[0196] By utilizing the hardware automatic jump mechanism of the interrupt vector table, the CPU idle time and response delay caused by polling for data arrival are avoided, achieving zero-latency perception and identification resolution of the second data, and significantly improving the real-time data reception and response speed in the vehicle domain controller.

[0197] When the second end is the second domain control module, if the first identifier of the second data in S602 indicates that the second data is of the real-time type, the second end calls the target tool to perform cross-layer decapsulation on the second data to obtain the decapsulated first data. The implementation may include, but is not limited to, S6021 and S6022 below.

[0198] S6021. If the first identifier of the second data indicates that the second data is of real-time type, the second end allocates the second data to the real-time core used for real-time data processing.

[0199] A real-time runtime environment is deployed in the real-time kernel.

[0200] When the first identifier of the second data indicates that it is of a real-time type, the second end assigns the processing task of the data to a real-time core dedicated to real-time data processing, on which a real-time operating environment has been deployed.

[0201] S6022, The second end calls the target tool through the real-time kernel to perform cross-layer decapsulation of the second data to obtain the first data.

[0202] The second end uses the real-time kernel to call the target tool that matches the encapsulation method to perform a cross-layer decapsulation operation on the second data to obtain the original first data.

[0203] By binding the real-time data decapsulation task to a dedicated real-time core with a lightweight real-time runtime environment, hard isolation between the decapsulation process and non-real-time tasks is achieved, avoiding uncertain delays caused by operating system scheduling and interrupt handling, thereby ensuring determinism and extremely low latency in real-time data recovery at the receiving end in the vehicle domain controller.

[0204] The method provided in this application embodiment can also use the Ethernet communication link between the first and second ends as a redundant link for the CAN communication link. Thus, in the event of a CAN communication link failure, communication can be maintained through the redundant link.

[0205] This process may include, but is not limited to, S701 and S702 described below.

[0206] S701. If the CAN link between the first and second ends fails, the second end receives the fourth data sent by the first end through the Ethernet redundant link.

[0207] The third data is the data that the first end originally needed to send via the CAN link. The difference between the third data and the fourth data is that the third data is the original data before encapsulation, while the fourth data is the data after the third data has been encapsulated accordingly.

[0208] When the second end detects a failure in the CAN link with the first end, it receives the fourth data sent by the first end through a pre-configured redundant Ethernet link.

[0209] The cross-layer encapsulated Ethernet link between the first and second ends is a redundant link for the CAN link between the first and second ends.

[0210] S702, the second end performs cross-layer decapsulation on the fourth data to obtain the decapsulated third data.

[0211] The second end performs a cross-layer decapsulation operation on the received fourth data, skipping multiple protocol stacks and directly restoring the third data from the Ethernet frame. This data was originally the content that the first end needed to send through the CAN link.

[0212] In this embodiment, by receiving data through a redundant Ethernet link and performing cross-layer decapsulation when the CAN link fails, lossless recovery of critical data is achieved in the event of a primary bus failure. This avoids data loss due to a single link failure and significantly improves the fault tolerance and functional safety level of the vehicle domain controller system.

[0213] The following is an example illustrating a vehicle data communication scheme.

[0214] As vehicles become increasingly intelligent, both now and in the future, the complexity of in-vehicle platforms is also rising. High real-time performance of intra- and inter-domain cross-chip communication within these platforms is becoming increasingly crucial. The accuracy of the vehicle's real-time communication performance directly impacts the deployment and scheduling of tasks across various scenarios. If the processing speed of intra- and inter-domain Ethernet communication data transmission and reception across chips within the vehicle can be reduced to below one millisecond, more tasks for microcontroller VIUs can be scheduled and executed at the SOC level. Furthermore, task deployment between SOCs becomes more flexible and diverse, enabling better redundancy and backup, and ultimately improving vehicle safety. Related technology 1 describes a communication architecture where one heterogeneous SOC acts as the root complex (RC) and the other as the endpoint (EP). This architecture, utilizing a shared memory window and doorbell interrupt mechanism, solves the communication problem between heterogeneous SOCs, improving communication load and reducing resource consumption. Related technology 2 describes a control method where domain controllers are bound together, with redundant control between sensing and processing components. This addresses communication failures and improves communication security within the domain controller. None of them mentioned solving the problem of timing issues in the microcontroller VIU-to-SOC communication within one millisecond. Therefore, an optimization method for inter-vehicle domain Ethernet communication in this embodiment is proposed.

[0215] This embodiment decomposes the complex scenarios that the vehicle's assisted driving needs to handle, identifies high-sequence tasks (tasks) that need to be completed within one millisecond for the transmission and reception of communication data, and organizes and distinguishes between real-time and non-real-time interrupt handling data.

[0216] Next, taking the Linux system platform as an example on the SOC side, RT patches and a "data interception" method in the interrupt vector table driver layer are integrated. By modifying the interrupt vector table corresponding to the Ethernet driver layer, two modes, "high priority" and normal priority, are set to perform different read and write operations on data, achieving "highest priority" data acquisition. Simultaneously, the timing of signal data processing by the VIU and SOC-side Scalable Service-Oriented Middleware over IP (SOME / IP) and Data Distribution Service (DDS) protocols is further optimized to improve timing. This includes using various specific methods such as Netlink and Direct Memory Access (DMA) combined with zero-copy to optimize communication data transmission.

[0217] Furthermore, Service-Oriented Architecture (SOA) automatically generates toolchain code for service adaptation, and the application then uses these service interfaces to perform data sending and receiving operations.

[0218] Finally, based on the topology of the VIU (or MCU, ECU) and SOC within and between the vehicle domains, and the corresponding task deployment, the corresponding functions are integrated onto the corresponding vehicle platform as needed. This includes communication data transmission and reception between the VIU (or MCU, ECU) and the SOC platform, and communication data transmission and reception between SOCs.

[0219] This embodiment's deterministic timing optimization method is part of a deterministic scheduling framework. This optimization method can reduce the time consumption of cross-chip and cross-domain communication to within one millisecond. This allows many resource-intensive tasks that cannot be run on the VIU (or MCU, ECU) to be "ported" to the resource-rich SOC platform. The signal data required for the task's execution, or the signal data that the front-end needs to execute during execution, can be read and sent efficiently and promptly. A typical business scenario is the task of calculating dynamic suspension adjustment. "Porting" this task from the ECU in the powertrain domain to the SOC in the driver or cockpit domain allows the original general suspension adjustment function (deployed on the VIU, MCU, ECU) to be upgraded into a large-scale AI model for dynamic suspension adjustment that can be deployed and run on the SOC. When the AI ​​model runs on the SOC, the data can be sent to the VIU (or MCU, ECU) in the powertrain domain for execution within one millisecond, and the execution result can be fed back within one millisecond.

[0220] In this embodiment, the vehicle's onboard domain controllers include: a driver domain controller (Automated Driving System (ADS)), a powertrain domain controller, a cockpit domain controller (Electronic Damper Control (EDC)), and a vehicle control domain controller. These domain controllers all have a microcontroller-based VIU (or ECU, MCU; in this embodiment, they are collectively referred to as VIU) or a system-on-a-chip (SoC) running Linux or QNX. The core content of this embodiment is divided into the following parts: First, the vehicle software architecture decomposes business scenarios based on vehicle development requirements. The business development architecture further decomposes these scenarios into tasks, designing corresponding architectures, data communication, and timing sequences, thereby determining the deployment of these tasks on the vehicle domain controller. In particular, it identifies tasks requiring deterministic scheduling and management, defining the corresponding signal data and the necessary deterministic timing for these signals. These tasks and their corresponding signal data are then deployed to the corresponding real-time cores for deterministic scheduling and execution.

[0221] Taking the Linux system platform as an example on the SOC side of the domain controller, tasks requiring deterministic scheduling and their corresponding deterministic scheduling frameworks are run separately on one or more cores, with Linux RT patches integrated on them. Integrating RT patches improves the real-time performance of the deterministic scheduling framework, task execution, and data communication scheduling. Other tasks are deployed and run on other non-real-time cores according to the architecture design, ensuring that tasks do not interfere with each other, thereby improving operational stability and security.

[0222] Next, a new "high-priority" approach is added to the data link layer of the seven-layer network architecture of the Ethernet communication standard in the Linux kernel. This is specifically implemented by configuring the interrupt priority to "highest priority" in the interrupt vector table or using the corresponding system call, distinguishing between read and write operations of signal data required by deterministic tasks. Finally, after identifying Ethernet communication data from the controller corresponding to the deterministic task scheduler through a "pass-through" method, the data is directly acquired and provided directly to the real-time scheduling core running the deterministic task.

[0223] In the real-time scheduling kernel, when the driver interface performs read and write operations, it identifies the flag indicating deterministic communication data and, using high-precision time synchronization via Time-Sensitive Networking (TSN), adds a hardware timestamp to the data, directly encapsulating the communication data into the application layer. This process of communication data moving from the real-time kernel on Linux to the user application process can be implemented in two ways: Method 1: Optimization of data encapsulation and processing using Netlink sockets.

[0224] First, define the communication data processing type (e.g., enumeration type: enum msg_types{……});) based on business needs. Core types include command types, periodic types, and event types. Next, define the communication data format (e.g., structure, struct msg_header{……}); core types include Netlink connection, communication data processing type, target service topic, client topic, communication data payload length, timestamp (accurate to nanoseconds), sequence number, and checksum. Finally, inline the variable-length communication data using pointers for zero-copy to reduce copying time. Set corresponding processing thread priorities, such as First In-First Out (SCHED_FIFO) scheduling policy, to reduce communication latency.

[0225] The fastest-optimized business scenario for communication is when the publishing and subscription of communication data is a cross-chip point-to-point process. That is, the information publishing end is on a component of one chip, while the corresponding information data subscription or consumption end is a specific component or process of a SoC on another chip. The subscription and publishing of information data adopts the form of SOA service interface, which decouples business development.

[0226] If the communication data publishing or the communication subscription end consists of multiple components, then the following method (method 2) of SOA service-oriented architecture is required to adapt to the corresponding many-to-many topology communication structure.

[0227] Method 2: Optimization of data encapsulation and processing in SOA service-oriented architecture Service-Oriented Architecture (SOA) requires a layered design. The application layer considers business logic and service composition, while the SOA layer includes service discovery and registration, method invocation and response, etc. Firstly, the definition of communication data processing types is expanded beyond the above to include: service registration, service request and response, service discovery and deregistration, broadcast and multicast, etc. Secondly, the definition of communication data formats is expanded beyond the above to include a service list structure, which includes the corresponding relationships between the target service topic, client topic, service ID, service method, and service priority.

[0228] Simultaneously, the standard communication protocol is further optimized. Specifically, in service discovery and deregistration, components such as garbage collection, built-in queues, and user queues are reduced; the thread model is simplified to reduce scheduling overhead (these were configured to prevent disconnections; functional modules were removed); and data transmission paths are optimized to reduce call stacks and data copying times, thus improving communication timing. When encapsulating the corresponding data using SOA services, this type of data is defined as an event class. Upon receipt, the client-side software component (SWC) waits for the data to arrive in a blocking manner, and the event class triggering method processes both the receive and send interface calls in real time.

[0229] Using SOA-based service interfaces, encapsulate or parse them before sending them to the application layer or calling the driver layer. This reduces the time spent queuing and waiting in intermediate stages of system scheduling, improves timing, and meets deterministic communication requirements. For an optimized Ethernet communication architecture at the SOC end, refer to [reference needed]. Figure 3 The content shown indicates that a Linux system is deployed on the SOC side, including a priority judgment module 301, a real-time processing module 302, and a non-real-time processing module 303.

[0230] The priority judgment module 301 is used to perform interrupt scanning through the interrupt vector table. For the scanned data to be processed, the interrupt priority of the data is determined. If it is a high priority, it is assigned to the real-time processing module 302 for processing; if it is a normal priority, it is assigned to the non-real-time processing module 303 for processing.

[0231] The real-time processing module 302 includes a real-time core - RT, which is used to encapsulate high-priority real-time data directly across layers through service-oriented architecture. For example, it can directly encapsulate the application interface data through service-oriented architecture and then directly reach the deterministic user-side software component SWC.

[0232] The non-real-time processing module 303 includes a non-real-time core -RT, which is used for processing through a standard Ethernet seven-layer network architecture. For example, it processes data based on a service discovery and subscription mechanism (SOME / IP) and a data distribution service protocol stack (DDS protocol stack), and then queues the data for processing until it reaches the nondeterministic user-side software component SWC.

[0233] For the Linux system on the SOC side, it can act as both a sender and a receiver.

[0234] When acting as the receiving end, processing begins with the real-time processing module 301, proceeding sequentially upwards. For example, if a high priority is determined, a direct processing scheme is adopted, allocating the data to the real-time processing module 302 for processing. The real-time processing module 302 encapsulates the interface data using a service-oriented architecture, then directly reaches the deterministic layer: the user-side software component SWC layer. Conversely, if a normal priority (low priority) is determined, a queuing processing scheme is adopted, allocating the data to the non-real-time processing module 303 for processing. The non-real-time processing module 303 processes the data based on the Service Discovery and Subscription Mechanism (SOME / IP) and the Data Distribution Service Protocol Stack (DDS protocol stack), then queues the data, ultimately reaching the non-deterministic layer: the user-side software component SWC.

[0235] When acting as the sending end, the processing direction is reversed, with the arrow pointing downwards. The specific implementation process can be referenced from the receiving end's processing, and will not be elaborated upon here. For example, real-time data is first processed by the real-time processing module 302, then processed by the priority judgment module 301, and finally transmitted; for non-real-time data, it is first processed by the non-real-time processing module 303, then processed by the priority judgment module 301, and finally transmitted.

[0236] Meanwhile, the communication architecture on the VIU side is optimized. To meet the functional safety ASIL-D requirements, the vehicle-mounted VIU platform needs to be based on AUTOSAR-CP. The platform's service tasks run at the SWC layer, with data originating from the RTE layer. The platform's service tasks correspond to Ethernet data, which must pass through the following channels from the bottom layer to the RTE layer: Ethernet Transport Protocol (EthTP) -> Socket Adapter (SoAD) -> Protocol Data Unit Router (PDUR) -> Communication Module (COM) (SOME / IP, DDS) before reaching the RTE. Data from various physical hardware ports at the bottom layer needs to be processed, thus increasing processing time.

[0237] The optimized Ethernet communication architecture for the Vehicle Integration Unit (VIU) can be referenced. Figure 4 The contents shown include: user-end software components 401 (SWC1, SWC2, SWC3), original encapsulation path 41 and optimized encapsulation path 42, and Ethernet interface module (ETHIF) 402.

[0238] The original encapsulation path 41 includes, in sequence: Real-time operating environment (RTE) 403, communication module (COM), service discovery and subscription mechanism (SOME / IP), data distribution service (DDS) 404, protocol data unit router (PDUR) 405, CAN transport protocol (CANTP) 406, CAN interface module (CANIF) 407, socket adapter (SOAD) 408, and Ethernet transport protocol (ETHTP) 409.

[0239] The optimized encapsulation path 42 enables direct cross-layer encapsulation between RTE and ETHTP.

[0240] The optimized approach is to directly obtain Ethernet data from the EthTP layer and encapsulate it into an interface for the RTE layer, providing it directly to the RTE layer and reducing the time consumed by intermediate processing steps. The processing at the Ethernet driver layer follows the same method as on the SOC side.

[0241] The "direct" communication from Ethernet to the RTE layer can be implemented using DMA. The DMA data structure definition includes: state, buffer physical address, timestamp, buffer pointer ring (zero-copy to save copy time), receive index, send index, and whether it is the sender or receiver. The communication data content is processed using SOA service-oriented architecture.

[0242] Similarly, Linux on the SOC side can also use DMA to achieve "direct access" to user application processes.

[0243] Furthermore, for tasks requiring deterministic scheduling to send and receive data, the SOA service-oriented toolchain is used to automatically generate the interface code for data communication, which is then integrated into the application.

[0244] Finally, based on the decomposition of business scenarios and architecture, tasks requiring deterministic communication are deployed on dedicated deterministic business chips or domain controllers on platforms dedicated to deterministic business. The corresponding microcontrollers (VIUs, MCUs, ECUs) and SOCs are modified and optimized as described above, and integrated and deployed. Communication between VIUs (or MCUs, ECUs) uses a redundant architecture based on traditional CAN communication. In this embodiment, Ethernet deterministic data communication serves as redundant communication, ensuring the stability of overall deterministic communication even with a redundant traditional CAN communication architecture when CAN communication malfunctions. Adaptable scenarios include: between VIUs and SOCs, between SOCs, and between VIUs. This embodiment provides backup redundant communication.

[0245] Originally, it was CAN communication. If CAN was faulty, then there would be a failure. Although there was an Ethernet link before, it was inefficient and could not be used as a redundant backup. Now, after cross-layer encapsulation, the efficiency has been improved, and it can be used as a redundant backup for the CAN link.

[0246] In a typical business scenario, taking dynamic suspension adjustment as an example, the business data flow for dynamic suspension adjustment can be referenced. Figure 5 The contents shown include the LINUX side 51 and the power domain - VIU52 of the SOC.

[0247] The processing steps include, but are not limited to, S5001 to S5008.

[0248] S5001, Enable suspension adjustment function.

[0249] S5002: Obtains road condition information ahead from various sensors through a non-real-time kernel.

[0250] S5003, Store road condition information ahead in the shared storage.

[0251] S5004: Real-time kernel calls the suspension dynamic adjustment module to obtain suspension dynamic adjustment control parameter information data.

[0252] S5005 identifies the data as high priority based on the interrupt vector table.

[0253] S5006, Transmit data to the power domain - VIU52.

[0254] S5007, implements cross-layer encapsulation.

[0255] S5008, Feedback the data to the suspension control unit.

[0256] The Diagnostic Manager (DM) of the suspension dynamic adjustment artificial intelligence (AI) model can be deployed and run on a Linux real-time kernel. The core data flow of the entire vehicle is roughly as follows: During driving, the user enables the suspension dynamic adjustment function through settings. The vehicle's systems acquire road condition information ahead, including images and video data. This information is processed by the system through image perception, fusion of various information, and recognition. The relevant information is then sent to the DM, planning and control functions of the suspension dynamic adjustment AI model (deterministic tasks running on the real-time kernel) via the shared memory of the Communication Manager (CM). After processing, the optimized Ethernet SOA service interface is invoked and sent to the VIU in the powertrain domain. The VIU in the powertrain domain then similarly uses the optimized internal service interface to complete the dynamic control of the suspension. The results are then fed back in real-time.

[0257] Thirdly, this application provides a data communication device for a vehicle, which is deployed at a first end in a vehicle domain controller. The first end is a domain control module in the domain controller, or the first end is an execution module controlled by the domain control module. The device includes: The acquisition unit is used to acquire the first data to be sent to the second end; the second end is a domain control module and / or an execution module. A determining unit is used to determine the target type of the first data; the target type includes real-time type or non-real-time type. The encapsulation unit is used to add a timestamp to the first data and then perform cross-layer encapsulation to obtain the encapsulated second data when the target type is real-time. Cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer. Specifically, when the first end is the first domain control module, the first data with added timestamps is encapsulated across layers through network connection sockets or service-oriented methods; when the first end is the first execution module, the first data with added timestamps is encapsulated across layers through service-oriented methods. The transmitting unit is used to transmit second data to the second end via Ethernet.

[0258] In some embodiments, the encapsulation unit is further configured to: set the trigger type in the first communication data processing type to an event class; set the target service provider in the first communication data format to be the identifier of the second end and the client to be the identifier of the first end; set the communication data length to a variable length; and obtain the second data based on the first communication data processing type, the first communication data format, and the variable-length first data.

[0259] In some embodiments, the encapsulation unit is further configured to: obtain a data pointer in the first end for storing first data; read the first data based on the data pointer; process the first communication data processing type, the first communication data format, and the variable-length first data to obtain second data.

[0260] In some embodiments, the encapsulation unit is further configured to: set the trigger type in the second communication data processing type to an event class, and the data processing method to broadcast or multicast; set the publisher in the second communication data format to include the identifier of the first end, and the subscriber to include the identifier of the second end; and obtain the second data based on the second communication data processing type, the second communication data format, and the variable-length first data.

[0261] In some embodiments, when the first end is a domain control module, the encapsulation unit is further configured to: allocate the first data after adding a timestamp to a real-time core for real-time data processing; deploy a real-time runtime environment in the real-time core; and encapsulate the first data across layers after adding a timestamp through the real-time core to obtain the encapsulated second data.

[0262] In some embodiments, the sending unit is further configured to: determine the target priority of the first data; and based on the target priority, send the second data to the second end in real time via Ethernet.

[0263] In some embodiments, the encapsulation unit is further configured to: if the CAN link between the first end and the second end fails, encapsulate the third data across layers to obtain the encapsulated fourth data; the third data is the data that originally needed to be sent to the second end via the CAN link; and send the fourth data to the second end via the Ethernet redundant link.

[0264] Fourthly, this application provides a data communication device for a vehicle, which is deployed at a second end in a vehicle domain controller. The second end is a domain control module in the domain controller, or the second end is an execution module controlled by the domain control module. The device includes: The receiving unit is used to receive second data sent by the first end via Ethernet and identify the first identifier of the second data; the first end is a domain control module and / or an execution module. The decapsulation unit is used to call a target tool to perform cross-layer decapsulation on the second data if the first identifier of the second data indicates that the second data is of a real-time type, thereby obtaining the decapsulated first data. The cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer. Specifically, when the first end is a first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method; when the first end is a first execution module, the second data is decapsulated across layers using a second tool. The feedback unit is used to feed back the first data to the application layer at the second end.

[0265] In some embodiments, when the second end is a domain control module, the receiving unit is further configured to: receive second data through an interrupt vector table and identify a first identifier of the second data.

[0266] In some embodiments, when the second end is a domain control module, the decapsulation unit is further configured to: if the first identifier of the second data indicates that the second data is of a real-time type, allocate the second data to a real-time core for real-time data processing; deploy a real-time runtime environment in the real-time core; and call the target tool through the real-time core to perform cross-layer decapsulation on the second data to obtain the first data.

[0267] In some embodiments, the decapsulation unit is further configured to: if the CAN link between the first end and the second end fails, receive the fourth data sent by the first end through the Ethernet redundant link; perform cross-layer decapsulation on the fourth data to obtain the decapsulated third data; the third data is the data that the first end originally needed to send through the CAN link.

[0268] Fifthly, this application provides a first-end device, which includes a memory and a processor. The memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, they implement the method provided in the first aspect.

[0269] In a sixth aspect, this application provides a second-end device, the vehicle including at least a memory and a processor, the memory storing a computer program or instructions, which, when executed by the processor, implement the method provided in the second aspect.

[0270] In a seventh aspect, this application provides a data communication system for a vehicle, the system including a first end and a second end; the first end is a first domain control module in a vehicle domain controller, or the first end is a first execution module controlled by the first domain control module; the second end is a second domain control module and / or a second execution module; The first end is used for: acquiring first data to be sent to the second end; determining the target type of the first data; the target type includes real-time type or non-real-time type; if the target type is real-time type, adding a timestamp to the first data and performing cross-layer encapsulation to obtain the encapsulated second data; cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer; and sending the second data to the second end via Ethernet; wherein, if the first end is a first domain control module, cross-layer encapsulation of the timestamped first data is performed through network connection socket method or service-oriented method; if the first end is a first execution module, cross-layer encapsulation of the timestamped first data is performed through service-oriented method. The second end is used for: receiving second data sent by the first end via Ethernet, and identifying the first identifier of the second data; the first end is a domain control module and / or an execution module; if the first identifier of the second data indicates that the second data is of real-time type, then the target tool is invoked to perform cross-layer decapsulation on the second data to obtain the decapsulated first data; cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer; and feeding the first data back to the application layer of the second end; wherein, when the first end is a first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method; when the first end is a first execution module, the second data is decapsulated across layers using a second tool.

[0271] In some embodiments, when the first end includes a first domain control module, the second end includes a first execution module; when the first end includes a first execution module, the second end includes a first domain control module; when the first end includes a first domain control module, the second end includes a second domain control module; and when the first end includes a first execution module, the second end includes a second execution module.

[0272] Eighthly, this application also provides a computer-readable storage medium storing a computer program or instructions that, when executed by a processor, implement the methods provided in the first or second aspect above.

[0273] Ninthly, this application also provides a computer program product comprising a computer program or instructions that, when executed by a processor, implement the methods provided in the first or second aspect above.

[0274] It should be noted that the descriptions of the embodiments of the above-described devices, storage media, equipment, systems, and program products are similar to the descriptions of the above-described method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of the storage media, equipment, devices, and program products of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0275] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0276] It should be noted that, in this embodiment, 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.

[0277] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0278] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0279] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0280] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0281] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0282] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data communication method for vehicles, characterized in that, The method is applied to a first terminal in a vehicle domain controller, wherein the first terminal is a first domain control module in the domain controller, or the first terminal is a first execution module controlled by the first domain control module; the method includes: Acquire the first data to be sent to the second end; the second end is the second domain control module and / or the second execution module. Determine the target type of the first data; the target type includes real-time type or non-real-time type. When the target type is real-time, the first data is timestamped and then encapsulated across layers to obtain the encapsulated second data. The cross-layer encapsulation is used to implement direct encapsulation from the application layer to the Ethernet layer. Specifically, when the first end is the first domain control module, the timestamped first data is encapsulated across layers using a network connection socket or a service-oriented approach. When the first end is the first execution module, the timestamped first data is encapsulated across layers using a service-oriented approach. The second data is sent to the second end via Ethernet; If the CAN link between the first end and the second end fails, the third data is encapsulated across layers to obtain the encapsulated fourth data; the third data is the data that originally needed to be sent to the second end via the CAN link. The fourth data is sent to the second end via a redundant Ethernet link.

2. The method according to claim 1, characterized in that, The first data with added timestamps is encapsulated across layers using a network connection socket to obtain the encapsulated second data, which includes: Set the trigger type in the first communication data processing type to an event class; In the first communication data format, the target service provider is set to the identifier of the second end, and the client is set to the identifier of the first end; Set the communication data length to a variable length; The second data is obtained based on the first communication data processing type, the first communication data format, and the first data of variable length.

3. The method according to claim 2, characterized in that, The process of obtaining the second data based on the first communication data processing type, the first communication data format, and the variable-length first data includes: Obtain the data pointer used to store the first data in the first end; Read the first data based on the data pointer; The first communication data processing type, the first communication data format, and the variable-length first data are processed to obtain the second data.

4. The method according to claim 1, characterized in that, By encapsulating the first data with added timestamps through a service-oriented approach, the encapsulated second data is obtained, including: Set the trigger type in the second communication data processing type to event type, and the data processing method to broadcast or multicast; In the second communication data format, the publisher includes the identifier of the first end, and the subscriber includes the identifier of the second end; The second data is obtained based on the second communication data processing type, the second communication data format, and the variable-length first data.

5. The method according to any one of claims 1-4, characterized in that, When the first end is the first domain control module, the step of adding a timestamp to the first data and then performing cross-layer encapsulation to obtain the encapsulated second data includes: The first data, after being timestamped, is allocated to a real-time core for real-time data processing; a real-time operating environment is deployed in the real-time core. The first data is timestamped by the real-time kernel and then encapsulated across layers to obtain the encapsulated second data.

6. The method according to any one of claims 1-4, characterized in that, Sending the second data to the second end via Ethernet includes: Determine the target priority of the first data; Based on the target priority, the second data is sent to the second end in real time via Ethernet.

7. A vehicle communication method, characterized in that, The method is applied to a second terminal in a vehicle domain controller, wherein the second terminal is a second domain control module in the domain controller, or the second terminal is a second execution module controlled by the second domain control module; the method includes: The system receives second data sent by the first end via Ethernet and identifies the first identifier of the second data; the first end is a first domain control module and / or a first execution module. If the first identifier of the second data indicates that the second data is of real-time type, then the target tool is invoked to perform cross-layer decapsulation on the second data to obtain the decapsulated first data; the cross-layer decapsulation is used to realize decapsulation between the Ethernet layer and the application layer; wherein, when the first end is the first domain control module, the second data is decapsulated across layers by a first tool corresponding to the network connection socket mode or a second tool corresponding to the service mode; when the first end is the first execution module, the second tool is used to decapsulate the second data across layers. The first data is fed back to the application layer of the second end; If the CAN link between the first end and the second end fails, the fourth data sent by the first end will be received through the Ethernet redundant link; The fourth data is decapsulated across layers to obtain the decapsulated third data; the third data is the data that the first end originally needed to send through the CAN link.

8. The method according to claim 7, characterized in that, When the second terminal is the second domain control module, the first identifier for identifying the second data includes: The second data is received through the interrupt vector table, and the first identifier of the second data is identified.

9. The method according to any one of claims 7-8, characterized in that, When the second end is the second domain control module, if the first identifier of the second data indicates that the second data is of real-time type, the target tool is invoked to perform cross-layer decapsulation on the second data to obtain the decapsulated first data, including: If the first identifier of the second data indicates that the second data is of a real-time type, the second data is allocated to a real-time core for real-time data processing; the real-time core deploys a real-time operating environment. The first data is obtained by using the target tool to perform cross-layer decapsulation of the second data through the real-time kernel call.

10. A vehicle data communication system, characterized in that, The system includes a first terminal and a second terminal; the first terminal is a first domain control module in a vehicle domain controller, or the first terminal is a first execution module controlled by the first domain control module; the second terminal is a second domain control module and / or a second execution module; The first end is used to: acquire first data to be sent to the second end; determine the target type of the first data; the target type includes real-time type or non-real-time type; if the target type is real-time type, add a timestamp to the first data and perform cross-layer encapsulation to obtain the encapsulated second data; the cross-layer encapsulation is used to realize direct encapsulation from the application layer to the Ethernet layer; The second data is sent to the second end via Ethernet; wherein, when the first end is the first domain control module, the first data with added timestamps is encapsulated across layers via network connection sockets or service-oriented methods; when the first end is the first execution module, the first data with added timestamps is encapsulated across layers via service-oriented methods; if the CAN link between the first end and the second end fails, the third data is encapsulated across layers to obtain the encapsulated fourth data; the third data is the data that originally needed to be sent to the second end via the CAN link; the fourth data is sent to the second end via a redundant Ethernet link. The second end is used for: receiving second data sent by the first end via Ethernet, and identifying a first identifier of the second data; the first end is the domain control module and / or the execution module; if the first identifier of the second data indicates that the second data is of real-time type, then calling a target tool to perform cross-layer decapsulation on the second data to obtain decapsulated first data; the cross-layer decapsulation is used to implement decapsulation between the Ethernet layer and the application layer; feeding the first data back to the application layer of the second end; wherein, when the first end is the first domain control module, the second data is decapsulated across layers using a first tool corresponding to the network connection socket method or a second tool corresponding to the service-oriented method; when the first end is the first execution module, the second data is decapsulated across layers using the second tool; if the CAN link between the first end and the second end fails, receiving fourth data sent by the first end via an Ethernet redundant link; performing cross-layer decapsulation on the fourth data to obtain decapsulated third data; the third data is the data that the first end originally needed to send via the CAN link.

11. The system according to claim 10, characterized in that, When the first end includes a first domain control module, the second end includes a first execution module; When the first end includes a first execution module, the second end includes a first domain control module; When the first end includes a first domain control module, the second end includes a second domain control module. If the first end includes a first execution module, the second end includes a second execution module.

Images