Charging pile, charging pile system and charging pile control method

Abstract

The invention relates to the technical field of electric vehicle charging, and discloses a charging pile, a charging pile system and a control method of the charging pile. The system comprises a plurality of charging pile nodes, and each node comprises a communication module and a processing module. The nodes are connected through a peer-to-peer network, and each node is configured to receive charging task request data in the network; based on the self state and a preset decision logic, calculating an adaptation degree numerical value and comparing the adaptation degree numerical value with a reference value in the request to determine whether to attempt to undertake the task; broadcasting the decision through a delay response mechanism with a conflict coordination function; and if the task is successfully undertaken, the execution integrating degree is also periodically evaluated, and task migration is actively initiated when a numerical value is lower than a threshold value. According to the method, distributed matching and dynamic redistribution of the charging task under the condition of no central scheduler are realized, and the method can be used for improving the problems of a centralized system in the aspects of single-point dependence, expansion flexibility and response delay.

Description

Technical Field

[0001] This invention relates to the field of electric vehicle charging technology, and more specifically, to a charging pile, a charging pile system, and a control method for the charging pile. Background Technology

[0002] With the increasing prevalence of electric vehicles, the scale and complexity of charging network are growing daily. Efficient charging scheduling is crucial for improving user experience and grid stability. Currently, most common charging system control schemes adopt a centralized architecture, with a central control unit collecting global information and making unified scheduling decisions. This architecture has inherent drawbacks: the central server is prone to becoming a performance bottleneck and a single point of failure; the system has poor scalability, requiring reconfiguration of the central system when adding new nodes; and the communication delay from information collection and decision-making to command issuance is relatively long, making it difficult to cope with rapid changes in local states.

[0003] Existing technologies also contain some solutions that attempt to optimize scheduling or load balancing, but they still remain centralized or have other limitations. For example, Chinese patent CN118636726A discloses a scheme that uses a predictive model for fault detection and central scheduling of idle charging piles. Although this scheme introduces intelligent prediction, the generation and issuance of its scheduling instructions still rely on the central unit, failing to solve the fundamental problems of centralized architecture. Another example is Chinese patent CN116552308A, which discloses a three-phase balance control method for community charging piles based on hardware connection and current sampling. While this method ensures local grid balance, its control logic depends on specific hardware sampling units and line connections, making it a static and isolated solution that cannot achieve dynamic, intelligent coordination and global optimization of charging pile resources in large-scale networks.

[0004] Therefore, how to build a decentralized, scalable, and adaptive charging pile collaborative control system while ensuring reliability and real-time performance has become a problem to be solved in this field. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present invention provide a charging pile, a charging pile system and a control method for the charging pile, so as to solve the problems mentioned in the background art, specifically: the single-point dependency and scalability problems that may exist in the existing charging pile system control scheme, as well as the limited coordination capability.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a charging pile system, comprising multiple charging pile nodes. Each of the aforementioned charging pile nodes includes: The communication module is configured to establish a direct data connection with at least one other charging pile node for peer-to-peer information exchange between nodes. The processing module, electrically connected to the communication module, is used to execute decision logic and control commands; Each of the charging pile nodes is configured to perform the following collaborative process: The communication module receives task request messages from other charging pile nodes, and the task request message carries a first reference value. In response to receiving the task request message, the processing module determines whether to accept the task request based on a predetermined local decision logic and the current state of the charging pile node itself, and generates a local decision. This determination process is based on calculation and comparison. When the local decision instruction is requested, a task response message is sent through the communication module; In the charging pile system, the allocation of charging tasks is jointly determined by the collaborative process executed in parallel by each charging pile node based on the task request message and the local decision logic, thereby achieving decentralized task scheduling.

