A long strip electronic price tag cloud management and OTA remote upgrading method and system

Abstract

The application provides a long strip-shaped electronic price tag cloud management and OTA remote upgrading method and system, the method comprising: receiving a cloud OTA upgrade package, establishing an installation dependency relationship and marking an irreversible installation operation; selecting a recovery interruption breakpoint covering the irreversible installation path, constructing a rollback interruption shadow state and a continue interruption shadow state; running a candidate upgrade program with the two types of interruption shadow states, intercepting page erasing, starting entry modification and recovery record updating operations; verifying bidirectional recovery capability according to side effect causality, checking a continue entry or a compensation sequence of each execution prefix, and generating a recovery responsibility handover voucher after all the checks pass. The bidirectional recovery capability of the candidate upgrade program to the irreversible installation interruption state is verified before the existing upgrade program exits, the official installation is constrained by the recovery responsibility handover voucher, the problem of early transfer of recovery responsibility is solved, and the recovery reliability and version state consistency after OTA upgrade interruption are improved.

Description

Technical Field

[0001] This invention relates to the field of software update technology, and in particular to a method and system for cloud management and OTA remote upgrade of elongated electronic price tags. Background Technology

[0002] When performing OTA (Over-The-Air) remote upgrades on elongated electronic shelf labels, the cloud management platform typically sends an OTA upgrade package consisting of candidate application firmware and candidate upgrade programs to the electronic shelf label. After verifying the upgrade package, the current upgrade program on the electronic shelf label sequentially performs page erasure, page writing, startup entry modification, and formal recovery record update. If a power outage or processor reset occurs during the installation process, the current upgrade program determines the installation progress based on the formal recovery record and continues the installation or restores the original version.

[0003] When this OTA upgrade also involves updating the existing upgrade program itself, the installation may be interrupted at a stage where the old page has been erased but the new page has not been fully written, the startup entry points to the target version but the target version has not been verified, or the official recovery record has adopted a new format but the existing upgrade program is still parsing it in the old format. At this time, the page content, startup entry, and official recovery record may be in different installation states. The existing upgrade program may lose its recovery capability because the old page has been overwritten or it cannot parse the new recovery record; the candidate upgrade program may also be unable to recognize the installation progress left by the existing upgrade program, and cannot determine whether to continue installation or restore to the stable state before the upgrade, resulting in incomplete page content, indeterminate startup version, incorrect recovery entry selection, or even repeated resets or inability to reconnect to the cloud.

[0004] The reason for the above problems is that when the upgrade program is replaced, the responsibility for recovery after the installation is interrupted also shifts. However, the existing upgrade package digest verification, candidate program execution verification, and target version startup verification cannot prove that the candidate upgrade program can handle the different interruption states that occur during the installation process. At the same time, if the recovery capability of the candidate upgrade program is directly tested using the real firmware area, boot entry point, and official recovery record, the test operation itself may destroy the original recovery conditions of the electronic price tag.

[0005] Therefore, how to confirm that the candidate upgrade program can continue the installation or restore to the current stable state in the face of irreversible installation interruption before the current upgrade program is withdrawn, and how to safely transfer the responsibility for restoration after confirmation, is a technical problem that needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a cloud-based management and OTA remote upgrade method and system for elongated electronic price tags, thereby resolving the technical problems mentioned in the background section.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A method for cloud-based management and OTA remote upgrade of elongated electronic shelf labels includes the following steps:

[0009] S1. Receive the cloud OTA upgrade package, establish the installation dependency relationship between upgrade operations based on the upgrade instruction information in the OTA upgrade package and the current stable state of the electronic price tag, identify irreversible installation operations based on the state recovery capability after each upgrade operation is executed, and form an irreversible installation path containing irreversible installation operations.

[0010] S2. Select recovery interruption points based on installation dependencies and irreversible installation paths, reproduce the installation interruption state according to the completed upgrade operations corresponding to each recovery interruption point, and form rollback interruption shadow state and continuation interruption shadow state for rollback direction and continuation direction respectively.

[0011] S3. Based on the candidate upgrade program call description, run the candidate upgrade program based on the rollback interruption shadow state and the continuation interruption shadow state respectively. Intercept the read and write events generated by the candidate upgrade program through the controlled storage service to form the side effect records of the rollback direction and the continuation direction and the corresponding result shadow state.

[0012] S4. Establish the causal relationship of side effects based on the side effect records, verify the bidirectional recovery capability of each recovery interruption point according to the causal relationship of side effects and the shadow status of the result, and check whether each side effect execution prefix has a continuation entry or a compensation sequence to recover to the current stable state. When the verification is successful, generate a recovery responsibility handover certificate.

[0013] S5. After verifying the handover certificate of responsibility for recovery, perform the actual installation according to the verified formal installation sequence, and use the independent installation progress log to determine the execution prefix corresponding to the installation interruption. Continue the installation or restore to the current stable state according to the execution prefix. After the formal installation is completed, verify the parsing results of the candidate upgrade program on the formal recovery record and the confirmation of the cloud upgrade completion. After the verification is passed, switch the recovery entry to the candidate upgrade program.

[0014] A cloud-based management and OTA remote upgrade system for elongated electronic price tags includes: a cloud management module, an installation dependency construction module, a recovery interruption state construction module, a shadow execution module, a recovery verification module, a formal installation and interruption recovery module, and a recovery responsibility switching module.

[0015] The beneficial effects of this invention are as follows:

[0016] This invention verifies the bidirectional recovery capability of candidate upgrade programs to irreversible installation interruptions before the current upgrade process exits, and uses a recovery responsibility handover certificate to constrain the formal installation, thus solving the problem of premature transfer of recovery responsibility and improving the reliability of recovery and version consistency after OTA upgrade interruptions. By reading the complete content of the current stable state and establishing installation dependencies based on the instruction sequence, read / write objects, and state prerequisites, it can accurately identify irreversible installation operations lacking recovery conditions, reduce omissions of critical installation paths, improve the accuracy of interruption risk location, and enhance the consistency of subsequent verification inputs.

[0017] This invention selects recovery interruption cutoff points covering all irreversible installation paths and reproduces the bidirectional interruption shadow state according to the instructions completed before the cutoff point. This ensures that the limited cutoff points correspond to key state changes, reducing computational and storage overhead caused by repeated verification and improving the efficiency and accuracy of interrupt state coverage and reproduction. By intercepting read and write events of candidate upgrade programs through a controlled storage service and updating the interruption shadow state based on the most recent preceding write, subsequent reads reflect the complete state evolution without altering the real page, startup entry point, and formal recovery record, thus improving the consistency of shadow execution and the stability of the real device.

[0018] This invention verifies the reachability of a bidirectional stable state through the causal relationship of side effects and examines the continuation entry or compensation sequence of each side effect execution prefix. It can identify installation sequences where the final state is correct but the intermediate state is unrecoverable, reducing the recovery failure rate caused by repeated interruptions and improving the reliability of verification results. By locating the interruption prefix through independent dual-slot installation progress logs and resuming execution according to the corresponding continuation entry or compensation sequence, the recovery entry is switched after the target version startup, recovery record parsing, and cloud confirmation are all successful. This reduces misjudgments of the installation location and improves the accuracy of formal installation recovery and the stability of responsibility handover. Attached Figure Description

