Intelligent fusion terminal-based end device analog meter reading system and method

Abstract

This invention relates to a terminal device simulation meter reading system and method based on a smart converged terminal. The system includes: a communication adaptation layer, used to provide data transmission and reception interfaces for various transport layer protocols, establish a physical communication link with the smart converged terminal under test, and support link status simulation; a protocol processing layer, used to load various communication protocols, perform frame parsing and encapsulation of transmitted and received data, implant faults, and simulate communication and equipment anomalies; a virtual device layer, used to dynamically create virtual device instances and maintain their operating status; a data intelligent generation and verification layer, used to generate simulated data based on industry load models and random distribution algorithms, and perform full-process verification; a business orchestration and automated testing layer, used to orchestrate test tasks and generate visual test reports; and a business management layer, used to realize full-dimensional simulation testing of the smart converged terminal. This system overcomes the limitations of single-stage simulation and achieves full-service, high-concurrency meter reading testing.

Description

Technical Field

[0001] This invention relates to the field of power Internet of Things (IoT) technology, and in particular to a terminal device analog meter reading system and method based on an intelligent fusion terminal. Background Technology

[0002] With the rapid development of the energy internet and the distribution internet of things (IoT), smart converged terminals, as core nodes connecting master stations and end devices, bear the heavy responsibility of massive end device access, protocol conversion, data collection, and edge computing. Verifying the correctness, stability, protocol compatibility, and full business process processing capabilities of smart converged terminals throughout their entire lifecycle—from R&D and factory testing to on-site operation and maintenance and system integration—is crucial for ensuring reliable system operation. Currently, the industry mainly relies on two methods in testing smart converged terminals: one is real-world testing based on actual physical environments, i.e., meter reading tests by connecting actual electricity meters, sensors, and other physical end devices; the other is using simple single-protocol simulation tools to only verify basic communication link connectivity. In other words, for testing the interaction between smart converged terminals and end devices, related solutions often focus on a single link or partial function. For example, IoT master station simulation communication systems only test the communication link between the master station and the converged terminal, without meter reading business logic; smart electricity terminal meter reading methods only optimize the reading interval of real devices without involving simulated test scenarios. Traditional testing in the industry still focuses on real physical devices, supplemented by simple single-protocol simulation tools, in an attempt to meet the full-dimensional testing needs of converged terminals.

[0003] However, existing testing methods based on real devices and simple simulation tools reveal numerous technical shortcomings in practical applications, making it difficult to meet the testing needs of today's rapidly iterating and large-scale deployment of intelligent converged terminals. Specifically, traditional testing methods require connecting actual physical devices, matching multiple models and protocol-based devices, resulting in high hardware procurement costs, complex wiring and cumbersome configuration, manual intervention required for simulating abnormal operating conditions, and low efficiency in switching test scenarios; existing simulation tools can only simulate communication links and cannot cover the entire business process, including meter reading data collection, command issuance, anomaly handling, and data verification, making it difficult to verify the actual business processing capabilities of converged terminals; each addition of a new protocol meter requires the purchase of physical equipment or the development of a dedicated hardware simulator, protocol adaptation requires modification of core code, making zero-code expansion impossible, resulting in long adaptation cycles and poor flexibility; it is difficult to flexibly simulate various device models and... The data items are similar, and there is a lack of systematic anomaly injection mechanisms. The simulation capabilities for communication anomalies (such as timeouts, bit errors, non-standard protocol frames) and equipment anomalies (such as crashes, self-recovery) are insufficient, making it impossible to fully verify the fault tolerance and anti-attack capabilities of the converged terminal. The testing process involves a lot of manual intervention, and the efficiency of result recording and analysis is low. It is difficult to integrate with the continuous integration / continuous delivery (CI / CD) process, resulting in delayed defect discovery and increased development and testing cycle costs. Most simulation tools only provide fixed values ​​or simple random numbers, which cannot simulate the temporal characteristics of real physical quantities (such as temperature fluctuations, daily changes in electricity load, and trend drift). The simulated data is out of touch with the actual scenario, and the test results have limited reference value.

[0004] Therefore, traditional meter reading testing methods often suffer from high testing costs, incomplete scenario coverage, and low testing efficiency due to their heavy reliance on physical hardware, poor protocol compatibility, and limited testing scenarios. Summary of the Invention

[0005] Based on this, in order to solve the above-mentioned technical problems, a terminal device simulation meter reading system and method based on intelligent converged terminals is provided. This system can break through the limitations of single-stage simulation, reduce dependence on physical equipment, accelerate the functional verification and performance evaluation of converged terminals, and achieve full-service, highly realistic, highly concurrent, and highly flexible meter reading tests.

[0006] A terminal device-based simulated meter reading system based on a smart converged terminal, the system comprising:

[0007] The communication adaptation layer provides data transmission and reception interfaces for various transport layer protocols, establishes a physical communication link with the intelligent fusion terminal under test, and supports link state simulation.

[0008] The protocol processing layer, connected to the communication adaptation layer, is used to dynamically load various communication protocols based on the protocol factory, and to perform frame parsing and encapsulation of the transmitted and received data according to the protocol description model. It also injects faults at the interception points of the protocol processing path to simulate communication and device anomalies.

[0009] The virtual device layer, connected to the protocol processing layer, is used to dynamically create virtual device instances based on the physical communication link and maintain the running status of each virtual device instance.

[0010] A data intelligent generation and verification layer, connected to the virtual device layer, is used to generate simulated data based on the industry load model and random distribution algorithm, and to perform full-process verification of the simulated data.

[0011] The business orchestration and automated testing layer, connected to the virtual device layer and protocol processing layer, is used to orchestrate test tasks, collect key indicators during the test process, and generate visual test reports.

[0012] The business management layer connects and interacts with all layers to provide visual management, monitoring, and configuration functions, enabling full-dimensional simulation testing of intelligent converged terminals.

[0013] In one embodiment, the communication adaptation layer is located at the bottom layer of the system and is used to provide a unified data transmission and reception interface to the upper layers, shielding the differences in the underlying links; it includes a serial port adapter, TCP / UDP Socket service, and MQTT / CoAP service;

[0014] The communication adaptation layer uses the Netty framework to build asynchronous event-driven network communication services to simulate abnormal link layer states such as bandwidth limitations, network latency, packet loss, and out-of-order delivery.

[0015] In one embodiment, the protocol processing layer includes:

[0016] The protocol factory module is used to dynamically load and manage various power industry communication protocols at runtime by parsing the configuration file of the protocol description model, and provides a general interface to support zero-code extension of custom protocols, achieving protocol independence and hot-plugging.

[0017] The frame parsing and encapsulation module implements the unpacking and repacking of byte streams based on a finite state machine, and various verification algorithms are built into the frame parsing and encapsulation module.

[0018] An exception injection engine injects faults at interception points in the protocol processing path to simulate protocol layer exceptions.

[0019] In one embodiment, the virtual device layer includes:

[0020] The equipment factory module pre-allocates memory based on object pool technology and dynamically creates or destroys equipment instances in batches according to the equipment file configuration.

[0021] The device state machine module is used to manage the state transitions of device instances between operating modes;

[0022] The register management module is used to maintain device data items in key-value pairs.

[0023] The data reporting strategy module supports periodic reporting, change reporting, and query response reporting, restoring the actual device behavior.

[0024] In one embodiment, the data intelligent generation verification layer includes:

[0025] The power load model module generates dynamic data with actual electricity consumption time-series characteristics based on typical daily load curves.

[0026] A multi-distribution random number generation module integrates various random distribution algorithms and is used to add noise to the dynamic data;

[0027] The data verification module attaches a verification code when the simulated terminal generates data, and performs verification and comparison at each stage on the intelligent fusion terminal and the simulation master station. If there is any inconsistency, an alarm is triggered, thus realizing the integrity verification of the entire data process.

[0028] In one embodiment, the service orchestration and automated testing layer includes:

[0029] The script orchestration module uses a scripting language to customize tests and calls the protocol processing layer and virtual device layer to automate the orchestration and scheduling of the test process.

[0030] The test report generation module is used to collect key metrics during the testing process and generate visual test reports.

[0031] In one embodiment, the business management layer is used for device management, protocol management, visual monitoring, log management, and user permission management.

[0032] In one embodiment, the system backend uses an asynchronous event-driven framework based on Netty and virtual threads, combined with lock-free circular buffers and object pooling technology, to achieve zero-copy data exchange under high concurrency; and supports the management of virtual device instances as lightweight state objects, enabling a single server to simulate the support of a massive number of devices.

