A method for realizing micro-service communication based on CAN bus protocol

Abstract

The application provides a method for realizing micro-service communication based on CAN bus protocol, comprising the following steps: S100, registering a standard network device in an operating system kernel and configuring a data transmission threshold for the standard network device; S200, establishing an IP address when the system starts and configuring a CAN channel number corresponding to the IP address, and meanwhile, establishing a mapping relationship table between the CAN channel number and the IP address corresponding thereto; S300, the kernel protocol stack sending a data packet; S400, the kernel protocol stack receiving a data packet; under the premise of not modifying the kernel protocol stack, the lossless bidirectional mapping between the standard IP data packet and the CAN FD frame is realized through the driving, the compatibility problem of the standard network model and the low-bandwidth bus is solved, and the existing micro-service ecology can be compatible, for example, gRPC, HTTP, MQTT and WebSocket can be directly run without any code modification.

Description

Technical Field

[0001] This invention relates to the technical field of microservice communication, and specifically to a method for implementing microservice communication based on the CAN bus protocol. Background Technology

[0002] Current microservice architectures generally rely on standard TCP / IP networks for inter-service communication, typically running on high-bandwidth links such as Ethernet or Wi-Fi, and utilizing the complete network protocol stack and Socket API provided by the operating system kernel. In embedded scenarios such as automotive or industrial control, some nodes are only equipped with a CAN FD bus interface and lack Ethernet capability. Existing solutions, if they need to transmit network data over the CAN FD, typically use the following methods: 1) Custom private protocol: The application layer directly manipulates the CAN frame ID and data field to achieve point-to-point communication; 2) Modify the kernel protocol stack: trim the IP / TCP headers to accommodate the CAN FD 64-byte limit; 3) Introduce an intermediate communication proxy: perform protocol conversion at the gateway node, and separate the CAN side from the Ethernet side.

[0003] The defects and shortcomings of the above method are as follows: 1) Private protocols lead to ecosystem fragmentation: Microservices need to customize dedicated communication logic for the CAN bus, making it impossible to reuse standard network libraries (such as libcurl, gRPC, etc.), resulting in high development and maintenance costs and difficulty in unifying the architecture with cloud-side services.

[0004] 2) The protocol stack modification is highly invasive: trimming the TCP / IP header requires deep modification of the operating system kernel, which can damage system stability and cannot coexist with standard network cards. It is not suitable for mixed network environments (such as domain controllers that contain both Ethernet and CAN).

[0005] 3) Lack of transparent network abstraction: Existing solutions cannot present CAN FD devices as standard network interfaces, and the upper-layer protocol stack cannot be used directly, resulting in strong coupling between network capabilities and physical interfaces, which limits the deployment flexibility of microservices on resource-constrained nodes.

[0006] Therefore, there is an urgent need to provide a new solution to address the defects and shortcomings of the existing technologies. Summary of the Invention

[0007] To address the shortcomings and deficiencies in existing technologies, this invention provides a method for implementing microservice communication based on the CAN bus protocol.

[0008] The specific solution provided by this invention is as follows: A method for implementing microservice communication based on the CAN bus protocol, characterized in that the method includes the following steps: S100: Registers standard network devices within the operating system kernel and configures data transmission thresholds for these standard network devices; S200: When the system starts up, an IP address is established and the CAN channel number corresponding to the IP address is configured. At the same time, a mapping table between the CAN channel number and its corresponding IP address is established. S300: When the kernel protocol stack sends data packets: S301: The driver intercepts standard IP packets sent by the protocol stack and parses the packet information corresponding to the standard IP packet; S302: Query the mapping table to convert the IP address in the data packet information into its corresponding CAN channel number; S303: Constructing compressed frames and compressed frame headers: S304: Calls the CAN controller register to send the compressed frame as a CAN FD data frame; S400: When the kernel protocol stack receives data packets: S401: The CAN controller reads its internal data after receiving a CAN FD data frame; S402: Based on the CAN channel number, query the mapping table to restore its corresponding IP address; S403: Construct a complete standard IP packet and fill in the restored packet information; S404: Submit the constructed complete standard IP packet to the protocol stack.

