A smart meter remote monitoring system

Abstract

The application discloses a kind of intelligent electric meter remote monitoring systems, specifically related to electric meter monitoring and data security field, including address identification module, benchmark construction module, operation monitoring module, abnormal analysis module, authority control module and data reporting module;Address identification module obtains the starting address and length of the reserved area not called by reading the executable address range of each storage page in the electric meter firmware storage medium;By real-time analysis of the block storage state of firmware reserved area, the change of check value and access behavior characteristics, the block check and difference statistics are completed on the electric meter side under the condition of edge computing, the dynamic risk score is generated and the isolation and reporting mechanism is triggered, and the metering operation characteristics collected by the intelligent sensor are combined as the associated reference of access behavior, to solve the lack of continuous security verification of the unused but executable firmware reserved area, so as to the security risk that may be attacked by the attacker step by step and bypass the existing encryption and check mechanism.

Description

Technical Field

[0001] This invention relates to the field of electricity meter monitoring and data security technology, and more specifically, to a remote monitoring system for smart meters. Background Technology

[0002] In current smart meter remote monitoring systems, manufacturers typically use methods such as firmware signing, encrypted communication, and periodic heartbeat detection to ensure data security. They also use smart sensors to collect metering signals such as voltage, current, and electricity consumption to support remote monitoring and alarm judgment. However, in actual engineering, to facilitate future upgrades or maintenance, the meter firmware reserves a special area in the storage chip. This area is currently unused, but it can still be written to and executed. Existing security detection generally does not check this area because it is considered idle. Furthermore, under edge computing conditions, the meter side mainly focuses on the established sampling and uplink links and does not additionally cover the continuous verification of this reserved area. Therefore, attackers can exploit this vulnerability by not cracking the encrypted communication, but by writing a small amount of code multiple times, each time, to slowly assemble malicious programs.

[0003] Once the malicious code is assembled, attackers can quietly modify electricity data, change alarm conditions, or even disable security mechanisms, while the platform still sees the data as normal and secure. Therefore, in the remote monitoring system of smart meters, it is necessary to solve the problem of the lack of continuous security verification in the unused but executable firmware reserved area, and block the long-term threat of hidden code injection to metering data security and communication integrity from the source. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a remote monitoring system for smart meters. By analyzing the block storage status, check value changes, and access behavior characteristics of the firmware reserved area in real time, the system completes block verification and difference statistics on the meter side under edge computing conditions, generates a dynamic risk score, and triggers isolation and reporting mechanisms. It also combines the metering operation characteristics collected by smart sensors as a correlation reference for access behavior. This addresses the security vulnerability of unused but executable firmware reserved areas lacking continuous security verification, which could allow attackers to inject malicious code step by step and bypass existing encryption and verification mechanisms.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a remote monitoring system for smart meters, comprising an address identification module, a benchmark construction module, an operation monitoring module, an anomaly analysis module, an access control module, and a data reporting module;

[0006] The address identification module reads the executable address range of each storage page in the meter firmware storage medium, obtains the starting address and length of the unused reserved area, and generates a monitoring address set by combining them in the order of storage page numbers;

[0007] The benchmark construction module reads the monitoring address set data byte by byte, divides each storage page into blocks of fixed byte length, performs cyclic redundancy check on each block to generate a check value, concatenates the blocks and check values ​​and inputs them into a hash function to generate a digest, and merges the digests to obtain the benchmark data.

[0008] The operation monitoring module reads real-time data from the monitoring address set at preset time intervals, divides the data into blocks and generates verification values ​​in the same way as the baseline data, performs byte difference counting to calculate the rate of change, records the number of accesses to each storage location in the monitoring address set during the monitoring period, and generates a feature data sequence.

[0009] The anomaly analysis module compares the block check values ​​of the feature data with the block check values ​​of the benchmark data, calculates the difference ratio, and generates a weighted risk score by combining the number of accesses, thus obtaining the risk result.

[0010] The access control module switches the execution permissions of the monitored address set to a non-executable state and freezes all remote communication sessions associated with the monitored address set when the risk results reach a preset threshold, generating isolation data.

[0011] The data reporting module structures and encrypts risk results and isolation data, and uploads them to the remote monitoring platform via a remote communication link to generate response data.

[0012] In a preferred embodiment, in the address identification module, the start address and end address of each storage page in the meter firmware storage medium are read sequentially by traversing the executable address range of each storage page to form an address record list.

[0013] By matching and comparing the call path data of each address record in the address record list, it is determined whether the address range is called by the current firmware version. The address range that does not match the call path is marked as the reserved area, and the address range that matches successfully is marked as the occupied area.

[0014] Calculate the length parameter for each reserved area address range. Sort the list of reserved area address ranges in ascending order according to their starting addresses. Traverse the sorted list. For two adjacent address ranges, check if the end address of the previous range plus one equals the start address of the next range. If they are equal, merge the two address ranges into one, with the start address of the merged range being the start address of the previous range and the end address being the end address of the next range. Recalculate the length parameter. If they are not equal, keep the two address ranges independent and do not merge them. Continue traversing subsequent address ranges.

[0015] Perform length filtering on the merged address range list, delete all address ranges with length parameters less than a preset threshold, and keep address ranges with length greater than or equal to the preset threshold to obtain an optimized address list;

[0016] The optimized address list is sorted according to the storage page number and starting address, and each address range is assigned a unique identifier to form a monitoring address set, which serves as the data input for the baseline construction module.

[0017] In a preferred embodiment, in the baseline construction module, data is read byte by byte from the monitoring address set according to the storage page number order, each storage page is divided into multiple blocks according to a fixed byte length, and the start address, end address and block number of each block are recorded at the same time as the block is divided to generate a block index table.

