An electronic price tag management system based on edge computing

Abstract

This invention relates to the fields of edge computing, the Internet of Things (IoT), and electronic shelf label (ESC) management technology, specifically an ESC management system based on edge computing. Deployed in an edge gateway device, the system includes: an edge sensing module for collecting local environmental variable data, inventory status data, and the binding mapping relationship between goods and ESCs in the target area; a collaborative computing module for calculating the cross-strip collaborative pricing matching degree based on a lightweight rule engine and generating an initial collaborative pricing strategy; a boundary verification module for calculating the mandatory compliance rate of the business boundary according to business constraint rules and correcting the strategy; an instruction issuing module for issuing price update instructions to the corresponding ESCs; and an adaptive feedback module for generating latency adjustment rules based on edge strategies to reduce the computational complexity of the rule engine. This invention achieves rapid decision-making at the edge, cross-strip linkage, and secure price adjustment simultaneously.

Description

Technical Field

[0001] This invention relates to the fields of edge computing, Internet of Things and retail electronic shelf label management technology, specifically an electronic shelf label management system based on edge computing. Background Technology

[0002] Existing electronic shelf label management systems are typically deployed within the price management architecture of supermarkets and stores, and communicate with multiple electronic shelf labels through gateway devices or back-end platforms; In related technologies, in order to update commodity prices, the back-end system can generate price adjustment instructions based on preset price rules and send them to the corresponding electronic price tags via the network; or, based on sales data, inventory data and other information uploaded by stores, the price strategy can be calculated on a remote platform and then the target price tags can be updated in batches. However, when local customer traffic, dwell time, and product consumption status change rapidly in a store, the former method is difficult to reflect real-time sales changes in the area in a timely manner, while the latter method is prone to price response delays due to long data transmission, strategy calculation, and instruction issuance links. At the same time, the electronic price tag management methods in related technologies usually cannot take into account cross-product linkage price adjustments, commercial constraint verification, and edge device load adaptive adjustment. Therefore, it is difficult to ensure the timeliness of price adjustments while also ensuring price accuracy and commercial security. Summary of the Invention

[0003] The purpose of this invention is to provide an electronic price tag management system based on edge computing, which solves the following technical problems: avoids the disconnect between on-site response caused by price adjustment decisions being uniformly issued from the remote cloud, and enables price tag updates to be closer to the actual sales rhythm, achieving the technical effects of rapid decision-making at the edge, cross-price tag linkage, and secure price adjustment.

[0004] The objective of this invention can be achieved through the following technical solutions: An edge computing-based electronic shelf label management system, wherein the system is deployed in an edge gateway device, and the edge gateway device establishes a data transmission link with the electronic shelf labels via a wireless communication protocol; the system includes: The edge sensing module is used to collect local environmental variable data and inventory status data of target products within a preset target area, and to obtain the binding mapping relationship between the target products and the electronic price tags. The collaborative computing module is used to calculate the cross-price tag collaborative price adjustment matching degree based on the local environmental variable data and the inventory status data through a preset lightweight rule engine, and generate an initial collaborative pricing strategy including the target price. The boundary verification module is used to calculate the mandatory compliance rate of the business boundary of the initial collaborative pricing strategy based on preset business constraint rules. The mandatory compliance rate of the business boundary is the ratio of the number of business constraint rules to the total number of business constraint rules. If the mandatory compliance rate of the business boundary is less than a preset compliance rate threshold, the initial collaborative pricing strategy is modified until the mandatory compliance rate of the business boundary is not less than the compliance rate threshold; otherwise, it is confirmed as the target pricing strategy. The instruction issuing module is used to convert the target pricing strategy into a price update instruction and issue it to the corresponding electronic price tag based on the binding mapping relationship through the wireless communication protocol. An adaptive feedback module is used to calculate the edge strategy generation delay from the completion of collecting the local environmental variable data to the issuance of the price update instruction; if the edge strategy generation delay is greater than a preset delay threshold, the computational complexity of the lightweight rule engine is reduced; otherwise, it remains unchanged.

[0005] Optional, the edge-aware module includes: An environmental data acquisition unit is used to acquire passenger flow density data and user dwell time data of the preset target area as local environmental variable data. The inventory monitoring unit is used to acquire real-time consumption rate data of the target product as the inventory status data.

[0006] Optionally, when calculating the cross-price tag coordinated price adjustment matching degree, the collaborative computing module performs the following operations: Obtain a pre-defined product relationship graph; Input the local environmental variable data and the inventory status data into the product association graph, and calculate the strategy synergy weight of the target product and the related products in the product association graph in the current state; The strategy coordination weights are normalized to calculate the cross-price tag coordinated price adjustment matching degree; and a set of linked tags is constructed based on the related products whose cross-price tag coordinated price adjustment matching degree is greater than a preset matching degree threshold. The initial coordinated pricing strategy containing the target price is generated based on the set of linked tags.

[0007] Optionally, the computational complexity of the lightweight rule engine is characterized by a preset edge rule engine lightweight index, which is the sum of the product of the peak CPU utilization rate of the lightweight rule engine when it runs on the edge gateway device and the first preset weight factor, and the product of the average memory consumption ratio and the second preset weight factor.

[0008] Optional business constraints include a minimum target retention ratio threshold and a price fluctuation frequency cap; When the boundary verification module modifies the initial collaborative pricing strategy, it performs the following operations: Obtain the benchmark price parameter of the target product and the number of historical price changes within a preset time window, and use the number of historical price changes as the historical price fluctuation frequency; The corresponding target retention ratio is calculated based on the target price in the initial collaborative pricing strategy and the benchmark consideration parameter. In response to the target retention ratio being less than the minimum target retention ratio threshold, the target price in the initial collaborative pricing strategy is increased; In response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being greater than the upper limit of the price fluctuation frequency, a delayed activation flag is added to the initial collaborative pricing strategy to delay the issuance time of the price update instruction by the instruction issuance module. In response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being less than or equal to the upper limit of the price fluctuation frequency, the initial collaborative pricing strategy is confirmed as the target pricing strategy.

[0009] Optionally, the edge strategy generation delay is the time difference from the timestamp when the edge perception module completes the collection of the local environmental variable data to the timestamp when the instruction issuing module outputs the price update instruction.

[0010] Optionally, the adaptive feedback module performs the following operations when reducing the computational complexity of the lightweight rule engine: Reduce the number of associated product levels in the product association graph referenced by the lightweight rule engine when calculating the cross-price tag collaborative price adjustment matching degree; Alternatively, the calculation branch in the lightweight rule engine where the strategy collaboration weight is lower than a preset weight threshold can be truncated.

