Electronic gas meter remote upgrading system and method

Abstract

The application relates to the technical field of data processing, and discloses an electronic gas meter remote upgrading system and method. The system comprises five core modules: an analysis module obtains the best upgrading opportunity through upgrading condition evaluation; an encapsulation module uses a dynamic key to double-encrypt and protect firmware differential data; a processing module uses a ring buffer to realize reliable fragmentation transmission; a replacement module uses a transaction rollback mechanism to ensure safe firmware replacement; and a verification module performs meter consistency verification and synchronously upgrades the result. The application solves the technical problems of inaccurate upgrading condition determination, insufficient safety, poor transmission reliability and low upgrading safety in the existing electronic gas meter remote upgrading technology, and improves the upgrading success rate, data safety, transmission stability and system reliability.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a remote upgrade system and method for electronic gas meters. Background Technology

[0002] Existing remote upgrade technologies for electronic gas meters mainly adopt a unified push upgrade method. The gas management system sends upgrade instructions and firmware packages to all devices that need to be upgraded simultaneously. During the upgrade process, a fixed encryption key is used to protect the firmware data, and the complete firmware package is sent to the gas meter device in a one-time transmission. After receiving the package, the device directly overwrites the original firmware to complete the upgrade operation. After the upgrade is completed, the device restarts and reports the upgrade result status to the management system.

[0003] However, existing technologies have several technical shortcomings. First, there is the problem of inaccurate upgrade condition determination. The system cannot accurately assess the actual state of the device before blindly performing the upgrade operation, resulting in forced upgrades when the device has insufficient power, poor network signal, or is performing metering tasks. This leads to a high upgrade failure rate and affects normal business operations. Second, there is the problem of insufficient security. Fixed encryption keys are easily cracked and there is a lack of effective anti-tampering mechanisms. Upgrade packages are at risk of being maliciously intercepted and modified during transmission. Third, there is the problem of poor transmission reliability. Transmitting large-capacity firmware packages at once is prone to interruption in unstable network environments. The lack of breakpoint resumption and fragmented retransmission mechanisms means that transmission failures require restarting. Finally, there is the problem of low upgrade security. Directly overwriting the original firmware cannot restore the original state in the event of an upgrade failure. There is a lack of effective rollback mechanisms and integrity verification.

[0004] Based on the analysis of the above-mentioned technical defects, the fundamental problem with the existing technology is that it lacks an intelligent upgrade scheduling mechanism, which cannot optimize the upgrade timing according to the actual status of the equipment. This results in insufficient data security protection during the upgrade process, making it unable to resist network attacks and data tampering. At the same time, the unreliability of the transmission mechanism exacerbates the impact of network environment fluctuations on the upgrade success rate. Finally, the lack of atomicity guarantee and fault recovery capability in the upgrade execution process makes the equipment face the serious risk of not being able to start after the upgrade fails. Furthermore, the lack of a professional verification mechanism for the gas meter metering function after the upgrade cannot ensure the metering accuracy and functional integrity of the upgraded equipment. Summary of the Invention

[0005] This application provides a remote upgrade system and method for electronic gas meters, which solves the technical problems of inaccurate upgrade condition determination, insufficient security, poor transmission reliability and low upgrade security in existing remote upgrade technologies for electronic gas meters, and improves the upgrade success rate, data security, transmission stability and system reliability.

[0006] In a first aspect, this application provides a remote upgrade system for electronic gas meters, the electronic gas meter remote upgrade system comprising:

[0007] The analysis module is used to comprehensively analyze and process the gas meter's operating status parameters through the upgrade condition assessment unit to obtain the upgrade timing prediction result;

[0008] The encapsulation module is used to perform dual encapsulation processing on the firmware differential data using the device identifier dynamic key according to the upgrade timing prediction result, so as to obtain the tamper-proof upgrade payload.

[0009] The processing module is used to perform breakpoint resume processing on the anti-tampering upgrade payload according to the ring buffer structure to obtain the upgrade data block;

[0010] The replacement module is used to perform a safe replacement process on the gas meter program partition based on the upgrade data block through a transactional rollback mechanism, and obtain version switching status information.

[0011] The verification module is used to perform metering consistency verification on the version switching status information, obtain a successful upgrade confirmation signal, and synchronize it to the remote monitoring platform.

[0012] Optionally, the analysis module is used for:

[0013] Real-time data acquisition and processing of gas meter battery voltage, communication signal strength, and storage space occupancy rate yields basic equipment status data.

[0014] Based on the basic status data of the equipment, the current metering task load is monitored and analyzed to obtain the equipment idle status determination result.

[0015] The device idle state determination result is compared and filtered with the preset upgrade condition threshold to obtain the upgrade qualification certification mark;

[0016] Based on the upgrade qualification certification identifier, the device geographical location and network topology are grouped and classified to obtain the upgrade batch division scheme;

[0017] Based on the aforementioned upgrade batch division scheme, time window allocation processing is performed to obtain upgrade timing prediction results.

[0018] Optionally, the encapsulation module is used for:

[0019] Based on the upgrade timing prediction results, the current firmware version and the target firmware version are compared to obtain firmware difference data.

[0020] The device's unique identifier is hashed with the version number of the firmware differential data to obtain the device identification dynamic key;

[0021] Based on the device identifier dynamic key, the firmware differential data is encrypted using the AES symmetric encryption algorithm to obtain a first-level encrypted data packet;

[0022] The device identifier dynamic key is encrypted using the RSA asymmetric encryption algorithm to obtain a second-level encryption key.

[0023] The first-level encrypted data packet and the second-level encryption key are combined and encapsulated to obtain a tamper-proof upgrade payload.

[0024] Optionally, the processing module is configured to:

[0025] The tamper-proof upgrade payload is segmented and cut according to the maximum number of bytes transmitted by the gas meter communication interface to obtain upgrade segments with serial numbers;

[0026] The upgrade fragments with serial numbers are cached and managed based on a circular buffer storage structure to obtain fragment storage bitmap information.

[0027] The fragmented storage bitmap information is synchronized with the transmission status table in real time to obtain a transmission progress tracking record.

[0028] Based on the transmission progress tracking record, retransmission requests are made for the missing fragments in the interrupted transmission to obtain supplementary transmission data.

[0029] The supplementary transmitted data and the received fragments are subjected to integrity verification processing based on the SHA verification algorithm to obtain the upgraded data block.

[0030] Optionally, the replacement module includes:

[0031] The backup unit is used to perform a complete image backup of the currently running firmware based on the upgrade data block to obtain the original version backup data;

[0032] The storage unit is used to perform redundant storage processing on the key configuration parameters and calibration data of the gas meter based on the original version backup data, and to obtain the system checkpoint record.

[0033] The replacement unit is used to input the upgraded data block into the gas meter program partition for atomic replacement processing to obtain the new version program status;

[0034] The verification unit is used to perform verification and analysis of hardware compatibility and dependencies based on the new version program status, and obtain the upgrade security assessment result.

[0035] The execution unit is used to confirm and execute the program switching operation based on the upgrade security assessment results, and obtain version switching status information.