[0018] Traverse the block index table, perform cyclic redundancy check operation on each block in turn, generate the block check value of the block, combine the block check value with the corresponding block number and block length, and write them into the block check value set in turn.

[0019] Traverse the set of block check values. For two adjacent blocks, first connect their block check values ​​sequentially to form an associated sequence. Then perform a second cyclic redundancy check on the associated sequence to generate an associated check value. Record the associated check value and the corresponding block number together to detect data changes across blocks.

[0020] Traverse the block index table, concatenate the data, block check value, and associated check value of each block in a fixed order to form an enhanced block, and feed the enhanced block as input data into the hash function to perform hash operation and generate a digest of the enhanced block;

[0021] All summaries are read sequentially according to the block index table. The summaries are merged in order to generate the baseline data. During the merging process, adjacent summaries are compared for duplication and invalidity. If duplication or invalidity is found, the corresponding summaries are deleted, and only one valid summary is retained.

[0022] The final baseline data is transmitted to the operation monitoring module as a comparison benchmark, and the block index table, block check value set and associated check value are stored in the secure storage area for feature analysis and abnormal data backtracking during operation.

[0023] In a preferred embodiment, in the operation monitoring module, each storage page in the monitoring address set is accessed sequentially at a preset time interval, and the corresponding real-time data segment is read sequentially based on the storage page number. The real-time data segment is combined with the storage page number and the current timestamp to form record data, and the record data is written sequentially into the operation cache area.

[0024] Iterate through all the record data in the running buffer, call the block index table of the base data, perform location matching on the real-time data segment, filter out the record data that is inconsistent with the check value of the corresponding block in the base data, and divide these real-time data segments into variable blocks according to a fixed byte length, while recording the start address, end address and block number of each variable block.

[0025] For each changed block, a cyclic redundancy check operation is performed to generate a real-time block check value. The real-time block check value is then compared byte by byte with the block check value of the corresponding baseline data. The positions of the differing bytes are counted and the difference ratio is calculated to generate difference distribution data.

[0026] Traverse the differential distribution data, perform a weighted operation on the differential ratio and the number of accesses to the corresponding storage location in the monitoring address set within the current monitoring period to obtain the block change weight, and merge all block change weights in the order of storage page number and block number to form a feature data sequence, and store the feature data sequence in the secure storage area.

[0027] In a preferred embodiment, in the anomaly analysis module, by traversing each block in the feature data sequence, the corresponding baseline data block check value and real-time block check value are located, a byte-by-byte XOR operation is performed to generate a difference mask, and the number of difference bytes and the number of accesses in the current monitoring period are counted in parallel. The number of difference bytes is written into the difference count table, and the number of accesses is written into the access count table.

[0028] For each record in the difference count table, divide the number of difference bytes by the total number of bytes in the block to obtain the initial difference ratio, and retrieve the preceding and following block numbers in the block index table for that block;

[0029] If the difference ratio of the associated blocks is greater than the difference threshold, the difference ratio of the current block is increased by the preset correlation correction coefficient; if the difference ratio of the associated blocks is equal to the difference threshold, the block and the associated blocks are marked as secondary verification targets, and more than two additional sampling verifications are performed simultaneously in the next monitoring cycle; if there are no associated blocks with a difference ratio greater than or equal to the difference threshold, the difference ratio of the current block remains unchanged, and the trend parameter of the difference ratio change of the block is recorded.

[0030] The processed difference ratio is bound to the number of accesses in the access count table to form a difference ratio table. At the same time as forming the difference ratio table, the block number and associated information of all blocks that enter the secondary verification target are recorded to the verification list, and the change trend parameters are synchronously stored in the secure storage area.

[0031] In a preferred embodiment, in the anomaly analysis module, by traversing each block in the feature data sequence, the corresponding baseline data block check value and real-time block check value are located, a byte-by-byte XOR operation is performed to generate a difference mask, and the number of difference bytes and the number of accesses in the current monitoring period are counted in parallel. The number of difference bytes is written into the difference count table, and the number of accesses is written into the access count table.

[0032] For each record in the difference count table, divide the number of difference bytes by the total number of bytes in the block to obtain the initial difference ratio, and retrieve the preceding and following block numbers in the block index table for that block;

[0033] If the difference ratio of the associated blocks is greater than the difference threshold, the difference ratio of the current block is increased by the preset correlation correction coefficient; if the difference ratio of the associated blocks is equal to the difference threshold, the block and the associated blocks are marked as secondary verification targets, and more than two additional sampling verifications are performed simultaneously in the next monitoring cycle; if there are no associated blocks with a difference ratio greater than or equal to the difference threshold, the difference ratio of the current block remains unchanged, and the trend parameter of the difference ratio change of the block is recorded.

[0034] The processed difference ratio is bound to the number of accesses in the access count table to form a difference ratio table. At the same time as forming the difference ratio table, the block number and associated information of all blocks that enter the secondary verification target are recorded to the verification list, and the change trend parameters are synchronously stored in the secure storage area for subsequent steps to call.

[0035] In a preferred embodiment, the access control module receives a total risk score and a risk record table for each block corresponding to the total risk score. The risk record table for each block contains the storage page number, block number, unique identifier, and risk score for each block, and is arranged in descending order of the risk score to form an access control sequence.

[0036] Traverse the permission processing sequence. If a block is marked as high risk, call the firmware permission switching instruction to switch the execution permission of the monitoring address set where the block is located from the executable state to the non-executable state, and immediately freeze all remote communication sessions associated with the storage page where the block is located. At the same time, generate isolation data and write it to the isolation data area.

