Multi-protocol converged communication method and device, electronic equipment and storage medium

Abstract

The application relates to a multi-protocol fusion communication method and device, electronic equipment and a storage medium, comprising the following steps: based on a target data model constructed in advance, performing format conversion on original communication data of each protocol type respectively to obtain to-be-transmitted data meeting a preset model format; based on a priority category of the to-be-transmitted data, distributing each to-be-transmitted data to a corresponding priority queue by using a protocol adaptation layer framework constructed in advance; adjusting a bandwidth quota of each priority queue based on a PID control algorithm; determining a target Ethernet frame in each priority queue according to a preset gating list; routing the target Ethernet frame through a target protocol identification field; and determining a data output port of each to-be-transmitted data. Thus, the problems of uncontrollable resource competition and delay, poor communication stack expansion and low cross-protocol interaction efficiency caused by independent operation of multiple protocols in a vehicle communication system under an AUTOSAR architecture in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a multi-protocol converged communication method, apparatus, electronic device and storage medium. Background Technology

[0002] With the development of intelligent connected vehicles and autonomous driving technology, multiple communication protocols such as CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, and Ethernet exist simultaneously in vehicle networks.

[0003] In related technologies, in-vehicle Ethernet communication systems based on the AUTOSAR (AUTomotive Open System Architecture) standard typically only support the independent operation of a single protocol.

[0004] However, the independent operation of multiple protocols can easily lead to problems such as resource contention and uncontrollable latency, poor communication stack scalability, and low efficiency of cross-protocol interaction, which urgently need to be addressed. Summary of the Invention

[0005] This application provides a multi-protocol converged communication method, apparatus, electronic device, and storage medium to solve the problems in related technologies, such as resource contention and uncontrollable latency caused by the independent operation of multiple protocols in AUTOSAR architecture vehicle communication systems, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0006] The first aspect of this application provides a multi-protocol converged communication method, including the following steps: Acquire raw communication data for multiple protocol types; Based on the pre-built target data model, the original communication data of each protocol type is converted into the format to obtain the data to be transmitted for each protocol type that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is assigned to a corresponding priority queue based on the priority category of the data to be transmitted for each protocol type, and the bandwidth quota for each priority queue is adjusted based on the PID (Proportional-Integral-Derivative) control algorithm. Based on the bandwidth quota sent by each priority queue, the target Ethernet frame in each priority queue is determined according to the preset gating list, and the target Ethernet frame is routed through the target protocol identifier field. The data output port of each data to be transmitted is determined respectively, so as to output the corresponding data to be transmitted using the data output port respectively.

[0007] According to one embodiment of this application, before acquiring raw communication data of multiple protocol types, the method further includes: Based on the communication layer of the vehicle open system architecture, a target protocol identifier field is added; Define the target protocol encoding table, obtain the preset model format for each protocol type, modify the routing lookup logic of the protocol data unit, and generate a ternary routing table for each protocol type.

[0008] According to one embodiment of this application, the target data model includes at least one of a metadata area, a data load area, and a verification area.

[0009] According to one embodiment of this application, determining the target Ethernet frame in each priority queue according to a preset gating list includes: Based on each time slot, a protocol data unit is determined from the corresponding priority queue, and the protocol data unit is used as data to be encapsulated. The data to be encapsulated is then encapsulated to obtain the target Ethernet frame in each priority queue.

[0010] According to one embodiment of this application, the above-described multi-protocol converged communication method further includes: Monitor the operating status of the protocol controller corresponding to each protocol type; If at least one protocol controller in each protocol type is in the fault state, the data to be transmitted corresponding to the protocol controller in the fault state will be switched to the backup output port so as to transmit the data to be transmitted corresponding to the protocol controller in the fault state based on the backup output port.

[0011] According to the multi-protocol fusion communication method of this application embodiment, based on a pre-built target data model, the original communication data of each protocol type is converted into a format to obtain data to be transmitted that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is allocated to a corresponding priority queue based on its priority category. The bandwidth quota for each priority queue is adjusted based on a PID control algorithm. The target Ethernet frames in each priority queue are determined according to a preset gating list, and the target Ethernet frames are routed using the target protocol identifier field to determine the data output port for each piece of data to be transmitted. This solves the problems in related technologies, such as resource contention and uncontrollable latency caused by independent operation of multiple protocols in AUTOSAR architecture vehicle communication systems, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0012] A second aspect of this application provides a multi-protocol converged communication device, comprising: The acquisition module is used to acquire raw communication data of multiple protocol types; The conversion module is used to convert the original communication data of each protocol type according to the pre-built target data model to obtain the data to be transmitted for each protocol type that meets the preset model format. The allocation module is used to allocate each piece of data to be transmitted to a corresponding priority queue based on the priority category of the data to be transmitted for each protocol type using a pre-built protocol adaptation layer framework, and to adjust the bandwidth quota sent by each priority queue based on a PID control algorithm. The transmission module is used to determine the target Ethernet frame in each priority queue according to a preset gating list based on the bandwidth quota sent by each priority queue, and to route the target Ethernet frame through the target protocol identifier field, and to determine the data output port of each data to be transmitted, so as to output the corresponding data to be transmitted through the data output port respectively.

[0013] According to one embodiment of this application, before acquiring raw communication data of multiple protocol types, the acquisition module further includes: Add a unit for the communication layer based on the vehicle open system architecture, and add a target protocol identifier field; The generation unit is used to define the target protocol encoding table, obtain the preset model format for each protocol type, modify the routing lookup logic of the protocol data unit, and generate a ternary routing table for each protocol type.