[0007] Furthermore, the local decision-making logic causes the processing module to execute: Based on the task requirement information and the status information of this node in the task request message, an evaluation value related to this node is determined. This evaluation value quantifies the degree of matching between this node and the task. The evaluation value is compared with the reference evaluation value carried in the task request message, which records the best evaluation value among the currently known competing nodes. Only when the evaluation value is better than the reference evaluation value, a local decision to apply for the task is generated, and the task response message carries the updated reference evaluation value, which is determined based on the evaluation value, so that subsequent nodes can know the new optimal value.

[0008] Furthermore, the local decision-making logic also causes the processing module to perform a conflict resolution check after generating the local decision indicating the application and before sending the task response message: Start a delay window whose duration is configured to be related to the evaluation value. The higher the evaluation value, the shorter the waiting time, so that better nodes tend to respond earlier. During the delay window, the communication module listens to whether it receives a task response message from other charging pile nodes for the same task request message; If received, the system compares its own determined evaluation value with the reference evaluation value carried in the received task response message. Only when its own evaluation value is better will the task response message be sent after the delay window ends. This mechanism helps to filter out the most suitable node in the network.

[0009] Furthermore, each of the charging pile nodes is also configured to perform dynamic task reallocation: During the successful application and execution of a charging task, the processing module periodically evaluates the suitability of continuing to execute the charging task based on the local decision logic. This evaluation is based on changes in the node's own state and changes in the network environment. When the evaluation result does not meet the preset conditions, the processing module generates a task migration decision and broadcasts a new task request message through the communication module. The new task request message corresponds to the charging task that is being executed, thereby reintegrating the task into the distributed allocation process.

[0010] Furthermore, the assessment of the adaptability to continue performing the charging task includes a quantification process: Get the current running parameters of this node; Calculate a continuous execution evaluation value based on the current operating parameters; The communication module obtains the expected evaluation value information of the charging task in the network, which reflects the potential ability of other nodes to perform the task. The evaluation result is generated based on the comparison between the continuous performance evaluation value and the expected evaluation value. If the evaluation value is significantly lower than the network expectation, migration is triggered.

[0011] Furthermore, the communication module is also configured to enable limited-range propagation of task requests: When the local decision instruction generated by the processing module does not claim the received task request message, if the task request message does not exceed the set propagation range, the task request message is forwarded so that the request can spread beyond the direct communication range of the initiating node in order to find a better service node.

[0012] A control method for a charging pile system, applied in a network consisting of multiple charging pile nodes, and executed on each charging pile node, the method comprising: Receiving steps: Receive task request messages propagating over the network; Decision-making steps: Based on the real-time status of this node and the predetermined node decision-making rules, independently judge the task request message and generate an application decision. The judgment includes calculating the local evaluation value and comparing it with the current best evaluation value carried in the message. Response steps: If the application decision indicates participation in the application, a task response message is sent to the network; Execution steps: If it is determined to be the final execution node of the task request message, then perform the corresponding charging operation; The final execution node of the task request message is dynamically determined by each charging pile node through the distributed interaction of the decision-making and response steps, based on the same node decision rules.

[0013] Furthermore, the decision-making process includes a clear competition and update mechanism: Calculate the local evaluation value of this node regarding the task request message; The local evaluation value is compared with the current best evaluation value recorded in the task request message; The response step is triggered only when the local evaluation value is better than the current best evaluation value, ensuring that only the better node will participate in the competition; The task response message sent contains an updated current optimal evaluation value, which is set as the local evaluation value of the sending node, thereby iteratively advancing the discovery of the optimal value on the network.

[0014] Furthermore, it also includes a task renegotiation step to optimize the migration of running tasks: During the process of providing charging services as the final execution node, monitor the state changes of this node; When a state change causes the evaluation of continuing to perform the charging service on this node to fall below the first threshold, the current service is suspended, and a new task request message corresponding to the current charging service is generated and broadcast to the network. The system monitors the network's response to the new task request message to transfer the charging service to a new execution node, thereby ensuring that the task is always executed by the node that is more suitable under the current conditions.

