Remote data management method and system for fuel dispenser based on cloud communication

Abstract

The present application relates to the technical field of fuel dispenser data management, in particular to a fuel dispenser remote data management method and system based on cloud communication. A site terminal generates batch data blocks by time threshold packet, performs reversible compression and anchor point insertion, and generates batch metadata with a hash tree root value as a batch identifier; a secure session is established with the cloud when online, and transactions are uploaded in priority; when offline, data blocks and metadata are spouted into optical frame columns, broadcasted by a price display screen, collected and decoded by a mobile terminal video, and uploaded. The cloud restores data blocks based on reconstruction fragments and metadata, verifies integrity with frame-level checking and batch identifier verification, and writes transaction records and running status into a transaction library and a timing library respectively with site identifier and batch identifier idempotent deduplication, generates a reply short code to synchronize the site terminal; after network recovery, the batch is supplemented according to the missing list to realize consistent reconciliation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of fuel dispenser data management, in particular to a fuel dispenser remote data management method and system based on cloud communication. BACKGROUND

[0002] The development of fuel dispensers and fuel station management systems has gone through stages from mechanical metering to electronic metering, and then to digitalization linked with station-level back office, cash register and tank level monitoring. To solve the integration difficulties caused by the coexistence of multiple devices, multiple manufacturers and multiple protocols in the station, the industry formed a system architecture centered on the forecourt controller in the early 1990s, and gradually promoted the standardization of communication protocols. The International Forecourt Standards Forum (IFSF) was established in 1992 to define the interconnection of messages and device status models for fuel dispensers, level meters, price signs, outdoor payment terminals and other forecourt equipment. Its purpose is to reduce dependence on proprietary protocols and promote the interoperability of devices from different manufacturers. Early attempts such as EPSI appeared in Germany, but their influence was mainly limited to the domestic market. The IFSF standard has been widely deployed in Europe and some emerging markets, and its communication layer has since migrated to TCP / IP, with controllers or protocol converters to connect existing devices to a unified interface. At the same time, wet stock management and telemetry (ATG, inventory and leakage monitoring) evolved from single-station localization to cloud-based services. Typical examples include cloud platforms for oil station networks that monitor and analyze oil inventory, transactions and alarms, providing remote reporting, compliance and discrepancy checking capabilities. This type of "cloud management" has been gradually adopted by forecourt controllers and station-level software to enable remote visualization, alarm and operational support across sites. The above process reflects the industry's evolution from "device-driven" to "standardized interconnection" and then to "cloud and data-driven".

[0003] Although the industry continues to make progress in standardization and cloudization, there are still some common deficiencies in the promotion and landing of existing technologies, especially in remote or small site environments. First, the network conditions at the site are uneven, and when there is a lack of stable wired or cellular links, transaction and operation data is difficult to upload in time, resulting in a gap in central side accounting and inventory analysis, and after transmission, it is easy to cause repeated warehousing and inconsistent accounts. Second, the cost of upgrading existing sites is high, and the early equipment protocols are heterogeneous, with significant investment in wiring and adding industrial control hosts, which limits the coverage of the management system in small and medium-sized sites. Third, the emergency reporting path in weak network or offline scenarios lacks data integrity and source credibility, and the common approach focuses on "transmitting it", but lacks support in batch consistency verification, idempotent deduplication, and traceable audit, requiring a lot of manual intervention for subsequent reconciliation. Fourth, although centralized regulation across sites can rely on cloud platforms, there is a lack of unified mechanisms for terminal-side data compression, synchronization boundaries, and breakpoint recovery, which can cause "partially transmitted, not fully restored" problems, affecting data closure and regulatory timeliness. Fifth, although portable collection through mobile devices can alleviate network deficiencies in some scenarios, the effectiveness constraints of the collection and upload process, batch-level authentication, and station-end marker closure mechanisms are not complete. In summary, there is still room for improvement in the reliable, low-cost, and auditable data return and reconciliation capabilities of existing solutions in weak network and offline conditions, so a remote data management method and system for fuel dispensers based on cloud communication are needed to solve the above problems. SUMMARY

[0004] (I) The technical problem solved: In view of the deficiencies of the prior art, the present invention provides a remote data management method and system for fuel dispensers based on cloud communication, which solves the above problems.

[0005] (II) Technical solution: To achieve the above purpose, the present invention provides the following technical solution: A remote data management method for fuel dispensers based on cloud communication, the method comprising: S1: a site terminal collects transaction records and operating status of a fuel dispenser, packages batch data blocks according to a time threshold, performs reversible compression and anchor insertion on the batch data blocks, and calculates a hash tree root value as a batch identifier, generates batch metadata, the batch metadata at least includes the batch identifier, site identifier, start and end time and record number; S2: in an online state, the site terminal establishes a secure session with the cloud, uploads the batch data blocks according to a hierarchical strategy prioritizing transactions, and the cloud completes signature verification, deduplication and shunting to the database; S3: in an offline state, the site terminal sprays the batch data blocks and their batch metadata to generate an optical frame column containing batch metadata, payload segments and check information, and broadcasts it through the fuel dispenser display screen.