[0036] Optionally, the replacement unit is used for:

[0037] Based on the upgraded data block, the gas meter metering service and communication function are stopped, and the system resource release status is obtained.

[0038] Based on the system resource release status, the integrity and version compatibility of the upgrade data block are verified and checked to obtain the upgrade ready identifier.

[0039] The upgrade readiness flag is used as a trigger condition to write the gas meter program partition segment by segment to obtain the program update progress record.

[0040] Based on the program update progress record, each written program segment is verified and confirmed to obtain segment verification status information.

[0041] Based on the segmented verification status information, the gas meter system is restarted and activated to obtain the new version program status.

[0042] Optionally, the verification module is used for:

[0043] Based on the version switching status information, a self-test scan is performed on the gas meter hardware sensors and communication links to obtain a functional integrity test report.

[0044] Based on the functional integrity test report, simulated measurement processing is performed on the built-in standard flow test points to obtain the upgraded measurement accuracy data.

[0045] The upgraded metrological accuracy data is compared with the factory standard metrological parameters to obtain the metrological consistency verification results.

[0046] Based on the metrological consistency verification results, the detailed upgrade status record is packaged and processed to obtain an upgrade success confirmation signal.

[0047] Based on the successful upgrade confirmation signal, incremental data synchronization processing is performed on the device operating status information to obtain a synchronization completion identifier from the remote monitoring platform.

[0048] Secondly, this application provides a method for remotely upgrading an electronic gas meter, the method comprising:

[0049] The gas meter's operating status parameters are comprehensively analyzed and processed by the upgrade condition assessment unit to obtain the upgrade timing prediction result;

[0050] Based on the upgrade timing prediction result, the firmware differential data is double-encapsulated using the device identification dynamic key to obtain the tamper-proof upgrade payload.

[0051] The tamper-proof upgrade payload is processed by resuming interrupted transmission according to a circular buffer structure to obtain the upgrade data block;

[0052] Based on the upgrade data block, the gas meter program partition is safely replaced using a transactional rollback mechanism to obtain version switching status information;

[0053] The version switching status information is subjected to metering consistency verification processing to obtain a successful upgrade confirmation signal and synchronize it to the remote monitoring platform.

[0054] The technical solution provided in this application uses an upgrade condition evaluation unit to comprehensively analyze and process the gas meter's operating status parameters to obtain an upgrade timing prediction result. This effectively solves the high failure rate problem caused by blind upgrades in existing technologies. By real-time monitoring of key parameters such as battery voltage, communication signal strength, storage space occupancy, and metering task load, an intelligent upgrade condition judgment mechanism is established to ensure that the upgrade operation is only performed when the device has the optimal upgrade conditions, significantly improving the upgrade success rate and avoiding interference with normal business operations. The dual encapsulation processing mechanism of the device identifier dynamic key overcomes the security vulnerability of fixed keys in existing technologies. Each upgrade generates a different dynamic key based on the device's unique identifier and firmware version number. Combined with the dual protection of AES symmetric encryption and RSA asymmetric encryption, a robust anti-tampering upgrade payload is constructed, effectively resisting network attacks and data tampering risks. The ring buffer structure's breakpoint resumption processing solves the problem of upgrade failure caused by transmission interruption in existing technologies. Through fragmented transmission, status tracking, and selective retransmission mechanisms, the integrity and reliability of data transmission can be guaranteed even in unstable network environments. The transactional rollback mechanism ensures the atomicity of the upgrade operation through secure replacement. By using full image backup, redundant storage, and step-by-step verification, it can quickly roll back to a stable state in case of any abnormality at any stage, completely eliminating the risk of the device failing to boot due to upgrade failure.

[0055] The metering consistency verification process addresses the specialized application needs of gas meters. Through a flow simulation calibration module, it comprehensively verifies the upgraded metering accuracy, ensuring that firmware upgrades do not affect the core metering functions of the device—a domain-specific feature lacking in existing general upgrade technologies. The SHA verification algorithm in this application plays a crucial role in fragmented transmission integrity verification. By performing step-by-step verification between supplementary transmitted data and received fragments, it ensures the accuracy of data reassembly. The collaborative application of AES and RSA encryption algorithms constructs a layered security protection system, while the dynamic key generation algorithm implements the advanced security feature of one-time pad encryption. The upgrade condition evaluation algorithm, through comprehensive analysis of multi-dimensional parameters, achieves intelligent upgrade scheduling, avoiding resource conflicts and service interruptions. The circular buffer management algorithm optimizes storage space utilization and supports efficient reassembly of out-of-order data, while the transactional operation algorithm guarantees the atomicity and consistency of the upgrade process. Attached Figure Description

[0056] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a schematic diagram of one embodiment of the remote upgrade system for electronic gas meters in this application.

[0058] Figure 2 This is a schematic diagram of one embodiment of the remote upgrade method for electronic gas meters in this application. Detailed Implementation

[0059] This application provides a remote upgrade system and method for an electronic gas meter. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0060] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1One embodiment of the remote upgrade system for electronic gas meters in this application includes:

[0061] Analysis module 101 is used to comprehensively analyze and process the gas meter's operating status parameters through the upgrade condition assessment unit to obtain the upgrade timing prediction result;

[0062] Encapsulation module 102 is used to perform double encapsulation processing on firmware differential data using device identification dynamic key based on upgrade timing prediction results to obtain tamper-proof upgrade payload;

[0063] Processing module 103 is used to perform breakpoint resume processing on the anti-tampering upgrade payload according to the ring buffer structure to obtain upgrade data blocks;

[0064] Replacement module 104 is used to perform safe replacement of the gas meter program partition through a transactional rollback mechanism based on the upgrade data block, and obtain version switching status information.

[0065] The verification module 105 is used to perform metering consistency verification on the version switching status information, obtain a successful upgrade confirmation signal, and synchronize it to the remote monitoring platform.

[0066] It is understood that the implementing entity of this application can be a remote upgrade system for electronic gas meters, or it can be a terminal or a server; the specific implementation is not limited here. This application's embodiments use a server as an example for illustration.

[0067] Specifically, the analysis module 101 collects real-time operating status parameters of the gas meter, such as battery voltage, communication signal strength, and storage space occupancy rate. A comprehensive evaluation mechanism is established through the upgrade condition evaluation unit. When the battery voltage is higher than the 3.2V threshold, the communication signal strength reaches -85dBm or higher, the storage space meets the requirement of 1.5 times the upgrade package size, and there are no metering tasks for 30 consecutive minutes, the system determines that the device meets the upgrade conditions. The system groups and classifies the devices based on their geographical location and network topology to avoid the failure problem caused by blind upgrades in existing technologies. Finally, the system outputs the upgrade timing prediction result for use by subsequent modules.

