TSDSI-M2M-TR-UCD_Industrial Automation-V0.1.0-20150306

Technical Report

Machine-to-Machine Communication (M2M)

Study on Indian use cases

Industrial Automation

1

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Intentionally left blank to fill information on:

a. Secretariat addressb. Editor with addressc. Chair with addressd. Vice-Chair with addresse. Copyright information

2

2

17

1819202122

23

Intentionally left blank to fill information on:

a. Standard numberb. Standard mnemonicc. Version [for status information]d. Draft date, if not published [for status informatione. Publication date of the standard [for status information]

3

3

24

2526272829

Intentionally left Blank for Abstract

Contents

1. Introduction 2. Purpose 3. Intended Audience 4. Scope 5. Definitions, Abbreviations, Acronyms 6. Use Cases for Industrial Automation

6.1 Overview 6.2 Industrial Automation Application Areas

6.2.1 Utilities 6.2.2 Oil and Gas Pipelines – Cellular Gateways 6.2.3 Smart Building Applications 6.2.4 Automated Yard Management 6.2.5 Renewable Energy Resources – Solar Power Generation 6.2.6 Remote Equipment Management 6.2.7 Other Use Cases

6.2.7.1 Robotic Arms 6.2.7.2 Liquid Flow Management 6.2.7.3 Production Management

Annexure - SCADA

Annexure - Oil & Gas Pipelines Cellular Gateways

Annexure – Smart Building Applications

Document Revision History

4

4

30

31

32

33

343536373839404142434445464748495051

52

53

54

55

56

57

58

59

60

1 INTRODUCTIONCommunication 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.

5

5

61

62

63

64

65

66

67

68

69

70717273747576

777879808182

838485868788

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.

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.

6

6

89909192

939495969798

99100101102103104105

106107108

109110111112113114

115116117118119120

121

122

123

7

7

124

125

2 PURPOSEIoT/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

8

126

127128129130131132133134135136137

138139140

141142143144145

146147148149150

151

3 INTENDED AUDIENCEM2M 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

9

152153154

155

156

157

4 SCOPEThe document gives a brief overview of M2M use case applications in Industrial Automation vertical for India geographical market.

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

10

158159160

161162163164165166167168169170

171172173

174175176177178179

180

5 DEFINITIONS, ABBREVIATIONS, ACRONYMS

M2M Machine to Machine

SCADA Supervisory Control and Data Acquisition

11

11

181

182

6 USE CASES FOR INDUSTRIAL AUTOMATION

6.1 Overview

Industrial automation systems utilize M2M communication to monitor and control remote and local facilities and equipment to increase operational efficiency. Examples of automation equipment can range from simple I/O modules, sensors, Distribution Control systems (DCS), Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs) to Industrial Robots. It is increasingly common to use wireless communication in monitoring applications. Remote service maintenance and diagnostics of machinery and industrial robots is a major application within factory automation and real-time monitoring of remote facilities and equipment are one of the most common applications within process automation.

The idea of the Internet of Things (IoT) has been creating a great deal of excitement in the computing and communications industry for some time. Currently, the industrial automation industry is starting to explore and implement IoT concepts and technology. The IoT vision is of a massively instrumented world of intelligent sensors (analog and digital) and actuators (analog and digital) communicating using IP to improve performance and efficiency. Internet protocol is the primary protocol in the Internet layer of the Internet protocol suite, delivering packets from source hosts to destination hosts solely based on the IP addresses in packet headers. There are a broad range of IoT applications that can be improved with sensing and control, including health care, traffic control, vehicle safety, energy use, agriculture, and manufacturing. This vision includes coupling massive sensing and control with big data and analytics to accomplish advanced levels of optimization and efficiency. Industrial automation has a history of adopting commercial technology as it becomes mainstream, and applying IoT technologies to improve performance and enable better integration with business systems is a logical step.

