Vehicle-mounted information processing method and vehicle-mounted information processing device

Abstract

The invention provides a vehicle-mounted information processing method and a vehicle-mounted information processing device, and the method comprises the steps: obtaining the connection state and neighborhood relation information between all devices in a vehicle-mounted network; determining a connection relationship between the devices based on the connection state and the neighbor relationship information; processing the connection relationship by using a fast spanning tree protocol, and determining a trunk path; according to the trunk path, mapping to obtain a topological data model; and performing difference comparison on the topological data model and an existing topological model stored locally, and adaptively selecting a configuration issuing mode to update network configuration according to a comparison result and the protocol support capability of target equipment. According to the invention, the adaptive configuration updating of the vehicle-mounted network topology is realized, and the maintainability and flexibility of the vehicle-mounted network are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle Ethernet technology, and more specifically, to a vehicle information processing method and a vehicle information processing device. Background Technology

[0002] Currently, the network topology of automotive Ethernet domain controllers generally adopts a static configuration approach, meaning that the network connections are fixed during the vehicle manufacturing stage. However, with the continuous evolution of automotive electronic and electrical architecture, the number of onboard sensors continues to increase, and device access methods are becoming increasingly flexible. For example, users can independently add or replace network nodes such as cameras and radars, leading to frequent changes in the network structure. Traditional static configuration methods are difficult to adapt to these dynamic changes, lacking adaptive capabilities when devices are replaced or the network is expanded, thus limiting the flexibility and maintainability of the automotive network.

[0003] To address the need for network topology discovery, several dynamic discovery methods based on information technology networks exist in the current technology, such as those relying on Simple Network Management Protocol (SNMP), Link Layer Discovery Protocol (LLDP), or Precise Time Protocol (PTP). However, these methods have significant limitations in the vehicular environment: SNMP has high resource requirements, and many vehicular microcontroller units and switches do not support it; LLDP is difficult to propagate effectively among non-LLDP nodes; and the Precise Time Protocol (PTP) requires all nodes to support the protocol, limiting its applicability. Furthermore, existing methods often focus on topology discovery itself, failing to effectively integrate identification, modeling, and configuration, and lacking real-time response and adaptive reconfiguration capabilities to dynamic link changes, making it difficult to meet the high reliability and automated operation and maintenance requirements of vehicular networks. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide an in-vehicle information processing method and an in-vehicle information processing device to overcome at least one of the above-mentioned defects.

[0005] In a first aspect, embodiments of this application provide a vehicle information processing method, the method comprising: acquiring connection status and neighbor relationship information between devices in a vehicle network; determining connection relationships between devices based on the connection status and neighbor relationship information; processing the connection relationships using a fast spanning tree protocol to determine a backbone path; mapping a topology data model according to the backbone path; comparing the topology data model with an existing topology model stored locally, and adaptively selecting a configuration distribution method to update the network configuration based on the comparison results and the protocol support capabilities of the target device.

[0006] In one optional embodiment of this application, the connection status and neighbor relationship information between devices in the vehicular network are obtained in the following manner: The link layer discovery protocol neighbor information of the devices is obtained through the network configuration protocol and its supporting structured data modeling language model interface; if the target device does not respond to the network configuration protocol request, the simple network management protocol is used to obtain the basic identifier and port information of the device by querying the object identifier in its management information base; if the target device does not respond to the simple network management protocol request, the process is downgraded to the network layer or link layer, and the binding relationship between the Internet Protocol address and the Media Access Control address is obtained by sending an Address Resolution Protocol broadcast request, or the online status of the device is detected by sending an Internet Control Message Protocol echo request message; based on the information successfully obtained in any step, the connection status and neighbor relationship between the devices are parsed and determined.

[0007] In one optional embodiment of this application, the connection relationship between devices is determined by: integrating information from different protocol sources, including a link layer discovery protocol neighbor table, an address resolution protocol cache table, Internet Control Message Protocol response data, and interface indexes and media access control address forwarding table information queried through Simple Network Management Protocol; performing cross-validation using information from different protocol sources to obtain cross-validation results; and constructing the connection relationship between devices based on the cross-validation results.

[0008] In one optional embodiment of this application, the backbone path is determined as follows: a bridge is selected based on bridge priority and media access control address; for each physical network segment, a port with the lowest path cost to the root bridge is selected as a designated port to forward data to that physical network segment; on each non-root bridge, a port with the lowest path cost to the root bridge is selected as the root port, and the ports corresponding to the remaining redundant links are set to a blocked state so that they only process protocol messages and do not forward user data traffic, thereby determining the backbone path.

[0009] In one optional embodiment of this application, the step of mapping the topology data model according to the backbone path includes: creating a top-level data container to describe the entire network scope; creating a device data node for each physical device identified in the network within the top-level data container; creating a port data node for each physical port under each device data node; creating a device link data node between the corresponding source port data node and the destination port data node according to the connection relationship and the backbone path; associating each port data node with its real-time operating status; and encoding all data nodes and their associations according to a predefined structured data modeling language specification to generate the topology data model.

[0010] In one optional embodiment of this application, the network configuration is updated in the following way: the newly generated topology data model is compared with the existing topology model stored locally to identify the configuration items that need to be changed; for the target device to be configured, the following processing is performed: check whether the target device to be configured supports the network configuration protocol; if the target device to be configured supports the network configuration protocol, construct the corresponding configuration data block and send it through the network configuration protocol session; if the target device to be configured does not support the network configuration protocol, check whether it supports the setting operation of the Simple Network Management Protocol; if it supports it, complete the configuration by setting the preset management object instance value in its management information base; if neither the network configuration protocol nor the Simple Network Management Protocol is supported, generate a configuration command sequence that the device can recognize, and execute it by calling the device's local command line interface script or by being triggered by the controller LAN bus message.

