Method, device, medium and product for multi-protocol communication

Abstract

The application provides a processing method, device, medium and product for multi-protocol communication, the method comprising: receiving multiple communication data packets sent by a communication terminal of different protocols, and obtaining multiple configuration parameters of each communication data packet; distributing each communication data packet to a corresponding physical protocol channel according to the multiple configuration parameters; transmitting each communication data packet to a multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser analyzes each communication data packet to obtain multiple analysis results carrying data packet identifiers; performing consistency verification on the multiple analysis results carrying data packet identifiers to obtain a verification result of each communication data packet; and if the verification result is verified, transmitting the corresponding communication data packet to a vehicle controller so that the vehicle controller makes a vehicle decision according to the communication data packet. The method can guarantee the efficiency of communication processing and meet the requirements of functional safety regulations on data integrity.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, specifically to a method, device, medium, and product for processing multi-protocol communication. Background Technology

[0002] In the evolution of automotive electronic and electrical architecture from distributed to domain-centralized systems, the vehicle communication system needs to simultaneously carry network data from multiple heterogeneous protocols and ensure that the communication processing meets functional safety objectives. This means that the communication engine not only needs to have the ability to concurrently parse multiple protocols, but also must provide reliability guarantees throughout the entire communication link.

[0003] Currently, related technologies deploy corresponding protocol stack software for different protocols. During communication processing, data packets from these heterogeneous protocols are aggregated into a single processing unit, and the protocol type is identified by unfolding the frame header fields layer by layer through software modules. However, limited by traditional serial processing mechanisms, the parsing and verification logic of these independent protocol stacks is often bound to a single execution path.

[0004] However, this approach and related technologies are difficult to flexibly handle the processing needs of heterogeneous protocols in multi-protocol concurrent scenarios, and lack effective fault isolation and fault tolerance mechanisms, which makes it impossible to simultaneously guarantee the efficiency of communication processing and meet the requirements of functional safety regulations for data integrity. Summary of the Invention

[0005] In view of this, this application aims to provide a method, device, medium and product for processing multi-protocol communication, so as to solve the problem that traditional related technologies cannot simultaneously guarantee the efficiency of communication processing and meet the requirements of functional safety regulations for data integrity.

[0006] The first aspect of this application provides a method for processing multi-protocol communication, comprising: receiving multiple communication data packets sent by communication terminals of different protocols, and obtaining multiple configuration parameters for each communication data packet; allocating each communication data packet to a corresponding physical protocol channel according to the multiple configuration parameters; wherein each physical protocol channel is configured with a corresponding multi-core physical protocol parser; transmitting each communication data packet to the multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser parses each communication data packet to obtain multiple parsing results carrying data packet identifiers; performing consistency verification on the multiple parsing results carrying data packet identifiers to obtain verification results for each communication data packet; if the verification result is successful, transmitting the corresponding communication data packet to the vehicle controller so that the vehicle controller makes vehicle decisions based on the communication data packet.

[0007] In one possible implementation of this application, each communication data packet is assigned a corresponding physical protocol channel based on multiple configuration parameters, including: performing a hash calculation on the multiple configuration parameters to obtain hash values ​​of the multiple configuration parameters; obtaining the physical protocol channel identifier corresponding to the hash value from a pre-built communication protocol specification dictionary; and assigning the communication data packets corresponding to the multiple configuration parameters to the physical protocol channel corresponding to the physical protocol channel identifier.

[0008] In one possible implementation of this application, a multi-core physical protocol parser parses each communication data packet to obtain multiple parsing results carrying data packet identifiers, including: the multi-core physical protocol parser distributing each communication data packet to multiple parsing cores; each parsing core parses each communication data packet according to the corresponding communication protocol based on the real-time operating system to obtain parsing results; and generating data packet identifiers for each communication data packet; and binding the data packet identifiers to the corresponding parsing results to obtain multiple parsing results carrying data packet identifiers.

[0009] In one possible implementation of this application, generating a data packet identifier for each communication data packet includes: obtaining the reception time and physical address of each communication data packet; and generating a data packet identifier based on the reception time and physical address.

[0010] In one possible implementation of this application, a consistency check is performed on multiple parsing results carrying data packet identifiers to obtain the check result of each communication data packet. This includes: comparing multiple parsing results with the same data packet identifier; if multiple parsing results are the same, the check result of each communication data packet is considered to have passed the check; if there are different parsing results among the multiple parsing results, the check result of each communication data packet is considered to have failed the check.

[0011] In one possible implementation of this application, the method further includes: monitoring the communication frequency of each physical protocol channel; determining the priority of the communication data packets corresponding to each physical protocol channel based on the communication frequency; and prioritizing the processing of communication data packets with higher priority.

[0012] In one possible implementation of this application, the method further includes: obtaining at least one communication feature of each communication data packet; determining whether at least one communication feature is abnormal based on the normal communication features of each communication protocol; and terminating the transmission of the communication data packet with the abnormality if an abnormality is determined to exist.

[0013] In one possible implementation of this application, the method further includes: sending a physical protocol channel authentication command to each physical protocol channel, causing the multi-core physical protocol parser in each physical protocol channel to send a key detection request to the hardware security unit, so that the hardware security unit generates a session encryption key for each physical protocol channel when it detects that the hardware identity of the multi-core physical protocol parser is legitimate; after receiving the session encryption key sent by the hardware security unit, performing security initialization on each physical protocol channel; after the security initialization of each physical protocol channel is completed, sending a security start completion status to the vehicle central management system, so that the vehicle central management system opens the communication permissions of each physical protocol channel; wherein, each communication data packet is only allowed to be allocated to the physical protocol channel that has the communication permission.

