Networking layer specification - ebalanceplus

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grand agreement N°864283

AUTHORS : MANUEL DÍAZ RODRÍGUEZ DATE : 29.07.2020 DANIEL GARRIDO MÁRQUEZ

CRISTIAN MARTÍN FERNÁNDEZ PILAR RODRÍGUEZ PINOS KRZYSZTOF PIOTROWSKI

Networking layer specification

Deliverable D5.1


2

This project has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under Grant Agreement N°864283

Technical References

1 PU = Public

PP = Restricted to other programme participants (including the Commission Services)

RE = Restricted to a group specified by the consortium (including the Commission Services)

CO = Confidential, only for members of the consortium (including the Commission Services)

Document history V Date Beneficiary Author

0 20/05/2020 UMA Pilar Rodríguez

1 07/07/2020 UMA

IHP

Cristian Martín Fernández

Daniel Garrido Márquez

Manuel Díaz Rodríguez

Pilar Rodríguez

Krzysztof Piotrowski

2 24/07/2020 CEMOSA

UNC

Jacobo Peralta Escalante

Anna Pinnarelli

Project Acronym ebalance-plus

Project Title Energy balancing and resilience solutions to unlock the flexibility and

increase market options for distribution grid

Project Coordinator CEMOSA

Project Duration 42 months

Deliverable No. D5.1

Dissemination level 1 PU

Work Package WP5 Communication Platform and system integration

Task T5.1 Networking layer

Lead beneficiary UMA

Contributing

beneficiary(ies) IHP

Due date of

deliverable 31 July 2020

Actual submission

date 29 July 2020


3


Summary

1.1 Summary of Deliverable

This document introduces the baseline of the platform’s communication design and implementation. With this purpose, the document collects information about the ebalance-plus platform architecture, the main components and types of networking involved to provide communication between them. The most relevant communication technologies and protocols are analyzed for the selection and development of the protocols stacks that guarantees the interoperability between the system components, as well as the reliability and scalability of the energy balancing platform.

Disclaimer Any dissemination of results must indicate that it reflects only the author's view and that the Agency (INEA) and the European Commission are not responsible for any use that may be made of the information it contains.


4


Table of Contents

TECHNICAL REFERENCES ................................................................................................ 2

DOCUMENT HISTORY ......................................................................................................... 2

SUMMARY ............................................................................................................................ 3

1.1 SUMMARY OF DELIVERABLE...................................................................................... 3

DISCLAIMER ........................................................................................................................ 3

TABLE OF CONTENTS ........................................................................................................ 4

1 INTRODUCTION ..................................................................................................... 10

2 EBALANCE-PLUS ARCHITECTURE ..................................................................... 10

3 ANALYSIS OF THE COMMUNICATION TECHNOLOGIES FOR SMART GRID .... 13

3.1 NETWORK LEVELS.................................................................................................. 13 3.2 REQUIREMENTS FOR COMMUNICATIONS IN SMART GRID ........................................... 16 3.3 ANALYSIS OF WIRED TECHNOLOGIES ....................................................................... 17 3.4 ANALYSIS OF WIRELESS TECHNOLOGIES .................................................................. 18 3.5 COMMUNICATION PROTOCOLS FOR AUTOMATION PROCESSES .................................. 24

4 COMMUNICATION TECHNOLOGIES FOR EBALANCE-PLUS ............................. 43

4.1 COMMUNICATION BETWEEN MANAGEMENT UNITS .................................................... 43 4.2 DEMO SITES TECHNOLOGIES .................................................................................. 43 4.3 COMMUNICATION PROTOCOLS STACK ...................................................................... 50

5 CONCLUSION ......................................................................................................... 56

ANNEX 1: COMPARISON OF TECHNOLOGIES FOR SMART GRID ............................... 57

REFERENCES .................................................................................................................... 59

bookmark://_Toc46885495/#_Toc46885495

bookmark://_Toc46885496/#_Toc46885496

bookmark://_Toc46885497/#_Toc46885497

bookmark://_Toc46885498/#_Toc46885498

bookmark://_Toc46885499/#_Toc46885499

bookmark://_Toc46885500/#_Toc46885500

bookmark://_Toc46885501/#_Toc46885501

bookmark://_Toc46885502/#_Toc46885502

bookmark://_Toc46885503/#_Toc46885503

bookmark://_Toc46885504/#_Toc46885504

bookmark://_Toc46885505/#_Toc46885505

bookmark://_Toc46885506/#_Toc46885506

bookmark://_Toc46885507/#_Toc46885507

bookmark://_Toc46885508/#_Toc46885508

bookmark://_Toc46885509/#_Toc46885509

bookmark://_Toc46885510/#_Toc46885510

bookmark://_Toc46885511/#_Toc46885511

bookmark://_Toc46885512/#_Toc46885512

bookmark://_Toc46885513/#_Toc46885513

bookmark://_Toc46885514/#_Toc46885514

bookmark://_Toc46885515/#_Toc46885515


5


Table of tables Table 1 Network requirements for different applications ...................................................... 15 Table 2 Smart Grid requirements......................................................................................... 16 Table 3 Narrow Band PLC features ..................................................................................... 18 Table 4 Broadband PLC features ........................................................................................ 18 Table 5 GSM/GPRS, wireless technology ........................................................................... 19 Table 6 CDMA wireless technology ..................................................................................... 19 Table 7 LTE wireless technology ......................................................................................... 20 Table 8 Benefits of 5G network in Smart Grids .................................................................... 22 Table 9 NB-IoT wireless technology features for IoT in Smart Grid...................................... 22 Table 10 ZigBee wireless technology features for IoT in Smart Grid .................................... 23 Table 11 Z-Wave wireless technology features for IoT in Smart Grid .................................. 23 Table 12 WiMAX wireless technology features for IoT in Smart Grid ................................... 23 Table 13 LoRa wireless technology features for IoT in Smart Grid ...................................... 24 Table 14 UNC technical specifications ................................................................................ 51 Table 15 UMA technical specifications ................................................................................ 53 Table 16 YNC technical specifications ................................................................................. 54 Table 17 DTU technical specifications ................................................................................. 55

Table of figures Figure 1 The ebalance-plus SGAM model ........................................................................... 11 Figure 2 ebalance-plus communication architecture ............................................................ 11 Figure 3 Network areas in ebalance-plus............................................................................. 14 Figure 4 5G network slicing ................................................................................................. 21 Figure 5 Roadmap architecture of 5G and smart grids ........................................................ 21 Figure 6 EEbus communication stack .................................................................................. 25 Figure 7 Substation architecture .......................................................................................... 27 Figure 8 Suite of IEC61850 protocols .................................................................................. 27 Figure 9 6LoWPAN protocol architecture............................................................................. 30 Figure 10 The reference model of the 6LoWPAN protocol stack.......................................... 30 Figure 11 Wireless HART communication architecture ........................................................ 31 Figure 12 MODBUS communication stack ........................................................................... 32 Figure 13 MODBUS architecture ......................................................................................... 33 Figure 14 OPC UA Communication layers ........................................................................... 35 Figure 15 OPC UA architecture layers ................................................................................. 36 Figure 16. Meter and More architecture ............................................................................... 37 Figure 17 BACnet architecture ............................................................................................ 38 Figure 18 KNX model .......................................................................................................... 39 Figure 19 CoAP communication pattern .............................................................................. 40 Figure 20 MQTT client publishing communication pattern ................................................... 41 Figure 21 MQTT publish-subscribe communication pattern ................................................. 41 Figure 22 Electric vehicle charging infrastructure and interface standards ........................... 42 Figure 23 University of Calabria pilot ................................................................................... 44 Figure 24 UNC pilot, connectivity scheme ........................................................................... 45 Figure 25 University of Malaga pilot ..................................................................................... 46 Figure 26 UMA pilot, connectivity scheme ........................................................................... 47 Figure 27 Yncréa Hauts-de-France engineering school pilot ............................................... 48 Figure 28 YNC pilot, connectivity scheme ........................................................................... 48 Figure 29 Technical University of Denmark pilot .................................................................. 49 Figure 30 DTU pilot, connectivity scheme ............................................................................ 49 Figure 31 UNC logical scheme ............................................................................................ 51 Figure 32 UNC protocols stacks .......................................................................................... 52

bookmark://_Toc46885457/#_Toc46885457

bookmark://_Toc46885458/#_Toc46885458

bookmark://_Toc46885459/#_Toc46885459

bookmark://_Toc46885460/#_Toc46885460

bookmark://_Toc46885461/#_Toc46885461

bookmark://_Toc46885462/#_Toc46885462

bookmark://_Toc46885463/#_Toc46885463

bookmark://_Toc46885464/#_Toc46885464

bookmark://_Toc46885465/#_Toc46885465

bookmark://_Toc46885466/#_Toc46885466

bookmark://_Toc46885467/#_Toc46885467

bookmark://_Toc46885468/#_Toc46885468

bookmark://_Toc46885469/#_Toc46885469

bookmark://_Toc46885470/#_Toc46885470

bookmark://_Toc46885471/#_Toc46885471

bookmark://_Toc46885472/#_Toc46885472

bookmark://_Toc46885473/#_Toc46885473

bookmark://_Toc46885474/#_Toc46885474

bookmark://_Toc46885475/#_Toc46885475

bookmark://_Toc46885476/#_Toc46885476

bookmark://_Toc46885477/#_Toc46885477

bookmark://_Toc46885478/#_Toc46885478

bookmark://_Toc46885479/#_Toc46885479

bookmark://_Toc46885480/#_Toc46885480

bookmark://_Toc46885481/#_Toc46885481

bookmark://_Toc46885482/#_Toc46885482

bookmark://_Toc46885483/#_Toc46885483

bookmark://_Toc46885484/#_Toc46885484

bookmark://_Toc46885485/#_Toc46885485

bookmark://_Toc46885486/#_Toc46885486

bookmark://_Toc46885487/#_Toc46885487

bookmark://_Toc46885488/#_Toc46885488


6


Figure 33 UMA logical scheme ............................................................................................ 52 Figure 34 UMA protocols stacks .......................................................................................... 53 Figure 35 YNC logical scheme ............................................................................................ 54 Figure 36 YNC protocols stacks .......................................................................................... 54 Figure 37 DTU logical scheme ............................................................................................ 55 Figure 38 DTU protocols stacks .......................................................................................... 55

bookmark://_Toc46885489/#_Toc46885489

bookmark://_Toc46885490/#_Toc46885490

bookmark://_Toc46885491/#_Toc46885491

bookmark://_Toc46885492/#_Toc46885492

bookmark://_Toc46885493/#_Toc46885493

bookmark://_Toc46885494/#_Toc46885494


7


List of Abbreviations

