A heterogeneous store-and-forward switching method and system for multi-port CAN Ethernet

Abstract

This invention relates to a heterogeneous store-and-forward switching method and system for multi-port CAN Ethernet. The method includes: uniformly setting each physical port as a logical port; in an interrupt service routine, appending a source port identifier and internal formatting to the received lightweight packets and storing them in a receive buffer queue; in the device's main loop, retrieving packets from the receive buffer queue, delaying device management frames in the packets to a security context, and executing a forwarding process for the remaining frames; in the forwarding process, matching the source port with a forwarding rule set to generate an output port bitmap, and then calling the matching sending backend to construct a forwarding path according to each target port type in the output port bitmap; dividing the maintenance tasks of the switching device into time slices, executing them in rotation during each main loop cycle, and limiting the duration of each execution. This invention achieves efficient and reliable store-and-forward switching for multi-port CAN Ethernet heterogeneous networks under harsh environments.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a heterogeneous store-and-forward switching method and system for multi-port CAN Ethernet. Background Technology

[0002] In the harsh environments of industrial automation, Controller Area Network (CAN) buses are widely used due to their high reliability and real-time performance, while Ethernet is gradually becoming the upper-layer backbone network due to its high bandwidth and powerful interconnection capabilities. Furthermore, as system complexity continues to increase, a single device often needs to integrate multiple CAN ports and Ethernet ports simultaneously to achieve seamless integration of field device data acquisition, remote monitoring, and centralized control.

[0003] In existing technologies, the interconnection between CAN and Ethernet is typically treated as a single protocol conversion gateway, focusing mainly on protocol encapsulation format, routing table lookup, and transmission delay analysis. However, harsh field environments often present adverse factors such as strong electromagnetic interference, wide temperature variations, and power fluctuations, placing higher demands on the hardware protection capabilities and software fault tolerance mechanisms of communication equipment. Furthermore, when an on-chip CAN controller and an external SPI CAN controller coexist, they differ significantly in transmit / receive timing, error recovery mechanisms, and throughput characteristics. If a simple, unified polling method is used to handle multi-port transmit / receive, some ports may become starved due to untimely service, or errors may propagate due to improper error handling.

[0004] Meanwhile, the harsh field environment also requires electrical isolation on the CAN side, independent protection on the power supply side, and isolation and surge / electrostatic discharge protection on the Ethernet side. Simple communication gateway solutions lack an integrated and coordinated design between hardware protection and software scheduling. Furthermore, in multi-port CAN Ethernet heterogeneous systems, the lack of a unified logical port model leads to multiple independent processing paths for subsequent functions such as rule forwarding, remote configuration, device diagnostics, and firmware upgrades, increasing firmware complexity and reducing system maintainability. Additionally, in low-power, sealed, wide-temperature industrial equipment, the lack of an operating system or a lightweight bare-metal environment causes uncontrollable latency jitter due to dynamic protocol stacks and dynamic memory allocation.

[0005] Therefore, those skilled in the art urgently need a store-and-forward switching solution that can adapt to harsh environments, accommodate heterogeneous interconnection of multiple types of CAN ports and Ethernet, and operate stably in a bare-metal environment. Summary of the Invention

[0006] (a) Technical problems to be solved In view of the above-mentioned shortcomings and deficiencies of the prior art, the present invention provides a heterogeneous store-and-forward switching method and system for multi-port CAN Ethernet, which solves the technical problems of uneven port scheduling, disconnect between hardware protection and software management, and uncontrollable latency in the bare metal environment when CAN Ethernet is interconnected in harsh environments.

[0007] (II) Technical Solution To achieve the above objectives, the main technical solutions adopted by the present invention include: In a first aspect, embodiments of the present invention provide a heterogeneous store-and-forward switching method for multi-port CAN Ethernet, the method being applied to a switching device including an on-chip CAN controller port, an external SPI CAN controller port, and an Ethernet port, the method comprising: Configure each physical port as a logical port with a unique identifier; In the interrupt service routine, lightweight receive processing, which only includes operations within the boundary, is performed. The received message is appended with the source port identifier and converted into the internal format of the interrupt service routine before being stored in the preset receive buffer queue. In the main loop of the device, a message is retrieved from the receive buffer queue, the device management frame in the message is delayed to the security context, and the remaining frames are processed by forwarding. In the forwarding process, the source port is matched with the preset forwarding rule set to generate an output port bitmap. Then, according to the type of each target port in the output port bitmap, the corresponding sending backend is called to form a forwarding path. The port bit that failed to be sent is retried in the next main loop forwarding process until the transmission is successful or the limit is exceeded and the bitmap is discarded. The maintenance tasks of the switching equipment are divided into time slices, which are executed in rotation during each main cycle, and the duration of each execution is limited.

[0008] Optionally, within the interrupt service routine, lightweight receive processing consisting only of boundary operations is performed. This includes appending a source port identifier to the received message, converting it to the interrupt service routine's internal format, and storing it in a pre-defined receive buffer queue. In the interrupt service routine, in response to the original message on any physical port, a lightweight receive process consisting only of in-boundary operations is performed, and a unique port identifier of the source physical port is appended to the received message. The message with the port identifier is converted into an internal message with a uniform internal format, and then the internal message is stored in a preset receive buffer queue. The internal message with a unified internal format includes the source port field, frame type field, original frame length field, and original frame payload field. For CAN raw messages, the raw frame payload field fully retains the CAN identifier, extended frame flag, remote frame flag, data length code, and up to 8 bytes of data; For raw Ethernet packets, the raw frame payload field is the restored Layer 2 Ethernet frame.

