Web-Based Toolkit for Performance Simulation and Analysis of Power Line Communication Networks

: AMIs (Advanced Metering Infrastructures) present an important role in Smart City environments, especially from the point of view of distribution and customers, offering control and monitoring capabilities. The use of PLC (Power Line Communication) technology offers a wide range of advantages in AMI, including not needing to deploy an additional communication infrastructure. However, the electrical network was not initially designed for communications, as these networks pose problems depending on the connected loads, such as network impedance variation, frequency selectivity or noise. For this reason, the use of simulators is proposed to facilitate the deployments based on PLC networks, and analysis and diagnosis tools for the identiﬁcation of problems in operating networks are also required. This paper presents a toolkit for evaluating and analyzing the performance of PLC networks. This toolkit is composed of SimPRIME, a simulator for the evaluation of NB-PLC PRIME (PoweR line Intelligent Metering Evolution) networks’ performance; SimBPL, a simulator for the evaluation of MV-BPL (Broadband Power Line over Medium Voltage) cells’ performance; and PRIME Analytics, a forensics tool that allows diagnosis of communication problems in PRIME operational networks based on trafﬁc traces. The toolkit has been developed throughout several research projects in close collaboration with DSOs (Distribution System Operators) and equipment manufacturers, so they provide solutions to actual problems of these industry key players and have been adapted to facilitate their use. As a result, the tools are accessible through web applications to increase their usability, portability, and scalability. These applications represent the ﬁrst steps in offering PLC simulation and analysis as a service that could beneﬁt the research community, academia, and industry.


Introduction
PLC (Power Line Communication) presents a wide range of advantages that make them very appropriate for Smart Grid applications, such as Advanced Metering Infrastructures [1]. However, they also involve a harsh communication medium, which suffers from frequency selectivity, impedance variation depending on the connected loads, or noise introduced by such connected loads [2,3].
From the point of view of the deployment and planning of PLC networks, simulation tools are useful to evaluate the performance of these kinds of networks under different conditions in an agile and cost-effective manner. Nevertheless, the typical complexity and learning curve of network simulators hinder their use, making it difficult to make the most of them.
From the point of view of the operation of PLC networks, the response of such networks is quite variable, so that a given network can show a decrease in performance at a given moment while working perfectly when operation crews arrive to fix the problem.

PLC Technologies
NB-PLC technology is very suitable for Smart Grids and AMI applications, as reflected in different studies [10,11] and pilot projects developed by main DSOs, such as, e.g., STAR (Iberdrola) [12] or SmartCity Málaga (ENEL) [13]. Nevertheless, BPL is gaining momentum in Smart Grid and AMI scenarios as a solution not only for transmitting aggregated traffic through long distances (e.g., MV-BPL cells) [14] but also for smart meter communications in last-mile [15] and other related applications [16].
For the sake of completeness, this section provides a summary of available PLC technologies, focusing on PRIME technology and IEEE 1901, since the toolkit presented in this paper is focused on them.
Regarding NB-PLC technologies, the most widely used ones are as follows. . This protocol is standardized by IEC 61334-4-32 [18]. The protocol is based on the use of narrowband binary phase-shift keying (BPSK) single carrier modulation for power line communications and achieves data rates up to 4.8 kbps. As far as security is concerned, this protocol uses the encryption type AES with a key length of 128 bits. This communication protocol is used in particular by all smart meters in Italy. In Spain, Endesa is responsible for the deployment in pilot projects in the cities of Málaga and Barcelona, as well as in the rest of the Spanish cities, meeting the requirements of Spanish Directive IET/290/2012 for a massive deployment. • Open Smart Grid Protocol (OSGP) is an Echelon-promoted protocol with a large presence in Asia, albeit with greater penetration in the Russian market and Northern Europe. It should be noted that its lower layers are standardized by IEC 14908 [19]. • CX1 [20] is a Siemens-sponsored protocol that has a strong presence in Australia [10] and little impact in the other continents. Although it is promoted by Siemens, like OSGP, its lower layers are standardized by the IEC. • PRIME is a protocol promoted by the alliance PRIME and led by the two major Spanish electricity suppliers, Iberdrola and Unión Fenosa, currently known as Naturgy.
Although it is a protocol promoted by Spanish companies, PRIME is also in use in countries such as Portugal, United Kingdom, Poland, Brazil, and Australia. This protocol is based on the lower layer definition of NB-PLC systems based on multicarrier modulations using Orthogonal Frequency Division Multiplexing (OFDM) and operates in the CENELC A band, like most NB protocols, in PLC, and additionally in the FCC band (3-500 kHz). The protocol is standardized by the ITU-T (G.9904) [21]. • G3-PLC is a protocol developed by the French group EDF and Maxim. Like other analyzed protocols, G3-PLC uses multicarrier modulation, in particular orthogonal frequency division multiplexing. Although it has many similarities with PRIME, G3-PLC (G.9903) [22] was developed to increase the robustness of the communication by implementing channel coding. By implementing this outer layer, lower data rates are achieved, reaching up to 34 kbps in the CENELEC A band. Table 1 shows a small comparison between the NB-PLC technologies that are most prominent in the market, reflecting their main similarities and differences. It should be noted that despite the fact that they all operate in the CENELEC A band, there is an important difference in the type of modulation used, single-carrier or multicarrier. We find technologies such as OSGP or M & M that use the first variant. Thus, they achieve lower data rates but are more robust to the characteristic effects of this type of communication such as noise. In the second group, we find technologies such as PRIME or G3-PLC, which use OFDM modulation or AMC-SS and achieve data rates of up to 1 Mbps in the case of PRIME. BPL includes a variety of systems that target high data rates and operate at frequencies from 1 MHz to 250 MHz. BPL can be used in the low and medium voltage ranges [14] and enables multimedia communication in home networks in the first case and distribution automation, remote control, and even AMI in the second case. Besides the industrial solutions based on the OPERA specification, the main GLP-oriented standards using medium voltage and low voltage distribution infrastructures are IEEE 1901 (in particular the access system specification) and ITU-T G. 9960 (ITU-T G.hn) [23].