[0014] According to one embodiment of this application, the target data model includes at least one of a metadata area, a data load area, and a verification area.

[0015] According to one embodiment of this application, the transmission module includes: An encapsulation unit is used to determine a protocol data unit from the corresponding priority queue based on each time slot, and encapsulate the protocol data unit as data to be encapsulated to obtain the target Ethernet frame in each priority queue.

[0016] According to one embodiment of this application, the above-described multi-protocol converged communication device further includes: The monitoring module is used to monitor the operating status of the protocol controller corresponding to each protocol type; The first transmission module is configured to, if at least one protocol controller in each protocol type is in the fault state, switch the data to be transmitted corresponding to the protocol controller in the fault state to the backup output port, so as to transmit the data to be transmitted corresponding to the protocol controller in the fault state based on the backup output port.

[0017] According to the multi-protocol fusion communication device of this application embodiment, based on a pre-built target data model, the original communication data of each protocol type is converted into different formats to obtain data to be transmitted that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is allocated to a corresponding priority queue based on its priority category. The bandwidth quota for each priority queue is adjusted based on a PID control algorithm. The target Ethernet frames in each priority queue are determined according to a preset gating list, and the target Ethernet frames are routed using the target protocol identifier field to determine the data output port for each piece of data to be transmitted. This solves the problems in related technologies, such as resource contention and uncontrollable latency caused by independent operation of multiple protocols in AUTOSAR architecture vehicle communication systems, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0018] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the multi-protocol converged communication method as described in the above embodiments.

[0019] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to perform the multi-protocol converged communication method as described in the above embodiments.

[0020] A fifth aspect of this application provides a computer program product, including a computer program that is executed to implement the multi-protocol converged communication method described in the above embodiments.

[0021] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a schematic diagram of an in-vehicle Ethernet communication system based on related technologies. Figure 2 This is a flowchart of a multi-protocol converged communication method provided according to an embodiment of this application; Figure 3 This application presents an embodiment of an Ethernet multiprotocol converged communication architecture based on the Autosar architecture. Figure 4 This is a block diagram of a hierarchical architecture for multiprotocol communication according to an embodiment of this application; Figure 5 This is an example diagram of a multi-protocol converged communication device according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] The following description, with reference to the accompanying drawings, outlines a multi-protocol fusion communication method, apparatus, electronic device, and storage medium according to embodiments of this application. Addressing the problems mentioned in the background art regarding the independent operation of multiple protocols in AUTOSAR-based vehicle communication systems, which leads to uncontrollable resource contention and latency, poor communication stack scalability, and low cross-protocol interaction efficiency, this application provides a multi-protocol fusion communication method. In this method, based on a pre-constructed target data model, the original communication data of each protocol type is format-converted to obtain data to be transmitted that meets the preset model format. Using a pre-constructed protocol adaptation layer framework, each piece of data to be transmitted is allocated to a corresponding priority queue based on its priority category. The bandwidth quota for each priority queue is adjusted using a PID control algorithm. Target Ethernet frames in each priority queue are determined according to a preset gating list, and the target Ethernet frames are routed using the target protocol identifier field to determine the data output port for each piece of data to be transmitted. This solves the problems in the related art regarding the independent operation of multiple protocols in AUTOSAR-based vehicle communication systems, which leads to uncontrollable resource contention and latency, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0025] Specifically, before introducing the embodiments of this application, we will first introduce the technical solutions of related technologies and the existing technical problems.

[0026] like Figure 1As shown, the current vehicle Ethernet communication system is based on the AUTSAR standard to implement single protocol (such as SOME (Scalable service-oriented middleware) / IP (Internet Protocol)) communication, but it has the following defects: (1) Protocol isolation: different protocols run independently, hardware resources are repeatedly occupied, bandwidth utilization is low, and there is a lack of multi-protocol differentiated processing capabilities; (2) High latency: the traditional scheduling mechanism cannot meet the real-time requirements, there is a lack of a unified protocol fusion framework, cross-protocol interaction requires multiple conversions, and the latency of key data transmission exceeds 50ms; (3) Poor scalability: no multi-protocol collaborative interface is defined, relying on customized development, poor compatibility, new protocols require reconstruction of the communication stack, long development cycle, and difficulty in adapting to future technology evolution; (4) Bandwidth competition: there is a lack of dynamic resource allocation mechanism, high-priority data (such as control commands) and low-priority data (such as entertainment information) compete for bandwidth, resulting in packet loss and latency jitter.

[0027] This shows that in related technologies, after the message is received by the EthIf module, it is simply routed and forwarded by the PduR module. It lacks the ability to differentiate multi-protocol data, which causes high-priority data (such as autonomous driving control commands) and low-priority data (such as entertainment information) to compete for bandwidth, resulting in latency jitter and packet loss problems.

[0028] Therefore, based on the above-mentioned related technologies, the embodiments of this application aim to solve the following problems: (1) resource contention and delay are uncontrollable when multiple protocols are transmitted in parallel; (2) traditional communication stacks have poor scalability and high protocol compatibility development costs; (3) cross-protocol data interaction efficiency is low and processing delay is long.

[0029] Based on the aforementioned technical problems, the embodiments of this application adopt a low-latency, high-bandwidth Ethernet multi-protocol converged communication method based on the AUTOSAR architecture to solve the problems in the related technologies, such as resource contention and uncontrollable latency caused by the independent operation of multiple protocols in the AUTOSAR architecture vehicle communication system, poor communication stack scalability and low cross-protocol interaction efficiency.

