Communication method of vehicle, vehicle and storage medium

Abstract

The invention provides a communication method of a vehicle, the vehicle and a storage medium, the method relates to the field of vehicle-mounted communication, and the method comprises the following steps: receiving a first message sent by a master node in a vehicle-mounted network, the first message comprising an enabling flag bit and a fixed identifier of a slave node, the enabling flag bit is used for indicating whether a slave node in the vehicle-mounted network distributes a virtual identifier or not; obtaining a target virtual identifier of the slave node based on the fixed identifier under the condition that the enabling flag bit indicates the slave node to allocate the virtual identifier; obtaining first sending time corresponding to the target virtual identifier based on the target virtual identifier; the vehicle communication data at the slave node is transmitted upon arrival of the first transmission time. The method enables communication when a device in an in-vehicle network changes.

Description

Technical Field

[0001] This application relates to the field of vehicle communication, and more specifically, to a vehicle communication method, vehicle, and storage medium in the field of vehicle communication. Background Technology

[0002] With the rapid development of automotive control technology, in-vehicle networks need to connect an increasing number of sensors and control units. In existing technologies, to simplify wiring layout and reduce costs, multiple devices can share a single cable for communication. However, for this type of network, the identity information and communication sequence of each device need to be pre-defined, and communication must proceed according to this predetermined order. This results in the need to modify device software settings when adding or removing devices from the existing network, and also wastes reserved communication bandwidth, leading to low flexibility in in-vehicle networks.

[0003] Therefore, how to communicate when devices in the vehicle network change is a problem that urgently needs to be solved. Summary of the Invention

[0004] This application provides a vehicle communication method, a vehicle, and a storage medium, which enables communication when devices in an in-vehicle network change.

[0005] Firstly, a vehicle communication method is provided, which is applied to a slave node in the vehicle, and the method includes: Receive the first message sent by the master node in the vehicle network. The first message includes an enable flag and a fixed identifier of the slave node. The enable flag is used to indicate whether the slave node in the vehicle network is assigned a virtual identifier. When the enable flag indicates that a virtual identifier is allocated to the slave node, the target virtual identifier of the slave node is obtained based on the fixed identifier; Based on the target virtual identifier, the first transmission time corresponding to the target virtual identifier is obtained; Upon reaching the first transmission time, vehicle communication data is transmitted from the node.

[0006] In the embodiments of this application, the slave node receives a first message sent by the master node. Since the first message includes an enable flag for whether to allocate a virtual identifier, the slave node can determine whether virtual identifier allocation is currently required through this enable flag. When the enable flag indicates virtual identifier allocation, the slave node obtains its target virtual identifier based on its own inherent fixed identifier (e.g., real identifier). When the number of slave nodes changes, each slave node can allocate a virtual identifier through the first message, thereby enabling dynamic transmission time determination through dynamically allocated virtual identifiers when the number of slave nodes in the vehicular network changes. Since the transmission time in this scheme is dynamically obtained based on virtual identifiers, it avoids the problem of idle communication resources caused by master node software modification and waiting for communication time of removed nodes in the prior art, thereby improving communication efficiency.

[0007] In conjunction with the first aspect, in some possible implementations, the target virtual identifier of the slave node is obtained based on a fixed identifier, including: Based on a fixed identifier, the response time corresponding to the slave node is obtained; Based on the response time, the target virtual identifier is obtained.

[0008] In the embodiments of this application, the response time is determined based on a fixed identifier, thereby obtaining the target virtual identifier. Compared to existing technologies that cannot adaptively adjust the communication process when devices change in the vehicular network, leading to the need to modify the software in the master node or resulting in idle communication time during the communication process, thus reducing communication efficiency, this solution determines the response time of the slave node based on the fixed identifier and then obtains the target virtual identifier corresponding to the slave node based on the response time. This enables the slave node to automatically complete the configuration of the vehicular network based solely on its own fixed identifier and predetermined rules when devices change in the vehicular network, without needing to modify the software in the master node or waiting for the communication time of the removed node during the communication process. This simplifies the communication configuration process and improves communication efficiency.

[0009] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target virtual identifier is obtained based on the response time, including: Upon reaching the response time, check if an assigned virtual identifier exists; If an assigned virtual identifier already exists, determine the target virtual identifier based on the assigned virtual identifier; If no assigned virtual identifier exists, the preset virtual identifier will be used as the target virtual identifier.

[0010] In the embodiments of this application, upon reaching the response time of the slave node, it is detected whether an assigned virtual identifier exists, and the target virtual identifier corresponding to the slave node is determined based on whether an assigned virtual identifier exists. If no assigned virtual identifier exists, a preset virtual identifier is determined as the target virtual identifier, for example, 1 can be determined as the target virtual identifier. If an assigned virtual identifier exists, the target virtual identifier is determined based on the assigned virtual identifier. Compared to the prior art, which cannot adaptively adjust the communication process when devices change in the vehicular network, resulting in the need to modify the software in the master node or resulting in idle communication time during the communication process, reducing communication efficiency, this solution can assign a corresponding virtual identifier to each slave node based on whether an assigned virtual identifier exists. Since assigning a corresponding virtual identifier to each slave node can ensure normal communication of each slave node in subsequent communication processes, avoiding modification of the master node's software, and since each slave node is a node that can communicate normally in the vehicular communication network, it can avoid the communication time waiting for deleted nodes in subsequent communication processes. This solution can adaptively perform communication when devices change in the vehicular network, simplifying the communication configuration process and improving communication efficiency.

[0011] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the communication method also includes: After obtaining the target virtual identifier based on the fixed identifier, a second message is sent to the master node, which includes the target virtual identifier of the slave node.

[0012] In the embodiments of this application, after obtaining the target virtual identifier based on the fixed identifier, a second message containing the target virtual identifier is sent to the master node. This message is used to send the target virtual identifiers corresponding to each slave node to the master node, enabling the master node to obtain the configuration status of the slave nodes in the vehicle network without modifying the software. Therefore, this solution can adaptively communicate when the device in the vehicle network changes, simplifying the communication configuration process and improving communication efficiency. Furthermore, since the slave nodes send the target virtual identifier information to the master node, the master node can ensure normal communication based on the number of slave nodes in the vehicle network during subsequent communication processes, without waiting for the communication time of the deleted nodes, thus improving communication efficiency.

[0013] Secondly, a vehicle communication method is provided, which is applied to a master node in the vehicle, and the method includes: After detecting that the vehicle is powered on, a first message is sent to the slave node. The first message is used to instruct the slave node in the vehicle network to allocate a virtual identifier. The first message includes the fixed identifier of the slave node. Receive a second message sent by the slave node, the second message including the virtual identifier of the slave node; Based on the second message, determine the second sending time; When the second transmission time arrives, the vehicle communication data of the master node is sent.

[0014] In the embodiments of this application, after power-on, the master node sends a first message to trigger virtual identifier allocation and receives a second message reported by the slave node to obtain its allocated virtual identifier, thereby determining its own second transmission time. Compared with the prior art, where the master node configures the information of the slave nodes and allocates communication time, resulting in manual modification of the master node software when adding nodes and idle waiting and wasted bandwidth when removing nodes, this solution allows the master node to dynamically perceive the current set of effective slave nodes simply by initiating the virtual identifier allocation process and collecting the responses of the slave nodes. Since the received second message includes the virtual identifier of the slave node, the master node can obtain the configuration of the vehicle network based on the virtual identifier of the slave node and determine the communication timing accordingly. This avoids the software modification process when the devices in the vehicle network change, effectively eliminates the bandwidth waste caused by idle time slots, realizes adaptive management of device resources in the vehicle network, and improves communication efficiency.

[0015] In conjunction with the second aspect, in some possible implementations, the second transmission time is determined based on the second message, including: Based on the second message, determine the number of virtual identifiers; The second sending time is determined based on the number of virtual identifiers.

