Monitoring and analysis of low-voltage network with smart grid architecture model by developing use cases

The rapid transition of smart meters from traditional meters has provided many benefits to utilities, distribution system operators (DSOs) and customers. The customers can check the hourly consumption data for electricity usage and control their energy usage by receiving tariff information. Smart meters enable DSO to get state estimation, interruption measurement, and asset management. The information regarding interruption measurement can be gathered by deploying smart meters at the customer level and at the substation level, which reduces the time at the control center to identify the affected power supply area.

Initially, automatic meter reading (AMR) meters were deployed to read the electricity energy consumption with one-way communication for accurate billing, and for reducing the cost of labor for a meter reading. However, after the invention of advanced metering infrastructure (AMI), the smart meters with two-way communication participated in different operations, such as tamper detection, theft detection, managing peak demand, fault management, power quality monitoring, and network planning. The smart meters are a part of the AMI network that uses different information and communication technology (ICT) solutions to send and receive the data. The collected data can be analyzed and utilized for other purposes (data mining for smart home solution), consisting of consumption data, events and alarms (Wang et al., 2016).

The interest of extended real-time monitoring for low-voltage (LV) network increased after the rapid growth in the penetration of distributed energy resources (DER) in the LV grid. Before integrating DER, the distribution companies were only interested in high voltage and medium voltage level monitoring. Nowadays, smart meters are used as an extended system of supervisory control and data acquisition system (SCADA) for monitoring and controlling of the end-points of the LV network (customers). The deployment of smart meters has reduced the number of current sensors, which can be used at feeder level for real-time monitoring of the LV network. The current sensors solution is costly, and for accurate real-time monitoring, we need voltage information as well, and voltage sensors will also increase the cost. Thus, a smart meter is a best-preferred solution for monitoring of LV network (Kauppinen et al., 2012).

There are different types of meters available in the market, which are manufactured by different vendors with different functionalities. In the INTEGRIS project (Pikkarainen et al., 2013), two types of meters have been used: a smart meter (SM) and a power quality meter (PQM). The smart meter provides fundamental quantities such as current, voltage, power, and reactive power, while PQM offers information about power quality problems such as flicker, harmonic distortion, etc. The PQM information is not enough to determine the power quality issues in the distribution network. Thus, the evaluation is required based on other measurement units, such as remote terminal unit (RTU), SMs, and estimated values. From the power quality point of view, SM measurements are providing only voltage level information. The advantage of using PQM measurements over SM is that the PQM measurements give an indication of voltage dips, fuse blown, and interruption information (Pikkarainen et al., 2013).

A centralized distribution network management system is presented in the paper (Repo et al., 2011) for LV network management. However, the centralized distribution network architecture is shown in general. The details about data type and its exchange between the systems involved in the distribution network management system are not provided. For LV network management, the following questions are addressed in this paper:

How can smart metering data be utilized for the use cases of the LV network?

To address the above research questions, use cases are designed to show the systematic analysis of data at different distribution network stages. The smart grid architecture model (SGAM) framework is introduced in this paper to cover use cases from the technical, functional, and market point of view.

A use case is the best way of describing the goals and requirements of actors involved in the LV monitoring process. The mapping of use cases into the SGAM framework makes it easier to understand the functionalities and sub-functionalities of use cases. This paper focuses on the use cases of power quality monitoring and outage identification, classification, and management. The main objective of this paper is to identify the outages and power quality problems at the LV network and send this information to the control center with the help of developing use cases. The second objective of this paper is to select the communication infrastructures for use cases. To achieve the second objective, different communication architectures used in various projects are reviewed, and communication performance indicators (latency, throughput, the data rate per packet, and response time) are compared to select communication infrastructure.

This paper is organized into five sections, including Introduction. The second section explains the use cases of outage identification, classification and management, and power quality monitoring with their LV network operation benefits. In the third section, the use cases are mapped into the SGAM framework with an emphasis on the implementation of communication media and protocols for LV network monitoring. The fourth section presents the discussion of this paper, and finally the last section summarizes this paper.

For any system analysis, a use case can be used as a methodology to identify, clarify, and organize system requirements. In this paper, the use cases are classified into two categories: outage identification classification and management, and power quality monitoring. These use cases are classified into two groups to know the interruption problems and improve the quality of service by maintaining the LV distribution network’s reliability. Besides, to improve the network’s quality, network planning can be achieved more efficiently with the help of these use cases.

Before designing a use case, it is necessary to know each system’s functionalities involved in use case design. Table 1 shows the systems with their description, which are employed in the use case design.