[0011] Optional, also includes: The multi-source data fusion module is used to receive the local environmental variable data and the inventory status data collected by the edge perception module, and to perform timestamp alignment processing on the local environmental variable data and the inventory status data with different sampling frequencies in the established multi-dimensional data buffer pool.

[0012] The beneficial effects of this invention are: 1. This invention moves the closed loop of perception, strategy generation and instruction issuance to the edge gateway, and generates strategies directly based on the local environment and inventory status; it effectively overcomes the instruction lag problem caused by unified cloud issuance, so that price tag updates keep up with the local instantaneous sales rhythm and greatly improves real-time response efficiency. 2. This invention uses a lightweight rule engine and a product association graph to calculate the strategic synergy weight and matching degree of related products. It breaks the traditional single-point reactive price adjustment, realizes multi-product combination linkage optimization, accurately responds to related purchase behaviors, and effectively improves the collaborative execution efficiency of heterogeneous node status updates in the target area. 3. This invention introduces a mandatory compliance rate check at the business boundary, and automatically corrects the initial pricing strategy by combining the minimum target retention ratio and the upper limit of price fluctuation frequency; it avoids blindly and rapidly reducing prices or frequently jumping prices, and ensures the timeliness of dynamic price adjustment while ensuring the stability of system operating parameters and the safety margin of output instructions. 4. This invention continuously monitors the generation latency of the strategy. When the latency exceeds the limit, the system complexity is reduced by cutting down the graph association level or truncating low-weight calculation branches. This effectively prevents gateway paralysis caused by sudden concurrent requests and ensures that the timely distribution of core product prices can be prioritized even during peak sales periods. 5. This invention establishes a multi-dimensional data buffer pool and performs strict timestamp alignment processing on local environmental variables and inventory status data with inconsistent sampling frequencies; it eliminates the scene misalignment caused by time differences of multi-source data, ensures that decisions are based on a unified time-series cross-section, and significantly improves the accuracy of collaborative pricing. Attached Figure Description

[0013] The invention will now be further described with reference to the accompanying drawings.

[0014] Figure 1 This is a schematic diagram of a module of an electronic price tag management system based on edge computing provided in an embodiment of this application. Detailed Implementation

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

[0016] Please see Figure 1 An edge computing-based electronic shelf label management system, wherein the system is deployed in an edge gateway device, and the edge gateway device establishes a data transmission link with the electronic shelf labels via a wireless communication protocol; the system includes: The edge sensing module is used to collect local environmental variable data and inventory status data of target products within a preset target area, and to obtain the binding mapping relationship between the target products and the electronic price tags. The collaborative computing module is used to calculate the cross-price tag collaborative price adjustment matching degree based on the local environmental variable data and the inventory status data through a preset lightweight rule engine, and generate an initial collaborative pricing strategy including the target price. The boundary verification module is used to calculate the mandatory compliance rate of the business boundary of the initial collaborative pricing strategy based on preset business constraint rules. The mandatory compliance rate of the business boundary is the ratio of the number of business constraint rules to the total number of business constraint rules. If the mandatory compliance rate of the business boundary is less than a preset compliance rate threshold, the initial collaborative pricing strategy is modified until the mandatory compliance rate of the business boundary is not less than the compliance rate threshold; otherwise, it is confirmed as the target pricing strategy. The instruction issuing module is used to convert the target pricing strategy into a price update instruction and issue it to the corresponding electronic price tag based on the binding mapping relationship through the wireless communication protocol. An adaptive feedback module is used to calculate the edge strategy generation delay from the completion of collecting the local environmental variable data to the issuance of the price update instruction; if the edge strategy generation delay is greater than a preset delay threshold, the computational complexity of the lightweight rule engine is reduced; otherwise, it remains unchanged.