[0016] In the embodiments of this application, the master node determines the number of virtual identifiers based on the second message and accordingly determines its own second transmission time. Compared to the prior art, where the master node's communication timing is based only on a pre-configured number of nodes and cannot be dynamically adjusted according to the actual number of online nodes in the network, this solution enables the master node to calculate its own transmission timing in the communication loop based on the number of virtual identifiers actually allocated and reported by the slave nodes. Therefore, the master node can dynamically match its communication behavior with the actual scale and load of the current network, avoiding idle delays that may occur due to waiting for the maximum preset number of nodes, thereby optimizing the timing of the communication loop and further improving the utilization efficiency of network bandwidth.

[0017] Combining the second aspect and the above implementation methods, in some possible implementation methods, the second transmission time is determined based on the number of virtual identifiers, including: The communication cycle time is determined based on the number of virtual identifiers; The second transmission time is determined based on the communication cycle time.

[0018] In the embodiments of this application, the master node determines the communication cycle time based on the number of virtual identifiers, and determines its own second transmission time accordingly. Compared to the prior art, where the master node's communication timing is based only on the pre-configured number of nodes and cannot be dynamically adjusted according to the actual number of online nodes in the network, this solution determines the cycle length for completing one communication cycle based on the number of virtual identifiers, and then arranges the master node's own transmission time according to the cycle length. This enables the master node's transmission behavior to be synchronized with the working cycle of the vehicular network, ensuring that its own messages are transmitted without conflict within the planned time window, avoiding additional idle time or delays caused by inaccurate timing estimation or fixed waiting, thereby further improving communication efficiency.

[0019] Combining the second aspect and the above implementation methods, in some possible implementations, the master node stores an identifier mapping relationship, which is used to represent the mapping relationship between the fixed identifier and the virtual identifier of the slave node. Before sending the first message to the slave node, the communication method further includes: Set the virtual identifier of all slave nodes in the identifier mapping relationship to the default value.

[0020] In the embodiments of this application, the master node stores the identifier mapping relationship and pre-sets the virtual identifiers therein to preset values, uniformly setting them to the initial state before virtual identifier allocation. This scheme actively resets the identifier mapping table in each power-on initialization cycle, so that the mapping table starts from an unallocated state, and is then filled and updated by the received second message. Since the preset value can be used to represent the "unallocated" or "invalid" state, the master node can distinguish which slave nodes have successfully participated in allocation and reported valid virtual identifiers. This mechanism ensures that the master node's understanding of the slave nodes that can communicate with the vehicular network in the current cycle is real-time and accurate, thus providing a reliable basis for its subsequent accurate communication scheduling, ensuring that the vehicular network can adaptively configure itself when equipment changes.

[0021] Thirdly, a vehicle communication device is provided, the device comprising: The receiving module is used to receive the first message sent by the master node in the vehicle network. The first message includes an enable flag and a fixed identifier of the slave node. The enable flag is used to indicate whether the slave node in the vehicle network is assigned a virtual identifier. The processing module is used to obtain the target virtual identifier of the slave node based on the fixed identifier when the enable flag indicates that the slave node is allocating a virtual identifier; to obtain the first transmission time corresponding to the target virtual identifier based on the target virtual identifier; and to transmit vehicle communication data at the slave node when the first transmission time is reached.

[0022] It should be understood that the extensions, limitations, explanations and descriptions of the relevant content in the first aspect above also apply to the same content in the third aspect.

[0023] Fourthly, a vehicle communication device is provided, the device comprising: The sending module is used to send a first message to the slave node after detecting that the vehicle is powered on. The first message is used to instruct the slave node in the vehicle network to allocate a virtual identifier. The first message includes the fixed identifier of the slave node. The processing module is used to receive a second message sent by the slave node, the second message including the virtual identifier of the slave node; determine a second transmission time based on the second message; and send the vehicle communication data of the master node when the second transmission time arrives.

[0024] It should be understood that the extensions, limitations, explanations and clarifications of the relevant content in the second aspect above also apply to the same content in the fourth aspect.

[0025] Fifthly, a vehicle is provided, including a memory and a processor; the memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to execute the vehicle communication method in the first aspect, the second aspect, any possible implementation of the first aspect, or any possible implementation of the second aspect.

[0026] Sixthly, a computer program product is provided, comprising: computer program code, which, when executed on a computer, causes the computer to execute the vehicle communication method in any of the first, second, or possible implementations of the first aspect or the second aspect.

[0027] In a seventh aspect, a computer-readable storage medium is provided, which stores computer program code that, when executed on a computer, causes the computer to perform the vehicle communication method in the first aspect, the second aspect, any possible implementation of the first aspect, or any possible implementation of the second aspect. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of a communication bus structure provided in an embodiment of this application; Figure 2 This is a schematic diagram of another communication bus structure provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a message transmission sequence provided in an embodiment of this application; Figure 4This is a schematic diagram illustrating another message sending sequence provided in an embodiment of this application; Figure 5 This is a schematic diagram of a communication network for a vehicle ambient light provided in an embodiment of this application; Figure 6 This is a schematic flowchart illustrating a vehicle communication method provided in an embodiment of this application; Figure 7 This is a schematic diagram of communication data in a transmission loop provided in an embodiment of this application; Figure 8 This is a schematic diagram of a message structure provided in an embodiment of this application; Figure 9 This is a schematic flowchart illustrating a virtual identifier allocation method provided in an embodiment of this application; Figure 10 This is a schematic flowchart illustrating another virtual identifier allocation method provided in an embodiment of this application; Figure 11 This is a schematic flowchart illustrating a communication method for a slave node provided in an embodiment of this application; Figure 12 This is a schematic flowchart illustrating another vehicle communication method provided in an embodiment of this application; Figure 13 This is a schematic flowchart illustrating another vehicle communication method provided in the embodiments of this application; Figure 14 This is a schematic diagram of the structure of a vehicle communication device provided in an embodiment of this application; Figure 15 This is a schematic diagram of the structure of another vehicle communication device provided in an embodiment of this application; Figure 16 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0030] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0031] Before introducing the methods of the embodiments of this application, the technical terms that may be involved in the embodiments of this application will be explained first.

[0032] 10Mbps Ethernet for vehicles: Also known as single-pair multipoint Ethernet or 10Mbps bus-type Ethernet for vehicles, it can be represented as 10BASE-T1S. It is used in vehicle or industrial environments to connect multiple devices via a single unshielded twisted-pair cable, enabling bus-type network communication without a switch. For example, 10BASE-T1S Ethernet supports a communication rate of 10 Mbps and employs Physical Layer Collision Avoidance (PLCA) to manage multi-node access; PLCA can send messages in a cyclic manner to achieve multi-point communication without message arbitration collisions.

[0033] Electronic Control Unit (ECU): Also known as an on-board controller, automotive microcomputer controller, network node, etc., it is used to implement specific control, computing, or sensing functions within a vehicle and has the ability to communicate with the vehicle's network. For example, an electronic control unit may include a microcontroller, memory, power management chip, and a physical layer interface connected to a bus.

[0034] It should be understood that in the embodiments of this application, master nodes and slave nodes can be used to represent ECUs that perform different logical functions in the network. The master node, also known as a NODE0 node, can represent the ECU responsible for coordinating network communication (such as initiating initialization procedures and sending synchronization beacons); the slave node, also known as a non-NODE0 node, can represent the ECU that accepts coordination from the master node and executes specific application functions (such as sensing and execution). Both master and slave nodes are essentially ECUs with network communication capabilities; their distinction is mainly based on their logical roles in the network protocol stack or application layer.

[0035] It should be noted that in 10BASE-T1S, a unique identifier needs to be assigned to each network node. Among them, the node with node ID 0 is the master node (for example, the node with NODE ID 0 can also be called the NODE0 node), which is responsible for sending the start flag of each transmission cycle.

