Automatic Generation of Charging Point's Digital Twin for Virtual Commissioning of Their Automation Systems

The wide propagation of electric vehicle (EV) charging infrastructure integrated into the energy distribution network poses numerous challenges for the engineering and control of the latter: the load dynamic characteristics become more unsteady, requiring more advanced control, predictions, and virtual commissioning. One step toward the automation of the design and simulation of new charging stations can be reached through the integration of the EV-specific standards and protocols with other widely spread electrical standards and, thereby, improving the compatibility between standards, increasing the reuse of the intelligent work results, and promoting the development of EVs’ infrastructure. A method for virtual commissioning of electrical charging stations is proposed, implemented, and tested in a form of a software tool in which the electrical system description from the widely used IEC 61850 standard is used as an input. The designed tool builds a digital twin of the charging station that consists of its Simulink model as well as two automatically generated communication code primitives using the open charge point protocol for control and management purposes over the autogenerated model. The generated digital twin can be used for virtual commissioning purposes. The application of the method is illustrated in a case study.


I. INTRODUCTION
As it is stated in [1], the European Commission's original proposal for an alternative fuels infrastructure directive (AFID) approved a plan for a total of 800 000 charging points (CPs) in EU countries by 2020. The wide propagation of electric vehicle (EV) charging infrastructure integrated into the energy distribution network poses numerous challenges for the engineering and control of the latter: the load dynamic characteristics become more unsteady, requiring more advanced control, predictions, and virtual commissioning. First, the EVs charging time factor today is one of the biggest obstacles that hold the EVs production level [2], [3]. Even with an average range of EVs' driving distance of about 200 miles (one charge/discharge cycle), it is still not enough to convince potential customers to use EVs instead of vehicles with the traditional combustion engines. Additionally, the AFID proposal specified only a "ratio of one publicly accessible CP for every ten EVs" but without any requirements "to take account of geographical distribution, population density, or network coverage." This leads to a situation with a surplus and deficit of charging stations (CSs) on the roadways. Second, with the growing number of EVs, their charging may have a negative impact on the power grid due to the high demand in the fast-charging profile of CSs, which makes the problem of electrical grid peaks shaving even more severe [4], [5]. Third, one of the modern approaches to charging EVs-swap CS-gains popularity due to the shortest time of charging (battery replacement takes about 5-6 min). If the number of the swap CS will continue to grow, they can be considered the Energy Market player that, contrary to the second problem, can help to shave a peak consumption. But due to its relative novelty, the impact of the swap systems is yet to be thoroughly estimated and simulated [6]. The mentioned developments are achieved with a high degree of automation, which raises the challenge of their commissioning and impact assessment.
Digital twin (DT) [7] is a novel concept born in the Industry 4.0 domain combining static and dynamic models of automated systems. In particular, DTs are used for the online simulation of complex automated plants and their virtual commissioning [8]. As the EV charging infrastructure is a complex distributed automation system on its own, and it needs to be tightly integrated with the evolving power grid, its testing and virtual commissioning are very important tasks. For this study, the term DT refers to the multilayered structure, as depicted in Fig. 1. The bottom layer is the static machine-readable information about the EV charging infrastructure integrated into the grid. The middle layer is the simulation model of the EV charging system integrated with the simulation model of the rest of the grid. The top layer is the distributed control software for the EV charging system. As can be seen from Fig. 1, the digital model under study consists of different layers, each of which is uniquely specific and refers to a certain field (for example, the top layer is informational, and the middle layer is a signal's and measurement's processing and simulation). In this work, the authors are aiming at the problem of digital model designing, where the automatic generation of various layers of the model is carried out using the IEC 61850 standard [9]. The proposed solution is novel. Therefore, an analysis of the solution results is given at the end of this article, and the advantages/disadvantages are discussed.
In particular, this article investigates the engineering process ruled by the IEC 61850 standard with the specific open charge point protocol (OCPP) [10] for communication between EV CS and EV. The idea is to use the engineering data of the energy distribution network (including the EV charging network) in form of IEC 61850 standard-compliant machine-readable documents to generate the physical and communication models of the CS ready for virtual commissioning. This aims at flexible and easy-to-use models of electrical systems. Toward this end, the transformation rules and instructions for the automatic generation of the CS DT system will be presented. The designed rules use the IEC 61850 system configuration design (SCD) file for the automatic generation of a CS model (MATLAB/Simulink) and management system (that consists of two software applications (in Python language) for the central management system (CMS) and CP, respectively). The source code of the designed application is publicly available 1 .
The contributions of this article are as follows. 1) Developing an automated method of creating DTs of automated EV charging infrastructure for the purpose of its virtual commissioning, which includes the following: a) design of the transformation rules for the generation of a simulation model based on the IEC 61850 electrical system specification; b) enabling OCPP capabilities into the Simulink modeling as an important part of the control system over the EV CS; c) prototyping of the software tool proving the developed autogeneration method. 2) Increasing the interoperability between IEC 61850 standard-compliant systems and EV CSs by investigating and defining the common points between the aforementioned. The rest of this article is organized as follows. In Section II, an overview of related works is given. Section III describes the use-case definition. Section IV briefly covers the details of the technologies used and depicts the flowchart of the work. In Section V, the background information is presented. In Section VI, the transformational templates, integrated into a designed software tool, the designed transformation rules, and the generation workflow are represented. Section VII represents the result of the autogeneration discussed in the case study of Section III. Finally, Section VIII concludes this article.