[0014] In one possible implementation of this application, the method further includes: monitoring security events that occur during the processing of each communication data packet; designing a log storage structure for storing security events based on a preset log design goal; determining the log level corresponding to the security event; and saving the security event to the log storage structure according to the log level to obtain a log record of the security event.

[0015] A second aspect of this application also provides a multi-protocol communication processing apparatus, comprising: a receiving module for receiving multiple communication data packets sent by communication terminals of different protocols and obtaining multiple configuration parameters for each communication data packet; an allocation module for allocating each communication data packet to a corresponding physical protocol channel according to the multiple configuration parameters; wherein each physical protocol channel is configured with a corresponding multi-core physical protocol parser; a parsing module for transmitting each communication data packet to the multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser parses each communication data packet to obtain multiple parsing results carrying data packet identifiers; a verification module for performing consistency verification on the multiple parsing results carrying data packet identifiers to obtain a verification result for each communication data packet; and a transmission module for transmitting the corresponding communication data packet to a vehicle controller if the verification result is successful, so that the vehicle controller makes vehicle decisions based on the communication data packet.

[0016] A third aspect of this application provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform a multi-protocol communication processing method as described in the first aspect and possible implementations thereof.

[0017] The fourth aspect of this application provides a computer storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a multi-protocol communication method as described in the first aspect and possible implementations of the first aspect.

[0018] The fifth aspect of this application provides a computer program product, comprising: a computer program that, when executed by a processor, implements a multi-protocol communication processing method as described in the first aspect and possible implementations of the first aspect.

[0019] This application provides a multi-protocol communication processing method, device, medium, and product. The method allocates multiple communication data packets to corresponding physical protocol channels using multiple configuration parameters for each data packet. This achieves rapid protocol splitting without relying on protocol stack software to unfold frame headers layer by layer. This ensures that communication data packets of different protocols are transmitted to their corresponding physical protocol channels at the physical level, achieving decoupling and flexible scheduling in multi-protocol concurrent scenarios. Furthermore, by utilizing a multi-core physical protocol parser configured within each physical protocol channel, consistency verification of multiple parsing results carrying data packet identifiers is performed, ensuring the reliability and integrity of communication data packets entering the vehicle controller. This hardware-software collaborative approach, configuring a multi-core physical protocol parser on the hardware side and allocating physical protocol channels based on configuration parameters on the software side while performing consistency verification, achieves physical splitting of communication data packets of different protocols through the hardware physical protocol channels, improving the flexibility and real-time efficiency of multi-protocol concurrent processing. Furthermore, the hardware multi-core physical protocol parser parses communication data packets, forming a two-layer fault-tolerant isolation mechanism in conjunction with software consistency verification, effectively avoiding single-point operational failures and ensuring the integrity of transmitted data. While ensuring the efficiency of communication processing, it also achieves strict protection of data integrity requirements in functional safety regulations. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the system architecture for the multi-protocol communication processing method provided in the embodiments of this application.

[0022] Figure 2 This is a flowchart illustrating the multi-protocol communication processing method provided in an embodiment of this application.

[0023] Figure 3 This is a schematic diagram of the structure of a multi-protocol communication processing device provided in an embodiment of this application.

[0024] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the evolution of automotive electronic and electrical architecture from distributed to domain-centralized systems, the vehicle communication system needs to simultaneously carry network data from multiple heterogeneous protocols and ensure that the communication processing meets functional safety objectives. This means that the communication engine not only needs to have the ability to concurrently parse multiple protocols but also must provide reliability guarantees throughout the entire communication link. Related technologies deploy corresponding protocol stack software for different protocols. During communication processing, data packets from these heterogeneous protocols are aggregated into a single processing unit, and the protocol type is identified by progressively expanding the frame header fields through software modules. However, limited by traditional serial processing mechanisms, the parsing and verification logic of these independent protocol stacks is often bound to a single execution path.

[0027] To overcome the aforementioned contradictions, this application proposes the following technical concept: By acquiring multiple configuration parameters of each communication data packet and allocating each communication data packet to its corresponding physical protocol channel; combining the multi-core physical protocol parser configured within each channel to parse the same communication data packet, and performing consistency verification based on the data packet identifier on the parsing results, without relying on the traditional protocol stack to unfold the frame header layer by layer, the diversion operation of communication data packets of multiple heterogeneous protocols is moved forward to the physical channel layer, and the data integrity guarantee is transformed from single-point verification to redundant verification through the multi-core physical protocol parser. This solves the problems of uncontrollable latency and insufficient functional safety integrity in multi-protocol concurrent processing, thereby meeting the flexible processing requirements of heterogeneous protocols while achieving strict protection of data integrity requirements in functional safety regulations.

[0028] Figure 1 A schematic diagram of the system architecture for a multi-protocol communication processing method provided in an embodiment of this application. (Reference) Figure 1 In this scenario, the following components are included: a communication engine 10. The communication engine 10 is divided into: a secure boot module 101, a flexible interrupt controller 102, a communication scheduler 103, a dynamic protocol virtual machine 104, and a hardware security unit 105.

[0029] In this embodiment, the communication engine 10 uses a quad-core heterogeneous processor to build a modular architecture, thereby achieving module-level permission isolation, protocol adaptation, and communication security.

[0030] The secure boot module 101 is responsible for the self-test before the communication engine 10 starts, to ensure the normal startup of the communication engine 10. It transmits the power-on self-test results to the dynamic protocol virtual machine 104 and controls whether the dynamic protocol virtual machine 104 is allowed to start.