[0036] The 10BASE-T1S system, similar to the CAN bus system, adopts a bus-type architecture and can achieve multi-point communication without the need for a switch chip. For example, ... Figure 1As shown, the 10BASE-T1S bus can include ECU1, ECU2, ECU3, ECU4, and ECU5. Among them, ECU1 can act as the master node on this segment of the bus, and ECU2, ECU3, ECU4, and ECU5 can act as slave nodes on this segment of the bus.

[0037] The ECU corresponding to node NODE0 can have a built-in Switch chip, which can simultaneously connect to both 10BASE-T1S and 100BASE-T1 networks (100Mbps in-vehicle Ethernet, supporting only point-to-point communication). The Switch chip enables data forwarding between the 10BASE-T1S and 100BASE-T1 networks. The forwarding path is determined by the Media Access Control Address (MAC address) and Virtual Local Area Network Information (VLAN) information in the Ethernet packet header. For example,... Figure 2 As shown, ECU1 has a built-in Switch chip and connects to both the 100BASE-T1 network and the 10BASE-T1S network. ECU1 can act as the master node on this bus segment, while ECU2, ECU3, ECU4, and ECU5 can act as slave nodes on this bus segment.

[0038] The communication process of 10BASE-T1S can be as follows: Figure 3 As shown, node NODE0 (i.e., ECU1) first sends a BEACON (BCN) signal, representing the start of the first transmission cycle. After sending the BCN, NODE0 sends the message it needs to transmit. After NODE0 completes its transmission, the bus enters a silent state, waiting for the timeout timer (TO_TIMER) to expire. Then, node NODE1 (i.e., ECU2) gets the opportunity to send a message. After node NODE1 completes its transmission, the bus enters a silent state, waiting for TO_TIMER to expire. Then, node NODE2 (i.e., ECU3) gets the opportunity to send a message. For example, the nodes in the bus sequentially get the opportunity to send messages and send messages. After NODE0 detects that NODE3 has completed its transmission and that the bus has entered a silent state waiting for TO_TIMER to expire, NODE0 resends the BCN flag, and the communication process enters the second transmission cycle. This communication process cycles in the above manner, thereby realizing continuous and periodic communication in the 10BASE-T1S network.

[0039] In this system, the NODE0 node is pre-configured with the maximum NODE ID value in that segment of the vehicular network. During communication, it determines the current sending node's NODE ID value based on the number of TO_TIMER timeouts. Once the node with the largest NODE ID value finishes sending and the timeout occurs, the NODE0 node sends a new round of BCN signals. Non-NODE0 nodes are pre-configured with their own NODE ID values. Starting from the BCN signal, they check the TO_TIMER timeout count. Once the timeout count equals their own NODE ID value, they determine that it is their sending opportunity and begin sending messages.

[0040] In existing technology, the master node controls the start of each transmission cycle, therefore, the master node needs to store information about the number of slave nodes in the system. During communication, when the master node detects that the number of TO_TIMER timeouts equals the number of slave nodes in the system, it indicates the end of the current transmission round and simultaneously sends a BCN to indicate the start of the next transmission cycle. When adding a slave node, the master node needs to modify the software to update the internally stored slave node count information, so that the newly added slave node can participate in the communication process.

[0041] In addition, when removing a slave node, such as Figure 4 As shown, when removing the slave node (ECU2), during the communication process, after ECU1 sends the BCN signal, it needs to wait for the bus to be silent and for the TO_TIMER to expire. Since ECU2 has been removed, it still needs to wait for ECU2 to send its message, and then wait for the TO_TIMER to expire before entering the sending time of ECU3. That is, there will be extra waiting time when ECU2 has the opportunity to send, resulting in bandwidth waste.

[0042] For example, such as Figure 5 As shown in (a), the entertainment host is the main algorithm controller of the ambient light. It interacts with the ambient light system through the internal switch of the left area controller. The left area controller and the entertainment host are connected point-to-point via 100BASE-T1, and the left area controller and the ambient light system are connected via 10BASE-T1S (the left area controller is the master node). The existing ambient light system contains 5 slave nodes, namely: dashboard ambient light, left front door ambient light, left rear door ambient light, right rear door ambient light, and right front door ambient light.

[0043] If, based on the aforementioned in-vehicle network, it is necessary to add a slave node, such as for ambient lighting in the ceiling, then... Figure 5As shown in (b), in order for the ambient lighting node and the entertainment host to interact smoothly, the left area controller needs to modify its software to change the number of its internal slave nodes from 5 to 6, thus incurring corresponding software change costs. If the original vehicle network includes the ambient lighting, and this ambient lighting needs to be removed in another vehicle model project, without modifying the left area controller's software, an additional TO_TIMER timeout will occur during the 10BASE-T1S communication process when the original ambient lighting is being transmitted, resulting in wasted bandwidth.

[0044] To address the issue that existing technologies require additional software modifications to the master node when adding or removing devices in vehicular networks, embodiments of this application provide a vehicle communication method, a vehicle, and a storage medium. When adding a slave node, a virtual identifier is allocated based on an enable flag, and a corresponding communication time is determined based on the virtual identifier, thus enabling the new slave node to join the vehicular communication. Therefore, compared to existing technologies, this solution eliminates the need for manual modification of the master node configuration and enables adaptive adjustment of the communication process when devices change in the vehicular network. When deleting a slave node, this solution sends a first message through the master node. The enable flag in the first message can be used to instruct the slave node to allocate a virtual identifier. If the slave node is deleted, it cannot receive the first message and therefore will not allocate a virtual identifier or corresponding communication time. This allows other slave nodes to communicate based on their own allocated virtual identifiers without waiting for the deleted node's communication time, enabling adaptive adjustment of the communication process when devices change in the vehicular network and improving bandwidth utilization.

[0045] The following is combined Figure 6 A vehicle communication method provided in the embodiments of this application will be described in detail.

[0046] Figure 6 This is a schematic flowchart illustrating a vehicle communication method provided in an embodiment of this application. Figure 6 As shown, method 600 includes steps S610 to S640, which are described in detail below.

[0047] For example, Figure 6 The method 600 shown can be executed by a vehicle; or by a processor in the vehicle; or by a chip in the processor of the vehicle; or by a software platform integrated in an electronic device; or by an ECU with communication capabilities in an in-vehicle network; or by a slave node in the in-vehicle network.

[0048] S610: Receives the first message sent by the master node in the vehicle network.

[0049] The first message includes an enable flag and a fixed identifier for the slave node. The enable flag is used to indicate whether the slave node in the vehicular network is assigned a virtual identifier.

[0050] It should be understood that a fixed identifier, also known as a real ID, real node identifier, preset identity identifier, hardware ID, etc., is used to uniquely identify an electronic control unit in the vehicle network. It is usually preset at the factory and cannot be changed. For example, the fixed identifier is the basis for nodes to participate in the network initialization process and for the master node to identify devices.

[0051] Alternatively, in one embodiment, the length of the control information group can be determined by the master node based on the number of slave nodes allowed to communicate during the current power-on cycle.

[0052] For example, such as Figure 7 As shown, during 10BASE-T1S communication, after the master node sends the BCN signal, the master node can send a control field (i.e., the first message) to the slave node. This control field is used to control all slave nodes to enter the virtual identifier allocation process and to control the fixed identifier information of each slave node. The content of the control field can be as shown in Table 1, including a preamble, virtual ID allocation enable, and a send control information group. The preamble can be 6 bits long and can be represented by a fixed value: "0x2A", which can be used to indicate the start of the send control field. The virtual ID allocation enable can be 2 bits long, where 0x0 can be used to indicate that virtual ID allocation is not enabled, 0x1 can be used to indicate that virtual ID allocation is enabled, and 0x2 to 0x3 can be reserved for fields with other meanings to be defined later. The send control information group can be 4 to 64 bits long and can be used to represent 16 groups of fixed identifiers for slave nodes. That is, the range of fixed identifiers for slave nodes is 0 to 15. The length of the send control information group varies depending on the number of nodes in the network. For example, if there are 3 slave nodes in the network that need to communicate, the send control information group contains 3 IDs with a total length of 12 bits. Any part less than 1 byte is padded with 0s, and the length after padding is 16 bits.