[0068] The encapsulation module 102 performs dual encryption encapsulation based on the upgrade timing prediction result. First, it compares the current firmware version with the target firmware version in binary format, extracts the differences to form firmware differential data, and then combines the device unique identifier with the version number of the firmware differential data. This is then used to generate a device identification dynamic key using the SHA-256 hash algorithm. This dynamic key is recalculated and generated for each upgrade, avoiding the security vulnerabilities of fixed keys in existing technologies. Subsequently, the firmware differential data is encrypted using the AES-256 symmetric encryption algorithm to generate a first-level encrypted data packet. The device identification dynamic key is then encrypted using the RSA-2048 asymmetric encryption algorithm to form a second-level encryption key. Finally, the first-level encrypted data packet and the second-level encryption key are combined and encapsulated to form a tamper-proof upgrade payload, achieving a dual security protection mechanism.

[0069] The processing module 103 segments the anti-tampering upgrade payload according to the maximum transmission unit of the gas meter communication interface. Each segment is set to 512 bytes and a serial number is added. A circular buffer storage structure is used to cache and manage the segmented data. The circular buffer uses read and write pointers to cyclically utilize the storage space and generate segmented storage bitmap information to record the reception status of each segment. The transmission status table and the segmented storage bitmap information are synchronized in real time to form a transmission progress tracking record. When a transmission interruption is detected, the system identifies the missing segment based on the bitmap information and initiates a retransmission request. After obtaining the supplementary transmission data, the SHA-256 check algorithm is used to verify the integrity of the supplementary data and the received segments. After ensuring that all segmented data is complete and error-free, they are merged to generate an upgrade data block.

[0070] The replacement module 104 employs a transactional rollback mechanism to perform a secure replacement process. The backup unit first performs a complete image backup of the currently running firmware, generating a backup data set of the original version stored in an independent Flash partition. The storage unit redundantly stores key gas meter configuration parameters and calibration data in two different storage areas, forming system checkpoint records. After receiving the upgrade data block, the replacement unit first stops the gas meter metering service and communication functions to release system resources. It then verifies the integrity and version compatibility of the upgrade data block. Once confirmed, it obtains an upgrade-ready flag. Subsequently, it performs segment-by-segment writing to the gas meter program partition, verifying and confirming each segment immediately after writing and recording the program update progress. After all program segments are written, the gas meter system is restarted to activate the new version program. The verification unit analyzes hardware compatibility and dependencies to ensure the new firmware matches the hardware platform. The execution unit confirms the program switching operation based on the verification results and outputs version switching status information.

[0071] The verification module 105 performs metering consistency verification on the version switch status information. It scans key components such as the CPU, memory, sensors, and communication modules using a hardware self-test program, generating a functional integrity test report. Then, it starts the built-in standard flow simulator, performing simulated metering operations at preset flow test points, recording the upgraded metering accuracy data, and comparing this data with the standard metering parameters at the time of the device's manufacture. If the deviation is within the allowable range, the metering consistency verification is confirmed to be successful. The system encapsulates and packages the detailed upgrade status record, including version information, upgrade time, and verification results, into a successful upgrade confirmation signal. This signal is then transmitted to the remote monitoring platform via an incremental data synchronization mechanism, completing the entire upgrade process.

[0072] In one specific embodiment, the analysis module 101 is used for:

[0073] Real-time data acquisition and processing of gas meter battery voltage, communication signal strength, and storage space occupancy rate yields basic equipment status data.

[0074] Based on the basic status data of the equipment, the current metering task load is monitored and analyzed to obtain the equipment idle status determination result.

[0075] The device idle status determination result is compared and filtered with the preset upgrade condition threshold to obtain the upgrade qualification certification mark;

[0076] Based on the upgrade qualification certification identifier, the geographical location and network topology of the devices are grouped and classified to obtain the upgrade batch division scheme;

[0077] Based on the upgrade batch division scheme, time window allocation is performed to obtain the upgrade timing prediction result.

[0078] Specifically, the analysis module 101 collects and processes the gas meter battery voltage, communication signal strength, and storage space occupancy rate in real time. The battery voltage is sampled every ten minutes by the built-in ADC analog-to-digital converter, converting the analog voltage signal into a digital quantity and storing it in the status register. The communication signal strength is obtained by the RSSI received signal strength indicator of the radio frequency front end, which converts the received radio frequency power into the corresponding dBm value. The storage space occupancy rate is obtained by scanning the usage of each partition of the Flash memory through the file system manager, calculating the ratio of used space to total space and converting it into a percentage value. The three types of data are summarized to form the basic status data structure of the device.

[0079] The system monitors and analyzes the current metering task load based on the equipment's basic status data. The metering task load includes the sampling frequency of the flow sensor, the number of data storage operations, and the refresh status of the display screen. When the flow sensor has no pulse signal input for 30 consecutive minutes, the data storage queue is empty, and the display screen is in standby mode, the system determines that there is no metering task to be executed. Combining the voltage value, signal strength value, and storage occupancy rate in the equipment's basic status data, the system generates an equipment idle status determination result through logical judgment and calculation. This result includes a Boolean value indicating whether the equipment is currently in an idle state and the specific values ​​of various indicators.

[0080] The device idle state determination result is compared and filtered with preset upgrade condition thresholds. The preset upgrade condition thresholds include battery voltage not lower than 3.2V, communication signal strength not lower than -85dBm, storage space occupancy rate not exceeding 70%, and the device must be in an idle state. The comparison and filtering adopts a step-by-step inspection method. The voltage value in the device's basic status data is compared with the 3.2V threshold, the signal strength value is compared with the -85dBm threshold, the storage occupancy rate is compared with the 70% threshold, and the idle state Boolean value is logically compared with the true value. When all four conditions are met, an upgrade qualification certification mark is generated as true; otherwise, an upgrade qualification certification mark is generated as false, and the specific unmet item is recorded.

[0081] Based on the upgrade qualification certification identifier, the devices' geographical location and network topology are grouped and categorized. The geographical location information is obtained through the area code preset during device installation. The network topology includes the communication gateway, relay nodes, and communication paths with adjacent devices to which the device belongs. The grouping and categorization algorithm first divides devices with upgrade qualification certification identifiers into different area groups according to their geographical location. Then, within each area group, it is further subdivided according to the network topology to ensure that devices on the same network path do not perform upgrade operations simultaneously to avoid network congestion. The number of devices in each group is controlled within 50 to ensure the processing capacity of the upgrade server. The grouping and categorization results form the upgrade batch division scheme data structure.

[0082] The upgrade batch segmentation scheme employs a time window allocation method, utilizing a staggered scheduling strategy. Each upgrade batch is allocated a 2-hour time window, with a 30-minute interval between batches to avoid network resource conflicts. The time window allocation algorithm schedules upgrades based on the off-peak gas consumption period in the device's time zone, typically selecting 2:00 AM to 6:00 AM as the primary upgrade period. It also considers historical fault records and maintenance priorities for time series sorting, generating upgrade timing prediction results that include the specific start and end times for each device. For example, in a residential community with 200 gas meters requiring upgrades, 120 of which meet the upgrade criteria, they are divided into four building groups with 30 devices per group. The first group is scheduled for upgrades from 2:00 AM to 4:00 AM, and the second group from 2:30 AM to 4:30 AM. This staggered scheduling ensures sufficient network bandwidth while avoiding the risk of large-scale simultaneous upgrade failures.

