TSDSI-M2M-TR-UCD_RemoteAssetManagement-V0.1.0 20150324
Technical Report
Machine-to-Machine Communication (M2M)
Study on Indian use cases
Remote Asset Management
1
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
2
Intentionally left blank to fill information on:
a.
b.
c.
d.
e.
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
Intentionally left Blank for Abstract
Remote Asset Management is perhaps the most common M2M requirement across various industry
verticals. This document briefly describes common requirements across applications from remote asset
management solutions such as:
Asset registration and authentication
Asset location monitoring
Asset remote configuration
Asset presence/availability (with location and time stamped) monitoring
Asset health monitoring
Asset remote diagnostic
Asset remote programming
Remote Asset operation/control
4
1
Introduction .......................................................................................................................................... 6
2
Purpose ................................................................................................................................................. 8
3
Intended Audience ................................................................................................................................ 9
4
Scope ................................................................................................................................................... 10
5
Definitions, Abbreviations, Acronyms ................................................................................................ 11
6
Use cases for remote asset management........................................................................................... 12
6.1
Overview ..................................................................................................................................... 12
6.2
Indian Ecosystem Specifics.......................................................................................................... 13
6.3
Approach ..................................................................................................................................... 13
6.4
Applications................................................................................................................................. 13
6.5
Sensors ........................................................................................................................................ 16
6.6
Actuators/Controllers ................................................................................................................. 18
6.7
Configuration .............................................................................................................................. 18
6.8
Functionalities ............................................................................................................................. 19
Document Revision History ........................................................................................................................ 23
5
Introduction
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.
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.
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.
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.
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.
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.
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.
6
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.
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.
7
Purpose
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.
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.
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.
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.
8
Intended Audience
M2M Platform Solution providers (Solution and Technology Architects), Regulatory bodies and Policy
makers.
Entrepreneurs who aspire to create products/Apps. for deployment on M2M platforms.
Underlying network service providers from various communication technology segments.
9
Scope
The document gives a brief overview of M2M use case applications in Remote Asset Management for
India geographical market. The focus in this document is to identify common asset management
functionalities that cut across various domains.
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.
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.
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.
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.
10
Definitions, Abbreviations, Acronyms
M2M
Machine to Machine
SCADA
Supervisory Control and Data Acquisition
11
Use cases for remote asset management
6.1 Overview
Remote asset management applications are perhaps the most common M2M deployments across
industry verticals. While these applications would be covered in depth in respective verticals, the focus
of this group is to identify common requirements across applications from remote asset management
solutions such as:








Asset registration and authentication
Asset location monitoring
Asset remote configuration
Asset presence/availability (with location and time stamped) monitoring
Asset health monitoring
Asset remote diagnostic
Asset remote programming
Remote Asset operation/control
Current industry focus is on providing end to end solutions for remote asset management. A typical
solution would have the following layers:
Remote Server: Reporting/Analytics
Backhaul Network
Aggregator (RTU)/Controller
Capillary Network
Sensor
Controls
Typically these layers are closely knit through proprietary implementations resulting in loss of
specializations & economies of scale. This document identifies common requirements at each layer &
interfaces for standardization.
M2M applications linked with operations of remote assets are part of specific industry verticals.
However, applications related to asset monitoring and management are considered under Remote Asset
Management (RAM) and covered in this document. Example: At a cell tower, M2M applications related
to operation of BTS equipment would be considered under a specific vertical, but managing the cell
12
tower site with its equipments as assets to ensure that components are recognized and registered in the
system, are operation-worthy and healthy, and can be remotely reconfigured and reprogrammed etc.
would come under the purview of RAM.
6.2 Indian Ecosystem Specifics
While 3G & 4G network penetration is gradually increasing in India, most Remote Asset Management
applications would have to rely upon 2G networks for backhaul connectivity in the foreseeable future.
As it is an emerging market with massive diversity over a vast geography, the stakeholders & their
interests in different applications are quite different from not just to the developed economies but are
also diverse across the country. The relevant requirements would be discussed in specific use cases.
6.3 Approach
The approach is to identify various remote asset management applications and common elements like
sensors & controls and common requirements with respect to configuration & functionality across
remote asset management applications. The various components have been categorized into the
following use case categories:
Different usage scenarios have been identified in each of these categories. The application use-cases
have been typically covered by the different M2M verticals. Commonly used sensors & controls have
been analyzed to understand technology requirements. Common functionality RAM requirements
across verticals have been highlighted here.
6.4 Applications
6.4.1
Cell Towers
The power consumption of assets, energy source utilization, battery health, cooling parameters & asset
health are the typical parameters remotely monitored at a cellular base station site. The objective is to
ensure high site uptime & maintain conducive environment for BTS & transmission equipment operation
while keeping track of energy utilization. For security/theft concerns accurate reporting is more
important than immediate preventive action.
6.4.2
Bank ATMs
Security is the primary requirement & real –time detection of any theft attempt with actionable insights
is critical. Multi-layer detection system based on sensors & cctv is required, with capability for instant
feed retrieval from remote server.
13
6.4.3
Logistics fleet management
Refrigerated trucks is a typical application of Logistics Fleet management. (Other applications have
requirements that are generally a subset of Refrigerated truck fleet requirements). Location tracking,
temperature monitoring for different chambers, door open alarm, goods in/out tracking, alerts on route
deviation & unexpected delays, energy/fuel monitoring are typical requirements of Refrigerated truck
fleet management.
6.4.4
Data Centres
Monitor temperature, energy consumption & operational health of equipments in the Data Centre.
6.4.5
Transport Carriers (Railways, Bus, Taxis etc.)
Location tracking, secure communication link, Message transfer.
6.4.6
Street Light Controllers
Street lights should switch on and off at predefined remotely configurable time instants and/or
illumination levels. Street light staggering & dimming and traffic based switching on lonely stretches
could be other applications.
Street lights maybe centrally monitored for health (detect faulty lights), visibility & availability. Street
lights powered by solar panels need to be monitored for charge status.
6.4.7
Digital Signages
Location specific content display, management of Digital signage as an asset (registration, location, &
health management) would be typical requirements. Content can have static and dynamic information.
Dynamic information can be sent remotely or be updated from a local control unit.
Digital signage content management - remote content upgrade. Content can have a static element and
some real-time dynamic data.
6.4.8
Power Grid Sites (Substations)
Monitor health and operating parameters
6.4.9
Industrial Equipment (Chillers, Pumps etc.)
Remote management of distributed industrial equipment such Chillers, Pumps, Compressors,
Generators, Wind Turbines etc. includes centralized monitoring of operational performance on the field,
remote diagnostics and tracking of mobile assets.
Remote operations monitoring and/or management, operational performance monitoring is the
application (Industrial Automation).
Remote diagnostics and tracking of the asset (its visibility, availability, and health can be covered in RAM
horizontal). Asset connectivity monitoring is also part of RAM (note – not all assets are required to be
14
online all the time). These features are currently considered as part of the specific Industrial Automation
solution.
This improves asset visibility, availability and utilization thus resulting in reduced operational costs.
6.4.10 Oil/Gas Pipelines
Oil/gas pipelines transmit crude oil/natural gas from point of production to processing facilities and
subsequently to point of end use. They are high risk, high value assets in remote locations running into
thousands of kilometres and hence require continuous monitoring to detect leaks, tampering, potential
damage due to encroachment or environmental factors like floods etc. Near real-time visibility enables
the oil/gas companies to respond to any abnormalities quickly to prevent any further damage to the
pipeline or to the environment. This application comes under Pipeline SCADA segment. Remote Asset
Monitoring and Management (visibility, availability and health of the assets is an inherent part of the
SCADA solution).
6.4.11 Storage Tanks
Remote tanks are deployed in various industries to store liquids, solids or gases. Remote tank
monitoring helps in better inventory management, immediate actionable information in case of
abnormalities and optimal re-filling trips resulting in reduced operational costs.
6.4.12 Home Appliances/Equipment
Remote status monitoring of home appliances.
Remote control of appliances (start/stop).
Remote scheduling of appliances to start/stop at a certain time.
Energy consumption insights for the applications.
Aspects of asset visibility, availability and health are an intrinsic part of the main home automation
solution.
6.4.13 Health Care Equipment
Monitor health of the equipment.
6.4.14 Elevators
Remote monitoring enables automated collection of elevator performance and usage data to detect any
issue quickly. The trends allow better visibility of degradation of performance, if any and identify any
potential issue to readjust the equipment maintenance cycle. This results in improved uptime of the
elevators.
15
6.4.15 Forests/Protected Environment
Remote monitoring of forests could help in early detection of forest fires which thus can be quickly
brought under control. It also enables prevention/detection of cutting of high value trees and
movement of animals in the forest environment.
6.4.16 High Value Structures (ex. Bridges)
Critical and remote infrastructural assets like bridges have to comply to rigid safety demands. These
structures may have to bear harsh environmental and operational conditions throughout their expected
life which is ever increasing. This calls for continuous monitoring of the structures for cracks,
movements, vibration etc. which might indicate a potential problem. Remote monitoring enables
remote gathering and analysis of this data which reduces overall cost of inspection, maintenance and
repair.
6.4.17 Utility Meters
Management of utility meters (visibility, availability and health) is currently treated as an inherent part
of the AMI/AMR solution.
6.5 Sensors
Sensors can be classified into 3 categories:



passive
intelligent
smart
We have listed few commonly used sensors in remote asset management applications:
Sensors
Description
Temperature Sensor
The temperature sensor measures
temperature ranges inside a cabinet
or equipment room, or the
temperature of a specific component if applied directly to
that component.
Humidity Sensor
It measures relative humidity
level in one compact device. It
can be integrated with RTU
seamlessly.
Smoke sensor
It monitors the presence of smoke
and/or fire. When detected, it sounds
16
an alarm and sends analog signals to
RTU for remote sensing through
UDMP central server.
Air Flow Sensor
The air-flow sensor will indicate via
a contact closure if the airflow of a
fan goes above or below a
threshold. This is useful for determining the loss of AC to
server and equipment rooms.
Water Sensor
Use this device to detect water
accumulation or leakage. When
water or water-based fluids come
into contact with this device, it signals by closing its
contact outputs.
Power Sensor
Measure Voltage, Current and Power in AC/DC power
systems. Select from a wide variety of powermeasurement sensors to fit your needs. Attaching them to
RTU to detect and correct site power problems early.
Power sensors can be used to monitor Battery, DG, Wind,
Solar Equipment etc.
Door Sensor
The door sensor indicates
the opening or closing of any
door, window, access lid, or
cover upon which it is
installed. There is also possibility to remotely control
lock/unlock state of gate through relay output of RTU to
sensor.
Fuel Level Sensor
Fuel sensors monitor the tank’s fuel level and measure
fuel usage by replacing the standard mechanical fuel level
gauge with a more capable electronic one. RTU can be
integrated with complete line of fuel sensors that allow
17
you to collect daily or even hourly
statistics to help you schedule tank refills
and establish billing.
Battery State of Charge Sensor
Hall Effect Sensor
Fuel level Sensor
Location (Lat/Long)
Measure latitude, longitude and altitude of the system
Magnetometer
Acceleration/Motion/Vibration/Tilt
Measure dynamic acceleration on a single axis, two or
three axes
Measure movement, vibration and tilt
Luminosity
Measure ambient light in terms of lux
Combustion gases - CO,CO2
Detects presence of CO/CO2 in the surrounding
environment. Measures the concentration in parts per
million
Liquid flow
Measure rate of fluid flow
Proximity
Detects presence of nearby object. Reports information in
binary form i.e. object present or object absent
6.6 Actuators/Controllers
These are devices like valves, robotic arms, switches. These can operate automatically or on command
from controller.
6.7 Configuration
This covers:



One time initialization configuration: This can be done in factory; onsite at the time of
installation OR remotely before activating the asset.
Operational parameters configuration - Run time settings. This can be done in factory; on site at
the time of installation or remotely before activating. This can be modified onsite or remotely.
Threshold/Trigger point configurations – this is generally done onsite or remotely. It can be
modified onsite or remotely.
18
6.8 Functionalities
6.8.1
Registration & Authentication
Detect or acknowledge presence of a new asset in the field. This asset may be configured in the system
and is therefore a "Valid" asset or it may be a "new" asset that is still to be configured OR a "Strange"
asset that is not meant to be configured in the system. Example - system detects a new meter # that got
installed in the field but not yet configured in it. Here the system does not "Actively" look for the asset,
but is notified of its presence. Example - a new SIM card that "pops" up in the network is detected.
Discover an asset that is preconfigured in the system. Here, the system actively looks for the particular
asset.
Authenticate the asset by validating its actual location and other parameters with expected
location/parameters. This may be required after every power cycling event of the asset/system.
Register the asset into the system after validating its authenticity. This may be required after every
power-cycling event at the asset/system.
Assets could be “business” assets like transformer/C.B./RMU/Digital signage/RMU; system assets like
meter/gateway/transducer/ RTU/DCU
6.8.2
Asset location management
Asset geographical time based tracking
Asset proximity sensing - detected through RFID locator or NFC/bluetooth.
Some assets are stationary like meters, cell towers & ATMs but some assets are mobile - like hand-heldunits/meter reading instruments etc. therefore location monitoring has a time element.
Asset proximity locator - Previously geotagged devices should pop up when they are within
communication range. Example- Walkby meter reader where the meter reading instrument carried by
the meter reader is able to detect meters in the vicinity over bluetooth/WiFi and then perform remote
meter reading. Another example - radio cabs locator.
Asset geo-fencing: Monitor location of asset and raise alert in case it crosses a predefined geo-fenced
area. Example - pet animals straying out of designated "Safe" areas;
Asset network location if applicable (example of network location of a meter in the electrical network (is
it on feeder or Distribution transfomer or on consumer end?).
Asset maybe linked to a local communication module (that may have an IP) and a SIM card. Maintaining
integration mapping of device (example meter) to communication modem (if applicable) to SIM no. (if
applicable) to IP # to the GIS location marker (example GIS coordinates).
6.8.3
Asset presence check & health diagnostics
Monitor the asset (example - loading condition of a distribution transformer,
19
Monitor "health" of the Asset - example its power supply/battery status, communication signal quality
etc.
Diagnostic monitoring of asset - example: if an asset is not communicating, perform remote
troubleshooting of the asset. Following functionalities maybe required:



6.8.4
Remote diagnostic
Remote programming
Remote operation/control
Data accumulation
Various types of data can be captured from the asset as follows Asset location data – especially for mobile assets to track their location
Asset usage data – the period for which asset has been used
Asset status/operating data – for monitoring of health and performance of an asset
Asset environment data – monitor environment data like temperature, humidity etc. around the asset.
This is important for some assets e.g. perishable assets like dairy products for which maintaining a
proper ambient temperature during storage and transit is of utmost important
6.8.5
Aggregation & Transmission
Transmission of the collected/aggregated data to a remote centralized location for analytics and
visualization.
The data could be sent by an asset directly to the RAM application or aggregated for a number of assets
by a gateway and then sent to RAM application.
6.8.6
Data Analytics & Insights
6.8.6.1 Alarm/Event notification
Ability for a user to define rules against which the asset data may be continuously validated to flag any
alarms or events. The validation can happen on real-time or historic data. The rules could be defined in
the RAM application or on the edge close to the asset e.g. on the gateway.
The rules could be to detect a threshold being exceeded to take an appropriate action or it could be
some action based on changing state of an asset. Multiple parameters may be correlated to come up
with an actionable event.
Alarm/event notification could be done using SMS or email etc.
6.8.6.2 Operational Analytics
Static information about assets e.g. asset ID, asset type, owner etc.
Trends – Time series trends of the operating parameters of the asset. Detect patterns and anomalies.
20
Key performance indicators – Monitor current asset performance e.g. Overall Equipment Effectiveness,
Energy consumption etc.
6.8.6.3 Predictive Analytics
Optimization – Compute optimal decision based on the sensor data and the defined system constraints.
For example, predicting optimal route for vehicles in a fleet , optimal route maintenance personal to
reach a remote asset, optimal maintenance schedule for a fleet instead of unit-based maintenance to
reduce overall operational costs
Condition based maintenance/predictive maintenance – use of operational data to predict failures and
schedule maintenance accordingly. Also, predict remaining useful lifetimes (RUL) of equipment
Recommendations – context aware recommendations. E.g. promotions/offers on digital kiosks based on
user browsing, context aware promotions/information on products etc.
6.8.7
Remote device management
Remote over the air firmware upgrades of the asset
Remote configuration of the equipment e.g. sampling interval, threshold etc.
Bulk provisioning and configuration
Remote SIM management if an interface is provided to CSPs SIM management platform e.g. SIM
activation/deactivation, SIM data usage information etc.
Remote diagnosis
6.8.8
Integration with Enterprise Systems
The sensor data and related analytics results from the asset may need to be transferred from the RAM
to other Enterprise IT systems to trigger business workflows. Following are few examples
Ticketing systems – Alerts from RAM could trigger automated generation of trouble tickets in a ticketing
system
Spare parts Inventory – Predictive maintenance information could be fed to inventory system to ensure
availability of spare parts on time
Product Engineering IT systems – Asset usage information data may be integrated with product
engineering systems to give an insight on how the asset features are being used by end users. This may
provide inputs in deciding asset roadmap
6.8.9
Security
User authentication –through a login and password validated against a user database stored in the RAM
application or interfacing with an external Identity management system
Role based access control – Ensure that access to the asset data and operations on the asset/data will be
based on the authority and the responsibility pre-defined for a role which is assigned to a user e.g. Only
21
Administrator role can configure the assets or regional offices can only view assets operating within
their region.
Data Integrity and Confidentiality – Protect data at rest and data-in-transit. The data stored on the asset
could be encrypted if required.
Strong encryption mechanisms between communicating systems to ensure a secure data transfer.
Support for secure connectivity with assets which could be behind firewall
Audit trail – Maintained for user actions for traceability
6.8.10 Remote Equipment Management
Geographical spread of install based of equipments is generally difficult to manage. For example, remote
agriculture pump, submersible water pumps, utility substation, power banks, telco-tower sites or at
times medical units or industrial/plant equipments (AC/Refrigerators etc.). They are generally installed
where the resident population is less, no population area or in case of medical/consumer equipments
technically less literate population.
It is therefore, it becomes extremely important for such remote assets to be monitored from central
monitoring units. Some of the cases also come into the possibility of remote monitoring as well as
control, or complete remotely managed equipments. Some of the important aspects of remote
equipment management are;



Throughput/efficiency or production level monitoring
Condition Monitoring
Maintenance & repair
M2M technology can help tremendously and has provided several successful use cases where such
implementations have been made. Remote windmill/windturbine and substation automation are
successful example of Remote equipment management using Remote Terminal Units (RTU) with
analog/digital interfaces for sensing & digital interfaces for actuation with cellular/non-cellular mode of
communication.
22
Document Revision History
Version
Date
Released by
Change Description
Version 0.1.0
20150324
24th March,
2015
Principal Author: Rushabh Shah,
Panchsheel Research;
Draft Release
Contributors: Anuj Ashokan, TTSL;
Mandar Patankar, TCS; Vaibhav Vijay,
Teramatrix; Bindoo Srivastava, IIT
Bombay; Jayeeta Saha, TSDSI
23