[0031] The communication scheduler 103 is responsible for the task management of the vehicle's communication data packets. It schedules data according to the priority of the communication data packets: creates an independent processing task for each communication data packet; supports task state switching: ready, suspended, and activated; dynamically allocates hardware and software processing resources, shortens the processing delay of high-priority communication data packets, and optimizes the overall communication real-time performance.

[0032] The flexible interrupt controller 102, in conjunction with the communication scheduler 103, enables preemptive processing of high-priority communication data packets. When a higher-priority communication data packet arrives, it can proactively interrupt the currently being processed low-priority communication data packet; and issue a switch to the dynamic protocol virtual machine 104 to handle the communication data packet. Simultaneously, it works with the hardware safety unit 105 to implement fault-protected interrupts.

[0033] The hardware security unit 105 is responsible for real-time monitoring of the processor hardware and communication bus link status throughout the entire process. Once hardware damage, link breakage, data anomalies, or attack behavior are detected, a protective interrupt is immediately triggered to achieve fault self-protection during operation. Specifically, the communication scheduler 103 reports the bus task load, and the hardware security unit 105 reports link or hardware anomalies.

[0034] In this embodiment, after the communication engine 10 starts, it performs a self-test via the secure startup module 101 and synchronously monitors communication information via the communication scheduler 103. Once the self-test is complete, data processing begins. The dynamic protocol virtual machine 104 identifies the priority of communication data packets. If the priority is low, it suspends the packet and prioritizes processing higher-priority packets. The flexible interrupt controller 102 interrupts the processing of the current communication data packet and switches to processing higher-priority packets. After the higher-priority packets are processed, the lower-priority packets are activated. The dynamic protocol virtual machine 104 identifies the communication protocol of the communication data packets, splits the data in the packets, extracts valid data, and then reconstructs it into a unified format for data transmission. In addition, throughout the entire process, the hardware security unit 105 checks the hardware and link integrity; if an anomaly is detected, a protective interrupt is initiated.

[0035] The dynamic protocol virtual machine 104 is the core of the architecture, responsible for assigning corresponding physical protocol channels to each communication data packet. This allows the multi-core physical protocol parser to parse each communication data packet, obtaining multiple parsing results carrying data packet identifiers. Consistency checks are performed on these parsing results to obtain the verification results for each communication data packet. If the verification result passes, the corresponding communication data packet is transmitted to the vehicle controller, enabling the vehicle controller to make vehicle decisions based on the communication data packet. Furthermore, it is also responsible for obtaining the priority of each communication data packet, identifying any abnormal communication data packets, obtaining communication permissions for each physical protocol channel, and storing logs.

[0036] In this embodiment, the dynamic protocol virtual machine 104 automatically identifies communication data packets of different communication protocols and loads the corresponding protocol parsing rules in real time. It can add, delete, and modify protocol parsing logic online without requiring hardware shutdown and restart. Even when different vehicle models and different communication protocols are used, the dynamic protocol virtual machine 104 automatically completes protocol format conversion and reorganization, enabling plug-and-play use of multiple communication protocols. Since different communication protocols have different communication data packet structures, the dynamic protocol virtual machine 104 performs data reconstruction and standardization, splitting redundant headers, filtering invalid fields, extracting effective payload data, and encapsulating it into a unified data format for transmission to the vehicle controller. This is equivalent to real-time reconstruction of communication data packets, eliminating the need for upper-layer services to adapt to multiple protocol differences.

[0037] In this embodiment, the communication engine is dynamically reconfigured at more than 10 levels: First, the protocol parsing logic is reconfigurable, compatible with multiple communication protocols, and a multi-mode protocol engine is deployed, supporting protocols such as CAN / TCP (Transmission Control Protocol) / UDP (UDP). A general library that virtualizes the computing interface is used to build an underlying support stack that conforms to communication heterogeneity. Second, the format of communication data in communication data packets is uniformly reconfigured to shield the differences between heterogeneous communication protocols. Third, the communication scheduling task is dynamically reconfigured to adaptively prioritize communication data packets. Fourth, module isolation and fault self-protection are achieved to solve the defects of traditional vehicle communication equipment, such as fixed protocols, poor expansion flexibility, and difficulty in adapting safety management to regulatory iterations.

[0038] Figure 2 This is a flowchart illustrating the multi-protocol communication processing method provided in an embodiment of this application. The execution entity of this embodiment can be... Figure 1 The dynamic protocol virtual machine in the illustrated embodiment. (For example...) Figure 2 As shown, the method includes: S201: Receive multiple communication data packets sent by communication terminals with different protocols, and obtain multiple configuration parameters for each communication data packet.

[0039] In this embodiment, the communication terminals of different protocols include vehicle CAN nodes, CAN FD nodes, LIN nodes, FlexRay nodes, and vehicle Ethernet nodes, etc., and these nodes send communication data packets according to their respective communication protocols.

[0040] In this embodiment, when these communication data packets are received through the physical layer, the complete frame header is not immediately expanded in depth. Instead, multiple configuration parameters are extracted from each communication data packet.

[0041] Configuration parameters refer to quantifiable information related to communication protocols and transmission characteristics that are directly extracted from or indirectly derived from communication data packets. These may include, but are not limited to, the physical port from which the data packet originated, the length of the communication packet, the concatenation value of a set of bit fields, and may also encompass compressed or transformed feature vectors.

[0042] S202: Based on multiple configuration parameters, assign corresponding physical protocol channels to each communication data packet; each physical protocol channel is configured with a corresponding multi-core physical protocol parser.

[0043] In this embodiment, after obtaining multiple configuration parameters of a certain communication data packet, the communication data packet is allocated to the corresponding physical protocol channel by quickly determining these parameters.