[0017] This embodiment provides an electronic price tag management mechanism based on edge computing; specifically, the system is deployed in the edge gateway device of the target location, and is suitable for cross-regional linkage control scenarios between the first target area and the adjacent second target area; The store typically experiences a surge in localized customer traffic between 6 PM and 9 PM. Consumers exhibit clear cross-selling behavior among items such as cold drinks, beer, ice cups, and nuts. This behavior is characterized by its regionality, temporality, and strong volatility. If price adjustment decisions are still uniformly issued from the remote cloud, it is easy to encounter asynchronous problems such as customers gathering but prices not responding, and target products having less than the preset threshold but related products still being displayed according to the original strategy. Therefore, this system moves the closed loop of perception, strategy generation, boundary verification and instruction issuance to the store edge gateway, so that price tag updates are closer to the actual sales rhythm. Specifically, the edge perception module collects local environmental variable data and inventory status data from the preset target area; the local environmental variables here are not abstract parameters, but on-site signals that directly reflect the interaction intensity of the target object, such as the customer flow density per unit area in front of a certain freezer, the dwell time of the target object in front of a certain display, and the change in the frequency of taking the target product. Inventory status data reflects changes in the availability of goods on the shelves. For example, a six-pack of beer may go from being fully stocked to having only a small amount left in the front row, or ice cups may be quickly taken away in a short period of time. At the same time, the system reads the binding mapping relationship between the product and the electronic price tag, for example, beer A - price tag E1, ice cup B - price tag E2, nuts C - price tag E3; This binding relationship enables subsequent strategies to accurately locate the target price tag without requiring manual inspection to reconfirm the tag correspondence. After the data collection is completed, the collaborative computing module uses a lightweight rule engine to generate local strategies. Here, lightweight means that it prioritizes the use of rule structures suitable for edge gateway operation, rather than relying on the return of historical samples exceeding the preset scale before performing complex modeling. Its core is not to decide whether to adjust a certain product parameter up or down, but to generate cross-price tag collaborative strategies by combining the correlation features of the regional acquisition status. Specifically, the lightweight rule engine includes a local decision tree set consisting of multiple sets of conditional judgment statements and a corresponding action library. It traverses and matches the local environmental variable data and inventory status data through forward reasoning to trigger preset price adjustment actions. For example, in the refrigerated section, beer and ice cups are often complementary, beer and the second-size product of the same brand may be substitutes, and beer and nuts may both see increased picking frequency in the evening; the collaborative calculation module makes combination adjustments rather than single-label adjustments based on this, thereby obtaining the initial collaborative pricing strategy; For ease of understanding, a simplified test scenario can be used: Assume the current target product is beer A, and related products include ice cups B, nuts C, and premium beer D. The system forms a three-item association set {B, C, D} based on the current situation. If B and C are determined to be positively synergistic in the current situation, and D is determined to be a substitute and restraint, then the initial strategy can be reflected as follows: beer A maintains an attractive price, ice cup B moderately synergizes, nuts C is promoted simultaneously, and premium beer D does not follow suit with a price reduction. This shows the data flow and logical direction, rather than the mathematical evaluation process. The boundary verification module performs business rule verification on the initial collaborative pricing strategy; this module extracts preset business constraint rules and determines whether the generated strategy does not meet the preset system operation constraints; the so-called business boundary mandatory compliance rate can be understood as the degree of rule coverage in a single strategy review; For ease of explanation, five system operation constraint rules can be set, including minimum target retention rate, maximum single reduction range, maximum number of price changes per day, preset target retention threshold, and state change objects must not overlap with lifecycle end objects. If the initial strategy meets 4 of the criteria, the compliance rate will be in the state of meeting 4 criteria and not meeting 1 criterion; when this state reaches the pass standard set by the store, the strategy can be directly confirmed as the target pricing strategy. If the standard is not met, further corrections are required. The correction method is not limited to simply rolling back all results, but can be targeted to adjust specific conflict items, such as increasing the target price of individual products, narrowing the scope of linkage, or postponing the change time of a certain label. This preserves the speed of on-site response and avoids the entire strategy being invalidated due to a single violation. The specific automated correction process adopts a greedy algorithm or heuristic search strategy. The system performs gradient fine-tuning on the target price or linkage range of conflict items in descending order of priority of business constraint rules. After each fine-tuning, the mandatory compliance rate of the business boundary is recalculated until its value is not less than the compliance rate threshold. Once the target pricing strategy is formed, the instruction issuing module converts the strategy into a price update instruction and, based on the binding mapping relationship, sends it to the corresponding electronic shelf label via a wireless communication protocol. The sent content may include the target price, effective time, promotional information, and linked label markings. For example, beer A's price tag displays a limited-time price, ice cup B displays a bundled purchase option, and nuts C displays a second item bundle recommendation; since the edge gateway and price tag are within the same store's local communication range, instructions do not need to be uploaded to the cloud and then fed back, thus shortening the on-site strategy implementation path; Furthermore, the adaptive feedback module continuously calculates the edge policy generation latency from the completion of perception to the output of the price update command. This latency essentially reflects whether the edge device can still keep up with the pace of changes in the store. If a large number of triggering events occur instantaneously in the target area, such as price adjustment requests occurring simultaneously in the refrigerated area, the cooked food area, and the entrance display, the edge gateway load will increase, and the policy generation time may be prolonged. At this point, to avoid the problem that the scenario has changed by the time the strategy is calculated, the system automatically reduces the computational complexity of the lightweight rule engine and prioritizes timeliness; if the current latency is within a controllable range, the existing complexity is maintained to maintain a relatively complete depth of collaborative analysis. As an anomaly handling mechanism, if the local environmental variables collected by the edge sensing module are missing, such as a passenger flow sensor going offline for a short time, the system can revert to generating a conservative strategy based only on the inventory status and the most recent valid environmental sample, so as to avoid freezing prices in the entire area due to an anomaly of a single sensor source. If the binding mapping relationship is inconsistent, for example, if the product position changes after the shelf is adjusted but not updated in sync, the system can temporarily suspend the automatic update of the label and send the abnormal record to the backend for manual review. If boundary verification fails to meet the compliance rate target, for example, if it is necessary to increase the inventory consumption rate while meeting the preset price lower limit, the system can stop automatic issuance and switch to manual approval mode; within the preset time window, the edge perception module detects that the target object interaction density in the first target area reaches the preset peak value, and the dwell feature value of the location of the first target label exceeds the preset time threshold. At 19:10 on a summer Friday in a certain chain supermarket, a concentration of customers was detected in the beverage refrigerated area. The average time customers spent in front of beer A increased significantly. Inventory monitoring showed that ice cups B were consumed faster, and nuts C were also taken along with the ice cups. After the edge gateway reads the binding relationship of the three electronic price tags E1, E2, and E3, it generates a set of collaborative strategies locally: Beer A maintains the main traffic-driving price, Ice Cup B is adjusted synchronously in the form of a bundle, and Nuts C is given a small linkage discount without breaking the gross profit margin. During the verification phase, it was found that if the price of Nuts C continued to decrease, it would reach the minimum target retention rate threshold set by the store. Therefore, the system only retained the display promotional text and did not increase the actual price reduction. Finally, the revised target strategy was sent to the corresponding price tags. If the edge gateway also needs to process the price adjustment of near-expiry products in the cooked food area at the same time, causing the strategy delay to approach the threshold, the system will automatically reduce the depth of non-core correlation analysis and prioritize ensuring that the price response in the refrigerated area is completed first. The purpose of this mechanism is to directly translate real-time changes in the local business environment of a store into controlled, implementable electronic shelf label updates that are subject to business boundary constraints, thereby achieving the technical effects of rapid decision-making at the edge, cross-shelf label linkage, and secure price adjustments.

[0018] In a preferred embodiment of the present invention, the edge perception module includes: an environmental data acquisition unit, used to acquire passenger flow density data and user dwell time data of the preset target area as the local environmental variable data; and an inventory monitoring unit, used to acquire real-time consumption rate data of the target product as the inventory status data.

