Electronic price tag display driving method and system, storage medium and program product

Abstract

The invention discloses an electronic price tag display driving method and system, a storage medium and a program product, and the method comprises the steps: obtaining data updating records of a plurality of electronic price tags in a preset time period; performing spatial density analysis on the data updating event of each electronic price tag based on the data updating record to obtain one or more high-density data updating areas; determining a plurality of data distribution nodes at a preset core position in the high-density data updating area, and determining a service range of the plurality of data distribution nodes based on the range of the high-density data updating area; and in response to a received data updating request of the electronic price tag, selecting the data distribution node with the service range covering the position information corresponding to the electronic price tag sending the data updating request and having the optimal preset route as a target node, and enabling the target node to execute the data updating request. The method and the device are used for improving the data processing capability in the local peak period, so that the timeliness of price updating is improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of electronic price tag display driving, and particularly relates to an electronic price tag display driving method and system, a storage medium and a program product. BACKGROUND

[0002] In the retail industry, the display driving performance of the electronic price tag system directly affects the timeliness and accuracy of commodity information updating. Due to the large number of electronic price tags and their wide distribution, the traditional centralized server architecture often has problems such as heavy server load and large response delay when processing a large number of display update requests of electronic price tags, which not only reduces the price updating efficiency, but also may cause display abnormalities.

[0003] In related technologies, an edge computing node can be introduced as an intermediate layer in the electronic price tag display driving system. By setting an edge computing node with data caching and logical processing capabilities between the server and the electronic price tag, local caching and fast response of data are realized. The edge computing node is responsible for receiving and caching commodity information and price data from the server, so that the electronic price tag can directly obtain the latest data from the connected edge computing node, and the edge computing node will periodically synchronize with the server to update the locally cached data.

[0004] However, in the context of a chain convenience store, electronic price tags in different regions within the same period often exhibit different data update frequencies and traffic characteristics. For example, the price adjustment frequency in the delicatessen area during the meal peak period is significantly higher than that in other areas, while the beverage area has more concentrated price update needs when the weather changes. The above edge computing node adopts a unified data distribution strategy, which is difficult to optimize resource scheduling according to the actual data traffic characteristics of electronic price tags in different regions, and may cause data processing queuing delays in local peak periods, reducing the timeliness of price updates. SUMMARY

[0005] The application provides an electronic price tag display driving method, system, storage medium and program product for improving the data processing capacity in local peak periods and thus improving the timeliness of price updates.

[0006] In a first aspect, the application provides an electronic price tag display driving method, which obtains data update records of a plurality of electronic price tags within a preset time period, the data update records including the location information and data update amount of each electronic price tag. Based on the data update records, spatial density analysis is performed on the data update events of each electronic price tag to obtain one or more high-density data update regions. A plurality of data distribution nodes are determined at a preset core position in the high-density data update region, and the service range of the plurality of data distribution nodes is determined based on the range of the high-density data update region. In response to receiving the data update request of the electronic price tag, a data distribution node having the optimal preset route and covering the location information corresponding to the electronic price tag sending the data update request is selected as a target node, and the target node is caused to execute the data update request.

[0007] By using the above technical solution, the data update records of the electronic price tags are obtained and spatial density analysis is performed, so that the areas with frequent data updates can be identified, and the data distribution nodes are deployed at the core positions of the high-density areas. The positions of the data distribution nodes are close to the actual business needs, and the data transmission distance is reduced. When the electronic price tag sends a data update request, the system selects a node covering the location of the price tag and having the optimal route to process the request. This node deployment and intelligent scheduling method based on the actual business characteristics enables the data update request to be processed nearby, reduces the network transmission overhead. At the same time, since the data distribution nodes are more reasonably distributed, network congestion caused by traditional centralized deployment is avoided, and the data update efficiency of the entire system is improved. This scheme dynamically perceives the business characteristics and makes corresponding deployment adjustments, improves the data processing capacity in local peak periods, and further improves the timeliness of price updates.

[0008] In some embodiments of the first aspect, the spatial density analysis of the data update events of each electronic price tag based on the data update records obtains one or more high-density data update areas, specifically comprising: dividing the preset area into a plurality of grid units, each grid unit having a preset area; calculating a data update density value in each grid unit, the data update density value being equal to the sum of the data update amounts of all electronic price tags in the grid unit in a preset time period divided by the preset area; combining the continuous grid units with data update density values greater than a preset density threshold into a high-density data update area.

[0009] By using the above technical solution, the system can accurately identify the range of the area in the data update request set by combining the continuous grid units with data update density values greater than the preset threshold into a high-density data update area. Since each grid unit has an equal area, the calculated density values are comparable, so that the data update activity levels between different areas can be uniformly measured and compared, and the accuracy of node deployment is improved.

[0010] In some embodiments of the first aspect, the data distribution node having the optimal preset route and covering the location information corresponding to the electronic price tag sending the data update request is selected as the target node, specifically comprising: The screening service covers candidate data distribution nodes of the electronic price tag position, and obtains a current processing load value of each candidate data distribution node; The physical distance of the electronic price tag to each candidate data distribution node is calculated, and the network device forwarding times required for the electronic price tag to reach each candidate data distribution node through the network device are obtained, to obtain network topology hops; Based on a preset time window, the real-time routing cost of each candidate data distribution node is calculated, and the real-time routing cost is equal to the sum of the transmission delay obtained by dividing the physical distance by the preset transmission rate, the forwarding delay obtained by multiplying the network topology hops by the preset single-hop delay, and the processing delay corresponding to the current processing load value; The candidate data distribution node with the smallest real-time routing cost is selected as the target node.

[0011] By adopting the above technical solution, the physical distance reflects the actual transmission path length, the network topology hops reflect the number of network devices through which data is transmitted, and the processing load value indicates the current processing capability state of the node. These factors are converted into time delays and summed to obtain the real-time routing cost, so that the node selection process can balance the transmission efficiency and processing capability. Selecting the node with the smallest real-time routing cost as the target node can improve the data transmission efficiency while balancing the node load.

[0012] In combination with some embodiments of the first aspect, in some embodiments, a plurality of data distribution nodes are determined at preset core positions in the high-density data update area, specifically including: The high-density data update area is subjected to cluster analysis to obtain data update hotspots; The center of gravity position of each data update hotspot is calculated, and the center of gravity position is taken as the preset core position; The number of data distribution nodes deployed at the preset core position is determined based on the number of electronic price tags of the data update hotspots, to obtain a plurality of data distribution nodes.

[0013] By adopting the above technical solution, the data update hotspots are obtained by cluster analysis of the high-density data update area, and the deployment positions of the data distribution nodes are determined by calculating the center of gravity positions of the hotspots, so that the node positions are closer to the actual business distribution. The number of nodes is determined based on the number of electronic price tags of the data update hotspots, so as to ensure that the node scale matches the actual business demand. By deploying the nodes at the center of gravity positions of the hotspots, the overall data transmission distance can be reduced. The number of nodes is determined according to the number of electronic price tags, so as to ensure sufficient processing capability and realize reasonable allocation of system resources.