PRIME
The tools presented in this article, SimPRIME and PRIME Analytics, were developed based on the PRIME power line communication protocol. The second generation of this NB-PLC technology was initially developed by the PRIME alliance and adopted the physical layer (PHY), media access control (MAC), and convergence specifications developed by the ITU-T in 2012 in version 1.3.6 [22]. Later, in version 1.4, PRIME extends the range of frequencies used and adds some features to provide greater robustness of communication at the physical layer (PHY) and at the media access control layer (MAC).
As for the physical layer of the protocol PRIME, it uses different frequency bands depending on the version. Version 1.3.6 uses the frequency band 41-89 kHz, and version 1.4 uses the frequency band 3-500 kHz, using the modulation Orthogonal Frequency Division Multiplexing. The carriers used in PRIME can use different encodings, differential 8 phaseshift keying (D8PSK), differential quaternary phase-shift keying (DQPSK) or digital binary phase-shift keying (DBPSK). To increase the robustness of the communication, PRIME offers the possibility to interleave and encode the data before modulation, using forward error correction (FEC). Depending on the modulation and FEC used by PRIME, the data transmission rates of this protocol can range from 5.4 kbps to 1028.8 kbps.
For the MAC layer, PRIME sets up two different types of nodes: Base Node and Service Node. The base node has the task of acting as a coordinator in the PLC network; therefore, PRIME allows only one node of this type. In the terminology of Advanced Metering Infrastructure (AMI), the base node is called a data concentrator or concentrator. This node is responsible for receiving all communication from the other service nodes in the PRIME network in which it resides. The service nodes are usually smart meters that form the end point of the PRIME network. However, these nodes can also serve as switches if the quality of communication requires it. The use of these switches aims to increase the range of the signal, avoiding communication problems due to attenuation or noise. Due to this feature, the physical topology of these networks follows a bus topology, while the logical topology is of the tree type.
With respect to Media Access Control, PRIME sets up two access mechanisms. In the first, a common conflict time (SCP) is defined, and in the second, a conflict-free time (CFP). It should be noted that vendors currently implement only the first mechanism, SCP, which is based on Multiple Access by Carrier Detection with Collision Avoidance (CSMA/CA). Nevertheless, research continues on the use of PPC to support new intelligent network services [24].
In the convergence layer, we find the Logical Link Control (LLC) layer. This layer is responsible for managing the logical links of the PRIME network. It associates each transaction with a unique identifier and is responsible for controlling the flow of information. PRIME specifies a maximum transmission unit (MTU) and a sliding window system to perform flow control between its elements. Manufacturers encode this MTU in each smart meter and specify the maximum length of the MAC service data unit (MSDU) in bytes. However, it is possible to send a larger amount of data. For this, the LLC layer is responsible for fragmenting the data into multiple MSDUs without exceeding the maximum MTU size. Fragmentation involves tagging with an identifier so that the packet can be reassembled at the destination. As for the sliding window, PRIME implements a set of the maximum allowed values for the window size (WS), which are very important for performance related to latency. Another important point is the ability of the PRIME devices to implement automatic repeat requests (ARQ) or not, in case you want to avoid packet loss, this capability is implemented end-to-end. PRIME uses at the application level the device language message specification or complementary specification for energy measurement (DLMS / COSEM). More specifically, COSEM (IEC 62056-61/62) is a profile of the DLMS (IEC 62056-53) application protocol specifically designed for energy measurement [25,26]. DLMS/COSEM includes data models for representing common energy-related parameters and a communication protocol for transmitting this type of information.

IEEE 1901
SimBPL is based on IEEE 1901 [27], which is currently being used by Spanish DSOs, such as Iberdrola orUnión Fenosa.
The IEEE 1901 standard considers two different specifications for Medium Access Control (MAC)/Physical (PHY): the first is based on Fast Fourier Transform (FFT) and the second on wavelet. It also describes both broadband communications over MV and indoor broadband communications over LV. In detail, SimBPL implements the MAC /PHY specification based on FFT for MV distribution infrastructures.
In the PHY layer, IEEE 1901 uses Orthogonal Frequency Division Multiplexing (OFDM) as a modulation technique. The standard considers the frequency band between 2 to 30 MHz. However, most real implementations use two sub-bands within the 2 to 30 MHz band. The first, called Mode 1, varies operates in the sub-band from 2 to 7 MHz, and the second, called Mode 2, operates in the sub-band from 8 to 18 MHz. Mode 2 allows higher data rates but is also more sensitive to attenuation.
In this type of communication, data rates in MV links are asymmetric because they are affected by background noise between two substations. Currently, a performance requirement of at least 100 kbps applies to medium-voltage networks. However, raw data rates of around Mbps can be achieved in practice [14].
IEEE 1901 defines three different kinds of nodes, namely the Network Termination Units (NTUs), the Head-End (HE), and the Repeating stations (RSs). Although the underlying physical topology of MV networks fits a ringed-mesh topology, the communications overlay on top of it forms a tree-wise logical topology. As defined in the standard, such a tree may be different for data traffic and signaling, since faster data rates are targeted for the former, while more robust modulations are used for the latter [28]. In practice, however, the topology is defined manually.
NTUs represent the leaves of such a tree-like topology and work as gateways to networks located at lower levels of the hierarchical power distribution infrastructure (in this caseLV), RSs work as communication relays, and the HE coordinates intra-cell communication and also works as a gateway for backhaul communication.
In practice, however, the role of HE is split into two nodes: the master, which coordinates communication within the cell, and the gateway, which provides such backhaul communication capability. This division is due to the fact that, in practice, different criteria are used to select the master and the gateway. In principle, the node that has the smallest average distance to all other nodes in the cell is the perfect candidate for the role of master, while the selection of the gateway depends heavily on the communication equipment installed in the SSs. Nevertheless, it may happen that the roles of master and gateway are assigned to the same SS. (3) Distributed TDMA: the master only allocates time slots to its neighbors and delegates the responsibility of allocating time slots to their corresponding neighbors. SimBPL assumes centralized TDMA as a multiple access method.
TDMA is also used for planning MV -BPL networks by defining TDMA domains that operate in one of the aforementioned frequency bands and can coexist with neighboring TDMA domains that operate in another frequency band [14]. Analogous to cellular communication systems, frequency bands can be reused at a greater distance if an adequate guard distance is provided over MV cables to avoid interference or if smart notching techniques are applied to mitigate their effects, but at the expense of data rates [29].

