1
TSDSI-M2M-TR-UCD_Utilities-V0.1.0-20150306
2
3
Technical Report
4
5
6
7
8
Machine-to-Machine Communication (M2M)
9
Study on Indian Use Cases
10
Utilities Vertical
11
12
13
14
15
16
17
18
1
19
20
21
22
23
24
Intentionally left blank to fill information on:
a.
b.
c.
d.
e.
Secretariat address
Editor with address
Chair with address
Vice-Chair with address
Copyright information
25
2
26
27
28
29
30
31
Intentionally left blank to fill information on:
a.
b.
c.
d.
Standard number
Standard mnemonic
Version [for status information]
Draft date, if not published [for status information]
Publication date of the standard [for status information]
3
32
Intentionally left Blank for Abstract
4
Contents
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
1.
2.
3.
4.
5.
6.
Introduction
Purpose
Intended Audience
Scope
Definitions, Abbreviations, Acronyms
Use Cases for Utilities
6.1
Advanced Metering Infrastructure
6.2
Automated Meter Reading
6.3
AMI Network Management Systems
6.4
Distributed Transformer Monitoring
6.5
RMU and FPI connectivity
6.6
SCADA
6.7
Pre-payment Metering
6.8
City Gas Distribution
6.9
City Water Distribution
6.10
Electric Vehicles Charging
6.11
Microgrids
6.12
Distributed Generation
6.13
Wide Area Monitoring (WAMS)
Annexure – Advanced Metering Infrastructure (AMI)
Bibliography
Document Revision History
58
5
59
1 INTRODUCTION
60
61
62
63
64
65
Communication infrastructure is the foundation of Process Automation, Instrumentation and
Control industry, an industry that has been in existence for more than 50 years. Sensor/transducer
based Remote Monitoring systems, and PLC/SCADA systems with remote control capabilities
have always used dedicated communication wires or wireless (Radio/Satellite etc.) systems for
providing connectivity between the end devices in the field and the control centre. In fact,
several communication protocols were created in the Industrial Automation space.
66
67
68
69
70
71
On a different plane, the scorching pace of innovations in IT technologies has led to
“commoditization” of devices. These devices are intelligent, have small and flexible form factor
and, more importantly, can “talk”, by integrating standard communication chips/modules of any
communication technology, almost in a plug and play fashion. Therefore, the world is now
witnessing emergence of devices that can communicate with each other – thus elevating
automation and control engineering industry to a new level altogether – the M2M/IoT.
72
73
74
75
76
77
Industries, especially in manufacturing and process industries have been leveraging the power of
“connectivity enhanced automation systems” to create solutions for improving operational
efficiencies and productivity of their assets and processes. They have created industry specific
standards and protocols in automation space. While many of these standards are defined at the
higher levels of the OSI model, the features have been standardized pre-assuming a certain
communication layer to service the application.
78
79
80
81
Till date, in most applications implemented in India in any vertical segment, the communication
infrastructure selected is a captive system that is used dedicatedly for the specific solution. In a
few cases, in larger organizations, certain dedicated channels of the corporate communication
backbone infrastructure (if it exists) are earmarked for such solutions.
82
83
84
85
86
87
The primary reason for this is driven by the need for a safe and secure operational regime,
instead of operational efficiency improvement. Automation solutions do not have a good
business case in several industry segments in India (especially in Smart Grids space) due to the
high TCO (CAPEX +OPEX) of the required communication systems, if these are dedicated for
the solution. Even a common communication backbone at the overall organization level for all
business, automation and IT needs does not make the solutions financially attractive.
88
89
90
91
92
93
94
As the IT sector grows in maturity in terms of robust engineering practices, creation and usage of
IT tools as “products”, user organizations are willing to migrate to digital shared platforms
(example - cloud) in a Platform as a service (PaaS) mode. PaaS platforms help reduce the cost of
service to individual clients and at the same time brings bare minimum standard features across
all vertical segments. The time is ripe for offering a common communication platform (the
“information” highway) for applications from various vertical segments (the “data” vehicles), in
order to bring down the TCO of the communication piece to affordable levels.
6
95
96
97
This brings the need for independent M2M platforms that can offer content transport capabilities
in a seamless, reliable and affordable manner with universal standards for content handling and
quality of service.
98
99
100
101
102
103
An independent M2M platform, that is based on a single or heterogeneous communication
technology on the one hand, with a set of standard common services (OSS, BSS and much
more), and standardized device interfaces, can be leveraged by multiple service providers,
multiple user organizations and for multiple applications. Availability of standard interfaces on
the communication and device facing sides of such a platform, will foster innovations in the
communication and device segments, with assured quality of service.
104
105
106
107
108
109
One of the major responsibilities of TSDSI’s M2M group is to define an M2M framework to
meet the above objectives. As part of this exercise, the group has undertaken study of various
vertical segments to extract business requirements from an M2M/IoT platform perspective. This
has helped the team bring out common requirements of all verticals, which in turn will become
candidates for M2M platform functionalities. This document is a compilation of application use
cases in various verticals studied by the team.
110
111
112
113
114
7
115
116
117
118
119
120
121
122
123
124
125
126
2 PURPOSE
127
128
129
In order to define a M2M service platform that can serve the needs of different verticals, it is
important to understand the functional requirements of these verticals in sufficient depth for the
appreciation of architecturally significant requirements.
130
131
132
133
134
TSDSI’s M2M group has undertaken study of various vertical segments to extract business
requirements from an M2M/IoT perspective. This is intended to help cross pollinate useful
features across different verticals for the overall benefit of the user community. Purpose of this
exercise is to extract common requirements of all verticals which in turn will become candidates
for M2M platform functionalities.
135
136
137
138
139
It also brings out the India specific implementation experience and learnings. This will help
aspiring M2M platform providers to gain an understanding of the drivers for successful field
implementation in the Indian ecosystem. It is believed that, India geographical market itself is a
representative sample for emerging economies. Therefore, a framework that is defined to address
this segment, will help to serve the needs of emerging economies market too.
IoT/M2M market is growing at the rate of approximately 8% CAGR (by no. of devices) and is
expected to touch 20 billion No. of connected devices by 2020. As on date, “niche”
services/solutions are being offered by players in key verticals in India as an end-to-end offering
encompassing the devices, communication system and the controlling IT application. A few of
these are – Automated Meter Reading in Power and Water Utilities, Electronic Toll Collection
Systems in Transportation, OBD based vehicle eCall solutions in Vehicles, Telemedicine in
Health, Remote Automated Cell Tower Monitoring, Street light Management systems in Smart
City, Home security and Surveillance systems, Building Management Systems, Automated
manufacturing in Industrial Automation etc. These qualify as M2M offerings in the specialized
vertical segment.
140
8
141
3 INTENDED AUDIENCE
142
143
M2M Platform Solution providers (Solution and Technology Architects), Regulatory bodies and
Policy makers.
144
Entrepreneurs who aspire to create products/Apps. for deployment on M2M platforms.
145
Underlying network service providers from various communication technology segments.
146
9
147
4 SCOPE
148
149
The document gives a brief overview of M2M use case applications in Utilities vertical for India
geographical market.
150
151
152
153
154
155
156
157
158
159
It is intended to serve as a reference point for Architects, policy makers and Regulatory bodies to
understand India specific requirements and/or drivers in each area.
160
161
162
Use cases selected for elaboration were based on the criteria of their perceived architectural
significance on the M2M platform and/or market potential. Architectural significance covers
differentiated data requirements and India geography specific deployment requirements.
163
164
165
166
167
168
The list of use cases provided in this document is not meant to be exhaustive, rather, it is a
representative of the verticals, compiled bases on contributions provided by TSDSI members and
subject matter experts in this domain area. Some use cases contain evolving/future requirements
also.
Some use cases can “belong” to more than one vertical. These have been described in the vertical
that is currently championing its implementation in India.
A few “representative” use cases are elaborated in detail describing actors and scenarios with call
flows. Architecturally considerations that are significant from an M2M perspective, ranging from
information exchange interface requirements, data traffic, performance requirements,
deployment considerations from Indian context are covered. Regulatory and statutory
compliance requirements, currently prevalent standards are also provided. The elaborated use
cases describe Indian Ecosystem specific aspects. Any foreseen constraints and challenges in
such implementations are also described.
169
10
170
5 DEFINITIONS, ABBREVIATIONS, ACRONYMS
M2M
Machine to Machine
AMI
Advanced Metering Infrastructure
AMR
Automated Meter Reading
SCADA
Supervisory Control and Data Acquisition
RAPDRP
Restructured Accelerated Power Development and
Reforms Program
IPDS
Integrated Power Development Scheme
IWT
India Water Tool
GAIL
Gas Authority of India Limited.
JV
Joint Venture
171
11
172
173
6 USE CASES FOR UTILITIES
174
175
176
Note: For the purpose of this document, utility vertical covers electricity, water & gas
distribution to end consumers. Infrastructure services like waste water, sewage disposal, street
lighting are not included in the scope of this document.
177
178
179
180
181
182
183
As per WEF global competitiveness index for 2014-15 [1], India ranks 118th out of 144 countries
globally on the quality of electricity and telephone infrastructure. Our per capita energy
consumption of approximately 900 units in 2010 was nearly one third [2] of the world average.
As per an India Water Tool (IWT) study, a major part of our country is already water stressed
[3]. UN Industrial Development Organization Report titled “Sustainable Energy for All”, says
that India as a country has the largest population that lacks access to clean fuel for cooking [4].
These are important markers of a country’s economic and social prosperity.
184
185
186
187
Information and Communication Technology (ICT), especially IoT/M2M will play a key role in
improving access to and efficient utilization of electricity, water and gas. Before describing the
M2M based applications in this vertical, a brief overview of the sector trends from M2M context
is given below.
188
Power Sector from M2M perspective
189
190
191
192
193
The Installed Capacity of Power Generation in India as of Oct 2014 is 255 GW [5]. India is the
third largest producer of electricity in the world. However, our per capita electricity consumption
is low as compared to many countries, due to poor access (nearly 20% population does not have
access to electricity) on the one hand and inadequate supply to the already electrified areas. The
potential demand by 2032 is estimated to be 900 GW [6].
194
195
196
Given below is the sector wise electricity consumption in our country.
12
197
198
199
200
201
Source: Annual report of Ministry of Power [7]
202
203
204
205
206
207
As evident from the above pie chart, Industrial, domestic and agricultural segments contribute to
approx. 50% of total electricity consumption. Electricity tariff rates for industrial sector are
highest, and cross subsidize the tariff rates for domestic sector. This is in contrast to the US and
parts of Europe, where domestic sector tariffs are higher than industrial. Thus there is a reason
for industrial sector consumers to adopt energy efficiency measures, while there is no such
motivation for residential category in India.
208
209
210
211
212
213
Power supply to the agricultural sector is generally highly subsidized (if not free) and unmetered
at the connection points. The Indian Power sector suffers from very high “aggregated technical
and commercial losses” of the order of almost 30% average. One of the major reasons for this is
inefficient billing and collection processes of our distribution utilities (called DISCOMs). This,
apart from the low tariffs, is a key contributor to mounting losses of electrical Distribution
utilities in our country.
13
214
215
216
At the same time, the need for conserving energy (to reduce the energy bills but more
importantly to manage in the regime of constrained supply) has been felt by consumers in the
tariff paying categories of industrial, commercial and residential segments.
217
218
219
220
221
222
223
224
225
226
In recent times, Utilities have deployed Remote Automated Metering systems for all Industrial
category and “high value consumer connections”, in order to facilitate automated meter reading
for billing. Meters have been installed at all Distribution transformers to facilitate remote
monitoring for early detection of overloads/incipient fault conditions at the transformer end in
order to save them. As part of the Ministry of Power’s Restructured Accelerated Power
Development and Reforms Program (RAPDRP), practice of spot meter reading and spot billing
of domestic and commercial consumers is being institutionalized. There is a growing move for
metering agricultural connections also in many utilities (to help assess actual consumption for
such connections). DISCOMs are starting to introduce Demand Response mechanisms for load
management.
227
228
229
230
231
Under the RAPDRP-IT initiative, SCADA systems have been provisioned for towns with a
population exceeding 4 lakhs and input energy of more than 350MU across the country (72 such
towns). This has remote monitoring and control of the town Substations, distribution feeder
sectionalizers and Ring Main units from Town level SCADA control centres. These programs
are being continued under the Integrated Power Development Scheme (IPDS) of the Govt.
232
233
234
235
236
All these initiatives rely heavily on a robust communication infrastructure for providing
connectivity between the head-end AMR/AMI systems to the meters directly or through interim
data concentrators/gateways. SCADA control centres and the RTUs are connected over
MPLS/MLLN or dedicated FO links. A few typical applications that are based on such
communication systems are described in later sub-sections.
237
Water Sector from M2M Perspective
238
239
As per a report by the 2030 Water Resources Group [8], prepared in 2009, the world is likely to
face a 40% deficit in water availability at a global level.
14
240
241
242
243
244
245
246
247
248
249
250
251
252
India, home to nearly 16% of the world’s population has 4% of the total fresh water share. While
many parts of the country have perennial and seasonal rivers that are used for water needs, a
major part of the country is arid and relies on ground water. In recent years, diversion of land for
construction purposes and aggressive water mining has led to depleting ground water reserves on
the one hand, and disappearance of local water bodies that could have got recharged during our
abundant monsoon seasons. The increasing incidents of heavy rainshowers instead of constant
rain, not only causes flooding but also results in inadequate recharging of the water bodies.
Rampant concretization has resulted in loss of opportunities for natural ground water recharging.
Our river waters are also dwindling due to the recently changing rain patterns (we have spells of
heavy rainfall for a few days that causes flooding and gets washed away). Gradual disappearance
of natural water bodies (ponds, seasonal streams and rivers), has aggravated the problem of
storing rain water.
253
254
255
256
257
258
259
Due to this, most cities and towns in our country are already water stressed. Approx.30-50% of
water gets leaked from the water distribution network. In most cities, water is supplied for 1 to 3
hours average per day by the municipal body/water utility. Many Consumers store water
supplied by the utility in underground sumps/tanks and then pump it to their overhead storage
tanks using their own pumps. This brings to fore the water-energy nexus: energy is required to
treat water at source, its transportation to the consumption point and its pumping to the storage
tanks at the point of consumption.
260
261
Water distribution networks in most areas are old and have minimal maintenance. Quality of
water available at supply points is often found contaminated due to improper sewage channel.
15
262
263
Shown below is the ground water quality as per BIS norms from India Water Tool [3]
(http://www.indiawatertool.in).
264
265
266
267
The World Bank estimates that approx. 21% communicable diseases are caused due to unsafe
drinking water [9]. Most consumers use water purifiers in their homes as an additional measure
for further purifying water. This has introduced an additional appliance that consumes electricity.
268
269
270
271
Many State Governments have taken up implementation of 24 X 7 water supply projects in
municipalities that have adequate sources of water. A few pilots for 24 X 7 water supply have
already been implemented. The scope of these pilots covers supply of water at a specified
pressure, 100% metering (with AMR for key bulk consumers) and setting up of IVR/Web based
16
272
273
274
water customer care centres (to facilitate processing of maintenance requests and revenue
management). Overhauling/replacing of the existing water distribution network with new system
and SCADA based monitoring are also included in the scope.
275
276
277
278
279
Several Municipal corporations/water supply boards in the country are setting up water SCADA
systems in the water distribution networks to monitor flow, pressure and leakage of water and in
a few cases remote operation of control valves in the network. They are also installing Remote
Automated Meter Reading (AMR) systems for bulk water supply connections to help monitor
the flow, pressure and consumption trends of water.
280
Recently, Water ATMs are being setup to sell drinking water (pre-paid water supply).
281
282
283
284
285
It is evident that smart water meters, SCADA systems and smart customer care services (through
Interactive Voice Response IVR/Web/mobile based) will play a major role in modernizing our
water infrastructure. With Water AMR/SCADA systems in place, utility and the consumer can
improve usage/billing efficiencies, leak detection, perform distribution analysis (flow and
pressure) and improve water source usage.
286
287
288
289
290
291
292
An M2M platform can enable cost effective solutions for hosting AMR, SCADA and customer
connect services for the water sector. The platform additionally helps in remote monitoring of
the water assets, which in turn helps in improved proactive maintenance. It also facilitates
automated notifications to Operations &Maintenance staff and consumers. The M2M platform
can provide location marked data, which opens possibilities for a host of location based insights.
The AMR and SCADA applications for water sector are similar to the power sector requirements
and are described in the subsequent sub-section.
293
City Gas Distribution from M2M Perspective
294
295
296
297
298
299
City Gas distribution was pioneered by GAIL in the early 1990s with CNG for transport and
PNG as a household fuel (as a cheaper and environment friendly alternative to petrol, diesel,
kerosene and LPG). GAIL created a separate subsidiary GAIL GAS limited in mid 2000s to
address this market and also entered into a few JVs for city gas distribution. After the
establishment of the Petroleum and Natural Gas Regulatory Board, private sector has also
entered into this segment.
300
301
302
India’s demand for gas is expected to more than double in 2030, rising from 49 million tons of
oil equivalent (MTOE) in 2012 to 168 MTOE by 2030 [10]. A picture of India’s projected gas
infrastructure by the end of the XIIth 5 year plan is reproduced below from the same report.
17
303
304
305
306
307
308
309
310
311
312
313
Source: PNGRB Vision document Nov 2013 [11].
314
315
316
317
Some critical drivers for the growth of this segment where M2M can help are – improve billing
and collection efficiencies, provide interactive customer connect to address maintenance/leakage
related problems and notification of standards/regulations for the remote monitoring of the last
mile distribution network.
318
319
320
321
322
City gas distribution network should come with appropriate instrumentation/SCADA systems for
monitoring gas pressure and detect leakages in the network. It can be seen that meters and
SCADA systems are an important component in the utility services of power, water and gas. The
following sections describe a few applications where ICT and automation solutions based on
meters and SCADA/instrumentation systems can help improve the operations of such utilities.
323
324
The following subsections describe a few use cases from a utilities perspective, where there is
potential for a common M2M platform to improve the smart management of these resources.
City Gas Distribution (CGD) sector in India has seen rapid growth in recent years and consumes
approx. 13.6 MMSCMD of natural gas. There are 15.22 lakh domestic connections, 10,631
commercial customers and 2974 industrial customers at present in India [11]. In the City
Transport Sector, there are presently around 588 CNG filling stations servicing around 1.2
million vehicles. In the year 2012-13, CGD network of over 34000 km covered 90 cities across
more than 50 Geographical areas. PNGRB has recently completed the 4th round of bidding for
CGD projects.
18
325
326
327
6.1 Advanced Metering Infrastructure (AMI)
Advanced Metering infrastructure is a bidirectional communication system between meters
installed at customer premises and a “head-end” system installed at utility end.
328
329
330
331
332
333
334
Electricity, Water and Gas utility service providers install meters at consumption point to
measure the quantity and quality of the “utility” supplied to the consumer. An Advanced
Metering Infrastructure help the service providers to acquire readings from these meters
remotely and automatically at regular predefined intervals and on demand. Apart from
shortening the revenue meter reading cycle, this infrastructure also helps utility in
monitoring the reliability and quality of supply to each of its consumers. Thus, AMI helps
to avoid meter related field trips by utility representative.
335
336
337
338
Utility can remotely control supply to the consumer premise by sending connect
/disconnect commands to the meter. Load Control for Demand Response programs can
also be effected through AMI. It can also configure the meters to set their parameters (like
contractual threshold for prepayment metering) and update their firmware.
339
340
341
Note: For the purpose of this discussion, when the AMI infrastructure is used for data
acquisition only, it is called AMR (Automated Meter Reading). AMR can also be used for
monitoring energy flow and quality at various nodes in its network.
342
343
This application is described in detail from an M2M perspective at Annexure – Advanced
Metering Infrastructure.
344
345
346
347
348
349
350
It may be noted that the business case for full AMI of residential consumer meters is not
very strong in India, given that the tariff rates in residential sector are highly subsidized.
Walk-by Automated Meter Readings (AMR) may turn out to be cost efficient as compared
to an AMI/AMR solution that aspires to use a dedicated communication infrastructure at
the last mile and in the WAN segments. Moreover, experience of cellular communication
infrastructure reliability for AMR communication in RAPDRP-IT has not been
satisfactory.
351
352
353
354
355
356
357
358
359
6.2 Walk-By or Drive-By Automated Spot Meter Reading (AMR)
Note: Remote Automated meter reading application is described as a subset of the AMI
use case detailed description.
Globally, power Utilities have been doing revenue meter reading of users through the
mechanism of Automated Meter Reading using walk-by or drive-by methodology: a meter
reader walks through a locality carrying a Meter Reading Instrument (MRI). This MRI is
able to "connect" with meters in the neighbor-hood over wireless and acquire meter
readings. The readings are uploaded to a Head end System (HES) as and when backhaul
19
360
361
connectivity is available (over an internet connection). HES can give remote route
navigation support to the meter reader.
362
363
364
365
366
367
368
In some cases, the meter reading Instrument can be configured to calculate revenue bill of
the user (by pre-loading the user’s tariff rate and revenue history in the instrument). Here,
the Meter reader can deliver the bill to the user on the spot, after reading the meter. This is
known as Spot Billing. The bills generated by the MRI are uploaded into the utility
revenue system later or online for synchronization in the Revenue Management System.
Such techniques are very popular in areas that are difficult to reach, as it helps avoid dual
visit to the customer premise for delivering bills.
369
370
Spot Meter readings of consumer meters has been implemented in more than 50 state
distribution utilities in India as part of the RAPDRP-IT initiative.
371
372
373
This form of AMR is prevalent in scenarios where a complete technology based Remote
AMR/AMI system is neither cost justified nor the frequency of meter reading is high
enough.
374
375
This technique is increasingly being used widely in water and gas revenue metering
projects.
376
377
378
379
380
381
382
Note: MRI to meter connectivity in the Field Area Network (FAN) is generally
implemented using RF technologies. The MRI to Head-end System connectivity (WAN
segment) is not necessarily required to be online in most implementations. If online
connectivity is available, utilities will be encouraged to perform on spot payment
collection from the users also (as the payment made by consumer can get reflected in the
utility revenue system immediately, giving confidence to the consumer for such modes of
payment).
383
384
385
386
387
388
389
390
391
392
393
394
395
6.3 AMI Network Management Systems (NMS)
Advanced Metering Infrastructure requires reliable network connectivity from each meter
to the head-end application through the interim gateway/Data Concentrator/Aggregator i.e
in the WAN and FAN/NAN segments. A Network Management system helps manage the
AMI network by configuring, monitoring, and supporting detection and restoration of
connectivity of devices. Many of the functionalities of such systems are candidates for an
M2M platform common services layer and hence described below:
Configuration: The AMI communication network should be self-configuring so that
remote meter can get connected to the enterprise application via any alternate
communication route. (While RF mesh networks support reconfiguration, this may not be
feasible on radial PLC networks). A Backup communication module may be required in
the meter to support an alternate communication channel for critical connections. This may
not be possible on Power Line Carrier (PLC) networks. A point to be considered is if this
20
396
397
can be offered as an M2M platform common service on same philosophy as mobile
network portability (MNP) of telecom networks.
398
399
400
401
402
403
Monitoring: This includes Network link coverage and reliability management (monitoring,
detection and rectification of link failures) w.r.t. link and bandwidth. The communication
system should be "available" at all times/on-demand. There should be automated alerts
when link between end to end devices goes down. Analytics at gateway are required to
provide insights for reasoning link failure (power failure or network congestion or poor
bandwidth or poor signal or device level issues).
404
405
406
Device Connectivity monitoring: This is a more generic service that monitors connectivity
of any two Remote machines and raises alerts on detecting a loss or deterioration in quality
of connectivity.
407
408
409
Recovery: Networks where system components get recovered automatically after a failure,
are called self-healing networks. Example - “System” gets re-established automatically
after a power cycling event.
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
6.4 Distribution Transformer (DT) Monitoring
Distribution transformers are the “power gateway” to downstream Low Tension (LT)
residential, commercial and agricultural consumers in the predominantly radial distribution
systems in India. The incidence of DT failure in India ranges from 1 to 25% across
DISCOMS as against the international norm of 1-2%. Some of the key reasons for this
high failure rate is overloading, oil leakage, inadequate maintenance. The Govt. had
mandated 100% metering through AMR ready meters for all DTs. The intent behind this is
to enable remote monitoring of DTs through an AMR system, to identify incipient faults in
the DT. A few utilities have implemented remote operation of the DT LT supply to
disconnect when the DT is overloaded in order to save it. Under the RAPDRP-IT
program, all DTs in the 1400 RAPDRP IT scheme towns have been provided with Remote
DT monitoring through meters. This scheme is now getting extended to the rest of the
country under the IPDS scheme. Here, DT meters are provided with an AMR modem that
helps the utility to obtain DT consumption parameter details at a daily frequency. It also
gets automated notification alerts in case of supply outage at the DT end.
6.5 Ring Main Unit (RMU) and Fault Passage Indicator (FPI) connectivity
Fault Passage Indicators (FPI) and Ring Main Unit (RMU) devices are being installed on
key sub-transmission Network nodes (66kV to 11kV) to improve reliability of the system.
Utility can monitor the health of the network at these nodes through remote monitoring of
these devices over a SCADA system. These devices can autonomously isolate faults in their
section, thus enabling recovery of the remaining system. Alerts sent by these to the control
centre, help the maintenance staff to identify the location of the faulty sections immediately
21
432
433
434
435
436
437
438
439
440
441
442
443
444
445
and thus reduce the time to detect and locate faulty sections. In RAPDRP part ‘B’ scheme
almost all utilities are going to install these devices in their networks in large nos. (on an
average 200 to 300 per Distribution utility). The proposed communication infrastructure for
these currently is GPRS WAN connectivity. The need for real-time notification of faults to
the control centre is the only critical requirement here.
6.6 Supervisory Control and Data Acquisition (SCADA)
Supervisory Control & Data Acquisition (SCADA) system gathers and displays
information from a wide geographical area and permits control of selected elements.
Complex systems like road or rail traffic; power, water or gas grids cannot be managed
locally. These systems need an overarching monitoring system that has the capability of
detecting critical conditions and notifying them to the Operator for their immediate
attention and remedial action. The operators in turn may need to control the network
remotely in order to respond to such critical situations example – prevent traffic jams or
collisions, clearing overloaded power lines in a network, identify gas leakages etc.
446
447
448
SCADA systems are the fundamental infrastructure layer in Power systems on which
applications like Energy Management Systems (EMS), Distribution Management Systems
(DMS), Distribution Automation (DAS), Substation Automation (SSA) are built.
449
450
SCADA systems comprise of sensors, actuators, Remote Terminal Units (RTU) /Data
concentrators (DCU), Front End Processors (FEP) and the SCADA head-end systems.
451
452
453
454
455
456
457
Key SCADA system functionalities comprise of continuous data acquisition from RTUs,
event notification on its detection at RTU end and remote control of actuators through the
RTUs. Sensors and actuators are connected to the RTUs over instrumentation wires. RTU
to FEP communication links are required to be with deterministic low latency and can be
redundant/fault tolerant depending upon the criticality of the application. SCADA systems
may have a FEP system at a Primary Data Centre and may have another FEP system at a
Disaster Recovery Centre.
458
459
460
461
462
In RAPDRP IT scheme of the Govt., SCADA systems are being installed for remote
monitoring of all Substations in distribution networks of key towns. Here, RMUs and FPIs
are planned to be connected to the Control centre over GPRS communication links (as data
is not critical); however Substations are connected to the control centres over
MPLS/MLLN links.
463
464
465
In Power Transmission networks, dedicated OFC links are being used for system
operations at the Load Dispatch Centres. However, PLCC links are also still used as the
primary channel of communication in many LDCs.
466
22
467
468
469
470
471
6.7 Prepayment Metering
472
473
474
475
476
Many power utilities are encouraging prepaid mode of electricity purchase for their
consumers, as this helps to reduce efforts for collecting payment at their end. Consumers
are adopting prepaid mode in order to help them “budget” for its usage. Landlords prefer
prepaid mode of payments, to save them the bother of recovering payments from their
tenant consumers.
477
478
479
480
481
482
483
484
485
486
Smart Grids of the future will have smart meters that support both prepayment mode as
well as credit mode of electricity consumption, from which consumer can select any mode
at will. In the conventional credit mode of payment, utility supplies electricity to the
consumer on “credit” basis and raises a bill for consumption made in the past, as measured
by electricity meter installed at the consumption premise. This scenario applies to water
and piped gas supply also. In prepayment mode, consumer buys electricity by paying
upfront. The prepayment amount is loaded into the electricity meter as a recharge and gets
updated in the balance credit amount in the meter. The meter is pre-configured to allow
supply of electricity worth the total “balance” amount in its memory, calculated based on
the applicable tariff for the consumer. As soon as the balance in meter falls below a
23
487
488
489
490
threshold level, meter issues a warning and disconnects through an inbuilt switch on
breach of a second disconnect threshold value. The process of remotely updating the meter
balance is achieved through an AMI layer. There is a provision for local recharge of the
meter by entering a token # into the meter through a keypad provided on the meter.
491
492
493
494
495
496
497
498
Alternately, meter does not have to manage balance amount details. A remote Prepayment
server manages the payment and consumption of consumers. It reads the consumption of
meter remotely over an AMI network continuously and decrements the balance amount
accordingly. As soon as balance amount fall below threshold, it sends a meter disconnect
command remotely to the meter over the AMI infrastructure. Meter simply executes the
disconnect command at the consumer premise. As soon as consumer makes payment, i.e
balance goes above a threshold value in the prepayment server system, it sends a meter
reconnect command remotely over the AMI infrastructure.
499
500
501
502
503
504
505
Prepayment meter disconnects supply to the consumer end when balance amount falls
below the threshold level; utility and consumer are notified of the disconnection; meter
reconnects when account is recharged. Consumer can recharge their account online and
this information will flow to meter from head-end over M2M platform. Consumer account
can be switched between prepaid and credit remotely over the M2M platform. This system
is currently applicable for electricity but can be applied for water, gas etc. utilities (smart
guest houses).
506
507
508
509
510
A Prepaid Metering Standard for Electricity Meters is notified by Bureau of Indian Standards
(BIS), India: IS 15884 (2010): Alternating Current Direct Connected Static Prepayment
Meters for Active Energy (Class 1 and 2) [ETD 13: Equipment for Electrical Energy
Measurement and Load Control].
511
512
513
514
6.8 City Gas Distribution (CGD)
Cities, especially metros are increasingly going in for supply of natural gas through piped
gas distribution systems. A gas distribution agency supplies natural gas to consumers
through a pipeline network.
515
516
517
518
519
Improving operational efficiencies and bringing down costs are identified as key areas of
improvement for local distribution companies in the emerging economies. Technological
advancements in meter-to-cash, distribution, customer service, leakage detection, workforce
management and asset management not only help in revenue protection and operational
efficiency but also help in meeting regulatory compliance.
520
521
522
523
The gas pipeline network is expected to come with a telemetry system to monitor and
control the supply pressure at various nodes in the distribution network and to ensure that
there is no leakage in the gas flow. These Telemetry systems traditionally use
instrumentation cabling for communication connectivity between the pipeline monitoring
24
524
525
nodes and the local PLC control centre. It remains to be seen whether GPRS
communication infrastructure is good for use in City Gas Distribution telemetry systems.
526
527
528
529
530
531
532
As per current practice, gas meters are installed at consumption premises for the purpose of
measuring consumption. Reading of the gas meters is currently done manually by a meter
reader who visits the consumer premise as per the billing cycle which is quarterly or later.
In some cities, smart automated meter reading by walk-by technique is being deployed.
Many CGD suppliers encourage their consumers to self-declare consumption by uploading
the meter reading value or a photograph of the meter to the CGD supplier website or on
phone.
533
534
535
536
537
538
AMI meters, also known as smart meters, are designed to transmit pricing and energy
information from the utility company to the consumer enabling a two way communication.
The various solutions in the smart gas market are Meter Data Management (MDM), meter
data analytics, Supervisory Control and Data Acquisition (SCADA), asset management for
gas pipeline, Geographic Information System (GIS), leakage detection, and mobile
workforce management.
539
Shown below is the Y-O-Y growth trend in the global market of Smart Gas meters.
540
541
542
Source : Markets and Markets Analysis
543
544
545
546
547
548
549
This market is limited to installation, system integration, and product management. The
above technology not only helps the consumer in the billing process but it will also
optimize manpower for revenue management and maintenance activities. The control and
data acquisition system also allows the Utility Company to develop statistical reports on
the consumption pattern of the gas in a particular area at different time slot and in different
season. This will help gas distribution vendors to prepare themselves better for any
eventuality.
550
551
It must be noted that a sophisticated full AMR system is not required for city gas
distribution as the meter is primarily used for revenue metering purpose for which a single
25
552
553
reading at the billing cycle is sufficient. Therefore, investing into a full RAMR/AMI
solution with dedicated communication infrastructure may not be cost effective.
554
Gas Sensors and Gas Metering: Applications and Markets
555
556
557
558

559
560
561
562

563
564
565

566
567
568
BCC Research estimates the global market for gas flow meters, sensors, monitors,
and secondary flow instrumentation totalled $4.5 billion in 2013 and $4.8 billion in
2014. Growing at a projected compound annual growth rate (CAGR) of 5.9%, the
market should exceed $6.4 billion by 2019.
Gas flow sensors/monitors market accounted for nearly $2.2 billion in 2013. The
market segment is predicted to increase to $2.3 billion by 2014, and with a CAGR of
6.7% from 2014 to 2019, it is expected that the market will reach $3.2 billion by
2019 [12].
BCC Research estimates that the gas flow meters segment of the market will reach
nearly $2.4 billion by 2019 up from $1.9 billion in 2014, a CAGR of 5.1% from 2014
to 2019 [12].
Some of the Gas metering standards followed in Europe are


Open Meter Standards (OMS)
DSMR (Dutch Smart Metering Requirements)
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
6.9 City Water Distribution
According to research [13] the smart water meter market is poised for steady growth in the
coming 5 years. Drivers for this growth are increasing demand for water itself, ageing system
infrastructure, and a need among utilities to operate their systems much more efficiently.
Most Systems, built 50 to 100 years ago badly need upgrading. As new pipes are constructed,
utility operators will simultaneously evaluate the merits of upgrading to the latest meter
technology as well. Additional forces that will propel smart water meter shipments will
include the need to conserve scarce water supplies, especially in desert regions like the
Middle East or South western United States, the need to reduce high levels of non-revenue
water, and the need to satisfy regulatory requirements. Growth will also come from emerging
markets in Asia Pacific and elsewhere as water metering rises along with rising standards of
living and the need to manage this valuable resource efficiently.
How smart water meters function: Smart meter works similar to Electricity meter where
water meters measures and manages water usage and losses. Smart meter integrated with
smart devices would focus on appropriate water usage by the customer as the customer is
directly paying the bill for the water consumed by them. The water distributor, municipalities,
government body needs to devise the mechanism where the proper billing system is installed.
The water meter should also measure water pressure at the heads along with the flow of
26
588
589
590
591
water, so as to enable its transportation to overhead tanks in high rise apartments. As per
CPHEEO manual, a head of 17 metres for metros, 13 metres for cosmopolitan and 7 metres
for tier II and II cities has been mandated. Metering is also expected to help conduct water
audits, a crucial tool for identifying and plugging water leakages
592
593
594
595
596
597
Water distribution in cities is undergoing renovation and modernization with water
SCADA systems inbuilt into the newer systems. Here, SCADA system helps monitor the
water flow and pressure at various nodes in the water distribution network as well as help
in identifying leakages quickly. A few municipal bodies are in the process of implementing
SCADA systems on their existing water and waste water networks, to monitor the flow and
pressure characteristics for improving operational efficiencies and planning.
598
599
600
601
602
603
604
605
606
607
608
609
Several water supply boards/municipalities are piloting the concept of actual consumption
based water supply billing as against a fixed charge practice prevalent currently. The idea
behind this move is to accurately measure the consumption of water by consumers in order
to monitor and plan for consumption trends, and also to monitor quality of supply (water
pressure) at the consumption points. Metering is also expected to help conduct water
audits, a crucial tool for identifying and plugging water leakages. Most bulk consumers of
water are being provided with AMR ready/compliant water meters that can be read either
through a GSM/GPRS based RAMR mode or through a walk-by AMR mode. AMR
metering is being piloted for residential categories of consumers in a few municipalities.
These are capable of being read through walk-by AMR. GPRS based RAMR systems for
residential consumers with dedicated communication infrastructure does not make
commercial sense.
610
611
612
613
614
615
616
617
In Europe some utility companies are responsible for water, gas and electricity meters. In
integrated system Energy meter acts like a concentrator for gas and water meter since it is
always powered. Whereas the gas meter and water meter could be battery based which are
required to run for several years. Hence the power consumption should be low. In India, in
places where the metering topology is similar to that in Europe (electricity, water and gas
meters are collocated at the consumption premise), electricity meter can be considered as a
gateway like in Europe. Wireless Metering Bus is a one such standard followed in Europe
region for supporting this topology.
618
619
WMBus operates in India at 865 MHz to 867 MHz to provide data to nearest electricity
meter which can provide data to the head end system.
620
621
622
Pressurised water supply systems in societies draw water from a water reservoir at the
mains. These use Industrial Automation systems for their management.
623
27
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
6.10 Electric Vehicles Charging
As per the National Electric Mobility Mission Plan 2020, there is a potential for sale of 6-7
million xEV (Hybrid and Pure Electric) Vehicles in 2020 in India. Electric Two-wheelers
have already gained popularity in the country. These vehicles contribute in saving precious
fossil fuel and reduced pollution. However, they are a new class of consumer for the
already burdened electric grids.
There are 4 types of EV charging:
1. V0G or Dumb Charging: Vehicle is plugged into the power socket and it gets charged
like a regular load.
2. V1G or Smart Charging: Vehicle charging characteristics can be controlled from the
grid side through an enabling AMI infrastructure via the Home Automation route.
Here, the charging current can be controlled to suit the prevailing grid side network
characteristics and therefore overburdening of the grid can be avoided.
3. V2G (Vehicle to Grid): Here energy stored in the EV batteries can be pumped back
into the Grid for grid support. The EV here acts as a mobile Electric storage device
i.e. Virtual Power Plant.
4. V2B (Vehicle to Building): Here, vehicle does not communicate with the Grid but
only with the Building Automation System. Energy from vehicle is consumed within
the Building and is not fed back into the grid.
A suitable public electric charging infrastructure with standard charging interfaces and
billing and payment mechanism is required as a companion to encourage adoption of
electric vehicles. This infrastructure will require a system for monitoring of charging
behavior at the charging points, and a system to support pay-on the-go billing
(Prepayment or credit charging) for the electric charging.
Currently, EVs charge status is monitored remotely by the EV service provider through a
GPRS enabled M2M platform and alert notifications are provided on the vehicle
dashboard when charge levels are approaching near empty. The EV service providers
can also remotely enable release of a “reserve” charge in the vehicle when it is near
empty levels at the request of the driver.
There is a potential for M2M based solutions for searching for and indicating location of
the nearest charging point on the vehicle dashboard, when the vehicle charge is nearing
empty levels.
6.11 Microgrids
Microgrid is a local electricity grid with integrated energy system that intelligently
manages loads and distributed energy generation resources and storage within the grid.
28
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
Microgrid can be independent i.e. isolated from main power grid (called Off-grid) or
integrated with the main grid (Called grid connected).
Microgrid comprises of local distributed generation (example solar/wind/biomass/microhydel/Diesel), local storage (battery) and a few local consumption premises. Meters are
used to measure the generation and consumption. There can be prepayment or credit
mode of metering. Meters can have load connect/disconnect switches to manage or
restrict load consumption. Sensors and actuators are installed at the local generation
equipments and storage to manage them from a central control centre.
Reaching the grid to remote and sparsely populated areas is often not viable
commercially and hence these areas remain in the dark. Isolated Microgrids with local
generation is becoming very popular in such areas across the world. Several communities
like to go in for grid connected microgrid systems with local storage and local captive
generation in order to securitize supply of power. In situations of grid failure, the
microgrid “islands” itself from the main grid and is able to maintain lifeline supply to the
microgrid area. Revival of LV DC systems, DC microgrid campuses are also gaining
ground.Solar PV based microgrids are being setup in India under the Jawaharlal Nehru
National Solar Mission JNNSM).
Microgrids rely heavily on smart sensor based communicating systems for AMI based
metering, dispatching of Distributed Energy Resources (DER) and Storage, and a Control
Centre for managing the operations, stability and safety of the grid.
Distributed Energy Resources (DER) provide on-site generation for electricity
consumers. Microgrid not only allow DERs to operate as dispatchable assets to provide
power to the microgrid when appropriate, but also to aggregate several DERs and energy
storage devices to optimize their use on behalf of the electricity users. When one DER
goes down, the microgrid can reduce energy usage in other locations and utilize other
DERs to adjust for the electricity generation capacity loss.
Smart Microgrids integrate various systems such as renewable energy generation, energy
storage, Building Management System(BMS), the utility’s Distribution Management
Systems (SCADA/DMS) etc and facilitate active participation in the Demand Response
and Ancillary Services markets, create enabling platform for roll out of Electric Vehicles
(EV) and transition to Net Zero Energy Buildings (NZEB).
Microgrid Control Centre optimizes integration, dispatching and control of DER, Storage
and loads. It manages frequency and voltage to maintain reliability of power supply. It
recognizes and responds in real time to faults in the system. Several service providers
29
702
703
704
have Smart Microgrid Control Centre solutions hosted in the cloud for managing multiple
microgrids. A reliable and robust communication network is a pre-requisite for smart
microgrids.
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
6.12 Distributed Generation
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
6.13 Wide Area Monitoring using Phasor Measurement Units (WAMS)
Small capacity Generation of electricity that can be consumed within the power
distribution network locally is known as Distributed Generation. This includes Captive
Power Generation from Diesel Generation power backup units, or from solar, wind,
biomass, micro-hydel plants that serve the load behind the meter. Small scale solar, wind,
or other renewable power generation that can be integrated into the local grid at the
distribution network level at community level also come under this category. Example –
captive power plants in malls, shopping complexes, hospitals, campuses, industrial
complexes, housing societies and townships etc.
Recently, as a result of JNNSM initiative and net metering policy announcements, retail
level consumers are turning into prosumers by installing rooftop solar systems in their
homes/buildings.
A renewable distributed generation system includes a SCADA system with sensors for
monitoring the renewable source intensity (example - insolation or wind speed), voltage,
current, power quality (harmonics) etc. This data is required at a central control centre for
analysis to help improve the forecasting algorithms and renewable generator
performance. An RAMR system with a meter at the power generation point for
measuring the actual generation and a meter at the grid injection point to measure the net
export/import of energy is also part of the overall distributed generation package.
Power Transmission networks are required to be managed under strict grid regulations.
When the limit of power system equipments are to be determined dynamically or the
system is to be rescued from a near potential collapse, data on the critical parameters of
the grid is required in realtime to the operator. SCADA data is generally available in 5 10 seconds granularity which does not reflect the transient state which is of 2-5 cycle in
nature of the network. Recently, phasor measurement units (PMUs) are being deployed
in for monitoring the network at a granularity of 20-1000 msec. These systems are known
as Wide area monitoring systems (WAMS). The real time situational awareness and
decision support systems enhance power system stability and reliability and provide
space to operator to use infrastructure to its maximum capacity. Typically, the stability
boundaries are determined by voltage, frequency and angular separation between
different interconnections. Secure operating region is the initial state of any power system
operation and when the system tends to violate from its optimal operation limits, the
system needs to be brought back with minimal co-ordinated actions. Wide Area
30
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
Monitoring Solutions help monitor grid stability and provide a wide area situational
awareness in real time by deploying Phasor Measurement Units, Phasor Data
Concentrators and WAMS analysis and visualization system on standards based protocols
and communication channels.
A Phasor Management Unit (PMU) is a microprocessor based device that reports the
magnitude and phase angle of an analog and /or derived phasor with respect to the global
time reference (time stamping), as per the synchrophasor standards (IEEE 1344,
IEEEC37.118). Synchrophasors are vector measured values (magnitude and phase of the
current and voltage are measured and transmitted). Applying a time stamp to the
transmitted vector measured values allows a comparison of the measured values from
different locations in the network.
Typically, a PMU measures voltage and current phasors at various nodes of the
transmission network to provide accurately time stamped measurements, allowing for
synchronised comparison of two quantities in real time to support power system stability
analyses and control.
Key components of WAMS are PMUs installed at each feeder in a substation(S/s) and a
phasor data concentrator (PDC) that acquires data from all “downstream” S/s PMUs over
a dedicated communication link. A PDC typically acquires data with a latency of 2040msec. All PMUs are GPS time synchronized.
Data from the PDCs travels to a control centre over a dedicated communication
infrastructure. It should be noted that WAMS are delay intolerant systems.
Currently, such systems are being piloted in various parts of the world. India has
undertaken an ambitious plan of deploying more than1500 PMUs across the country’s
national transmission network. Wide Areas Control Systems (WACs) are not yet
envisaged in the country.
In conclusion, it can be seen that utilities sector has traditionally relied on dedicated
communication infrastructure like PLCC/OFC/MPLS etc. as a communication medium of
choice for SCADA critical applications. Recently, public communication technologies
like GPRS based systems are coming into being in such applications. AMR/AMI based
solutions have evolved along with cellular technologies.
Establishing and sustaining GPRS link automatically from remote sites to a central
"head-end" is one of the key challenges being faced in the implementation of AMR/AMI
projects in this vertical. Also, there isn't any standard tool/mechanism for monitoring link
availability/health for such a large population of communicating modem based links.
Going forward, when AMI based Smart Grid projects are implemented, backhaul
31
781
782
783
784
785
786
787
788
789
790
791
792
793
communication network will be the foundation layer. Here, need for 100% availability of
the GPRS/communication link is even more essential as important use cases like Demand
Response, Load Management, Outage Monitoring etc. require constant communication
between the Head -end and tail-end remote equipments.
High cost of communication infrastructure has prohibited utilities from implementing
these solutions for the last mile consumers. M2M platforms that can host multiple
applications from various verticals, offer a unique opportunity to this vertical or
connecting the last mile consumers and bringing them online, thus opening up a host of
new applications to their mutual benefit. Need for transportation of data as per its priority
on same channel has also emerged from this vertical. Knowledge on presence,
connectivity and reachability to Remote devices at all times and mapped to their locations
is also a key need. These features should be supported at a M2M service layer.
794
32
795
Annexure – Advanced Metering Infrastructure
796
797
798
799
1
800
801
802
UC_Utilities_Advanced Metering Infrastructure
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
An Advanced Metering Infrastructure is a system by which following functionalities can be
achieved:
 Scheduled meter Reading: Remote automated acquisition of Utility Meter Data at Head –
