Distributed address allocation method based on CAN bus, battery pack and storage medium

Abstract

The embodiment of the invention discloses a distributed address allocation method based on a CAN bus, a battery pack and a storage medium, and relates to the technical field of CAN bus address allocation, and the method comprises the steps: obtaining a unique code of itself; sending a competition frame carrying a unique code of itself through a CAN bus; obtaining unique codes of other nodes, and marking node states corresponding to the obtained unique codes as online; according to a preset mapping rule, cluster numbers of all the online nodes are determined, the node with the specific cluster number is determined as a host, and the mapping rule is associated with codes of all the online nodes. By adopting the method provided by the invention, the whole process of address allocation and host selection can be autonomously and collaboratively completed by the nodes.

Description

Technical Field

[0001] This invention relates to the field of CAN bus address allocation technology, and in particular to a distributed address allocation method based on CAN bus, a battery pack, and a storage medium. Background Technology

[0002] In scenarios such as new energy vehicles and energy storage power stations, battery management systems (BMS) typically adopt a distributed architecture with multiple battery pack nodes working collaboratively. Nodes need to communicate with each other via a communication bus to achieve state synchronization, data exchange, and command transmission. Address allocation is a core prerequisite for ensuring the orderly operation of the distributed system. Each node must have a unique logical address (such as a cluster number) to avoid communication conflicts and achieve accurate data routing.

[0003] Current mainstream address allocation schemes primarily rely on a "centralized master controller allocation" model. Its core logic is as follows: a dedicated master controller (such as a central gateway or main BMS module) is set up, and all slave nodes send address requests to the master controller upon power-up. The master controller then uniformly allocates unique addresses and broadcasts them to the entire system. However, this scheme has significant drawbacks in practical applications: Firstly, the address allocation and host selection process is entirely dependent on the master controller; slave nodes cannot autonomously acquire addresses or determine master / slave identities. The entire process requires manual intervention in configuring the master controller's parameters, making full automation impossible. Secondly, the deployment of the master controller not only increases hardware and cabling costs, but subsequent program debugging, parameter optimization, and troubleshooting also require professional technical personnel, significantly increasing system maintenance costs. Furthermore, the master and slave nodes need to match a dedicated communication protocol, resulting in high protocol adaptation complexity and further reducing system compatibility and scalability.

[0004] There is an urgent need for a distributed address allocation scheme that does not rely on a central main controller and can automatically complete the entire process of address allocation and host election. Summary of the Invention

[0005] In view of this, the present invention provides a distributed address allocation method, a battery pack and a storage medium based on CAN bus, aiming to solve the problem that the existing technology requires a central master controller to perform distributed address allocation.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A distributed address allocation method based on CAN bus, the method comprising: S1. Obtain its own unique code; S2. Send a contention frame carrying its own unique code via the CAN bus; S3. Obtain the unique code of other nodes and mark the node status corresponding to the obtained unique code as online; S4. Determine the cluster number of all online nodes according to the preset mapping rules, wherein the node with a specific cluster number is determined as the host, and the mapping rules are associated with the encoding of all online nodes.

[0007] Optionally, the method further includes: S5. Periodically send heartbeat frames carrying its own unique code and cluster number to the CAN bus; S6. Monitor the heartbeat frame transmission status of other nodes. If a heartbeat frame of a certain node is not received within a preset number of consecutive heartbeat cycles, record the node status as offline and return to S4 to reallocate the cluster number and host of all online nodes.

[0008] Optionally, S5 further includes: Maintain a local online device table, which records the unique code, cluster number, last online timestamp, and node status of all online nodes; obtain the unique code and cluster number of other nodes from the heartbeat frames sent by other nodes, and update the last online timestamp and node status of the corresponding node in the local online device table to online accordingly.

[0009] Optionally, S6 includes: Periodically check the last online timestamp of other nodes in the local online device table; If the difference between the current system time and the last online timestamp of a certain node exceeds a preset number of heartbeat cycles, the node is determined to be offline, and the node's status is updated to offline in the local online device table. Then, the process returns to step S4 to reallocate the cluster number and host of all online nodes.

[0010] Optionally, the method further includes: The system receives a synchronization frame sent to the CAN bus by the host. The synchronization frame carries the host's system timestamp to synchronize the system time.