[0019] This embodiment provides a refined acquisition mechanism for the edge perception module; specifically, in the above-mentioned summer evening peak refrigerator promotion scenario, a single-dimensional personnel presence detection signal cannot meet the data input requirements for fine-grained strategy optimization, because different types of on-site states correspond to different business meanings. People walking around but not stopping may simply mean they are passing through the aisle; people standing for a long time but taking things slowly may mean they are comparing prices. A rapid increase in the consumption rate usually indicates that price attractiveness, scenario demand, or display location have all played a role; therefore, this embodiment further breaks down perception into an environmental data acquisition unit and an inventory monitoring unit, enabling the system to build a more accurate on-site state model of the user's browsing, comparison, and target product acquisition interaction process. Specifically, the environmental data acquisition unit is used to acquire passenger flow density data and user dwell time data; passenger flow density reflects the contact intensity of a target area per unit time, which can be obtained through top-view passenger flow counting equipment, infrared arrival and departure detectors, or store video analysis units; This metric helps the system distinguish between increased popularity in a localized area and a situation where there are many people in the store but the target shelves receive only average attention; user dwell time is closer to the consumer's decision-making process. When customers linger in front of a refrigerated display case, it usually means they are comparing capacity, brand, promotional tags, or bundled items. This kind of behavior often reflects the timing of price intervention better than simply passing by. The inventory monitoring unit is used to obtain real-time consumption rate data of target products. This rate is not the static total inventory, but reflects the pace at which products are taken from the shelves. For example, if there are 20 items remaining in inventory, and only 1 item is sold in the past 10 minutes, the system's judgment on subsequent price adjustments will obviously be different from that of 8 items sold in the past 10 minutes. The former is more suitable for stimulating demand through price, while the latter should be more controlled to prevent the core product from being depleted of inventory before the preset period, thus affecting the sales of related products. For ease of explanation, simplified data segments can be used to represent the data; let the passenger flow segments in the refrigerated area within a certain continuous observation window be denoted as F1, F2, F3, the dwell segments as T1, T2, T3, and the consumption segments as R1, R2, R3. If F2 is significantly higher than F1, T2 is also higher than T1, and R2 is also higher than R1, then it means that the area was not passed by by chance, but has entered a state of increased attention and purchase conversion. Based on this, the system can determine that the area is suitable for triggering local coordinated pricing; conversely, if F2 is high but T2 is low, it indicates that the aisle is more congested than the shelves are more attractive, and the system will determine that the price adjustment trigger conditions are not met, so as not to misjudge traffic flow as purchase intention. As an anomaly handling mechanism, if passenger flow density data is available but dwell time is missing, for example, if the camera is temporarily blocked, the system can use two consecutive cycles of increasing passenger flow and simultaneous acceleration of inventory consumption as alternative trigger conditions. If the dwell time is long but inventory consumption does not increase, it will be interpreted as a comparison browsing or price hesitation state, which may only trigger promotion display optimization without immediately triggering a substantial price change; if abnormal changes occur in inventory monitoring, such as instantaneous inventory fluctuations caused by concentrated employee replenishment or inventory count, the data for that period can be marked as operational disturbance samples and will not be directly involved in price adjustment judgment. Within a monitoring window at the same store from 19:15 to 19:25, the number of customers in front of the refrigerator increased continuously. The target customers spent more time in front of beer A and ice cup B. Inventory monitoring showed that the consumption rate of ice cup B increased significantly, while the preset second-size product D, although it attracted attention, was taken less frequently. Based on this, the system identified that an immediate consumption scenario of basic beer + ice cup was forming, while the demand for premium products remained stable. Based on this perception result, the subsequent strategy will prioritize edge linkage around the combination of A and B, and will not mistakenly include D in the synchronous price reduction; The purpose of this step is to collect and cross-verify local customer traffic, shelf dwell behavior, and changes in inventory consumption in a stratified manner, so as to achieve a more accurate perception of the true purchase intention and reduce false triggers caused by relying on a single sensor signal. In a preferred embodiment of the present invention, the collaborative computing module performs the following operations when calculating the cross-price tag collaborative price adjustment matching degree: obtaining a preset product association graph; inputting the local environmental variable data and the inventory status data into the product association graph, calculating the strategy collaboration weight of the target product and the associated products in the product association graph in the current state; normalizing the strategy collaboration weight, calculating the cross-price tag collaborative price adjustment matching degree; and constructing a linkage tag set based on the associated products whose cross-price tag collaborative price adjustment matching degree is greater than a preset matching degree threshold, and generating the initial collaborative pricing strategy containing the target price based on the linkage tag set.

[0020] This embodiment provides a collaborative computing mechanism based on a product association graph; specifically, in the aforementioned store scenario, if the price of a product is determined solely based on the customer flow and inventory status of a single product, it is easy to overlook the linkage effect in real retail operations. For example, a price reduction in beer may boost sales of ice cups and nuts, but it may also divert purchases of premium beer; promotions of energy drinks may attract younger customers, but they do not necessarily lead to a corresponding change in the price of bottled water in the same area. To enable the edge gateway to resolve this linkage relationship locally, this embodiment introduces a product association graph, which allows the system to not only perceive the current interaction popularity of the target product, but also identify its positive promotion relationship, negative inhibition relationship and collaborative price adjustment strategy for related products. Specifically, the product relationship graph can be pre-built by headquarters based on historical transactions, display logic and category rules, and then distributed to the local cache of the store's edge gateway; the nodes in the graph represent products, the edges represent relationships, and the direction and strength of the edges reflect the direction and degree of influence. For ease of understanding, a simplified scenario model can be used: Suppose there are 4 nodes in the graph, namely beer A, ice cup B, nuts C, and premium beer D; where A→B means that beer A has a significant driving effect on ice cup B, A→C means that it has a moderate driving effect on nuts C, and A→D means that there is a substitution and restraint relationship with premium beer D. Furthermore, the current on-site status can be input into the graph to form scenario-based strategy collaborative weights; if the customer flow in the refrigerated area increases and A is consumed faster, the edges A→B and A→C will be activated more significantly because this state is consistent with the immediate drinking scenario; while the edge A→D may manifest as avoiding price reductions in the same direction to prevent the high-end product from losing its price level. The normalization process mentioned here is essentially to organize the impact of different related products to the same comparable scale, so that the edge gateway can quickly determine which products are suitable for inclusion in this round of coordinated price adjustment. Continuing with the above simplified example, let's say that the strength of scenario-based collaboration between A and B, C, and D is high, medium, and low, respectively. After unifying the scale, we can obtain a sequence that is easier to make decisions about. For example, B should be the most likely to be involved, followed by C, and D is not recommended to be involved. Based on this, the system forms a cross-price tag collaborative price adjustment matching degree. It does not simply pursue the more participating products the better, but measures whether the tag combination that can form effective collaboration under the current on-site conditions is clear enough and consistent enough. The specific calculation process can be implemented through structured decomposition: the system assigns the strategy collaboration weights of a single associated product in its current state. With the total number The normalized weight of each product is calculated by ratioing the sum of the strategy synergy weights of all activated associated products. The calculation process can be expressed as follows: in, Indicates the first The strategy synergy weight of each activated associated product in its current state. It is a positive integer; The system extracts the normalized weight set and calculates the mean of the weights in the set. With the variance representing the degree of dispersion The difference is used as the matching degree of cross-price tag collaborative price adjustment. Specifically, it can be expressed as: in, The mean is the preset discrete penalty coefficient. Since the mean reflects the strength of the overall synergistic effect and the degree of dispersion reflects the imbalance of the synergistic distribution, this measurement method can accurately characterize whether the synergistic combination is clear and consistent enough. Discrete penalty coefficient The range of values ​​is an interval. The system is configured based on the supermarket's historical risk tolerance for cross-price tag price adjustments. A more conservative and stable price adjustment strategy is preferred by the supermarket. The larger the value; When the matching degree is high, it means that the price actions between related products can form a closed-loop control sequence that meets the preset convergence conditions; when the matching degree is low, it means that the scenario has not yet formed a clear linkage, and it is not advisable to force a large-scale joint debugging. As an exception handling mechanism, if a newly listed product is not present in the product association graph, the system can first process it as a single product, generate a local strategy based only on its own customer flow and inventory, and send the missing node information back to the backend for subsequent graph supplementation. If there are connections in the graph, but the on-site perception is obviously contradictory to the historical graph, for example, if Ice Cup B, which was often linked in the past, does not have any stop or consumption response in this round, the system can reduce the role of that edge in the current window to avoid historical experience overriding the real-time scene. If all related edges are weak in the current window, the system can determine that the matching degree is insufficient, and will not trigger cross-price tag joint debugging, but will only implement a conservative pricing strategy or maintain the original price for the target product. At around 19:20, after the edge gateway reads the real-time status of the refrigerated area, it inputs beer A as the target node into the local product map; the map shows that A has a predetermined relationship with ice cup B, nuts C, and premium beer D; Because the on-site performance shows an increase in immediate consumption demand, the system judges that the linkage value between A and B, C has increased, while the risk of promotion in the same direction as D has increased. After being adjusted to the same scale, the matching results of this round show that B and C are suitable for inclusion in the linked label set, while D is not included; therefore, the subsequent generated strategy is that A is adjusted in coordination with B and C, while D maintains its original price to maintain the price gradient. The purpose of this mechanism is to introduce the business relationships between products into edge-side decision-making, so that price adjustments are upgraded from single-label reactive actions to multi-label collaborative actions, thereby achieving dynamic pricing responses that are more in line with the logic of on-site sales.

