A method, apparatus, device, and vehicle for interacting with heterogeneous data in vehicles.

Abstract

This application discloses a method, apparatus, device, and vehicle for interacting with heterogeneous data in vehicles, belonging to the field of heterogeneous data interaction technology. The method includes: after acquiring a source data packet, first converting the source data packet into an intermediate data packet with a preset data structure; then identifying the target communication protocol for receiving the source data packet based on the intermediate data packet; subsequently, according to the conversion rules between the intermediate data packet and the target communication protocol, converting the intermediate data packet into a target data packet corresponding to the target communication protocol and sending it to the corresponding target node. This application introduces an intermediate data packet with a preset data structure as a unified conversion medium for heterogeneous data interaction in vehicles, enabling different types of source and target communication buses to interact by adapting to this intermediate data, eliminating the need to build dedicated conversion links for each specific protocol, and meeting the practical needs of flexible interaction in heterogeneous vehicle communication networks.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted heterogeneous data interaction technology, and in particular to a method, apparatus, device, and vehicle for interacting with vehicle-mounted heterogeneous data. Background Technology

[0002] In the field of automotive electronic communication technology, vehicles are typically equipped with a variety of communication nodes and communication buses that are adapted to different functional domains such as body control, smart cockpit, and autonomous driving. These include various communication carriers such as CAN bus, SOME / IP Ethernet bus, SPI, and IPC. Different nodes transmit data based on their own proprietary communication protocols, forming a heterogeneous automotive communication network to achieve data interaction and collaborative operation of multiple automotive modules.

[0003] However, when traditional technologies realize heterogeneous data interaction in vehicles, they usually adopt a point-to-point customized conversion mode, which builds a dedicated conversion link only for two specific protocol communication buses. For example, it is necessary to convert the source data packet into the target data packet according to a fixed rule. It directly performs protocol identification and conversion based on the original packet. There is no unified standard for data conversion, the logic is complicated and redundant, and the compatibility and scalability are poor. It cannot adapt to the adaptation requirements of the new bus protocol in the iterative upgrade of vehicle communication architecture, and it is difficult to meet the actual needs of flexible interaction in vehicle heterogeneous communication networks. Summary of the Invention

[0004] The main purpose of this application is to propose a method, device, equipment, and vehicle for interacting heterogeneous data in vehicles. By using a unified intermediate data structure, different types of source communication buses and target communication buses can interact by adapting to the intermediate data, without having to build a dedicated conversion link for each of the two specific protocols, thus meeting the practical needs of flexible interaction in vehicle heterogeneous communication networks.

[0005] To achieve the above objectives, one aspect of this application proposes a method for interacting with heterogeneous data in vehicles, the method comprising: The source data packet to be transmitted by the source node is obtained through the source communication bus corresponding to the source node. The source data packet is converted into an intermediate data packet with a preset data structure; Based on the intermediate data message, the target communication protocol for receiving the source data message is identified; According to the conversion rules between the intermediate data message and the target communication protocol, the intermediate data message is converted into the target data message corresponding to the target communication protocol; The target data packet is sent to the target node corresponding to the target communication protocol via the target communication bus corresponding to the target communication protocol.

[0006] Furthermore, in some embodiments, identifying the target communication protocol for receiving the source data packet based on the intermediate data packet includes: Extract the purpose of the data in the intermediate data message; Based on the purpose of the data and the intermediate data packets, the target node for receiving the source data packets is determined; The communication protocol corresponding to the target node shall be used as the target communication protocol.

[0007] Furthermore, in some embodiments, the purpose of extracting data from the intermediate data packet includes: Parse the data identifier field in the intermediate data message to obtain the corresponding data usage identifier; Based on the data purpose identifier, the data purpose corresponding to the intermediate data message is matched and obtained.

[0008] Furthermore, in some embodiments, the intermediate data packet includes: packet transmission priority and packet data length; The step of determining the target node for receiving the source data packet based on the data purpose and the intermediate data packet includes: Based on the preset vehicle domain controller partitioning rules, the functional domain corresponding to the purpose of the data is obtained; The target node is matched from each candidate node in the functional domain based on the data purpose identifier, the message transmission priority, and the message data length.

[0009] Further, in some embodiments, matching the target node from each candidate node within the functional domain based on the data purpose identifier, the message transmission priority, and the message data length includes: The data purpose identifier, the message transmission priority, and the message data length are mapped to a preset three-dimensional rectangular coordinate system to form a first feature point. The first circle corresponding to the first feature point is determined with the first feature point as the center and the preset parameter offset as the radius. Obtain the node-adapted data type, node priority adaptation threshold, and node-carrying data length threshold for each candidate node; The node-adapted data type, the node priority adaptation threshold, and the node-carrying data length threshold are mapped to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node. The second feature point is used as the center and a preset parameter offset is used as the radius to determine the second circle corresponding to the second feature point. Calculate the spatial distance between the center of the first circle and the centers of each of the second circles; Based on the intersection state of the first circle and each of the second circles, the candidate node that intersects with the first circle and has the smallest spatial distance value between its center and the circle is selected as the target node.

[0010] Furthermore, in some embodiments, mapping the data purpose identifier, the message transmission priority, and the message data length to a preset three-dimensional Cartesian coordinate system to form a first feature point includes: The data purpose identifier is linearly mapped to coordinate values ​​on the X-axis to generate the first coordinate value; The message transmission priority is linearly mapped to coordinate values ​​on the Y-axis to generate a second coordinate value; The message data length is linearly mapped to coordinate values ​​on the Z-axis to generate a third coordinate value; The first feature point is generated based on the first coordinate value, the second coordinate value, and the third coordinate value.

[0011] Further, in some embodiments, mapping the node-adapted data type, the node priority adaptation threshold, and the node-carrying data length threshold to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node includes: For each candidate node, the node's data type is linearly mapped to coordinate values ​​on the X-axis to generate a fourth coordinate value; The node priority adaptation threshold is linearly mapped to a coordinate value on the Y-axis to generate a fifth coordinate value; The threshold value of the data length carried by the node is linearly mapped to a coordinate value on the Z-axis to generate a sixth coordinate value; The second feature point is generated based on the fourth coordinate value, the fifth coordinate value, and the sixth coordinate value.