[0019] Figure 1 This is a flowchart of the cloud management and OTA remote upgrade method for elongated electronic price tags according to the present invention;

[0020] Figure 2 This is a framework diagram of the long strip electronic price tag cloud management and OTA remote upgrade system of the present invention;

[0021] Figure 3 This is a schematic diagram of the dependency analysis interface for the present invention;

[0022] Figure 4 This is a schematic diagram of the interface for restoring interruption candidate points and path coverage selection points in this invention;

[0023] Figure 5 This is a schematic diagram of the bidirectional shadow operation example and side effect verification interface of the present invention;

[0024] Figure 6 This is a schematic diagram of the device upgrade task status and abnormal alarm interface of the present invention. Detailed Implementation

[0025] 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.

[0026] Example 1: As Figure 1 As shown, this embodiment provides a method for cloud management and OTA remote upgrade of elongated electronic shelf labels, including the following steps:

[0027] S1. Receive the cloud OTA upgrade package, establish the installation dependency relationship between upgrade operations based on the upgrade instruction information in the OTA upgrade package and the current stable state of the electronic price tag, identify irreversible installation operations based on the state recovery capability after each upgrade operation is executed, and form an irreversible installation path containing irreversible installation operations.

[0028] S2. Select recovery interruption points based on installation dependencies and irreversible installation paths, reproduce the installation interruption state according to the completed upgrade operations corresponding to each recovery interruption point, and form rollback interruption shadow state and continuation interruption shadow state for rollback direction and continuation direction respectively.

[0029] S3. Based on the candidate upgrade program call description, run the candidate upgrade program based on the rollback interruption shadow state and the continuation interruption shadow state respectively. Intercept the read and write events generated by the candidate upgrade program through the controlled storage service to form the side effect records of the rollback direction and the continuation direction and the corresponding result shadow state.

[0030] S4. Establish the causal relationship of side effects based on the side effect records, verify the bidirectional recovery capability of each recovery interruption point according to the causal relationship of side effects and the shadow status of the result, and check whether each side effect execution prefix has a continuation entry or a compensation sequence to recover to the current stable state. When the verification is successful, generate a recovery responsibility handover certificate.

[0031] S5. After verifying the handover certificate of responsibility for recovery, perform the actual installation according to the verified formal installation sequence, and use the independent installation progress log to determine the execution prefix corresponding to the installation interruption. Continue the installation or restore to the current stable state according to the execution prefix. After the formal installation is completed, verify the parsing results of the candidate upgrade program on the formal recovery record and the confirmation of the cloud upgrade completion. After the verification is passed, switch the recovery entry to the candidate upgrade program.

[0032] S1 specifically includes the following sub-steps:

[0033] S110, based on the cloud-based OTA upgrade package and the current operating status of the long strip electronic price tag, obtains and standardizes the application software instruction set, stable status data and candidate upgrade program call descriptions through end-to-cloud collaboration.

[0034] The edge computing unit is located on the side of the elongated electronic price tag and includes an upgrade package verification module, a device status reading module, a shadow execution module, a controlled storage access gateway, an installation progress log control module, and a wireless communication interface. The OTA upgrade package issued by the cloud management platform includes at least the device model identifier, upgrade task identifier, current version identifier, target version identifier, candidate application firmware, candidate upgrade program, target stable state benchmark, application software instruction set, and candidate upgrade program call description.

[0035] When the electronic price tag leaves the factory, a cloud signature verification public key and public key identifier are pre-installed in a read-only trusted storage area, and the verification public key is not temporarily obtained from the current OTA communication link. The edge computing unit verifies the digital signature of the OTA upgrade package based on the pre-installed public key and recalculates the package digest; if the device model is inconsistent, the signature is invalid, or the digest is inconsistent, the unverified payload is deleted and the current operating state is retained.

[0036] The application software instruction set is an ordered set of upgrade instructions to be executed by the current upgrade program or candidate upgrade programs. Each instruction includes an instruction identifier, sequence position, operation type, target object, set of objects to be read, set of objects to be written, target address, data length, preceding instruction identifier, pre-execution state, input content summary, and post-execution state. The target address and data length are in bytes, and the set of objects to be written is determined based on the operation type, target object, target address, and data length. The candidate upgrade program call description includes the processor architecture identifier, the recovery entry address (which serves as the entry point for the candidate upgrade program), the context parameter block format, the position and value of the recovery direction field, the position of the recovery start instruction field, the address of the controlled storage service table, the correspondence between service call number and operation type, the address of the read return content, the execution return code, and the recovery record compatibility table. The recovery record compatibility table at least records the resolvable recovery record version and required fields.

[0037] Before modifying the official page, the edge computing unit reads the complete byte sequence, page address, original boot entry point, and original official recovery record of the current page involved in the application software instruction set through the storage controller, and forms the current stable state content set. The current stable state content set includes the complete content and content summary of each current page, the original boot entry point, the complete content of the original official recovery record, the recovery record version, the installation stage, the identifier of the most recently completed instruction, and a verification field. The edge computing unit writes the above content into a non-volatile recoverable data area that is isolated from the official firmware area, retains its content after power interruption and processor reset, and is prohibited from being released before the upgrade is completed, and performs readback digest verification on the written content.

[0038] The target stable state baseline includes the target page summary, target startup entry point, target recovery record final state, recovery record version, installation stage, most recently completed instruction identifier, verification fields, and target version identifier. The complete content written to the target page comes from candidate application firmware that has passed signature and summary verification. Data reading is an upgrade task-triggered operation without a fixed sampling period. The upgrade will be aborted if the page address exceeds the limit, the complete content reading fails, the summary verification is inconsistent, the candidate upgrade program call description is missing necessary fields, the recovery data area cannot save all the current stable state content, or the candidate application firmware lacks the complete target page content.

[0039] Ultimately, a standardized set of application software instructions, a set of current stable state content, a target stable state baseline, and descriptions of candidate upgrade program calls are formed, which are used by the S120 to establish installation dependencies.

[0040] S120: Based on a standardized application software instruction set, the explicit pre-order relationships, read / write objects, and state prerequisites of each upgrade instruction are parsed to form an installation dependency relationship with a defined direction. The edge computing unit extracts the instruction identifier, sequence position, pre-order instruction identifier, set of read objects, set of write objects, pre-execution state, and post-execution state for each instruction. Page objects are expanded into byte address ranges according to their starting address and data length. Startup entry points and formal recovery records are represented by field identifiers. Both pre-execution and post-execution states are represented using a structured state representation consisting of field names, field values, and content summaries.

[0041] For the i-th instruction in the application software instruction set and the j-th instruction ,when The directed dependency label is determined according to the following formula:

[0042]

[0043] in, For instructions Does it depend on instructions? The binary label takes the value 0 or 1 and is dimensionless; and These represent the sequential positions of the two instructions within the application software's instruction set, derived from cloud-based orchestration results, with values ​​ranging from 1 to the total number of instructions. For instructions The set of preceding instructions; For instructions The collection of objects to be written; For instructions The collection of objects to be read; For instructions The state after execution; For instructions The state before execution. express Provided At least one status field is required, and all fields with the same name must have identical values ​​or summaries. All sets and states originate from the application software instruction set formed by S110 and have no physical units.