[0009] Optionally, operations within the boundary include: performing register status reads, FIFO data copying, and cyclic redundancy checks; and explicitly disabling Flash memory writes, CAN controller baud rate reconfiguration, multi-byte continuous writes, and dynamic memory allocation operations within the interrupt service routine.

[0010] Optionally, in the device's main loop, a packet is retrieved from the receive buffer queue, the device management frame in the packet is delayed to the security context, and the remaining frames undergo a forwarding process including: In the device's main loop, each frame of internal message in the receive buffer queue is read sequentially; The frame type field of the internal message is parsed, and the parsing result is used to determine whether the current message is a device management frame of any one of the following types: configuration frame, diagnostic frame, or upgrade frame. If the message is a device management frame, the current internal message is stored in the delayed processing queue, and no response operation that would modify the non-volatile storage or peripheral operating parameters is executed. The message is then processed uniformly in the security context execution segment of the next main loop. If the message is not a device management frame, it will be transferred to the forwarding process to perform rule matching and port sending operations.

[0011] Optionally, the source port is matched with a preset forwarding rule set to generate an output port bitmap. Then, based on the type of each target port in the output port bitmap, the corresponding sending backend is called to construct the forwarding path, including: Parse the packets that are being forwarded to obtain the source port identifier, packet identifier, and extended frame flag. Using at least one of the source port identifier, message identifier, and extended frame flag as the matching keyword, query the preset forwarding rule set to obtain the set of target logical ports that the current message is allowed to be forwarded. An output port bitmap is generated based on the target logical port set. The bit width of the output port bitmap is equal to the total number of logical ports. The set state of each bit indicates that the corresponding port is the target port. Iterate through each port bit in the output port bitmap, and according to the physical port type corresponding to the port, call the corresponding sending backend to form a forwarding path, and execute message sending based on the forwarding path.

[0012] Optionally, based on the type of each target port in the output port bitmap, the corresponding sending backend is called to construct the forwarding path, including: When the current target port corresponds to the on-chip CAN controller port, the on-chip CAN transmission backend is called to form the first forwarding path, so as to perform transmission through the preset FlexCAN controller transmission mailbox built into the main control MCU; When the current target port corresponds to the SPI external CAN controller port, the external CAN transmission backend is called to form a second forwarding path, so as to write a transmission request to the target external CAN controller through the SPI bus, and limit the preset number of transmission requests within the same SPI transaction cycle; When the current target port corresponds to an Ethernet port, the Ethernet sending backend is invoked to form a third forwarding path, so as to encapsulate the internal message into a UDP packet and send it to the preset peer through a fixed service port.

[0013] Optionally, the maintenance tasks of the switching equipment can be divided into time slices, executed in rotation during each main cycle, and the duration of each execution can be limited, including: Acquire maintenance tasks for switching equipment, including analog-to-digital converter port protection monitoring, physical layer link status detection, CAN bus error recovery, and Ethernet link recovery; Each maintenance task is assigned an independent time slice, and the time slices are arranged in a preset order to form a rotation schedule. In each main cycle, the maintenance task to be executed is selected according to the rotation schedule table, and the timer is started; During the execution of maintenance tasks, the execution time is monitored in real time. When the execution time reaches the preset single execution time limit threshold, the current maintenance task is paused and the execution breakpoint is recorded. In the next main cycle, the paused maintenance task resumes from the execution breakpoint until the maintenance task is completed before switching to the next maintenance task.

[0014] Optionally, during the execution of maintenance tasks, when it is detected that any CAN port is in a bus-off state, has an acknowledgment error, or has a timeout in the transmit mailbox, or when it is detected that the Ethernet link is disconnected or the number of consecutive transmission failures of the external CAN controller exceeds a preset fault threshold, the recovery request is marked in the maintenance requirement bitmap of the corresponding port, and the corresponding recovery operation is executed when the time slice of the maintenance task to which the port belongs is rotated. The recovery operation includes controller soft reset, baud rate reconfiguration, and termination resistor status re-check.

[0015] Optionally, the heterogeneous store-and-forward switching method for multi-port CAN Ethernet further includes: When the switching equipment starts up, it reads the isolation power supply threshold, overcurrent protection delay and terminating resistor enable status of each physical port from the non-volatile parameter storage unit, and configures the corresponding power control command and terminating resistor switching command. In the safety context of the main loop, based on the modification instructions received from the preset remote management terminal for power control and terminating resistor switching, the modified isolation power supply threshold, overcurrent protection delay, and terminating resistor enable state are written to the non-volatile storage unit, and the currently running power control parameters and terminating resistor switching parameters are updated synchronously.

[0016] Secondly, embodiments of the present invention provide a heterogeneous store-and-forward switching system for multi-port CAN Ethernet. The system is applied to a switching device including an on-chip CAN controller port, an external SPI CAN controller port, and an Ethernet port. The system includes: The port abstraction module is used to uniformly set each physical port as a logical port with a unique identifier; The lightweight receive module is used to perform lightweight receive processing that only includes operations within the boundary in the interrupt service routine, and to add the source port identifier to the received message and convert it into the internal format of the interrupt service routine before storing it in the preset receive buffer queue. The main loop scheduling module is used to retrieve packets from the receive buffer queue in the device's main loop, delay the device management frame in the packet to the security context, and perform forwarding processing on the remaining frames; The rule forwarding module is used to match the source port with a preset forwarding rule set in the forwarding process, generate an output port bitmap, and then call the corresponding sending backend to form a forwarding path according to each target port type in the output port bitmap. It also controls the port bits that failed to send to retry sending in the next main loop forwarding process until the sending is successful or the limit is exceeded and the data is discarded. The maintenance task rotation module is used to divide the maintenance tasks of the switching equipment into time slices, execute them in rotation during each main cycle, and limit the duration of each execution.

