Communication method, master device, slave device, and vehicle communication system

Abstract

The application relates to a communication method, a master device, a slave device and a vehicle communication system. The communication method applied to the master device comprises the following steps: obtaining a control instruction; determining a target service primitive according to the control instruction, wherein the target service primitive represents a service primitive corresponding to a first communication protocol, and the first communication protocol represents a remote control protocol; determining a target data frame according to the target service primitive, wherein the target data frame represents a data frame corresponding to a second communication protocol, and the first communication protocol is different from the second communication protocol; and sending the target data frame to the slave device. The application directly encapsulates the target service primitive as a payload in a data segment of the data frame corresponding to the second communication protocol, can reduce protocol overhead, improve the proportion of the effective payload in the target data frame, and further improve communication efficiency and bandwidth utilization, and meanwhile, reduces the protocol stack complexity and processing delay of the master device and the slave device.

Description

Technical Field

[0001] This invention relates to, but is not limited to, the field of automotive electronic communication technology, and particularly to a communication method, a master control device, a slave device, and a vehicle communication system. Background Technology

[0002] As automotive electronic and electrical architecture evolves from a "distributed electronic control unit (ECU)" to a "centralized computing + regional controller" architecture, one of the core challenges facing the industry is how to achieve efficient and low-cost centralized control of the vast number of peripheral devices in a vehicle (such as headlights, windows, seats, HVAC dampers, wipers, various sensors and actuators, etc.). Traditional solutions rely on Local Interconnect Networks (LIN) or Controller Area Networks (CAN) and local MCUs, distributing control algorithms, diagnostic logic, and fault handling across a large number of small ECUs. This results in software fragmentation, complex version management, redundant wiring harnesses, increased costs and power consumption, and difficulties in unifying over-the-air (OTA) technology and security strategies.

[0003] Therefore, improving the management efficiency of edge devices and reducing management costs has become an urgent technical problem to be solved. Summary of the Invention

[0004] One objective of this invention is to provide a communication method to improve the management efficiency of edge devices and reduce management costs; a second objective is to provide a master control device; a third objective is to provide a slave device; and a fourth objective is to provide a vehicle communication system.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A communication method applied to a master control device, the method comprising: Obtain control commands; Based on the control command, a target service primitive is determined; the target service primitive represents a service primitive corresponding to a first communication protocol; the first communication protocol represents a remote control protocol. The target data frame is determined based on the target service primitive; the target data frame represents a data frame corresponding to the second communication protocol; the first communication protocol is different from the second communication protocol; The target data frame is sent to the slave device.

[0006] Based on the aforementioned technical means, on the one hand, the master control device in this solution uses the first communication protocol (i.e., RCP) to generate target service primitives and interacts with slave devices based on these target service primitives. It is evident that this solution employs the RCP communication framework, thereby centralizing the software on the master control device and achieving lightweighting of the slave devices. On the other hand, compared to related technologies that add IP and UDP headers to RCP service data, this solution directly encapsulates the RCP service data (i.e., the target service primitives) as payload into the data segment of the data frame corresponding to the second communication protocol. This eliminates the need for at least 28 bytes of header fields required for encapsulating IP and UDP headers, thereby reducing protocol overhead, increasing the proportion of effective payload in the target data frame, and thus improving communication efficiency and bandwidth utilization. Simultaneously, since the UDP and IP layers are removed from both the master and slave devices, the protocol stack complexity and processing latency are reduced.

[0007] Furthermore, the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier. The method further includes: determining a target virtual network identifier from a plurality of virtual network identifiers based on the target service primitive; Determining the target data frame based on the service primitive includes: encapsulating the target service primitive into the data segment of the target data frame; and placing the target virtual network identifier in the frame header control segment of the target data frame.

[0008] Based on the above technical means, logical isolation of multiple virtual communication networks on the same physical bus can be achieved, thereby avoiding interference between communications of different security levels or functional domains, and thus improving the overall security and communication efficiency of the system.

[0009] Furthermore, determining the target virtual network identifier from multiple virtual network identifiers based on the target service primitive includes: The target virtual network identifier is determined from a plurality of virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive; The communication direction includes either uplink communication or downlink communication; when the sending end is the master control device, the communication direction corresponding to the target service primitive represents downlink communication; when the sending end is the slave device, the communication direction corresponding to the target service primitive represents uplink communication. The service type represents the operation type corresponding to the target service primitive; The safety level represents the vehicle's safety integrity level.

[0010] Based on the above technical means, a multi-dimensional virtual network identifier allocation strategy can be implemented, and secure isolation and efficient routing at the physical bus level can be achieved, thereby improving the reliability and security of the system.

[0011] Furthermore, the second communication protocol characterizes the Controller Area Network Extended Length Protocol.

[0012] Based on the above technical means, by implementing the second communication protocol as the CAN XL protocol and directly encapsulating the RCP service primitive (i.e., the target service primitive) as the payload in the data segment of the CAN XL data frame, the overhead of at least 28 bytes caused by the tunnel encapsulation of the UDP layer and IP layer in the traditional RCP scheme can be eliminated, thereby significantly increasing the effective payload ratio and simplifying the protocol stack complexity; at the same time, it can also inherit the communication advantages of the CAN XL protocol, be compatible with the CAN ecosystem, and reduce the implementation cost of the RCP communication architecture.

[0013] On the other hand, the present invention proposes a communication method applied to a slave device, the method comprising: Receive target data frames sent by the master control device; the target data frames represent data frames corresponding to the second communication protocol. Determine the target service primitive in the target data frame; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol; Based on the target service primitive, determine the control command corresponding to the target data frame.

[0014] Based on the aforementioned technical means, on the one hand, the slave device in this solution interacts with the master device based on the target service primitive corresponding to the first communication protocol (i.e., RCP). It is evident that this solution employs the RCP communication framework, thereby centralizing the software on the master device and achieving lightweighting of the slave device. On the other hand, since the RCP service data (i.e., the target service primitive) in this solution is directly encapsulated as a payload within the data segment of the data frame corresponding to the second communication protocol, the slave device does not need to decapsulate the target data frame layer by layer. This eliminates the need for the UDP layer used for decapsulating the UDP header and the IP layer used for decapsulating the IP header, thereby reducing the complexity of the slave device's protocol stack and processing latency. This is more conducive to implementing MCU-less or minimally MCU-based designs for the slave device.

[0015] Furthermore, the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier. The step of determining the target service primitive in the target data frame includes: Determine the target virtual network identifier in the target data frame; If the target virtual network identifier matches the slave device, the target service primitive in the target data frame is determined; If the target virtual network identifier does not match the slave device, the target data frame is discarded.

[0016] Based on the above technical means, by introducing virtual communication networks and virtual network identification mechanisms, target data frames can be finely identified and filtered, thereby realizing multi-domain parallel communication and secure isolation at the physical bus level, and thus improving communication efficiency and system security.

[0017] Furthermore, the second communication protocol characterizes the Controller Area Network Extended Length Protocol.

[0018] Based on the aforementioned technical means, implementing the second communication protocol as the CAN XL protocol can inherit the communication advantages of the CAN XL protocol, be compatible with the CAN ecosystem, and reduce the implementation cost of the RCP communication architecture. At the same time, since the RCP service primitive (i.e., the target service primitive) is directly encapsulated as the payload in the data segment of the CAN XL data frame, the LLC sublayer of the slave device can directly deliver the payload to the application layer (i.e., the RCP service adaptation layer) of the slave device after completing VCID and SDT filtering, without having to decapsulate the IP header and UDP header layer by layer, and without having to set up IP and UDP layers in the slave device. This significantly shortens the processing path and forwarding latency, which is beneficial for the slave device to achieve MCU-less or extremely simple MCU design.

[0019] In another aspect, the present invention provides a master control device, comprising: A first service adaptation layer is used to acquire control commands; determine target service primitives based on the control commands; the target service primitives represent service primitives corresponding to a first communication protocol; the first communication protocol represents a remote control protocol; A first data link layer is used to determine a target data frame based on the target service primitive; the target data frame represents a data frame corresponding to a second communication protocol; the first communication protocol is different from the second communication protocol. A first data frame transceiver is used to send the target data frame to the slave device; the first data frame transceiver represents a data frame transceiver implemented based on the second communication protocol.

[0020] In another aspect, the present invention provides a device comprising: The second data frame transceiver is used to receive target data frames sent by the master control device; the target data frame represents a data frame corresponding to the second communication protocol; the second data frame transceiver represents a data frame transceiver implemented based on the second communication protocol. The second data link layer is used to determine the target service primitive in the target data frame; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol. The second service adaptation layer is used to determine the control command corresponding to the target data frame based on the target service primitive.

[0021] In another aspect, the present invention provides a vehicle communication system, comprising: a master control device and a plurality of slave devices, wherein the master control device is communicatively connected to the plurality of slave devices via a physical bus; wherein, The main control device is used to implement some or all of the steps in the communication method applied to the main control device described above. The slave device is used to implement some or all of the steps in the communication method applied to the slave device described above. The physical bus represents the communication bus carrying the second communication protocol.