[0021] In a preferred embodiment of the present invention, the computational complexity of the lightweight rule engine is characterized by a preset edge rule engine lightweight index. The edge rule engine lightweight index is the sum of the product of the peak CPU utilization rate of the lightweight rule engine when it runs on the edge gateway device and a first preset weight factor, and the product of the average memory consumption ratio and a second preset weight factor.

[0022] This embodiment provides a lightweight index mechanism for characterizing the operating load of the edge rules engine; specifically, in actual stores, the edge gateway usually not only undertakes price tag management, but may also handle local sensor access, device heartbeat maintenance and some cache forwarding tasks at the same time. If the pricing rule engine consumes too much processor and storage resources during a certain period, even if a better strategy is eventually calculated, the best price response window may be missed due to the device slowing down. Therefore, simply describing the reduction of complexity is not enough; it is necessary to transform the operating pressure of edge devices into observable, comparable, and triggerable adjustment metrics. Specifically, the lightweight index can be understood as a comprehensive representation of the pressure exerted by the edge rule engine on gateway resources; among them, the peak utilization rate of the central processor can better reflect the instantaneous computing impact and is suitable for observing whether the rule engine causes preemption in a short period of time. The average memory consumption ratio is a better indicator of the continuous operating load and is suitable for observing the long-term pressure that graph loading, history caching, and rule tree expansion bring to the device. By combining the two, the system can distinguish between instantaneous congestion and continuous expansion load. For ease of explanation, a simplified sandbox approach can be used: Suppose that in a certain round of price adjustment calculation, scheme P1 needs to expand a large number of product association levels at the same time, resulting in a significant instantaneous spike in processor usage; although scheme P2 has slightly lower processor pressure, it retains a large number of intermediate states, resulting in a long-term high memory usage. The system compares the two solutions using a unified index, thus going beyond a single resource dimension to comprehensively determine which solution is more suitable for the current gateway state; specifically, in the quantitative analysis, the peak utilization rate of the central processing unit... It can be defined as the maximum percentage of CPU usage within a single policy generation cycle; Average memory consumption Defined as the ratio of the average amount of memory used by the rules engine during the period to the total available memory allocated to the edge gateway system; After obtaining the above two ratio values, the system multiplies them by a preset load weighting factor. and For example, since instantaneous computational surges are more likely to cause congestion, CPU peak values ​​can be assigned weights. Assign weights to memory consumption ratios Adding the products of the two gives the lightweight index of the edge rule engine. The calculation process can be expressed as follows: Through this defined weighted sum mechanism, the system can convert resource consumption from different dimensions into a unified and intuitive load scale, providing a clear numerical trigger for subsequent adaptive degradation. This index is not used to pursue abstract computational elegance, but directly serves the on-site operation scenario; because once the edge device of the store is overloaded, the first thing affected is not necessarily the computation itself, but the timing of instruction issuance, the stability of wireless scheduling and the queuing efficiency of concurrent tasks; in other words, the more reasonable the lightweight index, the more conducive it is to ensuring that strategy generation and instruction issuance are completed within the preset time delay. As an exception handling mechanism, if the edge gateway experiences abnormal processor usage due to other business emergencies, such as a temporary concentrated upload of store video analysis tasks, the system can mark the lightweight index for that time period to avoid mistakenly attributing the external business impact entirely to the rule engine. If the memory monitoring module malfunctions briefly, a conservative load reduction can be implemented based solely on the processor peak value, and the system can re-enter the comprehensive evaluation mode after memory monitoring recovers. If the index remains high for an extended period, a background alarm can be triggered, prompting the store to maintain and optimize the edge device model, caching strategy, or map size. Around 19:25, the store's refrigerated display area, cooked food area, and entrance promotional display all triggered policy requests almost simultaneously. The edge gateway needed to concurrently process multiple sets of price tag linkages. The system found that when the current rule engine was calculating the linkage of the refrigerated display area graph, the peak processor usage increased significantly, and the memory cache remained high. At this point, the lightweight index is determined to have entered the high load range, and the subsequent adaptive feedback module can take measures to reduce complexity, prioritizing the timeliness of the current price adjustment in the freezer area. The purpose of this mechanism is to concretize and measur the resource pressure on the edge gateway, thereby enabling dynamic management of the complexity of the rule engine operation and avoiding the weakening of the real-time value of edge decision-making due to the excessive weight of local algorithms.

[0023] In a preferred embodiment of the present invention, the business constraint rules include a minimum target retention ratio threshold and a price fluctuation frequency upper limit; when the boundary verification module corrects the initial collaborative pricing strategy, it performs the following operations: obtaining the benchmark price parameter of the target product and the number of historical price changes within a preset time window, and using the number of historical price changes as the historical price fluctuation frequency; calculating the corresponding target retention ratio based on the target price in the initial collaborative pricing strategy and the benchmark price parameter; In response to the underlying asset retention ratio being less than the minimum underlying asset retention ratio threshold, the target price in the initial collaborative pricing strategy is increased; in response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being greater than the upper limit of the price fluctuation frequency, a delayed activation flag is added to the initial collaborative pricing strategy so that the instruction issuance module delays the issuance time of the price update instruction. In response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being less than or equal to the upper limit of the price fluctuation frequency, the initial collaborative pricing strategy is confirmed as the target pricing strategy.

