ena-cr008-001-1 4 data traffic analysis · activities in support of network planning and also, to...

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

Engage Consulting Limited of 62 T 0207 4050740 W www.engage-consulting.co.uk E [email protected]

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



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.



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



Related Documents

Reference 1 Smart Metering Updated Requirements (ENACR006-002-1.1)

Reference 2 Smart Metering Use Cases (ENA-CR007-001-1.1)

Reference 3 Smart Metering Data Traffic Analysis Workbook (ENA-CR008-001-1.4.xls)

Reference 4 Smart Metering Security Assessment (ENA-CR009-002-1.0)

Distribution

Recipient 1: Alan Claxton

Recipient 2: ENA Members



Table of Contents

Document Control....................................................................................................................2 Authorities................................................................................................................................. 2 Related Documents .................................................................................................................... 3 Distribution ............................................................................................................................... 3

Table of Contents ....................................................................................................................4 Executive Summary.................................................................................................................5 1 Introduction ............................................................................................................... 14

1.2 Background .................................................................................................................. 14 1.3 Purpose........................................................................................................................ 14 1.4 Scope .......................................................................................................................... 15 1.5 Copyright and Disclaimer................................................................................................ 15

2 Data Traffic Analysis approach................................................................................... 16 2.1 Annual Data Traffic Level v Potential Peak values.............................................................. 16 2.2 Use Case Scenarios - Assumptions .................................................................................. 16 2.3 Data Size Assumptions Used........................................................................................... 24

3 Data Traffic Analysis................................................................................................... 31 4 Summary of the Data Traffic Analysis ........................................................................ 33

4.1 Summary of Data Traffic Analysis Approach ..................................................................... 33 4.2 Annual Data Traffic per meter assessment ....................................................................... 33 4.3 Assessment of some potential ‘Peak’ Data Traffic Scenarios ............................................... 36

5 Conclusions ................................................................................................................ 45 Appendix 1 – Electricity & Gas Use Case Data Traffic Analysis – Detail............................... 54



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 TB2

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 = 106 bytes 2 1 Terabyte = 1012 bytes



• Cumulative per activity data volume in bytes;

• Cumulative data volume per activity per year.



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

ENA Latency req. (command 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



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)



RTP Readings 12 hours

1,194 4,776







(bytes)


(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)


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)


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

1,791 1,791







(bytes)


(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


meter

1,194 1,194

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


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


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)

3 months (Reporting period)

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


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


every 6 months)

6 months 15 min. 1,194 2,388







(bytes)


(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


every 6 months)


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 Assumed 15

minutes up to 12 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)


Basic Flow Total (Everything works as required)

332,980 1,288,818



GAS USE CASES Data granularity registered at the meter




(bytes)


(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 confirmation

almost real time 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


361,170 803,847



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



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.

3 Kbps = Kilo bits per second = 1,000 bits per second



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



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.



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.



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.

Table 1 – Summary of Electricity Scenarios used for data traffic analysis per each Use Case







voltage data)

Alternative flow: 1. The DNO does not receive the data

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



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)


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



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

As for UC 09







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 )

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 Data transmission

granularity to Central Data

Repository/DNO


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.


Within 15 min.

11_Check effectiveness of network management / system balancing measures

3. The Smart Metering System sends the requested data (assumed last real import/export and voltage data read)

As above

As above (1 month of ½ hour

As above



Use Cases Possible data exchange scenarios:


Estimated ENA Data transmission

granularity to Central Data

Repository/DNO


data)

Alternative flow: 1. Meter fails to send the message



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)


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

Alternative Flow: 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 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

Alternative flow: 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

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).



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







Alternative flow: 1. Smart Metering System is unable to send the outage alarm message 2. DNOs do not receive notification

As above As above

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)


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

Alternative Flow: 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)


12 hours

2. Meter sends outage report As above As above As Above

16 Regulatory Reporting on outages

Alternative Flow: 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


12 hours

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



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

Alternative Flow: 1. DNOs do not receive power restored message 2. Smart Metering System deems the request invalid 3. DNOs do not receive the confirmation response



12 hours



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

Alternative Flow: 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



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)

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

Alternative Flow: 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


1. DNO configures meter reading registers (this is confirmed by the metering system)

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)




Data granularity at meter (registered at the meter)

Data transmission granularity to Central Data Repository/DNOs


Alternative Flow: 1. Smart Metering System deems the request invalid 2. DNOs do not receive notification

On occurrence As above

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

Alternative Flow: 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)



Confirmation almost real time

Use Case 02 – Configure Smart Metering System

Alternative flow: 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

Alternative Flow: 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


Use Case 04 Display Messages from Gas Distribution Network

Alternative Flow: 1. Meter fails to send confirmation message

As above

On occurrence

12 hours







In cases where meter does not measure CV at the meter: 1. GDN’s send Calorific Value to the meter

Every day