[0037] If a block is marked as requiring secondary detection, the write channel of the communication session associated with that block is first frozen, while the read channel is preserved. In subsequent monitoring cycles, bidirectional reverse data verification is performed on that block, and the percentage difference between the verified risk score and the initial risk score is calculated. If the verified risk score is equal to or higher than the risk threshold, and the verification results are consistent across two consecutive monitoring cycles, a complete isolation operation is performed. If only some blocks within a storage page have verification results higher than the risk threshold in two consecutive cycles, only the permission switch and session freeze are performed on that storage page, and the block is added to the detection queue with doubled detection rounds. If the percentage difference does not exceed the fluctuation threshold, the write channel is restored and executable permissions are maintained.

[0038] If a block is marked as low risk, no permission switch will be performed. Instead, the risk score, number of accesses, difference ratio, and fluctuation range within the verification period will be stored in the security log area, and a future risk trend index will be calculated based on historical trends. If the trend index exceeds the warning threshold, the block will be adjusted to a secondary detection state and executed according to the corresponding detection round. Otherwise, the existing permissions and sampling frequency will be maintained.

[0039] After completing the permission processing for all blocks, the isolation records, reverse verification results, trend indices, and permission change logs for this period are encrypted and encapsulated into an access control report, which is then sent to the remote monitoring platform via a remote communication link. A copy of the report is stored in a secure storage area.

[0040] In a preferred embodiment, the access control module receives a total risk score and a risk record table for each block corresponding to the total risk score. The risk record table for each block contains the storage page number, block number, unique identifier, and risk score for each block, and is arranged in descending order of the risk score to form an access control sequence.

[0041] Traverse the permission processing sequence. If a block is marked as high risk, call the firmware permission switching instruction to switch the execution permission of the monitoring address set where the block is located from the executable state to the non-executable state, and immediately freeze all remote communication sessions associated with the storage page where the block is located. At the same time, generate isolation data and write it to the isolation data area.

[0042] If a block is marked as requiring secondary detection, the write channel of the communication session associated with that block is first frozen, while the read channel is preserved. In subsequent monitoring cycles, bidirectional reverse data verification is performed on that block, and the percentage difference between the verified risk score and the initial risk score is calculated. If the verified risk score is equal to or higher than the risk threshold, and the verification results are consistent across two consecutive monitoring cycles, a complete isolation operation is performed. If only some blocks within a storage page have verification results higher than the risk threshold in two consecutive cycles, only the permission switch and session freeze are performed on that storage page, and the block is added to the detection queue with doubled detection rounds. If the percentage difference does not exceed the fluctuation threshold, the write channel is restored and executable permissions are maintained.

[0043] If a block is marked as low risk, no permission switch will be performed. Instead, the risk score, number of accesses, difference ratio, and fluctuation range within the verification period will be stored in the security log area, and a future risk trend index will be calculated based on historical trends. If the trend index exceeds the warning threshold, the block will be adjusted to a secondary detection state and executed according to the corresponding detection round. Otherwise, the existing permissions and sampling frequency will be maintained.

[0044] After completing the permission processing for all blocks, the isolation records, reverse verification results, trend indices, and permission change logs for this period are encrypted and encapsulated into an access control report, which is then sent to the remote monitoring platform via a remote communication link. A copy of the report is stored in a secure storage area.

[0045] The technical effects and advantages of this invention are as follows:

[0046] 1. This invention achieves real-time security verification of unused but executable storage areas by continuously monitoring the block storage status, check value changes, and access behavior of the firmware reserved area, fundamentally blocking the injection channels of hidden code and ensuring the security of metering data and the integrity of communication;

[0047] 2. This solution utilizes a block-based verification and comparison mechanism between baseline data and real-time monitoring data to locate the range of abnormal changes at the storage page and block level, thereby narrowing the analysis area for security detection and improving the efficiency of anomaly detection.

[0048] 3. This solution also uses a weighted scoring method based on the difference ratio and the number of accesses, combined with risk threshold judgment, to dynamically distinguish high-risk, suspicious and normal storage blocks, thereby improving the response speed of security policies under various attack modes.

[0049] 4. When the risk results reach the set threshold, this solution will switch permissions and freeze the associated sessions, and generate isolation data to achieve closed-loop control from detection to isolation, thereby reducing the scope of the attack's spread.

[0050] 5. This solution employs a structured and encrypted data reporting method to securely transmit risk results and isolation information to the remote monitoring platform, ensuring the confidentiality and tamper-proof nature of alarm information during transmission and providing a reliable data foundation for subsequent evidence collection and response. Attached Figure Description

[0051] Figure 1 This is a system module diagram of the present invention.

[0052] Figure 2 This is a flowchart of the block risk scoring generation process of the present invention.

[0053] Figure 3 This is a flowchart of the total risk score calculation and processing of the present invention.

[0054] Figure 4 This is a flowchart of the low-risk trend monitoring process of the present invention. Detailed Implementation

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

[0056] Refer to the instruction manual appendix Figure 1-4 An embodiment of the present invention provides a remote monitoring system for smart meters, comprising an address identification module, a baseline construction module, an operation monitoring module, an anomaly analysis module, an access control module, and a data reporting module.

[0057] The address identification module reads the executable address range of each storage page in the meter firmware storage medium, obtains the starting address and length of the unused reserved area, and generates a monitoring address set by combining them in the order of storage page numbers;

[0058] The benchmark construction module reads the monitoring address set data byte by byte, divides each storage page into blocks of fixed byte length, performs cyclic redundancy check on each block to generate a check value, concatenates the blocks and check values ​​and inputs them into a hash function to generate a digest, and merges the digests to obtain the benchmark data.

[0059] The operation monitoring module reads real-time data from the monitoring address set at preset time intervals, divides the data into blocks and generates verification values ​​in the same way as the baseline data, performs byte difference counting to calculate the rate of change, records the number of accesses to each storage location in the monitoring address set during the monitoring period, and generates a feature data sequence.

