A vehicle-mounted heterogeneous device networking method

Abstract

The application discloses a kind of vehicle-mounted heterogeneous equipment networking methods, it is related to vehicle-mounted network communication technical field, including the deployment lightweight protocol adaptation layer on vehicle-mounted heterogeneous equipment, convert device native control instruction into standardized data theme;FastDDS communication framework is deployed in vehicle-mounted central node, and based on standardized data theme matching associated equipment is built to publish and subscribe network;Different standardized data theme types are configured with different QoS strategies, the function description of new access equipment is uploaded through adaptation layer and theme capability matrix is generated, adjust existing device subscription relationship, complete vehicle-mounted heterogeneous equipment networking.The application realizes the lightweight access of vehicle-mounted heterogeneous equipment, greatly reduces the access threshold of equipment and system power consumption, improves the reliability, real-time performance and expansibility of vehicle-mounted network.

Description

Technical Field

[0001] This invention relates to the field of vehicle network communication technology, and in particular to a method for networking heterogeneous devices in vehicles. Background Technology

[0002] With the continuous evolution of in-vehicle electronic and electrical architecture, the number and types of heterogeneous in-vehicle devices are experiencing explosive growth, including various functional modules such as fragrance diffusers, air pumps, cameras, radar sensors, and in-vehicle infotainment systems. Due to differences in suppliers, protocol standards, and data formats, interoperability among these devices on the same vehicle platform has become a pressing technical challenge. In recent years, the industry has begun to introduce Service-Oriented Architecture (SOA) and message middleware technology to forward and manage device control commands and data streams through a unified middleware layer. However, most of these solutions are based on heavy middleware or centralized servers, consuming significant computing and communication resources and making it difficult to guarantee real-time performance. Furthermore, with the deepening integration of autonomous driving and smart cockpit functions, the demand for high-bandwidth, low-latency, and high-reliability networks is becoming increasingly prominent. Traditional CAN bus, LIN bus, or single communication methods based on Ethernet are no longer sufficient to fully meet the requirements of concurrent transmission and hierarchical scheduling of multimodal data.

[0003] Existing technologies for interconnecting heterogeneous devices in vehicles typically suffer from the following shortcomings: First, protocol adaptation layers often rely on robust hardware processing capabilities or complex software stacks, making lightweight deployment impossible on resource-constrained devices, thus increasing system cost and power consumption. Second, when performing topic routing and message forwarding at the central node, static configuration or manual intervention is frequently employed, lacking dynamic discovery and automatic reconfiguration mechanisms, making it difficult to meet the hot-swappable requirements of new devices during vehicle operation. Third, differentiated Quality of Service (QoS) guarantee strategies are not provided for different types of data, such as control commands, status monitoring, and video streams, resulting in the inability to guarantee the real-time performance and reliability of critical control information during network congestion or failures. Especially for concurrent transmission scenarios of high-priority control commands and large-capacity video streams, existing methods struggle to maintain stable bandwidth allocation while ensuring minimal latency. Furthermore, the identification of new device capabilities and network topology updates still rely on manual configuration, lacking intelligent means for automatically generating capability matrices and adjusting subscription relationships. Summary of the Invention

[0004] In view of the problems existing in current methods for networking heterogeneous in-vehicle devices, this invention is proposed. Therefore, the problem this invention aims to solve is how to provide a method for networking heterogeneous in-vehicle devices.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] In a first aspect, the present invention provides a method for networking heterogeneous devices in a vehicle, which includes deploying a lightweight protocol adaptation layer on the heterogeneous devices in the vehicle to convert the native control commands of the devices into standardized data themes.

[0007] The FastDDS communication framework is deployed in the vehicle's central node to build a publish-subscribe network based on standardized data topics and related devices.

[0008] Differentiated QoS policies are configured for different standardized data topic types. The functional descriptions of newly accessed devices are uploaded through the adaptation layer and a topic capability matrix is ​​generated. The subscription relationships of existing devices are adjusted to complete the networking of heterogeneous in-vehicle devices.

[0009] As a preferred embodiment of the vehicle-mounted heterogeneous device networking method of the present invention, wherein: the vehicle-mounted heterogeneous devices include a fragrance diffuser, an air pump, and a camera; the adaptation layer parses the device's native control commands in real time based on the device's native communication protocol, utilizes frame verification and eliminates abnormal messages, and combines semantic naming rules based on device type, device function, and data type to map the device's native control commands into standardized data topics, wherein the expression for the frame verification is:

[0010]

[0011] Among them, byte i This represents the i-th byte in the message, where n is the total number of bytes in the message.

[0012] As a preferred embodiment of the vehicle-mounted heterogeneous device networking method of the present invention, the standardized data subject includes:

[0013] The adaptation layer maps data to a unified format theme name according to preset rules. The naming method is: theme name = device type + function + data type.

[0014] All publishable topics are registered to the central node and published. If communication interruption or packet loss occurs during data publication, a retransmission mechanism is initiated to adjust the sending interval and calculate the retry waiting time, expressed as:

[0015] τ=min(τ max ,α×2 a )

[0016] Where τ is the current waiting time, a is the number of retries already attempted, and α is the initial delay coefficient. max This is the maximum waiting time limit;

[0017] Map the fragrance diffuser's output concentration adjustment command to the fragrance control command theme; map tire pressure monitoring data to the air pressure monitoring data theme; map video stream data to the real-time video stream theme.

[0018] As a preferred embodiment of the vehicle-mounted heterogeneous device networking method of the present invention, the FastDDS communication framework automatically triggers a cleanup process when it detects that any node is offline or a topic is deregistered, cancels the corresponding publisher or subscriber entry, and performs resubscription or switches to an alternative publisher for the affected subscribers.

[0019] As a preferred embodiment of the vehicle-mounted heterogeneous device networking method of the present invention, the step of configuring differentiated QoS policies for different standardized data topic types includes:

[0020] For fragrance control commands, the strategy is to ensure that each command is acknowledged; the network layer completes one round trip within a predetermined time limit; and all network scheduling is prioritized.

[0021] For real-time video streaming topics, the strategy is to reserve a dedicated channel for bandwidth; the maximum data volume per second will not exceed the reserved bandwidth.

[0022] For barometric pressure monitoring data, the strategy is that the data update time is less than the lifecycle threshold; if no new data is received within the timeout period, a lifespan loss event is triggered, with the lifecycle threshold T being [not specified]. de The calculation formula is expressed as:

[0023]

[0024] in: is the average reporting period for the status topic, and ∈ is the time jitter ratio;

[0025] The central node maintains a topic-QoS mapping table, which associates the defined policies with the corresponding topics. When a new topic is registered or a new subscription is established, the corresponding QoS parameters are sent to the communication framework.

[0026] As a preferred embodiment of the vehicle-mounted heterogeneous device networking method of the present invention, the step of uploading the functional description of the newly accessed device and generating a topic capability matrix through the adaptation layer includes:

[0027] After a new device is connected, the adaptation layer generates a unique device identifier and software / hardware version information, extracts functional description items from the device driver, and forms a functional description table, including: a list of topics that can be published, a list of topics that can be subscribed to, the minimum / maximum data rate supported, and recommended QoS parameters;

[0028] The function description table is sent to the central node and compared with the existing topic catalog and QoS policy center to determine whether the new topic already exists or needs to be added.

[0029] According to the functional description table, the new device generates a device topic capability matrix at the central node. Each row of the matrix contains: device ID, topic name, role, and recommended QoS parameters.

[0030] If a topic proposed by a new device conflicts with the existing configuration, the policy center will automatically adjust it according to priority rules.

[0031] In a second aspect, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of a method for networking heterogeneous devices in a vehicle.

[0032] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements the steps of a method for networking heterogeneous devices in a vehicle.

[0033] The beneficial effects of this invention are as follows: This invention realizes lightweight access, efficient dynamic networking, and refined quality of service assurance for heterogeneous in-vehicle devices. On the one hand, it greatly reduces the access threshold for devices and system power consumption. On the other hand, it constructs a communication network that can be self-reconfigured and self-optimized, comprehensively improving the reliability, real-time performance, and scalability of the in-vehicle network. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart of a method for networking heterogeneous devices in a vehicle. Detailed Implementation

[0036] To make the above-mentioned objects, features, and advantages of the present invention more readily understood, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0037] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0038] Secondly, the term "one embodiment" or "example" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the invention. An embodiment appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment that selectively excludes other embodiments.

[0039] Reference Figure 1 This is the first embodiment of the present invention, which provides a method for networking heterogeneous devices in a vehicle, including:

[0040] S1: Deploy a lightweight protocol adaptation layer on heterogeneous in-vehicle devices to convert native device control commands into standardized data themes;