Daily


2. Meter confirms the data has been updated successfully to GDNs and suppliers

Every day

Daily


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

Alternative Flow: 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.



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 25

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 25 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

1 Report type



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



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 Broadband6

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.



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/OMS/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/OMS/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 30http://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 OPERA/UPA28 24 bytes29 Y Y



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 http://www.smartgridnews.com/artman/publish/Technologies_Security_News/That-Smart-Grid-Data-Surge-We-Mentioned-Earlier-You-Can-t-Ignore-It-1351.html



2.3.4 Security

In this data traffic analysis a basic level of security is assumed, namely when a command is sent to a meter (whether it is a data request, a schedule of reads or a configuration) each command and request is verified by the meter. The security checks are assumed to be 22 bytes per packet of data sent, which includes DES (Data Encryption Standard) and AES (Advanced Encryption Standard) for the detection and prevention of unauthenticated access and modification35.

Please note that in the future it could be possible that smart metering activities could also include such high security operations as RSA (Rivest Shamir Adleman chipper) which could add over 300 bytes per data packet, however due to large data overheads they are currently not too popular.

The analysis below also includes request verification, which is the authentication and check for errors in the request. Such verification is assumed to add 4 bytes to each request transmission going to the meter. Engage has prepared a report on security issues related to smart metering deployment (Reference 4), which further highlights the main threats and security measures that would need to be considered when rolling out smart meters.

35 http://www.rempli.org/download.php?Doc=29&PHPSESSID=859e10189e665ece80f54e096ff08764



3 Data Traffic Analysis An Excel Workbook (Reference 3 – ENA-CR008-001-1.3) was created to underpin the analysis, which is provided as a companion to this report. Summary output from this spreadsheet is provided in Section 4 below.

The spreadsheet allows the assumptions of the overheads per packet and the network to be modified (the cells that can be modified are shown in red in Reference 3) in order to see the immediate results in the data traffic flow. It also allows adjustments of the data sizes and the granularity of data transmissions, thus meeting other additional needs that the network operators might need to incur. Reference 3 contains several Worksheets, namely:

- The first Worksheet “DataSizeAssumptions” contains the assumptions of the electricity and gas data size in bytes, overhead size per packet and overhead per message transmission. The assumptions can be modified for different smart metering system solutions.

- The second Worksheet “EleTransferFrequencyAssumptions” contains the assumptions of electricity data registration occurrence at the meter, and how long it will be stored before transmission. This helps to understand how large the volume of data is that will be transmitted and how often. The last column contains an element to calculate the data volumes per year. The assumptions can be modified for different smart metering system solutions.

- The third Worksheet “Gas_TransferFreqAssumptions” contains the same as the above spreadsheet for gas. The assumptions can be modified for different smart metering system solutions.

- The fourth Worksheet “Electricity_DataTraffic” represents electricity related data flow volumes based on the assumptions in the previous Worksheet. The last 2 columns give the provision made for the data traffic during the year.

- The fifth Worksheet “Gas_DataTraffic” represents gas related data flow volumes based on the assumptions in the above mentioned spreadsheet tabs.

- The sixth Worksheet “Ele_DataTrafficSpeed” provides an overview of the electricity data speed requirements giving values in bits per second needed to receive a response, or data with varying latency levels assumed of 5 seconds, 30 seconds, 3 minutes , 5 minutes, 15 minutes, 1 hour and 12 hours.. These cells can be modified to identify the change in speed resulting from these changes.

- The seventh Worksheet “Gas_DataTrafficSpeed” gives an overview of gas data speed requirements similar to the electricity data.

The last two Worksheets have been provided to allow a user to derive a view of the potential impact of specific data traffic instances being triggered for a number of meters. This is viewed as a way to highlight a potential ‘peak’ data traffic estimate for some transactions that may become time critical, especially when it is necessary to undertake an active management of the network.

- The eighth Worksheet “Ele_DataSpeedMultpMeterers” provides an overview of the electricity data speed requirements for a specified number of meters in bits



per second needed to receive a response or data with various latency levels assumed of 5 seconds, 30 seconds, 3 minutes, 5 minutes, 15 minutes, 1 hour and 12 hours. A single figure for the number of meters can be entered and applied to all data traffic for each Use case, or alternatively, each individual data flow can be updated to reflect views regarding the number of meters that could be involved in that specific data flow requirement. The areas that can be changed are highlighted in red.

- The ninth Worksheet “Gas_DataSpeedMultpMeterers” provides an overview of the gas data speed requirements for a specified number of meters in bits per second needed to receive a response or data with various latency levels assumed of 5 seconds, 15 minutes or 1 hour. A single figure for the number of meters can be entered and applied to all data traffic for each Use Case, or alternatively, each individual data flow can be updated to reflect views regarding the number of meters that could be involved in that specific data flow requirement. The areas that can be changed are highlighted in red.