Architecture of the Developed Web Applications
This section describes the architecture and technologies used for the developed toolkit, highlighting the main benefits they bring. Section 3.1 provides the architecture details for SimPRIME, Section 3.2 provides the architecture details for SimBPL, and Section 3.3 provides the architecture details for PRIME Analytics. Figure 1 shows an overview of the architecture and technologies used in the web application developed to ease the execution of SimPRIME simulations. It can be seen that the web application is mainly based on the Python web framework Django. In addition, Celery is used as a task manager and RabbitMQ as a queue manager. Celery and RabbitMQ allow executing the simulations in the background, thus favoring the scalability of the developed solution. Figure 1 also illustrates how the developed solution allows several users to execute simulations concurrently, each of them, in turn, being able to order several simulations one after the other asynchronously. (3) Distributed TDMA: the master only allocates time slots to its neighbors and delegates the responsibility of allocating time slots to their corresponding neighbors. SimBPL assumes centralized TDMA as a multiple access method.

SimPRIME
TDMA is also used for planning MV -BPL networks by defining TDMA domains that operate in one of the aforementioned frequency bands and can coexist with neighboring TDMA domains that operate in another frequency band [14]. Analogous to cellular communication systems, frequency bands can be reused at a greater distance if an adequate guard distance is provided over MV cables to avoid interference or if smart notching techniques are applied to mitigate their effects, but at the expense of data rates [29].

Architecture of the Developed Web Applications
This section describes the architecture and technologies used for the developed toolkit, highlighting the main benefits they bring. Section 3.1 provides the architecture details for SimPRIME, Section 3.2 provides the architecture details for SimBPL, and Section 3.3 provides the architecture details for PRIME Analytics. Figure 1 shows an overview of the architecture and technologies used in the web application developed to ease the execution of SimPRIME simulations. It can be seen that the web application is mainly based on the Python web framework Django. In addition, Celery is used as a task manager and RabbitMQ as a queue manager. Celery and Rab-bitMQ allow executing the simulations in the background, thus favoring the scalability of the developed solution. Figure 1 also illustrates how the developed solution allows several users to execute simulations concurrently, each of them, in turn, being able to order several simulations one after the other asynchronously.  Figure 2 shows an overview of the architecture and technologies used in the web application developed as an interface to the SimBPL simulator. It can be seen that the developed web application is based on a microservice architecture that involves several technologies. The core of the simulator has been translated from MATLAB to Python (which is license-free) and runs at the backend (at the server). The frontend (which runs in a web browser) is developed using the JavaScript-based open-source web framework AngularJS. Additionally, Node.js is used as a REST server to connect the frontend and the backend and to store the required information (e.g., configurations of simulation scenarios, results, etc.) in a NoSQL MongoDB database. Finally, as in the previous case, RabbitMQ and Celery are used as queue and task managers, respectively. Again, the Node.js REST server  Figure 2 shows an overview of the architecture and technologies used in the web application developed as an interface to the SimBPL simulator. It can be seen that the developed web application is based on a microservice architecture that involves several technologies. The core of the simulator has been translated from MATLAB to Python (which is license-free) and runs at the backend (at the server). The frontend (which runs in a web browser) is developed using the JavaScript-based open-source web framework AngularJS. Additionally, Node.js is used as a REST server to connect the frontend and the backend and to store the required information (e.g., configurations of simulation scenarios, results, etc.) in a NoSQL MongoDB database. Finally, as in the previous case, RabbitMQ and Celery are used as queue and task managers, respectively. Again, the Node.js REST In addition, the deployment of this application has been automated using Docker. together with RabbitMQ and Celery boost the scalability of the developed solution. In addition, the deployment of this application has been automated using Docker.  Figure 3 shows an overview of the architecture and technologies used in the web application developed to ease the execution of PRIME Analytics. As in the case of SimPRIME, the web application is mainly based on the Python web framework Django. In addition, PostgreSQL is used as database with Citus data extension, which transforms PostgreSQL into a distributed database to increase processing capacity and, again, scalability. The deployment of this application has been also automated using Docker to favor its portability and scalability.

PRIME Analytics
The main Python scripts take the input file uploaded by the user and apply different parsers and algorithms for data analysis and subsequent graphics display.  Figure 3 shows an overview of the architecture and technologies used in the web application developed to ease the execution of PRIME Analytics. together with RabbitMQ and Celery boost the scalability of the developed solution. In addition, the deployment of this application has been automated using Docker.  Figure 3 shows an overview of the architecture and technologies used in the web application developed to ease the execution of PRIME Analytics. As in the case of SimPRIME, the web application is mainly based on the Python web framework Django. In addition, PostgreSQL is used as database with Citus data extension, which transforms PostgreSQL into a distributed database to increase processing capacity and, again, scalability. The deployment of this application has been also automated using Docker to favor its portability and scalability.

PRIME Analytics
The main Python scripts take the input file uploaded by the user and apply different parsers and algorithms for data analysis and subsequent graphics display. As in the case of SimPRIME, the web application is mainly based on the Python web framework Django. In addition, PostgreSQL is used as database with Citus data extension, which transforms PostgreSQL into a distributed database to increase processing capacity and, again, scalability. The deployment of this application has been also automated using Docker to favor its portability and scalability.
The main Python scripts take the input file uploaded by the user and apply different parsers and algorithms for data analysis and subsequent graphics display.

Description of the Developed Toolkit
This section describes the details of the developed toolkit, paying special attention to how they work and to the features they offer. Section 4.1 provides the implementation details for SimPRIME, Section 4.2 provides the implementation details for SimBPL, and Section 4.3 provides the implementation details for PRIME Analytics.

SimPRIME
The developed web application consists of several screens. This section will focus on the screen of the web application, which allows configuring a new simulation and ordering its execution (shown in Figure 4), as well as on how this is made possible.

Description of the Developed Toolkit
This section describes the details of the developed toolkit, paying special attention to how they work and to the features they offer. Section 4.1 provides the implementation details for SimPRIME, Section 4.2 provides the implementation details for SimBPL, and Section 4.3 provides the implementation details for PRIME Analytics.

SimPRIME
The developed web application consists of several screens. This section will focus on the screen of the web application, which allows configuring a new simulation and ordering its execution (shown in Figure 4), as well as on how this is made possible. As Figure 4 shows, the application allows configuring the following parameters: • Name: It is recommended to enter names that allow easily identifying the simulation, as well as distinguishing it from similar ones. Nevertheless, the application assigns a unique identifier to each simulation (ID).