II. RELATED WORK
A structured (systematic) review was implemented within the scope of this work. A short survey of related works has been implemented in the IEEE Xplore database. The reason for choosing this database was that the IEEE is the world's best-known standardization and standards organization. In addition, the authors found it very convenient and efficient to use the IEEE Xplore website search engine. The search template (1) has been considered for investigation WHAT AND RELATES AND TO WHAT (1) where the keyword "WHAT" was assigned with values "EV," OR "electrical vehicle," OR "CS." The "RELATES" had the values of "charging," OR "modeling," OR "management." The keyword "TO WHAT" was assigned to the communication protocols' and standards' names, which are related to the electrical system and electrical batteries' system management. As a result, template (2) was used, where "OR" is the inclusion criteria (increasing the number of similar works in the result) and "AND" is the exclusion criteria (decreasing the number of similar works in the result). From template (2), it is easy to see that the issue of EV management was considered the most important, where the problem of designing and modeling new CSs was examined in terms of the help of other standards related to electricity (for example, IEC 61851 for EVs and IEC 61970, IEC 63110, and OCPP for CSs). The key point of the study is that IEC 61850 can be used as a bridge between different standards to facilitate the design process of a new EV charging infrastructure. Thus, the research roadmap that formed the basis of the research is presented in the form of a mental map and is shown in Fig. 2 electricalvehicle OR EV OR chargingstation AND charging OR modeling OR management AND IEC61850 OR OCPP OR IEC61851 OR IEC61970 OR IEC61968 OR IEC63110 .
(2) Among the query results, only conference and journal papers were included in the scope of interest. Also, only publications during the last ten years were considered. As a result, 56 related works were identified, the most important of which are discussed in this section.
IEC 61850 is a multifacet standard, comprehensively covering engineering aspects of digital energy distribution systems from communication interoperability to high-level object-oriented architecture and the corresponding information models. Higgins et al. [11] have proposed the engineering process bridging the IEC 61850 model with object-oriented and decentralized executable automation architecture, aiming at reducing engineering and re-engineering efforts, especially related to software.
These ideas were further evolved by Andren et al. who presented the data transformational principles from the IEC 61850 design of the electrical system into the IEC 61499 control system [12]. They analyzed both IEC 61850 and IEC 61499 models of data representation and designed the transformation rules from one standard to another. They presented a model-driven engineering approach for the design and development of smart grid automation applications practically implemented in a tool for automatic generation and deployment of control applications based on IEC 61850 descriptions.
A step toward the integration of IEC 61850 into the EV charging system was made by Ustun et al., who proposed a model for EVs by extending IEC 61850 standard and its extension for distributed energy sources (DERs), i.e., IEC 61850-7-420. Essentially, what is proposed is an information model for the charge/discharge controller of an EV [13].
Integration of IEC 61850 with OCPP was done by Schmutzler et al. [14]. In that work, the authors emphasize the lack of the grid-oriented semantic structure of the OCPP protocol in the EV managing area. As a result, they proposed the IEC 61850 standard as one of the ways to overcome this shortcoming.
Xiong et al. present the method of IEC 61850 standard extension with smart EV scheduling algorithms [15]. The abstract data model, supporting web service, and an interface for the smart charging infrastructure are created and tested in this article. Smart charging data and additional features are standardized into substation configuration language (SCL) configuration files, making them instantly available to any smart grid device or application. As the authors state, this article not only expands the scope of the IEC 61850 standard in the field of smart charging but also significantly increases the scalability and interoperability of the smart charging infrastructure.
Together with the development of the DTs and with an understanding of the potential powerfulness of such tools, a new approach of IEC 61850 based communication modeling of EV charge-discharge management for maximum photovoltaics (PV) generation was made by Ustun et al. [16]. To boost PV generation, this article proposes a communication infrastructure for a smart EV charge-discharge algorithm. This scheme's components are completely modeled by the IEC 61850 communication standard. Given the variety of EV, PV, and smart meter manufacturers and models, this is critical for the effective deployment of such automation schemes.
Finally, in 2020, Aftab et al. [17] promoted the ideas of the work of Ustun [16] even further, considering the carbon footprint and damping the negative effect of EVs influence on the main utility grid while their charging to achieve higher efficiency of renewable energy sources participating in supporting the global balance in the Energy Market. They highlight the fact that technology-agnostic common communication is required to handle all EVs with various chargers.
It is also worth mentioning that the IEC 61850 is not the only standard used in electrical systems' automation. IEC 61970-301 and IEC 61968-11 are collectively known as the common information model (CIM) for power systems and focus on the needs of electricity transmission, energy management systems, SCADA, planning, and optimization. Although CIM is not fully compatible with the IEC 61850 specification on the electrical system, Lee et al. [18] proposed a solution for unifying these instruments.
IEC 63110 is a standard developed by the JWG11 of IEC Technical Committee TC69. Initiated by France, Germany, and Italy and started in November 2017 is another booming standard in the electrical field [19]. The IEC 63110 standard represents a competitor communication protocol technology to OCPP. The protocols are similar, but there are much more open-source OCPP implementations and openly available applications [20] available, while none of IEC 63110 were found which explains the authors' preference of OCPP.
Nevertheless, the need of having tools and automation solutions for modeling and testing the EVs charging infrastructures is gaining popularity together with stable growth in "green" cars. As a reaction on that need, Morab et al. [21] propose the model of a 22 kW charging unit and EVs battery management system using IEC 61851-1 protocol that specifies the information exchange between CP and EV. Additionally, the fact of IEC 61850 usability in modeling battery-related electric systems was proved by Ustun and Hussain [22], where the model of DERs was designed, and the developed IEC 61850 information model was utilized as the communication mechanism for realizing power management inside the model.
In summary, the conducted short survey shows clear signs of the growing use of the IEC 61850 standard for engineering the EV charging infrastructure automation. Some examples of the integration of EVs into the global energy grid already exist in the form of mobile or server applications. Photovoltaic systems and the global energy market are considered important components in the future development of EVs. All this indicates a high level of interest in integrating EVs into the global energy system. A gap, however, is identified between the IEC 61850-based engineering process of the grid infrastructure and the engineering of EV charging infrastructure that is dominated by the OCPP standard. At the time of this study, no papers were found that would have carried out theoretical/practical research on facilitating the creation of a DT model using the IEC 61850 standard. Therefore, the authors will fill this gap by proposing a new method that can be considered the first step toward solving these problems. At the same time, it should be noted that (since it is the first step) the main goal of the current research is the fact of successful automatic construction of a DT model and not the accuracy of the model itself. But it does not mean that the question of the model's accuracy is not important and is declined by the authors. It will be considered at another stage of this study and will be presented in another article.