Further details from the full analysis can be found in Section 4 and the detail is contained in Reference 3 – ENA-CR008-001-1.3 Data Traffic Workbook.

High-level Smart Meter Data Traffic Analysis – Client Confidential


4 Summary of the Data Traffic Analysis

4.1 Summary of Data Traffic Analysis Approach

The analysis assessed the ENA requirements for smart metering system related data to support smart grid activities. The requirements included:

- Two way communication;

- Remote disabling and enabling of supply;

- Power quality reads;

- Half Hourly Import and export data reads or 6 min. interval reads for gas;

- Half Hourly Active and Reactive power reads;

- Micro-Generation data reads;

- Data on request;

- Alarm configuration;

- Change of tariffs;

- Load management controls and feedback;

- Customer notifications of power/gas outages or other activities; and

- Management of outages.

The data traffic discussed in Section 4.2 is provided on a per meter basis in order to identify the data size requirements that each meter would need to handle as a minimum.

The analysis also provides an overview of data traffic in cases of alternative flows when the smart metering system fails, assuming that it would be corrected after one attempt.

To provide a complete picture for data traffic it is necessary to provide an insight into the potential ‘peak’ data traffic that might occur due to specific aspects of key Use Cases, that may require messages being sent to a number of meters, or data received from a number of meters. If the meters in question are geographically spread across the country, it is likely they will not provide added strain on the associated communications infrastructure. However, when events are localised and this data needs to be sent to or obtained from a concentrated area, it is possible that this might create added pressure on the associated aspect of the localised communication infrastructure. Section 4.3 will provide some insight into this.

4.2 Annual Data Traffic per meter assessment

Using the assumptions detailed above, the Data Traffic Analysis showed that as a minimum, the metering system should be capable of dealing with the following levels of data per annum:

• ELECTRICITY: 1.2 – 1.3 MBytes per meter per annum;

• GAS: c. 0.8 MBytes per meter per annum.



Based on the ENA requirement for electricity smart meters to store data in the meter for 3 months (as per ERA stated requirements) and then transmit it to the central data repository, this would result in a transmission of over 18 kbytes every 3 months of half-hourly data for each data item such as voltage, or electricity consumption etc. This amounts to c. 140-145 kbytes to transfer 3 month’s worth of electricity related half hour data. For gas, where GDN’s required up to 6 minute interval data collection, the data can reach over c.170-175 kbytes for transmission solely of interval data (6 months of data).

Within the assumed periods (3 months for electricity and 6 months for gas) the likely data transfer will be of the order of:

Meter Type All Operations work as expected (Use Case Basic Flow)

All Operations encounter each problem highlighted in Use Case Basic + Alternative Flows

ELECTRICITY c.325 kbytes c.410 kbytes GAS c.355 kbytes c.375 kbytes

Appendix 1 provides a detailed breakdown of the required bytes of data and the associated speed to provide a response within 5 seconds, 30 seconds, 3 minutes, 5 minutes, 15 minutes, 1 hour and 12 hours for electricity and 5 seconds, 15 minutes and 1 hour for gas. Table 6 provides an extract from Appendix 1 for Use Case 1 for both electricity and gas.



Table 6 – Extract for Electricity and Gas Use Cases 1 from Appendix 1.

Speed on cumulative volumes depending on response time required (bps) Electricity Use Cases Bytes Response time

required: 5sec Response time

required: 30 sec Response time required: 3min

Response time required: 5min


Response time required: 1 hour

Response time required: 12 hours

Assessment of network performance Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom 1. Data is periodically sent from the Smart Metering System (All Data)

145888

233421 38903 6,484 3890 1297 324 27

2. DNO requests data Included in step 3 below 3. The Smart Metering System sends the requested data

41489 66382 11064 1,844 1106 369 92 8

Alternative Flow: 1. Smart Metering System rejects the message as invalid

1187 1899 317 53 32 11 3 0

2. The Smart Metering System does not have any measured data stored

4300 6880 1147 191 115 38 10 1

3.1 The DNO does not receive the data from the Smart Metering System (scenario 1)

3103 4965 827 138 83 28 7 1

3.2 The DNO does not receive the data from the Smart Metering System (scenario 2)

3103 4965 827 138 83 28 7 1

Gas Use Cases Speed on cumulative volumes depending on

response time required (bps)

Bytes Response time required: 5sec (min)



Use Case 1 - Gather information for planning 1. The Smart Metering System sends the recorded gas demand data to the GDNO (6min)

Included in Step 2 below

2. The Smart Metering System sends the recorded gas demand data to the GDNO (daily)

352846 564554 3136 784

Alternative Flow: 1. Meter does not communicate requested data to the authorised GDN party 3103 4965 28 7 2. Meter data reads are missing / corrupted 4300 6880 38 10



4.3 Assessment of some potential ‘Peak’ Data Traffic Scenarios