[0015] A charging station, configured to operate as a cooperative node in a charging station network, includes: A communication unit for peer-to-peer communication with at least one other charging station to exchange task requests and decision responses; The decision and control unit is connected to the communication unit; The decision and control unit is configured as follows: The communication unit is used to obtain charging task request information from the network. Based on the obtained charging task request information and the status of the charging pile itself, the system applies internal decision rules to autonomously generate a control command on whether to compete for the charging task. The decision rules include evaluation value calculation and comparison. The communication unit is operated according to the control command to send corresponding contention response information; Furthermore, during the execution of the charging task, based on the internal decision-making rules and status monitoring results, the system autonomously decides whether to initiate a reallocation process for the charging task, and initiates the reallocation process through the communication unit when the decision is made.

[0016] The technical effects and advantages of this invention are as follows: This invention achieves the following effects by enabling each charging pile node to execute preset decision logic based on local information in a peer-to-peer network: Distributed task allocation and dynamic adjustment are implemented: Each node calculates a quantified suitability value based on the received task request and its own real-time status (such as load rate and available power). The node only participates in the response if its suitability is higher than the current reference value carried in the request. The pre-response delay mechanism and conflict coordination function help filter nodes with higher suitability to undertake tasks within the network. For already running tasks, the undertaking node periodically calculates its suitability for continued execution, and when this value falls below a set threshold, it republishes the task as a new request, thereby migrating the task to a more suitable node. This process achieves self-organization of task allocation and dynamic re-optimization during operation.

[0017] The system's operational reliability is enhanced: It does not rely on a central scheduling unit, and the failure of a single node does not affect the independent decision-making and task processing capabilities of other nodes. Task requests can be forwarded through neighboring nodes, and running tasks can be transferred from nodes in poor condition through a migration mechanism. This allows the system to maintain basic functionality even in the event of partial failure. Inter-node collaboration relies on local decision-making and direct communication between neighboring nodes, and the system architecture reduces the possibility of widespread service interruption due to the failure of a single node.

[0018] The system's responsiveness and scalability are improved: task allocation decisions are made in parallel by each node, eliminating the need to wait for calculations and instructions from a remote central server, thus shortening the local processing time from request issuance to allocation completion. When a new node joins, it only needs to connect to the existing peer-to-peer network and follow the defined communication and decision-making rules to automatically participate in system collaboration, without requiring reconfiguration of the central controller or updating of global node information. This approach facilitates adding or removing nodes as needed. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the distributed allocation process for charging tasks according to the present invention; Figure 2 This is a schematic diagram of the node response conflict coordination process of the present invention; Figure 3 This is a structural diagram of the task request forwarding and diffusion mechanism of the present invention; Figure 4This is a schematic diagram of the runtime task dynamic migration triggering process of the present invention; Figure 5 This is a schematic diagram of the charging pile module structure of the present invention.

[0020] The attached diagram is labeled as follows: 100, communication module; 200, processing module. Detailed Implementation

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

[0022] Example 1 As attached Figures 1 to 5 As shown, this invention provides a charging pile system, control method, and charging pile. The technical solution is based on a distributed collaborative decision-making and task flow mechanism, enabling the charging pile network to achieve self-organization and operational optimization without a central scheduling unit. The implementation of the technical solution will be specifically described below with reference to an embodiment deployed in a large public charging station.

[0023] I. System Physical Structure, Network Formation, and Basic Interfaces The charging pile system in this embodiment consists of multiple charging pile nodes (hereinafter referred to as "nodes") that are physically distributed. Each node is a fully functional independent charging device, and its modular structure and interaction relationships are as follows: 1. Communication Module 100: This module is the hardware unit that implements peer-to-peer network communication. In this embodiment, an industrial-grade wireless communication unit supporting the Mesh Network protocol is used. After power-on, this module automatically executes a neighbor discovery procedure, connecting to neighbors with signal strength greater than a preset threshold (e.g., the Received Signal Strength Indicator (RSSI) is greater than a certain threshold). This threshold can be adjusted according to the actual deployment environment. to (Adjustments between them) and have already negotiated to establish a direct point-to-point wireless link with other nodes in the network.