[0006] S2: in an online state, the site terminal establishes a secure session with the cloud, uploads the batch data blocks according to a hierarchical strategy prioritizing transactions, and the cloud completes signature verification, deduplication and shunting to the database; S3: in an offline state, the site terminal sprays the batch data blocks and their batch metadata to generate an optical frame column containing batch metadata, payload segments and check information, and broadcasts it through the fuel dispenser display screen.

[0007] S4: the mobile collection terminal collects and decodes the optical frame column to obtain a reconstructed fragment set, batch metadata and check information and upload to the cloud; S5: the cloud reconstructs the batch data block based on the reconstructed fragment set and batch metadata, verifies the integrity according to the check information and the batch identifier in the batch metadata, and executes deduplication with the combination of the site identifier and the batch identifier in the batch metadata as an idempotent key, and writes the transaction record and the running state into the transaction and time sequence databases respectively; S6: the cloud generates a return short code according to the batch identifier in the batch metadata and returns it to the mobile collection terminal, and the mobile collection terminal synchronizes the confirmation information to the site terminal after verification, and the site terminal marks the batch as reported; S7: when the site network is restored, the site terminal transmits the account book by batch in sequence, and the cloud matches the batches that have been stored in the database according to the batch identifier in the batch metadata and skips the repetition, and only stores the missing batches to complete the reconciliation.

[0008] Further, in S1, the reversible compression includes: first-order incremental encoding the timestamp and the value field in the batch data block, and second-order difference encoding the obtained incremental sequence, storing the difference value in variable-length encoding between adjacent anchor points, and recording the absolute value of the corresponding field at each anchor point, so that the batch data block can be losslessly restored in the cloud; the anchor point insertion includes: inserting anchor points at a record interval in the batch data block , wherein is 8 to 16, and each anchor point includes the absolute timestamp of the batch and the cumulative record count from the start of the batch.

[0009] Further, the check information of S3 includes a truncated message authentication code calculated based on a batch key, wherein the batch key is derived from the device key and the batch metadata through HMAC operation, and each optical frame at least contains a frame synchronization field, a batch identifier in the batch metadata, a fountain load fragment and the truncated message authentication code.

[0010] Further, the broadcast frame rate of the optical frame column is six to ten frames per second; the fountain framing divides the batch data block into original fragments and uses a redundancy coefficient , of 1.05 to 1.15, so that when the number of valid fragments in the reconstructed fragment set that pass the verification through the check information is not less than , the cloud can reconstruct the batch data block.

[0011] Further, the S4 comprises: the mobile acquisition terminal acquires and decodes the optical frame column to generate the reconstructed fragment set at a video of twenty-four to thirty frames per second; when the mobile acquisition terminal has no network connection, the reconstructed fragment set, batch metadata and check information are locally cached, and when the network is available, they are packaged as upload data packets and uploaded to the cloud; wherein the cloud only receives and processes when the upload data packet simultaneously contains the reconstructed fragment set, batch metadata and check information.

[0012] Further, the S5 comprises: the reconstructed batch data block recalculates the hash tree root value and compares it with the batch identification in the batch metadata; the number of batch metadata records and the number of reconstructed records are consistent, and the batch start and end times are within the preset tolerance; after passing the foregoing verification, the de-duplication is performed with the combination of the site identification and the batch identification as the idempotent key; in a single transaction, the transaction record is written into the transaction database, the running state is written into the time-series database, and the audit record containing the server timestamp, site identification, batch identification, record number, integrity check result and feedback status are written; any write failure triggers overall rollback and marks the batch as to be retried; and the batch identification or the hash tree root value is anchored with a trusted timestamp.

[0013] Further, the S6 comprises: the cloud performs message authentication operation using the device key according to the batch identification and the server timestamp in the batch metadata, and truncates to obtain a feedback short code, the length of the feedback short code is six to eight bits, and the validity period is set to ten minutes to twenty-four hours based on the server timestamp; the mobile acquisition terminal synchronizes the feedback short code to the site terminal in the form of a two-dimensional code or character code after local verification, and the site terminal only marks the corresponding batch as reported if the device key verification is passed, the validity period is within the validity period, and the cloud has not been marked as used; after receiving the confirmation, the cloud marks the feedback short code as used to prevent repeated submission.

[0014] Further, the S7 comprises: the cloud generates a missing list according to the site identification and the batch identification when the site network is restored, and limits it within a backtracking window, the backtracking window is twenty minutes to twenty-four hours or equivalent two hundred to five hundred batches; the site terminal only supplements the batch listed in the missing list in batch order, and the cloud updates the missing list in real time for each successfully stored batch until the missing list is empty.