[0011] In an optional embodiment of this application, the method further includes: monitoring topology state change events, wherein the topology state change event is at least one of the following: loss of neighbor relationship in Link Layer Discovery Protocol, topology change in Fast Spanning Tree Protocol, or change in network port connection status; when the topology state change event is detected, reconfiguring and issuing the current topology data model.

[0012] In one optional embodiment of this application, the method further includes: visualizing the topology data model to generate a network topology diagram containing device icons, connection lines, and port status indicators; providing a graphical user interface to receive user modifications to the network topology diagram via drag-and-drop and editing; and generating corresponding logical topology change data based on the modification operations to trigger a configuration update process.

[0013] Secondly, embodiments of this application also provide an in-vehicle information processing device, the device comprising: an information acquisition module, used to acquire connection status and neighbor relationship information between devices in an in-vehicle network; a connection relationship determination module, used to determine the connection relationship between devices based on the connection status and neighbor relationship information; a backbone path determination module, used to process the connection relationship using a fast spanning tree protocol to determine the backbone path; a topology data model acquisition module, used to map a topology data model according to the backbone path; and a network configuration update module, used to compare the topology data model with an existing topology model stored locally, and adaptively select a configuration distribution method to update the network configuration based on the comparison result and the protocol support capability of the target device.

[0014] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the method described above are performed.

[0015] This application provides a vehicle information processing method and apparatus. The method includes: acquiring connection status and neighbor relationship information between devices in a vehicle network; determining the connection relationship between devices based on the connection status and neighbor relationship information; processing the connection relationship using a fast spanning tree protocol to determine the backbone path; mapping a topology data model based on the backbone path; comparing the topology data model with an existing topology model stored locally, and adaptively selecting a configuration distribution method to update the network configuration based on the comparison result and the protocol support capabilities of the target device. This application achieves adaptive configuration updates of the vehicle network topology, improving the maintainability and flexibility of the vehicle network.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the vehicle information processing method provided in the embodiments of this application; Figure 2 A flowchart illustrating the determination of the connection relationship between devices provided in this application embodiment; Figure 3 A flowchart for determining the main path provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the mapping process used to obtain the topology data model in an embodiment of this application. Figure 5 This is a schematic diagram of the structure of the vehicle information processing device provided in the embodiments of this application; Figure 6 The present application provides a schematic diagram of the structure of an electronic device. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0020] First, the applicable application scenarios of this application will be introduced. This application can be applied to the field of automotive Ethernet technology.

[0021] Research has revealed that in-vehicle networks are transitioning from static configurations to a stage where they need to flexibly respond to dynamic changes. With the proliferation of in-vehicle sensors and users' independent replacement of equipment (such as cameras and radar), network structures are frequently changing. The traditional static configuration method of fixing connections during the manufacturing stage is no longer suitable, severely restricting the flexibility and maintainability of the network.

[0022] To address this challenge, existing technologies (such as SNMP, LLDP, and PTP) can achieve a certain degree of topology discovery, but they have significant limitations in heterogeneous vehicular environments: they may struggle to achieve full coverage due to high resource requirements and poor compatibility, or their inherent mechanisms may prevent effective propagation among unsupported nodes. More importantly, these methods are often isolated in the "discovery" phase, failing to form a closed loop with topology modeling and configuration updates. They lack real-time response and adaptive capabilities to dynamic changes, and thus cannot meet the core requirements of high reliability and automated operation and maintenance for vehicular networks.

[0023] Based on this, embodiments of this application provide a vehicle information processing method and a vehicle information processing device. Through this application, automatic discovery, real-time modeling and dynamic configuration updates of vehicle network topology are realized, effectively overcoming the rigidity of traditional static configuration methods and improving the network's adaptability, maintainability and operational reliability in scenarios with frequent device changes.

[0024] This application is specifically designed to address the complex, heterogeneous, and dynamically adaptable in-vehicle Ethernet in intelligent vehicles. It primarily solves the core operational challenge of how to achieve automatic identification, plug-and-play functionality, and rapid self-healing of network devices under a domain control architecture. Its goal is to make in-vehicle networks as flexible, automated, and reliable as IT data center networks.

[0025] The Network Configuration Protocol (Netconf) remotely manages network device configurations through standardized interfaces (such as XML / YANG), supports structured data operations, and acts like a "smart remote control," enabling precise control of vehicle domain controllers (such as adjusting camera parameters).

[0026] YANG (YetAnotherNextGeneration) is a data modeling language used to define data models of network device configuration and status (such as device ports and connection relationships). It is usually used in conjunction with Netconf to specify the configuration rules for various devices (such as sensors and ECUs) in the vehicle network.

[0027] The Simple Network Management Protocol (SNMP) queries device status (such as port traffic and error count) through the MIB (Management Information Base), but it depends on device support. It can quickly check the operating status of vehicle switches, but some low-end devices may not support it.

[0028] The Link Layer Discovery Protocol (LLDP) automatically discovers physical connections by broadcasting neighbor device information (such as MAC addresses and port numbers). Like a "megaphone," devices help the network identify its topology by broadcasting their corresponding locations.

[0029] The Address Resolution Protocol (ARP) resolves IP addresses to MAC addresses (e.g., via ARP broadcast) to confirm the online status of devices, much like "looking up a phone book," finding the physical address (MAC) of the corresponding device through the IP address.

[0030] The Internet Control Message Protocol (ICMP) detects network connectivity (such as the Ping command) by sending ICMP Echo requests to confirm whether a device is responding, much like a "knock test" to confirm whether a device is "at home" by sending signals.

