A can bus module communication method based on dynamic priority and hash conflict cooperation

Abstract

This invention proposes a CAN bus module communication method based on dynamic priority and hash collision coordination, comprising the following steps: Step 1, modules that need to communicate on the CAN bus send a pre-registration message to the MCU using a default address; Step 2, the MCU calculates the overall priority of the module based on the acquired bus load; Step 3, multiple candidate addresses are generated using an improved hash algorithm; Step 4, time-slotted collision detection is performed on the candidate addresses to find conflict-free addresses; Step 5, based on the time-slotted collision detection results and the overall priority of the module, dynamic address allocation is performed on the module, while simultaneously maintaining an idle address pool; Step 6, runtime collisions are detected through periodic verification and real-time detection, and collision avoidance is implemented.

Description

Technical Field

[0001] This invention relates to a CAN bus module communication method, and more particularly to a CAN bus module communication method based on dynamic priority and hash collision coordination. Background Technology

[0002] Currently, with the development of new power systems, the level of intelligence in substation equipment is constantly improving. As a reliable serial communication bus, the CAN bus is widely used in the collaborative communication between ECUs (Electronic Control Units) and various modules. However, in existing ECU projects, the address allocation mechanism of the CAN bus communication architecture has significant shortcomings, as detailed below.

[0003] 1. High risk of address conflict: When adopting a fixed pattern such as "module type high 4 bits + factory serial number low 6 bits", address conflicts are likely to occur when the factory serial number is repeated or the adjustment range of the low 6 bits is limited (only 0~63), resulting in data transmission interruption (such as loss of DIDO module remote signaling data, failure of control commands).

[0004] 2. Lack of priority differentiation: There is no priority distinction in the address allocation of all modules. Control modules (such as remote control output modules) and sensing modules (such as temperature and humidity sensing modules) compete for address resources, which may lead to delays in critical control commands.

[0005] 3. Lagging conflict detection: The lower 6 bits are only passively adjusted after an address conflict occurs, without an active detection mechanism. The conflict detection time is as long as 1 to 3 minutes (depending on heartbeat timeout), during which communication is completely interrupted.

[0006] 4. Waste of address resources: The addresses of offline modules are not reclaimed in time, resulting in the depletion of the idle address pool and the inability of new modules to register.

[0007] In existing technologies, CAN bus address conflict resolution methods mainly fall into two categories: hardware-fixed methods, which set the address via hardware DIP switches and require manual intervention, making them unsuitable for remote deployment scenarios; and simple random methods, which randomly adjust the lower 6 bits of the address after a conflict, lacking a conflict detection mechanism and potentially falling into a vicious cycle of "conflict-adjustment-re-conflict." Therefore, there is an urgent need for a purely software-implemented, highly reliable, low-latency address conflict resolution algorithm that is compatible with existing protocols, filling the gap in current technology. Summary of the Invention

[0008] Purpose of the invention: The technical problem to be solved by the present invention is to provide a CAN bus module communication method based on dynamic priority and hash collision coordination, which addresses the shortcomings of the existing technology.

[0009] To address the aforementioned technical problems, this invention discloses a CAN bus module communication method based on dynamic priority and hash collision coordination, comprising the following steps:

[0010] Step 1: The modules that need to communicate in the CAN bus send a pre-registration message to the MCU using the default address;

[0011] Step 2: The MCU calculates the overall priority of the module based on the acquired bus load;

[0012] Step 3: Use an improved hash algorithm to generate multiple candidate addresses;

[0013] Step 4: Perform time-slotted collision detection on the candidate addresses to find conflict-free addresses;

[0014] Step 5: Based on the time-slotted conflict detection results and the overall priority of the module, dynamically allocate addresses to the module and maintain an idle address pool at the same time.

[0015] Step 6: Detect runtime conflicts through periodic verification and real-time detection, and avoid conflicts.

[0016] Furthermore, the step 1 of sending a pre-registration message to the MCU at the default address includes:

[0017] After the module starts up, it sends a pre-registration message to the MCU via the factory default address. The pre-registration message follows the original application data structure, including a frame header, frame trailer, control field, and data field.

[0018] The control field function code is set to the preset pre-registration command; the data field includes module type, factory serial number, communication frequency, function priority identifier and module status code; among which, the module status code is used to indicate the module start-up status.

[0019] Furthermore, the overall priority of the computing module mentioned in step 2 includes:

[0020] Step 2-1: After receiving the pre-registration message, the MCU extracts the information contained in the data field;

[0021] Step 2-2, calculate the module's synthesis priority P, as shown below:

[0022]

[0023] Where F is the functional priority quantification value, which is determined by the type of module; This is the normalized value of the communication frequency; This is the verification value for the factory serial number; , and These are dynamic weighting coefficients, and the sum of the dynamic weighting coefficients is 1.