[0009] As a further preferred embodiment of the present invention, in step S100, standard network devices are registered within the operating system kernel using either a static configuration file or a dynamic service registration method.

[0010] As a further preferred embodiment of the present invention, in step S100, the data transmission threshold configured for the standard network device includes an overall data transmission threshold, and the overall data transmission threshold is equal to the sum of the standard protocol header threshold and the payload threshold.

[0011] As a further preferred embodiment of the present invention, in step S200: Each CAN channel number occupies only 1 byte in length, and each CAN channel number corresponds to only one unique communication node; The mapping table enables bidirectional conversion between each CAN channel number and its corresponding IP address.

[0012] As a further preferred embodiment of the present invention, in step S301, the standard IP data packet includes at least an IP header, a TCP header, and payload data.

[0013] As a further preferred embodiment of the present invention, in step S301, the data packet information includes at least the source IP address, destination IP address, port information, and protocol type.

[0014] As a further preferred embodiment of the present invention, the compressed frame header structure constructed in step S303 includes: CAN channel identifier: It includes the target channel, source channel, and protocol identifier; IP metadata includes total length, ID number, flags and fragment offset, time to live and protocol number, source IP address and destination IP address; Transport layer header: It includes: TCP: source port, destination port, sequence number, acknowledgment number, header length, reserved bits, control bits, and sliding window; or UDP: Source port and destination port; The compressed frame is a combination of a constructed compressed frame header and payload data extracted from a standard IP packet.

[0015] As a further preferred embodiment of the present invention, in step S303, payload data in the standard IP data packet is extracted according to the payload threshold: When the payload data in the standard IP packet does not exceed the effective payload threshold, all payload data is truncated. When the payload data in the standard IP packet exceeds the effective payload threshold, only the effective payload threshold of the payload data is truncated, and the excess part is reassembled and fragmented by the driver. The recombining and fragmentation process includes the following steps: 1) Calculate the total number of pieces; Total number of pieces = Original load total length / Effective load threshold, where the total number of pieces is rounded to the nearest integer; 2) Assign fragment identifier: Assign a unique ID number to the fragment and fill it into the ID number field in the IP metadata; 3) Piece-by-piece encapsulation: Compressed frames are constructed piece by piece, sequentially truncating from the original payload, with each effective payload threshold byte constituting one piece. 4) Cyclic transmission: The CAN controller register is called sequentially to send each compressed frame as an independent CAN FD data frame to the CAN bus; 5) Release resources: After all fragments have been sent, release the memory cache occupied by the original payload data.

[0016] As a further preferred embodiment of the present invention, in step S401, after the CAN controller receives the CAN FD data frame, it first triggers an interrupt and then reads the data through the driver.

[0017] As a further preferred embodiment of the present invention, between step S401 and step S402, the following is also included: Step S4011: Determine whether recombined fragments exist using the following method: 1) Determine based on ID number: Read the ID number field in the IP metadata. If multiple consecutively received frames have the same ID number, determine that they belong to the same fragment group of the original data packet, thus indicating the existence of reassembled fragments; or: 2) Determine based on the MF flag bit in the flag and fragment offset fields: Read the highest bit of the flag and fragment offset fields in the IP metadata. If the value of the MF flag bit is 1, it clearly indicates that there are subsequent fragments after the current frame, thus determining that there are reassembled fragments. If recombined fragments are determined to exist, extract their original payload data according to the following steps: 1) Establish a reassembly buffer: Create a corresponding reassembly buffer in memory using the received ID number as a unique index; 2) Store payload by offset: Calculate the location of the payload fragment in the reassembly buffer based on the fragment offset field in the current frame's IP metadata. 3) Timeout protection: Start the reassembly timeout timer. If all fragments are not collected before the timer expires, discard all data in the reassembly buffer and release the memory. 4) Integrity check: When the MF flag is received as 0, an integrity check is performed: if the check passes, it is confirmed that all data has been received; if it fails, continue to wait for subsequent fragments. 5) Sequential splicing and restoration: The load data of all fragments in the reassembly buffer are spliced ​​sequentially in ascending order of fragment offset to restore the complete original load data; 6) Construct and submit: Using the spliced ​​complete original payload data, combined with the restored source IP, destination IP and port information, construct a complete standard IP data packet and submit it to the kernel protocol stack.