[0044] Only Establish from arrive The edges are such that overlapping writes of the same object will not create duplicate dependencies in the opposite direction. Even with only one byte of overlapping addresses, the intersection is still considered non-empty. When a sequence position is missing, duplicated, or conflicts with an explicit preceding instruction, the dependency direction is not presumed; instead, the application software instruction set is deemed invalid and a request for reordering is sent to the cloud. Edge computing units use instructions as nodes and... The relationship is a directed edge, and a topology check is performed on the directed graph; if a cycle exists, nodes within the cycle are merged into composite operation nodes only if they are explicitly marked by the application software instruction set as the same indivisible transaction, otherwise the upgrade is terminated.

[0045] The final output includes node identifiers, sequential positions, predecessor nodes, successor nodes, read / write objects, pre-execution state, and post-execution state installation dependencies, which are used by the S130 to identify irreversible installation operations.

[0046] S130, based on installation dependencies, the current stable state content set, the target stable state baseline, and upgrade program format compatibility, identifies irreversible installation operations and forms a set of irreversible installation paths. The edge computing unit simulates the state changes of page content, startup entry, and formal recovery records node by node according to the topological order of the installation dependencies, without performing write operations on the actual storage objects.

[0047] The format compatibility of the current upgrade procedure is determined by the recovery record compatibility table attached to the candidate upgrade procedure call description and the local capability interface of the current upgrade procedure. The compatibility table lists the resolvable recovery record versions and required fields, and the local capability interface performs parsing on the recovery record copy and returns success, version not supported, field missing or verification failed.

[0048] The current upgrade procedure is considered capable of interpreting the updated recovery record only when the compatibility table declares support and the parsing interface returns a successful response. For each node, the edge computing unit checks whether, after execution, it still possesses the complete page content, original startup entry, and resolvable recovery record required to restore the current stable state.

[0049] Irreversible installation operations refer to operations in which, when a power outage or processor reset occurs after the corresponding operation is performed, the current upgrade program, based solely on the actual firmware area, the currently selectable boot entry point, and the formal recovery record, cannot determine the installation location and continue the installation, nor can it restore the current stable state on its own. The complete old content saved in the recovery data area is only used as the source of recovery for subsequent compensation sequences and is not used as a condition to deny the irreversibility of the operation.

[0050] When a page is erased or overwritten, covering the only valid page of the current version, a page occupied by the current upgrade program, or a page necessary for the continued recovery of the current upgrade program, the corresponding node is marked as an irreversible installation operation; when the boot entry is modified, causing the original boot entry to be deleted, invalidated, unable to be reselected, or when the processor resets and prioritizes an unverified candidate upgrade program, the corresponding node is marked as an irreversible installation operation; when the recovery record update exceeds the range of compatible versions of the current upgrade program or the parsing interface returns an unsuccessful status, the corresponding node is marked as an irreversible installation operation.

[0051] For OTA upgrade packages that include updates from the current upgrade program itself, at least one of the following should be marked as an irreversible installation operation: overwriting pages occupied by the current upgrade program, modifying the recovery entry, or writing to recovery records that the current upgrade program cannot parse. If no irreversible installation operation is identified, the current recovery responsibility handover verification will be terminated, and no recovery responsibility handover certificate will be generated.

[0052] If a reverse instruction exists but lacks complete recovery content or its execution depends on data that has already been overwritten, it is not considered directly recoverable. If any sub-operation in a composite operation satisfies the irreversibility condition, the entire composite operation is classified into the set of irreversible installation operations.

[0053] The edge computing unit traverses from the starting node of the installation dependency relationship to the target stable state node, saving an ordered sequence of nodes containing at least one irreversible installation operation as an irreversible installation path. Each path records the path identifier, node order, irreversible installation operation identifier, affected objects, and the state before the irreversible operation is executed. A verification blocking status is output when there are missing state fields, parsing capability conflicts, or failure to verify the content of the recovery data area.

[0054] The final output includes installation dependencies, a set of irreversible installation operations, a set of irreversible installation paths, as well as the associated set of current stable state content, target stable state baseline, application software instruction set, and candidate upgrade program call descriptions, which serve as the complete input for S210.

[0055] S2 specifically includes the following sub-steps:

[0056] S210, based on the installation dependencies, irreversible installation operation set, and irreversible installation path set output by S130, filters the interruptible execution boundaries to form a set of recovery interruption candidate points. After path identification is completed in S130, the edge computing unit reads the ordered node sequence and irreversible operation position of each path, and verifies the consistency between the path nodes and the installation dependency nodes through instruction identifiers. The digital structured data is not subjected to numerical filtering; instead, field integrity checks, identifier deduplication, address boundary checks, and state digest consistency checks are performed.

[0057] The edge computing unit determines the instruction boundary as a basic candidate point after each irreversible installation operation has been fully executed but before its subsequent operation has started. When multiple irreversible installation paths converge before the same subsequent node, and there are no new page erases, page writes, boot entry modifications, or recovery record updates between the most recent irreversible installation operation on each path and the convergence boundary, the convergence boundary is determined as a shared candidate point. Each recovery interruption candidate point includes a candidate point identifier, a set of identifiers of preceding completed instructions, a set of identifiers of subsequent incomplete instructions, identifiers of irreversible installation paths passing through the candidate point, and an identifier of the most recent irreversible installation operation.

[0058] Candidate points located before irreversible installation operations, after the target stable state, or within indivisible composite operations are deleted. Candidate points located exactly at the submission boundary of composite operations are included in the execution boundary after the completion of composite operations. If an irreversible installation path does not have an identifiable operation completion boundary, it is marked as an unverifiable path, subsequent verification is stopped, and the corresponding instruction identifier is returned through the end-to-cloud collaboration interface.

[0059] The set of interruption candidate points is restored and associated with the current stable state content set, the target stable state benchmark, the application software instruction set, and the candidate upgrade program call description with task identifiers to avoid reading data from other OTA tasks in the future.

[0060] The final output includes a set of candidate points for recovery interruption and their correspondence with irreversible installation paths, which are then used by the S220 to select points for path coverage.

[0061] S220. Based on the set of candidate points for recovery interruption and the correspondence between the candidate points and the irreversible installation path, perform irreversible interruption state coverage judgment and deterministic point selection to form a set of recovery interruption cut-off points. The edge computing unit determines an irreversible installation operation in an irreversible installation path and the state combination after the operation is fully executed, before the next page erase, boot entry modification, or recovery record update has started, as an irreversible interruption state coverage unit; when coverage units formed by different paths have the same set of completed instructions, page summary, boot entry value, and recovery record summary, they are merged into the same coverage unit.

[0062] The edge computing unit establishes a state coverage matrix with irreversible interruption state coverage units as the objects to be covered and recovery interruption candidate points as the optional objects. When the set of completed instructions preceding the candidate point is the same as the set of completed instructions of the corresponding coverage unit, or when the two only contain instructions that do not change the page, startup entry, and recovery record state, and the page summary, startup entry value, and recovery record summary of the two are completely consistent, the corresponding matrix element is set to 1; otherwise, it is set to 0.

[0063] The set of interruption point recovery points satisfies:

[0064]

[0065] in, Let C be the set of irreversible interrupt state overlay units; u is one of the irreversible interrupt state overlay units; C is the set of recovery interrupt cut-off points; c is one of the recovery interrupt cut-off points. This is a binary label indicating whether candidate point c covers cell u. It is set to 1 if it covers the cell and 0 if it does not. It is dimensionless. and The recovery interruption candidate points, irreversible installation paths, irreversible installation operation locations, and corresponding status summaries are derived from S210.