•
Duration: This field refers to the actual time to be simulated (in seconds). The simulation in principle will always take longer. It is recommended to establish a duration of more than 5000 s to ensure that the network is established and that measurements of the time to obtain consumption reports can be taken from all smart meters in the network (the so-called TTRAll). It is also recommended to avoid entering too high values to avoid that the simulations last too long.

•
Repetitions: The number of repetitions must be set considering the value entered in the "Duration" field. To obtain statistically significant results, it is necessary to have a minimum number of samples (e.g., more than 100). Therefore, considering that the time the network needs to get established is approximately 1000 s, if theoretically it is calculated that the time it takes for the concentrator to obtain a certain consumption report if all the smart meters in the network is 1000 s and a "Duration" equals to 5000 s is set, it would be known that four TTRAll values would be obtained in one execution. Therefore, if more than 100 values are wanted, a value greater than 25 should be entered in "Repeats". • Constellation: This drop-down allows selecting the constellation that the smart meter uses to transmit. Any of the constellations that the PRIME standard supports (i.e., DBPKS, DQPSK, D8PSK, with FEC OFF or ON) can be selected. If the "Dynamic" option is selected, the constellation is dynamically negotiated between each pair of nodes based on the channel conditions, as defined in the standard. By default, the most robust constellation is used (i.e., DBPSK with FEC ON). As Figure 4 shows, the application allows configuring the following parameters: • Name: It is recommended to enter names that allow easily identifying the simulation, as well as distinguishing it from similar ones. Nevertheless, the application assigns a unique identifier to each simulation (ID).

•
Duration: This field refers to the actual time to be simulated (in seconds). The simulation in principle will always take longer. It is recommended to establish a duration of more than 5000 s to ensure that the network is established and that measurements of the time to obtain consumption reports can be taken from all smart meters in the network (the so-called TTRAll). It is also recommended to avoid entering too high values to avoid that the simulations last too long. • Repetitions: The number of repetitions must be set considering the value entered in the "Duration" field. To obtain statistically significant results, it is necessary to have a minimum number of samples (e.g., more than 100). Therefore, considering that the time the network needs to get established is approximately 1000 s, if theoretically it is calculated that the time it takes for the concentrator to obtain a certain consumption report if all the smart meters in the network is 1000 s and a "Duration" equals to 5000 s is set, it would be known that four TTRAll values would be obtained in one execution. Therefore, if more than 100 values are wanted, a value greater than 25 should be entered in "Repeats". • Constellation: This drop-down allows selecting the constellation that the smart meter uses to transmit. Any of the constellations that the PRIME standard supports (i.e., DBPKS, DQPSK, D8PSK, with FEC OFF or ON) can be selected. If the "Dynamic" option is selected, the constellation is dynamically negotiated between each pair of nodes based on the channel conditions, as defined in the standard. By default, the most robust constellation is used (i.e., DBPSK with FEC ON). • Topology file: It can be a standard logical topology file in XML format (standard S11 report) or a compressed file (.ZIP) containing the actual power infrastructure topology in Shapefile format [30] together with an Excel file indicating the meters with and without communication capabilities in the considered scenario. • BER (Bit Error Rate). This parameter only takes effect when an S11 report is provided as a topology file. BER1 refers to the bit error rate between all nodes that are in the same logical level and BER2 to the bit error rate between nodes that are in contiguous logical levels, so BER1 must always be less than BER2. In principle, the current version of the simulator assumes that two nodes that are more than one logical level away cannot "see" each other (i.e., BER = 1). These values must be carefully set. If the values are set to high, the result may be that there is no communication between the nodes of the network and, therefore, no results of the execution are obtained. BERs are related to constellations (slower modulations have lower BERs, whereas faster modulations have higher BERs for the same SNR value). BER values in the range of 10 −4 -10 −5 are considered reasonable, with BER1 always being lower than BER2, as discussed above. • Report: Two types of reports are currently supported: S02 (incremental time curve) or S05 (daily billing) [31]. Based on the measurements made in the laboratory available at UC3M, the application-level size for the requests of both reports has been set to 70 bytes. In contrast, the size of the response associated with an S02 report at the application level has been set to 1568 bytes, and that of an S05 has been set to 646 bytes. • MTU (Maximum Transmission Unit): This field refers to the maximum payload size of the MAC layer in bytes. For example, if an S02 report is to be sent and 100 is entered in this field, 15 frames will be sent at the MAC layer with a payload of 100 bytes together with a last frame with a payload of 68 bytes. The maximum value that this field can take is 256 bytes, as indicated in the standard. • WS (Window Size): This field refers to the size of the data link layer transmission window (i.e., the number of packets that can be sent at the data link layer without needing to be acknowledged). For example, if "WS" is set to 1, each frame must be individually acknowledged (i.e., "stop and wait").