The previous section has highlighted the data traffic associated with one meter per annum. The discussion that follows will select some data traffic outcomes resulting from some of the key Use Cases (Reference 2) and provide an insight into the required data transfer speed needed under a number of latency assumptions for a varying number of meters.

Some examples of situations where data traffic could be at a peak are as follows:

• Under storm conditions the power outage data traffic (via alarms or checking energisation status) could be relatively heavy, but only for those parts of the country experiencing storm conditions and only on predominantly Overhead Line networks. Depending on the communication technology deployed this could lead to high volumes of data traffic on local communication infrastructure. Major disruptions will be identified by SCADA systems and the purpose of the use of the alarm notification and/or energisation checks will be to ensure that all supplies are restored appropriately;

• For Demand Side Management (DSM) when third parties will be able to control specific household equipment. This will be extremely important with the growth of new technology such as Electric Vehicles (EVs), heat pumps etc. It is assumed that these households will have undertaken contractual agreement with these third parties, allowing them to control certain equipment within pre-agreed limits. Problem parts of the network will be known to network businesses through the capture of planning data and it will be necessary to instigate swift action once problems are identified on that part of the network; and

• There might be a need to capture the latest half-hourly data from a number of metering systems to undertake an assessment of how problems may have been adversely impacted by recent changes. This may not require ‘second’ based response, but it may need a response within minutes with linked assessment tools leading to action needing to be taken quickly to avoid major problems. This is likely to be necessary when the network operators need to actively manage the network.

4.3.1 Assessment of some potential ‘Peak’ Data Traffic Scenarios

Some of these potentially ‘Peak’ activities will occur immediately the smart meters have been rolled out in specific areas, whereas others may be as a consequence of the growth of new technologies such as EVs, heat pumps etc., which will require electricity network businesses to actively monitor their networks and respond to problems in fairly short timescales.

4.3.1.1 Electricity Use Case 14 – Outage Alarm Sent

(Similar data traffic volume is associated with Use Case 15 - Verify Restoration of Supplies after Outage)

Use Case 14 reflects the process of a smart metering system sending an outage alarm to the Distribution Network Operator when an Outage has been detected. Outages can impact a large number of meters depending on the cause of the



outage and Figure 1 below indicates the required communication speed necessary to deliver an alarm from a varying number of meters. As stated earlier, the larger the outage the more likely the DNO’s SCADA systems will have detected the extent of the problem. The challenge for the DNO will be to capture this alarm related information and use it to ensure that supplies have been restored to all customers.

Figure 1 – Outage Alarm - Require Communication speed per packet for varying numbers of meters and assumed latency (response times)

0

2,000

4,000

6,000

8,000

10,000

12,000

5 secs

30 secs

3 mins

5 mins

15 mins

1 hour

12 hours

Latency periods

kbps

200 meters400 meters600 meters800 meters1000 meters5000 meters10000 meters

Speed per packet depending on response time required

No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours

kbps kbps kbps kbps kbps kbps kbps

200 191 32 5 3 1 0 0 400 382 64 11 6 2 1 0 600 573 96 16 10 3 1 0 800 764 127 21 13 4 1 0 1000 955 159 27 16 5 1 0 5000 4,776 796 133 80 27 7 1

10000 9,552 1,592 265 159 53 13 1

If we assume that the incident is fairly localised then all of these alarm signals will create data traffic on specific nodes of the communication infrastructure. Based on the data above, if the DNO requires a response from 1,000 meters within a 3 minute period, then this implies that this part of the communication infrastructure needs to deliver data at c. 27,000 bits per second (27kbps). However as the number of meters involved increases (if they were still part of the same nodes of the communication infrastructure), then this would increase the



required speed as shown above to c. 133kbps for 5,000 meters and c. 265kbps for 10,000 meters.

As the required response time (latency) for these activities reduces, then the required speed increases very quickly from 27kbps for 3 minute latency for 1,000 meters to almost 1 Mbps for a 5 second response.

4.3.1.2 Electricity Use Case 01 – Request latest month’s data for all relevant electricity parameters

Similar data traffic volume is associated with

• Use Case 02 – Determine network impact of proposed new demand / generation connections;

• Use Case 03 – Determine network impact of proposed increases in demand / generation at existing connection points;

• Use Case 04 – Monitor demand and generation profiles for network load forecasting – same data, but may be for up to 3 months, rather than 1 month;

• Use Case 05 – Determine Latent Demand due to Embedded Generation – same data, but may be for up to 3 months, rather than 1 month;

• Use Case 07 – Collect data for active network management – same data, but latency will need to be shorter; and

• Use Case 11 - Check effectiveness of active network management / system balancing measures.

This example spans both the System Planning aspects of DNOs operation (UC 01 – 05) and the active management of the network when the uptake of new technologies such as EVs and heat pumps etc. is much more prevalent and the DNO needs to manage the network much more actively and respond within much tighter timescales.