[0031] Please see Figure 1 , Figure 1 This is a flowchart illustrating the vehicle information processing method provided in an embodiment of this application. Figure 1 As shown in the figure, the vehicle information processing method provided in this application embodiment includes: S101. Obtain the connection status and neighbor relationship information between devices in the vehicle network.

[0032] This step employs a protocol degradation detection strategy to ensure maximum compatibility.

[0033] Connection status refers to the physical and logical operating status of a device port, such as "on / normal" or "off / faulty".

[0034] Neighbor relationship information refers to the identity and connection information that directly connected devices in a network know about each other, such as "port 1 of device A is connected to port 2 of device B".

[0035] Specifically, the connection status and neighbor relationship information between devices in the vehicular network are obtained through the following methods: Step 1: Obtain the device's link layer discovery protocol neighbor information through the network configuration protocol and its supporting structured data modeling language model interface.

[0036] Preferred method (advanced protocol): First, attempt to establish a connection with the target device using a network configuration protocol, and then directly read the "neighbor table" collected and stored by the device through its accompanying structured data modeling language interface. This table contains the identities and connection port information of neighboring devices directly connected to the target device.

[0037] Here, the Netconf / YANG configuration probe submodule in the network information acquisition module will first attempt to establish a network configuration protocol session with devices in the network (such as high-end switches and domain controllers).

[0038] After the connection is established, the data model defined by the structured data modeling language on the device is queried through this protocol interface. This accesses the nodes representing the link layer discovery protocol function within the model, and the device returns the information stored in its link layer discovery protocol neighbor table through this interface. This table contains detailed information about its directly connected neighbor devices, providing a clearly structured list including device identifiers, local ports, neighbor device identifiers, and neighbor ports.

[0039] The Network Configuration Protocol (NIC) is an XML-based network management protocol that provides a standard mechanism for remotely configuring and managing network devices. It supports the creation, retrieval, updating, and deletion of configuration data, making it well-suited for structured and automated operations.

[0040] Structured Data Modeling Language (SDM) is a language used to model configuration and status data for network devices. It defines the structure, constraints, and relationships of the data, enabling it to be understood and processed programmatically. It is typically used in conjunction with network configuration protocols as a "data contract" or "schema definition" for communication between the two.

[0041] Link-layer discovery protocol neighbor information refers to the information collected by network devices by periodically sending broadcast messages to directly connected links, revealing information about neighboring devices. This information typically includes: the local port number, the neighboring device's MAC address, the neighboring device's port number, and the neighboring device's system name. This is the most direct and accurate source of information for discovering the physical topology.

[0042] Step 2: If the target device does not respond to the network configuration protocol request, then the Simple Network Management Protocol is used instead, and the basic identifier and port information of the device are obtained by querying the object identifier in its management information base.

[0043] Secondary option (intermediate protocol): If the target device does not respond or does not support the network configuration protocol, the simple network management protocol is used as a fallback. Basic device identifiers (such as system name and description) and port information (such as interface index, description, and type) are obtained by querying the device's management information database.

[0044] If the target device (such as some mid-range switches or devices that do not support the network configuration protocol) does not respond or returns an error in step one, the SNMP configuration probe submodule determines that it does not support the network configuration protocol.

[0045] The system then downgraded and sent a query request to the device using the Simple Network Management Protocol (SMLP).

[0046] This query request is issued for a specific object identifier in the device management information database. These OIDs correspond to variables storing device system information (such as system name, device description) and interface information (such as interface index, interface description, interface type). The device returns the value corresponding to the queried OID, thereby obtaining the device's basic identifier and port list.

[0047] Here, Simple Network Management Protocol (SMLP) is a protocol widely used for managing IP network devices. It primarily monitors and manages network devices through a "query-response" mechanism.

[0048] The Management Information Base (MIB) is a virtual database that contains all objects that can be managed by the Simple Network Management Protocol (SMLP). Each object is identified by a unique object identifier.

[0049] Degradation refers to automatically switching to a more general and widely supported alternative method when the preferred advanced method fails or becomes unavailable. This is a key design feature that enables high compatibility in this solution.

[0050] Step 3: If the target device does not respond to the Simple Network Management Protocol (SMMP) request, the process is downgraded to the network layer or link layer. The binding relationship between the Internet Protocol address and the Media Access Control (MAC) address is obtained by sending an Address Resolution Protocol (IPC) broadcast request, or the online status of the device is detected by sending an Internet Control Message Protocol (ICP) echo request message.

[0051] Basic approach (lower-level protocol): If the target device also does not support Simple Network Management Protocol (SMMP), the approach is further downgraded to the network or link layer. This involves sending Address Resolution Protocol (ARP) broadcast requests to obtain the IP address and MAC address binding relationship; or sending Internet Control Message Protocol (ICP) echo requests (i.e., Ping) to detect the device's online status based on whether a response is received.

[0052] Furthermore, if the target device (such as a resource-constrained microcontroller unit or a very simple switch) does not respond in step two, the ARP / ICMP probe submodule determines that it also does not support the Simple Network Management Protocol and further downgrades to the most basic network layer and link layer protocols.

[0053] Method A (Address Resolution Protocol): A broadcast packet of Address Resolution Protocol (ARP) is sent within the local network segment. Devices with the IP address will reply with their MAC address. This method establishes a mapping between IP addresses and MAC addresses.

[0054] Method B (Internet Control Message Protocol): Sends an ICMPEcho request (i.e., Ping) to the target device's IP address. If the device is online and the network is connected, it will reply with an ICMPEcho response. This is mainly used to confirm whether the device is "alive" and online.