[0012] Furthermore, in some embodiments, the intermediate data packet further includes: the real-time packet loss rate of the source communication bus; The method further includes: Compare the real-time packet loss rate with the preset vehicle packet loss rate threshold; When the real-time packet loss rate is determined to be greater than the vehicle-mounted packet loss rate threshold, a fault alarm is triggered, and a prompt message indicating that there is a fault in the source communication bus is output.

[0013] To achieve the above objectives, another aspect of this application proposes an in-vehicle heterogeneous data interaction device, the device comprising: The source message acquisition module is used to acquire the source data message to be transmitted by the source node through the source communication bus corresponding to the source node; An intermediate message conversion module is used to convert the source data message into an intermediate data message with a preset data structure; The target communication protocol identification module is used to identify the target communication protocol used to receive the source data packet based on the intermediate data packet. The target message conversion module is used to convert the intermediate data message into a target data message corresponding to the target communication protocol according to the conversion rules between the intermediate data message and the target communication protocol. The target message transmission module is used to send the target data message to the target node corresponding to the target communication protocol via the target communication bus corresponding to the target communication protocol.

[0014] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned method for interacting with heterogeneous in-vehicle data.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a vehicle, the vehicle including the aforementioned onboard heterogeneous data interaction device or the aforementioned electronic device.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a method, apparatus, device, and vehicle for interacting with heterogeneous data in a vehicle. The method obtains a source data packet through the source communication bus corresponding to the source node, first converts the source data packet into an intermediate data packet with a preset data structure, then identifies the target communication protocol for receiving the source data packet based on the intermediate data packet, then converts the intermediate data packet into a target data packet corresponding to the target communication protocol according to the conversion rules between the intermediate data packet and the target communication protocol, and finally sends the target data packet to the corresponding target node through the target communication bus corresponding to the target communication protocol. Compared with traditional technologies, this application establishes a unified standard for in-vehicle heterogeneous data interaction by introducing intermediate data messages with a preset data structure as a unified conversion medium. Instead of directly identifying and converting protocols based on the original messages, it first converts all source data messages into intermediate data messages of a fixed format, and then adapts them to different target communication protocols. This avoids the problems of mutually coupled conversion rules and complex, redundant logic in traditional technologies. Simultaneously, the unified intermediate data structure allows different types of source and target communication buses to interact by adapting to this intermediate data, eliminating the need to build dedicated conversion links for each specific protocol. This effectively improves the compatibility and scalability of in-vehicle heterogeneous data interaction and can adapt to the needs of new bus protocols added during the iterative upgrade of the in-vehicle communication architecture. Furthermore, this invention simplifies the data interaction logic through a unified conversion process, ensuring smooth data interaction between in-vehicle functional domain nodes and the bus, improving the overall integrity and stability of the vehicle's electronic system, and thus meeting the practical needs of flexible interaction in in-vehicle heterogeneous communication networks. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for interacting with heterogeneous data in a vehicle, as provided in an embodiment of this application. Figure 2 This is a schematic diagram of the data interaction architecture for vehicle multi-bus protocol adaptation and AI assistance provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an in-vehicle heterogeneous data interaction device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0020] As used in this application, the terms "several", "each", etc., "several" include one, two or more, "each" refers to each of the corresponding plurality, and "any" refers to any one of the plurality.

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

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] (1) BusAdapter is the base class of bus adapters. It is a standardized interface component of the protocol adaptation layer. It defines a unified bus communication interface specification for initialization, data transmission and reception, and resource release. All kinds of vehicle-specific bus adapters inherit this base class to implement their own logic, thereby decoupling the bus from the core interaction framework and ensuring the scalability of the system.

[0024] (2) ECU stands for Electronic Control Unit, which is the control node of the vehicle electronic system. It is widely used in vehicle functional domains such as body control, chassis control, and power system, and is responsible for generating, receiving and processing vehicle communication data packets.

[0025] (3) CANAdapter is a CAN bus adapter, a dedicated adapter that inherits from the BusAdapter base class. It adapts to the CAN bus communication protocol and is responsible for parsing and verifying the CAN bus source data message, as well as the mutual conversion between intermediate data messages and CAN protocol messages. It adapts to CAN bus communication in scenarios such as the vehicle body control domain.

[0026] (4) SomeIPAdapter is a SOME / IP bus adapter, a dedicated vehicle Ethernet adapter implemented based on the BusAdapter base class. It performs data serialization, service ID encapsulation and other operations according to the characteristics of the SOME / IP protocol, realizes the conversion between intermediate data and SOME / IP protocol messages, and adapts to high-speed Ethernet communication in the intelligent cockpit domain and autonomous driving domain.

[0027] (5) INT8 is an 8-bit integer quantization format, which is a deep learning model compression optimization method. It converts the floating-point model parameters of the AI ​​auxiliary layer into 8-bit integer data, greatly reducing the storage space and computing power consumption of the model. It is compatible with embedded low-computing-power hardware platforms such as vehicle MCU and SoC, and ensures the efficient operation of functions such as three-dimensional space matching and protocol recognition.

[0028] Traditional in-vehicle heterogeneous data interaction solutions commonly employ a customized point-to-point, pairwise conversion model. For example, dedicated conversion links are built for only two specific communication protocols, directly converting protocols based on the source node's original messages, without a unified conversion intermediary or data standard. Because the conversion rules between different protocols are interdependent, separate conversion logic must be developed for each pair of protocols, resulting in high code redundancy and maintenance difficulty. Furthermore, these solutions can only adapt to fixed protocol combinations. When a new bus protocol is added, a dedicated conversion link must be redeveloped for that protocol and all existing protocols, failing to adapt to the rapid iteration of in-vehicle communication architectures. Inconsistent conversion logic across different buses leads to high complexity in multi-bus collaborative interaction, making it difficult to meet the needs of efficient and flexible interaction in in-vehicle heterogeneous networks.