[0014] In combination with some embodiments of the first aspect, in some embodiments, before causing the target node to execute the data update request, the method further includes: Get the timestamp of the data update request and the data version number; Determine if the target node is currently processing a historical data update request from an electronic price tag; If so, compare the data version number of the data update request with the data version number of the historical data update request; If the data version number of the data update request is greater than the data version number of the historical data update request, then the processing of the historical data update request will be terminated, and the data update request will be inserted into the first position of the processing queue of the target node. If the data version number of the data update request is not greater than the data version number of the historical data update request, then the data update request is discarded; If not, the data update requests are inserted into the target node's processing queue in the order of the request sending timestamps.

[0015] By employing the above technical solution, and by obtaining the sending timestamp and data version number of the data update request and comparing them with the historical data update requests currently being processed, the system can identify the latest data update request. When the data version number of the new request is higher, the system will terminate the processing of the old version of the historical request and insert the new request at the head of the processing queue, thereby avoiding the processing of outdated data and reducing the waste of system resources. For data update requests with version numbers no higher than the historical requests, the system will directly discard them to prevent the duplicate processing of the same version of data. When the target node has no historical requests being processed, the system inserts them into the processing queue in the order of the request sending timestamps, improving the timeliness of data updates. This processing mechanism ensures that the system always uses the latest data version, improving the timeliness and accuracy of the data. At the same time, through reasonable queue management and request filtering, it improves system processing efficiency and reduces system resource consumption.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after causing the target node to execute a data update request, the method further includes: Monitor the real-time processing load of each data distribution node; When the real-time processing load of the target node is detected to exceed the preset load threshold, the real-time processing load of other data distribution nodes other than the target node is obtained. The service area of ​​the target node is divided into multiple sub-regions of equal area, and the number of electronic price tags in each sub-region is calculated. Select adjacent data distribution nodes in order of increasing real-time processing load, and assign the sub-regions to the selected data distribution nodes in turn until the real-time processing load of the target node is reduced to below the preset load threshold. When the real-time processing load of the target node drops below a preset load threshold, the sub-region is reassigned to the target node.

[0017] By adopting the above technical solution and monitoring the processing load of data distribution nodes in real time, the system can promptly identify nodes with excessive load. When the load of a target node exceeds a preset threshold, the system divides its service area into equal-area sub-regions and calculates the number of electronic price tags in each sub-region, achieving refined management of the service area. Based on the real-time processing load of other nodes, the system selects adjacent nodes in ascending order of load and sequentially allocates the sub-regions to these nodes until the target node's load drops below the threshold. When the target node's load returns to normal, the system reassigns the sub-regions to the target node, achieving dynamic adjustment of the service area. This load balancing mechanism enables the system to automatically distribute tasks when a node's load is too high, improving system reliability.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, adjacent data distribution nodes are selected in ascending order of other real-time processing loads, and sub-regions are sequentially allocated to the selected data distribution nodes, specifically including: The other real-time processing loads are sorted in ascending order among the adjacent data distribution nodes to obtain the first sorting result; Sort the electronic price tags in the sub-regions in descending order of quantity to obtain the second sorting result; Based on the first and second sorting results, the sub-region with the most electronic price tags is assigned to the other data distribution nodes with the lowest real-time processing load. Calculate the real-time processing load of the target node. If the real-time processing load is higher than the preset load threshold, continue to allocate the next sub-region to other data distribution nodes with the second lowest real-time processing load, until the real-time processing load of the target node is reduced to below the preset load threshold.

[0019] By adopting the above technical solution, the sub-region with the largest number of electronic price tags is preferentially assigned to the node with the lowest real-time processing load. This allocation strategy ensures that the heavily loaded sub-regions are assigned to the nodes with the most sufficient processing capacity. The system continuously calculates the real-time processing load of the target node, and if the load is still too high, it continues to assign the next sub-region to the node with the second lowest load, until the load of the target node drops below the threshold. This achieves optimal allocation of system load, improves system resource utilization efficiency, enhances the timeliness of data update processing, and improves the overall performance of the system.

[0020] In a second aspect, embodiments of this application provide an electronic price tag display driving system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to execute the method described in any possible implementation of the first aspect.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application provides an electronic price tag display driving method. It acquires data update records from electronic price tags and performs spatial density analysis to identify areas with frequent data updates. Data distribution nodes are then deployed at core locations within these high-density areas. The location of these data distribution nodes closely aligns with actual business needs, reducing data transmission distance. When an electronic price tag sends a data update request, the system selects a node covering the price tag's location with the optimal route to process the request. This node deployment and intelligent scheduling method, based on actual business characteristics, ensures that data update requests are processed locally, reducing network transmission overhead. Furthermore, the more rational distribution of data distribution nodes avoids network congestion caused by traditional centralized deployments, improving the overall data update efficiency of the system. This scheme, which dynamically senses business characteristics and makes corresponding deployment adjustments, enhances data processing capabilities during local peak periods, thereby improving the timeliness of price updates.

[0024] 2. This application provides an electronic price tag display driving method. By obtaining the sending timestamp and data version number of a data update request and comparing them with historical data update requests currently being processed, the system can identify the latest data update request. When the data version number of the new request is higher, the system will terminate the processing of the old version of the historical request and insert the new request at the head of the processing queue, thereby avoiding the processing of outdated data and reducing the waste of system resources. For data update requests with version numbers no higher than those of historical requests, the system will directly discard them to prevent the duplicate processing of the same version of data. When the target node has no historical requests being processed, the system inserts them into the processing queue according to the order of the request sending timestamps, improving the timeliness of data updates. This processing mechanism ensures that the system always uses the latest data version, improving the timeliness and accuracy of the data. At the same time, through reasonable queue management and request filtering, it improves system processing efficiency and reduces system resource consumption.

[0025] 3. This application provides an electronic price tag display driving method. By monitoring the processing load of data distribution nodes in real time, the system can promptly identify nodes with excessive load. When the load of a target node exceeds a preset threshold, the system divides its service area into equal-area sub-regions and calculates the number of electronic price tags in each sub-region, achieving refined management of the service area. Based on the real-time processing load of other nodes, the system selects adjacent nodes in ascending order of load and sequentially allocates the sub-regions to these nodes until the target node's load drops below the threshold. When the target node's load returns to normal, the system reassigns the sub-regions to the target node, achieving dynamic adjustment of the service area. This load balancing mechanism enables the system to automatically distribute tasks when node load is too high, improving system reliability. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating an electronic price tag display driving method in an embodiment of this application.