[0022] The beneficial effects of this invention are: (1) The present invention encapsulates the RCP service primitive as the payload directly into the data segment of the CAN XL data frame, removing the at least 28-byte header required for UDP and IP protocol tunnel encapsulation, reducing the complexity of the protocol stack, thereby improving the data transmission rate and reducing the latency; (2) This invention fully retains the original capabilities of CAN XL, such as high bandwidth, large payload and virtual network isolation, while using the SDT field to clearly distinguish RCP data from other possible tunnel data, thus achieving clear isolation at the protocol level; (3) The present invention achieves logical isolation of RCP service requests with different security levels and different control domains at the physical bus level through VCID, and performs hardware-level VCID filtering from the LLC sub-layer of the device. Non-member frames do not trigger any upper-layer interrupts, thus meeting functional safety requirements. (4) The physical layer in this invention adopts the CAN_H and CAN_L twisted pair structure, which can smoothly upgrade the existing infrastructure corresponding to the CAN protocol and CAN FD protocol; at the same time, the transceiver corresponding to the CAN XL protocol has low cost and does not require an external high-precision clock, which is conducive to the low-cost design of edge devices. Attached Figure Description

[0023] Figure 1 A schematic diagram illustrating the implementation process of a communication method provided by the present invention; Figure 2 This is a schematic diagram of the structure of a CAN XL data frame in one embodiment of the present invention; Figure 3 A schematic diagram illustrating the implementation process of an embodiment of the present invention; Figure 4 A schematic diagram illustrating the implementation process of a communication method provided by the present invention; Figure 5 A schematic diagram illustrating the implementation process of an embodiment of the present invention; Figure 6 This is a timing diagram of the interaction between the master control device and the slave device in one embodiment of the present invention; Figure 7 A schematic diagram illustrating the implementation process of an embodiment of the present invention; Figure 8 A schematic diagram of the hardware entity of the main control device provided by the present invention; Figure 9 A schematic diagram of the hardware entity of the device provided by the present invention; Figure 10 This invention provides a system framework diagram of a vehicle communication system. Detailed Implementation

[0024] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0025] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0026] To improve the management efficiency of edge devices in automobiles, the Remote Control Protocol (RCP) has been proposed. RCP is a lightweight communication protocol whose core objective is to migrate the protocol conversion function from edge device controllers to area controllers or even central controllers, transforming edge devices into "remotely accessible peripherals" to enable remote control and lightweight edge devices. Currently, RCP implementations are generally tied to 10 Mbit / s Baseband Single-Pair Ethernet Short Reach (10BASE-T1S). 10BASE-T1S, defined by the Institute of Electrical and Electronics Engineers (IEEE) standard, supports multi-point connections, meaning multiple nodes can be connected to a single bus. However, existing RCP architectures still have the following shortcomings: First, there is a bandwidth bottleneck. The effective bandwidth of 10BASE-T1S is only 10 Mbit / s; Secondly, the cost is relatively high. The transceivers and related terminal equipment for 10BASE-T1S are relatively expensive. For example, while the LAN866x series of 10BASE-T1S endpoint devices supporting RCP are powerful, their overall material cost is high. Secondly, the integration of the RCP architecture with the CAN ecosystem is difficult. In the automotive industry, many edge devices currently communicate based on the CAN protocol or the Flexible Data-rate Controller Area Network (CAN FD) protocol. Implementing RCP using the 10BASE-T1S solution would require a complete replacement of the existing physical layer infrastructure corresponding to the CAN protocol, resulting in high migration costs. Finally, the protocol overhead is significant. During the encapsulation of RCP service data, firstly, the application layer of the master device generates the RCP service data (i.e., payload data) and transmits it down to the transport layer. Then, based on the User Datagram Protocol (UDP), the transport layer of the master device adds an 8-byte UDP header to the RCP service data, encapsulates it to generate a UDP data segment, and transmits the UDP data segment down to the network layer. Next, based on the Internet Protocol (IP), the network layer of the master device adds a 20-byte IP header to the UDP data segment, encapsulates it to generate an IP packet, and passes the IP packet down to the Ethernet protocol at the data link layer (IEEE 802.3cg Ethernet in the 10BASE-T1S scenario). Finally, at the data link layer of the master device, an Ethernet frame header and trailer are added to the IP packet to generate a complete Ethernet frame. This Ethernet frame can be transmitted to the edge device at a rate of 10 Mbit / s via the 10BASE-T1S physical layer on a single-pair twisted-pair bus. At the edge device, the IP header and UDP header need to be stripped layer by layer to reconstruct the RCP service data. It is evident that this approach incurs significant redundant overhead: the IP header and UDP header occupy at least 28 bytes. When transmitting minute control instructions (e.g., General Purpose Input / Output (GPIO) toggle instructions, whose effective data may only be a few bytes), the overhead of the data frame header fields accounts for a very high proportion, wasting valuable payload resources. At the same time, the introduction of complete IP and UDP layers into the protocol stack increases the software complexity and processing latency of the master control device and edge devices, which is particularly detrimental to the MCU-less design of edge devices.

[0027] The technical solutions of the present invention will now be clearly and completely described with reference to the accompanying drawings in the embodiments of the present invention.

[0028] Figure 1 This is a schematic diagram illustrating the implementation process of a communication method provided by the present invention, wherein the communication method is applied to a master control device.

[0029] Here, the master control device can be the control center of the vehicle communication system used to implement the communication method. In some embodiments, the master control device can be deployed on the vehicle's area controller or central computing platform to perform functions such as executing control algorithms, initiating remote read / write requests, managing security policies, and global time synchronization.

[0030] In some implementations, the master control device is used to execute the RCP control algorithm, initiate remote read / write requests, manage security policies, and perform global time synchronization. In some implementations, the master control device may be based on an AURIX™ TC4xx series chip with a clock speed of 400MHz or other automotive processors.

[0031] like Figure 1 As shown, the communication method applied to the master control device includes the following steps S11 to S14: Step S11: Obtain control commands.

[0032] Here, control commands can refer to commands that control the vehicle to perform any function. In some implementations, control commands can be control commands for any edge device in the vehicle.

[0033] In some implementations, control commands can be raw commands or sets of parameters received by the master control device and used to trigger a specific operation. In some implementations, control commands may include the object of operation (e.g., left front headlight, seat heater, HVAC damper), the type of operation (e.g., on, off, adjust), and operation-related parameters (e.g., brightness level, temperature setpoint, duty cycle). For example, one control command might be to adjust the brightness of the left front headlight to 50%; another control command might be to activate the intermittent wiper mode.

[0034] In some implementations, the sources of control commands are diverse. In some implementations, control commands may come from user input through the in-vehicle human-machine interface (HMI), driving decisions generated by the autonomous driving system, detection requests issued by the diagnostic system, or configuration commands in OTA update packages, etc.

[0035] Step S12: Determine the target service primitive according to the control command; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol.

[0036] Here, the first communication protocol represents the Remote Control Protocol (RCP), and RCP is an application layer communication protocol. RCP is a communication protocol that adopts a client-server model; where the client-server model refers to a distributed communication interaction paradigm, with the two communicating parties being a client and a server, respectively. The client actively initiates a request, and the server receives the request, completes the business processing, and returns a response message. Therefore, in the communication method provided by this invention, the master control device can be used as the client, and the slave device as the server.

[0037] Meanwhile, as mentioned above, RCP migrates the protocol conversion function in the edge device controller to the area controller or even the central controller, making the edge devices lighter. In some embodiments, the protocol conversion function in the slave device is partially or completely migrated to the master control device to achieve software centralization in the network and lightweight slave devices.

[0038] The service primitives corresponding to the first communication protocol refer to the standardized interactive commands and their corresponding parameter values ​​corresponding to the first communication protocol. In some implementations, the service primitives corresponding to the first communication protocol are, i.e., RCP service messages or RCP service primitives.

[0039] In some implementations, the service primitives corresponding to the first communication protocol are in a compact binary encoding format to maximize payload utilization.

[0040] In some implementations, RCP service primitives include fields related to specific operations. In some implementations, the RCP service primitive includes at least the following fields: Slave Device Identifier (ID), used to locate the slave device to be operated by the control command; Service Type field, used to identify the operation type corresponding to the control command, such as General Purpose Input Output Write (GPIO_WRITE), General Purpose Input Output Read (GPIO_READ), Pulse Width Modulation Set (PWM_SET), Analog-to-Digital Converter Read (ADC_READ), Inter-Integrated Circuit Transfer (I2C_TRANSFER), Serial Peripheral Interface Transfer (SPI_TRANSFER), etc.; Operation parameters, such as the GPIO port number corresponding to GPIO_WRITE or GPIO_READ, the duty cycle corresponding to PWM_SET, etc.; Service Priority, indicating the priority set according to the real-time and safety criticality of the RCP service primitive. For example, the service primitive of the GPIO_READ instruction can be encoded as [service type, slave device ID, GPIO port number, target level], which is 4 bytes in total; another example is that the service primitive of the PWM_SET instruction can be encoded as [service type, slave device ID, channel number, duty cycle], which is 4 bytes in total.

[0041] In some implementations, the application layer of the master control device can convert the received control commands into standardized target service primitives. Accordingly, the application layer of the master control device can also be called the RCP service adaptation layer.

[0042] In some implementations, the application layer of the master control device can parse the received control commands to match the service primitives corresponding to the first communication protocol, extract operation parameters, and then generate target service primitives according to predetermined binary encoding rules. For example, when the control command is to turn on the left front headlight, the application layer of the master control device will determine the service type of the control command as GPIO_WRITE, set the slave device ID to the left front headlight ID, the GPIO port to, for example, the PA5 port, and the target level to high level, and finally generate a binary target service primitive.

[0043] Step S13: Determine the target data frame according to the target service primitive; the target data frame represents the data frame corresponding to the second communication protocol; the first communication protocol is different from the second communication protocol.

[0044] Here, the second communication protocol is a different communication protocol from the first communication protocol. In some embodiments, the second communication protocol can be the CAN protocol. In some embodiments, the second communication protocol can be the first-generation CAN communication protocol, the second-generation CAN communication protocol (i.e., CAN FD), or the third-generation CAN communication protocol (i.e., CAN XL).