[0029] In view of this, this application provides a method, apparatus, device, and vehicle for interacting with heterogeneous data in vehicles. This solution unifies the source data packets of all source nodes into intermediate data packets with a preset data structure, using the intermediate data packets as the sole intermediary for all protocol conversions, replacing the traditional pairwise conversion mode, thereby simplifying the overall logic of data interaction. Moreover, this invention uses the intermediate data packets as the core, first identifying the target communication protocol based on the intermediate data packets, and then converting the intermediate data packets into target data packets corresponding to the target protocol according to the exclusive conversion rules between the intermediate data packets and the target protocol. This achieves unidirectional conversion from source protocol, intermediate data, to target protocol, eliminating the need to maintain a direct conversion relationship between the source and target protocols, significantly reducing the development and maintenance costs of the conversion logic. Therefore, this invention, through unified intermediate data packets, can adapt to any type of source / target communication bus. When adding a new bus protocol, only the conversion rules between the bus and the intermediate data need to be developed; there is no need to modify the conversion logic of the existing bus or rewrite the links between the new bus and all existing buses. This allows it to adapt to the rapid iterative upgrades of vehicle communication architectures and meet the efficient and flexible interaction requirements of heterogeneous vehicle networks.

[0030] Figure 1 This is an optional flowchart of a method for interacting with heterogeneous data in a vehicle, provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S1 to S5: Step S1: Obtain the source data packet to be transmitted by the source node through the source communication bus corresponding to the source node; Indicatively, this invention can adapt to communication scenarios of heterogeneous communication protocol nodes in vehicles, is compatible with source and target nodes of different bus types, and covers the data interaction needs of multiple types of vehicle buses such as CAN, SOME / IP, DDS, SPI, and IPC. Step S2: Convert the source data packet into an intermediate data packet with a preset data structure; As an illustration, by using a unified intermediate data structure, the heterogeneity of the source and target communication protocols at the physical layer, protocol layer, and data format can be shielded; the complex logic of traditional pairwise conversion can be simplified into a one-way conversion between each bus and the intermediate data, which greatly reduces the complexity of the conversion logic, development costs, and maintenance difficulty.

[0031] Step S3: Based on the intermediate data packet, identify the target communication protocol used to receive the source data packet; As an illustration, this step can automatically identify the target communication protocol based on the protocol characteristics carried by the intermediate data, without the need for manual configuration of protocol types and routing rules, thereby improving the automation and intelligence of data interaction and reducing human intervention.

[0032] Step S4: According to the conversion rules between the intermediate data packet and the target communication protocol, convert the intermediate data packet into a target data packet corresponding to the target communication protocol; As an illustration, a one-way conversion rule between intermediate data and the target protocol is adopted, which eliminates the need to maintain a direct conversion relationship between the source and target protocols. This makes rule management simpler and conversion more efficient, avoids compatibility issues caused by direct conversion between multiple protocols, and improves the stability and accuracy of data conversion.

[0033] Step S5: Send the target data packet to the target node corresponding to the target communication protocol through the target communication bus corresponding to the target communication protocol.

[0034] As an illustration, by precisely matching the bus hardware of the target communication protocol, the adaptability and reliability of data transmission are ensured, thereby achieving seamless end-to-end data forwarding between heterogeneous protocol nodes and meeting the communication requirements of in-vehicle scenarios.

[0035] Steps S1 to S5 as illustrated in this embodiment upgrade the traditional N×N pairwise conversion architecture to an N+1 unidirectional conversion architecture by using unified intermediate data as the core of the conversion. This eliminates the coupling between multiple different protocols, allowing for the development of conversion rules only for the intermediate data when adding a new bus, without modifying the existing protocol conversion framework. Furthermore, the unified intermediate data format significantly reduces logical redundancy in multi-protocol conversion, lowering development complexity and code volume, and improving the overall efficiency of data interaction.

[0036] For step S1, in some embodiments, when the vehicle is in normal operation, the source nodes of various functional domains of the vehicle, such as the ECU node of the body control domain, the central control node of the smart cockpit domain, and the perception node of the autonomous driving domain, will generate various types of data to be transmitted, such as vehicle speed data, cockpit entertainment data, and autonomous driving perception data.

[0037] It is understandable that there is a one-to-one correspondence between source nodes and source communication buses. Source nodes in different functional domains are adapted to different types of source communication buses. For example, source nodes in the body control domain correspond to the CAN bus, source nodes in the smart cockpit domain correspond to the SOME / IP Ethernet bus, source nodes in the autonomous driving domain correspond to the DDS bus, and the IPC bus is used for data transmission of in-vehicle short-range modules.

[0038] Therefore, embodiments of the present invention can accurately adapt to the protocol specifications of various source communication buses through a source bus adapter, and collect source data packets output by source nodes in real time, ensuring the integrity and native compatibility of source data collection, and avoiding problems such as data loss and format corruption caused by direct cross-protocol collection. For example, when the ECU in the body control domain needs to transmit body speed data, the source bus adapter reads the source data packet through the CAN bus, and at this time, the packet carries information such as ID, data length, and data content specified by the CAN protocol.

[0039] In step S2, in some embodiments, the preset unified data structure of the present invention has a fixed format, independent of the source communication protocol and the target communication protocol, and is used to shield the heterogeneity of different protocols at the physical layer, protocol layer, and data format. After acquiring the source data packet, the source bus adapter extracts the content of the source data packet and encapsulates it into an intermediate data packet according to the preset conversion rules, thus completing the conversion from source data packet to intermediate data packet.

[0040] For example, when the vehicle speed data transmitted via the CAN bus is converted into an intermediate data message, core information such as the speed value, data purpose identifier, message transmission priority, and message data length are encapsulated according to the field requirements of a preset structure to form a unified format intermediate data message. It can be understood that at this point, the intermediate data message is no longer limited by the original CAN protocol and can adapt to the conversion needs of any subsequent target communication protocol. Through this conversion, the complex N×N pairwise conversion logic in traditional technology can be simplified to an N+1 unidirectional conversion logic from each bus to the intermediate data, thus eliminating the coupling of conversion rules between different protocols.

[0041] In a preferred embodiment, this application also constructs a layered data interaction architecture for in-vehicle multi-bus protocol adaptation and AI assistance, such as... Figure 2 As shown, the architecture is divided into a vehicle communication protocol stack layer, a protocol adaptation layer, a core control layer, and a data optimization layer from top to bottom. At the same time, a parallel AI assistance layer is configured to provide intelligent support for the entire process. The layers are decoupled and coordinated to fully realize the data parsing, conversion and transmission in steps S1 to S5 of the method in this application.

[0042] Specifically, the vehicle communication protocol stack layer, as the underlying communication entry and exit point of the architecture, can support multiple heterogeneous communication protocols in vehicle scenarios, including CAN / SPI, Some / IP, IPC, RPMsg, UDP / IP, TCP / IP, etc., while also reserving expansion interfaces to support flexible access of new protocols. It can acquire source data packets and send target data packets, providing native protocol support for heterogeneous data interaction and ensuring native adaptation and acquisition of various bus data.

