Electronic price tag management method based on hardware-independent architecture

Abstract

The invention relates to the technical field of Internet of Things, in particular to an electronic price tag management method based on a hardware-independent architecture, which comprises the following steps: S1, basic information of an electronic price tag is maintained in a digital store system, the electronic price tag is registered as an Alicloud IoT device, and the basic information comprises a hierarchical relationship among a shelf, a shelf layer, a guide rail, an RFID and the electronic price tag device; s2, receiving a commodity information updating request through the abstract interface layer, selecting a corresponding supplier adapter according to the ID of the electronic price tag equipment, and converting the commodity information into a standardized format irrelevant to hardware to obtain standardized commodity information; and S3, sending the standardized commodity information to an electronic price tag device through an Alicloud IoT platform, and monitoring a message processing state to ensure reliable transmission and final consistency of messages. Decoupling of a service system and specific hardware equipment is achieved, multi-supplier equipment can be managed in a unified mode, and reliable synchronization of mass price tag display content and background data is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to an electronic price tag management method based on a hardware-independent architecture. Background Technology

[0002] Electronic shelf labels (ESCs), as key digital devices in new retail scenarios, have been widely used in physical stores such as supermarkets, convenience stores, and digital retail outlets to replace traditional paper price tags and enable dynamic, real-time price updates. Traditional ESC systems typically consist of closed end-to-end solutions provided by hardware vendors, including dedicated communication base stations, proprietary device protocols, and bundled management software. Current technological practices face the following limitations and challenges: Strong hardware dependence and supplier lock-in: Once a store deploys electronic shelf label hardware from a certain brand, its back-end management system, communication protocols, and even operation and maintenance services are deeply tied to that supplier. If other brands or models of shelf labels need to be introduced, a separate system often needs to be deployed, resulting in data silos, fragmented management interfaces, and difficulties in unified control and smooth replacement of hardware devices due to incompatible protocols, causing stores to lose flexibility in procurement and operation and maintenance; The management complexity and costs of having multiple suppliers surge: Large chain stores often use electronic shelf label devices from multiple suppliers simultaneously due to procurement strategies, regional supply differences, or historical reasons. Under existing solutions, the merchandise system needs to be individually integrated and adapted for the APIs or protocols of different suppliers. Any change to product information (such as price or promotion) requires generating multiple copies of data and calling different interfaces to distribute them, resulting in high system complexity, high development and maintenance costs, and a high risk of data inconsistency due to differences in adaptation logic. The real-time and consistency issues of data synchronization: The core value of electronic shelf labels lies in ensuring real-time consistency between offline displayed prices and online business systems (such as ERP and promotion engines). Existing solutions based on proprietary protocols often lack efficient and reliable transmission and eventual consistency guarantee mechanisms when dealing with scenarios such as large-scale concurrent device updates, network fluctuations, and device offline. This can easily lead to customer complaints and compliance risks due to message loss, out-of-order delivery, or asynchronous device states, resulting in discrepancies between the displayed price and the final price. System expansion and maintenance difficulties: Closed systems struggle to leverage the elasticity, high availability, and rich PaaS service capabilities of cloud computing. As the number of connected devices increases, system scalability faces challenges. Furthermore, maintenance tasks such as fault diagnosis, device status monitoring, and log analysis become inefficient due to the closed nature of the system.

[0003] In recent years, although some solutions have attempted to improve connectivity by introducing general wireless communication technologies or by performing simple protocol conversions at the application layer, none of them have fundamentally solved the core problems of deep decoupling between hardware and business logic, unified management of multi-vendor equipment, and ensuring reliable data synchronization and eventual consistency in ultra-large-scale distributed environments.

[0004] Therefore, there is an urgent need for an innovative electronic shelf label management method that can build a hardware-independent unified management architecture, shield the differences in underlying hardware, decouple the business system from specific devices, and provide highly reliable and consistent data synchronization capabilities to meet the complex needs of digital store operations in the new retail era. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide an electronic shelf label management method based on a hardware-independent architecture, comprising the following steps: S1: Maintain the basic information of electronic shelf labels in the digital store system and register the electronic shelf labels as Alibaba Cloud IoT devices. The basic information includes the hierarchical relationship between shelves, shelf layers, guide rails, RFID, and electronic shelf label devices. S2: Receive product information update requests through the abstract interface layer, select the corresponding supplier adapter based on the electronic price tag device ID, and convert the product information into a hardware-independent standardized format to obtain standardized product information; S3: Send the standardized product information to the electronic price tag device through the Alibaba Cloud IoT platform, and monitor the message processing status to ensure reliable message transmission and eventual consistency.

[0006] Preferably, in step S1, maintaining the basic information of the electronic price tag in the digital store system includes: In the digital store system, a data model is established and stored, including the hierarchical relationship between shelves, shelf layers and guide rails, where each guide rail is configured with several RFID positioning points for physical location positioning. Based on the position coordinates of each RFID positioning point on the guide rail, the physical position of the electronic price tag installed on it is determined, and the unique identifier of each RFID positioning point is bound one by one with the Alibaba Cloud IoT device identifier corresponding to the electronic price tag. Establish and store a three-element mapping relationship between product code, shelf physical location information and electronic shelf label device identifier, and realize automatic positioning and matching of products to corresponding electronic shelf label devices through the three-element mapping relationship.