[0044] Specifically, hash calculations are performed on multiple configuration parameters to obtain hash values ​​for the multiple configuration parameters; the physical protocol channel identifier corresponding to the hash value is obtained from the pre-built communication protocol specification dictionary; and the communication data packets corresponding to the multiple configuration parameters are allocated to the physical protocol channels corresponding to the physical protocol channel identifiers.

[0045] In this embodiment, a pre-built communication protocol specification dictionary stores different hash values ​​and their corresponding physical protocol channel identifiers. This approach aims to replace traditional layer-by-layer frame header parsing with lightweight hash mapping, achieving low-latency, low-storage-consumption, and fast channel offloading. The pre-built communication protocol specification dictionary only needs to maintain a fixed number of entries to support multiple protocols, maintaining controllable storage overhead. It is also easily extended for new communication protocols by simply appending entries to the dictionary. Only configuration parameters are read, without expanding the complete frame header, thus reducing latency and resource consumption during communication protocol identification. Since communication data packets of different protocols are physically isolated to their respective physical protocol channels, mutual waiting and interference during mixed communication data packet processing are eliminated. This allows communication data packets of different protocols to be processed independently and concurrently, creating the preconditions for redundant parsing and fault tolerance to meet ASIL-D level functional safety requirements.

[0046] S203: Transmit each communication data packet to the multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser can parse each communication data packet and obtain multiple parsing results carrying data packet identifiers.

[0047] In this embodiment, the physical protocol channels are implemented by independent hardware partitions, and each physical protocol channel is configured with dedicated cache and memory space.

[0048] Specifically, the multi-core physical protocol parser distributes each communication data packet to multiple parsing cores; each parsing core, based on the real-time operating system, parses each communication data packet according to the corresponding communication protocol to obtain the parsing result; and generates a data packet identifier for each communication data packet; the data packet identifier is bound to the corresponding parsing result to obtain multiple parsing results carrying data packet identifiers.

[0049] In this embodiment, the multiple parsing cores in the multi-core physical protocol parser are multiple physically independent processor cores.

[0050] In this embodiment, the multi-core physical protocol parser configured within each physical protocol channel contains multiple parsing cores. These parsing cores share the communication data packets of that physical protocol channel, but each operates independently. The multi-core physical protocol parser simultaneously distributes the same received communication data packet to the multiple parsing cores within it. Each parsing core, based on a real-time operating system (RTOS), parses the communication data packet according to the corresponding communication protocol to obtain the parsing result.

[0051] The parsing result can be the original payload data, signal value, or status information obtained after decoding and verification. Simultaneously with parsing, each parsing core generates a packet identifier for the data packet and binds the packet identifier to the corresponding parsing result, thus obtaining multiple parsing results carrying packet identifiers.

[0052] In this embodiment, since the same communication data packet is redundantly parsed by multiple parsing cores, each parsing result carries the same data packet identifier. This allows multiple parsing results to be traced back to the same original communication data packet, providing an accurate comparison basis for subsequent consistency verification.

[0053] Specifically, the receiving time and physical address of each communication data packet are obtained; based on the receiving time and physical address, a data packet identifier is generated.

[0054] In this embodiment, the reception time can be a timestamp based on a globally synchronized clock, and the physical address is the hardware identity of the communication data packet source (such as that sent by the brake pedal). The two are concatenated to form a unique data packet identifier. This design enables verification not only to determine whether different parsing results of the same communication data packet are consistent, but also to quickly locate the specific time and hardware where the fault occurred when there is inconsistency, thereby effectively supporting fault diagnosis and security auditing.

[0055] Optionally, the processing priority of each communication protocol can be adaptively adjusted according to the real-time communication load to avoid timeouts of critical data. Specifically, the communication frequency of each physical protocol channel is monitored; the priority of the communication data packets corresponding to each physical protocol channel is determined based on the communication frequency; and high-priority communication data packets are processed first.

[0056] In this embodiment, the communication frequency of each physical protocol channel, i.e., the number of communication data packets arriving per unit time, is monitored in real time. Based on the communication frequency, the current communication urgency of various protocols is assessed, and the priority of each physical protocol channel is dynamically determined. For example, when a sudden increase in the communication frequency of the physical protocol channel corresponding to the steering control-related CAN FD is detected, its priority is increased to higher than the priority of the physical protocol channel corresponding to the entertainment system Ethernet traffic. After the priority is determined, tasks are scheduled for processing according to priority. If necessary, the processing of low-priority communication data packets is paused, and the freed resources are used for the processing of high-priority communication data packets. Low-priority tasks are resumed after the high-priority tasks are completed. This adaptive priority adjustment based on communication frequency can perceive the pressure distribution of mixed traffic in real time and dynamically optimize resource scheduling.

[0057] In this embodiment, by determining the priority of each communication data packet, collaborative optimization of communication data packets of different protocols is achieved.

[0058] S204: Perform consistency verification on the parsing results of multiple data packet identifiers to obtain the verification result of each communication data packet.

[0059] Specifically, multiple parsing results with the same data packet identifier are compared. If multiple parsing results are the same, the verification result of each communication data packet is "verification passed"; if there are different parsing results among the multiple parsing results, the verification result of each communication data packet is "verification failed".

[0060] In this embodiment, multiple parsing results with the same data packet identifier are first divided into a set of parsing results to be verified. Each parsing result within a group is compared one by one. If all parsing results in a group are completely identical, the verification result of the communication data packet is determined to be successful; if any parsing result in the group is different from the others, the verification result is determined to be unsuccessful. This "all identical or no" criterion ensures data integrity with the strictest standards. Any parsing differences caused by momentary failures in the parsing core, data transmission bit flips, or parsing logic errors can be immediately detected and marked as verification failures, effectively preventing erroneous data from entering subsequent vehicle decision-making stages.