[0066] When selecting specific points, the edge computing unit first chooses the candidate point for recovery interruption that can cover the most uncovered units; if the number of covered units is the same, it selects the candidate point that can cover the most irreversible installation paths; if they are still the same, it selects the candidate point with the earlier sequential position in the application software instruction set. Each time a cutoff point is added, the units it covers are deleted and the remaining candidate points are recounted until all covered units are covered or the remaining candidate points cannot cover any uncovered units. The number of iterations does not exceed the total number of candidate points. When the set of covered units for irreversible interruption states is empty, the recovery responsibility handover verification is terminated; if uncovered units exist, the state of coverage failure is output, and shadow operation is not initiated.

[0067] When all coverage units are covered, the edge computing units arrange the recovery interruption points according to the topological order of installation dependencies, and attach a set of completed instructions, a set of incomplete instructions, a set of coverage units, and a set of coverage paths to each point. Finally, the output recovers the interruption point set, and continues to carry the current stable state content set, the target stable state baseline, the application software instruction set, and the candidate upgrade program call description, so that S230 can reproduce the interruption state.

[0068] S230. Based on the set of recovery interruption cutoff points, installation dependencies, and the current stable state content set, reproduce the installation execution results before each cutoff point, and construct the rollback interruption shadow state and the continuation interruption shadow state. The interruption shadow state is a copy of the electronic price tag's logical state stored in the isolated verification space of the edge computing unit, including a page mapping table, a complete page byte sequence, a startup entry field, a copy of the formal recovery record, a completed instruction bitmap, an incomplete instruction table, a recovery direction field, a recovery start instruction field, and a state summary.

[0069] The edge computing unit copies the complete page content, original startup entry, and formal recovery record from the current stable state content set, and sequentially reproduces page erasure, page writing, startup entry modification, and recovery record update according to the completed instruction set of the cutoff point. Page erasure updates the shadow page to the erased state defined by the storage device interface; page writing updates the corresponding byte range based on the target address and input content; startup entry and recovery record are updated as a whole according to field boundaries.

[0070] After each operation is completed, the edge computing unit calculates a summary of the affected objects and compares it with the post-execution state summary of the installation dependency nodes. If they match completely, the process continues; otherwise, the corresponding pointcut is marked as a reproduction failure. If the current page content is missing, the address is out of bounds, the input payload is missing, or the recovery record cannot be parsed according to the specified version, default values ​​are not used for completion. After reproduction to the pointcut, a basic shadow state of the pointcut is formed and copied to two isolated namespaces.

[0071] The recovery direction field of the rollback namespace is written with the rollback value specified in the candidate upgrade procedure call description. The recovery start instruction field is written with the application software instruction identifier with the largest sequential position in the set of completed instructions preceding this point, and this identifier is determined as the rollback instruction identifier. The candidate upgrade procedure starts from the instruction corresponding to this rollback instruction identifier and processes the completed instructions that need to be rolled back in reverse topological order of the installation dependencies. If there are multiple instructions that can be processed simultaneously, they are processed in descending order of their sequential position in the application software instruction set. The recovery direction field of the continue namespace is written with the continue value. The recovery start instruction field is written with the application software instruction identifier with the earliest topological order in the set of incomplete instructions following this point. If there are multiple instructions with the same topological order, the instruction identifier with the smallest sequential position is written. Both fields are written according to the candidate upgrade procedure context parameter block format and do not change the content of the shadow page, startup entry, or formal recovery record.

[0072] The final output includes the rollback interrupt shadow state, the continuation interrupt shadow state, and the candidate upgrade procedure call description reference corresponding to each recovery interrupt cutoff point, which serve as the input for S310 to establish an isolated running instance.

[0073] S3 specifically includes the following sub-steps:

[0074] Based on the rollback interrupt shadow state, continuation interrupt shadow state, and candidate upgrade program call description output by S310 and S230, a bidirectional isolated running instance is established in the edge computing unit on the side of the elongated electronic price tag.

[0075] The edge computing unit loads the candidate upgrade program based on the processor architecture identifier, sets the program entry address to the recovery entry address in the candidate upgrade program call description, and writes the cutpoint identifier, recovery direction, recovery start instruction identifier, shadow state address and controlled storage service table address according to the context parameter block format.

[0076] The candidate upgrade program reads different recovery directions and start instructions through the same recovery entry point, thereby executing rollback recovery and continued installation respectively, without the implementer having to choose an undisclosed program entry point. Each running instance includes a candidate upgrade program execution space, a shadow page space, a shadow startup entry point, a shadow recovery record, a global access event counter, a call interception table, and a running status area.

[0077] Candidate upgrade programs must access and write to pages, boot entries, and recovery records through controlled storage service tables. Call parameters must include at least the application software instruction identifier, operation type, target object, target address, data length, and content address. The edge computing unit disables direct access permissions for running instances to the real firmware area, real boot entry, official recovery record, and storage controller registers via memory access protection. If a candidate upgrade program bypasses the controlled storage service table to access these areas directly, a protection exception is triggered, and the edge computing unit immediately terminates the corresponding instance.

[0078] Rollback instances and continuation instances use independent shadow states and independent running state areas, and can be executed sequentially or in parallel when storage spaces are completely isolated. Instances are not started if the candidate program summary, entry address, or context parameter block length does not match the call description.

[0079] Ultimately, rollback instances and continue-run instances are formed, each corresponding to a recovery interruption point, for the S320 to record all controlled storage access events.

[0080] S320, based on rollback instances, continue instances, and application software instruction sets, intercepts read and write events generated by candidate upgrade programs and forms a side effect record with a definite read source and preceding write relationship. Each time a controlled storage service call arrives, the edge computing unit increments the global access event counter by 1 and writes the obtained global access event sequence number to the call record; reads and writes share the same sequence number space.

[0081] Each call record includes an instance identifier, a pointcut identifier, a recovery direction, a global access event sequence number, an execution thread identifier, an application software instruction identifier, an operation type, an object of action, an address range, a summary before the call, a summary after the call, and a return code.

[0082] Write calls must carry an application software instruction identifier. The edge computing unit uses this identifier to locate the application software instruction set and verifies the operation type, target, address range, and pre-execution state. If any field does not match, the call is recorded as a side effect that exceeds the application software instruction set, and the instance is terminated. For read events, the edge computing unit records whether the returned content comes from the initial interrupt shadow state or a preceding write side effect; if it comes from a preceding write, it records the global access event sequence number of the corresponding side effect.

[0083] For write side effects, the read association window starts after the previous write side effect in the same execution thread and ends before the current write side effect. The edge computing unit selects read events whose objects belong to the current application software instruction read object set from the window and writes the source side effect sequence numbers of these read events into the read source set of the current side effect. When the application software instruction read object set is empty, the read source set can be empty.

[0084] The edge computing unit simultaneously searches for the preceding write with the largest global access event sequence number within the same target and overlapping address range, and records it as the most recent preceding write. The shadow state is not updated when the page address is out of bounds, the data length is 0 but the operation requires writing content, the instruction identifier is missing, or the same event sequence number is duplicated. The corresponding instance terminates when the candidate upgrade procedure returns a completion status, an error status, or triggers a protection exception.