[0024] Furthermore, the dynamic weighting coefficients mentioned in step 2-2 are dynamically adjusted based on the obtained bus load and threshold.

[0025] Furthermore, step 3, which involves generating multiple candidate addresses using an improved hash algorithm, includes:

[0026] Multiple candidate addresses are generated based on the module type ID, factory serial number, current system timestamp, and overall priority of the module.

[0027] Furthermore, the step 3, which involves generating multiple candidate addresses using an improved hash algorithm, specifically includes the following steps:

[0028] Step 3-1: Use the SHA-1 algorithm to extract the first 32 bits of the module's serial number hash value M;

[0029] Step 3-2: Obtain the current system timestamp T;

[0030] Step 3-3: Calculate the priority offset S based on the priority P, as follows:

[0031]

[0032] in, Indicates rounding down;

[0033] Steps 3-4: Calculate candidate low-order addresses , means as follows:

[0034]

[0035] in, For address number, , This is the prime number offset. This indicates taking the modulus of 64;

[0036] Steps 3-5 combine the module type ID with the candidate low-order address to form multiple candidate addresses, represented as follows: .

[0037] Furthermore, step 4, which involves performing time-slotted conflict detection on candidate addresses, includes:

[0038] Step 4-1: The MCU sends a time slot allocation message to the module, containing the time slot numbers corresponding to all candidate addresses. Time slot parameters, including time slot length, time slot interval, and response window;

[0039] Step 4-2, the module in the time slot Send an internal address test message, with the destination address being [address]. The data field is the module number, and triple verification is performed as follows:

[0040] The first verification step involves the MCU monitoring the CAN bus. If no CAN bus is detected... Concurrent messages to an address will undergo the second and third layers of verification; otherwise, they will be considered as bidirectional conflicts.

[0041] The second layer of verification involves the MCU sending... The address sends a verification response message. After receiving the message, the module replies with an acknowledgment. If no reply is received, it is determined to be a one-way conflict; otherwise, the second verification is passed.

[0042] The third verification involves the module sending an address confirmation message to the MCU. The MCU receives the message and replies with an confirmation. If no reply is received, it is determined to be a one-way conflict; otherwise, the third verification is passed.

[0043] like If the address passes triple verification, it is marked as a conflict-free address; if Address conflict, check other addresses.

[0044] Furthermore, the dynamic address allocation for the module described in step 5 includes:

[0045] Step 5-1: Select conflict-free addresses from the candidate addresses and allocate them according to priority P from high to low;

[0046] Step 5-2: If all candidate addresses conflict, the optimal free address is extracted from the free address pool for allocation. The optimal free address is the address that is the one that is the oldest since the last allocation and whose Hamming distance from the allocated address is greater than or equal to a preset value.

[0047] Step 5-3: The MCU records the address allocation status, updates the address allocation table, and sends an address confirmation message to the module.

[0048] Step 5-4: After receiving the address confirmation message, the module updates its local CAN address and replies with an address activation message.

[0049] Step 5-5: After receiving the address activation message, the MCU marks the module as registered.

[0050] Furthermore, the maintenance of the free address pool described in step 5 includes:

[0051] Regularly scan and mark the addresses of registered modules that have not sent heartbeat messages within the first preset time period as waiting to be reclaimed;

[0052] Delayed recycling: If an address awaiting recycling does not request re-registration within a second preset time period, it will be placed into the idle address pool.

[0053] Address cleaning removes unassigned addresses from the free address pool that have exceeded the third preset time period and re-verifies availability.

[0054] Furthermore, the conflict avoidance described in step 6 includes:

[0055] Step 6-1: Periodic verification. The MCU broadcasts address verification messages according to the heartbeat cycle. The module receives the message and replies. If no reply is received, it is marked as a suspected conflict.

[0056] Step 6-2, Real-time Collision Detection: The MCU monitors the CAN bus. If concurrent messages with the same address are detected, collision handling is performed immediately, specifically including:

[0057] Step 6-2-1: The MCU sends a conflict alarm message to the conflicting address, and at the same time randomly selects a temporary address from the free address pool and allocates it, while setting the validity period.

[0058] Step 6-2-2: After receiving the temporary address and validity period, the module switches to the temporary address to send a temporary validity message;

[0059] Step 6-2-3: Based on the temporary address, the module re-executes steps 3 to 5 to update the formal address;

[0060] Step 6-2-4: If the temporary address is not updated within the validity period, the MCU will reallocate the temporary address. If reallocation fails, the module will be marked as faulty.

[0061] Step 6-3: After the conflict resolution is completed, the MCU updates the address allocation table, puts the original conflicting address into the free address pool and marks it as needing verification.