Figure 2 (shown on the next page) illustrates the required communication speeds in kbps that would be needed for varying levels of latency (response times).



Figure 2 – Request last month’s data for all relevant electricity parameters - Require Communication speed per packet for varying numbers of meters and assumed latency (response times)

010,00020,00030,00040,00050,00060,00070,000

5 secs

30 secs

3 mins

5 mins

15 mins

1 hour

12 hours

Latency periods

kbps

200 meters400 meters600 meters800 meters1000 meters


No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours


200 13,276 2,213 369 221 74 18 2 400 26,553 4,425 738 443 148 37 3 600 39,829 6,638 1,106 664 221 55 5 800 53,106 8,851 1,475 885 295 74 6

1000 66,382 11,064 1,844 1,106 369 92 8

Clearly as such response times needed dropped to say 15 minutes, the required speed that the communication system would need to support escalates as the table above demonstrates.

Rather than access all data held in a smart metering system, it may be only one parameter that is of interest e.g. voltage. Figure 3 (shown on the next page) represent the required communication speeds to support retrieval of just voltage data for each half-hour for the last month from a varying number of meters. For a response within 5 – 15 minutes for 600 – 1,000 meters indicates a speed required of 100 – 500 kbps.



Figure 3 – Request last month’s data for a single electricity parameter e.g. voltage - Require Communication speed per packet for varying numbers of meters and assumed latency (response times)

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

5 secs

30 secs

3 mins

5 mins

15 mins

1 hour

12 hours

Latency periods

kbps



No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours


200 6,027 1,004 167 100 33 8 1 400 12,053 2,009 335 201 67 17 1 600 18,080 3,013 502 301 100 25 2 800 24,106 4,018 670 402 134 33 3

1000 30,133 5,022 837 502 167 42 3

4.3.1.3 Electricity Use Case 09 (Scenario 4) – Direct Control of Household Appliances

Similar data traffic volume is associated with

• Use Case 08 (Scenario 4) – Perform Active Management of Network Power Flow;

• Use Case 10 (Scenario 4) – Perform System Balancing;

• Use Case 13 – Query meter energisation status to determine outage source and location.



Figure 4 – Exert direct control over a number of household appliances - Require Communication speed per packet for varying numbers of meters and assumed latency (response times)

0

5,000

10,000

15,000

20,000

25,000

5 secs

30 secs

3 mins

5 mins

15 mins

1 hour

12 hours

Latency periods

kbps



No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours


200 382 64 11 6 2 1 0 400 764 127 21 13 4 1 0 600 1,146 191 32 19 6 2 0 800 1,528 255 42 25 8 2 0 1000 1,910 318 53 32 11 3 0 5000 9,552 1,592 265 159 53 13 1

10000 19,104 3,184 531 318 106 27 2

This demand side management (DSM) tool will become more necessary as new technology is deployed. Again the impact on the local communication infrastructure will be dictated by the number of meters that would respond using the same communication infrastructure. If we look at seeking a DMS response from 1,000 meters in a specific localised part of network that uses the same communication infrastructure node, it can be seen that as the response time needed reduces from 15 minutes to something of the order of 30 seconds, then the speed needed to support this activity would need to increase from 11kbps to 318 kbps. Clearly this type of consideration needs to be a key part of any communication infrastructure design.

4.3.1.4 Electricity Use Case 17 – Restore and maintain supply during outages

This Use Case reflects the overall process of



a. Power is restored to the Smart Metering System

b. The Smart Metering System sends a date and time stamped power restored message to the Distribution Network Operator

c. The Distribution Network Operator receives the message and sends a message to the Smart Metering System activating the maximum power consumption threshold

d. The Smart Metering System receives the message and validates it

e. The Smart Metering System activates the maximum power consumption threshold and sends a confirmation response to the Distribution Network Operator

Figure 5 summarises the outcome of the evaluation of this Use Case.

Figure 5 – Activate Maximum Power Consumption levels - Require Communication speed per packet for varying numbers of meters and assumed latency (response times)

0

5,000

10,000

15,000

20,000

25,000

30,000

35,000

5 secs

30 secs

3 mins

5 mins

15 mins

1 hour

12 hours

Latency periods

kbps



No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours


200 573 96 16 10 3 1 0 400 1,146 191 32 19 6 2 0 600 1,719 287 48 29 10 2 0 800 2,292 382 64 38 13 3 0 1000 2,866 478 80 48 16 4 0 5000 14,328 2,388 398 239 80 20 2

10000 28,656 4,776 796 478 159 40 3



It has been suggested that this Use Case should be completed within 5 minutes. Again, the impact on the local communication infrastructure will depend on how many meters are linked to specific local nodes of the communication infrastructure. For this level of response for 1,000 meters the communication infrastructure needs to support a speed of 48 kbps. This increases to approaching 0.5 Mbps if this covers 10,000 meters.