[0083] In one specific embodiment, the encapsulation module 102 is used for:

[0084] Based on the upgrade timing prediction results, the current firmware version and the target firmware version are compared to obtain firmware difference data.

[0085] The device's unique identifier and the firmware differential data version number are hashed together to obtain the device identification dynamic key.

[0086] Based on the device identifier dynamic key, the firmware differential data is encrypted using the AES symmetric encryption algorithm to obtain a first-level encrypted data packet;

[0087] The device identifier dynamic key is encrypted using the RSA asymmetric encryption algorithm to obtain the secondary encryption key.

[0088] The first-level encrypted data packet is combined and encapsulated with the second-level encryption key to obtain a tamper-proof and upgrade-proof payload.

[0089] Specifically, the encapsulation module 102 performs a difference comparison between the current firmware version and the target firmware version based on the upgrade timing prediction result. The difference comparison adopts a binary file comparison algorithm, which divides the current firmware version file into data blocks of fixed size, each data block being 1024 bytes in size. The target firmware version file is also divided according to the same rule. By comparing the data content of the two version files block by block, when the data block content is completely identical, the block is skipped. When the data block content differs, the data block of the target version is marked as content that needs to be updated. All data blocks that need to be updated are reorganized according to the offset address in the original file to form a firmware differential data structure containing the offset address, data length, and specific data content. This differential data only contains the changed parts between versions and is not the complete firmware file.

[0090] The device's unique identifier and the firmware differential data version number are hashed together. The device's unique identifier is a 12-bit string assigned by the manufacturer, containing the device model prefix, production batch number, and device serial number. The firmware differential data version number is the version identifier string of the target firmware. The hash operation first merges the device's unique identifier and version number into a single input string through string concatenation. Then, the SHA-256 hash algorithm is used to calculate the digest of this input string. The SHA-256 algorithm converts input data of arbitrary length into a fixed-length 256-bit hash value. This hash value is output as 32 bytes of binary data and serves as the dynamic key for device identification in subsequent encryption operations. Each upgrade generates a completely different dynamic key due to the different version number.

[0091] The firmware differential data is encrypted using the AES symmetric encryption algorithm based on the device identifier dynamic key. The AES symmetric encryption algorithm uses a 256-bit key length and CBC cipher block chaining mode. The 32-byte device identifier dynamic key is directly used as the AES encryption key. The firmware differential data is grouped into 16-byte blocks. When the last data block is less than 16 bytes, it is padded using PKCS7. The CBC mode requires a 16-byte initialization vector, which is generated by a pseudo-random number generator and appended to the beginning of the encrypted data. The AES encryption algorithm performs transformation operations such as substitution, permutation, and key addition on each 16-byte data block to generate a corresponding 16-byte ciphertext block. All ciphertext blocks are concatenated in their original order to form a first-level encrypted data packet.

[0092] The device identification dynamic key is encrypted using the RSA asymmetric encryption algorithm. The RSA asymmetric encryption algorithm uses a 2048-bit key length and includes two keys: a public key and a private key. The public key is used for encryption, and the private key is used for decryption. The 32-byte device identification dynamic key is used as the plaintext input to the RSA encryption algorithm. Due to the input data length limitation of the RSA algorithm, the OAEP optimal asymmetric encryption padding method is used to extend the 32-byte plaintext to meet the data length requirement of the 2048-bit RSA algorithm. The RSA encryption operation is based on large integer exponentiation. The padded plaintext data is converted into a large integer, and the public key exponentiation is used to perform a modular exponentiation on this large integer. The result is converted into 256-byte ciphertext data to form the secondary encryption key.

[0093] The first-level encrypted data packet and the second-level encryption key are combined and encapsulated using a structured data format. The encapsulated data packet consists of four parts: a data header, the first-level encrypted data packet, the second-level encryption key, and a checksum. The data header occupies 16 bytes and contains information such as the encapsulation format version number, encryption algorithm identifier, total data packet length, and timestamp. The first-level encrypted data packet is directly appended to the data header while maintaining the original encryption format. The 256-byte data of the second-level encryption key is appended to the first-level encrypted data packet. The checksum is calculated using the CRC32 cyclic redundancy check algorithm to verify the values ​​of the aforementioned three parts of the data. The 4-byte CRC32 checksum is appended to the end of the data packet, ultimately forming a tamper-proof and upgrade-resistant payload containing complete encryption information and integrity verification. For example, a gas meter device is identified as GM2024A001. The current firmware version is V2.1, and the target version is V2.3. The difference comparison shows that there are 85 data blocks totaling 42KB that need to be updated. After the device identifier GM2024A001 is connected with the version number V2.3, a 32-byte dynamic key is generated by SHA-256 hash operation. This key is used to encrypt the 42KB differential data with AES-256 to generate a first-level encrypted packet. At the same time, the dynamic key is used to encrypt with RSA-2048 to generate a 256-byte second-level key. Finally, it is encapsulated into a complete upgrade payload containing a data header, encrypted differential data, encryption key and checksum.

[0094] In one specific embodiment, the processing module 103 is configured to:

[0095] The tamper-proof upgrade payload is segmented and cut according to the maximum number of bytes transmitted by the gas meter communication interface to obtain upgrade segments with serial numbers;

[0096] The upgrade fragments with sequence numbers are cached and managed based on a circular buffer storage structure to obtain fragment storage bitmap information;

[0097] The fragmented storage bitmap information is synchronized with the transmission status table in real time to obtain the transmission progress tracking record;

[0098] Based on the transmission progress tracking records, retransmission requests are processed for missing fragments in interrupted transmissions to obtain supplementary transmission data.

[0099] The SHA checksum algorithm is used to perform integrity verification on the supplementary transmitted data and the received fragments to obtain the upgraded data block.

[0100] Specifically, the processing module 103 performs fragmentation processing on the anti-tampering upgrade payload according to the maximum number of bytes transmitted by the gas meter communication interface. The maximum transmission unit (MTU) value of the communication interface is obtained through the network layer protocol stack. The common MTU value of the NB-IoT communication interface is 512 bytes, and the MTU value of the LoRa communication interface is 255 bytes. The fragmentation algorithm divides the anti-tampering upgrade payload into equal-length segments according to the net payload size after subtracting the protocol header overhead from the MTU value. Each segment contains two parts: a segment header and segment data. The segment header occupies 8 bytes and contains the segment sequence number, the total number of segments, the current segment length, and the segment check value. The segment sequence number starts from 0 and increments to ensure that the receiving end reassembles the segments in order. The total number of segments represents the number of segments into which the complete upgrade payload is divided. The current segment length records the actual number of data bytes in the segment. The segment check value is calculated by the CRC16 algorithm on the segment data. All segments form an upgrade segment array with serial numbers in sequence.