Two use cases are designed in this paper by integrating actors (customer, SM, PQM, Intelligent Electronic Devices (IEDs)) and these systems (SCADA, GIS, NIS, CIS, OMS, DMS). The first use case determines the outage problems, while the second one focuses on power quality problems in the LV network.

Use case of outage identification, classification, and management

This use case describes how the outage information is received from a smart meter. The outage data can be exported to different systems for checking and verifying outages in the distribution network.

In this use case, the smart meters periodically measure the voltage and current at end-points (consumers) of the distribution network. Regulators set the threshold voltage levels to ensure the reliability of a network and quality of electric supply. When voltage levels change from the predefined value, smart meters generate events and alarms and send this information to DMS/OMS followed by different operating systems between DMS/OMS and a smart meter. For single or two-phase faults, it generates phase missing alarm separately for each phase, and for three-phase fault, it generates the last gasp message alarm. The outage information is confirmed by DMS/OMS with the help of SCADA and CIS by checking the planned outages and filtering out the events by knowing the issues in the distribution network. The following steps are required for this use case:

A smart meter measures the voltage levels.

Smart meter generates the alarm for an outage.

DMS/OMS receives the information.

DMS/OMS confirms the outages by checking planned/unplanned outages by employing SCADA, CIS and NIS.

To understand the procedure applied in the use case design in a visual format, some diagrams are presented in figures. Figure 1 shows the data transmission process from smart meters and from IEDs during outage events and the systems involved for data collection. Figure 1 depicts that a smart meter sends the outage information to the data concentrator (DC) during three-phase fault at the customer location, while an IED is placed at the secondary substation, which sends the outage information to RTU during the fault at the secondary substation. The outage information is transferred to the control center from IEDs and a smart meter via different information systems (RTU, front end system, DC, AMI head end, meter data management system (MDMS), etc.), where further actions can be taken based on the collected information. For sending outage information to the control center, an enterprise service bus (ESB) is utilized which facilitates the services of service-oriented architecture (SOA) and serves as an integrating bus for information systems at the control center. To forward the outage data from RTU to SCADA and then to DMS via ESB, the front-end system, which acts as an interface between SCADA and RTU, is used. For notifying the customer about the cause and duration of the interruption, a web portal is utilized.

Figure 1:

Figure 2 shows the sequence diagram, representing the type of data exchange between different systems and actors for sending outage information to the control center. At first, the outage information is sent to DMS/OMS from different actors and systems in parallel to information from SCADA. Then, DMS/OMS identifies the planned and unplanned outages. For planned outages, DMS/OMS confirms the outage information (outage location and affected customers) from GIS and NIS along with the information (data) collected from SCADA and MDMS via ESB. In contrast, for unplanned outages, it only confirms the outage location and affected customers from GIS and CIS. The collected information (planned or unplanned outages) is then sent to the customer via the web portal. Moreover, queries are generated by the control center for smart meters to ensure the occurrence of the outage and its location.

Figure 2:

Figure 3 depicts the query (ping) and response process for finding the outage’s exact location. At first, the query is generated by DMS/OMS to MDMS via ESB, and then this process is continued until getting the response of smart meters. For identifying the fault at the customer level, an event is generated from DC, which can be used to distinguish the faults at secondary substations from the fault at the end customer. A ping request is then sent to all smart meters for getting their acknowledgement signals to confirm their online status. In this way, outage location is confirmed by getting response or acknowledgement signals from smart meters, AMI head end, DC, MDMS, and by getting information from CIS and GIS. After the confirmation of the outage location, the information is updated on the web portal.

Figure 3:

This use case visualizes how different participants/stakeholders can observe the process of identification, classification, and management of fault at LV network. Furthermore, the collected metering data at DC can be utilized for different purposes, such as intelligent algorithms (estate estimation and voltage control) can be implemented for the self-healing of LV network which can be applied at the secondary substation.

Use case of power quality

In the transmission of power from generation to consumption, the power quality is affected due to various factors, such as weather, transmission cables, failure of protection devices, the malfunctioning of devices, overloading, disturbances from the customer, switching off equipment, distortion factors, etc. This use case illustrates how smart meter data is used to analyze the power quality problems at the LV network.

The power quality events based on voltage thresholds are defined by standard EN 50160. The purpose of this use case is to transfer the power quality events or alarms generated by a smart meter to DMS and to power quality database. In this use case, the PQM device measures the power quality quantities (voltage dips, flicker and harmonics) at the substation level, and sends this information to an intermediate data collection system for power quality (PQ) devices. Moreover, the PQM device measures other quantities, such as; fuse blown, an indication of voltage dips, and interruptions for 10 min interval. The intermediate data collection system for PQ devices receive the power quality information from all other PQ devices installed at the LV network and sends the collected information to MDMS.