A. SCENARIO
Let us consider a basic building block of the EV charging infrastructure: one CP with three charging outputs, connected  with a charging management station. The CP may be located in a parking lot of an office or factory, so the full charge of EVs must be guaranteed before the working day ends. During winter days, the outside temperature may be below −20°l evel, so it is also needed to preheat the cars. The requirements are presented in Table 1. The electric schema of the system is shown in Fig. 3.
The electrical scheme, as presented in Fig. 3, consists of one main electrical source "VTR0" of ac type (alternate current), one main current sensor "CT10," and three branches. Each branch consists of ac/dc converter "D1x" and the current breakers "CB1x" and "CAB1x" representing power losses in the cable from CP to EV. Furthermore, in this article, the DT will be presented that is designed to meet the requirements.
The use case aims at answering the following questions. 1) HOW MANY vehicles will be serviced at the same time (what is the maximum capacity of the system)? 2) WHEN and HOW LONG they will be charged? 3) WHAT ASPECTS influence the CS performance and how? All these questions correspond to the real requirements for CSs for EVs. Thus, similar questions were addressed by Csiszár [23] to calculate the appropriate geographical location and deployment conditions for a future CS. The purpose of the study was to develop a method for calculating the need for charging EVs and to determine the principles for the placement of public charging infrastructure. Therefore, the purpose of the study presented by Csiszár is more related to the field of EV management when the objectives of the current study are purely technical. However, due to the identity of the object under study (EVs), the main tasks and, therefore, the questions that arise are also similar.