[0062] Beneficial effects:

[0063] 1. This invention implements five core mechanisms through pure software: dynamic priority quantization calculation, improved timestamp hash candidate address generation, multi-dimensional time-slotted conflict detection, dynamic address pool management, and runtime conflict closed-loop avoidance. It is embedded in the original CAN bus communication architecture and does not rely on hardware modifications.

[0064] 2. This invention can control the address conflict rate to an extremely low level, and provides a high success rate for address allocation of high-priority modules (control class), while keeping the address allocation response time within a short range. In addition, it is fully compatible with the original communication protocols (frame structure, function code, data format).

[0065] 3. This invention is applicable to real-time collaborative communication scenarios between ECU main control unit (MCU) and various types of highly dynamic CAN bus modules, and is especially suitable for application requirements with frequent hot-swapping of modules and significant functional differences. Attached Figure Description

[0066] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0067] Figure 1 This is a schematic diagram of the overall process of the method of the present invention.

[0068] Figure 2 This is a detailed flowchart of the method of the present invention. Detailed Implementation

[0069] This application provides a CAN bus module communication method based on a dynamic priority hash-conflict cooperative algorithm, which is applicable to real-time cooperative communication scenarios between ECU master control unit (MCU) and multiple types of highly dynamic CAN bus modules.

[0070] The overall technical concept of this application is to provide a CAN bus module communication method based on a dynamic priority hash-conflict cooperative algorithm. The method implements five core mechanisms in pure software, embeds them into the original CAN bus communication architecture, does not rely on hardware modifications, and effectively solves problems such as frequent address conflicts, insufficient communication stability of key modules, and lagging conflict detection.

[0071] This application achieves the following: 1) an extremely low address conflict rate; 2) a high success rate for address allocation to high-priority modules (control types); 3) address allocation response time is kept within a short range; and 4) full compatibility with existing communication protocols (frame structure, function codes, data formats). This method is particularly suitable for the application requirements of Saudi ECU projects, which involve frequent hot-swapping of modules and significant functional differences.

[0072] The core idea of ​​this invention lies in constructing a complete algorithm system of "priority-oriented - hash generation - time slot detection - dynamic management - closed-loop avoidance", as detailed below:

[0073] 1. Dynamic weight priority model: The weights are dynamically adjusted based on functional importance, communication frequency, and bus load to ensure that high-priority modules (such as control modules) obtain conflict-free addresses first.

[0074] 2. Improved timestamp hash algorithm: Combines the module's unique identifier (factory serial number hash), real-time timestamp, and priority offset to generate 3 low-collision candidate addresses, improving collision resistance by 3 times;

[0075] 3. Bidirectional triple collision detection: Combining bus monitoring, MCU→module response, and module→MCU response, it avoids misjudgments caused by one-way communication failures, with a collision detection accuracy rate of ≥99.9%;

[0076] 4. Dynamic Free Address Pool: Through a "periodic scanning - delayed reclamation - address cleaning" mechanism, it achieves efficient circulation of address resources, increasing address utilization to over 90%;

[0077] 5. Runtime closed-loop conflict avoidance: Periodic verification + real-time response, conflict detection time is shortened to within 100ms, recovery time is ≤30ms, and communication interruption is avoided.

[0078] like Figure 1 As shown, the method includes:

[0079] Step S101, Module pre-registration: The module sends a pre-registration message at the default address, containing key parameters such as type ID and factory serial number;

[0080] Step S102, Priority Calculation: The MCU calculates the overall priority of the module according to the dynamic weight model (combining functional priority, communication frequency, etc., with weights adjusted according to bus load);

[0081] Step S103, Candidate Address Generation: The high 4 bits of the fixed address are used to generate 3 11-bit candidate addresses using an improved hash algorithm (integrating the factory serial number hash, timestamp, etc.);

[0082] Step S104, Time-slotted conflict detection: Allocate independent time slots to candidate addresses and detect conflicts through triple verification of bus monitoring and bidirectional response;

[0083] Step S105, Dynamic Address Allocation: Prioritize selecting conflict-free candidate addresses; if none are found, take the optimal address from the free pool while maintaining the address pool (periodic scanning, delayed reclamation, etc.).

[0084] Step S106, Runtime Conflict Avoidance: Conflicts are detected through periodic verification and real-time detection, triggering closed-loop processing such as temporary address allocation and re-addressing.

[0085] Specifically, such as Figure 2 As shown, this application is implemented through the following steps.

[0086] I. Module Pre-registration Stage:

[0087] After the CAN bus module starts up, it sends a pre-registration message to the MCU via the factory default address (the lower 6 bits are the factory serial number mod 64, and the higher 4 bits are the module type ID). The pre-registration message follows the original application data structure (frame header 0x68, frame tail 0x16), with the control field function code set to 0x0B (pre-registration command), and the data field defined byte-wise as follows:

[0088] [Module Type ID (1 byte), Serial Number (16 bytes), Communication Frequency (2 bytes, unit Hz), Functional Priority Identifier (1 byte), Module Status Code (1 byte)]

[0089] Among them, module status code 0x00 indicates normal startup, and 0x01 indicates fault restart.

[0090] The specific byte allocation of the pre-registration message data field (21 bytes in total) is shown in Table 1:

[0091] Table 1. Byte Allocation Table for Pre-registration Message Data Field

[0092] 0 Module Type ID 1 BIN The corresponding high 4 bits of the CAN address, such as 0x05 = control type, 0x03 = sensing type, 0x01 = auxiliary type. 1~16 Factory serial number 16 ASCII A unique identifier for the module, such as "SA_ECU_202405001". 17~18 Communication frequency 2 BIN Little-endian mode, such as 0x0064=100Hz, 0x0032=50Hz 19 Functional priority identifier 1 BIN 0x05 = Control type (highest), 0x03 = Sensing type, 0x01 = Auxiliary type 20 Module status codes 1 BIN 0x00 = Normal startup, 0x01 = Fault restart, 0x02 = Restart after upgrade

[0093] II. Priority Calculation Phase:

[0094] After receiving the pre-registration message, the MCU extracts the data field parameters and calculates the module's overall priority P using a dynamic weighted priority model. The formula is as follows:

[0095]

[0096] In the formula, F is the functional priority quantification value (range 1-5; F=4-5 for control modules, F=2-3 for sensing modules, and F=1 for auxiliary modules). The normalized value of the communication frequency ( = Actual communication frequency / 1000, range 0.001-10, rounded to 3 decimal places). This is the factory serial number check value (the sum of the 16 bytes of the factory serial number mod 10, range 0-9). , , For dynamic weighting coefficients, satisfying + + =1, and dynamically adjusted according to bus load:

[0097] (1) When bus load = 25% (low load): =0.4、 =0.3、 =0.3, balancing functional priority and communication frequency;

[0098] (2) When the bus load = 50% (medium load): =0.5、 =0.4、 =0.1, increase the priority weight of the function;

[0099] (3) When bus load = 70% (high load): =0.6、 =0.3、 =0.1, prioritizing communication for control modules.

[0100] III. Candidate Address Generation Stage:

[0101] The MCU generates three candidate addresses (b05~b00) based on the module type ID, which is the high 4 bits of the fixed CAN address (b09~b06), using an improved timestamp hash algorithm. The specific steps are as follows:

[0102] (1) Extract the 32-bit hash value M of the module's serial number (using the SHA-1 algorithm to take the first 32 bits);

[0103] (2) Obtain the current system timestamp T (accurate to 1ms, formatted as 4-byte UNIX time);

[0104] (3) Calculate the priority offset S (S = P×3, take the integer part, range 3-15);

[0105] (4) According to public = (M×T + S + i×17) mod 64 generates 3 candidate lower 6-bit addresses (i=1,2,3, 17 is a prime offset to avoid duplicate candidate addresses);

[0106] (5) Combine the high 4 bits with the 3 candidate low 6 bits to form 3 complete 11-bit CAN candidate addresses (A1, A2, A3).

[0107] IV. Time-slotted conflict detection phase:

[0108] The MCU allocates independent listening time slots for the three candidate addresses and uses a bidirectional triple verification mechanism to detect address conflicts. The specific process is as follows:

[0109] (1) The MCU sends a time slot allocation message (function code 0x0C) to the module, which includes the time slot number (T1, T2, T3) and time slot parameters (time slot length 5ms, time slot interval 2ms, response window 1ms) corresponding to the three candidate addresses.

[0110] (2) The module sends an address test message (target address A1, data field is module number) in time slot T1, and the MCU performs triple verification:

[0111] Verification 1 (Bus Listening): The MCU listens to the bus. If no concurrent message is detected at address A1, proceed to Verification 2.

[0112] Verification 2 (MCU → Module): The MCU sends a verification response message (data field is "VERIFY_OK") to A1. The module receives the message and replies with an acknowledgment. If no reply is received, it is determined to be a "one-way conflict".

[0113] Verification 3 (Module → MCU): The module sends an address confirmation message (data field A1) to the MCU. The MCU receives the message and replies with an acknowledgment. If no reply is received, it is determined to be a "one-way conflict".

[0114] (3) If A1 passes the triple verification, mark it as a "no conflict address"; if A1 is conflicted, check A2 and A3 according to the same process;