[0015] Further, the application also provides a fuel dispenser remote data management system based on cloud communication, comprising at least one processor and a memory, the memory stores computer program instructions, and the computer program instructions are executed by the processor to make the system execute the cloud communication-based fuel dispenser remote data management method of any of the foregoing methods.

[0016] (Three) beneficial effects: compared with the prior art, the present application provides a fuel dispenser remote data management method and system based on cloud communication, which has the following beneficial effects: the fuel dispenser remote data management method and system based on cloud communication, by batch data block formed by time threshold, reversible compression and anchor point insertion, and hash tree root value as batch identification metadata modeling, seamless switching between online and offline links: online according to "transaction priority" hierarchical transmission fast into cloud, offline "batch data block plus batch metadata" fountain frame into optical frame column on the fuel dispenser display screen broadcast, video acquisition and decoding by mobile acquisition terminal and uploaded to the cloud; the cloud carries out double integrity check on frame level check information and batch identification, realizes deduplication based on site identification and batch identification joint idempotent key, and writes transaction record and running state into transaction library and time sequence library respectively in a single transaction, and returns a short code to complete the station end closed loop, and after network recovery, according to the missing list, the batch is transmitted to ensure the final consistency. Thus, first, it solves the "data empty window" caused by the unstable uplink of remote or weak sites, and the optical emergency channel and fountain redundancy ensure that "enough fragments can be restored"; second, it solves the problem of lack of credibility and audit in offline emergency reporting, batch identification, frame level message authentication and audit record together guarantee the source can be verified, the process can be traced back; third, it solves the problem of repeated storage and inconsistent accounts, joint idempotent key and transaction storage ensure unique storage and consistent account reconciliation; fourth, it solves the problem of "transmitting a part and not restoring the full amount", anchor point and reversible compression support breakpoint reconstruction and lossless recovery; fifth, it reduces the transformation and wiring cost, and reuse of price display screen and mobile terminal can complete offline transmission; sixth, it improves the coverage and timeliness of cross-station centralized supervision, so that small or transformed sites also have low-cost, auditable and closed-loop data remote management capabilities. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 The fuel dispenser remote data management method based on cloud communication provided by the present application is shown in the flowchart.

[0018] Figure 2 The fuel dispenser remote data management method based on cloud communication provided by the present application is shown in the flowchart.

[0019] Figure 3 The fuel dispenser remote data management system based on cloud communication provided by the present application is shown in the structural diagram. DETAILED DESCRIPTION

[0020] Clearly, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0021] In order for those skilled in the art to better understand the technical scheme of the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0022] Please refer to Figure 1 , Figure 1 The flowchart of the remote data management method of the fuel dispenser based on cloud communication provided by the present application is shown in the figure. Figure 2 The timing diagram of the remote data management method of the fuel dispenser based on cloud communication provided by the present application is shown in the figure. The remote data management method of the fuel dispenser based on cloud communication is characterized in that the method comprises: S1: the site terminal collects the transaction records and running status of the fuel dispenser, packages the batch data block according to the time threshold, performs reversible compression and anchor insertion on the batch data block, calculates the hash tree root value as the batch identifier, generates the batch metadata, and the batch metadata at least includes the batch identifier, site identifier, start and end time and record number; S2: in the online state, the site terminal establishes a secure session with the cloud, uploads the batch data block according to the hierarchical strategy of transaction priority, and the cloud completes the signature verification, deduplication and shunting into the database; S3: in the offline state, the site terminal sprays the batch data block and its batch metadata, generates an optical frame column containing batch metadata, load segment and check information, and broadcasts it through the fuel dispenser display screen; S4: the mobile collection terminal video collects and decodes the optical frame column, obtains the reconstructed segment set, batch metadata and check information and uploads them to the cloud; S5: the cloud reconstructs the batch data block based on the reconstructed segment set and batch metadata, verifies the integrity according to the check information and batch identifier in the batch metadata, performs deduplication with the site identifier and batch identifier in the batch metadata as the idempotent key, and writes the transaction records and running status into the transaction and time sequence databases respectively; S6: the cloud generates a short reply code according to the batch identifier in the batch metadata and returns it to the mobile collection terminal, and the mobile collection terminal synchronizes the confirmation information to the site terminal after verification, and the site terminal marks this batch as reported; S7: when the site network is restored, the site terminal transmits the account book according to the batch order, and the cloud matches the batches that have been stored in the database according to the batch identifier in the batch metadata and skips the duplicates, only stores the missing batches to complete the reconciliation.