IV. PROPOSED ENGINEERING FRAMEWORK
The suggested engineering framework's goal is to automate the development and validation of distributed automation logic for CSs, facilitated by the automatically generated simulation model. The results of this study are displayed in the form of the "autogeneration tool," as presented in Fig. 4, which takes an SCD file (the electrical system description) as an input and generates a simulation model of a CS as well as a communication tool (server/client) (presented in Fig. 4 as "Electrical Model of the CP," "CMS application," and "CP application," respectively). As a result, these three modules constitute the DT of CS, which is useful for obtaining physical characteristics (current, voltage, etc.) as well as for the virtual commissioning of its distributed automation, including communication between CMS and CP.
The qualitative methodology of the proposed approach was designed in two steps.
1) Data collection: The procedure begins with design documentation in the form of an "SCD" diagram and is subdivided into two steps. a) Participant observation: Includes the CSs major equipment and their consistency with the IEC 61850 standard (see Fig. 3). b) Recursivity: The design under study can be changed during the data collection phase (it is not prohibited to adjust the initial "SCD" diagram). 2) Data analysis: Recognition of patterns of the designed "SCD" file. This step is represented in three steps. a) Coding: This step is already implemented in the IEC 61850 standard since all abstractions under the study are associated with specific words/labels (more information about it will be presented in Section V-A). b) Pattern thematic analysis: Transformation of coded words to structured data (fitting the data) and generation of a pattern (will be explained in Section VI). c) Content analysis: Generation of a stack of patterns. Analysis of the resulting stack of patterns, generation of the corresponding model, and its validation against the initial "SCD" file (will be explained in Section VII). all the substation's configured data in a standardized format. 5) A catalog of logical objects: All IEC 61850 standardcompliant devices utilize the same namespaces of objects and functions, making it possible to integrate objects in a data center power implementation. According to the engineering process implied by IEC 61850, there are two types of configuration tools required: "system configuration tool" and "intelligent electronic device (IED) configuration tool," as shown in Fig. 5. The structure of the electrical system and the required functions (logical nodes) are described in system configuration files (SSD and SCD) when the precise IED models that perform these functions are included in IED configuration files (IID, ICD, SCD, and CID). System configuration tools (exemplified by "Helinks" [24] in this article) include graphical editors for composing systems from objects and storing the descriptions in form of SSD and SCD configuration files.