[0115] Conflict state definitions: no conflict (all three verifications pass), one-way conflict (any one verification fails), and two-way conflict (concurrent messages are detected on the bus).

[0116] V. Dynamic Address Allocation Phase:

[0117] The MCU allocates addresses based on the collision detection results and maintains a dynamic free address pool. The specific steps are as follows:

[0118] (1) Prioritize the selection of "non-conflicting addresses" from the three candidate addresses and allocate them from high to low priority P (if there are multiple non-conflicting addresses, select the one with the smallest sequence number);

[0119] (2) If all three candidate addresses conflict, extract the “optimal free address” from the free address pool (defined as: the address that is the oldest time since the last allocation and has a Hamming distance ≥ 3 from the allocated address; the Hamming distance is used to reduce interference between adjacent addresses).

[0120] (3) The MCU updates the address allocation table (including: module number, CAN address, priority P, allocation time, status) and sends an address confirmation message to the module (function code 0x0D, data field is allocated address + validity period);

[0121] (4) After receiving the message, the module updates its local CAN address and replies with a "address effective" message. After receiving the message, the MCU marks the module as "registered".

[0122] (5) Rules for maintaining the free address pool:

[0123] Periodic scanning (cycle 10s): For modules that are "registered" but have no heartbeat message within 30s, mark their addresses as "to be reclaimed";

[0124] Delayed recycling (5s delay): If no re-registration request is received within 5s for an address to be recycled, it will be placed in the free address pool.

[0125] Address cleaning (daily at 00:00): Removes addresses from the idle address pool that have not been allocated for more than 24 hours and re-verifies availability;

[0126] VI. Runtime Conflict Avoidance Phase:

[0127] The MCU achieves closed-loop conflict handling through periodic verification and real-time response. The specific steps are as follows:

[0128] (1) Periodic verification: The MCU broadcasts an address verification message (function code 0x0E, data field is "CHECK_ADDR") according to the heartbeat cycle (default 1 minute). After receiving the message, the module replies with "ADDR_VALID + its own CAN address". If it does not reply, it is marked as "suspected conflict".

[0129] (2) Real-time conflict detection: The MCU monitors the bus and if it detects concurrent messages with the same address, it immediately triggers the "conflict handling process";

[0130] (3) Conflict resolution process:

[0131] Step 1: The MCU sends a "conflict alarm" message to the conflicting address and simultaneously allocates a temporary address (randomly selected from the free address pool, valid for 60 seconds, and marked as "temporarily occupied").

[0132] Step 2: After receiving the temporary address, the module switches to the temporary address and sends a "Temporary Effective" message;

[0133] Step 3: Based on the temporary address, the module re-executes Step 3 (candidate address generation) - Step 5 (address allocation) to complete the formal address update;

[0134] Step 4: If the temporary address is not updated within its validity period, the MCU will reassign a temporary address (maximum of 3 retries; if the retries fail, the module will be marked as "faulty").

[0135] (4) After the conflict is resolved, the MCU updates the address allocation table, puts the original conflicted address into the free address pool and marks it as "needs to be checked" (the conflict needs to be checked again before the next allocation).

[0136] Example:

[0137] This embodiment takes a 220kV intelligent substation ECU (electronic control unit) system as the application scenario. The system contains 3 types of CAN bus modules. The specific parameters are shown in the table below. The MCU performs dynamic address allocation and conflict avoidance for the 3 connected modules. The initial bus load is 20% (low load). The initial free address pool contains addresses 0x030, 0x035, 0x042, and 0x051 (11-bit CAN address, the high 4 bits are the module type ID, and the low 6 bits are the address sequence number).

[0138] Table 2 CAN Bus Module Parameter Table

[0139] Control class (ID: 0x05) 1 Remote control circuit breaker opening and closing SA_ECU_202405001 100Hz 0x05 Sensor category (ID: 0x03) 1 Collect temperature and humidity data SA_ECU_202405002 50Hz 0x03 Auxiliary class (ID: 0x01) 1 Provides power status monitoring SA_ECU_202405003 20Hz 0x01

[0140] (a) Module pre-registration stage

[0141] After the module powers on, it sends a pre-registration message to the MCU via the factory default address (lower 6 bits = factory serial number mod 64, higher 4 bits = module type ID). The message follows the original frame structure (frame header 0x68, frame trailer 0x16), the control field function code is set to 0x0B, and the data field is allocated by byte as follows:

[0142] Control modules: The data field is [0x05, "SA_ECU_202405001" (16 bytes), 0x00, 0x64 (100Hz, little-endian), 0x05, 0x00]

[0143] Sensor modules: The data field is [0x03, "SA_ECU_202405002" (16 bytes), 0x00, 0x32 (50Hz, little-endian), 0x03, 0x00]