[0045] Thus, after determining the target service primitive, the target service primitive is directly encapsulated as a payload within the data segment corresponding to the second communication protocol, according to the data frame structure of the second communication protocol, to obtain the target data frame. For example, in the case of CAN XL as the second communication protocol, the target service primitive is encapsulated as a payload within the data segment of the CAN XL data frame to obtain the target data frame. It is evident that this framing operation achieves seamless integration between the first and second communication protocols.

[0046] In some implementations, the target service primitive can be encapsulated as a payload into a target data frame using the data link layer of the master device.

[0047] Step S14: Send the target data frame to the slave device.

[0048] Here, "slave device" refers to an edge device in the vehicle controlled by the master control device. For example, a slave device can be headlights, doors and windows, seats, HVAC dampers, windshield wipers, various sensors and actuators, etc. In some implementations, a slave device can be a remote peripheral node with no MCU or a simplified MCU design. In some implementations, the slave device only needs to retain a transceiver conforming to a second communication protocol (e.g., CAN XL) and some interface logic (e.g., GPIO outputs, ADC sampling paths, etc.).

[0049] Since the target data frame is the data frame corresponding to the second communication protocol, after determining the target data frame, the master control device sends the target data frame to the slave device through the physical bus corresponding to the second communication protocol.

[0050] As can be seen from the above, in the communication method for a master control device provided by the present invention, firstly, a control command is acquired; then, according to the control command, a target service primitive is determined, wherein the target service primitive represents a service primitive corresponding to a first communication protocol, and the first communication protocol represents a remote control protocol; subsequently, according to the target service primitive, a target data frame is determined, wherein the target data frame represents a data frame corresponding to a second communication protocol, and the first communication protocol is different from the second communication protocol; finally, the target data frame is sent to the slave device. Thus, on the one hand, the master control device in the present invention uses a first communication protocol (i.e., RCP) to generate the target service primitive and interacts with the slave device based on the target service primitive. It is evident that the present solution employs the RCP communication framework, thereby concentrating the software on the master control device and achieving lightweighting of the slave device. On the other hand, compared to related technologies that add IP and UDP headers to RCP service data, this invention directly encapsulates the RCP service data (i.e., the target service primitive) as the payload into the data segment of the data frame corresponding to the second communication protocol. This eliminates the need for at least 28 bytes of header fields required for encapsulating IP and UDP headers, thereby reducing protocol overhead, increasing the proportion of the payload in the target data frame, and thus improving communication efficiency and bandwidth utilization. This effect of increasing the payload proportion is particularly noticeable in the transmission of small control instructions. For example, experimental results show that for small control instructions (e.g., GPIO operations with a payload of 1 to 4 bytes), the payload proportion in the target data frame generated by this method can be increased to nearly 100%, compared to less than 20% in the data frame generated by the existing method. At the same time, since the UDP and IP layers are removed from the master and slave devices, the protocol stack complexity and processing latency are reduced.

[0051] In some implementations, the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier.

[0052] Here, the bus network corresponding to the second communication protocol refers to the physical bus or cable corresponding to the second communication protocol.

[0053] Multiple Virtual Local Area Networks (VLANs) refer to multiple isolated and logically independent virtual communication networks created by dividing the bus network using software or protocol layer logic without changing the hardware cabling of the bus network. These multiple VLANs are implemented using the same physical bus network, eliminating the need for separate physical lines for each VLAN, thus significantly reducing cabling costs and weight. Furthermore, traffic between different VLANs is isolated, and each VLAN can be independently configured with scheduling policies, bandwidth allocation, and security policies, thus offering high flexibility.

[0054] Each virtual communication network has a corresponding virtual network identifier to achieve logical segmentation of the physical bus network.

[0055] Thus, the communication method further includes the following step S15: Step S15: Determine the target virtual network identifier from multiple virtual network identifiers based on the target service primitive.

[0056] Here, after determining the target service primitive, the master control device can determine the target virtual network identifier based on the target service primitive.

[0057] In some implementations, the master control device can determine the target virtual network identifier corresponding to the target service primitive using any method. In some implementations, the master control device can determine the target virtual network identifier based on the service type corresponding to the target service primitive. For example, if the service type corresponding to the target service primitive is real-time control, the first virtual network identifier is determined as the target virtual network identifier; while if the service type corresponding to the target service primitive is non-real-time control, the second virtual network identifier is determined as the target virtual network identifier. In some implementations, the master control device can determine the target virtual network identifier based on the device identifier of the slave device corresponding to the target service primitive; wherein different virtual network identifiers correspond to different sets of slave device identifiers. For example, if the slave device identifier corresponding to the target service primitive belongs to the first set of slave device identifiers, the third virtual network identifier is determined as the target virtual network identifier; while if the slave device identifier corresponding to the target service primitive belongs to the second set of slave device identifiers, the fourth virtual network identifier is determined as the target virtual network identifier.

[0058] Thus, determining the target data frame based on the service primitive, i.e., step S13 above, can be implemented as the following step S131: Step S131: Encapsulate the target service primitive into the data segment of the target data frame; place the target virtual network identifier in the frame header control segment of the target data frame.

[0059] Here, the data segment of the target data frame refers to the field in the target data frame used to encapsulate the payload.

[0060] The frame header control segment of the target data frame refers to the field in the header of the target data frame used to carry control information. In some embodiments, the frame header control segment includes a Virtual Network Identifier (VNI) segment, which encapsulates a target virtual network identifier so that the slave device can determine whether the target data frame belongs to the target data frame to be processed by the slave device based on the target virtual network identifier. In some embodiments, the frame header control segment includes a Service Data Unit (SDN) type segment, which indicates the upper-layer protocol type used by the payload in the data segment; wherein, the upper-layer protocol type used by the payload in the data segment refers to the communication protocol type used to generate the payload. It can be understood that in this scheme, the upper-layer protocol used by the payload in the data segment refers to the protocol type corresponding to the target service primitive, i.e., RCP. Thus, in this scheme, the SDN type segment in the frame header of the target data frame is used to indicate RCP.

[0061] Thus, after determining the target virtual network identifier, it is encapsulated in the control segment of the target data frame header to guide the slave device in performing hardware-level filtering; the target service primitive is encapsulated in the data segment of the target data frame to enable the slave device to identify the specific service request. In some implementations, multiple target service primitives corresponding to control commands can be transmitted in a single target data frame to fully utilize the payload of the target data frame.

[0062] As can be seen from the above, in the embodiments provided by the present invention, a virtual network identifier mechanism is introduced, and the virtual network identifier is placed in the frame header control segment of the target data frame. At the same time, the target service primitive is directly encapsulated in the data segment of the target data frame. In this way, logical isolation of multiple virtual communication networks on the same physical bus can be achieved, thereby avoiding interference between communications of different security levels or functional domains, and thus improving the overall security and communication efficiency of the system.

[0063] In some implementations, determining the target virtual network identifier from multiple virtual network identifiers based on the target service primitive, i.e., step S15 above, can be implemented as the following step S151: Step S151: Determine the target virtual network identifier from multiple virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive. The communication direction includes either uplink communication or downlink communication; when the sending end is the master control device, the communication direction corresponding to the target service primitive represents downlink communication; when the sending end is the slave device, the communication direction corresponding to the target service primitive represents uplink communication. The service type represents the operation type corresponding to the target service primitive; The safety level represents the vehicle's safety integrity level.

[0064] Here, communication direction refers to the direction of information flow during data transmission. The communication direction corresponding to the target service primitive is either uplink or downlink communication.

[0065] Downlink communication refers to the data transmission direction from the master device to the slave device; that is, the data sender is the master device, and the data receiver is the slave device. For example, when the master device sends control commands or configuration parameters to the slave device, the communication direction is downlink communication.

[0066] Uplink communication refers to the data transmission direction from the slave device to the master device; that is, the data sender is the slave device and the data receiver is the master device. For example, when the slave device sends status information or reports diagnostic information to the master device, the communication direction is uplink communication.

[0067] In this way, by determining the target virtual network identifier corresponding to the target service primitive based on the communication direction corresponding to the target service primitive, logical isolation of bidirectional data streams can be achieved, avoiding mutual interference between uplink and downlink data streams.

[0068] Service type refers to the operation type corresponding to the target service primitive. For example, the service type corresponding to the target service primitive may include GPIO_WRITE, GPIO_READ, PWM_SET, ADC_READ, I2C_TRANSFER, SPI_TRANSFER, etc.

[0069] Thus, when the master control device determines the target virtual network identifier based on the service type corresponding to the target service primitive, it first determines whether the service type corresponding to the target service primitive is a real-time control type. Then, if the service type corresponding to the target service primitive is real-time control, it determines the target virtual network identifier corresponding to the real-time control service for the target service primitive. Correspondingly, if the service type corresponding to the target service primitive is non-real-time control, it determines the target virtual network identifier corresponding to the non-real-time control service for the target service primitive. For example, in the service types in the above example, GPIO_WRITE is real-time control, GPIO_READ is non-real-time control (e.g., in interrupt mode) or real-time control (e.g., in polling mode, under fault detection), PWM_SET is real-time control, ADC_READ is non-real-time control, I2C_TRANSFER is non-real-time control, SPI_TRANSFER is non-real-time control, etc.