[0011] Optionally, S1 includes: Retrieve the unique code pre-stored in memory; If a unique code is not obtained, a globally unique code is generated and stored in memory.

[0012] Optionally, generating a globally unique code and storing it in memory includes: A unique code is generated by combining hardware features with a hardware random number generator; Check if other nodes have the same unique code. If they do, regenerate the unique code and repeat the check until the check passes. Write the unique code that passes the detection into the memory.

[0013] Optionally, S4 includes: Sort all online nodes' unique codes according to preset rules; The cluster number and master of each node are determined based on the sorting results. The node corresponding to a specific cluster number is determined to be the master, and the remaining nodes are determined to be slaves. If the cluster number changes, a cluster number change frame containing its own unique code and the new cluster number is sent to the CAN bus, and the cluster numbers of the other nodes are obtained from the cluster number change frames sent by the other nodes.

[0014] In addition, to achieve the above objectives, the present invention also provides a battery pack including a microcontroller, a memory, and a computer program stored in the memory and running thereon, wherein the microcontroller is configured to execute the CAN bus-based distributed address allocation method as described in any one of claims 1 to 8.

[0015] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a computer program, which is loaded and executed by a processor to implement the distributed address allocation method based on the CAN bus as described in any one of claims 1 to 8.

[0016] The beneficial effects of this invention are as follows: No central controller is required throughout the process. Nodes autonomously establish their identities by acquiring their own unique codes; they trigger address contention and share their unique codes by sending a contention frame carrying their own unique codes via the CAN bus; they achieve autonomous identification between nodes by acquiring the unique codes of other nodes and marking the node status corresponding to the acquired unique codes as online—that is, they acquire the unique numbers of other nodes and complete the status archiving of other nodes within the system; and they determine the cluster numbers of all online nodes according to preset mapping rules, where nodes with specific cluster numbers are identified as hosts. The mapping rules and the codes of all online nodes... The associated steps enable autonomous determination of cluster number and master / slave identity. In summary, this embodiment avoids dependence on a central master controller. The entire process of address allocation and host selection is completed autonomously and collaboratively by the nodes, without any manual intervention in parameter configuration. This achieves fully automated operation of address allocation and host election. At the same time, it eliminates the hardware procurement, deployment, and cabling costs of the master controller, and eliminates the need for professional technicians to perform program debugging, parameter optimization, and troubleshooting, significantly reducing the system's operation and maintenance costs. In addition, the nodes follow a unified preset mapping rule to complete address allocation and master / slave determination, without the need to match a dedicated master / slave communication protocol, effectively reducing protocol adaptation complexity and significantly improving the system's compatibility and scalability. Attached Figure Description

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

[0018] To gain a more complete understanding of this application and its beneficial effects, the following description will be provided in conjunction with the accompanying drawings. In the following description, the same reference numerals denote the same parts.

[0019] Figure 1 This is a schematic diagram of a distributed address allocation method based on a CAN bus according to an embodiment of the present invention; Figure 2 This is a schematic diagram of some steps in a distributed address allocation method based on a CAN bus provided in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the steps of obtaining a unique code in a distributed address allocation method based on a CAN bus according to an embodiment of the present invention. Figure 4 A flowchart illustrating the steps of obtaining the unique encoding portion of the distributed address allocation method based on CAN bus provided in this embodiment of the invention; Figure 5 A schematic diagram of an overall system implementation environment provided for an embodiment of the present invention; Figure 6 This is a schematic diagram of a battery pack provided in an embodiment of the present invention. Detailed Implementation

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

[0021] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0022] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0023] Example 1: This embodiment is applied to nodes in a CAN bus distributed system. To facilitate communication between nodes, a communication protocol is pre-defined. The communication protocol in this embodiment is as follows: In practice, the communication protocol may take other forms, as long as it does not violate the implementation of this application.

[0024] Please refer to Figures 1-5 , Figure 1 A flowchart illustrating a distributed address allocation method based on a Controller Area Network (CAN) bus, provided as an embodiment of the present invention, is provided. The method can be applied to nodes in a CAN bus distributed system, and includes: Step S1: Obtain your own unique code.