V. BACKGROUND
IEC 61850-6 defines five types of files for working with SCL files: SSD, ICD, SCD, CID, and IID. Here is the definition of some of them.
SSD-System Specification Description: This file outlines the topology of the automated electrical system as well as the required functions (logical nodes), but it does not include the exact IED models that perform these functions.
SCD-Substation Configuration Description: A file containing the system's whole configuration, including the information model of the physical equipment chosen, network settings, data flows, etc. An SCD file is made up of a ".ssd" file and several ".icd" files.
The SCL of the IEC 61850 provides unique characteristics and attributes for the definition of connections between independent components, just as a physical representation of any piece. The keyword "Terminal," for example, defines a physical connection (where the tag "connectivityNode" is the name of that connection), which is used to specify a destination port. Fig. 6(a) depicts the physical connection of two circuit breaker components. Fig. 6(b) is represented in the same scheme but SCL. As can be seen from Fig. 6(b), every new element has its parameters, such as "name" and "type" in a "ConductingEquipment" node. It also features a "Terminal" subnode that contains further information about component connections. Every IEC 61850 object, as shown in Fig. 6(b), does not have a tag identification of port direction (input/output), but only a connection name (for example "MFS/J/01/L1" in Fig. 6(b)).
An advantage of the IEC 61850 standard is that it has a strongly defined catalog of names for logical objects. It means that by knowing the name of the IEC 61850 element, it is possible to establish accurately its type, functions, parameters,  and properties. This feature makes IEC 61850 attractive for an automatic generation of DT types of system. For example, a charging process of an EV (Fig. 7, top part) from the IEC 61850 point of view can be described, as shown in Fig. 7 (bottom part).
In Table 2, some of the IEC 61850 "blocks" that can be used for the design of the CS electrical system are given.

B. OCPP
OCPP is an application-level protocol for communication between an EV, CP, and a CMS, often known as a CS network. The Open Charge Alliance (OCA) created OCPP in 2009 as a free, open-source, and simple-to-implement protocol. As capabilities to existing chargers by plugging them in. In OCPP 2.0.1 new features, enhanced security, tariff, and cost display, operator monitoring, and so on have been added. According to the OCPP protocol, every charging process (transaction between CP and EV) can be divided into five steps (see Fig. 8). The transaction starts when a new car is detected at the CS. The "energy offer" period starts when one is logged in to the CSs system through any authorization type that is described in the OCPP standard (login/password, NFS card, direct purchase through the credit card, etc.). The "energy flow" can be interrupted and continued again after some short period (specified uniquely for each CS by its vendor/owner) or interrupted at all.
An open-source OCPP implementation is provided by OCA-a global consortium of public and private EV infrastructure. It has both client (CP) and server (CMS) parts.

C. MATLAB/SIMULINK MODEL
In this work, MATLAB/Simulink is used to create a simulation model of the CP. This simulation model is generated in two steps, namely.
1) The "autogeneration tool" (see Fig. 4) generates a MAT-LAB script of the future model (the exact algorithm will be discussed in the "IEC 61850-MATLAB/Simulink transformation template" subsection C of Section VI). 2) MATLAB script transformation to the actual SIMU-LINK model (implemented by inherent MATLAB functionality).