[0023] In this embodiment, the method is completed by the site terminal, mobile acquisition terminal and cloud platform. The technical principle is to aggregate the refueling business data into a batch unit that is verifiable, locatable and recoverable in a time window at the site side, and to seamlessly switch between two links when the network condition changes to ensure data closed loop and consistency. Specifically, in S1, the site terminal continuously acquires transaction records and running status, rolls up the batch data block according to the time threshold, reversibly compresses the fields in the block to reduce transmission and storage overhead, inserts anchor points as synchronization and breakpoint recovery boundaries, constructs a hash tree for the records in the batch and takes the root value as a unique batch identifier, and forms batch metadata together with the site identifier, start and end time, record number, etc., thereby providing a basis for subsequent verification and traceability. In S2, if the network is available, the site terminal establishes a secure session with the cloud, uploads the batch data block according to the transaction priority principle, and the cloud completes source verification, duplicate detection and data type shunting into the database, realizing real-time aggregation. In S3, if the network is not available, the site terminal sprays the batch data block and its metadata, generates an optical frame column containing metadata, load segments and check information, and broadcasts it at a predetermined frame rate through the dispenser screen, forming an emergency reporting channel without wiring. In S4, the mobile acquisition terminal takes a picture and decodes it, recovers and reconstructs the segment set and uploads it together with the batch metadata and check information to the cloud. In S5, the cloud reconstructs the batch data block based on the segment set and metadata, first verifies the integrity based on the frame-level check information and batch identifier, then performs deduplication using the combination of the site identifier and batch identifier as an idempotent key, and then writes the transaction records into a transaction database and the running status into a time-series database, ensuring atomicity and queryability of the write. In S6, the cloud generates a short code return to the mobile acquisition terminal based on the batch identifier, and the mobile acquisition terminal synchronizes the confirmation to the site terminal after verification, and the site terminal marks the batch as reported based on this, forming an in-site closed loop. In S7, when the site network is restored, the site terminal supplements the shift account according to the batch order, and the cloud matches the batch identifier to match the database and skips the duplicate, only falling into the missing batch to achieve final consistency. The role of this embodiment is to realize verifiable remote data management in batches, which is compatible with online direct connection and offline optical channel in function, and can be deployed in remote small stations without additional computers or new wiring, while ensuring the integrity, idempotency and auditability of the data.

[0024] Further, in S1, the reversible compression includes: first-order incremental encoding of the timestamp and numerical field in the batch data block, and second-order difference encoding of the obtained incremental sequence, storing the difference value between adjacent anchor points with variable length encoding, and recording the absolute value of the corresponding field at each anchor point, so that the batch data block can be losslessly recovered in the cloud; anchor point insertion includes: inserting anchor points at a record number interval in the batch data block, wherein the anchor point includes: a timestamp, a numerical field, and a batch identifier, and the batch identifier is a hash value of the record number interval. The number of anchors is 8 to 16, and each anchor includes the absolute timestamp of the batch and the cumulative record count since the start of the batch.