[0027] Figure 2 This is another flowchart illustrating an electronic price tag display driving method in an embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the physical device structure of an electronic price tag display driving system provided in an embodiment of this application. Detailed Implementation

[0029] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0030] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0031] The following example is used in conjunction with Figure 1 The present application describes an electronic price tag display driving method in its embodiments: Please see Figure 1 This is a flowchart illustrating an electronic price tag display driving method in an embodiment of this application.

[0032] S101. Obtain data update records of multiple electronic price tags within a preset time period; The system acquires data update records for multiple electronic shelf labels within a preset time period. These records include the location information and update volume for each label. Location information can be the label's coordinates within the shopping mall or supermarket, or information representing its spatial location such as the shelf number. The update volume can be the number of price changes within the preset time period, or the cumulative value of price changes, or other indicators representing the frequency of data updates. The preset time period can be flexibly set according to the actual application scenario, such as one day, one week, or one month; no limitation is imposed here.

[0033] There are several ways to implement the system's acquisition of data update records. Firstly, the system can record update events in real time each time an electronic shelf label is updated, and associate these events with the label's location information for storage, then summarize and statistically analyze the data at the end of a preset time period. Secondly, the system can periodically retrieve data update logs from the electronic shelf labels over a certain period. These logs contain the timestamps and update amounts for each update event, which are then matched with the shelf label's location information to obtain a complete data update record.

[0034] To further improve the accuracy of data update records, the system can set a dedicated counter on the electronic price tag to accumulate the amount of data updates over a period of time. When data update records are needed, the system only needs to read the counter value of each electronic price tag and then clear the counter to zero. This allows for accurate and efficient acquisition of the required data update information without the need for frequent recording or fetching of log data, thus reducing system overhead.

[0035] S102. Based on the data update records, perform spatial density analysis on the data update events of each electronic price tag to obtain one or more high-density data update areas; The system performs spatial density analysis on the data update events of each electronic price tag based on data update records, obtaining one or more high-density data update regions. Specifically, a preset region is divided into multiple grid cells, each with a preset area; the data update density value within each grid cell is calculated, which is equal to the sum of the data update amounts of all electronic price tags in the grid cell within a preset time period divided by the preset area; consecutive grid cells with data update density values ​​greater than a preset density threshold are combined into high-density data update regions. The preset density threshold can be flexibly set according to actual conditions to identify the regions with the most frequent data updates; it is not limited here. First, the preset area is divided into multiple grid units, each with a preset area. This preset area can be the entire floor plan of a shopping mall, supermarket, or warehouse. The preset area can be set according to the actual application scenario, such as 10 square meters, 20 square meters, etc., without limitation here. Second, the data update density value within each grid unit is calculated. The data update density value is equal to the sum of the data update amounts of all electronic price tags in the grid unit within a preset time period divided by the preset area. The data update amount can be the number of updates, the size of the update data packet, or a weighted combination of the two, without limitation here. Finally, consecutive grid units with data update density values ​​greater than a preset density threshold are combined into a high-density data update area. The preset density threshold can be dynamically adjusted based on historical data statistics or business needs. The determination of consecutive grid units can be based on four-neighbor or eight-neighbor connectivity, without limitation here.

[0036] This step can be achieved using a density analysis method based on a regular grid. The system first establishes a coordinate system, dividing the entire monitoring area into rectangular grids of a fixed size (e.g., 5m x 5m). For each grid, the system iterates through the location information of all electronic price tags, determining whether they fall within the current grid's area. If an electronic price tag is within the grid, its data update volume within a preset time period is added to the total update volume of that grid. After completing the statistics for all grids, the system calculates the density value (total update volume / grid area) for each grid. Next, the system uses a depth-first search or breadth-first search algorithm, starting with grids whose density values ​​exceed a threshold, to search for all adjacent high-density grids, merging them into a continuous high-density region.

[0037] The system can also employ an analysis method based on kernel density estimation. The system uses the kernel density estimation (KDE) algorithm to smooth the spatial distribution of electronic price tags. Specifically, the system sets a kernel function (such as a Gaussian kernel) for each electronic price tag location, and the bandwidth of the kernel function is adaptively adjusted according to the sparsity of the price tag distribution. The system sets sampling points throughout the entire area and calculates the density value at each sampling point. This density value is the sum of the products of the kernel function values ​​contributed by all electronic price tags to that point and their data update amounts. By extracting contour lines from the density field, the system can identify the boundaries of regions where the density values ​​exceed a threshold, thus obtaining high-density data update areas.

[0038] When performing spatial density analysis, the classification of electronic price tags at grid boundaries may be ambiguous, leading to discrepancies in density calculations between adjacent grids. The system can address this issue using an overlapping grid strategy: based on the original grid division, the system creates an additional set of auxiliary grids offset by half a grid cell, ensuring that each electronic price tag is completely covered by at least two grids. The system calculates the density values ​​of the main grid and the auxiliary grids separately. For boundary regions, the system selects the grid with the highest density value among all grids containing that region as the representative density for that region. When determining high-density regions, the system comprehensively considers the analysis results of the main grid and the auxiliary grids. If a region is identified as high-density in any grid system, it is included in the final high-density data update area.

[0039] S103. Determine several data distribution nodes at a preset core location within the high-density data update area, and determine the service range of several data distribution nodes based on the extent of the high-density data update area. The system determines several data distribution nodes at preset core locations within a high-density data update area. Specifically, this includes: performing cluster analysis on the high-density data update area to obtain data update hotspots; calculating the centroid location of each data update hotspot and using this centroid location as the preset core location; determining the number of data distribution nodes deployed at the preset core location based on the number of electronic price tags at each data update hotspot, resulting in several data distribution nodes. The service range of these data distribution nodes is then determined based on the extent of the high-density data update area. For location determination, the system first performs cluster analysis on the high-density data update area to obtain data update hotspots. The clustering algorithm can be K-means, DBSCAN, or hierarchical clustering, etc., and is not limited here. Then, it calculates the centroid location of each data update hotspot. The centroid calculation can be based on a weighted average of the geographical coordinates of the electronic price tags, with the weights being either the data update volume or update frequency, and is not limited here. This centroid location is used as the preset core location. Finally, based on the number of electronic price tags at each data update hotspot, it determines the number of data distribution nodes deployed at the preset core location. The number of nodes can be determined considering factors such as single-node processing capacity and redundancy backup requirements, and is not limited here. To determine the service range, the system needs to divide the coverage area of ​​each node based on the geometry and size of the high-density data update area and the service capacity of the nodes. The division principle can be to minimize the service distance, balance the load, or ensure the quality of service, etc., which is not limited here.