[0061] In this embodiment, byte-level comparison can be used during the comparison process. The granularity of the comparison can be the entire parsing result or a preset key field within the parsing result. It should be noted that the consistency check relies on the data packet identifiers generated and bound in the preceding steps, as well as multiple parsing results generated by redundant parsing from multiple parsing cores. The collaboration of these elements enables fault detection and tolerance during the parsing phase through hardware redundancy and voting mechanisms, ensuring the integrity and reliability of communication data used for vehicle operation decisions. This allows the entire communication processing process to meet ISO 26262 ASIL-D level functional safety requirements.

[0062] S205: If the verification result is successful, the corresponding communication data packet is transmitted to the vehicle controller so that the vehicle controller can make vehicle decisions based on the communication data packet.

[0063] For example, communication data packets for steering control, braking, or other safety-critical communication data packets are securely delivered to the vehicle controller after successful verification. If the verification fails, the communication data packet will not be transmitted to the vehicle controller, and a preset fault handling mechanism may be triggered, such as logging the error event, notifying the hardware security unit, or triggering a system degraded operation mode to ensure vehicle safety.

[0064] In this embodiment, if sensitive data is involved in each communication data packet, the sensitive data needs to be encrypted.

[0065] As described above, by using multiple configuration parameters for each communication data packet, multiple communication data packets are allocated to corresponding physical protocol channels. This achieves rapid protocol routing without relying on layer-by-layer frame header expansion in the protocol stack software. This ensures that communication data packets of different protocols are transmitted to their corresponding physical protocol channels at the physical level, achieving decoupling and flexible scheduling in multi-protocol concurrent scenarios. Furthermore, by utilizing multi-core physical protocol parsers configured within each physical protocol channel to perform consistency verification on the parsing results carrying multiple data packet identifiers, the reliability and integrity of communication data packets entering the vehicle controller are ensured. This hardware-software collaborative approach, which configures multi-core physical protocol parsers on the hardware side and allocates physical protocol channels based on configuration parameters on the software side while performing consistency verification, achieves physical routing of communication data packets of different protocols through hardware physical protocol channels, improving the flexibility and real-time efficiency of multi-protocol concurrent processing. Simultaneously, the hardware multi-core physical protocol parser parses communication data packets, forming a two-layer fault-tolerant isolation mechanism in conjunction with software consistency verification, effectively avoiding single-point operational failures and ensuring the integrity of transmitted data. While ensuring the efficiency of communication processing, it also achieves strict protection of data integrity requirements in functional safety regulations.

[0066] Alternatively, high-performance multi-core System on Chip (SoC) and hardware virtualization technology can be used to dynamically load and reconstruct the protocol stack in a software-defined manner, thereby enabling parallel operation of multiple communication protocols, reconstruction of communication data, and resource isolation. However, performance depends on CPU computing power and virtualization overhead, increasing the requirements for other hardware.

[0067] Alternatively, a pseudo-reconstruction can be achieved by enhancing the protocol conversion capabilities of the central gateway, designing the terminal ECUs with simple, fixed protocols, and having the powerful central gateway handle all complex communication protocol conversions and routing. However, the central gateway typically does not use particularly high-performance hardware, and this approach would increase the processing load on the central gateway.

[0068] Based on the above embodiments, this embodiment introduces the process of identifying abnormal communication data packets, which is detailed below: S301: Obtain at least one communication feature of each communication data packet.

[0069] In this embodiment, communication features may include, but are not limited to: communication data packet interval time, communication data packet length distribution, and check error frequency.

[0070] S302: Based on the normal communication characteristics of each communication protocol, determine whether at least one communication characteristic is abnormal.

[0071] In this embodiment, normal communication characteristics can be obtained in advance by statistically modeling the standard communication behaviors of various communication protocols; or the normal communication characteristics can be adaptively updated through online learning by an artificial intelligence compiler. At least one communication characteristic is compared with the normal communication characteristics; if the deviation exceeds a preset deviation tolerance threshold, the data packet is determined to be abnormal.

[0072] The preset deviation tolerance threshold can be adjusted according to the actual situation.

[0073] S303: If an anomaly is detected, the transmission of the communication data packet with the anomaly will be terminated.

[0074] In this embodiment, once an anomaly is detected, the subsequent transmission and parsing of the communication data packet are immediately terminated to prevent abnormal communication data packets from consuming processing resources or causing controller status errors.

[0075] As described above, the solution involves acquiring at least one communication characteristic of each network communication data packet, determining whether at least one communication characteristic is abnormal based on the normal communication characteristics of each communication protocol, and terminating the transmission of the abnormal network communication data packet if an anomaly is detected. By extracting the communication characteristics of communication data packets and comparing them with the normal communication characteristics of the corresponding communication protocol, abnormal behaviors deviating from the normal pattern can be detected. Abnormal communication data packets can be terminated during transmission, effectively improving proactive defense capabilities and further enhancing data integrity.

[0076] Based on the above embodiments, in this embodiment, in order to obtain communication permissions before the physical protocol channel is put into use, the details are as follows: S401: Send a physical protocol channel authentication command to each physical protocol channel, causing the multi-core physical protocol parser in each physical protocol channel to send a key detection request to the hardware security unit, so that the hardware security unit generates a session encryption key for each physical protocol channel when it detects that the hardware identity of the multi-core physical protocol parser is legitimate.

[0077] In this embodiment, each multi-core physical protocol parser has a unique and tamper-proof hardware identity burned into its internal memory.