[0070] Safety level, as defined in ISO 26262 "Road vehicles, functional safety", classifies risk levels into Quality Management (QM) and Automotive Safety Integrity Level (ASIL). QM indicates that a failure of the corresponding function will not cause safety hazards, and only routine quality control is required. ASIL includes ASIL-A, ASIL-B, ASIL-C, and ASIL-D; ASIL-A represents the lowest safety integrity level; ASIL-B represents a medium safety integrity level; ASIL-C represents a higher safety integrity level; and ASIL-D represents the highest safety integrity level. In some implementations, a corresponding safety level is configured for each control command or service primitive during the vehicle control system design phase.

[0071] In some implementations, different security levels may correspond to the same or different virtual network identifiers. For example, security levels QM and ASIL-A correspond to the same virtual network identifier, while ASIL-A, ASIL-B, ASIL-C, and ASIL-D correspond to different virtual network identifiers.

[0072] In this way, the master control device can determine the target virtual network identifier corresponding to the target service primitive based on the security level corresponding to the target service primitive.

[0073] As can be seen, the mapping mechanism based on security level and virtual network identifier can realize the logical isolation of data streams of different security levels, and avoid the failure of high security level functions caused by low security level failures. At the same time, dedicated bandwidth time slots can be allocated for control commands or service primitives of high security level (e.g., ASIL-D) to ensure low-latency transmission of control commands or service primitives of high security level and avoid bus congestion affecting the response of security functions.

[0074] The device type of a slave device can refer to the classification of slave devices according to their functions. For example, a slave device could be a sensor, actuator, or area controller. Different device types have different hardware interface requirements and communication characteristics. For instance, sensors are typically used to collect environmental data (e.g., temperature and pressure data), actuators are used to drive mechanical components (e.g., motors and solenoid valves), and area controllers are responsible for local control logic. Therefore, by determining the corresponding virtual network identifier based on the device type of the slave device corresponding to the service primitive, slave devices of the same type or those used to implement related functions can be mapped to the same virtual network identifier. In this way, the master device can send control commands to multiple slave devices of the same device type at once via multicast messages, significantly reducing the amount of data transmitted on the bus and improving communication efficiency. In addition, dedicated bandwidth time slots can be allocated to the corresponding virtual communication network based on the communication characteristics of slave devices of different types to ensure deterministic data transmission.

[0075] Here, the master device can determine the target virtual network identifier corresponding to the target service primitive from multiple virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive. In some implementations, a mapping relationship between at least one of the communication direction, service type, security level, and device type of the slave device and multiple virtual network identifiers can be pre-established, thereby enabling the master device to determine the target virtual network identifier based on the mapping relationship.

[0076] For example, when determining the target virtual network identifier based on communication direction, service type, security level, and slave device type simultaneously, the master control device can maintain a mapping table between communication direction, service type, security level, slave device type, and multiple virtual network identifiers. In this way, the master control device can look up the mapping table based on the quadruple data (communication direction, service type, security level, slave device type) corresponding to the target service primitive, thereby outputting a unique target virtual network identifier. For example, if the quadruple data corresponding to the target service primitive is (uplink communication, GPIO_READ, ASIL-D, brake), the master control device determines the target virtual network identifier as "0x10" based on the mapping table; as another example, if the quadruple data corresponding to the target service primitive is (downlink communication, diagnostic service type, QM, sensor), the master control device determines the target virtual network identifier as "0x20" based on the mapping table. In some implementations, this mapping table can be a default mapping configuration table or can be dynamically updated by the user to support flexible network management.

[0077] In some implementations, a local virtual network identifier whitelist can be maintained in the slave device to perform hardware-level filtering on the target data frame based on the whitelist. That is, if the target virtual network identifier in the target data frame is in the slave device's whitelist, the slave device continues to process the target data frame; if the target virtual network identifier in the target data frame is not in the slave device's whitelist, the slave device discards the target data frame.

[0078] As can be seen from the above, in the embodiments provided by the present invention, the target virtual network identifier is determined based on at least one of the following: the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive. This enables a multi-dimensional virtual network identifier allocation strategy and achieves secure isolation and efficient routing at the physical bus level, thereby improving the reliability and security of the system.

[0079] In some implementations, the second communication protocol characterizes a controller area network extended length protocol.

[0080] Here, Controller Area Network Extra Long (CAN XL) is the third-generation evolution of the CAN protocol, designed to address the limitations of classic CAN and CAN FD protocols in terms of bandwidth, payload capacity, and flexibility. CAN XL supports data segment transmission rates up to 20 Mbit / s; the maximum payload per frame of CAN XL can reach 2048 bytes, far exceeding the 64 bytes of classic CAN and the 128 bytes of CAN FD. Furthermore, CAN XL is compatible with the physical layer structures of CAN FD and classic CAN protocols, using the same CAN_H and CAN_L twisted-pair cables.

[0081] The CAN XL protocol supports the Virtual CAN Network ID (VCID) field, which allows up to 256 logically isolated virtual communication networks to be implemented on the same physical bus, enabling multi-domain secure communication.

[0082] The CAN XL protocol also supports a Service Data Unit Type (SDT) field to indicate the type of upper-layer protocol used by the payload in the data segment (e.g., CAN protocol, CAN FD protocol, RCP, Ethernet frame tunnel, etc.), which facilitates quick identification and filtering by the receiver.

[0083] The ISO 11898-1:2024 standard divides the data link layer corresponding to the CAN protocol into a logical link control (LLC) sublayer and a media access control (MAC) sublayer, and determines the SDT and VCID through the LLC sublayer.

[0084] Here, the second communication protocol is implemented as the CAN XL protocol.

[0085] In this way, the LLC sublayer in the master control device can determine the target virtual network identifier (i.e., the target VCID) from multiple virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive, and determine the value of the SDT field based on the upper-layer communication protocol corresponding to the target service primitive being RCP; then, the MAC sublayer in the master control device encapsulates the target service primitive as a payload into the data segment of the CAN XL data frame, and encapsulates the target VCID and SDT values ​​determined by the LLC sublayer into the VCID field and SDT field of the CAN XL data frame, respectively, to obtain the target data frame.

[0086] Meanwhile, the LLC sublayer in the slave device can maintain a VCID whitelist. Thus, upon receiving a target data frame, the LLC sublayer of the slave device can perform hardware-level filtering based on this VCID whitelist. Specifically, if the target virtual network identifier in the target data frame is in the LLC's VCID whitelist, the LLC sublayer will pass the target service primitive in the target data frame to the slave device's application layer for further processing; if the target virtual network identifier in the target data frame is not in the LLC sublayer's VCID whitelist, the LLC sublayer will discard the target data frame without generating any upper-layer interrupts, thereby achieving hardware-level security isolation and protocol filtering at the physical bus level.

[0087] Furthermore, there is a clear bearer relationship between RCP and the CAN XL protocol: RCP, as an application layer protocol, directly encapsulates RCP service primitives (i.e., target service primitives) into the payload of CAN XL data frames without requiring tunneling processing through intermediate protocols such as UDP and IP. This direct bearer mode, on the one hand, reduces header overhead, increases the effective payload ratio, and improves communication efficiency; on the other hand, it simplifies protocol stack complexity and reduces data processing latency. Specifically, both the master and slave devices omit the UDP and IP protocol layers. The LLC sublayer in the slave device can deliver the payload to the application layer (i.e., the RCP service adaptation layer) after completing VCID filtering, without the need for layer-by-layer decapsulation. This significantly shortens the data processing path and reduces forwarding latency, facilitating MCU-less or minimally MCU-based designs for slave devices.

[0088] Furthermore, implementing the second communication protocol as the CAN XL protocol allows this communication method to inherit the aforementioned communication advantages of the CAN XL protocol. For example, it can fully retain the native capabilities of the CAN XL protocol, such as high bandwidth (e.g., data segment transmission rate up to 20 Mbit / s), large payload (e.g., maximum payload of 2048 bytes per frame), and virtual network isolation (e.g., support for up to 256 VCIDs). At the same time, the SDT field in the CAN XL protocol can be used to clearly distinguish RCP service primitives from other possible tunnel data, achieving clear isolation at the protocol level.

[0089] Meanwhile, since the CAN XL protocol is compatible with the physical layers of the CAN FD and classic CAN protocols, it retains the twisted-pair structure of CAN_H and CAN_L. Therefore, implementing the second communication protocol as the CAN XL protocol allows for a smooth upgrade of the existing infrastructure corresponding to the CAN and CANFD protocols, thereby maximizing the protection of existing assets and reducing the implementation cost of the RCP communication architecture.

[0090] As can be seen from the above, in the embodiments provided by the present invention, by implementing the second communication protocol as the CAN XL protocol and directly encapsulating the RCP service primitive (i.e., the target service primitive) as the payload in the data segment of the CAN XL data frame, the overhead of at least 28 bytes caused by the tunnel encapsulation of the UDP layer and IP layer in the traditional RCP scheme can be eliminated, thereby significantly increasing the effective payload ratio and simplifying the protocol stack complexity; at the same time, it can also inherit the communication advantages of the CAN XL protocol, be compatible with the CAN ecosystem, and reduce the implementation cost of the RCP communication architecture.

[0091] In some implementations, the communication method further includes the step S16: Step S16: Determine the target arbitration priority based on the service priority corresponding to the target service primitive.

[0092] Since RCP service primitives have corresponding service priorities, and these priorities are set based on the real-time and security criticality of the target service primitive (or the control command corresponding to the target service primitive) to distinguish the urgency and importance of different RCP service requests, the target arbitration priority corresponding to the target service primitive can be determined based on its service priority. It is understandable that the higher the service priority of the target service primitive, the higher the target arbitration priority assigned to that primitive.

[0093] In some implementations, a mapping relationship between service priority and arbitration priority can be pre-configured, and then the target arbitration priority corresponding to the target service primitive can be determined based on the mapping relationship and the service priority corresponding to the target service primitive.