4.3.1.5 Gas Use Case 03 – Disable Supply of Gas

This Use Case is based on the assumption that the gas smart meter incorporates a valve within the final meter functional specification. A use could be made of the gas valve by a Gas Distribution Network to prevent gas being offtaken from the network in the following circumstances;

• Temporary isolation - following public reported emergency, such as a smell of gas in the premises or suspected Carbon Monoxide (CO) report by consumer.

• Temporary isolation by GDN for poor pressure - Where the GDN has identified effected premises and wishes to reduce risk to consumers by temporarily isolating the supplies.

• Temporary isolation to reduce demand following damage to distribution mains or temporary reduction in gas availability - Possible prevention measure where consumers (whether a percentage or all for a particular Gas Supply Emergency) are isolated to ensure the overall pressure is maintained in the mains and services.

• Temporary isolation for Water Ingress - Isolate to protect consumers from poor pressure and some protection to consumer’s appliances from water ingress.

These scenarios potentially provide, once identified, an almost immediate response to a potential issue and allow the GDN to take some action prior to the visit by a competent person to site under the normal attendance policies and safety case requirements.

There are likely to be a limited number of incidents each year where this provides benefit. Robust procedures would be required to ensure that these processes operate safely.

Figure 6 illustrates required speeds necessary to issue these commands for a varying number of meters with the three specified response times of 5 seconds, 15 minutes and 1 hour.

In the assumptions from ENA members it was stated that this action would need to be completed by the end of an hour. This indicates a very low speed of 3 kbps or less. As Figure 6 illustrates, this Use Case would only pose a problem for any local communication infrastructure if the response time was to be in the seconds, which current thinking believes that it will not require such immediate response time for this action.



Figure 6 – Send relevant request to disable gas supply to a number of meters

01,0002,0003,0004,0005,0006,0007,0008,0009,000

5 secs

15 mins

1 hour

Latency periods

kbps



No. of Meters

Response time required: 5 sec



kbps kbps kbps

200 382 2 1 400 7,642 4 1 600 1,146 6 2 800 1,528 8 2

1000 1,910 11 3



5 Conclusions 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 MB 30 – 40 TB36

Gas Less Than 1 MB 15 – 20 TB

TOTAL - 45 – 60 TB

Table 7 below summarises for a single electricity or gas meter the following Networks assumptions for each relevant Use Case step and data volume outcomes for each activity and per year:

• Data granularity registered at the meter - time;

• Data Transmission granularity – How often data is transferred;

• Latency required – transfer time for data;

• Cumulative per activity data in bytes; and

• Cumulative data volume per year.

36 1 Megabyte = 106 , 1 Terabyte = 1012 bytes



Table 7 – Details of Electricity & Gas assumptions and Use Case data requirements – per meter





(bytes)


(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



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



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)



TOU Readings 12 hours

2,006 8,024

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



RTP Readings 12 hours

1,194 4,776







(bytes)


(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)


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


HH Average

2. DNO requests data 3. Smart System sends data

on occurrence (assumed to happen once every 3

months)


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)


per year)

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

1,791 1,791







(bytes)


(bytes) extreme weather


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


meter

1,194 1,194



per year)

once a year For customers associated with LV faults (1,000 max) 5 mins, where as


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


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)


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


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


every 6 months)

6 months 15 min. 1,194 2,388







(bytes)


(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


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


every 6 months)


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 Assumed 15

minutes up to 12 hours (i.e.

confirming meter changes)

1,194 1,194

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


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



332,980 1,288,818



GAS USE CASES Data granularity registered at the meter




(bytes)