[0033] In one embodiment, the system employs configuration-driven and hot-reload technology, defining device parameters, protocol types, data generation rules, and exception injection rules through an external configuration file, and monitoring file changes to achieve the hot-reload function that dynamically adjusts all configurations without restarting or interrupting testing.

[0034] A method for simulating meter reading using an end device based on a smart converged terminal, the method comprising:

[0035] Multiple communication links with the intelligent converged terminal are established through the communication adaptation layer, and the link status is configured.

[0036] The protocol processing layer dynamically loads the communication protocol of the target device and establishes a protocol parsing channel;

[0037] The virtual device layer creates virtual device instances in batches and assigns each instance a unique ID, protocol parameters, data generation rules, and state machine.

[0038] The data intelligent generation and verification layer generates simulated meter reading data that conforms to the characteristics of power load for each of the virtual device instances, and attaches a verification code;

[0039] According to the reporting policy, the virtual device instance encapsulates the simulated data with verification code into a protocol frame through the protocol processing layer and then sends it to the intelligent fusion terminal through the communication adaptation layer.

[0040] The business orchestration and automated testing layer performs stress, anomaly, and full-process automated testing on the intelligent converged terminal by injecting faults and orchestrating business scenarios.

[0041] After processing the data, the intelligent fusion terminal uploads it to the simulation master station, which completes the data consistency verification throughout the entire process by comparing the check code.

[0042] The business management team conducts real-time visual monitoring, log recording, and report generation of the testing process.

[0043] The aforementioned terminal device simulation meter reading system and method based on intelligent converged terminals, through the collaborative operation of the communication adaptation layer, protocol processing layer, virtual device layer, data intelligent generation and verification layer, service orchestration and automated testing layer, and service management layer, replaces physical terminal devices with pure software. It can quickly establish a stable communication link with the intelligent converged terminal under test and flexibly simulate various complex link states and abnormal device communication conditions. It achieves full-dimensional, high-fidelity simulation testing of intelligent converged terminals. Utilizing the dynamic instance creation capability of the virtual device layer, it enables high-concurrency simulation of massive numbers of terminal devices on a single machine. The data intelligent generation and verification layer combines industry load models and random distribution algorithms to generate simulated data with realistic physical characteristics, and ensures data consistency through a full-process verification mechanism, effectively improving the authenticity and reliability of test data. The fault implantation function of the protocol processing layer and the automated testing capability of the service orchestration and automated testing layer enable the system to simulate complex communication anomalies and device failure scenarios, automatically complete test task orchestration and key indicator collection, significantly improving testing efficiency and coverage, and providing comprehensive technical support for the stability verification of intelligent converged terminals. Attached Figure Description

[0044] Figure 1This is a structural block diagram of a terminal device simulating meter reading system based on a smart fusion terminal in one embodiment;

[0045] Figure 2 This is a schematic diagram of the three-layer architecture of a terminal device simulating meter reading system based on a smart fusion terminal in one embodiment;

[0046] Figure 3 This is a schematic diagram of the packet merging processing algorithm in one embodiment;

[0047] Figure 4 This is a schematic diagram of the anomaly injection decision algorithm process in one embodiment;

[0048] Figure 5 This is a schematic diagram of the software architecture of a terminal device simulating meter reading system based on a smart fusion terminal in one embodiment;

[0049] Figure 6 This is a flowchart illustrating a terminal device-based meter reading system using a smart fusion terminal in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In one embodiment, such as Figure 1 As shown, a terminal device analog meter reading system based on an intelligent fusion terminal is provided, including:

[0052] The communication adaptation layer 100 is used to provide data transmission and reception interfaces for various transport layer protocols, establish a physical communication link with the intelligent fusion terminal under test, and support link status simulation.

[0053] The protocol processing layer 200, connected to the communication adaptation layer 100, is used to dynamically load various communication protocols based on the protocol factory, and to perform frame parsing and encapsulation of the transmitted and received data according to the protocol description model. It also injects faults at the interception points of the protocol processing path to simulate communication and device anomalies.

[0054] The virtual device layer 300, connected to the protocol processing layer 200, is used to dynamically create virtual device instances based on the physical communication link and maintain the running status of each virtual device instance.

[0055] The data intelligent generation and verification layer 400 is connected to the virtual device layer 300 and is used to generate simulated data based on the industry load model and random distribution algorithm, and to perform full-process verification of the simulated data.

[0056] The business orchestration and automated testing layer 500 is connected to the virtual device layer 300 and the protocol processing layer 200. It is used to orchestrate test tasks, collect key indicators during the test process, and generate visual test reports.

[0057] The business management layer 600 connects and interacts with each layer to provide visual management, monitoring, and configuration functions, enabling full-dimensional simulation testing of intelligent converged terminals.

[0058] This embodiment provides a terminal device simulation meter reading system based on a smart converged terminal. During the R&D, testing, and maintenance phases of the smart converged terminal, it replaces physical devices with pure software, achieving full-dimensional interface connectivity with the southbound interface of the converged terminal. Specifically, it adopts a multi-layered structure, plug-in module expansion, and front-end / back-end separation design, divided from bottom to top into a communication adaptation layer 100, a protocol processing layer 200, a virtual device layer 300, and a service orchestration and automated testing layer 500. The upper layers are supported by a data intelligent generation and verification layer 400 and a service management layer 600, constructing a bidirectional closed-loop testing system for the entire meter reading business, from the simulated terminal to the smart converged terminal to the simulation master station. The back-end uses a high-concurrency asynchronous architecture to simulate massive numbers of devices, while the front-end implements visual monitoring and operation. It achieves multi-protocol adaptive simulation, large-scale high-concurrency device simulation, intelligent high-fidelity data generation, full-level anomaly injection, full-process data verification, and automated testing. The overall architecture balances scalability, high performance, and ease of use.

[0059] In one embodiment, the communication adaptation layer is located at the bottom layer of the system and is used to provide a unified data transmission and reception interface to the upper layers, shielding the differences in the underlying links; it includes a serial port adapter, TCP / UDP Socket service, and MQTT / CoAP service; the communication adaptation layer uses the Netty framework to build an asynchronous event-driven network communication service to simulate abnormal states of the link layer such as bandwidth limitation, network latency, packet loss, and out-of-order delivery.

[0060] The communication adaptation layer is responsible for shielding the differences between the underlying physical links and network protocols, providing a unified data transmission and reception interface for the upper layers. It includes three core sub-modules: serial port adapter, TCP / UDP Socket service, and MQTT / CoAP service. It is mainly used to unify and abstract the underlying communication methods, support communication links such as physical serial ports / virtual serial ports, TCP / UDP, and MQTT / CoAP, and realize data transmission and reception and link status simulation, such as bandwidth limitation, latency, and packet loss.

[0061] Specifically, the serial adapter can use a physical serial port for communication or a serial port server, supporting serial connections (RS-232 / RS-485) with the intelligent fusion terminal. In this embodiment, the serial adapter can be bound to a real physical serial port device or communicate with serial applications within the fusion terminal via a virtual serial port. Specifically, a physical serial port can be used under Windows, or a serial port server can be connected to the intelligent fusion terminal, with software dynamically managing the serial port to achieve half-duplex data communication.

[0062] The TCP / UDP Socket service provides high-concurrency communication capabilities over Ethernet, supporting TCP Server / Client and UDP unicast / broadcast, and can simulate harsh environments such as network bandwidth limitations, latency, and packet loss. Specifically, the system can implement the Reactor pattern based on Netty, registering each Socket connection to the EventLoop; the Server mode listens on a specified port, allocates a virtual device instance and establishes a session context after accepting a connection; the Client mode actively connects to the converged terminal according to the configuration; a lock-free circular buffer is used to handle data caching and implement packet fragmentation / reassembly; and network attributes are simulated through application-layer token buckets or the Linux tc command.

[0063] The MQTT / CoAP service can be adapted to IoT communication scenarios, enabling virtual devices to interact with converged terminals / simulation master stations through a publish / subscribe model, supporting session persistence and simulation of weak network environments. Specifically, the system can be encapsulated into a unified Channel interface based on Eclipse Paho (MQTT) and Californianium (CoAP); configure Broker address, client ID, username / password, subscribe to downlink topics, and publish uplink topics; automatically handle reconnection and heartbeat keep-alive, and cache data to be sent during disconnection; and support simulation of message delay, duplication, and out-of-order delivery.