[0024] Each node maintains a dynamic "neighbor node list" through its communication module 100. The list records the identifiers and link status of neighbor nodes that can communicate directly. The communication modules 100 of all nodes work together to form a multi-hop peer-to-peer network covering the entire site.

[0025] Data packets can be forwarded through intermediate nodes in this network. The transmission of data packets uses the User Datagram Protocol (UDP), whose connectionless and low-overhead characteristics make it suitable for broadcast and multicast communication. To support state awareness between nodes, nodes exchange basic information by periodically broadcasting lightweight state messages (containing their own identifier, load rate, available power, etc.).

[0026] 2. Processing Module 200: This module is the control unit of the node, employing a high-performance microcontroller with a built-in floating-point unit. Processing Module 200 is electrically connected to Communication Module 100 via a Serial Peripheral Interface (SPI), responsible for generating and parsing network data packets and executing defined decision logic. The processing module 200's built-in flash memory stores consistent program code for all nodes, including preset decision logic, matching rules, and various system constants. Each node maintains basic synchronization of its local clock through a simple network time synchronization mechanism to support distributed timing.

[0027] 3. Charging Execution Unit: This unit receives digital control commands from the processing module 200 and converts them into control signals for the power devices to complete the electrical energy conversion and transmission. Simultaneously, this unit feeds back the actual electrical parameters of the charging process to the processing module 200.

[0028] 4. State Sensing and Acquisition Unit: This unit includes a current sensor, voltage detection circuit, temperature sensor, etc. It continuously acquires the real-time physical state of the node, converts the analog signals into digital signals, and provides them to the processing module 200. The processing module 200 reads these signals and synthesizes them into local state parameters used for decision-making. These parameters include at least: Current load factor: A dimensionless scalar, calculated as current total output power / node rated power. Its range is [0, 1].

[0029] Real-time available power: A dimensional physical quantity, measured in kilowatts (kW), calculated as: node rated power - current total output power.

[0030] Interface occupancy status: Indicates whether the charging gun of this node has been connected to a vehicle and is in a service ready state.

[0031] II. Gradual Implementation of Collaborative Processes The following describes the collaborative process of the parallel execution of the 200 processing modules at each node, step by step, according to the life cycle of the charging task.

[0032] Step 1: Generating the task request and broadcasting the first hop Once an electric vehicle establishes a physical and communication connection with a node (denoted as node A) via a charging connector, node A's processing module 200 obtains the charging demand parameters for this charge from the vehicle's battery management system using the standard charging communication protocol. These parameters serve as inputs for subsequent decisions and include: Power demand The unit is kilowatt-hour (kWh).

[0033] Maximum charging power required The unit is kilowatt (kW).

[0034] Battery nominal voltage The unit is volt (V).

[0035] Subsequently, node A's processing module 200 creates a task request message. This is a structured message that is transmitted between nodes.

[0036] First, the processing module 200 generates a globally unique task identifier.

[0037] The method involves concatenating the "Media Access Control Address of Node A" with the "System Clock Millisecond Count Value of Processing Module 200" into a single string. Then, Message-Digest Algorithm 5 (MD5) is used to hash this string, and the first 64 bits of the resulting 128-bit hash value are used as the task identifier. This task identifier is used to uniquely identify the charging task throughout its entire lifecycle.

[0038] Next, the processing module 200 constructs a complete task request data packet, the meaning of each field and its initialization assignment are as follows: Task Identifier: The unique identifier generated above.

[0039] Charging requirement parameters: including the above , , Data such as...

[0040] First reference value Initialize to a set minimum value In this embodiment This field is the comparison benchmark.

[0041] Forwarding count value Initialize to .

[0042] Maximum forwarding count N: A preset system constant. In this embodiment, N=6. This parameter is used to limit the number of hops a task request can propagate through the network.