VI. MODELING NOMENCLATURE, GENERATION FLOW, AND TRANSFORMATION STEPS DESCRIPTION
According to the structure of the proposed engineering framework (see Fig. 4), the DT model of the CP system consists of three parts: 1) OCPP server (CMS application); 2) OCPP clients (CP application); 3) Simulink model of CPs electrical equipment (electrical model of the CP). The communication protocol between CMS and CP is the transmission control protocol (TCP)-based WebSocket. It is already integrated into the open-source code of the OCPP client-server application, implemented in Python. Communication between the CP and the Simulink model is implemented through MATLAB's "matlab.engine" functionality (also written in Python).

A. GENERATION FLOW (IEC 61850 -OCPP)
As mentioned in Section IV, the attractive advantage of the IEC 61850 standard is a catalog of logical objects, associated with the electrical objects. The autogeneration aims at the creation of Python scripts for the CMS and CP sides of the distributed control application.
As it is represented in Fig. 7, the CS can be represented as several IEC 61850 objects (or logical nodes) interconnected with each other according to the electrical system's scheme. At the same time, the OCPP protocol consists of several instructions that can be assigned to every specific IEC 61850 object. Therefore, in terms of the object-oriented approach, every IEC 61850 object can be represented as a "class," where OCPP instructions are the "functions." Practically, it is possible to assign all OCPP instructions to all IEC 61850 objects, but it would not make sense because not all instructions are logically inherited by the IEC 61850 object. For example, for the "XCBR" object of IEC 61850 (switch), it would be natural to assign some "set" and "get" functions (or "SetVariables-Payload" and "GetVariablesPayload," as it is stated in OCPP protocol) to set and get the current state of the switch.
Based on that information, the authors designed a "transformation table" that works as a "bridge" between specific IEC 61850 logical nodes and specific OCPP instructions. Thanks to the strictly specified names of logical nodes in IEC 61850, they can be uniquely defined. For brevity, only the transformation of some IEC 61850 logical nodes is demonstrated in Fig. 9.

B. GENERATION FLOW (IEC 61850 -MATLAB)
Another part of the DT generation is related to the creation of the MATLAB/Simulink model. For each IEC 61850 object, the corresponding MATLAB/Simulink object is picked up from the existing Simulink library (the rightmost column, as shown in Table 3). The content of Table 3 is represented in the "autogeneration tool" (presented in Fig. 4) in a form of a transformation table (in the same manner as it is implemented for the OCPP transformation).

C. TRANSFORMATION STEPS (IEC 61850 -MATLAB)
The transformation procedure for a MATLAB/Simulink model generation consists of the following steps. 1) Read an ".SCD" file and create an array of IEC 61850 objects (see Table 2) with specified properties (see Fig. 6(b)). 2) Transform the array of IEC 61850 objects (obtained from the previous step) into Simulink objects (according to Table 3). 3) Create a new (blank) MATLAB model. 4) Place transformed Simulink objects from step 2 in the newly created model from step 3. MATLAB script is used for that. 5) Create connections between Simulink objects in the new model according to the "SCD" file. This process is based on the work with the IEC 61850 objects stack (or array) obtained from step 1. The array analysis occurs by the FIFO principle (first in-first out). The pseudocode of the IEC 61850 stack analysis is presented in Fig. 10. Here, the "accum_array" object initialized in line 5 represents the list of all objects that have similar connections. The algorithm compares one-byone elements in the IEC 61850 array (lines 6-14) and   fulfills the "accum_array" with new IEC 61850 objects (line 11). After the end of each "round" in the analysis, all detected similar connections of IEC 61850 should be cleared to prevent the infinity loop (line 15). The resulted "accum_array" (see Fig. 11(a)) represents a source for the building of Simulink connections (line 15 in Fig. 10), where the structure of connections is represented in a form of a "star" with one central object and several beams around it (see Fig. 11(b)). The first object in the list is always the center.
Because every IEC 61850 object (or logical node) can have N ≥ 0 number of connections, then the same object may be presented in the resulted "accum_array" stack several times. Let us imagine the result during another "round" of IEC 61850 stack analysis, as presented in Fig. 12(a), then the resulted connection's scheme for Simulink objects is presented in Fig. 12(b).
One of the issues with converting IEC 61850 objects into MATLAB/Simulink objects is the lack of apparent identification of IEC 61850 object connections, which MAT-LAB/Simulink objects have. As a result, the following rules were created to convert an IEC 61850 object into a MAT-LAB/Simulink object (see Table 4).
When the analysis of IEC 61850 objects is over, then the resulted schematic representation is saved in form of a MATLAB script (line 16 in Fig. 10).