[0101] The upgrade fragments with serial numbers are cached and managed using a circular buffer storage structure. The circular buffer is a fixed-size circular queue data structure that manages data storage and reading operations through read and write pointers. When the write pointer catches up with the read pointer, it means the buffer is full; when the read pointer catches up with the write pointer, it means the buffer is empty. A fixed-size Flash storage area is allocated inside the gas meter as a circular buffer. The buffer size is set to 1.5 times the upgrade load size to ensure sufficient space to store out-of-order fragments. When each fragment arrives, its storage location in the buffer is calculated based on its serial number. The storage location is calculated by multiplying the serial number by the fragment size and adding the buffer base address. The fragment storage bitmap information adopts a bit array structure. Each bit corresponds to the reception status of a fragment. A bit value of 1 indicates that the corresponding fragment has been received, and a bit value of 0 indicates that the corresponding fragment has not been received. The size of the bit array is equal to the total number of fragments divided by 8 and rounded up.

[0102] The fragment storage bitmap information and the transmission status table are synchronized in real time. The transmission status table records detailed transmission information for each fragment, including fragment sequence number, sending time, receiving time, retransmission count, and status flag. The status flag includes five states: not sent, sent, received, retransmitting, and transmission failed. Real-time synchronization is executed every 100 milliseconds via a timer interrupt. The synchronization algorithm traverses each bit of the fragment storage bitmap information. When a bit changes from 0 to 1, it indicates that the corresponding fragment has just been received. The receiving time and status flag of that fragment in the transmission status table are updated. When a fragment is detected to have been sent but not received for more than 5 seconds, the status flag is updated to retransmitting. The synchronization process also calculates the overall transmission progress percentage by dividing the number of received fragments by the total number of fragments and multiplying by 100. This generates a transmission progress tracking record containing the status of each fragment, the overall progress, and transmission statistics.

[0103] Based on the transmission progress tracking record, retransmission requests are processed for missing fragments in interrupted transmissions. The retransmission request processing employs a selective retransmission protocol. Fragments in the retransmission status table (RSD) are identified as either retransmitting or have failed. These fragment sequence numbers are organized into a retransmission request list. The retransmission request message includes a message header, the number of missing fragments, and an array of missing fragment sequence numbers. The message header occupies 4 bytes and includes the message type, request identifier, and checksum. Upon receiving a retransmission request, the sending end retransmits the corresponding fragment data according to the sequence number array. Retransmitted fragments are marked with a retransmission flag to indicate that they are retransmitted data. Upon receiving retransmitted fragments, the receiving end processes them according to the same buffer management process. The retransmission request processing also includes timeout and retry mechanisms. If a fragment fails to retransmit successfully more than three times, it is marked as a transmission failure, and the upper-layer module is notified. Successfully received retransmitted fragments update the RSD and fragment storage bitmap information, forming supplementary transmission data.

[0104] The supplementary transmitted data and received fragments are verified for integrity using the SHA checksum algorithm. Integrity verification employs two levels: fragment-level verification and overall verification. Fragment-level verification uses the CRC16 algorithm to verify the integrity of each fragment's data. The CRC16 value of the received fragment data is calculated and compared with the checksum in the fragment header. If they do not match, the fragment verification fails and a retransmission is requested. Overall verification uses the SHA-256 algorithm to verify the integrity of the reassembled upgrade payload. The verification process first concatenates and reassembles all received fragments according to their sequence numbers, removes the fragment header information to restore the original tamper-proof upgrade payload format, and then calculates the SHA-256 hash value for the reassembled data. The calculated result is compared with the original hash value provided by the sender. If the hash values ​​match, the data integrity verification is confirmed to be successful, and an upgrade data block is generated for subsequent modules. For example, an upgrade payload of 50KB needs to be transmitted through an NB-IoT interface with a 512-byte MTU. After deducting the 8-byte fragment header, each fragment has a net payload of 504 bytes, and the data is divided into 100 fragments for transmission. Fragments 15, 32, and 67 are lost during transmission. After detecting the missing fragments through the fragment storage bitmap, a retransmission request is sent. After successfully receiving the replacement fragments, all 100 fragments are checked for CRC16 and SHA-256. After verification, they are reassembled into a 50KB upgrade data block.

[0105] In one specific embodiment, the replacement module 104 includes:

[0106] The backup unit is used to perform a complete image backup of the currently running firmware based on the upgrade data block to obtain the original version backup data.

[0107] The storage unit is used to redundantly store key configuration parameters and calibration data of the gas meter based on the original version backup data, and obtain system checkpoint records.

[0108] The replacement unit is used to input the upgrade data block into the gas meter program partition for atomic replacement processing to obtain the new version program status;

[0109] The verification unit is used to perform verification and analysis of hardware compatibility and dependencies based on the new version of the program, and to obtain the upgrade security assessment results.

[0110] The execution unit is used to confirm and execute the program switching operation based on the upgrade security assessment results, and obtain version switching status information.

[0111] Specifically, the replacement module 104 achieves secure firmware replacement through the collaborative work of five sub-units, solving the problems of unrecoverable upgrade failures and data loss in existing technologies. The backup unit performs a complete mirror backup of the currently running firmware based on the upgrade data block. The mirror backup adopts a sector-by-sector copying method. First, it scans the partition table of the gas meter's Flash memory to obtain the starting address and size of the storage area where the currently running firmware is located. The firmware storage area is usually divided into multiple 4KB sectors. The backup process reads the current firmware data sector by sector. Each read operation starts from the starting address of the source sector and reads continuously in blocks of 512 bytes. The read data is immediately written to the corresponding position in the backup storage area. The backup storage area is located in an independent Flash partition to avoid conflicts with the running firmware. After the write operation is completed, the written data is read back to verify the accuracy of the backup data. When an inconsistency between read and write is detected, the backup operation of that sector is re-executed. After all sectors are backed up, the MD5 digest value of the backup data is calculated and stored in the metadata segment of the backup area, forming the original version backup data containing complete firmware code, configuration information, and verification data.

[0112] The storage unit performs redundant storage processing on the key configuration parameters and calibration data of the gas meter based on the original version backup data. The key configuration parameters include information such as device identification, network configuration, metering parameters, security keys, and user settings. The calibration data includes data such as flow sensor calibration coefficients, temperature compensation parameters, pressure correction coefficients, and metering accuracy benchmark values. The redundant storage adopts a three-copy storage strategy, storing the key data in three different Flash partitions: the main storage area, the backup storage area, and the emergency storage area. Each storage area uses a different data organization format to enhance fault tolerance. The main storage area uses a structured data format to store data according to parameter type, the backup storage area uses a compressed format to reduce storage space occupation, and the emergency storage area uses a simplified format to store only the most critical recovery information. When the storage operation is executed, the configuration parameters and calibration data are first extracted from the original version backup data and serialized according to a predefined data structure. The serialized data is written to the three storage areas respectively. After each write, data integrity is immediately checked to generate a system checkpoint record containing storage location, data length, checksum, and timestamp.