•
Polling Strategy: This drop-down allows establishing the polling strategy of the smart meters, being able to select "Sequential" (the concentrator is requesting the reports one by one) or "Simultaneous" (the concentrator requests all the reports at once by means of a broadcast message). The default strategy is "Sequential". • keepalive: This field represents the period in which the smart meters exchange keepalive messages with the concentrator (in seconds). Low values allow a vision of the status and topology of the network very accurately and promptly but overload the network with control traffic. High values reduce the possibility that such traffic negatively affects the performance of the network but also causes the information on the status and topology of the network to be outdated. The default value of this field is 120 s.
Real scenarios (deployed in the field), if the maps in Shapefile format that describe them are provided, or 2.
Synthetic scenarios, if S11 topology files are provided and the BER is specified between nodes at the same logical level (BER1) and between nodes at adjacent logical levels (BER2).
The first option may allow evaluating the configuration of the PRIME network that best fits a specific actual scenario, whereas the second one may allow evaluating which protocol parameters (e.g., MTU, WS) are more suitable depending on the network conditions. Figure 5 shows in detail how the inputs and outputs are processed and connected to the core of SimPRIME. One of the main inputs of the core of SimPRIME is the attenuation matrix between each pair of nodes in the network. Such a matrix allows calculating, based on knowledge of the transmission power of the sending node, the power received by all the nodes of the network and, therefore, given a reference noise level, obtaining the SNR (signal-to-noise) ratio for such a packet in all network nodes. In the first option described in the previous paragraph, such an attenuation matrix is obtained by applying Transmission Line Theory to the graph that is generated from the Shapefile map (module "Process SHAPEFILE" in Figure 5). In the second option, such a matrix is obtained from the bit error probabilities BER1 and BER2. on knowledge of the transmission power of the sending node, the power received by all the nodes of the network and, therefore, given a reference noise level, obtaining the SNR (signal-to-noise) ratio for such a packet in all network nodes. In the first option described in the previous paragraph, such an attenuation matrix is obtained by applying Transmission Line Theory to the graph that is generated from the Shapefile map (module "Process SHAPEFILE" in Figure 5). In the second option, such a matrix is obtained from the bit error probabilities BER1 and BER2.  Figure 6 shows the dashboard developed in this case. It can be seen that it is composed of three main areas: an area devoted to the representation of the cell (on the lefthand side), which allows creating and editing cells and checking their representation both in graph format and in table or matrix format (where each entry represents the distance between this pair of nodes); an area devoted to the configuration and execution of the simulations (on the right-hand side); and an area with a list of the executed simulations, which allows one to access the results by clicking on any of the links.   Figure 6 shows the dashboard developed in this case. It can be seen that it is composed of three main areas: an area devoted to the representation of the cell (on the left-hand side), which allows creating and editing cells and checking their representation both in graph format and in table or matrix format (where each entry represents the distance between this pair of nodes); an area devoted to the configuration and execution of the simulations (on the right-hand side); and an area with a list of the executed simulations, which allows one to access the results by clicking on any of the links.  Regarding the representation of the cell, it is worthwhile highlighting that in this 331 kind of cells there are two important roles: the master and the gateway. The master is re-332 sponsible for managing the communications (based on TDMA) within the cell. The gate-333 way oversees forwarding all the data to the backend of the utility (typically it is a node 334 equipped with broadband access equipment). The master is represented by a star and the 335 gateway is drawn in pink. Two different nodes may implement these two roles, as it is the 336 case shown in Figure 6. Regarding the representation of the cell, as was explained in Section 2.3, in this kind of cell, there are two important roles: the master and the gateway. The master is responsible for managing the communications (based on TDMA) within the cell. The gateway oversees forwarding all the data to the backend of the utility (typically it is a node equipped with broadband access equipment). The master is represented by a star, and the gateway is drawn in pink. Two different nodes may implement these two roles, as shown in Figure 6.