[0040] This step can be achieved using a node deployment method based on K-means clustering. The system first collects the location coordinates and data update volume information of all electronic shelf labels within the high-density area. Based on business requirements, a pre-defined number of clusters K (i.e., the expected number of nodes to be deployed) is set. The system then executes the K-means clustering algorithm: K electronic shelf label locations are randomly selected as initial cluster centers; the Euclidean distance from each electronic shelf label to each cluster center is calculated, and the labels are assigned to the nearest cluster; for each cluster, the system calculates the weighted center of gravity (weighted by data update volume) of all member shelf label locations and updates the cluster centers; this assignment and update process is repeated until convergence. The final cluster centers are the deployment locations of the data distribution nodes. For the service area, the system uses the Voronoi diagram method, with each node location as a seed point, dividing the entire area into multiple polygonal units. Within each polygon, the distance from all points to their seed point is less than the distance to other seed points.

[0041] The system can also employ a density peak-based node deployment method. The system constructs a density distribution map of electronic price tags and uses the Density Peak Clustering (DPC) algorithm to identify data update hotspots. The system calculates the local density of each price tag (the product of the number of neighboring price tags within radius r and their data update volume) and the minimum distance to higher density points. Points with both high density and large distance are identified as cluster centers. Based on the number of price tags included in each cluster and the total data update volume, the system determines the number of nodes required for that cluster: if the total update volume exceeds 80% of a single node's processing capacity, multiple nodes are deployed. For service area partitioning, the system uses a capacity-constrained region allocation algorithm to ensure that the expected load within each node's service area does not exceed its processing capacity threshold.

[0042] When determining the location of data distribution nodes, some hotspot areas may have their center of gravity located on physical obstacles (such as walls or shelves), making node deployment impossible. The system can employ a feasible location search strategy: when the calculated center of gravity location is unavailable, the system uses that location as the center and expands outwards in a spiral search pattern to search for deployable locations. The system maintains a set of coordinates containing all deployable locations, obtained through prior site surveys or architectural drawing analysis. During the search process, the system calculates the sum of the distance from each candidate location to the original center of gravity location and the average distance to all electronic shelf labels within that hotspot area, selecting the feasible location with the smallest overall distance as the actual deployment location.

[0043] S104. In response to receiving a data update request from an electronic price tag, select a data distribution node whose service range covers the location information of the electronic price tag that sent the data update request and has the best preset route as the target node. In response to a received data update request from an electronic price tag, the system selects a data distribution node with the optimal preset route whose service range covers the location information of the electronic price tag that sent the data update request as the target node. Specifically, it filters candidate data distribution nodes whose service range covers the location of the electronic price tag and obtains the current processing load value of each candidate data distribution node; it calculates the physical distance from the electronic price tag to each candidate data distribution node, and the number of network device forwardings required for the electronic price tag to reach each candidate data distribution node through network devices, obtaining the network topology hop count; based on a preset time window, it calculates the real-time routing cost of each candidate data distribution node, which is equal to the transmission delay obtained by dividing the physical distance by the preset transmission rate, the forwarding delay obtained by multiplying the network topology hop count by the preset single-hop delay, and the sum of the processing delay corresponding to the current processing load value; and selects the candidate data distribution node with the minimum real-time routing cost as the target node. First, candidate data distribution nodes whose service range covers the electronic price tag locations are selected. This requires the system to maintain the service range information of each node and perform spatial queries. The query method can be spatial data structures such as R-tree index or quadtree index, which is not limited here. Next, the current processing load value of each candidate data distribution node is obtained. The load value can include indicators such as CPU utilization, memory usage, and queue length, which is not limited here. The physical distance from the electronic price tag to each candidate data distribution node is calculated. The distance calculation can use Euclidean distance, Manhattan distance, or distance considering the actual path, which is not limited here. The number of network device forwardings required for the electronic price tag to reach each candidate data distribution node through network devices is calculated to obtain the network topology hop count. Based on a preset time window, the real-time routing cost of each candidate data distribution node is calculated. The real-time routing cost is equal to the transmission delay obtained by dividing the physical distance by the preset transmission rate, the forwarding delay obtained by multiplying the network topology hop count by the preset single-hop delay, and the processing delay corresponding to the current processing load value. The weight coefficients of each delay can be dynamically adjusted according to the actual network conditions, which is not limited here. Finally, the candidate data distribution node with the lowest real-time routing cost is selected as the target node.

[0044] This step can employ a node selection method based on multi-objective optimization. The system maintains a real-time updated node status table, recording the location, service range, current load, and network topology information of each node. When a data update request is received, the system first quickly locates all candidate nodes covering the requested price tag using spatial indexing. For each candidate node, the system calculates three cost components in parallel: (1) Transmission cost: calculates the straight-line distance based on the coordinates of the price tag and the node, and calculates the transmission time based on the wireless transmission rate (e.g., the transmission rate of the 433MHz band); (2) Network cost: calculates the number of hops of the shortest path using Dijkstra's algorithm based on the maintained network topology map, and calculates the total forwarding delay for each hop based on a typical router processing delay (e.g., 5ms); (3) Processing cost: estimates the waiting time based on the node's current queue length and average processing time. The system weights and sums the three cost components and selects the node with the minimum total cost.

[0045] The system can also employ a machine learning-based intelligent routing method. The system deploys a trained neural network model to predict the optimal node. During the training phase, the system collects historical data, including price tag location, node status, selected node, and actual processing latency. The system constructs a feature vector containing information such as price tag coordinates, distances to candidate nodes, load, and network hop count. This data is used to train a multilayer perceptron (MLP) or decision tree model. During actual operation, the system inputs the features of the current request into the model, the model outputs scores for each candidate node, and the system selects the node with the highest score as the target node. The model can be periodically updated online based on newly collected data to adapt to changes in network conditions.

[0046] When selecting a target node, multiple candidate nodes may have very similar real-time routing costs. Simply selecting the node with the lowest cost may lead to load imbalance. The system can address this issue by introducing a random perturbation mechanism: when the cost difference between the optimal and second-best nodes is less than a preset threshold (e.g., 5%), the system does not directly select the node with the lowest cost. Instead, it constructs a selection probability distribution based on the inverse of the cost, with nodes having a higher probability of being selected due to their lower costs. Specifically, the system calculates the selection probability of each candidate node by dividing its cost by the sum of the inverses of the costs of all candidate nodes, and then selects the target node according to this probability distribution using a random number generator. This probabilistic selection mechanism effectively distributes the request load while ensuring overall performance.

[0047] S105. Obtain the timestamp of the data update request and the data version number; The system retrieves the sending timestamp and data version number of the data update request. This step is a data acquisition operation, primarily extracting two key pieces of information from the received data update request message. The sending timestamp records the exact time the electronic price tag was generated and the update request was sent, typically using Unix timestamp format or ISO 8601 standard format, with millisecond-level precision. The data version number is a unique identifier used to identify the data update version, which can be an incrementing integer, a UUID, or a time-based version number. These two pieces of information are crucial for subsequent request processing order control and version conflict resolution.