[0018] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a method for implementing microservice communication based on the CAN bus protocol. Without modifying the kernel protocol stack, it achieves lossless bidirectional mapping between standard IP data packets and CAN FD frames through a driver, solving the compatibility problem between standard network models and low-bandwidth buses. It is compatible with the existing microservice ecosystem, such as gRPC, HTTP, MQTT, WebSocket, etc., which can all run directly without any code modification.

[0019] 2) This invention provides a method for implementing microservice communication based on the CAN bus protocol. It utilizes the fixed topology characteristics of CAN FD to compress the IP address into a 1-byte channel identifier and dynamically restores it through the driver to achieve the binding of address semantics with physical channels.

[0020] 3) This invention provides a method for implementing microservice communication based on the CAN bus protocol. By constructing a compressed frame header, the protocol header is compressed to 27 bytes while retaining key semantics such as port, serial number, and checksum. This allows the CAN FD 64-byte frame to still carry 37 bytes of valid business data, balancing efficiency and reliability while improving payload data efficiency. The payload data can occupy a maximum of 37 bytes per frame, accounting for 58% (37 / 64), which is much higher than the unoptimized solution (12 bytes).

[0021] 4) This invention provides a method for implementing microservice communication based on the CAN bus protocol, achieving zero-intrusion deployment. Only a driver module needs to be loaded to virtualize the CAN FD interface into a standard network card, and it supports coexistence with Ethernet cards and unified routing.

[0022] 5) This invention provides a method for implementing microservice communication based on the CAN bus protocol, which has low resource consumption: it can be applied to typical scenarios such as vehicle SOA and industrial edge microservices, and provides standard network communication capabilities for ECUs / PLCs without Ethernet interfaces. Attached Figure Description

[0023] Figure 1 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation

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

[0025] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0026] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0027] [First Embodiment] like Figure 1 The first embodiment of the present invention provides a method for implementing microservice communication based on the CAN bus protocol, comprising the following steps: S100: Registers standard network devices within the operating system kernel and configures data transmission thresholds for these standard network devices; As an optional method, in step S100, standard network devices are registered within the operating system kernel using either a static configuration file or a dynamic service registration method. Specifically: The static configuration file method is suitable for scenarios where the network topology is fixed and the nodes do not change frequently. Its advantages are simple implementation, no need to rely on external services, fast system startup speed and high determinism. The dynamic service registration method is suitable for scenarios that support hot-swapping and where nodes may dynamically join or leave. Its advantages are high flexibility, good scalability, and the ability to take effect without restarting the system, making it easy for large-scale deployment and online system upgrades.

[0028] The data transmission threshold configured for this standard network device includes an overall data transmission threshold, which is equal to the sum of the standard protocol header threshold and the payload threshold. By limiting the maximum length (MTU) of a single data packet or data frame, it can be recognized and used by the standard network protocol stack.

[0029] In this embodiment, the data transmission threshold configured for the standard network device is 77 bytes, of which the standard protocol header threshold is 27 bytes and the payload threshold is 37 bytes. That is, in this embodiment, the MTU is set to 77 bytes, including a 27-byte standard protocol header threshold and a 37-byte payload threshold.