IoT applied to automation uses this technology to streamline, collapse, and create system architectures that are more affordable, responsive, and effective. The goal is seamless communications and interaction from process industry’s field input/output (I/O), including sensors, actuators, analyzers, drives, vision, video, and robotics, for increased performance and flexibility. This revolution will drive intelligence to the edge of the system with the ultimate goal of all industrial devices supporting IP, including field I/O. Wireless IP devices, including smartphones, tablets, and sensors, are already being used in manufacturing. The wireless sensor I/O open standards WirelessHART, Profibus, Modbus, ISA100, and WIA-PA are all IP devices supporting the latest IPv6 standards, which leverage larger address spaces and improved cybersecurity standards.

The Industrial Internet of Things (IIoT) is believed to transform and reinvent sectors that account for nearly two thirds of the global economy. It can do to the industrial sector what electricity did in the previous century. Currently, IIoT is already helping to improve productivity, reducing costs and enhancing worker safety. Example – at an oil refinery factory, workers wear wireless gas detector that tracks exposure to harmless gases. Factory managers can monitor status,

12

12

183

184185

186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225

location and safety of its workers from a remote control centre. Sensors embedded in machinery continuously monitor their performance, raising alerts proactively for need for maintenance. Workers can control hazardous sites remotely by sending in remotely controllable machines to these areas.

Industrial Automation solutions consists of 3 broad areas – Devices, Infrastructure and Analytics.

DevicesDevices need to be intelligent. That is the starting point. All the devices must to be able to run, collect data, understand their current status or health, communicate with other systems and devices, and react to configuration or operational changes securely. Devices need to be able to run autonomously or as part of a larger system. The devices in Industrial Automation Environment can be broadly classified in to

Sensors: Conventional sensors with added communication features, Wireless sensors etc. Example: Thermal, Voltage, Current, Vibration Sensors, Pressure Transducers Actuators: Devices like valves and robotic arms that control processes based on the parameters fed to them Controllers: Programmable logic controllers with logics implemented to control processes based on measurements received through the I/O modules using the configured parameters. Resulting control outputs drive the processes through the I/O modules.

InfrastructureThere needs to be an infrastructure that supports the devices. The infrastructure is more than plugging in a TCP/IP cable. It contains built-in security and can be adapted for different environments. It has communications, localized storage, remote storage, and data access. A key element of this is the contextual understanding of the data obtained from devices.

AnalyticsAnalytics and optimization are the third component. The infrastructure uses models to transform the data into actionable information. Analytics drive the optimization. The optimization can be either localized or systematic, and it can be manual or automated. The analytics are dependent on the implementation and can run the gamut from using the information to make better, faster decisions all the way to self-healing devices, effectively transforming the information to knowledge. Everything on the IoT must first be capable of operating safely and securely, and then adding business value. The distribution of information is another key element. Having actionable information available is not helpful unless it can be acted on in a timely fashion. This could mean distributing it to individuals inside the organization, other systems in the network, other devices, or back to the device itself. There needs to be an organization to consume the information produced. Too often we focus on the device functionality without understanding the business context. Having information available is, again, meaningless without a purpose. The organization sets the objectives or desired behavior and is responsible for maintaining and validating the status. Too often there are business changes made without realizing the impact on the industrial process control systems. Also, all of the above points need to be achieved cost effectively, or they will not be accepted as required by an organization.

13

13

226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271

A low deterministic latency based communication infrastructure with bounded jitter is the backbone of Industrial Automation solutions.

Industrial Automation applications can be classified in to the following categories based on the nature of application

1. Small Processes – These are controlled by a local PLC. May involve some precision control. For most of these applications remote monitoring will be a requirement though M2M technology. The process is controlled locally and could be partly or fully automated

2. Facility Level Automation: Small and medium industrial Plants, Buildings, Campuses with Distributed Control & Automation. A common facility wide communication infrastructure is used for data exchange and control

3. Automation of Large Infrastructure Processes. Some of the Use Cases overlaps with what has been defined under the Utilities Subsection. Industries like Gas, Electricity and WaterUtilities, Pipeline, Power Plant Control etc. come under this category

The use cases under Industrial Automation can be classified in to following categories

1. Application specific Use Cases – Utilities, Manufacturing, Small, Medium and Large Industrial Processes, Refineries, Transportation and Shipping, Facility Monitoring, Consumables Vending automation etc.

2. Generic Use Cases applicable across application domains such as Device management, Firmware management etc.

