Can bus hybrid scheduling and fault tolerant communication method for multi-module devices
By employing a hybrid scheduling architecture and a two-factor session verification mechanism, the problems of high latency and single point of failure in CAN bus communication are solved, enabling efficient and reliable communication between multi-module devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2025-10-14
- Publication Date
- 2026-07-03
AI Technical Summary
Existing CAN bus communication technology suffers from high latency, high risk of single point of failure, and insufficient systematic command verification in emergency situations, making it difficult to balance the real-time nature of sudden commands with the deterministic nature of periodic polling.
A hybrid scheduling architecture is adopted, combining event-driven and state machine polling, and a two-factor session verification mechanism is introduced to achieve fault isolation and flexible fault tolerance management, ensuring the real-time performance, reliability and robustness of communication.
It achieves microsecond-level response, fault isolation, fine-grained management of communication resources, and accuracy of command response in CAN bus communication, thereby improving the system's real-time performance, reliability, and robustness.
Smart Images
Figure CN121333846B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of industrial communication technology, specifically relating to a CAN bus hybrid scheduling and fault-tolerant communication method and system for multi-module devices. Background Technology
[0002] Controller Area Network (CAN) bus is a high-performance, highly reliable, technologically mature, and cost-optimized serial communication protocol. Due to its excellent error detection and handling mechanisms, it is widely used in distributed real-time control in fields such as automotive electronics, industrial automation, and power management systems. In typical application scenarios, a master device (master node) communicates with multiple controlled devices (slave nodes) through a single CAN bus, forming a "one master, many slaves" topology.
[0003] Current network data packet processing technologies, such as the patent document CN113572688A [Pattern Forwarding Method and Terminal Equipment, Computer Storage Medium], provide a packet processing scheme that combines FPGA (Field Programmable Gate Array) for receiving data packets, PCIE (High-Speed Peripheral Component Interconnect Standard) for driving transmission, and DPDK (Data Plane Development Kit) module. This scheme aims to drive the physical network card and FPGA through DPDK polling mode to achieve low latency and high throughput processing of high-speed Ethernet packets. The core of this scheme lies in the pure polling mechanism of the DPDK module. However, this pure polling mechanism cannot achieve efficient and fast microsecond-level responses to the host computer, and it cannot be well applied to emergency situations in CAN applications.
[0004] Furthermore, in current CAN bus serial communication technology, for example, in the patent document CN105389278A [A Master-Slave Serial Communication Method Based on CAN Bus], a master-slave serial communication scheme is provided. This scheme aims to realize data interaction between the master control unit and multiple slave modules through a master-slave protocol. It obtains the physical address and network status information broadcast by the slave node by accessing and listening to the CAN cluster, and records this information to configure the address of the slave node, thereby realizing point-to-point communication between the master and slave. However, due to the dependence of the communication system on a single master node, there is a risk of single point of failure.
[0005] On the other hand, in terms of the matching and verification of instructions and responses, for example, the patent document [A Fast Matching Method for AT Instruction Identifiers] with patent publication number CN101035372A provides a method for fast matching of AT (Attention Instruction) identifiers through a preset index table. This method aims to shorten the instruction search and parsing time and improve instruction processing efficiency, but it does not provide a systematic instruction execution result verification mechanism.
[0006] Therefore, in view of the above-mentioned deficiencies of the existing technology, there is an urgent need in the field for an innovative multi-device CAN bus communication scheme. This scheme should be able to effectively balance the real-time nature of burst commands and the determinism of periodic polling, and provide a fault-tolerant management mechanism that can be flexibly configured for different command types, thereby systematically improving the reliability and efficiency of communication. Summary of the Invention
[0007] In view of the above, the present invention provides a CAN bus hybrid scheduling and fault-tolerant communication method and system for multi-module devices. It adopts a hybrid scheduling architecture that combines event-driven upper computer instructions with status polling of lower computer module communication, introduces a hierarchical fault tolerance and verification mechanism, and effectively isolates faulty nodes of lower computer modules. Thus, while ensuring communication determinism, it significantly improves the real-time performance, reliability and robustness of the system.
[0008] A CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices includes:
[0009] The main controller, as the master node of the CAN bus, adopts a dual CAN controller architecture. It communicates with the host computer through the first CAN controller, receives control commands issued by the host computer in real time through a hardware interrupt mechanism, and immediately sends the corresponding reception confirmation frame of the control command to the host computer according to the established protocol between the two. At the same time, the control command is treated as the highest priority event-driven task, which ensures microsecond-level response to sudden emergency commands.
[0010] The main controller uses a state machine polling mechanism based on the instruction lifecycle to pre-set different state machine enumeration lists for different host computer instructions. Then, it dynamically calls the corresponding state machine enumeration list according to the function type of the instruction to be processed. It establishes a serial communication link with multiple lower-level modules (slave nodes of the CAN bus) through the second CAN controller and communicates with each lower-level module in sequence according to the state machine enumeration list. The state machine strictly completes the state transition according to the preset order of the list, ensuring the orderliness and determinism of the communication process and completely avoiding bus congestion.
[0011] In the state machine polling mechanism, the main controller dynamically calls different fault tolerance strategy parameters according to the function type of the instruction to be sent. The fault tolerance strategy parameters include the maximum number of retries and the communication timeout time, and different parameter values are configured for instructions of different function types, thereby realizing flexible on-demand allocation of communication resources.
[0012] To further enhance the reliability and security of communication sessions, after sending instructions to the lower-level computer module, the master and slave nodes perform dual consistency verification based on a two-factor session verification mechanism using identifiers and data fields to confirm the validity of instruction execution and ensure the accuracy of instruction responses.
[0013] If the main controller does not receive a valid response through the two-factor session verification mechanism within the communication timeout period, a limited number of retry procedures will be performed based on the maximum number of retries.
[0014] Furthermore, the hardware interrupt mechanism is implemented as follows: the main controller communicates with the host computer through the bxCAN (basic extended CAN) module built into the first CAN controller. When the host computer sends a control command message, the first CAN controller triggers a receive interrupt when it receives a matching message through the CAN interface. In the interrupt service routine, the command reception is completed, a data packet confirming the reception is immediately sent to the host computer, and a software flag is set. The main program in the main controller triggers the task processing of the control command by cyclically querying the flag. This mechanism ensures a microsecond-level response to external emergency events and guarantees system stability by adhering to the principle of "only handling the most urgent matters in the interrupt".
[0015] Furthermore, the state machine polling mechanism establishes an independent state machine instance for each pending host computer instruction. The state machine adopts a multi-layer state coding structure, which clearly defines the communication stage between the host computer instruction and each lower-level module in the list through state identifiers. The multiple states defined by the state identifiers are sequentially included according to the communication process: initial state, instruction sending state for the first lower-level module, response waiting state for the first lower-level module, instruction sending state for the second lower-level module, response waiting state for the second lower-level module, ... instruction sending state for the last lower-level module, and response waiting state for the last lower-level module. Each response waiting state includes three sub-states: retrying, communication successful, and communication failure. The state machine transitions sequentially according to the above-preset state sequence until it has traversed all lower-level modules and completed the communication task of the host computer instruction or is interrupted by a high-priority event midway. This ensures that only one lower-level module is communicated with at the same time in a "question and answer" manner, thereby logically eliminating bus conflicts and ensuring the determinism of communication.
[0016] Furthermore, the main controller dynamically calls the corresponding state machine enumeration list based on the functional type of the instruction to be processed. Specifically, in each state machine instance, the instruction sending state and response waiting state for a specific lower-level module are independently configured with fault tolerance strategy parameters matching the instruction type. Moreover, the parameter configurations of each state in the state machine enumeration list corresponding to different instruction types are different from each other, so that the parameters configured in each state of the state machine corresponding to the key control instruction have differentiated characteristics from the parameters configured in each state of the state machine corresponding to the state query instruction. This achieves refined and flexible management of communication resources. The key control instructions include power-on instructions and power-off instructions, and the state query instructions include timed data request instructions. The power-on instructions, power-off instructions, and state query instructions all contain fault tolerance strategy parameters corresponding to the timed data request instructions, which are reasonably set according to actual engineering requirements, thereby achieving refined and adaptive management of communication resources.
[0017] Furthermore, the two-factor session authentication mechanism based on identifiers and data fields decomposes the traditional single-path authentication into independent yet complementary dual authentication paths based on different fields of the CAN message. Specifically:
[0018] At the main controller, according to predefined encoding rules, the instruction type information is encoded in the high-order part of the CAN identifier, and the lower-level module address information is encoded in the low-order part of the CAN identifier to form the first verification factor (identifier verification). Utilizing the inherent filtering and addressing characteristics of the CAN protocol identifier field, the instruction type and device address information are structured and embedded within it. The lower-level module performs hardware-level fast filtering and matching at this level, which can invalidate most irrelevant or incorrectly addressed messages, greatly reducing the software processing load of the main processor.
[0019] At the same time, according to the predetermined application layer protocol, the specific feature values of the downlink command data sent to the lower-level module and the uplink response data replied by the lower-level module are compared to form a second verification factor (data domain verification).
[0020] The first verification factor is verified at the lower-level module. First, the identifier field of the received message is checked to verify whether its high-order part matches the expected instruction type and whether its low-order part matches the lower-level module address.
[0021] If the first verification factor passes, then the verification of the second verification factor continues, i.e., comparing whether the specific feature value matches the expected feature value.
[0022] The instruction is considered valid only if both factors pass the dual verification.
[0023] Furthermore, the identifier field is divided into two functional segments: an instruction type segment and a device address segment. The instruction type segment is located in the high-order part of the identifier field and is used to encode the type of instruction. The device address segment is located in the low-order part of the identifier field and is used to encode the physical or logical address of the lower-level module. By comparing the response frame data field of the lower-level module with the instruction frame data field sent to the lower-level module, the response frame identifier of the lower-level module, the lower-level module number, and the instruction type, a two-factor session verification mechanism for the identifier and data field is established to confirm the validity of instruction execution and ensure the accuracy of instruction response.
[0024] Furthermore, the verification method for the second verification factor is as follows: the main controller predefines unique expected response data for each type of downlink command data according to the established communication protocol between the main controller and the lower-level module; after receiving the uplink response data from the lower-level module, it compares the result with the predefined expected response data; if the received uplink response data completely matches the expected response data, the command execution is deemed valid; if the received uplink response data does not match or no response data is received within a timeout, the command execution is deemed invalid, and a limited retry process is triggered. This scheme ensures the absolute accuracy of the command response at the application layer and solves the response confusion problem in retry scenarios.
[0025] Furthermore, the specific implementation of the finite retry process is as follows:
[0026] S1: When no response is received due to timeout or the two-factor session authentication mechanism determines that the response is invalid, the main controller initiates the retry process;
[0027] S2: Increment the retry count by 1 and resend the command to the same lower-level module;
[0028] S3: Wait for a response again and initiate the two-factor session verification mechanism to verify validity;
[0029] S4: Repeat steps S1 to S3 for the retry process until the retry count reaches the maximum number of retries configured for the current instruction type;
[0030] S5: If the main controller receives a valid response through the two-factor session verification mechanism before reaching the maximum number of retries, the instruction is judged to have been executed successfully and the retries are terminated to prevent misjudgment of system communication failure due to a single communication failure caused by an unexpected situation.
[0031] S6: If no valid response is received after the retry count reaches the maximum number of retries, the current instruction execution is determined to have failed. The current lower-level module is marked as having a communication failure state, and a fault information containing the fault device identifier and fault type is generated and reported to the upper-level computer. The communication process is then immediately switched to the next lower-level module to continue execution, thereby achieving fault isolation.
[0032] A CAN bus hybrid scheduling and fault-tolerant communication system for multi-module devices, comprising:
[0033] The host computer is used to issue control commands and receive status information and fault reports;
[0034] The main controller, as the master node of the CAN bus, is a microprocessor at its core, which executes the above-mentioned CAN bus hybrid scheduling and fault-tolerant communication method.
[0035] Multiple lower-level modules, acting as slave nodes on the CAN bus, communicate with the main controller.
[0036] The main controller adopts a dual CAN controller architecture and has two CAN interfaces. The first CAN controller is connected to the host computer through the first CAN interface. The CAN controller receives control commands issued by the host computer in real time through a hardware interrupt mechanism and submits the control commands to the microprocessor for processing.
[0037] The second CAN controller connects to multiple lower-level modules through the second CAN interface, forming an independent CAN bus communication link for performing serial polling communication with multiple lower-level modules.
[0038] This invention constructs a communication architecture that combines high real-time performance and high determinism through a hybrid scheduling mechanism that integrates communication for upper-level hardware interrupt responses with serial polling of lower-level module state machines. It achieves intelligent adaptation of communication resources by flexibly invoking differentiated fault-tolerance strategy parameters and corresponding state machine enumeration lists based on instruction types. The state machines adopt a fully configurable design concept, where each state in the state enumeration list can be independently configured with its fault-tolerance parameters and execution logic. When a lower-level module is identified as faulty, the state machine automatically skips the instruction sending and response waiting states for that module and directly switches to the next valid module to continue the polling process, thus achieving precise fault isolation. This dynamically configurable state machine management and fault-skipping mechanism effectively prevents system-level communication blockage caused by single-point failures, significantly improving system availability and robustness. It ensures both immediate response to urgent upper-level instructions and orderly and deterministic communication with multiple lower-level modules, resulting in a simultaneous leap in overall system efficiency and security.
[0039] This invention introduces a two-factor session verification mechanism based on identifiers and data fields. By comparing identifier features, and additionally comparing specific data features of the instructions sent to the lower-level module and the responses from the lower-level module, the problem of response confusion is fundamentally eliminated, ensuring the accuracy of instruction execution result determination. The limited number of retries and the proactive fault node skipping and communication fault reporting mechanism enable the system to automatically isolate faulty devices and prevent them from spreading and affecting the global task. The system robustness is greatly enhanced, which is particularly in line with the stringent requirements of industrial applications for long-term stable operation. Attached Figure Description
[0040] Figure 1 This is a schematic diagram of the CAN bus hybrid scheduling and fault-tolerant communication system architecture of the present invention.
[0041] Figure 2 This is a schematic diagram of the serial polling and multi-layer fault-tolerant mechanism based on a state machine according to the present invention. Detailed Implementation
[0042] To describe the present invention in more detail, the technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.
[0043] Example 1:
[0044] This embodiment provides a CAN bus hybrid scheduling and fault-tolerant communication system for multi-module devices, such as... Figure 1 As shown, the system includes a host computer, a main controller, and a slave computer. The main controller uses an embedded microprocessor that integrates at least two independent CAN controller peripherals. Each CAN controller peripheral has basic expansion functions, conforms to the CAN 2.0A / B protocol specification, and can be connected to the physical bus through an external CAN transceiver chip.
[0045] The microcontroller's first CAN interface (CAN1) connects to the host computer via a CAN transceiver, forming an independent CAN communication channel that communicates with the host MCU's CAN interface. The microcontroller's second CAN interface (CAN2) connects to multiple (e.g., 12) power supply slave modules via another CAN transceiver, forming another independent CAN communication channel. These two CAN communication channels are independent at both the physical and protocol layers, forming a dual-channel communication architecture.
[0046] The microcontroller runs an embedded program developed in C language, and its development environment can be Keil MDK. After the system powers on, the microcontroller first initializes the system clock, GPIO (general purpose input / output), etc., and then configures the baud rate (preferably 500kbps), filters, interrupts, and other parameters of the two CAN controllers (CAN1 and CAN2). Among them, the receiver mailbox of CAN1 is configured to generate a receive interrupt, which notifies the application layer master control scheduling module. The master control scheduling module then calls and manages the state machine management module, and communicates with the lower-level module through CAN2 based on the serial polling mode of the state machine.
[0047] When the host computer needs to issue a control command, it sends a CAN message conforming to a predetermined application layer protocol via the CAN1 bus. Upon successful reception of this message, the microcontroller's CAN1 peripheral immediately generates a hardware receive interrupt. The program execution flow jumps to the preset interrupt service routine. In the interrupt service routine, a data packet acknowledging receipt is immediately sent to the host computer, and a software flag is set before exiting the interrupt routine. The main program triggers task processing of the command by repeatedly checking this flag. This mechanism ensures a microsecond-level response to external emergencies, and by adhering to the principle of "only handling the most urgent matters in the interrupt," the entire process is fast and concise, guaranteeing real-time performance.
[0048] Once the flag is detected to be 1, the main program clears the flag and creates a new instruction task based on the instruction information recorded in the interrupt, and adds it to the state machine processing queue. This design achieves a smooth transition between event-driven tasks and polling tasks.
[0049] This implementation method uses a state machine-based serial fault-tolerant polling and fault handling process as follows: Figure 2 As shown:
[0050] The main program establishes an independent state machine instance for each instruction in the queue. This state machine defines the complete interaction sequence between this instruction and all lower-level modules. Based on the instruction issued by the host computer, the program enters the state machine matching that instruction. Then, starting from the initial state, the state machine switches the sending state of the currently communicating lower-level module according to the enumerated list order (e.g., from "Lower-level Module 1" to "Lower-level Module 12"). It then sends an instruction frame to that lower-level module. After sending, a timeout timer is started, and the program transitions to a state of waiting for the lower-level module to respond. Finally, it calls the differentiated fault-tolerance strategy parameters according to the instruction type.
[0051] In this embodiment, the fault tolerance strategy parameters are configured as follows: For power-on command: maximum number of retries = 3, timeout ≥ 3ms; For power-off command: maximum number of retries = 3, timeout ≥ 2ms; For timed data request command: maximum number of retries = 4, timeout ≥ 5ms.
[0052] When entering the response reception waiting state for the lower-level module, if no response is received before the timeout timer expires, the process jumps to the retry process; if a response is received from CAN2 before the timeout, the application layer session verification mechanism is executed.
[0053] The two-factor session verification mechanism for identifiers and data fields first verifies the identifier ID against the instruction type and the lower-level module number. Each lower-level module corresponds to its own independent identifier ID number (lower 4 bits), and each different instruction corresponds to its own independent identifier ID number (higher 7 bits). Then, the application-layer session verification mechanism is executed. Based on the established communication protocol with the lower-level module, a unique expected response data is predefined for each type of downlink instruction data. After receiving the uplink response data from the lower-level module, provided the first verification factor (identifier verification) passes, the second verification factor is performed. This involves comparing the feature values in the received message data field with the expected feature values and comparing their consistency with the predefined expected response data for the current downlink instruction. For example, if the sent instruction is a "power-on command," the expected response from the lower-level module is 0x02 0x01; if the sent instruction is a "communication detection command," the expected response from the lower-level module is 0x01 0x01. If the received uplink response data matches the expected response data exactly, the instruction is deemed valid, communication is marked as successful, the data is processed and reported, and the system switches to the next lower-level module in the enumeration list, entering the sending state of the next lower-level module. If the received uplink response data does not match, or no response data is received within a timeout period, the instruction is deemed invalid, and a limited number of retry cycles are triggered. This scheme ensures the absolute accuracy of the instruction response at the application layer and solves the response confusion problem in retry scenarios.
[0054] Retry process: When no response is received due to timeout or the session verification mechanism determines the response is invalid, the retry process is initiated; the retry count is incremented, and the instruction is resent to the same lower-level module; wait for a response again and initiate the session verification mechanism to verify validity; repeat the above retry process until the retry count reaches the maximum number of retryes configured for the current instruction type; if a valid response is received through the session verification mechanism before reaching the maximum number of retryes, the instruction is determined to have been executed successfully and the retry ends, preventing misjudgment of system communication failure due to a single communication failure caused by unforeseen circumstances.
[0055] When the retry count reaches the maximum number of retries but no valid response is received, the current communication attempt on the lower-level module is terminated, the lower-level module is marked as having a communication failure state, a fault information containing the fault device identifier and fault type is generated, and the fault information is reported to the upper-level computer. The lower-level module is then immediately skipped, and the system switches to the next lower-level module in the enumeration list, entering the sending state of the next lower-level module and continuing to communicate with the next lower-level module. This mechanism effectively prevents system-level blocking caused by single-point failures and greatly enhances system availability.
[0056] Following the above process, after the state machine has processed all the instructions in the instruction queue and all the communication with the valid lower-level modules in sequence, the instruction task ends, and the main loop continues to wait for new interrupt events and timed polling tasks.
[0057] Example 2:
[0058] This embodiment provides a CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices, which can efficiently and stably report power module data from the lower-level device to the upper-level device quickly. The steps are as follows:
[0059] Step 1: Receive data acquisition instructions from the host computer.
[0060] The host computer sends a communication detection command (e.g., command code 0x03, indicating "report all parameters") to the main controller via the first CAN bus (CAN1). The reception and processing flow of this command is exactly the same as in Example 1: CAN1 generates a hardware receive interrupt, and in the main interrupt service routine, it immediately replies with an acknowledgment frame to the host computer and sets the "high-priority task flag". After the main loop detects this flag, it creates a new "data acquisition" command task and adds it to the state machine processing queue; this ensures that the host computer's data requests can be responded to in a timely manner.
[0061] Step 2: The state machine polls and collects data from the lower-level power module.
[0062] After the communication test is completed, the main program serially polls the lower-level machine module for data acquisition commands every 500ms. The main program creates a state machine instance for this data acquisition command. The state machine establishes communication with each lower-level machine module in sequence according to the enumerated list (e.g., from lower-level machine module No. 1 to No. 12). For each lower-level machine module in the list, the state machine performs the following operations:
[0063] Invoking the fault tolerance strategy: Since this command is a status query command, the system invokes the fault tolerance strategy parameters specifically configured for query commands. These parameters are: maximum number of retries 4, timeout 5ms. This configuration tends to ensure that the data is eventually successfully obtained through multiple attempts, while the short timeout ensures polling efficiency.
[0064] Step 3: Response verification.
[0065] Sending a data request command: The state machine sends a specific command (e.g., command code 0x05) to the current target lower-level module via the second CAN bus (CAN2) to request data.
[0066] Waiting for and verifying the response: The state machine waits for a reply from the lower-level module. The uplink response data from the lower-level module includes not only specific values such as voltage, current, and temperature, but also a specific characteristic value (e.g., data header 0xFD) to indicate that this frame of data is a response to the "request status data" command. The state machine uses the application layer session verification mechanism to check whether the characteristic value in the response data matches the expectation. Only when the verification is successful is the data reception determined to be successful.
[0067] Step 4: Dealing with communication failures.
[0068] If communication with a lower-level module times out or verification fails, a retry will be performed according to the above-mentioned strategy (maximum 4 times). If the retry still fails, the lower-level module will be marked as "communication failure" and the communication will be marked as interrupted in the reported data. At the same time, the node will be skipped immediately and the data will be requested from the next lower-level module. This fault isolation mechanism ensures that the failure of a single node will not block the entire data acquisition process.
[0069] Step 5: Summarize and report the data.
[0070] Once the state machine completes a round of communication with all lower-level modules (whether successful or not) in the order listed, it signifies that the "data acquisition" command task has been executed. At this point, the main controller organizes and packages the status data (including valid data and fault flags) of all lower-level modules temporarily stored in memory into a complete data report. Then, after receiving a data request command from the host computer via the first CAN bus (CAN1), the main controller sends this complete data report to the host computer.
[0071] The above description of the embodiments is provided to enable those skilled in the art to understand and apply the present invention. Those skilled in the art can readily make various modifications to the above embodiments and apply the general principles described herein to other embodiments without creative effort. Therefore, the present invention is not limited to the above embodiments, and any improvements and modifications made to the present invention by those skilled in the art based on the disclosure thereof should be within the scope of protection of the present invention.
Claims
1. A CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices, characterized in that: The main controller, as the master node of the CAN bus, adopts a dual CAN controller architecture. It communicates with the host computer through the first CAN controller, receives control commands issued by the host computer in real time through a hardware interrupt mechanism, and immediately sends the corresponding reception confirmation frame of the control command to the host computer according to the established protocol between the two parties. At the same time, the control command is treated as the highest priority event-driven task. The main controller uses a state machine polling mechanism based on the instruction lifecycle to pre-set different state machine enumeration lists for different host computer instructions. Then, it dynamically calls the corresponding state machine enumeration list according to the function type of the instruction to be processed. It establishes a serial communication link with multiple lower-level modules through the second CAN controller and communicates with each lower-level module in sequence according to the state machine enumeration list. The state machine strictly completes the state transition according to the preset order of the list, ensuring the orderliness and determinism of the communication process. In the state machine polling mechanism, the main controller dynamically calls different fault tolerance strategy parameters according to the function type of the instruction to be sent. The fault tolerance strategy parameters include the maximum number of retries and the communication timeout time, and different parameter values are configured for instructions of different function types. After sending instructions to the lower-level machine module, the master and slave nodes perform dual consistency verification based on a two-factor session verification mechanism using identifiers and data fields to confirm the validity of instruction execution and ensure the accuracy of instruction response. If the main controller does not receive a valid response through the two-factor session verification mechanism within the communication timeout period, a limited number of retry procedures will be performed based on the maximum number of retries.
2. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 1, characterized in that, The specific implementation of the hardware interrupt mechanism is as follows: the main controller communicates with the host computer through the bxCAN module built into the first CAN controller. When the host computer sends a control command message, the first CAN controller triggers a receive interrupt when it receives a matching message through the CAN interface. In the interrupt service routine, the command reception is completed, a data packet confirming the reception is immediately sent to the host computer, and a software flag is set. The main program in the main controller triggers the task processing of the control command by cyclically querying the flag.
3. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 1, characterized in that: The state machine polling mechanism establishes an independent state machine instance for each pending host computer instruction. The state machine adopts a multi-layer state coding structure, which clearly defines the communication stage between the host computer instruction and each lower-level computer module in the list through state identifiers. The multiple states defined by the state identifiers are sequentially included in the communication process as follows: initial state, instruction sending state for the first lower-level computer module, response waiting state for the first lower-level computer module, instruction sending state for the second lower-level computer module, response waiting state for the second lower-level computer module, ... instruction sending state for the last lower-level computer module, and response waiting state for the last lower-level computer module. Each response waiting state includes three sub-states: retrying, communication successful, and communication failure. The state machine transitions sequentially according to the above-preset state sequence until it has traversed all lower-level computer modules and completed the communication task of the host computer instruction, or is interrupted by a high-priority event midway.
4. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 3, characterized in that, The main controller dynamically calls the corresponding state machine enumeration list based on the function type of the instruction to be processed. Specifically, in each state machine instance, the instruction sending state and response waiting state for a specific lower-level module are independently configured with fault tolerance strategy parameters that match the instruction type. Moreover, the parameter configurations of each state in the state machine enumeration list corresponding to different instruction types are different, so that the parameters configured in each state of the state machine corresponding to the critical control instruction have different characteristics from the parameters configured in each state of the state machine corresponding to the status query instruction. The critical control instructions include power-on instructions and power-off instructions, and the status query instructions include timed data request instructions. The power-on instructions, power-off instructions, and status query instructions all contain fault tolerance strategy parameters corresponding to the timed data request instructions, which are reasonably set according to actual engineering requirements.
5. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 1, characterized in that, The two-factor session authentication mechanism based on identifiers and data fields decomposes the traditional single-path authentication into independent yet complementary dual authentication paths based on different fields of the CAN message. Specifically: On the main controller side, according to the predefined encoding rules, the instruction type information is encoded in the high-order part of the CAN identifier, and the lower-order module address information is encoded in the low-order part of the CAN identifier to form the first verification factor. By utilizing the natural filtering and addressing characteristics of the CAN protocol identifier field, the instruction type and device address information are structured and embedded in it. At this level, the lower-level module performs hardware-level fast filtering and matching, which can invalidate most irrelevant or incorrectly addressed messages. At the same time, according to the predetermined application layer protocol, it compares the specific feature values of the downlink command data sent to the lower-level module with the uplink response data replied by the lower-level module to form a second verification factor. The first verification factor is verified at the lower-level module. First, the identifier field of the received message is checked to verify whether its high-order part matches the expected instruction type and whether its low-order part matches the lower-level module address. If the first verification factor passes, then the verification of the second verification factor continues, i.e., comparing whether the specific feature value matches the expected feature value. The instruction is considered valid only if both factors pass the dual verification.
6. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 5, characterized in that, The identifier field is divided into two functional segments: an instruction type segment and a device address segment. The instruction type segment is located in the high-order part of the identifier field and is used to encode the type of instruction. The device address segment is located in the low-order part of the identifier field and is used to encode the physical or logical address of the lower-level module. By comparing the response frame data field of the lower-level module with the instruction frame data field sent to the lower-level module, the response frame identifier of the lower-level module, the lower-level module number, and the instruction type, a two-factor session verification mechanism of identifier and data field is established to confirm the validity of instruction execution and ensure the accuracy of instruction response.
7. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 5, characterized in that, The verification method for the second verification factor is as follows: the main controller predefines unique expected response data for each type of downlink command data according to the established communication protocol between the main controller and the lower-level module; after receiving the uplink response data replied by the lower-level module, it compares the data with the predefined expected response data; if the received uplink response data completely matches the expected response data, the command execution is deemed valid; if the received uplink response data does not match or no response data is received within a timeout, the command execution is deemed invalid, and a limited retry process is triggered.
8. The CAN bus hybrid scheduling and fault-tolerant communication method for multi-module devices according to claim 1, characterized in that, The specific implementation of the finite retry process is as follows: S1: When no response is received due to timeout or the two-factor session authentication mechanism determines that the response is invalid, the main controller initiates the retry process; S2: Increment the retry count by 1 and resend the command to the same lower-level module; S3: Wait for a response again and initiate the two-factor session verification mechanism to verify validity; S4: Repeat steps S1 to S3 for the retry process until the retry count reaches the maximum number of retries configured for the current instruction type; S5: If the main controller receives a valid response through the two-factor session verification mechanism before reaching the maximum number of retries, the instruction is deemed to have been executed successfully and the retries are terminated. S6: If no valid response is received after the retry count reaches the maximum number of retries, the current instruction execution is determined to have failed. The current lower-level module is marked as having a communication failure state, and a fault information containing the fault device identifier and fault type is generated and reported to the upper-level computer. The communication process is then immediately switched to the next lower-level module to continue execution, thereby achieving fault isolation.
9. A CAN bus hybrid scheduling and fault-tolerant communication system for multi-module devices, characterized in that, include: The host computer is used to issue control commands and receive status information and fault reports; The main controller, as the master node of the CAN bus, has a microprocessor at its core and executes the CAN bus hybrid scheduling and fault-tolerant communication method as described in any one of claims 1 to 8. Multiple lower-level modules, acting as slave nodes on the CAN bus, communicate with the main controller. The main controller adopts a dual CAN controller architecture and has two CAN interfaces. The first CAN controller is connected to the host computer through the first CAN interface. The CAN controller receives control commands issued by the host computer in real time through a hardware interrupt mechanism and submits the control commands to the microprocessor for processing. The second CAN controller connects to multiple lower-level modules through the second CAN interface, forming an independent CAN bus communication link for performing serial polling communication with multiple lower-level modules.