High-level Smart Meter Data Traffic Analysis

(1)

High-level Smart Meter Data Traffic Analysis – ENA Authorised Parties

High-level Smart Meter Data Traffic

Analysis

For: ENA

May 2010

Engage Consulting Limited

Document Ref: ENA-CR008-001-1.4

Restriction: ENA Authorised Parties

(2)

Document Control

Authorities

Version Issue Date Author Comments 0.1 01st_{April 2010} _{Viktorija Namavira} _{First draft}

0.2 06th_{April 2010} _{Viktorija Namavira} _{Tom Hainey comments implemented} 0.3-0.6 08th_{April 2010} _{Jane Eccles/ James Boraston} _{General check of the report}

0.7 12th_{April 2010} _{Tom Hainey} _{Clarifications added}

0.8 12th_{April 2010} _{Simon Harrison} _{Comments regarding protocols}

0.9 14th_{April 2010} _{Tom Hainey} Update following QA of model & ENA ICT Group feedback

1.0 28th_{April 2010} Viktorija Namavira / Tom Hainey

Update following ENA members responses.

Provides insight into potential ‘Peak’ data traffic requirements.

1.1 5th_{May 2010} _{Tom Hainey} _{Updated with ENA comments on V1.0} 1.2 7th_{May 2010} Tom Hainey / Viktorija

Namavira Updated with ENA comments on V1.1 1.3 10th_{May 2010} _{Tom Hainey} _{Update with some comments on V1.2} 1.4 12th_{May 2010} _{Tom Hainey} _{Update of Executive Summary} Version Issue Date Reviewer Comments

0.8 12h_{April 2010} _{Tom Hainey} _{Review of First draft} 1.0 29th_{April 2010} _{Tom Hainey} _{Review of Updated Draft}

1.1 5th_{May 2010} _{Tom Hainey} _{Review of ENA suggested changes} 1.2 7th_{May 2010} _{Craig Handford} _{Quality Review}

1.3 10th_{May 2010} _{Tom Hainey} _{Updated with some comments on V1.2} 1.4 12th_{May 2010} _{Tom Hainey} _{Updated of Executive Summary} Version Issue Date Authorisation Comments

0.8 12th_{April 2010} _{Tom Hainey} Issue to ENA for Distribution together _{with Excel based ENA data traffic} analysis.

(3)

1.0 29th_{April 2010} _{Tom Hainey} _{Issued to ENA.} 1.1 5th_{May 2010} _{Tom Hainey} _{Issued to ENA} 1.2 7th_{May 2010} _{Craig Handford} _{Issued to ENA} 1.3 10th_{May 2010} _{Tom Hainey} _{Issued to ENA} 1.4 12th_{May 2010} _{Tom Hainey} _{Issued to ENA}

Distribution

Recipient 1: Alan Claxton Recipient 2: ENA Members

(4)

Executive Summary

This data traffic evaluation is based on a set of assumptions related to the raw data being transferred across the smart metering system and the overheads on that process typically introduced by security and the selected communication protocols being used. This evaluation has assumed that the transport protocol used will be TCP/IP. The reason for choosing TCP/IP protocols is that they are commonly used in smart grids and smart metering communications in pilot projects in Europe, USA, Australia and other regions and because TCP/IP creates a relatively high overhead in data transmission messages. TCP/IP protocols will therefore represent the higher end of requirements of the communications infrastructure in terms of packet sizes associated with data transmission. It follows that assuming TCP/IP will provide a robust indicative estimate of the data packet sizes that each meter and the wider metering system will need to deal with on both an individual activity and annual basis. These assumptions would need to be refined if different protocols were assumed to apply.

The approach uses Use Case scenarios (Reference 2) to define the detail surrounding the data that will need to be exchanged to enable network operators to undertake certain activities in support of network planning and also, to an increasing extent over time, in the active management of smart grids. This includes data storage, data transmission and response time granularity assumptions, which facilitate the understanding of the amount of data stored at the meter, the size the transmitted data packets will need to be, and how often and how quickly they will need to be sent.

To support their requirements, network operators envisage that certain data will need to be stored within the meter for a minimum of 3 months; this aligns with ENA’s understanding of suppliers’ requirements for data storage at the meter. The meter will therefore need to have sufficient memory capacity to accommodate both these requirements.

Based on the set of assumptions described in this report, the data flow volumes that will be generated by network operators’ business processes, both on a ‘per meter’ and ‘total meter population per annum’ basis, are shown below (assuming a population of 27 million electricity meters and 20 million gas meters):

Meter Type Single Meter p.a. Total Meter Population p.a.

Electricity Less than 1.5 MB1 _{30 – 40 TB}2

Gas Less Than 1 MB 15 – 20 TB

TOTAL - 45 – 60 TB

Table E.1 below summarises for a single electricity or gas meter the following:

• Data granularity registered at the meter – period covered by the data; • Data Transmission granularity – frequency data will be transferred; • Latency required – maximum acceptable transfer time for data;

1_{1 Megabyte = 10}6 _bytes 2_{1 Terabyte = 10}12_bytes

(6)

• Cumulative per activity data volume in bytes; • Cumulative data volume per activity per year.

(7)

Engage Consulting Limited Page 7 of 62

T 0207 4050740 W www.engage-consulting.co.uk E [email protected]

Table E.1 – Details of Electricity & Gas assumptions and Use Case data requirements (per meter)

ELECTRICITY USE CASES Data granularity

registered at the meter Data transmission granularity req. (command ENA Latency execution time)

Cumulative per activity (bytes)

Cumulative Data volume per year

(bytes) Assessment of network performance

Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom

Basic Flow – Data Periodically HH average 3 months on availability _{145,888 583,552}

Basic Flow – DNO Requests data On event (assumed once every 3 months)

HH average

Once every 3 months

(1 month of ½ hour data) 12 hours 41,489 165,956 Use Case 02 - Determine network impact of proposed new demand / generation connections

Basic Flow on event (assumed once

every 3 months) HH Average

3 months

(1 month of ½ hour data) 12 hours 41,489 165,956 Use Case 03 - Determine network impact of proposed increase in demand / generation at existing connection points