6.2 Industrial Automation Application AreasTypical application areas for some verticals are described below.

6.2.1 UtilitiesIn the case of transmission and distribution elements of electrical utilities, Supervisory Control and Data Acquisition systems (SCADA) will monitor substations, transformers, feeders, lines, capacitor banks, breakers, other switching equipment and other electrical assets. SCADA systems are typically used to control geographically dispersed assets that are often scattered over a wide area.

SCADA systems distinguish themselves from other ICS systems by being large-scale processes that can include multiple sites, and large distances. These processes include industrial, infrastructure, and facility-based processes such as 1. Industrial processes include those of manufacturing, production, power generation,

fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

2. Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical

14

14

272273274275276277278279280281282283284285286287288

289

290291292293294

295296

297298299300301302303304305306307308309310311312

power transmission and distribution, wind farms, civil defense siren systems, and large communication systems.

3. Facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. They monitor and control heating, ventilation, and air conditioning systems (HVAC), access, and energy consumption.

A typical SCADA system is described in Annexure_SCADA.

6.2.2 Oil and Gas Pipeline – Cellular Gateways

This use case addresses a cellular gateway to transport oil and gas pipeline data to a backend server, to remotely monitor, manage and control devices equipped in the pipeline (e.g. meters, valves, etc.).

Oil and gas companies can have meters are remote destinations that makes manual monitoring of the state of these meters as an expensive task to be pursued on a regular basis. Automated monitoring of oil and gas pipeline data can streamline the remote monitoring and management of these remote pipeline meters.

When a fault is monitored on specific link of the pipeline network, it is necessary to open or shut the pipeline valve to block the link or to provide detour route. Also, when there is a necessity to change the quantity of oil and gas in pipeline, the valves should be damped through remote control.

This use case is described in detail in Annexure- Oil and Gas Pipeline Cellular Gateways

6.2.3 Smart Building Applications

Smart building is a M2M service that utilizes a collection of sensors, controllers, alerter, gateways deployed at the correct places in the building combined with applications and server resides on the Internet to enable the automatic management of the building with just limited human labour. Smart building system can greatly reduce the cost involved in managing the building like energy consumption, labour cost. With the smart building system, services like video monitor, light control, air-condition control and power supply can all be managed at the control centre. Some services can be triggered automatically to save the precious time in case of fire, intruder, gas leak etc.

This use case is described in detail in Annexure- Smart Buildings

6.2.4 Automated Yard Management

15

15

313314315316317318319320

321322

323324325

326327328329

330331332333

334

335336

337338339340341342343344

345

346347

Automated yard management is an example of WiFi/Zigbee or such wireless technologies for inventory management & placement of material in a yard. Several variation of automated yard management are available where M2M/IoT technology is used in varied context depending on the material in the yard, speed of material movement, inbound marking & QC of the material, material grade management depending on the production cycle or customer demand, and dispatch.

To illustrate we have taken an example of a plywood manufacturing plant with one overhead crane for inbound material movement, internal material movement and outbound material movement on a car/truck. The entire yard is connected over a wifi-bridge or zigbee node devices. In our example we have considered Wifi-bridge as the connecting technology. Backend is remotely located with server infrastructure & monitoring stations.

Stacking Procedure:

The inbound material is notified using a sensor communicating over wifi to the central system. Crane picks it up and takes it to QC bench for QC testing. QC is done on the predefined parameters such as uniformity of thickness and surface monitoring. Based on the incoming material production cycle and/or QC results the material is stacked in the relevant stacks for that quality/customer.

Figure1: M2M/IoT perspective of yard management

Dispatch Procedure:

16

16

348349350351352353

354355356357358359

360

361362363364365

366

367

368

369

370

371

372

373

374

375

376

377

378

Once the demand for that material has come from a client, the relevant quality/customer related material is queued for dispatch. When the truck reaches for loading with customer marked bar code/RFID tag, a trigger is sent to the server for overhead display as well as for sending appropriate information to the crane. Whenever the crane is available (based on priority queuing), the crane will pick up the pre-calculated amount of material of respective marking/grade and loads it into the car/truck for dispatch. The electronic weight measurement machine can calculate the loaded quantity with dispatch number and server is notified to give a go ahead on overhead display.