[0043] The protocol adaptation layer, as the core of protocol conversion execution, comprises two main modules: the BusAdapter base class and the multi-protocol stack data conversion management module. The BusAdapter base class uniformly defines the standard interface specification for bus communication. Various vehicle buses only need to inherit from this base class and implement the corresponding interface logic to complete bus adaptation, achieving complete decoupling between the framework and the bus. Furthermore, the multi-protocol stack data conversion management module is primarily responsible for uniformly scheduling each bus adapter, completing the two conversions: from source data packets to intermediate data packets, and from intermediate data packets to target data packets. It is the actual execution vehicle for protocol conversion.

[0044] Furthermore, for Figure 2 The core control layer, as the scheduling core of the architecture, is the hub connecting the protocol adaptation layer, AI assistance layer, and data optimization layer. It can realize scheduling links such as target communication protocol identification and conversion rule matching, ensuring the orderly execution of the entire process interaction.

[0045] Furthermore, the AI-assisted layer, as an intelligent decision-making engine running parallel to the core control layer, can bidirectionally connect to the core control layer. Based on the characteristic information carried by the unified intermediate data, it can automatically complete the identification of the target communication protocol and the dynamic optimization of the interaction rules. At the same time, it adopts a lightweight AI model to adapt to the low computing power environment of in-vehicle embedded systems, thereby getting rid of the dependence on manual configuration in traditional solutions and improving the automation level of the interaction process.

[0046] Furthermore, the data optimization layer, as a full-process performance enhancement layer, includes four major categories: real-time optimization components, reliability optimization components, lightweight optimization components, and compliance optimization components. It can perform full-process performance optimization on intermediate and target data, ensuring low latency and high security of data transmission in vehicle scenarios, and providing performance support for heterogeneous data interaction.

[0047] Specifically, through the aforementioned layered architecture collaboration, the entire processing flow from steps S1 to S5 can be achieved: The data to be transmitted generated by the source node is collected by the corresponding source communication bus through the vehicle communication protocol stack layer. After being parsed and verified by the BusAdapter adapted to the bus, it is reported to the protocol adaptation layer. For example, the speed data of the ECU in the body control domain is collected via the CAN bus, verified by the CANAdapter, and then reported.

[0048] The source bus adapter in the protocol adaptation layer extracts the content of the source data message according to preset rules and encapsulates it into a unified intermediate data message, which is then reported to the core control layer for verification and storage, thereby shielding the heterogeneity of the source protocol. For example, a CAN-formatted speed message is converted into intermediate data by the CANAdapter, thus breaking free from the limitations of the CAN protocol.

[0049] The core control layer sends intermediate data to the AI-assisted layer. The AI-assisted layer then automatically identifies the target communication protocol based on the characteristics of the intermediate data. After the data is sent back, the core control layer schedules the corresponding target bus adapter to stand by. For example, if the AI-assisted layer identifies the target protocol as Some / IP, it will schedule SomeIPAdapter as the target bus adapter.

[0050] The core control layer sends out intermediate data, and the protocol adaptation layer schedules the target bus adapter to convert the intermediate data into target protocol messages according to specific rules and performs verification. For example, the intermediate data is converted into target messages conforming to the Some / IP specification by SomeIPAdapter.

[0051] After being optimized by the data optimization layer, the target message is sent to the corresponding target node via the target communication bus, achieving seamless forwarding of heterogeneous data. For example, a Some / IP format message is sent to the intelligent cockpit domain controller via Ethernet, completing the interaction from CAN to Some / IP.

[0052] For step S3, in some embodiments, identifying the target communication protocol for receiving the source data packet based on the intermediate data packet includes: Extract the purpose of the data in the intermediate data message; Based on the purpose of the data and the intermediate data packets, the target node for receiving the source data packets is determined; The communication protocol corresponding to the target node shall be used as the target communication protocol.

[0053] Specifically, extracting the data purpose from intermediate data messages is achieved by parsing the data identifier field and matching the data purpose, ensuring the accuracy and standardization of data purpose extraction. This includes: The purpose of extracting data from the intermediate data message includes: Parse the data identifier field in the intermediate data message to obtain the corresponding data usage identifier; Based on the data purpose identifier, the data purpose corresponding to the intermediate data message is matched and obtained.

[0054] In illustrative terms, in this embodiment of the invention, a data identifier field is provided in the preset data structure of the intermediate data packet. This field can be identified using a hexadecimal value, with different values ​​corresponding to different types of data uses. The field length is fixed at 2 bytes, facilitating rapid parsing by the core control layer. Specifically, the core control layer can read the data identifier field in the intermediate data packet through the parsing module of the protocol adaptation layer, decode it, and obtain the corresponding hexadecimal value, i.e., the data use identifier. For example, if the parsed data use identifier is 0x0003, the corresponding data service type is cabin air conditioning control; if the data use identifier is 0x0004, the corresponding data service type is power system status control. This data identifier field is synchronously written by the source node when sending the source data packet, and after conversion by the source bus adapter, it is completely retained in the intermediate data packet, ensuring the consistency and integrity of the data use identifier.

[0055] Furthermore, the vehicle node configuration library pre-stores a mapping table between data usage identifiers and data usages. This mapping table covers data service types across all functional domains of the vehicle and can be flexibly updated according to the iterative upgrades of the vehicle communication architecture. After obtaining the data usage identifier, the core control layer calls this mapping table to determine the specific data usage corresponding to that identifier through precise matching.

[0056] In some embodiments, the present invention may further define the specific fields of the intermediate data message and refine the specific implementation process of determining the target node for receiving the source data message based on the data purpose and the intermediate data message.

[0057] In this embodiment, in addition to the data identifier field, the intermediate data packet also explicitly includes two fields: packet transmission priority and packet data length. These two fields are inherent fields of the preset data structure of the intermediate data packet and do not require additional collection.

[0058] Message transmission priority is used to characterize the importance of source data messages, using a 1-5 level hierarchy, with level 1 being the highest and level 5 the lowest. The field length is 1 byte, set by the source node based on the data's importance, and written into the intermediate data message after conversion by the source bus adapter. For example, autonomous driving command data has a level 1 priority, chassis safety data has a level 2 priority, and in-vehicle entertainment data has a level 5 priority. The message data length is used to characterize the number of bytes of data payload in the intermediate data message. The field length is 2 bytes. It is calculated and written by the source bus adapter based on the actual length of the source data when converting the source data message. For example, the intermediate data length after conversion of CAN bus source data is 8 bytes, and the intermediate data length after conversion of SOME / IP bus source data is 32 bytes.