[0007] Preferably, in step S2, selecting the corresponding supplier adapter based on the electronic shelf label device ID includes: The system queries the pre-set device registry and obtains the mapped supplier identifier based on the electronic shelf label device ID carried in the product information update request. The device registry stores the mapping relationship between electronic shelf label device IDs and supplier identifiers. Based on the supplier identifier, a matching target supplier adapter is selected from several supplier adapters that have been instantiated in the system. Each supplier adapter encapsulates the protocol details for communicating with a specific brand or model of electronic shelf label hardware. The target supplier adapter's information processing method is invoked through the hardware-independent standard application programming interface defined in the abstract interface layer to process the product information update request.

[0008] Preferably, in step S2, converting the product information into a hardware-independent standardized format to obtain standardized product information includes: The original product information is formatted according to a predefined standardized data structure to generate intermediate data including product identification, price, promotional information and display template type identification. Based on the display template type identifier, the corresponding template rendering engine is invoked to generate a visual price tag image that conforms to the electronic price tag screen specifications based on the intermediate data; Upload the visualized price tag image to the cloud object storage service and obtain the image URL with access permissions; The image URL and necessary product information summary are encapsulated into standardized product information according to a preset, supplier-independent message protocol.

[0009] Preferably, in step S3, the standardized product information is sent to the electronic price tag device via the Alibaba Cloud IoT platform, including: The target supplier adapter encapsulates the standardized product information according to the sub-device message format defined by the Alibaba Cloud IoT platform; Through the established MQTT connection, the encapsulated message is published to the Alibaba Cloud IoT sub-device Topic corresponding to the target electronic price tag device; The electronic shelf label device subscribes to the sub-device Topic and receives messages, parses the image URL, downloads and displays the corresponding image; After completing the display update, the electronic price tag device returns an operation confirmation message to the digital store system through the Alibaba Cloud IoT platform.

[0010] Preferably, in step S3, monitoring the message processing status to ensure reliable message transmission and eventual consistency includes: Assign a globally unique message sequence number to each sent update message, and record its sending time, target device, and expected status; A timeout monitoring mechanism is activated. If no operation confirmation message is received from the electronic price tag device within a preset time, a message retransmission process is triggered. The message idempotency check is performed on the electronic price tag device, and duplicate update requests are identified and rejected based on the message sequence number. Periodically initiate status queries to the electronic shelf label device, compare the actual displayed content reported by the electronic shelf label device with the system's expected content, and if there is a discrepancy, automatically trigger the repair process to resend the standardized product information until a consistent state is achieved.

[0011] Preferably, the periodic device status synchronization task includes: According to the configured synchronization cycle, a status query command is sent to the online electronic shelf label device through the Alibaba Cloud IoT platform; Receive a response from the electronic price tag device, the response containing at least the product identifier or message serial number associated with the content currently displayed by the device; Compare the identifier or serial number reported by the electronic shelf label device with the latest product identifier or the last successfully sent message serial number that the electronic shelf label device should display, as recorded in the system. If the comparison is inconsistent, it is determined that the status is inconsistent, and the latest standardized product information is automatically added to the resend queue.

[0012] Preferably, it includes a supplier hot-swap mechanism: When it is necessary to integrate the electronic price tags of a new supplier, a new supplier adapter is developed according to the interface specifications defined in the abstract interface layer, and the supplier adapter is registered as a pluggable module in the system's adapter manager. The adapter manager dynamically loads or unloads the vendor adapter module at runtime without restarting the core service. By configuring the supplier identifier associated with each electronic shelf label device through the management interface, the system dynamically routes requests to the corresponding adapter module based on the configuration.

[0013] Preferably, it also includes a multi-supplier parallel processing mechanism: When the system manages equipment from multiple suppliers simultaneously, the received product information update requests are grouped according to the supplier to which the target supplier's equipment belongs; Allocation of independent processing threads or queues to requests from different vendor groups enables parallel processing. The system maintains a unified monitoring view, aggregating and displaying the overall status and processing indicators of all supplier equipment; When a communication link or adapter from a particular supplier fails, the system implements fault isolation to prevent disruption to the normal message delivery of other suppliers' devices.

[0014] Preferably, it also includes a full-link anomaly handling mechanism: If the supplier adapter fails to process, the system will attempt to call the backup adapter pre-configured for the device, or record the failure status and issue an alarm. If a connection interruption with the Alibaba Cloud IoT platform is detected, the standardized product information to be sent will be persisted to a local queue and resent in order after the connection is restored. When an electronic shelf label device is detected as offline for an extended period, its status is marked; once the device is back online, the latest product information will be synchronized first. The system records a full-link log from request reception, adapter processing, message delivery to device response, and supports error tracking and location based on a unique request ID.