[0030] S200: When the system starts up, an IP address is established and the CAN channel number corresponding to the IP address is configured. At the same time, a mapping table between the CAN channel number and its corresponding IP address is established. In this embodiment, Each CAN channel number occupies only 1 byte (e.g., 0x00~0xFF), and each CAN channel number corresponds to only one communication node; The mapping table enables bidirectional conversion between each CAN channel number and its corresponding IP address.

[0031] By utilizing the fixed topology characteristics of CAN FD, the IP address is compressed into a 1-byte channel identifier, and dynamically restored by the driver, thus achieving the binding of address semantics with the physical channel.

[0032] S300: When the kernel protocol stack sends data packets: S301: The driver intercepts standard IP packets sent by the protocol stack and parses the packet information corresponding to the standard IP packet; In this embodiment, a standard IP packet includes at least an IP header (20 bytes), a TCP header (20 bytes), and payload data.

[0033] Furthermore, the data packet information should include at least the source IP address, destination IP address, port information, and protocol type; S302: Query the mapping table to convert the IP address in the data packet information into its corresponding CAN channel number; S303: Constructing compressed frames and compressed frame headers: In this embodiment, the constructed compressed frame header occupies a total length of 27 bytes, and its structure includes: CAN channel identifier (3 bytes): It includes the target channel (1 byte), the source channel (1 byte), and the protocol identifier (3 bytes), where the protocol identifier can be represented as, for example, 0x06=TCP, 0x11=UDP; IP metadata (8 bytes): It includes total length (1 byte), ID number (2 bytes), flags and fragment offset (2 bytes), time to live (TTL, used to limit the maximum number of hops a packet can survive in the network, this value is decremented by 1 each time it passes through a routing node, and the packet is discarded when it reaches 0), protocol number (1 byte), source IP address (1 byte), and destination IP address (1 byte). Transport layer header (maximum 16 bytes): It includes: TCP: Source port (2 bytes), destination port (2 bytes), sequence number (4 bytes), acknowledgment number (4 bytes), header length, reserved bits, control bits (2 bytes), and sliding window (2 bytes); or UDP: Source port (2 bytes) and destination port (2 bytes); A compressed frame is a combination of a constructed compressed frame header and payload data extracted from a standard IP packet.

[0034] For example: Suppose there is a device with IP address 192.168.1.100, whose corresponding source channel number is 0x01, obtained from the mapping table; the target device's IP address is 192.168.1.200, and its corresponding target channel number is 0x02. Using the UDP protocol for communication, the original payload data is "HELLO CAN FD" (12 bytes in total), which does not exceed the effective payload threshold (49 bytes in a UDP scenario), therefore fragmentation is unnecessary.

[0035] Its original number of bytes satisfies: IP metadata: Source IP = 192.168.1.100, Destination IP = 192.168.1.200, Total length = 32 bytes, TTL = 64, Protocol = UDP(17); Original occupancy is 20 bytes; UDP: Source port = 49152 (0xC000), Destination port = 80 (0x0050); Original size is 8 bytes; The original payload data is "HELLO CAN FD", and the original number of bytes occupied is 12. Therefore, the original total number of bytes occupied is 40 bytes.

[0036] In the compressed CAN FD frame structure, the compressed frame header is 15 bytes long (UDP scenario), as follows: CAN channel identifier (3 bytes in total): Target channel 0x02 (1 byte), Source channel 0x01 (1 byte), and Protocol identifier 0x11 (1 byte); IP metadata (8 bytes in total): Total length 0x0C (1 byte), ID number 0x00 0x01 (2 bytes), Flags and fragment offset 0x00 0x00 (2 bytes), Time to Live (TTL=64) and Protocol number (UDP=17, 1 byte), Source IP address 0x01 (1 byte) and Destination IP address 0x02 (1 byte); UDP transport header: source port 0xC0 0x00 (2 bytes) and destination port 0x00 0x50 (2 bytes); Therefore, the compressed frame header in this embodiment only occupies 15 bytes.