[0024] This embodiment provides a strategy correction mechanism oriented towards business boundaries; specifically, in the aforementioned store scenario, the edge gateway is already able to quickly form a linked price adjustment strategy based on changes in customer flow, dwell time, and inventory, but if there is a lack of operational bottom-line constraints, rapid on-site response may actually amplify the risks. For example, if the price of a certain beer is continuously reduced due to a sudden increase in customer traffic, although it will bring short-term sales, it may erode gross profit; or if the price of a certain ice cup is changed frequently in a short period of time, even if the changes are small each time, it is easy to cause the state of the system output to oscillate and reduce the smoothness of the node control sequence. Therefore, this embodiment further incorporates the minimum target retention ratio threshold and the upper limit of price fluctuation frequency into the local verification and correction process. Specifically, the boundary verification module first obtains the benchmark pricing parameters and historical price fluctuation frequency of the target product. The benchmark pricing parameters can come from the product file, the cost of the purchase batch, or the store's accounting cost. It determines the preset lower limit of the parameters that cannot be exceeded by automatic price adjustment. The historical price fluctuation frequency reflects how many times the price of the product has changed within a certain period. It corresponds to the stability requirements of price management. For products that are highly sensitive to consumers, prices should not fluctuate frequently in a short period of time. Otherwise, even if each fluctuation is legal, it may cause the system to become unstable due to excessively high interaction frequency. After the initial collaborative pricing strategy is generated, the boundary verification module checks whether the gross profit margin is sufficient based on the relationship between the target price and the cost. The specific target retention ratio is calculated as the ratio of the target price minus the benchmark consideration parameter to the target price. To facilitate understanding, a micro-level example can be used to illustrate the logical flow: Suppose the benchmark price parameter for beer A is denoted as... The target price given by the initial strategy is denoted as Then the corresponding target retention ratio is: If calculated If the target retention rate is less than the minimum threshold set by the store, the system will not execute the action directly. Instead, it will raise the target price of the product to a safe range that meets the bottom line of operations. This is not about pursuing a fixed value, but about ensuring that the promotional activities are still within the scope of sustainable operation. Regarding the verification of price fluctuation frequency, if the current gross profit of a product meets the requirements, but the price has changed multiple times on the same day or in the last few hours, the system may not immediately push the new price, but instead delay the execution time and put the current strategy into the subsequent effective queue to avoid the same product repeatedly refreshing the price tag in a short period of time. This correction mechanism is essential for the stability of the terminal control system; because an unusually high volume of local customers does not necessarily mean that the product needs to remain cheaper. Conversely, when a product is already in a high-conversion state, it is even more necessary to prevent the target price parameters from being adjusted downwards in an unordered manner; since the price tag is the price carrier that consumers see directly, frequent changes will not only affect operational stability, but also increase the cost of explanation and complaint handling for stores. As an exception handling mechanism, if cost data is missing or in an unstable state during updates, the system can suspend automatic price adjustments for the product and only allow the use of the safety price range preset by headquarters; if the historical price frequency records are incomplete, such as when there are local gaps after the store's network is restored, the system can adopt a more conservative default limit, prioritizing reducing the number of price changes rather than taking risks with frequent adjustments. If a product hits both the lower limit of gross profit and the upper limit of frequency, the gross profit margin will be protected first, and then the store's time-based strategy will be used to decide whether to postpone the adjustment. If necessary, the automatic price adjustment for this round can be canceled directly. Around 19:30, the system prepared to implement a coordinated strategy for beer A, ice cup B, and nuts C; during the verification phase, it was found that if the price of nuts C continued to drop, it would be lower than the set minimum target retention rate. Therefore, the system only retained the display promotional text and did not increase the actual price reduction. It was also discovered that the price of Ice Cup B had changed multiple times in the past hour. Although the target price still met the gross profit requirement, in order to avoid frequent price updates, the system postponed the update instruction for Ice Cup B to the next stable window, while Beer A was executed directly at the current time. The purpose of this mechanism is to constrain rapid dynamic pricing within the acceptable operating boundaries of stores, thereby achieving a balance between the speed of marginal decision-making and business security.

[0025] In a preferred embodiment of the present invention, the edge strategy generation delay is the time difference from the timestamp when the edge perception module completes the collection of the local environmental variable data to the timestamp when the instruction issuing module outputs the price update instruction.

[0026] This embodiment provides a mechanism for defining the latency of edge policy generation. Specifically, when the on-site environment of the store is constantly fluctuating, only by clearly defining the start and end boundaries of the latency can the system determine whether local computing truly has real-time value. If the latency definition is too broad, external waiting time unrelated to the policy will be mixed into the statistics, which will not truly reflect the response capability of the edge gateway. If the definition is too narrow, the key processing link between strategy formation and instruction output may be ignored. Therefore, this embodiment sets the starting point as the timestamp of the edge perception module completing the collection of local environmental variables and the ending point as the timestamp of the instruction issuing module outputting the price update instruction, thus corresponding to a complete, traceable local processing link that is directly related to the on-site business. Specifically, this latency covers the processes of local data processing, collaborative computing, business boundary verification, strategy correction, and instruction encapsulation after the sensed data enters the network, but does not include the natural waiting time for customers to arrive at the shelf or the final execution time required for the physical refresh of the price tag. The advantage of this definition is that it is more suitable as a basis for adjusting the complexity of the rule engine, because it reflects the processing efficiency of the edge gateway itself from seeing an event to issuing an action. For ease of explanation, a simplified time segment can be used: In a certain round of events in the refrigerated display case area, the time when perception is completed is t1, the time when strategy verification is completed is t2, and the time when the price update instruction is output is t3. Then the edge strategy generation delay corresponds to the segment from t1 to t3. If in another round of events, although the actual price tag refresh is slightly slower, the time from t1 to t3 is very short, it indicates that the edge gateway's local policy is still timely enough. The problem can then be located in the wireless link or the terminal display, rather than being misjudged as the rule engine's calculation being too slow. As an exception handling mechanism, if a timestamp is missing in a certain step, for example, if the start time is not recorded due to the restart of the sensing module, the delay statistics of that round can be marked as invalid samples and will not be used for adaptive complexity adjustment. If multiple price adjustment events enter the gateway concurrently, the system can record their start and end times separately according to the event identifier to avoid mutual overwriting; if the issuance is canceled due to business rule conflicts after policy verification, the end point can be recorded as the time of cancellation decision output, which can be used to evaluate the timeliness of local decision-making, without having to wait for a non-existent issuance action. At 19:32, the customer flow and inventory data of the refrigerated area were collected and timed. The local gateway performed graph collaborative analysis, gross profit verification and postponement judgment on beer A, ice cup B and nuts C, and generated a price update instruction in a short period of time after 19:32. The system records the time from the completion of data collection to the output of the command, which is used as the generation delay of the edge strategy in the current round. If the delay increases for several consecutive rounds, the complexity can be further reduced. If the delay remains stable, it means that the current edge-side analysis depth is still within an acceptable range. The purpose of this mechanism is to establish a unified and operable metric boundary for edge-side response speed, thereby providing a reliable basis for subsequent load adjustment and performance evaluation.