[0025] In this application, the distributed system does not have a central master controller to uniformly allocate addresses. Each node has a unique code, which serves as the node's identity identifier. This ensures that all nodes can be identified during CAN bus broadcast communication, avoiding communication conflicts caused by identity confusion (such as the inability to trace the sender of data frames). At the same time, the unique code is also the basis for cluster number allocation, and the cluster number is the unique logical address identifier of the node in the distributed system.

[0026] To assign a unique cluster number to each node, the node needs to obtain its own unique code after power-on. In this embodiment, the unique code has global uniqueness and is a 4-byte (32-bit) node identifier. In specific implementations, it can also be other byte identifiers, such as 5 or 6 bytes. This application does not limit it.

[0027] Through step S1, each node completes the acquisition of its own unique code, providing a data foundation for subsequent cluster number allocation, master and slave determination, and global address synchronization.

[0028] Step S2: Send a contention frame carrying its own unique code via the CAN bus.

[0029] After a node powers on, it sends a contention frame to other nodes via the CAN bus. The frame ID is preset according to the aforementioned protocol, and the data field carries its own unique code. The purpose of this frame is to announce its access status to other nodes in the system and trigger address contention process steps S3-S4. Afterward, the newly powered-on node and other nodes on the CAN bus that received the contention frame enter the address contention process to allocate addresses. This frame can be configured to be sent only after the first power-on or after an offline restart to avoid repeated transmissions that occupy bus resources.

[0030] Through step S2, the newly powered-on node triggers the address contention process and shares its own unique code.

[0031] Step S3: Obtain the unique codes of other nodes and mark the nodes corresponding to the obtained unique codes as online.

[0032] After power-on, the node can also listen to messages sent by other nodes via the CAN bus. For example, it can listen to contention frames sent by other nodes via the CAN bus, and then obtain the unique code of the newly powered-on node by parsing the contention frames sent by other newly powered-on nodes, and record the status of the sending node as online. In one implementation, the node continuously listens to the bus and maintains a local online device table. The table has a record for each node, and each record contains at least the following fields: unique code, cluster number, last online timestamp, and node status. The node status includes at least two options: "online" and "offline". After obtaining its own unique code, the node records it in the online device table. Similarly, after obtaining the unique code of other nodes, the node records the unique code in the local online device table and synchronously updates the last online timestamp and node status of the corresponding node to online. When a node is determined to be offline, the status field in its record is updated to "offline". Since no cluster number has been assigned at this time, the cluster number information is temporarily recorded as empty.

[0033] Through step S3, the newly powered-on node obtains the unique number of other nodes and completes the status archiving of other nodes in the system, providing a data source for subsequent cluster number allocation and host determination.

[0034] Step S4: Determine the cluster number of all online nodes according to the preset mapping rules, wherein the node with a specific cluster number is determined as the host, and the mapping rules are associated with the encoding of all online nodes.

[0035] Through the aforementioned steps, the newly powered-on node has completed the acquisition of its own and other nodes' unique codes and the identification of their online status. Therefore, based on the unique codes of all online nodes and according to preset mapping rules, the cluster number of the node can be determined, and the node corresponding to a specific cluster number can be selected as the host. Preferably, based on the aforementioned implementation method, firstly, the unique codes of all online nodes are extracted from the local online device table. Then, the unique codes of all online nodes are sorted according to preset rules, such as sorting in ascending order of 32-bit unsigned integer values. Next, the cluster number of each node is determined based on the sorting result. Preferably, the unique code at the first position of the sort can correspond to cluster number 1, the second position to cluster number 2, and so on, forming a continuous and unique logical address. In specific implementations, other rules can also be used, such as assigning the unique code at the last position of the sort to cluster number 1, and the second-to-last position to cluster number 2, etc. This application does not limit this. Simultaneously, the node corresponding to a specific cluster number is designated as the master, and the remaining nodes are designated as slaves. For example, the node corresponding to cluster number 1 is designated as the master, and the remaining nodes are designated as slaves. After the cluster numbers are allocated, the newly allocated cluster number is compared with the original cluster numbers recorded in the local online device table (which was empty before cluster number allocation) to determine whether its own cluster number has changed. Since the original cluster numbers were empty during the initial allocation, all newly powered-on nodes are determined to have changed cluster numbers and immediately send a cluster number change frame containing their own unique code and the newly allocated cluster number to the CAN bus. Each node (including the newly powered-on nodes with changed cluster numbers) continuously listens to the bus. Upon receiving a cluster number change frame sent by another node, it parses it to obtain the new cluster number of the corresponding node and updates it to the local online device table, achieving synchronization of cluster number information across the entire system. At this point, the system completes the unified allocation of cluster numbers. Subsequently, each slave node operates collaboratively according to the master's instructions or preset logic, and the system enters the normal communication process.