[0037] By constructing a compressed frame header and compressed frame, the protocol header is compressed to 27 bytes while retaining key semantics such as port, sequence number, and checksum. This allows the CAN FD 64-byte frame to still carry 37 bytes of valid service data, balancing efficiency and reliability.

[0038] It is worth noting that in this step, payload data in standard IP packets is truncated according to the payload threshold (37 bytes): When the payload data in the standard IP packet does not exceed the effective payload threshold, all payload data is truncated. When the payload data in the standard IP packet exceeds the effective payload threshold, only the effective payload threshold of the payload data is truncated, and the excess part is reassembled and fragmented by the driver. The reassembly and fragmentation process includes the following steps: 1) Calculate the total number of fragments; Total number of fragments = Original payload total length / Payload threshold, where the total number of fragments is rounded to the nearest integer; for example: if the original payload length is 120 bytes and the payload threshold in a UDP scenario is 49 bytes, then the total number of fragments = (120 / 49) ≈ 3 fragments. 2) Assign fragment identifier: Assign a unique ID number (2 bytes) to the fragment and fill it into the ID number field in the IP metadata; the ID number starts from 0x0001 and increments, and is used to identify all fragments belonging to the same original data packet at the receiving end; 3) Piece-by-piece encapsulation: Compressed frames are constructed piece by piece by sequentially extracting data from the original payload, with each effective payload threshold byte constituting one piece. This includes the following steps: 3.1) Copy the compressed frame header; each fragment shares the same CAN channel identifier and IP metadata (except for flags and fragment offsets); 3.2) Fill in the fragment offset; the fragment offset is the offset of the current fragment in the original payload, that is, the product of (frame number - 1) and the payload threshold, and fill the calculation result into the flag and fragment offset fields in the IP metadata; 3.3) Set the MF flag; except for the last fragment (MF=0, indicating no subsequent fragments), set MF=1 for all other fragments (indicating there are still subsequent fragments). 3.4) Enter the frame number (implicit); the frame number can be derived from the fragment offset and does not need to be stored separately.

[0039] 4) Cyclic transmission: The CAN controller register is called sequentially to send each compressed frame as an independent CAN FD data frame to the CAN bus; 5) Release resources: After all fragments have been sent, release the memory cache occupied by the original payload data.

[0040] While balancing efficiency and reliability, it improves payload data efficiency. A single frame of payload data can occupy up to 37 bytes, accounting for 58% (37 / 64), which is much higher than the unoptimized solution (12 bytes).

[0041] S304: Calls the CAN controller register to send the compressed frame as a CAN FD data frame; S400: When the kernel protocol stack receives data packets: S401: After receiving a CAN FD data frame, the CAN controller reads its internal data. In this process, after receiving a CAN FD data frame, the CAN controller first triggers an interrupt and then reads the data through the driver. Interrupts are a common way for operating systems to handle events. After receiving a CAN FD data frame, the CAN controller first triggers a hardware interrupt to the CPU. Its purpose is to promptly notify the CPU that a new data frame has arrived, avoiding the CPU continuously polling the CAN controller status and consuming system resources. After the CPU responds to the interrupt, it enters the interrupt service routine and reads the internal data of the CAN FD data frame from the CAN controller's receive buffer through the driver.