[0053] Alternatively, in another embodiment, the control information group is sent in a fixed length of 64 bits, fully containing 16 sets of fixed identifier values ​​(ID1 to ID16) of the slave nodes.

[0054] It should be understood that in this embodiment, when the virtual ID allocation enable flag indicates that allocation is enabled (value 0x1), the control information group will be sent in a fixed length of 64 bits, completely containing the fixed identifier values ​​(ID1 to ID16) of 16 slave nodes. By sending this complete list containing all preset fixed identifier values, the master node can ensure that every possible slave node is traversed and attempted to be triggered to participate in the virtual identifier allocation process during network initialization, thereby achieving a comprehensive and complete discovery and identification of the actual network topology.

[0055] For example, in the first communication cycle after the vehicle is powered on, the master node (such as the area controller) sends a virtual ID allocation enable flag of 0x1, and simultaneously sends a complete 64-bit control information group containing all the preset fixed identifiers from ID1 to ID16. For instance, ID1 to ID4 correspond to the fixed identifiers of the left front, right front, left rear, and right rear door modules, respectively. At this time, in a network that is actually only connected to the left front (ID1) and right rear (ID4) door modules, the master node can simultaneously trigger these two modules to respond and complete the virtual identifier allocation (e.g., assigning virtual ID1 and virtual ID2 respectively) in their corresponding transmission opportunities by broadcasting this complete list. For the module positions corresponding to the unconnected ID2 and ID3, their preset transmission opportunities will time out silently due to no node response, and the master node can thus identify these two nodes as offline. This process ensures that regardless of the physical connection status, the network can complete the status discovery of all preset nodes and the identifier initialization of online nodes.

[0056] Table 1

[0057] It should be understood that the lengths of the different contents of the above control fields and the number of IDs in the sending control information group are illustrative and are not limited in this application embodiment.

[0058] S620. When the enable flag indicates that the slave node is assigned a virtual identifier, the target virtual identifier of the slave node is obtained based on the fixed identifier.

[0059] The virtual identifier, also known as a virtual ID, dynamic identifier, logical time slot identifier, or communication sequence number, is used in networks employing conflict avoidance mechanisms such as 10BASE-T1S to identify the logical transmission order or time slot position occupied by a slave node in the current communication cycle. For example, the virtual identifier can be obtained through an automatic allocation process after power-on and used to determine the specific timing of node message transmission.

[0060] In the embodiments of this application, the first message sent by the master node includes an enable flag. When the enable flag is used to instruct the slave node to allocate a virtual identifier, the slave node obtains the target virtual identifier based on its own fixed identifier.

[0061] For example, after ECU1 (master node) sends the BCN signal, it sends a control field. ECU2 (slave node) receives the control field, in which the virtual ID allocation enable is "0x1", which is used to indicate that virtual ID allocation is being performed. The virtual identifier corresponding to ECU2 is then obtained based on the real ID (i.e., fixed identifier) ​​in the control field.

[0062] In one implementation, the above method includes: Based on a fixed identifier, the response time corresponding to the slave node is obtained; Based on the response time, the target virtual identifier is obtained.

[0063] For example, consider a network consisting of ECUs with fixed identifiers 1, 3, and 4 (i.e., ECU1, ECU3, and ECU4). The allocation process begins after the master node sends a start beacon. ECU1's response time is set after the first TO_TIMER timeout, according to the rules. ECU3's response time is after the third TO_TIMER timeout; and ECU4's response time is after the fourth TO_TIMER timeout.

[0064] In the above implementation, the response time is determined based on a fixed identifier, and then the target virtual identifier is obtained. Compared with existing technologies that cannot adaptively adjust the communication process when devices in the vehicular network change, resulting in the need to modify the software in the master node or idle communication time during the communication process, thus reducing communication efficiency, this solution determines the response time of the slave node based on the fixed identifier, and then obtains the target virtual identifier corresponding to the slave node based on the response time. This enables the slave node to automatically complete the configuration of the vehicular network based solely on its own fixed identifier and predetermined rules when devices in the vehicular network change, without modifying the software in the master node or waiting for the communication time of the removed node during the communication process. This simplifies the communication configuration process and improves communication efficiency.

[0065] In one implementation, the above method includes: Upon reaching the response time, check if an assigned virtual identifier exists; If an assigned virtual identifier already exists, determine the target virtual identifier based on the assigned virtual identifier; If no assigned virtual identifier exists, the preset virtual identifier will be used as the target virtual identifier.

[0066] In the embodiments of this application, each slave node needs to immediately assign its own virtual ID after its own transmission opportunity arrives. The virtual ID is obtained by combining its own fixed identifier (real ID value) and the virtual identifier (virtual ID value) published by the previous slave node. If the slave node's real ID is 1, then the virtual ID is assigned as 1; if the slave node's real ID is not 1, and other slave nodes have not published virtual identifier information in the previous communication process, then the virtual ID is assigned as 1; if the slave node's real ID is not 1, and in the previous communication process, the virtual ID previously received from other slave nodes was a, then the virtual ID of that slave node is assigned as a+1.

[0067] For example, consider a network of ECUs (ECUs) with fixed identifiers 1, 3, and 4 (i.e., ECU1, ECU3, and ECU4). After the master node sends a start beacon, the allocation process begins. ECU1's response time is set to after the first TO_TIMER timeout, according to the rules. Upon reaching this response timeout, ECU1 listens to the network, finds no declaration of any allocated identifier, and therefore allocates the target virtual identifier as 1 and broadcasts it. ECU3's response time is after the third TO_TIMER timeout. During the waiting period, ECU3 hears ECU1's declaration of virtual identifier 1. When its own response timeout is reached, it hears that the "maximum value of allocated virtual identifiers" is 1, so it applies the accumulation rule, allocates the target virtual identifier as 2, and broadcasts it. ECU4's response time is after the fourth TO_TIMER timeout. At this point, ECU4 hears that the "maximum value of allocated virtual identifiers" has been updated to 2, and allocates its own target virtual identifier as 3.

[0068] In the above implementation, upon receiving a response from a slave node, the existence of an assigned virtual identifier is checked, and the target virtual identifier corresponding to the slave node is determined based on the existence of an assigned virtual identifier. If no assigned virtual identifier exists, a preset virtual identifier is determined as the target virtual identifier, for example, 1 can be determined as the target virtual identifier. If an assigned virtual identifier exists, the target virtual identifier is determined based on the assigned virtual identifier. Compared to existing technologies that cannot adaptively adjust the communication process when devices change in the vehicular network, leading to the need to modify the software in the master node or resulting in idle communication time during the communication process, reducing communication efficiency, this solution can assign a corresponding virtual identifier to each slave node based on the existence of an assigned virtual identifier. Since assigning a corresponding virtual identifier to each slave node ensures normal communication of each slave node in subsequent communication processes, avoiding software modification of the master node, and since each slave node is a node that can communicate normally in the vehicular communication network, it can avoid the communication time waiting for deleted nodes in subsequent communication processes. This solution can adaptively perform communication when devices change in the vehicular network, simplifying the communication configuration process and improving communication efficiency.

[0069] S630. Based on the target virtual identifier, obtain the first transmission time corresponding to the target virtual identifier.

[0070] In the embodiments of this application, the numerical value of the target virtual identifier determines the order in which the node obtains a transmission opportunity on the bus in each communication cycle. After receiving the beacon initiating a new round of communication cycle from the master node, the slave node does not need to arbitrate or negotiate again. It only needs to accurately calculate the "first transmission time" that belongs to the node and does not conflict with other nodes based on the value of its own virtual identifier and through the counting timeout (TO_TIMER) period mechanism.

[0071] One implementation also includes: After obtaining the target virtual identifier based on the fixed identifier, a second message is sent to the master node.

