Demand Response: From Utilities to Smart Cities

Introduction

1Demand response (DR) is an important tool deployed in

electricity markets to overcome temporary real-time mismatches

in supply and demand. In a typical DR event, a utility suppresses

short-term demand by offering incentives to users to avoid more

expensive supply expenditure. In other words, the utility elicits a

response (reduced consumption) from the demand side using a

signal, economic or otherwise (for instance, an incentive per unit

of energy reduced).

A similar behavior is seen with cab aggregators that use surge

pricing to both reduce demand and potentially increase supply.

Another example is the use of different charges at different times

of the day by hyper-local last-mile services delivering food on

demand. Generally, DR is most useful when increasing supply is

not viable and demand needs to be managed instead.

Can we apply the DR paradigm to other scenarios? Let us

consider the example of smart cities. Smart city programs

typically aim for excellence in citizen experience while availing city

services. But even the best IoT-enabled infrastructure in a smart

city can come under stress during short periods of peak demand.

An example would be the strain on public transportation during

periods of peak citizen engagement, such as a fireworks display.

One might argue that smart services during normal operations

increase the expectations of citizens, who then feel let down by

poor experiences during peak demand periods.

Can DR be of help here? DR can be thought of as a ‘horizontal’

smart city service that cuts across multiple ‘vertical’ citizen

services to ensure the best city-government service, even during

peak demand. For example, a smart city can move citizens to and

from mass public events in a controlled way by incentivizing them

to choose alternative paths or stagger their travel. This would

improve the citizen experience and help the city avoid

infrastructure investment that is justified only during peak

WHITE PAPER

WHITE PAPER

demand. The city-government thus acts as an aggregator that

can handle peak demand for its offered services.

This white paper explores the role of DR in improving citizen

services in a smart city. We will present a simplified DR

architecture and explore possible use cases; we will also illustrate

this with a hypothetical situation. We will present a sequence of a

smart city operation that includes DR and conclude with some

suggested approaches in realizing DR for smart cities.

Architecture for DR

An aggregator connects the supply side to the demand side,

operating on two timescales: short term and long term. In short-

term operations, the aggregator collates the real-time supply and

the constraints at a given time and over the entire duration of the

operations. For example, a cab aggregator knows the number of

vehicles available across a city. The aggregator would also know

or forecast the demand at any given point.

Depending on the demand and supply, the aggregator can

present offers at ‘normal’ prices or try to reduce the demand by

increasing real-time prices (for a taxi) or offering incentives (to

electricity consumers). The guiding principle in this optimization is

the business objective: revenue/profit and customer satisfaction.

The algorithm should factor in demand requests and supply

availability.

In long-term operations, the aggregator can try to predict the

typical demand as a function of environmental parameters (for

example, time of week, weather and road conditions) and could

also learn the sensitivity of the demand side to price or incentive

signals. These longer-term learned models can be used by the

aggregator to optimize the supply and demand in real time.

In addition, regulatory requirements and preferences might need

to be reflected in the aggregator’s decisions, even if it is in

conflict with the profit goal. For example, a cab aggregator would

like to increase supply of cabs in a congested area with high

demand while the regulator (city-government) might want exactly

the opposite. Therefore, a DR architecture should consider

regulatory constraints that affect decisions.

WHITE PAPER

Use Cases in a Smart City

Figure 1 illustrates the use of DR in multiple domains in a smart

city. For each domain, we provide examples of the components

proposed. We observe that the possible application of DR

constitutes a diverse spectrum of domains, with the goods and

services being both discrete in time and space, as well as

continuous, like in the case of electricity.

Domain Electricity Parking Healthcare – Epidemic Management

Mobility

Supply side Utility provider Private/Public parking provider/owner

Healthcare professionals

Cab operators, public transport providers

Aggregator Ancillary service providers

City authority or a private company

City administration/government

City transport authority

Regulator Utility/Electricity regulator

City administration/government

City administration/City government

City administration/government

Demand side Consumers Drivers Citizens Commuter

Goods/Service Uninterrupted supply

Adequate parking Vaccination for all Multimodal journey/trips

Figure 1: Examples of DR in a Smart City

Let us take a specific use case, focusing on mobility as a primary

service and exploring how the demand response paradigm can be

applied here. For this example, let us assume that the city offers

all smart services through a platform. Citizens can access services

in the healthcare, utilities, transport and e-government domains

by logging on to the smart city platform.

For the sake of illustration, let us take the case of a citizen who

subscribes to mobility services — which could include notifications,

route planning and offers — through this platform and wants to 2

plan a trip from point A to B. The mobility services section of the

smart city demand response platform will perform the following

actions:

1. Accept the citizen’s trip demand, which consists of the origin