[0060] The anomaly analysis module compares the block check values ​​of the feature data with the block check values ​​of the benchmark data, calculates the difference ratio, and generates a weighted risk score by combining the number of accesses, thus obtaining the risk result.

[0061] The access control module switches the execution permissions of the monitored address set to a non-executable state and freezes all remote communication sessions associated with the monitored address set when the risk results reach a preset threshold, generating isolation data.

[0062] The data reporting module structures and encrypts risk results and isolation data, and uploads them to the remote monitoring platform via a remote communication link to generate parsable response data.

[0063] In the address identification module, the executable address range of each storage page in the meter firmware storage medium is traversed, and the start address and end address of each storage page are read sequentially to form an address record list;

[0064] By matching and comparing the call path data of each address record in the address record list, it is determined whether the address range is called by the current firmware version. The address range that does not match the call path is marked as the reserved area, and the address range that matches successfully is marked as the occupied area. The call path data is the execution flow information of the program code in the meter firmware, which is used to identify whether each stored address range is accessed and referenced by the instructions or functions of the current firmware version.

[0065] Calculate the length parameter for each reserved address range. The length parameter is the total number of bytes (end address minus start address plus one). Sort the reserved address range list in ascending order by start address. Traverse the sorted list. For two adjacent address ranges, check if the end address plus one of the previous range equals the start address of the next range. If they are equal, merge the two address ranges into one, with the start address of the merged range being the start address of the previous range and the end address being the end address of the next range. Recalculate the length parameter. If they are not equal, keep the two address ranges independent and do not merge them. Continue traversing subsequent address ranges.

[0066] Perform length filtering on the merged address range list, delete all address ranges with length parameters less than a preset threshold, and keep address ranges with length greater than or equal to the preset threshold to obtain an optimized address list;

[0067] The optimized address list is sorted according to the storage page number and starting address, and each address range is assigned a unique identifier to form a monitoring address set, which serves as the data input for the baseline construction module.

[0068] In the baseline construction module, data is read byte by byte from the monitoring address set according to the storage page number. Each storage page is divided into multiple blocks of fixed byte length. At the same time as the block is divided, the start address, end address and block number of each block are recorded to generate a block index table.

[0069] Traverse the block index table, perform cyclic redundancy check operation on each block in turn, generate the block check value of the block, combine the block check value with the corresponding block number and block length, and write them into the block check value set in turn.

[0070] Traverse the set of block check values. For two adjacent blocks, first connect their block check values ​​sequentially to form an associated sequence. Then perform a second cyclic redundancy check on the associated sequence to generate an associated check value. Record the associated check value and the corresponding block number together to detect data changes across blocks.

[0071] Traverse the block index table, concatenate the data, block check value, and associated check value of each block in a fixed order to form an enhanced block, and feed the enhanced block as input data into the hash function to perform hash operation and generate a digest of the enhanced block;

[0072] All summaries are read sequentially according to the block index table. The summaries are merged in order to generate the baseline data. During the merging process, adjacent summaries are compared for duplication and invalidity. If duplication or invalidity is found, the corresponding summaries are deleted, and only one valid summary is retained.

[0073] The final benchmark data is transmitted to the operation monitoring module as a comparison benchmark, and the block index table, block check value set and associated check value are stored in the secure storage area. The secure storage area is located in an independent storage area of ​​the meter firmware storage medium and is used for feature analysis and abnormal data backtracking during operation.

[0074] In the operation monitoring module, each storage page in the monitoring address set is accessed sequentially at preset time intervals. The corresponding real-time data segments are read sequentially based on the storage page number. The real-time data segments are combined with the storage page number and the current timestamp to form record data, and the record data is written to the operation cache area in sequence.

[0075] Iterate through all the record data in the running buffer, call the block index table of the base data, perform location matching on the real-time data segment, filter out the record data that is inconsistent with the check value of the corresponding block in the base data, and divide these real-time data segments into variable blocks according to a fixed byte length, while recording the start address, end address and block number of each variable block.

[0076] For each changed block, a cyclic redundancy check operation is performed to generate a real-time block check value. The real-time block check value is then compared byte by byte with the block check value of the corresponding baseline data. The positions of the differing bytes are counted and the difference ratio is calculated to generate difference distribution data.

[0077] Traverse the differential distribution data, perform a weighted operation on the differential ratio and the number of accesses to the corresponding storage location in the monitoring address set within the current monitoring period to obtain the block change weight, and merge all block change weights in the order of storage page number and block number to form a feature data sequence. Store the feature data sequence in the secure storage area for subsequent steps to call.

[0078] In the anomaly analysis module, by traversing each block in the feature data sequence, the corresponding baseline data block verification value and real-time block verification value are located, and a byte-by-byte XOR operation is performed to generate a difference mask. At the same time, the number of difference bytes and the number of accesses in the current monitoring period are counted in parallel. The number of difference bytes is written into the difference count table, and the number of accesses is written into the access count table.

[0079] For each record in the difference count table, divide the number of difference bytes by the total number of bytes in the block to obtain the initial difference ratio, and retrieve the preceding and following block numbers in the block index table for that block;

[0080] If the difference ratio of the associated blocks is greater than the difference threshold, the difference ratio of the current block is increased by the preset correlation correction coefficient; if the difference ratio of the associated blocks is equal to the difference threshold, the block and the associated blocks are marked as secondary verification targets, and more than two additional sampling verifications are performed simultaneously in the next monitoring cycle; if there are no associated blocks with a difference ratio greater than or equal to the difference threshold, the difference ratio of the current block remains unchanged, and the trend parameter of the difference ratio change of the block is recorded.