[0025] In this embodiment, after the site terminal obtains the batch data block by completing the time threshold encapsulation, it first performs first-order incremental encoding on the numerical fields such as "timestamp, volume, unit price, amount, pump pressure, and temperature," replacing the field value of each record with the difference relative to the previous record. Then, it performs secondary differencing on the resulting difference sequence, concentrating slowly changing or locally stable sequences into small-amplitude integers. Subsequently, variable-length encoding is used to store these difference values ​​between adjacent anchor points to significantly reduce storage and transmission volume. To avoid error propagation and facilitate random positioning and breakpoint recovery, the system intervals the data by the number of records. Insert anchor point ( (Taking 8 to 16), each anchor point is written with the absolute timestamp of the current batch and the cumulative record count since the start of the batch, and the absolute value of the fields that need to be restored without loss is recorded at the anchor point. In this way, when restoring on the cloud side, only the absolute value and cumulative count of any anchor point need to be read, and subsequent records can be reconstructed from that anchor point by reversing the process of "quadratic difference restoration to first-order increment, and then accumulation of the first-order increment to the absolute value". If a segment of data is lost or out of order, the cloud can skip the missing segment and directly realign from the next anchor point, avoiding the need to backtrack and decode the entire segment, thereby improving the robustness and efficiency of reconstruction. Taking a real-world scenario of a batch of data from a remote small station every 5 minutes as an example, a batch typically contains more than ten transactions and several status points. After incremental and secondary differential, most of the differential values ​​fall into the small integer range. Combined with variable-length encoding, the batch data blocks can be compressed to a lower proportion of the original size. At the same time, since the anchor points provide absolute time and record counts, even if individual segments are lost during fountain-style framing and offline optical broadcasting, the cloud can still restore them without loss from the nearest anchor point. This does not affect subsequent integrity verification and idempotent data entry using batch identifiers, ensuring data accuracy while also taking into account accessibility and maintainability in weak network environments.

[0026] Furthermore, the verification information of S3 includes a truncated message authentication code calculated based on the batch key, wherein the batch key is derived from the device key and batch metadata through HMAC operation, and each optical frame contains at least a frame synchronization field, a batch identifier in the batch metadata, a fountain load fragment, and the truncated message authentication code.

[0027] In this embodiment, the station terminal performs HMAC operation on the batch metadata using the device key to derive a "batch key" as the symmetric authentication key for the optical broadcast of the batch after generating the metadata of each batch; then constructs the minimum necessary fields for each optical frame to be broadcast: frame synchronization field for boundary positioning, batch identification for cross-link association and anti-batch stringing, data payload segment carrying the fountain encoded data, and truncated message authentication code calculated based on the aforementioned batch key (message authentication is performed on the frame header and payload segment, and then truncated to reduce the codeword length). During the price display screen broadcast process, even if there is ambient light variation, shooting jitter, or individual frame loss, the mobile acquisition terminal can first rely on the synchronization field to quickly find the frame boundary, then read the batch identification to determine the ownership, and then quickly determine the authenticity and integrity of the frame using the truncated message authentication code; unqualified frames will be discarded immediately without entering the reconstruction; when the acquisition end accumulates sufficient qualified segments, it uploads to the cloud; the cloud derives the same batch key based on the known device key and batch metadata, recalculates and compares the truncated message authentication code frame by frame, realizes consistent integrity and source verification between the end and the cloud, and thus ensures that the segments are unforgeable and cannot be tampered with without traces, and avoids mixing different site or batch segments, ultimately providing trusted input for fountain decoding and batch-level reconstruction.

[0028] Further, the broadcast frame rate of the optical frame column is six to ten frames per second; the fountain frame divides the batch data block into original segments and uses a redundancy coefficient , of 1.05 to 1.15, so that when the number of valid segments that pass the verification through the verification information in the reconstructed segment set is not less than

[0029] , the cloud can reconstruct the batch data block. In this embodiment, the station terminal outputs an optical frame column at a broadcast frame rate of six to ten frames per second in an offline scene, and the technical principle is to strike a balance between the refresh ability of a general price display screen and the sampling ability of a mobile acquisition terminal (24-30 fps) to achieve stable sampling and anti-flicker: too low a frame rate will result in too long a delay for the entire batch broadcast, and too high a frame rate will easily cause rolling stripes and uneven exposure, increasing the error code; six to ten frames per second can still obtain sufficient valid frames for the acquisition end under most lighting and jitter conditions. To alleviate the natural frame loss and local occlusion of the offline optical link, the batch data block is fountain framed into original segments and a redundancy coefficient (1.05-1.15) is introduced, i.e., 5%-15% of redundant segments are additionally broadcasted in addition to the original segments, so that the mobile acquisition terminal only needs to accumulate to a "valid segment number" that passes the verification through the truncated message authentication code to reach . For The decoding set can be completed by rounding up to the nearest integer, thereby avoiding the stringent requirement of "no missing in the full segment". In combination with field application, when the mountainous small station is under strong backlight and human flow shielding for emergency broadcasting, even if the collected video has occasional jitter, automatic exposure jump, partial frame blur or screen reflection leading to recognition failure, the fountain redundancy still allows the mobile terminal to accumulate enough effective segments after multiple short-time collection and upload. After the cloud determines the "effective segment number " accordingly, the original batch data block can be reconstructed, and then the integrity check, idempotent deduplication and shunting to the database can be completed according to the S5 step. The role and function of this parameter design is to exchange a small amount of redundancy for robust reachability and controllable broadcast delay: on the one hand, it significantly reduces the threshold that single collection must be "uninterrupted from beginning to end", and on the other hand, it shortens the whole batch broadcast time under limited display bandwidth, improves the efficiency of on-site operation, and improves the success rate and reproducibility of weak network or offline scenarios.

[0030] Further, the S4 comprises: the mobile collection terminal collects and decodes the optical frame column at a rate of twenty-four to thirty frames per second to generate the reconstructed segment set; when the mobile collection terminal has no network connection, the reconstructed segment set, batch metadata and check information are cached locally, and when the network is available, they are packaged as upload data packets and uploaded to the cloud; wherein the cloud only receives and processes when the upload data packet contains the reconstructed segment set, batch metadata and check information at the same time.

[0031] In this embodiment, the mobile collection terminal collects the optical frame column broadcast by the pump price display screen at a rate of twenty-four to thirty frames per second, applies the built-in decoding pipeline to sequentially complete frame synchronization positioning, batch identification reading, fountain segment extraction, and frame-level message authentication verification, only uses the verified segments for decoding and generates a reconstructed segment set, and simultaneously packages the paired batch metadata and verification information into the local persistent cache; to adapt to weak network environments, when no available network is detected, the terminal stays in cache mode and continuously appends new reconstructed segment sets; once the network is available, the "reconstructed segment set, batch metadata, and verification information" are packaged as an upload data packet and uploaded to the cloud through a secure channel; the access verification gateway of the cloud checks the structure of the upload data packet, only processes it when the three elements are present and correctly formatted, otherwise returns a missing indication to prompt the terminal to continue collecting or retransmitting, thereby avoiding incomplete reports such as "only segments without metadata" and "only metadata cannot be reconstructed" entering the subsequent reconstruction and warehousing link; in typical applications in remote mountainous areas, maintenance personnel can first complete screen collection and local decoding caching in areas without signal, then move to a location outside the station with 4G signal to trigger automatic uploading, and after the cloud successfully receives the compliant upload data packet, the reconstruction, integrity verification, and deduplication warehousing process is entered; if the network fluctuation during uploading causes interruption, the application will retain the upload data packet and retry according to the exponential backoff strategy, ensuring that the same batch does not need to be collected repeatedly to be ultimately delivered, thereby achieving seamless connection and engineering usability of offline collection and online uploading without additional wiring and computers.

[0032] Further, the S5 includes: recalculating the hash tree root value of the reconstructed batch data block and comparing it with the batch identification in the batch metadata, and verifying that the number of batch metadata records and the number of reconstructed records are consistent and that the batch start and end times are within the preset tolerance; after passing the foregoing verification, performing deduplication using the combination of the site identification and the batch identification as an idempotent key; in a single transaction, simultaneously writing transaction records to a transactional database, writing running status to a time-series database, and writing audit records containing server timestamps, site identification, batch identification, record number, integrity verification result, and receipt status, and triggering overall rollback and marking the batch as to be retried if any write fails; and anchoring the batch identification or the hash tree root value with a trusted timestamp.

[0033] In this embodiment, after receiving the reconstructed fragment set and batch metadata uploaded by the mobile collection terminal, the cloud enters the verification, deduplication and atomic warehousing process. The technical principle is to ensure data uniqueness, verifiability and recoverability through three mechanisms of encryption digest, consistency index and transaction control. First, the cloud recalculates the hash tree root value of the batch according to the reconstructed batch data block, and compares the obtained root value with the batch identifier in the batch metadata one by one. If they are consistent, it is determined that the content has not been tampered with. Then, the cloud performs equality verification on the record number recorded in the batch metadata and the actual record number obtained by reconstruction, and verifies that the batch start and end time is within the preset tolerance. The tolerance is used to absorb the small drift of the terminal clock or the boundary difference caused by the time zone standardization. Only when all the above verifications pass, the cloud executes deduplication with the combination of the site identifier and the batch identifier as the idempotent key. It can be implemented through unique index or idempotent write interface, that is, if there is already a record with the same combination key, it is determined as a retransmission and does not repeat the warehouse, otherwise it performs new warehouse. To avoid partial success causing inconsistent accounts, the cloud completes three types of writing in a single transaction, namely writing transaction records into a transaction database, writing running status into a time series database, and writing audit records containing server timestamp, site identifier, batch identifier, record number, integrity verification result and feedback status. Any failed write will trigger a whole rollback and mark the batch state as pending retry. The retry can be triggered by a background task according to the exponential backoff strategy to ensure the final success and not produce duplicate data. To enhance external provability, the cloud also anchors the batch identifier or the above hash tree root value to apply a trusted timestamp to generate a time proof. The proof is saved in association with the audit record for subsequent evidence and cross-institution reconciliation scenarios. Taking an actual application as an example, a remote site uploads the same batch through offline optical link and then supplements it twice by site direct connection after network recovery. The cloud automatically identifies the second write as a retransmission and skips it due to the same idempotent key. Since the three table writes are in the same transaction, there will be no situation of separated transaction and state. If the write fails due to time series database failure, the whole rollback and enters the pending retry queue. After the service is restored, it is automatically submitted again to ensure that the batch is only warehoused once and the full amount is traceable.

[0034] Further, the S6 includes: the cloud uses the device key to perform message authentication operation according to the batch identifier and the server timestamp in the batch metadata, and truncates to obtain a feedback short code. The length of the feedback short code is six to eight bits, and the validity period is set to ten minutes to twenty-four hours based on the server timestamp. After the mobile collection terminal verifies the feedback short code locally, it is synchronized to the site terminal in the form of a two-dimensional code or character code. The site terminal only marks the corresponding batch as reported if the device key verification is passed, the validity period is within, and it has not been marked as used by the cloud. After receiving the confirmation, the cloud marks the feedback short code as used to prevent repeated submission.

[0035] In this embodiment, after completing the batch reconstruction and warehouse check, the cloud takes the batch identifier and server timestamp in the batch metadata as input, combines with the device key to perform message authentication operation and truncates the output to generate a six to eight digit short code, and sets the validity period to ten minutes to twenty-four hours according to the server timestamp to limit the replay window; the mobile collection terminal receives the short code from the cloud and performs local pre-checking, the checking principle is to re-calculate and compare the truncated results according to the same input combination and the paired verification key, thereby excluding counterfeit or expired short codes before station interaction, and then synchronously giving the station terminal in the form of two-dimensional code or character code (which can be transmitted through local wired connection, Bluetooth or the same local area network); the station terminal performs two-level verification after receiving, first performs consistency check on the short code based on the device key and checks whether the current time falls within the validity period, and secondly queries the use state of the short code from the cloud through the mobile collection terminal as a network bridge, only when both pass and the cloud returns that it has not been marked as used, the station terminal will update the corresponding batch state to reported and record the time and operator identifier, the cloud immediately marks the short code as used after receiving the confirmation to achieve idempotent control, any subsequent repeated submission of the same batch will be rejected due to the cloud returning that it has been used; in the actual process of remote stations, when the maintenance personnel complete offline collection with the mobile phone and trigger cloud reconstruction and warehouse, the mobile phone receives the short code and passes the local check, and then returns to the station to display the short code to the station terminal for scanning or input, the station terminal completes the unused state confirmation with the cloud through the data channel of the mobile phone, and finally completes the station state closed loop and cloud idempotent locking, which solves the risks of short code forgery, cross-station misuse, repeated submission and late reporting, and ensures the uniqueness and traceability of batch-level reconciliation.

[0036] Further, the S7 includes: the cloud generates a missing list according to the station identifier and batch identifier when the station network is restored, and is limited within the backtracking window, which is twenty minutes to twenty-four hours or equivalent two hundred to five hundred batches; the station terminal only supplements the batches listed in the missing list according to batch order, and the cloud updates the missing list in real time for each successfully warehoused batch until it is empty.

[0037] In this embodiment, the cloud-based index of data already stored in the database is compared with the local ledger of the site terminal within a limited time or batch number range using a difference set comparison. A missing data list, ordered chronologically, is generated using the site identifier and batch identifier as keys. The site terminal then strictly follows the list order to perform data retransmission, and after each batch is successfully stored, the cloud immediately removes completed items from the list until it is empty, thus avoiding full retransmission and duplicate data storage. Specifically, when the site network recovers, the site terminal first completes a handshake with the cloud and reports the range of its most recent local ledger. The cloud retrieves the set of batches already stored in the database within a backtracking window and calculates the difference with the site's range to obtain the missing data list. This list only contains batches to be supplemented and is sorted by batch start time before being returned to the site. The site terminal then sends batch data blocks accordingly. The cloud uses the aforementioned idempotent key for deduplication and updates the list and audit records immediately after each batch is verified for storage. If data retransmission is interrupted or individual batches fail, the site terminal can... The process continues from where it left off, based on the latest list returned from the cloud, avoiding starting from scratch. The limited window prevents the massive historical data transmission caused by long-term, large-scale network outages from consuming bandwidth, and also makes the convergence process controllable and observable. Taking a remote small station as an example, the station generates eighteen five-minute batches during the ninety-minute network outage. Six of these batches have been sent to the cloud via the offline optical link of the mobile acquisition terminal. After the network is restored, the cloud returns a list of only twelve missing batches after comparison within the retrospective window. The station terminal transmits the twelve batches in sequence, and the cloud verifies and stores each batch in the database and reduces the list in real time. When the list is finally cleared, it means that the ledger is completely consistent with the central database for that period. The role of this mechanism is to significantly reduce duplicate traffic and manual reconciliation costs after network restoration, ensure batch order and database consistency, accelerate the recovery and convergence of weak network environments, and ensure that all data transmissions are still constrained by idempotent keys and audit records, as well as the traceability of the process.

[0038] Furthermore, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of the cloud-based remote data management system for fuel dispensers provided by the present invention. The present invention also provides a cloud-based remote data management system for fuel dispensers, including at least one processor and a memory. The memory stores computer program instructions, which, when executed by the processor, cause the system to perform the aforementioned cloud-based remote data management method for fuel dispensers.

[0039] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting; it is not intended to exclude myriad other embodiments of the present application that other inventors can develop based on the same general inventive concepts embodied by the described embodiments. That is, although the present application is described in terms of particular embodiments and implementations, it is to be understood that the terminology used is for the purpose of descriptive clarity and that it is intended to be limited only by the words recited in the appended claims. The scope of the present application shall be limited only by the claims.

[0040] While the embodiments of the application have been shown and described herein, it is to be understood that the application is not limited to these embodiments. Rather, numerous modifications are possible without departing from the spirit and scope of the present application as delineated by the claims and their equivalents.

Claims

1. A remote data management method for fuel dispensers based on cloud communication, characterized in that: The method includes: S1: The station terminal collects transaction records and operating status of the fuel dispenser, encapsulates them into batch data blocks according to time thresholds, performs reversible compression and anchor insertion on the batch data blocks, calculates the hash tree root value as the batch identifier, and generates batch metadata. The batch metadata includes at least the batch identifier, station identifier, start and end time, and number of records; S2: In online mode, the station terminal establishes a secure session with the cloud, uploads the batch data blocks according to a transaction-priority hierarchical strategy, and the cloud completes signature verification, deduplication, and distribution into the database; S3: In offline mode, the station terminal performs fountain-style framing on the batch data blocks and their batch metadata to generate an optical frame series containing batch metadata, payload fragments, and verification information, and broadcasts it through the fuel dispenser display screen; S4: The mobile acquisition terminal performs video acquisition and decoding on the optical frame series. S5: Obtain the reconstructed fragment set, batch metadata, and verification information and upload them to the cloud; S6: The cloud reconstructs the batch data block based on the reconstructed fragment set and batch metadata, verifies the integrity based on the verification information and the batch identifier in the batch metadata, and performs deduplication using the combination of the site identifier and the batch identifier in the batch metadata as an idempotent key, writes the transaction record to the transactional database, and writes the running status to the time-series database; S7: The cloud generates a short receipt code based on the batch identifier in the batch metadata and returns it to the mobile acquisition terminal. After verification, the mobile acquisition terminal synchronizes the confirmation information to the site terminal, and the site terminal marks the batch as reported; S8: When the site network recovers, the site terminal re-uploads the ledger in batch order. The cloud matches the batches already stored in the database based on the batch identifier in the batch metadata and skips duplicates, only storing the missing batches to complete the reconciliation.

2. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that, In step S1, reversible compression includes: performing first-order incremental encoding on the timestamp and numerical fields within the batch data block and performing secondary differential encoding on the resulting incremental sequence; storing the differential values ​​between adjacent anchor points using variable-length encoding; and recording the absolute value of the corresponding field at each anchor point, so that the batch data block can be losslessly recovered in the cloud; anchor point insertion includes: inserting anchor points at intervals according to the number of records within the batch data block. Insert anchor points, where The number of anchors is 8 to 16, and each anchor includes the absolute timestamp of the batch and the cumulative record count since the start of the batch.

3. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that: The verification information of S3 includes a truncated message authentication code calculated based on the batch key, wherein the batch key is derived from the device key and batch metadata through HMAC operation, and each optical frame contains at least a frame synchronization field, a batch identifier in the batch metadata, a fountain load fragment, and the truncated message authentication code.

4. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that: The optical frame series is broadcast at a frame rate of six to ten frames per second; The fountain-style framing divides the batch of data blocks. The original fragments were processed using a redundancy factor. , The value is between 1.05 and 1.15, ensuring that the number of valid segments in the reconstructed segment set that pass the verification information is not less than [a certain value]. At that time, the cloud can reconstruct the batch data blocks.

5. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that, S4 includes: the mobile acquisition terminal acquiring and decoding the optical frame series at 24 to 30 frames per second to generate the reconstructed segment set; when the mobile acquisition terminal has no network connection, the reconstructed segment set, batch metadata, and verification information are locally cached, and when the network is available, they are encapsulated into an upload data packet and uploaded to the cloud; wherein, the cloud only receives and processes the upload data packet if it simultaneously contains the reconstructed segment set, batch metadata, and verification information.

6. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that, S5 includes: recalculating the hash tree root value of the reconstructed batch data block and comparing it with the batch identifier in the batch metadata, and verifying that the number of batch metadata records is consistent with the number of reconstructed records and that the start and end times of the batch are within a preset tolerance; after passing the aforementioned verification, performing deduplication using the combination of the site identifier and the batch identifier as an idempotent key; simultaneously writing transaction records to a transactional database, writing the running status to a time-series database, and writing audit records containing server timestamps, site identifiers, batch identifiers, record counts, integrity verification results, and receipt status in a single transaction, triggering an overall rollback and marking the batch as pending retry; and anchoring the batch identifier or the hash tree root value with a trusted timestamp.

7. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that, S6 includes: the cloud uses the device key to perform message authentication calculation and truncates the short receipt code based on the batch identifier and server timestamp in the batch metadata. The short receipt code is six to eight digits long and the validity period is set to ten minutes to twenty-four hours based on the server timestamp. After verifying the receipt short code locally, the mobile acquisition terminal synchronizes it to the site terminal in the form of a QR code or character code. The site terminal marks the corresponding batch as reported only if the device key verification is successful, the batch is valid, and the batch has not been marked as used by the cloud. After receiving the confirmation, the cloud marks the receipt short code as used to prevent duplicate submissions.

8. The remote data management method for fuel dispensers based on cloud communication according to claim 1, characterized in that, S7 includes: when the site network is restored, the cloud generates a missing list based on the site identifier and batch identifier, and limits it to a backtracking window, which is 20 minutes to 24 hours or equivalent to 200 to 500 batches; the site terminal supplements only the batches listed in the missing list according to the batch order, and the cloud updates the missing list in real time for each successfully entered batch until it is cleared.

9. A remote data management system for fuel dispensers based on cloud communication, characterized in that: The system includes at least one processor and a memory, the memory storing computer program instructions, which, when executed by the processor, cause the system to perform the remote data management method for fuel dispensers based on cloud communication as described in any one of claims 1 to 8.

Images