[0078] In this embodiment, the multi-core physical protocol parser within the physical protocol channel reads its own hardware identity and calculates a digital signature or message authentication code. It then sends a key detection request carrying the digital signature or message authentication code to the hardware security unit, which verifies the correctness of the digital signature or message authentication code. If correct, the hardware identity of the current multi-core physical protocol parser is confirmed as legitimate; if the signature is incorrect, it is determined to be illegitimate hardware, and subsequent services are rejected.

[0079] In this embodiment, once authentication is successful, the hardware security unit runs a key derivation function (such as KDF) to determine the session encryption key for each physical protocol channel.

[0080] S402: After receiving the session encryption key sent by the hardware security unit, perform security initialization on each physical protocol channel.

[0081] In this embodiment, the session encryption key is used to perform secure initialization of each physical protocol channel, including configuring the encryption / decryption engine and initializing the security context.

[0082] S403: After the security initialization of each physical protocol channel is completed, a security start-up completion status is sent to the vehicle central management system so that the vehicle central management system can open the communication permissions of each physical protocol channel; wherein, each communication data packet can only be assigned to the physical protocol channel that has the communication permission.

[0083] In this embodiment, after the security initialization is completed, a security start-up completion status is sent to the vehicle central management system. Based on this, the central management system opens the communication permissions of the physical protocol channel. Unauthorized physical protocol channels cannot participate in the sending and receiving of any communication data packets.

[0084] As described above, sending a physical protocol channel authentication command to each physical protocol channel causes the multi-core physical protocol parser to send a key detection request to the hardware security unit. Upon detecting legitimate hardware identity, the hardware security unit generates a session encryption key for each physical protocol channel. After receiving the key, it performs security initialization on each physical protocol channel. After security initialization is complete, it sends a security startup completion status to the vehicle central management system, enabling the system to grant communication permissions to each physical protocol channel. This ensures that only physical protocol channels that have undergone hardware authentication and completed security initialization have communication permissions and can send and receive data. This establishes a dual security defense at the physical and session layers, preventing unauthorized or illegal physical protocol channels from accessing the vehicle network.

[0085] Based on the above embodiments, an anti-counterfeiting verification mechanism is added during the transmission of communication data packets. Differentiated verification schemes are designed to match the transmission characteristics of the two mainstream heterogeneous automotive protocols, CAN FD and automotive Ethernet. The core purpose is to intercept illegally transmitted communication data packets that have been tampered with, forged, or repeatedly replayed, in order to meet automotive network security regulations.

[0086] Specifically, for CAN FD, all communication data packets of CAN FD must undergo one-time security encryption. The checksum generated for each communication data packet can only be used once. The checksum is calculated by combining the session encryption key of the physical protocol channel, the sequence number of each communication data packet, and the payload data. Each communication data packet has a unique, continuously incrementing sequence number that never repeats. Even if an attacker intercepts a legitimate communication data packet and retransmits it, the expired sequence number will directly determine it as illegitimate, thus preventing replay attacks at their source. The checksum is appended to the end of the communication data packet; the receiving end of the communication data packet recalculates the checksum and compares it; if they do not match, the packet is discarded.

[0087] Specifically, for in-vehicle Ethernet, each in-vehicle Ethernet communication data packet is accompanied by a constrained random verification tag, and an authentication call matrix is ​​predefined.

[0088] In this embodiment, the constrained random verification tag contains a constrained random factor, an incrementing frame number, and a data verification digest, and is attached to the end of the communication data packet.

[0089] In this embodiment, a predefined authentication call matrix is ​​a pre-written rule table. Because the amount of communication data running on the vehicle Ethernet is large, a single set of rules cannot be used to process it. The predefined authentication call matrix is ​​used to quickly match the verification standards of different communication data packets.

[0090] The structure of the predefined authentication call matrix is ​​as follows: Line: Indicates the device that sends the communication data packet (camera, central computing unit, power controller, etc.); Column: Indicates the data type of the communication data packet (high-security control message, intelligent driving perception data, ordinary entertainment message); Table cell: Stores the validation algorithm for the constraint random validation label.

[0091] In order to hierarchically record security events occurring during communication processes using multiple protocols, and to meet the auditability requirements of UNR155 and ISO / SAE 21434, the method of this application also includes the following steps: S601: Monitor security events that occur during the processing of various communication data packets.

[0092] In this embodiment, various security events occurring during the processing of each communication data packet are continuously monitored, including but not limited to: Electronic Control Unit (ECU) restart, watchdog timeout, security verification failure, key synchronization failure, secure boot failure, communication controller hardware error, communication data packet verification error, and excessive communication load.

[0093] S602: Based on the preset log design goals, design a log storage structure for storing security events.

[0094] In this embodiment, the preset log design goal is: a) Security First: The logs themselves must be tamper-proof, and critical security logs must be encrypted in real time and output to a protected storage area.

[0095] b) Auditability: Meets the requirements of UN R155 (Vehicle Cybersecurity Regulation) regarding CSMS (Cybersecurity Management System), enabling the tracing of the entire process of cybersecurity incident occurrence and handling.

[0096] c) Diagnosis and Debugging: Provides logs of different levels of detail for development debugging, production line testing, after-sales diagnosis, and on-site problem reproduction.

[0097] d) Performance and Efficiency: The overhead of the logging system must be clearly constrained to ensure it does not impact the real-time performance of critical communication tasks. Binary and circular caching mechanisms should be employed to reduce I / O (computer interface) and storage pressure.

[0098] e) Multi-mode adaptation: The log format and content can adapt to different communication protocols and different operating modes (normal, debugging, security emergency).

[0099] S603: Determine the log level corresponding to the security event.

[0100] In this embodiment, nine log levels, from 0 to 8, are defined according to the ISO / SAE 21434 (Road Vehicles - Cybersecurity Engineering) standard: EMERGENCY (0): System unavailable. Example scenarios: ECU suddenly restarts, watchdog timeout, and security verification completely fails.