[0059] The process of determining the target node based on the data's purpose and intermediate data messages specifically includes: Based on the preset vehicle domain controller partitioning rules, the functional domain corresponding to the purpose of the data is obtained; The target node is matched from each candidate node in the functional domain based on the data purpose identifier, the message transmission priority, and the message data length.

[0060] As an illustration, the preset vehicle domain controller partitioning rules are stored in the configuration module of the core control layer. These rules divide all vehicle nodes into multiple functional domains, such as chassis control, powertrain, smart cockpit, autonomous driving, and body control, according to the division of labor among vehicle functional modules. Each functional domain corresponds to a specific data usage type. After extracting the data usage, the core control layer uses these partitioning rules to precisely match the corresponding functional domain. For example, if the data usage is for chassis speed control, it corresponds to the chassis control domain; if the data usage is for cockpit display, it corresponds to the smart cockpit domain; if the data usage is for motor speed control, it corresponds to the powertrain domain; and if the data usage is for obstacle perception, it corresponds to the autonomous driving domain.

[0061] Next, the core control layer selects all nodes within the functional domain corresponding to the data purpose identifier from the vehicle node configuration library that can receive data corresponding to that data purpose identifier, forming a candidate node set. For example, if the data purpose identifier is 0x0001 (chassis speed control purpose), the corresponding functional domain is the chassis control domain, and the candidate nodes in this domain include chassis domain controllers, chassis status feedback nodes, vehicle speed sensor nodes, etc. Then, the core control layer extracts the adaptation parameters of each candidate node and matches and filters the candidate node's adaptation parameters with the three features of the intermediate data message. Finally, the candidate node that matches all features is selected as the target node.

[0062] Specifically, the three characteristics of the intermediate data message are: data purpose identifier 0x0001 (chassis speed control purpose), message transmission priority level 2, and message data length 8 bytes; the candidate node parameters in the chassis control domain are as follows: Chassis Domain Controller: The node adapts to data type 0x0001 (chassis speed data), the node priority adapts to threshold levels 1-3, and the node carries a data length threshold of 16 bytes; Chassis status feedback node: The node adapts to data type 0x0001 (chassis speed data), the node priority adapts to a threshold of 3-5 levels, and the node carries a data length threshold of 8 bytes. Vehicle speed sensor node: The node's data type is 0x0002 (vehicle speed sensor data), the node priority adaptation threshold is 2-4 levels, and the node's data length threshold is 4 bytes.

[0063] Through matching and filtering, the chassis domain controller's adaptation parameters fully match the three core characteristics of the intermediate data message. The priority adaptation threshold of the chassis status feedback node does not match the message transmission priority, and the adaptation data type of the vehicle speed sensor node does not match. Therefore, the chassis domain controller is selected as the target node.

[0064] This embodiment defines the fields of the intermediate data message and matches the target node by combining three dimensions: data purpose identifier, message transmission priority, and message data length. This ensures that the target node can accurately adapt to the data transmission requirements, solves the problem of single target node matching dimensions and poor adaptability in traditional technologies, and further improves the reliability and targeting of in-vehicle heterogeneous data interaction.

[0065] Furthermore, in a preferred embodiment, the present invention can also achieve accurate matching of target nodes by using three-dimensional spatial geometric comparison, then: The step of matching the target node from each candidate node within the functional domain based on the data purpose identifier, the message transmission priority, and the message data length includes: The data purpose identifier, the message transmission priority, and the message data length are mapped to a preset three-dimensional rectangular coordinate system to form a first feature point. The first circle corresponding to the first feature point is determined with the first feature point as the center and the preset parameter offset as the radius. Obtain the node-adapted data type, node priority adaptation threshold, and node-carrying data length threshold for each candidate node; The node-adapted data type, the node priority adaptation threshold, and the node-carrying data length threshold are mapped to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node. The second feature point is used as the center and a preset parameter offset is used as the radius to determine the second circle corresponding to the second feature point. Calculate the spatial distance between the center of the first circle and the centers of each of the second circles; Based on the intersection state of the first circle and each of the second circles, the candidate node that intersects with the first circle and has the smallest spatial distance value between its center and the circle is selected as the target node.

[0066] Furthermore, upon determining the first feature point, we have: The step of mapping the data purpose identifier, the message transmission priority, and the message data length to a preset three-dimensional Cartesian coordinate system to form a first feature point includes: The data purpose identifier is linearly mapped to coordinate values ​​on the X-axis to generate the first coordinate value; The message transmission priority is linearly mapped to coordinate values ​​on the Y-axis to generate a second coordinate value; The message data length is linearly mapped to coordinate values ​​on the Z-axis to generate a third coordinate value; The first feature point is generated based on the first coordinate value, the second coordinate value, and the third coordinate value.

[0067] Furthermore, upon determining the second feature point, we have: The step of mapping the node's adapted data type, the node's priority adaptation threshold, and the node's data length threshold to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node includes: For each candidate node, the node's data type is linearly mapped to coordinate values ​​on the X-axis to generate a fourth coordinate value; The node priority adaptation threshold is linearly mapped to a coordinate value on the Y-axis to generate a fifth coordinate value; The threshold value of the data length carried by the node is linearly mapped to a coordinate value on the Z-axis to generate a sixth coordinate value; The second feature point is generated based on the fourth coordinate value, the fifth coordinate value, and the sixth coordinate value.