[0085] During the execution of the candidate upgrade program, S320 generates call records item by item according to the order of controlled storage service calls. Each time a read or write call is intercepted, the candidate upgrade program is paused and S330 is simultaneously called to update or read the current shadow state. The program is only allowed to continue execution after the call result is returned to it. Write events that successfully modify the shadow page, shadow startup entry point, or shadow recovery record through application software instruction set verification are identified as side effects. Read events only generate read records and read sources, and are not considered as separate side effect nodes. After the candidate upgrade program finishes execution, a rollback side effect record sequence and a continuation side effect record sequence are generated for each cutoff point, allowing S410 to establish the causal relationship of side effects.

[0086] S330, as a shadow state processing step synchronously executed when S320 processes each controlled storage service call, updates the shadow object according to the unified global access event sequence number and responds to this read with the latest shadow content; the candidate upgrade program can only continue to generate subsequent read or write calls after obtaining the return value of this read.

[0087] For a read event with global access event sequence number t and object position x, the return value is determined according to the following formula:

[0088]

[0089] Where T is the total number of global access events for the currently running instance. The global access event sequence number of the current read event; The sequence number of the write event preceding the current read event; The sequence number of the nearest preceding write event to the set of positions to be applied; Read the value obtained from the object position x at event sequence number t;

[0090] The value formed at position x by the most recent preceding write event; For write events The set of locations where the action occurs; This represents the value of position x in the initial interrupt shadow state. T, t, and All values ​​are dimensionless positive integers. Page position x is represented by a byte address, and page value is represented by a byte; the positions of the startup entry and recovery record are represented by field identifiers, and their values ​​are encoded using the corresponding field. The above data originates from the initial interrupt shadow state formed by S230 and the call records and side effects written by S320 according to the order of call occurrence.

[0091] If a recent write exists, the most recently written value must be returned; otherwise, the initial value is returned. The instance terminates if the event sequence number is missing, duplicated, or out of bounds. Partial page writes overwrite bytes, while unwritten portions retain the previous version's content. Page erasure updates the entire affected page to the device erase state. Startup entry and recovery record fields are submitted as complete fields. After each side effect update, the edge computing unit increments the shadow state version number and uses the updated state for the next read event. After execution, the final page mapping, complete page content, startup entry, recovery record, termination reason, and state version number are saved.

[0092] Finally, the rollback side effect record, continuation side effect record, rollback result shadow state, and continuation result shadow state corresponding to each recovery interruption point are output as inputs to S410.

[0093] S4 specifically includes the following sub-steps:

[0094] S410, based on the rollback side effect record, continuation side effect record, rollback result shadow state, and continuation result shadow state output by S330, establishes a side effect causal relationship for each recovery interruption point. A side effect causal relationship is a directed dependency between side effects formed due to the source of the read, previous writes to the same object, or prerequisites for the execution of application software instructions.

[0095] The edge computing unit groups side effect records according to the cutoff point identifier and recovery direction, and sorts them in ascending order by global access event number; it checks whether the state before writing is equal to the state of the corresponding shadow object before that event, and whether the post-writing digest is equal to the state digest used in subsequent reads. The edge computing unit uses each write side effect as a node.

[0096] When the current side effect's read source set contains a preceding side effect number, a read dependency edge is established from that preceding side effect node to the current node. When the most recently written preceding field points to a side effect, an object state dependency edge is established. When the application software instruction corresponding to the current side effect has a predecessor instruction, it is determined whether the predecessor instruction is executed in the current running instance. If the predecessor instruction is executed in the current running instance and has been mapped to a side effect node, an execution prerequisite dependency edge is established from that side effect node to the current side effect node. If the predecessor instruction belongs to the set of preceding completed instructions for the recovery interrupt point, no execution prerequisite dependency edge is established between side effect nodes. Instead, the state of the corresponding object in the initial interrupt shadow state is compared with the state after the execution of the predecessor instruction. If they are completely consistent, the execution prerequisite is considered to be satisfied. If the predecessor instruction has neither a corresponding side effect node nor belongs to the set of preceding completed instructions, the corresponding recovery direction is determined to be a causal verification failure.

[0097] When multiple conditions generate edges in the same direction, they are merged into one edge, and the edge type set is preserved. All edges should point from the smaller global access event sequence number to the larger sequence number. If a reverse edge, a side effect with a non-existent reference, or a directed cycle occurs, the corresponding side effect record is deemed invalid. When reading associated windows, reading object collections, or when the most recent previous write field is missing, causal relationships are not automatically inferred; instead, the corresponding recovery direction is judged as a causal verification failure.

[0098] Finally, the causal relationships of the fallback side effects and the continuation side effects are formed for each recovery interruption point, and the causal validity identifier is output for S420 to determine the reachability of the bidirectional steady state.

[0099] S420. Based on the causal relationship of rollback side effects, the causal relationship of continuation side effects, the shadow state of rollback result, the shadow state of continuation result, the current stable state content set and the target stable state benchmark, determine the bidirectional stable state reachability of each recovery interruption point.

[0100] The edge computing unit performs topological sorting on the causal relationships of the two types of side effects, and the sorting results must cover all side effect nodes. Then, it checks whether the pre-execution state of each side effect can be formed from the initial interruption shadow state and all predecessor side effect results according to the topological order. If there are unsorted nodes, the pre-execution state is not satisfied, or the candidate upgrade program ends in an error state, the corresponding recovery direction is determined to be unreachable.

[0101] When comparing the rollback result shadow state with the current stable state content set, calculate the complete content summary page by page and verify the original startup entry, the official recovery record version, the installation stage, the most recently completed instruction identifier, and the verification fields; when comparing the continued result shadow state with the target stable state benchmark, verify the target page summary, the target startup entry, the target recovery record final state, and the target version identifier.

[0102] If all fields are completely identical and the candidate upgrade procedure ends normally, it is considered reachable; if any field is inconsistent, it is considered unreachable. No summary similarity threshold is set. Retained pages that have not been modified by this application software instruction set are still verified according to the summary in the current stable state content set.

[0103] When both the backtracking and continuation directions are reachable, the corresponding cut-off point is marked as bidirectional recovery successful; when only one direction is reachable or both directions are unreachable, it is marked as bidirectional recovery failed, and the generation of recovery responsibility handover certificate is prohibited. The edge computing unit uploads the cut-off point identifier, the judgment values ​​of the two directions, the mismatch object identifier, and the result summary through the edge-cloud collaboration interface, while the complete page content is retained on the electronic price tag.

[0104] Finally, the bidirectional recovery results of each recovery interruption point, the verified causal relationship of side effects, and the steady-state mismatch record are output for S430 to check the execution prefix.

[0105] S430. Based on the bidirectional recovery results of each recovery interruption point, the verified causal relationship of side effects, the candidate upgrade procedure call description, and the current stable state content set, check whether each side effect execution prefix has a continuation entry or a compensation sequence that can restore to the current stable state. The side effect execution prefix is ​​a temporary shadow state formed from the first term of a certain fallback side effect sequence or continuation side effect sequence to the end of any non-last side effect.