[0036] Through step S4, the node completes the unified allocation of global cluster numbers and the division of master and slave nodes, thus building an orderly distributed communication architecture.

[0037] The beneficial effects of the CAN bus-based distributed address allocation method described in this embodiment are as follows: No central controller is required throughout the entire process. Step S1 enables nodes to autonomously establish their identities; step S2 triggers the address contention process and shares their unique codes; step S3 achieves autonomous identification between nodes, obtaining unique numbers from other nodes and archiving the status of other nodes within the system; and step S4 enables autonomous determination of cluster numbers and master / slave identities. In summary, this embodiment avoids dependence on a central master controller. The entire process of address allocation and master selection is completed autonomously and collaboratively by the nodes, without any manual intervention in parameter configuration, achieving fully automated operation of address allocation and master election. Simultaneously, it eliminates the hardware procurement, deployment, and wiring costs of the master controller, and eliminates the need for professional technicians to perform program debugging, parameter optimization, and troubleshooting, significantly reducing system maintenance costs. Furthermore, nodes follow unified preset mapping rules to complete address allocation and master / slave determination, eliminating the need for matching specific master / slave communication protocols, effectively reducing protocol adaptation complexity and significantly improving system compatibility and scalability.

[0038] In some implementations, reference Figure 5 The distributed address allocation method based on the CAN bus described in this embodiment also includes: Step S5. Periodically send heartbeat frames carrying its own unique code and cluster number to the CAN bus; In this embodiment, to achieve hot-swappable node functionality and ensure stable system operation when nodes are dynamically added or removed, after each node completes address allocation and enters the normal communication process, the node periodically sends a heartbeat frame carrying its own unique code and cluster number to the CAN bus. It can also carry other information, such as the node's liveness status identifier to indicate its liveness status. The frame ID is preset according to the protocol, and the preset period is preferably one heartbeat cycle (500ms), but it can also be other periods, such as two heartbeat cycles (1000ms). This application does not limit this.

[0039] When a new node powers on and connects to a normally operating system, the new node executes steps S1 to S4. First, it obtains its own unique code. Then, it sends a contention frame carrying its unique code via the CAN bus, triggering all system nodes to enter address contention process steps S3-S4 to reallocate addresses. The new node receives heartbeat frames from other online nodes on the bus and parses out the unique codes of those online nodes. Existing online nodes, having already obtained the unique codes of other existing online nodes in the previous address allocation round, do not need to repeatedly obtain each other's unique codes; they only need to parse the new node's contention frame to obtain its unique code. Subsequently, all nodes, based on a preset mapping rule associated with the online node codes, uniformly determine the cluster number of all currently online nodes and select the node corresponding to a specific cluster number as the host. Through this process, the system can complete new node access and automatic address architecture adaptation without interrupting operation, ensuring overall communication stability.

[0040] Through step S5, each node establishes a real-time monitoring mechanism for the status of other nodes, and provides support for the reallocation of addresses for new nodes joining the system and for subsequent offline node determination and address reallocation.

[0041] In some implementations, nodes maintain a local online device table, which records the unique code, cluster number, last online timestamp, and node status of all online nodes. After receiving a heartbeat frame from another node, the node can parse and extract the unique code and cluster number of the corresponding node, and update the last online timestamp of the node in the local online device table in real time. This forms a dynamic tracking and management of the operating status of all nodes. When a contention frame sent by a newly accessed node is received and the address contention process begins, the unique code of all online nodes can be extracted from the online device table to allocate cluster numbers and hosts to all online nodes.

[0042] Step S6. Monitor the heartbeat frame transmission status of other nodes. If no heartbeat frame is received from a certain node within a preset number of consecutive heartbeat cycles, record the node as an offline node and return to step S4 to reallocate the cluster number and host of all online nodes.