Abbreviations Definitions 3GPP 3rd Generation Partnership Project 4G Fourth Generation 5G Fifth Generation 6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks AC Alarm & Conditions AMI Advanced Metering Industrial AMQP Advanced Message Queuing Protocol API Application Programming Interface ASCI Abstract Communication Service Interfaces ASCII American Standard Code for Information Interchange ASHRAE American Society of Heating, Refrigerating and Air Conditioning Engineers BACnet Building Automation and Control network BACnet MS/TP BACnet Master-Slave Token Passing BACnet/SC BACnet Secure Connect BAN Building Area Network BAS Building Automation System BB-PLC Broadband PLC BMS Building Management System BPSK Binary Phase-Shift Keying CDMA Code Division Multiple Access CMS Central Management System CMU Customer Management Unit CoAP Constrained Application Protocol COSEM Companion Specification for the Energy Metering CSMA Carrier Sense Multiple Access CSMACA CSMA with Collision Avoidance CSMS Charging Station Management System D2D Device-to-Device DA Data Access DDS Data Distribution Service DER Distributed Energy Resources DERMU Distributed Energy Resources Management Unit DL Data Link DLMS Device Language Message Specification DMS Distribution Management System DMU Device Management Unit DNP3 Distributed Network Protocol DNS Domain Name System DNS-SD DNS Service Discovery DRM Demand Response Management DSL Digital Subscriber Line DSSS Direct Sequence Spread Spectrum DTLS Datagram Transport Layer Security E2E End-to-End EVSE Electric Vehicle Supply Equipment FAN Field Area Network FDIR Fault, Detection, Isolation and Restoration FHSS Frequency Hopping Spread Spectrum FPGA Field Programmable Gate Array FSK Frequency Shift Keying FTTH Fiber to the Home


8


G2V Grid to Vehicle GOOSE Generic Object Oriented Substation Event GPRS General Packet Radio Service GSM Global System for Mobile HA Historical Access HART Highway Addressable Remote Transducer HHU Hand-Held Unit HLDC High Level Data Control HMI Human Machine Interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol HTTPS HTTP Secure HV High Voltage HVAC Heating, Ventilation, Air Conditioning IAN Industrial Area Network IEC International Electromechanical Commission IED Intelligent Electronic Device IoT Internet of Things IP Internet Protocol ISA International Society of Automation ISM Industrial, Scientific and Medical (band) IWSN Industrial Wireless Sensor Network Li-Fi Light Fidelity LLC Logical Link Control LonWorks Local Operation Network LOS Loss of Signal LPWAN Low Power Wide Area Network LR-WPAN Low-Rate Wireless Personal Area Networks LTE Long Term Evolution LV Low Voltage LV-GMU Low Voltage Grid Management Unit M2M Machine-to-Machine MAC Medium Access Control mCHP micro Combined Heat and Power mDNS Multicast Domain Name System MIMO Massive Multiple-input Multiple-output MMS Manufacturing Message Specification MPLS MultiProtocol Label Switching MQTT Message Queue Telemetry Transport MV Medium Voltage MV-GMU Medium Voltage Grid Management Unit NAN Neighborhood Area Network NB-IoT Narrow Band IoT NB-PLC Narrowband PLC NFV Network Function Virtualization NLOS Non-Line of Sight NR New Radio NWK Network OCA Open Charge Alliance OCPP Open Charge Point Protocol OFDM Orthogonal Frequency Division Multiplexing OPC UA Open Protocol Communication United Architecture O-QPSK Offset-Quadrature Phase Shift Keying ORM Outage and Restoration Management PCL Power Communication Line


9


PDCP Packet Data Convergence Protocol PLC Programmable Logic Controller PRIME PoweRline Intelligent Metering Evolution PS Primary Substation PSK Pre-Shared Key QoS Quality of Service RBE Report-by-Exception RESTFUL Representational StateTransfer RPK Random Pair-wise Key RTU Remote Terminal Unit SCADA Supervisory Control and Data Acquisition SDN Software Defined Networks SEB Monitoring and Control System SG Smart Grid SGAM Smart Grids Architecture Mode SHIP Smart Home IP SLA Service Level Agreement SME SHIP Message Exchange SOAP Simple Object Access Protocol SOH State of Health SPINE Smart Premises Interoperable Neutral Message Exchange SS Secondary Substation SUN Smart Utility Network TCP Transport Control Protocol TDMA Time Division Multiple Access TL_GMU Top Level Grid Management Unit TLS Transport Layer Security TSO Transmission System Operator UDP Unit Datagram Protocol V2B Vehicle to Building V2G Vehicle-to-Grid WAN Wide Area Network Wi-Fi Wireless Fidelity WiMAX Worldwide Interoperability for Microwave Access WP Work Packet WSN Wireless Sensors Network


10


1 Introduction The ebalance-plus project aims to provide an energy monitoring platform characterized

by the flexibility of smart grid solutions, ensuring the flexibility, the security, the stability, the resilience and scalability of the distribution grid. To guarantee the integration and interoperability of the different domains involved, this document carries out a thorough study of the trends in the area of communication technologies, standards and protocols, focusing on the role of communication and networking in the evolution from the traditional electric power grid to smart grids. First of all, the hierarchical ebalance-plus architecture is depicted in Section 2, pointing out the communication flows between the main components. Section 3 presents the network types applied to the different levels of the smart grid and an analysis of the principal communication technologies used to support each one attending the smart grid requirements, followed by the most relevant communication protocols and standards in the energy sector. Section 4 offers an approach about suitable communication protocols stacks to support the different demo sites developed in the project. This section includes a physical and logical description of the entities that implement each demo site: the connection schemes, systems and devices involved to establish the baseline to implement a proper communication stack. The analysis carried out throughout this document allows to identify the future direction toward a reliable and efficient deployment of a networking stack.

2 ebalance-plus architecture The ebalance-plus concept comprises a set of relevant components, the management

units, that increase the flexibility of the energy platform employing smart-grid solutions. Figure 1 The ebalance-plus SGAM model , represents the five layers of ebalance-plus concept translated into the Smart Grids Architecture Model (SGAM). In ebalance-plus, customer premises, Distributed Energy Resources (DER) and distribution grids are considered the domains that comprise the bottom layer. The second layer is composed of the seven technologies developed within ebalance-plus project to increase the flexibility and the distribution grid observability. In the third layer, we can see the management units that control the different fields and components. The fourth layer is where the user’s interfaces and the different components exchange information to increase the interoperability for prosumers or increase the grid resilience for Distribution System Operators (DSO). Finally, the business layer is on top, where the main component is the energy aggregator.


11


Figure 1 The ebalance-plus SGAM model

The ebalance-plus model is based on a hierarchical architecture to ensure scalability, where each management unit is coordinating a lower level, as shown in Figure 2. The management units and technologies implemented in the ebalance-plus project are described in the Grant Agreement document and the Work Package 3 (WP3). Next, the communication flows between the main components are addressed to define the different levels from the point of view of the communication networking.

Figure 2 ebalance-plus communication architecture


12


The management units are:

• Top Level Grid Management Unit, (TL-GMU). This is the core of the Smart Grid

distribution intelligence. It is in charge of the management and control commands in

the downstream, and is also responsible for data reception from the systems and

devices that lie in lower levels.

• MV Grid Management Unit, (MV-GMU). This unit installed in the Primary Substation

(PS), (High Voltage-Medium Voltage, HV/MV), at MV level controls all the Low Voltage

GMU (LV-GMU) below this PS, and provides flexibility to the next level, Distribution

System Operators - Transmission System Operator, (DSO-TSO). Moreover, this unit

provides resilience mechanisms to optimize power flows and to apply “Fault, Detection,

Isolation and Restoration” (FDIR) services.

• LVGrid Management Unit, (LV-GMU). This unit installed in the secondary Substation

(SS), (Medium Voltage -Low Voltage, MV/LV), at LV level is responsible for providing

information about quality parameters from all Costumer Management Units (CMU),

Distributed Energy Resources Management Units (DERMU) and smart-grid

technologies allocated in the same LV distribution grid.

• Customer Management Unit, (CMU). This unit controls smart-appliances, collects

consumption information and energy quality parameters from the smart-meter, and

manages the power level of the power inverters supplying local renewable sources.

• DER Management Units, (DERMU). The DERMU is installed along with every DER

asset for managing and exploiting the DER by exchanging commands with the

ebalance-plus platform.

Figure 2 ebalance-plus communication architecture, shows a communication architecture on four levels:

The top-level corresponds with the Central Management Systems (CMSs), where the TL-

GMU resides. As mentioned before, the information from the systems and devices in lower layers is received by an upstream communication link whereas it can send commands to them by a downstream one.

The second level is constituted by the PSs. Each one has an MV-GMU, being responsible for collecting the data from sensors and issuing control commands to MV actuators located within the PS. MV-GMU interacts with DERMUs as well as with LV-GMUs located at the SSs.

The next level is composed by the SSs, which are in charge of the LV energy distribution at the neighborhood scale. In the same manner that PS, each SS comprises an LV-GMU, which receives data from LV sensors, smart meters and DERs located in LV level and delivers management and control commands to LV actuators and DERs. Finally, the prosumer premises constitute the bottom and fourth level. On this level the smart meter is directly connected to the CMU, the smart meter controls advanced power functionalities and manages the power outputs of energy based on the set points issues by the LV-GMU. At the device level, the Device Management Unit (DMU) interacts locally with smart device sensors and actuators.

The location and information exchange between the main components of the ebalance-plus platform give us a better insight into the network areas that will address the communication needs of the entities involved in the hierarchical architecture.

Communication between the TL-GMU, MV-GMUs and LV-GMUs is performed through a Wide Area Network (WAN) to cover the large geographical deployment that comprises the top levels of the architecture.


13


In a Primary Substation, we can find a local grid subnet composed of sensor/actuator nodes that along with DERMUs are available to communicate with MV-GMU through the MV Field Area Network (MV-FAN).

The lower level is constituted by Secondary Substations, which are responsible for LV energy distribution. Connectivity between the LV-GMU, smart meters, LV field sensors/actuator and DERMUs is accomplished through the LV Field Area Network (LV-FAN) .

A Home Area Network (HAN) is used at the bottom level made up of prosumer premises. The smart meter is directly connected to the CMU and it is connected to appliance sensors, actuators and DMUs.

3 Analysis of the communication

technologies for Smart Grid In the context of Smart Grid, the main objectives of the communication network are: to be

able of guaranteeing reliable, secure and real-time data collection from a massive number of

data sources and to support the interoperability between heterogeneous technologies and

communication services.

3.1 Network levels

The Smart Grid communication infrastructure is commonly seen as a hierarchical network with three-tier architecture: Access tier. The network should support real-time information flows between customer and energy management systems. In this tier, the HAN is applied because it can provide low-cost solutions for monitoring and control of electric devices deployed at customers’ premises. In the case of HAN gateways, these should be equipped with multiple radio interfaces to facilitate the integration of different devices. The access tier must also provide connectivity services for electric vehicles. For services that support Vehicle-to-Grid (V2G), wireless technologies seem the most appropriate choice, but some use cases have shown to require different networking solutions. Distribution tier. This tier of the communication network enables the state, data estimation and

real-time control of the distribution grid. It interconnects the local area networks (i.e. Home

Area Network (HAN)/Building Area Network (BAN)/Industrial Area Network (IAN)) with the

smart grid communication backbone and provides the communication support to implement

data management services to handle the large amount of data collected in the distribution grid.

The distribution tier includes specialized networks to provide reliable communication to a large