[0017] (III) Beneficial Effects The beneficial effects of this invention are as follows: The heterogeneous store-and-forward switching method for multi-port CAN Ethernet proposed in this invention has the following significant advantages over existing technologies due to its use of unified logical port plane abstraction, interrupt-driven lightweight reception and main loop security context layered processing, bitmap-based rule forwarding and differentiated transmission backend, and maintenance task fragmentation round-robin techniques: First, by unifying the logical ports, the on-chip CAN, external CAN, and Ethernet are incorporated into the same forwarding expression framework, eliminating multi-protocol branches and redundant configuration paths, and reducing the complexity of firmware development and maintenance.

[0018] Second, by employing a scheduling mechanism that combines lightweight message reception processing with centralized processing in the main loop, the risk of deadlock and system instability introduced by performing Flash writing, peripheral reconfiguration, or long-term transmission operations within the interrupt context is effectively reduced.

[0019] Third, different transmitting backends are used for different types of CAN controllers, but the same matching and scheduling rules are shared. This avoids the port starvation problem caused by simple unified polling and facilitates port expansion and fault location.

[0020] Fourth, the maintenance task fragmentation and rotation mechanism effectively reduces the impact of periodic recovery tasks on message forwarding latency, ensuring the real-time performance and determinism of the system. Attached Figure Description

[0021] Figure 1 A flowchart illustrating a heterogeneous store-and-forward switching method for multi-port CAN Ethernet according to an embodiment of the present invention; Figure 2 Provided for an embodiment of the present invention Figure 1 The flowchart of the sub-steps of S200 in the shown steps; Figure 3 Provided for an embodiment of the present invention Figure 1 The flowchart of the sub-steps of S300 in the shown steps; Figure 4 Provided for an embodiment of the present invention Figure 1 The flowchart of the sub-steps of S400 in the steps shown; Figure 5 Provided for an embodiment of the present invention Figure 1 The flowchart of the sub-steps of S500 in the steps shown is as follows. Detailed Implementation

[0022] To better explain and facilitate understanding of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] refer to Figures 1-5As shown in the figure, this invention proposes a heterogeneous store-and-forward switching method for multi-port CAN Ethernet. This method is applied to a switching device that includes an on-chip CAN controller port, an external SPI CAN controller port, and an Ethernet port. The method includes: uniformly setting each physical port as a logical port with a unique identifier; in the interrupt service routine, performing lightweight receive processing that only includes operations within the boundary, and adding a source port identifier to the received message and converting it into the internal format of the interrupt service routine before storing it in a preset receive buffer queue; in the device main loop, retrieving messages from the receive buffer queue, delaying the device management frame in the message to the security context, and performing a forwarding process on the remaining frames; in the forwarding process, matching the source port with a preset forwarding rule set to generate an output port bitmap, and then calling the corresponding sending backend to form a forwarding path according to each target port type in the output port bitmap, and controlling the port bit that failed to send to retry sending in the next forwarding process of the main loop until successful transmission or exceeding the limit and being discarded; dividing the maintenance task of the switching device into time slices, executing them in rotation in each main loop cycle, and limiting the duration of each execution.

[0024] This embodiment, employing a unified logical port plane abstraction, interrupt-based lightweight reception and main loop security context layered processing, bitmap-based rule forwarding and differentiated transmission backends, and maintenance task fragmentation round-robin techniques, offers the following significant advantages over existing technologies: First, by integrating on-chip CAN, external CAN, and Ethernet into the same forwarding expression framework through a unified logical port, it eliminates multi-protocol branches and redundant configuration paths, reducing the complexity of firmware development and maintenance. Second, the scheduling mechanism of lightweight reception processing and centralized processing in the main loop effectively reduces the deadlock risk and system instability introduced by performing Flash writing, peripheral reconfiguration, or long-duration transmission operations within the interrupt context. Third, by using differentiated transmission backends for different types of CAN controllers while sharing the same rule-matching scheduling, it avoids the port starvation problem caused by simple unified polling and facilitates port expansion and fault location. Fourth, the maintenance task fragmentation round-robin mechanism effectively reduces the impact of periodic recovery tasks on message forwarding latency, ensuring the real-time performance and determinism of the system.

[0025] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0026] Specifically, refer to Figure 1As shown, this embodiment proposes a heterogeneous store-and-forward switching method for multi-port CAN Ethernet, enabling on-chip CAN, external SPI CAN, and Ethernet ports to complete reception, buffering, rule determination, forwarding, diagnosis, and recovery within a unified logical port plane. Furthermore, it reduces the impact of single-port failures on the entire device through hardware isolation and independent power supply protection. The method may include the following steps S100 to S500: S100. Set each physical port as a logical port with a unique identifier.

[0027] In this embodiment, the switching device includes 12 CAN physical ports and one Ethernet physical port. The 12 CAN physical ports include 6 on-chip CAN controller ports (numbered CAN0 to CAN5) and 6 SPI external CAN controller ports (numbered CAN6 to CAN11). The Ethernet physical port is a separate Ethernet port. After the switching device starts up, it first performs a port abstraction initialization process, mapping the 13 physical ports to 13 logical ports in the logical port plane, and assigning each logical port a unique port identifier within that logical port plane. After the port abstraction initialization is completed, all subsequent message reception, buffer management, rule matching, forwarding decisions, and transmission operations are based on the logical port identifiers. The hardware differences of the physical ports are completely transparent to the upper-layer processing logic. Therefore, when adding or removing physical ports, only the port mapping table needs to be updated without modifying the core forwarding logic, thus decoupling the physical port configuration from the forwarding processing logic.