[0113] The replacement unit inputs the upgrade data block into the gas meter program partition for atomic replacement processing. Atomic replacement ensures that the firmware update operation either succeeds completely or fails completely, without any intermediate state of partial update. The replacement process first stops all business functions of the gas meter, including metering services, communication modules, and display modules, to release system resources. Then, it decrypts and decompresses the upgrade data block to restore the complete target firmware data. The firmware data is loaded into a temporary buffer according to a predefined memory mapping layout for integrity and format verification. After the verification passes, the replacement operation begins. The replacement operation adopts a shadow update mechanism. First, the target firmware is written to the shadow partition without directly overwriting the current running partition. After the shadow partition is written, the partition pointer of the bootloader is modified to set the shadow partition as the new running partition. The partition pointer modification adopts an atomic write operation to ensure the indivisibility of the operation. Each step of the replacement operation has a corresponding status flag recorded in non-volatile memory. If any step fails, a rollback operation is performed according to the status flag to restore the state before replacement. After successfully completing all replacement steps, a new version program status flag is generated.

[0114] The verification unit performs hardware compatibility and dependency verification based on the new firmware's program status. Hardware compatibility verification checks whether the new firmware's hardware resource requirements match the current hardware platform. Verification items include hardware characteristics such as processor architecture, memory size, storage capacity, peripheral interfaces, and sensor types. The verification process obtains the actual hardware configuration information by reading the hardware identifier register and compares it item by item with the hardware requirement description of the new firmware. Dependency verification checks whether the system libraries, drivers, and external modules required by the new firmware are complete and available. The verification algorithm scans the import table and symbol table of the new firmware and performs matching checks with the library functions and interfaces provided by the system. When missing dependencies are found, the specific missing information and impact assessment are recorded. Compatibility and dependency verification also includes version compatibility checks to ensure compatibility between the new firmware version and the hardware version, bootloader version, and configuration data version. The verification results are summarized to generate an upgrade security assessment result that includes compatibility status, dependency status, risk assessment, and recommended actions.

[0115] The execution unit confirms and executes the program switching operation based on the upgrade security assessment results. The program switching operation includes three stages: boot switching, configuration migration, and service restart. When the upgrade security assessment results show that all verification items have passed, the execution unit starts the switching process. In the boot switching stage, the system boot parameters are modified to set the new firmware as the default boot firmware. The boot parameters are stored in a dedicated boot configuration area. The modification operation adopts a three-step process of write-verify-confirm to ensure that the parameters are updated correctly. In the configuration migration stage, the user configuration and calibration data of the original version are adapted to the new firmware format. The migration process performs data conversion according to the configuration mapping relationship between versions. For incompatible configuration items, default values ​​are used to replace them and change logs are recorded. In the service restart stage, the various functional modules of the gas meter are restarted in a predetermined order. The startup order is hardware initialization, system services, communication modules, metering services, and user interface. After each module starts, a functional self-test is performed to confirm that it is working normally. When all stages are successfully completed, version switching status information is generated to indicate that the firmware replacement operation is completely completed.

[0116] In one specific embodiment, the replacement unit is used for:

[0117] Based on the upgrade data block, the gas meter metering service and communication function are stopped, and the system resource release status is obtained;

[0118] The integrity and version compatibility of the upgrade data block are verified and checked based on the system resource release status to obtain the upgrade ready flag.

[0119] The upgrade readiness flag is used as a trigger condition to write the gas meter program partition segment by segment, thus obtaining the program update progress record.

[0120] Each written program segment is verified and confirmed based on the program update progress record to obtain segment verification status information.

[0121] The gas meter system is restarted and activated based on the segmented verification status information to obtain the new version program status.

[0122] Specifically, the replacement unit achieves secure atomic firmware replacement, solving the problem of device startup failure caused by upgrade interruptions in existing technologies. Based on the upgrade data block, the gas meter metering service and communication functions are stopped. The stopping operation employs an orderly shutdown strategy to avoid data loss and state inconsistencies. First, a stop signal is sent to the metering service. Upon receiving the signal, the metering service stops data acquisition from the flow sensor, writes unprocessed metering data in the cache to the memory, and updates the cumulative gas consumption record. After the metering service stops, it releases the occupied timer and interrupt resources. The communication function stops by shutting down the RF transceiver, releasing the network connection, and clearing the transmit and receive buffers. Before stopping, the communication module sends all pending data packets and sends a device offline notification to the server. The display module stops by turning off the LCD backlight, stopping the interface refresh task, and saving the current display state. After all functional modules stop, the system enters a minimum operating state, retaining only core system services and upgrade management functions, generating a system resource release status that includes the stopping status of each module, resource release status, and system load information.

[0123] The integrity and version compatibility of the upgrade data block are verified based on the system resource release status. Integrity verification first calculates the SHA-256 hash value of the upgrade data block and compares it with the expected hash value to confirm that it has not been tampered with during data transmission. Then, CRC32 cyclic redundancy check is performed on the upgrade data block to detect data storage errors. After successful verification, the file header of the upgrade data block is parsed to obtain metadata such as firmware version number, hardware adaptation information, dependent library version, and installation requirements. Version compatibility check matches the hardware model in the metadata with the current device hardware identifier, which is obtained by reading the chip UID and model register. Dependency library version check confirms that the bootloader version, system library version, and peripheral driver version required by the new firmware match the current system. Memory requirement verification checks whether the code segment size, data segment size, and stack requirements of the new firmware exceed hardware limits. After all verification items pass, the upgrade ready flag is set to true. If any verification fails, the flag is set to false and the specific reason for the failure is recorded.

[0124] The upgrade readiness flag is used as a trigger condition to perform segmented writing to the gas meter program partition. Segmented writing adopts a block programming method to reduce the impact of a single write failure. The program partition is divided into 4KB sectors, with each sector as an independent write unit. The write process first erases the target sector to clear the original data. The erase operation is performed by sending a sector erase command to the Flash controller and waiting for the erase completion flag. Then, the corresponding 4KB data in the upgrade data block is written to the erased sector. The write operation is performed in pages of 256 bytes. After each page is written, a readback verification is performed immediately to ensure that the written data is correct. During the write process, the program update progress record is maintained. The record structure includes the total number of sectors, the number of sectors written, the current sector number being written, the write status, and error information. The progress percentage is calculated by dividing the number of sectors written by the total number of sectors. The write status includes five states: preparing, writing, verifying, completed, and failed. If any sector write fails, the subsequent write operation is stopped immediately and the location of the erroneous sector is recorded.

[0125] Each written program segment is verified and confirmed according to the program update progress record. The verification and confirmation adopts a multi-layer verification mechanism to ensure the accuracy of the written data. The first layer of verification is sector-level CRC check, which calculates the CRC32 check value of each written 4KB sector and compares it with the expected value. The second layer of verification is code segment integrity check, which calculates the SHA-256 digest after concatenating the data of all code sectors and compares it with the original firmware digest. The third layer of verification is symbol table verification, which checks whether the function entry address, variable address and constant address of the new firmware are correctly aligned. The verification process also includes boot vector table verification to confirm that the interrupt vector, reset vector and exception handling vector point to valid code addresses. The results of each verification step are recorded in the segment verification status information. The status information includes the sector verification result array, code integrity status, symbol table verification status and boot vector verification status. When a verification failure is detected, the failure type and failure location are recorded for fault analysis.