and destination, along with preferences such as pick-up time

2. Retrieve supply side info from transport aggregators

3. Calculate the supply levels using own data and data from

transport aggregators

4. Match the supply and demand resources

5. Learn from preferences based on its info on the citizen

WHITE PAPER

6. Process the demand and suggest travel plans to the citizen

with additional travel choices – offering discounts/coupons to

manage demand surge

7. Use the data for future learning

Demand Response Module in Mobility

Services

With the above details, let us do a deep dive using an illustration

of the experiences of two New Yorkers – Tom Peters and Greg

Allen. Let us say they want to go from Times Square (point A) to

Wall Street (point B), and access the mobility app on a Sunday

requesting options for 8 am on Monday. Once the request is

placed, the sequence of events that the demand response module

will start performing is illustrated in Figure 2.

Smart citizen

(Greg and Tom)Ride

requestDemand

store

Processingdemand

Load historical trip data (Tom

and Greg)

Load user-specictransport model

Aggregate current tripdemands

Predict transport

mode for Greg and Allen

Fetch supply options

Transportoperators

Matchdemand and

supplydata

Determine transport on live

dataDemand response recommendation algorithm

Demand > Supply YESNO

Tom and Greg selection

Offers (example, discount price at different time)

Predict nal transport mode and price

Appendhistoricaltrip data

1 2 3

4

5a5b 6a 6b 6c

6d5c

7

88a8b 9

10

11

12

Figure 2: Demand Response Module for Mobility Services

The key steps are listed below:

1. The details of the requests by Tom and Greg in terms of

source, destination, timing and trip preferences are captured

2. Historical requests are retrieved for the two citizens. The

objective is to learn their travel patterns based on historical

data

WHITE PAPER

3. The prediction model built inside the platform takes the

historical demand requests by Tom and Greg into account to

come up with a possible prediction in terms of transport

preferences. This prediction is certainly a candidate for deep

learning neural models or machine learning classification

models

4. The prediction output of the model is saved for further

consideration

5. The platform will also now analyze requests from other users

in terms of pick-up time, destination and location, along with

various other factors such as airport trip, rush hour, day of the

week, weather patterns, user’s preferred travel mode

(bus/train/taxi) and travel preferences in terms of time or price

6. It gathers supply information from its own inventory or looks

to transport aggregators for the best possible options for a trip

between Time Square and Wall Street

7. For further mobilization of available resources other than

inventory, during the period of demand spikes, the platform

also makes requests to suppliers or master aggregators.

Master aggregators in this context would be the bus

companies, train systems or taxi operators, from whom trip-

specific information such as bus numbers, train numbers, taxi

options and estimated time of travel will be sourced

8. The transport aggregators will provide information on the

availability of supply

9. The platform will now match the demand and supply resources

and decide the possible mode and price of the transport

options

10.Based on user preferences and supply/demand resources, it

will finally come up with recommendations in terms of

coupons/discounts and provide this information to the citizen

to manage the demand surge. Also, it will propose a premium

price for the route given the demand surge

After executing the above options, the demand module could

present Greg and Tom with the following options.

n Bus T2A from Times Square to Wall Street; estimated travel

time 30 minutes; $2.75

n Subway from Times Square to Wall Street; estimated travel

time 20 minutes; $2.75

WHITE PAPER

n Taxi operator 1 from Times Square to Wall Street; estimated

travel time 40 minutes; $8 at 8 AM

n Taxi operator 2 from Times Square to Wall Street; estimated

travel time 20 minutes; $4 at 7.30 AM, including a 50%

discount (recommended)

The module not only presents options at the preferred pick-up

time, but also highlights better deals around that time after

considering available offers and the user persona.

Tom and Greg may accept the discounted offer for a different

time or pay a premium to travel at 7.30 am. If Tom accepts the

offer, the DR module will apply specific discounts as per available

contracts with suppliers. In case Greg does not accept the offer,

he will pay a premium price for his travel at 8 am. Once Tom and

Greg make their selections, their requests will be appended to

their travel histories for further learning.

At a high level, the DR module aggregates user demands and

supplier choices, applies contractual discounts on the supplier

choices and finally, based on user preferences, provides multiple

choices to those who subscribe to the mobility app. The DR

module is able to provide such recommendations by solving an

optimization problem – matching supply and demand in real time

with demand and supply constraints. Machine learning techniques

can play a significant role in this optimization process, especially

in predicting real-time series demands. In the prediction of time

series demands, the deployment of recurrent neural networks like

LSTM can bring significant results in terms of the predictive power

of what future demand will look like.

Applying DR to Real-world Challenges

DR is an important tool to handle scale and efficiently manage

real-time supply-demand mismatches. This approach is common