(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 confirmation

almost real time 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


361,170 803,847



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 insight into these ‘peak’ activities Section 4.3 of the report considered a number of Use Case examples for a varying number of meters and different potential latency periods. The example below is based on Section 4.3.1.2 (Use Case 01 – Request latest month’s data for all relevant electricity parameters). This data capture process initially supports the assessment of the network’s performance (planning activities), 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 technology such as EVs and heat pumps etc.

Table 8 highlights this Use Case example and clearly illustrates the required speed that localised communication infrastructure may need to support at ‘peak’ periods, for varying number of meters and different levels of latency:

Table 8 – Example of Speed per data packet needed for varying numbers of meters and different latencies.


No. of Meters

Response time

required: 5 sec

Response time

required: 30 sec

Response time

required: 3min

Response time

required: 5min

Response time

required: 15min

Response time

required: 1 hour

Response time

required: 12 hours

kbps kbps kbps Kbps kbps Kbps kbps

200 13,276 2,213 553 221 74 18 2 400 26,553 4,425 1,106 443 148 37 3 600 39,829 6,638 1,660 664 221 55 5 800 53,106 8,851 2,213 885 295 74 6

1000 66,382 11,064 2,766 1,106 369 92 8

This example does not assume any scheduling or grouping of meters to control the response, but simply assumes that the data from the specified number of meters for this activity needs to be delivered in the specified latency times across the local communication infrastructure.

If the network operator needed to acquire data from 600 - 1,000 meters from a localised part of their network for planning purpose and this only needed a response within 12 hours, then the local communication infrastructure covering these meters only needs to support a speed of 5 – 8 kbps. However, once new types of demand have been connected to the network and there is a need for the DNOs to proactively manage their network, the DNO will need to capture data in a much shorter time frame to facilitate speedy responses. In Table 8 above, if this meant the response time would need to be 15 minutes rather than 12 hours, then the local communication infrastructure would need to deal with data traffic in to 0.2 – 0.4 Mbps range (Million bits per second) shown in yellow in Table 8. 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.



Appendix 1 – Electricity & Gas Use Case Data Traffic Analysis – Detail Cells highlighted in yellow reflect the typical response times for one meter for the cases shown in Section 4.3.

Speed on cumulative volumes depending on response time required (bps)

Electricity Use Cases Bytes Response time required:

5secs

Response time required: 30secs

Response time required:

3min


5min


15min



Assessment of network performance Use Case 01 - Monitor current flows and voltage levels to identify thermal capacity and statutory voltage headroom 1. Data is periodically sent from the Smart Metering System (All Data)

145,888

233,421 38,903 6,484 3,890 1,297 324 27


41,489 66,382 11,064 1,844 1,106 369 92 8

Alternative Flow: 1. Smart Metering System rejects the message as invalid

1,187 1,899 317 53 32 11 3 0

2. The Smart Metering System does not have any measured data stored

4,300 6,880 1,147 191 115 38 10 1

3.1 The DNO does not receive the data from the Smart Metering System

3,103 4,965 827 138 83 28 7 1

3.2 The DNO does not receive the data from the Smart Metering System

3,103 4,965 827 138 83 28 7 1

Use Case 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)

Included in step 2 below

2. Smart Metering System retrieves the requested data

41,489 66,382 11,064 1,844 1,106 369 92 8

Alternative Flow:





5secs



3min


5min


15min



1. The DNO does not receive the data

3,103 4,965 827 138 83 28 7 1

Use Case 03 - Determine network impact of proposed increase in demand / generation at existing connection points 1. DNO requests stored HH power flow and voltage data (and micro-generation data where available)

Included in step 2 below

2. Smart Metering System retrieves the requested data

41,489 66,382 11,064 1,844 1,106 369 92 8

Alternative Flow: 1. The DNO does not receive the data

3,103 4,965 827 138 83 28 7 1

Use Case 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 scenario 1 and alternate flow 4)

Use Case 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 scenario 1 and alternate flow 4)

Use Case 06 - Identify Voltage Quality Issues 1. The Smart Metering System accumulates time and data stamped voltage quality events (assumed 6 events)

656 1,050 175 29 17 6 1 0


3,103 4,965 827 138 83 28 7 1

Actively manage network / System Balancing





5secs



3min


5min


15min



Use Case 07 - Collect data for active management 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 Scenario 1


3,103 4,965 827 138 83 28 7 1

08 Use Case - Active network management of network voltage The same data flow as in Use Case 09

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

2,006 3,210 535 89 53 18 4 0

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

1,194 1,910 318 53 32 11 3 0

3. Power Sharing by Maximum Thresholds

0 0 0 0 0 0 0 0

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

1,194 1,910 318 53 32 11 3 0

Alternative Flow: 1. Maximum Power Threshold Reached - consumer does not turn off appliances

0 0 0 0 0 0 0 0

2. Power Sharing by Maximum Power Thresholds - consumer turns off some of the appliances

0 0 0 0 0 0 0 0





5secs



3min


5min


15min



System Balancing 10 Use Case - Perform System Balancing The same data flow as in Use Case 09


0 0 0 0 0 0 0 0


41,489 66,382 11,064 1,844 1,106 369 92 8


3,103 4,965 827 138 83 28 7 1

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

1,791 2,866 478 80 48 16 4 0

Alternative Flow: 1. Smart Metering System deems the request invalid for scenario 1

1,187 1,899 317 53 32 11 3 0

2. DNOs do not receive acknowledgment message for scenario 1

3,103 4,965 827 138 83 28 7 1

3. Smart Metering System deems the request invalid for scenario 2

1,187 1,899 317 53 32 11 3 0

4. DNOs do not receive acknowledgment message for

3,103 4,965 827 138 83 28 7 1





5secs



3min


5min


15min



scenario 2 Use Case 13 - Query Meter Energisation Status to determine Outage Source and Location 1. False Outage Report (DNO checks meter energisation status: supply on)

1,791 2,866 478 80 48 16 4 0

2. Confirmed network outage 1,194 1,910 318 53 32 11 3 0 Alternative Flow: 1. Smart Metering deems the request invalid (for scenario 1)