[0015] Compared with the prior art, the beneficial effects of the present invention are: This invention achieves the abstraction of physical hardware into standardized cloud-based logical devices by maintaining basic information of electronic price tags decoupled from hardware within the digital store system and uniformly registering them as Alibaba Cloud IoT devices. This architecture allows the upper-layer merchandise management system to interact with standardized Alibaba Cloud IoT device identifiers without needing to be aware of specific hardware models and suppliers. This effectively solves the supplier lock-in problem caused by strong hardware dependence in traditional solutions, significantly improves system compatibility and scalability, and reduces system modification costs caused by changes in hardware selection. This invention receives requests through an abstract interface layer and automatically routes them to the corresponding supplier adapter based on the device ID, converting product information into a hardware-independent standardized format. This mechanism achieves complete decoupling of business logic and hardware protocols, allowing the digital store system to develop and maintain only one unified set of business logic and interfaces. When a store uses equipment from multiple suppliers simultaneously, the system can automatically adapt without developing separate interface modules or generating multiple sets of data for each supplier. This greatly simplifies the system architecture, reduces the complexity of development and maintenance, and fundamentally avoids the risk of data inconsistency caused by multiple systems operating in parallel. This invention utilizes the Alibaba Cloud IoT platform for reliable transmission of standardized messages and implements a full-link monitoring and consistency guarantee mechanism, including message serialization, timeout retransmission, idempotency verification, and periodic status synchronization. This solution fully leverages the high availability, high concurrency, and stable connection capabilities of the cloud platform to ensure reliable message delivery and sequential processing for massive numbers of price tag devices in high-concurrency update scenarios. Simultaneously, through proactive status querying and comparison repair, it achieves eventual consistency between the electronic price tag display content and the expected state of the backend system, effectively solving the industry pain point of price tag inconsistencies caused by network fluctuations and device offline, significantly improving the reliability of price management and customer trust. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0017] Figure 1 This is a flowchart of an electronic price tag management method based on a hardware-independent architecture according to the present invention; Figure 2 This is a sequence diagram showing the changes to the electronic price tag device of this invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Obviously, the described embodiments are only some, not all, of the embodiments described in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0019] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a” and “an” used herein, and “the”, may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0020] First Embodiment Please see Figure 1 As shown in the figure, this embodiment provides an electronic shelf label management method based on a hardware-independent architecture, which includes the following steps: S1: Maintain the basic information of electronic shelf labels in the digital store system and register the electronic shelf labels as Alibaba Cloud IoT devices. The basic information includes the hierarchical relationship between shelves, shelf layers, guide rails, RFID, and electronic shelf label devices. Specifically, in this embodiment, a shelf belongs to the store and is used to display goods. Its main attribute is the shelf code. A shelf layer belongs to the shelf. A shelf has multiple layers, and the display situation of each layer is different. It is mainly used to define the shelf layer number. A guide rail is installed on the shelf and is used to estimate the price tag and bind the relationship between the price tag and the goods. The guide rail belongs to the shelf layer. A shelf layer has one or more guide rails. The guide rail has attributes such as length, RFID spacing, and first RFID distance. The RFID list on the guide rail needs to be defined. RFID is used to locate the position on the guide rail. When a price tag is installed on the guide rail, it will automatically obtain the corresponding RFID as the unique identifier of the price tag. The electronic shelf label can be found on the guide rail through RFID. The electronic shelf label is a device corresponding to the Alibaba Cloud IoT model. In the digital store system, it is attached with RFID attributes.

[0021] Preferably, in step S1, maintaining the basic information of the electronic price tag in the digital store system includes: In the digital store system, a data model is established and stored, including the hierarchical relationship between shelves, shelf layers and guide rails, where each guide rail is configured with several RFID positioning points for physical location positioning. Based on the position coordinates of each RFID positioning point on the guide rail, the physical location of the electronic price tag installed on it is determined, and the unique identifier of each RFID positioning point is bound to the Alibaba Cloud IoT device identifier corresponding to the electronic price tag. This device identifier uniquely represents an electronic price tag. Establish and store a three-element mapping relationship of "product code - shelf physical location information - electronic shelf label device identifier" to achieve automatic positioning and matching of products to corresponding electronic shelf label devices.

[0022] S2: Receive product information update requests through the abstract interface layer, select the corresponding supplier adapter based on the electronic shelf label device ID, and convert the product information into a hardware-independent standardized format to obtain standardized product information. Specifically, in this embodiment, the interaction between the electronic shelf label supplier and Alibaba Cloud IoT devices adopts a "gateway / sub-device" mode. The main access process is as follows: Each gateway only needs one MQTT connection. The gateway itself has a device identity, and the gateway uses MQTT for access; the gateway subscribes to topics (such as device network entry / exit replies, message push topics), and the gateway initiates an MQTT subscribe. Subscribe to topics and set corresponding callback handling methods; users do not need to create these two topics in the console in advance. The gateway requests to join the virtual network (Topic: / sys / ${gw_productKey} / ${gw_deviceName} / bridge / online request payload); sub-devices join the network, which is usually triggered when the sub-device first connects (Topic: / sys / ${gw_productKey} / ${gw_deviceName} / bridge / online); sub-devices go offline (Topic: / sys / ${gw_productKey} / ${gw_deviceName} / bridge / offline); sub-device uplink messages (Topic: / sys / ${gw_productKey} / ${gw_deviceName} / bridge / post); sub-device downlink messages (Topic: / sys / ${gw_productKey} / ${gw_deviceName} / bridge / push).