[0030] Specifically, Figure 2 This is a flowchart illustrating a multi-protocol converged communication method provided in an embodiment of this application.

[0031] like Figure 2 As shown, the multi-protocol converged communication method includes the following steps: In step S201, raw communication data of multiple protocol types are acquired.

[0032] According to one embodiment of this application, before obtaining the original communication data of multiple protocol types, the method further includes: adding a target protocol identifier field to the communication layer based on the vehicle open system architecture; defining a target protocol encoding table to obtain a preset model format for each protocol type; and modifying the routing lookup logic of the protocol data unit to generate a ternary routing table for each protocol type.

[0033] Specifically, such as Figure 3 As shown, this application adopts an Ethernet multi-protocol converged communication architecture based on the vehicle open system architecture, namely the Autosar architecture. It mainly comprises four components: an application layer, a middleware layer, a communication stack, and a hardware abstraction layer. The application layer supports standardized interfaces for multiple protocols (such as CAN / LIN / FlexRay / TSN (Time-Sensitive Networking)) and implements cross-ECU (Electronic Control Unit) service calls through the Autosar RTE (Runtime Environment). The middleware layer includes a protocol conversion module and a QoS (Quality of Service) manager. The protocol conversion module can convert data formats between CAN / LIN / FlexRay and Ethernet protocols, and the QoS manager dynamically allocates bandwidth based on priority tags. The communication stack supports the expansion of the Autosar Ethernet communication module and multi-protocol convergence. The hardware abstraction layer adapts to in-vehicle Ethernet controllers (such as the Broadcom BCM8988x series). Detailed descriptions based on specific implementation methods will follow.

[0034] Specifically, such as Figure 4As shown, to achieve differentiated processing and routing of multi-protocol data, the communication layer of the AUTOSAR standard needs to be extended. Firstly, based on application-layer technologies, this involves developing cross-ECU service interfaces and protocol-independent service primitives based on the AUTOSAR SWS-RTE standard, such as RTE_Com_SendMultiProtocol() and RTE_Com_ReceiveMultiProtocol(); supporting mapping of different protocol data formats: "CAN: DBC file signal parsing," "LIN: LDF file parameter mapping," "FlexRay: FIBEX configuration parsing," and "TSN: IEEE 802.1Q standard PDU encapsulation"; implementing dynamic service discovery through the RTE service catalog; completing the development of a PDU routing mechanism based on AUTOSAR COM; and supporting synchronous / asynchronous service call modes. In other words, at the communication layer of the vehicle open system architecture, i.e., the AUTOSAR COM layer's PDU (Protocol Data) layer... In the metadata structure of the Unit (Protocol Data Unit), a target protocol identifier field is added. This field identifies the original communication protocol from which the current PDU carries the raw communication data, enabling a protocol-transparent service discovery mechanism. Multi-protocol services are dynamically registered / deregistered via the D-Bus bus. Through this target protocol identifier field, the PduR module can distinguish protocol data from different sources within the same PDU unit, providing a basis for subsequent differentiated routing. Simultaneously, a timestamp is inserted at the application layer, and the PduR interface is used to statistically analyze protocol conversion, routing, and end-to-end transmission latency. A latency compensation model is established, reserving a 1ms redundant latency window for EF class data to ensure that the end-to-end latency is ≤5ms in the worst-case scenario.

[0035] Secondly, in order to manage multiple protocol types in a unified manner, this embodiment defines a target protocol encoding table to establish a mapping relationship between each protocol type and the corresponding target protocol identifier field, and obtain a preset model format for each protocol type. For example, the protocol identifier 0x01 corresponds to the protocol type CAN. Through the above target protocol encoding table, the system can dynamically identify and expand new protocol types. When a new protocol is added, it is only necessary to add a new mapping entry to the target protocol encoding table without modifying the underlying communication stack.

[0036] Finally, in the standard AUTOSAR architecture, the PduR module uses a binary routing table based on the source PDU identifier and the destination PDU identifier for route lookup. Since the binary routing table cannot distinguish between data of different protocol types, it leads to routing confusion when multiple protocols coexist. To solve the above problem, this embodiment extends the routing lookup logic of the PduR module, expanding the original binary routing table into a ternary routing table that includes the destination protocol identifier. The lookup key of this ternary routing table is (Protocol ID, Source_Pdu_Id, Destination_Pdu_Id), that is, the target path for data forwarding is determined based on the combination of the destination protocol identifier, the source PDU identifier, and the destination PDU identifier. Thus, through the above extension, the PduR module can execute differentiated routing strategies for data of different protocol types. For example, it can route CAN protocol data to the Ethernet output port, while routing FlexRay protocol data to the internal loopback interface.

[0037] Furthermore, after completing the aforementioned pre-expansion, the system enters the multi-protocol data acquisition stage. In this embodiment, a hardware abstraction layer is used to adapt to different types of protocol controllers (including but not limited to CAN controllers, LIN controllers, FlexRay controllers, and Ethernet controllers), develop hardware-independent driver interfaces, support MAC (Media Access Control) layer configuration, DMA (Direct Memory Access) channel management, and interrupt handling. Then, an independent circular buffer is configured for each protocol controller, which is directly mapped to the FIFO (First In, First Out) queue of the controller hardware. When any protocol controller receives raw communication data of multiple protocol types from the external bus, the hardware triggers an interrupt or uses a polling mode to move the raw communication data from the hardware FIFO to the corresponding circular buffer. The circular buffer adopts a producer-consumer model: the hardware interrupt service routine acts as the producer to write data into the buffer, and the upper-layer protocol processing module acts as the consumer to read data from the buffer.