Basic Flow on event (assumed once

every 3 months) HH Average

3 months

(1 month of ½ hour data) 12 hours 41,489 165,956 Use Case 04 - Monitor demand and generation profiles for network load forecasting – See Use Case 01

Use Case 05 - Determine Latent Demand due to Embedded Generation – See Use Case 01 Use Case 06 - Identify Voltage Quality Issues

Basic Flow on event (assumed once a

month) Assumed send Reports every 6 months) 12 hours 656 1,312 Actively manage network / System Balancing

Use Case 07 - Collect data for active management Basic Flow – As in Use Case 01 but with a lower latency

required HH average As Required Lower Latency than UC 01 As UC 01 As UC 01

Use Case 08 - Active network management of network voltage – Uses Voltage information captured to instigate actions on DNO Assets to control voltage, as well as having the same data flows as Use Case 09 to undertake actions in the household to address voltage issues via ToU/Peak tariffs, control household equipment etc.

09 Use Case - Perform Active Management of Network Power Flow 1. Operation of (Distribution Use of System) Time of Use

tariff (Scenario 1)

on occurrence (assumed to

happen every 3 months) 3 months Up to 5-15 min. to configure. TOU Readings 12

hours

2,006 8,024

2. Operation of (Distribution Use of System) Real Time Pricing

(Scenario 2)

happen every 3 months) 3 months Up to 5-15 min. to configure. RTP Readings 12

hours

(8)

(bytes) 3. Power Sharing by Maximum Thresholds (Scenario 3) on occurrence (assumed to

happen every 3 months) 3 months Between Metering System and IHD via HAN – no DNO related data traffic

Not related to

DNO

Data flows between Meter & IHD, nothing

to DNO

4. Direct Control, by DNOs, of appliance or micro-generation

(Scenario 4)

happen every 3 months) 3 months 5-15 min. for up to 1,000 meters (may need to be

repeated across the country)

1,194 4,776

System Balancing

10 Use Case - Perform System Balancing

Same data flow as in Use Case 09 On occurrence (assumed to

happen every 3 months) On event (assumed to happen once every 3 months) 5 – 15 min latency (On localised basis, which is

constraining factor, only small subset of meters involved – assume 1,000. However at national level could

be millions)

See UC

09 See UC 09

11 Use Case - Check effectiveness of active network management / system balancing measures 1. The Smart Metering System measures power flow and

voltage data (as in Use Case 01) HH Average 2. DNO requests data

3. Smart System sends data on occurrence (assumed to happen once every 3 months)

3 months

(1 month of ½ hour data) 5-15min. 41,489 165,956 Actively manage network during planned and unplanned outage

Use Case 12 - Notify consumer of planned outage 1. Consumer notification of planned / emergency outage 2. Consumer notified that outage is over

on occurrence of the event (assumed one planned

outage per year)

once per year Message confirmation within

12 hours. 5-10 min. (within

Hour)

1,791 1,791

Use Case 13 - Query Meter Energisation Status to determine outage source and location 1. False Outage Report (DNO checks meter energisation

status: supply on) On occurrence of the event (assumed to happen once per year)

once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of

(9)

(bytes) extreme weather

events. 30 sec per single

meter 2. Confirmed network outage On occurrence of the event

(assumed to happen once per year)

once a year 1,000 meters in 15 min. or 100,000 in 1 hour; in cases of extreme weather

events. 30 sec per single

meter

1,194 1,194

Use Case 14 - Send Alarm to DNO during network outage 1. Outage alarm sent to the Distribution Network

Operator On occurrence of the event (assumed to happen once per year)

once a year For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 597 597

Use Case 15 - Verify restoration of supplies after outage

1. Meter notifies DNOs of power restoration On occurrence of the event (assumed to happen once

every 6 months)

6 months For customers associated with LV faults (1,000 max) 5 mins, where as volumes associated with HV faults, 15 mins is adequate 597 1,194

Use Case 16 - Regulatory Reporting of outages 1. DNO requests stored outage information

2. Meter sends outage report on event (assumed once every 3 months) (Reporting period) 3 months 12 hours 1,161 4,644 Use Case 17 - Restore and maintain supply during outages

1. Smart Metering System sends "power restored"

message to the DNO On occurrence of the event (assumed to happen once every 6 months)

6 months 5 min. _{597 1,194}

2. DNO activates the maximum power consumption threshold

3. Smart Metering confirms activation of the maximum

On occurrence of the event (assumed to happen once

every 6 months)

(10)

(bytes) power consumption threshold

Manage safety issues

Use Case 18 - Manage meter safety alarm

1. Smart Metering System sends alarm to DNOs on event (assumed once a

year) once a year 15 min 597 597

2. DNO remotely disconnects the supply through the Smart Metering System (where necessary)

3. The Smart Metering sends the confirmation message to the DNO

on event (assumed once a

year) once a year 15 min. 1,194 1,194

Use Case 19 - Manage extreme voltage at meter 1.The Smart Metering System sends alarm of a voltage level outside its configured tolerance levels

2.(Optionally) the Smart Metering System auto-disconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO 3.Supply is enabled by DNO after emergency/safety action

On occurrence of the event (assumed to happen once

every 6 months) on event (assumed once a

year) 6 months once a year Alarm in up to 15 min. 5 min. 1,791 2,388

Support network activities

Use Case 20 - Configure Smart Metering System

1. DNO configures meter reading registers on event (assumed every 3

years) every 3 years minutes up to 12 Assumed 15 hours (i.e. confirming meter

changes)

1,194 1,194

2. DNO configures meter alarms on event (assumed every 3

years) every 3 years As Above 1,194 1,194

3. DNO configures meter load threshold on event (assumed every 3

years) every 3 years As Above 1,194 1,194