in the energy domain, and we believe it is applicable for smart

city services as well. To implement DR in real-world systems, the

models must learn from past data or realistic simulations so that

the alpha/beta phases of deployment can be faster.

Some suggested approaches to implementing a DR system for

smart cities:

1. Set up and build a simulation-based environment of a domain.

For example, in the use case mentioned in this paper, a

mobility environment that can be the basis of any ML or RL

approaches for designing the controller. The simulation will

WHITE PAPER

involve logging the multiple requests at different times – and

even future day and times – by citizens wishing to travel from

place A to B. The simulation should be a faithful model in

terms of the underlying distributions of the data generated.

2. Calibrate or design the behavioural response models on the

demand side. For example, in the use case given above, trip

requests would be the behavioral response. This would require

some research on current demand trends.

3. Build scalable algorithms for matching supply and demand in

real time with efficient management of constraints. This is the

optimization problem that the DR system is intended to solve.

In the example given above, the optimized route does not

necessarily have to ensure only shorter travel time; a travel

mode with a discount could be just as relevant. The algorithms

need to maintain optimal performance even when faced with

hundreds of thousands of trip requests. The supplier network

must be robust.

4. We have approached DR from a citizen-centric approach.

However, the approach must balance the benefits to all the

stakeholders. In the case of third-party suppliers, the

aggregator must demonstrate an increase in revenue to make

it attractive for them to sign up to the platform.

5. The approach should incorporate trade-offs between system

efficiency and data privacy.

6. Provide adequate incentives to citizens to manage demand

constraints.

References

1. IEEE; Demand Response in Electricity Markets: An Overview; June 2007; accessed

Sep. 2019; https://ieeexplore.ieee.org/abstract/document/4275494

2. arXiv.org; Managing travel demand: Location recommendation for system efficiency

based on mobile phone data; Oct. 2016; accessed Sep. 2019;

https://arxiv.org/pdf/1610.06825.pdf

All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties. Copyright © 2019 Tata Consultancy Services Limited

About Tata Consultancy Services Ltd (TCS)

Tata Consultancy Services is an IT services, consulting and business solutions

organization that delivers real results to global business, ensuring a level of

certainty no other firm can match. TCS offers a consulting-led, integrated portfolio

of IT and IT-enabled, infrastructure, engineering and assurance services. This is TMdelivered through its unique Global Network Delivery Model , recognized as the

benchmark of excellence in software development. A part of the Tata Group,

India’s largest industrial conglomerate, TCS has a global footprint and is listed on

the National Stock Exchange and Bombay Stock Exchange in India.

For more information, visit us at www.tcs.com

TCS

Des

ign

Serv

ices

M

09

19

II

I

WHITE PAPER

Contact

Visit the page on Research and Innovation www.tcs.com

Email: innovation.info@tcs.com

Blog: #Research and Innovation

Subscribe to TCS White Papers

TCS.com RSS: http://www.tcs.com/rss_feeds/Pages/feed.aspx?f=w

Feedburner: http://feeds2.feedburner.com/tcswhitepapers

About The Authors

Ramesh Balaji

Ramesh Balaji is a senior data

scientist, with a focus on smart

cities (understanding the interesting

patterns of smart people through

machine learning techniques) and in

assisted living (understanding the

activity patterns of the elderly

through data and image recognition

patterns). He holds a master's

degree in computer engineering

from California National University

for Advanced Studies, USA.

Arun Vasan

Arun Vasan is a principal scientist

with TCS R&I, where he works on

cyber-physical systems. He obtained

a BTech degree in computer science

and engineering from IIT Madras,

India, and an MS and PhD in

computer science from the

University of Maryland, College Park,

USA. He has served as visiting

faculty at IIT Madras and as a

reviewer for several conferences and

journals. His current research

interests are in analytics for

intelligent infrastructure, with a

focus on energy and mobility.

Srinivasan Raghavan

Venkatachari

Raghavan is the head of the digital

citizen program within the TCS

Research and Innovation (R&I) unit,

with a focus on creating research-

led business offerings for citizen-

centric smart cities. He holds a

bachelor’s degree in computer

science and engineering from

IIT Delhi, India, and a master’s

degree in aerospace engineering

from IIT Madras, India. He is a

senior member of the ACM.

Arun Vijayakumar

Arun Vijayakumar is an enterprise

architect with TCS R&I. With over

20 years of IT experience in

enterprise architecture and smart

city consulting, he presently works

on the digital citizen and connected

social systems research programs,

handling the architecture of various

solutions and research projects

within these programs. Arun holds a

master’s degree in applied statistics

from the University Campus,

University of Kerala, India, with

computer application and operations

research as his specializations, and

an MBA in operations management

from the University of Madras, India.