[0028] Furthermore, port identifiers use integer numbers from 0 to 12, where numbers 0 to 5 correspond to on-chip CAN controller ports CAN0 to CAN5, numbers 6 to 11 correspond to SPI external CAN controller ports CAN6 to CAN11, and number 12 corresponds to the Ethernet port. A port mapping table is maintained in the logical port plane, recording the association between each logical port identifier and its corresponding physical port hardware resources. For on-chip CAN controller ports, the port mapping table records the corresponding FlexCAN controller instance number, receive mailbox, and transmit mailbox allocation; for SPI external CAN controller ports, the port mapping table records the corresponding SPI bus number, chip select pin number, and external CAN controller model; for Ethernet ports, the port mapping table records the corresponding MAC address and fixed UDP service port.

[0029] S200. In the interrupt service routine, perform lightweight receive processing that only includes operations within the boundary, and add the source port identifier to the received message and convert it into the internal format of the interrupt service routine before storing it in the preset receive buffer queue.

[0030] In this embodiment, the switching device configures an independent interrupt service routine entry point for each physical port. When any physical port receives a raw packet, it triggers the corresponding interrupt request, and then enters the interrupt service routine of that port to perform lightweight receive processing. All interrupt service routines follow a unified design constraint: only performing operations within the specified boundaries, ensuring that the execution time in the interrupt context is short and highly predictable. Specifically, refer to... Figure 2 As shown, step S200 may include the following sub-steps S210 to S220: S210. In the interrupt service routine, in response to the original message on any physical port, perform lightweight receive processing that only includes in-boundary operations and append a unique port identifier of the source physical port to the received message.

[0031] Furthermore, operations within the specified boundaries include: performing register status reads, FIFO data copying, and cyclic redundancy checks. Additionally, Flash memory writes, CAN controller baud rate reconfiguration, multi-byte continuous writes, and dynamic memory allocation operations are explicitly disabled within the interrupt service routine.

[0032] Further explanation: Register status reading: The interrupt flag register of the CAN controller or the status register of the Ethernet is read to confirm that message reception is complete and no error flags are set. For on-chip CAN controllers, the receive mailbox status is obtained by reading the FlexCAN registers; for SPI external CAN controllers, the interrupt pin status and receive buffer status register are read via the SPI bus; for Ethernet, the receive descriptor status bits are read. FIFO data copy: The raw message data in the receive FIFO is copied byte by byte to the pre-allocated static receive buffer. For CAN messages, the copied content includes the CAN identifier, extended frame flag, remote frame flag, data length code, and up to 8 bytes of data payload; for Ethernet messages, the entire Layer 2 Ethernet frame content is copied. No data format conversion or reassembly is performed during the copying process. Cyclic Redundancy Check (CRC): The received raw message data is subjected to hardware or software CRC check to verify the integrity of the message during physical layer transmission. If the CRC check fails, the message is discarded and the port error count is updated, without proceeding to subsequent processing.

[0033] To further explain, the following prohibitions apply: Flash memory writes: No programming or erasing operations are permitted on non-volatile memory cells, as Flash operations typically take milliseconds to tens of milliseconds, far exceeding the microsecond execution time window acceptable to interrupt service routines. CAN controller baud rate reconfiguration: Write operations to the CAN controller's bit timer registers are prohibited, as baud rate reconfiguration involves controller resynchronization, potentially introducing unpredictable latency. Static multi-byte continuous writes: When operating an external SPI CAN controller, only necessary status reads and data copies are performed within each SPI transaction cycle. Multi-byte continuous writes are prohibited within interrupt contexts to avoid prolonged SPI bus occupation affecting communication with other peripherals. Dynamic memory allocation operations are prohibited: Calls to malloc, free, or other dynamic memory management functions are prohibited, as the execution time of dynamic memory allocation is unpredictable and carries the risk of allocation failure, failing to meet the real-time requirements of interrupt contexts.

[0034] S220: Convert the message with port identifier into an internal message with a uniform internal format, and then store the internal message into a preset receive buffer queue.

[0035] Furthermore, the unified internal format of the internal message includes a source port field, a frame type field, a raw frame length field, and a raw frame payload field. For CAN raw messages, the raw frame payload field fully retains the CAN identifier, extended frame flag, remote frame flag, data length code, and up to 8 bytes of data. For Ethernet raw messages, the raw frame payload field is the restored Layer 2 Ethernet frame, including the destination MAC address, source MAC address, Ethernet type, and payload.

[0036] Furthermore, the receive buffer queue is implemented using a statically allocated circular buffer with a preset queue depth of 64 packet slots. The size of each slot is fixed at the preset maximum internal packet length. The read and write pointers of this circular buffer are atomic operations, eliminating the need for mutexes or semaphores, thus ensuring that data transfer between the interrupt context and the main loop context does not result in race conditions. After packet conversion is complete, the interrupt service routine writes the internal packet to the current write pointer position in the receive buffer queue and then updates the write pointer. If the queue is full, the current packet is discarded and the port drop count is updated, but the interrupt service routine does not perform any blocking waits to ensure that it can complete execution and exit within the specified time.

[0037] S300: In the main loop of the device, the message is retrieved from the receive buffer queue, the device management frame in the message is delayed to the security context, and the remaining frames are processed by the forwarding process.