number of heterogeneous sensors and actuators, and to monitor and control power system

equipment, Field Area Networks (FAN) or Neighborhood Area Networks (NAN).

Core tier. The network used here is a WAN to create a high-capacity communication backbone

capable of delivering a large amount of data collected by the FANs to remote control centers

over long distances. There are several options for the WANs deployments such as all Internet

Protocol (IP) core network or MultiProtocol Label Switching (MPLS) but, for electric utilities, a


14


relevant option is the deployment of private WANs and to use public data networks to link

them.

The selection of network type depends mainly on requirements like data rate, coverage

range and latency. Following a brief description of the network types participants in the

ebalance-plus platforms, Table 1 Network requirements for different applications shows some

examples of values for the network requirements for different applications.

Figure 3 Network areas in ebalance-plus

Home Area Network, HAN

The HAN is at the customer’s premises and it is the end of the network architecture. It

provides communication for household appliances and equipment, which send and receive

signals from a smart meter. The customer’s premise is connected to other smart grid entities

like electric utility or third-parties via a smart meter or a gateway.

Field and Neighborhood Area Network, FAN/NAN

A NAN/FAN supports communication between WAN and a premise area. It enables

data collection from customers and connects with field devices such as intelligent electronic

devices (IED). FAN includes a metering network that enables services such as remote

meter/reading, control and events detection. The applications supported by FAN require higher

data rate and larger coverage range than HAN applications.

Wide Area Network, WAN

WAN supports real-time monitoring, control and protection of the state of the smart grid.

It also provides communication links for the smart grid backbone and covers long distances

from FAN to the control center. These Wide-area functionalities involve high data rates and

shorter response times.


15


Network Application Data size

(bytes) Latency

Reliability

(%)

HAN Home automation 10-100 Seconds >98

Building automation >100 Seconds >98

FAN

Meter reading – on-demand

(from meters to utility) 100 <15s >98

Pricing (from utility to smart

meter) 100 <1 min >98

Electric service prepayment

(from utility to customers) 50-150 <30s >98

Demand response (from

utility to customer devices) 100 <1min >99.5

Distribution automation (from

field devices to DMS) 100-1000 <5s >99.5

Distribution automation (from

field devices to DMS) 100-250 <5s >99.5

Distribution automation -FCIR

(commands from DMS to field

devices)

25 <5s >99.5

Outage and Restoration

Management (ORM) (from

meters to OMS)

25 <20s >98

Customer information and

messaging customers

request account info from

utility/utility responds to

customers)

0 <20s >98

WAN

Wide-area protection 4-157 <0.1s >99.9

Wide-area control 4-157 < [5s-2min] >99.9

Wide-area monitoring >52 <[0.1s-2min] >99.9

Table 1 Network requirements for different applications


16


3.2 Requirements for communications in Smart Grid

To identify which communication technologies are suitable for Smart Grid, it is necessary

to define the basic requirements that should be covered. Table 2 Smart Grid requirements lists

the basic requirements that the communication technologies should fulfil for Smart Grid.

Requirement Description Range values for SG

Coverage/Frequenc

y Impact of the used band. <1 GHz

Capacity Ability to fulfil indoor/outdoor

Smart Grid application needs. Depend on application

Scalability Ability to integrate a fast-growing

very high number of M2M devices.

Security

Robustness against failures and

attacks (physical and network

attacks).

Mechanisms for authentication,

encryption, trust management and

intrusion

Latency

Time taken for a packet to travel

from a point to another in the

network.

<100ms network-oriented-application

>100ms End-customer-oriented-

services

Throughput Data volume traffic between SG

components. ≈ Kbytes

Reliability

Capacity to continue generating

power with an acceptable degree

of quality against a fault.

• 8-12 h

• up to 72h for critical services

and sites

Availability

End2End service availability in

Smart Grid depends on location

and time availability

• SG application 95-99 %

• SG infrastructure <90

Costs

Price of a single communication

service.

Price of installation of a

communication interface at the

customer premises.

• Coverage-capacity-operation

• Cabling-power supply-house

owner consent

Control The advisability of relying on a

commercial network Dedicated Wireless/Mobile network

Lifetime

Technology life-cycle/system

availability

The main underlying technology

should be standardized

At least 15 years

Table 2 Smart Grid requirements


17


There are many studies [1], [2] and pilots evaluating communication technologies based on a comparison of a set of parameters. The next analysis of communication technologies focused in Smart Grid takes into account some aspects such as the impact of the band used. There are three reasons to set the limit at 1 GHz, the first one is historical, sub 1 GHz bands were the first ones to be allocated for technical reasons, the second one is related to propagation characteristics, offering less interfered wireless channels, and the third one is related to the band availability [3].

Another aspect to consider is the ability of commercial networks to cover both Smart Grid

applications and the mobile market.

3.3 Analysis of wired technologies

3.3.1 Optical Fiber Optical fiber transmission is used both inside substations and for long-distance

transmission of data. Optical fibers are often embedded in the stranded conductors of the shield (ground) wires of overhead lines. Given some applications with mission-critical requirement and the widespread use of Optical fiber, Fiber to the Home (FTTH) seems a proper solution for Smart Grids. It is the fastest network available, and it can support a wide range of communication protocols and services. However, it is not the best option to support end-user-oriented appliances at the access tier, due to its low penetration and the high costs of deploying the FTTH networks. Besides, some entities of electric grid like substations, usually do not have access to optical fiber networks and, finally, some suitable optical fiber features such as high bandwidth are not needed for Smart Grid purposes.

In connection with the national broadband plans and the Smart Grid deployment, and

since the main disadvantage of optical technologies is the cost of deploying the fiber networks, current deployments rather show that wireless technologies such as LTE are more likely to reduce the geographical digital divide.

3.3.2 Digital Subscriber Line, xDSL This technology offers low-cost services for Smart Grid because the physical

infrastructure is already available, and the bandwidth required is not very strict. Nevertheless, it presents several drawbacks in terms of access line regulation, which depend on customer and installation costs.

3.3.3 Power Line Communications, PLC Power line communication is widely used by utilities for remote metering. The extended

use of this technology is motivated by the constraints of the commercial offerings and the interest of DSO to control all the communication infrastructure, but primarily because the physical lines needed for PLC already exist.

There are two main PLC classes, the Narrowband PLC, (NB-PLC, Table 3 Narrow Band PLC features) and the Broadband PLC (BB-PLC, Table 4 Broadband PLC features). Table 3 Narrow Band PLC features and Table 4 Broadband PLC features summarize the main advantages and disadvantages of both classes.

NB-PLC Physical line Existing

Band Used 3-500 kHz


18


Coverage 150 Km

Data rate 1–10 Kbps (Up to 500 Kbps)

Use case Small meter pilots. HAN (Broadband capability for required data rates of different applications).

Power Transmission Communication limit to each line segment between transformers.

Stability in LV-MV for transfer data in real-time

Not always fulfilled.

Interference in a wide area The capacity is not sufficient to carry the metering traffic with required security features.

Table 3 Narrow Band PLC features

BB-PLC

Physical line Existing

Band Used VHF 1.8-250 MHz

Coverage Significantly shorter than NB-PLC

Data rate Up to 200 Mbps in very short distances

Availability Requires line amplifiers for higher availability

Use case It is mainly considered for in-home applications

Reliability Is not suitable for critical applications or in outage events Is not standardized technology

Attenuation Higher than in NB-PLC

Interference Use the same spectrum as LAN or radio applications

Table 4 Broadband PLC features

3.4 Analysis of wireless technologies

Wireless communication is important as a reliable, efficient, and intelligent way to enhance the conventional power grids into smart grids. Wireless technologies ensure low installation costs and flexible deployments providing connectivity over extended areas or in environments without existing communication infrastructure.

Taking into account the control requirement previously mentioned in Table 2 Smart Grid requirements, we can consider two cases:

• Use a commercial public network where the operators can offer a dedicated service

level agreement (SLA).

• Deployment of a Smart Grid in a private network by utilities or by third-parties avoiding

problems of radio resources.

3.4.1 Wi-Fi (IEEE 802.11) Wireless Fidelity (Wi-Fi) is a popular wireless local area network technology used for

home applications. It operates in the unlicensed 2.4 GHz and 5 GHz bands and thus it is subject to interference with other technologies sharing the same spectrum.


19


3.4.2 900 MHz band and GSM/GPRS Global System for Mobile/General Packet Radio Service (GSM/GPRS) is currently very often used by mobile operators even if there are other more advanced mobile technologies available. Smart Grid operating in 900 MHz frequency applies GSM/GPRS. However, although this technology seems a feasible solution in terms of investments for its wide availability and good coverage in indoor conditions, results from trials [4] have shown that its features are insufficient for Smart meters.

GSM/GPRS Use WAN.

Availability Large deployment.

Coverage Provides a reasonable indoor coverage but insufficient for Smart meters.

Private Network It is not possible. Dedicated services and Quality of Service (QoS) are not guaranteed.

Table 5 GSM/GPRS, wireless technology

3.4.3 450 MHz band and CDMA and future LTE The lower frequency of 450 MHz presents a relevant advantage against GSM 900 MHz

and Long Term Evolution (LTE) 800 MHz, due to its availability in many countries and lower usage. Code Division Multiple Access (CDMA) presents better propagation characteristics and requires four times fewer base stations.

CDMA Availability Large deployment and a spectrum underutilized

Coverage Presents good propagation conditions in indoor

Costs Is cheaper due to it requests fewer base stations

Table 6 CDMA wireless technology

3.4.4 800 MHz band and LTE Long Term Evolution (LTE), is the fourth generation (4G) of cellular communications

standardized by the 3rd Generation Partnership Project (3GPP), that allows getting over some of the GSM shortcomings, like insufficient coverage in indoor conditions for smart meters. This technology provides high capacity, low latency, secure and reliable data-packet switching. Compared with its predecessors, LTE uses new access schemes on the air interface for downlink and uplink, which brings flexibility in scheduling as well as power efficiency.

The fast roll-out of LTE has led to the wide use of this networking technology for, among others, smart metering, distribution automation, fault location, etc. Consequently, LTE is a promising choice to support IEC 61850 together with the Manufacturing Message Specification (MMS) protocol, for smart metering and remote control services [5]. The simulation carried out in [5] assess the LTE capability to support IEC 61850 abstract objects and services mapping, by studying if LTE fulfils requirements like scalability, latency, reliability or QoS. This analysis highlights the functionality of Medium Access Control (MAC) scheduling mechanisms, which can be used to implement prioritization of IEC61850 messages over background traffic. Throughput and packet loss ratio are measured at the Packet Data Convergence Protocol (PDCP) layer, while the delay is measured at the application layer. This study, along with others, present LTE as a good candidate to form part of the communication layer of the ebalance-plus platform.


20


LTE Use WAN, HAN

Coverage Large deployment

Costs Depends on locations but do not need building costs

Private Network No dedicated services although it can be achieved with 5G

Table 7 LTE wireless technology

The previous technologies, GSM and LTE count with the drawbacks of not being able to guarantee dedicated resources and private network conditions to ensure reliability and prioritization for Smart Grid services. These shortcomings are addressed by the fifth generation (5G) or 5G New Radio (5G NR) and by the Network Slicing.