[0081] The processed difference ratio is bound to the number of accesses in the access count table to form a difference ratio table. At the same time as forming the difference ratio table, the block number and associated information of all blocks that enter the secondary verification target are recorded to the verification list, and the change trend parameters are synchronously stored in the secure storage area for subsequent steps to call.

[0082] In the anomaly analysis module, a basic score is generated by traversing the difference ratio table, multiplying the difference ratio by the number of visits, assigning a first weight based on the change status of the associated verification value of the block, assigning a second weight based on the comparison between the basic score and the difference threshold, and multiplying the two weights by the basic score to obtain the block risk score.

[0083] If the risk score of a segment falls within a 5% fluctuation range above and below the risk threshold, the segment is marked as requiring secondary detection, and its data is read at least twice in subsequent monitoring cycles for verification. If the risk score of a segment equals the risk threshold, the segment is directly included in the high-risk list, and a threshold trigger mark is added to the high-risk list to distinguish between threshold triggering and exceeding the threshold triggering during backtracking analysis. If the risk score of a segment is not within the fluctuation range and does not equal the risk threshold, the segment is marked as normal and read at the regular sampling frequency.

[0084] The total risk score is generated by accumulating the risk scores of all blocks in the order of storage page number and block number, and then compared with the risk threshold.

[0085] If the total risk score is greater than the risk threshold, the risk result is output as high, and a list of all high-risk, threshold-triggered, and sub-segments requiring secondary detection is fed back to the monitoring process to adjust the sub-sampling order for the next monitoring cycle. If the total risk score is equal to the risk threshold, a full re-inspection process is directly initiated, followed by a cross-cycle consistency verification. If the consistency verification results for two consecutive cycles reach or exceed the risk threshold, a weighted final result is generated and marked as persistently high risk. If the total risk score is less than the risk threshold, the risk result is output as low, and the difference ratio table and sub-segment risk scores are recorded in the monitoring log. The future risk trend index is calculated based on the trend parameters in the log. If the trend index is higher than the warning threshold, the sub-segment is automatically added to the secondary detection queue for the next cycle.

[0086] It should be noted that in the formula structure involved in this scheme, dimensionless terms can be used as proportional or structural adjustment factors. When combined with quantities with units, they only play a role in numerical scaling and do not introduce new physical dimensions. Therefore, they will not change or confuse the overall unit system. This combination of "dimensionless terms and terms with units" can be understood as a composite structural expression commonly used in mathematical physics modeling. It conforms to the principle of dimensional consistency and has a clear physical interpretation basis.

[0087] Secondly, in the formula structure of this scheme, if multiple variables with different physical units are involved, including but not limited to time, mass or energy variables, their joint appearance is to express the collaborative modeling relationship of multiple physical mechanisms. Each variable can form a unified structure through function mapping, ratio combination or normalization adjustment, with clear units and clear meaning. The overall expression conforms to the principle of dimensional consistency and the conventional formula of engineering modeling.

[0088] In this solution, constants, weights, adjustment factors, threshold parameters, proportional coefficients, etc., are all adjustable control parameters for different application environments. Their values ​​depend on the target equipment configuration, data input characteristics, and performance optimization goals. During the implementation phase, they are set to converge within a reasonable range through model verification, performance constraints, or engineering calibration. Although these parameters do not have a unique preset value, they have clear adjustment logic and calculation paths. They belong to the deterministic setting process in engineering implementation. The purpose of this setting is to ensure that the solution is both universally adaptable and reproducible and operable, without affecting its technical clarity and feasibility.

[0089] definition For the first Risk score for each block:

[0090]

[0091]

[0092]

[0093]

[0094]

[0095]

[0096]

[0097]

[0098] in, For the first Risk score for each block; For the first The proportion of differences in each block; This refers to the status of changes in the associated verification value; For the first The value of each block of real-time data bytes; For the first The value of the base data bytes in each block; The total number of bytes in the block; For the first The number of accesses to each block. This indicates the total number of times the segment was accessed within the monitoring period; For the first The first weight of each block Based on the change status of the associated check value of this block calculate; The preset change threshold, Used to determine whether to increase the weight; For the first The second weight of each block, Based on the proportion of difference With risk threshold The comparison results; As a preset risk threshold, Used to control the impact of high-discrepancy-ratio blocks;

[0099] For the overall risk score, This indicates the cumulative risk of all blocks within the current monitoring period; For the first Risk score for each block; This is a trend correction function, used to adjust the risk score based on previous data. and time window Calculate the trend adjustment value; For the first The block in the _ ... Risk score for the monitoring period; It is the time window for trend calculation; For comprehensive judgment function, By assessing the total risk score With risk threshold The relationship and the results of trend correction and time factor To output risk results; Total risk score Strict high risk threshold The output state at that time; Medium is the total risk score. The output status is within a fluctuation range of ±5% above and below the risk threshold. Total risk score Output status when the fluctuation limit is 5% below the risk threshold;

[0100] Furthermore, in the risk scoring process, the proportion of difference is first calculated for each segment. This involves summing the absolute values ​​of the byte-by-byte differences between the real-time data block and the baseline data, and then dividing by the sum of the absolute values ​​of the baseline data; finally, the difference ratio is calculated. With the number of visits The base score is obtained by multiplication, and the status is changed according to the correlation check value. With change threshold The comparison results determine the first weight. Based on the difference ratio With risk threshold The comparison results determine the second weight. The base score is multiplied by the two weights to obtain the block risk score. Then, risk scores were assigned to all blocks. Accumulate by block number, and combine with trend correction function. Forming an overall risk score Finally, the total risk score will be calculated. With risk threshold If the risk level is higher than the threshold, a high-risk status is output; if the risk level is within a 5% fluctuation range above or below the threshold, a medium-risk status is output and the verification process begins; if the risk level is lower than the threshold minus 5%, a low-risk result is output.