[0027] In a preferred embodiment of the present invention, when reducing the computational complexity of the lightweight rule engine, the adaptive feedback module performs the following operations: reducing the number of associated product levels in the product association graph referenced by the lightweight rule engine when calculating the cross-price tag collaborative price adjustment matching degree; or, truncating the calculation branches in the lightweight rule engine where the strategy collaboration weight is lower than a preset weight threshold.

[0028] This embodiment provides an adaptive complexity reduction mechanism for high-load scenarios. Specifically, in the aforementioned store business, after introducing a product graph, the edge gateway can understand the driving and substitution relationships between related products more precisely. However, the deeper the graph and the more branches it has, the greater the computational pressure will be. During normal, stable periods, such in-depth analysis is generally acceptable; however, during evening peak hours, holidays, or when price adjustments are triggered simultaneously in multiple regions, continuing to expand through too many levels and weakly related branches may lead to strategy generation lag. Therefore, this embodiment does not simply disable collaborative capabilities after detecting high latency, but rather hierarchically trims the analysis scope, retaining the part most valuable to current sales. Specifically, the first way to reduce complexity is to reduce the number of related product levels in the product association graph. The graph level can be understood as the influence circle that expands outward from the target product. Taking beer A as an example, the first layer may be directly linked products such as ice cup B and nuts C, the second layer may be side dishes that are further related to B, and the third layer may extend to products with weaker scenarios. In actual stores, the associated nodes that are less than the preset step size away from the target product map tend to reflect immediate purchasing behavior more directly; the associated nodes that are more than the preset level threshold have an exponentially decreasing influence weight within the preset time window and should be truncated first; therefore, when the system needs to speed up decision-making, the first or first two levels can be retained first, and the more distant levels can be temporarily excluded, so that the edge gateway can form an effective strategy more quickly. The second way to reduce complexity is to truncate computational branches whose weight coefficients are below a preset threshold. Here, the weight coefficient reflects the actual impact of a related product on the price action of the target product. If a branch is weak for a long time or has a sparse response in the current scenario, continuing to retain the branch will usually only increase the computational burden without significantly changing the result. The preset weight threshold can be a fixed constant initialized by the system, or it can be an adaptive threshold dynamically calculated based on the median of the weights of all activated associated edges in the current product association graph. For ease of understanding, a simplified sandbox representation can be used: Suppose that the current associated branches of beer A include B, C, D, and E, where B and C are strongly associated within the current window, D is moderately associated, and E is very weakly associated; if the system enters a high-latency state, branch E can be directly truncated, and if necessary, D can be demoted to the observation branch, leaving only B and C to participate in the matching degree calculation in this round; this essentially gives way to the key linkages to the secondary influences. This step embodies the concept of degradable operation in edge computing; that is, when device resources are scarce, the system does not pursue full branch analysis, but prioritizes timely response to the most important sales relationships; in this way, even under reduced load, stores can still maintain core linkage pricing capabilities, rather than completely losing local intelligence. As an exception handling mechanism, if the number of products that can participate in the linkage is too small after the level reduction, causing the collaborative strategy to lose its combination meaning, the system can revert to a single-tag conservative strategy for the target product. If the remaining weights after truncating the branches are all close to the threshold edge, the stable configuration of the previous round can be maintained to avoid frequent switching of graph depth and cause strategy jitter; if the high load state continues, the system can also queue up and postpone the price adjustment requests of non-urgent areas and set the immediate consumption area and the near-expiration cleanup area as priority calculation objects. At 19:35, the store's edge gateway simultaneously received multiple price linkage requests from the refrigerated display area, the bakery area, and the fresh food area, and recorded that the edge policy generation latency had been continuously increasing. At this point, the system performs a complexity reduction process on the beer A graph in the refrigerated section: originally, it would refer to the first-level relationship from A to B, C, and D, as well as the second-level complementary products extended from B. Now, it only retains the direct relationship between A and B and C; at the same time, it truncates the E branch, which currently has a very weak influence. After this trimming, the system can still quickly generate the core linkage strategy of beer A + ice cup B + nuts C, and is no longer slowed down by peripheral weakly related products. The purpose of this mechanism is to prioritize the real-time computing capabilities of high-value linkage relationships when edge gateway resources are limited, thereby achieving a dynamic balance between policy timeliness and collaborative analysis depth.

[0029] In a preferred embodiment of the present invention, it further includes: a multi-source data fusion module, used to receive the local environmental variable data and the inventory status data collected by the edge perception module, and to perform timestamp alignment processing on the local environmental variable data and the inventory status data with different sampling frequencies in an established multi-dimensional data buffer pool.

