3.1. Overall Description of PnP
In a microgrid system, PnP is a crucial feature that encompasses various aspects, including device installation, configuration, and operation, particularly at the device and system levels. The PnP functionality is divided into two key components: PnP from edge devices to the cloud platform, and PnP from end devices to the edge devices. Both of these components play a vital role in enabling the intelligence and efficient operation of the microgrid, collectively establishing the foundation for its smart and effective functioning.
Firstly, PnP from edge devices to the cloud platform primarily involves the integration of edge computing and cloud computing. In this link, edge devices can connect to the cloud platform without the need for complex configurations or settings, with simple PnP enabling the edge devices to establish a seamless connection with the cloud platform. This allows microgrid devices to come online with zero configuration, significantly reducing the configuration workload at the construction site while improving data collection accuracy and efficiency.
Secondly, PnP from end devices to edge devices primarily involves device-level interconnectivity. Through simple device interface operations, end devices can quickly establish connections with edge devices and enable real-time data exchange. Similarly, this reduces the workload of on-site configuration, improves device operational efficiency, and ensures data accuracy.
The aforementioned PnP links are based on the prerequisites of communication, protocols, and model standardization. These three elements form the fundamental requirements for enabling device PnP functionality. Together, they ensure compatibility and stability in device interaction and communication processes, providing support for the overall operation of the microgrid. The architectural diagram for the PnP application in microgrids is shown in
Figure 5.
3.2. Logical Node of JS-MCS
Distributed energy resources (DERs) may be put into operation or shut down frequently during microgrid operation. Hence, their information interfaces need a PnP function to realize fast identification and configuration by the cloud platform when the DER integrates and to improve the DER integration efficiency. The information model is the important foundation for PnP integration of microgrid equipment. The equipment’s logical nodes (LNs) predefine the groupings of IEC 61850 data objects (DOs) that serve specific equipment functions such as automatic control, monitoring, protection, and measurement.
A particular physical device of a DER could be extracted to the logical devices (LDs) consisting of the relevant LNs to provide specific functions. The LNs of the DERs in JS-MCS typically include:
The LN in IEC 61850 specifically for photovoltaic (solar panel) systems is DPV. This logical node is used to model the functions and behavior of solar photovoltaic power generation systems. The DPV logical node would likely contain data objects representing the status and control of the solar photovoltaic system, measurements of power and energy, and possibly information about conditions like solar irradiance and temperature that might affect the system’s performance. The following general logical nodes in IEC 61850-7-4 might be used with solar photovoltaic systems:
MMXU: Measurement unit. This logical node might include measurements of current, voltage, power, and energy for the photovoltaic system.
GGIO: General purpose input/output. This logical node might be used for a variety of status and control information about the photovoltaic system.
CSWI: Controlled switch. This logical node could be used to model the controls for disconnect switches or other switchgear associated with the photovoltaic system.
- (2)
Battery energy storage
IEC 61850-7-420 is an extension of the IEC 61850 standard, specifically providing logical nodes to cater to the battery energy storage system. This standard defines a set of logical nodes to facilitate the modeling, control, measurement, and management of battery systems in the context of DERs. Here are the logical nodes in IEC 61850-7-420 specifically associated with the battery energy storage system:
BAT: This logical node represents a battery system. It models the functionality of battery storage systems, including data attributes related to charge and discharge power, state of charge (SOC), state of health (SOH), temperature, and other operational parameters. It also includes control commands for starting and stopping the charging or discharging process.
BCR: The battery charger/rectifier logical node models the functionality of the battery charger or rectifier, including data related to active and reactive power, current, voltage, and operational status. Control commands include starting and stopping the charging process.
BTR: This logical node represents a battery trip unit. It is used to model the functionality that trips the battery connection based on conditions such as over-temperature, under-voltage, over-voltage, and over-current.
BSW: BSW represents a battery switch. It models the functionality of the switch that connects and disconnects the battery from the DC bus, including its operational status and control commands.
INV: INV represents an inverter. This logical node models the functionality of an inverter, which is commonly used in battery storage systems to convert DC power to AC power for feeding into the grid. This includes data related to active and reactive power, current, voltage, frequency, and operational status. Control commands include starting and stopping the inverter.
- (3)
Transformer
Transformers can be represented by a variety of logical nodes in the IEC 61850 standards. In IEC 61850-7-4, which covers general power system equipment, several logical nodes are typically associated with transformers:
XCBR: Circuit breaker. This logical node is often used with transformers to control the circuit breaker that connects the transformer to the rest of the power system.
XSWI: Disconnect switch. This logical node may be used with transformers to control disconnect switches that isolate the transformer for maintenance or during a fault condition.
TCTR: Transformer current transformer. This logical node is used to represent the current transformer that is used to measure the current in the transformer.
TVTR: Transformer voltage transformer. This logical node is used to represent the voltage transformer that is used to measure the voltage of the transformer.
MMXU: Measurement unit. This logical node contains measured data from the transformer, including voltage, current, power, and energy measurements.
ZCAP: Capacitor bank. In case the transformer is equipped with shunt capacitors for voltage regulation, this logical node can represent them.
PTOC: Transformer over-current protection. This logical node provides the over-current protection function for the transformer.
- (4)
AC and DC loads
In IEC 61850-7-4 and IEC 61850-7-420, loads (both AC and DC) are not typically represented as separate logical nodes. Instead, they would likely be represented through other logical nodes, primarily measurement and control related, depending on the functionality of the load in the power system. Here are some logical nodes that are associated with AC and DC loads:
MMXU: Measurement unit. This logical node contains measured data related to the load, such as voltage, current, power, and energy measurements.
GGIO: General-purpose input/output. This logical node can be used for a variety of status and control information about the AC and DC loads.
CSWI: Controlled switch. This logical node could be used to control a switch that can connect or disconnect the AC and DC loads from the power system.
CILO: Interlocking function. If the AC and DC loads have interlocks to ensure safe operation (for example, to prevent them from being switched on when certain conditions are not met), these might be represented with this logical node.
- (5)
Rectifier or inverter
In the IEC 61850-7-420 and IEC 61850-7-4 standards, there is no specific logical node for a rectifier or inverter. However, these devices’ functionalities could be modeled using a combination of different logical nodes, depending on their specific use and the systems they are connected to.
For instance, in a solar power generation system, the inverter converting DC power to AC might be represented as part of the DPV logical node in IEC 61850-7-420. If the inverter is part of a battery energy storage system, it might be represented as part of the BAT logical node. In a more generic context in IEC 61850-7-4, the control, status, and measurement functions associated with an inverter or rectifier might be represented by a combination of logical nodes like MMXU, GGIO, and CSWI, which are similar to those of the AC and DC loads.
3.3. PnP between Cloud and Edge
The process of data exchange facilitating the PnP between cloud and edge platforms, as depicted in
Figure 6, involves intricate and integral interactions that are crucial for optimal functionality.
Initially, the edge unit is responsible for procuring the operational measurements and status information from the cloud platform. These acquired values are vital for maintaining a real-time understanding of the cloud platform’s status and can provide valuable insights into its functionality.
Once the edge unit has obtained these values, it proceeds to update the corresponding data objects in its information model. These updates provide an accurate and up-to-date representation of the cloud platform’s operations. The accuracy of the data is contingent upon the dynamic updating mechanism, a crucial feature enabling the system to adapt to changes in the cloud platform’s operational parameters.
Subsequently, the edge unit triggers a report based on the specifications delineated in the report–control–block options. This report, containing critical status and operation data from the cloud platform, is then transmitted to the cloud platform itself. The cyclical nature of this transmission process ensures a consistent exchange of information, contributing to the robustness of the entire system.
Simultaneously, the edge unit is tasked with receiving control commands and settings alterations from the cloud platform. This dual-directional communication establishes a firm groundwork for cooperative and coordinated operations between the two platforms.
Upon receipt of these controls and settings, the edge unit is required to make reasonable decisions to act upon. The rationale and efficacy of these decisions are paramount to the system’s effective operation. By leveraging advanced analytics and decision-making algorithms, the edge unit is capable of making determinations that align with the operational objectives of the cloud platform, ensuring smooth, efficient, and harmonious PnP operations.
The basic process of cloud-to-edge PnP involves a series of meticulously coordinated steps. The following provides a detailed explanation of the entire process:
- (1)
Cloud platform preset configuration process: On the cloud platform side, the initial information model and required authentication information for the edge devices are preset. This includes predefining the initial information model and encryption certificates for the edge devices. This preset phase ensures standardization and security of the edge devices, providing a foundation for their interaction with the cloud platform in the subsequent processes.
- (2)
Product type creation process: The cloud platform creates product types based on the physical model file of the edge devices. This step involves predefining the device’s model, allowing the cloud platform to recognize and handle various types of edge devices, thereby enabling seamless management of the devices.
- (3)
Secondary model documentation process for edge devices: First, the cloud platform manually completes the documentation process for the secondary model of the edge devices and establishes the association between the primary and secondary devices. This step involves manually documenting the secondary model of the edge devices and establishing the association between the primary and secondary devices. When not restricted by access permissions for edge devices, it supports automatic documentation based on the information uploaded by the edge devices. It also supports through scanning QR codes to establish documentation of the secondary models or batch documentation of the secondary models of edge devices through importing files.
- (4)
Identity information upload process after edge device startup: After the edge device powers on and starts up, it uploads its identity information to the cloud platform through an IoT APP. This step represents the identity information upload phase of the edge device, playing a crucial role in the cloud platform’s permission management and device status tracking.
- (5)
Cloud platform identity information receiving and verification process: Upon receiving the identity information from the edge device, the cloud platform performs identity comparison and matching based on the predocumented information. Once a successful match is found, access permissions are granted to the edge device. This is the identity information verification phase, where the crucial aspect is ensuring system security by only allowing verified devices to access the cloud platform.
- (6)
The process of establishing a connection between the edge device and the cloud platform: Once the edge device establishes a successful connection with the cloud platform, it should send an online message to the platform. This step involves establishing a communication connection between the edge device and the cloud platform, and sending the online message indicates that the device has successfully connected to the cloud platform.
- (7)
The process of the cloud platform receiving the device’s online message and refreshing its status: Upon receiving the online message from the edge device, the cloud platform should promptly refresh the operational status of the device. This is the phase of device status update, where the cloud platform can reflect the real-time operational status of the device for subsequent management and control purposes.
- (8)
The data parsing process of the cloud platform: The cloud platform will parse the data based on the model defined in the product type. This is the data parsing phase, where the cloud platform can understand and process the data uploaded by the device, providing further control and management of the device.
In
Figure 6, “CAN” stands for “controller area network”, a vital communication protocol within microgrids. This protocol facilitates real-time communication and control coordination in power devices. Within microgrids, “CAN” serves these key functions:
Efficient communication: “CAN” enables seamless communication among microgrid control units, promoting real-time information exchange for coordinated operation. Distributed resource management: “CAN” aids in managing distributed energy resources like solar and wind generation [
23], enhancing efficiency and stability. Intelligent energy management: With data communication capabilities, “CAN” supports intelligent decisions for energy allocation, scheduling, and optimization in varying scenarios.
3.4. PnP between Cloud and Terminal
The mechanism underlying data exchange between cloud and terminal in a microgrid context, as outlined in
Figure 7, underscores a complex interplay of various parameters that are integral to a microgrid’s operation. The terminal unit within the microgrid system encompasses numerous information equipment models, each playing a significant role in the microgrid’s data exchange process. These models enable the constant and efficient flow of information within the microgrid, thereby facilitating seamless operations and communications.
An illustrative example of such an information equipment model within a terminal unit is the battery energy storage. and symbolize the active and reactive power, respectively. These parameters are modeled by the measured values MMXU.TotW and MMXU.TotVAr, correspondingly. These models serve as crucial markers for the system’s operational status, allowing the tracking of power contribution and responsiveness in real time, thereby ensuring enhanced system performance and stability. The breaker position, a critical determinant of power transmission and distribution within the grid, is modeled via the status information DO-XCBR.Pos. This model aids in the accurate monitoring of the breaker’s position, hence ensuring secure and efficient power flow within the system. The parameters , , and represent the voltage reference, active power reference, and reactive power reference of the battery energy storage, respectively. These parameters are modeled by control values DRCC.OutVSet, DRCC.OutWSet, and DRCC.OutVarSet, correspondingly. These models ensure that the voltage, active, and reactive power of battery energy storage stay within the desired range, thereby promoting overall system stability and operational efficiency.
In a word, these intricate data exchange processes between the cloud and the terminal contribute significantly to the PnP functionality within microgrids, underlining the paramount importance of accurate modeling and control in the successful operation of these complex systems.
The basic process of cloud PnP includes:
- (1)
The cloud platform should initially preconfigure a device model associated with the end device. This is the initial stage of cloud-based PnP, where, by predefining the device model, it becomes convenient for the device to automatically register and connect after power-on, thereby improving the convenience and automation of device integration.
- (2)
Subsequently, the cloud platform needs to install the end device collection APP on the edge device. This application serves as a communication bridge between the end device and the edge device, responsible for data collection and transmission.
- (3)
Once the end device is powered on and starts up, it should immediately upload its identity information to the edge device. This step is crucial to ensure the security and identification of the end device, while also providing essential information for the subsequent device registration.
- (4)
The device collection APP on the edge device receives the end device’s active registration identity information or completes the registration process between the end device and the edge device after the edge device self-discovers the end device. The active registration process is applicable to network-type end devices, such as Ethernet and IP-based communication carriers. On the other hand, the self-discovery registration process is applicable to serial port-based end devices, such as broadband carriers and RS-485 communication end devices.
- (5)
Once the end device is successfully registered, the edge device will send the end device’s identity registration message to the cloud platform through the IoT business APP. This process synchronizes the existence and status of the end device to the cloud platform, further enhancing the integrity and real-time nature of the system.
- (6)
Upon receiving the identity registration message from the end device, the cloud platform will complete the documentation of the end device and the association with primary and secondary devices based on the uploaded end device identity information. This process should support manual completion of secondary model documentation for the end device and the association of primary and secondary devices. Additionally, it should also support the completion of secondary model documentation for the end device through scanning QR codes or importing files.
- (7)
Upon receiving the online or offline message from the end device, the cloud platform should promptly update the operational status of the end device. This step ensures that the cloud platform can reflect and manage the operational status of the end device in real time, contributing to the stable operation of the system.
- (8)
Finally, when the cloud platform receives business messages from the end device, it will perform in-depth parsing and processing of the messages. This will facilitate a further understanding of the device’s operational condition, enable the discovery of potential issues, and facilitate effective problem resolution.
One of the key metrics we employed to measure the speed of the integration process is the average time taken to establish connections between various microgrid components. In a comparative study, we executed integration tasks using both traditional methods and our proposed edge–cloud collaboration approach. The results clearly demonstrate a significant reduction in the time required for component connection, with our method outperforming the traditional methods by an average of 30%. This reduction in integration time showcases the effectiveness of our PnP method in streamlining the setup process.
Latency reduction is another critical aspect that directly impacts the smoothness of the integration process. We conducted latency tests during data exchange between edge devices and the cloud platform using our approach. Our findings indicate an average latency reduction of 25% when compared to conventional integration methods. This reduction not only ensures faster data flow but also contributes to the overall stability and responsiveness of the microgrid system.