[0023] Ideally, gateway subscription topics further include: The gateway sends a reply request ( / sys / gw_pk / gw_dn / bridge / online_reply) to the network access request server. The gateway sends replies to requests for devices to leave the network and go offline, in the format / sys / gw_pk / gw_dn / bridge / offline_reply. The cloud will push messages to sub-devices and gateways via the topic / sys / gw_pk / gw_dn / bridge / push.

[0024] Preferably, in step S2, selecting the corresponding supplier adapter based on the electronic shelf label device ID includes: The system queries the pre-set device registry and retrieves the mapped supplier identifier based on the electronic shelf label device ID carried in the product information update request. The device registry stores the mapping relationship between electronic shelf label device IDs and supplier identifiers. Based on the supplier identifier obtained from the query, select the matching target supplier adapter from several supplier adapters that have been instantiated in the system. Each supplier adapter encapsulates the protocol details for communicating with a specific brand or model of electronic shelf label hardware. By using the hardware-independent standard application programming interface (API) defined by the abstract interface layer, the information processing methods of the target supplier adapter are called to handle product information update requests. The standard interface predefines device-independent product information processing operation specifications, which include information format conversion rules, data validity verification logic, and device control command generation standards.

[0025] Preferably, in step S2, converting the product information into a hardware-independent standardized format to obtain standardized product information includes: The original product information is formatted according to a predefined standardized data structure to generate intermediate data including product identifier, price, promotional information and display template type identifier. Specifically, in this embodiment, the intermediate data also includes product name, promotional information (including promotion type, discount amount / discount rate, effective time range) and display template type identifier fields. Each field has a predefined uniform data type and length constraint. According to the display template type identifier, the corresponding template rendering engine is matched and called, and a visual price tag image that conforms to the electronic price tag screen specifications is generated based on intermediate data. Specifically, in this embodiment, the template engine has multiple sets of layout rules adapted to the electronic price tag display specifications, and dynamically generates a visual display image containing a price display area, promotional labels and key product information based on the product's base price and promotional rules information. The visual price tag image is uploaded to the cloud object storage service to obtain the image URL with access permissions. Specifically, in this embodiment, the visual display image is processed according to a preset compression format (including image resolution, color depth, and file format) and then uploaded to the designated storage space of the Alibaba Cloud OSS storage service. The publicly accessible image link with a preset validity period is obtained through the interface provided by Alibaba Cloud OSS. The image URL and necessary product information summary are encapsulated into standardized product information according to a preset, supplier-independent message protocol. Specifically, in this embodiment, the image link is associated with and encapsulated with the core fields (unique product ID, product name, and promotional rule information) in the standardized product display information data structure to form a hardware-independent standardized message format. The message format presets a unified field order, data separator, and check bit to ensure that different supplier adapters can parse and process according to unified rules.

[0026] S3: Sends standardized product information to electronic shelf label devices via the Alibaba Cloud IoT platform and monitors message processing status to ensure reliable message transmission and eventual consistency. For details, please refer to [link to relevant documentation]. Figure 2 As shown, the system calculates the product price image on the electronic shelf label based on real-time data, uploads the generated image to Alibaba Cloud OSS, obtains the image link address, and sends a device message to Alibaba Cloud IoT, carrying the product price image link. The electronic shelf label supplier system obtains the change of the electronic shelf label through the downlink message of the sub-device, retrieves the image link address in the message, and displays it on the corresponding electronic shelf label. After successful processing, the electronic shelf label supplier notifies Alibaba Cloud IoT of the processing status through the uplink message of the sub-device. After receiving the message that the electronic shelf label has been processed, the digital store marks the display change of the electronic shelf label as completed. Because it adopts the Alibaba Cloud IoT integration method, both the electronic shelf label supplier and the digital store develop additional business rule protocols for the digital store end for the Alibaba Cloud IoT protocol. Alibaba Cloud IoT has a scale of hundreds of millions of devices, automatically expands, and ensures connection stability. The device message processing time to the platform is within 50ms. In addition, the electronic shelf label processes messages according to time sequence, that is, the final result is based on the most recent change, achieving product data synchronization with some delay and consistency.