[0072] The second message, also known as the NODE ID information publishing message, may include the target virtual identifier of the slave node.

[0073] In the embodiments of this application, a NODE ID information publishing message for non-NODE0 nodes is constructed using the User Datagram Protocol (UDP). The purpose of this message is for non-NODE0 nodes to publish their virtual ID and real ID to the NODE0 node. The NODE ID information publishing message is sent by non-NODE0 nodes to all other nodes (i.e., multicast transmission).

[0074] Optionally, a source port number for publishing the NODE ID information can be defined in the UDP header to ensure that other nodes can receive and identify the Ethernet packet as a NODE ID information publishing packet. For example, the source port number for publishing the NODE ID information can be set to 65000.

[0075] For example, the structure of a NODE ID information publishing message can be as follows: Figure 8 As shown in Table 2, the NODE ID information publishing message includes a MAC address, IP header, UDP header, and data field. The data field can include the sender node's real NODE ID (i.e., real ID) and virtual NODE ID (i.e., virtual ID). The real NODE ID can be 4 bits long, and its specific value can be used to represent the real ID value of a non-NODE0 node. The virtual NODE ID can also be 4 bits long, and its specific value can be used to represent the virtual ID value of a non-NODE0 node.

[0076] Table 2

[0077] For example, such as Figure 9 As shown, Figure 9 This is a schematic flowchart illustrating a virtual identifier allocation method provided in an embodiment of this application; in the embodiments of this application, it can be based on... Figure 9 The method shown in 900 determines the virtual identifier of the slave node.

[0078] S901, Initialization complete.

[0079] For example, after the vehicle is powered on, the left front corner radar ECU completes a self-test, the network communication stack is ready, and it waits for instructions from the master node.

[0080] S902, Receive BCN and send control field.

[0081] For example, the left front corner radar ECU receives a start beacon (BCN) sent by the area controller (master node) and the control fields that follow from the bus.

[0082] S903. Determine the value of the virtual ID allocation enable flag; if the value of the enable flag is 0, execute S904; if the value of the enable flag is 1, execute S905.

[0083] For example, if the value of the virtual ID allocation enable flag is 0, then no virtual ID allocation is performed, and the communication phase is directly entered, and S904 is executed; if the value of the virtual ID allocation enable flag is 1, then the node performs dynamic allocation of identity identifiers, and S905 is executed.

[0084] S904, Enter normal communication process.

[0085] For example, if the enable flag is 0, the radar ECU will ignore the allocation process and directly use the configured virtual ID (e.g., 2) to send the target data according to its corresponding transmission time.

[0086] S905. Enter the virtual ID allocation process and send messages according to the internal real ID corresponding to the sending opportunity.

[0087] For example, since the enable flag is 1, the radar ECU enters the allocation process. The slave node waits for the corresponding transmission opportunity based on its own real ID (e.g., preset to 1).

[0088] S906. Determine your own real ID; if real ID = 1, execute S907 and S908; if real ID ≠ 1, execute S909.

[0089] For example, check its own real ID. If the value is 1, it will be the first node to be assigned a virtual ID, and execute S907 and S908. If the real ID value is not 1, it will wait for other slave nodes to be assigned virtual IDs, and execute S909.

[0090] S907, Virtual ID is assigned as 1.

[0091] For example, as the first allocation node, without listening to other nodes, the virtual ID is directly set to the initial value of 1.

[0092] S908, Send a NODE ID information publication message when the real ID corresponds to the sending opportunity.

[0093] For example, in the transmission slot where real ID=1, the slave node broadcasts a message to the network segment containing "real ID: 1, virtual ID: 1".

[0094] S909, When a real ID sending opportunity is detected.

[0095] For example, for the right front corner radar (assuming real ID=3), it needs to wait for the previous two transmission slots to pass before it can assign a virtual ID when it detects that its own transmission opportunity has arrived.

[0096] S910. Determine whether other non-NODE0 nodes have published NODE ID information; if yes, execute S913; if no, execute S911.

[0097] For example, when its own transmission time slot arrives, it is determined whether other non-NODE0 nodes have already published NODEID information. If so, it needs to be allocated according to its already allocated virtual ID, and S913 is executed; if not, a preset virtual ID value is directly allocated, and S911 is executed.

[0098] S911, Virtual ID is assigned as 1.

[0099] For example, the virtual ID of the non-NODE0 node is assigned as 1.

[0100] S912, Immediately send a NODE ID information publication message.

[0101] For example, after allocation is completed, within the current sending opportunity, the user broadcasts their real ID and the newly allocated virtual ID.

[0102] S913, The virtual ID value in the last received NODE ID information release message is a.

[0103] For example, if a message issued by the left front radar is detected, in which the virtual ID is 1, then it records this value, i.e., a=1.

[0104] S914, Virtual ID is assigned as a+1.

[0105] For example, according to the rules, it calculates its own virtual ID as a+1 = 2, thereby ensuring that the virtual ID is continuously incremented without conflict.

[0106] For example, such as Figure 10 As shown, Figure 10 This is a schematic flowchart illustrating a virtual identifier allocation method provided in an embodiment of this application; in the embodiments of this application, it can be based on... Figure 10 The method shown 1000 determines the virtual identifier of the slave node.

[0107] S1001, set the virtual ID of all nodes in the NODE ID mapping table to 0.

[0108] For example, before executing S1001, the NODE0 node and non-NODE0 nodes are initialized. After the vehicle is powered on, the NODE0 node (such as the left domain controller) initializes the identifier mapping relationship maintained internally, clearing or setting the "virtual ID" column in all entries to an invalid value of 0.

[0109] S1002, Send BCN.

[0110] For example, the NODE0 node sends a BCN signal to indicate to all slave nodes that they are ready to receive subsequent instructions.

[0111] S1003, each non-NODE0 node waits to receive the send control field.

[0112] For example, after successfully receiving the BCN signal, non-NODE0 nodes (such as various door modules and radars) synchronously enter a waiting state, preparing to parse the next data segment immediately following the BCN.

[0113] S1004, Send control field.

[0114] For example, after the NODE0 node finishes sending the BCN, it sends control data. This field contains a "Virtual ID allocation enabled" flag (set to 1 at this time), and a list of real IDs including those of non-NODE0 nodes.

[0115] S1005, each node identifies virtual ID allocation enable = 0x1, enters the virtual ID allocation process, and sends messages according to the real ID at the corresponding sending opportunity.

[0116] For example, each non-NODE0 node decodes the control field, finds that the virtual ID allocation enable flag is "1", and executes the virtual ID allocation process in method 900.

[0117] Alternatively, the implementation of S1005 can be found in [reference needed]. Figure 6 The relevant descriptions in S620 will not be repeated here.

[0118] S1006, Node NODE1 calculates virtual ID=1 using the algorithm.

[0119] For example, a node with a real ID of 1 (such as the front left radar) is activated in the first time window. Since it is the first assigned node and has not listened to any previous claims, it defines itself as the starting point of the logical sequence and calculates a virtual ID = 1.

[0120] Alternatively, the implementation of S1006 can be found in [reference needed]. Figure 6 The relevant descriptions in S620 will not be repeated here.

[0121] S1007, TO_TIMER timeout detected.

[0122] For example, detecting a TO_TIMER timeout indicates the end of the current node's transmission window, and bus control should be transferred to the next candidate node (real ID=2).

[0123] S1008, send a NODE ID information publication message.

[0124] For example, after calculating the virtual ID (or when it is its turn to send after a timeout), a node (such as NODE1) immediately constructs and broadcasts a NODE ID information publication message to inform the NODE0 node of its own node's real ID and virtual ID.

[0125] S1009, Update the NODE ID mapping table, updating the virtual ID value of real ID=1 to 1.

[0126] For example, the NODE0 node continuously listens to the bus and updates its internal NODE ID mapping table after receiving a NODE ID information publication message.