[0055] Address Resolution Protocol (ARP) is a network protocol used to look up the MAC address of a device based on its IP address.

[0056] The Internet Control Message Protocol Echo Request message, commonly known as the message used by the "Ping" command, is used to test the reachability of network connectivity.

[0057] An Internet Protocol (IP) address is a device's network layer logical address, used to locate the device within a network.

[0058] The Media Access Control address is the physical address of the device's network interface card (NIC), and it is a globally unique identifier.

[0059] Finally, step four: Based on the information successfully obtained in any step, parse and determine the connection status and neighbor relationships between devices.

[0060] The original information successfully obtained from any of the above steps will be parsed.

[0061] If the LLDP neighbor information is obtained from step one, the connection relationship can be determined directly and accurately ("Port 1 of device A is connected to port 2 of device B").

[0062] If the information is obtained from step two or three, it needs to be combined with other information for inference. For example, by discovering the IP and MAC binding of device B through ARP, confirming its online status through ICMP, and combining this with the MAC address forwarding table found on the switch (showing that device B's MAC address was learned from a certain port), the connection relationship between the switch and device B can be inferred.

[0063] The final output is a system-understandable description of how the devices are connected.

[0064] Connection status refers to the current state of the network connection, such as "connected / enabled" or "not connected / disabled".

[0065] S102. Determine the connection relationship between devices based on connection status and neighbor relationship information.

[0066] Specifically, please refer to Figure 2 , Figure 2 The flowchart provided in this application for determining the connection relationship between devices determines the connection relationship between devices in the following manner: S201, Integrate information from different protocol sources.

[0067] The information includes the neighbor table obtained through the link layer discovery protocol, the address resolution protocol cache table, the Internet Control Message Protocol response data, and the interface index and media access control address forwarding table information obtained through the Simple Network Management Protocol.

[0068] This step is performed by the device adjacency identification mechanism in the topology reasoning and modeling module. It aggregates data of varying formats obtained from different protocols in S101 into a unified processing platform. This data includes: Link Layer Discovery Protocol (LLDP) Neighbor Table: Obtained from high-end devices that support LLDP (such as switches and domain controllers). This is the most authoritative direct connection information, explicitly recording "port X of this device is connected to port Z of neighbor device Y".

[0069] Address Resolution Protocol (ARP) cache table: obtained from the device or by listening to ARP responses on the network. It provides a mapping between IP addresses and MAC addresses.

[0070] Internet Control Message Protocol (ICP) response data: obtained through Ping scanning, it simply records which IP addresses are online and which have responded.

[0071] The interface index and Media Access Control (MAC) address forwarding table information obtained from the Simple Network Management Protocol (SNMP) are retrieved from the switch that supports SNMP. The MAC address forwarding table is particularly critical, as it records the MAC addresses of the end devices learned by the switch from each port, implying that "the device connected to switch port n has a MAC address of m".

[0072] S202. Perform cross-validation using information from different protocol sources to obtain cross-validation results.

[0073] The specific method is as follows: Verifying the authenticity of LLDP information: For example, an LLDP announcement states that device A's port 1 is connected to device B. The system can check device B's ARP table or IP address to see if it matches the device identifier in the LLDP information.

[0074] Supplementing and verifying with the MAC address forwarding table: For terminal devices that do not support LLDP (such as cameras), the system found that the MAC address of camera C was learned in the MAC address forwarding table of switch port 3. This indicates that camera C is likely connected to port 3. The system can further verify the IP address and online status of camera C via ARP or ICMP to confirm this connection.

[0075] Discovering hidden connections: If LLDP information is interrupted somewhere (for example, by a simple switch that does not support LLDP), the system can infer the existence and approximate location of the simple switch by analyzing changes in the MAC address forwarding tables of upstream and downstream switches.

[0076] False information filtering: Eliminate invalid information caused by configuration errors or network transients.

[0077] S203. Based on the cross-validation results, construct the connection relationships between devices.

[0078] The connections confirmed through cross-validation (such as "Port 1 of Switch A - Port 2 of Switch B", "Port 3 of Switch A - Camera C") are combined to form a diagram describing the physical interconnection of all devices.

[0079] In the graph, different roles such as domain controllers, switches, and sensors are identified based on device type (obtained from SNMP or LLDP information); ultimately, this set of connections will be transformed into structured data to prepare for subsequent mapping into a topology data model.

[0080] S103. Use the Fast Spanning Tree Protocol to process connection relationships and determine the main path.

[0081] Specifically, please refer to Figure 3 , Figure 3 The flowchart for determining the trunk path provided in this application embodiment determines the trunk path in the following manner: S301. Select a bridge based on bridge priority and media access control address.

[0082] All RSTP-enabled switches (also known as "bridges") in a network periodically communicate with each other using a special multicast message called a Bridge Protocol Data Unit (BPDU). Each BPDU contains the sender's bridge ID.

[0083] The bridge ID consists of two parts: a configurable bridge priority (a 16-bit value, defaulting to 32768) and the switch's media access control address (MAC address, globally unique).

[0084] All switches elect a root bridge by comparing the bridge IDs in the received BPDUs. The rule is: the switch with the smallest bridge ID becomes the root bridge. During the comparison, the bridge priority is compared first, with a smaller value being better; if the bridge priorities are the same, the MAC addresses are compared, with a smaller MAC address being better.

[0085] After a period of BPDU exchange, all switches in the network will reach a consensus on "who is the root bridge". The root bridge will become the logical center (root) of the entire spanning tree topology.

[0086] Here, in the Spanning Tree Protocol (STP), the root bridge is the switch or bridge elected as the logical root of the network tree. It is the convergence point of network traffic, and the path of all data is calculated around it.

[0087] Bridge priority is a manually configurable value that influences the root bridge election outcome. Administrators can ensure that a core switch is elected as the root bridge by setting its priority to a lower value.

[0088] The Media Access Control (MAC) address is the physical address of each network device's network interface card (NIC), and it is a globally unique identifier. In the case of bridges with the same priority, it is used to determine a unique root bridge.

[0089] S302. For each physical network segment, select the port with the lowest path cost from the root bridge as the designated port to forward data to that physical network segment.

[0090] Non-root bridge switches need to calculate their "distance" to the root bridge, which is measured by path cost. Path cost is a cumulative value determined based on factors such as port speed; the higher the speed, the lower the cost.

[0091] Port election: For each physical network segment (i.e., the two ends of a link), all switches (or bridges) connected to that segment compare their path costs to the root bridge.

[0092] The device with the lowest path cost to the root bridge will have its port connected to that network segment designated as the designated port. If the path costs are the same, the sender's bridge ID is compared, and the one with the smaller bridge ID wins. There is one and only one designated port on each physical network segment. The designated port is responsible for forwarding data traffic destined for the root bridge to that network segment and handling traffic from that network segment destined for the root bridge. It is a port in a forwarding state.

[0093] S303. On each non-root bridge, select the port with the lowest path cost to the root bridge as the root port, and set the ports corresponding to the remaining redundant links to a blocked state so that they only process protocol messages and do not forward user data traffic, in order to determine the backbone path.

[0094] On each non-root bridge (i.e., a switch that is not the root bridge), it compares all ports that can receive BPDUs and calculates the path cost to the root bridge through each port.

[0095] The port with the lowest path cost to the root bridge will be elected as the root port of that non-root bridge. Each non-root bridge has one and only one root port. The root port is the "best path" from the switch to the root bridge.

[0096] RSTP will block all other ports on a non-root bridge that are neither the root port nor the designated port.

[0097] A port in a blocked state only receives and processes protocol messages such as BPDUs, but does not forward any user data traffic. This is like logically "placing a roadblock" on a loop, completely blocking the possibility of data packets circulating in the loop.

[0098] Here, through distributed computation in these three steps, the RSTP protocol successfully constructs a loop-free logical tree within the physical loop, with the root bridge as the root and the root port and designated ports as branches. This "tree" is the backbone path. It directly implements loop avoidance in physical links and backbone path selection, providing a stable, loop-free network foundation for upper-layer vehicular applications, and is a key technology for ensuring the high reliability of vehicular networks.

[0099] S104. Based on the main path, map to obtain the topology data model.

[0100] The topology data model includes at least the following core datasets defined based on the YANG data modeling language specification: The node-list is used to provide a structured description of all device entities discovered in the network. Each node element contains attribute information that uniquely identifies the device. The link-list is used to provide a structured description of the physical or logical connection relationships between the device entities in the node list. Each link element explicitly specifies the source node, destination node, and corresponding port it connects to. The port state (port-state) is associated with a specific device port in the node list and is used to describe the real-time operating status of each port.

[0101] The topology data model integrates the aforementioned datasets to form a complete structured representation of the network topology. In practical applications, it can be further expanded to include other network parameters obtainable through protocol probing, but the node list, link list, and port status constitute the minimum complete dataset for the aforementioned model.

[0102] Specifically, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the mapping to obtain the topology data model provided in the embodiments of this application.

[0103] S401. Create a top-level data container to describe the entire network scope.

[0104] First, a root data object is instantiated. This object corresponds to the / networks / network node in the YANG model. During creation, a unique identifier (e.g., network-id) is assigned to it to distinguish different in-vehicle network domains (such as "Intelligent Driving Domain Network" and "Cockpit Domain Network").

[0105] In a data model, the top-level data container refers to the highest-level structure or root object representing the entire entity. In this case, it represents the entire managed vehicular Ethernet domain.

[0106] Network scope refers to the entire vehicular network boundary that this topology discovery targets.

[0107] S402. In the top-level data container, create a device data node for each physical device identified in the network.

[0108] Iterate through all discovered physical devices (such as domain controllers, switches, cameras, and radar), and create a child node for each device under the top-level network node created by S401. This child node corresponds to / networks / network / node in the YANG model. Each device data node contains a unique identifier (node-id) and attributes obtained from the collected information, such as device type and management IP address.

[0109] A device data node is an object in the data model used to represent an independent network device.

[0110] Physical devices are the actual hardware entities in a network.

[0111] S403. Under each device data node, create a port data node for its physical port.

[0112] Here, for each device data node created in S402, the system further iterates through all physical network ports on that device (such as Eth0, Eth1), creating a child node for each port. This child node corresponds to / networks / network / node / termination-point in the YANG model. Each port data node contains a unique identifier for the port (tp-id), such as the port name or index.

[0113] S404. Based on the connection relationship and the backbone path, create a device link data node between the corresponding source port data node and the destination port data node.

[0114] Based on the connection relationships determined in S102 and the backbone path status determined by the RSTP protocol in S103, connections are created in the data model.

[0115] For each pair of connected device ports, the system creates a link data node under the top-level network node (corresponding to / networks / network / link in the YANG model).

[0116] Within this link node, the source device node, source port node, destination device node, and destination port node can be precisely specified using attributes such as source and destination.

[0117] At the same time, it can record whether the link is in a forwarding state (i.e., belongs to the backbone path) or blocked after RSTP calculation.

[0118] The backbone path is a logical path that is actively forwarding, calculated by the RSTP protocol.

[0119] S405. Associate each port data node with its real-time operating status.

[0120] Here, each port data node created in S403 is associated with its dynamic status information. This status information (such as oper-status) is obtained in real time from the device via SNMP or Netconf, and includes: Operation status: up (on / normal) or down (off / malfunction).

[0121] Management status: up (enabled by administrator) or down (disabled by administrator).

[0122] These status data exist as child nodes or attributes of port data nodes.

[0123] S406. Encode all data nodes and their relationships according to the predefined structured data modeling language specifications to generate a topological data model.

[0124] The system serializes (encodes) the hierarchical data node tree built in memory by S401 to S405 into a specific data format file (such as XML or JSON) according to the syntax rules defined by the Structured Data Modeling Language (YANG model). This file is the final machine-readable topology data model. It can be saved to the local configuration library or sent directly to the network management system or SDN controller via the Netconf protocol.

[0125] The steps described above organize the specific and disorganized network physical information into a highly structured and standardized data model. The significance of this model lies in the fact that it transforms topology information from scattered, unstructured logs or configuration fragments into a unified "source of facts" that can be automatically parsed and processed by programs. This provides the absolute prerequisite and possibility for automated difference comparison and configuration distribution in S105, and is the core pillar for achieving automation of the entire solution.

[0126] S105. Compare the topology data model with the existing topology model stored locally, and adaptively select the configuration distribution method to update the network configuration based on the comparison results and the protocol support capabilities of the target device.

[0127] Specifically, update the network configuration in the following ways: The newly generated topology data model is compared with the existing topology model stored locally to identify the configuration items that need to be changed.

[0128] Here, the local configuration library is pre-built to maintain the current valid topology model; it supports structured storage of topology data in YANG model format, which facilitates flexible subsequent calls and difference comparisons; when the topology changes, the incremental configuration update process is triggered by comparing model differences.

[0129] Load the previously successfully generated and stored topology data model (old model) from the local configuration library, and load it into memory along with the newly generated topology data model (new model).

[0130] Model comparison: The system recursively traverses and compares the two models item by item. This is not just a simple file comparison, but a comparison of the addition, deletion, and modification of nodes and attributes based on the tree structure of the data model.

[0131] After comparison, the system will generate a structured difference report, clearly listing: New additions: newly added device nodes, port nodes, and link nodes.

[0132] Deleted items: Nodes that existed in the old model but have disappeared in the new model.

[0133] Modifications: Nodes whose status has changed, such as a port changing from up to down.

[0134] For the target device that needs to be configured, the following processing should be performed: Check whether the target device to be configured supports the network configuration protocol; if the target device to be configured supports the network configuration protocol, construct the corresponding configuration data block and send it through the network configuration protocol session.

[0135] Here, the first step is to check whether the target device has the Netconf service port (usually TCP port 830) open, and attempt to exchange protocol capabilities. If the device responds and indicates support for the required YANG model, it is determined to be supported; based on the difference report, configuration data conforming to the YANG model specification supported by the device is generated, which is usually encoded in XML format.

[0136] Distribution via Network Configuration Protocol (NCP) session: Establish a secure Netconf session and use the `` operation to precisely distribute configuration data blocks to the target device. This is the most ideal and structured configuration method.

[0137] If the target device to be configured does not support the network configuration protocol, check whether it supports the Simple Network Management Protocol (SMMP) settings; if it does, complete the configuration by setting the preset management object instance value in its management information base.

[0138] If the Netconf connection fails, the system checks whether the target device supports the SNMP "Set" operation (i.e., write operation).

[0139] This transforms configuration changes into settings for specific Management Information Base (MIB) object instance values.

[0140] If neither the network configuration protocol nor the simple network management protocol is supported, a sequence of configuration commands that the device can recognize is generated and executed by calling the device's local command-line interface script or by being triggered by a controller LAN bus message.

[0141] For lightweight devices with extremely limited resources that do not support any standard network management protocols (such as some microcontroller units or minimal switches), the last resort is to use local script calls or pre-made templates for distribution: For lightweight devices that do not support Netconf / SNMP (such as some MCU nodes or low-configuration switches), the preset configuration template is executed through CAN trigger, Shell script or REST interface.

[0142] Based on a predefined template, generate a sequence of command-line configuration commands that the device's operating system can recognize.

[0143] Distribution Method A (Script Invocation): Log in to the device via SSH or Telnet and automatically execute these commands one by one.

[0144] Method B (Bus Triggered): This is a method unique to in-vehicle networks. For devices that cannot be remotely logged into, the configuration command sequence is encapsulated into a specific Controller Area Network (CLAN) message and sent to the bus. The device listens to the bus, and upon receiving the configuration message, executes the corresponding configuration script locally. This achieves indirect configuration of the lowest-level devices.

[0145] This application can operate collaboratively through multiple standard protocols, and achieve the following objectives while being compatible with the capabilities of different devices: integrate multiple network protocols such as Netconf / YANG, SNMP, LLDP, ARP, and ICMP to achieve multi-source information collection; utilize the RSTP protocol to achieve loop avoidance and backbone path selection in physical links; realize graphical modeling and visualization of topology structure; and realize dynamic response, adaptive reconstruction, and configuration update of topology changes.

[0146] In an optional embodiment of this application, the method further includes: monitoring topology status change events, wherein the topology status change event is at least one of the following: loss of neighbor relationship in the link layer discovery protocol, topology change in the fast spanning tree protocol, or change in network port connection status; when a topology status change event is detected, the current topology data model is re-configured and distributed.

[0147] Here, the monitoring link layer detects lost neighbor relationships: it periodically checks the LLDP neighbor table obtained from the device via Netconf or SNMP. If a previously existing neighbor entry is found to have disappeared (i.e., "aged" and not updated), or if a message indicating a change in neighbor relationship is received as defined in the LLDP protocol's "TLV", the trigger scenarios are: the physical network cable is unplugged, the adjacent device is powered off or restarted, or the port is disabled by the administrator.

[0148] Monitoring Rapid Spanning Tree Protocol (RSTP) topology changes: Listen to Bridge Protocol Data Units (BPDUs) in the network, or directly query the switch's RSTPMIB library. When changes are detected in key information such as the root bridge ID and path cost transmitted in the BPDU, or when the RSTP status of a port changes (e.g., from blocking to forwarding), this can be detected. Triggering scenarios include: a root bridge switchover in the network, or a failure of a backbone link causing RSTP to be recalculated and a backup path activated.

[0149] Monitor network port connection status changes: Periodically query the ifOperStatus (operation status) management information base object of the device port via SNMP or Netconf. When the status changes from up(1) to down(2) or vice versa, it can be detected, triggering scenarios: physical link interruption of the port, device failure, port being remotely enabled / disabled.

[0150] Once the monitoring module detects any change event that meets the criteria, it will immediately send an interrupt or message notification to the system's core processing unit.

[0151] Upon receiving the notification, the entire process from S101 (information collection) to S105 (configuration distribution) is automatically and immediately restarted; the latest connection status of the entire network is immediately obtained again through multi-protocol fusion; based on the new information, the connection relationships and RSTP backbone paths are recalculated; and a new topology data model is constructed.

[0152] The new model is compared with the old model stored before the event occurred to identify the points of change, and the necessary configuration updates are adaptively distributed to the affected target devices.

[0153] In an optional embodiment of this application, the method further includes: visualizing the topology data model to generate a network topology diagram that includes device icons, connection lines, and port status indicators.

[0154] The graphical engine reads the machine-readable topology data model file (typically XML or JSON data based on the YANG model) generated by step S104; the engine then converts the elements in the data model into visual elements according to predefined mapping rules. Device data nodes are rendered as corresponding device icons (e.g., different icons are used to represent switches, cameras, and domain controllers).

[0155] Device link data nodes are rendered as connecting lines between device icons.

[0156] Port status information is converted into visual cues, such as port status indicators (e.g., green dots indicate port up, red dots indicate port down; bold lines indicate that the link is an RSTP backbone path, and dashed lines indicate that the port is blocked).

[0157] Finally, a network topology diagram that intuitively reflects the current state of the network in real time is drawn on the user interface.

[0158] It provides a graphical user interface to receive user modifications to the network topology diagram via drag-and-drop and editing; based on the modifications, it generates corresponding logical topology change data and triggers the configuration update process.

[0159] In addition to displaying the network topology diagram, an interactive graphical user interface is provided. This interface supports standard user interaction operations. Network administrators can perform the following operations using the mouse: Drag and drop: Directly drag and drop device icons to change their layout in the logical view (this usually does not change the physical connection, but optimizes the convenience of visual management).

[0160] Edit: Perform more in-depth editing operations. For example, right-click a connection and select "Disable" to logically disconnect the link; or right-click a device and select "Configure" to modify its IP address and other parameters. More advanced editing may include: logically defining a new traffic path, even if a physical loop exists.

[0161] Once the user completes the editing and confirms, the graphical engine does not directly operate the device. Instead, it translates the user's graphical actions into a set of structured logical topology change data. This data describes "what the user wants the network to look like."

[0162] Use this set of changed data as the "target model" and the current topology data model as the "source model", and then trigger the same configuration update process as S105.

[0163] Perform a difference comparison to calculate the configuration changes required to move from the current state to the user's desired state. Also, based on the device's protocol support capabilities, adaptively select Netconf, SNMP, or script methods to distribute these configuration changes to the corresponding network devices.

[0164] This application breaks the reliance on a single protocol and ensures maximum device coverage through a protocol degradation mechanism; it automatically identifies and updates topology changes in real time, supporting graphical display; it uses the YANG data model for structured topology description and distributes it through Netconf, integrating structured modeling and configuration distribution; it introduces RSTP to avoid loops and dynamically maintain the smooth operation of the backbone link; it is designed specifically for vehicle domain networks and is compatible with the communication capability limitations of lightweight MCUs and low-configuration switches.

[0165] The vehicle information processing method and device provided in this application adaptively acquire connection information of heterogeneous devices by employing a protocol degradation detection strategy (sequentially trying Netconf, SNMP, and ARP / ICMP), and cross-verifies multiple information sources such as LLDP and SNMP to intelligently infer the complete physical connection relationship. Then, the RSTP protocol is used to automatically eliminate network loops and determine loop-free backbone paths, ultimately mapping the topology to a standardized YANG data model. This application can monitor network status changes in real time, and by comparing topology model differences and adaptively selecting the configuration distribution method (Netconf, SNMP, or script) based on device capabilities, it achieves full automation of the vehicle network from topology discovery and modeling to configuration updates, significantly improving network reliability, self-healing capability, and operational efficiency in scenarios with frequent device changes.

[0166] Based on the same inventive concept, this application also provides an in-vehicle information processing device corresponding to the in-vehicle information processing method. Since the principle of the device in this application is similar to that of the in-vehicle information processing method described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0167] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the vehicle information processing device provided in an embodiment of this application. Figure 5 As shown, the in-vehicle information processing device 500 includes: The information acquisition module 501 is used to acquire the connection status and neighbor relationship information between various devices in the vehicle network; The connection relationship determination module 502 is used to determine the connection relationship between devices based on the connection status and neighbor relationship information; The trunk path determination module 503 is used to process the connection relationship using the fast spanning tree protocol to determine the trunk path. The topology data model acquisition module 504 is used to map and obtain the topology data model based on the trunk path; The network configuration update module 505 is used to compare the topology data model with the existing topology model stored locally, and adaptively select the configuration distribution method to update the network configuration based on the comparison results and the protocol support capabilities of the target device.