[0064] In one embodiment, the protocol processing layer includes: a protocol factory module, used to dynamically load and manage various power industry communication protocols at runtime by parsing the configuration file of the protocol description model, and to provide a general interface to support zero-code extension of custom protocols, achieving protocol independence and hot-plugging; a frame parsing and encapsulation module, which implements the unpacking and repacking of byte streams based on a finite state machine, and the frame parsing and encapsulation module has various built-in verification algorithms; and an exception injection engine, which injects faults at the interception points of the protocol processing path to simulate protocol layer exceptions.

[0065] The protocol processing layer can support dynamic hot-plugging of protocols by building a protocol factory, complete the packaging and decomposition of various protocols, integrate an exception injection engine, implement fault simulation at the protocol layer, and perform security processing such as data encryption and verification, achieving a deep integration of protocol independence and fault simulation. Specifically, the protocol processing layer is responsible for parsing and encapsulating raw data, realizing dynamic adaptation of multiple protocols and full-level exception injection. It is the core business module, comprising three sub-modules: protocol factory, frame parsing and encapsulation, and exception injection.

[0066] The protocol factory module implements dynamic loading and hot-plugging of multiple protocols based on the Protocol Description Model (UPDL), and provides an open general ProtocolCodec interface to support zero-code extension of custom protocols; the frame parsing and encapsulation module implements byte stream unpacking / encapsulation based on a finite state machine, and has built-in verification algorithms such as CRC8 / 16 / 32 and MD5; the exception injection engine implants faults at the protocol layer and data layer, supports the simulation of multiple types of exceptions such as packet loss, data tampering, verification errors, and illegal function codes, and the exception rules are configurable and support dynamic adjustment.

[0067] The protocol factory module can dynamically load and manage various communication protocol models. At runtime, it generates codecs based on the protocol type, enabling zero-code extension and hot-plugging of protocols. Specifically, the protocol factory module uses JSON Schema to define the Protocol Description Model (UPDL), which includes frame structure, field types, and verification algorithms. It converts the UPDL into an executable parsing script through an embedded Lua script engine, or generates a dynamic link library to achieve plug-in loading. It caches the loaded protocol processor, monitors changes to the configuration file, and achieves hot loading.

[0068] In this embodiment, the system can adopt multi-protocol adaptive simulation and dynamic expansion technology, mainly including decoupling protocol parsing from business logic based on the Netty codec pipeline, and incorporating common power protocol libraries such as DL / T645, DL / T698, Modbus, IEC 101 / 104, MQTT, and CoAP; opening the ProtocolCodec general interface, which allows developers to quickly access custom binary / text protocols without modifying the core framework; and adopting the Protocol Description Model (UPDL), which defines the protocol frame structure, field types, and verification algorithms through JSON Schema, and dynamically loads configuration files to achieve "zero-code" extension and hot-plugging of protocols.

[0069] The frame parsing and encapsulation module can perform byte stream unpacking, verification, field extraction, and response frame assembly according to the protocol model, supporting fixed-length frames, variable-length frames, and frames with special delimiters. Specifically, the frame parsing and encapsulation module implements the unpacking engine based on a finite state machine (FSM), with states including waiting for the frame header, receive length field, receive data field, and verification waiting; it extracts fields according to the protocol definition and converts them to host byte order, supporting complex nested structures; the frame parsing and encapsulation module has built-in verification algorithms such as CRC8 / 16 / 32, LRC, and MD5, and the verification range can be configured; the frame parsing and encapsulation module can query register data according to the request command code, assemble the response frame according to the protocol format, and recalculate the verification.

[0070] The exception injection engine implants faults into the protocol stack processing path to simulate communication and device anomalies, verifying the fault tolerance capabilities of the converged terminal. Specifically, the exception injection engine can set interception points (Hooks) before / after frame parsing and before / after encapsulation, and the exception injector registers callback functions; it matches exception rules (probability, device ID, command code) based on the rule engine to implement anomalies such as packet loss, delayed response, data tampering, and verification errors; and it enables / disables rules in real time and dynamically adjusts parameters through the management interface.

[0071] Among them, the anomaly injection engine can support anomaly injection at all levels of protocol layer, data layer, state layer and link layer, including hundreds of abnormal conditions such as data jump, dead value, over-limit, error check code, device crash, network latency, packet loss, etc. Anomaly rules are triggered by probability or time, and parameters can be dynamically enabled / disabled and adjusted during the test.

[0072] In this embodiment, the system employs full-layer anomaly injection and fault simulation technology. By designing a fault injection engine, it implements systematic anomaly injection at the protocol, data, state, and link layers, supporting probabilistic, deterministic, and temporal faults to verify the fault tolerance and anti-attack capabilities of the converged terminal. The injected anomalies or faults mainly include: data layer anomalies: spikes, dead values, data jumps, packet loss (proportional), and exceeding limits; protocol layer anomalies: error check codes, illegal function codes, delayed responses, excessively long fields, and malformed packets; state layer anomalies: forcing the device state machine to transition to a fault state, simulating device crashes, self-recovery, and standby behaviors; and link layer anomalies: simulating bandwidth limitations, network latency, packet loss, and out-of-order delivery, recreating the harsh communication environment of wireless public network / power line carrier. All anomaly rules can be defined through configuration files and triggered by probability or time, supporting dynamic adjustment during testing.

[0073] In one embodiment, the virtual device layer includes: a device factory module, which pre-allocates memory based on object pool technology and dynamically creates or destroys device instances in batches according to device file configuration; a device state machine module, which manages the state transitions of device instances between working modes; a register management module, which maintains device data items in key-value pairs; and a data reporting strategy module, which supports periodic reporting, change reporting, and query response reporting to restore the behavior of real devices.

[0074] The virtual device layer dynamically creates a massive number of virtual device instances based on the device factory, and each instance has an independent ID, protocol parameters, state machine, and data generator. The virtual device layer can design device state machines to simulate multiple working modes of devices and configure flexible data reporting strategies (periodic, change, query response) to achieve high-fidelity device behavior simulation.

[0075] The virtual device layer is responsible for the creation, management, and behavior simulation of massive numbers of virtual devices, comprising four main sub-modules: device factory, device state machine, register management, and data reporting. The device factory dynamically creates / destroys virtual device instances based on configuration files. Each instance has a unique ID, protocol parameters, state machine, and data generator, and supports batch creation. Specifically, the device factory module can pre-allocate device instance memory based on object pooling technology and maintain instance context through a ConcurrentHashMap. It supports batch importing device profile information (table number, asset number, protocol type, etc.) according to configuration files, enabling rapid modeling of tens of millions of devices.

[0076] The device state machine module is used to simulate the state transitions of multiple operating modes of a device, supporting dual triggering by internal timers and external commands. Specifically, the device state machine module designs a state transition matrix, defines states such as standby, running, fault, and calibration, and their transition conditions, supporting dual triggering by internal timers and external commands; it uses the state pattern to encapsulate each state as an independent module, manages state transitions through Spring StateMachine, and supports the listening and processing of state events.

[0077] The register management module can be used to simulate the registers / configuration items of a device, supporting read and write operations and providing data support for data generation and command response. Specifically, the register management module stores register data in key-value pairs, mapping register addresses and data items according to the protocol model; it supports real-time modification and persistence of register data, and can be manually adjusted through the front-end interface to simulate device parameter configuration.

[0078] The data reporting strategy module can implement multiple data reporting strategies based on configuration, replicating the reporting behavior of real devices. Specifically, the data reporting strategy module supports periodic reporting (timer-triggered), change reporting (triggered when data change exceeds a threshold), and query response (returning data only when a query command is received), replicating the reporting behavior of real devices; the reported data is provided by the data intelligent generation and verification layer, supporting the supplementary transmission of real-time data and historical data.

[0079] In one embodiment, the intelligent data generation and verification layer includes: a power load model module, which generates dynamic data with actual electricity consumption time sequence characteristics based on typical daily load curves; a multi-distribution random number generation module, which integrates various random distribution algorithms to add noise to the dynamic data; and a data verification module, which adds a verification code when the data is generated by the simulation terminal, and performs verification and comparison at each stage in the intelligent fusion terminal and the simulation master station, triggering an alarm when there is inconsistency, thereby realizing the integrity verification of the entire data process.

[0080] Among them, the data intelligent generation and verification layer incorporates a typical load model of the power industry and a multi-distribution random number generation algorithm to generate simulated data that conforms to the actual time series characteristics; a verification code mechanism is used to realize the automatic verification of data from the simulation terminal to the simulation master station throughout the entire process, ensuring the integrity of data transmission.