[0106] The edge computing unit generates a prefix status summary table for each execution prefix. Each entry includes a pointcut identifier, recovery direction, prefix identifier, most recently completed side effect number, summary of all affected pages, startup entry value, and recovery record summary. A continuation entry is a call description that enables the candidate upgrade program to continue execution from the corresponding prefix. It includes the candidate upgrade program entry address, context parameter block address, recovery direction, next application instruction identifier, prefix status summary, and controlled storage service table address.

[0107] A continuation entry point is determined to exist when the current prefix state is completely consistent with the prefix state required for the continuation entry point, and all preceding side effects of the next instruction have been completed. If no continuation entry point exists, the edge computing unit generates a compensation sequence based on the current stable state content set. For all affected flash memory pages, a full page erase is performed first, followed by full page writing and digest verification using the complete old page content stored in the recovery data area. Then, the original boot entry point is restored, and finally, the original formal recovery record is restored. The endpoint of the compensation sequence is uniformly the current stable state; the previous valid shadow state with uncertain meaning is not used.

[0108] If any complete page of content is missing from the recovered data area, the compensation sequence is deemed nonexistent. The overall pass condition is:

[0109]

[0110] in, The value used to determine coverage restoration; M is the total number of interruption points to restore; m is the point number. and These are the fallback reachability determination value and the continue reachability determination value, respectively. The set of non-last terms for execution prefixes in the two recovery directions of the m-th tangent point; q is the prefix identifier; A decision value exists for continuing the entry process; To compensate for the existence of judgment values, all judgment values ​​are dimensionless, taking 1 if the condition is met and 0 if not; 0 is taken when the field is missing.

[0111] when When the set is empty, the corresponding internal conjunction result is defined as 1; when the total number of interruption points M is 0, the restoration coverage determination value will be restored. If the value is set to 0, no restoration responsibility handover certificate will be generated. This only applies if M is greater than 0 and... When =1, a recovery coverage result is generated.

[0112] The edge computing unit uses the standardized application software instruction set and installation dependencies in S110 as the sequential skeleton, identifying all upgrade instructions in the standardized application software instruction set as installation operations to be arranged. For upgrade instructions that were completed before a recovery interruption point and therefore not executed again in the corresponding continued running instance, the condition for the upgrade instruction to pass verification is that the object digest formed after reproducing the upgrade instruction in S230 is completely consistent with the post-execution state digest of the instruction in the installation dependency. For upgrade instructions actually executed in the continued running instance, the side effect records are mapped to the corresponding upgrade instructions according to the application software instruction identifier, operation type, target object, address range, data length, input content digest, pre-execution state digest, and post-execution state digest. Side effects with the same application software instruction identifier and target object generated by different cutoff points are merged into the same formal installation operation only when the above fields are completely consistent. If any field is inconsistent, or if an upgrade instruction has neither a consistent reproduction result in S230 nor a consistent and verified continued side effect, the formal installation sequence generation is deemed to have failed, and no recovery responsibility handover certificate is generated.

[0113] After mapping and deduplication, the formal installation operations are arranged according to the topological order of installation dependencies. If multiple operations can be arranged simultaneously, they are arranged in ascending order according to their position in the application software instruction set, forming a unique formal installation sequence that starts from the current stable state and ends at the target stable state. The recovery responsibility handover certificate includes certificate version, device identifier, upgrade task identifier, current version identifier, target version identifier, OTA upgrade package summary, recovery interruption cutoff point set summary, recovery overwrite result summary, prefix state summary table summary, continue entry set summary, compensation sequence set summary, formal installation sequence summary, and cloud signature.

[0114] The edge computing unit uploads the aforementioned fields to be signed to the cloud. After the cloud verifies the consistency between each field and the OTA upgrade task record, a signature is generated for all fields except the cloud signature. The final output includes the recovery coverage result, the recovery responsibility handover certificate, the unique verified formal installation sequence, the continuation entry, the compensation sequence, and the prefix status summary table, which serve as inputs to the S510.

[0115] S5 specifically includes the following sub-steps:

[0116] Based on the recovery coverage results, recovery responsibility handover credentials, verified formal installation sequence, continue entry, compensation sequence, and prefix status summary table output by S510 and S430, an installation progress log independent of the formal recovery record is established, and a real installation is performed. The installation progress log is set in a separate log area inaccessible to the application software instruction set, using two alternating log slots; each log slot includes a log generation, upgrade task identifier, current pending side effect sequence number, most recently completed side effect sequence number, current prefix status summary, log checksum, and validity flag.

[0117] The edge computing unit uses a cloud-based signature verification public key pre-installed in the read-only trusted storage area of ​​the electronic price tag to verify and restore the responsibility handover certificate, without re-obtaining the public key through this network. Real storage write permissions are only granted when the device identifier, task identifier, OTA upgrade package digest, formal installation sequence digest, and cloud signature are all valid.

[0118] Before performing each formal installation operation, the edge computing unit selects a non-current valid log slot, writes the increased log generation, the sequence number of the side effect to be executed, and the state summary before execution, and finally writes a valid flag after verification. After the operation is completed and the verification is read back, the sequence number of the most recently completed side effect and the state summary after execution are written in the same way.

[0119] At startup, the log slot with the highest log generation number is selected from the valid log slots; if two slots have the same generation number but different contents, the system enters the recovery retention state. Page erasure, page writing, boot entry modification, and formal recovery record updates in the production installation sequence are mapped to the storage controller, boot configuration interface, and recovery record interface, respectively. Because the installation progress log is located in a separate log area, formal recovery record updates will not overwrite the installation progress.

[0120] The address range, data length, and expected digest of each operation must be consistent with the application software instruction set; if the address goes out of bounds, the read digest is inconsistent, or the log write fails, subsequent operations are stopped and the process is transferred to S520. This ultimately generates an installation progress log that can determine the execution prefix after a power outage or reset, as well as the status of formal installation completion or installation interruption.

[0121] The S520, based on the installation progress log, prefix status summary table, continue entry, and compensation sequence, determines the recovery location after power failure recovery, processor reset, storage write verification failure, or abnormal exit of the candidate upgrade program, and then executes continue installation or restores the current stable state. Wireless link interruption is not considered a stop condition for local formal installation because the OTA upgrade package, formal installation sequence, and current stable state content set have all been verified and saved on the electronic price tag side.

[0122] The edge computing unit first reads two log slots and verifies the log checksum and valid flags. If a valid log slot exists, it selects the record with the highest log generation and determines the execution prefix pointed to by the log based on the current pending side effect sequence number and the most recently completed side effect sequence number. It then compares the actual page summary, startup entry point, and formal recovery record summary with the corresponding prefix status summary table. If the actual state is completely consistent with the corresponding prefix, the execution prefix is ​​determined. If the actual state is inconsistent, it is determined that the installation interruption occurred during page erasure, page writing, startup entry point modification, or recovery record update. Instead of presuming a partial write state as another execution prefix, it directly calls the compensation sequence covering all affected objects to restore the current stable state.

[0123] When no valid log slot exists, the edge computing unit reads the actual state of all affected objects and compares it item by item with the prefix state summary table; if only one entry matches completely, the corresponding execution prefix is ​​determined. If multiple matching entries exist, the system enters the recovery hold state; if no matching entries exist, it first uses the complete old page content, original startup entry, and original formal recovery record stored in the non-volatile recovery data area of ​​S110 to execute the compensation sequence covering all affected objects, restoring the electronic price tags to the current stable state. If the recovery data area content is missing, the summary verification fails, or the state after compensation is still inconsistent with the current stable state content set, the system enters the recovery hold state.