[0038] After the upper-layer processing module reads the raw communication data from the circular buffer, it queries the corresponding target protocol encoding table according to the protocol controller type from which the raw communication data originates, determines the corresponding protocol identifier, and then encapsulates the payload of the raw communication data together with the protocol identifier into an extended AUTOSAR PDU unit. This PDU unit includes a protocol identifier field: filled with the value obtained from the protocol encoding table (e.g., 0x01 represents CAN); a data payload area: filled with the valid data content of the raw data frame; and a metadata extension area: containing information such as hardware timestamp and initial priority value.

[0039] In step S202, based on the pre-built target data model, the original communication data of each protocol type is converted into a different format to obtain the data to be transmitted for each protocol type that meets the preset model format.

[0040] Specifically, in this embodiment, the middleware layer technology is mainly implemented by a protocol conversion module, a protocol conversion algorithm, and a QoS manager. The protocol conversion module includes a protocol parsing engine comprising "CAN: BCM mode parsing based on SocketCAN", "LIN: diagnostic protocol processing conforming to ISO 17987", and "FlexRay: frame structure parsing conforming to ISO 10681". To achieve unified processing of multi-protocol data, a protocol-independent UDM (Unified Data Management) is constructed. The Unified Data Model (UDM) is the target data model, which serves as an intermediate representation for multi-protocol conversion. It decouples the pairwise conversion relationships between different protocols, reducing the original O(N²) conversion complexity between N protocols to O(N). The target data model includes a metadata area, a data payload area, and a checksum area. The metadata area records the control information and context attributes of the original data. The data payload area is a variable-length byte array used to store the valid data content after format conversion. Its maximum length is preferably 1500 bytes to adapt to the maximum transmission unit of a standard Ethernet frame. For shorter protocol data (such as 8 bytes for CAN), only the first few bytes of the array are used, leaving the rest blank. The checksum area stores the integrity check code for the entire UDM data structure, preferably calculated using the CRC32 (Cyclic Redundancy Check) algorithm. The receiving end can verify whether errors occurred during data transmission and conversion using the checksum.

[0041] Furthermore, to achieve format conversion of raw data from different protocols to UDM, a protocol conversion algorithm is set. Specifically, the UDM is defined to implement data conversion from DBC (Database Can) to JSON (JavaScript Object Notation) to AVB (Audio Video Bridging) / TSN (Time-Sensitive Networking), achieving dynamic data compression based on a Bloom filter (compression rate ≥70%). This is mainly reflected in the fact that this application embodiment constructs a dedicated parsing engine for each supported protocol type, such as a CAN protocol parsing engine, a LIN protocol parsing engine, a FlexRay protocol parsing engine, and a TSN protocol parsing engine. For the CAN protocol, the parsing engine receives CAN frames based on the SocketCAN interface and parses them according to the signal descriptions defined in the DBC file. This mainly includes: extracting the CAN ID, data length code, and 8-byte data payload from the CAN frame; extracting the physical signal value from the 8-byte data according to the signal start bit, length, byte order, factor, and offset defined in the DBC file; and converting the CAN data into a JSON format. The ID is filled into the Signal_ID field of the UDM, the parsed physical signal values ​​are filled into the Payload area of ​​the UDM in sequence, and the data length is filled into the Data_Length field. For the LIN protocol parsing engine, the parsing engine performs parsing according to the parameter mapping defined in the LDF file, and also follows the ISO 17987 standard to process diagnostic frames. For the FlexRay protocol parsing engine, the parsing engine performs parsing according to the frame structure defined in the FIBEX (FlexRay switching format) configuration file, and follows the ISO 10681 standard. For the TSN protocol parsing engine, the parsing engine decapsulates Ethernet frames conforming to the IEEE 802.1Q standard, extracts the payload, and parses the priority information in the VLAN tag, mapping the priority to the Priority_Class field of the UDM.

[0042] Therefore, through the above data conversion, regardless of whether the original data comes from CAN, LIN, FlexRay or TSN protocols, it is uniformly converted into UDM format to obtain data to be transmitted with a standard structure.

[0043] Furthermore, for the QoS manager, this embodiment defines 5 priority levels (0-4, with 0 being the highest) through a priority labeling system, which are mapped to IEEE 802.1p service levels; dynamic bandwidth allocation requirements: a PID controller based on real-time traffic monitoring, supporting μs-level bandwidth allocation granularity, and integrating IEEE 802.1Qbv time-aware scheduling.

[0044] Furthermore, to reduce Ethernet transmission load and improve bandwidth utilization, this embodiment also provides an optional data compression function during the format conversion process. For the differences in data length between different protocols (such as CAN 8 bytes and Ethernet 1500 bytes), variable-length field padding technology is used to avoid bandwidth waste caused by fixed-length alignment. For periodically transmitted signals (such as wheel speed sensor data, sent once every 1ms), the value change between two adjacent samples is usually small. This embodiment uses Delta encoding: only the difference between the current value and the previous value is stored, rather than the complete value. For example, for a 32-bit wheel speed signal, the difference can be represented by 8 bits, with a compression rate of 75%, reducing Ethernet transmission load. For non-periodic sparse signals, this embodiment uses the lightweight LZ4 compression algorithm to compress the Payload area of ​​the UDM and records the compression flag in the reserved field of the metadata area. The receiving end decompresses according to the compression flag.