[0127] In the above implementation, after obtaining the target virtual identifier based on the fixed identifier, a second message containing the target virtual identifier is sent to the master node. This message is used to send the target virtual identifiers corresponding to each slave node to the master node, enabling the master node to obtain the configuration status of the slave nodes in the vehicle network without modifying the software. Therefore, this solution can adaptively communicate when devices in the vehicle network change, simplifying the communication configuration process and improving communication efficiency. Furthermore, since the slave nodes send the target virtual identifier information to the master node, the master node can ensure normal communication based on the number of slave nodes in the vehicle network during subsequent communication processes, without waiting for the communication time of deleted nodes, thus improving communication efficiency.

[0128] S640. When the first transmission time is reached, vehicle communication data from the slave node is transmitted.

[0129] In the embodiments of this application, after executing S610, S620 and S630, a virtual ID is assigned to the slave node, and the communication phase begins. According to the first transmission time corresponding to the virtual ID, when the transmission time is reached, the slave node encapsulates the latest vehicle communication data prepared internally in a specified format and transmits it to the bus through the physical layer.

[0130] For example, such as Figure 11 As shown, Figure 11 This is a schematic flowchart illustrating a communication method for a slave node provided in an embodiment of this application; in the embodiments of this application, it can be based on... Figure 11 The method 1100 shown enables communication between slave nodes.

[0131] S1101, Virtual ID allocation complete.

[0132] For example, after executing S630, virtual IDs are assigned to each slave node that needs to communicate.

[0133] S1102, Receive BCN and send control field.

[0134] For example, at the beginning of each communication cycle, the master node sends a broadcast start beacon (BCN signal) along with control fields.

[0135] S1103. Determine the virtual ID allocation enable flag; if the enable flag = 1, execute S1104; if the enable flag = 0, execute S1105.

[0136] For example, the control field includes a virtual ID allocation enable flag. If the enable flag = 1, it means that virtual ID allocation is required, and S1104 is executed; if the enable flag = 0, virtual ID allocation is not required, and S1105 is executed.

[0137] S1104, Enter the virtual ID allocation process.

[0138] For example, if the enable flag is 1, it means that virtual ID allocation is required. In this case, the slave node needs to allocate a virtual ID based on its own real ID.

[0139] Alternatively, the implementation of S1104 can be found in [reference needed]. Figure 6 The relevant descriptions in S620 will not be repeated here.

[0140] S1105. Enter the normal communication process and send messages according to the internal virtual ID corresponding to the sending opportunity.

[0141] For example, messages are sent according to the sequential position corresponding to the virtual ID stored in the device.

[0142] S1106. Determine whether the control information group contains its own real ID; if yes, proceed to S1107; if no, proceed to S1102.

[0143] For example, determine whether the control information group contains its own real ID. If it does, it means that the master node allows it to communicate in this round of the loop, and execute S1107; if it does not, it means that communication is not allowed in this round, and execute S1102.

[0144] S1107, Waiting for the opportunity to send the virtual ID.

[0145] For example, a slave node (e.g., virtual ID=3) must wait for the node with the previous virtual ID (e.g., virtual ID=2) to complete its transmission and time out before it gets its own transmission opportunity.

[0146] S1108, Send message.

[0147] For example, when its designated transmission time arrives, the slave node encapsulates the vehicle communication data into a message and sends it out via the bus.

[0148] In the above embodiments, the slave node receives a first message sent by the master node. Since the first message includes an enable flag for allocating virtual identifiers, the slave node can determine whether virtual identifier allocation is currently required through this enable flag. When the enable flag indicates that virtual identifier allocation is enabled, the slave node obtains its target virtual identifier based on its own inherent fixed identifier (e.g., real identifier). When the number of slave nodes changes, each slave node can allocate virtual flags through the first message, thereby enabling the dynamic transmission time to be determined by dynamically allocated virtual identifiers when the number of slave nodes in the vehicular network changes. Since the transmission time in this scheme is dynamically obtained based on virtual identifiers, it avoids the problem of idle communication resources caused by master node software modification and waiting for communication time of removed nodes in the prior art, thereby improving communication efficiency.

[0149] The following is combined Figure 12 Another vehicle communication method provided in the embodiments of this application will be described in detail.

[0150] Figure 12 This is a schematic flowchart illustrating another vehicle communication method provided in an embodiment of this application. Figure 12 As shown, method 1200 includes S1210 to S1240, which are described in detail below.

[0151] For example, Figure 12 The method 1200 shown can be executed by a vehicle; or by a processor in the vehicle; or by a chip in the processor of the vehicle; or by a software platform integrated in an electronic device; or by an ECU with communication function in the vehicle network; or by a master node in the vehicle network.

[0152] S1210. After detecting that the vehicle is powered on, send the first message to the slave node.

[0153] The first message, also known as the control field, is used to instruct the slave nodes in the vehicular network to assign virtual identifiers. The first message includes the fixed identifier of the slave node.

[0154] In the embodiments of this application, after detecting that the vehicle is powered on, the master node sends a first message to the slave node to control each slave node to allocate or not allocate virtual identifiers.

[0155] In one implementation, the master node stores an identifier mapping relationship, which represents the mapping relationship between the fixed identifier and the virtual identifier of the slave node. Before sending the first message to the slave node, the method further includes: Set the virtual identifier of all slave nodes in the identifier mapping relationship to the default value.

[0156] The identifier mapping relationship, also known as the node mapping table, ID correspondence table, or topology table, is used in the master node to store and maintain the correspondence between the fixed identifiers of all slave nodes in the network and their currently assigned dynamic identifiers. For example, the identifier mapping relationship is a core data structure for the master node to perform communication scheduling, determine the online node list, and calculate communication timing.

[0157] In the embodiments of this application, the master node, as the master control node during the communication phase, needs to maintain the identifier mapping relationship to determine the virtual ID of each slave node and ensure that the communication process proceeds normally. Before allocating virtual IDs, the master node needs to restore each virtual ID in the maintained identifier mapping relationship to a specific value to avoid a situation where a slave node has been removed, but because the slave node did not participate in this round of virtual ID allocation, it still retains the virtual ID value from the previous power-on cycle.

[0158] It should be understood that when the enable flag in the first message indicates that a slave node in the vehicular network needs to be assigned a virtual identifier, the virtual identifiers of all slave nodes in the identifier mapping relationship are set to a preset value. If the enable flag in the first message indicates that a slave node in the vehicular network does not need to be assigned a virtual identifier, the slave node will perform communication after receiving the first message, and it is not necessary to set all virtual identifiers to the preset value.

[0159] In the above implementation, the master node stores the identifier mapping relationship and pre-sets the virtual identifiers to preset values, uniformly setting them to the initial state before virtual identifier allocation. This solution actively resets the identifier mapping table during each power-on initialization cycle, starting from an unallocated state, and then filling and updating it using the received second message. Since the preset values ​​can be used to represent "unallocated" or "invalid" states, the master node can distinguish which slave nodes have successfully participated in allocation and reported valid virtual identifiers. This mechanism ensures that the master node's understanding of the slave nodes that can communicate with the vehicular network in the current cycle is real-time and accurate, thus providing a reliable foundation for subsequent precise communication scheduling and ensuring that the vehicular network can adaptively configure itself when equipment changes.

[0160] S1220, Receive the second message sent by the slave node.

[0161] The second message includes the virtual identifier of the slave node.

[0162] For example, when a source port number of 65000 is detected in the UDP header, the message is identified as the second message, i.e., a NODE ID information publication message sent by the slave node. The real ID and virtual ID in the data field following the source port number are captured.

[0163] S1230. Based on the second message, determine the second transmission time.

[0164] The second sending time is used to indicate the periodic timing when the master node sends its own application data during the normal communication phase.

[0165] In one implementation, the above method includes: Based on the second message, determine the number of virtual identifiers; The second sending time is determined based on the number of virtual identifiers.