[0027] Please see Figure 2 As shown, in step S3, standardized product information is sent to the electronic shelf label device via the Alibaba Cloud IoT platform, including: The target supplier adapter encapsulates standardized product information according to the sub-device message format (MQTT) defined by the Alibaba Cloud IoT platform. Specifically, in this embodiment, the target supplier adapter calls the built-in protocol conversion module to convert the hardware-independent standardized message format into the standard communication protocol format supported by the Alibaba Cloud IoT platform. The standard communication protocol includes the MQTT protocol or the HTTP / 2 protocol. During the conversion process, message header encapsulation (including device identifier, message type, and timeout), payload encryption processing, and verification code generation are completed according to the Alibaba Cloud IoT device access specifications. Through the established MQTT connection, the encapsulated message is published to the Alibaba Cloud IoT sub-device Topic corresponding to the target electronic shelf label device. Specifically, in this embodiment, based on the registration information of the electronic shelf label device, the gateway / sub-device access mode of the Alibaba Cloud IoT platform is adopted. The registered gateway device acts as a message forwarding agent, and sends the converted standardized protocol message to the sub-device Topic corresponding to the specified electronic shelf label device. The gateway device has completed the association binding and permission authorization with the sub-device in advance to ensure the directionality and security of message transmission. The electronic shelf label device subscribes to sub-device topics and receives messages. After parsing the image URL, it downloads and displays the corresponding image. Specifically, in this embodiment, after receiving a message through a preset communication link, the electronic shelf label device first verifies the validity of the message verification code. After successful verification, it parses the image link and core product information in the message, and downloads the corresponding visual display image based on the image link via the HTTPS protocol. During the download process, image integrity verification is performed (based on MD5 checksum comparison). After successful verification, the electronic shelf label device adapts the image size according to its own hardware display specifications, updates the screen display content, and caches the core product information. After completing the display update, the electronic shelf label device returns an operation confirmation message to the digital store system through the Alibaba Cloud IoT platform. Specifically, in this embodiment, after completing the display update, the electronic shelf label device generates a confirmation response message containing the processing status code (success / failure), processing timestamp, current device battery level, and network signal strength. After being encapsulated in the same Alibaba Cloud IoT standard protocol format, the message is fed back to the gateway device through the sub-device Topic, and then forwarded to the Alibaba Cloud IoT platform by the gateway device, thus completing the closed-loop feedback of the message processing result.

[0028] Preferably, in step S3, monitoring the message processing status to ensure reliable message transmission and eventual consistency includes: Each sent update message is assigned a globally unique message sequence number, and its sending time, target device, and expected status are recorded. Specifically, in this embodiment, a unique message sequence number is generated for each standardized message sent through the Alibaba Cloud IoT platform. The message sequence number is generated using a combination rule of "electronic price tag device ID + millisecond-level timestamp + 6-digit random check code" to ensure global uniqueness. At the same time, the core message information is recorded in the system's built-in message status table, including the message sequence number, target device ID, message sending time, expected execution result, current transmission status (pending confirmation / confirmed / retrying / failed), and associated product information summary. A timeout monitoring mechanism is activated. If no operation confirmation message is received from the electronic price tag device within a preset time, a message retransmission process is triggered. Specifically, in this embodiment, a preset message confirmation timeout threshold (configurable range of 1-30 seconds) is set up, and an independent timeout monitoring thread is started to monitor the confirmation response status of each message in real time. If no confirmation response message is received from the electronic price tag device within the timeout threshold, a message retry mechanism is triggered. The number of retries is preset to 3-5 times (supports dynamic system configuration). The retry interval adopts an exponential backoff strategy (e.g., the first interval is 1 second, the second interval is 2 seconds, the third interval is 4 seconds, and the subsequent interval is kept to a maximum of 8 seconds). When the maximum number of retries is reached and no confirmation response is still received, the message status is marked as failed and an alarm message is pushed to the management terminal. Message idempotency verification is implemented on the electronic shelf label device side, identifying and rejecting duplicate update requests based on message sequence numbers. Specifically, in this embodiment, message idempotency checking is implemented based on a combination identifier of message sequence number + product unique ID: an idempotency cache is built into the electronic shelf label device side (the cache validity period is consistent with the message timeout threshold). When a message is received, it is first checked whether the combined identifier already exists in the cache; if it already exists, a success response is returned directly to avoid duplicate processing; before retrying sending on the system side, the message status table is also queried, and retry operations are only performed on messages in the pending confirmation or retry status to prevent duplicate sending; The system periodically initiates status queries to the electronic shelf label devices, comparing the actual displayed content reported by the devices with the system's expected content. If discrepancies are found, a repair process is automatically triggered, resending standardized product information until consistency is achieved. Specifically, in this embodiment, a periodic device status synchronization task is configured. The system periodically sends status query commands to the electronic shelf label devices. Upon receiving the commands, the devices report the currently displayed message sequence number, the product's unique ID, and a summary of the displayed content (an MD5 value generated based on product information and image links). The system compares the reported information with the locally stored expected message data. If discrepancies are found, a message resending process is automatically triggered to ensure the final consistency between the actual displayed content of the electronic shelf label and the system's expected content.