[0101] ALERT (1): Security events requiring immediate action. Example scenarios: Detection of denial-of-service attacks, key synchronization failures, and secure boot failures.

[0102] CRITICAL (2): Critical error affecting major functions. Example scenarios: Hardware errors in the communication controller and failures in the hardware engine responsible for encryption, etc.

[0103] ERROR (3): General error, but functionality may be degraded. Example scenarios: Occasional communication packet verification errors, sensor signal timeouts, and node loss, etc.

[0104] WARNING (4): Warning, may indicate a potential problem. Example scenarios: excessive communication load, memory usage exceeding threshold, and non-critical task timeouts.

[0105] NOTICE (5): Normal but important times. Example scenarios: successful establishment of a security session, completion of firmware update, and configuration changes, etc.

[0106] INFO (6): Runtime information used to track status. Example scenarios: Communication protocol switched from CAN to Ethernet, filter rules were updated, or a node went online or offline.

[0107] DEBUG (7): Detailed debugging information, typically enabled only during the development phase. Example scenarios: raw communication data packets (which need to be anonymized), printed function call stacks, and internal state machine transition records, etc.

[0108] TRACE (8): The most detailed execution trace, with a significant impact on performance, is only used for locating problems in extreme cases. Example scenario: Recording the entry and exit times of each interrupt for analyzing microsecond-level timing issues.

[0109] For example, when a security event is identified as excessive communication load, multiple preset log levels are checked, and it is found that excessive communication load is defined as the WARNING level.

[0110] S604: Based on the log level, the security event is saved to the log storage structure to obtain the log record of the security event.

[0111] In this embodiment, the logs are not only statically stored locally, but also provide standardized program call interfaces to support automated auditing. By adopting a hierarchical logging mechanism, storage and retrieval efficiency are optimized, and a complete and traceable record is provided for subsequent auditing and evidence collection.

[0112] As described above, monitoring security events that occur during the processing of various communication data packets involves designing a log storage structure for storing security events based on preset log design goals, determining the log level corresponding to each security event, and saving security events to the log storage structure according to their log levels. This approach can uniformly record security events at different log levels, optimizing storage and retrieval efficiency while providing a traceable and complete basis for subsequent auditing and evidence collection.

[0113] Figure 3 This is a schematic diagram of the structure of a multi-protocol communication processing device provided in an embodiment of this application. Figure 3 As shown, the multi-protocol communication processing device, applied to an electronic device, includes: a receiving module 301, an allocation module 302, a parsing module 303, a verification module 304, and a transmission module 305.

[0114] The receiving module 301 is used to receive multiple communication data packets sent by communication terminals with different protocols, and to obtain multiple configuration parameters of each communication data packet.

[0115] The allocation module 302 is used to allocate corresponding physical protocol channels to each communication data packet according to multiple configuration parameters; wherein each physical protocol channel is configured with a corresponding multi-core physical protocol parser.

[0116] The parsing module 303 is used to transmit each communication data packet to the multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser can parse each communication data packet and obtain multiple parsing results carrying data packet identifiers.

[0117] The verification module 304 is used to perform consistency verification on the parsing results of multiple data packet identifiers to obtain the verification result of each communication data packet.

[0118] The transmission module 305 is used to transmit the corresponding communication data packet to the vehicle controller if the verification result is successful, so that the vehicle controller can make vehicle decisions based on the communication data packet.

[0119] In one possible implementation of this application, the allocation module 302 is specifically used to: perform hash calculation on multiple configuration parameters to obtain hash values ​​of multiple configuration parameters; obtain the physical protocol channel identifier corresponding to the hash value from a pre-built communication protocol specification dictionary; and allocate the communication data packets corresponding to the multiple configuration parameters to the physical protocol channel corresponding to the physical protocol channel identifier.

[0120] In one possible implementation of this application, the parsing module 303 is specifically used for: distributing each communication data packet to multiple parsing cores by the multi-core physical protocol parser; parsing each communication data packet according to the corresponding communication protocol by each parsing core based on the real-time operating system to obtain the parsing result; generating a data packet identifier for each communication data packet; and binding the data packet identifier to the corresponding parsing result to obtain multiple parsing results carrying data packet identifiers.

[0121] In one possible implementation of this application, the parsing module 303 is further configured to: obtain the reception time and physical address of each communication data packet; and generate a data packet identifier based on the reception time and physical address.

[0122] In one possible implementation of this application, the verification module 304 is specifically used to: compare multiple parsing results with the same data packet identifier; if the multiple parsing results are the same, the verification result of each communication data packet is that the verification is passed; if there are different parsing results among the multiple parsing results, the verification result of each communication data packet is that the verification is failed.

[0123] In one possible implementation of this application, the multi-protocol communication processing apparatus further includes a determining module. The determining module is specifically configured to: monitor the communication frequency of each physical protocol channel; determine the priority of the communication data packets corresponding to each physical protocol channel based on the communication frequency; and prioritize the processing of communication data packets with higher priority.

[0124] In one possible implementation of this application, the multi-protocol communication processing device further includes a judgment module. The judgment module is specifically configured to: acquire at least one communication feature of each communication data packet; determine whether at least one communication feature is abnormal based on the normal communication features of each communication protocol; and if an abnormality is determined to exist, terminate the transmission of the abnormal communication data packet.