Additional inputs:

In some cases, collision avoidance technologies such as proximity sensors, alarm, radar, continuous laser distance monitoring is used for avoiding collision of more than one crane. Various types of mechanical gauges/radar or laser distance measurement methods are used for position and placement of the material. In few cases it is seen that the forklifts are mounted with anti-collision devices as well. The central server maintains the inventory stack using a 2-D/3-D map of the entire yard.

6.2.5 Renewable Energy Resources – Solar Power Generation

Solar power generation has seen quite a bit of growth in last 5-10 years. It is seen as a green alternative of the power and at the same time several new solar farms have come up. There have been several cases where the initial work was done manually. Since the installation base is spread over several miles, some of the farms have realized that remote monitoring and alarm based maintenance & repair will have better ROIs and near-real time picture of the performance of their solar farms for increasing cost of operation, maintenance, and reducing yield due to performance degradation during the life cycle of plant equipment. The critical parts which need to be monitored and informed about are

- Weather monitoring such as solar radiation for throughput calculation etc. - Throughput/efficiency or production - Plant Condition (dust, rain etc.)- Maintenance & repair as per need

17

17

379380381382383384385386

387

388389390391392393

394395

396397398399400401402403

404405406407

408

Fig. 9.2 Use of M2M/IoT Technology in a Solar Power Plant

In a solar power plant, it is important to ensure that the plant is working at the highes throughput and highest efficiency while at the same time reduce the maintenance & repair costs to as low as possible to achieve better ROI and low cost of energy. To ensure this, a local weather station is installed with near-real time values of the Solar radiation, weather conditions such as temperature, humidity etc, to calculate the maximum possible power generation.

Any drop in the optimum power generation may be due to additional dust on the surface of a panel or due to any other damage. The central monitoring & control system takes care of the alarm generation to the in-charge/appropriate person in case of any such issue. Further inputs are also received from the inverter, Utility meter that is connected to the grid and plant monetization etc. On the basis of analysis and time-of-the-year, solar radiation & power fed to the grid, an optimum level of operation/maintenance if required can be taken care using minimal manpower.

6.2.6 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;

18

18

409

410

411

412

413

414

415

416

417

418419420421422

423424425426427428

429430

431432433434435436

437438439440

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.

6.2.7 Other Use Cases There are other use cases in this category that are not covered as they follow similar standard flows, with slight variations based on the use of technology. For example, Robotic Arms used in painting of an automobile uses a 3-D diagram of the entire part to ensure uniform paint thickness across all surfaces. Listed below are a few such cases. This is not an exhaustive list as M2M/IoT finds a place in almost entire factory/plant or a industry environment, depending on the approach taken up by that industry.

6.2.7.1 Robotic ArmsUsed for uniform painting of an automobile/consumer good.

6.2.7.2 Liquid (water/chemical) flow managementWith regard to the chemical flow management in various industries for cleaning & enriching of various ores in mining; adding of chemicals in food items; bleaching; preservative addition etc.

6.2.7.3 Production ManagementQualitative and quantitative measures of a production life cycle

19

19

441442443

444445446447448

449450451452453454455

456457

458459460461

462463

464

Annexure- SCADA1 UC_SCADA

1.1 Background

SCADA systems, especially in the Distribution Utilities are moving from use of proprietary networks to using public telecom infrastructure for communication. Presently, substations are evolving to support the IEC 61850 Power Utility Automation set of standards Therefore, it is necessary to have an adaptation layer in the clients to assure interoperability between the technologies used by the actor systems and the operation of SCADA.

The current generation of SCADA master station architecture is of an open system architecture. There are still multiple networked systems, sharing master station functions. There are still RTUs utilizing protocols that are vendor-proprietary. The major improvement is that of opening the system architecture, utilizing open standards and protocols and making it possible to distribute SCADA functionality across a WAN and station LAN.