[0166] In the embodiments of this application, the master node determines the number of virtual identifiers, i.e. the number of slave nodes participating in the communication, based on the virtual identifiers of each slave node in the second message. Based on the number of virtual identifiers, the second sending time can be determined, i.e. the timing of message sending by the master node during the communication phase.

[0167] In the above implementation, the master node determines the number of virtual identifiers based on the second message and accordingly determines its own second transmission time. Compared to existing technologies where the master node's communication timing is based solely on a pre-configured number of nodes and cannot be dynamically adjusted according to the actual number of online nodes in the network, this solution enables the master node to calculate its own transmission timing in the communication loop based on the number of virtual identifiers actually allocated and reported by slave nodes. Therefore, the master node can dynamically match its communication behavior with the actual scale and load of the current network, avoiding idle delays that may occur due to waiting for the maximum preset number of nodes, thereby optimizing the timing of the communication loop and further improving the utilization efficiency of network bandwidth.

[0168] In one implementation, the above method includes: The communication cycle time is determined based on the number of virtual identifiers; The second transmission time is determined based on the communication cycle time.

[0169] The communication cycle time can be used to represent the minimum repeatable time length required for a 10BASE-T1S network to complete one full data exchange round. A communication cycle begins with the BCN signal sent by the master node, followed by time slots in which the master node and all valid slave nodes send data sequentially according to their virtual identifiers.

[0170] For example, the communication cycle time can be calculated using the formula: T_Cycle = T_BCN + N * (T_Slot) + T_Guard. Where T_Cycle is the communication cycle time, T_BCN is the fixed time for sending beacons, N is the number of virtual identifiers, T_Slot is the standard time slot length pre-allocated to each slave node (i.e., TO_TIMER time), and T_Guard is an optional guard interval.

[0171] In the above implementation, the master node determines the communication cycle time based on the number of virtual identifiers, and determines its own second transmission time accordingly. Compared to existing technologies where the master node's communication timing is based solely on a pre-configured number of nodes and cannot be dynamically adjusted according to the actual number of online nodes in the network, this solution determines the cycle length for completing one communication cycle based on the number of virtual identifiers, and then schedules the master node's own transmission time according to the cycle length. This allows the master node's transmission behavior to be synchronized with the working cycle of the vehicular network, ensuring that its messages are transmitted without conflict within the planned time window. This avoids additional idle time or delays caused by inaccurate timing estimation or fixed waiting, thereby further improving communication efficiency.

[0172] S1240. When the second transmission time is reached, the vehicle communication data of the master node is transmitted.

[0173] In the embodiments of this application, when the second transmission time is reached, the master node obtains the right to send messages on the bus, encapsulates the latest vehicle communication data prepared internally according to the protocol, and drives it to be sent on the bus.

[0174] Optionally, in one implementation, the master node sends a BCN signal when the second transmission time is reached, and after sending the BCN signal, the master node sends vehicle communication data.

[0175] In the above embodiment, after power-on, the master node sends a first message to trigger virtual identifier allocation and receives a second message reported by the slave node to obtain its allocated virtual identifier, thereby determining its own second transmission time. Compared to the prior art, where the master node configures the information of the slave nodes and allocates communication time, resulting in manual modification of the master node software when adding nodes and idle waiting and wasted bandwidth when removing nodes, this solution allows the master node to dynamically perceive the current set of effective slave nodes simply by initiating the virtual identifier allocation process and collecting the responses from the slave nodes. Furthermore, since the received second message includes the virtual identifier of the slave node, the master node can obtain the configuration of the vehicular network based on the virtual identifier of the slave node and determine the communication timing accordingly. This avoids software modification when devices change in the vehicular network and effectively eliminates bandwidth waste caused by idle time slots, achieving adaptive management of device resources in the vehicular network and improving communication efficiency.

[0176] The following is combined Figure 13 Another vehicle communication method provided in the embodiments of this application will be described in detail.

[0177] Figure 13 This is a schematic flowchart illustrating another vehicle communication method provided in an embodiment of this application. Figure 13 As shown, method 1300 includes S1301 to S1310, and S1301 to S1310 are described in detail below.

[0178] For example, taking a vehicle network including node NODE0, node NODE1, and node NODE3 as an example, node NODE2 is removed and its virtual ID is 0, while the virtual IDs of node NODE1 and node NODE3 are not 0.

[0179] For example, Figure 13 The method 1300 shown can be executed by a vehicle; or by a processor in the vehicle; or by a chip in the processor of the vehicle; or by a software platform integrated in an electronic device; or by an ECU with communication function in the vehicle network; or by a node in the vehicle network.

[0180] S1301, According to the NODE ID mapping table, the number of virtual IDs is 2.

[0181] For example, in a vehicle network including nodes NODE0, NODE1, and NODE3, only the virtual IDs corresponding to NODE1 and NODE3 are not 0, and the maximum virtual ID is 2.

[0182] S1302, Send BCN.

[0183] For example, sending a start beacon (BCN) marks the beginning of this round of communication.

[0184] S1303, each non-NODE0 node waits to receive the send control field.

[0185] For example, after receiving the BCN, NODE 1 and NODE 3 nodes wait to receive the control command section.

[0186] S1304, Send Control Field.

[0187] For example, the master node sends a control field containing "Assignment Enable=0" and an identifier mapping relationship, which includes a list of nodes that are allowed to communicate, namely nodes with virtual IDs not equal to 0: node NODE 1 and node NODE 3.

[0188] S1305, TO_TIMER timeout detected.

[0189] For example, after the control field has been sent and the bus is silent, TO_TIMER starts timing.

[0190] S1306, send the first data packet.

[0191] For example, after detecting a TO_TIMER timeout, the NODE 1 node sends the first data packet.

[0192] S1307, TO_TIMER timeout detected.

[0193] For example, after the first data packet is sent and the bus is silent, TO_TIMER starts timing.

[0194] S1308, send the second data packet.

[0195] For example, after detecting a TO_TIMER timeout, the NODE 3 node sends a second data packet.

[0196] S1309, 3 TO_TIMER timeouts detected.

[0197] For example, after sending the BCN and detecting three TO_TIMER timeouts, the NODE0 node confirms the end of the communication cycle.

[0198] S1310, send BCN.

[0199] For example, after sending the previous BCN and detecting three TO_TIMER timeouts, the NODE0 node confirms the end of a communication cycle and resends a start beacon (BCN) to mark the start of a new communication cycle.

[0200] In the above embodiments, the master node can obtain the configuration of the vehicle network based on the virtual identifier of the slave node, and determine the communication timing accordingly. This avoids the software modification process when the devices in the vehicle network change, effectively eliminates the bandwidth waste caused by idle time slots, realizes adaptive management of device resources in the vehicle network, and improves communication efficiency.

[0201] The above text combined Figures 1 to 13 This application provides a detailed description of a vehicle communication method based on its embodiments; the following will be combined with... Figures 14 to 16 The apparatus embodiments of this application are described in detail below. It should be understood that the apparatus in the embodiments of this application can perform the various methods described in the foregoing embodiments of this application, that is, the specific working processes of the various products described below can be referred to the corresponding processes in the foregoing method embodiments.

[0202] Figure 14 This is a schematic diagram of a vehicle communication device provided in an embodiment of this application. The vehicle communication device 1400 includes a receiving module 1410 and a processing module 1420.

[0203] The receiving module is used to receive the first message sent by the master node in the vehicle network. The first message includes an enable flag and a fixed identifier of the slave node. The enable flag is used to indicate whether the slave node in the vehicle network is assigned a virtual identifier. The processing module is used to obtain the target virtual identifier of the slave node based on the fixed identifier when the enable flag indicates that the slave node is allocating a virtual identifier; to obtain the first transmission time corresponding to the target virtual identifier based on the target virtual identifier; and to transmit vehicle communication data at the slave node when the first transmission time is reached.