3.4.5 Fifth Generation, 5G This new technology presents the ability to promote full networking among countries

overcoming the expectations of previous cellular technologies. To provide high-quality 5G services, several technologies have emerged:

• Millimeter wave communication offers low latency by using mm-wave spectra ranging

[3-300] GHz. Besides, this technology provides very large bandwidth allocation, which

supports higher throughput than the existing 4G systems.

• Hetnets, the 5G wireless networks require a high demand for data rates. Hetnets solve

this requirement by allowing densification of the network by deploying small cells that

are placed in indoors and outdoors. As result, it provides higher spectral efficiency and

can reduce the consumption of a mobile device due to its communication with nearby

pico-cell. This solution improves network coverage and capacity.

• Massive Multiple-input Multiple-output (MIMO), which consists of the use of extensive

service antennas with spatial multiplexing. This technology allows concentrating radio

energy into smaller areas, obtaining higher throughput and efficiency.

• Visual Light Communication, also called Light Fidelity (Li-Fi) or optical wireless

communication, presents advantages like low power, less interference, and very high

spatial reuse which becomes a proper choice for indoor communication in 5G.

5G networks usually use significant core technologies such as IoT and Software Defined Networks (SDN). SDN decouples the control and data planes to get superior programmability, adaptability, and flexibility in network architectures. The combination of these SDN solutions with the IoT is considered the bridge to 5G networking.

The data traffic distribution in a Smart Grid network can be classified into two sections. The first, the HAN, which involves interaction between the utility and the users through connections like smart meters and sensors, and a second segment comprising the direct connection between the utility providers and the generation side.

The architecture of 5G and Smart Grids tackles both the transmission and the distribution

sides. The 5G network slicing layers of its architecture Figure 4 5G network slicing, comprise multiple domains at both the user and utility sides. Some of the features of 5G slicing are the on-demand deployment, where the network functions are analyzed based on the service needs. Also, 5G network slicing can be perceived as one network sliced into multiple instances, where each one can be optimized for specific requirements/application/services. Slicing allows the deployment of several virtual networks on a single physical infrastructure, allowing resource isolation and customized operations.


21


Figure 4 5G network slicing

Smart Grid 5G slice deployment involves virtualized network functionalities and infrastructure layers by the use of Network Function Virtualization (NFV), which reduces machine interconnection and configuration time, while improving productivity. NFV services can simplify machine data collection, aggregation and analysis.

The concurrent connection between wireless transfers with simultaneous power

entities promotes wireless communication. Nevertheless, high initial investment and low availability during bad weather conditions or natural disasters make it a less preferred approach.

Figure 5 Roadmap architecture of 5G and smart grids


22


There are many advantages of using 5G networks in smart grid toward high-quality service and scalability.

5G advantages in Smart Grid Cost-effective and increased scalability

Reduce power consumption

More connectivity among devices

High data rate and low latency

The speed intervention of circuit breakers in fault detection is better in the distributed network management in 5G

Two-way energy trading

Active wireless transmission spectra between the grid and the networks

Dynamic energy pricing

Secure communication can be ensured by using an intrusion detection system

Table 8 Benefits of 5G network in Smart Grids

3.4.6 Wireless technologies for IoT There is a lot of research about the benefits of 5G and IoT for Smart Grid. The following

sections introduce the more popular wireless technologies for IoT, highlighting the advantages and disadvantages according to their standardization, scalability and compatibility with the current and future standards.

Narrow Band IoT (NB-IoT)

As was mentioned in the previous section, IoT is a driver of 5G and it may also offer a brand-new solution for current smart grids due to features such as low power, long-range, and high capacity. Requirements like secure and reliable communication between the utilities and the devices with high QoS are difficult to achieve for unlicensed Low Power Wide Area Network (LPWAN) technologies, such as Long Range (LoRa) or Sigfox, as they are very likely to suffer from interference in the crowded free band. On the other hand, Narrow Band IoT (NB-IoT), works on a licensed band based on the current LTE facilities, which presents an excellent co-existence performance with GSM. It will be a good candidate as a wireless technology for IoT over 5G.

NB-IoT can provide service level agreements (SLA) with a specific grade of service. In

addition, compared to LoRa or Sigfox, NB-IoT relies on existing cellular technologies, thus the investment and the time required for deployment are reduced. Some of the features that NB-IoT provides are low device cost, uplink latency below 10s, up to 40 devices per household and a 10 years’ battery life.

NB-IoT Use FAN

Standard 3GPP over LTE and GSM today, 5G tomorrow

Coverage < 35 km

Data rate Uplink: < 250 kbps Downlink: < 230 kbps

Latency Uplink latency below 10s

Devices connected 40 devices connected per household

Features over devices Low costs; low power consumption; over 10 years battery life

Table 9 NB-IoT wireless technology features for IoT in Smart Grid


23


ZigBee

Zigbee is a wireless mesh network in the IEEE standard 802.15.4 used in smart grids due to its low power consumption and low deployment costs. ZigBee is considered as a suitable option for in-home applications. It operates under the unlicensed Industrial, Scientific and Medical band (ISM) and precisely because of that it is more likely subjected to interference compared with NB-IoT. Other drawbacks that it presents in practical use are low processing capabilities, small memory size, or small delay tolerance.

ZigBee Use HAN

Standard IEEE 802.15.4

Coverage 30-50 m

Data rate 250 kbps (2.4 GHz); 40kbps (915 MHz); 20 kbps (868 MHz)

Latency 15 ms

Devices connected 250 networks nodes

Features over devices Low costs; low power consumption; high battery life

Table 10 ZigBee wireless technology features for IoT in Smart Grid

Z-Wave

Z-Wave is reliable, low power, low-cost wireless technology that operates in 868 MHz in Europa. Presents common features with ZigBee although with low data rate capabilities.

Z-Wave Use HAN

Standard IEEE 802.15.4

Coverage Internal 30-50 m; external up to 100 m

Data rate 9.6 Kbps to 40 Kbps

Latency 15 ms

Devices connected 250 networks nodes

Features over devices Low costs; low power consumption; high battery life

Table 11 Z-Wave wireless technology features for IoT in Smart Grid

Worldwide Interoperability for Microwave Access, WiMAX

WiMAX is a 4G wireless technology based on the IEEE802.16. This technology supports real-time, high data rates and two-way broadband communications. However, its deployment can be expensive and for that WiMAX is not widely adopted as a platform for smart grids. Furthermore, the high frequency used, makes difficult the coverage in indoor conditions. Additionally, WiMAX can be affected by bad weather conditions.

WiMAX Use Remote-monitoring, real-time pricing. WAN

Standard IEEE802.16

Coverage 10-50 km (LOS) 1-5 km (NLOS)

Data rate Up to 75 Mbps

Latency 10-50 ms

Features over devices Real-time high-data-rate two-way broadband communication

Table 12 WiMAX wireless technology features for IoT in Smart Grid


24


Wireless mesh network

It is a flexible network constituted by a group of nodes that can be implemented over several standards, 802.11, 802.15 and 802.16. Its topology provides good network reliability, wide coverage ranges and high capacity thanks to the multi-hop routing. However, the initial investment is high and its set-up and maintenance are difficult since it requires continuous supervision. As a result, a third party is needed. Most of its features like latency, used band, coverage or data rate rely on the selected standard.

Long Range, LoRa

LoRa is one of the LPWAN unlicensed technologies. It operates on the 433-868 MHz or 915 MHz in ISM. To mitigate the effect of interference, LoRa uses a Frequency Hopping Spread Spectrum (FHSS), achieving long-range communication up to 15 km in urban environments or 22 km in rural areas. LoRaWAN is based on LoRa and adds a network layer to handle congestion between connected devices and central nodes. The low data rates of LoRa determines that it is only applicable to applications with low payloads.

LoRa Use FAN

Coverage 10-50 km

Data rate 0.3-50 kbps

Latency Average 2s

Devices connected Home automation 300; sensors 200; metering 100

Features over devices Low cost; low power and long-range communication

Table 13 LoRa wireless technology features for IoT in Smart Grid

Sigfox

This technology is deployed by using proprietary base stations which are configured with cognitive software-defined radios by connecting them to backend servers utilizing IP-based network. It uses ultra-narrowband (UNB), 100 Hz bandwidth in the ISM bands providing highly sensitive, ultra-low power consumption and long ranges, up to 30-50 km in rural areas. This range is reduced to 3-10 km in urban areas.

In conclusion, compared with unlicensed technologies for FAN, NB-IoT provides high QoS and reliable services for mission-critical grid applications. For instance, although it has similar latency and data rate as the wireless mesh network, the latter presents problems of redundancy and security, making NB-IoT more suitable for smart grids.

Finally, based on several studies and simulations [6], it has been demonstrated that NB-IoT

is suitable for services that require long-range, high reliability and appropriate data rate, meeting other requirements such as scalability and security. However, NB-IoT is not suitable for strict delay-tolerant applications (AMI, DRM, G2V, and V2G).

3.5 Communication protocols for automation

processes A protocol is a set of rules used to communicate in computer systems or Smart devices in a telecommunication connection. Communication protocols are used for transferring messages and packets between computing systems acting as a telecommunication medium.


25


This section introduces the most relevant communication standards and protocols for different applications into Smart Grid: building automation, power-system automation, automatic meter reading and vehicular automation.

3.5.1 EEbus EEBus is a new data communication standard forming the interface between in-house

communication and the energy supplier. The standard is currently under development. It connects the IP world of the smart grid and smartphones to automation and communication networks in the home and building area. For this purpose, EEBus supplies an application-neutral standardized interface.

EEBus is initially bridging the following three standards:

• ISO EN 16484-5 (Data Communication Protocol – BACnet).

• IEC 14543-3 (Home and Building Electronic Systems – KNX).

• EN 14908-1 (Control Network Protocol – LON).

The EEbus architecture is based on the SGAM model offering solution for the following layers:

• Function Layer. Use cases specification.

• Information Layer. Smart Premises Interoperable Neutral Message Exchange (SPINE).

• Communication Layer. Smart Home IP (SHIP).

Figure 6 EEbus communication stack, represents an overview of the communication stack with the layers and solutions involved. More details in [7].

Figure 6 EEbus communication stack

• SHIP Message. The SHIP Message Exchange (SME) protocol enables secure

connection and efficient communication between the devices.

• Web Sockets. Enables continuous communications from cloud application to physical

devices (RFC 6455).

• Transport Layer Security (TLS), a protocol for secure IP communication. (RFC 5246)


26


• Multicast Domain Name System (mDNS), is used via Unit Datagram Protocol (UDP)

to send messages to all participants for network setup. (RFC 6762).

• DNS Service Discovery (DNS-SD), scans an EEbus network for available devices

and services. (RFC 6763).

• UDP/TCP. UDP is used to find SHIP devices and Transport Control Protocol (TCP)

for data communication. (RFC 793).

SPINE Resources. Describe the device model and the message content itself as data

models (class description), and application rules.

• SPINE Protocol. Describes the format of a SPINE datagram, the rules and description