[0101] In the access control module, the module receives the total risk score and the corresponding risk record table for each block. The risk record table for each block contains the storage page number, block number, unique identifier and risk score of each block, and is arranged in descending order of risk score to form an access control sequence.

[0102] Traverse the permission processing sequence. If a block is marked as high risk, call the firmware permission switching instruction to switch the execution permission of the monitoring address set where the block is located from the executable state to the non-executable state, and immediately freeze all remote communication sessions associated with the storage page where the block is located. At the same time, generate isolation data and write it to the isolation data area.

[0103] If a block is marked as requiring secondary detection, the write channel of the communication session associated with that block is first frozen, while the read channel remains open. In subsequent monitoring cycles, bidirectional reverse data verification is performed on that block, calculating the percentage difference between the verified risk score and the initial risk score. If the verified risk score is equal to or higher than the risk threshold, and the verification results are consistent across two consecutive monitoring cycles, a complete isolation operation is performed. This operation includes switching the execution permissions of all storage locations within the monitored address set to a non-executable state and freezing all remote communication sessions associated with the monitored address set. If only some blocks within a storage page have verification results higher than the risk threshold in two consecutive cycles, only the permission switching and session freezing are performed on that storage page, and the block is added to the detection queue with doubled detection rounds. If the percentage difference does not exceed the fluctuation threshold, the write channel is restored and executable permissions are maintained.

[0104] If a block is marked as low risk, no permission switch will be performed. Instead, the risk score, number of accesses, difference ratio, and fluctuation range within the verification period will be stored in the security log area, and a future risk trend index will be calculated based on historical trends. If the trend index exceeds the warning threshold, the block will be adjusted to a secondary detection state and executed according to the corresponding detection round. Otherwise, the existing permissions and sampling frequency will be maintained.

[0105] After completing the permission processing for all blocks, the isolation records, reverse verification results, trend indices, and permission change logs for this period are encrypted and packaged into an access control report, which is sent to the remote monitoring platform via a remote communication link. A copy of the report is stored in a secure storage area for retrospective auditing.

[0106] In the data reporting module, the risk results and isolation data output by the access control process are received. The risk results are processed into fields according to storage page number, block number, risk score and risk level. The isolation data is processed into fields according to storage page number, start address, end address and isolation reason to form an initial record set.

[0107] Traverse the initial record set, perform field integrity checks and data type checks on each record, write records that fail the checks to the exception record table, and delete the corresponding records from the initial record set; merge records that pass the checks in a fixed order to generate a data packet, and assign a unique packet identifier to the data packet.

[0108] The data packet is input into the encryption operation process, and the preset symmetric key is used to perform block encryption to generate an encrypted data packet. Then, the digest operation is performed on the encrypted data packet to generate an integrity check code, and the integrity check code is appended to the end of the encrypted data packet to form a complete data packet.

[0109] The system invokes a reliable transmission protocol via a remote communication link to send a complete data packet to the remote monitoring platform. After sending, it waits for a parsing confirmation response from the platform. If the parsing confirmation response is marked as successful, the complete data packet and the confirmation time are written to the security log area. If the parsing confirmation response is marked as failed, the complete data packet is added back to the queue to be sent and resent in the next transmission cycle according to the failure retry policy.

[0110] Furthermore, this solution forms a complete firmware security monitoring process in the order of address identification, baseline construction, operational monitoring, anomaly analysis, access control, and data reporting. First, in the address identification stage, the address range that needs to be monitored in the firmware storage medium is determined, and a monitoring address set is generated. In the baseline construction stage, the data of the monitoring address set is divided into blocks, and cyclic redundancy check values ​​and correlation check values ​​are calculated to form stable baseline data. In the operational monitoring stage, the real-time data of the monitoring address set is read periodically, and the data change ratio and access frequency of each block are calculated to form feature data. In the anomaly analysis stage, the feature data is compared with the baseline data, and multi-condition judgment is performed in combination with the access frequency to obtain the block risk score and the total risk score.

[0111] When the risk score triggers a threshold, the access control phase will prohibit the execution of the monitoring address set and disconnect the relevant remote communication; when secondary detection is required, the relevant blocks will be reviewed and verified first; finally, in the data reporting phase, the risk score results and isolated data will be structured, encrypted and sent to the remote monitoring platform to ensure the integrity of the transmitted data.

[0112] This solution addresses the problem that traditional smart meters struggle to detect and handle potential malicious tampering or abnormal access in a timely manner during firmware operation. It enables the system to locate abnormal locations and assess risk levels at the initial stage of risk development, and to immediately block permissions and report information when triggering conditions are met. This reduces the possibility of security vulnerabilities being continuously exploited and ensures the stability of meter operation and the security of metering data.

[0113] In this solution, edge computing refers to decentralizing key calculation and processing logic, such as block reading, cyclic redundancy check, hash digest generation, difference byte statistics, access count weighting, risk score calculation, and permission switching and session freezing after threshold triggering, to the meter side or the nearest data collection gateway as much as possible. This allows for rapid judgment and loss mitigation before remote platforms intervene. Its purpose is to reduce reliance on real-time cloud computing, reduce reporting latency, shorten the attack window, and improve local availability and processing certainty under conditions of disconnection or weak network.

[0114] In this solution, the smart sensor refers to the acquisition unit and its supporting sampling link inside the electricity meter used to form metering and operational characteristics. As a "behavioral reference input" for safety monitoring, it provides operational evidence that corroborates changes in firmware storage. Its purpose is to compare operational characteristics such as electricity metering, load fluctuations, and alarm triggering with storage changes and access behaviors in the firmware reserved area to improve the interpretability and traceability of covert injection and abnormal access. It includes, but is not limited to, sampling and detection units for collecting information such as voltage, current, power, energy, frequency, power factor, cover opening / tampering trigger status, and communication link status, as well as local processing and caching components that write the above acquisition results into logs or form feature fields.

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