[0204] Optionally, as an embodiment, the processing module 1420 is specifically used to: obtain the response time corresponding to the slave node based on the fixed identifier; and obtain the target virtual identifier based on the response time.

[0205] Optionally, as an embodiment, the processing module 1420 is specifically used to: detect whether there is an allocated virtual identifier when the response time is reached; if there is an allocated virtual identifier, determine the target virtual identifier based on the allocated virtual identifier; if there is no allocated virtual identifier, determine the preset virtual identifier as the target virtual identifier.

[0206] Optionally, as an embodiment, the processing module 1420 is further configured to: after obtaining the target virtual identifier based on the fixed identifier, send a second message to the master node, the second message including the target virtual identifier of the slave node.

[0207] Figure 15This is a schematic diagram of another vehicle communication device provided in an embodiment of this application. The vehicle communication device 1500 includes a transmitting module 1510 and a processing module 1520.

[0208] The sending module is used to send a first message to the slave node after detecting that the vehicle is powered on. The first message is used to instruct the slave node in the vehicle network to allocate a virtual identifier. The first message includes the fixed identifier of the slave node. The processing module is used to receive a second message sent by the slave node, the second message including the virtual identifier of the slave node; determine a second transmission time based on the second message; and send the vehicle communication data of the master node when the second transmission time arrives.

[0209] Optionally, as an embodiment, the processing module 1520 is specifically used to: determine the number of virtual identifiers based on the second message; and determine the second transmission time based on the number of virtual identifiers.

[0210] Optionally, as an embodiment, the processing module 1520 is specifically used to: determine the communication cycle time based on the number of virtual identifiers; and determine the second transmission time based on the communication cycle time.

[0211] Optionally, as an embodiment, the processing module 1520 is further configured to: set the virtual identifier of all slave nodes in the identifier mapping relationship to a preset value.

[0212] It should be noted that the communication device 1400 or 1500 of the vehicle described above is embodied in the form of a functional unit. The term "module" here can be implemented in software and / or hardware, without specific limitations.

[0213] For example, a "module" can be a software program, hardware circuit, or a combination of both that implements the above functions. Hardware circuits may include application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0214] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0215] Figure 16 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0216] For example, vehicle 1600 includes processor 1610, memory 1620 and executable program code 1630.

[0217] For example, vehicle 1600 includes one or more processors 1610 that can support the vehicle 1600 in implementing the vehicle communication method in the method embodiment. Processor 1610 can be a general-purpose processor or a special-purpose processor. For example, processor 1610 can be a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gates, transistor logic devices, or discrete hardware components.

[0218] For example, processor 1610 can be used to control vehicle 1600, execute software programs, and process data from the software programs. Vehicle 1600 may also include a communication unit for receiving and transmitting signals.

[0219] For example, the vehicle 1600 may include one or more memories 1620 storing executable program code 1630. The executable program code 1630 can be run by the processor 1610 to generate instructions, causing the processor 1610 to execute the vehicle communication method described in the above method embodiments according to the instructions. For example, the processor 1610 executes the following according to the instructions: receiving a first message sent by a master node in the vehicle network, the first message including an enable flag and a fixed identifier of a slave node, the enable flag indicating whether the slave node in the vehicle network is allocated a virtual identifier; if the enable flag indicates that the slave node is allocated a virtual identifier, obtaining a target virtual identifier of the slave node based on the fixed identifier; obtaining a first transmission time corresponding to the target virtual identifier based on the target virtual identifier; and transmitting vehicle communication data at the slave node when the first transmission time is reached. Alternatively, the processor 1610 executes the following instructions: upon detecting that the vehicle is powered on, it sends a first message to the slave node, the first message being used to instruct the slave node in the vehicular network to allocate a virtual identifier, the first message including a fixed identifier of the slave node; receives a second message sent by the slave node, the second message including the virtual identifier of the slave node; determines a second transmission time based on the second message; and when the second transmission time arrives, sends the vehicle communication data of the master node.

[0220] Optionally, the memory 1620 may also store data. Optionally, the processor 1610 may also read data stored in the memory 1620, which may be stored at the same memory address as the executable program code 1630, or the data may be stored at a different memory address than the executable program code 1630.

[0221] For example, the processor 1610 and memory 1620 can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) of the end device.

[0222] For example, the memory 1620 can be used to store related programs of the vehicle communication method provided in the embodiments of this application, and the processor 1610 can be used to call the executable program code 1630 stored in the memory 1620 when controlling the vehicle to execute the vehicle communication method of the embodiments of this application. This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the vehicle communication method of any of the foregoing embodiments.

[0223] The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0224] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the vehicle communication method in the above embodiments.

[0225] In addition, the electronic device provided in the embodiments of this application may specifically be a chip, component or module. The electronic device may include a connected processor and a memory. The memory is used to store instructions. When the electronic device is running, the processor may call and execute the instructions to make the chip execute the vehicle communication method in the above embodiments.

[0226] The vehicle, computer-readable storage medium, computer program product or chip provided in this application are all used to execute the communication method of the corresponding vehicle provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the communication method of the corresponding vehicle provided above, and will not be repeated here.

[0227] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

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

Claims

1. A communication method of a vehicle, characterized by, The communication method applied to a slave node in the vehicle comprises: receiving a first message sent by a master node in a vehicle network, the first message comprising an enabling flag and a fixed identifier of the slave node, the enabling flag being used to indicate whether the slave node in the vehicle network is allocated a virtual identifier; in the case that the enabling flag indicates that the slave node is allocated a virtual identifier, obtaining a target virtual identifier of the slave node based on the fixed identifier; obtaining a first sending time corresponding to the target virtual identifier based on the target virtual identifier; sending vehicle communication data at the first sending time.

2. The communication method according to claim 1, characterized by, The obtaining of the target virtual identifier based on the fixed identifier comprises: obtaining a response time corresponding to the slave node based on the fixed identifier; obtaining the target virtual identifier based on the response time.

3. The communication method according to claim 2, wherein, The obtaining of the target virtual identifier based on the response time comprises: detecting whether there is an allocated virtual identifier at the response time; in the case that there is the allocated virtual identifier, determining the target virtual identifier based on the allocated virtual identifier; in the case that there is no allocated virtual identifier, determining a preset virtual identifier as the target virtual identifier.

4. The communication method according to any one of claims 1 to 3, characterized by, The communication method further comprises: after the obtaining of the target virtual identifier based on the fixed identifier, sending a second message to the master node, the second message comprising the target virtual identifier of the slave node.

5. A communication method of a vehicle, characterized by, The communication method applied to a master node in the vehicle comprises: after detecting that the vehicle is powered on, sending a first message to a slave node, the first message being used to indicate that the slave node in a vehicle network is allocated a virtual identifier, the first message comprising a fixed identifier of the slave node; receiving a second message sent by the slave node, the second message comprising a virtual identifier of the slave node; determining a second sending time based on the second message; sending vehicle communication data of the master node at the second sending time.

6. The communication method according to claim 5, wherein, The determining of the second sending time based on the second message comprises: determining a number of virtual identifiers based on the second message; determining the second sending time based on the number of virtual identifiers.

7. The communication method according to claim 6, wherein, The determining of the second sending time based on the number of virtual identifiers comprises: determining a communication cycle period time based on the number of virtual identifiers; determining the second sending time based on the communication cycle period time.

8. The communication method according to any one of claims 5 to 7, characterized by, The master node stores an identifier mapping relationship, the identifier mapping relationship being used to represent a mapping relationship between the fixed identifier and the virtual identifier of the slave node, before sending the first message to the slave node, the communication method further comprises: setting all the virtual identifiers of the slave node in the identifier mapping relationship to a preset value.

9. A vehicle characterized by comprising: The vehicle comprises: a memory for storing executable program codes; a processor for calling and running the executable program codes from the memory, so that the vehicle executes the communication method according to any one of claims 1 to 4 or 5 to 8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program which, when executed, implements the communication method according to any one of claims 1-4 or 5-8.

Images