[0045] Furthermore, communication enhancement is implemented, primarily through multi-protocol PDU queue management, priority preemptive scheduling mechanism, and signal routing table supporting multi-protocol fusion; the time synchronization subsystem integrates the IEEE 1588v2 precision time protocol to achieve a synchronization accuracy of ±1μs.

[0046] Therefore, through the above compression mechanism, this embodiment can achieve a data compression rate of no less than 70%, significantly reducing the Ethernet transmission load.

[0047] Furthermore, after completing the UDM construction, the protocol conversion rules are updated without modifying the underlying communication stack. Simultaneously, an XML (Extensible Markup Language)-based configuration file is designed to store the protocol conversion rules (such as the mapping from CAN signal IDs to Ethernet VLAN tags), supporting online loading and hot updates. A hash table is used to accelerate rule lookups, ensuring a conversion latency of less than 10μs. At this point, the system can further convert the UDM into a preset model format for each protocol type based on routing decisions. For example, UDM-Ethernet frame: the UDM's payload area is encapsulated into an Ethernet frame conforming to the IEEE 802.1Q standard, and the priority field in the VLAN (Virtual Local Area Network) tag is mapped from Priority_Class; UDM-CAN frame: the DBC configuration is looked up based on the UDM's Signal_ID, and the physical signal values ​​in the payload area are re-encoded into CAN frame data bytes; UDM-JSON: the UDM data is serialized into a JSON string for cloud communication or debugging output.

[0048] Therefore, through the aforementioned bidirectional conversion capability, this embodiment realizes a flexible conversion architecture from arbitrary protocol to UDM to arbitrary protocol.

[0049] In step S203, using the pre-built protocol adaptation layer framework, each piece of data to be transmitted is assigned to the corresponding priority queue based on the priority category of the data to be transmitted for each protocol type, and the bandwidth quota sent by each priority queue is adjusted based on the PID control algorithm.

[0050] Specifically, in this embodiment, in order to achieve unified access and dynamic management of multi-protocol data, a protocol adaptation layer framework that supports dynamic protocol registration is first constructed. This protocol adaptation layer framework serves as a bridge between upper-layer applications and lower-layer communication protocols, and is responsible for protocol identification, adaptation, and routing.

[0051] The protocol adaptation layer framework includes the following core components: Protocol Registry: A global hash table used to store information about registered protocols. The key of the hash table is the protocol identifier, and the value is the corresponding protocol adapter object; Protocol Adapter Interface: Defines a set of standardized adaptation functions, including protocol parsing functions, serialization functions, and priority mapping functions; Adapter Manager: Responsible for the dynamic registration, deregistration, and lookup of protocols, and provides a unified calling interface.

[0052] Dynamic protocol registration mechanism: The adapter layer framework supports hot-swappable registration of protocols without modifying the underlying communication stack or restarting the system. When a new protocol type needs to be added (such as adding AVB (Audio Video Bridging) protocol), developers only need to implement the standardized adapter interface, such as the standardized API (Application Programming Interface) interface, and call the registration function to insert the adapter object into the protocol registry. Through the above dynamic registration mechanism, the access time of adding a new protocol can be shortened to less than 15 minutes, which significantly reduces the development cost of protocol extension.

[0053] To ensure low-latency data processing, the adapter lookup operation needs to meet strict real-time requirements. In this embodiment, a hash table is used as the underlying data structure of the protocol registry, and optimizations have been made for typical vehicle scenarios (supporting 8-16 protocols at the same time). The lookup time complexity of the hash table is O(1), and the actual lookup latency is less than 10 microseconds.

[0054] Furthermore, after completing the construction of the adaptation layer framework, the system identifies and maps the priority category of each piece of data to be transmitted (i.e., the aforementioned UDM format data).

[0055] First, the priority category is read from the Priority_Class field in the UDM metadata area. This example defines a 5-level priority system, with lower values ​​indicating higher priority (levels 0-4, with level 0 being the highest): Secondly, in order to achieve interoperability with the standard Ethernet QoS mechanism, this embodiment maps the above 5 priority levels to the 3-bit priority code points defined by the IEEE 802.1Q standard. Through the above mapping, the priority system of this application can be seamlessly connected with the QoS policy of standard Ethernet switches.

[0056] Secondly, after priority identification, the system assigns each piece of data to be transmitted to the corresponding priority queue. In this embodiment, five independent priority queues are maintained in the communication stack, corresponding to the five priority levels mentioned above. Each queue adopts a FIFO structure and has independent buffer management. When the data to be transmitted arrives at the adaptation layer framework, the system performs the following enqueue decision, including reading UDM.priority_class to obtain the priority level P (levels 0-4), checking the current depth of the corresponding priority queue, and updating queue statistics (current depth, average waiting time, etc.). For data with priority 0, when the target queue is full, the system uses preemptive scheduling: it checks whether there is a non-empty queue of a lower priority queue (levels 1-4). If so, it discards a data packet from the tail of the lowest priority queue to free up space for EF-class data to enqueue. This mechanism ensures zero packet loss for the highest priority data.