[0048] The system can employ a message parsing-based information extraction method. Data update requests received by the system are typically encapsulated in messages of a specific format, such as JSON, XML, or a custom binary protocol. The system uses the appropriate parser to extract the information: for JSON format, the system calls a JSON parsing library to directly access the timestamp and version fields; for binary protocols, the system reads the timestamp (e.g., the first 8 bytes) and version number (e.g., the next 4 bytes) from specific byte positions according to a predefined message structure.

[0049] Alternatively, a structured data extraction method based on protocol buffers can be used. The system uses Protocol Buffers or a similar serialization framework to define the message structure for data update requests. The message definition explicitly includes timestamp and version fields. After receiving the serialized message, the system uses the deserialization method provided by the framework to automatically convert the message into a structured object, and then directly accesses the corresponding properties of the object to obtain the timestamp and version number.

[0050] When acquiring timestamps, a missynchronization issue may arise between the local clock of the electronic shelf label and the system clock. The system can implement a clock synchronization correction mechanism: when processing requests, the system records not only the sending timestamp but also the receiving timestamp. The system periodically sends clock synchronization messages to the electronic shelf labels, collects round-trip time delay information, and calculates the clock deviation. When processing data update requests, the system uses the calculated clock deviation to correct the sending timestamp, ensuring its accuracy.

[0051] S106. Determine whether the target node is processing a historical data update request from the electronic price tag; The system determines whether the target node is currently processing a historical data update request from an electronic shelf label. This is a conditional check step to see if the target data distribution node currently has any incomplete data update requests from the same electronic shelf label. The system needs to maintain the processing queue status information for each node, including a list of requests being processed and those awaiting processing. The determination is based on the electronic shelf label identifier in the request, such as the shelf label ID or MAC address.

[0052] S107. Compare the data version number of the data update request with the data version number of the historical data update request; If so, the system compares the data version number of the data update request with that of historical data update requests. This is a version comparison operation used to determine the version relationship between the new request and historical requests. The comparison rules for the data version number depend on the format of the version number: if it is an incrementing integer, a direct numerical comparison is performed; if it is a timestamp format, the time sequence is compared; if it is a semantic version number (such as 1.2.3 format), it needs to be compared level by level in the order of major version number, minor version number, and revision number. The comparison result will determine the subsequent request processing strategy.

[0053] S108. If the data version number of the data update request is greater than the data version number of the historical data update request, then the processing of the historical data update request is terminated, and the data update request is inserted into the first position of the processing queue of the target node. The system compares the version number of the current data update request with the version number of historical data update requests currently being processed. If the version number of the current request is higher, it means that it contains updated data. Therefore, the system will terminate the processing of the ongoing historical request and insert the new data update request at the front of the target node's processing queue to prioritize the processing of the latest data update. This ensures that electronic price tags always display the latest price information. The data version number can be a monotonically increasing sequence number or a data update timestamp, as long as it reflects the freshness of the data; there are no restrictions here.

[0054] The system can maintain a version number comparator. When a new data update request arrives, the system retrieves the data version number from the request and compares it with the version number of a historical request currently being processed by the target node. If the new request's version number is greater, the system triggers a request replacement process, terminating the processing of the current historical request and inserting the new request at the head of the queue.

[0055] Each data update request carries a unique, incrementing sequence number as its version number. The system can also record the latest processed version number for each electronic price tag. When a new request arrives, the system retrieves the latest processed version number of that price tag and compares it with the version number of the new request. If the new request's version number is greater, the system terminates the processing of any previous requests for that price tag (if any) and inserts the new request at the head of the processing queue.

[0056] S109. If the data version number of the data update request is not greater than the data version number of the historical data update request, then discard the data update request; This step is the reverse of S108. If the comparison finds that the version number of the new data update request is not greater than (i.e. less than or equal to) the version number of the historical request being processed, it means that the data update request carries outdated data. In this case, the system will directly discard the request and not process it to save system resources.

[0057] S110. Insert the data update requests into the processing queue of the target node in the order of the request sending timestamps; If the judgment result in step S106 is negative, the data update requests are inserted into the processing queue of the target node in the order of their sending timestamps. If the target node has no historical requests being processed, the system directly inserts the newly arrived data update requests into the node's processing queue, sorting them by their sending timestamps to ensure that the processing order of the requests matches their sending order—first-sent requests are processed first. The sending timestamp can be generated by the electronic price tag device when sending the request, or by the gateway device receiving the request when receiving it; any time stamp reflecting the order of requests is acceptable and not limited here.

[0058] If a system data update request includes a timestamp field, it records the creation time of the request, accurate to milliseconds. The processing queue of the data distribution node is a priority queue, where priority is determined by the request's timestamp; requests with smaller timestamps (i.e., those sent earlier) have higher priority. When a new request is inserted into the queue, the system inserts it into the appropriate position based on its timestamp, ensuring the priority order of the entire queue.

[0059] If the data update request does not contain a timestamp, the gateway device receiving the request generates a timestamp by calling the system clock when the request arrives, and then forwards the request along with the timestamp to the data distribution node. The node inserts the requests into the processing queue according to the order of the timestamps generated by the gateway devices.

[0060] If the local clocks of the electronic shelf label devices are not synchronized, it may result in inaccurate timestamps for requests, affecting the processing order of requests. To avoid this problem, the system can require all electronic shelf label devices to periodically synchronize their time with a unified clock server. If a shelf label device is offline for an extended period and cannot synchronize its time, the system will force it to perform a clock synchronization upon its re-entry to ensure that the device time is consistent with the system time before allowing it to send data update requests.

[0061] S111, causes the target node to execute a data update request.

[0062] Once a data update request is successfully inserted into the target node's processing queue, the system drives the target node to retrieve and execute requests one by one according to the queue's priority, until the queue is empty. For each request, the target node needs to parse the request content, extract the device ID of the electronic shelf label, the product information to be updated, and price data, and then send this data to the corresponding electronic shelf label device via the wireless network. After receiving the data, the electronic shelf label device updates its internal database and displays the new product information on the screen. After the entire request is executed, the target node generates an execution result for the request and sends it to the initiator of the data update, informing them that the request has been processed.

[0063] In the above embodiments, by acquiring the data update records of electronic price tags and performing spatial density analysis, areas with frequent data updates can be identified. Data distribution nodes can then be deployed at key locations within these high-density areas. The location of these data distribution nodes closely aligns with actual business needs, reducing data transmission distance. When an electronic price tag sends a data update request, the system selects a node covering the price tag's location with the optimal route to process the request. This node deployment and intelligent scheduling method, based on actual business characteristics, ensures that data update requests are processed locally, reducing network transmission overhead. Furthermore, the more rational distribution of data distribution nodes avoids network congestion caused by traditional centralized deployments, improving the overall data update efficiency of the system. This scheme, which dynamically senses business characteristics and makes corresponding deployment adjustments, enhances data processing capabilities during local peak periods, thereby improving the timeliness of price updates.