[0126] The gas meter system is restarted and activated based on segmented verification status information. The restart and activation process includes two stages: software restart and hardware initialization. The software restart first saves the current system status information to non-volatile memory, including upgrade status, timestamp, and restart reason. Then, it sends a software reset command to the system reset controller to trigger the processor restart. The hardware initialization stage starts from the reset vector of the new firmware. The bootloader first performs hardware self-tests, including memory test, clock configuration, and peripheral initialization. After the self-tests pass, it loads the main program of the new firmware and initializes the runtime environment. After the new firmware starts, it performs version identification and functional self-tests. Version identification confirms the currently running firmware version by reading the version information in the firmware header. Functional self-tests include metering module test, communication module test, and display module test. After all self-test items pass, the new version program status flag is set to indicate that the firmware upgrade is successful. For example, when upgrading a gas meter with a new 128KB firmware, the replacement unit first stops metering and communication services to release system resources. After verifying the integrity and compatibility of the upgrade data, it begins writing the firmware segment by segment, dividing the 128KB firmware into 32 4KB sectors and writing them sequentially to the Flash memory. After each sector is written, a CRC check is immediately performed to confirm the data is correct. After all sectors are written, code integrity and symbol table verification are performed. After successful verification, the system is restarted. The new firmware starts up and completes hardware initialization and functional self-test, then sets the new version program status to indicate that the upgrade is successful.

[0127] In one specific embodiment, the verification module 105 is used for:

[0128] Based on the version switching status information, a self-test scan is performed on the gas meter's hardware sensors and communication links to obtain a functional integrity test report.

[0129] Based on the functional integrity test report, simulated metering was performed on the built-in standard flow test points to obtain the upgraded metering accuracy data.

[0130] The upgraded metrological accuracy data is compared with the factory standard metrological parameters to obtain the metrological consistency verification results.

[0131] Based on the metrological consistency verification results, the detailed upgrade status records are packaged and processed to obtain an upgrade success confirmation signal.

[0132] Based on the successful upgrade confirmation signal, incremental data synchronization processing is performed on the equipment operation status information to obtain a synchronization completion identifier from the remote monitoring platform.

[0133] Specifically, the verification module 105 performs a self-test scan of the gas meter's hardware sensors and communication links based on the version switching status information. The self-test scan uses a module-by-module testing method to ensure that all hardware components are working properly. The hardware sensor self-test includes the flow sensor, temperature sensor, pressure sensor, and battery voltage detection module. The flow sensor self-test sends a test pulse signal and detects the time and amplitude parameters of the feedback signal. Under normal circumstances, the feedback signal should arrive within the expected time window and the signal amplitude should be within the specified range. The temperature sensor self-test reads the current ambient temperature value and compares it with a reasonable temperature range. The pressure sensor self-test measures the current pipeline pressure and verifies the stability of the value. The communication link self-test includes RF module power output testing, antenna VSWR detection, and network connection status verification. The RF power test measures whether the transmission power meets the design specifications through a built-in power detector. The antenna detection calculates the VSWR through reflected power measurement to confirm that the antenna matching is normal. The network connection test sends test data packets to the base station and waits for a response to confirm that the communication link is unobstructed. The test results of all self-test items are summarized to form a functional integrity test report, which includes the test status, test values, and abnormal information of each hardware module.

[0134] Based on the functional integrity test report, simulated metering is performed on the built-in standard flow test points. The simulated metering uses software simulation to generate standard flow signals to verify the accuracy of the metering algorithm. The built-in standard flow test points include four standard test conditions: zero flow point, small flow point, common flow point, and maximum flow point. The zero flow test point simulates a completely closed state to verify the zero-point stability of the metering system. The small flow test point simulates a minor leakage state to verify the system's sensitivity to small flow. The common flow test point simulates normal gas usage to verify daily metering accuracy. The maximum flow test point simulates peak gas usage to verify the system's linearity. The simulated metering process generates a pulse sequence corresponding to the flow rate through a digital signal generator. The pulse frequency is proportional to the flow rate value. The generated pulse signal is input to the metering algorithm module for flow calculation. The metering algorithm calculates the instantaneous flow rate and cumulative flow rate based on the pulse frequency, temperature compensation, and pressure correction. Each test point is tested ten times, and the average value is taken as the metering result for that point. The metering results of the four test points are summarized to form the upgraded metering accuracy data. The data structure includes the test point flow rate value, calculated flow rate value, relative error, and test timestamp.

[0135] The upgraded metrological accuracy data is compared with the factory standard metrological parameters. The factory standard metrological parameters are stored in the calibration data area of ​​the equipment, including the standard flow value and allowable error range for each test point. The deviation comparison algorithm compares the upgraded test results with the standard parameters one by one, and calculates the relative error percentage by subtracting the standard value from the measured value, dividing by the standard value, and then multiplying by 100. The allowable error range for zero flow point is ±0.1%, for small flow point it is ±2%, for commonly used flow point it is ±1%, and for maximum flow point it is ±1.5%. The comparison process also includes linearity checks. The linear correlation coefficient of the metrological characteristic curve is calculated by the error distribution of the four test points. A linear correlation coefficient greater than 0.999 indicates good metrological characteristics. The effectiveness of temperature compensation and pressure correction is verified by repeated testing under different temperature and pressure conditions. When the relative error of all test points is within the allowable range and the linear correlation coefficient meets the requirements, a metrological consistency verification result is generated as a pass. When any test point exceeds the error range, a verification result is generated as a failure and the specific out-of-tolerance information is recorded.

[0136] Based on the metrological consistency verification results, the detailed upgrade status record is encapsulated and packaged. The detailed upgrade status record contains all key information and verification results of the upgrade process. The record content includes upgrade start time, upgrade end time, original firmware version, target firmware version, upgrade data packet size, transmission time, verification test results, and abnormal event logs. The encapsulation and packaging adopts a structured data format. The data packet header includes the total record length, data format version, device identifier, and timestamp. The data body organizes the detailed information of each stage in chronological order. The verification test results are encapsulated separately and include hardware self-test status, metrological accuracy test data, error analysis results, and consistency verification conclusions. The abnormal event log records warnings and error messages that occur during the upgrade process. After encapsulation, the MD5 digest of the entire data packet is calculated as the data integrity check code. When the metrological consistency verification is passed and there are no serious abnormal events, an upgrade success confirmation signal is generated. The signal content includes the upgrade status identifier, verification result summary, and data packet check code.

[0137] Based on the successful upgrade confirmation signal, incremental data synchronization is performed on the device's operating status information. Incremental data synchronization only transmits status change information relative to the last synchronization, reducing network traffic and power consumption. The synchronized data includes the device's current firmware version, running time, cumulative gas consumption, battery level, signal strength, and recent alarm records. The incremental synchronization algorithm compares the differences between the current state and the last synchronized state, and only packages and sends the changed data items. Data compression uses differential encoding to transmit numerical changes rather than absolute values. Synchronized data is classified according to priority. Critical status changes, such as firmware version updates, are sent immediately, while general status changes, such as battery depletion, are sent according to a preset cycle. Data transmission uses a reliable transmission protocol to ensure that important information is not lost. After sending, the system waits for server confirmation. If no response is received within the timeout period, the system automatically retransmits up to three times. After successfully receiving the synchronized data, the server returns a confirmation message, which includes a reception timestamp and data verification results. After receiving the confirmation message, the gas meter updates its local synchronization status flag and generates a synchronization completion identifier for the remote monitoring platform.