[0057] Finally, based on the queue allocation, this embodiment uses a PID control algorithm to dynamically adjust the transmission bandwidth quota of each priority queue to adapt to the real-time changing network load. The bandwidth quota is the total number of bytes allowed to be sent from the queue within a unit time window T (e.g., 100 milliseconds). This embodiment configures an independent PID controller for each priority queue to dynamically adjust its bandwidth quota. In addition, differentiated PID parameters are configured for the traffic characteristics of different priority categories. The PID controller requires real-time traffic monitoring data as input. This embodiment deploys a traffic monitoring module at the hardware abstraction layer. The traffic monitoring module collects the following indicators for each priority queue at a configurable sampling period (e.g., 10 microseconds), such as the current transmission rate, average waiting time (the delay from enqueuing to dequeuing), and packet loss rate (the proportion of data dropped due to queue fullness). The monitoring data is reported to the PID controller every 100 microseconds. The controller calculates the new bandwidth quota based on the feedback error and realizes the bandwidth adjustment through the configuration of a preset gating list.

[0058] Therefore, through the coordinated operation of the aforementioned PID control and time-aware scheduling, this embodiment achieves microsecond-level bandwidth allocation granularity, which can effectively cope with sudden traffic and network congestion, and ensure low-latency transmission of high-priority data.

[0059] In step S204, based on the bandwidth quota sent by each priority queue, the target Ethernet frame in each priority queue is determined according to the preset gating list, and the target Ethernet frame is routed through the target protocol identifier field. The data output port of each data to be transmitted is determined so that the corresponding data to be transmitted can be output using the data output port.

[0060] According to one embodiment of this application, determining the target Ethernet frame in each priority queue according to a preset gating list includes: determining a protocol data unit from the corresponding priority queue based on each time slot, using the protocol data unit as data to be encapsulated, encapsulating the data to be encapsulated, and obtaining the target Ethernet frame in each priority queue.

[0061] Specifically, this embodiment uses the bandwidth quota for each priority queue calculated by the aforementioned PID controller, combined with the IEEE 802.1Qbv time-aware scheduling mechanism, to realize the process of retrieving data from the priority queue and encapsulating it into an Ethernet frame.

[0062] Specifically, firstly, based on the bandwidth quotas of each priority queue output by the PID controller, the system calculates and configures a preset gating list. This preset gating list is a time-scheduled table that defines the time slot allocation for each priority queue to send data within each repetition cycle. Within each time slot, only the corresponding priority queue is allowed to send data; the gating status of other queues is closed, thus achieving physical isolation of different priority traffic in the time dimension. Secondly, when the system clock reaches the start time of a certain time slot, the gating scheduler triggers a transmission event. For example, the scheduler reads the queue identifier corresponding to the current time slot and checks whether the priority queue is not empty (i.e., whether there is a PDU to be sent). If the queue is not empty, the scheduler takes a PDU from the head of the queue as data to be encapsulated. If the queue is empty, the time slot remains idle (or an idle frame is sent), waiting for the next... The system performs Ethernet frame encapsulation operations after retrieving the PDU from the priority queue, primarily involving the construction of a standard Ethernet frame header. Next, the retrieved PDU data (i.e., the Payload area of ​​UDM format data) is filled into the data payload area of ​​the Ethernet frame. For PDUs shorter than 46 bytes, 0 to 46 bytes are filled according to the minimum Ethernet frame length requirement. Finally, the CRC32 checksum of the entire Ethernet frame (excluding the FCS field) is calculated and filled into the 4-byte FCS (Fieldbus Control System) field at the end of the frame. Through this encapsulation process, the system converts each PDU in the priority queue into an independent target Ethernet frame that can be transmitted over standard Ethernet. Simultaneously, time-division multiplexing technology is used to schedule the data transmission of different protocols on a shared physical link in a time-division manner.

[0063] Furthermore, after completing the Ethernet frame encapsulation, the system routes the Ethernet frame through the target protocol identifier field to determine its output port. The three-element routing table lookup result contains the following information: output interface type: such as Ethernet interface, CAN interface, LIN interface, FlexRay interface, or internal loopback interface; target channel identifier: such as Ethernet port number (eth0 / eth1), CAN controller number (can0 / can1), etc.; output priority: the transmission priority on the output link. Then, based on the routing decision result, the system outputs the target Ethernet frame (or other protocol frames after reverse conversion) through the corresponding data output port.

[0064] According to an embodiment of this application, the above-described multi-protocol fusion communication method further includes: monitoring the operating status of the protocol controller corresponding to each protocol type; if at least one protocol controller in each protocol type is in a fault state, then switching the data to be transmitted corresponding to the protocol controller in the fault state to the backup output port, so as to transmit the data to be transmitted corresponding to the protocol controller in the fault state based on the backup output port.

[0065] Specifically, in this embodiment, in order to detect the fault status of the protocol controller in a timely manner, the system deploys a comprehensive health monitoring mechanism at the hardware abstraction layer.

[0066] Specifically, an independent watchdog timer is configured for each protocol controller (including CAN controller, LIN controller, FlexRay controller and Ethernet controller). The watchdog timer sends a health query request to the corresponding protocol controller at a fixed period (e.g. 100 milliseconds). In addition to the watchdog timer, the system also periodically reads the status registers of each protocol controller, such as bus offline flag, error counter, clock fault flag, etc.

[0067] Furthermore, to support rapid switching in the event of a failure, the system pre-builds a protocol redundancy mapping table, which defines the backup output port and standby protocol channel for each protocol controller in case of failure. Through the above redundancy configuration, the failure of any single protocol controller will not cause a complete data interruption, and the system always has an available backup transmission path.