[0041] Specifically, in the vehicle system, a lightweight adaptation layer is deployed for heterogeneous devices such as fragrance diffusers, air pumps, and cameras. This adaptation layer is used to achieve unified access between devices with different protocols, ensuring that subsequent data publishing has standardized semantics.

[0042] Before deployment, configure access parameters for each device, including the device's unique identifier, the type of communication protocol used (such as serial port protocol, CAN protocol, or proprietary JSON format protocol), and the types of commands and data structures supported locally. The adaptation layer needs to be able to automatically load these parameters and complete the protocol handshake and data listening after startup.

[0043] When the device outputs raw data frames, the adaptation layer first performs frame boundary identification and verification to eliminate abnormal or incomplete frames. The checksum is calculated using the following expression:

[0044]

[0045] Among them, byte i This represents the i-th byte in the message, where n is the total number of bytes in the message.

[0046] After the verification is passed, the valid data payload is extracted for subsequent processing.

[0047] The adaptation layer extracts semantic fields from the messages and completes the semantic abstraction of device data. For example, a control command from a fragrance diffuser indicating a fragrance concentration of 0.8 is interpreted as a concentration adjustment ratio; a pressure value reported by an air pump is 2.4 bar; a camera continuously outputs several frames of video stream data per second, which needs to be sorted and processed according to timestamps and frame numbers.

[0048] The adaptation layer maps this data to a unified format theme name according to preset rules. The naming method is: theme name = device type + function + data type.

[0049] Once the adaptation layer completes data parsing and topic mapping, it registers all publishable topic information with the central node. This process ensures that subsequent subscribing devices can subscribe on demand and dynamically bind based on the topic catalog.

[0050] Before transmission, each piece of data is encapsulated into a standard structure containing the following three elements: the mapped subject name; the timestamp that generated the data, usually using a unified time base (such as GPS time); and the data body, including auxiliary fields such as value, unit, and status label.

[0051] For command-type data such as fragrance control, an event-driven mechanism is typically used for real-time release; while tire pressure monitoring data can be uploaded periodically or proactively reported when the detected value changes exceed a threshold; video stream data needs to be continuously pushed, requiring stable bandwidth.

[0052] If communication interruption or packet loss occurs during data transmission, the adaptation layer should initiate a retransmission mechanism and adjust the transmission interval according to the exponential backoff strategy, calculating the retry waiting time, as follows:

[0053] τ=min(τ max ,α×2 a )

[0054] Where τ is the current waiting time, a is the number of retries already attempted, and α is the initial delay coefficient (e.g., 100 milliseconds). max This represents the maximum waiting time limit.

[0055] S2: Deploy the FastDDS communication framework at the vehicle's central node to build a publish-subscribe network based on standardized data topics and related devices;

[0056] Specifically, the FastDDS middleware is installed in the central node (such as the vehicle domain control unit) and a system-level configuration file is loaded, which includes: network interface selection (such as Ethernet or vehicle CAN bus gateway); default transport protocol (UDP / IP, TCP / IP or shared memory);

[0057] Start the FastDDS topic discovery service so that it can listen for join and leave events of publishers or subscribers within the local area network.

[0058] The memory pool and thread pool are pre-allocated according to the vehicle environment; the central node constructs a topic directory based on the received registration information, listing all known topic names and their source devices.

[0059] FastDDS' built-in discovery protocol periodically broadcasts topic presence messages, ensuring that all nodes receive timely updates when a new topic registers or deregisters.

[0060] It employs a combination of exact matching and wildcard matching: Exact matching: Publishers and subscribers with exactly the same topic name are directly associated; Wildcard matching: Supports wildcards for suffixes or prefixes, such as camera_stream_ which can match all camera-related real-time video stream topics.

[0061] When an air pump node issues a subscription request for the tire pressure demand topic, FastDDS searches the topic directory for all device identifiers that have published that topic and automatically performs point-to-point or multicast connections at the network layer.

[0062] If only one device publishes, a one-to-one reliable channel is built; if multiple devices publish, a multicast group or multiple one-to-many channels are built, depending on the QoS configuration.

[0063] When a camera node starts publishing a live video stream topic, it broadcasts a new publication event. Any dashboard device that has subscribed to the topic receives the event and automatically creates a corresponding receiving channel locally, and completes a handshake and data stream binding with the camera node.