for connecting SPINE devices, for instance, the identification of supported use cases

or determination of the address of a function.

• The Application. It completes the EEbus stack with the use case. The use case

specifications are manuals on how to use the SPINE toolbox (data classes) to

implement a specific solution.

3.5.2 IEC 61850 Standard. Power system automation protocols

The IEC61850 is an open standard for Ethernet communication within substation. The IEC61850 standard is focused on communications between protection equipment, control and measure in an automated substation. The standard defines several aspects of the substation communication network in 10 sections or chapters. It defines communication protocols, specific architecture, configuration, data models and electrical and environmental requirements as well as compliance and quality test mechanisms. The IEC61850 standard is aimed toward the protocol consolidation to guarantee the interoperability. This comprises a new data model definition, object and functions oriented in which the substation is divided into basic functions through the concept of logic node and simple information units, simplifying the database of the installations and providing a more user-friendly structure. This new data model allows interchangeable devices, offering interoperability. In addition, to define communication protocols, IEC61850 specifies a data structure.

The IEC61850 standard presents as innovation the introduction of the Local Area

Network (LAN) into the substation leading to a significant reduction of wiring. LAN also provides an important feature of Smart Grid - scalability.

The typical substation architecture in Figure 7 Substation architecture, shows how the substation network is connected to the outside WAN via a secure gateway. Outside remote operators and control centers can use Abstract Communication Service Interfaces (ASCI) to query and control devices in the substation. A substation bus carries all ASCI requests/responses and generic substation event messages. The process bus connects all IEDs to the traditional dumb devices (merge units, etc.). A substation usually has one global substation bus and multiple process buses, one per bay.


27


Figure 7 Substation architecture

The main objective of IEC61850 is the automation of control and protection functions in the substation. The communication services define the interaction between the system elements interchanging the data model information. The interoperability, between IEDs of different providers, is achieved thanks to services independent of final devices and used protocols.

The IEC61850 standard establishes the applied protocols and the structure of the messages described in Figure 8 Suite of IEC61850 protocols.

• Type 1: Rapid messages for protection.

• Type 1A: Triggers used for protection.

• Type 2: Median speed messages for control (controls, alarms, etc.).

• Type 3: Slow messages for supervision and configuration.

• Type 4: Instantaneous values sending of analogy signals.

• Type 5: Files transference.

• Type 6: Time synchronization.

Figure 8 Suite of IEC61850 protocols


28


The core of the architecture in Figure 8 Suite of IEC61850 protocols, is formed of Manufacturing Message Specification (MMS) protocol for exchanging non time-critical information through a concept of client-server. Likewise, the standard also defines protocols for messages with stricter delay requirements, Generic Object Oriented Substation Event (GOOSE) and Sample Values. These are Ethernet types and are transmitted through a publisher-subscriber architecture.

3.5.3 IEC 62056 Standard. Automatic meter reading protocols

IEC 62056 is a widely-used standard for AMI which defines several methods for meter reading, tariffs notification and load control. It is based on the Device Language Message Specification (DLMS) protocol and the Companion Specification for the Energy metering (COSEM) model. DLSM is considered as a set of rules or common languages that standardize the protocol. COSEM provides information about Transport and Application Layers for the DLMS protocol. Object Identification System (OBIS), is used to identify COSEM objects.

The IEC 61107 communication standard to read utility meters is into IEC 62056 as IEC 62056-21 which describes hardware and protocol specification for local meter data exchange. In such systems, a hand-held unit (HHU) or a unit with equivalent functions is connected to a tariff device or a group of devices.

The protocol permits reading and programming of tariff devices. It is designed to be

particularly suitable for the environment of electricity metering, especially as regards electrical isolation and data security. Although it can operate over any media, usually the communication with the meter is via a serial port. It can implement up to five communication models, A, B, C, D and E, where the version C is used for electricity meters. The HHU or equivalent unit acts as a master while the tariff device acts as a slave in protocol modes.

Other standards widely used in the Smart grid are: The IEC 60870 which defines telecontrol application functions and the Common

Information Model (CIM) defined in the IEC 61790 standard for electricity transmission network, whose domain covers the energy management system application supervising and controlling electricity transmission networks.

3.5.4 IEEE802.15.4 Standard The IEEE802.15.4 standard-based Wireless Sensors Network (WSN) is a suitable

standard for Smart Building applications for low-power wireless mesh solutions. The application of WSN provides rapid-connect packet data, reliable network services and reduce overall infrastructure support requirements in several Smart Grids applications such as automation, remote monitoring and supervision.

It refers to the two layers of the ISO/OSI model, the PHY and MAC layers for LR-WPAN.

In IEEE802.15.4, all devices are categories such as Full-Function Devices (FFD) or like Refined Function Devices (RFD) according to their capabilities. FFDs can initiate a Personal Area Network (PAN) and act as coordinator of the PAN or can forward data and act as the routers.

The physical layer provides a trade-off between energy consumption, communication

range, and reliability. IEEE802.15.4 uses Offset-Quadrature Phase Shift Keying (O-QPSK) modulation with Direct Sequence Spread Spectrum (DSSS) and frame size of 127 Bytes.


29


The IEEE802.15.4g is a modification in the physical layer of the IEEE802.15.4 designed for Smart Utility Network (SUN) application. It introduces three alternative physical layers: Orthogonal Frequency Division Multiplexing (OFDM) that offers longer range, higher bandwidth and better handling of external interference and multi-path fading. Frequency Shift Keying (FSK) that increases the transmit power efficiency and O-QPSK with the same characteristics of IEEE802.15.4. [7], compares the performance of two IEEE802.15.4 physical layers in the Smart Building context: 2.4 GHz O-QPSK and sub GHz OFDM.

On the MAC layer, IEEE802.15.4 supports different modes of operation: beacon-

enabled and beaconless with or without a PAN coordinator, in a star or in peer-to-peer topology. The MAC layer controls the access to the radio channel employing the Carrier Sense Multiple Access with a Collision Avoidance (CSMACA) mechanism, and a protocol for network access control, allowing that multiples stations use the same media for transmission. If upper layers detect that the communication throughput has been degraded below a specific threshold, the MAC performs an energy detection scan through the available channels. In this way, upper layers switch to the channel with the lowest energy. The 802.15.4 MAC is also responsible for flow control via acknowledged frame delivery, frame validations and network synchronization, controlling the association, managing device secure and scheming the guaranteed time slot mechanism. [7] describes more details about the design and implementation of this standard on Field Programmable Gate Array (FPGA) as well as the frame structure.

3.5.5 6LoWPAN, Routing Protocols. IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN), is a low power

wireless mesh network where every node has its own IPv6 address. It can communicate with 802.15.4 devices alongside other types of devices with an IP network link. 6LoWPAN allows the transmission of IP packets into networks based on IEEE 802.15.4 introducing an adaptation layer between the DL layer and NWK layer of the OSI model, redesigning the format of the IPv6 packet obtaining a simpler transmission and processing and lower consumption. This allows the node to connect directly with the Internet using open standards. It enables devices with limited processing power to send information wirelessly using the Internet Protocol.

Some of the advantages of 6LoWPAN, (RFC6282) are:

• It offers end-to-end IP addresses nodes. There is no need for a gateway, only a router

that connects to IP.

• It supports self-healing, robust and scalable mesh routing.

• It offers one-to-many and many-to-one routing.

• leaf nodes can sleep for a long duration of time.

• It offers thorough support for the PHY layer, which gives freedom of frequency band

and physical layer, so can be used across multiple communication platforms.


30


Figure 9 6LoWPAN protocol architecture

In the 6LoWPAN architecture (Figure 9 6LoWPAN protocol architecture), when a low processing power sensor node in 6LoWPAN or Decrease Function Device (RFD) wants to transmit its data packet to an IP-enabled device outside of 6LoWPAN, it first transmits it to the highest processing power sensor node, the full function device (FFD) in the same PAN. FDDs will forward the data packet hop by hop to a 6LoWPAN Gateway as a router. The 6LoWPAN gateway joins the 6LoWPAN network with the IPv6 domain and uses the IP address of the destination IP-enabled device and forwards the packet.

Figure 10 The reference model of the 6LoWPAN protocol stack, represents the 6LoPWAN protocol stack

Figure 10 The reference model of the 6LoWPAN protocol stack


31


3.5.6 Wireless HART and ISA100.11a, process automation standards

IEEE802.15.4 is a standard for low-rate wireless personal area networks (LR-WPAN) that specifies the physical (PHY) and MAC layers. It is the base for technologies such as ZigBee, Wireless HART, ISA100.11. All these industrial wireless sensors networks (IWSN) include a combination of device improvements, security, network technology and network management.

Wireless HART (IEC62591), is a standard based on Highway Addressable Remote

Transducer (HART) communication protocol and operates in the 2.4 GHz ISM band. Figure 11, shows the Wireless HART architecture which comprises a mesh of self-organized and self-healing devices. In a Wireless HART network, each station (field device) forms a network actuating as a signal source and a signal repeater. Wireless HART provides extended network range and reliability due to the routing.

Figure 11 Wireless HART communication architecture

ISA 100.11a was developed through the International Society of Automation (ISA). It is

a standard designed to support process automation, factory automation and RFID. ISA 100.11a defines the protocol stack, system management and security functions for low-power, low-rate networks. It doesn’t specify a process automation protocol application layer or an interface to an existing protocol, it only specifies tools for the interface construction.

From studies about the differences between Wireless HART and ISA 100.11a [5] and

the comparison with other IWSN for IoT monitoring [6], it is worth noting that some mechanisms, which improve the performance of the protocols are under study.

At the MAC layer both, Wireless HART and ISA 100.11a don’t operate in beacon mode and they implement superframes and use Time Division Multiple Access (TDMA) and Carrier Sense Multiple Access (CSMA). Both consider that the MAC layer of IEEE 802.15.4 is not capable of delivering the deterministic latency needed by industrial applications so they extend and complement medium access mechanisms with functionalities at the data link (DL) layer with the Time Synchronized Channel Hopping (TSCH) offering improvements such as the possibility to have deterministic latency (communication resources are pre-allocated), and a


32


mechanism of channel hopping that minimizes interferences with devices that work in the same frequency. In the case of ISA 100.11a, the DL is used to implement network functions, i.e., routing, implementing two types, one at the DL layer for IEEE802.15.4 traffic and one at the Network (NWK) layer, for handling the IPv6 backbone traffic due to the network and transport layers that are based on 6LoWPAN.

Regarding the timestamp requirement, Wireless HART and ISA 100.11a define their own time standard as Universal Time Coordinated (UTC) and International Atomic Time (TAI) respectively, providing services to synchronize sensor nodes. ISA 100.11a uses object-oriented representation while Wireless HART uses a command-oriented representation.

From the transport of collected data, both standards use fragmentation and reassembly mechanisms to overcome the limitations of the Maximum Transmission Unit (MTU) in IEC802.15.4, being equal to 127 bytes. This mechanism is implemented at the network layer in the case of ISA 100.11a and at the application level in the case of Wireless HART.