[0068] Furthermore, when the health monitoring mechanism detects that a protocol controller is in a fault state, the system automatically triggers a dynamic switching process to the backup controller (e.g., CAN2 is enabled when CAN1 fails). After determining the fault, the fault detection module generates a fault event, which is sent to the fault management submodule of the adaptation layer framework to query the protocol redundancy mapping table. Based on the redundancy mapping query result, the system dynamically updates the three-element routing table of the PduR module. After the routing table is updated, the system begins to transmit the data that originally belonged to the fault controller through the backup output port or the backup protocol channel. When the fault controller recovers, the system supports automatic or manual switchback operations to restore the original routing configuration.

[0069] The watchdog timer triggers a reset process when it times out three times in a row.

[0070] Furthermore, to verify the technical effects of the present invention, this embodiment was verified using an in-vehicle Ethernet test platform (such as Vector VN1630+BCM89880), mainly including: latency indicators: end-to-end latency of EF (priority 0) class data ≤3ms (typical value 2.1ms), which is 60% lower than the traditional solution; bandwidth utilization: under mixed load (50% CAN + 30% FlexRay + 20% Ethernet), the bandwidth utilization is stable at over 92%; compatibility: supports simultaneous access of 8 protocols (CAN / LIN / FlexRay / AVB / etc.), and the protocol extension time is <15 minutes.

[0071] In summary, the embodiments of this application can achieve the following technical effects: (1) Kernel-mode protocol stack optimization: the protocol conversion logic is pushed down to the Linux kernel module, the kernel thread is used to handle the interrupt context, the user-mode switching overhead is reduced, and the PDU buffer is pre-allocated using memory pool technology to avoid dynamic memory allocation delay; (2) Multi-core load balancing: Through the CPU affinity binding strategy, EF class data processing is fixedly allocated to high-performance cores, and BE class data is allocated to low-power cores (such as Cortex-A55). (3) Multi-protocol dynamic fusion architecture, based on the Autosar PduR interface to define a unified API abstraction layer, supports plug-and-play CAN / LIN / FlexRay / Ethernet protocols, generates protocol conversion rules (such as CAN signal to Ethernet frame mapping) through the Vector CANoe toolchain, and supports OTA updates; (4) Low latency guarantee mechanism, zero copy technology (such as DPDK) reduces data copying overhead; kernel mode protocol stack optimization, and pushes scheduling logic down to the driver layer; polling mode processes high priority data streams to avoid interruption delay.

[0072] (5) Dynamic bandwidth allocation and priority scheduling, with priority queues divided based on QoS tags (such as EF, AF, BE classes); By combining deep reinforcement learning algorithms to monitor network load in real time and dynamically adjust bandwidth quotas, bandwidth utilization is increased to 90%, and multi-protocol parallel transmission is supported. LLQ (Low Latency Queuing) is used to allocate strict priorities to real-time traffic, ensuring latency <1ms and reducing the packet loss rate of critical data to 0.1%.

[0073] (6) Protocol-independent adaptation layer framework, defines standardized data format and routing rules, supports dynamic registration and unified management of multiple protocols; performs binary encoding compression on traditional protocol signals to reduce transmission load (e.g., 8-byte CAN signal is compressed to 4 bytes), reduces protocol compatibility development cost by 50%, and shortens adaptation cycle by 30%.

[0074] According to the multi-protocol fusion communication method of this application embodiment, based on a pre-built target data model, the original communication data of each protocol type is converted into a format to obtain data to be transmitted that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is allocated to a corresponding priority queue based on its priority category. The bandwidth quota for each priority queue is adjusted based on a PID control algorithm. The target Ethernet frames in each priority queue are determined according to a preset gating list, and the target Ethernet frames are routed using the target protocol identifier field to determine the data output port for each piece of data to be transmitted. This solves the problems in related technologies, such as resource contention and uncontrollable latency caused by independent operation of multiple protocols in AUTOSAR architecture vehicle communication systems, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0075] Next, a multi-protocol converged communication device according to an embodiment of this application is described with reference to the accompanying drawings.

[0076] Figure 5 This is a block diagram of a multi-protocol converged communication device according to an embodiment of this application.

[0077] like Figure 5 As shown, the multi-protocol converged communication device 10 includes: an acquisition module 100, a conversion module 200, an allocation module 300, and a first transmission module 400.

[0078] Among them, the acquisition module 100 is used to acquire raw communication data of multiple protocol types; The conversion module 200 is used to convert the original communication data of each protocol type according to the pre-built target data model to obtain the data to be transmitted for each protocol type that meets the preset model format. The allocation module 300 is used to allocate each piece of data to be transmitted to the corresponding priority queue based on the priority category of the data to be transmitted for each protocol type using a pre-built protocol adaptation layer framework, and to adjust the bandwidth quota sent by each priority queue based on a PID control algorithm. The first transmission module 400 is used to determine the target Ethernet frame in each priority queue according to a preset gating list based on the bandwidth quota sent by each priority queue, and to route the target Ethernet frame through the target protocol identifier field, and to determine the data output port of each data to be transmitted, so as to output the corresponding data to be transmitted through the data output port respectively.

[0079] According to one embodiment of this application, before acquiring raw communication data of multiple protocol types, the acquisition module 100 further includes: Add a unit for the communication layer based on the vehicle open system architecture, and add a target protocol identifier field; The generation unit is used to define the target protocol encoding table, obtain the preset model format for each protocol type, modify the routing lookup logic of the protocol data unit, and generate a ternary routing table for each protocol type.

