Smart Meter Development Using Digital Twin Technology for Green Energy Distribution Optimization

: This study proposes a digital twin (DT) approach and technical framework for smart meters to solve potential implementation and development problems and adapt to the new energy revolution trend and increase smart grid network security. DT models were deployed in the cloud and edge using a smart meter DT demonstration system. This paper evaluates the DT system's communication performance in real-time smart grid application through three dimensions: remote application service for smart grid user side, P2P transaction on the user side, and user real-time request service. This study's container-based decision tree strategy for smart meters meets the smart grid's real-time communication requirements for user-side applications.


Introduction
Currently, the smart grid is undergoing continuous development, resulting in an expansion of its scope. Consequently, the project now encompasses a broader range of content and specific processes (Ferreira et al., 2023). In order to guarantee the caliber of smart grid development and underscore its modernization, intelligence, and informatization, it is imperative to employ pertinent scientific and technological advancements in the actual construction process and attain meticulous and precise construction. This has evolved into a fundamental prerequisite for such undertakings. The establishment of a dependable smart grid necessitates the completion of three distinct stages: planning, construction, and upkeep. The utilization of digital twin (DT) technology in specific smart grid construction projects has the potential to enhance the technical quality of the infrastructure, thereby facilitating its wider implementation and dissemination in practical settings.
The compromise of a smart grid by a network intrusion can result in significant damage to energy distribution. According to statistical data, the power grid attacks that occurred in the United States in 2009 and in Ukraine in 2015 resulted in the deprivation of electricity supply for more than 200,000 consumers. The security concerns of smart grids can be challenging to assess and gauge due to the utilization of numerous interactive devices and network communication protocols offered by various device manufacturers (Oughton et al., 2019;Case, 2016). The adequacy of general testing tools is limited to power grids that are uncomplicated in terms of spatial extent and structural complexity. Consequently, fulfilling the security assessment criteria of smart grids poses a challenge (Andrysiak et al., 2017). Consequently, it is imperative to establish a selfcontained framework architecture that meets the security evaluation requirements of intelligent power grids and integrate this framework as an intrinsic characteristic of interconnected devices.
The concept of DT was initially introduced in 2003 and has since undergone significant advancements, resulting in a simulation technology that seamlessly integrates various disciplines, physical quantities, scales, and probabilities through a process of continuous refinement (Niaz et al., 2021). According to reference (Niaz et al., 2022), DT exhibits compatibility with contemporary advanced technologies such as big data, network cloud, artificial intelligence, 5G, among others. The construction of a virtual body model in the digital realm, along with the establishment of a mapping correlation between the digital virtual body and the physical entity, is accomplished through the utilization of big data mining and processing techniques, ultimately resulting in the objective of achieving entity "mirroring" (Shoukat et al., 2022a). Despite the longstanding proposal of the concept of DT, its application and research achievements in various fields are not uniformly distributed. The application of DT technology has yielded noteworthy outcomes in various domains, including healthcare, aviation, and land exploration, as evidenced by sources (Haleem et al., 2023;Shoukat et al., 2022).
DT technology has potential value growth points in energy and power, and research over the previous two years has indicated a rising tendency (Zhang et al., 2020). Huang et al. (2021) address energy internet DT technology. The DT model supported ultra-high voltage AC/DC power grid second-level online analysis by Zhou et al. (Zhou et al., 2022). Song et al. (2020) created an inverter DT model using neural networks to track dynamic behavior. Francisco et al. (2020) benchmarked real-time energy management using smart city DT energy management.
Communication must be secure since power meter data is confidential. The smart meter also helps electricity suppliers and consumers connect (Abdalzaher et al., 2023). Peng et al. (2019) proposed "closed-loop feedback correction" to improve smart meter development productivity and quality. The suggested smart meter topology permits two forms of communication: between the physical meter and the container, and between the container and other components. The paper's main contributions are these: -We discuss smart meter fundamentals in container-based DT technology.
-Keys or other methods safeguard data flow from the physical meter to the container. Modern smart meters use encrypted connection to protect data in transit between the container and the system.
-This study deploys the container in the cloud or locally to improve smart meter P2P communication speed and efficiency.

Framework
We'll evaluate the structure's communication delay to see if it's practical in a smart grid. Table  1 lists the experiment's software and hardware.

Hardware Selection
The experiment tests the communication delay of this topology using the "single MCU + communication module" and no specific metering chip. We currently simulate power meter data using software data. Figure 1 shows MCU's STM32L431RCT6-based IoT development board, Little Bear Pie.

Figure 1. Cub Pie Development Board
In above section, we introduced four communication technologies, namely NB IoT, LoRa, Wi Fi and Wi SUN. In order to meet our assumptions about the application scenarios of smart meters, we need to implement longdistance communication and medium short distance communication respectively.
NB-IoT and Wi-Fi technology can network without gateway equipment for transit, making it convenient and fast. Thus, we use NB-IoT for long-distance communication and Wi-Fi for medium-and short-distance. Figure 2 shows Lexin ESP8266 with BC35-G NB IoT modules.

Figure 2. NB IoT Module and Wi-Fi Module
At the same time, there is also a desktop computer for developing containers and deploying containers in edge scenarios. The CPU is I7-7700K and the memory is 24 GB.