[0124] The restore hold state prohibits page overwriting, modification of the startup entry, and updates to the restore record. It only retains the current upgrade program, read-only state acquisition capabilities, and communication capabilities in a controlled state. Only after the cloud returns a restore command that has been verified by a pre-set public key, matches the current upgrade task identifier, and carries complete restore content that has passed digest verification, will the compensation sequence be re-executed using that complete restore content. If the cloud only specifies a prefix but the actual state does not match the state digest of that prefix, the restore hold state will not be exited.

[0125] After determining the execution prefix, if the prefix status summary, recovery direction, and next application software instruction identifier of the corresponding continue entry are consistent with the actual state, the candidate upgrade program is restarted according to the candidate upgrade program entry address and context parameter block in the continue entry, and the formal installation sequence continues to be executed; if the continue entry condition is not met, the corresponding compensation sequence is executed. Flash pages in the compensation sequence are restored in the order of whole page erasure, complete old page writing, and summary verification, followed by restoration of the original boot entry and the original formal restoration record, until the actual state is completely consistent with the current stable state content set. The installation progress log is updated alternately after each continue operation or compensation operation is completed; if an interruption occurs again during the compensation process, the compensation sequence covering all affected objects is re-executed, and partial restored content is not used as the new execution prefix.

[0126] The final output is either the formal installation completed status or the current stable state recovery completed status, with the formal installation completed status being passed to S530.

[0127] S530, based on the formal installation completion status, target stable state benchmark, and recovery responsibility handover certificate, starts the target version, verifies the candidate upgrade program takeover capability and cloud reconnection results, and switches the recovery entry after all passes. The edge computing unit only sends the target version startup command to the startup control interface when the summary verification after the last item of the formal installation sequence is executed passes, the installation progress log indicates that all side effects are completed, and the target startup entry is successfully written.

[0128] After the target version is started, the candidate upgrade program reads the formal recovery record according to the call description disclosed in S110, and returns the upgrade task identifier, the most recently completed application software instruction identifier, the recovery record version, and the parsing return code; when the parsing return code is successful and all fields are consistent with the target stable state benchmark, the candidate upgrade program is deemed to have the ability to read the formal recovery record.

[0129] The candidate application firmware sends the device identifier, upgrade task identifier, target version identifier, target status summary, and candidate upgrade program summary to the cloud via the wireless communication interface. The cloud compares the OTA upgrade task record and recovery responsibility handover certificate item by item. If all match, a signed upgrade completion confirmation is returned.

[0130] When the wireless link is temporarily unavailable, the electronic shelf label will reconnect according to the reconnection interval in the device's communication configuration. The reconnection interval is determined by the electronic shelf label's communication protocol and the store's wireless network configuration, and no value is given arbitrarily in this step. Before obtaining valid confirmation of upgrade completion, the current upgrade program, the original recovery entry, and the recovery data area will all be retained. The recovery entry is a persistent entry point for the electronic shelf label to call the upgrade program when the application firmware fails to start or the formal recovery record indicates that the installation is incomplete. It includes the upgrade program version identifier, the program starting address, and the entry verification field.

[0131] After the candidate upgrade program is successfully parsed, the target application firmware is successfully started, and the cloud upgrade is successfully verified, the edge computing unit will switch the recovery entry to the candidate upgrade program and read back for verification. If the read back is consistent, the area occupied by the current upgrade program will be marked as a releaseable area, the valid mark in the installation progress log will be cleared, and the recovery data area will be released after confirming that no further compensation is needed.

[0132] If the readback is inconsistent, the original recovery entry will be restored without releasing the current upgrade procedure. Finally, the result of the recovery entry switch will be fed back to the cloud through the end-to-cloud collaboration interface. The cloud will then update the electronic shelf label version status, upgrade task status, and recovery responsibility status, forming the target electronic shelf label's operational status and OTA upgrade completion status after the handover of recovery responsibility.

[0133] Example 2: Figure 2 As shown, this embodiment provides a cloud-based management and OTA remote upgrade system for elongated electronic price tags, including:

[0134] The cloud management module is used to generate and distribute OTA upgrade packages containing candidate application firmware, candidate upgrade programs, application software instruction sets, target stable state benchmarks and candidate upgrade program call descriptions, and to verify and sign the recovery coverage results;

[0135] The installation dependency building module is located on the long strip electronic price tag side. It is used to verify the signature and digest of the OTA upgrade package, read the complete content of the pages involved in the application software instruction set, the startup entry and the formal recovery record, form the current stable state content set, and establish installation dependencies according to the instruction order, previous instructions, overlapping read and write objects and the consistency of the state before and after execution, and identify irreversible installation operations and irreversible installation paths.

[0136] The recovery interruption state construction module is used to select recovery interruption points from the instruction boundaries after the irreversible installation operation is completed, so that each irreversible installation path passes through at least one recovery interruption point, and reproduces the page, startup entry and recovery record status according to the instructions completed before each recovery interruption point to form rollback interruption shadow state and continue interruption shadow state.

[0137] The shadow execution module is used to run the candidate upgrade program in the rollback interruption shadow state and the continuation interruption shadow state according to the candidate upgrade program call description. It intercepts read and write events through the controlled storage service, records the read source, application software instruction identifier and the most recent previous write, updates the interruption shadow state according to the most recent previous write and responds to subsequent reads, forming rollback side effect record, continuation side effect record, rollback result shadow state and continuation result shadow state.

[0138] The recovery verification module is used to establish the causal relationship of side effects based on the source of the read, the most recent preceding write, and the execution premise of the application software instructions. It compares the shadow state of the rollback result with the current stable state, compares the shadow state of the continuation result with the target stable state, and forms a prefix state summary table for each side effect execution prefix. It checks the corresponding continuation entry or generates a compensation sequence to restore to the current stable state. When all recovery interruption points are bidirectionally reachable and all execution prefixes have a continuation entry or compensation sequence, a recovery coverage result is formed. After being signed by the cloud management module, a recovery responsibility handover certificate is generated.

[0139] The formal installation and interruption recovery module is used to verify the handover certificate of recovery responsibility. It alternately maintains two installation progress log slots in an independent log area that is inaccessible by the application software instruction set. It controls the page to erase and write, the startup entry to modify and the formal recovery record to update according to the verified formal installation sequence. After the installation is interrupted, it determines the execution prefix based on the valid installation progress log slot or the prefix status summary table, calls the corresponding continue entry to continue the installation or executes the compensation sequence to restore the current stable state.

[0140] The recovery responsibility switching module is used to control the startup of the target version after the formal installation is completed, verify the parsing results of the candidate upgrade program on the formal recovery record and the confirmation of the cloud upgrade completion. After the verification is passed, the recovery entry is switched to the candidate upgrade program, the area occupied by the current upgrade program is released and the upgrade completion status is reported back to the cloud management module.

[0141] The module consists of a dependency building module, an interruption recovery module, a shadow execution module, a recovery verification module, a formal installation and interruption recovery module, and a recovery responsibility switching module, which are connected in sequence. The output of the previous module serves as the input of the next module. The cloud management module communicates with the dependency building module, the recovery verification module, and the recovery responsibility switching module, respectively.