For monitoring the power quality in the MV network, the RTU provides phase voltage unbalance, phase voltage level, and total harmonic distortion of phase voltage information. These measurements are taken approximately every 1.5 min and transferred to the 10-min average value for power quality monitoring purpose (Pikkarainen et al., 2013).

The consequences of power quality problems are economic losses. It was found that 90% of losses (production loss, equipment loss, work costs, labor costs, monetary losses due to replacement of system devices) were observed for the industry sector. Thus, power quality is a significant issue that has a considerable impact on the economy (Amaripadath et al., 2017).

Figure 4 shows how power quality data is transmitted from smart meters and from IEDs to control center. As compared to the previous use case, here an additional PQM device is used which measures the power quality from substation level. To avoid the congestion of power quality data, an intermediate data collection system for PQ devices (PQDB) is used in this use case which gathers the power quality data from MDMS and PQ devices. After collecting the power quality data, the PQDB sends this information to the control center, where DMS/OMS identifies the power quality issues in the distribution network and updates this information on the web portal to inform the customer.

Figure 4:

The sequence diagram of this use case is different from the previous use case because two additional actors (PQM device and PQDB) are used to measure and collect power quality information.

The sequence diagram in Figure 5 explains how power quality information is checked at the feeder and substation levels. If power quality issue is identified at feeder level, the number of affected customers on that feeder is recognized, and this information is transferred to the web portal. If power quality issue affects several feeders, the power quality information is determined at the substation level, and this information is transferred to the web portal. For this purpose (identifying power quality issue at the feeder or substation level), DMS/OMS defines the threshold values and gets the information from PQDB.

Figure 5:

The advantage of this use case is that it provides power quality information from the LV network and shows the relationship between different power quality measurement devices and field devices (RTU, SCADA) of the distribution network. This use case can be utilized for determining the network-holding capacity.

The ICT solution defines the requirements and conditions for integrating different actors and systems used in the use cases. To achieve the integration requirements and meet the goals of use cases, it is required to design the use cases so that its scope and objectives would be clearly defined. For this purpose, the SGAM framework is used, which explains ICT solution behavior in a physical distribution system.

The SGAM provides the most straightforward way to illustrate the smart grid-related functionalities and explains how three-dimensional (zone plane, domain plane, and interoperability layers) architecture is used to describe the use case and sub functionalities of the use case in a pictorial form. The domain (one-dimensional smart grid plane) shows the stages involved in the transmission of electrical energy from generation to customers, while zone shows how the management of power system is divided hierarchically into six zones, namely, process, field, station, operation, enterprise, and market. The interoperability layers represent how devices and communication technologies are integrated that belongs to different layers of interoperability (Bruinenberg et al., 2012).

There are three approaches for mapping the use cases: top-bottom, bottom to top, and mix approach. The difference between the bottom to top and top to bottom approach is that the bottom to top approach is preferred for the technical implementation of a specific use case which meets the one or two business objectives. On the contrary, in the top to bottom approach, a general or high-level use case is described, and the use case’s concrete implementation is unknown. The mixed approach is the combination of both approaches, and it does not follow any sequence in the mapping process of use case. In the mixed approach, each layer is designed randomly, unlike top-bottom and bottom-to-top approaches that follow the designing sequence. In the mixed approach, at first component and business layers are developed, and then the function layer is created based on the information and needs of the business layer. In the end, information and communication layers are developed (Radi et al., 2019). In this paper, the bottom to top approach is applied (e.g. start mapping use cases into SGAM from component layer to the business layer) to meet the business objectives (monitoring of outage and power quality problems at LV network) of use cases. The bottom to top approach is applied here because data are generated from smart meters and from IEDs, which is forwarded to DMS/OMS for further actions. In the mapping process, smart meters, IEDs and PQMs are placed at the component layer, while DC, PQDB and RTU are placed at the communication layer of SGAM. Figure 6 describes the systematic mapping of a use case into the SGAM framework.

Figure 6:

For LV network monitoring, the deployment of communication infrastructure and how different components communicate are big decisions. For a communication system, secure data and reliable high-speed information transfer are essential parameters that should be effectively managed by a smart power network (Sharma et al., 2019). In this section, different communication technologies, communication protocols and communication infrastructures are presented, and discussion is carried out to select suitable communication infrastructure for the use cases of this paper.