Software Design
Docker container: Docker builds our container. Alpine Linux is used as the base image for developing the C-language TCP/IP communication program, installing Mosquitto, which implements the message queuing telemetry transport (MQTT) protocol, and OpenLEADR, which implements OpenADR2.0.
Alpine Linux is used to build container images. Alpine Linux image volumes are just over 5M. Using it as a container's base image can lower its capacity, reducing storage space and easing network distribution and propagation.
The container communicates with application servers, intelligent devices, and other containers using a C-language TCP/IP program. MQTT is a lightweight TCP/IP-based publish/subscribe protocol. MQTT provides dependable, real-time communication services for resourceconstrained devices with little code and low resource use. Figure 3 depicts MQTT protocol workflow. When subscribers subscribe to topics of interest in the agent and the publisher publishes messages to the agent, the agent sends the topic information to all subscribers in turn to complete a message subscription and publication.

Admin
Agent Subscriber Connection Agent Topic (/home/price) Connection confirmation

Figure 3. MQTT Subscription and Publishing Process
Python module OpenLEADR completely implements OpenADR2.0b. This module simplifies container node VTN or VEN implementation. Upload the Docker image to Alibaba Cloud's container image service.
Little Bear Pie Development Board: Because the Xiaoxiong development board uses STM32R431RC as the master MCU, we use STM32CubeMX and Keil uVision5 for software development. In order to achieve multi-function concurrent operation and reduce the difficulty of development, Huawei LiteOS is used as the realtime operating system (RTOS) control program to run. On the development board, the NB-IoT module and Wi-Fi module are used to realize the communication program with the container through the MQTT protocol. Send the control attention (AT) through the serial port (UART) of the MCU to communicate with the NB IoT module and the Wi-Fi module. The program flow when using the two modules for experiments is shown in Figure 4.
Smart grid remote application service scenario: In the smart meter application, the communication between the smart meter and the application server is very frequent. In order to test the delay of the smart meter structure proposed by us on the communication between the smart meter and the application server, we designed a scenario as shown in Figure 5. As shown in the figure, t1 represents the communication delay between existing smart meters and application servers, and t1 ′ represents the communication delay between smart meters and application servers in our smart meter structure.  Existing structure Proposed structure

Figure 6. Peer-To-Peer Transaction Scenario on the User Side of Smart Grid
Smart grid user-side real-time service request scenario: smart meters should respond to the needs of users. In order to test the delay of the ondemand response of our proposed smart meter structure (for example, users use mobile applications to request data from a smart meter ), we propose this scenario . In this scenario, consider two situations: (1) The required data exists and is available in the container, and the container can return data directly.
(2) If the required data is not in the container or the data in the container is unavailable, the container will request data from the physical electricity meter, take the data to the container for saving, and then return the data.
The above two cases are respectively represented by t5 and t5 ′ representative. However, existing smart meters can only read data from physical meters t5 ′′ representative. The common settings of the above three experimental scenarios are summarized as follows: 1) The smart meter application server is deployed on the cloud platform, which is about 120 km away from the physical meter.
2) In the three scenarios we propose, containers are deployed on cloud platforms and edge systems, respectively.
3) The cloud platform server in another location is used to simulate the smart devices (such as mobile phones, computers, etc.) used by users.
The server is about 500 kilometers away from the physical electricity meter and 660 kilometers away from the application server.
4) The container uses the TCP/IP protocol when communicating with application servers, users' intelligent devices, and other containers, and the MQTT protocol when communicating with physical meters. In both cases, the limited load of each communication is set to 512 bytes. 5) Each experiment scenario runs for 24 hours, and the communication interval of each round is set to 1 minute.

Results and Discussion
We tested the communication delay t3 between containers and physical meters in different deployment situations and the communication delay t4 between containers in different deployment situations, as shown in Figures 7 and  8, respectively. This was done in order to better explain why the smart meter structure that we proposed can reduce the time required for P2P communication.

Figure 7. Possibility of Communication Delay Time Between Physical Electricity Meter and Container
Figure 7 demonstrates that the communication delay between containers that are deployed in the cloud and physical meters ranges from 0.4 to 0.8 seconds, whereas the communication delay that exists between containers that are deployed in the edge system and physical meters ranges from 60 to 140 milliseconds. Figure 8 demonstrates that the communication delay between containers located within the same urban cluster is less than 2.6 milliseconds, that the communication delay between containers located within separate urban clusters is less than 4.8 milliseconds, and that the communication delay between containers located within the same edge system is less than 0.6 milliseconds. Figure 6 demonstrates that the majority of P2P interactions are carried out between designated containers when utilizing our smart meter structure, in contrast to the current smart meter structure, which requires smart meters to take part in each and every P2P communication. Therefore, the smart meter that uses this structure for P2P communication is far faster than the structure that is currently used by smart meters.

Conclusion
This article introduces the container-based smart meter digital twin. The experimental platform and its software and hardware components follow. Using the software and hardware components, an experimental platform was created to evaluate smart meter communication delay in cloud and edge systems. The smart grid remote application service, user-side P2P transaction, and real-time request service scenarios were chosen for actual implementation. The suggested smart meter design was evaluated for communication delay in three experimental scenarios. Containers placed in the cloud and physical meters communicate in 0.4 to 0.8 seconds, while edge system containers communicate in 60 to 140 milliseconds. This study's smart meter framework meets smart meter implementation requirements.

Acknowledgement
The author(s) wish to acknowledge Dr. Muhammad Usman Shoukat (Hubei Key Laboratory of Advanced Technology for Automotive Components, Wuhan University of