[0094] In some implementations, the target arbitration priority corresponding to the target service primitive can be determined using the LLC sublayer in the master control device. For example, the LLC sublayer can maintain the mapping relationship between service priorities and arbitration priorities, and then determine the target arbitration priority based on this mapping relationship.

[0095] The target arbitration priority directly affects the arbitration order of target data frames on the bus. In some implementations, the higher the target arbitration priority, the smaller the corresponding target arbitration priority identifier (PID) value, and the easier it is to obtain the right to transmit in bus contention.

[0096] Thus, determining the target data frame based on the service primitive, i.e., step S13 above, can be implemented as the following step S132: Step S132: Place the target arbitration priority in the arbitration segment of the target data frame; encapsulate the target service primitive into the data segment of the target data frame.

[0097] The arbitration segment of the target data frame refers to the field in the header of the target data frame used to carry arbitration information.

[0098] After determining the target arbitration priority, the target PID corresponding to the target arbitration priority is encapsulated in the arbitration segment of the target data frame; the target service primitive is encapsulated in the data segment of the target data frame so that the slave node can identify the specific service request.

[0099] In some implementations, the master device includes a CAN XL controller for implementing bus arbitration functionality. During the master device's initialization phase, the CAN XL controller is initialized to configure the arbitration segment rate. In some implementations, the CAN XL controller's arbitration segment rate is between 500 Kbit / s and 1 Mbit / s.

[0100] As can be seen from the above, in the embodiments provided by the present invention, by establishing a mapping relationship between the service priority and arbitration priority corresponding to the service primitive, fine-grained scheduling of different types of RCP service requests can be achieved, ensuring that high-security and / or high-real-time control commands are transmitted first, avoiding delays in critical control commands due to low-PID tasks preempting the bus, thereby improving the functional safety and response reliability of the whole vehicle system.

[0101] In some implementations, CAN XL data frames carrying RCP service primitives, such as Figure 2 As shown. The CAN XL data frame 200 includes the following fields: PID field 21: Used to encapsulate the arbitration priority identifier corresponding to the CAN XL data frame; in some implementations, PID field 21 may occupy 11 bits; XL Format (XLF) field 22: Used to identify whether the current data frame is a CAN XL data frame or a CANFD data frame; when the XLF field 22 is recessive, that is, when the logical value of the XLF field 22 is "1", it indicates that the current data frame is a CAN XL data frame; when the XLF field 22 is dominant, that is, when the logical value of the XLF field 22 is "0", it indicates that the current data frame is a CAN FD data frame; in some implementations, the XLF field 22 occupies 1 bit; Arbitration-to-Dataphase Switch (ADS) field 23: A trigger field used to achieve a smooth switch from arbitration mode to data transmission mode; SDT field 24: Used to indicate the type of upper-layer protocol used by the payload in the data segment; VCID field 25: Used to indicate the identifier of the virtual network corresponding to the current CAN XL data frame 200; in some implementations, VCID field 25 occupies 8 bits; The Simple / Extended Content (SEC) field 26 is used to notify the MAC and LLC sublayers of the slave device whether the current CAN XL data frame 200 contains an extended header and to support CANsec (link layer security extension). When the logical value of the SEC field 26 is "0", it indicates that there is no additional extended functionality and the data segment is the payload. When the logical value of the SEC field 26 is "1", it indicates that the data segment contains an extended header, and the extended header needs to be stripped before the payload can be extracted. Data Length Code (DLC) field 27: Used to indicate the byte length of the payload of the current data frame; in some implementations, DLC field 27 occupies 11 bits; Acceptance Field (AF) 28: Used for addressing and frame reception filtering; in some implementations, AF field 28 occupies 32 bits; Data (DATA) field 29: Used to carry the payload; in some implementations, DATA field 29 occupies 1 to 2048 bits; Preamble Cyclic Redundancy Check (PCRC) field 210: This is a check field used to verify the integrity of information between the arbitration section and the control section; in some implementations, the PCRC field 210 occupies 13 bits. Frame Cyclic Redundancy Check (FCRC) field 211: This is a check field used to verify the integrity of the entire frame of data; in some implementations, FCRC field 211 occupies 32 bits. Format Check Pattern (FCP) field 212: This is a bitstream check field used to check whether the bitstream at the receiving end has been offset or misaligned; in some implementations, FCP field 212 occupies 4 bits.

[0102] Below, in conjunction with Figure 3 The following describes an embodiment of the present invention in which the master control device 300 sends an RCP service request; wherein the second communication protocol is implemented as the CAN XL protocol. Figure 3 As shown, this embodiment includes the following steps S31 to S36: Step S31: The application layer 310 of the main control device 300 receives the control command 301; In some implementations, the application layer 310 (i.e., the RCP service adaptation layer) of the master control device receives control commands issued by the upper-layer control algorithm, or control commands determined based on user-triggered operations.

[0103] Before executing step S31, the master control device is initialized. This includes: loading the RCP device mapping table, which records the logical address, device type, security level, and corresponding VCID allocation scheme of each slave device in the vehicle; initializing the CAN XL controller to configure the arbitration segment rate (e.g., 500 Kbit / s to 1 Mbit / s) and the default data segment rate (e.g., a maximum rate of 20 Mbit / s); activating each CAN XL transceiver and completing bus status detection.

[0104] In some implementations, the LLC sublayer 320 of the master device maintains a VCID mapping table. In some implementations, this VCID mapping table uses a quadruple of data (communication direction, service type, security level, slave device type) as the index key to output unique VCID values.

[0105] Step S32, the application layer 310 determines the standardized RCP service primitive 302 corresponding to the control command 301; In some implementations, the RCP service primitive 302 includes at least the following fields: The RCP service primitive includes at least the following fields: target slave device ID (used to locate the slave device), service type field (used to identify, for example, operation type such as GPIO_WRITE, GPIO_READ, PWM_SET, ADC_READ, I2C_TRANSFER, SPI_TRANSFER, etc.), operation parameters (for example, GPIO pin number, target level, etc.), and service priority.

[0106] In some implementations, the RCP service primitive 302 is encoded in a compact binary format.

[0107] In step S33, the LLC sublayer 320 in the master device 300 determines the VCID 303 and SDT value 304 corresponding to the RCP service primitive 302; and submits the RCP service primitive 302, VCID 303 and SDT value 304 to the MAC sublayer 330 of the slave device. In some implementations, the LLC sublayer 320 can query the VCID mapping table based on the communication direction, service type, security level, and slave device type information in the RCP service primitive 302 to determine the VCID 303 corresponding to the RCP service primitive 302.

[0108] The SDT value 304, set by LLC sublayer 320, is used to indicate the "RCP native protocol" type identifier. For example, the SDT value 304 can be set to "0x10", or other user-defined reserved values ​​in the CAN XL specification, to distinguish it from Ethernet data frames, classic CAN data frames, CAN FD data frames, etc.

[0109] Based on the service priority in RCP service primitive 302, LLC sublayer 320 sets the PID corresponding to RCP service primitive 302.

[0110] Step S34: The MAC sublayer 330 of the master control device 300 encapsulates the CAN XL data frame to obtain the target CAN XL data frame 305; and submits the target CAN XL data frame 305 to the physical coding sublayer (PCS) 340 of the master control device. Here, based on the PID corresponding to RCP service primitive 302, the MAC sublayer sets the arbitration field in the target CAN XL data frame 305; Set the XLF field in the frame header of the target CAN XL data frame 305 to be implicit to indicate that the current data frame is a CAN XL data frame; Based on the determined SDT value 304, set the SDT field in the target CAN XL data frame 305; Based on the determined VCID 303, set the VCID field in the target CAN XL data frame 305; The binary code corresponding to RCP service primitive 302 is directly loaded into the data segment of the target CAN XL frame 305 as the payload.

[0111] Here, the payload length of a CAN XL data frame does not exceed 2048 bytes, and for a single control command, the payload length is typically much less than 64 bytes. Therefore, multiple RCP service primitives corresponding to control commands can be transmitted in a single CAN XL data frame to fully utilize the large payload capacity of CAN XL.

[0112] In step S35, PCS 340 encodes the target CAN XL data frame 305 to obtain the binary bit stream 306 corresponding to the target CAN XL data frame 305; and submits the binary bit stream 306 to the physical medium attachment (PMA) 350 of the master control device. In step S36, the PMA 350 serializes the bit stream 306 and sends it to the CAN XL bus 360.

[0113] Here, the PMA 350 is used as the CAN XL transceiver for the main control device.

[0114] In some implementations, during the transmission phase of the target CAN XL data frame 305, bus arbitration is performed. Specifically, the target CAN XL data frame is first pushed into the hardware transmission queue to participate in non-destructive bit-by-bit arbitration. Then, after successful arbitration, the arbitration segment is transmitted at the arbitration segment rate. After the ADS field, the transmission switches to the data segment rate to transmit the payload (i.e., the target CAN XL data frame containing the payload is transmitted). After transmission is complete, the bus is released.

[0115] On the other hand, the present invention also provides a communication method applied to a slave device. For example... Figure 4 As shown, the communication method includes the following steps S41 to S43: Step S41: Receive the target data frame sent by the master control device; the target data frame represents the data frame corresponding to the second communication protocol.

[0116] The process of generating the target data frame can be found in the detailed description of the various embodiments of the communication method applied to the master control device described above, and will not be repeated here.

[0117] In some implementations, a transceiver in the slave device can continuously monitor signals on the bus network and begin receiving data frames when the start of frame (SOF) is detected.