The communication layer (the second layer of SGAM) describes in what fashion or how different devices are connected and which communication technologies, communication protocols are used (Uslar et al., 2019). For the use cases of this paper, the communication layer is designed to map the use cases into the SGAM framework and to visualize the integration process of different actors and systems, which is shown in Figure 7.

Figure 7:

Figure 7 depicts the mapping of the use cases into SGAM layers. The communication media and communication protocols used in the mapping process are explained in detail in this section.

Communication protocols and standards

The communication protocols define the set of rules for data transmission among different devices in the communication network. The communication protocol supports devices from different manufacturers with various specification to share the information in the same language. Most of the communication protocols follow the open system interconnect (OSI) model layer structure. The OSI model consists of seven layers that illustrate how data are processed from each layer and each layer’s function during data transmission. The data transmission can be serial, parallel, or peer-to-peer communication, and it depends upon the supporting protocols, bandwidth, communication channel, and supporting communication media. This section gives the brief introduction of communication protocols that support the selected communication infrastructure employed for the use cases of this paper.

DLMS/COSEM protocol

DLMS stands for device language and message specification, while COSEM stands for companion specification for energy metering. The DLMS and COSEM are two different standards used together (DLMS/COSEM) as a communication protocol for meter data exchange. The DLMS (IEC 62056-53) is the suite of standards maintained by DLMS user association that provides the interoperable environment for meter data exchange, while COSEM (IEC 62056-62) is an object-oriented model for meter communication interface that gives the complete description of functionalities and carries the set of specifications. The specifications of COSEM are used to define the transport and application layer for DLMS protocol. The DLMS/COSEM works on the client/server-based architecture (meter acts as a server, and DC acts as a client) and operates on the application layer (an upper layer of the OSI model). Each layer of the OSI model performs different tasks, and lower layers of the OSI model provide services to an upper layer. The type and the number of lower layers are dependent on the used communication media (Dedé et al., 2015).

In smart metering applications, the DC polls the smart meters for data acquisition. Like poll command, the push command is also introduced in DLMS/COSEM for the event notifications. The notification of events generated by smart meters can be sent to DC without any ping request created by DC. As compared to report service approach used by IEC 61850, this approach performs the same actions (Dedé et al., 2015).

Modbus

Modbus (an application layer communication protocol) belongs to the family of field bus protocols, and they are widely used in industrial automation applications. The Modbus supports the communication between RTU, meters and other field devices via a serial line, and it uses the recommended standard (RS-485 or RS-232) for data transmission. Modbus communication is possible by master/slave architecture in which the master sends the request and slave responds to the request (Camachi et al., 2017).

IEC 61850

The IEC 61850 is the international standardized protocol (object-oriented standard) used for substation automation communication. The advantage of using IEC 61850 is that it provides an abstract data model and an abstract communication interface. The IEC 61850 is the part of the IEC technical committee (TC 57) reference architecture that defines the standardized names, the meaning of data, device behavior models, and abstract services (Camachi et al., 2017).