[0081] The data intelligence generation and verification layer is responsible for generating and verifying high-fidelity simulation data throughout the entire process. It includes a power load model module, a multi-distribution random number generation module, and a data verification module. The power load model module is used to construct typical load models for the power industry and generate simulation data that conforms to time-series characteristics. Specifically, based on typical daily load data from the power grid company, the power load model module constructs 24-hour load curves for residential / industrial / commercial applications, supports linear / nonlinear trends and periodic sine wave simulations, and allows configuration of baseline values, slopes, and fluctuation ranges, supporting time-series trend simulations.

[0082] The multi-distribution random number generation module is used to generate random numbers with different distributions for simulating noise, discrete events, etc. Specifically, the multi-distribution random number generation module can use the Java Random Number API and Apache Commons Math to generate uniform, normal (Box-Muller), and Poisson distributed random numbers; combined with the Xorshift128+ algorithm, it can quickly generate noise sequences and overlay them onto the load curve data.

[0083] In this embodiment, the system can employ intelligent high-fidelity data generation technology, mainly including: multi-distribution random number generation algorithms: uniform distribution (irregular noise), normal distribution (physical quantities such as voltage / temperature, Box-Muller algorithm), and Poisson distribution (discrete events such as the number of fault occurrences); typical load models in the power industry: constructing 24-hour time-series load curves for residential, industrial, and commercial electricity consumption scenarios, supporting linear / nonlinear trends, periodic simulation, and random walks to generate dynamic data that conforms to actual electricity consumption patterns; data preprocessing and noise superposition: integrating moving average, first-order low-pass, and other filtering algorithms to simulate sensor data preprocessing; superimposing random noise to improve data accuracy; and simultaneously supporting the reading of real data streams from external files (CSV / JSON), playback by timestamp, and restoration of the on-site scene.

[0084] The data verification module is used to automatically verify data throughout the entire process from the simulation terminal to the simulation master station, accurately identifying data tampering and loss. Specifically, the data verification module can use MD5 / CRC16 / 32 algorithms to generate checksums, which are transmitted along with the data packets. The fusion terminal and the simulation master station recalculate the checksums and compare them. If they are inconsistent, retransmission and alarms are triggered, and the verification results are recorded in the log throughout the process.

[0085] In this embodiment, the system can employ full-process automatic data verification technology, specifically using the MD5 / CRC checksum mechanism to achieve full-process automatic verification of meter reading data from "simulated terminal - intelligent fusion terminal - simulation master station". This mainly includes: after the simulated terminal generates meter reading data, it calculates a unique checksum and encapsulates "data + checksum" into a message for transmission; the intelligent fusion terminal receives the data, recalculates the checksum, and if they match, it processes the data normally; otherwise, it triggers retransmission and an alarm; the fusion terminal uploads data along with a secondary checksum, and the simulation master station completes the final verification, recording the verification results throughout the process to accurately identify data tampering and loss issues.

[0086] In one embodiment, the data intelligent generation verification layer may also include a data playback module to recreate the real-world data scenario and improve the authenticity of the test. Specifically, the data playback module supports reading pre-recorded real data streams from CSV / JSON files, parsing timestamps and data items, and accurately replaying the data by timestamp to simulate actual meter reading data on-site.

[0087] In one embodiment, the business orchestration and automated testing layer includes: a script orchestration module, which uses a scripting language to customize tests and calls the protocol processing layer and virtual device layer to achieve automated orchestration and scheduling of the test process; and a test report generation module, which collects key indicators during the test process and generates a visual test report.

[0088] The business orchestration and automated testing layer supports scripted automated testing, enabling fault orchestration and test task scheduling, automatically collecting test data and generating visual test reports, and seamlessly integrating with CI / CD pipelines to improve the level of test automation.

[0089] The business orchestration and automated testing layer is responsible for the orchestration, execution, and report generation of test tasks, supporting CI / CD integration. It includes a script orchestration module and a test report generation module. The script orchestration module supports scripted test case orchestration for automated testing, using Quartz for task scheduling and automatically collecting test metrics (device connection count, reporting success rate, response latency, etc.). Specifically, the script orchestration module provides a Lua / Python scripting engine, supports custom test steps, exception injection timing, and assertion conditions; it allows for drag-and-drop orchestration of test flows, lowering the barrier to script writing.

[0090] The test report generation module automatically generates visual test reports, supporting report export and sharing. Specifically, based on the collected test data, the module generates visual content such as bar charts, line charts, and reports, including modules for test overview, indicator statistics, anomaly analysis, and problem localization. It can seamlessly integrate with CI / CD pipelines to achieve automated integration testing; reports can be exported in PDF / Excel format and support online sharing.

[0091] In one embodiment, the business orchestration and automated testing layer may further include a task scheduling module and a data acquisition module. The task scheduling module can implement timed, triggered execution of test tasks and supports the parallel execution of batch tasks. Specifically, the task scheduling module can be based on Quartz to implement task scheduling, supporting one-time and periodic tasks; it can configure task triggering conditions (such as reaching a threshold for the number of devices, successful network connection), and supports the parallel execution of multiple tasks.

[0092] The data acquisition module can automatically collect key indicators during the testing process, providing data support for the test report. Specifically, the data acquisition module can collect indicators such as the number of connected devices, data reporting success rate, command response latency, anomaly rate, and system resource utilization in real time, and store them in a time-series database.

[0093] In one embodiment, the business management layer is used for device management, protocol management, visual monitoring, log management, and user permission management.

[0094] Specifically, the business management layer can achieve centralized management of devices, protocols, and users, support real-time data viewing, communication data analysis, and log management, provide a WinForms visual operation interface, realize centralized management of devices / protocols, display device status and simulation data in real time, support bidirectional log association and multi-condition query, and reduce the operation threshold.

[0095] In this embodiment, the business management layer is responsible for software configuration, monitoring, logging, and user management, including device management, protocol management, visual monitoring, log management, and user permission management. Device management enables batch creation, deletion, and configuration modification of virtual devices, and real-time viewing of device status. Specifically, it provides a visual interface that supports importing / exporting device profile information, allows filtering of devices by device ID, protocol type, and status, and displays real-time device connection status, last communication time, and data reporting status.

[0096] Protocol management allows for the addition, deletion, and configuration modification of protocols, and supports hot reloading of protocols. Specifically, it provides a protocol upload and testing interface, supports the editing and import of UPDL configuration files, allows real-time enabling / disabling of protocols, and allows viewing of protocol parsing logs.

[0097] Visual monitoring can display simulated data, device status, and test indicators in real time, realizing data visualization and alarm pop-ups; specifically, it is based on LiveCharts to build dynamic dashboards, and receives real-time data pushes from the backend through SignalR to achieve millisecond-level curve updates; it supports the overlay and comparison of data from multiple devices, configuration of alarm thresholds, and real-time pop-up reminders when anomalies occur.

[0098] Log management enables the recording, querying, and exporting of communication logs, operation logs, and exception logs. Specifically, it uses structured log storage, which includes fields such as device ID, timestamp, data content, operation type, and exception type. It supports filtering and querying based on multiple conditions, and logs can be exported as CSV / JSON files for easy problem analysis.

[0099] User permission management enables fine-grained management of users, roles, and permissions, ensuring software operation security. Specifically, it is based on the RBAC permission model, defining roles such as administrators, testers, and operations and maintenance personnel, assigning different operation permissions (such as device configuration, protocol management, and log viewing), and supporting the addition, deletion, and modification of user permissions.

[0100] In one embodiment, a terminal device-based simulated meter reading system based on a smart fusion terminal can employ device state machine and intelligent response technology. For multiple operating modes of the device (standby, running, fault, calibration), a state transition matrix is ​​designed. State transitions can be triggered by an internal timer or driven by external commands. Each state is encapsulated as an independent module using state patterns for easy expansion. A command dispatcher maps function codes to corresponding processing functions. Device registers / configuration items are stored in key-value pairs, supporting read and write operations. For time-consuming operations (such as device self-test), an asynchronous response is simulated, first replying with a "received" frame and then sending a result frame later, replicating the actual device response behavior.

[0101] The system can also employ virtual time and timing consistency technology. To accurately simulate timing-dependent scenarios (such as multiple devices reporting simultaneously), a virtual time mechanism is used, with the simulation software uniformly advancing the time to avoid uncertain behavior caused by real clock drift. All simulation data is accompanied by nanosecond-level high-precision time stamps, supporting breakpoint resume and timing alignment to ensure the accuracy and traceability of test data.