[0064] When publishers and subscribers first establish a channel, they perform a two-way handshake to confirm the connection and initiate heartbeat detection (e.g., sending a heartbeat packet every 200ms) to ensure the link is alive and to detect faulty nodes in a timely manner.

[0065] When a new device comes online, it automatically publishes the topics it can provide or needs; FastDDS immediately incorporates it into the topology without manual intervention.

[0066] When a device goes offline or malfunctions, its topic registration is revoked. FastDDS notifies all relevant subscribers, automatically disconnects the corresponding channel, and cleans up resources.

[0067] Based on the monitoring results of communication latency and packet loss rate, the central node can trigger a rematching mechanism to replace high-latency or low-reliability channels with backup channels or adjust them to a better transmission protocol.

[0068] S3: Configure differentiated QoS policies for different standardized data topic types, upload the functional description of newly accessed devices through the adaptation layer and generate a topic capability matrix, adjust the subscription relationship of existing devices, and complete the networking of heterogeneous in-vehicle devices.

[0069] Specifically, define the Quality of Service (QoS) policy, with the fragrance control command as the subject. The goal is to ensure that the end-to-end latency of the command does not exceed the predetermined time, while achieving zero packet loss. Policy elements include: ensuring that every command is acknowledged; that is, the network layer must complete one round trip within the predetermined time limit; and prioritizing this type of message in all network scheduling.

[0070] Real-time video streaming topic, objective: to continuously and stably support high-definition or low-latency video streams. Strategy elements: dedicated bandwidth reserves; maximum data volume per second does not exceed the reserved bandwidth.

[0071] Barometric pressure monitoring data topic, objective: to periodically report status data, with automatic alarm if no updates are received for an extended period. Strategy elements: data update time is less than the lifespan threshold; if no new data is received within the timeout period, a lifespan loss event is triggered. Lifespan threshold T de The calculation formula is expressed as:

[0072]

[0073] in: ∈ represents the average reporting period for the status topic, and ∈ represents the time jitter ratio.

[0074] The central node maintains a topic-QoS mapping table, which associates the three types of policies defined with the corresponding topics.

[0075] When a new topic is registered or a new subscription is established, the policy center automatically sends the corresponding QoS parameters to the communication framework.

[0076] The QoS monitoring interface provided by FastDDS collects real-time metrics such as average latency and 95th percentile latency for each topic; bandwidth usage: monitors the actual real-time video stream throughput and compares it with the reserved bandwidth of 20Mbps; packet loss rate: counts the number of failed confirmations for fragrance control commands.

[0077] Dynamic adjustments are made. If the delay of the fragrance control command theme approaches the predetermined extension limit, the network priority is increased. If the actual bandwidth of the real-time video stream theme is lower than the reserved value, the reliability requirements can be temporarily relaxed and the best effort mode can be switched to prevent the flow from being interrupted. If the barometric pressure monitoring data theme frequently triggers timeouts, the lifecycle threshold is increased.

[0078] When a new device is connected, the following steps are performed: its functional description data is registered to the central node through the adaptation layer; a device capability matrix table is automatically generated, which includes a list of publishable / subscribeable topics and QoS requirements; existing devices dynamically adjust their subscription relationships based on the device capability matrix table.

[0079] After a new device is connected, the adaptation layer immediately performs a self-test to confirm that the sensors, actuators or communication modules are in normal condition, and generates a unique device identifier and software and hardware version information.

[0080] The adaptation layer extracts functional description items from the device driver or firmware to form a functional description table, including: a list of publishable topics, a list of subscribed topics, the minimum / maximum supported data rates, and recommended QoS parameters;

[0081] The adaptation layer sends the functional description table to the device registration service of the central node, along with a timestamp and device certificate to complete trusted authentication.

[0082] After receiving the function description, the central node compares it with the existing topic catalog and QoS policy center to determine whether the new topic already exists or needs to be added.

[0083] According to the functional description table, the new device generates a device topic capability matrix at the central node. Each row of the matrix contains: device ID, topic name, role, and recommended QoS parameters.

[0084] If a new device proposes a topic that conflicts with the existing configuration (e.g., the same topic but different QoS requirements), the policy center will automatically adjust it according to priority rules.

[0085] This embodiment also provides a computer device applicable to a method for networking heterogeneous devices in a vehicle, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement all or part of the steps of the method described in the above embodiments of the present invention.