[0043] While sending its own heartbeat frame, the node continuously monitors the heartbeat frame transmission status of other nodes on the bus. The preset offline determination condition is "not receiving a heartbeat frame from a certain node for a preset number of consecutive heartbeat cycles". The number of consecutive cycles can be set according to system requirements (such as three or five heartbeat cycles), and this application does not limit it. When the offline determination condition is met, the node is marked as offline and the process returns to step S4. Based on the unique code of the currently online node, the cluster number allocation and host determination are re-executed.

[0044] Preferably, based on the aforementioned implementation, the node can also run a watchdog task to periodically inspect the local online device table, checking the last online timestamp of other nodes in the local online device table. The number of periods can be three heartbeat cycles (1500ms) or four heartbeat cycles (2000ms), etc., and this application does not limit this. If it is found that the difference between the last online timestamp of a node and the current system time exceeds a preset number of heartbeat cycles, such as three heartbeat cycles (1500ms), it is determined that the corresponding node has not sent a heartbeat frame for three consecutive heartbeat cycles and is in an offline or faulty state. Then, the node status is updated to offline in the local online device table, and then the process returns to step S4. Based on the updated online node information, the cluster number and host of all online nodes are reassigned, thereby realizing the dynamic self-organization and communication link self-healing of the system in the case of node offline or fault, ensuring the stability and fault tolerance of system operation.

[0045] Through step S6, the system achieves automatic identification and dynamic address reallocation of offline nodes, ensuring that the remaining nodes can still maintain an orderly communication architecture, thereby improving the fault tolerance and operational stability of the distributed system.

[0046] Through steps S5 and S6, the system establishes a real-time node status monitoring mechanism based on heartbeat frames. This not only supports seamless hot-plugging of new nodes but also automatically identifies offline nodes and triggers address reallocation, enabling dynamic self-organization and communication link self-healing of the system, thereby improving the system's fault tolerance and operational stability.

[0047] It should be noted that the reason why sending a contention frame carrying its own unique code triggers the address contention process for all nodes in the system is that other nodes receiving the contention frame will obtain the unique code by parsing the frame. If the new node has never been connected to the system before, other nodes have not yet obtained its unique code. After obtaining the unique code by parsing the contention frame, they can determine that it is a new node. If the node has been connected to the system before, other previously online nodes, although they have obtained the unique code, have been marked as offline because the node was offline. During the offline period, there is no heartbeat frame interaction, so they cannot obtain its status update. Therefore, when they parsing the contention frame, they can determine that it has come back online and that the number of online nodes in the system has changed. In either case, the entire system will enter the address contention process. Based on the aforementioned implementation method, after a new node sends a contention frame carrying its own unique code, other nodes parse the contention frame to obtain the unique code, compare the unique code with the local online device table, and will get the result that the unique code is new or the corresponding node is marked as offline, thus determining that a new node has joined and entering the address contention process.

[0048] To achieve time unification among nodes within the system, a time synchronization mechanism based on synchronization frames can be configured. After the system completes address allocation and operates stably, the host sends a synchronization frame to the CAN bus. The frame ID is preset according to the protocol, and the data field of the synchronization frame carries at least the host's system timestamp (such as a 64-bit Coordinated Universal Time (UTC) timestamp, accurate to the millisecond level). Other nodes continuously listen to the bus and receive the synchronization frames sent by the host. By parsing the synchronization frame, the host's system timestamp information is extracted, and then the host's time is synchronized. This completes the time unification calibration of all nodes, providing a unified time reference for core processes such as the periodic inspection of the watchdog task, the timed sending of heartbeat frames, and the timeout determination of offline nodes. This improves the timing coordination accuracy of the system and avoids misjudgment of status or delay in process triggering caused by node time asynchrony.

[0049] In some implementations, reference Figure 3 Step S1 further includes the following steps: Step S11: Power on and start the node.

[0050] Power-on is the process by which the core hardware of a node starts up and enters its initial working state. It is the physical starting point of all processes, waking up the node's built-in microcontroller unit (MCU), CAN controller, and other hardware from its power-off sleep state, in preparation for subsequent acquisition of unique codes and CAN communication initialization.

[0051] Step S12: The node completes CAN communication initialization.