[0064] The above embodiments describe a method for node deployment and request processing based on the data update characteristics of electronic shelf labels. However, in real-world applications, factors such as mall promotions and holidays may lead to a sudden increase in electronic shelf label data update requests in certain areas, causing a surge in the load on the data distribution nodes responsible for those areas. To address this dynamic load change, this application also provides another electronic shelf label display driving method. This method monitors the processing load of the data distribution nodes in real time, and when an abnormal load is detected, it promptly re-divides and allocates the service scope, thereby ensuring the stable operation of the system. The following section combines... Figure 2 Another electronic price tag display driving method in the embodiments of this application is described below: Please see Figure 2 This is another flowchart illustrating an electronic price tag display driving method in an embodiment of this application.

[0065] S201. Monitor the real-time processing load of each data distribution node; Real-time load processing is a comprehensive metric, encompassing parameters such as CPU utilization, memory usage, network bandwidth utilization, request queue length, average response time, and requests processed per second, among others. No specific limitations are set here. The monitoring time granularity can be configured according to system requirements, such as collecting data every second, every 5 seconds, or every minute; no specific limitations are set here. Monitoring data can be obtained through proactive polling, where the system periodically sends status query requests to each node; or through passive reporting, where each node proactively pushes its own status information to the monitoring center; no specific limitations are set here. The system can store the collected load data in a time-series database for subsequent trend analysis and historical queries. The storage duration and accuracy can be adjusted according to actual needs; no specific limitations are set here.

[0066] This step can be achieved through a distributed monitoring method based on agents. The system deploys a monitoring agent on each data distribution node, which is responsible for collecting various performance metrics of the local node. The agent obtains CPU utilization through system calls (reading the / proc / stat file or calling system APIs), memory usage through the memory management interface, and network traffic data through the network interface. The agent maintains a circular buffer to store data from the most recent N sampling periods and calculates a moving average to smooth out instantaneous fluctuations. The monitoring center communicates with each agent through a message queue (such as RabbitMQ or Kafka). The agents package the aggregated load data into JSON format messages and send them to the message queue at fixed time intervals (e.g., 5 seconds). The monitoring center consumes these messages from the queue, parses them, and updates the load status table of each node.

[0067] The system can also employ a centralized monitoring method based on the SNMP protocol. The system uses Simple Network Management Protocol (SNMP) for load monitoring. Each data distribution node runs an SNMP agent, which implements a custom Management Information Base (MIB) and defines object identifiers (OIDs) related to node load. The monitoring center, acting as the SNMP management station, maintains a list of IP addresses for all nodes. The monitoring center uses SNMP GET requests to periodically query the load information of each node, including custom OIDs such as processor load (1.3.6.1.4.1.xxx.1.1), memory usage (1.3.6.1.4.1.xxx.1.2), and queue length (1.3.6.1.4.1.xxx.1.3). Upon receiving the request, the node's SNMP agent calls the corresponding system interface to obtain real-time data, encapsulates it into an SNMP response message, and returns it. The monitoring center parses the response message, extracts the load data, and updates the monitoring database.

[0068] S202. When the real-time processing load of the target node is detected to exceed the preset load threshold, obtain the real-time processing load of other data distribution nodes other than the target node. When the real-time processing load of the target node exceeds a preset load threshold, the system acquires the real-time processing load of other data distribution nodes besides the target node. This step involves two key operations: load threshold determination and acquisition of other node loads. The preset load threshold is a key parameter that triggers the load balancing mechanism. It can be a single metric threshold (e.g., CPU utilization exceeding 80%) or a combination of multiple metrics thresholds (e.g., CPU exceeding 70% and queue length exceeding 100), without limitation here. The threshold can be a statically configured fixed value or an adaptive value dynamically calculated based on historical data, without limitation here. When the target node exceeds the threshold, the system needs to acquire the current load status of all other data distribution nodes. This can be done through real-time querying or reading the most recent cached data, without limitation here. The scope of other nodes can be all nodes in the system, or it can be limited to a subset of nodes in the same region or with network connectivity as the target node, without limitation here.

[0069] S203. Divide the service area of ​​the target node into multiple sub-regions of equal area, and calculate the number of electronic price tags in each sub-region. The system divides the service area of ​​the target node into multiple sub-regions of equal area and calculates the number of electronic shelf labels (ESCs) within each sub-region. This step aims to fine-grainedly divide the service area of ​​the overloaded node, providing a foundation for subsequent load balancing. The principle of equal area division ensures geographical uniformity, but the specific shape of the division can be a regular shape such as a square, rectangle, or hexagon; no limitation is made here. The granularity of the division (i.e., the number of sub-regions) can be dynamically determined based on the size of the service area and the density of ESCs, such as dividing a 1000-square-meter area into 10 or 20 sub-regions; no limitation is made here. When calculating the number of ESCs within each sub-region, the system needs to perform a spatial query based on the location information of the ESCs to determine which sub-region each label belongs to. In addition to the number of labels, the statistics can also include information such as the data update frequency and historical load of labels within each sub-region; no limitation is made here.

[0070] The system can employ a grid-based equal-area segmentation method. First, the system obtains the boundary coordinates of the target node's service area and calculates its minimum bounding rectangle. Based on the preset number of sub-regions N, the system calculates the number of rows and columns of the grid, ensuring that the number of rows × the number of columns is greater than or equal to N and as close as possible (e.g., when N=12, it can be divided into a 3×4 grid). The system calculates the width (total width / number of columns) and height (total height / number of rows) of each grid, generating grid boundary coordinates. For irregular boundaries within the service area, the system uses a ray casting method to determine if the center of each grid is within the service area, discarding grids outside the area. For each valid grid, the system performs a spatial query: iterating through the coordinates of all electronic price tags, determining if they fall within the boundary of the current grid (x_min ≤ x ≤ x_max AND y_min ≤ y ≤ y_max), and counting the number of price tags that meet the conditions.

[0071] The system can also adopt an adaptive partitioning method based on Voronoi diagrams. The system uses a weighted Voronoi diagram to achieve equal area partitioning. First, the system randomly generates N seed points within the service range of the target node as the centers of the sub-regions. Then iterative optimization is performed: (1) Generate a Voronoi diagram based on the current seed points, with each Voronoi unit representing a sub-region; (2) Calculate the area of ​​each sub-region and find the regions with the largest and smallest areas; (3) Move the seed point of the region with the largest area a certain distance toward the region with the smallest area; (4) Repeat steps 1-3 until the variance of the area of ​​all sub-regions is less than the threshold. After the partitioning is completed, the system uses an R-tree spatial index structure to accelerate the price tag attribution query: insert all price tag coordinates into the R-tree, and use the range query function of the R-tree to quickly find all price tags inside the polygon boundary of each sub-region.