[0043] Timestamp: The absolute timestamp at which the data packet was created.

[0044] Node A's processing module 200 then sends this task request data to all nodes in its "neighbor node list" via its communication module 100 in the form of UDP broadcast.

[0045] After the broadcast is sent, node A itself will also process this message.

[0046] Step 2: Local contention decision-making of receiving nodes Upon receiving this UDP broadcast packet, the communication module 100 of any node in the network (denoted as node B) performs basic checks (such as data integrity checks). After confirming that the data packet format is correct and the task identifier is valid, it delivers the packet to the processing module 200. The processing module 200 then initiates its local decision loop. 1. Parsing and Status Synchronization: The processing module 200 parses the data packet and extracts the charging demand parameters and the current first reference value. (Assuming the value is 0.0 at this point). Simultaneously, the latest local status parameters, including the current load rate, are read from the status sensing unit. and available power .

[0047] 2. Execute matching rules and calculate fitness value: The processing module 200 calls its stored matching rule function, which is consistent across all nodes, to calculate a scalar value (fit value F) representing the degree of matching.

[0048] In this embodiment, the function is defined as follows: ; in: , : represents the preset weighting coefficient, and This embodiment sets , These coefficients can be configured during system deployment.

[0049] Current load rate of the node .

[0050] Power matching degree, calculated as follows: Its range is [0, 1]. The function ensures that it will not promise power beyond its capabilities.

[0051] Calculation example: Assume a node of , And task requirements .

[0052] but .

[0053] Substitute into the formula: .

[0054] node Calculated fitness value It is 0.5.

[0055] 3. Comparison and Decision Making: Processing module 200 will calculate the results... (0.5) and the task request data packet (0.0) is compared.

[0056] The pre-defined decision logic is: when At that time, node It is considered a valid candidate.

[0057] In this example, the condition 0.5 > 0.0 is met. Therefore, the processing module 200 of node B generates a first decision indicating a "response" and begins preparing the response data.

[0058] Preparing response data includes: (0.5) Assign a value to the reference value to be declared in an internal variable. And construct a response packet, in which the updated first reference value field will carry this .

[0059] Step 3: Distributed Conflict Coordination and Response Sending Before sending response data, to avoid multiple nodes responding simultaneously and to select a suitable node, node B enters the coordination phase: 1. Determine the coordination waiting time: Processing module 200 determines the time based on its own calculations. (Right now ), calculate transmission delay (Unit: milliseconds). This embodiment uses the following formula: ; in It is the preset maximum coordination delay, for example (This value can be adjusted according to the network environment).

[0060] calculate: .

[0061] node Start a time of The timer.

[0062] 2. Monitoring and Final Verification: In During the waiting period, the node The communication module 100 continuously listens to the wireless channel. If it receives response data from other nodes for the same task identifier during this period, it parses and extracts the updated first reference value (denoted as ). ).

[0063] node Will With the eavesdropping Compare.

[0064] The preset conflict coordination logic is as follows: Node Its response data is sent only if the following conditions are met: (a) its own timer expires; and (b) during the waiting period. Greater than all those detected value.

[0065] If no response is received before the timer expires, condition (b) is automatically satisfied, and the node... Send response data after the timer expires.

[0066] Assuming nodes Hearing the node while waiting The response, its .because Condition (b) is not satisfied, node Sending will be cancelled after the timer expires.

[0067] Step 4: Task confirmation, execution, and request forwarding mechanism Task confirmation and charging start: Initiating node After broadcasting the request, start a global response timeout timer (e.g., It performs validity checks on the received response data (checking task identifier matching, data integrity, etc.).

[0068] The first response data that passes the judgment is accepted. Node The processing module 200 then sends a request to the response node (assuming it is a node). Send a "task confirmation" command. Node After receiving confirmation, the processing module 200 becomes the final execution node of the task and sends a "start charging" command to the charging execution unit.

[0069] Request forwarding mechanism: For the calculation in step two For nodes that are not currently the best, their processing module 200 does not generate a response, but checks the forwarding count value in the request data. .

[0070] if (This example) If ), then the node will The value is incremented by 1, and the modified task request data packet is rebroadcast through the communication module 100.