[0052] The node configures the parameters of its CAN controller, transceiver, etc., including completing CAN communication initialization, bus baud rate (e.g., 500kbps), frame format (e.g., CAN2.0B extended frame, 29-bit ID), etc. After completion, the CAN communication function is enabled, and the node enters the state of being able to send and receive data frames, ensuring the normal transmission of subsequent data frames.

[0053] Step S13: Obtain the unique code pre-stored in the memory.

[0054] The node first obtains a pre-stored unique code from the memory. The memory is preferably non-volatile, meaning data is not lost after power failure and the unique code can be stored long-term, preventing duplicate generation of the unique code after a node restart. The node reads a pre-code from a designated address in the non-volatile memory. This code is written during the production phase and is generated based on information such as the production batch and node serial number, possessing global uniqueness. If the obtained code conforms to a preset format (e.g., a 32-bit unsigned integer, not all 0s or all 1s, etc.), it is directly used as the node's unique code.

[0055] Step S14: If a unique code is not obtained, a globally unique code is generated and stored in memory.

[0056] If a unique code cannot be obtained from the non-volatile memory, the code generation process is initiated to generate a unique code and store it in the non-volatile memory.

[0057] In some embodiments, reference Figure 4 The encoding generation process can be followed as follows: Step S141: Combine hardware features with a hardware random number generator to generate a unique code.

[0058] A unique code is generated by combining the node's hardware characteristics with a hardware random number generator. The hardware characteristics can be node-specific physical information (such as MCUID, CAN controller physical address segment). This information is fixed by the hardware manufacturer and is unique, and can be used as the "basic identifier segment" of the code. Then, a random number is generated using a hardware random number generator (HRNG) as the "random segment" of the code to further improve the uniqueness of the code and avoid coding conflicts caused by the duplication of hardware characteristics of different nodes. For example, a 32-bit unique code can be composed of a 24-bit MCU chip ID and an 8-bit hardware random number.

[0059] Step S142: Detect whether other nodes have the same unique code. If they do, regenerate the unique code and repeat the detection until the detection passes. To ensure that the generated code is globally unique across all online nodes and to avoid address allocation conflicts caused by code duplication, it is necessary to check whether the generated unique code is globally unique. In some implementations, nodes send a code detection frame to the CAN bus. The frame ID is preset according to the protocol, and its data field carries the newly generated unique code. Each node that receives the frame compares the unique code in the frame with its own unique code. If a node finds that the unique code matches its own, it will reply with a conflict response frame. The frame ID is preset according to the protocol. The node that sent the detection frame waits within a preset window period (e.g., 1000-2000ms). If a conflict response is received, it indicates that the code is duplicated. A new unique code is then regenerated, and the above detection steps are repeated until no conflict response frames are received after sending. In this case, the unique code is confirmed to be globally unique, and the detection passes. If no conflict response frame is received within the window period, the unique code is determined to be globally unique.

[0060] Step S143: Write the unique code that passed the detection into the memory.

[0061] To prevent the generated unique code from being lost and to avoid duplicate generation, the node can be reused directly when it is powered on again. The node writes the unique code that has passed the test into its memory.

[0062] In this embodiment, the principle of "pre-stored code priority and random generation as a fallback" is adopted: the unique code is obtained from the memory first, and if the acquisition fails, it is automatically generated. This reduces the overhead of repeated code verification, shortens the power-on startup time of the node, and adapts to scenarios such as new nodes joining the network and old nodes experiencing memory failure. No manual intervention is required, which reduces the system deployment and maintenance costs.

[0063] Example 2: like Figure 6 As shown, this application also provides a battery pack 40, which includes an MCU 401, a memory 402, a bus transceiver 403, and a bus controller 404.

[0064] The memory 402 is used to store programs, and the processor 401 is used to execute the programs stored in the memory 402. When the program stored in the memory 402 is executed by the MCU 401, the battery pack 40 executes the distributed address allocation method based on the CAN bus in Embodiment 1. The method includes: S1. Obtaining its own unique code; S2. Sending a competition frame carrying its own unique code through the CAN bus; S3. Obtaining the unique codes of other nodes and marking the node status corresponding to the obtained unique code as online; S4. Determining the cluster number of all online nodes according to a preset mapping rule, wherein the node with a specific cluster number is determined as the host, and the mapping rule is associated with the codes of all online nodes.