[0102] In one embodiment, a three-layer architecture diagram of an end-device analog meter reading system based on a smart converged terminal is provided as follows: Figure 2 As shown, the system's core hierarchy and functional modules are divided from top to bottom, intuitively demonstrating the system's data flow and functional division. For example... Figure 2 As shown, the terminal device-based meter reading system based on intelligent converged terminals has a top-down layered design. The top layer is the business management layer, which is the entry point for user interaction and business control. The middle layer is the protocol processing layer, used for core business logic and protocol parsing. The bottom layer is the communication adaptation layer, used for accessing and adapting underlying communication links. The devices, protocols, and test rules configured by the user in the business management layer are passed down to the protocol processing layer for parsing and encapsulation. Then, the communication adaptation layer establishes a physical link, ultimately completing the interaction with the intelligent converged terminal under test.

[0103] like Figure 2 As shown, specifically, the business management layer is the system's user interaction and business control layer, providing a visual operation interface for testers. This mainly includes: Terminal device type management: defining, configuring, and managing virtual terminal device templates of different models and protocols; Protocol management: configuring, loading, and managing different communication protocols (such as DL / T645, Modbus, etc.), supporting dynamic protocol expansion and parameter configuration; Data viewing: real-time viewing of communication data, device status, and data reporting results during simulated meter reading; Statistical analysis: statistical analysis of test data, such as meter reading success rate, communication latency, and number of anomalies, providing support for test reports.

[0104] The protocol processing layer is the core business logic layer of the system, responsible for all protocol-related processing and anomaly simulation. It mainly includes: Encoding and Decoding: Encoding (e.g., checksum calculation) and decoding (e.g., message parsing) of transmitted and received data according to protocol specifications; Parsing and Encapsulation: Encapsulating business data into standard messages according to the protocol format, or parsing received messages into business data; Packet Reassembly and Decomposition: Solving common packet reassembly and decomposition problems in streaming protocols such as TCP, ensuring complete message parsing; Security Processing: Implementing security mechanisms in the protocol, such as encryption, authentication, and anti-tampering verification; Anomaly Simulation: Injecting various anomalies (e.g., verification errors, message malformation, delayed response) into the protocol processing process to simulate communication failures in real-world scenarios, used to verify the fault tolerance capabilities of the tested terminal.

[0105] In one embodiment, the packet merging processing algorithm proceeds as follows: Figure 3 As shown, Figure 3 This demonstrates the handling process of packet reassembly / splitting in TCP transmission. Based on the "buffer accumulation-length reading-frame segmentation" algorithm, it realizes the reconstruction of complete frames, including core steps such as data reception, buffer judgment, frame header parsing, data segmentation, and protocol processing, demonstrating reliable data parsing capabilities under high concurrency.

[0106] like Figure 3 As shown, the packet merging processing algorithm includes the following steps: The system receives byte stream data from the communication layer and appends it to a memory buffer for temporary storage; it determines whether there is enough data to read the frame header, checks the current data length in the buffer to see if it is greater than or equal to the frame header length defined by the protocol; if not, it means that there is not enough data to parse the frame header, and the process returns to "waiting for more data", continuing to receive data and append it to the buffer; if yes, it proceeds to the next step, reads the frame header, obtains the frame length L, reads the protocol frame header part from the buffer, parses the "frame length field" defined by the protocol, and obtains the total length L of the current frame (including the frame header + data body).

[0107] Next, the system determines whether there is enough data to read a complete frame. It checks the current data length in the buffer again to see if it is greater than or equal to the frame length L. If not, it means there is not enough data to form a complete protocol frame, and the process returns to "waiting for more data" to continue receiving data. If so, it means there is already at least one complete protocol frame in the buffer. The system reads and processes one frame of data, retrieves the complete data of length L from the buffer, and delivers it to the protocol processor for parsing, verification, and business logic processing. After processing, the processed L bytes are removed from the buffer to avoid duplicate processing.

[0108] The system repeatedly checks if there is still data in the buffer, and then checks the remaining data length in the buffer again to see if it is greater than or equal to the frame length L. If yes, it returns to the step of reading the frame header and continues to process the next protocol frame; otherwise, the process ends and waits for the next batch of data to be received.

[0109] In one embodiment, the anomaly injection decision algorithm process is as follows: Figure 4 As shown, Figure 4 The core decision-making process of the fault injection engine is demonstrated, including steps such as abnormal rule acquisition, random number probability determination, rule matching, abnormal type handling (packet loss, data jump, verification error, etc.), and logging, reflecting the configurability and flexibility of full-level abnormal injection.

[0110] like Figure 4As shown, the anomaly injection decision algorithm process includes: process initiation, entering the anomaly injection judgment stage; the system obtains the current device anomaly rule list and reads all the anomaly rules configured for the virtual device (such as packet loss rate, data jump probability, verification error probability, etc.) to prepare for subsequent judgment; the system judges whether the rule is empty. If the rule is empty, it means that the current device has not configured any anomalies, and the process ends directly without any modification, and the message is sent normally; if the rule is not empty, the system enters the rule matching stage.

[0111] Next, the system retrieves a rule and iterates through the list of abnormal rules in sequence. For each rule, a random number Rn (between 0 and 1) is generated and compared to the rule's trigger probability. The system checks if Rn is less than the rule's probability. If not, the current random number does not match the rule's trigger probability, and the exception is not triggered. The system then retrieves the next rule and continues the check. If Rn matches, the abnormal rule is matched, and the system enters the exception handling phase. Next, the system modifies the message according to the rule type. Based on the matched exception type, the system modifies or marks the message. Supported exception types include: Packet loss: directly marking the message as "discarded"; Data jump: modifying data fields in the message, such as changing a normal meter reading value to a jump-related abnormal value; Checksum error: tampering with the message's checksum (such as CRC or checksum) to create a checksum failure scenario; Erroneous data: modifying the message format to generate malformed messages or data that does not conform to the protocol specifications. Next, the system can record the time, device, rule type, and message modification details of this injection in the exception log for subsequent test analysis and problem localization. It then determines whether to mark the message as discarded. If so, it indicates the exception is a "packet loss" rule, and the system returns directly without sending a message, simulating communication loss. If not, it indicates the exception is a message modification rule, and the modified message will be sent normally to the tested terminal, simulating data / protocol anomalies. Finally, the system ends the exception injection process, and the message (either discarded or modified) enters the subsequent communication process.

[0112] The communication adaptation layer is the system's bottom-level communication access layer, responsible for establishing a physical communication link with the terminal under test and shielding the differences between different communication methods. It mainly includes: serial port adapter (including virtual serial port): supports physical serial ports and virtual serial ports, and is compatible with devices that use traditional RS485 / 232 communication; TCP / UDP communication: supports TCP and UDP communication based on IP networks, and is compatible with network devices such as Ethernet, 4G / 5G, etc.; MQTT: supports MQTT protocol communication commonly used in IoT, and is compatible with terminal devices based on IoT platforms.

[0113] This embodiment integrates core technologies such as high-concurrency network communication, multi-protocol dynamic adaptation, intelligent data generation, full-level exception injection, lock-free concurrent programming, and configuration-driven hot reloading. It features front-end and back-end separation development, balancing high performance, high scalability, and ease of use. Specifically, the front-end programming language is C#; the development tool is Microsoft Visual Studio 2022 (64-bit); the UI framework is WinForms + .NET Framework 8.0 (compatibility and stability are prioritized); the communication libraries are HttpClient (REST API) and SignalRClient (real-time bidirectional communication); data visualization uses ScottPlot (lightweight plotting) and LiveCharts (dynamic dashboards); logging uses NLog / log4net (operation and communication logs); and unit testing uses the NUnit / xUnit (ViewModel) layer.

[0114] The backend programming language of the technology stack is Java 17 / 21 (LTS version, supporting ZGC and virtual threads); network communication uses Netty (an asynchronous event-driven network framework for handling high-concurrency TCP / UDP connections); protocol libraries include modbus4j / jamod (Modbus), Eclipse Paho (MQTT), and Californianium (CoAP); the concurrency model uses Netty EventLoop + virtual threads, with channels corresponding to device connections, EventLoop handling I / O, and virtual threads handling business logic; data processing uses Apache Commons Math and Java random number API (for multi-distribution random number generation); a custom filtering algorithm is used (for sensor data preprocessing); the state machine is Spring StateMachine / squirrel-foundation (for device state transition management); configuration management uses Spring Boot + YAML / HOCON (supporting hot reloading and multi-environment configuration); and logging uses SLF4J. +Logback (structured logs, output by device ID / direction); build and testing primarily use Maven / Gradle (dependency management), JUnit5+Mockito (unit testing), and JMeter / Gatling (performance testing); deployed with Docker+Kubernetes (containerized deployment, elastic scaling).