The order of following communication protocols represents mostly the correlation between the protocols and the different layers of the Open System Interconnection (OSI/ISO) model.

3.5.7 Modbus RTU or ASCII or TCP. Process, building automation and automatic meter reading protocol

MODBUS is an application layer messaging protocol which provides client/server communication between devices connected on different types of buses or networks. Created for use with Modicon’s Programmable Logic Controllers (PLC), it was released as an open protocol in 2004 and has become a de-facto standard for connecting a wide range of industrial electronic devices. Modbus is used to communicate between intelligent devices and sensors and instruments, and to monitor field devices using PCs and Human-Machine Interfaces (HMI). It is also popular in building, infrastructure, transportation, and energy applications.

As shown in Figure 12 MODBUS communication stack, it is used over several physical links (RS485, RS232 and TCP/IP) while the data can be transported via American Standard Code for Information Interchange (ASCII), Remote Terminal Units (RTU), Modbus is widely used for process control and SCADA systems. This protocol is characterized by its simple implementation and low cost, (cheaper than DNP3).

Figure 12 MODBUS communication stack


33


Figure 13 MODBUS architecture shows the communication within all types of network architecture using MODBUS, where the devices can use MODBUS to initiate a remote operation. The gateways allow communication between the different buses or networks.

Figure 13 MODBUS architecture

3.5.8 DNP3. Process and power system automation protocol

Distributed Network Protocol (DNP3) is a communication protocol used between components in process automation systems. It is widely used in the power industry (electrical and water), were reliability and timestamping are important. It was designed for SCADA systems, where it is used by SCADA master stations (aka Control Centres), RTU and Intelligent Electronic Devices (IED).

The DNP3 was developed by Westronic in the early versions of the IEC60870-5

standard telecontrol protocol specification. Currently, it is governed by IEEE Std 1845-2012 IEEE Standard for Electric Power Systems Communications Distributed Network Protocol (DNP3) [8].

Standardized, it provides high compatibility and interoperability. Some of the features

that this protocol offers are: The Sequence of Event (SOE) reporting, capacity for transferring a large amount of data using a very little bandwidth and time synchronization of slave devices.

Compared to Modbus, DNP3 counts with a useful feature, it can use report-by-exception (RBE) functionality. With RBE functionality, only a change in data is reported rather than reporting all data each time a device is polled. This feature of DNP3 allows historical and event-driven data to be transmitted while ensuring that no critical data is lost.

DNP3 works in the serial link and TCP/IP. The protocol is based on the Enhanced Performance Architecture (EPA), a simplified model of Open System Interconnection (ISO/OSI) model. It specifies the data link, pseudo-transport and application layers. However, EPA did not support application layer messages were larger than the maximum length of the data link frame. The DNP3 uses the data link in combination with the pseudo-transport layer


34


to support advanced RTU functions and messages larger than the maximum frame length defined by the IEC60870-5.

DNP3 protocol layers are placed on top of the physical layer, which is responsible for transmitting messages over physical media although this layer is not specified in the DNP3 standard.

Although the security and privacy mechanism will be tackled in D5.2, [3] and [4] present a taxonomy of attack and vulnerabilities related to security associated with the smart grid, were DNP3 protocol is involved.

DNP3 presents important functionalities, high robustness and efficiency but on the

other hand, it wouldn’t be the best solution due to its higher costs and complexity.

3.5.9 OPC UA Industrial control protocol Open Protocol Communication United Architecture (OPC UA) is a data exchange

protocol for industrial communication (PC-to-machine, machine-to-machine). OPC UA is implemented with a couple of server/client. The OPC server is a program that translates the communication protocol used for the device into the OPC protocol. The OPC client software is a program that connects to the device, such as a SCADA/HMI system. The OPC client communicates with the OPC server to receive data or send commands to the device.

There are two mechanisms for exchanging this data:

• A client-server model in which UA clients use the dedicated services of the UA server.

• A publisher-subscriber model, in which a UA server makes configurable subsets of

information available to any number of receivers.

Both mechanisms are detached from the actual protocol and therefore TCP and Hypertext Transfer Protocol Secure (HTTPS) represent the client-server, and UDP as well as Advanced Message Queuing Protocol (AMQP) and Message Queue Telemetry Transport (MQTT) the subscriber model.

OPC UA presents some advantages like a reduced load on the hardware device,

standardization and independence from the physical transport medium and the transport protocol so the client applications do not need to know anything about hardware protocol details.

The communication layers, presented in Figure 14 OPC UA Communication layers, are on top of the TCP/IP transport layer, one that handles the session and one to establish a secure channel between the client and the server. The transport layer is made up of TCP/IP and on top of Hypertext Transfer Protocol (HTTP). The communication layer secures both the integrity of data and authentication.


35


Figure 14 OPC UA Communication layers

Figure 15 OPC UA architecture layers, presents a service-oriented and multi-layers’ architecture which provides innovate technologies and methodologies such as new protocols, security algorithms, encoding standards or application services while maintaining backwards compatibility for existing products.

The OPC UA information modelling framework transforms data into information. This

framework defines the rules and base building blocks that expose an information model with OPC UA.

The OPC UA Services are the interface between servers as the supplier of an

information model and clients as consumers of that information model. Some of the information models defined by OPC are Automation-Data (DA), Alarm &

Conditions (AC), Historical Access (HA) or Programs (Prog). Other organizations can build their models. There are some examples of standards

working or mapping to OPC UA are Field Device Integration (FDI) combining Electronic Device Description Language (EDDL), and Field Device Tool (FDT) or PLCopen for PLC programming languages.


36


Figure 15 OPC UA architecture layers

OCP can be thought as a universal translator for linking different systems. It works with virtually every control system and can communicate with major building automation protocols such as Modbus, BACnet or Lonworks. OPC specifications include transmission of real-time events and alarms, and interfacing of real-time data to various types of devices.

3.5.10 PRIME PoweRline Intelligent Metering Evolution (PRIME) is a new generation protocol of

PRIME Alliance focused in the data transmission using the power line as media. PRIME implements the first two layers of the OSI model, the physical and data link layers.

At the physical layer, PRIME uses PLC technology with a 500 kHz band in the last

standard version and it uses OFDM modulation.

At the data link layer, it defines the access to the media with a tree topology with two different types of nodes:

• Base node: It constitutes the tree root and acts as a communication master, there is

only one base node in the subnet.

• Service node: this element is initially disconnected and realizes a registration process

before joining to the network. The service nodes have two functions: keep the

connection into the subnet for the application layer and routing functions for the data

from other services nodes.

The service nodes can stay in one of the next three states:

• Disconnected: The node is not connected to the network.