[0065] The CAN bus transceiver 403 is used to enable data communication between the battery pack 40 and the CAN bus; the CAN bus controller 404 is used to process the communication data, such as performing data parsing.

[0066] Furthermore, the logical instructions in the aforementioned memory 402 can be implemented as software functional units and, when sold or used as independent products, can be stored in several computer-readable storage media. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of any of the methods described in Embodiment 1 of the present invention. The aforementioned storage media include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and various other media capable of storing program code.

[0067] The above-mentioned product can execute any of the distributed address allocation methods based on CAN bus described in Embodiment 1, and has the corresponding beneficial effects of the method. For technical details not described in detail in this embodiment, please refer to the distributed address allocation method based on CAN bus provided in Embodiment 1 of the present invention.

[0068] Example 3: According to an embodiment of the present invention, a computer-readable storage medium is provided, the type of which is described in Embodiment 2. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the processor executes the steps of the distributed address allocation method based on the CAN bus described in Embodiment 1.

[0069] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general-purpose hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to enable a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments.

[0070] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A distributed address allocation method based on CAN bus, characterized in that, include: S1. Obtain its own unique code; S2. Send a contention frame carrying its own unique code via the CAN bus; S3. Obtain the unique code of other nodes and mark the node status corresponding to the obtained unique code as online; S4. Determine the cluster number of all online nodes according to the preset mapping rules, wherein the node with a specific cluster number is determined as the host, and the mapping rules are associated with the encoding of all online nodes.

2. The distributed address allocation method based on CAN bus as described in claim 1, characterized in that, The method further includes: S5. Periodically send heartbeat frames carrying its own unique code and cluster number to the CAN bus; S6. Monitor the heartbeat frame transmission status of other nodes. If a heartbeat frame of a certain node is not received within a preset number of consecutive heartbeat cycles, record the node status as offline and return to S4 to reallocate the cluster number and host of all online nodes.

3. The distributed address allocation method based on CAN bus as described in claim 2, characterized in that, The S5 also includes: Maintain a local online device table, which records the unique code, cluster number, last online timestamp, and node status of all online nodes; obtain the unique code and cluster number of other nodes from the heartbeat frames sent by other nodes, and update the last online timestamp and node status of the corresponding node in the local online device table to online accordingly.

4. The distributed address allocation method based on CAN bus as described in claim 3, characterized in that, S6 includes: Periodically check the last online timestamp of other nodes in the local online device table; If the difference between the current system time and the last online timestamp of a certain node exceeds a preset number of heartbeat cycles, the node is determined to be offline, and the node's status is updated to offline in the local online device table. Then, the process returns to step S4 to reallocate the cluster number and host of all online nodes.

5. The distributed address allocation method based on CAN bus as described in claim 1, characterized in that, The method further includes: The system receives a synchronization frame sent to the CAN bus by the host. The synchronization frame carries the host's system timestamp to synchronize the system time.

6. The distributed address allocation method based on CAN bus as described in claim 1, characterized in that, S1 includes: Retrieve the unique code pre-stored in memory; If a unique code is not obtained, a globally unique code is generated and stored in memory.

7. The distributed address allocation method based on CAN bus as described in claim 6, characterized in that, The step of generating a globally unique code and storing it in memory includes: A unique code is generated by combining hardware features with a hardware random number generator; Check if other nodes have the same unique code. If they do, regenerate the unique code and repeat the check until the check passes. Write the unique code that passes the detection into the memory.

8. The distributed address allocation method based on CAN bus as described in any one of claims 1-7, characterized in that, S4 includes: Sort all online nodes' unique codes according to preset rules; The cluster number and master of each node are determined based on the sorting results. The node corresponding to a specific cluster number is determined to be the master, and the remaining nodes are determined to be slaves. If the cluster number changes, a cluster number change frame containing its own unique code and the new cluster number is sent to the CAN bus, and the cluster numbers of the other nodes are obtained from the cluster number change frames sent by the other nodes.

9. A battery pack comprising a microcontroller, a memory, and a computer program stored in the memory and running thereon, characterized in that, The microcontroller is configured to execute the CAN bus-based distributed address allocation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the distributed address allocation method based on the CAN bus as described in any one of claims 1 to 8.

Images