[0144] Auxiliary modules: The data field is [0x01, "SA_ECU_202405003" (16 bytes), 0x00, 0x14 (20Hz, little-endian), 0x01, 0x00]

[0145] The MCU successfully received 3 pre-registration messages, with no messages lost or formatted incorrectly.

[0146] (II) Priority Calculation Stage

[0147] Since the initial bus load is 20% (low load), the dynamic weighting coefficient is set to... =0.4、 =0.3、 =0.3, according to the formula Calculate the overall priority P:

[0148] Control module: F = 5; = 100Hz / 1000 = 0.1; The sum of the 16 bytes of ASCII code in "SA_ECU_202405001" is 1005. = 1005 mod 10 = 5. P = 0.4×5+0.3×0.1+0.3×5 = 2+0.03+1.5 = 3.53.

[0149] Sensing modules: F = 3; = 50Hz / 1000 = 0.05; The sum of the 16 bytes of ASCII code in "SA_ECU_202405002" is 1006. = 1006 mod 10 = 6. P = 0.4×3+0.3×0.05+0.3×6 =1.2+0.015+1.8 = 3.015.

[0150] Auxiliary module: F = 1; = 20Hz / 1000 = 0.02; The sum of the 16 bytes of ASCII code in "SA_ECU_202405003" is 1007. = 1007 mod 10 = 7. P = 0.4×1+0.3×0.02+0.3×7 =0.4+0.006+2.1 = 2.506.

[0151] (III) Candidate Address Generation Stage

[0152] Based on an improved timestamp hash algorithm, the high 4 bits are fixed as the module type ID, generating 3 candidate addresses for the low 6 bits (formula). = (M×T + S + i×17) mod 6, where i=1,2,3, and 17 is the prime number offset):

[0153] (1) Parameter preparation

[0154] M (Hash value of the first 32 bits of the serial number SHA-1): Control module M1=0x90E12E65, Sensor module M2=0xB1F763BD, Auxiliary module M3=0x2DB7729A

[0155] T (Current system timestamp, accurate to 1ms): 1717171200 (2024-06-01 00:00:00)

[0156] S (Priority Offset): Control class S1 = |3.53 × 3| = 10, Sensing class S2 = |3.015 × 3| = 9, Auxiliary class S3 = |2.506 × 3| = 7

[0157] (2) Candidate address calculation

[0158] Control modules:

[0159] H1 = (0x90E12E65×1717171200+10+1×17) mod 64 = 27;

[0160] H2 = (0x90E12E65×1717171200+10+2×17) mod 64 = 44;

[0161] H3 = (0x90E12E65×1717171200+10+3×17) mod 64 = 61,

[0162] The candidate addresses are 0x015B (0x05<<6 +27), 0x016C (0x05<<6 +44), and 0x17D (0x05<<6 +61).

[0163] Sensing modules:

[0164] H1 = (0xB1F763BD×1717171200+9+1×17) mod 64 = 26;

[0165] H2 = (0xB1F763BD×1717171200+9+2×17) mod 64 = 43;

[0166] H3 = (0xB1F763BD×1717171200+9+3×17) mod 64 = 60,

[0167] The candidate addresses are 0x00DA (0x03<<6 +26), 0x00EB (0x03<<6 +43), and 0x00FC (0x03<<6 +60).

[0168] Auxiliary modules:

[0169] H1 = (0x2DB7729A×1717171200+7+1×17) mod 64 = 24;

[0170] H2 = (0x2DB7729A×1717171200+7+2×17) mod 64 = 41;

[0171] H3 = (0x2DB7729A×1717171200+7+3×17) mod 64 = 58,

[0172] The candidate addresses are 0x0058 (0x01<<6 +24), 0x0069 (0x01<<6 +41), and 0x007A (0x01<<6 +58).

[0173] (iv) Time-slotted conflict detection phase

[0174] The MCU sends a time slot allocation message (function code 0x0C) to the three modules. The time slot length is 5ms, the interval is 2ms, and the response window is 1ms. The modules send address test messages in the corresponding time slots, and collisions are detected through triple verification.

[0175] (1) Control modules

[0176] Time slot T1 (0-5ms) test 0x015B: MCU did not detect concurrent messages (verification 1 passed), sent a response message and received module confirmation (verification 2 passed), received module address confirmation message and replied (verification 3 passed), marked as a conflict-free address.

[0177] (2) Sensing modules

[0178] Time slot T1 (0-5ms) test 0x00DA: The MCU detects a concurrent message with 0x00DA on the bus (verification 1 fails), and determines a bidirectional conflict;

[0179] Time slot T2 (7-12ms) test 0x00EB: No concurrent packets (verification 1 passed), bidirectional response normal (verification 2, 3 passed), marked as conflict-free address.