[0168] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 300 includes a processor 310, a memory 320, and a bus 330.

[0169] Memory 320 stores machine-readable instructions executable by processor 310. When electronic device 300 is running, processor 310 and memory 320 communicate via bus 330. When the machine-readable instructions are executed by processor 310, they can perform the operations described above. Figure 1 The steps of the vehicle information processing method in the illustrated method embodiment can be found in the method embodiment for specific implementation methods, which will not be repeated here.

[0170] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0172] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0174] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0175] Finally, it should be noted that the above embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the technical scope disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A vehicle information processing method, characterized in that, include: Obtain connection status and neighbor relationship information between devices in the vehicle network; Based on the connection status and neighbor relationship information, the connection relationship between devices is determined; The connection relationships are processed using the Rapid Spanning Tree Protocol (RSP) to determine the main path; Based on the main path, a topology data model is obtained through mapping; The topology data model is compared with the existing topology model stored locally, and the configuration distribution method is adaptively selected to update the network configuration based on the comparison results and the protocol support capabilities of the target device.

2. The method according to claim 1, characterized in that, The connection status and neighbor relationship information between devices in the vehicular network can be obtained through the following methods: The link layer discovery protocol neighbor information of the device is obtained through the network configuration protocol and its supporting structured data modeling language model interface; If the target device does not respond to the network configuration protocol request, the Simple Network Management Protocol is used in a fallback manner, and the basic identifier and port information of the device are obtained by querying the object identifier in its management information base. If the target device does not respond to the Simple Network Management Protocol request, the process is downgraded to the network layer or link layer. The binding relationship between the Internet Protocol address and the Media Access Control address is obtained by sending an Address Resolution Protocol Broadcast Request, or the online status of the device is detected by sending an Internet Control Message Protocol Echo Request message. Based on the information successfully obtained in any step, the connection status and neighbor relationships between devices are parsed and determined.