SimBPL
Regarding the configuration and execution of simulations, the following parameters can be configured [ • Constellation: drop-down that allows selecting any of the constellations defined in the standard. • Payload size: application payload size, which may allow simulating different services or applications (e.g., telecontrol may entail low payload sizes, whereas the aggregation of metering data may entail high payload sizes).
Once all these parameters are configured, it is possible to configure the number of runs to be simulated at the upper part of the menu (in pink).

PRIME Analytics
PRIME Analytics allows extracting information from NB-PLC PRIME operational networks by analyzing files accessible remotely through the data concentrator. Specifically, PRIME Analytics is specially designed to extract information that is relevant for the diagnosis and solution of problems that affect the communication performance of the networks under analysis.
As Figure 7 illustrates, it takes the following files as input: • Topology file: a standard S11 report in XML format; • Topology event file: a log of every change in the topology; • Traffic traces: a log of all messages processed by the data concentrator. Status of the logical topology, generated every minute, as well as a hierarchical diagram of the first snapshot of the selected interval; • TTRi (time required for the concentrator to retrieve a consumption report after the request has been made) vs. NID (SID + LNID); Likewise, the tool also provides the following information in table format: • List of nodes sorted by the number of unregistrations of the nodes depending on them; • List of nodes sorted by their number of unregistrations. Figure 7 illustrates the relationship between the inputs, that the tool considers and the output that it provides.  Figure 8 shows the web page developed in this case to upload a new scenario to be analyzed. It can be seen that this web page allows uploading the files generated by the PRIME concentrator (S11 file, topology file, and event file) associated with the scenario to be studied. Once the files are uploaded, the tool stores them in a database for subsequent  TTRi (time required for the concentrator to retrieve a consumption report after the request has been made) vs. NID (SID + LNID); Likewise, the tool also provides the following information in table format: • List of nodes sorted by the number of unregistrations of the nodes depending on them; • List of nodes sorted by their number of unregistrations. Figure 7 illustrates the relationship between the inputs, that the tool considers and the output that it provides. Figure 8 shows the web page developed in this case to upload a new scenario to be analyzed. It can be seen that this web page allows uploading the files generated by the PRIME concentrator (S11 file, topology file, and event file) associated with the scenario to be studied. Once the files are uploaded, the tool stores them in a database for subsequent analysis and representation of the information based on different graphs that allow the analysis and identification of possible problems registered in the PRIME network.

SimPRIME
The developed web application provides a list with the IDs of the ordered simulations. When any of these IDs are clicked, the application leads the user to a screen that shows a summary of the input parameters of this simulation, a table that allows tracking the process and status of the simulation, and several graphs. These graphs are box-andwhisker plots that represent the time that the concentrator needs to retrieve the reports

SimPRIME
The developed web application provides a list with the IDs of the ordered simulations. When any of these IDs are clicked, the application leads the user to a screen that shows a summary of the input parameters of this simulation, a table that allows tracking the process and status of the simulation, and several graphs. These graphs are box-and-whisker plots that represent the time that the concentrator needs to retrieve the reports from the smart meters in the network (TTRAll) and the time needed to read the report from each of the nodes in the network (TTRi). Figures 9 and 10 show examples of graphs of TTRAll and TTRi. Figure 9 gives an idea of the overall performance of the network. In particular, the graph shows the average time the concentrator needs to retrieve the report from all the smart meters in the network (in this case between 907.5 and 910 s) and the variance of this measure (edges of the plot and whiskers). This information may help, e.g., to set the periodicity to poll the smart meters in the PRIME network, which should be higher than the TTRAll. Figure 10 zooms in and gives an idea of the performance of each node in the network. In this case, nodes with IDs between 1 and 13 and between 50 and 60 work well, since the average time the concentrator needs to get their reports is low and the variance is also low. However, the graph also allows identifying a group of nodes (with IDs between 15 and 30) whose performance is much worse and may present communication problems, since the average and variance of their measures are high.  These graphs can be downloaded in several formats, and the raw data can be also downloaded to be further processed.   These graphs can be downloaded in several formats, and the raw data can be also downloaded to be further processed.

SimBPL
As shown in Figure 6, in the middle of the dashboard, there is a list of the ordered  These graphs can be downloaded in several formats, and the raw data can be also downloaded to be further processed.

SimBPL
As shown in Figure 6, in the middle of the dashboard, there is a list of the ordered simulations. This list includes the ID of the simulation, the number of runs, the furthest median (i.e., the worst case in the communication between any node of the cell and the gateway), and the last update. Figure 6 also illustrates the kind of figures that the application provides when clicking on any of the entries of the list. These graphs are again box-and-whisker plots of the time each node needs to communicate with the gateway. Figure 6 depicts the results for the cell shown on the left of the figure. The box-andwhisker plots give an idea of the average time the gateway needs to retrieve information from each node and of the variance of this measurement. In this case, the variation in the measurements is lower than in the previous section due to the use of TDMA. In the case of node 2, the result is 0 because it is indeed the gateway. If the application under study was, e.g., telecontrol, this information may be useful to determine whether the data exchange meets the requirements of the applications (i.e., if it is low and deterministic enough).
As in the previous section, these graphs together with the associated raw data can be downloaded to obtain the information shown in Figures 11 and 12.

PRIME Analytics
The developed web application provides a deep analysis of the files collected by the PRIME concentrator (S11, events file, and topology file). Each file pack is organized into the tool with a specific identifier, storing the data and allowing queries. After the files are processed, the tool shows different graphs with processed information that allows analyzing the behavior and status of the PLC network at specific time instants.
In general, PRIME Analytics tool is designed and developed to carry out an in-depth analysis of the messages exchanged in the PRIME networks, detecting errors and locating problematic nodes both logically and physically. This is of special importance for DSOs since it allows them to better plan and prepare the in-field operations.
The analysis of the graphical and tabulated information provided by PRIME Analytics may be used for different purposes. To illustrate the potential of PRIME Analytics for DSO, in the next sections, some use cases are analyzed.
A. Distinguishing between problematic and non-problematic scenarios.

PRIME Analytics
The developed web application provides a deep analysis of the files c PRIME concentrator (S11, events file, and topology file). Each file pack is the tool with a specific identifier, storing the data and allowing queries. Af processed, the tool shows different graphs with processed information th lyzing the behavior and status of the PLC network at specific time instants In this case, we present an example of how PRIME Analytics can be used to distinguish between problematic and non-problematic scenarios. Graphs of packet types provide useful information for this purpose. Figure 13 shows two graphs of packet types for two different scenarios. It can be observed that the ratio of ALV B versus ALV S (keepalive messages sent by the concentrator vs. keepalive messages sent by the service nodes) is higher in Figure 13a (12.1% vs. 4.6%) than in Figure 13b (43% vs. 40.6%). The higher this parameter, the more problems there will be in the communications, since it implies that more ALV messages sent by the concentrator remain unanswered (in an ideal situation, this ratio should be 1). Figure 13 also shows that the percentage of promotion requests (PRO REQ S) is much higher in Figure 13a (53.5%) than in Figure 13b (1.2%). A low percentage like the one in Figure 13b is associated with a simple and stable topology, while a high percentage like the one in Figure 13a is associated with a complex and dynamic topology, which may be due to frequent impedance variations or the appearance of impulsive noise. The average SNR graph is also useful for this purpose. Figure 14 shows such a for the same scenarios analyzed before. In Figure 14a, there are two large groups: on SNR above 18 dB, and another with SNR below 12 (which is the biggest one inde Figure 14b, however, all the nodes have an average SNR above 18 dB. Based on th ysis of these graphs, it can be concluded that in the scenario shown in Figure 14a t a group of nodes that present low-quality communications with the concentrator. The average SNR graph is also useful for this purpose. Figure 14 shows such a graph for the same scenarios analyzed before. In Figure 14a, there are two large groups: one with SNR above 18 dB, and another with SNR below 12 (which is the biggest one indeed). In Figure 14b, however, all the nodes have an average SNR above 18 dB. Based on the analysis of these graphs, it can be concluded that in the scenario shown in Figure 14a there is a group of nodes that present low-quality communications with the concentrator. Once the DSOs know that a given network is facing communication problems, it is very important to determine when they are happening. As has been already mentioned, the conditions in the PLC channels vary quite frequently, so it may happen that when the DSOs send their O&M crew to the field, the network is working again without problems. PRIME Analytics can be used to identify patterns in the communications problems and plan the in-field operation appropriately.
For the identification of problematic time intervals, the list of instants with the greatest number of unregistrations can be used. As an example of this, Figure 15 shows that, in the scenario under study, 817 smart meters unregister between 7:45 and 8:30 AM. Although it is not the case in this example, a similar analysis could be done to try to identify Once the DSOs know that a given network is facing communication problems, it is very important to determine when they are happening. As has been already mentioned, the conditions in the PLC channels vary quite frequently, so it may happen that when the DSOs send their O & M crew to the field, the network is working again without problems. PRIME Analytics can be used to identify patterns in the communications problems and plan the in-field operation appropriately.
For the identification of problematic time intervals, the list of instants with the greatest number of unregistrations can be used. As an example of this, Figure 15 shows that, in the scenario under study, 817 smart meters unregister between 7:45 and 8:30 AM. Although it is not the case in this example, a similar analysis could be done to try to identify patterns. In this case, this datum will be used to narrow down the diagnostics to find where the problem was and which nodes were involved, as explained in the next section. patterns. In this case, this datum will be used to narrow down the diagnostics to find where the problem was and which nodes were involved, as explained in the next section. C. Identifying problematic nodes within a problematic time interval.
As was just mentioned, once the DSO knows when a given network is facing problems, PRIME Analytics can be used for identifying where the problems are taking place and who are the nodes involved in such problems.
Regarding the identification of problematic nodes, if a time interval is selected that covers such a period and the number of switches is sorted by the number of unregistrations of their "children" (Figure 16), it can be observed which are the two switches from which more nodes unregister. In this example, from now on, these two switches will be referred to as SW1 (with MAC address ending in FA, with 226 unregistrations) and SW2 (with MAC address ending in 70, with 205 unregistrations).  C. Identifying problematic nodes within a problematic time interval.
As was just mentioned, once the DSO knows when a given network is facing problems, PRIME Analytics can be used for identifying where the problems are taking place and who are the nodes involved in such problems.
Regarding the identification of problematic nodes, if a time interval is selected that covers such a period and the number of switches is sorted by the number of unregistrations of their "children" (Figure 16), it can be observed which are the two switches from which more nodes unregister. In this example, from now on, these two switches will be referred to as SW1 (with MAC address ending in FA, with 226 unregistrations) and SW2 (with MAC address ending in 70, with 205 unregistrations). patterns. In this case, this datum will be used to narrow down the diagnostics to find where the problem was and which nodes were involved, as explained in the next section. C. Identifying problematic nodes within a problematic time interval.
As was just mentioned, once the DSO knows when a given network is facing problems, PRIME Analytics can be used for identifying where the problems are taking place and who are the nodes involved in such problems.
Regarding the identification of problematic nodes, if a time interval is selected that covers such a period and the number of switches is sorted by the number of unregistrations of their "children" (Figure 16), it can be observed which are the two switches from which more nodes unregister. In this example, from now on, these two switches will be referred to as SW1 (with MAC address ending in FA, with 226 unregistrations) and SW2 (with MAC address ending in 70, with 205 unregistrations).  Nodes can unregister because they lose connectivity or because some nodes in their communication path to the concentrator do so. In the graph of connections to switches for these two nodes, it can be observed that both SW1 and SW2 communicate with the concentrator through the same switch. Figure 17 shows the graph obtained when using the MAC address of SW2 as search criterion (it is the same for SW1). From now on, this SW with MAC address ending in 41 will be referred to as SW3. Nodes can unregister because they lose connectivity or because some nodes in their communication path to the concentrator do so. In the graph of connections to switches for these two nodes, it can be observed that both SW1 and SW2 communicate with the concentrator through the same switch. Figure 17 shows the graph obtained when using the MAC address of SW2 as search criterion (it is the same for SW1). From now on, this SW with MAC address ending in 41 will be referred to as SW3.  If switch SW3 is searched in the table of nodes sorted by the number of unregistrations (very similar to the one shown in Figure 16, but displaying nodes instead of Repeating the search with SW3 MAC address, it can be checked that this switch is directly connected to the concentrator (with MAC address ending in 30), as shown in Figure 18. Nodes can unregister because they lose connectivity or because some nodes in their communication path to the concentrator do so. In the graph of connections to switches for these two nodes, it can be observed that both SW1 and SW2 communicate with the concentrator through the same switch. Figure 17 shows the graph obtained when using the MAC address of SW2 as search criterion (it is the same for SW1). From now on, this SW with MAC address ending in 41 will be referred to as SW3.  If switch SW3 is searched in the table of nodes sorted by the number of unregistrations (very similar to the one shown in Figure 16, but displaying nodes instead of so it can be concluded that the problem is located downstream. If switches SW1 and SW2 are searched in this table, it can be also observed that they do not unregister in such an interval, so the problem is in the nodes connected to them. Analyzing the nodes with the highest number of unregistrations in that period, it can be observed that both are connected to switches SW1 and SW2, so the communication problem is located in the section that connects these nodes with their "parents". DSOs (Distribution System Operators) can accurately locate this part of the network using the MAC addresses of such nodes and the MAC addresses of switches SW1 and SW2.

Discussion
PLC technologies are very appropriate for Smart Grids in general and AMI in particular. One of their main advantages is that they use as a communication medium an infrastructure that is already deployed. However, this is also a source of problems, such as noise, impedance variability or the relationship of the communication performance with the grid topology itself, which may make, e.g., PRIME, which has been widely tested in Europe, present operational constraints affecting its performance in Brazil [32].
As a result, in recent years, more and more simulation and analysis tools have been developed to try to respond to the difficulties presented in this type of network and help DSO to deploy, manage, and operate them. In this paper, three tools focused on PRIME and BPL technologies have been shown, combining simulations with the remote evaluation of the network performance based on traffic traces available from concentrators.
Regarding PRIME simulators, much research has been carried out. Reference [33] focuses on the performance of multi-hope PLC networks, but modeling only the MAC layer, without considering channel modeling and communication errors. Reference [34], on the other hand, focuses very much on the PHY layer and the probability of error, but without paying attention to other parameters, such as the latency or the TTR, which are more representative for DSOs. The authors of [35] approach the problem of considering different layers in a very similar way as SimPRIME, abstracting the PHY layer from the upper layers by means of PER vs. SNR curves, but such curves are computed for a fixed packet length. Reference [36] also applies this approach, but PER is computed for a fixed packet length that is always set to the maximum allowed value, thus penalizing the control traffic, which is based on small packets and is critical for network operation. Nevertheless, [36] addresses such an interesting application for DSOs as the remote and massive upgrade of firmware in PRIME networks. More recently, references [37,38] stand out as two innovative approaches for simulating the PHY layer of NB-PLC technologies. The authors of [37] propose a new methodology for network scale simulation based on directly implementing an OFDM modulator in EMTP-ATP (electromagnetic transients programme-alternative transients programme). By configuring different OFDM parameters, both PRIME and G3-PLC are considered, observing that they are significantly affected in medium-voltage (MV) power line channels. Reference [38] presents an analysis that focuses on how the use of different error correction codes, mechanisms for suppressing noisy intercarriers, and adjusting the equalization curve affect the performance of PRIME and G3-PLC by using an innovative ad hoc virtual PLC lab, developed by the authors, which allows for replicable, fully automated, and cost-effective tests. SimPRIME addresses layers from the PHY layer up to the application layer, presenting a great trade-off between implementing such layers rigorously and providing metrics useful for DSOs. Thus, on the one hand, the BER depends on the selected coding scheme, the PER depends on the BER and on the length of the packet, and Data Link layer mechanisms, such as acknowledgements and ARQ (Automatic Repeat Requests) mechanisms, are accurately implemented. On the other hand, it provides metrics, such as the TTRAll or TTRi, which are meaningful for the deployment and planning of PRIME networks and have been widely used for assessing relevant applications for DSOs, such as performance evaluation [39] and replicability analysis [40] in AMI or DR [41]. In addition, to the best of the authors' knowledge, SimPRIME was the first PRIME simulator whose results were compared with measurements from a real operational PRIME network, obtaining acceptable accuracy [42], and is the first PRIME network simulator that can be run from a web application, which represents an important achievement in terms of usability and facilitates its use in industry.
Regarding BPL, efforts have been traditionally focused on indoor communication networks (e.g., for in-home multimedia communications). Thus, reference [43] presents a channel simulator for this kind of network that considers cable characteristics, cable lengths, and loads. Recently, attention has been also paid to other emerging applications. As a token of this, reference [44] focuses on the application of BPL to IoT, paying special attention to PHY aspects, and references [45,46] focus on applications of BPL for Smart Grids, thus being very related to SimBPL. In particular, reference [45] aims to evaluate by means of simulating how the throughput of BPL is influenced by channel conditions and the physical characteristics of the grid. Regarding the differences between this study and Sim BPL, although both focus on AMI, reference [45] focuses on BPL over low-voltage grids and SimBPL focuses on BPL over medium-voltage grids. In addition, reference [45] implements G.hn in the ns-3 network simulator, whereas SimBPL relies on an implementation of IEEE 1901 in Python. Regarding the similarities, both use license-free platforms, and the parameters that [45] conclude significantly influence the throughput (namely background noise, line length, number of branches, branch tap length, and terminal load branch impedance) are also considered in SimBPL. The authors of [46] aim to evaluate by means of simulation the impact of repeaters in the linear topology of distribution substations on BPL performance. To do so, laboratory and in-field tests are carried out, and the obtained results are used as inputs for the simulations. Reference [46] focuses on medium voltage and IEEE 1901, as SimBPL, although it uses ns-3 as a network simulator. Again, to the best of the authors' knowledge, all these tools do not provide a web-based interface to enable interacting easily with them remotely and are not designed for scaling up, as in the case of SimBPL.
Finally, monitoring, analysis, and grid conditioning in PLC operational networks were identified as key by industry since the earlier stages [47]. For some time now, much research has been carried out to monitor grid conditions (e.g., cable aging [48], fault detection [49,50]) based on measurements from the PLC communication networks already deployed. Even more recently, machine learning has been proposed to improve such grid monitoring mechanisms [51][52][53][54]. PRIME Analytics differ from these proposals in that it does not use PLC channel measurements to diagnose problems in the electrical grid, but it does use higher-level information from the PLC network, such as traffic traces and standard reports available in the concentrators, to diagnose problems in the PLC network itself. Thus, PRIME Analytics does not represent an alternative to such proposals, but it can be used in combination with them, especially when the communication problem is due to a grid problem (e.g., a cable cut). PRIME Analytics allows an operator to both detect and identify non-persistent problems in PRIME networks by analyzing a set of graphical and tabulated information, supporting programming and optimizing possible repairs in the field with a very small margin of error, since it locates the error in the logical segment of the PRIME network. Although PRIME Analytics has been used so far mainly for carrying out forensic analysis focused on the performance of PRIME networks in relevant scenarios for DSOs such as to assess the impact of different sources of noise [55], it has also been used to detect cybersecurity problems in PRIME networks [56], presenting a great research potential in this line.
Overall, we believe that the toolkit presented in this paper stands out for its comprehensiveness and versatility, in that it covers not only simulation tools but also analysis tools for both PRIME and BPL, as well as for the scalability and usability provided by the web-based software architecture and interfaces.

Conclusions
The usefulness of simulation and analysis tools for PLC networks is irrefutable. However, the typical complexity and learning curves of network simulators and the understanding of the networks for their analysis hinder their use.
Web applications represent a gentle, portable, and scalable solutions to this problem. This paper presents three web applications developed to ease the execution of: (1) simulation using SimPRIME (simulation of NB-PLC PRIME networks), (2) simulation using SimBPL (simulation of MV-BPL cells), and (3) PRIME Analytics (analyzing and diagnosing communication problems in NB-PLC PRIME networks). Solutions (1) and (3) are based on the Python web framework Django, whereas solution (2) is based on a microservice architecture that combines different technologies for the front-end (e.g., AngularJS) and backend (e.g., Node.js, Python).
Ease of development might be highlighted as the main advantage of solution (1) and solution (3), since only Python skills would be required, whereas full-stack development skills would be required for solution (2). Although both solutions incorporate technologies to boost scalability, such as RabbitMQ for queue management and Celery for task management, the higher modularity of solution (2) makes it stand out in terms of flexibility. The use of Citus in solution (3) to parallelize the workload makes it also very scalable.
A clear analogy can be drawn between these web applications for PLC simulations and main Cloud service models, namely SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service). In IaaS, the cloud provider provides the computer, storage, network, and other critical computing resources. This service is generally provided to companies with powerful IT staff who are willing to configure their IT infrastructure but not host it. An example of this type of service would be virtual machines or containers. In PaaS, companies build their solutions on top of the applications developed or purchased by the cloud provider using APIs (Application Programming Interfaces), libraries, services, and other tools supported by the cloud provider. This service is usually used by companies whose main business is the development of applications or solutions. An example of this type of service would be IoT platforms, such as Microsoft Azure IoT Hub, AWS IoT, or Google Cloud IoT. Finally, in SaaS, end users use vendor applications running on cloud infrastructure. Examples of this type of service are Dropbox, Google Drive, or Microsoft Teams. Therefore, the toolkit presented in this paper, although not yet running on a cloud infrastructure, is an SaaS-wise solution in the sense that users only use the software through a user-friendly interface, but they are not aware of the underlying complexity.
As in the case of SaaS, these types of web applications can dramatically increase the use of PLC simulators and PLC network analytics. They can help accelerate researchers' progress in facilitating the use of these types of tools by utility operators who are not familiar with network analyzer and simulator environments or in facilitating their use in academic settings (for example, laboratories), thus also helping to make PLC technologies more popular.
The core of this work has been carried out by a research project funded by the Spanish government under contract OSIRIS (RTC-2014-1556-3), counting with the leadership of a global DSO such as UFD and the participation of several smart meters manufacturers needing to design, develop, and evaluate tools that allow detecting or evaluating communication errors in NB-PLC networks and providing design criteria for BPL deployment.