[0080] According to one embodiment of this application, the target data model includes at least one of a metadata area, a data load area, and a verification area.

[0081] According to one embodiment of this application, the first transmission module 400 includes: The encapsulation unit is used to determine the protocol data unit from the corresponding priority queue based on each time slot, and encapsulate the protocol data unit as the data to be encapsulated to obtain the target Ethernet frame in each priority queue.

[0082] According to one embodiment of this application, the multi-protocol converged communication device 10 described above further includes: The monitoring module is used to monitor the operating status of the protocol controller corresponding to each protocol type; The second transmission module is used to switch the data to be transmitted corresponding to the protocol controller in the faulty state to the backup output port if at least one protocol controller in the protocol controller corresponding to each protocol type is in a faulty state, so as to transmit the data to be transmitted corresponding to the protocol controller in the faulty state based on the backup output port.

[0083] According to the multi-protocol fusion communication device of this application embodiment, based on a pre-built target data model, the original communication data of each protocol type is converted into different formats to obtain data to be transmitted that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is allocated to a corresponding priority queue based on its priority category. The bandwidth quota for each priority queue is adjusted based on a PID control algorithm. The target Ethernet frames in each priority queue are determined according to a preset gating list, and the target Ethernet frames are routed using the target protocol identifier field to determine the data output port for each piece of data to be transmitted. This solves the problems in related technologies, such as resource contention and uncontrollable latency caused by independent operation of multiple protocols in AUTOSAR architecture vehicle communication systems, poor communication stack scalability, and low cross-protocol interaction efficiency.

[0084] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0085] When the processor 502 executes the program, it implements the multi-protocol fusion communication method provided in the above embodiments.

[0086] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.

[0087] The memory 501 is used to store computer programs that can run on the processor 502.

[0088] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0089] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0090] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0091] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0092] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the multi-protocol converged communication method described above.

[0093] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0094] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0096] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0097] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0098] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0099] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0100] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method of multi-protocol convergence communication, characterized by, Includes the following steps: Acquire raw communication data for multiple protocol types; Based on the pre-built target data model, the original communication data of each protocol type is converted into the format to obtain the data to be transmitted for each protocol type that meets the preset model format. Using a pre-built protocol adaptation layer framework, each piece of data to be transmitted is assigned to a corresponding priority queue based on the priority category of the data to be transmitted for each protocol type, and the bandwidth quota for each priority queue is adjusted based on a PID control algorithm. Based on the bandwidth quota sent by each priority queue, the target Ethernet frame in each priority queue is determined according to the preset gating list, and the target Ethernet frame is routed through the target protocol identifier field. The data output port of each data to be transmitted is determined respectively, so as to output the corresponding data to be transmitted using the data output port respectively.

2. The method according to claim 1, characterized in that, Before acquiring raw communication data for multiple protocol types, the process also includes: Based on the communication layer of the vehicle open system architecture, a target protocol identifier field is added; Define the target protocol encoding table, obtain the preset model format for each protocol type, modify the routing lookup logic of the protocol data unit, and generate a ternary routing table for each protocol type.

3. The method according to claim 1, characterized in that, The target data model includes at least one of the following: metadata area, data load area, and verification area.

4. The method according to claim 1, characterized in that, The step of determining the target Ethernet frame in each priority queue according to the preset gating list includes: Based on each time slot, a protocol data unit is determined from the corresponding priority queue, and the protocol data unit is used as data to be encapsulated. The data to be encapsulated is then encapsulated to obtain the target Ethernet frame in each priority queue.

5. The method according to claim 1, characterized in that, Also includes: Monitor the operating status of the protocol controller corresponding to each protocol type; If at least one protocol controller in each protocol type is in a fault state, the data to be transmitted corresponding to the protocol controller in the fault state will be switched to the backup output port so as to transmit the data to be transmitted corresponding to the protocol controller in the fault state based on the backup output port.

6. A multi-protocol converged communication device, characterized in that, include: The acquisition module is used to acquire raw communication data of multiple protocol types; The conversion module is used to convert the original communication data of each protocol type according to the pre-built target data model to obtain the data to be transmitted for each protocol type that meets the preset model format. The allocation module is used to allocate each piece of data to be transmitted to a corresponding priority queue based on the priority category of the data to be transmitted for each protocol type using a pre-built protocol adaptation layer framework, and to adjust the bandwidth quota sent by each priority queue based on a PID control algorithm. The transmission module is used to determine the target Ethernet frame in each priority queue according to a preset gating list based on the bandwidth quota sent by each priority queue, and to route the target Ethernet frame through the target protocol identifier field, and to determine the data output port of each data to be transmitted, so as to output the corresponding data to be transmitted through the data output port respectively.

7. The apparatus according to claim 6, characterized in that, Before acquiring raw communication data of multiple protocol types, the acquisition module further includes: Add a unit for the communication layer based on the vehicle open system architecture, and add a target protocol identifier field; The generation unit is used to define the target protocol encoding table, obtain the preset model format for each protocol type, modify the routing lookup logic of the protocol data unit, and generate a ternary routing table for each protocol type.

8. The apparatus according to claim 6, characterized in that, The target data model includes at least one of the following: metadata area, data load area, and verification area.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the multi-protocol converged communication method as described in any one of claims 1-5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the multi-protocol converged communication method as described in any one of claims 1-5.

Images