Open standards eliminate a number of the limitations of previous generations of SCADA systems. The utilization of off-the-shelf systems makes it easier for the user to connect third party devices to the system and/or the network. Another advantage brought about by the distribution of SCADA functionality over a WAN is that of disaster survivability. The distribution of SCADA processing across a LAN improves reliability, but in the event of a total loss of the facility housing the SCADA master, the entire system could be lost as well. By distributing the processing across physically separate locations, it becomes possible to build a SCADA system that can survive a total loss of any one location.

Figure 2: Layers – SCADA

20

20

465

466

467

468

469470471472473474475476477478479480481482483484485486487488

489

1.2 Description

1.2.1 Station Control Center Communication to Remote Terminal Units /Intelligent Electronic Devices / Bay Control Units at EHV, HV and MV Substations

This use case concerns the integration of SCADA systems to field devices to enable collection power grid data at periodic intervals as well as reporting of asynchronous events like alarms in the grid based on detected faults and for automatically controlling operations of actuating elements such as circuit breakers. For that purpose, RTUs are deployed at the substations that communicate with the SCADA Master Control and other systems in the utility DCCs. The RTU accepts commands to operate control points, sets analog output levels, and responds to requests. It provides status, analog and accumulated datato the SCADA master station.

The IEDs (Intelligent Electronic Devices) are connected to conventional sensing and switching equipment to enable digital data exchange. Some of the primary devices can have embedded communicating features enabling them to be configured as IEDs in the system

Depending on the time criticality of the application, the IEDs are capable of communicating at varied data rates with

sampling rates for analog quantities varying from a milliseconds to a second execution cycle time for switching actions in the order of 100ms for distribution

applications and lesser for transmission applications

1.2.2 Central Control Center (Load Despatch Center) Communication to Local Control Center and Selected RTUs, IEDs

Control Center Applications supervise, control, monitor and acquire data from critical infrastructure systems, operate from remote end and ensure security and safety of the grid. The communication is through

21

21

490

491492493494495

496

497498

499500501502503504505506

507508509510

511512

513514515

516

517518

519520521

1. Station Gateway which gathers important control points and measurands and makes it available to the Central Control Center through appropriate communication channels

2. In selected applications and in cases where Station Level Controls are not deployed, set of RTUs, IEDs are enabled to communicate directly to the Central Control Center (possibly through Data Concentrators)

22

22

522523524525526

1.3 Contextual Illustration

Figure 3: Schematic Diagram of SCADA Use Cases

1.4 Scenarios

1.4.1 Updates to Active Displays and Operational Model: When new SCADA data values are received, updates operations model and active displays with new SCADA data values, alarms status changes if required, and logs power system changes. Telemetry systems provide the data in the form of analog measurements, status, or accumulator data from substation, neighboring control center, or fielddevice.Example : Breaker status updates to the Operator Workstation Graphics

1.4.2 Network Operation Transmission / Distribution

1. Network operation monitoring (substation- and network state supervision, logging) 2. Network control (remote or local through field operatives) - Single or multiple

devices controlled separately or through a programmed sequence of operations - Example of sequence of operations is Fault management (supports restoration switching actions)

3. The execution of Control commands will generally have feedback mechanism in terms of:

a. Action confirmed by a status change, measurement value change

23

23

527

528

529

530

531

532

533534535536537538

539

540541542543544545546547

b. Check - Before - Execute actions - which verify certain preconditions and take operator confirmation before final execution of the control

1.5 Common Use Cases across Applications

1.5.1 Data Acquisition –Measurands

Data Acquisition and Measurements are a very generic entity, this specification covers awide range of use cases that involve the transfer of telemetered data to and from a Data Acquisition application. The main difference between the client applications is based on which measurements are of interest.

Description of Data Exchange Mechanism

One-way send: Producer application has implicit or internal knowledge of what consuming applications require. E.g. State Estimator produces array of estimated measurement values for Data Acquisition. This is the same as Subscribe & Notify with the Subscribe stage implicitly defined in the producer application.

Request & Reply: Producer application sends data to consumer applications, based on consumer application requesting data. E.g. State Estimator requests array of analogue measurements. This is essentially the same as a one-off Subscribe & Notify with immediate response.