[0118] In some implementations, the slave device includes a Physical Coding Sublayer (PCS) and a data link layer, which in turn includes a MAC sublayer and an LLC sublayer. Thus, during the reception of a target data frame: first, the PCS decodes the binary bitstream of the received target data frame, and the decoded target data frame is submitted to the MAC sublayer; then, the MAC sublayer verifies the decoded target data frame. If the verification fails, the target data frame is discarded; if the verification passes, the target data frame is submitted to the LLC sublayer of the slave device. In some implementations, the MAC sublayer can perform a Cyclic Redundancy Check (CRC) and a full-frame CRC on the target data frame.

[0119] Step S42: Determine the target service primitive in the target data frame; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol.

[0120] Here, the data segment content in the target data frame is read from the device to determine the target service primitive.

[0121] The target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents RCP. Here, the specific implementation method of the master control device determining the target service primitive can be found in the detailed description of the various embodiments of the communication method applied to the master control device above, and will not be repeated here.

[0122] In some implementations, target service primitives can be extracted from the target data frame from the device's LLC sublayer.

[0123] Step S43: Determine the control command corresponding to the target data frame based on the target service primitive.

[0124] Here, after determining the target service primitive, the target service primitive is parsed to identify the control instructions corresponding to the target data frame.

[0125] As mentioned above, RCP service primitives include at least a slave device identifier, a service type field, operation parameters, and service priority. Thus, by parsing the target service primitive, the service type corresponding to the target data frame (e.g., GPIO_WRITE, PWM_SET, or ADC_READ) can be identified. Then, based on the service type, the slave device identifier and operation parameters are extracted from the target service primitive, and the extracted slave device identifier is checked against the local device. If they do not match, the target data frame is discarded; if they match, processing of the target service primitive continues. Here, the parsed service type and operation parameters are used as the logical control instructions corresponding to the target data frame.

[0126] In some implementations, after determining the control instruction corresponding to the target data frame, the control instruction is converted into the format specification defined by the corresponding hardware driver interface (e.g., SPI, I2C, etc.) and sent to the corresponding hardware driver interface to execute the control instruction.

[0127] In some implementations, the slave device can also feed back the execution result to the master device. In some implementations, when the slave device feeds back the execution result to the master device, firstly, the application layer of the slave device encodes the execution result into an RCP service response primitive, wherein the field structure of the RCP service response primitive is aligned with the field structure of the RCP service request primitive, and also includes a status code and return data indicating the execution result; then, the data link layer of the slave device encapsulates the RCP service response primitive as a payload into a data segment of a data frame corresponding to the second communication protocol, obtaining a response data frame; finally, the response data frame is sent to the master device through the communication bus corresponding to the second communication protocol.

[0128] As can be seen from the above, in the communication method for slave devices provided by the present invention, firstly, a target data frame sent by the master device is received, wherein the target data frame represents a data frame corresponding to the second communication protocol; then, a target service primitive in the target data frame is determined, wherein the target service primitive represents a service primitive corresponding to the first communication protocol, and the first communication protocol represents a remote control protocol; finally, a control command corresponding to the target data frame is determined based on the target service primitive. Thus, on the one hand, the slave device in this solution interacts with the master device based on the target service primitive corresponding to the first communication protocol (i.e., RCP), indicating that the RCP communication framework is used in this solution, thereby concentrating the software on the master device and achieving lightweighting of the slave device. On the other hand, since the RCP service data (i.e., the target service primitive) in this solution is directly encapsulated as a payload in the data segment of the data frame corresponding to the second communication protocol, the slave device does not need to decapsulate the target data frame layer by layer, eliminating the need for the UDP layer used for decapsulating the UDP header and the IP layer used for decapsulating the IP header, thereby reducing the complexity of the slave device's protocol stack and processing latency, which is more conducive to the implementation of MCU-less or minimally simplistic MCU designs for the slave device.

[0129] In some implementations, the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier.

[0130] For details on the specific implementation of multiple virtual communication networks and their corresponding virtual network identifiers, please refer to the detailed explanation in the communication method applied to the master control device above; it will not be repeated here.

[0131] Thus, determining the target service primitive in the target data frame, i.e., step S42 above, can be implemented as the following steps S421 to S423: Step S421: Determine the target virtual network identifier in the target data frame.

[0132] For details on how to determine the target virtual network identifier in the target data frame, please refer to the detailed explanation in the communication method applied to the master control device above, which will not be repeated here.

[0133] The target virtual network identifier is encapsulated in the frame header control segment of the target data frame. Therefore, the target virtual network identifier can be determined by parsing the frame header control segment of the target data frame.

[0134] Step S422: If the target virtual network identifier matches the slave device, determine the target service primitive in the target data frame; Step S423: If the target virtual network identifier does not match the slave device, the target data frame is discarded.

[0135] Here, the slave device maintains a local virtual network identifier whitelist. Thus, if the target virtual network identifier is in the slave device's local virtual network identifier whitelist, it is determined that the target virtual network identifier matches the slave device; if the target virtual network identifier is not in the slave device's local virtual network identifier whitelist, it is determined that the target virtual network identifier does not match the slave device.

[0136] If the target virtual network identifier matches the slave device, the slave device continues to parse the target data frame to determine the target service primitive from the data segment of the target data frame.

[0137] If the target virtual network identifier does not match the slave device, the slave device discards the target data frame without further processing.

[0138] In some implementations, when using the LLC sublayer in the data link layer of the slave device to determine whether the target virtual network identifier matches the slave device, the LLC sublayer can determine whether to generate an upper-layer interrupt based on the determination result. That is, if they match, the LLC sublayer sends the target service primitive to the application layer of the slave device for data processing; if they do not match, the LLC sublayer discards the target data frame without generating any upper-layer interrupt, thereby achieving efficient and secure isolation at the physical bus level.

[0139] As can be seen from the above, in the embodiments provided by the present invention, by introducing a virtual communication network and a virtual network identification mechanism, the target data frame is finely identified and filtered, thereby realizing multi-domain parallel communication and security isolation at the physical bus level, and thus improving communication efficiency and system security.

[0140] In some implementations, the second communication protocol characterizes a controller area network extended length protocol.

[0141] Here, as mentioned above, implementing the second communication protocol as the CAN XL protocol can inherit the communication advantages of the CAN XL protocol, be compatible with the CAN ecosystem, and reduce the implementation cost of the RCP communication architecture. At the same time, since the RCP service primitive (i.e., the target service primitive) is directly encapsulated as the payload in the data segment of the CAN XL data frame, the LLC sublayer of the slave device can directly deliver the payload to the application layer (i.e., the RCP service adaptation layer) of the slave device after completing VCID and SDT filtering, without having to decapsulate the IP header and UDP header layer by layer, and without having to set up IP and UDP layers in the slave device. This significantly shortens the processing path and forwarding latency, which is beneficial for the slave device to achieve MCU-less or extremely simple MCU design.

[0142] In some implementations, where the second communication protocol represents the CAN XL protocol, the slave device may be a simplified MCU design or a design without an MCU, retaining only the CAN XL transceiver and input / output interface logic.

[0143] Below, in conjunction with Figure 5 An embodiment of the present invention, in which a slave device 500 receives and processes a target data frame sent by a master device, will be described; wherein, the second communication protocol is implemented as the CAN XL protocol. Figure 5 As shown, this embodiment includes the following steps S51 to S56: Step S51: The PMA layer 550 of the slave device 500 receives the binary bit stream 501 corresponding to the target CAN XL data frame from the CAN XL bus 560; and submits the binary bit stream 501 to the PCS 540 of the slave device. Here, the PMA layer 350 is used as a CAN XL transceiver in the slave device. The PMA layer 350 can continuously listen to the signals on the CAN XL bus 360, and start receiving operations after detecting the start of frame bit to obtain the binary bit stream 501 corresponding to the target CAN XL data frame.

[0144] In some implementations, the slave device 500 is initialized before receiving the target CAN XL data frame. Initialization of the slave device 500 includes the following steps: First, after powering on, the slave device 500's CAN XL controller is initialized to ensure that its arbitration segment rate and data segment rate are consistent with the master device; second, the VCID list to which the device belongs (i.e., the slave device 500's local virtual network identifier whitelist) is obtained from the master device through local pre-configuration or through network management data frames; third, the local application layer (i.e., the RCP service adaptation layer) is initialized to establish a mapping relationship between RCP service primitives and local hardware interfaces (e.g., GPIO, PWM, ADC, I2C, SPI, etc.).

[0145] In step S52, PCS 540 decodes the received bit stream 501 to obtain the decoded data 502 corresponding to the target CAN XL data frame; and submits the decoded data 502 to the MAC sublayer 530. In step S53, the MAC sublayer 530 deframes the decoded data 502 corresponding to the target CAN XL data frame (CAN XL Deframes) and verifies the preamble CRC and the full frame CRC; if the verification fails, the target CAN XL data frame is discarded; if the verification passes, the deframed target CAN XL data frame 503 is submitted to the LLC sublayer 520 of the slave device 500. In step S54, LLC sublayer 520 determines whether the VCID and SDT values ​​in the target CAN XL data frame 503 after deframed match with the slave device 500; if they match, the RCP service primitive 504 in the target CAN XL data frame is submitted to the application layer 510. Here, LLC sublayer 520 parses the VCID and SDT fields of the target data frame to extract the VCID and SDT values ​​corresponding to the target CAN XL data frame.

[0146] If the parsed VCID belongs to the local VCID list of slave device 500, and the SDT value indicates that the payload is RCP service data, then it is determined that the VCID and SDT value corresponding to the target CAN XL data frame match the slave device 500; if the VCID does not belong to the local VCID list of slave device 500, or the SDT value indicates that the payload is not RCP service data, then it is determined that the VCID and SDT value corresponding to the target CAN XL data frame do not match the slave device 500.