The IEC 61850 is also used beyond the substation such as communication for wind and hydroelectric power plants. IEC 61850 can be mapped into manufacturing message specification (MMS) protocol (an OSI protocol that runs over TCP/IP, where IP stands for internet protocol. Moreover, it also provides the interoperability between IEDs which are manufactured by different vendors (León et al., 2016).

The interface model of IEC 61850 is broken down into logical devices and further divided into logical nodes. Before exporting the data from RTU to SCADA, the data sets are defined, which reflect that what kind of services are subscribed by a client. Both DLMS/COSEM and IEC 61850 can be compared in terms of transporting information for smart metering application (Dedé et al., 2015).

The IEC 61850 supports different types of messages from different performance classes, and they are mapped to different protocols. The grouping of messages is based on the specific requirement of the message type. In other words, the message of the same requirements is grouped and mapped to the same message type protocol (Kuzlu et al., 2014). Figure 8 shows the message type grouping and their mapping into different protocols.

Figure 8:

IEC 61850 MMS

MMS defines the set of encoding rules for mapping the messages to bits or bytes during transmission. MMS operates over client-server architecture and supports the services of IEC61850. The IEC 61850 services are mapped into MMS protocol using over TCP/IP of OSI model and running over layer three on ethernet (a popular local area network protocol). The preferable solution for MMS is to use it for data communication between field devices and from DC to AMI head-end (León et al., 2016).

CIM

The CIM stands for common information model, and it is an object-oriented data model in the power system. CIM is used to define the object classes, object attributes, and the relationship to other classes. It is used as a common data exchange model for application integration. In other words, it is used for the exchange of information (information about the configuration and status of the network) between applications in operation and business layers of SGAM. CIM is not a database, but it is a method for storing and organizing the data. For standardized communication between different communication systems, CIM defines the semantics for all CIM supported communication systems. The standards that come in CIM category are IEC 61968 and IEC 61970 (Arnold et al., 2010). Table 6 shows the specific application of different standards.

Table 6.

Standards, along with their application and comments as applied in SGAM (Arnold et al., 2010).

Standard	Application	Comments
DLMS/COSEM	This standard is mainly used to support communication between smart meters and DC. A few applications of this standard are: electricity meter data reading and exchange, support of outages and power quality alarms, tariff and load control	DLMS User group
IEC 61850	This standard was first designed to provide the communication between substations, and now it is used for the communication between the control center and substation for monitoring and controlling purpose. However, it can also be used beyond substation communication. For example; for communication between DERs and substation, but these protocols or standards are still in practice	This standard is open, maintained and developed by IEC
IEC 61968/61970/IEC62325 suite (CIM)	These standards are used to define the systemic model for data exchange. The IEC 61970 is used for interface-related application and the energy management system, while IEC 61968 is used to transfer information between different systems at the control center. For the data exchange to DSO and energy markets, IEC 62325 standard is used	These standards are open, maintained and developed by IEC
IEC 62351	This standard is used to define the information security for data exchange and power control-related operations	This standard is open, maintained and developed by IEC

The smart meters generate different events; some are set by DSO and some by the manufacturer. These events are meter/device status events (last gasp or power store), meter temper flags, and meter hardware information (low battery alarms, battery critical). Besides these events, there are alarms which are generated based on voltage threshold levels set by DSO. These alarms are as follows: phase missing, neutral conductor fault, asymmetrical voltage, and voltage unbalance (over and under voltage) (Repo et al., 2011).

The unnecessary alarms (alarm followed by another alarm) must be avoided and prioritized before sending it to DMS. The unnecessary alarms create overwhelming data that produce congestion in the communication network and increase data transfer power consumption. To avoid unnecessary alarms, the alarm filtration algorithm can be utilized at DMS or at the SCADA system, which depends on the architecture (topology) and the length of the network.

A DSO can prioritize the alarms, and one example of prioritization of alarm is set by Elenia Oy in Finland, which is described below.

The priority is given to the phase missing alarm (phase fault) when the phase fault is identified. The second priority is set for an asymmetrical voltage alarm that indicates the neutral conductor fault. The third priority is given to phase unbalance voltage alarms (Kauppinen et al., 2012).

For finding the exact fault location or affected smart meters, queries are generated. The queries are created by a system operator and can be classified as manual, semi-automatic and fully automatic. The manual query can be sent by DMS/OMS to smart meters at any time. The semi-automatic query is generated after receiving the alarm notification. These quarries are created to know the meters’ status (either meters are on the same feeder or different feeders). On the other hand, the fully automated queries are used for a weak network; an automated query is issued at least once in a day for analyzing the network (Kauppinen et al., 2012). When a query is created by DMS and received by smart meters, the following responses can be seen by smart meters:

Device responding (no alarm).

The designing of use cases and then mapping them into the SGAM framework is the main contribution of this paper. Moreover, this research paper will help the network operating company and DSO to design a suitable communication network associated with specific protocols for data communication to SCADA or to make the distribution network as an active network.

This paper aims to describe a process to monitor the LV network problems (outage, power quality) using smart metering events by designing use cases. The use cases have shown the involvement of different actors and systems in the monitoring process, which are later mapped into SGAM framework to see the monitoring process in a pictorial format. Communication technologies and communication protocols between actors and systems or between different systems play an essential role in the monitoring process. For that purpose different communication infrastructures, communication technologies and protocols are discussed in this paper. For the designed use cases of this paper, PLC with GPRS (hybrid solution) communication infrastructure is selected for the communication between SMs and control center based on the key performance indicators (latency and throughput) of different communication technologies and by reviewing different communication infrastructures used in different projects. In communication protocols, DLMS/COSEM is chosen to support PLC communication between SM and DC. At the same time, IEC 61850 is selected to support the communication between field devices and the control center over ethernet. In future, the designed use cases can be further developed by adding more functionalities (by implementing data mining algorithms) in PQDB and MDMS. Moreover, the proposed smart platform can be confirmed by incorporating simulated test cases.

List of Acronyms:

AMI= Advanced Metering Infrastructure