Subscribe & Notify Changes: Producer application sends data changed since previous request to consumer application. The producer application must maintain a list for each consumer application to identify which data items have changed since the last successful data exchange. When data changes the producer application must scan its interest lists to establish whether any data needs sending. The initial subscription would be followed by an immediate reply of all the subscribed data to synchronize the applications.

Broadcast & Filter: Middleware supports producer application broadcasting events and consumer applications set up filter profiles. Unless there are multiple consumers of many events, this is less efficient.

1.5.2 Data Acquisition – Events

Alarm and Trip / Outage events to be notified to the Operator consoles and other clients according to their criticality. In case of widespread system disturbances several devices will be reporting events - Few protocols used support special algorithms to handle collision to ensure timely reporting of events

1.6 Common Use Cases – Device Management

Use Case Name Use Case Description

24

24

548549

550

551

552

553554555556

557

558559560561562563564565566567568569570571572573574575576

577578

579580581582

583

584

Remote Device Time Synchronization

GPS based time synchronization is used to synchronize - NTP, IRIG-B, PTP -IEEE 1588-2008 have been used in applications depending on the latency requirements. NTP supports 50-100 milliseconds accuracyIRIG B supports 1-10 microseconds accuracyPTP supports 20 -100 nano seconds on TCP / IP Ethernet

Remote Device Health Monitoring

Remote Device Health Monitoring: acquiring remote device self-diagnostic data – on demand or periodically or on predefined triggers.

Remote Device Configuration / Programming - Engineering aspects

Devices such as Controllers, PLCs have programmed logics, assignment on physical I/O s to I/O data set. These are prepared at Engineering phase and periodically updated when there are changes in operations. These need to be downloaded on changes needed and also uploaded to the client for verification purposes when necessary. During the Configuration update - the controller will generally be not be available for operation, hence certain redundancy measures are also taken such as Freezing I/O status for the update duration - but this will be depending on the application

Remote Device Configuration - Parameterization

The devices will have to be parameterized with the right 1. Set points in case of control actions such as PID Control2. Settings for Alarm functions - Analog and Binary levels for triggering action / alarm3. Scaling factors for transducer and sensor measurementsGenerally adopted at Commissioning phase and updated when changes take place in the field devices, processes

Remote Device Firmware Upgrade

Remote device firmware upgrade - Done when the manufacturers introduce new firmware - multiple devices have to be upgraded together generally and will require verifying Configurations and Settings after the upgrade

System Availability

Startup, shutdown, abrupt power outage of a component, recovery of system, recovery of device etc.  

Redundancy measures

SCADA systems have few practices depending on the application for redundancy measures1. Hot standby systems - where a parallel controller also executes the measurements but with its Output getting connected to the Controllable objects only at the time of failure of the Main controller

25

25

2. Master / Slave configurations - where the slave takes over when Master fails 3. certain processes also need Bump less transfer when the Control changes over to new device - this is ensured by functionality in the controllers

26

26

585586

Annexure- Oil and Gas Pipeline Cellular Gateways

2 UC_ Oil and Gas Pipeline Applications – Cellular Gateways

2.1 Description

This use case addresses a cellular gateway to transport oil and gas pipeline data to a backend server, to remotely monitor, manage and control devices equipped in the pipeline (e.g. meters, valves, etc.).

Oil and gas companies can have meters are remote destinations that makes manual monitoring of the state of these meters as an expensive task to be pursued on a regular basis. Automated monitoring of oil and gas pipeline data can streamline the remote monitoring and management of these remote pipeline meters.

When a fault is monitored on specific link of the pipeline network, it is necessary to open or shut the pipeline valve to block the link or to provide detour route. Also, when there is a necessity to change the quantity of oil and gas in pipeline, the valves should be damped through remote control.

2.2 Actors

Oil and gas pipeline meters, valve controllers, cellular networks, backend servers, remote monitoring, management and control software

2.3 Pre-conditions

Cellular network connectivity, Satellite connectivity

2.4 T7riggers

New pipeline sensor data requiring transport to a backend server

Network dynamic access constraint or network utilization constraints or prior network access policy constraints or device energy minimization considerations can cause delay tolerant sensor data to be buffered (and aggregated if needed) at the gateway and transmitted at a later time