3. The method according to claim 2, characterized in that, The connection relationships between devices are determined in the following ways: Integrate information from different protocol sources, including the link layer discovery protocol neighbor table, the address resolution protocol cache table, Internet Control Message Protocol response data, and the interface index and media access control address forwarding table information queried through Simple Network Management Protocol; Cross-validation is performed using information from different protocol sources to obtain cross-validation results; Based on the cross-validation results, the connection relationships between devices are constructed.

4. The method according to claim 1, characterized in that, The main path is determined in the following manner: A bridge is selected based on bridge priority and media access control address; For each physical network segment, select the port with the lowest path cost from the root bridge as the designated port to forward data to that physical network segment; On each non-root bridge, select the port with the lowest path cost to the root bridge as the root port, and set the ports corresponding to the remaining redundant links to a blocked state so that they only process protocol messages and do not forward user data traffic, in order to determine the backbone path.

5. The method according to claim 1, characterized in that, The process of mapping the topology data model based on the main path includes: Create a top-level data container to describe the entire network scope; In the top-level data container, a device data node is created for each physical device identified in the network; Under each device data node, create a port data node for its physical port; Based on the connection relationship and the backbone path, a device link data node is created between the corresponding source port data node and the destination port data node; Associate each port data node with its real-time operational status; All data nodes and their relationships are encoded according to a predefined structured data modeling language specification to generate the topological data model.