[0038] In this embodiment, the main loop of the switching device is the core scheduling entity that runs continuously in a bare-metal environment. The main loop executes repeatedly according to a fixed cycle. In each cycle, packet forwarding tasks are processed first, followed by maintenance tasks, and finally, delayed device management frames. Data exchange between the main loop and the interrupt service routine is achieved through a receive buffer queue. The interrupt service routine is responsible for writing internal packets into the queue, and the main loop is responsible for retrieving packets from the queue and performing subsequent processing. This embodiment employs a priority-based scheduling strategy in each round of the main loop. Forwarding of ordinary data frames takes precedence over the security context of device management frames in each main loop cycle, ensuring that the real-time performance of data forwarding is not affected by management operations. Furthermore, although device management frames are delayed, they are stored in an independent delayed processing queue and will not be lost, thereby ensuring the reliable execution of management instructions and operational consistency. Specifically, refer to... Figure 3 As shown, step S300 may include the following sub-steps S310 to S330: S310. In the main loop of the device, read each frame of internal message in the receive buffer queue in sequence.

[0039] S320. Parse the frame type field of the internal message and determine whether the current message is a device management frame of any one of the following types: configuration frame, diagnostic frame, or upgrade frame, based on the parsing result.

[0040] S330a If the message is a device management frame, the current internal message is stored in the delayed processing queue, and no response operation that would modify the non-volatile storage or peripheral operating parameters is executed. The message is then processed uniformly in the security context execution segment of the next main loop.

[0041] S330b: If the message is not a device management frame, the message will be transferred to the forwarding process to perform rule matching and port sending operations.

[0042] S400. In the forwarding process, the source port is matched with the preset forwarding rule set to generate an output port bitmap. Then, according to the type of each target port in the output port bitmap, the corresponding sending backend is called to form a forwarding path. The port bit that failed to be sent is retried in the next main loop forwarding process until the transmission is successful or the limit is exceeded and the bitmap is discarded.

[0043] In this embodiment, packets with a unified internal format are assigned to a set of target ports based on a preset forwarding rule set, and the actual transmission operation is completed through differentiated sending backends. For ports that fail to transmit due to busy underlying buses or temporary unavailability of hardware resources, a port bit reservation mechanism is used to implement limited retries to avoid packet loss. Furthermore, the entire forwarding process does not involve dynamic memory allocation; all cached items are obtained from a statically allocated forwarding cache pool. Specifically, refer to... Figure 4As shown, step S400 may include the following sub-steps S410 to S440: S410. Parse the message that is being processed to obtain the source port identifier, message identifier and extended frame flag.

[0044] S420. Using at least one of the source port identifier, message identifier, and extended frame flag as the matching key, query the preset forwarding rule set to obtain the set of target logical ports that the current message is allowed to be forwarded.

[0045] Furthermore, the forwarding rule set includes: rule priority, matching conditions (source port identifier, packet identifier range, extended frame flag mask), action (allow / deny), and destination port mask. The matching process of the forwarding rule set includes: First, using the source port identifier as the primary matching key, querying the rule sub-table corresponding to that source port. Second, traversing the rule sub-table from high to low priority, matching the packet identifier with the packet identifier range in the rule. Next, the extended frame flag is used as an auxiliary matching condition, participating in the matching only when the rule specifies an extended frame flag constraint. Finally, when a forwarding rule is matched, the destination port mask field in that rule is read to obtain the set of target logical ports that the current packet is allowed to be forwarded. If no match is found after traversing all rules, a default rule is applied, for example, disallowing forwarding and executing the forwarding processing of the next main loop. In this embodiment, the forwarding rules support one-to-many forwarding (a message from one source port is forwarded to multiple destination ports simultaneously), broadcast forwarding (forwarded to all other ports), and port isolation (prohibiting forwarding between specified ports) to meet the heterogeneous interconnection requirements of CAN to CAN, CAN to Ethernet, and Ethernet to multiple CANs.

[0046] S430. Generate an output port bitmap based on the target logic port set. The bit width of the output port bitmap is equal to the total number of logic ports. The set state of each bit indicates that the corresponding port is the target port.

[0047] S440. Traverse each port bit in the output port bitmap, and according to the physical port type corresponding to the port, call the corresponding sending backend to form a forwarding path, and execute message sending based on the forwarding path.

[0048] Furthermore, the forwarding paths include: When the current target port corresponds to the on-chip CAN controller port, the on-chip CAN transmission backend is called to form the first forwarding path, so as to perform transmission through the preset FlexCAN controller transmission mailbox built into the main control MCU.

[0049] When the current target port corresponds to the SPI external CAN controller port, the external CAN transmission backend is called to form a second forwarding path, so as to write a transmission request to the target external CAN controller through the SPI bus, and limit the preset number of transmission requests within the same SPI transaction cycle.

[0050] When the current target port corresponds to an Ethernet port, the Ethernet sending backend is invoked to form a third forwarding path, so as to encapsulate the internal message into a UDP packet and send it to the preset peer through a fixed service port.

[0051] S500 divides the maintenance tasks of the switching equipment into time slices, executes them in rotation during each main cycle, and limits the duration of each execution.