[0115] In one embodiment, the software architecture of a terminal device-based simulated meter reading system based on a smart converged terminal has three layers, such as... Figure 5As shown, this demonstrates the composition of the software's three-tier architecture, the core modules at each level, and the interaction relationships between modules. It also embodies the bidirectional closed-loop testing system for the entire meter reading business, consisting of "simulated terminal - intelligent fusion terminal - simulation master station," clearly presenting the transmission and processing flow of data and instructions at each stage.

[0116] like Figure 5 As shown, the system generates virtual devices and data through backend services, interacts with the converged terminal under test via the communication layer, and links with the data center to achieve end-to-end meter reading simulation and testing closed loop. Specifically, the device layer is the system's interaction entry point, divided into two roles: Simulation devices 1-n: Virtual terminal device instances created by the system's backend services, which can be generated in batches (from 1 to n) to simulate the behavior and data of real energy meters, data collectors, and other devices; Converged terminals 1-n: The objects under test, i.e., the smart converged terminals, which receive meter reading data from the simulation devices and transmit it upwards, serving as the verification target for the entire test. The simulation devices establish a connection with the converged terminals through the communication layer, realizing the realistic meter reading process of "simulation devices reporting data, and converged terminals receiving and processing it."

[0117] The communication layer, acting as a data transmission hub, shields the differences between various communication methods, providing a unified transmission channel for upper-layer services: Ethernet / Wireless: Supports IP-based network communication, adapts to protocols such as TCP / UDP and MQTT, and corresponds to the network interface of the converged terminal. Serial Communication: Supports serial port protocols such as RS485 / 232, adapts to the physical interface of traditional meter reading equipment, and includes virtual serial port simulation capabilities. Messages generated by the backend service are sent to the simulation device or the converged terminal under test through the corresponding channel of the communication layer; response data from the device / terminal is also sent back to the backend service through the communication layer.

[0118] The backend service layer contains 8 core functional modules that interact bidirectionally with the data center. The core functional modules mainly include: device session manager, state machine engine, data generator, data rule configuration, protocol manager, task manager, exception injection engine, and front-end service / MQTT broker.

[0119] The data center interacts bidirectionally with the backend service layer, storing simulation data, test logs, device status, and configuration rules; and provides persistent support for backend services, enabling data playback, rule reuse, and result statistics.

[0120] In one embodiment, a terminal device analog meter reading system based on a smart fusion terminal employs interface-oriented programming, a compact memory model, and a lock-free data structure design for its core data structure, balancing performance, scalability, and portability. The system features a unified communication interface structure, with all communication methods implementing a single interface, eliminating the need for upper layers to concern themselves with underlying details and facilitating the expansion of new communication types. Polymorphism is implemented through function pointers, achieving performance close to direct calls, and the C language offers strong portability. The system can adopt a protocol description model structure, parsing UPDL configuration files into binary memory structures to avoid repeated JSON parsing. Field index references replace pointers, facilitating serialization / deserialization and hot reloading. Simple verification algorithms use function pointers, while complex logic uses Lua scripts, balancing performance and flexibility. During fault injection, the system can utilize linked lists and hash indexes to balance traversal and fast querying; probabilistic judgment enables fine-grained anomaly control; parameter unions save memory and adapt to parameter requirements for different anomaly types. When creating a virtual device instance, a lightweight state object is used to store only core information, reducing memory usage; registers are stored through a Map to adapt to register differences in different protocols; communication channels, data rules, and exception rules are bound to enable personalized configuration of device behavior.

[0121] In one embodiment, an end-device simulated meter reading system based on a smart fusion terminal is provided. The system backend adopts an asynchronous event-driven framework and virtual threads based on Netty, combined with lock-free circular buffers and object pool technology to achieve zero-copy data exchange under high concurrency. It also supports managing virtual device instances as lightweight state objects, enabling a single server to simulate and support a massive number of devices.

[0122] In this embodiment, the system is developed with separate front-end and back-end. The back-end uses the Netty asynchronous event-driven framework and virtual threads to achieve high-concurrency processing, while the front-end provides visual monitoring and operation. Each layer is decoupled yet works collaboratively. The system employs lock-free concurrent programming and performance optimization techniques, including lock-free circular buffers, object pool pre-allocation, CPU core isolation and binding, batch data aggregation, and dynamic compressed transmission. This achieves zero-copy data exchange, avoids performance losses caused by lock contention and dynamic memory allocation, and significantly improves processing efficiency in high-concurrency scenarios.

[0123] Specifically, the system employs large-scale device high-concurrency simulation technology. The backend is based on the Netty Reactor model, which can manage thousands of TCP connections with a single thread. Each device instance is stored as a lightweight state object in a ConcurrentHashMap instead of occupying an independent thread, thus avoiding the overhead of thread context switching. Periodic reporting tasks are scheduled through Netty EventLoop and combined with object pool technology to pre-allocate objects such as packets and device instances, eliminating the latency and fragmentation caused by dynamic memory allocation. An 8-core 16G server can stably simulate more than 15,000 devices online simultaneously. Furthermore, the system uses a lock-free circular buffer to implement a producer-consumer model, completing zero-copy data exchange between data acquisition and protocol sending threads, avoiding performance jitter caused by lock contention.

[0124] The lock-free circular buffer structure is an abstract data structure designed based on the following principles: lock-free operation in a single producer-single consumer scenario, suitable for data transfer between serial port / network threads and protocol parsing threads; pre-allocation of fixed memory to avoid frequent dynamic allocation; and differentiation of empty / full states using `is_full` to improve space utilization. Object pool pre-allocation refers to the pre-allocation of a pool of object instances, packets, and buffers during the initialization phase, which are then directly acquired and reused at runtime, eliminating latency and fragmentation caused by dynamic memory allocation and improving data processing efficiency.

[0125] In one embodiment, an end-device analog meter reading system based on a smart fusion terminal is provided. The system adopts configuration-driven and hot-loading technology. It defines device parameters, protocol types, data generation rules, and exception injection rules through an external configuration file and monitors file changes to achieve the hot-loading function of dynamically adjusting all configurations without restarting or interrupting testing.

[0126] The configuration-driven and hot-loading technology utilizes YAML / JSON / XML to externalize all configurations, defining device types, protocol parameters (baud rate, parity check), register mapping tables, data generation rules, exception injection rules, and state transition diagrams. This is loaded at software startup without recompilation. Furthermore, it integrates hot-loading functionality, dynamically adjusting the number of devices, reporting intervals, data rules, and exception parameters by monitoring file changes or API triggers, without interrupting simulation and significantly improving testing efficiency. In this embodiment, the system employs configuration-driven and hot-loading technology, externalizing all configurations such as device, protocol, data generation, and exception injection through YAML / JSON / XML. It supports hot-loading of configuration files, and modifications to the configuration do not require software restarts or simulation interruptions, improving configuration iteration efficiency by more than 10 times.

[0127] In one embodiment, an end-device simulation meter reading system based on a smart fusion terminal is provided. For high-concurrency, high-real-time, and massive device simulation scenarios, it performs in-depth performance optimization from four dimensions: memory management, protocol stack processing, data generation, and network communication to ensure ultimate performance on ordinary hardware.

[0128] Specifically, in terms of memory management optimization, bit-field compression and compact structure design are adopted for virtual device instances, reducing the memory usage of a single instance to less than 64 bytes, significantly reducing the memory overhead of simulating massive numbers of devices; for point table data of tens of millions of devices, memory-mapped files (MMAP) are used for storage, enabling data sharing between multiple processes without the need for serialization / deserialization, and the access speed is close to that of memory operations; hot spot cache stores frequently changing telemetry data (voltage, current), and uses a lock-free data structure for updates; static cache stores device description files, and differential encoding compression is used to reduce memory usage.