Claims

1. A remote monitoring system for smart meters, characterized in that, It includes an address identification module, a baseline construction module, an operation monitoring module, an anomaly analysis module, an access control module, and a data reporting module; The address identification module reads the executable address range of each storage page in the meter firmware storage medium, obtains the starting address and length of the unused reserved area, and generates a monitoring address set by combining them in the order of storage page numbers; The benchmark construction module reads the monitoring address set data byte by byte, divides each storage page into blocks of fixed byte length, performs cyclic redundancy check on each block to generate a check value, concatenates the blocks and check values ​​and inputs them into a hash function to generate a digest, and merges the digests to obtain the benchmark data. The operation monitoring module reads real-time data from the monitoring address set at preset time intervals, divides the data into blocks and generates verification values ​​in the same way as the baseline data, performs byte difference counting to calculate the rate of change, records the number of accesses to each storage location in the monitoring address set during the monitoring period, and generates a feature data sequence. The anomaly analysis module compares the block check values ​​of the feature data with the block check values ​​of the benchmark data, calculates the difference ratio, and generates a weighted risk score by combining the number of accesses, thus obtaining the risk result. The access control module switches the execution permissions of the monitored address set to a non-executable state and freezes all remote communication sessions associated with the monitored address set when the risk results reach a preset threshold, generating isolation data. The data reporting module structures and encrypts risk results and isolation data, and uploads them to the remote monitoring platform via a remote communication link to generate response data.

2. The smart meter remote monitoring system according to claim 1, characterized in that: In the address identification module, the executable address range of each storage page in the meter firmware storage medium is traversed, and the start address and end address of each storage page are read sequentially to form an address record list; By matching and comparing the call path data of each address record in the address record list, it is determined whether the address range is called by the current firmware version. The address range that does not match the call path is marked as the reserved area, and the address range that matches successfully is marked as the occupied area. Calculate the length parameter for each reserved area address range. Sort the list of reserved area address ranges in ascending order according to their starting addresses. Traverse the sorted list. For two adjacent address ranges, check if the end address of the previous range plus one equals the start address of the next range. If they are equal, merge the two address ranges into one, with the start address of the merged range being the start address of the previous range and the end address being the end address of the next range. Recalculate the length parameter. If they are not equal, keep the two address ranges independent and do not merge them. Continue traversing subsequent address ranges. Perform length filtering on the merged address range list, delete all address ranges with length parameters less than a preset threshold, and keep address ranges with length greater than or equal to the preset threshold to obtain an optimized address list; The optimized address list is sorted according to the storage page number and starting address, and each address range is assigned a unique identifier to form a monitoring address set, which serves as the data input for the baseline construction module.

3. The smart meter remote monitoring system according to claim 2, characterized in that: In the baseline construction module, data is read byte by byte from the monitoring address set according to the storage page number. Each storage page is divided into multiple blocks of fixed byte length. At the same time as the block is divided, the start address, end address and block number of each block are recorded to generate a block index table. Traverse the block index table, perform cyclic redundancy check operation on each block in turn, generate the block check value of the block, combine the block check value with the corresponding block number and block length, and write them into the block check value set in turn. Traverse the set of block check values. For two adjacent blocks, first connect their block check values ​​sequentially to form an associated sequence. Then perform a second cyclic redundancy check on the associated sequence to generate an associated check value. Record the associated check value and the corresponding block number together to detect data changes across blocks. Traverse the block index table, concatenate the data, block check value, and associated check value of each block in a fixed order to form an enhanced block, and feed the enhanced block as input data into the hash function to perform hash operation and generate a digest of the enhanced block; All summaries are read sequentially according to the block index table. The summaries are merged in order to generate the baseline data. During the merging process, adjacent summaries are compared for duplication and invalidity. If duplication or invalidity is found, the corresponding summaries are deleted, and only one valid summary is retained. The final baseline data is transmitted to the operation monitoring module as a comparison benchmark, and the block index table, block check value set and associated check value are stored in the secure storage area for feature analysis and abnormal data backtracking during operation.

4. The smart meter remote monitoring system according to claim 3, characterized in that: In the operation monitoring module, each storage page in the monitoring address set is accessed sequentially at preset time intervals. The corresponding real-time data segments are read sequentially based on the storage page number. The real-time data segments are combined with the storage page number and the current timestamp to form record data, and the record data is written to the operation cache area in sequence. Iterate through all the record data in the running buffer, call the block index table of the base data, perform location matching on the real-time data segment, filter out the record data that is inconsistent with the check value of the corresponding block in the base data, and divide these real-time data segments into variable blocks according to a fixed byte length, while recording the start address, end address and block number of each variable block. For each changed block, a cyclic redundancy check operation is performed to generate a real-time block check value. The real-time block check value is then compared byte by byte with the block check value of the corresponding baseline data. The positions of the differing bytes are counted and the difference ratio is calculated to generate difference distribution data. Traverse the differential distribution data, perform a weighted operation on the differential ratio and the number of accesses to the corresponding storage location in the monitoring address set within the current monitoring period to obtain the block change weight, and merge all block change weights in the order of storage page number and block number to form a feature data sequence, and store the feature data sequence in the secure storage area.