[0071] if If the node discards the data packet, it will no longer forward it.

[0072] This mechanism enables task requests to be distributed in a controlled manner across the network.

[0073] Step 5: Dynamic Task Migration During Runtime During the execution of the charging task, the final execution node (assuming it is a node) The processing module 200 periodically (e.g., every...) Assess the necessity of retaining the task.

[0074] 1. Calculate the current execution fit value: node The processing module 200 calculates the current execution fit value. .

[0075] A feasible calculation formula is as follows: ; in: , Preset migration assessment weighting coefficients, for example , .

[0076] :node Instantaneous load rate at the time of evaluation.

[0077] :node The status summary (including load rate and available power) of each neighboring node is obtained through the communication module 100.

[0078] Then, the processing module 200 of node C substitutes the charging requirement parameters of this task into the state data of each neighboring node, uses the same matching rule function as in step two to calculate the fitness value that each neighboring node might obtain if it takes over this task, and takes the maximum value. This process is a local estimation.

[0079] A very small positive constant, for example This is used to prevent the denominator from being zero.

[0080] Calculation example: Assume a node current The estimated .

[0081] but .

[0082] 2. Migration Determination: Processing module 200 will... (0.630) and a predetermined migration threshold Compare. It is a system preset constant, such as 0.70.

[0083] The migration trigger condition is: .

[0084] In this example, the condition 0.630 < 0.70 is true.

[0085] 3. Trigger the migration process: Once the conditions are met, the node... The processing module 200 performs the following operations: a. Send a "pause charging" command to the charging execution unit. This command controls the charging unit to stop outputting according to safety specifications and notifies the vehicle battery management system to enter standby mode.

[0086] b. Based on the original charging requirement parameters of this task, generate a new task request data. The task identifier of this new data can be associated with the original task and the first reference value. Reset to (0.0), the forwarding count value H is reset to .

[0087] c. Broadcast this new request via communication module 100.

[0088] This operation causes the task to be republished to the network. Nodes in the network will, based on their current state, determine a new execution node through the aforementioned competitive decision-making process. Once confirmed, the processing module 200 of the new final execution node will either continue or restart the charging process from the pause point.

[0089] The foregoing detailed description of the specific implementation methods, data flow processes, and logical judgment details of each technical feature in the claims of this invention. The charging pile system in this embodiment, through peer-to-peer communication between nodes, unified local decision-making logic (including matching degree calculation, conflict coordination, and migration evaluation), and the resulting autonomous behaviors (broadcasting, responding, forwarding, and migrating), realizes a distributed charging task allocation and operation optimization method.

[0090] Specifically, the charging pile in this embodiment is configured to execute the above-mentioned steps S11 to S16, S71 to S711, etc., through its communication module 100, processing module 200 and stored corresponding programs, thereby becoming a node that can operate collaboratively in a decentralized network.

[0091] Those skilled in the art can implement the charging pile system, control method, and charging pile described in this invention based on this description.

[0092] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change. Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A charging pile system, characterized in that, It includes multiple charging pile nodes, wherein each of the charging pile nodes includes: Communication module (100) for establishing a direct data connection with at least one other charging pile node; The processing module (200) is electrically connected to the communication module (100); Each of the aforementioned charging pile nodes is configured to perform: S11: Receive task request data containing charging demand parameters through the communication module (100), wherein the task request data carries a first reference value; S12: In response to the received task request data, the processing module (200) determines whether to respond to the task request data based on the currently acquired local status parameters and preset decision logic, and generates a first decision result; S13: When the first decision result indicates a response, response data containing a confirmation identifier is sent through the communication module (100); The multiple charging pile nodes coordinate to complete the allocation of charging tasks in a distributed manner through their respective parallel execution of S11, S12 and S13.