[0129] In terms of protocol stack processing optimization, for high-frequency messages such as IEC61850 and GOOSE / SV, ASN.1 encoding and decoding codes are statically generated based on ICD files to avoid dynamic XML parsing at runtime, improving encoding and decoding efficiency by 5-10 times. The hierarchical state machines of IEC101 / 104 are merged into multi-dimensional state tables, and the next state and processing function are determined by table lookup, reducing branch prediction failures in nested if-else statements and improving parsing speed. For continuous remote signaling data, SIMD instructions (ARMNEON / x86SSE) are used to process multiple bytes of change flags at once to achieve parallel parsing. Hardware CRC check of the network card and DPDK technology are used to bypass the kernel protocol stack to achieve microsecond-level transmission of GOOSE / SV messages, meeting the ultra-high real-time requirements of power protection.

[0130] In terms of data generation optimization, direct digital frequency synthesis (DDS) technology is used to generate sine waves and pre-calculate load curve templates. Data is generated quickly at runtime using a lookup table method, avoiding the large amount of computation required for real-time calculation of sine functions and load curves. The Xorshift128+ algorithm is used to generate random numbers, which is several times faster than the native Java Random algorithm. Random number sequences are pre-generated and cached for noise superposition and anomaly simulation. For a large number of devices, virtual threads are used to generate data in parallel, with each thread responsible for generating data for one group of devices, making full use of CPU multi-core resources.

[0131] In network communication optimization, a lock-free circular buffer is used to implement the producer-consumer model, enabling zero-copy data exchange between data acquisition and protocol sending threads, thus avoiding performance jitter caused by lock contention. Multiple virtual device reporting data frames are merged into a single network packet for transmission, reducing TCP / IP protocol stack header overhead and improving network transmission efficiency. The LZ4 / Zstd lightweight compression algorithm is adaptively selected based on network quality to compress reported data in real time, reducing bandwidth consumption, and the compression / decompression time is negligible. At the operating system level, dedicated CPU cores are isolated, binding tasks with high real-time requirements (such as GOOSE / SV sending and protocol parsing) to these isolated cores to prevent other tasks from preempting resources and ensuring microsecond-level task scheduling accuracy.

[0132] In one embodiment, an experiment was conducted on a simulated meter reading system based on a smart fusion terminal. The experimental background was as follows: A provincial power company planned to upgrade its electricity consumption information collection system, requiring the smart fusion terminal to support access to tens of millions of meters, minute-level data collection, and compatibility with multiple protocols such as DL / T645-2007, 698.45, and Modbus. Before the new system went live, comprehensive performance testing and functional verification were required. If real meters and concentrators were used to build the test environment, thousands of devices would need to be purchased, costing tens of millions of yuan, and the process would take several months, which could not meet the project schedule. Therefore, the company adopted the simulated meter reading system based on a smart fusion terminal as described in this embodiment, constructing a large-scale virtual meter cluster in a laboratory environment to complete comprehensive testing.

[0133] In this embodiment, the experimental objectives are: to verify the performance of the master station: test the throughput, response time, and resource consumption of the master station when concurrently logging into 10 million virtual meters, periodically reporting data, and pushing real-time events; to verify protocol compatibility: confirm that the master station can correctly parse multiple meter protocols such as DL / T645-2007, 698.45, and Modbus, and process different data formats (frozen data, curve data, event logs); to verify business functions: including remote fee control (trip and reconnection), tiered electricity pricing calculation, abnormal electricity consumption detection (such as electricity theft, voltage loss), and automatic meter reading success rate statistics; to test disaster recovery and expansion capabilities: verify the automatic recovery and data replenishment mechanism of the master station in the event of partial service failures or network interruptions; and to train the operation and maintenance team: train operation and maintenance personnel in a simulated environment to master the operation procedures and troubleshooting methods of the new master station.

[0134] The experimental test environment setup included: Hardware deployment: Deploying 8 high-performance x86 servers as a simulator cluster (64-core CPU, 256GB memory, 10 Gigabit network card), installing the Windows Server operating system and this simulation software; setting up a test version of the intelligent converged terminal and simulation master station environment, including access front-end machine, business microservices, time-series database, message queue, connected to the simulator cluster via a 10 Gigabit switch; Network configuration: Simulating power wireless private network and fiber optic network, configuring parameters such as link bandwidth, latency, and packet loss rate; Software configuration: Front-end and back-end are deployed separately, with the back-end using a Docker containerized cluster, and the front-end deployed to the operation terminal of maintenance personnel to achieve remote monitoring and operation.

[0135] The virtual device modeling and configuration in the experiment mainly included: Batch modeling: Through the simulation software management interface, the file information (meter number, asset number, protocol type, user type, etc.) of 10 million virtual meters was generated in batches and exported as CSV files for one-time import; Protocol allocation: Protocol types were allocated according to 70% DL / T645-2007, 20% 698.45, and 10% Modbus, and corresponding data items (voltage, current, power consumption, demand, etc.) were configured; Data generation configuration: Corresponding power load models (residential / industrial / commercial) were configured for different user types, generating a 24-hour baseline load curve, superimposed with ±3% random fluctuations; Reporting frequency configuration: Data reporting was frozen at midnight every day, and real-time load data was reported every 15 minutes; Anomaly rule configuration: Multiple types of anomaly scenarios were preset, including voltage phase loss of 50,000 meters, current reverse of 10,000 meters, clock anomaly of 500 meters, 10% network packet loss, and 200ms network latency.

[0136] The test execution and results are as follows: Small-scale verification: 100,000 virtual meters were launched to verify the correctness of the converged terminal protocol parsing, with a 100% data reporting success rate, command response latency <50ms, and no data loss; High-concurrency performance test: The number of virtual meters was gradually increased to 10 million, and the converged terminal ran at full load for 48 hours. The CPU and memory usage of the converged terminal remained stable. The peak data reporting capacity at midnight each day reached 100,000+ meters per second, with an entry latency of <90 minutes, and no service crashes or memory leaks; Anomaly and fault tolerance test: Preset anomaly scenarios were triggered, and the converged terminal could accurately identify all anomalies and provide accurate alarms. 100% accuracy, with no missed or false alarms; 100% data retransmission success rate under 10% packet loss and 200ms latency conditions, capable of handling abnormal packets normally; Disaster recovery testing: Simulating 5 million electricity meters going online simultaneously, a 30-minute network interruption, and primary / backup database switching, the converged terminal can quickly handle login storms, complete full data retransmission after network recovery, with primary / backup switch service interruption time <30s and no data loss; Automated testing: Integrating test cases into the company's CI / CD pipeline enables automatic triggering of simulated tests after code submission, reducing defect discovery time by an average of 70% and improving testing efficiency by 80%.

[0137] The implementation results are as follows: This simulation system successfully replaced the real physical equipment, completed the full-dimensional testing of the new system, and provided a reliable test basis for the launch; compared with the traditional testing solution, it saved 150 million yuan in hardware procurement costs, shortened the testing cycle from 3 months to 2 weeks, and improved testing efficiency by more than 80%; at the same time, it provided a safe training environment for the operation and maintenance team, enabling operation and maintenance personnel to quickly become familiar with the new system and shortening the fault response time by 40%.