[0029] Preferably, the periodic device status synchronization task includes: According to the configured synchronization cycle, a status query command is sent to the online electronic shelf label devices through the Alibaba Cloud IoT platform. Specifically, in this embodiment, according to the configurable preset synchronization cycle (configuration range is 5-30 minutes, and supports differentiated settings according to store area, device brand or shelf type), the list of electronic shelf label devices currently in the online status query state is filtered through the device online status query interface of the Alibaba Cloud IoT platform, and a status query command is sent to each device in the list. The query command carries the system identifier and query timestamp for device identity verification and request deduplication. The system receives a response from the electronic shelf label device. The response includes at least the product identifier or message serial number associated with the currently displayed content. Specifically, in this embodiment, after receiving and verifying the status query command, the electronic shelf label device reports the core information currently being displayed, including but not limited to: the unique serial number of the currently displayed message, the unique ID of the associated product, a summary of the displayed content, and the current display mode of the device. After receiving the reported information, the system retrieves the expected product information (including the expected message serial number, the unique ID of the target product, and a summary of the expected displayed content) for the corresponding device from the target product information database of the digital store system. The system compares the identifier or serial number reported by the electronic shelf label device with the latest product identifier or the last successfully sent message serial number recorded in the system. Specifically, in this embodiment, the system compares the actual display information reported by the device with the retrieved expected product information in multiple dimensions, including: consistency of product unique ID, consistency of message serial number, and consistency of display content summary. If any dimension is inconsistent, it is determined that the display content is deviated, and the message resending mechanism is automatically triggered to resend the standardized product information. After resending, the status query is performed again at a preset verification interval (1-5 seconds) until the information reported by the device is completely consistent with the expected information, or the maximum number of retries is reached (after reaching the maximum number of retries, it is marked as a synchronization failure and an alarm is triggered). If the comparison is inconsistent, it is determined to be a state inconsistency, and the latest standardized product information is automatically added to the retransmission queue. Specifically, in this embodiment, all inconsistency events found during each state synchronization check are fully logged. The logged content includes: device ID, store number, shelf location information, timestamp of inconsistency occurrence, key fields of expected product information, actual reported information of the device, inconsistency type (product information mismatch / abnormal message sequence number / broken image link / incorrect display mode), handling measures, and final processing results. The log data is stored in the system operation and maintenance database, which supports statistical analysis by time range, device type, and inconsistency type, providing data support for system protocol adaptation and optimization, device fault location, and operation and maintenance strategy adjustment.

[0030] Preferably, it includes a supplier hot-swap mechanism: When it is necessary to integrate a new supplier's electronic shelf label, a new supplier adapter is developed according to the interface specifications defined in the abstract interface layer. This supplier adapter is then registered as a pluggable module in the system's adapter manager. Specifically, in this embodiment, when it is necessary to integrate a new brand electronic shelf label supplier, an adapter module corresponding to the new supplier is implemented based on the adapter development specifications preset in the abstract interface layer. The adapter module must be compatible with standardized message format parsing, hardware protocol conversion, and device control command generation functions, and must not require modification of the core business logic of the digital store system. The developed adapter module is packaged into an independently deployable plug-in package and submitted to the adapter manager through the system's preset adapter registration interface. At the same time, metadata information such as supplier identifier, compatible device model, and supported display specifications is entered. The adapter manager dynamically loads or unloads vendor adapter modules at runtime without restarting the core service. Specifically, in this embodiment, the adapter manager has a built-in plug-in management framework that supports dynamic loading and unloading of adapter instances based on vendor identifiers: when the system starts, it automatically scans registered adapter plug-in packages and loads them into the runtime memory to generate callable adapter instances; when a vendor stops cooperating or needs to upgrade its adapter, the adapter manager issues an uninstallation command to release the resources occupied by the corresponding adapter instance without interrupting the overall system operation and without affecting the normal operation of other vendor adapters. By configuring the supplier identifier associated with each electronic shelf label device through the management interface, the system dynamically routes requests to the corresponding adapter module based on the configuration. Specifically, in this embodiment, the digital store system provides a visual configuration management interface, through which managers can query the list of registered suppliers and enable or disable the adapter function corresponding to a specific supplier identifier based on store operation needs: when enabled, the adapter manager includes the electronic shelf label device adapted by that supplier in the normal message processing queue; when disabled, the system automatically stops sending new messages to the device corresponding to that supplier and marks the relevant device status as pending switching. Registered electronic shelf label devices support migration between different supplier adapters: by modifying the supplier identifier corresponding to the device ID in the device registry through the configuration management interface, the adapter manager detects the change in mapping relationship in real time and automatically routes the message processing request of that device to the new supplier adapter; during the migration process, the system uses the original standardized message format and transmission mechanism without modifying the core business logic such as product information management and message sending, ensuring that the device migration does not affect the continuity of store shelf label display.

[0031] Preferably, it also includes a multi-supplier parallel processing mechanism: When the system manages devices from multiple suppliers simultaneously, the received product information update requests are grouped according to the supplier to which the target supplier's device belongs. Specifically, in this embodiment, when the digital store system connects to electronic shelf label devices from multiple suppliers at the same time, after receiving a product information update request, the system automatically groups all pending update requests according to the supplier identifier based on the "electronic shelf label device ID - supplier identifier" mapping relationship stored in the device registry. Each supplier corresponds to an independent request processing queue, and the queue is sorted according to the request reception timestamp. Independent processing threads or queues are allocated to requests from different supplier groups to achieve parallel processing. Specifically, in this embodiment, the system starts a multi-threaded parallel processing framework and allocates an independent thread pool to the request processing queue of each supplier (the thread pool size can be dynamically adjusted according to the number of supplier devices). Each thread pool performs operations such as message format conversion, protocol adaptation, and IoT platform distribution in parallel. The request processing processes of different suppliers do not occupy resources, avoiding the blockage of the overall processing link by a large number of requests from a single supplier, and improving the overall concurrent processing efficiency of the system. The system maintains a unified monitoring view, aggregating and displaying the overall status and processing indicators of all supplier equipment. Specifically, in this embodiment, the system maintains a globally unified processing status view, which integrates the status information of electronic price tag equipment corresponding to all suppliers, including equipment online status, message sending progress (pending / processing / completed / failed), the most recent synchronization time, fault alarm details, etc. The system displays the operating status of each supplier's equipment through standardized monitoring indicators (such as processing success rate and average response time); at the same time, it provides a consistent visual management interface, allowing administrators to perform operations such as equipment status query, message resending, and fault troubleshooting without distinguishing between supplier types. When a communication link or adapter of a certain supplier fails, the system implements fault isolation to avoid affecting the normal message delivery of other supplier devices. Specifically, in this embodiment, a supplier-level fault isolation mechanism is implemented: each supplier is allocated an independent resource pool (including thread resources, network connection resources, and storage cache resources), and supplier-level abnormal circuit breaker thresholds (such as the number of consecutive failures and processing timeout rate) are configured; when a supplier's adapter fails (such as protocol parsing failure or IoT connection interruption) or reaches the circuit breaker threshold, the system automatically marks the supplier's request processing queue as isolated, suspends the processing of new requests and triggers an alarm, while not affecting the normal operation of other supplier thread pools; after the fault is recovered, the system verifies the availability of the supplier's adapter through a preset health check mechanism, and automatically releases the isolation and resumes request processing after confirming that it is normal.