• Terminal: The node is connected to the subnet but it doesn`t perform routing functions.

The leaf node of the tree.

• Switch: The node is connected to the subnet and acts as a router. It is a branch node

of the tree.

3.5.11 Meter and More Meter and More is also an open protocol that uses power lines as media for communication. Is an evolution of a protocol property of the Italian company, ENEL deployed in Spain by ENDESA. It is characterized for using Binary phase-shift keying (BPSK) modulation in its physical layer and is based on the IEC 61334-32 standard. It is a protocol-oriented to short messages and it counts with extensions to be compatible with DLMS/COSEM. Meter and More, covers the completed OSI stack layers Figure 16, allowing its use over several transmission media.

• PLC profile. For communication between smart meters and concentrators.

• IP profile. For communication through public networks between the core system

and the concentrator.

• IEC62056-2110 profile. For local access through optical port.

• DLMS/COSEM. For communications PLC making interchange of COSEM objects,

as an alternative to PLC profile.


37


Figure 16. Meter and More architecture

3.5.12 Building automation protocols Building automation is an example of distributed control of building systems: heating,

lighting, ventilation, air conditioning and other systems through a Building Management System (BMS) or Building Automation System (BAS).

BAS core functionality keeps building climate within a specific range, monitors

performance and device failures in all systems and provides malfunction alarms. The usual objectives are improved occupant comfort, efficient operation of building system, and reduction of energy consumption.

Section 3.5.7, Modbus and Section 3.5.9 OPC, are examples of Industrial control

protocols that can be used in building automation. And the latter provides connectivity between different protocols. The current section introduces some of the most widely used communication protocols developed specifically for building automation.

All of them are open protocols that can usually communicate with each other thanks to

gateways and Application Programming Interfaces (API) developed by the various user groups and vendors.

Each protocol has its own advantages and disadvantages and mixing protocols may

be the most effective way to optimize a building system.

BACnet

The American Society of Heating, Refrigerating and Air Conditioning Engineers (ASHRAE) designed the Building Automation and Control network (BACnet) protocol. It is an open and compatible protocol regardless of the equipment manufacturer. It became a standard by ANSI and ISO. The BACnet protocol allows powerful communication support for the different building systems including Heating, Ventilation, Air Conditioning (HVAC), lighting, fire protection, and physical security (access control, intrusion) devices. It is used for communication across devices with 5 interoperable areas: data sharing, alarms and events,


38


scheduling, trending and device management. The BACnet protocol can also communicate over multiple physical layers or link layers that are among others, BACnet/IP, BACnet Master-Slave Token Passing (BACnet MS/TP), Ethernet, BACnet/IPv6 and the future-coming BACnet SecureConnet (BACnet/SC).

Figure 17 BACnet architecture

KNX

KNX is a communication protocol developed for home and building automation, it was created in 1999 by Konnex Association, now KNX Association. It is standardized (EN 50090, ISO/IEC 14543), based on the communication stack of the European Installation Bus (EIB), but enlarged with the physical layers, configuration modes, and application experience of BatiBUS and European Home Systems (EHS).

KNX is used in residential and commercial building automation for HVAC, lighting,

security, remote access, blinds and shutter control, visualization and energy management. The choice for transmission media.

Figure 18 KNX model shows the KNX architecture. At the top of the model is the layer

of Interworking and (Distributed) Application Models for Home and Building Automation. KNX models an application as a collection of sending/receiving Datapoint from/to KNX devices, Datapoints can be inputs, outputs, parameters, diagnostic data, and so on.

Below, the Configuration Models are shown, where the different configurations allow

that KNX provides a diverse alternative for different markets, local user, level of training, and application environment. The Common Run-Time Interworking is shared for the configuration modes to create the multidomain home and building communication system, which defines the physical communication media, message protocol and model for KNX. A Common Kernel model shared by all the devices includes the seven OSI model layers. The PHY layer supports different transmission media for KNX, twisted-pair cable (TP1), power line (PL 110), radio frequency (RF), fiber-optical cable, IP/Ethernet (KNXnet/IP). The DL provides MAC and logical link control (LLC). The Network Layer controls the hop count of a frame and segment-wise acknowledged telegram which is the structure used by KNX to transmit or receive information. The Transport Layer defines four types of communication: multicast, broadcast, one-to-one connectionless, one-to-one connection-oriented, KNX communicates with other protocols via gateways. The Session and Presentation layers are empty while the Application Layer offers several application services.


39


Figure 18 KNX model

LonWorks

Local Operation NetWork (Lonworks), is a communication protocol used for many types of control in building automation applications. The protocol was developed by Echelon in 1988, and in 1999 it was accepted as a standard by ANSI for control networking (ANSI/CEA-709.1-B).

Lonworks is used in the majority of the devices involved in building projects, including

HVAC and lighting. Also, this protocol is used in other markets such as outdoor lighting, transportation, utility, process control and home automation. Lonworks was designed on a low bandwidth platform for networking devices through power lines, fiber optics, and other media. As a transport protocol, Lonworks connects to IP-aware applications or remote-network-management tools using IP tunneling standard ISO/IEC 14908-4 (ANSI/CEA-852).

Lonworks consists of software (open protocol LonTalk) and hardware components:

• Twisted-pair and/or power line transceivers to transmit Lonworks protocol.

• LonWorks, communication protocol (ANSI/EIA 709.1)

• LonWorks Network System, LNS Network Operating System as a software component.

• LonMaker which allows interoperability among devices.

3.5.13 Application Layer protocols To complete the analysis, this section is dedicated to the application layer protocols.

There are numerous protocols especially aimed to IoT: Extensible Messaging and Presence Protocol (XMPP), Representational StateTransfer (RESTFUL) Services, AMQP, HyperText Markup Language WebSocket (HTML 5's) and Data Distribution Service (DDS), but for this analysis, we focus in the de facto standards for IoT solutions, CoAP, and MQTT.

Constrained Application Protocol CoAP


40


Constrained Application Protocol CoAP, described in RFC 7252, is a web exchange protocol with a client-server architecture (Figure 19 CoAP communication pattern). It is used as part of constrained nodes or network with memory and power limitations. It stands between the UDP layer and the Application layer. Its features include:

• Constrained web protocol fulfilling Machine-to-Machine (M2M) requirements.

• It is easy to proxy to/from HTTP.

• It is an open IETF standard.

• It utilizes a little asynchronous exchange model.

• UDP is binding with unwavering quality and multicast help.

• URL is supported.

• DTLS based Pre-Shared Key (PSK), RandomPair-wise Key (RPK) and authentication

security.

• It is intended to be used without IP fragmentation.

Figure 19 CoAP communication pattern

CoAP solves the lack of order and unreliable transmission of UDP datagrams utilizing a messaging layer over the actual request/response so the time-critical packets are acknowledged by an adjustable QoS.

Message Queue Telemetry Transport, MQTT

MQTT protocol is a client-server publish-subscribe message transport protocol created in 1999 for IBM. The current version is 3.1.1. MQTT is a protocol that follows the publish-subscribe communication pattern that provides decoupling of peers in large distributed systems.

MQTT is lightweight and similar to CoAP. It is suitable for M2M communication in

constrained environments. It works over TCP, can be secured by TLS and provides three levels of QoS being the QoS important for controlling the protocol overhead and for allowing the network to manage the quality when bandwidth or connection problem happen.

• QoS 0, the messages are assured to arrive at most once, hence can be lost when

connection problems occur.

• QoS 1, the messages are assured to arrive, but duplications can occur.

• QoS 2 where messages are assured to arrive exactly once, this type is intended for

systems where TCPs mechanisms are not enough.


41


There are two types of MQTT connection:

• Publishing Connection. A client connects to the server (broker) to publish multiple

messages during the lifetime of the connection, Figure 20 MQTT client publishing

communication pattern.

Figure 20 MQTT client publishing communication pattern

• Subscription Connection. A client connects to the broker and subscribes to message

topics receiving the publications of other clients forwarded by the broker, Figure 21

MQTT publish-subscribe communication pattern.

Figure 21 MQTT publish-subscribe communication pattern

The broker acts as an intermediary between the publisher and subscribes guarantying the delivery of the message based on the QoS.

As already mentioned, the two protocols are de facto the protocols for IoT solutions very present in some of the demo sites described in Section 4.2. The current section is closed with the introduction of an application layer communication protocol for other service supported by several demo sites in the ebalance-plus project, namely the V2G service.

OCPP 2.0. protocol

In the Electric Vehicle (EV) industry, several standards ensure the base level of interoperability of the front-end communication and signaling processes for smart charging between EV and charge stations. The Open Charge Alliance (OCA), a group of European Industries, have developed an open-source common back-end protocol - the Open Charge


42


Point Protocol (OCPP) for charging stations, to reduce and secure the overall investment costs. The objective of OCPP is to qualify an interoperable EV charging foundation - a versatile and simple framework for both EV drivers and system administrators. In this manner, the clients can choose the most fitting charging station vendors and the most proper IT back-end provider freely.

Figure 22 Electric vehicle charging infrastructure and interface standards shows the usual Charging Infrastructure that comprises an EV, Charging Station and the Charging Station Management System (CSMS). The Charging Station is the physical framework, were the EV is charged. A Charging Station has at least one Electric Vehicle Supply Equipment (EVSE) which can provide power to one EV at any moment. EVSE needs to speak with the Battery Management System (BMS) of the battery pack in EV to charge it at the right rate for keeping up the State of Health (SOH) of the batteries. The typical media for this can be the PLC or Controller Area Network (CAN).

Figure 22 Electric vehicle charging infrastructure and interface standards

Three are the main versions of OCPP:

▪ OPCC 1.5 - this version describes 25 Operations, 10 focused on Charging Station and

15 focused in the Central management system, Authorize, Boot Notification, Data

transfer, etc.

▪ OPCC 1.6 - this version uses the Simple Object Access Protocol (SOAP) Framework

to send messages between sections over the Internet.

▪ OPCC 2.0 - this is the most recent version supported by JSON. It contains 116 use

cases and 16 Function Blocks, with one or more use cases in each of them. Out of

these, only some are needed to implement a basic Charging Station of CSMS.

• Provisioning Functional block.

• Authorization Functional block.

• Transactions Functional block.

• Availability Functional block.

• Metering Functional block.


43


4 Communication technologies for

ebalance-plus In light of the previous sections, it is evident that there is a broad range of communication

technologies for Smart Grid and its selection depends on the target application and the requirements that it needs to cover, Table 1 Network requirements for different applications and Table 2 Smart Grid requirements.

To delimit the set of communication technologies that will form part of the ebalance-plus

project, the present section describes the demo sites or pilots that will be implemented during the project for testing and validating the ebalance-plus platform highlighting the technologies solutions involved and the communication protocols/ interfaces supported.

Before presenting the different demos sites, Section 4.1 provides technical details about the connection of the entities common to all demo sites, the MUs, and the methodology carried out to guarantee its self-healing and reliability of the ebalance-plus platform.

4.1 Communication between Management Units

The Management Units (MUs) in the ebalance-plus architecture, are securely connected in order to create a trusted and distributed infrastructure of the system. The communication between the MUs is based on channels that use the IP protocol. Depending on the network configuration, the MUs are connected directly or via a secure Proxy. The latter solution is used in case one or both communicating units are located behind a firewall or generally in a private network and cannot be accessed directly from the public network. In any case, the MUs and proxies are authenticated using certificates, so only trusted peers are allowed and the communication between these is further encrypted to provide confidentiality.

The communication modules that are going to be used between the MUs will support

mechanisms for self-healing and reliability. These will be applied on the network layer, e.g., to reconnect in case of a broken link and monitoring the communication delay. But these will also be applied on the application layer in the distributed middleware, where proper actions will be applied in case the needed data cannot be obtained from a remote peer. Additionally, monitoring of the energy consumption is envisioned, to be able to control and limit the energy consumption by the MUs, especially in the case of the CMU at the end-user premises.

4.2 Demo sites technologies

The ebalance-plus project will carry out the testing and validation of 4 pilots in different European countries and different electric market contexts. This approach aims to demonstrate challenges such as interoperability, demand response or integration of smart-grid solutions:

• Smart grid solutions with variable consumption, storage and generation in the

University of Calabria (UNC).

• Distributed PV system with V2G technologies, supported by high-efficient power

converters, connected to the electric grid in the University of Malaga (UMA) and

distributed energy storage.

• Building management system in Yncréa Hauts-de-France engineering school (YNC)

and Institut Catholique de Lille (ICL).


44


• Power-to-heat systems by the Technical University of Denmark.

4.2.1 The University of Calabria (Smart grid)

The Campus of the University of Calabria, in Italy, as shown in Figure 23 University of Calabria pilot, comprises a variety of buildings (laboratories, classrooms, administrative offices, library and student residence) that represent both electric and thermal passive end-users. The campus is supplied by a MV/MV substation with a ring distribution grid in MV that feeds 28 MV/LV substations. The campus can be thought of as an aggregation of consumers, prosumers and producers. It is equipped with several renewable energy generation plants and monitoring and control systems (SEB) in some buildings.

Figure 23 University of Calabria pilot

Figure 24 UNC pilot, connectivity scheme, describes the connectivity of the participating entities in the pilot, where the blue components are technologies developed in the ebalance-plus project, while the black components are technologies already available in the campus.

Existing technologies for four office buildings:

• Each building has a PV plant.

• The monitoring systems for the buildings’ consumptions and PV plants production.

Existing technologies for residential blocks (Chiodo2):

• A hybrid AC/DC microgrid: It consists of three nanogrids installed and connected to a

common DC bus operating as a unique hybrid AC/DC microgrid. This microgrid

integrates two PV plants, a Stirling–engine micro Combined Heat and Power (mCHP)


45


generator, a lithium battery energy storage, several electric loads and some

controllable loads.

• Heat pumps with thermal storage.

• A room automation system. For every apartment, the management system controls the

access of people, the electrical switchboards, the alarm system and the heating

system.

ebalance-plus management unit technologies:

• DERMU, the management unit will be integrated to control the operations of the units

m-CHP and RES plants.

• IoT devices to manage apartment devices and small storage units will be installed in a

residential block (Monaci).

• A CMU will be installed per apartment, (at least in five apartments).

• IoT solutions for energy management and the integration of the heat pump in the

ebalance-plus platform.

Figure 24 UNC pilot, connectivity scheme

4.2.2 The University of Malaga, (Smart Campus) The Campus of the University of Malaga, Spain is composed of 19 buildings with different

uses, four of them have been selected (two faculties, one research center, one sport-center) that belong to different smart-grids of the Campus. The selected buildings provide smart solutions at different levels:

• Building Level: increase flexibility with smart storage.


46


• District Level: PV canopies in a DC network with efficient power inverters.

Figure 25 University of Malaga pilot

The four buildings shown in Figure 25 University of Malaga pilotwill benefit of smart-storage systems to increase the energy flexibility and two canopies with five electric charging stations V2G and PV roofs, each will be installed at the district level to maximize the use of local renewable energy generation. The system is supported by the SiC power inverters, which create a local DC-DC grid to optimize the energy efficiency of power flows.

ebalance-plus technologies to be installed/tested:

• Smart Batteries will be installed in each building.

• Photovoltaic Canopies

• V2G Charging points that work with DC. As well as the bus of the complete solution:

photovoltaic-EV SiC power inverter.

• SiC Power Inverter with DC Bus.

Figure 26 UMA pilot, connectivity scheme, describes a physical deployment of the University of Malaga demo site, where we can see that most of the entities involved will be developed throughout the life of the project. Some of the substations will be virtualized.


47


Figure 26 UMA pilot, connectivity scheme

4.2.3 Yncréa Hauts-de-France engineering school and Institut Catholique de Lille, (district of academic buildings)

The pilot is carried out in a block of academic buildings in Lille, France. The buildings are connected to the electricity grid by a feed point. PV panels are installed on two buildings and energy storage is connected to the system for discharging and charging mode and six EV charging points are installed in the parking of the block. A Supervisory Control and Data Acquisition (SCADA) system is developed with the following capabilities:

• Receive global power consumption measurements of each building.

• Receive forecast of PV production based on satellite images.

• Control the store mode and its power reference.

• The possibility to apply management algorithms.

• Communication and control of EV charging point.

Figure 27 Yncréa Hauts-de-France engineering school pilot, shows the demo site where the first approach is to install three CMUs with API accessing to local Building Automation and Control System (BACS) and Building Energy Management System (BEMS).


48


Figure 27 Yncréa Hauts-de-France engineering school pilot

Figure 28 YNC pilot, connectivity scheme shows the isolated pilot diagram with the existing technologies in black and the entities developed in the project in blue.

Figure 28 YNC pilot, connectivity scheme

4.2.4 Technical University of Denmark (Summer Houses) For this pilot in Denmark, 15 summer houses have been chosen. These houses are

equipped with ICT communication devices, IoT sensors, heat and Model predictive control (MPC) controller. These houses count with several smart solutions such as a digitalization hub


49


to host grey-box models for the individual summer houses and pools and provide online forecasts of wind and solar power generation. Each house will be controlled using online forecasts of the CO2 emissions (see Figure 29 Technical University of Denmark pilot).

Figure 29 Technical University of Denmark pilot

These solutions aim to control the consumption based on Price/CO2 to offer the capability to support voltage regulation and to assess to what extend the controllable variable demand of swimming pools can be used to improve the resilience of the local distribution network and the overall power system.

Figure 30 DTU pilot, connectivity scheme shows the pilot diagram with the existing

entities (black) and the ebalance-plus technologies that will be developed (blue).

Figure 30 DTU pilot, connectivity scheme


50


4.2.5 In-Lab emulator for smart grid technologies The In-Lab emulator will be used as a model of a defined grid topology. In this model some

aspects of the real grid are abstracted. One of the aspects is communication. The main goal of the emulator is to allow experimenting with the energy management algorithms and the real energy flows that are captured by the real hardware are used to control the algorithms. The communication level in the emulator has the main task to move data between the components. But it is not our focus to emulate communication related aspects that may influence the system on the data plane, like delays or data throughput. But it is still open if these aspects will not be addressed in a future version of the emulator, e.g., to identify the communication bottlenecks.

4.3 Communication protocols stack

This section presents a preliminary approach of the suite of communication protocols and standards that will be part of the demo sites, this approach comprises the set of protocols stacks, according to the technical specifications of the entities involves in each demonstrator.

The selection of the communication protocols will be subject to progressive analysis and

modifications, according to the implementation and development needs of the demo sites during the project life.

Previously, the physical schemes of the demo sites have been described in Section 4.2.

This section offers a preliminary option for the communication stack of each one of the demo sites, taking into account some considerations:

• This initial selection comprises only part of the final set of technologies. It is due to the

fact that, as it is shown in demo sites diagrams, several entities will be developed during

the project and the decision about them is currently studied by the consortium.

• In the same manner as it was done in the analysis of the protocols, the following

methodology has been matching them with the layers of the ISO/OSI model, here the

communication between the different entities will be represented by a protocols stack

described for layers.

• Some layers, e.g. the physical layer, are out of scope being defined by the device

providers and existing installations in the demo sites, (fiber optical, Ethernet, mobile

network).

Following, based on next logical demo site schemes, the suitable protocols and the provisional selection is defined to guaranty a high grade of compatibility and interoperability.

The University of Calabria (Smart grid)

Figure 31 UNC logical scheme represents the logical scheme of the demo site, where the µ-grid block comprises a set of components such as heat pumps, thermal storage, lighting, PV field, mCHP, or EV charging points. All these components cover a range of protocols pointed out in Table 14 UNC technical specifications. For this reason, in Figure 32 UNC protocols stacks showing the protocols stacks diagram, the protocol stack of this block may change.


51


Figure 31 UNC logical scheme

Device Supported protocol MVGMU Modbus, DNP3, IEC60870

LVGMU Modbus, DNP3, IEC60870

CMU Modbus, MQTT

DERMU Modbus, MQTT

IoT gateways Modbus RTU, Bluetooth, GPRS, WiFi, Ethernet, SNMP

IoT Platform Modbus, OPC, LonWorks, KNX, BACnet, IEC62056-21, SNMP, MQTT

IoT devices Modbus, IEC62056-21, ZigBee, WiFi, Z-Wave, Bluetooth

Smart batteries HTTPS API

PLC Modbus TCP/RTU, MQTT

Smart meter IEC62056-21

µ-grid KNX, BACnet, CANbus, OCCP 1.5

Table 14 UNC technical specifications


52


Figure 32 UNC protocols stacks

The University of Malaga, (Smart Campus)

In this case, as it is noticed in Figure 33 UMA logical scheme, the component MVGMU is virtualized, so its protocols stack is omitted in Figure 34 UMA protocols stacks. Considering the LVGMU, there are two in the SS, one virtualized and a second, physical LVGMU.

Figure 33 UMA logical scheme


53


Device Supported protocol LVGMU Modbus, DNP3, IEC60870

CMU Modbus, MQTT

DERMU Modbus, MQTT

V2G DC/DC OCCP 2.0

SiC DC/AC Power Inverter

Modbus

Smart batteries HTTPS API

Smart meter Modbus, IEC62056-21

Table 15 UMA technical specifications

Figure 34 UMA protocols stacks

YNC (district of academic buildings)

In the same manner, as for the previous demo site, the MVGMU and LVGMU are virtualized, so their protocols stack blocks are omitted in Figure 36 YNC protocols stacks. In Figure 35 YNC logical scheme and Figure 36 YNC protocols stacks several black blocks appear. Their protocols stacks will be similar to the rest of blocks in the diagram. That means, all will work over IP and will use MQTT as application layer to avoid future compatibility problems.


54


Figure 35 YNC logical scheme

Device Supported protocol IoT Devices Modbus, OPC, LonWorks, KNX, BACnet, IEC62056-21, MQTT

EV Charging Point OCCP 1.5

V2G OCPP 2.0

Table 16 YNC technical specifications

Figure 36 YNC protocols stacks


55


Technical University of Denmark (Summer Houses)

Figure 37 DTU logical scheme

Device Supported protocol CMU Modbus, MQTT

Table 17 DTU technical specifications

Figure 38 DTU protocols stacks

Demo site summary

As can be noticed, all protocols involved in the demo sites work over IP. It facilitates

the compatibility of the whole platform due to the extended used of this protocol. Related to the data link layer, most of the devices and solutions support MODBUS protocol, for this reason, it will be the first option to adopt always it will be possible.

The presence of MQTT, in most of the technical specifications of the components,

makes it a selected application protocol. MQTT can present some disadvantages in real-time applications due to an inefficient bandwidth usage but this problem can be avoided thanks to gateway solutions that previously analyze the data from the end devices, sending asynchronous periodic reports and events when the values are out of range or an alarm is active.

Nevertheless, the previous schemes show some blocks or protocols stacks that don’t

present these protocols, it is the case of devices and solutions focused in EV services that count with specific protocols as CANbus and OPCC or the case of IEC62056-21 for smart meters.

The possible compatibility problems between protocols are solved with gateways that

enable a translation from the original protocol to the desired protocol.


56


5 Conclusion

This document offers an overall perspective of current communication technologies and

protocols for Smart Grid, specifying their common usage into the energy sector as well as their

strengths and weaknesses and how these take them in the proper choice depending on

several requirements such as the costs, their deployment in the region or the interoperability

with the rest. The goal of this document is the guide to implement the e-balance-plus

communication platform, WP5. This document offers an initial networking solution that

guarantees the communication between the entities involved in the demo sites presentation,

Section 4.2.

Communication and data exchange is one of the aspects that will be assessed by the In-

Lab emulator, introduced in Section 4.2.5. This emulator will allow experimenting with the

energy management algorithms developed in the project. The security is tackled in D5.2 and

the security and privacy mechanism obtained along with the communication protocols stacks

provided in this document will be used to validate the middleware platform implemented in

D5.3 for the control and management of the information required by the energy algorithms

mentioned previously. The integration of the communication platform in D5.4 and the

implementation of platform prototypes in D5.5 will allow following the development and

evolution of this initial solution toward the final version of the system, that will be evaluated in

the uses cases implemented in the different demo sites, in WP6.


57


Annex 1: Comparison of technologies

for Smart Grid

TABLE I. The comparison of communication technologies in Smart Grid. “Smart Choice for the Smart

Grid: Narrowband Internet of Things (NB-IoT)”.

TABLE II. The communication requirements of different applications. “Smart Choice for the Smart Grid: Narrowband Internet of Things (NB-IoT)”.


58


Table 1. Summary of wired communication technologies for Smart Grid. “The role of communication systems in smart grids: Architectures, technical solutions and research challenges”

Table 2. Summary of wireless communication technologies for Smart Grid. “The role of communication systems in smart grids: Architectures, technical solutions and research challenges”


59


References

[1] M. P. S. R. Murat Kuzlu, "Communication network requirements for major smart grid," 2014.

[2] D. S. T. K. S. E. Vehbi C. Gungor, "Smart Grid Technologies: Communication Technologies and Standards," 2011.

[3] A. Sendin, "Telecommunication networks for the smart grid," Boston : Artech House, 2016.

[4] E. &. Young, "Kosten-Nutzen-Analyse für einen flächendeckenden Einsatz intelligenter Zähler, Studie im Auftrag des Bundesministeriums für," 2013.

[5] G. K. T. P. D. N. J. H. R. H. Campfens, Performance of LTE for Smart Grid Communications, 2014.

[6] Y. C. X. C. D. W. L. Y. Yuke Li, "Smart Choice for the Smart Grid: Narrowband Internet of Things (NB-IoT)," 2017.

[7] [Online]. Available: www.eebus.org.

[8] [Online]. Available: www.dnp.org.

[9] I. D. T. S. Ihab Darwish, "Vulnerability Assessment and Experimentation of Smart Grid DNP3," January 2016.

[10] M. P. S. S. Jonathan Butts, "A Taxonomy of Attacks on the DNP3 Protocol," 2009.

[11] M. Nixon, "A Comparison of WirelessHART and ISA100.11a," 2012.

[12] S. S. J. S. S. Duarte Raposo, "Industrial IoT Monitoring: Technologies and Architecture Proposal," 2018.

[13] N. S. Bhat, "Design and Implementation of IEEE 802.15.4 Mac Protocol on FPGA," 2012.

[14] E. R. X. V. Jonathan Muñoz, "Overview of IEEE802.15.4g OFDM and its Applicability to Smart Building Applications," 2018.

[15] "www.eebus.org," [Online].

Networking layer specification - ebalanceplus

Documents

Transcript of Networking layer specification - ebalanceplus