[0052] In this embodiment, in addition to real-time message reception and forwarding, the switching equipment in a bare-metal environment also needs to periodically perform multiple maintenance tasks to ensure long-term stable operation in harsh environments. These maintenance tasks include analog-to-digital converter port protection monitoring, physical layer link status detection, CAN bus error recovery, and Ethernet link recovery. Since continuous execution of these maintenance tasks in the main loop would take a long time and may cause unacceptable jitter to the real-time performance of message forwarding, this embodiment divides the maintenance tasks into multiple time slices, which are executed in rotation during each main loop cycle. A time limit is set for the single execution duration of each time slice to ensure that continuous execution of any maintenance task does not excessively delay message forwarding processing. Specifically, refer to... Figure 5 As shown, step S500 may include the following sub-steps S510 to S550: S510: Obtain maintenance tasks for the switching equipment, including analog-to-digital converter port protection monitoring, physical layer link status detection, CAN bus error recovery, and Ethernet link recovery.

[0053] Furthermore, the analog-to-digital converter (ADC) port protection monitoring detects the power supply voltage and current of each CAN port to determine if there are any overcurrent or undervoltage abnormalities; the physical layer link status detection monitors the link connectivity and negotiation status of the Ethernet physical layer; the CAN bus error recovery monitors the error counter status of each CAN port and performs recovery when the bus is shut down; and the Ethernet link recovery periodically attempts to re-establish the link connection after the Ethernet link is disconnected, including re-triggering auto-negotiation and reconfiguring MAC / PHY interface parameters.

[0054] S520. Allocate an independent time slice for each maintenance task and arrange the time slices in a preset order to form a rotation schedule.

[0055] Furthermore, an example of a round-robin scheduling table is shown in Table 1.

[0056] S530. In each main cycle, select the maintenance task to be executed according to the rotation schedule table and start the timer.

[0057] S540. During the execution of maintenance tasks, monitor the execution time in real time. When the execution time reaches the preset single execution time limit threshold, pause the current maintenance task and record the execution breakpoint.

[0058] S550. In the next main cycle, continue the suspended maintenance task from the execution breakpoint until the maintenance task is completed before switching to the next maintenance task.

[0059] Furthermore, during the execution of maintenance tasks, when any CAN port is detected to be in a bus-off state, have an acknowledgment error, or have a timeout in the transmit mailbox, or when the Ethernet link is detected to be disconnected or the number of consecutive transmission failures of the external CAN controller exceeds a preset fault threshold, the recovery request is marked in the maintenance requirement bitmap of the corresponding port. When the time slice of the maintenance task to which the port belongs is rotated, the corresponding recovery operation is then executed. The recovery operation includes controller soft reset, baud rate reconfiguration, and termination resistor status re-check.

[0060] It is worth mentioning that this embodiment achieves a binding relationship between hardware protection resources and software logical ports. Each logical port is not only a protocol forwarding endpoint, but also associated with a set of independent hardware protection configurations. The management and monitoring of port status are consistent at both the software and hardware levels. When a CAN port is powered off by the hardware protection circuit due to an overcurrent or short-circuit fault, this event is reported to the main loop via an interrupt. The system automatically switches the logical state of the port to disabled, thereby automatically excluding the port during the forwarding rule matching stage, achieving software isolation of hardware faults. This embodiment's architecture of binding hardware protection with logical ports effectively reduces the impact of single-port hardware faults on the normal operation of the entire machine and other ports, enhancing the fault tolerance and reliability of the switching equipment in harsh environments. Specifically, it includes the following steps G100 and G200: G100 reads the isolation power supply threshold, overcurrent protection delay, and terminating resistor enable status of each physical port from the non-volatile parameter storage unit when the switching equipment starts up, and configures the corresponding power control commands and terminating resistor switching commands.

[0061] In this embodiment, the non-volatile parameter storage unit independently stores a set of hardware configuration parameters for each logical port. When the switching device starts up, the hardware configuration parameters of each port are read sequentially via the SPI interface to perform hardware configuration operations such as power supply threshold configuration, overcurrent protection delay configuration, and termination resistor enable configuration. After the hardware configuration operations are completed, power control instructions (corresponding to the combination of power supply threshold and overcurrent protection delay) and termination resistor switching instructions (corresponding to the termination resistor enable state) are generated for each port. These instructions are stored in the instruction cache in memory for dynamic adjustment during subsequent runtime.

[0062] G200, in the safety context of the main loop, according to the power control and terminating resistor switching modification instructions received from the preset remote management terminal, writes the modified isolation power supply threshold, overcurrent protection delay and terminating resistor enable state into the non-volatile storage unit, and synchronously updates the currently running power control parameters and terminating resistor switching parameters.

[0063] In this embodiment, the switching device may receive hardware parameter modification instructions from a remote management terminal via configuration frames during operation. For example, it may adjust the power supply threshold of a certain CAN port to adapt to different cable lengths and load conditions, or change the enable state of the terminating resistor to adapt to changes in the bus topology. Since such operations involve modification of control outputs and writing to non-volatile memory units, the execution time is uncontrollable and may affect normal forwarding tasks. Therefore, this embodiment limits its processing to the security context execution segment of the main loop.

[0064] Furthermore, this embodiment also proposes a heterogeneous store-and-forward switching system for multi-port CAN Ethernet, including: The port abstraction module is used to uniformly set each physical port as a logical port with a unique identifier.

[0065] The lightweight receive module is used in the interrupt service routine to perform lightweight receive processing that only includes operations within the boundary. It appends the source port identifier to the received message, converts it into the internal format of the interrupt service routine, and stores it in the preset receive buffer queue.

[0066] The main loop scheduling module is used to retrieve packets from the receive buffer queue in the device's main loop, delay the device management frames in the packets to the security context, and perform forwarding processing on the remaining frames.