[0180] (3) Auxiliary modules

[0181] Time slot T1 (0-5ms) test 0x0058: No concurrent messages (verification 1 passed), bidirectional response normal (verification 2, 3 passed), marked as conflict-free address.

[0182] (v) Dynamic address allocation stage

[0183] (1) Address allocation

[0184] Control modules: Prioritize selecting the conflict-free candidate address 0x015B, the MCU updates the address allocation table, sends an address confirmation message (function code 0x0D, data field 0x015B + validity period 300s), and after the module updates its local address, it replies "address effective" and is marked as registered.

[0185] Sensor modules: Select a conflict-free candidate address 0x00EB and complete the allocation and registration process.

[0186] Auxiliary modules: Select the conflict-free candidate address 0x0058 to complete the allocation and registration process.

[0187] (2) Maintenance of the free address pool

[0188] Periodic scan (10s cycle): If no module without heartbeat message is found after 10s, the address pool status remains unchanged.

[0189] The initial free address pool (0x030, 0x035, 0x042, 0x051) remains unchanged.

[0190] (vi) Runtime conflict avoidance phase

[0191] Periodic verification: The MCU broadcasts an address verification message (function code 0x0E) every 1 minute. All 3 modules reply with "ADDR_VALID + their own address", indicating no suspected conflict.

[0192] Conflict simulation: A conflict is artificially simulated between control module 0x015B and a newly added faulty module (mistakenly set address 0x015B). The MCU detects the concurrent message and triggers the processing flow.

[0193] Step 1: The MCU sends a conflict alarm message to 0x015B and selects 0x016C from the free address pool as a temporary address (valid for 60 seconds).

[0194] Step 2: The control module receives the temporary address, switches to 0x016C, and sends a "Temporary Effective" message.

[0195] Step 3: The module re-executes the candidate address conflict detection (0x016C has no conflict) and address allocation based on 0x016C, and completes the formal address update to 0x016C.

[0196] Step 4: The MCU updates the address allocation table, puts the original conflicting address 0x015B into the free address pool and marks it as "needs verification".

[0197] The implementation results are shown in Table 3:

[0198] Table 3 Implementation Results

[0199] Address conflict rate A conflict occurred only once in the simulated scenario; no conflicts were observed during actual operation, with an occurrence rate of 0.05%. High priority module address allocation success rate Control modules were successfully assigned on the first attempt, and reassigned successfully after a conflict, with a 100% success rate. Address allocation response time The average time allocated to the 3 modules is 45ms. Protocol compatibility The frame structure, function codes, and data format remain unchanged, and it communicates normally with the original module.

[0200] In its specific implementation, this application provides a computer storage medium and a corresponding data processing unit. The computer storage medium is capable of storing a computer program, which, when executed by the data processing unit, can run the invention's content regarding a CAN bus module communication method based on dynamic priority and hash collision coordination, as well as some or all of the steps in various embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0201] Those skilled in the art will clearly understand that the technical solutions in the embodiments of the present invention can be implemented using computer programs and their corresponding general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of computer programs, i.e., software products. These computer program software products can be stored in a storage medium and include several instructions to cause a device containing a data processing unit (which may be a personal computer, server, microcontroller, MCU, or network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of the present invention.

[0202] This invention provides a concept and method for CAN bus module communication based on dynamic priority and hash collision coordination. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment of the invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A CAN bus module communication method based on dynamic priority and hash collision coordination, characterized in that, Includes the following steps: Step 1: The modules that need to communicate in the CAN bus send a pre-registration message to the MCU using the default address; Step 2: The MCU calculates the overall priority of the module based on the acquired bus load; Step 3: Use an improved hash algorithm to generate multiple candidate addresses; Step 4: Perform time-slotted collision detection on the candidate addresses to find conflict-free addresses; Step 5: Based on the time-slotted conflict detection results and the overall priority of the module, dynamically allocate addresses to the module and maintain an idle address pool at the same time. Step 6: Detect runtime conflicts through periodic verification and real-time detection, and avoid conflicts.

2. The CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 1, characterized in that, The step 1 of sending a pre-registration message to the MCU at the default address includes: After the module starts up, it sends a pre-registration message to the MCU via the factory default address. The pre-registration message follows the original application data structure, including a frame header, frame trailer, control field, and data field. The control field function code is set to the preset pre-registration command; the data field includes module type, factory serial number, communication frequency, function priority identifier and module status code; among which, the module status code is used to indicate the module start-up status.