[0032] Preferably, it also includes a full-link anomaly handling mechanism: If the supplier adapter fails to process, the system attempts to call the backup adapter pre-configured for the device, or records the failure status and issues an alarm. Specifically, in this embodiment, there is a fallback mechanism for supplier adapter processing failures: a primary supplier identifier and a corresponding backup supplier identifier are pre-configured in the device registry for the electronic price tag device (supporting 1-2 levels of backup configuration). When the primary supplier adapter fails to process (including protocol conversion failure, instruction generation failure, and response timeout), the system automatically triggers the adapter switching mechanism, queries the backup supplier identifier of the device, and calls the corresponding backup adapter to re-execute the product information processing flow. If there is no backup adapter or the backup adapter processing still fails, the device processing status is marked as adapter abnormal and an alarm is pushed to the management terminal. If a connection interruption with the Alibaba Cloud IoT platform is detected, the standardized product information to be sent is persisted to a local queue. Once the connection is restored, the messages are resent in order. Specifically, in this embodiment, the Alibaba Cloud IoT connection exception cache is implemented: the system has a built-in local persistent message queue (based on disk storage, supporting breakpoint resume) that monitors the connection status with the Alibaba Cloud IoT platform in real time. When a connection interruption is detected (including network timeout, authentication failure, and platform service unavailability), all standardized messages to be processed are automatically stored in the local queue. The queue is sorted according to message priority (based on the urgency of product updates), and a connection retry mechanism is initiated (the retry interval adopts an exponential backoff strategy: 1 second / 3 seconds / 5 seconds / 10 seconds cycle). Once the connection is restored, the messages are resent in batches according to the queue order to ensure that no messages are lost. When an electronic shelf label device is detected as offline for an extended period, its status is marked. Once the device is back online, the latest product information is synchronized first. Specifically, in this embodiment, the electronic shelf label device offline processing involves: a preset offline threshold (configurable range of 5-30 minutes) and periodic acquisition of the device's online status via the Alibaba Cloud IoT platform; when the device's continuous offline time reaches the threshold, the system marks its status as offline abnormal and records the offline start time and the last communication time; when the device re-enters the network and reports its online status, the system automatically queries the latest product information and unfinished message tasks corresponding to the device, prioritizing the distribution of the latest standardized product information to ensure rapid synchronization to the desired display status after the device re-enters the network. The system records end-to-end logs from request reception, adapter processing, message delivery to device response, and supports error tracking and location based on unique request IDs. Specifically, in this embodiment, the end-to-end operation logs and error tracking are as follows: The system records end-to-end operation logs from receiving product information update requests, adapter processing, message delivery, device response to exception triggering. The logs include a unique request ID, device ID, supplier identifier, operation timestamp, processing steps, data summary, and error code (a pre-defined unified error code system distinguishes between adapter errors, IoT connection errors, device errors, data format errors, etc.). The logs are stored in a structured format in a designated database and support multi-dimensional queries by request ID, device ID, error type, and time range. An error tracking link is also provided, linking the end-to-end logs through the unique request ID, facilitating administrators in locating the problem area, analyzing the cause of the failure, and supporting system maintenance and optimization.

[0033] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for managing electronic shelf labels based on a hardware-independent architecture, characterized in that, Includes the following steps: S1: Maintain the basic information of electronic shelf labels in the digital store system and register the electronic shelf labels as Alibaba Cloud IoT devices. The basic information includes the hierarchical relationship between shelves, shelf layers, guide rails, RFID, and electronic shelf label devices. S2: Receive product information update requests through the abstract interface layer, select the corresponding supplier adapter based on the electronic price tag device ID, and convert the product information into a hardware-independent standardized format to obtain standardized product information; S3: Send the standardized product information to the electronic price tag device through the Alibaba Cloud IoT platform, and monitor the message processing status to ensure reliable message transmission and eventual consistency.

2. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, In step S1, the basic information of the electronic price tag is maintained in the digital store system, including: In the digital store system, a data model is established and stored, including the hierarchical relationship between shelves, shelf layers and guide rails, where each guide rail is configured with several RFID positioning points for physical location positioning. Based on the position coordinates of each RFID positioning point on the guide rail, the physical position of the electronic price tag installed on it is determined, and the unique identifier of each RFID positioning point is bound one by one with the Alibaba Cloud IoT device identifier corresponding to the electronic price tag. Establish and store a three-element mapping relationship between product code, shelf physical location information and electronic shelf label device identifier, and realize automatic positioning and matching of products to corresponding electronic shelf label devices through the three-element mapping relationship.

3. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, In step S2, the corresponding supplier adapter is selected based on the electronic shelf label device ID, including: The system queries the pre-set device registry and obtains the mapped supplier identifier based on the electronic shelf label device ID carried in the product information update request. The device registry stores the mapping relationship between electronic shelf label device IDs and supplier identifiers. Based on the supplier identifier, a matching target supplier adapter is selected from several supplier adapters that have been instantiated in the system. Each supplier adapter encapsulates the protocol details for communicating with a specific brand or model of electronic shelf label hardware. The target supplier adapter's information processing method is invoked through the hardware-independent standard application programming interface defined in the abstract interface layer to process the product information update request.

4. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, In step S2, the product information is converted into a hardware-independent standardized format to obtain standardized product information, including: The original product information is formatted according to a predefined standardized data structure to generate intermediate data including product identification, price, promotional information and display template type identification. Based on the display template type identifier, the corresponding template rendering engine is invoked to generate a visual price tag image that conforms to the electronic price tag screen specifications based on the intermediate data; Upload the visualized price tag image to the cloud object storage service and obtain the image URL with access permissions; The image URL and necessary product information summary are encapsulated into standardized product information according to a preset, supplier-independent message protocol.

5. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, In step S3, the standardized product information is sent to the electronic price tag device via the Alibaba Cloud IoT platform, including: The target supplier adapter encapsulates the standardized product information according to the sub-device message format defined by the Alibaba Cloud IoT platform; Through the established MQTT connection, the encapsulated message is published to the Alibaba Cloud IoT sub-device Topic corresponding to the target electronic price tag device; The electronic shelf label device subscribes to the sub-device Topic and receives messages, parses the image URL, downloads and displays the corresponding image; After completing the display update, the electronic price tag device returns an operation confirmation message to the digital store system through the Alibaba Cloud IoT platform.

6. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, In step S3, the message processing status is monitored to ensure reliable message transmission and eventual consistency, including: Assign a globally unique message sequence number to each sent update message, and record its sending time, target device, and expected status; A timeout monitoring mechanism is activated. If no operation confirmation message is received from the electronic price tag device within a preset time, a message retransmission process is triggered. The message idempotency check is performed on the electronic price tag device, and duplicate update requests are identified and rejected based on the message sequence number. Periodically initiate status queries to the electronic shelf label device, compare the actual displayed content reported by the electronic shelf label device with the system's expected content, and if there is a discrepancy, automatically trigger the repair process to resend the standardized product information until a consistent state is achieved.

7. The electronic shelf label management method based on a hardware-independent architecture according to claim 6, characterized in that, The periodic device status synchronization task includes: According to the configured synchronization cycle, a status query command is sent to the online electronic shelf label device through the Alibaba Cloud IoT platform; Receive a response from the electronic price tag device, the response containing at least the product identifier or message serial number associated with the content currently displayed by the device; Compare the identifier or serial number reported by the electronic shelf label device with the latest product identifier or the last successfully sent message serial number that the electronic shelf label device should display, as recorded in the system. If the comparison is inconsistent, it is determined that the status is inconsistent, and the latest standardized product information is automatically added to the resend queue.

8. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, Including supplier hot-swap mechanisms: When it is necessary to integrate the electronic price tags of a new supplier, a new supplier adapter is developed according to the interface specifications defined in the abstract interface layer, and the supplier adapter is registered as a pluggable module in the system's adapter manager. The adapter manager dynamically loads or unloads the vendor adapter module at runtime without restarting the core service. By configuring the supplier identifier associated with each electronic shelf label device through the management interface, the system dynamically routes requests to the corresponding adapter module based on the configuration.

9. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, It also includes a multi-vendor parallel processing mechanism: When the system manages equipment from multiple suppliers simultaneously, the received product information update requests are grouped according to the supplier to which the target supplier's equipment belongs; Allocation of independent processing threads or queues to requests from different vendor groups enables parallel processing. The system maintains a unified monitoring view, aggregating and displaying the overall status and processing indicators of all supplier equipment; When a communication link or adapter from a particular supplier fails, the system implements fault isolation to prevent disruption to the normal message delivery of other suppliers' devices.

10. The electronic shelf label management method based on a hardware-independent architecture according to claim 1, characterized in that, It also includes a full-link anomaly handling mechanism: If the supplier adapter fails to process, the system will attempt to call the backup adapter pre-configured for the device, or record the failure status and issue an alarm. If a connection interruption with the Alibaba Cloud IoT platform is detected, the standardized product information to be sent will be persisted to a local queue and resent in order after the connection is restored. When an electronic shelf label device is detected as offline for an extended period of time, its status is marked. Once the equipment is back online, prioritize synchronizing the latest product information; The system records a full-link log from request reception, adapter processing, message delivery to device response, and supports error tracking and location based on a unique request ID.

Images