5. The smart meter remote monitoring system according to claim 4, characterized in that: In the anomaly analysis module, by traversing each block in the feature data sequence, the corresponding baseline data block verification value and real-time block verification value are located, and a byte-by-byte XOR operation is performed to generate a difference mask. At the same time, the number of difference bytes and the number of accesses in the current monitoring period are counted in parallel. The number of difference bytes is written into the difference count table, and the number of accesses is written into the access count table. For each record in the difference count table, divide the number of difference bytes by the total number of bytes in the block to obtain the initial difference ratio, and retrieve the preceding and following block numbers in the block index table for that block; If the difference ratio of the associated blocks is greater than the difference threshold, the difference ratio of the current block will be increased by the preset correlation correction coefficient; if the difference ratio of the associated blocks is equal to the difference threshold, the block and the associated blocks will be marked as secondary verification targets, and more than two additional sampling verifications will be performed synchronously in the next monitoring cycle. If there are no associated blocks with a difference ratio greater than or equal to the difference threshold, then keep the difference ratio of the current block unchanged and record the trend parameter of the difference ratio change of the block. The processed difference ratio is bound to the number of accesses in the access count table to form a difference ratio table. At the same time as forming the difference ratio table, the block number and associated information of all blocks that enter the secondary verification target are recorded to the verification list, and the change trend parameters are synchronously stored in the secure storage area.

6. The remote monitoring system for smart meters according to claim 5, characterized in that: In the anomaly analysis module, a basic score is generated by traversing the difference ratio table, multiplying the difference ratio by the number of visits, assigning a first weight based on the change status of the associated verification value of the block, assigning a second weight based on the comparison between the basic score and the difference threshold, and multiplying the two weights by the basic score to obtain the block risk score. If the risk score of a segment falls within a fluctuation range of 5% above and below the risk threshold, the segment is marked as requiring secondary detection, and the data of that segment is read more than twice in subsequent monitoring cycles for verification. If the risk score of a segment equals the risk threshold, the segment will be directly included in the high-risk list and marked with a threshold trigger flag in the high-risk list. If the risk score of a segment is not in the floating range and is not equal to the risk threshold, then the segment is marked as normal and read at the normal sampling frequency. The total risk score is generated by accumulating the risk scores of all blocks in the order of storage page number and block number, and then compared with the risk threshold. If the total risk score is greater than the risk threshold, the risk result is output as high, and the list of all high-risk, threshold-triggered, and sub-blocks requiring secondary detection is fed back to the running monitoring process to adjust the sub-block sampling order for the next monitoring cycle. If the total risk score equals the risk threshold, a full re-inspection process is initiated directly. After the full re-inspection, a cross-cycle consistency verification is performed. If the consistency verification results for two consecutive cycles both reach or exceed the risk threshold, a weighted final result is generated and marked as continuously high risk. If the total risk score is less than the risk threshold, the risk result is output as low, and the difference ratio table and the segmented risk score are recorded in the monitoring log. The future risk trend index is calculated based on the trend parameters in the log. If the trend index is higher than the warning threshold, the segment is automatically added to the secondary detection queue for the next cycle.

7. The smart meter remote monitoring system according to claim 6, characterized in that: In the access control module, the module receives the total risk score and the corresponding risk record table for each block. The risk record table for each block contains the storage page number, block number, unique identifier and risk score of each block, and is arranged in descending order of risk score to form an access control sequence. Traverse the permission processing sequence. If a block is marked as high risk, call the firmware permission switching instruction to switch the execution permission of the monitoring address set where the block is located from the executable state to the non-executable state, and immediately freeze all remote communication sessions associated with the storage page where the block is located. At the same time, generate isolation data and write it to the isolation data area. If a block is marked as requiring secondary detection, the write channel of the communication session associated with that block is first frozen, while the read channel is retained. In subsequent monitoring cycles, bidirectional reverse data verification is performed on that block, and the percentage difference between the verified risk score and the initial risk score is calculated respectively. If the verified risk score is equal to or higher than the risk threshold, and the verification results are consistent across two consecutive monitoring cycles, then a complete isolation operation is performed. If only some blocks within a storage page have verification results higher than the risk threshold for two consecutive cycles, then only the permission switch and session freeze will be performed on that storage page, and that block will be added to the detection queue with double the detection rounds. If the percentage difference does not exceed the fluctuation threshold, the write channel is restored and executable permissions are maintained; If a block is marked as low risk, no permission switching will be performed. Instead, the risk score, number of accesses, difference ratio, and fluctuation range within the verification period will be stored in the security log area, and a future risk trend index will be calculated based on historical trends. If the trend index exceeds the warning threshold, the segment will be adjusted to a secondary detection state and executed according to the corresponding detection round; otherwise, the existing permissions and sampling frequency will be maintained. After completing the permission processing for all blocks, the isolation records, reverse verification results, trend indices, and permission change logs for this period are encrypted and encapsulated into an access control report, which is then sent to the remote monitoring platform via a remote communication link. A copy of the report is stored in a secure storage area.

8. The remote monitoring system for smart meters according to claim 7, characterized in that: In the data reporting module, the risk results and isolation data output by the access control process are received. The risk results are processed into fields according to storage page number, block number, risk score and risk level. The isolation data is processed into fields according to storage page number, start address, end address and isolation reason to form an initial record set. Iterate through the initial record set, perform field integrity checks and data type checks on each record, write records that fail the checks to the exception record table, and delete the corresponding records from the initial record set; Records that pass verification are merged in a fixed order to generate data packets, and a unique packet identifier is assigned to each data packet. The data packet is input into the encryption operation process, and the preset symmetric key is used to perform block encryption to generate an encrypted data packet. Then, the digest operation is performed on the encrypted data packet to generate an integrity check code, and the integrity check code is appended to the end of the encrypted data packet to form a complete data packet. The system invokes a reliable transmission protocol via a remote communication link to send a complete data packet to the remote monitoring platform. After sending, it waits for a parsing confirmation response from the platform. If the parsing confirmation response is marked as successful, the complete data packet and the confirmation time are written to the security log area. If the parsing confirmation response is marked as failed, the complete data packet is added back to the queue to be sent and resent in the next transmission cycle according to the failure retry policy.

Images