[0072] S204. Select adjacent data distribution nodes in order of increasing real-time processing load, and assign the sub-regions to the selected data distribution nodes in sequence until the real-time processing load of the target node is reduced to below the preset load threshold. The system selects adjacent data distribution nodes in ascending order of other real-time processing loads and assigns sub-regions to the selected data distribution nodes sequentially. Specifically, it sorts adjacent data distribution nodes in ascending order of other real-time processing loads to obtain a first sorting result; it sorts the number of electronic price tags in the sub-regions in descending order to obtain a second sorting result; based on the first and second sorting results, the sub-region with the most electronic price tags is assigned to the data distribution node with the lowest real-time processing load; the system calculates the real-time processing load of the target node, and if the real-time processing load is higher than a preset load threshold, it continues to assign the next sub-region to the data distribution node with the second lowest real-time processing load, until the real-time processing load of the target node is reduced to below the preset load threshold.

[0073] First, the system sorts adjacent data distribution nodes according to their real-time processing load from low to high, resulting in a first sorting result. "Adjacent" here can refer to geographical proximity, network topology proximity, or service range proximity; this is not limited here. Second, the system sorts the number of electronic price tags within each sub-region from highest to lowest, resulting in a second sorting result. Then, based on both sorting results, the sub-region with the most electronic price tags is assigned to the data distribution node with the lowest real-time processing load. This allocation strategy ensures efficient load shifting. After allocation, the system needs to recalculate the real-time processing load of the target node. The calculation method can be based on factors such as the number of price tags in the remaining sub-regions and the expected request rate; this is not limited here. If the load is still higher than the threshold, the system continues to assign the next sub-region to the node with the second lowest load until the target node's load drops below the threshold. An upper limit can be set during the allocation process for the number of sub-regions a single node can receive to avoid excessive load concentration; this is not limited here.

[0074] The system can employ a progressive allocation method based on a greedy algorithm. The system implements a load balancing scheduler that maintains two priority queues: a node queue (ordered in ascending order of load) and a sub-region queue (ordered in descending order of price tag quantity). The specific process is as follows: (1) The system queries the list of adjacent nodes of the target node and determines the adjacency relationship by calculating the distance between nodes or querying the predefined topological relationship; (2) Obtain the real-time load value of each adjacent node and build a node priority queue; (3) Sort the sub-regions divided in step S203 according to the number of price tags and build a sub-region priority queue; (4) Take out the sub-region with the most price tags from the sub-region queue and take out the node with the lowest load from the node queue; (5) Perform the allocation operation: update the service range configuration of the node, add the boundary coordinates of the sub-region to the service range of the node, and remove it from the service range of the target node; (6) Recalculate the expected load of the two nodes: target node load = current load - (number of transferred sub-region price tags × average request rate), receiving node load = current load + (number of transferred sub-region price tags × average request rate); (7) Update the position of the receiving node in the node queue and check whether the target node load is lower than the threshold; (8) Repeat steps 4-7 until the condition is met.

[0075] An optimization allocation method based on linear programming can also be used. The system models the load allocation problem as a linear programming problem to solve. Set the decision variable x[i,j] to indicate whether to allocate sub-region i to node j (0 or 1). Objective function: minimize the load variance of all nodes. Constraints include: (1) Each sub-region can only be allocated to one node: Σx[i,j] = 1; (2) It can only be allocated to adjacent nodes: x[i,j] = 0 if j is not an adjacent node; (3) The final load of the target node is lower than the threshold: the current load of the target node - Σ(x[i,k] × load of sub-region i) ≤ threshold, where k ≠ target node; (4) Other nodes cannot be overloaded: the current load of node j + Σ(x[i,j] × load of sub-region i) ≤ capacity of node j. The system uses the simplex method or interior point method to solve the linear programming problem and obtain the optimal allocation scheme. Based on the solution results, the system performs the sub-region redistribution operation in batches.

[0076] During sub-region allocation, network partitions may occur, causing some adjacent nodes to temporarily be unable to receive allocation requests. The system can implement an allocation transaction backup mechanism: before executing the allocation operation, the system first creates an allocation transaction record, including information such as the source node, target node, sub-region identifier, and timestamp, and persists this record. The system sends an allocation request to the target node, setting a reasonable timeout. If no confirmation is received within the timeout period, the system marks the node as unavailable, removes it from the candidate list, and selects the next available node for reallocation. Simultaneously, the system records the result of each attempt in the allocation transaction record. For incomplete allocation transactions, the system initiates a periodic retry mechanism. When the target node is detected to be available again, the system resends the allocation request according to the transaction record, ensuring eventual consistency of the load balancing operation.

[0077] S205. When the real-time processing load of the target node drops below the preset load threshold, the sub-region is reassigned to the target node.

[0078] When the real-time processing load of the target node drops below a preset load threshold, the system reassigns the sub-region to the target node. This step is the load balancing recovery phase, designed to restore the temporarily transferred service scope and the original service scope allocation once the node load returns to normal. The system needs to continuously monitor the load status of the target node to determine when the recovery process can begin. The criteria for determining load reduction can include not only simple threshold comparisons but also load stability assessments, such as requiring the load to remain below the threshold for a certain period (e.g., 5 minutes); this is not limited here. The reassignment process can be an immediate full return or a gradual return, i.e., returning one or several sub-regions at a time, observing load changes, and then deciding whether to continue; this is not limited here. During the reassignment process, the system needs to ensure service continuity and avoid affecting currently processed requests; a graceful failover approach can be used, which is not limited here.

[0079] The system can employ a threshold-triggered batch recovery method. The system sets up a load monitoring task for the target node, checking its load value at fixed intervals (e.g., 30 seconds). When the load is detected to be below the threshold safety line (e.g., 80% of the threshold), the recovery process is initiated. The system queries the allocation history to obtain a list of all sub-regions transferred from that node and their current host nodes. The system sends batch return requests to these nodes, containing a list of sub-region identifiers to be returned. Nodes receiving the requests perform the following operations: (1) stop receiving new electronic price tag requests from these sub-regions; (2) wait for currently processed requests to complete; (3) remove the sub-regions from their service scope; (4) send a return confirmation message to the target node. After receiving all confirmations, the target node re-adds these sub-regions to its service scope configuration and begins receiving related requests.

[0080] A gradual recovery method based on load feedback can also be adopted. The system adopts a gradual strategy to restore the service range and avoid a sudden large load backflow. Specific implementation: (1) The system maintains a recovery queue to store all sub-regions to be returned, arranged in ascending order of the number of price tags in the sub-regions; (2) When the load of the target node is lower than the threshold, the system takes out the sub-region with the fewest price tags from the queue; (3) The system calculates the expected load increment after returning the sub-region: increment = number of price tags in the sub-region × historical average request rate; (4) If the current load + increment < 90% of the threshold, the return operation is performed; (5) The return operation adopts a two-stage submission: in the first stage, the target node adds the sub-region in the configuration in advance but does not activate it, and notifies the current holding node to prepare for handover; in the second stage, at the agreed time point, the current node stops the service, and the target node activates the configuration and starts the service; (6) After the return of a sub-region is completed, the system waits for an observation period (such as 2 minutes) to monitor the load change; (7) If the load is still stable below the threshold, the next sub-region is returned, otherwise the recovery process is paused.