1,187 1,899 317 53 32 11 3 0

2. DNO does not receive the message (scenario 1)

3,103 4,965 827 138 83 28 7 1


597 955 159 27 16 5 1 0

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

3,103 4,965 827 138 83 28 7 1

2. DNO does not receive notification

3,103 4,965 827 138 83 28 7 1

Use Case 15 - Verify restoration of supplies after outage 1. Meter notifies DNOs of power restoration

597 955 159 27 16 5 1 0

Alternative Flow: 1. Smart Metering System fails to detect power restoration

3,103 4,965 827 138 83 28 7 1


3,103 4965 827 138 83 28 7 1

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

2. Meter sends outage report 1,161 1,858 310 52 31 10 3 0 Alternative Flow:





5secs



3min


5min


15min



1. Smart Metering rejects the message as invalid

1,187 1,899 317 53 32 11 3 0

2. Smart Metering System does not have any of the requested information stored

4,300 6,880 1,147 191 115 38 10 1


3,103 4,965 827 138 83 28 7 1

Case 17 - Restore and maintain supply during outages 1. Smart Metering System sends "power restored" message to the DNO

597 955 159 27 16 5 1 0

2. DNO activates the maximum power consumption threshold

Included in Step 3 below.

3. Smart Metering confirms activation of the maximum power consumption threshold

1,194 1,910 318 53 32 11 3 0

Alternative Flow: 1. DNO does not receive "power restored" message

3,103 4,965 827 138 83 28 7 1

2. Smart Metering deems the request invalid

1,187 1,899 317 53 32 11 3 0

3. DNO does not receive the confirmation response

3,103 4,965 827 138 83 28 7 1

Manage safety issues Use Case 18 - Manage meter safety alarm 1. Smart Metering System sends alarm to DNOs


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


3. The Smart Metering sends the confirmation message to

1,791 2,866 478 80 48 16 4 0





5secs



3min


5min


15min



the DNO Alternative Flow: 1. DNO does not receive the alarm

3,103 4,965 827 138 83 28 7 1

2. Smart Metering deems the request invalid

1,187 1,899 317 53 32 11 3 0

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

3,103 4,965 827 138 83 28 7 1

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

1,791 2,866 478 80 48 16 4 0

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

3,103 4,965 827 138 83 28 7 1

2. The Smart Metering System fails to auto disconnect

3,103 4,965 827 138 83 28 7 1

Support network activities Use Case 20 - Configure Smart Metering System 1. DNO configures meter reading registers

1,194 1,910 318 53 32 11 3 0





5secs



3min


5min


15min



2. DNO configures meter alarms

1,194 1,910 318 53 32 11 3 0

3. DNO configures meter load threshold

1,194 1,910 318 53 32 11 3 0

Alternative Flow: 1. Smart Metering deems the request invalid

1,187 1,899 317 53 32 11 3 0

2. DNOs do not receive notification

3,103 4,965 827 138 83 28 7 1

Basic Flow Total 332,980 532,768 88,795 14,799 8,879 2,960 740 62 Basic + Alternative Flow Total

419,342 670,947 111,825 18,637 11,182 3,727 932 124



Speed on cumulative volumes depending on

response time required (bps) Gas Use Cases Bytes Response time

required: 5secs


15min


Use Case 1 - Gather information for planning 1. The Smart Metering System sends the recorded gas demand data to the GDNO (6min) Included in Step 2 below 2. The Smart Metering System sends the recorded gas demand data to the GDNO (daily) 352846 564554 3136 784 Alternative Flow: 1. Meter does not communicate requested data to the authorised GDN party 3103 4965 28 7 2. Meter data reads are missing / corrupted 4300 6880 38 10 Use Case 02 - Configure Smart Metering System 1. GDN configures meter reading registers 2388 3821 21 5 Alternative Flow: 1. Smart Metering deems the request invalid 1187 1899 11 3 2. GDNs do not receive confirmation 3103 4965 28 7 Use Case 03 - Disable Supply of Gas 1. Gas is disabled by GDNs 1791 2866 16 4 Alternative Flow: 1. GDNs do not receive confirmation 3103 4965 28 7 2. Smart Metering deems the request invalid 1187 1899 11 3 Use Case 04 - Display Messages from Gas Distribution Network 1. GDN sends notification to IHD 1194 1910 11 3 Alternative Flow: 1. Meter fails to send confirmation message 3103 4965 28 7 Use Case 05 - Measure and Store Calorific Values at the meter 1177 1883 10 3 (Optionally) GDN update the message 1177 1883 10 3 Alternative Flow: 1. The Smart Metering System rejects the message as invalid 2364 3782 21 5 Tampering Notification send to GDNs 597 955 5 1 Basic Flow Total 361,170 577,872 3,210 803 Basic + Alternative Flow Total 382,620 612,192 3,401 850