2. The charging pile system according to claim 1, characterized in that, When the processing module (200) executes S12, it is specifically configured as follows: S121: Calculate an adaptation value based on the charging demand parameter in the task request data and the local status parameter; S122: Compare the calculated fit value with the first reference value carried in the task request data; S123: A first decision result indicating the response is generated only when the comparison result is that the fit value is greater than the first reference value; The response data sent in S13 includes an updated first reference value, which is equal to the calculated fit value.

3. The charging pile system according to claim 2, characterized in that, After executing S123 to generate the first decision result of the indication response, the processing module (200) is further configured to execute, before executing S13: S124: Before sending the response data, start a delay timer, the duration of which is a non-negative time value determined based on the fit degree value; S125: During the operation of the delay timer, the communication module (100) listens to whether response data for the same task request data is received from other charging pile nodes; S126: If detected, extract the updated first reference value contained in the response data and compare it with the fitness value calculated by itself. Only when the fitness value of itself is greater than the extracted updated first reference value will S13 be executed after the delay timer ends.

4. The charging pile system according to claim 1, characterized in that, Each of the aforementioned charging pile nodes is also configured to perform: S14: When a charging task is successfully undertaken and is being executed based on the response data, the processing module (200) periodically calculates a current execution fit value according to the preset decision logic. S15: Compare the current execution fit value with a predetermined migration threshold; S16: When the comparison result is that the current execution fit value is less than the migration threshold, a migration instruction is generated and a new task request data is broadcast through the communication module (100), the new task request data corresponding to the charging task being executed.

5. The charging pile system according to claim 4, characterized in that, The calculation of the current execution fit value in S14 is based on the real-time load rate of the charging pile node at the calculation time, and the estimated fit information of the neighboring charging pile nodes to the charging task being executed, obtained through the communication module (100).

6. The charging pile system according to claim 1, characterized in that, The communication module (100) is further configured to, when the first decision result generated by S12 indicates no response, if the forwarding count value carried in the task request data is less than a preset maximum forwarding number N, where N is a positive integer, then increment the forwarding count value by 1 and forward the modified task request data to at least one preset peer charging pile node.

7. A control method for a charging pile, characterized in that, Applied to any charging pile node in the charging pile system according to any one of claims 1 to 6, the method is executed by the processing module (200) of the charging pile node, and includes: S71: Analyze the task request data received through the communication module (100) to obtain the charging demand parameters and the first reference value carried therein; S72: Obtain the local status parameters of the charging pile node; S73: Based on the charging demand parameters, the local status parameters, and the preset matching rules, calculate the compatibility value of the charging pile node with the task request data; S74: Compare the calculated fit value with the first reference value; S75: If the fit value is greater than the first reference value, a response instruction is generated and response data is sent through the communication module (100). The response data includes an updated first reference value, which is equal to the fit value.

8. The control method for a charging pile according to claim 7, characterized in that, After S75 generates the response command and before sending the response data, the following is also included: S76: Wait for a coordination time window that is dynamically determined based on the fitness value; S77: Within the coordination time window, if response data sent by other charging pile nodes for the same task request data is detected, the updated first reference value carried by it is compared with its own adaptation value. S78: The response data is sent only after the coordination time window ends, provided that the self-fitness value is greater than the first reference value after all updates are monitored.

9. The control method for a charging pile according to claim 7, characterized in that, Also includes: S79: During the execution of a charging task, periodically calculate a current execution fit value; S710: Compare the current execution fit value with a predetermined migration threshold; S711: When the current execution fit value is less than the migration threshold, pause the current charging task and generate a new task request data for broadcast.

10. A charging pile, characterized in that, Configured as a charging pile node in the charging pile system of any one of claims 1 to 6, it includes a communication module (100) and a processing module (200), and is configured to perform the control method of any one of claims 7 to 9.

Images