[0068] In illustrative terms, this embodiment achieves target node matching through a process of coordinate mapping, circle construction, distance calculation, intersection judgment, and node selection. The entire process is completed by a lightweight model of the AI-assisted layer, using INT8 quantization optimization to reduce computing power consumption and adapt to automotive MCU / SoC environments. The specific process is as follows: The preset three-dimensional Cartesian coordinate system uses the vehicle core domain controller as the origin (0,0,0), and the three axes correspond to three feature fields. A linear mapping method is used to convert the actual values ​​of each feature field into coordinate values ​​in the coordinate system. The mapping rules can be preset in the AI ​​assistance layer. The specific mapping method is as follows: The X-axis corresponds to the data usage identifier, which linearly maps the hexadecimal data usage identifier (0x0001-0x000F) to coordinate values ​​from 0 to 10. For example, 0x0001 corresponds to X=1, 0x0005 corresponds to X=5, and 0x000F corresponds to X=10. The Y-axis corresponds to the message transmission priority, linearly mapping priority levels 1-5 to coordinate values ​​0-10. The higher the priority, the larger the coordinate value. For example, level 1 corresponds to Y=10, level 3 corresponds to Y=6, and level 5 corresponds to Y=2. The Z-axis corresponds to the message data length, linearly mapping the length values ​​of 0-64 bytes to coordinate values ​​of 0-50. The smaller the data length, the larger the coordinate value. For example, 8 bytes corresponds to Z=45, 32 bytes corresponds to Z=25, and 64 bytes corresponds to Z=5.

[0069] According to the above mapping rules, the data purpose identifier, transmission priority, and data length of the intermediate data packet are mapped to a spatial point in a three-dimensional coordinate system, namely the first feature point. For example, if the features of the intermediate data packet are: data purpose identifier 0x0001 (X=1 after mapping), transmission priority level 2 (Y=8 after mapping), and data length 8 bytes (Z=45 after mapping), then the coordinates of the first feature point are (1, 8, 45). Subsequently, a first circle is constructed with this first feature point as the center and a preset offset as the radius, and the center coordinates O1 (Xo1, Yo1, Zo1) and radius R1 (0.5) of the first circle are recorded. Optionally, the offset in this embodiment is set to 0.5, which can be flexibly adjusted according to the actual vehicle scenario.

[0070] The core control layer extracts the adaptation parameters of all candidate nodes from the vehicle node configuration library. These adaptation parameters correspond one-to-one with three characteristics of intermediate data packets: the node adaptation data type corresponds to the data purpose identifier, using the same hexadecimal numerical identifier to characterize the data service type that the node can handle; the node priority adaptation threshold refers to the lowest priority level of the packets that the node can handle, for example, levels 1-3 indicate that the node can handle priority level 1, 2, and 3 packets; the node data length threshold refers to the maximum byte limit of the packets that the node can receive, for example, ≤16 bytes indicates that the node can receive packets with a data length not exceeding 16 bytes. For example, the adaptation parameters of a candidate node (chassis domain controller) in the chassis control domain are: node adaptation data type is 0x0001, node priority adaptation threshold is level 2, and node data length threshold is 16 bytes.

[0071] Furthermore, the adaptation parameter mapping process of the chassis domain controller is as follows: the node adapts to data type 0x0001 (X=1 after mapping), the node priority adapts to threshold level 2 (Y=8 after mapping), and the node carries a data length threshold of 16 bytes (Z=35 after mapping). Then, the coordinates of the second feature point are (1,8,35). Subsequently, with the second feature point as the center and using the same preset offset (0.5) as the radius as the first circle, a second circle corresponding to the candidate node is constructed. The center coordinates O2i (Xo2i,Yo2i,Zo2i) and the radius R2i (0.5) of the second circle are recorded, where i is the candidate node number.

[0072] The AI assistance layer uses the distance formula between two points in a three-dimensional Cartesian coordinate system to calculate the spatial distance value Di between the center O1 of the first circle and the center O2i of the second circle of each candidate node. The formula is as follows: Di = ; where the unit of Di is the distance unit within the coordinate system. The smaller Di is, the higher the matching degree between the characteristics of the intermediate data packet and the adaptation parameters of the candidate node. For example, the spatial distance Di between the center O1(1, 8, 45) of the first circle and the center O21(1, 8, 35) of the second circle of the chassis domain controller is Di = = 10; the spatial distance Di between the center O22(1, 6, 45) of the second circle of another candidate node (chassis status feedback node) and the center O1 of the first circle is Di = = 2. Then, the matching degree between the characteristics of the intermediate data packet and the adaptation parameters of the chassis status feedback node is higher.

[0073] The AI assistance layer judges the intersection status between the first circle and each second circle based on a preset circumcircle intersection judgment rule. The specific rule is as follows: If |R1 - R2i| < Di < R1 + R2i, there is an intersection area (partial overlap) between the two circles, indicating that the matching degree between the adaptation parameters of the candidate node and the characteristics of the intermediate data packet is relatively high. Mark this candidate node as a valid candidate node; If Di ≥ R1 + R2i, there is no intersection area (mutually separated) between the two circles, indicating that the matching degree between the adaptation parameters of the candidate node and the characteristics of the intermediate data packet is extremely low. Do not mark it as a valid candidate node for the time; If Di ≤ |R1 - R2i|, one circle completely contains the other circle, indicating that the adaptation parameters of the candidate node completely cover the characteristics of the intermediate data packet. Mark it as a valid candidate node.

[0074] The radii of both the first circle and the second circle are 0.5. Therefore, R1 + R2i = 1.0 and |R1 - R2i| = 0.0: For the chassis domain controller, Di = 10, which is greater than 1.0. There is no intersection area between the two circles, and it is not marked as a valid candidate node; For the chassis status feedback node, Di = 2, which is greater than 1.0. There is no intersection area between the two circles, and it is not marked as a valid candidate node; Suppose there is a third candidate node (vehicle speed display node) with the center O23(1, 8, 44.8) of its second circle. Di = = 0.2, satisfying 0.0 < 0.2 < 1.0. Therefore, the two circles intersect, and it is marked as a valid candidate node.

[0075] Subsequently, all valid candidate nodes are sorted in ascending order of Di, and the valid candidate node with the smallest Di is selected as the target node. If multiple valid candidate nodes have the same Di, the candidate node whose second circle completely contains the first circle is selected first.

[0076] Therefore, this embodiment achieves accurate matching of target nodes through three-dimensional spatial geometric comparison. Compared with the traditional single-dimensional matching method, the matching logic of this embodiment is more rigorous and accurate, which can effectively select the most suitable data receiving node and further improve the reliability and adaptability of vehicle heterogeneous data interaction.

[0077] In a preferred embodiment, the intermediate data message further includes: the real-time packet loss rate of the source communication bus; The method further includes: Compare the real-time packet loss rate with the preset vehicle packet loss rate threshold; When the real-time packet loss rate is determined to be greater than the vehicle-mounted packet loss rate threshold, a fault alarm is triggered, and a prompt message indicating that there is a fault in the source communication bus is output.