[0081] During the sub-region reallocation process, some electronic shelf label requests may be lost during node switching. The system can employ a request caching and forwarding mechanism: Before returning a sub-region, the system enables request caching on the original service node and sets a switching time window (e.g., 30 seconds). Within this window, the original service node continues to receive requests belonging to the sub-regions to be returned, but does not process them immediately; instead, it serializes the requests and stores them in a local cache queue. Simultaneously, the original service node sends a switching notification to the requesting electronic shelf label, informing it of the new service node address. At the end of the switching time window, the original service node forwards all cached requests in batches to the target node and clears its local cache after forwarding. Upon receiving the forwarded requests, the target node inserts them into a priority position in its processing queue, ensuring these requests are processed promptly.

[0082] In the above embodiments, by monitoring the processing load of data distribution nodes in real time, the system can promptly identify nodes with excessive load. When the load of a target node exceeds a preset threshold, the system divides its service area into equal-area sub-regions and calculates the number of electronic price tags in each sub-region, achieving refined management of the service area. Based on the real-time processing load of other nodes, the system selects adjacent nodes in ascending order of load and sequentially allocates the sub-regions to these nodes until the target node's load drops below the threshold. When the target node's load returns to normal, the system reassigns the sub-regions to the target node, achieving dynamic adjustment of the service area. This load balancing mechanism enables the system to automatically distribute tasks when a node's load is too high, improving system reliability.

[0083] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of an electronic price tag display driving system provided in an embodiment of this application.

[0084] It should be noted that, Figure 3 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0085] like Figure 3 As shown, the system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage portion 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0086] The following components are connected to I / O interface 305: input section 306 including a camera, infrared sensor, etc.; output section 307 including a liquid crystal display (LCD) and speakers, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0087] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0088] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0090] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0091] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application 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. Such 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.

[0092] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0093] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for driving an electronic price tag display, characterized in that, include: Acquire data update records of multiple electronic price tags within a preset time period, wherein the data update records include the location information and data update amount of each electronic price tag; Based on the data update records, spatial density analysis is performed on the data update events of each electronic price tag to obtain one or more high-density data update regions. Several data distribution nodes are determined at a preset core location within the high-density data update area, and the service range of the several data distribution nodes is determined based on the range of the high-density data update area. In response to receiving a data update request from an electronic shelf label, a data distribution node with the optimal preset route whose service range covers the location information corresponding to the electronic shelf label that sent the data update request is selected as the target node, and the target node executes the data update request.

2. The method according to claim 1, characterized in that, The spatial density analysis of each data update event on the electronic price tag based on the data update records yields one or more high-density data update regions, specifically including: The preset area is divided into multiple grid units, each of which has a preset area; Calculate the data update density value within each grid cell. The data update density value is equal to the sum of the data update amounts of all electronic price tags in the grid cell within the preset time period divided by the preset area. The continuous grid cells with data update density values ​​greater than a preset density threshold are combined into a high-density data update region.

3. The method according to claim 1, characterized in that, The step of selecting a data distribution node as the target node, which has a service range covering the location information corresponding to the electronic price tag that sent the data update request and has an optimal preset route, specifically includes: Filter candidate data distribution nodes whose service range covers the location of the electronic price tag, and obtain the current processing load value of each candidate data distribution node; Calculate the physical distance from the electronic price tag to each of the candidate data distribution nodes, and the number of network device forwardings required for the electronic price tag to reach each of the candidate data distribution nodes through network devices, to obtain the network topology hop count; Based on a preset time window, the real-time routing cost of each candidate data distribution node is calculated. The real-time routing cost is equal to the transmission delay obtained by dividing the physical distance by the preset transmission rate, the forwarding delay obtained by multiplying the network topology hop count by the preset single-hop delay, and the sum of the processing delay corresponding to the current processing load value. The candidate data distribution node with the lowest real-time routing cost is selected as the target node.

4. The method according to claim 1, characterized in that, The determination of several data distribution nodes at preset core locations within the high-density data update area specifically includes: Cluster analysis is performed on the high-density data update region to obtain data update hotspots; Calculate the centroid position of each data update hotspot and use the centroid position as the preset core position; Based on the number of electronic price tags in the data update hotspots, the number of data distribution nodes deployed in the preset core location is determined, resulting in several data distribution nodes.

5. The method according to claim 1, characterized in that, Before the target node executes the data update request, the method further includes: Obtain the sending timestamp and data version number of the data update request; Determine whether the target node is processing a historical data update request from the electronic price tag; If so, compare the data version number of the data update request with the data version number of the historical data update request; If the data version number of the data update request is greater than the data version number of the historical data update request, then the processing of the historical data update request is terminated, and the data update request is inserted into the first position of the processing queue of the target node. If the data version number of the data update request is not greater than the data version number of the historical data update request, then the data update request is discarded; If not, the data update request is inserted into the processing queue of the target node in the order of the timestamps of the request sending.

6. The method according to claim 1, characterized in that, After the target node executes the data update request, the method further includes: Monitor the real-time processing load of each of the aforementioned data distribution nodes; When the real-time processing load of the target node is detected to exceed a preset load threshold, the real-time processing load of other data distribution nodes other than the target node is obtained. The service area of ​​the target node is divided into multiple sub-regions of equal area, and the number of electronic price tags in each sub-region is calculated. Adjacent data distribution nodes are selected in order of increasing real-time processing load, and the sub-regions are sequentially assigned to the selected data distribution nodes until the real-time processing load of the target node is reduced to below the preset load threshold. When the real-time processing load of the target node drops below the preset load threshold, the sub-region is reassigned to the target node.

7. The method according to claim 6, characterized in that, The step of selecting adjacent data distribution nodes according to the other real-time processing loads from low to high, and sequentially allocating the sub-regions to the selected data distribution nodes, specifically includes: The other real-time processing loads are sorted in ascending order among the adjacent data distribution nodes to obtain the first sorting result; The number of electronic price tags in the sub-region is sorted from most to least to obtain a second sorting result; Based on the first and second sorting results obtained, the sub-region with the most electronic price tags is assigned to other data distribution nodes with the lowest real-time processing load. Calculate the real-time processing load of the target node. If the real-time processing load is higher than the preset load threshold, continue to allocate the next sub-region to other data distribution nodes with the second lowest real-time processing load, until the real-time processing load of the target node is reduced to below the preset load threshold.

8. An electronic price tag display driving system, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images