Processing of recent measurements can result in remote requests for additional or more frequent measurements

A firmware upgrade becomes available that needs to get pushed to the gateways

27

27

587588

589

590

591

592593594

595596597598599

600601602603

604

605606

607

608

609

610

611612613614

615616

617

2.5 Normal Flow

Sensor data related to oil/gas quantity and quality, pressure, load, temperature, and consumption data is forwarded to backend server that is processed by a remote monitoring service associated with the oil and gas pipeline. Pipeline sensors and pipeline cellular gateways can communicate with each other wirelessly (if sensors and gateways are different nodes in the system). Pipeline cellular or satellite gateways can serve as aggregation points. Sensor data may be locally forwarded until it reaches a gateway or directly transmitted to the gateway depending on proximity of the sensor(s) to each gateway on the pipeline.

Figure 4. Flow - Oil and Gas Pipeline Gateway2.6 Alternative Flow

Pipeline meter data can be stored, aggregated, and forwarded at an appropriate time based on network availability constraints or policy constraints or energy minimization

28

28

618

619620621622623624625626

627

628

629630

constraints for the pipeline meter gateway. Transmission policies can be designed made to minimize network overhead.

29

29

631632

Annexure- Smart Building Applications

3 Smart Building Applications

3.1 Description

Smart building is a M2M service that utilizes a collection of sensors, controllers, alerter, gateways deployed at the correct places in the building combined with applications and server resides on the Internet to enable the automatic management of the building with just limited human labour. Smart building system can greatly reduce the cost involved in managing the building like energy consumption, labour cost. With the smart building system, services like video monitor, light control, air-condition control and power supply can all be managed at the control centre. Some services can be triggered automatically to save the precious time in case of fire, intruder, gas leak etc.

3.2 Actors

M2M Service Provider: A company that provides M2M service including entities like gateway, platform and enables the communication between them. The M2M Service Provider also exposes APIs for the development of all kinds of applications. The gateway provided by the Service Provider can be used to connect to different devices such as sensors, controllers.

Control Centre: The manage centre of the building, all data collected by the sensor is reported to the Control Centre and all commands are sent from the Control Centre. The Control Centre is in charge of the controlling of the equipments deployed around the building.

Smart Building Service Provider: A company that provides smart building services. A Smart Building Service Provider is a professional in the area. It is in charge of install the device all around the building, set up the Control Centre and provide the application that is used to manage the Control Centre and necessary training to workers in the Control Centre on how to manage the system. The Smart Building Service Provider has a business contract with the M2M Service Provider in utilizing the communication, gateway, M2M platform and APIs provided by the M2M Service Provider.

3.3 Pre-conditions

The Smart Building Service Provider establishes a business relationship with the M2M Service Provider in using the gateway, M2M platform and APIs.

30

30

633634

635

636

637638639640641642643644645

646

647648649650651

652653654655

656657658659660661662663

664

665666

The Smart Building Service Provider installs all the sensors, controllers, alerter in and around the building and sets up the Control Centre in the building with the application to run the system.

The Control Centre belongs to an estate management company and takes charge of several buildings all over the city. The building in the use case is one of them.

3.4 Triggers

None3.5 Normal Flow

1. The light control of the building

The Control Centre needs to control the light in the building by different areas and different floors. The Control Centre also needs to switch on and off all the light in the building. For the management of the lights, the Smart Building Service Provider deployed one gateway in each floor to get connection with the lights in the same floor. Each floor of the building has at least 100 lights and the building has 50 floors above the ground and 5 floors under the ground and each light can be switched separately. The lights in every floor is connected with the gateway using local WIFI network, the gateway is connected with the M2M platform using paid 3GPP network, the Control Centre is connect with the M2M platform using fixed network. A patrolling worker with a mobile device can access to the gateway’s local network to switch the lights. The illustration can be seen in figure 6.1

In order to switch the light from the whole floor, instead of sending request from the Control Centre 100 times, the Control Centre creates a group on the gateway of each floor to include all the light on that floor. As a result, the Control Centre could switch the light of a whole floor just by sending one request to the group created on the gateway, the gateway fans out the request to each light to switch them off.