[0078] In illustrative terms, this embodiment of the invention, through real-time packet loss rate detection, can eliminate abnormal source packets in the early stages of data processing, terminating subsequent invalid conversion and matching processes, thereby improving overall interaction efficiency. Furthermore, this invention can directly pinpoint the source communication bus exhibiting communication anomalies and output dedicated fault indication information. Unlike traditional technologies that only provide vague alarms indicating data interaction failures, this invention allows maintenance personnel to quickly locate the type and location of the faulty bus, significantly reducing the troubleshooting time for in-vehicle communication systems.

[0079] For step S4, in some embodiments, this step can complete the data format conversion based on the dedicated bus adapter of the protocol adaptation layer. The conversion logic is centered on the unified intermediate data message and is only associated with the target communication protocol, completely isolating the influence of the source communication protocol.

[0080] As an illustration, the system has pre-stored exclusive conversion rules for intermediate data and various vehicle protocols. These rules are stored in the offline constraint dictionary and bus adapter, and different encapsulation logic is executed for different target protocols such as SOME / IP, CAN, and DDS.

[0081] Intermediate data allows the physical and data link layer formats of the source protocol to be stripped away, retaining only the data content and transmission priority. The conversion process only requires data serialization and format encapsulation according to the target protocol specifications. Simultaneously, if the real-time packet loss rate of the source communication bus exceeds the limit during the conversion process, the system will terminate the current conversion process to prevent incomplete data from generating the target message.

[0082] In some embodiments, step S5 is the final step in data interaction, where the data optimization layer and the vehicle communication protocol stack work together to accurately transmit the target data packet to the matching target node.

[0083] As an illustration, before the target data packet is sent, it will undergo adaptation optimization through the data optimization layer. High transmission priority packets will preempt bus timing to ensure low-latency transmission, long packets will be lightweighted and compressed, and a check field will be added to improve transmission reliability.

[0084] Next, the optimized message is transmitted through the target communication bus corresponding to the target protocol, adhering to the target bus's communication timing and transmission specifications. If a fault alarm exists on the source bus, the system can temporarily suspend data transmission and upload the abnormal status to the on-board diagnostic system.

[0085] Therefore, through step S5 of this embodiment of the invention, seamless end-to-end data forwarding between heterogeneous protocol buses is achieved, which not only ensures the adaptability of data transmission, but also ensures the communication safety of the whole vehicle by combining fault detection mechanism, and meets the high real-time and high reliability communication requirements of vehicle scenarios such as autonomous driving and chassis control.

[0086] This invention, through the above technical solution, solves the problems of poor scalability, insufficient intelligence, and low reliability of data conversion in existing in-vehicle heterogeneous data interaction technologies, namely: The protocol adaptation layer constructed in this invention defines the standard interface specifications of all buses through the BusAdapter base class. Various vehicle buses (CAN, SOME / IP, DDS, SPI, IPC, etc.) only need to inherit this base class and implement 3 interfaces to complete bus adaptation. When adding new bus conversion rules, there is no need to modify the framework code. It can quickly respond to the iterative upgrade of the vehicle EE architecture and flexibly adapt to diverse bus communication needs.

[0087] This invention uses an AI-assisted layer to automatically identify the target communication protocol, eliminating the need for manual configuration of protocol types and routing rules. It can automatically perform intermediate data packet feature analysis and accurate three-dimensional spatial matching of target nodes. At the same time, it links a fault detection mechanism to achieve real-time alarms for source bus anomalies. This solves the problems of manual protocol configuration and delayed fault handling in existing solutions, improves the automation level and operational reliability of the framework, reduces maintenance costs, and meets the high reliability communication requirements of vehicle scenarios.

[0088] This invention effectively shields the heterogeneity of different buses in terms of physical layer, protocol layer, and data format through a unified intermediate data format, enabling flexible data interaction between multiple protocols. At the same time, the data optimization layer, through components such as real-time optimization and reliability optimization, can perform priority scheduling, lightweight compression, and verification processing on target data packets. Combined with the source bus real-time packet loss rate detection mechanism, abnormal packets can be eliminated in the early stage of data processing, avoiding problems such as data loss, tampering, and delay during data conversion. It can adapt to the requirements of real-time and accuracy communication in scenarios such as autonomous driving and chassis control, and realize seamless end-to-end data forwarding between heterogeneous protocol nodes.

[0089] The top-down layered architecture constructed by this invention includes, for example, an in-vehicle communication protocol stack layer, a protocol adaptation layer, a core control layer, and a data optimization layer, and is equipped with an AI-assisted layer to provide intelligent support for the entire process. The layers are decoupled and coordinated, and can be widely applied to various in-vehicle EE architecture scenarios such as the vehicle control domain, the intelligent cockpit domain, and the autonomous driving domain. Please see Figure 3 This application also provides an in-vehicle heterogeneous data interaction device, which can implement the above-mentioned in-vehicle heterogeneous data interaction method. The device includes: The source message acquisition module 601 is used to acquire the source data message to be transmitted by the source node through the source communication bus corresponding to the source node; The intermediate message conversion module 602 is used to convert the source data message into an intermediate data message with a preset data structure. The target communication protocol identification module 603 is used to identify the target communication protocol for receiving the source data packet based on the intermediate data packet; The target message conversion module 604 is used to convert the intermediate data message into a target data message corresponding to the target communication protocol according to the conversion rules between the intermediate data message and the target communication protocol; The target message transmission module 605 is used to send the target data message to the target node corresponding to the target communication protocol through the target communication bus corresponding to the target communication protocol.

[0090] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0091] It should be noted that the device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0092] Those skilled in the art will clearly understand that, for convenience and simplicity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0093] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method for interacting with heterogeneous data in a vehicle. This electronic device can include any smart terminal such as a tablet computer or an in-vehicle computer.

[0094] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0095] Please see Figure 4 , Figure 4 This illustrates the hardware structure of an electronic device according to another embodiment, the electronic device comprising: The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 702 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 702 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this application are implemented through software or firmware, the relevant program code is stored in the memory 702 and is called and executed by the processor 701. The input / output interface 703 is used to implement information input and output; The communication interface 704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.). Bus 705 transmits information between various components of the device (e.g., processor 701, memory 702, input / output interface 703, and communication interface 704); The processor 701, memory 702, input / output interface 703 and communication interface 704 are connected to each other within the device via bus 705.