[0067] The rule forwarding module is used to match the source port with a preset forwarding rule set in the forwarding process, generate an output port bitmap, and then call the corresponding sending backend to form a forwarding path according to each target port type in the output port bitmap. It also controls the port bits that failed to send to retry sending in the next main loop forwarding process until the sending is successful or the limit is exceeded and the data is discarded.

[0068] The maintenance task rotation module is used to divide the maintenance tasks of the switching equipment into time slices, execute them in rotation during each main cycle, and limit the duration of each execution.

[0069] In summary, this embodiment proposes a heterogeneous storage-forwarding and switching method and system for multi-port CAN Ethernet. First, by abstracting the unified logical port plane, it integrates three heterogeneous physical ports—on-chip CAN, external SPI CAN, and Ethernet—into the same forwarding expression framework, eliminating multi-protocol branches and redundant configuration paths, significantly reducing the complexity of firmware development and maintenance. Second, the interrupt service routine employs lightweight receive processing that only includes boundary operations, explicitly disabling time-consuming operations such as Flash writing, baud rate reconfiguration, multi-byte continuous writing, and dynamic memory allocation. This effectively reduces the risk of deadlock and system instability within the interrupt context, ensuring the real-time performance and predictability of interrupt responses. Third, the main loop uses a priority-based scheduling strategy, delaying device management frames to execution in the security context while prioritizing the forwarding of ordinary data frames. This ensures that the real-time performance of data forwarding is unaffected by management operations and guarantees the reliable execution and consistency of management instructions. Furthermore, the forwarding process employs a bitmap-based rule matching and differentiated backend collaboration mechanism. Different types of CAN controllers call their respective matching backends, but share the same rule matching schedule. This avoids port starvation caused by simple unified polling and facilitates port expansion and fault location. Simultaneously, a port bit reservation mechanism enables limited retries of unsuccessfully sent packets, effectively reducing packet loss rate. Then, a maintenance task fragmentation and rotation mechanism divides periodic maintenance tasks such as ADC port protection monitoring, physical layer link status detection, CAN bus error recovery, and Ethernet link recovery into multiple time slices, which are executed in rotation during each main cycle. A time limit is imposed on the duration of each execution, effectively reducing the impact of periodic recovery tasks on packet forwarding latency and ensuring real-time performance and determinism under harsh environments. Finally, the binding architecture of hardware protection resources and software logic ports allows for rapid detection and automatic isolation of single-port hardware faults at the software level, effectively reducing the impact of single-port faults on the normal operation of the entire device and other ports, significantly enhancing the fault tolerance and long-term operational reliability of the switching equipment.

[0070] Since the systems / devices described in the above embodiments of the present invention are systems / devices used to implement the methods of the above embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the systems / devices based on the methods described in the above embodiments of the present invention, and therefore will not be repeated here. All systems / devices used in the methods of the above embodiments of the present invention fall within the scope of protection of the present invention.

[0071] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0072] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0073] It should be noted that in the description of this invention, the word "a" or "an" preceding a component does not exclude the existence of multiple such components. This invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. The use of terms such as first, second, third, etc., is merely for convenience and does not indicate any order. These terms can be understood as part of the component names.

[0074] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0075] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning of the basic inventive concept, can make other changes and modifications to these embodiments.

[0076] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from the spirit and scope of the invention.

Claims

1. A heterogeneous store-and-forward switching method for multi-port CAN Ethernet, characterized in that, The method is applied to a switching device that includes an on-chip CAN controller port, an external SPI CAN controller port, and an Ethernet port. The method includes: Configure each physical port as a logical port with a unique identifier; In the interrupt service routine, lightweight receive processing, which only includes operations within the boundary, is performed. The received message is appended with the source port identifier and converted into the internal format of the interrupt service routine before being stored in the preset receive buffer queue. In the main loop of the device, a message is retrieved from the receive buffer queue, the device management frame in the message is delayed to the security context, and the remaining frames are processed by forwarding. In the forwarding process, the source port is matched with the preset forwarding rule set to generate an output port bitmap. Then, according to the type of each target port in the output port bitmap, the corresponding sending backend is called to form a forwarding path. The port bit that failed to be sent is retried in the next main loop forwarding process until the transmission is successful or the limit is exceeded and the bitmap is discarded. The maintenance tasks of the switching equipment are divided into time slices, which are executed in rotation during each main cycle, and the duration of each execution is limited.

2. The method as claimed in claim 1, characterized in that, Within the interrupt service routine, lightweight receive processing, consisting only of boundary operations, is performed. This includes appending a source port identifier to the received packet, converting it to the interrupt service routine's internal format, and storing it in a pre-defined receive buffer queue. In the interrupt service routine, in response to the original message on any physical port, a lightweight receive process consisting only of in-boundary operations is performed, and a unique port identifier of the source physical port is appended to the received message. The message with the port identifier is converted into an internal message with a uniform internal format, and then the internal message is stored in a preset receive buffer queue. The internal message with a unified internal format includes the source port field, frame type field, original frame length field, and original frame payload field. For CAN raw messages, the raw frame payload field fully retains the CAN identifier, extended frame flag, remote frame flag, data length code, and up to 8 bytes of data; For raw Ethernet packets, the raw frame payload field is the restored Layer 2 Ethernet frame.

3. The method as described in claim 1, characterized in that, Operations within the boundary include: performing register status reads, FIFO data copying, and cyclic redundancy check; and, within the interrupt service routine, explicitly disallowing Flash memory writes, CAN controller baud rate reconfiguration, multi-byte continuous writes, and dynamic memory allocation operations.