[0030] This embodiment provides a multi-source data fusion mechanism; specifically, in actual store deployments, the generation rhythms of different data sources are often inconsistent. Customer flow density data may be updated on a second-by-second or shorter cycle, dwell time usually needs to span a continuous observation window to form an effective value, and inventory consumption rate may come from shelf weight sensors, image recognition or sales outbound records, and its update frequency is different from the former two. If these data are directly entered into collaborative computing without time alignment, the system is prone to mixing the inventory status from a few minutes ago with the current second-level changes in passenger flow, resulting in misjudgment of the situation on site. Therefore, this embodiment sets up a multi-source data fusion module, first establishing a multi-dimensional data buffer pool on the edge side, and then performing alignment processing on data with different sampling frequencies under a unified time reference. In detail, the multi-dimensional data buffer pool can be understood as a local time-series container on the edge gateway, used to temporarily store data fragments from different sources such as customer flow, stay, and inventory; each piece of data carries its own collection time stamp when it enters the buffer pool. The fusion module merges these data into similar observation windows according to a unified timeline, so that a round of collaborative computing can use information from the same scene section as much as possible; For ease of understanding, a simplified sandbox approach can be used: Let the passenger flow data segments be F1, F2, and F3, the dwell time segments be T1 and T2, and the inventory rate segments be R1 and R2; since the three types of data update at different speeds, the system does not require them to be generated at exactly the same time, but rather aligns F2, T1, and R1 belonging to the same business window into the same set of scenario inputs. When entering the next window, F3, T2, and R2 are then combined to form the next set of inputs. This avoids the mismatch where the customer flow has already surged, but the inventory is still using earlier data or the dwell time has just been formed, and the customer flow has already reached the next peak. This alignment is particularly important in retail settings because there is often a brief delay in the transmission between local customer traffic and product consumption; customers approach the shelf first, then stop to compare, and then take the product before inventory changes are reflected. If the system does not perform time buffering and alignment at the edge, it may misjudge this natural chain as unrelated discrete events, thereby weakening the accuracy of collaborative pricing. As an exception handling mechanism, if a data source is missing in the current window, such as when the inventory sensor is temporarily offline, the multi-source data fusion module can decide whether to generate a downgraded input based on the most recent valid sample and the status of other data sources; if the missing time is too long, the data source will stop participating in the current window decision. If the time deviation between different data sources is too large and exceeds the preset alignment tolerance range, the system can mark the window as a low-confidence window and only allow the output of conservative strategies; if there is a sudden backlog in the buffer pool, the system can prioritize retaining the data of the latest window and high-priority areas, and discard outdated fragments to avoid the edge gateway losing its real-time response capability while waiting for complete data. Around 19:40, the customer flow counting device in the refrigerated area reports the change in customer flow every second, the dwell time analysis outputs the results every 30 seconds, and the inventory weight sensor updates the remaining quantity every 10 seconds. The multi-source data fusion module writes these data at different paces into the local buffer pool, and organizes the high-traffic segments, extended stay segments, and accelerated inventory consumption segments that belong to the same business window of 19:40 into the same input, and then hands them over to the collaborative computing module for processing; Since the data has been time-aligned, the system can more accurately determine that increased customer traffic is being converted into consumption, thereby generating a more relevant price tag strategy that fits the actual situation. The purpose of this mechanism is to eliminate the scenario misalignment caused by inconsistent sampling rhythms of different data sources, thereby achieving temporal consistency and decision stability of the input data required for edge-side collaborative pricing.

[0031] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. An electronic price tag management system based on edge computing, characterized in that, The system is deployed in an edge gateway device, which establishes a data transmission link with the electronic price tag via a wireless communication protocol; the system includes: The edge sensing module is used to collect local environmental variable data and inventory status data of target products within a preset target area, and to obtain the binding mapping relationship between the target products and the electronic price tags. The collaborative computing module is used to calculate the cross-price tag collaborative price adjustment matching degree based on the local environmental variable data and the inventory status data through a preset lightweight rule engine, and generate an initial collaborative pricing strategy including the target price. The boundary verification module is used to calculate the mandatory compliance rate of the business boundary of the initial collaborative pricing strategy based on preset business constraint rules. The mandatory compliance rate of the business boundary is the ratio of the number of business constraint rules to the total number of business constraint rules. If the mandatory compliance rate of the business boundary is less than a preset compliance rate threshold, the initial collaborative pricing strategy is modified until the mandatory compliance rate of the business boundary is not less than the compliance rate threshold; otherwise, it is confirmed as the target pricing strategy. The instruction issuing module is used to convert the target pricing strategy into a price update instruction and issue it to the corresponding electronic price tag based on the binding mapping relationship through the wireless communication protocol. An adaptive feedback module is used to calculate the edge strategy generation delay from the completion of collecting the local environmental variable data to the issuance of the price update instruction; if the edge strategy generation delay is greater than a preset delay threshold, the computational complexity of the lightweight rule engine is reduced; otherwise, it remains unchanged.

2. The electronic price tag management system based on edge computing according to claim 1, characterized in that, The edge sensing module includes: An environmental data acquisition unit is used to acquire passenger flow density data and user dwell time data of the preset target area as local environmental variable data. The inventory monitoring unit is used to acquire real-time consumption rate data of the target product as the inventory status data.

3. The electronic price tag management system based on edge computing according to claim 1, characterized in that, When calculating the cross-price tag collaborative price adjustment matching degree, the collaborative computing module performs the following operations: Obtain a pre-defined product relationship graph; Input the local environmental variable data and the inventory status data into the product association graph, and calculate the strategy synergy weight of the target product and the related products in the product association graph in the current state; The strategy coordination weights are normalized to calculate the cross-price tag coordinated price adjustment matching degree; and a set of linked tags is constructed based on the related products whose cross-price tag coordinated price adjustment matching degree is greater than a preset matching degree threshold. The initial coordinated pricing strategy containing the target price is generated based on the set of linked tags.

4. The electronic price tag management system based on edge computing according to claim 1, characterized in that, The computational complexity of the lightweight rule engine is characterized by a preset edge rule engine lightweight index, which is the sum of the product of the peak CPU utilization rate of the lightweight rule engine when it runs on the edge gateway device and the first preset weight factor, and the product of the average memory consumption ratio and the second preset weight factor.

5. The electronic price tag management system based on edge computing according to claim 1, characterized in that, The business constraints include a minimum target retention ratio threshold and a price fluctuation frequency cap. When the boundary verification module modifies the initial collaborative pricing strategy, it performs the following operations: Obtain the benchmark price parameters of the target product and the number of historical price changes within a preset time window, and use the number of historical price changes as the historical price fluctuation frequency; The corresponding target retention ratio is calculated based on the target price in the initial collaborative pricing strategy and the benchmark consideration parameter. In response to the target retention ratio being less than the minimum target retention ratio threshold, the target price in the initial collaborative pricing strategy is increased; In response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being greater than the upper limit of the price fluctuation frequency, a delayed activation flag is added to the initial collaborative pricing strategy to delay the issuance time of the price update instruction by the instruction issuance module. In response to the underlying asset retention ratio being greater than or equal to the minimum underlying asset retention ratio threshold and the historical price fluctuation frequency being less than or equal to the upper limit of the price fluctuation frequency, the initial collaborative pricing strategy is confirmed as the target pricing strategy.

6. The electronic price tag management system based on edge computing according to claim 1, characterized in that, The edge strategy generation delay is the time difference from the timestamp when the edge perception module completes the collection of the local environmental variable data to the timestamp when the instruction issuing module outputs the price update instruction.

7. The electronic price tag management system based on edge computing according to claim 3, characterized in that, When reducing the computational complexity of the lightweight rule engine, the adaptive feedback module performs the following operations: Reduce the number of associated product levels in the product association graph referenced by the lightweight rule engine when calculating the cross-price tag collaborative price adjustment matching degree; Alternatively, the calculation branch in the lightweight rule engine where the strategy collaboration weight is lower than a preset weight threshold can be truncated.

8. The electronic price tag management system based on edge computing according to claim 1, characterized in that, Also includes: The multi-source data fusion module is used to receive the local environmental variable data and the inventory status data collected by the edge perception module, and to perform timestamp alignment processing on the local environmental variable data and the inventory status data with different sampling frequencies in the established multi-dimensional data buffer pool.

Images