6. The method according to claim 2, characterized in that, Update network configuration using the following methods: The newly generated topology data model is compared with the existing topology model stored locally to identify the configuration items that need to be changed. For the target device that needs to be configured, the following processing should be performed: Check whether the target device to be configured supports the network configuration protocol; If the target device to be configured supports the network configuration protocol, then construct the corresponding configuration data block and send it through the network configuration protocol session; If the target device to be configured does not support the network configuration protocol, then check whether it supports the Simple Network Management Protocol (SMMP) setting operation; If supported, the configuration is completed by setting the preset management object instance value in its management information base; If neither the network configuration protocol nor the simple network management protocol is supported, a sequence of configuration commands that the device can recognize is generated and executed by calling the device's local command-line interface script or by being triggered by a controller LAN bus message.

7. The method according to claim 1, characterized in that, The method further includes: Monitor topology status change events, wherein the topology status change event is at least one of the following: loss of neighbor relationship in the link layer discovery protocol, topology change in the fast spanning tree protocol, or change in network port connection status; When the topology state change event is detected, the current topology data model is re-configured and distributed.

8. The method according to claim 1, characterized in that, The method further includes: The topology data model is visualized to generate a network topology diagram that includes device icons, connection lines, and port status indicators; It provides a graphical user interface that allows users to modify the network topology diagram by dragging and editing. Based on the modification operation, corresponding logical topology change data is generated, triggering the configuration update process.

9. A vehicle-mounted information processing device, characterized in that, include: The information acquisition module is used to acquire the connection status and neighbor relationship information between various devices in the vehicle network; The connection relationship determination module is used to determine the connection relationship between devices based on the connection status and neighbor relationship information; The trunk path determination module is used to process the connection relationship using the fast spanning tree protocol to determine the trunk path. The topology data model acquisition module is used to map and obtain the topology data model based on the trunk path; The network configuration update module is used to compare the topology data model with the existing topology model stored locally, and adaptively select the configuration distribution method to update the network configuration based on the comparison results and the protocol support capabilities of the target device.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1 to 8.

Images