[0042] S402: Based on the CAN channel number, query the mapping table to restore its corresponding IP address; Corresponding to the above, between steps S401 and S402, there is also step S4011: determining whether recombined fragments exist by means of the following method: 1) Determine based on ID number: Read the ID number field in the IP metadata. If multiple consecutively received frames have the same ID number, determine that they belong to the same fragment group of the original data packet, thus indicating the existence of reassembled fragments; or 2) Determine based on the MF flag bit in the flag and fragment offset fields: Read the highest bit of the flag and fragment offset fields in the IP metadata. If the value of the MF flag bit is 1, it clearly indicates that there are subsequent fragments after the current frame, thus determining that there are reassembled fragments. If recombined fragments are determined to exist, extract their original payload data according to the following steps: 1) Establish a reassembly buffer: Create a corresponding reassembly buffer in memory using the received ID number as a unique index; the reassembly buffer shall include at least: ID number identifier, total number of fragments (recorded when MF value is 0), received fragment count counter, payload data storage area organized by offset (size = original payload total length), and timeout timer; 2) Store payload by offset: Calculate the location of the payload fragment in the reassembly buffer based on the fragment offset field in the current frame's IP metadata. Storage start position = fragment offset; Then copy the payload data of the frame to the corresponding location in the reconstruction buffer; Example: Threshold = 49 bytes, original payload 120 bytes divided into 3 pieces: The first frame has a fragment offset of 0, a payload length of 49 bytes, and a buffer storage location of [0:48]. The frame number is 2, its fragment offset is 49, the payload length is 49 bytes, and the buffer storage location is [49:97]. The frame number is 3, its fragment offset is 98, its payload length is 22 bytes, and its buffer storage location is [98:119]. 3) Timeout protection: Start the reassembly timeout timer (e.g., 100ms). If all fragments are not collected before the timer expires, discard all data in the reassembly buffer and release the memory to prevent memory overflow. 4) Integrity check: When the MF flag is received as 0 (last piece), an integrity check is performed. Verification criteria: Number of received fragments × threshold ≥ total length in IP metadata; if the verification passes, it is confirmed that all data has been received; if it fails, continue to wait for subsequent fragments (until timeout or all fragments are received). 5) Sequential splicing and restoration: The load data of all fragments in the reassembly buffer are spliced ​​sequentially in ascending order of fragment offset to restore the complete original load data; 6) Construct and submit: Using the spliced ​​complete original payload data, combined with the restored source IP, destination IP, port and other information, construct a complete standard IP data packet and submit it to the kernel protocol stack.

[0043] S403: Construct a complete standard IP packet and fill in the restored packet information; S404: Submit the constructed complete standard IP packet to the protocol stack.

[0044] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for implementing microservice communication based on the CAN bus protocol, characterized in that: The method includes the following steps: S100: Registers standard network devices within the operating system kernel and configures data transmission thresholds for these standard network devices; S200: When the system starts up, an IP address is established and the CAN channel number corresponding to the IP address is configured. At the same time, a mapping table between the CAN channel number and its corresponding IP address is established. S300: When the kernel protocol stack sends data packets: S301: The driver intercepts standard IP packets sent by the protocol stack and parses the packet information corresponding to the standard IP packet; S302: Query the mapping table to convert the IP address in the data packet information into its corresponding CAN channel number; S303: Constructing compressed frames and compressed frame headers: S304: Calls the CAN controller register to send the compressed frame as a CAN FD data frame; S400: When the kernel protocol stack receives data packets: S401: The CAN controller reads its internal data after receiving a CAN FD data frame; S402: Based on the CAN channel number, query the mapping table to restore its corresponding IP address; S403: Construct a complete standard IP packet and fill in the restored packet information; S404: Submit the constructed complete standard IP packet to the protocol stack.

2. The method for implementing microservice communication based on the CAN bus protocol according to claim 1, characterized in that: In step S100, standard network devices are registered within the operating system kernel using either a static configuration file or a dynamic service registration method.

3. The method for implementing microservice communication based on the CAN bus protocol according to claim 2, characterized in that: In step S100, the data transmission threshold configured for the standard network device includes an overall data transmission threshold, and the overall data transmission threshold is equal to the sum of the standard protocol header threshold and the payload threshold.

4. The method for implementing microservice communication based on the CAN bus protocol according to claim 3, characterized in that: In step S200: Each CAN channel number occupies only 1 byte in length, and each CAN channel number corresponds to only one unique communication node; The mapping table enables bidirectional conversion between each CAN channel number and its corresponding IP address.