[0096] The processor 701 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. This processor is the control center of the terminal device, connecting various parts of the terminal device via various interfaces and lines.

[0097] The memory 702 can be used to store the computer program. The processor implements various functions of the terminal device by running or executing the computer program stored in the memory and calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device or other volatile solid-state storage device.

[0098] This application also provides a vehicle, which includes the aforementioned in-vehicle desktop dynamic display device or the aforementioned electronic device.

[0099] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for interacting with heterogeneous data in a vehicle.

[0100] It is understood that the content of the above method embodiments is applicable to the present computer storage medium embodiments. The specific functions implemented by the present computer storage medium embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0101] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for interacting with heterogeneous in-vehicle data.

[0102] It is understood that the content of the above method embodiments is applicable to the embodiments of this computer program product. The specific functions implemented by the embodiments of this computer program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0103] Those skilled in the art will understand that all or some of the steps, apparatuses, or functional modules / units in the methods disclosed above can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0104] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for interacting with heterogeneous data in a vehicle, characterized in that, The method includes: The source data packet to be transmitted by the source node is obtained through the source communication bus corresponding to the source node. The source data packet is converted into an intermediate data packet with a preset data structure; Based on the intermediate data message, the target communication protocol for receiving the source data message is identified; According to the conversion rules between the intermediate data message and the target communication protocol, the intermediate data message is converted into the target data message corresponding to the target communication protocol; The target data packet is sent to the target node corresponding to the target communication protocol via the target communication bus corresponding to the target communication protocol.

2. The method for interacting with heterogeneous vehicle data according to claim 1, characterized in that, The step of identifying the target communication protocol for receiving the source data packet based on the intermediate data packet includes: Extract the purpose of the data in the intermediate data message; Based on the purpose of the data and the intermediate data packets, the target node for receiving the source data packets is determined; The communication protocol corresponding to the target node shall be used as the target communication protocol.

3. The method for interacting with heterogeneous vehicle data according to claim 2, characterized in that, The purpose of extracting data from the intermediate data message includes: Parse the data identifier field in the intermediate data message to obtain the corresponding data usage identifier; Based on the data purpose identifier, the data purpose corresponding to the intermediate data message is matched and obtained.

4. The method for interacting with heterogeneous vehicle data according to claim 3, characterized in that, The intermediate data message includes: message transmission priority and message data length; The step of determining the target node for receiving the source data packet based on the data purpose and the intermediate data packet includes: Based on the preset vehicle domain controller partitioning rules, the functional domain corresponding to the purpose of the data is obtained; The target node is matched from each candidate node in the functional domain based on the data purpose identifier, the message transmission priority, and the message data length.

5. The method for interacting with heterogeneous vehicle data according to claim 4, characterized in that, The step of matching the target node from each candidate node within the functional domain based on the data purpose identifier, the message transmission priority, and the message data length includes: The data purpose identifier, the message transmission priority, and the message data length are mapped to a preset three-dimensional rectangular coordinate system to form a first feature point. The first circle corresponding to the first feature point is determined with the first feature point as the center and the preset parameter offset as the radius. Obtain the node-adapted data type, node priority adaptation threshold, and node-carrying data length threshold for each candidate node; The node-adapted data type, the node priority adaptation threshold, and the node-carrying data length threshold are mapped to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node. The second feature point is used as the center and a preset parameter offset is used as the radius to determine the second circle corresponding to the second feature point. Calculate the spatial distance between the center of the first circle and the centers of each of the second circles; Based on the intersection state of the first circle and each of the second circles, the candidate node that intersects with the first circle and has the smallest spatial distance value between its center and the circle is selected as the target node.

6. The method for interacting with heterogeneous vehicle data according to claim 5, characterized in that, The step of mapping the data purpose identifier, the message transmission priority, and the message data length to a preset three-dimensional Cartesian coordinate system to form a first feature point includes: The data purpose identifier is linearly mapped to coordinate values ​​on the X-axis to generate the first coordinate value; The message transmission priority is linearly mapped to coordinate values ​​on the Y-axis to generate a second coordinate value; The message data length is linearly mapped to coordinate values ​​on the Z-axis to generate a third coordinate value; The first feature point is generated based on the first coordinate value, the second coordinate value, and the third coordinate value.

7. The method for interacting with heterogeneous vehicle data according to claim 5, characterized in that, The step of mapping the node's adapted data type, the node's priority adaptation threshold, and the node's data length threshold to the three-dimensional Cartesian coordinate system to form a second feature point corresponding to each candidate node includes: For each candidate node, the node's data type is linearly mapped to coordinate values ​​on the X-axis to generate a fourth coordinate value; The node priority adaptation threshold is linearly mapped to a coordinate value on the Y-axis to generate a fifth coordinate value; The threshold value of the data length carried by the node is linearly mapped to a coordinate value on the Z-axis to generate a sixth coordinate value; The second feature point is generated based on the fourth coordinate value, the fifth coordinate value, and the sixth coordinate value.

8. The method for interacting with heterogeneous vehicle data according to claim 1, characterized in that, The intermediate data message also includes: the real-time packet loss rate of the source communication bus; The method further includes: Compare the real-time packet loss rate with the preset vehicle packet loss rate threshold; When the real-time packet loss rate is determined to be greater than the vehicle-mounted packet loss rate threshold, a fault alarm is triggered, and a prompt message indicating that there is a fault in the source communication bus is output.

9. A vehicle-mounted heterogeneous data interaction device, characterized in that, The device includes: The source message acquisition module is used to acquire the source data message to be transmitted by the source node through the source communication bus corresponding to the source node; An intermediate message conversion module is used to convert the source data message into an intermediate data message with a preset data structure; The target communication protocol identification module is used to identify the target communication protocol used to receive the source data packet based on the intermediate data packet. The target message conversion module is used to convert the intermediate data message into a target data message corresponding to the target communication protocol according to the conversion rules between the intermediate data message and the target communication protocol. The target message transmission module is used to send the target data message to the target node corresponding to the target communication protocol via the target communication bus corresponding to the target communication protocol.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the method for interacting with heterogeneous data in a vehicle as described in any one of claims 1 to 8.

11. A vehicle comprising an interactive device for heterogeneous in-vehicle data as claimed in claim 9 or an electronic device as claimed in claim 10.

Images