[0147] Step S55: Based on the RCP service primitive 504, the application layer 510 determines the control command corresponding to the target CAN XL data frame and executes the control command. Here, the service type field of the RCP service primitive 504 is parsed from the application layer 510 of device 500 to determine the operation type corresponding to the RCP service primitive 504; then, based on the operation type, the target slave device ID and operation parameters are extracted from the RCP service primitive 504; subsequently, if the target slave device ID does not match the ID of the current slave device 500, the RCP service primitive 504 is discarded; if the target slave device ID matches the ID of the current slave device 500, the parsed operation type and operation parameters are converted into hardware control instructions conforming to the communication protocol of the hardware driver interface, and the hardware control instructions are sent to the hardware driver interface to execute the corresponding hardware control operation.

[0148] Step S56: Send the execution result to the main control device.

[0149] Here, when the execution result is sent from device 500 to the master device, firstly, the application layer 510 of device 500 encodes the execution result into an RCP service response primitive. The field structure of this RCP service response primitive is aligned with the field structure of the RCP service request primitive, and it also includes a status code and return data to indicate the execution result. Then, the LLC sublayer 520 of device 500 determines the VCID and SDT values ​​corresponding to the RCP service response primitive. After that, the MAC sublayer 530 of device 500 encapsulates the RCP service response primitive as a payload into the data segment of a CAN XL data frame, and encapsulates the VCID and SDT values ​​corresponding to the RCP service response primitive into the VCID field and SDT field of the CAN XL data frame, respectively, to obtain a response data frame. Finally, the response data frame is sent to the master device via the CAN XL bus.

[0150] In some implementations, the LLC sublayer 520 of the device 500 maintains a VCID mapping table corresponding to RCP service request primitives and RCP service response primitives, so that the LLC sublayer 520 can directly determine the VCID used when returning the execution result to the master device, i.e., the VCID corresponding to the RCP service response primitive, based on the VCID corresponding to the RCP service primitive (i.e., the RCP service request primitive) sent by the master device and the VCID mapping table.

[0151] In some implementations, the LLC sublayer 520 of the slave device 500 can determine the VCID corresponding to the RCP service response primitive based on a preset offset. For example, if the preset offset is 8 bits, the LLC sublayer 520 of the slave device can add the offset to the value of the VCID corresponding to the RCP service request primitive to obtain the VCID corresponding to the RCP service response primitive.

[0152] It should be noted that the above descriptions of the communication method embodiments applied to the master control device and the communication method embodiments applied to the slave device are corresponding. Therefore, for any technical details not disclosed in the communication method embodiments applied to the slave device, please refer to the description of the communication method embodiments applied to the master control device.

[0153] Below, refer to Figure 6 An embodiment of the interaction between the master control device and the slave device is described; wherein, the control command issued by the master control device to the slave device is "turn on the left front headlight". Figure 6 As shown, this embodiment includes the following steps S61 to S614: S61, according to the control command, the application layer 610 of the master control device generates the RCP service primitive; then, step S62 is executed. For example, the service type field in the RCP service primitive generated by application layer 610 is "0x01", which means GPIO_WRITE; the slave device identifier field in the RCP service primitive is "0x0A", which means slave device ID; the operation parameter fields in the RCP service primitive are "0x05" and "0x01", which means that the GPIO pin corresponding to GPIO_WRITE is PA5 port and the level is high.

[0154] In step S62, the application layer 610 sends the RCP service primitive to the LLC sublayer 620 of the master device; then, step S63 is executed. Step S63: LLC sublayer 620 determines VCID based on the service type and slave device attributes corresponding to the RCP service primitive, and determines SDT value and PID; then, step S64 is executed. Here, the VCID corresponding to the downlink real-time control in the vehicle comfort domain is set to "0x01". The PID is set to medium priority (for example, the PID is set to "0x120"). The SDT value is set to "0x10" to indicate that the upper-layer protocol corresponding to the data segment load is RCP.

[0155] In step S64, the LLC sublayer 620 sends the RCP service primitive, VCID, SDT value and PID to the MAC sublayer 630 of the master control device; then, step S65 is executed. In step S65, the MAC sublayer 630 performs framing based on the information transmitted by the LLC sublayer 620 to obtain the target CAN XL data frame; then, step S66 is executed. Here, the MAC sublayer 630 sets the PID field to "0x120", the logical value of the XLF field to "1", the value of the SDT field to "0x10", and the value of the VCID field to "0x01", encapsulating the binary RCP service primitive into the data segment.

[0156] At the same time, the CRC check value is calculated based on the values ​​of the encapsulated XLF field, SDT field, VCID field, data segment, etc.

[0157] In step S66, the MAC sublayer 630 sends the target CAN XL data frame to the CAN XL bus 640 via the CAN XL transceiver in the slave device; then, step S67 is executed. Here, with the current bus load rate at 15%, the data transfer rate can be set to 20 Mbit / s to improve the data transfer speed.

[0158] Step S67: The slave device receives the target CAN XL data frame sent by the master device from the CAN XL transceiver and submits the target CAN XL data frame to the MAC sublayer 650 of the slave device; then, step S68 is executed. In step S68, the MAC sublayer 650 performs a CRC check on the target CAN XL data frame; if the check passes, proceed to step S69; if the check fails, discard the target CAN XL data frame. In step S69, the MAC sublayer 650 transmits the target CAN XL data frame to the LLC sublayer 660 of the slave device; then, step S610 is executed. In step S610, the LLC sublayer 660 of the slave device filters the target CAN XL data frame based on the VCID and SDT values ​​corresponding to the target CAN XL data frame. If the VCID corresponding to the target CAN XL data frame is in the slave device's local VCID list, and the SDT value indicates that the upper-layer protocol used by the payload in the data segment of the target CAN XL data frame is RCP, then the RCP service primitive in the data segment of the target CAN XL data frame is extracted; otherwise, the target CAN XL data frame is discarded. Then, step S611 is executed. In step S611, the LLC sublayer 660 submits the extracted RCP service primitives to the application layer 670 of the slave device; then, step S612 is executed. In step S612, the application layer 670 parses the RCP service primitive to determine that the service type is GPIO_WRITE, the slave device ID is "0x0A" and matches its own ID, and the operation parameters are "PA5" and "high level"; then, step S613 is executed. In step S613, the application layer 670 calls the function GPIO_WRITE(PA5, HIGH) to turn on the left front headlight 680; then, step S614 is executed. In step S614, the left front headlight 680 sends status information to the application layer 670 of the slave device.

[0159] Subsequently, the application layer 670 of the device can also generate an RCP service response primitive and send the RCP service response primitive to the master device via the CAN XL bus.

[0160] Below, in conjunction with Figure 7 The illustrated embodiment demonstrates the process of isolating multiple virtual communication networks based on VCID. Figure 7 As shown, this embodiment includes the following steps S71 to S78: In step S71, the application layer 711 in the master control device 710 generates the first RCP service primitive 701 and the second RCP service primitive 702; Here, the first RCP service primitive 701 means braking 50% pressure, with a service type of "PWM_SET", a slave device ID of "0x11", operating parameters of "channel 0", "duty cycle 50%", and a risk level of ASIL-D.

[0161] The second RCP service primitive 702 means "HVAC air blowing", with a service type of "GPIO_WRITE", a slave device ID of "0x20", operating parameters of "PA0" and "HIGH", and a risk level of body domain quality management (QM body).

[0162] In step S72, the application layer 711 submits the first RCP service primitive 701 and the second RCP service primitive 702 to the LLC sublayer 712 of the master device 710. In step S73, the LLC sublayer 712 determines the VCID, SDT value, PID and other information corresponding to the first RCP service primitive 701 and the second RCP service primitive 702 respectively; Here, LLC determines the first VCID (e.g., "0x10") corresponding to the first RCP service primitive 701 and the second VCID (e.g., "0x30") corresponding to the second RCP service primitive 702 based on the communication direction, service type, security level, and device type of the slave device corresponding to the first RCP service primitive 701 and the second RCP service primitive 702, respectively.

[0163] At the same time, LLC determines the first SDT value (e.g., "0x10", indicating that the upper layer protocol corresponding to the payload is RCP) and the first PID corresponding to the first RCP service primitive 701, and determines the second SDT value (e.g., "0x10", indicating that the upper layer protocol corresponding to the payload is RCP) and the second PID corresponding to the second RCP service primitive 702.

[0164] In step S74, the LLC sublayer 712 sends the first RCP service primitive 701 and its corresponding first VCID, first SDT value, first PID and other information, and the second RCP service primitive 702 and its corresponding first VCID, first SDT value, second PID and other information to the MAC sublayer 713 of the master control device. In step S75, the MAC sublayer 713 performs frame assembly to obtain the first data frame 703 corresponding to the first RCP service primitive 701 and the second data frame 704 corresponding to the second RCP service primitive 702. As shown above, in the first data frame 703, the SDT field value is "0x10", the VCID field value is "0x10", and the arbitration priority ID is "0x080" (determined by the LLC sublayer 712 based on the service priority, and representing a higher arbitration priority); in the second data frame 704, the SDT field value is "0x10", the VCID field value is "0x30", and the arbitration priority ID is "0x180" (determined by the LLC sublayer 712 based on the service priority, and representing a lower arbitration priority). In step S76, the MAC sublayer 713 sends the first data frame 703 and the second data frame 704 to the CAN XL bus 714. Here, since the arbitration priority of the first data frame 703 is higher than that of the second data frame 704, the first data frame 703 is sent first.