D. TRANSFORMATION STEPS (IEC 61850 -OCPP)
The approach for autogeneration of the CP and CMS scripts is easier than in the case of the Simulink script because there is no need to worry about interconnections between the objects.  As such, only OCPP instructions analysis among all IEC 61850 objects is needed (presented as "OCPP properties" in Fig. 9). The schematic representation of that idea, where the IEC 61850 stack is presented only from two objects ("XCBR" and "TVTR"), is presented in Fig. 13.
When the list of unique OCPP instructions is defined, it is saved in two separate files (one for the future CP application and another for the CMS).

A. DESIGN OF THE PROGRAMMING TOOL
To implement the generation based on the principles presented in this article, a software tool was developed. The tool is written in C# and runs under the Windows operating system. The tool's interface is shown in Fig. 14. It has three windows for a preview of generated results (from left to right): XML structure of the uploaded SCD file of IEC 61850, generated MATLAB script of the electrical model of the CS, and generated script for CMS/CP applications. The interface of the designed application is simple and intuitively understandable.

B. TESTING AND RESULTS
An electrical scheme of a CS in IEC 61850 (see Fig. 3) was taken as an example for a demonstration of the results, which was used as input data for the designed application. The authors would like to again highlight that the proposed electrical system under investigation is taken for demonstration purposes only. It is very simplified and cannot be applied directly to some real-life hardware. The electric schema of the system is shown in Fig. 3 and has been created in Helinks environment and the SCD file, which is needed for the initial transformation process that has been generated. A video with a detailed description of the autogeneration process is available on YouTube 2 . The resulting MATLAB/Simulink model, generated from the scheme, is presented in Fig. 15.
To test the autogenerated CMS and CP scripts and validate the OCPP communication channel, the following scenario over the autogenerated model has been chosen (the battery and charger properties are not relevant in this test and can be chosen arbitrarily). 1) From time 0-5 s, the battery was discharging (EV is connected to CP but the charging process had been not yet initiated). 2) At the time of 5 s, CMS sends to CP the "set_variable" request through the OCPP protocol to change the status of the "CB10" switch from "open" to "close." 3) After that the CP receives the "set_variable" request and the MATLAB command on changing of "Initial-State" property of the "CB10" Simulink object will be executed.
2.https://www.youtube.com/watch?v=mNwVgZl6sdM In scope of this work, the authors have made two nonrealtime experiments (on a PC), where two modes of the CSs work (under +25 and −25°C) were simulated. To get the simulation results from these two experiments, we spend around 15 min (5 min and 10 min long). However, in case of a real-time experiment, the authors would need to spend around 15 h to get the same dataset. Since the time difference between the real-time experiment and nonreal-time experiment is relatively high (60 times), this factor can be considered as the advantage of the nonreal-time approach.
The resulted battery voltage curve in this experiment is shown in Fig. 16. The fact of successful switch "CB10" activation in the Simulink model through the OCPP command is proving the correctness of the autogenerated system.
To test the autogenerated Simulink script, it is important to recall the initial demands, defined at the beginning of the work (see Table 1). For that test, the charger model "PRIMAX P4500F-3-125-ka" and the battery with the parameters (125 V, 50 A * h) have been chosen. The test simulation over the autogenerated model was running and the results are presented in Table 5.
As for intermediate technical conclusion made only on the results, as presented in Table 5, it is possible to say that PRIMAX P4500F-3-125-10 can charge only one car with the battery capacity of around 6250 VA * h and only during the time when temperature is around +20°C. During the winter, the charging efficiency of the CP drops down at  approx. 60% of its initial charging power. As a result, the charger model "PRIMAX P4500F-3-125-10" cannot satisfy the demand and, subsequently, cannot be used-another more powerful charger is needed.
Before debriefing, the proposed approach is compared with the existing solutions (see Table 6) to emphasize the value of ongoing work. As can be seen from Table 6, only the current research results confirm the possibility of converting the IEC 61850 electrical system model into a MATLAB model. This fact distinguishes the present study from other works.
Summarizing the results presented in Section VII, it is worth recalling that the original purpose of this study was to demonstrate the IEC 61850 standard as the starting material for creating a DT model of an electrical system. As highlighted in Section II, there is a gap in current research on the IEC 61850 standard and its benefits in facilitating the creation of a DT model. Thus, the authors paid more attention to the conversion of data from one format to another, rather than the accuracy of the resulting DT model. Further plans to achieve convincing accuracy of the automatically generated DT model will be explained in Section VIII (last paragraph).