[0142] The above formulas are all deterministic logical judgment rules executed based on the data from this OTA upgrade task. They are not empirical models formed through sample training or data fitting, nor do they contain preset parameters or similarity thresholds arbitrarily set by the implementers. Its input set is derived from the application software instruction set formed by S110. The irreversible interruption state overlay unit originates from the correspondence between the recovery interrupt candidate point and the irreversible installation path formed by S210. The preceding data to be written originates from the initial interrupt shadow state of S230 and the call record of S320. The various judgment values ​​are derived from the bidirectional recovery results of S420 and the continued entry and compensation sequence check results of S430. The binary judgment values ​​are dimensionless, the global access event sequence number is a dimensionless integer, and the page address, page value, and field value are represented by byte address, byte value, or field encoding according to the definition after the corresponding formula.

[0143] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0144] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0145] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for cloud-based management and OTA remote upgrade of elongated electronic shelf labels, characterized in that, Includes the following steps: S1. Receive the cloud OTA upgrade package, establish the installation dependency relationship between upgrade operations based on the upgrade instruction information in the OTA upgrade package and the current stable state of the electronic price tag, identify irreversible installation operations based on the state recovery capability after each upgrade operation is executed, and form an irreversible installation path containing irreversible installation operations. S2. Select recovery interruption points based on installation dependencies and irreversible installation paths, reproduce the installation interruption state according to the completed upgrade operations corresponding to each recovery interruption point, and form rollback interruption shadow state and continuation interruption shadow state for rollback direction and continuation direction respectively. S3. Based on the candidate upgrade program call description, run the candidate upgrade program based on the rollback interruption shadow state and the continuation interruption shadow state respectively. Intercept the read and write events generated by the candidate upgrade program through the controlled storage service to form the side effect records of the rollback direction and the continuation direction and the corresponding result shadow state. S4. Establish the causal relationship of side effects based on the side effect records. Verify the bidirectional recovery capability of each recovery interruption point according to the causal relationship of side effects and the shadow status of the result. Check whether each side effect execution prefix has a continuation entry or a compensation sequence to restore to the current stable state. Generate a recovery responsibility handover certificate when the verification is successful.

2. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 1, characterized in that, Also includes: S5. After verifying the handover certificate of responsibility for recovery, perform the actual installation according to the verified formal installation sequence, and use the independent installation progress log to determine the execution prefix corresponding to the installation interruption. Continue the installation or restore to the current stable state according to the execution prefix. After the formal installation is completed, verify the parsing results of the candidate upgrade program on the formal recovery record and the confirmation of the cloud upgrade completion. After the verification is passed, switch the recovery entry to the candidate upgrade program.

3. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 1, characterized in that, S1 specifically includes: Verify the signature and digest of the cloud OTA upgrade package, extract the application software instruction set and candidate upgrade program call description, read the complete content of the pages involved in the application software instruction set, the startup entry and formal recovery record, and form the current stable state content set; A directed installation dependency relationship is established based on the order of instructions, preceding instructions, overlapping read / write objects, and consistency of states before and after execution. Instructions that do not belong to the same indivisible transaction within a loop are judged as invalid in order. Simulate state changes along the installation dependencies, and identify operations that lack complete old page content, original startup entry, or records that can be parsed and restored by the current upgrade program as irreversible installation operations, forming a set of irreversible installation paths that include irreversible installation operations.

4. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 1, characterized in that, S2 specifically includes: The instruction boundary where each irreversible installation operation is completed and its subsequent operation has not yet started is identified as a recovery interruption candidate point, and the path convergence boundary where no new page erasure, boot entry modification or recovery record update has occurred is identified as a shared candidate point. Candidate recovery interruption points are selected sequentially based on the number of covered and uncovered paths, the number of irreversible installation operations covered, and the order of instructions, until each irreversible installation path passes through at least one recovery interruption point, thus forming a set of recovery interruption points. Starting from the current stable state content set, according to the instruction reproduction page, startup entry and recovery record status completed before each recovery interruption cutoff point, the reproduction state is copied to two isolated spaces and written to the rollback direction and the continuation direction respectively, forming the rollback interruption shadow state and the continuation interruption shadow state.

5. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 1, characterized in that, S3 specifically includes: Based on the candidate upgrade program call description, the two types of interrupt shadow states are written into the context parameter block of the candidate upgrade program respectively. The rollback instance and the continuation instance are run through the controlled storage service table, and the candidate upgrade program is prohibited from directly accessing the real firmware area, the boot entry point and the formal recovery record. Global access event sequence numbers are assigned to the same sequence number space for read and write events. Read events within the same thread that are located between adjacent writes and belong to the current instruction's read object set are associated with the current write. The source of the read and the most recent preceding write of the same object are recorded to form a bidirectional side effect record. According to the global access event sequence number, the read is responded to with the most recent previous write value or the initial interrupt shadow state value of the object location, and the shadow state is updated accordingly to form the rollback result shadow state and the continuation result shadow state.

6. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 1, characterized in that, S4 specifically includes: Using each side effect as a node, directed edges are established based on the source of the read, the most recent previous write to the same object, and the execution prerequisites of the application software instructions, forming a causal relationship between the fallback side effect and the continuation side effect. The state before execution is reviewed according to the topological order of the causal relationship between the two types of side effects. The shadow state of the rollback result is compared with the current stable state, and the shadow state of the continuation result is compared with the target stable state to form a bidirectional recovery result for each recovery interruption point.

7. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 6, characterized in that, Also includes: For each side effect, a prefix status summary table is generated. The continuation entry that matches the prefix status is checked, or a compensation sequence is generated based on the complete content of the current stable state to sequentially perform full page erasure, full old page writing, startup entry recovery, and formal recovery record recovery. When all cutpoints are bidirectionally accessible and all prefixes have a continuation entry or compensation sequence, a recovery responsibility handover certificate is generated.

8. The method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 2, characterized in that, S5 specifically includes: The system uses the cloud signature verification public key pre-installed on the electronic price tag to verify the handover certificate of responsibility for the recovery. It alternately writes two installation progress log slots in an independent log area that is inaccessible to the application software instruction set, and performs page erasure, startup entry modification and formal recovery record update according to the formal installation sequence. If the installation is interrupted, the execution prefix is ​​determined from the log slot with the largest valid log generation. If the log slot is invalid, the actual object state is compared with the prefix state summary table to determine a unique execution prefix. The corresponding continue entry is called to continue the installation, or the compensation sequence is executed to restore the current stable state.

9. A method for cloud management and OTA remote upgrade of a long strip electronic price tag according to claim 8, characterized in that, Also includes: After the formal installation is completed, launch the target version, verify the parsing results of the candidate upgrade program on the formal recovery record and the confirmation of the cloud upgrade completion. After the verification is successful, switch the recovery entry to the candidate upgrade program and release the area occupied by the current upgrade program.

10. A cloud-based management and OTA remote upgrade system for elongated electronic shelf labels, employing the cloud-based management and OTA remote upgrade method for elongated electronic shelf labels as described in any one of claims 1 to 9, characterized in that... include: The module includes a cloud management module, an installation dependency building module, an interruption recovery building module, a shadow execution module, a recovery verification module, a formal installation and interruption recovery module, and a recovery responsibility switching module.

Images