[0086] This embodiment also provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, it performs the method in any optional implementation of the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0087] The storage medium proposed in this embodiment and the data storage method proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0088] In summary, this invention achieves lightweight access for heterogeneous in-vehicle devices, efficient dynamic networking, and refined quality of service assurance. On the one hand, it greatly reduces the access threshold for devices and system power consumption; on the other hand, it constructs a self-reconfigurable and self-optimizing communication network, comprehensively improving the reliability, real-time performance, and scalability of the in-vehicle network.

[0089] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for networking heterogeneous devices in a vehicle, characterized in that: include, Deploy a lightweight protocol adaptation layer on heterogeneous in-vehicle devices to convert native device control commands into standardized data themes; The in-vehicle heterogeneous devices include a fragrance diffuser, an air pump, and a camera. The adaptation layer parses the device's native control commands in real time based on the device's native communication protocol, uses frame verification and eliminates abnormal messages, and combines semantic naming rules based on device type, device function, and data type to map the device's native control commands into standardized data topics. The expression for the frame verification is: in, Indicates the first in the message bytes, It is the total number of bytes in the message; The FastDDS communication framework is deployed in the vehicle's central node to build a publish-subscribe network based on standardized data topics and related devices. Configure differentiated QoS policies for different standardized data topic types, upload the functional description of newly accessed devices through the adaptation layer and generate a topic capability matrix, adjust the existing device subscription relationship, and complete the networking of vehicle-mounted heterogeneous devices; The configuration of differentiated QoS policies for different standardized data topic types includes: For fragrance control commands, the strategy is to ensure that each command is acknowledged; the network layer completes one round trip within a predetermined time limit; and all network scheduling is prioritized. For real-time video streaming topics, the strategy is to reserve a dedicated channel for bandwidth; the maximum data volume per second will not exceed the reserved bandwidth. For barometric pressure monitoring data, the strategy is that the data update time is less than the lifecycle threshold; if no new data is received within the timeout period, a lifespan loss event is triggered, and the lifecycle threshold is [not specified]. The calculation formula is expressed as: in: This represents the average reporting cycle for the status topic. The time jitter ratio; The central node maintains a topic-QoS mapping table, which associates the defined policies with the corresponding topics. When a new topic is registered or a new subscription is established, the corresponding QoS parameters are sent to the communication framework.

2. The method for networking heterogeneous devices in a vehicle as described in claim 1, characterized in that: The standardized data topics include: The adaptation layer maps data to a unified format theme name according to preset rules. The naming method is: theme name = device type + function + data type. All publishable topics are registered to the central node and published. If communication interruption or packet loss occurs during data publication, a retransmission mechanism is initiated to adjust the sending interval and calculate the retry waiting time, expressed as: in, The current waiting time, This represents the number of retries already attempted. This is the initial delay coefficient. This is the maximum waiting time limit; Map the fragrance diffuser's output concentration adjustment command to the fragrance control command theme; map tire pressure monitoring data to the air pressure monitoring data theme; map video stream data to the real-time video stream theme.

3. The method for networking heterogeneous devices in a vehicle as described in claim 2, characterized in that: When the FastDDS communication framework detects that any node is offline or a topic is deregistered, it automatically triggers a cleanup process, revokes the corresponding publisher or subscriber entry, and performs resubscription or switches to an alternative publisher for the affected subscribers.

4. The method for networking heterogeneous devices in a vehicle as described in claim 3, characterized in that: The process of uploading the functional description of the newly accessed device through the adaptation layer and generating a topic capability matrix includes: After a new device is connected, the adaptation layer generates a unique device identifier and software / hardware version information, extracts functional description items from the device driver, and forms a functional description table, including: a list of topics that can be published, a list of topics that can be subscribed to, the minimum / maximum data rate supported, and recommended QoS parameters; The function description table is sent to the central node and compared with the existing topic catalog and QoS policy center to determine whether the new topic already exists or needs to be added. According to the functional description table, the new device generates a device topic capability matrix at the central node. Each row of the matrix contains: device ID, topic name, role, and recommended QoS parameters. If a topic proposed by a new device conflicts with the existing configuration, the policy center will automatically adjust it according to priority rules.

5. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the vehicle-mounted heterogeneous device networking method according to any one of claims 1 to 4.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the vehicle-mounted heterogeneous device networking method according to any one of claims 1 to 4.

Images