4. The method as claimed in claim 1, characterized in that, In the device's main loop, packets are retrieved from the receive buffer queue. Device management frames within the packets are delayed until the security context is reached. The remaining frames undergo a forwarding process including: In the device's main loop, each frame of internal message in the receive buffer queue is read sequentially; The frame type field of the internal message is parsed, and the parsing result is used to determine whether the current message is a device management frame of any one of the following types: configuration frame, diagnostic frame, or upgrade frame. If the message is a device management frame, the current internal message is stored in the delayed processing queue, and no response operation that would modify the non-volatile storage or peripheral operating parameters is executed. The message is then processed uniformly in the security context execution segment of the next main loop. If the message is not a device management frame, it will be transferred to the forwarding process to perform rule matching and port sending operations.

5. The method as claimed in claim 1, characterized in that, The source port is matched against a preset forwarding rule set to generate an output port bitmap. Then, based on the type of each target port in the output port bitmap, the corresponding sending backend is called to construct the forwarding path, including: Parse the packets that are being forwarded to obtain the source port identifier, packet identifier, and extended frame flag. Using at least one of the source port identifier, message identifier, and extended frame flag as the matching keyword, query the preset forwarding rule set to obtain the set of target logical ports that the current message is allowed to be forwarded. An output port bitmap is generated based on the target logical port set. The bit width of the output port bitmap is equal to the total number of logical ports. The set state of each bit indicates that the corresponding port is the target port. Iterate through each port bit in the output port bitmap, and according to the physical port type corresponding to the port, call the corresponding sending backend to form a forwarding path, and execute message sending based on the forwarding path.

6. The method as claimed in claim 1, characterized in that, Based on the type of each target port in the output port bitmap, the corresponding sending backend is called to construct the forwarding path, including: When the current target port corresponds to the on-chip CAN controller port, the on-chip CAN transmission backend is called to form the first forwarding path, so as to perform transmission through the preset FlexCAN controller transmission mailbox built into the main control MCU; When the current target port corresponds to the SPI external CAN controller port, the external CAN transmission backend is called to form a second forwarding path, so as to write a transmission request to the target external CAN controller through the SPI bus, and limit the preset number of transmission requests within the same SPI transaction cycle; When the current target port corresponds to an Ethernet port, the Ethernet sending backend is invoked to form a third forwarding path, so as to encapsulate the internal message into a UDP packet and send it to the preset peer through a fixed service port.

7. The method as claimed in claim 1, characterized in that, The maintenance tasks for switching equipment are divided into time slices, executed in rotation during each main cycle, and the duration of each execution is limited by time constraints, including: Acquire maintenance tasks for switching equipment, including analog-to-digital converter port protection monitoring, physical layer link status detection, CAN bus error recovery, and Ethernet link recovery; Each maintenance task is assigned an independent time slice, and the time slices are arranged in a preset order to form a rotation schedule. In each main cycle, the maintenance task to be executed is selected according to the rotation schedule table, and the timer is started; During the execution of maintenance tasks, the execution time is monitored in real time. When the execution time reaches the preset single execution time limit threshold, the current maintenance task is paused and the execution breakpoint is recorded. In the next main cycle, the paused maintenance task resumes from the execution breakpoint until the maintenance task is completed before switching to the next maintenance task.

8. The method as claimed in claim 1, characterized in that, During the execution of maintenance tasks, when any CAN port is detected to be in a bus-off state, have an acknowledgment error, or have a timeout in the transmit mailbox, or when the Ethernet link is detected to be disconnected or the number of consecutive transmission failures of the external CAN controller exceeds the preset fault threshold, the recovery request is marked in the maintenance requirement bitmap of the corresponding port. When the time slice of the maintenance task to which the port belongs is rotated, the corresponding recovery operation is executed. The recovery operation includes controller soft reset, baud rate reconfiguration, and termination resistor status re-check.

9. The method as claimed in claim 1, characterized in that, Also includes: When the switching equipment starts up, it reads the isolation power supply threshold, overcurrent protection delay and terminating resistor enable status of each physical port from the non-volatile parameter storage unit, and configures the corresponding power control command and terminating resistor switching command. In the safety context of the main loop, based on the modification instructions received from the preset remote management terminal for power control and terminating resistor switching, the modified isolation power supply threshold, overcurrent protection delay, and terminating resistor enable state are written to the non-volatile storage unit, and the currently running power control parameters and terminating resistor switching parameters are updated synchronously.

10. A heterogeneous store-and-forward switching system for multi-port CAN Ethernet, characterized in that, The system is applied to a switching device that includes an on-chip CAN controller port, an external SPI CAN controller port, and an Ethernet port. The system includes: The port abstraction module is used to uniformly set each physical port as a logical port with a unique identifier; The lightweight receive module is used to perform lightweight receive processing that only includes operations within the boundary in the interrupt service routine, and to add the source port identifier to the received message and convert it into the internal format of the interrupt service routine before storing it in the preset receive buffer queue. The main loop scheduling module is used to retrieve packets from the receive buffer queue in the device's main loop, delay the device management frame in the packet to the security context, and perform forwarding processing on the remaining frames; The rule forwarding module is used to match the source port with a preset forwarding rule set in the forwarding process, generate an output port bitmap, and then call the corresponding sending backend to form a forwarding path according to each target port type in the output port bitmap. It also controls the port bits that failed to send to retry sending in the next main loop forwarding process until the sending is successful or the limit is exceeded and the data is discarded. The maintenance task rotation module is used to divide the maintenance tasks of the switching equipment into time slices, execute them in rotation during each main cycle, and limit the duration of each execution.

Images