VIII. CONCLUSION
In this work, the transformation approach of the IEC 61850 SCD file of the CS into the OCPP-based Python applications (client/server) and MATLAB/Simulink physical model was presented. These rules were integrated into the code (programming language C#) of the designed application. The designed application is publicly available on the Internet.
Enterprises involved in the maintenance and building of new CSs for EVs can be seen as the potential stakeholders, as well as engineers and enterprises who already work with IEC 61850 standard.
The advantages of the presented work are as follows. 1) Compatibility with IEC 61850 standard output files: The designed approach is compatible with the SCD file of the IEC 61850 standard. It makes it possible to use the output files of the IEC 61850 standard-compatible tool (Helinks designer in the case of this study) as the input files for another application (designed in this work). 2) Reuse of design files: Design files reuse helps reduce the development time on the DT model of the charging system. (see the YouTube video of a simple use-case scenario, presented on page 9). 3) Compatibility with OCPP and (potentially) with the IEC 63110: The autogenerated code for the OCPP communication can potentially be compatible with protocol IEC 63110 without additional changes (to be proved in future work). The limitations include the following. 1) The number of supported IEC 61850 objects is limited: At this stage, only a subset of objects existing in the IEC 61850 library (only those presented in Table 2) is supported. 2) Not all IEC 61850 objects can be unambiguously transformed into Simulink objects: Most of the Simulink components have so-called polarity (when the object has input and output pads) but this information is not specified in the IEC 61850; therefore, there is a risk of autogeneration of the Simulink model, which is not possible to simulate at all, or the simulation results will be incorrect. To minimize the risk of creating a new model incorrectly, the operator still needs to visually check the Simulink model itself and manually correct the model in case of inconsistencies. 3) Limitation of IEC 61850 components library: Even though the IEC 61850 library has all the most important components for the design of a simple CS mode, its amount is still not sufficient even for a more or less complicated project. Currently, the IEC 61850 has 91 logical nodes, divided into 13 logical groups. Therefore, the development of IEC 61850 components' library is a vital condition for further development of the approach presented in this article. The possibility to autogenerate the model of the CS for the hardware-in-the-loop (HiL) system (for example, the OPAL-RT simulator [25]) is the one option to validate the accuracy of the autogenerated model. The results of the software-in-theloop simulation, as presented in this work (see Section XIII), could be compared with the result of the HiL simulation to increase the validation ability of automatically generated models. Additionally, transformational principles that were presented in this work can be potentially propagated to other communication standards of the global energy market (such as OpenADR [26]) to explore the potential benefits of use and compatibility with other communication protocols. Software-in-the-loop. HiL Hardware-in-the-loop.