Basic Flow Total (Everything works as

(11)

GAS USE CASES Data granularity

(bytes) Use Case 1 - Gather information for planning

1.The Smart Metering System sends the recorded gas demand data to the GDNO (6min)

Every 6 minutes all day for the winter period (Was

November-March) - 6 months

once a year 5 days _{351,544 351,544}

2.The Smart Metering System sends the recorded gas

demand data to the GDNO (daily) every day at 6 am every 6 months 5 days 1,302 2,604

Use Case 02 - Configure Smart Metering System

1. GDN configures meter reading registers on event (assumed to

happen every 3 years) every 3 years almost real time confirmation 2,388 2,388 Use Case 03 - Disable Supply of Gas

1. Gas is disabled by GDNs on event (assumed once

every 3 years) every 3 years Up to 1 hour (was almost real time) 1,791 1,791 Use Case 04 - Display Messages from Gas

Distribution Network

1.GDN sends notification to IHD on occurrence to happen

once every 10 years every 10 years Up to 1 hour (was almost real time) 1,194 1,194 Use Case 05 - Measure and Store Calorific Values

at the meter

Update CV daily daily Up to 1 hour (was

almost real time) 1,177 429,605 (Optionally) GDN update the message on occurrence (assumed to

happen once a month) monthly Up to 1 hour (was almost real time) 1,177 14,124 Tampering Notification send to GDNs

meter sends tampering notification to GDNs on occurrence (assumed

once a year) once a year almost real time 597 597

Basic Flow Total (Everything works as

(12)

Currently, Network Operators are able to rely on Radio Teleswitching, which has the capability to address large populations of meters in a matter of seconds, for control of ‘off-peak’ appliances such as electric storage (space) and water heating. However, this service is due to be withdrawn in 2014. Network Businesses also have the capability, through their SCADA systems, to identify major disruptions to their network that affect many thousands of their customers. In both these examples, the communications system is able to transmit the data at the necessary transmission granularity and latency. With regard to the smart metering communications system, one concern for network operators will be to ensure that where required to do so, it will be able to simultaneously transmit data to or from a few hundred, or perhaps up to a thousand, meters that are geographically closely located (e.g. covering one or more 11kV feeders over a small geographical area e.g. less than 1 km2_). Some communication technologies that could be deployed would support fast response times for several hundred meters. For example an LV network Power Line Carrier system acting through a local concentrator could provide a dedicated communication path for perhaps 100 meters at premises served from a given distribution substation. However, with some communication technologies, such as GPRS where a local transmitter might serve an area covered by perhaps hundreds of distribution substations, the communication infrastructure might be put under considerable strain should it be called upon to handle simultaneous data flows to or from all meters associated with the networks served by those substations. The risk is that if the communication infrastructure is not sufficiently sized to deal with these ‘peak’ activities within the required response times (latency), this could result in the local communications infrastructure becoming overloaded and unable to provide the functionality required by network operators. In a ‘worst case scenario this could conceivably result in the network operating outside its thermal and voltage capabilities.

Clearly the required response times for processes supporting planning activities tend not to be too onerous; for example 12 hours is a typical latency figure used for these activities in the ‘Assess Network Performance’ Use Cases. However, where there is a need to actively manage parts of the network, the latency will need to align with network operators’ requirements to receive, assess and act on the information within a given critical timescale. In general terms, the active management of networks will require that the communications infrastructure is able to support a higher speed of data transfer. How quickly and widely active network management will need to become commonplace will depend on the speed of uptake of new sources of electricity demand and production such as electric vehicles (EVs), heat pumps and micro-generation. However, it is anticipated that there will be some early clustering of these sources of demand and generation that will require pockets of the network to be actively managed in the very near future.

To gain an insight into these ‘peak’ activities Section 4.3 of the report considers a number of Use Case examples for a varying number of meters and different potential requirements for latency. An example is illustrated in Section 4.3.1.2 (Use Case 01 – Request latest month’s data for all relevant electricity parameters). This data capture process supports the assessment of the network’s performance (planning activities) initially assuming relatively high acceptable latency, but it will also form a key part of the active management of the network in the future (Use Case 07) with the deployment of new sources of demand such as EVs and heat pumps etc. The latency in this active management stage will then need to be much lower e.g. 15 minutes.

If the network operator needed to acquire data from 600 - 1,000 meters from a localised part of their network to support planning processes, and this needed a response only within 12

(13)

hours, then the local communication infrastructure covering these meters would only need to support a speed of 5 – 8 kbps3_{. However, once new types of demand have been connected to} the network and there is an increasing need for network operators to proactively manage their networks, they will need to capture certain data in a much shorter timeframe to facilitate the necessary speed of operational response. If this resulted in a requirement for a response time of 15 minutes rather than 12 hours, then the local communication infrastructure would need to deal with data traffic in the 0.2 – 0.4 Mbps range (Million bits per second). These figures assume no group addressing or broadcast capability in place, so represent what could be considered as a worst case response time requirement.

In conclusion the key points to note from this work are as follows:

• Initially network operators only need data for network planning purposes which will normally be collected on a rolling 3 month basis. The volume of this data and the required latency should be easily managed by any communication solution deployed;

• The required latency for communicating with the smart metering system will reduce as new demand and production are deployed and this will require any communication infrastructure to be able to deal with these potential local ‘peaks’ within the operational timescales that network operators can respond.

This report and analysis supports the conclusions stated above and describes how network operators’ requirements of the smart metering system will evolve over time to support the needs of a smart grid.

(14)

1 Introduction

For Great Britain (GB) smart metering, we now know the high level structure of the Central Communications model. We are therefore able to make some key assumptions on the structure and scope of services within that model.

The particular data traffic scenarios that have been used within this analysis reflect the smart meter related data flows associated with domestic and small-to-medium enterprise smart meters and the use of the communications infrastructure to support smart grid functionality. The scenarios are aligned with specifically developed Use Cases. This approach has enabled a structured and easy to understand analysis of the data traffic to be performed.

By applying the Use Case approach, the GB smart metering requirements will remain solution and technology agnostic, supporting innovation and communication technology interoperability in the future. The use of Use Cases will also provide the basis for assessment of data volumes and traffic, which will be critical in selecting the communications service options and subsequent solutions.

1.1.1 Smart Metering Scenarios

To fully inform the Ofgem E-serve process it is important to assess the key Use Cases using relevant data exchange flows. The scenarios highlight the level and detail of data traffic incurred by the specific activity from the meter, or network operator side that the communications infrastructure will need to support. This helps to estimate more detailed data traffic volumes which in turn will highlight the minimum data size requirements that will need to be handled by a smart meter, including data storage requirements at the meter and the data volumes that meter might need to handle at one point in time. The analysis also helps to identify the data communication speed requirements at the meter depending on the activities carried out, which will give some idea of the communication solutions needed for smart meters.

Such analysis additionally provides some facts that will allow the appropriate Cost Benefit Analysis to be undertaken. This will inform the development of the Ofgem Smart Metering Prospectus.

1.2 Background

Use of smart meters will cause significant data traffic flow as meters will be configured, set and read remotely using the communication network for smart meters over different periods e.g. weekly, daily, hourly, etc. In order to optimise network requirements for smart meters, and develop appropriate standards, it is important to keep in mind the data traffic flow requirements to ensure reliable and secure smart metering system data exchange.

1.3 Purpose

The objective of this report is to construct scenarios aligned with each Use Case (Reference 2), identify the information flow and data to be exchanged, and estimate the amount of data that will be flowing from the meter to the network

(15)

operator and other authorised parties and vice versa. This will help the assessment of smart meter communication requirements for dealing with the smart grid related data requirements. Such analysis provides an overview of the system requirements to ensure a reliable and effective exchange of data and provide the necessary ability to regulate demand, optimise the grid, and allow further innovation.

1.4 Scope

The scope of this report includes the analysis of data traffic between the meter and the network operators. This report does not include network traffic analysis between independent service providers, suppliers or linked entities such as smart home appliances and other utility meters (water, heat).

1.5 Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in ENA. Engage Consulting Limited has an unlimited licence to use any techniques or know-how developed by it under this Agreement on its future work.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Engage Consulting Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.

(16)

2 Data Traffic Analysis approach

This data traffic analysis should be considered as a starting point to gain some insight into the potential level of data traffic that any communication network would need to support for each smart meter type over any period of interest. The analysis is based on a number of assumptions stated below for the typical activities that will underpin the Use Cases provided in Reference 2. The assumptions used were considered reasonable for this type of analysis based on feedback from ENA members. However, the assumptions can be modified later to meet any further developments within the sector thus allowing a reassessment of the requirements at a later stage. A Workbook (Reference 3) that forms the basis of this work is also provided as a companion to this report for use by interested parties.

2.1 Annual Data Traffic Level v Potential Peak values

The focus of the evaluation has been on identifying:

1. The overall data traffic for each meter over a year. (See Section 4.2)

2. The potential requirement of needing to notify or receive data from a group of meters at periods of stress on the system (proxy for ‘peak’ activity). (See Section 4.3).

2.2 Use Case Scenarios - Assumptions

The project has outlined several Use Cases (Reference 2) that are relevant to network business requirements for smart metering to support smart grids. Each Use Case consists of various scenarios, which describe an occurrence, or a general process of data exchange. Use of scenarios helps to identify various data exchange flows depending on the process and trigger event that caused the data to be exchanged, thus making sure that the basic data flow is identified and presented in the analysis.

Table 1 (electricity) and Table 2 (gas) summarise the potential data exchange scenarios relevant to the network operator’s smart grid activities and the planning of smart grid activities based on the required interval data requirements. The scenarios will be used in presenting Raw Data Analysis and TCP/IP protocol based analysis later in the report.

The column “Data granularity at meter” indicates how often the data is being recorded at the meter, but is not being sent immediately. This helps to estimate how many values the meter collects before actually transmitting it to the central data depository.

The column “data transmission granularity” shows how often it is estimated that the data will actually be transmitted between the meter and the end party i.e. the Central Data Repository System or network operators. Where it is stated “on occurrence” this means that the data is transmitted as soon as the meter registers the event as occurring. The assumption of how often the scenario is likely to occur is given in brackets and will be used purely for data traffic estimation in the potential smart grid operation scenario.

(17)

The column ‘Response Time’ represents how quickly the network operators would generally require the metering system to execute the commands, or to submit the requested data.

Assessment of network performance

Use Cases Potential data exchange scenarios:

Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO Response time (latency) required by ENA

1. Data is periodically sent from the Smart Metering System (import/export; real/reactive flow and voltage as specified by DNOs)

Every HH average Every 3 months Assumed that DNO’s would be able to access the data by being able to log into the Central data Repository (assumption)4 2. DNO requests data (in cases where

the data is needed earlier then the configured data submission )

3. The Smart Metering System sends the requested data (assumed one month of HH real/reactive import/export, micro-generation real/reactive flow and voltage) (in cases where the data is needed earlier then the configured data submission)

On event (assumed to happen once every 3 months) As above Every 3 months As above (1 month of ½ hour data) 12 hours 01_Monitor Power Flows

and Voltage Levels to Identify Thermal Capacity and Statutory Voltage Headroom

Alternative Flows: Metering system failure:

1. Smart Metering System rejects the message as invalid

2. The Smart Metering System does not have any measured data stored 3. The DNO does not receive the data from the Smart Metering System (in case of scenario 1 and 2) On event (assumed to happen once a year) As above 12 hours is considered reasonable for an error report to reach DNO’s in this case If data is requested with an expectation that it arrives within 12 hours, it seems reasonable for a ‘fail’ alarm to be delivered in the same timescale as above Once a year As above As above 12 hours As above As above 02_Determine network impact of proposed new demand / generation connections

1. DNO requests stored HH power flow and voltage data (and

micro-generation data where available)

2. Smart Metering system retrieves the requested data (assumed one month of HH real and reactive energy import and export, real/reactive generation energy and

On event (assumed to happened once every 3 months) As above On event (assumed to happen once every 3 months) As above (1 month of ½ hour data) 12 hours 12 hours

4_{It is assumed that the DNO’s are able to access data from the Central Data Depository. The data is for planning} purposes thus a 3 months delay is acceptable.

(18)

Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO Response time (latency) required by ENA voltage data) Alternative flow:

1. The DNO does not receive the data On event ( assumed to happen once a year) On event ( assumed to happen once a year) 12 hours

1. DNO requests stored HH power flow and voltage data (and

micro-generation data where available) 2. Smart Metering system retrieves the requested data (assumed one month of HH real and reactive energy import and export, real/reactive generation energy and voltage data) On event (assumed to happen once every 3 months) As above Every 3 months As above (1 month of ½ hour data) 12 hours 03_Determine network impact of proposed increases in demand / generation at existing connection points Alternative flow:

1. The DNO does not receive the data On event ( assumed to happen once a year)

On event ( assumed to happen once a year)

12 hours

04_Monitor demand and generation profiles for network load forecasting

1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01)

Every HH average Every 3 months As per UC 01

05_Determine Latent Demand due to Embedded generation

1. At the defined interval the Smart Metering System collects the data and sends it to the DNO (please see Use Case 01)

Every HH average Every 3 months As per UC 01

06_Identify Voltage

Quality Issues 1. The Smart Metering System accumulates time and date stamped voltage quality events (assumed 6 events)

On event (assumed to happen once a month)

On event (assumed

every 6 months) 12 hours

Alternative Flow:

1. Meter fails to send the message On event (assumed to happen once a year)

On event (assumed to happen once a year)

12 hours

Actively manage network / System Balancing

1. Data is periodically sent from the Smart Metering System (import/export; real/reactive flow, real/reactive generation flow and voltage as specified by DNOs) as in Use Case 01

As Use Case 01 As required Once EVs, heat pumps etc. are common, this may need to happen more often and faster than for UC 01 e.g. 5-15 minutes 07_Collect data for

active management

Alternative flow:

1. Meter fails to send the message On event (assumed to happen once a year) On event (assumed to happen once a year) 12 hours 08_Active Management

of network voltage Uses Voltage information captured to instigate actions on DNO Assets to control voltage, as well as having the same data flows as Use Case 09 to undertake actions in

(19)

the household to address voltage issues via ToU/Peak tariffs, control household equipment etc.

1. Operation of (Distribution Use of

System) Time of Use Tariff On event (assumed to happen once every 3 months) On event (assumed to happen once every 3 months ) Up to 5-15 min. to configure, send to up to 1,000 meters TOU readings – 12 hours

2. Operation of (Distribution Use of

System) Real Time Pricing As above As above As above 3. Power Sharing by Maximum

Thresholds As above As above Related to Metering system and IHD, nothing to DNO 4. Direct Control, by DNOs, of

appliances or micro-generation As above As above 5-15 min for command execution to up to 1,000 meters (may need to be repeated across country) 09_Perform Active Management of Network Power Flow Alternative Flow:

1. Power Sharing by Maximum Power Thresholds – consumer does not turn off appliances

2. Power Sharing by Maximum Power Thresholds – consumer turns off some of the appliances As above As above As above As above 5-15 min. 5-15 min. System Balancing

Use Cases Possible data exchange scenarios:

Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO Response time (latency) required by ENA 10_Perform System

Balancing The same data flow as in Use Case 09 On occurrence (assumed every 3 months)

On event (assumed once every 3 months)

5-15 minutes (On localised basis, which is constraining factor, only small subset of meters involved – assume 1,000. However at national level could be millions).

1. The Smart Metering System measures power flow and voltage data (as in Use Case 01)

HH Average

2. DNO requests data (in cases where the data is needed earlier then the configured data submission )

On event (assumed to happen once a year). This may have low localised impact, but high concurrence. Potentially millions of meters. On event (assumed to happen once every 3 months) Within 15 min. 11_Check effectiveness of network management / system balancing measures

3. The Smart Metering System sends the requested data (assumed last real

(20)

Use Cases Possible data exchange scenarios:

Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO Response time (latency) required by ENA data) Alternative flow:

1. Meter fails to send the message On event (assumed to happen once a year)

On event (assumed to happen once a year)

12 hours

Actively manage network during Planned & Unplanned Outages

1. Consumer notification of planned /

emergency outage On occurrence of the event (assumed to happen once per year)

On occurrence of the event (assumed to happen once per year)

Notification of outage to be sent within 10 days to IHD before the outage; message confirmation within 12 hours.

5-10 mins if within hour.

2. Consumer notified that outage is

over As above As above As above

12 Notify consumer of planned outage

1. Smart metering system deems the request invalid for step 1

2. DNOs do not receive acknowledgement message for step 1

3. Smart metering system deems the request invalid for step 2

4. DNOs do not receive acknowledgement message for step 2

On event (assumed to happen once a year) As above As above As above On event (assumed to happen once a year) As above As above As above 12 hours

1. False Outage Report (DNO checks

meter energisation status: supply on) On occurrence of the event (assumed to happen once per year)

On occurrence of the event (assumed to happen once a year) Ability to send energisation queries to 1,000 meters in 15 minutes or 100,000 meters in 1 hour in the example of an extreme weather related event.

30secs for one meter 2. Confirmed network outage As above As above 30sec for one meter 13_Query Meter

Energisation Status to determine Outage Source and Location

1. Smart Metering system deems the request invalid (for step 1)

2. The Distribution Network Operator does not receive the message (for step 1)

As above As above

12 hours

14 Send Alarm during Network Outage to Identify Loss of Supply

1. Outage alarm sent to the Distribution Network Operator

(Note: Need to control number of outage alarms to avoid swamping communication infrastructure e.g. say only first 1,000 meters in any localised region).

On occurrence of the event (assumed to happen once a year)

Receive alarm within 5 mins for LV faults (1,000 max); up to 15 min for HV faults.

(21)

Estimated ENA related Data granularity at meter (registered at the meter) Estimated ENA Data transmission granularity to Central Data Repository/DNO Response time (latency) required by ENA Alternative flow:

1. Smart Metering System is unable to send the outage alarm message

2. DNOs do not receive notification

As above As above

12 hours

1. Meter notifies DNOs of power

restoration On occurrence of the event (assumed to happen once every 6 months)

On occurrence of the event (assumed to happen once every 6 months)

Receive alarm within 5 mins for LV faults (1,000 max); up to 15 min for HV faults. 15 Verify restoration of

supplies after outage

1. Smart Metering System fails to detect power restoration

2. DNOs do not receive message

On event (assumed to happen once a year) As above On event (assumed to happen once a year) As above 12 hours

1. DNO requests stored outage

information On occurrence (assumed every 3 months)

3 months

(Reporting period) 12 hours

2. Meter sends outage report As above As above As Above 16 Regulatory Reporting

on outages

1. Smart Metering System rejects the message as invalid

2. Smart Metering System does not have any of the requested information stored 3. DNOs do not receive notification

On event (assumed to happen once a year) As above As above On event (assumed to happen once a year) As above As above 12 hours

1. Smart Metering System sends “power restored” message to the DNO

On occurrence of the event (assumed to happen once every 6 months)

Approx. 5 min for command execution

2. DNO activates the maximum power

consumption threshold As above As above 15 min 3. Smart Metering confirms activation

of the maximum power consumption threshold

As above As above 15 min 17 Restore and maintain

supply during outages

1. DNOs do not receive power restored message

2. Smart Metering System deems the request invalid

3. DNOs do not receive the confirmation response On event (assumed to happen once a year) As above As above On event (assumed to happen once a year) As above As above 12 hours

(22)

Manage Safety Issues

1. Smart Metering System sends alarm

to DNOs On occurrence (assumed once a year)

On occurrence (assumed once a year)

15 min

2. DNOs remotely disconnect the supply through the Smart Metering System (where deemed necessary)

As above As above 15 mins

3. The Smart Metering sends the

confirmation message to the DNO As above As above 15 mins 18 Manage meter safety

alarm

1. DNOs do not receive the alarm 2. Smart Metering System deems the request invalid

3. DNO does not receive confirmation of the supply switch activating to cut-off supply

On event (assumed to happen once a year) As above As above On event (assumed to happen once a year) As above As above 12 hours

1. The Smart Metering System sends alarm of a voltage level outside its configured tolerance levels

On occurrence (assumed once every 6 months)

Alarm in 15 min

2. (Optionally) the Smart Metering System auto-disconnects itself from the network supply of electricity sending confirmation of disconnection to the DNO On occurrence (Assumed to happen once a year) On occurrence (Assumed to happen once a year) Alarm in 5min (Possibly require 30 secs to 2 mins)

3. Supply is enabled by DNO after

emergency/safety action As above As above Alarm in 5 min (Possibly require 30 secs to 2 mins) 19 Manage extreme

voltage at meter

1. The Smart Metering System fails to send the extreme voltage alarm

2. The Smart Metering System fails to auto disconnect As above As above As above As above 12 hours

Support Network activities

Data granularity at meter (registered at the meter) Data transmission granularity to Central Data Repository/DNOs Response time (latency) required by ENA

1. DNO configures meter reading registers (this is confirmed by the metering system) On occurrence – assumed to happen every 3 years On occurrence – assumed to happen every 3 years 2. DNO configures meter alarms (this

is confirmed by the metering system) As above As above 20 Configure Smart

Metering System

3. DNO configures meter load threshold (this is confirmed by the metering system) As above As above Assumed 15 mins up to 12 hours (i.e. confirming meter changes)

(23)

Data granularity at meter (registered at the meter) Data transmission granularity to Central Data Repository/DNOs Response time (latency) required by ENA Alternative Flow:

1. Smart Metering System deems the request invalid

2. DNOs do not receive notification

On occurrence As above

Table 2 – Summary of Gas Scenarios used for data traffic analysis per each Use Case

1. The Smart Metering System sends the recorded gas demand data to the Gas Distribution Network Operator ( assumed 6min interval data)

Every 6 minutes

every day Every year 5 days 2. The Smart Metering System sends

the recorded gas demand data to the Gas Distribution Network Operator ( assumed Daily registered data)

Every day at 6am Every 6 months 5 days 01 Gather information

for Planning

1. Meter does not communicate requested data to the authorised GDN party

2. Meter data reads are missing / corrupted

On occurrence of event (assumed to happen once a year) As above On occurrence of event (assumed to happen once a year) As above 12 hours

1. GDN configures meter reading registers (this is confirmed by the metering system) (frequency of readings detail) On occurrence – assumed to happen every 3 years On occurrence – assumed to happen every 3 years Confirmation almost real time

Use Case 02 – Configure Smart Metering System

1. Smart Metering deems the request invalid 2. GDNs do not receive confirmation

On event (assumed to happen every 3 years) As above On event (assumed to happen every 3 years) As above 12 hours

1. Gas is disabled by GDNs, meter

sends acknowledgment. Assumed every 3 years Assumed every 3 years Updated to 1 hour (previously assumed real-time for smart grid needs) Use Case 03 – Disable

Supply of gas

1. Smart Metering deems the request invalid 2. GDN does not receive confirmation

On event – assumed to happen once every 3 years As above On event – assumed once every 3 years As above 12 hours

1. Meter displays message from GDNs

to customer display On occurrence – assumed to happen once every 10 years

On occurrence Updated to 1 hour (previously assumed real-time for smart grid needs) Use Case 04 Display

Messages from Gas Distribution Network

(24)

In cases where meter does not measure CV at the meter:

1. GDN’s send Calorific Value to the

meter Every day

Daily

Updated to 1 hour (previously assumed real-time for smart grid needs) 2. Meter confirms the data has been

updated successfully to GDNs and

suppliers Every day Daily

Updated to 1 hour (previously assumed real-time for smart grid needs) 3. (optionally) GDN update the

message Assumed once per month Monthly 12 hours 4. Meter confirms the message As above As above As Above

Use Case 05 – Measure and Store Calorific Values at the meter

1. The Smart Metering System rejects the

message as invalid On event – assumed to happen once a year

Once a year 12 hours

Tampering notification

to GDNs Meter Sends tampering notification to GDNs On event – assumed to happen once a year

Once a year Almost real time.

Each scenario presents a data exchange between the smart metering system and the central data communication party, and/or network operators.

2.3 Data Size Assumptions Used

The analysis is structured to give an overview of the processes associated around the data exchange in a day to day situation using certain assumptions, which could be updated later to fit a more specific metering system set-up.

First of all a Raw Data analysis is provided, which provides an overview of the size of each data item as registered at the meter. It is assumed that the data will be stored at the meter for at least 3 months (in line with ERA assumptions for Suppliers).

Then, while giving consideration to the different protocols used for data communication, the TCP/IP protocol based data traffic analysis will be provided. The reason for choosing TCP/IP protocols is that they are commonly used in smart grids and smart metering communications in pilot projects in Europe, USA, Australia and other regions while being able to create some of the highest overheads in a data transmission message.

2.3.1 Raw Data Analysis - size assumption

Command/Request for data – request is usually a one byte request code and can contain commands such as the identification request, read request, write, negotiate, wait and terminate request. In order to assess the minimum data size requirements, the payload of the message can increase the command to up to 25 bytes; therefore this size is used in the analysis.

(25)

Response – The size of the response can vary significantly, depending on the activity, it can be 4 bytes when only one meter read is requested, for instance, the latest voltage read, or it can be over 100 bytes when asking for a meter performance report or a range of interval reads for the last 3 weeks.

Below is a table summarising assumptions made when considering the size of basic data exchanges.

Table 3 – Summary of Raw Data Size Assumptions

(Please note the bold numbers represent a summary of non bold numbers)

Data

Total size

(bytes) Breakdown

Command / Request (data flow to the meter) – request from the Authorised

Party for a certain data ₂₅

The request can be made to schedule reads, to update meter, to request reads on demand, to control load, to change tariff etc.

4 Real Power (import) (kW) 4 Reactive Power (import) (kVAr) 4 Real Power (export) (kW) 4 Reactive Energy (export) (kVAr) 4 Micro-generation Real Power (kW) 4 Micro-generation Reactive Power (kVAr) 4 Voltage

4 Power Factor

Meter Periodic Data read

4 GAS-per read*

Confirmation / Notification message ₂₅ Includes: Failure notifications, messages, etc. 18 _{This report is automatically produced when failure}

occurs within the system 2 Error Id 1 Switch Status 4 Timestamp 4 read voltage 4 read frequency 1 Report type 1 Check sum

Meter sends Error Report

1 Closing flag

150

This report is produced on occurrence of the failure or as scheduled to determine meter performance.

1 Status 4 Timestamp 2 Diagnostics

Meter sends Performance Report

(26)

140 Event Log (14 bytes per event) - assumed 10 events 1 Check sum

1 Closing flag

14 Outage report is sent after the supply has been restored

4 Outage detected timestamp 4 Supply restored timestamp 2 Event id

Meter sends Outage Report (1 outage registered) 4 Data Weekly read submission 28 7*8 (for electricity) 28 7*4 (for gas) One month of data (assumed to include Meter sends one month of HH real/reactive import/export, microgeneration real/reactive and voltage data) 40320 (4*48*30)*7 Last day HH import data summary 192 48*4 CV value for gas 8

2.3.2 Data Exchange Protocols and Communication Review

When data is sent from, or to, the Smart Metering System, the size of the data will increase depending on the protocols used within the end-to-end communication. In European projects a range of protocols and communication types are currently used for smart metering and smart grid purposes. Thus, for instance, a combination of Power Line Carrier (PLC) (in most cases between the meter and data concentrator) and GPRS (mostly between the concentrator and data administration) communication based on IEC 61334 S-FSK, DLMS/COSEM, TCP/IP protocols is used in Dutch DSMR, French ERDF, Spain’s and Italy’s smart metering projects. M-bus and SML protocols are widely used in German projects. Meanwhile, the recent announcement on smart metering roll out by British Gas includes GPRS and DLMS for WAN communication and alternative technologies where GPRS has no coverage and ZigBee for HAN communication.

Each protocol has certain data size overheads that can increase the size of the data substantially. Data size overheads include a certain data packet frame, which means that for every packet of data sent there will be a frame which includes meter id, equipment status, type of message, etc. The size of the packet frame depends on the communication protocol used. It can add from 10 to 50 bytes per packet of data sent. Table 4 below provides an overview of the most commonly used protocols for Smart Metering System Data Exchanges in Europe and other regions and provides data size overhead per packet depending on the protocol. Please note that the table includes both carrier protocols (e.g. TCP/IP, PLC FSK, PRIME) and the data encoding protocols (e.g. FLAG, DLMS, SML, ZSE). Data

(27)

encoding protocols would need a carrier protocol to actually move the data around.

Table 4 – Summary of characteristics of main protocols used for Data Exchange in Smart Metering Systems5

Transport Protocols Used For Physical Carriers Protocols: Estimated Protocol frame size (bytes) Remote AMR AMI PSTN GSM GPRS Low Power RF PLC Broadba nd6 PLC Narrowb and Mesh radio

IEC 61334 (S‐FSK, FSK, OFDM) 45 bytes7 Y Y ‐ ‐ ‐ Y Y8 ‐

IEC 62056‐31 Euridis9 45 bytes10 Y ‐ ‐ ‐ ‐ ‐ ‐ ‐

EN 13757 M‐Bus11 27 bytes ‐ Y12 ‐ ‐ Y ‐ ‐ ‐

TCP/IP protocol13 50 bytes Y Y Y Y Y Y Y

SITRED14 45 bytes15 Y Y Y Y

PRIME 8 bytes16 Y Y Y

EverBlu unknown17 Y Y Y Y

OPERA/UPA18 24 bytes19 Y Y ‐ ‐ ‐ Y Y ‐

ZigBee20 15 bytes Y Y Y

5_{http://www.openmeter.com/files/deliverables/OPEN-Meter%20WP2%20D2.1%20part4%20v1.0.pdf} 6_{PLC Broadband is still in development. IEEE P1901 (data rate expected: >100Mbits/s) is working} towards standardisation of this network. It is expected that it will take approximately another 4 years, before the standard will be confirmed. Other associations are also working on further PLC broadband developments, including: G.hn (data rate expected: 1Gbit/s) and OPERA (<205Mbps)

http://www.openmeter.com/files/deliverables/OPEN-Meter%20WP2%20D2.1%20part2%20v2.3.pdf 7_{http://www.openmeter.com/files/deliverables/OPEN-Meter%20WP2%20D2.1%20part2%20v2.3.pdf} 8_{http://www.openmeter.com/files/deliverables/OPEN-Meter%20WP2%20D2.1%20part4%20v1.0.pdf}_– AMI system is supported when used with DLMS/COSEM

9_{Euridis supports twisted pair local bus with carrier signalling. It is widely used in France. Work under} progress to adapt it to new needs with higher speed and use with DLMS/COSEM.

10

http://www.erdfdistribution.fr/fichiers/fckeditor/File/ERDF/2009/doc_linky/specification_linky/ERDF-CPT-Linky-SPEC-FONC-CPL_Linky%20PLC%20profile%20functional%20specifications.pdf

11_{M-bus is mainly used with heat, gas and water meters. It supports twisted pair local bus with base} band signalling and wireless in the unlicensed 868-980 MHz SRD

12_{AMI supported when used in conjunction with DLMS/COSEM}

13_{TCP/IP profile with GPRS is used in smart metering project in Netherlands.}

14_{SITRED (Integrated System for data Transmission on Electricity Distribution network) is Enel’s} proprietary solution. It includes its’ own data exchange and encoding application layers. It is being standardised as the ‘Meters and More’ protocol – see press release:

http://www.enel.com/ewcm/salastampa/comunicati_eng/1629732-1_PDF-1.pdf.dl 15_{The frame extracted from IEC 61334 FSK protocol, which is a Physical Layer of SITRED.} 16_{http://www.iberdrola.es/webibd/gc/prod/en/doc/MAC_Spec_white_paper_1_0_080721.pdf} 17_{This protocol is proprietary, therefore no information is available. It uses proprietary data formats} 18_{Open PLC European Research Alliance}

19_{http://www.ist-opera.org/opera1/downloads/D18/OP_WP2_Deliverable_D18_v1.01.pdf}

20_{The ZigBee protocol stack includes lower layers consistent with IEEE 802.15.4 radio specifications. It} supports a variety of upper application layers – the typical AMI solution is the ZigBee Smart Energy profile.

(28)

Data Exchange Protocols

Dependent on the protocol used when the data is transmitted the data is protected by additional verification and checks to ensure that the data is correct. Transmitted data can also include a pause after the data packet to avoid collision with other transmitted data in order to guarantee the delivery of the message and command. An example of a typical communication session would consist of the following data transmissions, identification, negotiation (reconfigure the communication channel30 for communication parameters differing from the default values), log-on, security, read, write, and terminate. In order to clarify how the data overheads are created, the example of a typical communication process taken from EPRI (Electric Power Research Institute) and based on TCP/IP mode of operation is shown in Table 5 below.

This example assumes that the requested data is sent within various packets, with each packet usually taking between 50 and 66 bytes. The size of the data will depend on the data that was requested. In the example below, the descriptor <ACK> acknowledges the receipt of the package bit and valid CRC3231 is used to detect errors in the message.

The assumptions on data traffic message size vary considerably. For instance, in Flanders32_{advanced metering data size requirement assessment (“An evaluation of}

21_{http://www.mayor.de/lian98/doc.en/html/u_iec62056.htm}

22_{AMI supported when used in Mode E with DLMS/COSEM and remote two-way communication.} 23_{DLMS/COSEM has been selected as a basis of the Dutch and the French projects}

24_{Open Metering System Specification (OMS)}

https://www.zvei.org/fileadmin/user_upload/Fachverbaende/Energietechnik/Brancheninformationen/OM S/OMS-Spec_Vol2_Primary_v200.pdf

25_{SML (Smart Message Language) – is applied by RWE, E.ON, EnBW, Vattenfall, also by Landis&Gyr,} Hager, etc.

26_{Open Metering System Specification (OMS)}

https://www.zvei.org/fileadmin/user_upload/Fachverbaende/Energietechnik/Brancheninformationen/OM S/OMS-Spec_Vol2_Primary_v200.pdf

27

http://www.jennic.com/files/support_files/JN-AN-1035%20Calculating%20802-15-4%20Data%20Rates-1v0.pdf

28_{Open PLC European Research Alliance}

29_{http://www.ist-opera.org/opera1/downloads/D18/OP_WP2_Deliverable_D18_v1.01.pdf}

30_{http://intelligrid.epri.com/Smart_Grid_Information_Sharing_Calls/2009/AMI_HAN_Mtg._Materials_6.16}

.09/NIST_Vendor_Webinar_2.pdf

31_{Toggle bit is used to reject duplicate packets thus retransmitted packets keep the same state as the original packet} sent. CRC stands for Cyclical Redundancy Checking and is used to verify the integrity of a data communication. A CRC character is generated at the end of transmission.

32_{Flanders is the northern region of Belgium and represents 60% of its population with population} density reaching 440 inhabitants/km2

Protocols: Estimated Protocol

frame size (bytes) Remote AMR AMI

IEC 62056‐21”FLAG” 22 bytes21 Y Y22

IEC 62056 DLMS/COSEM23 14 bytes24 Y Y

SML25 14 bytes26 Y Y

Zigbee SmartEnergy 25 bytes27 Y

(29)

two-way communication means for advanced metering in Flanders (Belgium)”), which provided an analysis of advanced meter requirements, although it was recognised that typical data size is 32 bytes, the data size requirements per transaction type per meter was required to be a minimum of 512 bytes for commands, parameter adjustments and alarms, and 1024 bytes for meter registers (periodically and on demand).33_{Some recent articles speculate that 14 byte data} reads are more likely to be in the range of 4k to 16k bytes per reading.34

Table 5 – TCP/IP based message transaction overheads

The data throughput differs significantly depending on the protocol and communication used.

2.3.3 Data size calculation assumptions based on TCP/IP protocol

With data being actually transmitted the characteristics of protocols used through end-to-end communication will need to be used to carry out data traffic analysis. As was stated above, the overhead per packet of data sent through the TCP/IP protocol amounts to up to 50 bytes. Therefore each raw data transaction will contain an additional 50 bytes. Additionally, the message negotiation and verification needs to be taken into account which adds further packet transactions. As was previously mentioned TCP/IP data transmission can easily add around 10 further transactions. Therefore it will be assumed that each data transmission will add a further 500 bytes.

33_{http://www.vreg.be/vreg/documenten/rapporten/RAPP-2007-8.pdf}

34

High-level Smart Meter Data Traffic Analysis