In order to switch the light of the building, instead of sending request from the Control Centre 5500 times, the Control Centre could create a group on the M2M platform to include all the groups created on each gateway on each floor. In this way, the Control Centre simply send one request to the group on the M2M platform, the group fans out the request to the group on every gateway, the group on the gateway fans out the request to each lights to switch it.

31

31

667668669

670671

672

673674

675

676677678679680681682683684685686687

688689690691692693

694695696697698699

The maintenance of the member of the group is the duty of a worker with a mobile device. Whenever a new light is installed, the worker adds the light to the group of the corresponding floor. Whenever a broken light is removed, the worker with the mobile device first searches the light from the group and removes the light from the group.

The Control Centre creates the group in the purpose of controlling the lights, so the group is configured to accept lights only in case the group may cause unexpected result on other devices introduced to the group by mistake. For example, if the type of the group is configured as “light”, then “wash machine” cannot be a member of the group. Because the commands to wash machine is much more complicated. If a wash machine is added to the group of lights by mistake, it may cause unexpected behavior to the wash machine.

The add and remove of the members of the group of each floor is not necessary to be known to the Control Centre, but the Control Centre do know how to switch off the lights from the whole floor. In this way the Control Centre is exempt from the trivial task of maintaining each single light. However in the mean time, the administrator of the Control Centre can always make a list of all the lights and view their status from the Control Centre by retrieving from the group.

2. Intruder

With the deployment of smart building system, the number of patrollers is greatly reduced. For the security reason, a number of motion detector and cameras are installed all over the building.

The motion detector and the cameras are configured to work together. During the period when certain floor of the building is in safe mode, whenever the motion detector detects a moving object, the camera captures a picture of the moving object immediately. The picture is sent to the Control Centre for the inspector to verify if it is an intruder or an automated image recognition system. As a result of fast reaction, the motion detector must trigger the photo shot as soon as possible.

If the inspector sitting in the Control Centre finds that the object captured in the photo is a dog or a cat, he could just ignore the picture. If the figure caught in the picture is a stranger with some professional tools to break into a room. The inspector could send out a security team as soon as possible to the location based on the location reported from the motion detector.

3. Fire alarm

32

32

700701702703704

705706707708709710711

712713714715716717718

719

720721722

723724725726727728729

730731732733734

735

In case of an emergency, the residents of the building need to be evacuated immediately. All the devices related to a fire alarm need to be triggered almost at the same time. Whenever the fire sensor detects a fire in the building, a chain group of devices associated with the fire detection shall be turned on simultaneously such as the siren, the evacuation guide light, start the water pouring system, stop the elevator, cut off the electricity at certain areas, send message to the hospital, call the fireman, in a way not interrupting each other. Due to the possible latency and unavailability on the network to the Control Centre, the trigger of the devices on one floor is configured in the gateway.

If only one fire sensor in one room of the building detects a fire with a range less than one square meter, siren and water pouring system in the room would be switched on to alarm the resident to put out the fire. If lots of fire sensors all detect fire together with smoke sensors, temperature sensors reporting unusual situations, the whole fire alarm system will be triggered and all the residents in the building will be evacuated. If in the mean time of a fire alarm, the sensors detect that the temperature is below the threshold which means the fire is under control, the alarm can be cancelled automatically to all sirens and actuators to avoid the panic.

With the configuration on the gateway, the trigger of the devices can be very fast so that the damage caused by the fire can be limited to its minimum

3.6 Alternative flow

None3.7 Post-conditions

None

33

33

736737738739740741742743744

745746747748749750751752753

754755

756

757758

759760761762763764765766767768769770771772773774775

3.8 High Level Illustration

Figure 5: High Level Illustration of BMS

34

34

776777778

779780

781

782

Document Revision HistoryVersion Date Released by Change Description

Rel 1.0 20150306 6th March, 2015

Principal Author: Narayanan Rajagopal, TCS;

Contributors: Narendra Saini, Sukrut Systems; Bindoo Srivastava, IIT Bombay; Jayeeta Saha, TSDSI

Release 1.

35

35

783

784