[0125] In one possible implementation of this application, the multi-protocol communication processing device further includes a communication permission acquisition module. Specifically, the communication permission acquisition module is used to: send a physical protocol channel authentication command to each physical protocol channel, causing the multi-core physical protocol parser in each physical protocol channel to send a key detection request to the hardware security unit, so that the hardware security unit generates a session encryption key for each physical protocol channel when it detects that the hardware identity of the multi-core physical protocol parser is legitimate; after receiving the session encryption key sent by the hardware security unit, perform security initialization on each physical protocol channel; after the security initialization of each physical protocol channel is completed, send a security startup completion status to the vehicle central management system, so that the vehicle central management system opens the communication permissions of each physical protocol channel; wherein, each communication data packet is only allowed to be allocated to the physical protocol channel that has the communication permission.

[0126] In one possible implementation of this application, the multi-protocol communication processing device further includes a log storage module. Specifically, the log storage module is used to: monitor security events occurring during the processing of each communication data packet; design a log storage structure for storing security events based on a preset log design goal; determine the log level corresponding to the security event; and save the security event to the log storage structure according to the log level, thereby obtaining a log record of the security event.

[0127] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device of this embodiment includes a processor 401 and a memory 402.

[0128] The memory 402 stores computer execution instructions; the processor 401 executes the computer execution instructions stored in the memory to implement the various steps performed by the electronic device in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0129] Alternatively, the memory 402 can be either standalone or integrated with the processor 401.

[0130] When the memory 402 is set up independently, the electronic device also includes a bus 403 for connecting the memory 402 and the processor 401.

[0131] This application embodiment also provides a vehicle, which includes: a vehicle body, the vehicle body being configured with the aforementioned electronic equipment, the electronic equipment being used to execute the aforementioned multi-protocol communication processing method.

[0132] This application also provides a computer storage medium storing computer execution instructions. When the processor executes the computer execution instructions, the above-described multi-protocol communication processing method is implemented.

[0133] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described multi-protocol communication processing method.

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

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

[0136] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0137] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0138] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0139] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0140] 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. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0141] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0142] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0143] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for processing multi-protocol communication, characterized in that, include: Receive multiple communication data packets sent by communication terminals with different protocols, and obtain multiple configuration parameters for each communication data packet; Based on the multiple configuration parameters, each communication data packet is assigned a corresponding physical protocol channel; wherein each physical protocol channel is configured with a corresponding multi-core physical protocol parser; Each communication data packet is transmitted to the multi-core physical protocol parser corresponding to each physical protocol channel, so that the multi-core physical protocol parser parses each communication data packet and obtains multiple parsing results carrying data packet identifiers; The parsing results of the multiple data packet identifiers are subjected to consistency verification to obtain the verification result of each communication data packet; If the verification result is successful, the corresponding communication data packet is transmitted to the vehicle controller so that the vehicle controller can make vehicle decisions based on the communication data packet.

2. The method according to claim 1, characterized in that, The step of allocating corresponding physical protocol channels to each communication data packet according to the multiple configuration parameters includes: Perform hash calculations on the multiple configuration parameters to obtain the hash values ​​of the multiple configuration parameters; Obtain the physical protocol channel identifier corresponding to the hash value from the pre-built communication protocol specification dictionary; The communication data packets corresponding to the multiple configuration parameters are assigned to the physical protocol channel corresponding to the physical protocol channel identifier.

3. The method according to claim 1, characterized in that, The multi-core physical protocol parser parses each communication data packet to obtain multiple parsing results carrying data packet identifiers, including: The multi-core physical protocol parser distributes each communication data packet to multiple parsing cores; Each of the aforementioned parsing cores, based on a real-time operating system, parses each communication data packet according to the corresponding communication protocol to obtain the parsing result; and generates a data packet identifier for each communication data packet. The packet identifier is bound to the corresponding parsing result to obtain multiple parsing results carrying the packet identifier.

4. The method according to claim 3, characterized in that, The data packet identifier for generating each communication data packet includes: Obtain the reception time and physical address of each communication data packet; A data packet identifier is generated based on the received time and the physical address.

5. The method according to claim 1, characterized in that, The process of performing a consistency check on the parsing results of the multiple data packet identifiers to obtain the check result of each communication data packet includes: Compare multiple parsing results with the same data packet identifier. If the multiple parsing results are the same, the verification result of each communication data packet is verified as passed. If there are different parsing results among the multiple parsing results, then the verification result of each communication data packet is that the verification fails.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Monitor the communication frequency of each physical protocol channel; Based on the communication frequency, the priority of the communication data packets corresponding to each physical protocol channel is determined; The high-priority communication data packets are processed first.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain at least one communication feature of each communication data packet; Based on the normal communication characteristics of each communication protocol, determine whether the at least one communication characteristic is abnormal; If an anomaly is detected, the transmission of the communication data packet with the anomaly will be terminated.

8. The method according to any one of claims 1-5, characterized in that, The method further includes: A physical protocol channel authentication command is sent to each physical protocol channel, causing the multi-core physical protocol parser in each physical protocol channel to send a key detection request to the hardware security unit, so that the hardware security unit generates a session encryption key for each physical protocol channel when it detects that the hardware identity of the multi-core physical protocol parser is legitimate. Upon receiving the session encryption key sent by the hardware security unit, the system performs security initialization on each physical protocol channel. After the security initialization of each physical protocol channel is completed, a security start-up completion status is sent to the vehicle central management system so that the vehicle central management system can open the communication permissions of each physical protocol channel; wherein, each communication data packet can only be assigned to the physical protocol channel that has the communication permission.

9. The method according to any one of claims 1-5, characterized in that, The method further includes: Monitor security events that occur during the processing of the aforementioned communication data packets; Based on the preset log design goals, a log storage structure for storing the security events is designed; Determine the log level corresponding to the security event; Based on the log level, the security event is saved to the log storage structure to obtain the log record of the security event.

10. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the multi-protocol communication processing method according to any one of claims 1 to 9.

Images