end. The data can be acquired at a configurable predefined frequency.
 On demand meter reading: Meter reading data can also be acquired “on-demand”.
 Event notification: Events detected at meter end can be notified to the head-end.
 Remote meter operation: Head-end application can remotely control supply at the meter
end by commanding the meter to connect or disconnect supply. This can be done for a
single meter or a set of meters. It can be done instantaneously or can be set for execution
at a later instant.
 Remote meter configuration: Meter parameters can be set remotely by the head-end.
These parameters can be for setting meter maximum demand threshold or for updating
the meter’s balance in case of prepayment metering.
 Meter location health monitoring: meter location health data, based on the metering unit
self-diagnostics can be monitored remotely. This includes monitoring status of power
supply to the meter location.
 Meter firmware can be updated remotely through the Head-end application.
 Meter time synchronization can be done over the AMI system.
2
Title
Objective
To summarise, various meter related activities can be performed remotely, thus saving cost, time
and manpower for making field trips.
Advanced Metering Infrastructure also facilitates execution of Demand Response programs:
Meters can be controlled remotely by setting their behaviour for a demand response event or
controlling them directly in real-time during the DR event.
AMI can be used for other utility meters on the consumer premise like water and gas meters also.
Meter Data Acquisition without remote meter operation (Remote Automated Meter Reading) is
also covered in this use case description.
33
831
832
3
833
834
835
836
837
838
839
840
841
842
843
844
Source
Smart Grid Use Case Repository
Smart Metering Use cases – OneM2M Requirements Document
Hem Thukral, ISGF
Dheeraj Agarwal, WIPRO
Narayanan Rajagopal, TCS
Narang Kishor, Narnix
Anirban Ganguly, TTSL
B S Chauhan, CDOT
Raunaque Quaiser, ST MicroElectronics
Nandan Kumar Jha, IITB
Bindoo Srivastava, IITB
845
4
846
4.1 Current Practice
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
Background
Consumer meter reading data is acquired manually by meter readers who visit the meter
premise monthly/bimonthly either by visual reading or through spot meter reading handheld
devices. Generally, total energy consumption for the entire “billing” period is taken for the
purpose of billing. This reading is uploaded to the Billing system of the utility at the end of
the day or later. Meter readers follow a meter reading route sequence to cover the meters in
an area. This often results in missed readings (due to meter premises locked or other
reasons), “coffee shop” readings, wrong readings (visual reading error), missed consumers
(meter not listed in the reading list). Errors creep in during the uploading process (incorrect
manual upload, validation failures etc.). The entire process is time consuming.
Apart from the errors in the billing readings as described above, there is no data on
consumption pattern of individual consumers at a granularity less than billing period, and
quality of supply to consumer point cannot be monitored. Any tampers or faults in meter
also go unnoticed.
Utilities have already established Remote Automated Meter Reading systems for meter data
acquisition (RAMR) of their “high revenue” consumers (HT, Bulk LT etc.). Meters have
been installed at Distribution Transformers for monitoring the aggregated energy
consumption of downstream consumers. RAMR for these meters is getting implemented.
The primary focus here has been to ensure that meter reading data should be available atleast
at a monthly periodicity so as to ensure billing. Data acquisition at a daily or less periodicity
is not an operational requirement as on date(for consumer meters).
This use case extends RAMR to the last mile – the LT consumer. It also aims at providing
meter reading data to the utility at a daily/hourly periodicity for monitoring consumption
34
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
trend and use the information to predict load for the upcoming time blocks; observe and
monitor voltage, frequency and power factor profile at the various nodes in the grid and take
suitable actions (like remote connect/disconnect of supply) to ensure these lie within
acceptable limits.
4.2 Need for Use Case
Electricity Meters are no longer simple billing meters of the past. They now belong to the
genre of information loggers that can monitor and capture energy, load, voltage, current,
power factor and tamper events et al at the metered premise. This rich information, if
sourced at the right time, can be leveraged to provide improved quality of service to the
consumer and also detect faults/mal-operations on occurrence. Electricity supply is
increasingly going out of the realm of “obligation to serve”and is becoming a commercial
service, where very soon, customer will have a choice of multiple suppliers.In such a
scenario monitoring of energy consumption and supply quality at individual consumer
premises will be very important for utilities and consumer themselves. This data will help
them “monitor” quality and reliability of supply, improve asset operations, manage
consumer connections and billing and plan energy despatch much more efficiently. It also
helps obviate the need for utility staff to visit the consumer premises to take meter readings,
providing all data remotely.
4.3 Indian Ecosystem Specifics
In India, manual meter reading activity for billing is cheaper than remote system based
reading. (Globally, manual meter reading for revenue is more costly than system based
RAMR). However, a remote meter reading system allows utility to acquire data frequently
from the meter, which can be used for monitoring the energy flow quality and reliability
etc.
The Indian utilities, regulators, policy makers are aware about the potential of AMI as the
foundation for not only smart grids, but also to improve their operations in a BAU
scenarios to serve their consumers (retail electricity distribution)...
On the electrical domain front: RAMR has been implemented in more than 50 Utilities in
1400 towns of the country covering on an average 50000 meters per utility the RAPDRPIT scheme alone. Here meters installed on HT consumers and at distribution transformers
are connected directly to a Meter Data Acquisition Systems (MDAS) – Head end system
through GPRS modems. This program is being extended to cover other parts of the country
under the Integrated Power Development Scheme (IPDS).As part of the IPDS scheme, all
distribution transformers, HT consumers and ring-fencing boundary meters will be covered
by RAMR.
India’s Smart Grid Vision is to “Transform the Indian Power Sector into a secure,
adaptive, sustainable and digitally enabled ecosystem that provides reliable and quality
energy for al with active participation of all stakeholders. Visibility into the each and every
power system node – at across the value chain, is a key pre-requisite for realising this
vision. Smart Grid Technology pilots are being implemented in a few utilities to gain
experience as a pre-cursor to a full rollout. The primary focus of these pilots is the AMI
layer- specifically the smart meter and communication infrastructure for the last mile and
backhaul connectivity.
In the water domain, utilities/service providers are increasingly exploring RAMR solutions
to monitor and plug water leakage.
35
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
City Gas distribution service providers are also exploring walkby AMR solutions for
performing revenue reading activities. It should be noted that communication infrastructure
for the power sector AMI can be leveraged for water and gas RAMR also. Water and Gas
AMR is covered under the AMR use case.
It should be noted that there is no business case as of now for heat meters in India.
5
Description
Business Scenario #1: Remote Meter Registration:
A new meter installed at a consumer premise or on the electric grid node (example feeder or
distribution transformer) is commissioned into the AMI system.
36
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
A typical process flow is as below:
Actors: Meter, AMI System Administrator.
Pre-requisite: Meter is installed in the field with a previously activated communication
module. AMI Head-end and Gateway (if applicable) are available.
Pre-condition: Meter details are available in the AMI head-end Master. (This is similar to
the IMSI-MSISDN configuration into TSP’s system as part of SIM card activation).
Trigger: new meter is installed in the field and powered up.
Scenario #1: deployment architecture - Meter –Gateway- AMI Head-end. Meter contacts the
Gateway first time and provides its details (name/serial no., unique identifier and address).
Gateway verifies with the AMI head-end that this meter is authentic and valid for its AMI
system. This will help block devices masquerading as meters from the AMI system. AMI
head-end links meter name, identifier and its address in its configuration table and
“activates” the meter. AMI head-end links the meter to its parent gateway if the gateway is
expected to work as an aggregator/Data concentrator. Note- here another precondition is that
connectivity between gateway and head-end is also there. A response is provided to meter
that it has been activated and its initial readings are obtained.
Scenario #2: Same flow as case #1, except that Gateway has prior information about the
meters expected to be in its range. Hence, gateway can validate new meter on its own and
informs the head-end about this to complete registration at the head-end. Here, connectivity
between gateway and head-end need not be there at the time of registering meter at the
gateway.
Scenario #3: deployment Architecture: meter to AMI Head-end direct connection. Meter
contacts the AMI head-end directly. Here, the meter authentication happens directly from
AMI HES. Here. Connectivity between meter and head-end is required as a precondition.
Alternate flow#1: Precondition of meter details being known a-priori at head-end is not
essential. Here, when a new “strange” meter comes into the system. Head-end notifies the
user or an external system and awaits approval before registering the meter.
Note: several meters may come up concurrently in the system for registration.
Post conditions: Valid meter is registered in the system and meter gets activated. Newly
registered meter location is mapped to its electrical, geographical and AMI network
hierarchies. Meter is linked to the related consumer (if applicable). Initial meter readings and
date of activation of meter at the current location are recorded in the system.
Unknown meter discovered in the system is reported to the AMI configurator.
It the new meter does not receive a response from the head-end/gateway, it waits for a preconfigured duration and attempts to register into the system again. The no. of such attempts
can be predefined in the meter. Meter logs all attempts of registration as part of its
diagnostic logs.
37
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
Information exchange: meter details, location (geographical, electrical and AMI network),
time of registration, registration and activation messages.
Triggered from meter end at anytime; bidirectional flow of small data in real-time; high
security requirements. Requires high priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario#2: Remote Meter configuration:
Device parameters can be configured remotely through a Head-end application.
Typical call flow is as follows:
Actors: Meter, AMI Configurator, DR Service Provider
Pre-requisite: Communication link between Meter and AMI head-end is available.
Precondition: Meter has been previously registered into the system.
Triggers:
Trigger#1 - After meter registration by the AMI configurator or by a software module.
Trigger #2- Meter configuration can be changed by AMI Configurator.
Trigger #3 – Demand Response (DR) Service Provider can configure meters of DR
enrolled consumers for DR event behaviour.
Trigger # 4 – Credit amount update in Meter for pre-paid metering.
Trigger #5: AMI configurator wants to configure behaviour of gateway remotely
through the head-end.
AMI system is configured for meter reading schedule (meter parameters to be acquired and
38
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
acquisition periodicity. There can be separate “schedules” for reading different parameters
(example – monthly billing parameters reading, daily load profile, hourly instantaneous
etc.). Data Acquisition schedule can be configured to start at a defined instant, and end at
another instant (example instantaneous values of voltage, current and energy data to be
acquired from meter at half-hourly periodicity from date XX till date YY (for vigilance
purposes). Scheduled meter reading can be configured in “pull” or “push” mode according
to the type of communication modules at the meter, gateway, Data concentrator/aggregator
and head-end levels.
Event handling behaviour is configured in the AMI system. Critical events are configured to
be notified to the head-end immediately on detection. (Note – Detection of event can be later
than its actual occurrence), with or without a guaranteed SLA for delivery notification.
Example – current Smart Grid pilots in India have specified that critical events must be
notified to the head-end within 1 minute of their “occurrence”. Normal priority events can
be notified to the head-end at a scheduled frequency or when the total no. of events exceeds
a threshold no. Events can be detected by the meter (example- tamper events recognised by
the meter. There are approx. 50+ tamper events for electricity meters in the Indian
ecosystem) or gateway (example –request for registration from a new meter is an event) or
aggregator (example – scheduled meter reading failed).
Meter parameters can be configured remotely through AMI. Some example of parameters
that can be configured remotely are sanctioned demand, disconnection threshold for load
control, credit balance in case of prepayment mode of operation etc.
AMI system can configure meter behaviour for predefined triggers. Example – meter can be
configured to disconnect supply when load exceeds sanctioned demand. Meter can
disconnect supply when load breaches a threshold, reconnect after 1 minute and if load is
still above the threshold limit, disconnect supply, generate an event for this action and notify
the “upstream” master (gateway or aggregator or direct head-end about this disconnection
event).
Meter can be configured for load control (example - if load exceeds a threshold demand, say
sanctioned demand, the supply should be cutoff and this action should be logged as an
event).
Meter can be configured for Demand Response events.
Credit balance update for prepayment meters can be remotely configured.
Health and diagnostic monitoring of meters and meter location is configured.
All configurations are initiated via the head-end system. Configurations may be done in the
form of configuration request messages. Feedback on outcome of configuration is expected
to be provided to the head-end which in turn provides report and error logs to the AMI
configurator.
39
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
Scenario #1: Aggregator/Data Concentrator in the middle: AMI head-end provides meter
configuration to the Gateway that in turn manages configuration of its downstream meters.
Scenario #2: Gateway in the middle: AMI head-end configures the meters with the gateway
acting as a bridge. Data acquisition periodicity can be configured in the gateway or in the meters.
Scenario #3: Direct meter: AMI Head-end configures meter directly.
Alternate scenario: In certain scenarios, AMI configurator may also remotely connect with the
data concentrator/gateway and directly configure it or its downstream meters.
Note: several meters may be required to be configured concurrently within a specified time
duration.
Post conditions: Certain configurations are done in the meter while a few maybe done in the
gateway/aggregator. Meter or gateway/aggregator report successful configuration to the
head-end. Failed configuration attempt is notified to the AMI system administrator.
Information exchange: meter parameter configuration details, time of configuration,
configuration messages.
Triggered from Head-end at anytime; bidirectional flow of small data in real-time; high
security requirements. Some configuration scenarios may require priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #3: Scheduled Meter reading:
Actors: Meter, AMI System Administrator, Meter Data Management System.
Prerequisite: Communication link between device and upstream entity is available.It will
have to establish a communication session with the meter for this purpose. Alternately, it
can have an “always on” session with the downstream meter/s.
Precondition: Meter or gateway has been configured previously for the data acquisition.
Trigger: none.
Case #1a: At the predefined instances, aggregator acquires data from its meter/s. Data
acquisition can be initiated by the meter end (push data) or by the aggregator (pull data).
Data from multiple downstream meters is collated at the aggregator end and then sent
upstream to the AMI head-end. Aggregator can apply local intelligence for managing
acquisition failures or enriching the acquired data with location based information. Sending
data upstream to the AMI Head-end and acquiring data from downstream meters can be run
independently (with data acquired from meters being buffered at the aggregator end).
Case #1b: Same as for case of Aggregator, except that gateway does not “analyse or collate”
the data acquired, but simply pushes this data upstream as individual files. Gateway can
or Data from meter is acquired at the AMI head-end application at configured time
instances.
40
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
Data acquisition can be initiated by the upstream entity (pull data) or from the downstream
device (push data) in both these segments.
A 2 step data acquisition process (meter to gateway and head-end to gateway) is popularly
done to optimise the concurrent data acquisition volume at the head-end by reducing the no.
of tail-end nodes. It also helps in optimizing the underlying network infrastructure.
A communication device (modem or gateway) will poll a previously registered electricity
Meter for acquiring data previously stored or current in the meter. It can acquire data from a
single meter or from several meters in its “downstream network”.
After acquiring data from the meter/s, it will establish a communication session with its
upstream “head-end application” to upload the meter reading data. Alternately, the upstream
communication session can be “always on”. The meter data will be uploaded to the head-end
as a file or data stream. Data can be uploaded individual meter-wise or for a set of Meters. It
is assumed that the head-end and Gateway have prior agreement on the list of meters for
which data has to be uploaded. Alternately, Gateway can act as a simple router that connects
meter to the head-end and meter data is then polled by the head-end. Gateway can also poll a
downstream meter for data and then push this data file to the head-end.
In the exception condition of gateway not being able to poll a downstream meter (exhausting
retries), it should record inability to communicate with the meter and notify this to the headend. In case gateway is able to establish communication with meter but not able to obtain
data, this should be recorded and notified to the head-end. Gateway should monitor its last
successful poll of a meter and be able to acquire data from the meter from that instant. In
case gateway is not able to establish connection with head-end (exhausting retries), it should
record this in its memory and push the previously unsent data at the next scheduled upload
instant.
Note: several meters may be scheduled to provide their readings concurrently. Similarly,
multiple gateways may be scheduled to upload data to the head-end concurrently..
Post condition: Data is made available to the head-end at the scheduled instances. Summary
Result of scheduled data acquisition activity is updated at the head-end at each scheduled
instant (success or fail). If required, log of scheduled reading activities at downstream
entities (gateway or meter) can also be uploaded to the head-end periodically or on request.
Detailed Logs are then flushed from the downstream entities. Meter reading data can be
flushed from the gateway/Data concentrator after successful transmittal to the head-end.
This data maybe retained in the gateway if required to perform any local aggregation and
analytics functions. Data from Head-end is provided to a Meter Data Management system
that processes the same further. Reports, error alerts and logs are provided to the AMI
System Administrator.
Information exchange: meter reading data, time stamp, reading process messages.
Triggered from meter end at predefined time instances; primarily upload of data from meter
41
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
end that is delay tolerant. Data size can be small as well as streaming (example - load
profile) according to the data parameters. Normal security requirements. Does not require
priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #4: On-demand Meter reading:
Utility may want to acquire data from a single or a set of meters in between scheduled meter
reading instants. This scenario is same as scheduled meter reading except that the meter
reading is triggered by the upstream entity either due to AMI user request or because
missing data is required from the downstream device.
Example- Meter billing data acquisition is typically scheduled monthly or bimonthly. User
may want to take a billing reading of the meter as a last reading before disconnecting the
supply to the user or before performing a meter replacement activity.
Users for this feature at utility end are typically vigilance team (for monitoring tampering),
O&M team (for monitoring supply quality and reliability), billing team (to obtain meter
billing reading).
On-demand meter reading requests typically have a specific timeout duration within which
the data is expected to arrive.
Information exchange: meter reading data, time stamp, reading process messages.
Triggered from Head-end at any time; primarily upload of data from meter end that has to be
provided within a specified latency duration. Data size can be small as well as streaming
(example - load profile) according to the data parameters. Normal security requirements.
Requires priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #5: Event notification:
Actors: Meter, AMI administrator, Meter Data Management System,Consumer, Utility user
Pre-requisite: Meter to upstream Gateway link is available. Gateway to upstream AMI
Head-end link is available.
Precondition: Meter is configured to detect events and report their occurrence.
Trigger: occurrence of an event is detected by the meter.
Description: Meter can notify the upstream entity of occurrence of the event immediately on
its occurrence or can report a list of all events since last update. The event notification can
be initiated by the meter or gateway/head-end can poll the meter for acquiring this
information. A meter can be configured to detect several types of events. Events can be
classified as critical requiring immediate notification to the upstream entity or can be normal
events that can be uploaded at a fixed interval. As part of event notification, a snapshot of
meter parameters can also be provided. In Indian Power ecosystem, there is a large variety
of “Tamper” events that are typically configured in meters.
42
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
One of the critically important events in electricity meters is regarding power supply status
at the meter location. Meter should report power outage to the Head-end immediately (last
gasp message). Similarly, meter should report restoration of power supply immediately to
the head-end. This helps remote monitoring of power supply status to the consumers, to help
improve reliability of power supply.
Some events are monitored by the gateway/Aggregator/Data Concentrator entity (like meter
link) using local analytics. Example - Aggregator/Data concentrator can collate power
outage or power restoration event messages from all its downstream meters and notify a
single event to the head-end. This not only helps reduce the data volume flow to the
upstream entity, it also helps improve speed of decision making.
Events can also be generated at the AMI head-end level.
Events generated in the AMI system can be further propagated through AMI HES to a Meter
Data Management System for processing, collation and analytics as well as for further
routing to other systems like CRM (for outage reporting), Asset/Maintenance management
systems.
Events can be notified to the relevant users from AMI Head-end level or from the MDM
system. User can be utility staff (example O&M field staff or vigilance team etc.) or
consumer (to notify power outage).
Post conditions: Events are made available at the head-end. Interim entities can flush events
data and event notification activity logs after propagating to the head-end. Some events can
be retained in the aggregator if required for local aggregation/analytics.
Information exchange: meter events data, time stamp, reading process messages.
Triggered from meter at any time; primarily upload of data from meter end that has to be
provided within a specified latency duration. Data size is small. Normal security
requirements. Requires priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #6: Communicate with Consumer over AMI through InHome-Display device:
Actors: meter, consumer, Utility staff
Utility meters, especially electricity meters, are typically installed outside the consumer
premises (in the building common area or on poles outside the home). Therefore, consumers
find it difficult to regularly monitor their consumption by visually reading the meters. InHome-Displays are portable devices that are connected to the meter over a wired/wireless
communication medium and can be used by consumer for monitoring their consumption
from the comfort of their homes. In future, In-Home-Displays maybe rendered on the Home
TV or mobile phone (home automation segment). Consumer can monitor and in some
cases, even remotely control their home appliances through this device for better managing
their consumption. Utility can send important messages to consumer on this device through
the AMI network (similar to message notifications from Dish TV service providers).
43
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
This scenario is described in the Home Automation segment.
Information exchange: messages from meter or head-end.
Triggered from Head-end or meter at any time; primarily southbound data from head-end or
meter that has to be provided within a specified latency duration. Data size is small. Normal
security requirements. Requires priority handling.
Business Scenario #7: Remote Meter Operation:
Actors: meter, consumer, utility staff, AMI system administrator
Pre-requisite: Meter to upstream Gateway link is available. Gateway to upstream AMI
Head-end link is available.
Precondition: Meter is configured to accept remote operation commands.
Trigger #1: User triggered- Utility authorised person (in response to consumer request for
temporary disconnection OR for disconnecting supply to consumers found tampering etc.)
Trigger #2: User triggered – consumer wants to operate their meter remotely using AMI
infrastructure (say from utility website, if utility so allows)
Trigger#3: Utility Revenue system (remote disconnection due to non-payment of dues or
reconnection after pending dues have been cleared)
Trigger#4: Prepayment system initiated on breaching minimum credit balance limits
Trigger#5: for Remote load control (initiated from AMI Head-end)
Description:
Meter receives request for connect or disconnect supply from Head-end (through gateway or
direct in case there is no gateway in the AMI infrastructure). Meter validates the request by
authenticating the requestor credentials. Meter then checks the current status of supply and if
it finds it to be in the requested state already, it reports back to Head-end that no action is
required. Otherwise, meter performs the desired operation and reports outcome of the action
(success). Meter can send an acknowledgement for receipt of command request to the
initiator. Head-end propagates the outcome of the command request to the originator of the
request (user or external system). Remote Switching operation of consumer meter has to be
notified to the consumer on their registered mode of communication (email/SMS) and/or
published on utility portal as a notification for the consumer. These can also be notified to
the consumer on their in-home-display.
This entire flow is expected to be performed in a predefined duration from the instance of
the command request. Meter can be configured to reject command requests that are old (i.e.
received after a long time gap). If requestor does not receive any feedback from meter on
outcome of the command request, it can send an on-demand status update request to meter
in order to ascertain the actual status. It is assumed that a command once despatched from
the requestor to the meter, cannot be cancelled.
Certain meter operations can be initiated locally at the meter itself, based on predefined
triggers in the meter. These are notified to the head-end as events.
Generally, meter operations are priority actions that need to be executed within predefined
44
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
duration.
Post conditions: meter operation is executed and result of the same is provided to the
initiator. Detailed execution logs can be provided to the head-end for post
mortem/performance diagnostics purposes.
Information exchange: messages between head-end and meter.
Triggered from Head-end at any time; bidirectional data exchange between head-end and
meter in realtime. Data size is small. High security requirements. Requires high priority
handling.
Business Scenario #8: Demand Response:
Utilities enroll consumers into a Demand Response program, whereby they can control
consumer demand remotely through their meters during predefined Demand Response
periods. This can be done by cutting off supply to the premise through meter operation in
case it exceeds a pre-agreed demand response threshold (load curtailment upto say 80% of
sanctioned demand). Demand Response can also be implemented by controlling consumer
appliances remotely through a Home –Area- Network system over the AMI (controlling the
load offered by the appliance). Appliance control can be in the form of switching on/off the
appliance. Example - utility may be able to remotely switch off non-essential loads like air
conditioners and washing machines in order to reduce load of the consumer (rather than
switching off supply to the premise through the meter). Utility can control appliance settings
to reduce its load (example – thermostat control of air-conditioners; drier control of washing
machines etc.).
Demand Response schemes help utilities restrict overall system demand during peak
periods, which helps them avoid the need to purchase expensive supply. In our country, it
can also help in avoiding the need for load shedding. Consumers who enrol in such events
can get a tariff incentive from utilities for the same.
A new category of Demand Response aggregators/service providers is emerging in the
country to address this segment. These service providers “enrol” retail consumers and
execute demand response events on behalf of the utilities.
Utility schedules a demand response event for a specific date and time in future. It advertises
the same to its consumers on various communication media (consumers’ registered mobile
phone, email address, utility website – consumer portal etc.). Note – one of the
communication channels can be the In-Home-Display unit of consumers. The demand
response event information covers the expected load relief and tariff concession on offer.
Interested consumers enrol in the scheme by registering for the same on the utility website
or by accepting registration request through their mobile phone/email. A consumer can opt
out of the scheme at any time before the actual start of the event.
Given below is detailed description of call flow for consumers registered for the DR event...
45
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
Actors: meter, consumer, DR Service provider.
Pre-requisite: Meter of enrolled consumers have load control switching capability. Meter
supports DR events. Meter is time synchronised with the overall system.
Preconditions: Consumer enrols for a DR event.
Trigger: Consumer enrolment is notified to the DR administrator user in the utility or at
service provider end and/or to the DR application.
Description:
DR application or administrator remotely configures the enrolled consumer’s meter for the
DR event through the AMI infrastructure (following the configure meter call use case flow).
This covers – configuring the meter for restricting the load to a fixed load value or to a % of
the sanctioned demand of the consumer for the DR period duration. Meter switch is
configured to reconnect after a wait period of say 5 minutes to check if load has been
brought down to under DR threshold. The no. of reconnect attempts by meter before locking
out the supply for the remaining DR event duration is also configured.
When the DR event starts, meter monitors the load consumption and disconnects supply if it
exceeds the predefined DR threshold.
Example – Consumer has enrolled for a DR event for tomorrow from 4pm to 5pm, where
load has to be restricted to less than 80% of sanctioned demand. DR system or DR user
remotely configures the meter over AMI for DR as follows: DR threshold is set to 80% of
sanctioned demand. Meter reconnect wait period duration is set to 5 minutes and reconnect
frequency is set to 3 attempts before lockout. This is set for the time period tomorrow from
4pm to 5 pm. This means that tomorrow at 4pm, meter will start monitoring the total load
and will disconnect immediately when load exceeds 80% of sanctioned load. It will send a
notification of this to the In-Home-Display unit and to the upstream AMI head-end and wait
for 5 minutes. Consumer is expected to switch off some of their appliances to bring down
the load within this wait period of 5 minutes. (Note – disconnection of supply will be
noticed by the consumer and if they are aware that they are in the DR event, they can take
action without waiting for notification from meter). Meter will reconnect after 5 minutes
wait period and if load is less than the DR load, it will remain connected otherwise it will
“trip” again with a notification. It will attempt such reconnections 3 times before tripping
out completely for the remaining duration of the DR event. Once DR event has elapsed,
meter will reconnect on its own. All actions by meter will be logged in its memory for as
well as notified to the utility over AMI and to consumer on the IHD. DR event log can be
uploaded to the Head-end after the DR event is passed. Note- notifications of DR actions
during the event can be propagated to the AMI head-end immediately on occurrence or can
be sent later.
Consumer opts out of DR event. This information is forwarded to the DR administrator/DR
system. System immediately cancels the DR configuration in the meter over the AMI
infrastructure.
46
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
Post condition: Meters of enrolled consumers are configured for DR event. Log of Meter
actions during DR event are uploaded to the DR system through the AMI.
Information exchange: messages between head-end and meter.
Triggered from Head-end at any time; bidirectional data exchange between head-end and
meter in realtime. Data size is small but continuous during DR event duration. High security
requirements. Requires high priority handling.
Business Scenario #9: Remote Over The Air Programming:
Actors: meter, AMI configurator
As applications based on AMI evolve, meter and gateway firmware may need to be
upgraded suitably. Meter firmware may have to be updated in part or in full. The way Apps.
Versions are upgraded remotely when the device is online, similarly the firmware versions
of meters and gateways can be upgraded. However, it is expected that the firmware versions
of all devices deployed in a project get upgraded within a fixed time duration (as system
may not be able to support devices with different versions).
Pre-requisite: Communication link is available. Meter firmware version is maintained in the
AMI head-end database.
Precondition: It is expected that power supply and communication connection between the
meter and the firmware source location is maintained throughout the firmware upgrade
session. Note: can M2M platform support partial download of firmware on the device?
Trigger: AMI configurator may trigger a firmware upgrade for a single meter, set of meters
or all meters in an area.
Description:
AMI Head–end can delegate the responsibility of meter firmware upgrade to the gateways.
In this case, new firmware version is downloaded onto the gateway and it can manage the
firmware upgrade of its downstream meters. Alternately, Head-end establishes connection
with meter through the gateway as bridge for the download. (note- firmware upgrade can be
initiated when the meter establishes connection with the head-end and head-end detects that
meter firmware version is lower than that in the target version.
Firmware version of meter (destination device) is compared with the “target” firmware
version. If the meter version is lower, head-end initiated transfer of the higher version to the
meter. Once the transfer is completed, meter switches onto the higher version. This may
require a power cycling action – that needs to be pre-programmed in the meter (As part of
firmware upgrade logic). After switching onto the new version, meter reports back its new
version to the head-end. Head-end updated the Meter version in the AMI database. If
firmware download is interrupted due to power failure or break in communication link,
47
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
head-end and meter will terminate the download session. Head-end will have to initiate the
download activity afresh when conditions restored. Meter always reports its firmware
version to the head-end as part of handshake activity after power cycling.
There can be several concurrent sessions for firmware upgrades on a set of meters.
Same process applies to firmware upgrade of gateways.
Normal operations of meters/gateway is suspended during a firmware upgrade session.
It is possible that target firmware version may differ across different meters (example APIs
for different make or models of meters maybe different – hence firmware version may have
to be managed accordingly).
Firmware upgrade status and progress log is managed at the Head-end. It is assumed that
there is a master firmware management module that orchestrates firmware upgrade activity
of all target meters in that event.
Firmware upgrade of gateways can be done directly without need to go through the AMI
infrastructure if remote login of the gateway can be taken.
Post Condition: Firmware version in the meter is upgraded and meter is able to resume
operations with the new version successfully. In case a meter firmware is not upgraded
because its link was down or power supply was down or process failed, this will be updated
in the AMI head-end accordingly and error notification sent to concerned user.
Information exchange: data from head-end, messages between head-end and meter.
Triggered from Head-end at any time; primarily large data stream from head-end to meter.
Large data stream. High security requirements. Requires normal handling. All other AMI
processes between meter and Head-end are put on hold during this activity.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #10: Remote Meter Power Supply status:
Monitoring status of power supply at the meter end, helps monitor supply reliability to the
end-consumer.
Actors: meter, utility staff, consumer
Pre-requisite: Meter is capable of reporting a power outage event in the absence of power
supply to it. Here an outage of power supply to the meter is considered as a power outage
event by the meter. Meter time clock is synchronised with the system.
48
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
Trigger:
Meter loses mains Power supply
Meter power supply is restored.
Head-end or gateway initiates a check meter condition request in case meter has not
communicated with head end/gateway for a predefined duration.
Description: Meter power supply change is notified to the head-end immediately on
occurrence. When the power supply connection goes off (due to a power failure or fault)
meter reports loss of power supply to the head-end as a last gasp message. For this, it must
have sufficient battery power. (note – this is not supported in meters operating on PLC
communication mode). Loss of power supply is also recorded as an event in the meter event
log along with time stamp. When power supply is restored, or there is a power cycling event
due to any reason, meter reports back to head-end this event along with snapshot of its
instantaneous data.
For PLC based systems, Gateway can keep monitoring connectivity of meters. If a meter
fails to respond to gateway after predefined no. of retries, gateway notifies head-end about
loss of communication with meter. This can be due to a link failure or because of power
failure at the meter end.
Alternately, head-end can “ping” meter to test its power supply status. If meter responds to
head-end query, it is powered else it maybe out of mains power.
Post condition: Meter status is available at the head-end.
Information exchange: data from meter.
Triggered from meter at any time; small data size. High security requirements. Requires
high priority handling.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #11: Remote Meter health monitoring:
Actors: meter, AMI system administrator
Prerequisite: meter and gateway have self-health monitoring and self-diagnostic features.
Trigger: meter health data can be uploaded to the head-end at scheduled intervals. It can
also be provided to head-end on demand.
Description: Meter conducts self-health checks periodically and records the same in its log.
It can be configured to notify alert health situations to upstream gateway or head-end on
occurrence.
The health log is transferred to the head-end periodically or on demand.
Meter can be designed to perform some self-diagnostic routines for predefined trigger
situations. The self-diagnostic features include monitoring communication link status and
strength etc.
49
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
Gateway can also perform diagnostic tests on its downstream meters and log results.
The health parameters to be monitored include power supply status, communication link
status.
Post condition: health data is made available to the AMI head end from where alerts can be
despatched to concerned users for alarm situations.
Information exchange: same as scheduled meter reading and on-demand meter reading.
Note: this scenario is applicable for Remote Automated Reading applications also.
Business Scenario #12: Remote Meter Time synchronization:
Meter time clock is synchronised with the system reference clock (preferably GPS based).
Meter time is checked by the system and if found out of step, it is updated.
Information exchange: messages between head-end and meter.
Triggered from Head-end or meter at any time; small messages in realtime. High security
requirements. Requires priority handling. All other AMI processes between meter and Headend are put on hold during this activity.
Note: this scenario is applicable for Remote Automated Reading applications also.
6
Actors
1555
Actor Name
Actor
Type
(person,
organization,
device, system)
Role Description
Meter
Device
The meter is the device that measures
and stores the electricity parameters of
interest
AMI Configurator
Person/system
AMI administrator
Person/system
Consumer
Utility Staff
Person
Person
Configures type of data to be acquired,
periodicity of its acquisition and list of
meters from which to acquire.
Monitors the AMI process for error
free operations.
Consumer of electricity
Utility staff are users of the AMI
50
Demand
Response Person/System
Service Provider
Meter
Data System
Management System
system with predefined roles and
access privileges
This person or system configures
meters of DR enrolled consumers for
DR events. DR event notifications and
logs are provided to this person/system
during and post the event.
MDM is the repository of meter
readings. It validates data arriving from
AMI for completeness and accuracy. If
data for some intervals has not arrived
from a meter, MDM flags this to the
AMI Administrator or requests the
AMI to re-acquire this data on-demand.
51
1556
7
Contextual Illustration
1563
8
Potential New Requirements
1564
1565
In future, other utility meters on the premise like water and gas meters may also be
connected to the electricity AMI. Electricity meter will act as the router in this scenario.
1557
1558
1559
1560
1561
1562
52
1566
1567
9
Information Exchange
1568
1569
1570
1571
1572
1573
India has adopted IS 15959 - DLMS COSEM Protocol for smart meters used in distribution
network for Distribution transformers, HT consumers and 11kV feeder meters. It is expected
that the same protocol will be extended to meters in the LT residential segment for utility
AMI facing communication. The meters will have a separate port for communication with
the Home automation systems (for which data protocols are in the process of being notified)
and service provider systems (protocols yet to be notified).
1574
No standard data protocols have been notified as on date for water and gas meters.
1575
1576
10 Architectural considerations (Non functional Requirements)
1577
10.1 Interface Requirements (as applicable)
1578
1579
Source:Overview of sample grid-embedded IPV6 based stacks [14]
1580
53
1581
1582
Meter to Gateway protocols (last mile connectivity) are many a times proprietary.
1583
10.2 APIs to be exposed to the Application from platform
1584
1585
1586
1587
1588
1589
APIs for monitoring and managing the NAN and WAN segments of AMI –wrt
connectivity and desired data throughputs – a Network Management System.
APIs for tracking location of meters and gateway.
APIs for configuring data transfer priority.
10.3 Performance Criteria
1590
1591
1592
1593
1594
1595
Each project in the power sector is expected to have meters of the order of a few lakhs in
nos.
10.4 Interoperability
1596
1597
1598
It is desired that Gateways should be interchangeable in future.
1599
1600
1601
1602
10.5 User Interface
Remote user interface for configuring and troubleshooting the gateways. M2M platform
should support remote IP link for the same.
54
1603
1604
10.6 Communication Infrastructure
1605
1606
Currently prevalent communication technologies in the various AMI segments are depicted in
the contextual diagram.
1607
In the HAN Connectivity requirements are described in scenarios.
1608
Data concentrator should be able to work offline wrt head-end.
1609
10.7 Deployment Considerations
1610
1611
1612
1613
1614
Meters are installed in consumer premises that can be prone to electrical noise interference.
Data concentrators installation may not have good power supply hence battery powering
maybe required.
1615
1616
10.8 Geographical consideration (for geographical spread and concentration
of the constituent devices)
1617
1618
1619
1620
Meters can be widely dispersed or installed in clusters. Data Concentrator units are widely
dispersed.
55
1621
1622
1623
10.9 Security
Data concentrators need to be protected from vandalism. Security requirements are
described in the scenario description.
1624
1625
1626
1627
1628
1629
1630
1631
1632
10.10 Startup Shutdown process
Meter end will register itself with the head-end on each power cycling event (Normal power
on event that can be hardwired or soft power cycling.
Gateway power cycling or restart will trigger meters to register afresh with it.
It is expected that Head-end is operational before the gateway. Gateway is expected to be
operational before meter.
1633
1634
1635
1636
1637
10.11 Data Management
Discussed in scenarios.
10.12 Data Backup and Archiving
Gateway data backup can be taken remotely.
1638
1639
1640
1641
11 Potential market growth
Under the IPDS scheme of the Govt., AMI/RAMR for all Distribution transformers in the
country is likely to be rolled out.
1642
1643
12 Contracts and Regulations
1644
Contracts and Regulations
Impact on Use case
56
EMI/EMC and SAR for Radio
devices
Backhaul network usage –
dedicated bandwidth
procurement or transaction
based
1645
1646
1647
13 Constraints
1648
14 Challenges
1649
1650
1651
1652
1653
1654
1655
1656
AMI systems do not always require continuous online connectivity between the devices.
However, connection needs to be established on demand at any time in order to propagate
critical events data immediately on its occurrence.
The total data volumes per device is not too large –making it unattractive for end to end
cellular communication due to low ARPU realization.
Power, water and gas utilities are critical infrastructure and have therefore generally relied
on dedicated non-shared communication networks. Any M2M communication infrastructure
must have high security and safety measures in place, in order to host any utility application.
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
15 Available Indian Standards
IS13779 Indian Standard AC Static WattHour Meters Class 1 & 2 -Specification
IS 15959: Data exchange for electricity Meter reading, Tariff and load control - companion
standard.
IS 15884 (2010): Alternating Current Direct ConnectedStatic Prepayment Meters for Active
Energy (Class 1 and 2)[ETD 13: Equipment for Electrical Energy Measurement andLoad
Control].
BIS is currently finalizing standards for smart meters for LT applications.
1669
57
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
Bibliography
1. World Economic Forum Report for India, available at:
http:// www3.weforum.org/docs/GCR2014-15/IND.pdf
2. Growth
of
Electricity
Sector
of
India
from
1947-2013,
available
at:
http://www.cea.nic.in/reports/planning/dmlf/growth.pdf
3. India Water Tools, available at: http://www.indiawatertool.in
4. The Indian Express, available at: http://indianexpress.com/article/india/india-others/66per-cent-of-india-still-relies-on-dung-based-fuel-to-cook-un/
5. D. Dubey ,”Issues and challenges in electricity sector in India”, The Business &
Management Review, Volume 5 Number 4, January 2015.
6. A. Pal, ”POWER SECTOR IN INDIA: GROWTH, POLICIES AND CHALLENGES”,
International Journal of Emerging Technology and Advanced Engineering, Volume 3, Special
Issue 3: ICERTSD 2013, Feb 2013, pages 527-536.
7. ANNUAL REPORT 2012-13,available at:
http://cea.nic.in/reports/yearly/annual_rep/2012-13/ar_12_13.pdf
8. 2030 Water Resources Group, ”Charting Our Water Future”.
9. http://water.org/country/india/
10.
CII-2011 report, available at:
http://www.atkearney.com/documents/10192/4693720/India+Luxury+Review+2011+CII++A.T.+Kearney.pdf/e2f622d6-a0b0-4104-91ec-b24013d1e780
11. Industry Group For Petroleum & Natural Gas Regulatory Board,”Vision 2030”.
12. BCC Research, August 2014, Gas Sensors and Gas Metering: Applications and Markets,
http://www.reportlinker.com/p0297997-summary/Gas-Sensors-and-Gas-MeteringApplications-and-Markets.html
13.http://www.navigantresearch.com/
14.www.learningace.com/doc/1944311/.../ee392n_lecture9cisco
58
1710
1711
Document Revision History
Version
Date
Released by
Change Description
Rel 1.0 20150306
6th March,
2015
Principal Author: Bindoo
Srivastava, IIT Bombay;
Release 1.
Contributors: Narayanan
Rajagopal, TCS; Hem Thukral,
ISGF; Raunaque Quaiser, ST
Microelectronics; Anirban
Ganguly, TTSL; Dheeraj Agarwal,
WIPRO; Narang S Kishor, Narnix
Technologies; B S Chauhan,
TSDSI; Nandan Jha, IIT Bombay;
Jayeeta Saha, TSDSI
1712
1713
59