[0138] The end-device simulated meter reading system based on intelligent converged terminals provided in this application embodiment achieves full-service, high-concurrency, high-realism, high-flexibility, and automated testing of intelligent converged terminal meter reading through multi-dimensional technological innovation. Compared with existing technologies and traditional testing methods, it has significant technical effects and economic value, mainly including: greatly improving R&D testing efficiency and shortening project cycle; it can simultaneously simulate thousands of multi-protocol and multi-model devices, covering different test scenario combinations, and shortening regression testing time from several days to several hours; it can be integrated with CI / CD pipelines through Testcontainers, automatically launching smoke tests in the simulated environment with each code commit, shifting defect discovery time from the testing phase to the development phase, and shortening the development and testing cycle of a single project by more than 30%. Significantly reduces testing costs and achieves efficient resource utilization. One simulation software can replace tens of thousands of real-world devices, directly saving hardware procurement costs (e.g., simulating 10,000 industrial-grade sensors can save millions of yuan), reducing hardware costs by more than 90%. The simulation software is wear-free and requires no calibration, avoiding maintenance costs caused by the aging and damage of physical equipment, bringing maintenance costs close to zero. Automated simulation and regression testing reduce the manpower required for a single test from 3-5 person-days to 0.5 person-days, lowers the skill threshold for operation, and reduces reliance on senior engineers. Running on ordinary servers / virtual machines, no dedicated server room is required, and the power consumption of a single server simulating tens of thousands of devices is only a few hundred watts, reducing the total power consumption of real devices by more than 99%. The testing quality has been comprehensively improved, verifying the full-dimensional capabilities of the converged terminal and achieving end-to-end testing of the entire meter reading business process. This covers scenarios such as data collection, command issuance, anomaly handling, and data verification, increasing test comprehensiveness from 30% to over 95%. It supports simulation of hundreds of abnormal operating conditions at all levels, fully verifying the fault tolerance, anti-attack capabilities, and protocol robustness of the converged terminal, and proactively identifying vulnerabilities such as buffer overflows and authentication bypasses. Dynamic data consistent with actual electricity consumption patterns in the power industry is generated, significantly enhancing the reference value of test results and ensuring the converged terminal adapts to real-world business scenarios after deployment. Problem localization efficiency has been improved, and test observability has been enhanced. Two-way log correlation has been implemented, with both front-end real-time data and back-end logs containing a unified device ID and high-precision timestamps. Interaction records between the terminal and simulator can be quickly correlated via Grafana / ELK, reducing problem localization time by an average of 60%. A dynamic dashboard displays the real-time status of all devices, message traffic, and error rates, making anomalies immediately apparent without requiring individual device inspection. The test environment is securely isolated, avoiding risks to real systems. All offensive and boundary tests are conducted in a simulated environment. Even if the simulator crashes, it will not have any impact on real devices and production systems. The simulated data is completely fictitious and does not contain personal privacy or trade secrets, avoiding the risk of real data leakage. No data usage authorization is required, simplifying the test approval process.Supporting disaster recovery drills and operations and maintenance training, it enhances industry operational capabilities. It can instantly take thousands of simulated devices offline simultaneously, simulating scenarios such as large-scale device disconnection and network interruption, verifying the reconnection strategy, data retransmission mechanism, and automatic system recovery capabilities of converged terminals, and providing test basis for real disaster recovery. The simulated environment can be used for operations and maintenance team training, enabling them to become familiar with system operation and fault handling procedures in advance, shortening the real fault response time by more than 40%.

[0139] In one embodiment, such as Figure 6 As shown, a terminal device analog meter reading system based on an intelligent fusion terminal is provided, including the following steps:

[0140] Step 602: Establish multiple communication links with the intelligent converged terminal through the communication adaptation layer, and configure the link status;

[0141] Step 604: The protocol processing layer dynamically loads the communication protocol of the target device and establishes a protocol parsing channel;

[0142] Step 606: The virtual device layer creates virtual device instances in batches and assigns each instance an independent ID, protocol parameters, data generation rules, and state machine;

[0143] Step 608: The data intelligent generation verification layer generates simulated meter reading data that conforms to the power load characteristics for each of the virtual device instances, and attaches a verification code.

[0144] Step 610: The virtual device instance, according to the reporting policy, encapsulates the simulated data with verification code into a protocol frame through the protocol processing layer, and then sends it to the intelligent fusion terminal through the communication adaptation layer.

[0145] Step 612: The business orchestration and automated testing layer performs stress, anomaly, and full-process automated testing on the intelligent converged terminal by injecting faults and orchestrating business scenarios.

[0146] Step 614: After processing the data, the intelligent fusion terminal uploads it to the simulation master station, and the simulation master station completes the data consistency verification throughout the entire process by comparing the verification code.

[0147] Step 616: The business management layer performs real-time visual monitoring, log recording, and report generation of the testing process.

[0148] It should be understood that although the steps in the flowchart above are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart above may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0149] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A terminal device analog meter reading system based on an intelligent converged terminal, characterized in that, The system includes: The communication adaptation layer provides data transmission and reception interfaces for various transport layer protocols, establishes a physical communication link with the intelligent fusion terminal under test, and supports link state simulation. The protocol processing layer, connected to the communication adaptation layer, is used to dynamically load various communication protocols based on the protocol factory, and to perform frame parsing and encapsulation of the transmitted and received data according to the protocol description model. It also injects faults at the interception points of the protocol processing path to simulate communication and device anomalies. The virtual device layer, connected to the protocol processing layer, is used to dynamically create virtual device instances based on the physical communication link and maintain the running status of each virtual device instance. A data intelligent generation and verification layer, connected to the virtual device layer, is used to generate simulated data based on the industry load model and random distribution algorithm, and to perform full-process verification of the simulated data. The business orchestration and automated testing layer, connected to the virtual device layer and protocol processing layer, is used to orchestrate test tasks, collect key indicators during the test process, and generate visual test reports. The business management layer connects and interacts with all layers to provide visual management, monitoring, and configuration functions, enabling full-dimensional simulation testing of intelligent converged terminals.

2. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The communication adaptation layer is located at the bottom layer of the system and is used to provide a unified data transmission and reception interface to the upper layers, shielding the differences in the underlying links. This includes serial port adapters, TCP / UDP socket services, and MQTT / CoAP services. The communication adaptation layer uses the Netty framework to build asynchronous event-driven network communication services to simulate abnormal link layer states such as bandwidth limitations, network latency, packet loss, and out-of-order delivery.

3. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The protocol processing layer includes: The protocol factory module is used to dynamically load and manage various power industry communication protocols at runtime by parsing the configuration file of the protocol description model, and provides a general interface to support zero-code extension of custom protocols, achieving protocol independence and hot-plugging. The frame parsing and encapsulation module implements the unpacking and repacking of byte streams based on a finite state machine, and various verification algorithms are built into the frame parsing and encapsulation module. An exception injection engine injects faults at interception points in the protocol processing path to simulate protocol layer exceptions.

4. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The virtual device layer includes: The equipment factory module pre-allocates memory based on object pool technology and dynamically creates or destroys equipment instances in batches according to the equipment file configuration. The device state machine module is used to manage the state transitions of device instances between operating modes; The register management module is used to maintain device data items in key-value pairs. The data reporting strategy module supports periodic reporting, change reporting, and query response reporting, restoring the actual device behavior.

5. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The intelligent data generation verification layer includes: The power load model module generates dynamic data with actual electricity consumption time-series characteristics based on typical daily load curves. A multi-distribution random number generation module integrates various random distribution algorithms and is used to add noise to the dynamic data; The data verification module attaches a verification code when the simulated terminal generates data, and performs verification and comparison at each stage on the intelligent fusion terminal and the simulation master station. If there is any inconsistency, an alarm is triggered, thus realizing the integrity verification of the entire data process.

6. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The business orchestration and automated testing layer includes: The script orchestration module uses a scripting language to customize tests and calls the protocol processing layer and virtual device layer to automate the orchestration and scheduling of the test process. The test report generation module is used to collect key metrics during the testing process and generate visual test reports.

7. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The business management layer is used for device management, protocol management, visual monitoring, log management, and user permission management.

8. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The system backend adopts an asynchronous event-driven framework and virtual threads based on Netty, combined with lock-free circular buffers and object pool technology, to achieve zero-copy data exchange under high concurrency. It also supports managing virtual device instances as lightweight state objects, enabling a single server to simulate and support a massive number of devices.

9. The terminal device analog meter reading system based on an intelligent fusion terminal according to claim 1, characterized in that, The system employs configuration-driven and hot-reload technology. It defines device parameters, protocol types, data generation rules, and exception injection rules through an external configuration file and monitors file changes to achieve the hot-reload function that dynamically adjusts all configurations without restarting or interrupting testing.

10. A method for simulating meter reading using an end device based on a smart converged terminal, characterized in that, Applied to the system according to any one of claims 1-9, the method comprises: Multiple communication links with the intelligent converged terminal are established through the communication adaptation layer, and the link status is configured. The protocol processing layer dynamically loads the communication protocol of the target device and establishes a protocol parsing channel; The virtual device layer creates virtual device instances in batches and assigns each instance a unique ID, protocol parameters, data generation rules, and state machine. The data intelligent generation and verification layer generates simulated meter reading data that conforms to the characteristics of power load for each of the virtual device instances, and attaches a verification code; According to the reporting policy, the virtual device instance encapsulates the simulated data with verification code into a protocol frame through the protocol processing layer and then sends it to the intelligent fusion terminal through the communication adaptation layer. The business orchestration and automated testing layer performs stress, anomaly, and full-process automated testing on the intelligent converged terminal by injecting faults and orchestrating business scenarios. After processing the data, the intelligent fusion terminal uploads it to the simulation master station, which completes the data consistency verification throughout the entire process by comparing the check code. The business management team conducts real-time visual monitoring, log recording, and report generation of the testing process.

Images