[0165] In step S77, the first slave device 715 and the second slave device 716 listen to the data frames in the CAN XL bus 714 and receive the first data frame 703 and the second data frame 704. In step S78, based on the VCID field in the first data frame 703 and the second data frame 704, the first slave device 715 discards the second data frame 704 and retains the first data frame 703, and the second slave device 716 discards the first data frame 703 and retains the second data frame 704.

[0166] Here, the local VCID list corresponding to the first slave device 715 includes VCIDs "0x10" and "0x11", and the local VCID list corresponding to the second slave device 716 includes VCID "0x30".

[0167] As can be seen, logical isolation of CAN XL data frames can be achieved through the VCID field in the CAN XL data frame.

[0168] As can be seen from the above embodiments, on the one hand, the present invention directly encapsulates the RCP service primitive as the payload into the data segment of the CAN XL data frame, removing the at least 28-byte header required for UDP and IP protocol tunnel encapsulation, reducing protocol stack complexity, thereby improving data transmission rate and reducing latency; on the other hand, the present invention fully retains the native capabilities of CAN XL, such as high bandwidth (e.g., the maximum data segment transmission rate is 20 Mbit / s), large payload (e.g., the maximum payload is 2048 bytes), and virtual network isolation (i.e., up to 256 VCIDs), while using the SDT field to clearly distinguish RCP data from other possible tunnel data, achieving clear isolation at the protocol level; furthermore, VCIDs are used to achieve logical isolation of RCP service requests of different security levels and control domains at the physical bus level, while hardware-level VCID filtering is performed from the LLC sublayer of the device, and non-member frames do not trigger any upper-layer interrupts, meeting functional safety requirements; finally, the physical layer in the present invention uses the CAN_H and CAN_L twisted-pair structure, which can smoothly upgrade the existing infrastructure corresponding to the CAN protocol and CAN FD protocol. The transceivers for the XL protocol are low-cost and do not require an external high-precision clock, which is beneficial for the low-cost design of edge devices.

[0169] Based on the above method embodiments, the present invention provides a master control device. For example... Figure 8 As shown, the main control device 800 includes: a first service adaptation layer 810, a first data link layer 820, and a first data frame transceiver 830; wherein, The first service adaptation layer 810 is used to acquire control commands; determine target service primitives based on the control commands; the target service primitives represent service primitives corresponding to the first communication protocol; the first communication protocol represents a remote control protocol; The first data link layer 820 is used to determine a target data frame based on the target service primitive; the target data frame represents a data frame corresponding to the second communication protocol; the first communication protocol is different from the second communication protocol. A first data frame transceiver 830 is used to send the target data frame to a slave device; the first data frame transceiver represents a data frame transceiver implemented based on the second communication protocol.

[0170] It is understood that the first service adaptation layer 810 corresponds to the application layer of the main control device or the RCP service adaptation layer in the above method embodiment.

[0171] In some implementations, the first data link layer 820 includes a first logical link control sublayer and a first media access control sublayer; the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier; The first logical link control sublayer is used to determine the target virtual network identifier from multiple virtual network identifiers based on the target service primitive; The first media access control sublayer is configured to: encapsulate the target service primitive into the data segment of the target data frame; and place the target virtual network identifier in the frame header control segment of the target data frame.

[0172] In some implementations, the first logical link control sublayer is used to determine a target virtual network identifier from a plurality of virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive. The communication direction includes either uplink communication or downlink communication; when the sending end is the master control device, the communication direction corresponding to the target service primitive represents downlink communication; when the sending end is the slave device, the communication direction corresponding to the target service primitive represents uplink communication. The service type represents the operation type corresponding to the target service primitive; The safety level represents the vehicle's safety integrity level.

[0173] In some implementations, the second communication protocol characterizes a controller area network extended length protocol.

[0174] Based on the above method embodiments, the present invention also provides a slave device. For example... Figure 9 As shown, device 900 includes: a second service adaptation layer 910, a second data link layer 920, and a second data frame transceiver 930; wherein, The second data frame transceiver 930 is used to receive target data frames sent by the master control device; the target data frame represents a data frame corresponding to the second communication protocol; the second data frame transceiver represents a data frame transceiver implemented based on the second communication protocol. The second data link layer 920 is used to determine the target service primitive in the target data frame; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol. The second service adaptation layer 910 is used to determine the control command corresponding to the target data frame based on the target service primitive.

[0175] It is understood that the second service adaptation layer 910 corresponds to the application layer of the device or the RCP service adaptation layer in the above method embodiment.

[0176] In some implementations, the second data link layer 920 includes a second logical link control sublayer; the bus network corresponding to the second communication protocol includes multiple virtual communication networks; each virtual communication network has a corresponding virtual network identifier. The second logical link control sublayer is used for: Determine the target virtual network identifier in the target data frame; If the target virtual network identifier matches the slave device, the target service primitive in the target data frame is determined; If the target virtual network identifier does not match the slave device, the target data frame is discarded.

[0177] In some implementations, the second communication protocol characterizes a controller area network extended length protocol.

[0178] Based on the above method and device embodiments, the present invention also provides a vehicle communication system. For example... Figure 10 As shown, the communication system 1000 includes: a master control device 1010 and multiple slave devices 1020, wherein the master control device 1010 is communicatively connected to the multiple slave devices 1020 via a physical bus 1030; wherein, The main control device is used to implement some or all of the steps in the communication method applied to the main control device described above. The slave device is used to implement some or all of the steps in the communication method applied to the slave device described above. The physical bus represents the communication bus carrying the second communication protocol.

[0179] It should be noted that the descriptions of the above device and system embodiments are similar to those of the above method embodiments, and have similar beneficial effects. In some embodiments, the functions or modules included in the device and system provided in this disclosure can be used to perform the methods described in the above method embodiments. For technical details not disclosed in the device and system embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0180] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A communication method, characterized in that, Applied to a main control device, the method includes: Obtain control commands; Based on the control command, a target service primitive is determined; the target service primitive represents a service primitive corresponding to a first communication protocol; the first communication protocol represents a remote control protocol. The target data frame is determined based on the target service primitive; the target data frame represents a data frame corresponding to the second communication protocol; the first communication protocol is different from the second communication protocol; The target data frame is sent to the slave device.

2. The method according to claim 1, characterized in that, The bus network corresponding to the second communication protocol includes multiple virtual communication networks; Each virtual communication network has a corresponding virtual network identifier; The method further includes: determining a target virtual network identifier from a plurality of virtual network identifiers based on the target service primitive; Determining the target data frame based on the service primitive includes: encapsulating the target service primitive into the data segment of the target data frame; and placing the target virtual network identifier in the frame header control segment of the target data frame.

3. The method according to claim 2, characterized in that, The step of determining the target virtual network identifier from multiple virtual network identifiers based on the target service primitive includes: The target virtual network identifier is determined from a plurality of virtual network identifiers based on at least one of the communication direction, service type, security level, and device type of the slave device corresponding to the target service primitive; The communication direction includes either uplink communication or downlink communication; when the sending end is the master control device, the communication direction corresponding to the target service primitive represents downlink communication; when the sending end is the slave device, the communication direction corresponding to the target service primitive represents uplink communication. The service type represents the operation type corresponding to the target service primitive; The safety level represents the vehicle's safety integrity level.

4. The method according to any one of claims 1 to 3, characterized in that, The second communication protocol characterizes the Controller Area Network Extended Length Protocol.

5. A communication method, characterized in that, Applied to a slave device, the method includes: Receive target data frames sent by the master control device; the target data frames represent data frames corresponding to the second communication protocol. Determine the target service primitive in the target data frame; the target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol. Based on the target service primitive, determine the control command corresponding to the target data frame.

6. The method according to claim 5, characterized in that, The bus network corresponding to the second communication protocol includes multiple virtual communication networks; Each virtual communication network has a corresponding virtual network identifier; The determination of the target service primitive in the target data frame includes: Determine the target virtual network identifier in the target data frame; If the target virtual network identifier matches the slave device, the target service primitive in the target data frame is determined; If the target virtual network identifier does not match the slave device, the target data frame is discarded.

7. The method according to claim 5, characterized in that, The second communication protocol characterizes the Controller Area Network Extended Length Protocol.

8. A master control device, comprising: The first service adaptation layer is used to obtain control commands; Based on the control instructions, determine the target service primitive; The target service primitive represents the service primitive corresponding to the first communication protocol; The first communication protocol represents a remote control protocol; The first data link layer is used to determine the target data frame based on the target service primitive; The target data frame represents the data frame corresponding to the second communication protocol; The first communication protocol is different from the second communication protocol; A first data frame transceiver is used to send the target data frame to the slave device; The first data frame transceiver represents a data frame transceiver implemented based on the second communication protocol.

9. A device comprising: The second data frame transceiver is used to receive target data frames sent by the master control device. The target data frame represents the data frame corresponding to the second communication protocol; The second data frame transceiver represents a data frame transceiver implemented based on the second communication protocol; The second data link layer is used to determine the target service primitives in the target data frame; The target service primitive represents the service primitive corresponding to the first communication protocol; the first communication protocol represents the remote control protocol. The second service adaptation layer is used to determine the control command corresponding to the target data frame based on the target service primitive.

10. A vehicle communication system, comprising: A master control device and multiple slave devices, wherein the master control device is communicatively connected to the multiple slave devices via a physical bus; wherein, The main control device is used to implement the method according to any one of claims 1 to 4; The slave device is used to implement the method according to any one of claims 5 to 7; The physical bus represents the communication bus carrying the second communication protocol.

Images