[0138] The above describes the remote upgrade system for electronic gas meters in the embodiments of this application. The following describes the remote upgrade method for electronic gas meters in the embodiments of this application. Please refer to [link / reference]. Figure 2 One embodiment of the remote upgrade method for electronic gas meters in this application includes:

[0139] The gas meter's operating status parameters are comprehensively analyzed and processed by the upgrade condition assessment unit to obtain the upgrade timing prediction result;

[0140] Based on the upgrade timing prediction result, the firmware differential data is double-encapsulated using the device identification dynamic key to obtain the tamper-proof upgrade payload.

[0141] The tamper-proof upgrade payload is processed by resuming interrupted transmission according to a circular buffer structure to obtain the upgrade data block;

[0142] Based on the upgrade data block, the gas meter program partition is safely replaced using a transactional rollback mechanism to obtain version switching status information;

[0143] The version switching status information is subjected to metering consistency verification processing to obtain a successful upgrade confirmation signal and synchronize it to the remote monitoring platform.

[0144] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A remote upgrade system for electronic gas meters, characterized in that the system... The method comprises the following steps: An analysis module is used for comprehensive analysis and processing of the gas meter operating state parameters by the upgrade condition evaluation unit to obtain an upgrade opportunity prediction result, which is used for: real-time collection and processing of the battery voltage, communication signal strength and storage space occupancy rate of the gas meter to obtain device basic state data; monitoring, analyzing and processing of the current metering task load based on the device basic state data to obtain a device idle state determination result; The device idle state determination result is compared and screened with a preset upgrade condition threshold to obtain an upgrade qualification certification mark; The device geographical location and network topology relationship are grouped and classified based on the upgrade qualification certification mark to obtain an upgrade batch division scheme; A time window allocation process is performed based on the upgrade batch division scheme to obtain an upgrade opportunity prediction result; An encapsulation module is used for double encapsulation of the firmware difference data based on the upgrade opportunity prediction result through a device identifier dynamic key to obtain a tamper-proof upgrade load; A processing module is used for breakpoint continuation processing of the tamper-proof upgrade load according to the ring buffer structure to obtain an upgrade data block; A replacement module is used for safe replacement processing of the gas meter program partition according to the upgrade data block through a transaction rollback mechanism to obtain version switching state information; A verification module is used for meter consistency verification processing of the version switching state information to obtain an upgrade success confirmation signal and synchronizes to a remote monitoring platform, which is used for: self-checking and scanning processing of the gas meter hardware sensor and communication link based on the version switching state information to obtain a functional integrity detection report; analog metering processing of the built-in standard flow test point according to the functional integrity detection report to obtain post-upgrade metering accuracy data; deviation comparison processing of the post-upgrade metering accuracy data and the factory standard metering parameter to obtain a meter consistency verification result; Based on the meter consistency verification result, the upgrade state detailed record is encapsulated and packaged to obtain an upgrade success confirmation signal; and the device operating state information is incrementally synchronized according to the upgrade success confirmation signal to obtain a remote monitoring platform synchronization completion identifier.

2. The electronic gas meter remote upgrading system of claim 1, wherein, The encapsulation module is used for: Difference comparison processing of the current firmware version and the target firmware version based on the upgrade opportunity prediction result to obtain firmware difference data; Hash operation processing of the device unique identifier and the version number of the firmware difference data to obtain a device identifier dynamic key; First layer encryption processing of the firmware difference data through an AES symmetric encryption algorithm based on the device identifier dynamic key to obtain a first level encryption data packet; Second layer encryption processing of the device identifier dynamic key based on an RSA asymmetric encryption algorithm to obtain a second level encryption key; Combination and encapsulation processing of the first level encryption data packet and the second level encryption key to obtain a tamper-proof upgrade load.

3. The electronic gas meter remote upgrading system of claim 1, wherein, The processing module is used for: Fragmentation and cutting processing of the tamper-proof upgrade load according to the maximum transmission byte number of the gas meter communication interface to obtain an upgrade fragment with a serial number. The upgrade fragment with the serial number is subjected to a cache management process based on a ring buffer storage structure to obtain fragment storage bitmap information; The fragment storage bitmap information is subjected to real-time synchronization processing with a transmission state table to obtain transmission progress tracking records; Missing fragments interrupted in transmission are subjected to retransmission request processing according to the transmission progress tracking records to obtain supplementary transmission data; The supplementary transmission data is subjected to integrity verification processing with the received fragments based on a SHA check algorithm to obtain upgrade data blocks.

4. The electronic gas meter remote upgrading system of claim 1, wherein, The replacement module comprises: A backup unit configured to perform complete mirror backup processing on the current running firmware based on the upgrade data blocks to obtain original version backup data; A storage unit configured to perform redundant storage processing on the key configuration parameters and calibration data of the gas meter based on the original version backup data to obtain system checkpoint records; A replacement unit configured to input the upgrade data blocks into the gas meter program partition for atomic replacement processing to obtain a new version program state; A verification unit configured to perform verification and analysis processing on hardware compatibility and dependency based on the new version program state to obtain an upgrade security evaluation result; An execution unit configured to perform confirmed execution processing on program switching operations according to the upgrade security evaluation result to obtain version switching state information.

5. The electronic gas meter remote upgrading system of claim 4, wherein, The replacement unit is configured to: Perform stop operation processing on the gas meter metering service and communication function according to the upgrade data blocks to obtain a system resource release state; Perform verification and check processing on the integrity and version compatibility of the upgrade data blocks based on the system resource release state to obtain an upgrade ready-to-use identifier; Perform piecewise writing processing on the gas meter program partition with the upgrade ready-to-use identifier as a trigger condition to obtain program update progress records; Perform check and confirmation processing on each written program segment according to the program update progress records to obtain segment verification state information; Perform restart activation processing on the gas meter system based on the segment verification state information to obtain a new version program state.

6. A remote upgrading method of an electronic gas meter, characterized by, The electronic gas meter remote upgrade method comprises: Performing comprehensive analysis processing on the gas meter running state parameters through an upgrade condition evaluation unit to obtain an upgrade timing prediction result; Performing double encapsulation processing on the firmware differential data through a device identifier dynamic key according to the upgrade timing prediction result to obtain a tamper-resistant upgrade load; Performing breakpoint continuation processing on the tamper-resistant upgrade load according to a ring buffer structure to obtain upgrade data blocks; Performing safe replacement processing on the gas meter program partition through a transactional rollback mechanism according to the upgrade data blocks to obtain version switching state information; Performing metering consistency verification processing on the version switching state information to obtain an upgrade success confirmation signal and synchronizing the signal to a remote monitoring platform.

Images