5. The method for implementing microservice communication based on the CAN bus protocol according to claim 4, characterized in that: In step S301, the standard IP data packet includes at least an IP header, a TCP header, and payload data.

6. The method for implementing microservice communication based on the CAN bus protocol according to claim 5, characterized in that: In step S301, the data packet information includes at least the source IP address, destination IP address, port information, and protocol type.

7. A method for implementing microservice communication based on the CAN bus protocol according to claim 6, characterized in that: In step S303, the constructed compressed frame header structure includes: CAN channel identifier: It includes the target channel, source channel, and protocol identifier; IP metadata includes total length, ID number, flags and fragment offset, time to live and protocol number, source IP address and destination IP address; Transport layer header: It includes: TCP: source port, destination port, sequence number, acknowledgment number, header length, reserved bits, control bits, and sliding window; or UDP: Source port and destination port; The compressed frame is a combination of a constructed compressed frame header and payload data extracted from a standard IP packet.

8. A method for implementing microservice communication based on the CAN bus protocol according to claim 7, characterized in that: In step S303, payload data is extracted from the standard IP data packet according to the payload threshold: When the payload data in the standard IP packet does not exceed the effective payload threshold, all payload data is truncated. When the payload data in the standard IP packet exceeds the effective payload threshold, only the effective payload threshold of the payload data is truncated, and the excess part is reassembled and fragmented by the driver. The recombining and fragmentation process includes the following steps: 1) Calculate the total number of pieces; Total number of pieces = Original load total length / Effective load threshold, where the total number of pieces is rounded to the nearest integer; 2) Assign fragment identifier: Assign a unique ID number to the fragment and fill it into the ID number field in the IP metadata; 3) Piece-by-piece encapsulation: Compressed frames are constructed piece by piece, sequentially truncating from the original payload, with each effective payload threshold byte constituting one piece. 4) Cyclic transmission: The CAN controller register is called sequentially to send each compressed frame as an independent CAN FD data frame to the CAN bus; 5) Release resources: After all fragments have been sent, release the memory cache occupied by the original payload data.

9. The method for implementing microservice communication based on the CAN bus protocol according to claim 1, characterized in that: In step S401, after the CAN controller receives the CAN FD data frame, it first triggers an interrupt and then reads the data through the driver.

10. A method for implementing microservice communication based on the CAN bus protocol according to claim 8, characterized in that: Between step S401 and step S402, the following is also included: Step S4011: Determine whether recombined fragments exist using the following method: 1) Determine based on ID number: Read the ID number field in the IP metadata. If multiple consecutively received frames have the same ID number, determine that they belong to the same fragment group of the original data packet, thus indicating the existence of reassembled fragments; or: 2) Determine based on the MF flag bit in the flag and fragment offset fields: Read the highest bit of the flag and fragment offset fields in the IP metadata. If the value of the MF flag bit is 1, it clearly indicates that there are subsequent fragments after the current frame, thus determining that there are reassembled fragments. If recombined fragments are determined to exist, extract their original payload data according to the following steps: 1) Establish a reassembly buffer: Create a corresponding reassembly buffer in memory using the received ID number as a unique index; 2) Store payload by offset: Calculate the location of the payload fragment in the reassembly buffer based on the fragment offset field in the current frame's IP metadata. 3) Timeout protection: Start the reassembly timeout timer. If all fragments are not collected before the timer expires, discard all data in the reassembly buffer and release the memory. 4) Integrity check: When the MF flag is received as 0, an integrity check is performed: if the check passes, it is confirmed that all data has been received; if it fails, continue to wait for subsequent fragments. 5) Sequential splicing and restoration: The load data of all fragments in the reassembly buffer are spliced ​​sequentially in ascending order of fragment offset to restore the complete original load data; 6) Construct and submit: Using the spliced ​​complete original payload data, combined with the restored source IP, destination IP and port information, construct a complete standard IP data packet and submit it to the kernel protocol stack.

Images