3. The CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 2, characterized in that, The overall priority of the computing module mentioned in step 2 includes: Step 2-1: After receiving the pre-registration message, the MCU extracts the information contained in the data field; Step 2-2, calculate the module's synthesis priority P, as shown below: ； Where F is the functional priority quantification value, which is determined by the type of module; This is the normalized value of the communication frequency; This is the verification value for the factory serial number; , and These are dynamic weighting coefficients, and the sum of the dynamic weighting coefficients is 1.

4. The CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 3, characterized in that, The dynamic weighting coefficients mentioned in step 2-2 are dynamically adjusted based on the obtained bus load and threshold.

5. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 4, characterized in that, Step 3, which involves generating multiple candidate addresses using an improved hash algorithm, includes: Multiple candidate addresses are generated based on the module type ID, factory serial number, current system timestamp, and overall priority of the module.

6. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 5, characterized in that, Step 3, which involves generating multiple candidate addresses using an improved hash algorithm, includes the following specific steps: Step 3-1: Use the SHA-1 algorithm to extract the first 32 bits of the module's serial number hash value M; Step 3-2, obtain the current system timestamp T; Step 3-3: Calculate the priority offset S based on the priority P, as follows: ； in, Indicates rounding down; Steps 3-4: Calculate candidate low-order addresses , means as follows: ； in, Address number, , This is the prime number offset. This indicates taking the modulus of 64; Steps 3-5 combine the module type ID with the candidate low-order address to form multiple candidate addresses, represented as follows: .

7. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 6, characterized in that, Step 4, which involves performing time-slotted collision detection on candidate addresses, includes: Step 4-1: The MCU sends a time slot allocation message to the module, containing the time slot numbers corresponding to all candidate addresses. Time slot parameters, including time slot length, time slot interval, and response window; Step 4-2, the module in the time slot Send an internal address test message, with the destination address being [address]. The data field is the module number, and triple verification is performed as follows: The first verification step involves the MCU monitoring the CAN bus. If no CAN bus is detected... Concurrent messages to an address will undergo the second and third layers of verification; otherwise, they will be considered as bidirectional conflicts. The second verification step involves the MCU sending... The address sends a verification response message. After receiving the message, the module replies with an acknowledgment. If no reply is received, it is determined to be a one-way conflict; otherwise, the second verification is passed. The third verification involves the module sending an address confirmation message to the MCU. The MCU receives the message and replies with an confirmation. If no reply is received, it is determined to be a one-way conflict; otherwise, the third verification is passed. like If the address passes triple verification, it is marked as a conflict-free address; if Address conflict, check other addresses.

8. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 7, characterized in that, Step 5, which involves dynamically allocating addresses to the module, includes: Step 5-1: Select conflict-free addresses from the candidate addresses and allocate them according to priority P from high to low; Step 5-2: If all candidate addresses conflict, the optimal free address is extracted from the free address pool for allocation. The optimal free address is the address that is the one that is the oldest since the last allocation and whose Hamming distance from the allocated address is greater than or equal to a preset value. Step 5-3: The MCU records the address allocation status, updates the address allocation table, and sends an address confirmation message to the module. Step 5-4: After receiving the address confirmation message, the module updates its local CAN address and replies with an address activation message. Step 5-5: After receiving the address activation message, the MCU marks the module as registered.

9. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 8, characterized in that, The maintenance of the free address pool described in step 5 includes: Regularly scan and mark the addresses of registered modules that have not sent heartbeat messages within the first preset time period as waiting to be reclaimed; Delayed recycling: If an address awaiting recycling does not request re-registration within a second preset time period, it will be placed into the idle address pool. Address cleaning removes unassigned addresses from the free address pool that have exceeded the third preset time period and re-verifies availability.

10. A CAN bus module communication method based on dynamic priority and hash collision coordination according to claim 9, characterized in that, Step 6, which describes conflict avoidance, includes: Step 6-1: Periodic verification. The MCU broadcasts address verification messages according to the heartbeat cycle. The module receives the message and replies. If no reply is received, it is marked as a suspected conflict. Step 6-2, Real-time Collision Detection: The MCU monitors the CAN bus. If concurrent messages with the same address are detected, collision handling is performed immediately, specifically including: Step 6-2-1: The MCU sends a conflict alarm message to the conflicting address, and at the same time randomly selects a temporary address from the free address pool and allocates it, while setting the validity period. Step 6-2-2: After receiving the temporary address and validity period, the module switches to the temporary address to send a temporary validity message; Step 6-2-3: Based on the temporary address, the module re-executes steps 3 to 5 to update the formal address; Step 6-2-4: If the temporary address is not updated within the validity period, the MCU will reallocate the temporary address. If reallocation fails, the module will be marked as faulty. Step 6-3: After the conflict resolution is completed, the MCU updates the address allocation table, puts the original conflicting address into the free address pool and marks it as needing verification.

Images