Surging to a Smarter Future · 8.4. Training Need Assessment and Content Development 66 8.4.1....
80
www.pwc.com World Bank Surging to a Smarter Future Detailed Project Report for World Bank “ICT Enabled Integration for Green Growth” June 2016
Transcript of Surging to a Smarter Future · 8.4. Training Need Assessment and Content Development 66 8.4.1....
www.pwc.com World Bank
Surging to a Smarter Future
Detailed Project Report for World Bank
“ICT Enabled Integration for Green Growth”
June 2016
PwC 2
Table of Contents
1. Overview 4
1.1. Sectional Overview 4
1.2. Intended readers 4
1.3. Approach adopted for the document 4
1.4. Executive Summary 5
1.5. Objectives of the Project 6
2. Shimla – City Profile 7
2.1. City Snapshot & Projection 7
2.2. Geographical Overview 8
2.2.1. Climate and Rainfall 8
2.2.2. Land Use Pattern 8
2.2.3. Tourism and Industry 9
2.2.4. Industrial Scenario 9
2.2.5. Economic Features 9
2.3. Existing Scenario 10
2.3.1. General 10
2.3.2. Source 10
2.3.3. Distribution System 12
2.3.4. Service Coverage 12
3. Design Considerations 14
4. Water Value Chain 16
5. Architecture& Solution Elements 19
5.1. Water Collection and Treatment 19
5.1.1. Architecture of Water Distribution System Automation 19
5.1.2. Detailed analysis of Process Monitoring and Control 20
5.1.3. Detailed Analysis of Plant Wide SCADA 24
5.1.4. Detailed Analysis of Plant Automation 41
5.1.5. RTU’s for Distribution & Intake networks 46
6. Estimated Cost 54
6.1. Summary 54
7. Service Level Agreement 56
7.1. Purpose of this Agreement 56
7.2. Problem Severity Levels 57
7.3. Breach of SLA 58
7.3.1. Monitoring and Auditing 58
7.3.2. Reporting Procedures 58
PwC 3
7.3.3. Issue Management Procedure 58
7.3.4. Change Management: 59
7.3.5. Service Continuity 59
7.3.6. Security Management 59
7.3.7. SLA Change Control 59
8. Capacity Building and Change Management 61
8.1. Need for Change Management 62
8.1.1. Identification of Stakeholders 63
8.1.2. Description of Roles and Responsibilities 63
8.1.3. Participation by Stakeholders 64
8.2. Staffing and Deployment Strategy 64
8.2.1. Staffing and Deployment Plan 64
8.2.2. Staffing and Deployment Process 65
8.3. Training Strategy 66
8.4. Training Need Assessment and Content Development 66
8.4.1. Capacity Building 66
8.4.2. Training 66
9. Monitoring and Evaluation 68
9.1. Monitoring and Evaluation Framework 68
9.1.1. Clearly Defined Objectives 69
9.2. Define Organization’s Roles and Responsibilities 69
9.3. Approach for Monitoring and Evaluation Process 69
9.3.1. Monitoring 69
9.3.2. Evaluation 70
10. Assumption and Risk Management 73
10.1. Process for Risk Assessment 73
10.1.1. Risk Identification 73
10.2. Risk Mitigation Strategy Based on Risk Evaluation Matrix 74
10.2.1. Risk Mitigation Strategy based on Risk Evaluation Matrix 74
10.3. Risk Monitoring 74
11. Project Implementation Strategy and Sustainability Plan 75
11.1. Stakeholder’s Involvement 75
11.2. Tendering and Bid Process Management 75
11.3. Project Implementation Strategy 75
11.4. Project Phasing Strategy 76
11.4.1. Exit Plan 76
11.5. Sustainability Plan 76
12. Project Implementation Schedule 78
PwC 4
Overview 1.1. Sectional Overview
This document is divided into following broad sections and sub sections:
1. Section 1: Overview & Executive Summary – This section provides a brief overview of entire
document on what is contained in the document, the target audience, the approach adopted etc.
This section also has an Executive Summary and states clearly the Objectives of the Shimla project
as well as a bit of background about it.
2. Section 2: Shimla – This section is meant
to give a clear background and history about
the Shimla city to the readers
3. Section 3: Water Scada– This section
forms the major portion of the document.
This includes the following subsections
under it
Smart city guiding principles:
Detailing of the PwC Smart City Local
Governance Framework which is an overview
on the Services offered as part of the project,
KPIs for each of the services, Desired
Objectives & Outcomes, Functional areas &
services of each of the Govt. departments
under the scope of the project.
Detailing of the Regulatory Framework which explains about the regulating body, their functions
etc.
Detailing of the Technology Framework which includes the guiding principles for the technological
framework, a brief description on the technical aspects of each of the services offered etc.
Section on the essential financials which details about the Bill of Material, estimated cost etc.
1.2. Intended readers
Target audience of this document is following stakeholders:
1. Process Owners: Process owners for each of the business function would be required to read this document primarily from application stack perspective. They would be able to understand how the IT requirements of their individual function would be catered and through which application and provide feedback on it.
2. Senior Management/ Policy Maker who are responsible for Strategy design and implementation and have detail statistics about the cost utilization on projects.
3. Other Stakeholder includes all stakeholders of the project for transformation of Shimla to a Smart
City would be encouraged to read the document especially for the functions which are not matured in
Producer Companies.
1.3. Approach adopted for the document
The aims and objective that are initially envisaged for formulation of any water supply plan are related to
population of the area, socio-economic status of the people inhabiting the area, investigation of sources,
PwC 5
their capacity and dependability on long term basis, future Development Plan of the region, existing and
proposed level of water supply, its quality and history of epidemnicity of water borne diseases.
The approach to achieve these goals is governed by the following methodologies
• Examination of decadal population of the project area and estimation of future population to the
end of the planning period.
• Total daily requirement of water for the present and future estimated population.
• Exploration of capable and dependable sources within or outside the project area.
• Ascertaining the raw water quality viz physical, chemical and bacteriological.
• Determination of treatment process consistent with raw water quality.
• Planning and designing of collection and distribution system considering the topography and
location of settlements of the project area.
1.4. Executive Summary
Objectives of Water Supply Plan for any region should be conceived and conceptualized consistent with
broader perceptions related to socio- economic structure of the inhabitants, their needs and requirement
of adequate potable water and involvement of capital investment as well. The strategy of planning should
therefore aim at formulation of general programmes directed to specific results and conceptual frame work
for action.
Provision of drinking water to communities is not only the basic amenity but it should be viewed as an
integral part of the major public health programme aimed at prevention of water borne diseases which will
result in better health, happiness and well being of the community. It has been proved by epidemiological
studies that all fatal enteric diseases like cholera; Diarrhea, typhoid etc. are caused due to intake of
contaminated water. It therefore, implies that purity of drinking water conforming to prescribed standard
of purity should be primary concern of any water supply system and hence the planning and design of
water supply projects should address not only the technical features but the public health aspect too. The
planned strategy shall take into account the identification of source of supply, collection, transmission,
distribution and other related aspects. Keeping in view the aforesaid concept and objectives formulation of
water supply plan of Shimla M. C. Area should be governed by the following considerations:
• Identification of dependable source on long-term basis
• Potentiality and environmental conditions of the source
• Examination of raw water quality
• Assessment of degree of treatment required
• Per capita daily water requirement
• Total requirement of water for ultimate designed population
The planning should be so framed that it would not only integrate the existing system of water supply but
would also envisage a strategic plan consistent with future overall development of the project area. The
planning should also be streamlined to fit into the regional development plans, long-term sector plan, land
use plan and other open space planning. The planning scenario may also include the supporting activities
like health, education, staff training and infrastructural improvements etc.
The present scale of water to rural or urban population is generally inadequate all over the country hence
the MC, Shimla is no exception. Increasing demand of rising population, non-availability of potential
source, inadequacy of infrastructure etc all lead to scarcity of drinking water in the project area.
Beginning as a feeder of paltry population of 16000 souls in year 1875 AD, Shimla city water supply grew
to larger proportion augmented and improved over the years. Despite the improvements carried out so far
PwC 6
as aforesaid, scarcity of water prevails in many pockets of the city particularly in special areas
amalgamated within the municipal boundary and the areas that are likely to be amalgamated. Depletion of
yield of sources during lean period cause further increase in demand and supply gap resulting in much
hardships and miseries to the inhabitants of the city. City Development Plan (CDP) proposed under
JNNURM identifies water supply and sanitation as a major priority area to be tackled in order to lessen
the growing gap between demand and supply. To provide adequate quantum of portable water to the
citizens, the CDP has envisioned a rate of 135 lpcd water supply to the city. The plan has estimated total
quantity of water required till the end of planning year of 2047 as 71.11 MLD. Further the plan reiterates
availability of about 30 MLD of water, which falls too short of present requirement of the city causing
acute shortage. To tide over the crisis, the state administration conceived a plan to bring water from
Koldam Reservoir (Lift Water Supply Scheme from Koldam Reservoir)
1.5. Objectives of the Project
The primary objective of this initiative is real time remote monitoring of Water treatment to distribution
network of Shimla on parameters like Flow, Pressure, UGR & SUMP Levels, Energy Consumption and Water
Quality.
The objectives of this initiative are following:
Timely availability of real time operating parameters
Real time assessment of water supply situation
Real time data on water quality
Readily available on-line information of distribution data in command areas periphery network
Reliable real time data for service level parameters
To provide alert in case of deviation to set parameters
To bring in accountability into the system and the services
To use latest technology effectively and efficiently to yield significant improvements in
efficiency, productivity, profitability and competitive advantage to Shimla
To enable better decision making by providing real time data and a technological platform
for effective integration with other communications and information management
technology
To provide significant opportunities for item-based process improvement and innovation
in the functioning of Water network
Establishment of the Water SCADA will result in accurate and automated data in continuity for pressure,
flow, energy consumption monitoring, and water quality monitoring including complete water audit for
the transmission mains. Current project is aimed at
Real time Dash board view of Overall system on healthiness
Efficient utilization of water
Ease of coordination for maintenance activities from the plant to the consumers-end
Water SCADA would enable Centralized control and monitoring of distribution and collection system
which would in turn provide data for water modelling and energy use optimization, as well as predictive
maintenance of distributed equipment. The central control room which would be established for
automation of water Distribution ensures constant communication from the server to the remote units.
The system will have configuration to support fail safe design for round the clock monitoring.
PwC 7
2. Shimla – City Profile
2.1. City Snapshot & Projection
The city was spotted as a tiny agglomeration of hamlets inhabited by 16000 persons more than 130 years
back. As the time passed by, it grew in importance on account of its salubrious climate and surrounding
beautiful natural landscape till it became the capital city of Himachal Pradesh. It continues to grow in shape
and size amalgamating more and more adjoining urbanize able areas. Presently MC, Shimla covers an area
of 51.30 sq.km comprising Shimla Municipal Corporation recently merged special areas of Dhalli, New
Shimla, Tutu and Kasumpti etc. The major land uses are located on the southern face of Shimla due to
gradual slope and sunny side. The city sprawls over spurs of central Himalayas south of river Satluj. The
average height of the city is 2130.0 m above MSL. Geo-climatic setting of the town is mainly characterized
as a place having heavy monsoon, cold winter, rugged topography, steep slopes, deep valleys and elongated
mountain spurs. The total population as recorded in 2001 census is 1,56,127 souls (1,44,975 for Shimla +
11,152 souls for merged area as per gazette notification in 2006). Detailed features of the project are given
in succeeding chapter.
Earlier Detailed Project Report for Rehabilitation for Water Supply distribution system of Shimla City was
approved amounting to Rs. 72.36 Crores in the meeting held on 20.02.2009 under the Chairmanship of
Secretary, Ministry of Urban Development, Govt. of India under JNNURM. The funds allocated of Rs.
1447.20 Lacs against the approved project under JNNURM has not been utilized so far. Thus, the Govt. of
India has been withdrawn the funds allocated.
The Irrigation and Public Health Deptt, Govt. of Himachal Pradesh has allowed the work of consultancy
services for updating the earlier approved Project of Rehabilitation of distribution system through
WAPCOS Ltd. which is empanelled with the JNNURM and consultancy jobs.
Section 2
Proposed
Solution
PwC 8
2.2. Geographical Overview
Geology of Shimla indicates sub Himalayan characteristics. The rock found in the project area have
undergone three distinct generations of deformations resulting in variation of altitude of formation.
Carbonaceous, Phyllite, local bands of quartzite and lime stone forming Jutog group of rocks occupy main
Shimla area and extends from Annadele – Chura Bazar-prospect hill-Jakhoo-U.S. club and high land area
whereas shales, slate, greywacke quartzite, local conglomerates and dolomites forming Shimla group of
rocks are found in Sanjaulli and Dhalli area.
2.2.1. Climate and Rainfall
Shimla is on the map of international tourist centres on account of its being hill station with salubrious
climate and extraordinary natural and scenic landscapes. It maintains a pleasant climate during summer
month from April to mid June followed by monsoon up to end of September. The city experiences winter
from September to March and cold spells between the month of December and February when temperature
ranges between -4o C to 17oC. The temperature in summer month varies between 18oC and 32o C. Average
annual rainfall is recorded as 1179.8mm. The maximum and minimum annual rainfall recorded so far is
1897mm in the 1995 and 456.37mm in the year 1987. Most of the rainfall occurs in the month of June, July,
August and September, which accounts for 70% of annual rainfall.
2.2.2. Land Use Pattern
The extent of MC, Shimla is 9950 ha that includes Shimla Municipal Corporation with its added areas of
Dhalli, Tutu and New Shimla and Kasumpti. Area under urban uses is 1475.6 ha as mentioned in
Development Plan (Source: Town and Country Planning Dept., HP), which accounts to 15% of total planning
area. Existing land use plan of SPA is given in the following Table:
Sl.
No.
Land Use Area in ha % of planning area
1. Residential 963.13 9.07
2. Commercial 25.22 0.25
3. Industrial 9.00 0.07
4. Tourism 21.70 0.22
5. Public and Semi Public 138.78 1.39
6. Park and other spaces 6.00 0.06
7 Traffic and Transportation 371.73 3.75
8. Agriculture 2174.75 21.85
9. Forest 6080.15 61.12
10. Water bodies and Barren land 219.34 2.20
Total 9950.00 100%
PwC 9
2.2.3. Tourism and Industry
Tourism is an important revenue earner to the state Govt. It employs nearly 4049 numbers of workers.
Shimla is an attractive destination for tourist from all over the world through out the year. Topography of
the town is characterized by interlocking spurs, narrow and deep valley with high peaks and thick forest. Its
salubrious climate and beautiful scenic location attract large number of foreign tourists. It is easily accessible
through Chandigarh-Shimla National Highway No 22, Kalka-Shimla narrow gauge toy train and by air from
Delhi, Chandigarh and Kullu. Tourist population grew from 9,12,528 in 1998 to 21,97,795 in 2007.
2.2.4. Industrial Scenario
The city has small scale and service industries. Factors prohibitive to industrialization are the inhospitable
geographical features, inadequate and high cost of transport facilities and the absence of market in the near
vicinity. Industrial growth is almost stagnant since late 1960. Nevertheless the traditional small-scale
industries like wool spinning, weaving, basket making and metal work that use local resources are making
tardy progress. There are about 450 small scale and service industries operating in SPA. Description of
existing industries is given in the following table.
Sl.No. Category of Industries No. of units. No. of workers
1 Textile 18 60
2 Manufacturing 110 494
3 Communication 44 154
4 Auto repairs 52 228
5 Food products 63 294
6 Service Industries 117 384
7. Other 45 686
Total 449 2300
2.2.5. Economic Features
Natural resources play a key role in economic survival of the town as tourism and agriculture are the main
stay of the economy. The shift from agriculture to horticulture has changed the economic pattern of the
region as the city has become major centre for collection and distribution. Per capita income is estimated
to be Rs. 27486.0 per annum. The key drivers of economic sectors for MC, Shimla are tourism, health area,
education, agri processing, trading hub etc.
PwC 10
2.3. Existing Scenario
2.3.1. General
Pure drinking water free from physical, chemical and biological contamination is the basic necessity for
health and happiness of any community. Epidemiological investigation has amply proved that fatal
intestinal diseases like cholera, diarrhea etc. are transmitted through intake of contaminated water. Urban
communities in absence of inadequate and scarce availability of pure drinking water may be compelled to
consume water of doubtful quality falling prey to such health hazards.
Water supply facilities were introduced in Shimla more than 130 years ago by pumping water from nearby
spring sources. The city grew over the years increasing its boundary as well as population with subsequent
augmentation of water supply to match the needs of the growing population. With the commissioning of the
last augmentation scheme of water supply in the year 1992 the total installed capacity of the system rose to
29.50 MLD.
2.3.2. Source
The water, which is received from different sources for Shimla Town for distribution, is detailed as under:
2.3.2.1. Dhalli Catchment
An average of 0.45 MLD water is received from this source under gravity condition at Dhalli filter. This is
the source based on spring sources of the dense protected forest known as Dhalli catchment.
2.3.2.2. Cherot & Jagroti
From this source an average of 3.50 MLD of water is received which is collected at Dhalli Filter. Part of this
water is distributed in the adjoining area of Dhalli Zone and balance is received at Sanjauli reservoir
through gravity main from Dhalli filter.
2.3.2.3. Chair Nllah
From the source, an average of 1.70 MLD water is received which is pumped from Chair source to storage
tank at Lambidhar from where water is distributed to Kufri under SPA Shimla.
2.3.2.4. Source at Gumma at Nauti Khad
This is the main source of water supply, which provides approximately 16.75 MLD of water. This quantity
of water is pumped from Gumma & received at Carignano reservoir from where it is gravitated to the
Sanjuli reservoir. From Sanjauli this water is further gravitated to the Ridge reservoir and also to Mans
field reservoir. In addition to this, some of the sectoral tanks are also fed through feeder line from Sanjuli
reservoir. These setoral tanks are Engine Ghar, North Oak, Bharari, Advace Study, Sandal Chakkar and
Totu.
2.3.2.5. Source at Gumma at Nauti Khad near Bridge
From this source, about 4.54 MLD of water is pumped and received at Carignano reservoir from where it
is gravitated to the Sanjuli reservoir. From Sanjauli this water is further gravitated to the Ridge reservoir
and also to Mans field reservoir. In addition to this, some of the sectoral tanks are also fed through feeder
line from Sanjuli reservoir. These setoral tanks are Engine Ghar, North Oak, Bharari, Advace Study,
Sandal Chakkar and Totu.
2.3.2.6. Ashwani Khad
From this source, about 7.60 MLD of water is pumped through two stages and received at Kasumpti
reservoir from where part of the water is distributed in the adjoining area and sectoral tanks located at
PwC 11
sector-1, 3 & 4 New Shimla are filled-up. The balance water is again pumped from this reservoir to Mans
field tank. From Mans field tank the water is distributed in the adjoining area and sectoral tank at Knolls
wood is also connected with this water tank. In addition to this the sectoral tank at Tuti Kandi and sump
well of Kamna Devi Pump house is also fed.
2.3.2.7. River Giri
From this source, about 20.00 MLD of water is pumped into Dhalli Treatment Plant and further water is
distributed in the adjoining area of Dhalli Zone and balance is received at Sanjauli reservoir through
gravity main from Dhalli filter.
Surface water is drawn from five main sources occurring as springs and streams. The following Table
shows the name of source and quantities of water drawn from them.
Sl.
No.
Name of source Quantities drawn in MLD
(Average)
1 Dhalli catchment 0.45
2 Churat Nallah 3.50
3 Nauti Khad 16.75
4 Nauti Khad near Bridge 4.54
5 Ashwani Khad 7.60
6 River Giri 20.00
Total 52.84
The water available i.e. 1.70 MLD from Chair Nallah is being supplied to Kufri under SPA Shimla.
Water from the sources are treated and pumped barring Dhalli catchment source, which operates under
gravity conditions. Water thus pumped or gravitated are stored in 10 number of service reservoirs located
at suitable sites covering the MC, Shimla as given in the following Table:
Sl. No. Reservoirs Capacity in ML Type
1. Carignano 3.01 UG
2. Sanjaulli 8.78 UG
3. Ridge 4.63 UG
4. Mans field 3.63 UG
5. Kasumpti 2.00 UG
6. Kasumpti 0.227 OH
7. Viceregal lodge 0.23 OH
8. Jakhu 0.32 OH
9. Boileaugunj 0.24 UG
PwC 12
10. Balancing Reservoir at Masobara 3.00 UG
Total 26.447
The total capacity of existing reservoirs as shown above is 26.447 ML. The reservoirs located at Sanjaulli is
largest one having a capacity to store 8.78ML and the smallest one is situated at Kasumpti having a capacity
of 0.223 ML. Newly developed areas of BCS, Chakkar, Tohu etc. do not have separate service reservoirs
instead they are fed from existing ones causing considerable loss in pressure at the tail end of the network.
2.3.3. Distribution System
The city has fourteen delineated water zones based on topography and location of feeder reservoirs as shown
in the following Table:
Sl.
No.
Name of zone Area covered
1. Sanjaulli Sanjaulli Bazaar, Engine Ghar, Nav Bahar, Snowdown, Jakhoo, Pumping Station, Grand Hotel, Shankli, Scandal, Sangti
2. Bharari Bharari, Harvington, Kuftu, Anu, Bermu, etc
3. Ridge Telegraph office, Krishna Nagar, Sabzi Mandi, Ripon, Lalpani, Western Command, Ram Bazaar, Middle bazaar
4. High Court Lower High Court area, Paradas Garden, Kanlog, Talland
5. BCS BCS, Khalini, Forest Colony
6. AG office Kaithu, Annandale, Kavi, AG Office, Ram nagar Vidhan Sabha, Chaura Maidan, Tuti Kandi, Kumar House, Raj Bhavan, Ava Lodge, Labour Bureau, Kenndy House, Win Gate
7. Vice Regal lodge Institute of Advanced Studies, Tilak Nagar, Ghora Chowk, Hanuman Temple
8. Mansfield Mansfield to Marina, Secretariat, Chotta Shimla bazaar, Brock Hurst upto Govt. School
9. Kasumpti Kasumpti Colony, Lower Brock Hurst, Patti Rehana, Patina Mehli, Pantha Ghati, Patelog
10. University University Complex, Summer Hill, Govt. Quarters, Shiv Mandir
11. Kamna Devi Hill Spur of Kamna Devi, Forest Colony
12. Chakkar Sandal Hill, Tara Devi, Shoghi
13. Tutu Tutu Bazaar, Jutogh, Dhamida, Fatenchi
14. Dhalli Dhingu Devi Mandir, Dhalli Bazar, Indira Nagar, Part area of Mashobra
2.3.4. Service Coverage
At present 27765 consumer connections have been provided by the Deptt. The details of private and public
services are detailed below:
PwC 13
Sl. No. Head No. of connections
1. Domestic 21276
2. Commercial 5161
3. Street hydrants /Construction connection 900
4. Govt. Buildings/ Institutions/ Religious 428
Total 27765
Water is supplied to the consumers during non-lean season from 60 to 90 minutes on daily basis and during
lean season around 60 minutes on alternate day basis.
PwC 14
3. Design Considerations
Key design considerations taken into account are as follows –
System is designed for projected population of 3.24 Lakhs by 2047
There are 7 Sources of water, major sources being River Giri, Nauti Khad, Ashwani Khad.
System designed for 24x7 water supply system and water requirement of 71.11 MLD by year 2047
Reduced chance of contamination
Distribution pipeline is pressurized for 24 hrs. hence, lower chance of foreign
contamination
No tank at consumer end (except for high rise building). Hence, bacterial / virus
contamination through tank is eliminated
Continuous on-line monitoring of water quality at water treatment plant
Water meters :
Electromagnetic flow meter : In Main Pipelines ( Intake, WTP, MBR & UGRs)
On-line monitoring of production of water, quality of water, distribution status, and demand
management.
System should be flexible, scalable , support open protocol and distributed architecture design
Centralized Water SCADA in line with Smart city concept envisaged for monitoring and controlling
of WTPs , Water Supply & Distribution system spread across city
Revenue management system for metering, billing and collection
The primary objective of this initiative is real time remote monitoring of Water treatment to distribution
network on parameters like Flow, Pressure, UGR & SUMP Levels, Energy Consumption and Water Quality.
The objectives of this initiative are following:
Timely availability of real time operating parameters
Real time assessment of water supply situation
Real time data on water quality
Readily available on-line information of distribution data in command areas periphery network
Reliable real time data for service level parameters
To provide alert in case of deviation to set parameters
To bring in accountability into the system and the services
To use latest technology effectively and efficiently to yield significant improvements in
efficiency, productivity, profitability and competitive advantage to Shimla Municipal
Corporation
To enable better decision making by providing real time data and a technological platform
for effective integration with other communications and information management
technology
To provide significant opportunities for item-based process improvement and innovation
in the functioning of Water network
Establishment of the Water SCADA will result in accurate and automated data in continuity for pressure,
flow, energy consumption monitoring, and water quality monitoring including complete water audit for
the transmission mains. Current project is aimed at
Real time Dash board view of Overall system on healthiness
Efficient utilization of water
PwC 15
Ease of coordination for maintenance activities from the plant to the consumers-end
Water SCADA would enable Centralized control and monitoring of distribution and collection system which
would in turn provide data for water modelling and energy use optimization, as well as predictive
maintenance of distributed equipment. The central control room which would be established for automation
of water Distribution ensures constant communication from the server to the remote units. The system will
have configuration to support fail safe design for round the clock monitoring.
PwC 16
4. Water Value Chain
Objective is to maximize their asset management & utilization, reduce capital expenditures, improve
reliability and enhance service delivery to Shimla City citizens, business and industries.
Shimla Water Value Chain involves two components as shown below:
Water collection and treatment- This component involves the collection of the Raw water from
different Sources and then treating the water by passing it through the Water Treatment Plant where it
is Coagulated , Flocculated, Chlorinated and then backwashed to distribute it into the MBR.
Water supply and distribution- After the treatment from treatment plants water is distributed to
the 11 major reservoirs and 28 minor reservoirs from where it reaches to the consumers through internal
sector pipelines.
A smart water system is proposed and designed looking at current requirement that will help the authority
to gather meaningful and actionable data about the flow, pressure and distribution of a city's water and help
in better city water management and operations.
Distribution & Supply
Distribution to 11 major reservoirs and 28 minor reservoirs
Supply to consumer
Water Collection &
Treatment
Collection of freshwater
Raw water treatment
1 2
PwC 17
SMART WATER MANAGEMENT SYSTEM
PwC 18
Shimla Smart Water Management Integrated View
PwC 19
5. Architecture& Solution Elements
5.1. Water Collection and Treatment
In this section, we will discuss in detail the first component of Water Supply Chain i.e. Collection of Water
and its treatment of the collected water through Water Treatment Plant (WTP) and pumped to storage
reservoir
5.1.1. Architecture of Water Distribution System Automation
The three major components of automation of Water Distribution System are:
1) Process Monitoring and Control
2) Plant Wide SCADA
3) Plant Automation
Process Monitoring and Control: This includes primary instrumentation, including pressure, level,
flow and analytical instruments, primary control devices such as valve actuators and solenoids and electrical
equipment, including motor control centers, variable frequency drivers and packaged control panels. The
types and quantities of devices needed at this level are dependent on the plant processes and capacity and
to some extent the physical layout of the plant
Process Automation: The process automation Category includes area control panels, local indicators,
Programmable Logical Controllers, Remote Terminal Units (RTUs), Distributed Control Units (DCUs),
dedicated operator interface devices, panel mounted recorders, indicators, single loop controllers. Many of
these devices are considered instruments but the intent here is to show generally where they would be
located in the plant. Like the process monitoring and control category, the types and quantities of these
devices depend on the plant processes, the level of unattended operation, plant capacity and physical
capacity.
Plant Wide SCADA: This category constitutes Operator Interface Workstations, computer networks,
printers, SCADA software applications, reporting application, Alarming Systems Firewalls, communication
processors and network storage devices. Many of these devices and systems are similar for any water
treatment plant and the equipment costs are only moderately affected by the type of processes and physical
size of the plant. Software development including graphic displays, PLC programming and report
PwC 20
development are directly related to the processes used, field equipment count, no. of SCADA computers and
plant capacity.
5.1.2. Detailed analysis of Process Monitoring and Control
5.1.2.1. Water Treatment Functional Architecture
PwC 21
1) Raw Water Pumping-
Raw water pumping involves moving raw water from the source to the treatment plant. Surface water
treatment plant intakes are typically equipped with screens or rakes that remove large objects from the flow
before it enters the plant that convey it to the head of the treatment plant. The automation of raw water
pumping includes the automatic controls, valve actuators, variable frequency pump drives and flow and
level monitoring instruments
Potential benefits of the automation of raw water pumping are:
Reduced energy cost as a result of off-peak operation
Automatic startup and shutdown in response to emergencies or water demands
Reduced Labour costs and improved water quality as a result of more uniform flow rates
2) Coagulation-
Coagulation removes dirt and other particles suspended in water. Alum and other chemicals are added to
water to form tiny sticky particles called “floc” which attract the dirt particles. The combined weight of the
dirt and the alum (floc) become heavy enough to sink to the bottom during sedimentation. Coagulation
involves the addition of chemicals to influent raw water to form particles large enough to be removed by
settling. Typical coagulants are:
Alum
Ferric Chloride and Coagulant Aids
As raw water pH can interfere with the coagulation process, pH control is often included.
Control Modes for Coagulation Process:
Manual Control - A common method of controlling coagulant dosages is manually adjusting the
coagulant , coagulant aid and acid and caustic feed rates based upon observation, jar testsand
instrument readings. Jar testing is performed on a scheduled basis with increased frequency when
the quality of source water fluctuates.
Some of the instruments needed in the limited automation of Coagulation process:
Raw water flowmeters
Raw water turbidity monitors
Raw water pH meters
Settled water turbidity monitors
Automatic Control
Automatic control - It adjusts coagulant feed rates and dosages in response to variation the
plant flow and/or source water quality. Automatic shutdown of the plant should also shut down
the coagulant feed. Automatic pH control may be required at some plants. Feedback control of
the coagulant dose is accomplished using streaming current detectors and controllers. The use
of streaming current detectors may not be suitable with some source waters
Some of the instruments needed for automatic control of Coagulation process:
Raw water flowmeters
Raw water turbidity monitors
Raw water pH meters
Settled Water turbidity monitors
Controller for streaming current detectors
pH controllers
Potential Benefits of automated Coagulation Process:
Adding stream current detectors can include improved coagulant dosing resulting in chemical cost
savings ,
More consistent treated water quality and fewer process upsets
PwC 22
3) Flocculation/sedimentation - Flocculation refers to water treatment processes that combine or
coagulate small particles into larger particles, which settle out of the water as sediment. Alum and iron
salts or synthetic organic polymers (used alone or in combination with metal salts) are generally used
to promote coagulation. Settling or sedimentation occurs naturally as flocculated particles settle out of
the water. The heavy particles (flocculation) settle to the bottom and the clear water moves to filtration.
4) Filtration and Disinfectors – Many water treatment facilities use filtration to remove all particles
from the water. Those particles include clays and silts, natural organic matter, precipitates from other
treatment processes in the facility, iron and manganese, and microorganisms. Filtration clarifies water
and enhances the effectiveness of disinfection.
The majority of the surface water treatment utilizes granular media filtration, gravity fed to remove
suspended solids.
Controlling Methods to automate the filtration Process:
There are two primary methods for the control of gravity filters:
Constant Rate
Declining Rate
With constant rate filtration, the influent channel water level is maintained at a constant level as
flow is split equally between all on-line filters.
There are three main approaches used for controlling constant rate filters including:
Constant Rate with filter effluent rate of flow controller
Constant rate with constant water level and influent flow splitting
Constant rate with variable water level and influent flow splitting
Automatic Control: A certain level of automated control is required for filtration; completely
manual control is not utilized. The most common indicator of filter performance is Turbidity. Each
filter’s effluent should be monitored and recorded continuously. Automation of a typical filter
configuration and typical instrumentation includes:
Individual filter turbidity
Combined filter effluent turbidity
Filter effluent Flow Rate
Filter influent channel level
Filter Head loss
Filter level or level switches
Backwash Flow rate
Filter Effluent particle Counts
Flow Controller- using Modulated discharge control valves to vary effluent flow rate
5) Declining rate filters- These filters are typically equipped with effluent weirs or fixed position
effluent valves rather than effluent rate of flow controllers. The declining rate filters collect solids; the
flow through the filter begins to drop off. Solid begins to accumulate in the filter media bed, porosity
decreases and the head loss across the bed increases. To avoid head-loss increases beyond a desired level
of turbidity breakthrough of the filter media the filter needs to be backwashed or cleaned.
PwC 23
6) Backwashing- Backwashing is the cleaning of filters after the water is treated through their medium
i.e. effluent wires. There are four basic Backwash Methods:
Up flow of wash water through the filter bed without auxiliary scour
Up flow of wash water through the filter bed with air scour
Up flow of wash water with surface wash
Continuous backwash
Control Methods for Automated Backwashing: Backwash is typically initiated manually with
operator intervention or automatically based on filter head loss, filter run time or turbidity levels
of the filter water exceeding a certain set point. Backwash sequencing typically is configured to
minimize filter bumping by gradually increasing backwash flowrate or having a low rate and High
rate backwash. Backwashing is typically completed based on the duration of backwash cycle or on
backwash
The components needed to automate the backwashing are:
1) Turbidity Analyzers
2) Turbidity Recorders
3) Pressure Sensors
7) Chlorination – This is the final step of water treatment. After the filtration the chlorine dose is
given to the water for the end purification. Chlorine dose is given in a controlled and it is controlled
through the chlorine sensor and the residual controller and analyzer. Some of the typical instruments
needed to automate the chlorination are: Chlorinator with pacing signal input – Flow Pacing and
Residual feedback Controller
PwC 24
5.1.3. Detailed Analysis of Plant Wide SCADA
5.1.3.1. Functional Overview of a Plant Wide SCADA
In this section we have covered the indicative Functional Overview of SCADA & its Reporting Application
Software with brief description of each application/services planned to be implemented through Water
SCADA
The services of the department, both information and transactional, shall be delivered to the
stakeholders through multiple service delivery channels including portals (for both internal and external
stakeholders mobile communication (SMS services)
For all users / stake holders the portal is envisaged to deliver information services about the processes
and allow to control based on authorization and access rights. The portal shall also facilitate
transactional services both for water delivery and energy use
The portal shall be accessed through secure intranet and all services shall be delivered through the
internet
The access shall be extended through secure VPN connectivity
The proposed system shall also provide the mobile application/SMS services for facilitating
communication for alarm / alerts /intervention required
Process Instruments Needed for the Automation of Process
Raw Water Pumping Raw Water Flow Meters
Influent Channel Level Sensor
Raw Water l Level Sensor
Flow Controller
Speed and Valve Controls
Valves and Actuators
Variable frequency Drives
Coagulation/Flocculation/
Sedimentation
Raw Water Flow Meters
Raw Water Turbidity Monitors
Raw Water pH meters
Settled water pH Meters
Controller for streaming current detectors- coagulation dosage
control
pH controllers
Backwashing Turbidity Analyzer
Turbidity Recorder
Pressure Sensor – for measuring head loss
Chlorination Flow meters for filtered water
Residual Analyzer
Residual Recorder
Residual Controller- Configured for one of the following modes:
Flow paced
Residual control or compound close-loop control
Chlorinator with pacing signal input
Finished Pumping Flow Meter- for finished water flow
Level Sensor- for checking reservoir level
Chlorine Sensor- checking Chlorine Level
Pressure Sensor- to check the distribution system pressure
Flow Controller – using modulated pump discharge control valves
Variable Frequency Drives for the adjustment of pump speed
PwC 25
Ethernet Ring network
WMSOWS - 1 OWS - 2
PRIMARY/
SECONDARYUPS Reporting Printers
City Control Room
DSL IP WAN NETWORK
SMS functionality
on critical alarms
Web
Client
Leak
DetectionPSU CPU COMCOM
+-
Data
Concenrator
PSU COM
+-
DI DO AI AO
PSUCOM
+-
DI DO AI AO COM
Ethernet Ring network
PSU CPU COMCOM
+-
WTP Controller
ClariflocculatorBuilding
PSUCOM
+-
DI DO AI AO
P
L
A
N
T
C
O
N
T
R
O
L
N
E
T
W
O
R
K
CWPH
EWSOWS - 1 OWS - 2
PRIMARY/
SECONDARYUPS Reporting Printers
PSU COM
+-
DI DO AI AO
Chemical Building
SwitchGear Panel
PSU COM
+-
DI DO AI AO
Chlorination BuildingPSU COM
+-
DI DO AI AO
BackwashPSU COM
+-
DI DO AI AO
Filter House
Modbus Serial
Modbus Ethernet
Fiber Optic
WTP Control RoomDSL IP WAN NETWORK
PSU CPU COMCOM
+-
SMS functionality
on critical alarms
5.1.3.2. SCADA & Reporting Application Software
The task of the SCADA shall be to collect all process-related data from the processing units into the process
database. The process database shall reflect the real-time image of the process. The collected information
shall further be distributed, e.g. for displays, historical archiving, calculations, printing, reports generation
and further transmission to other systems.
The Objectives of reporting software are:
• Continuous system self-supervision
• Display of events & alarms
• Storage of time stamped events
• Trend reports
• Display of station Network Diagram with status of all process objects
• Alarm and event reports
PwC 26
• Automatic printout of fault reports
• Parameter settings of event & alarm
SCADA system should be capable of being configured to various predefined users so that each user defined
in the system can be given access rights for various features. The hierarchies of authorization should take
due care of protecting the system from unnecessary configuration changes. The Suggested users are
following but not limited to
• System Administration
• Engineering
• Maintenance
• Operation
The access rights shall be in the form of passwords & user ID both, Only the system administrator should be
authorized to add / remove users and change access rights. It is desired that the system should prompt the
password change after first log-in so that default password will be overwritten. It is desired that the WMS
software should support multiple instances of software on the same personal computer simultaneously of
the same make. It is desired that the software should have the functionality to alert the system operator
about the event in a specific station by pop up or colour change of the minimized software instances for a
particular station .
A feature of sending the SMS message to field crew is also desired. It shall able to send disturbance & fault
event to the field crew. The WMS shall possess the following additional functionality.
• Features to add new graph, display& reports
• Features of web view only access
• Data exporting to other system in the XML format.
Ethernet Ring network
PSU CPU COMCOM
+-
WTP Controller
EWSOWS - 1 OWS - 2
PRIMARY/
SECONDARYUPS Reporting Printers
WTP Control RoomDSL IP WAN NETWORK
PSU CPU COMCOM
+-
SMS functionality
on critical alarms
RTU
RTU
RTU RTU RTU RTU RTU
RTU
RTU
RTU’s installed at remote locations for reservoir
monitoring & Control
Typical Telemetry Achitecture
PwC 27
5.1.3.3. Functional Requirement of SCADA System
5.1.3.3.1. System Display
The Display system should be based on the principle of communicating to the operator through visual aids
like mimics/ screen videos like Single line diagrams of individual distributors. The operator should be able
to use pictures to communicate with the process and the control system:
• Pictures should visualize the controlled process with industry standard symbols and Specified
colors
• The operator should be able to select the object by using the mouse and issuing the command
by double click. The operator should also able to issuing the command on selected object by
using the functional keys. The keys should be standard for all the installation of a specific
manufacturer
• Pictures should inform the operator about alarms and events by specified color changes
• Pictures should illustrate process data
5.1.3.3.2. Trends Display
A trend is a time-related follow-up of process data. The major parameters to be considered for trends are:
• Flow
• Pressure
• Turbidity
• Energy
• Chlorine levels
• Ph
• Ammonia
• Water Levels
• BOD, SS/SS
The trend display shall be available in graphical mode as a line graph. Trends shall be available on a two
dimensional co-ordinate system that consists of horizontal time (X) axis and vertical value (Y) axis. Trends
shall have minimum following characteristics:
• The curve can be scrolled in both direction, X and Y
• The time axes shall be scalable on minute, hours , day and monthly basis
o It should be possible to get the value of parameters at any instance by clicking the trend
o minimum eight parameters trends should be visible in one screen at one point of time
sharing the same process data
o The graphic window shall be resizable & maxim sable
5.1.3.3.3. Reports Display
The system shall collect the data from the database and able to produce report & produce printout on the
operators request. The system shall have the capability of displaying minimum 10 reports on a single window
simultaneously The system shall able to generate reports based on the user selected values on the basis of
time interval of Day/ Week/ Month/ Year However system should be capable of generating reports on the
basis of:
• Predefined time intervals
• when a predefined event occurs
• Day (mean, peak)
• Month (mean, peak)
• Year (mean, peak)
• System should provide functionality to produce user defined reports
5.1.3.3.4. Event Display
The event list presents the process events from the monitored process in pre-defined way whenever there is
change in status or change in limiting values. Each event shall normally be presented by displaying a
predefined event text line, which describes the event in the process. Event text lines shall consist of a time
PwC 28
stamp, object identification, a single text indicating status and data value. The events should be printed with
WTP/UGR ID, Distributor ID & equipment wise segregation. The events shall be presented in chronological
order so that the latest event appears on the top line of the first page. The event list shall contain keys for
browsing the list forward and backward. Configured of event log file for day, week, month and year wise
shall be possible. Events shall be stored in the history buffer in the computer’s RAM memory, and also stored
on the computer hard disk. The length of the history may be 10,000 events. The 10000 events shall be stored
on the basis of First in First out Principle (FIFO). User configurable prioritization of event shall be possible.
The system should have the functionality for user configurable prioritization & filtration of events.
5.1.3.3.5. Alarm List
The alarm list shall display the present alarm situation of the supervised process. All data Acquisition &
control malfunctions including no responses from field devices and Check- back –verification errors on
control selections, should be reported as alarms. Each alarm message should clearly indicate the type of
malfunction that caused the failure in the operation sequence. Each alarm shall have the time stamp (date
& time), object identification (WTP name & Distributor name), a signal text and a text indicating alarms
status. The alarms will be shown in chronological order. Alarms will have different colors on the basis of
priority and operator shall be in a position to view in archives category wise. Occurrence of alarm will be
noticed by popup in screen with sound. Alarm sound will be different on the basis of priority. The alarm data
can be exported to external system as per the requirement of the operator.
5.1.3.4. System Level Functions
5.1.3.4.1. Status Supervision
The position of each equipment shall be supervised continuously. Every detected change of position shall be
immediately displayed in the single-line diagram on the station of SCADA screen, recorded in the event list
and a hard copy printout shall be produced. Alarms shall be initiated in the case of spontaneous position
changes. The positions shall be indicated by two auxiliary switches, normally closed (NC) and normally open
(NO), which shall give ambivalent signals. An alarm shall be initiated if these position indications are
inconsistent or if the time required for operating mechanism to change position exceeds a predefined limit.
The SCADA shall also monitor the status of auxiliaries. The status and control of auxiliaries shall be done
through separate one or more IED and all alarm and analogue values shall be monitored and recoded
through this IED.
5.1.3.4.2. Measurements
Analogue inputs shall be connected via PLC / RTU with/without intermediate transducers. The measured
values shall be displayed locally on the station monitoring system and in the control center. The abnormal
values must be discarded. The analogue values shall be updated every 10 minutes. Threshold limit values
shall be selectable for alarm indications
5.1.3.4.3. Event and Alarm Handling
Events and alarms that are generated by the sensor unit shall be recorded in an event list in the station
Monitoring System .Alarms shall be recorded in a separate alarm list and appear on the screen. All, or a
freely selectable group of events and alarms shall also be printed out on an event printer. The alarms and
events shall be time-tagged
5.1.3.4.4. Presentation and Dialogues General
The processor shall be a redundant with hot standby and shall provide basic functions for supervision and
control of the equipment. The operator shall give commands to the equipment on the screen via mouse clicks
or keyboard commands. The SCADA monitors shall give the operator access to alarms and events displayed
on the screen. Aside from these lists on the screen, there shall be a printout of alarms or events in an event
log. The following standard pictures shall be available on the monitors of Control Center - Single-line
diagram showing the status and measured values. Control dialogues with interlocking and blocking details.
This control dialogue shall tell the operator whether the device operation is permitted or blocked.
Measurement dialogues Alarm list, station / bay oriented Event list, station / bay-oriented System status
PwC 29
5.1.3.5. SCADA Monitoring System Design Principles
Consistent design principles shall be adopted with the monitoring system concerning labels, colors,
dialogues and fonts. Non-valid selections shall be dimmed out.
The object status shall be indicated using different status colour for: Selected object under command
Selected on the screen Not updated, obsolete values, not in use or not sampled Alarm or faulty state Warning
or blocked Update blocked or manually updated Control blocked Normal state
• Process Status Displays and Command Procedures
• The process status of the WTP/Distribution System in terms of actual values of analog as well
as the positions of valves, circuit breakers, motors, pumps shall be displayed in the WTP single-
line diagram
• In order to ensure a high degree of security against undesired operation, a "select-before-
execute" command procedure shall be provided. After the "selection" of a switch, the operator
shall be able to recognize the elected device on the screen, and all other equipment shall be
blocked. As communication between control Centre and device to be controlled is established,
the operator shall be prompted to confirm the control action and only then final execute
command shall be accepted. After the “execution” of the command the operated switching
symbol shall flash until the switch has reached its new position. The operator shall be in a
position to execute a command only, if the equipment is not blocked and if no interlocking
condition is going to be violated. The interlocking statements shall be checked by the
interlocking scheme implemented at bay and WTP level
• After command execution the operator shall receive a confirmation that the new switching
position has been reached or an indication that the switching procedure was unsuccessful with
the indication of the reason for non-functioning
5.1.3.5.1. WMS Supervision & Display
The Water Management System (WMS) shall be comprehensively self-monitored such that faults are
immediately indicated to the operator, possibly before they develop into serious situations. Such faults are
recorded as a faulty status in a system supervision display. This display shall cover the status of the entire
WTP and Distribution Network including all sensors, communication infrastructure and remote
communication links, etc.
5.1.3.5.2. Event List
The event list shall contain events that are important for the control and monitoring of the
WTP/Distribution System. The event and associated time (with1 ms resolution) of its occurrence has to be
displayed for each event. The operator shall be able to call up the chronological event list on the monitor at
any time for the whole WTP/Distribution System or sections of it. A printout of each display shall be possible
on the hard copy printer.
The events shall be registered in a chronological event list in which the type of event and its time of
occurrence are specified. It shall be possible to store all events in the computer for at least one month. The
information shall be obtainable also from a printed event log.
5.1.3.5.3. Alarm List
Faults and errors occurring in the WTP/Distribution System shall be listed in an alarm list and shall be
immediately transmitted to the control Centre. The alarm list shall substitute a conventional alarm table,
and shall constitute an evaluation of all station alarms. It shall contain unacknowledged alarms and
persisting faults. The date and time of occurrence shall be indicated. The alarm list shall consist of a
summary display of the present alarm situation. Each alarm shall be reported on one line that contains:
• The date and time of the alarm
• The name of the alarming object A descriptive text
• The acknowledgement state
Whenever an alarm condition occurs, the alarm condition must be shown on the alarm list and must be
displayed in a flashing state along with an audible alarm. After acknowledgement of the alarm, it should
appear in a steady (i.e. not flashing) state and the audible alarm shall stop. The alarm should disappear only
if the alarm condition has physically cleared and the operator has reset the alarm with a reset command.
PwC 30
The state of the alarms shall be shown in the alarm list (Unacknowledged and persistent, Unacknowledged
and cleared, Acknowledged and persistent). Filters for selection of a certain type or group of alarms shall be
available as for events.
5.1.3.5.4. Object Picture
When selecting an object such as a valve or other equipment in the single-line diagram, the associated bay picture shall be presented first. In the selected object picture, all attributes like Type of blocking Authority Local / remote control etc., shall be displayed.
5.1.3.5.5. Control Dialogues (In future)
The operator shall give commands to the system by means of mouse click located on the single-line diagram.
It shall also be possible to use the keyboard for command activation. Data entry is performed with the
keyboard. Dedicated control dialogues for controlling at least the devices shall be available:
5.1.3.5.6. User-Authority Levels
It shall be possible to restrict activation of the process pictures of each object (bays, apparatus...) within a
certain user authorization group. Each user shall then be given access rights to each group of objects, e.g.:
Display only Normal operation (e.g. open/close) Restricted operation (e.g. by-passed interlocking) System
administrator
For maintenance and engineering purposes of the station WMS, the following authorization levels shall be
available:
• No engineering allowed Engineering/configuration allowed Entire system management
allowed
• The access rights shall be defined by passwords assigned during the log-in procedure. Only the
system administrator shall be able to add/remove users and change access rights
5.1.3.5.7. Reports
The reports shall provide time-related follow-ups of measured and calculated values. The data displayed shall comprise:
Trend reports: • Day (mean, peak)
• Month (mean, peak)
• Semi-annual (mean, peak)
• Year (mean, peak) Historical reports of selected analogue Values:
o Day (at 15 minutes interval)
o Week
o Month
o Year
It shall be possible to select displayed values from the database in the process display on-line. Scrolling
between e.g. days shall be possible. Unsure values shall be indicated. It shall be possible to select the time
period for which the specific data are kept in the memory.
Following printouts shall be available from the printer and shall be printed on demand:
• Daily voltage and frequency curves depicting time on X-axis and the appropriate parameters
• On the Y-axis. The time duration of the curve is 24 hours
• Weekly trend curves for real and derived analogue values
• Printouts of the maximum and minimum values and frequency of occurrence and duration of
maximum and minimum values for each analogue parameter for each circuit in 24 hrs. period
• Provision shall be made for logging information about breaker status like number of operation
with date and time indications
• Equipment operation details shift wise and during 24 hours
• Printout on adjustable time period as well as on demand
• Printout on adjustable time period as well as on demand
• Reports in specified formats which shall be handed over to successful bidder
PwC 31
5.1.3.5.8. Trend Display (Historical Data)
It shall be possible to illustrate all types of process data as trends - input and output data, binary and
analogue data. The trends shall be displayed in graphical form as column or curve diagrams with a maximum
of 10 trends per screen. Adjustable time span and scaling ranges must be provided.
It shall be possible to change the type of value logging (direct, mean, sum, or difference) on-line in the
window. It shall also be possible to change the update intervals on-line in the picture as well as the selection
of threshold values for alarming purposes
5.1.3.6. Software Requirements
5.1.3.6.1. WMS Software
WMS software can be divided into three categories:
• Operating system software
• Application software that includes any application loaded on the computer (SCADA Software
)
• Configuration file(s) for the settings, displays, and database of the WMS application (Reporting
Application Software)
Note that the WMS computer may have other applications that also have configuration files.
The WMS application typically runs on computers requiring the latest version of Windows, Linux, or some
other operating system. Design tradeoffs can occur when certain requirements are made. For example, the
Designer/Specifier may require a certain operating system to meet a corporate standard, which may limit
WMS selection. The behavior of the operating system software during and after power failures may help to
prevent unexpected WMS performance and must be determined prior to deployment. In addition to the
WMS software, the Designer/Specifier should also consider other software applications to be loaded on the
computer. Examples of such applications include software that configures WTP/Distribution System
devices, monitors network traffic, retrieves data from WTP/Distribution System devices, views different
files, web browsers, and other applications that may be important to personnel working in the
WTP/Distribution System. These applications may or may not be directly linked in the WMS application.
The Designer/Specifier should also consider whether the actual configuration files should have backup files
located on the WTP/Distribution System computer or if the files should be stored elsewhere. Due to
availability, security, and redundancy, this determination may not be trivial and should engage all of the
impacted parties
5.1.3.6.2. Issues
Patches and updates to all WMS software will be issued at various times during the life of the system.
Coordination of the various updates is essential and may require a maintenance contract or licenses that the
Designer/Specifier should include in the WMS specification. This may increase software costs. The
Designer/Specifier may require that all vendors provide copies of all WMS software. The Designer/Specifier
should consider whether multiple copies are required, which may increase software costs due to licensing
issues. The Designer/Specifier should also address process issues that most likely should not be included in
the WMS specification. The Designer/Specifier should provide a means to provide a version control process
that records all WMS software. These records should include compatibility relationships between the
various software. A backup process should also be put in place.
5.1.3.7. SCADA Software Requirements
5.1.3.7.1. Architecture of SCADA software
• Client / Server architecture based on TCP/IP networking and report-by-exception (RBE) technology
• Standalone single server operation
• Symmetric main-standby & capacity for triple standby server functionality
• Additional servers for client load sharing and remote locations
• Permanent Standby Server designed to be placed outside corporate firewalls providing a read-only
access to the server while ensuring corporate security
PwC 32
• Fully automated data transfer between servers to provide complete server redundancy. This transfer
shall include configuration, real-time data, historic data and event lists. Database updates shall be
on an incremental basis with tunable parameters
• A scalable fully distributable architecture providing:
a. Unlimited number of server systems
b. Unlimited number of display clients
• Where multiple servers are deployed, the system shall be capable of being configurable from a single
client
• All redundancy shall be handled by the database, with the operational state of systems preserved
through a server changeover. The system shall not rely on driver redundancy for data transfer where
providing redundant server. The system shall present a uniform view of data including
communication status after a fail over
• Forced changeover between main and standby allowing seamless changeover between main and
standby servers without shutting down either server
• Clients to connect to a synchronizing server as soon as the configuration and current data in the
database has synchronized. Incomplete data sets as per clients request on event or trend provide
indications that the synchronization is still in progress to ensure that conclusions are not drawn
from incomplete data sets
• Configurable compression of data communications between client/server and server/server to allow
optimization of communications performance over WAN networks
• Change reporting on Client/Server and Server/Server links rather than polled communication to
permit operation on WAN networks
• Capable of operating Client/Server and Server/Server links over low to medium speed channels
depending upon database size
• Application shall be native 32-bit and 64-bit versions and supported on Windows® Server and
Workstation operating systems including Windows 2000, Windows XP, Windows 2000 Server,
Windows 2003 Server, Windows 7 (32 and 64 bit) and Windows Server 2008 R2 and later.
5.1.3.7.2. Database
The SCADA database shall be of true relational database design and optimized for real-time SCADA
operation. The database shall be object oriented and organized in a hierarchical structure. It shall support
user-created “Templates” that allows management of common configuration from a single point in the
database. Instances of templates shall be used for repetitive, standard configuration. Templates of standard
configuration shall support multiple object types including, but not limited to:
• Point / Tag objects
• PLC / RTU or PLC / RTU objects
• Mimics or Graphic display objects
• Trend objects
• Logic programs
• Schedules
• Link objects
The SCADA database shall allow users to extend the database schema to store custom data, in either the
Configuration or data stream. These changes can be performed online without need for server restart.
5.1.3.7.3. Operator Interfaces
• SCADA software shall provide the ability to support multiple local and remote display clients
• Display facilities shall be available via LAN, WAN and dial-up connection
• Display clients shall be supported as Rich Clients without the requirement of a database resident at
the display node
• Rich Clients shall support database management and configuration changes
• Rich Clients shall support multiple monitors (multi-head display), allow logon for all heads from a
single location. The system should also provide navigation facilities such that displays on each head
can be controlled from any head. (yoking)
• Integrated Web Sever capability shall be available, providing all display and operational facilities of
the Rich Client without the need for additional software to be installed.
PwC 33
• Web Clients shall allow users to view Mimics, Trends, Database Objects, Reports as well as perform
control functions using a standard web browser.
• Changes made to the SCADA server shall require no additional steps to be performed in order for
those changes to be available to Rich Clients and Web Clients.
• Each full function Rich Client shall be configurable to connect to one, or multiple server systems
• Full function display clients shall automatically fail-over & reconnect to a redundant server node
when server change-over occurs.
• Current generation Windows® look and feel shall be provided by the SCADA system operator
interfaces, including provision for “favourites lists” comprising links to any server object. This
includes, but is not limited to: Mimics, Graphs, List Queries
5.1.3.7.4. Mimics / Graphics
SCADA system Mimics shall support a wide range of graphical facilities. Scalable Vector Graphics are
required in order to permit operation of the SCADA system with different resolution clients operating
simultaneously. Fixed resolution bitmap graphics are not acceptable. Mimics shall be multi-layered, object
oriented and permit mimics to be embedded in other mimics. Other objects that must be available for
embedding in a mimic include:
• Button objects
• Hyperlinks
• Disk images (e.g. JPG, motion JPEG)
• Remotely updated images
• Hyperlinks with embedded queries (for generating filtered lists directly from a mimic)
• Object menus
Graphical facilities within a mimic must also be object oriented including the ability to manipulate attributes
of embedded objects in real time, supporting animation including but not limited to:
• Fill factors
• Fill colour
• Rotation
• Position
5.1.3.7.5. Line thickness
• Text attributes
• Transparency
• Alpha blending
• Multi-rate Flashing
A suite of Graphical Symbols shall be provided for integration with configuration templates and embedding
within other mimics. Import of mimics shall be supported from DXF format, including integration of multi-
layered DXF drawings in to native SCADA mimics.
Adding Custom database fields dynamically to Metadata where the server does not have to be restarted after
adding or modifying.
Mimics shall support the ability to specify OPC data source information to display directly on the mimic.
This permits data from other systems to be seamlessly integrated in to the SCADA display. Other facilities
required to be supported by mimics includes:
• Context sensitive object menus available from mimic
• Accept an alarm from a mimic
• Issue a control from a mimic
• Operator Notes (as a native feature)
• ToolTips
• Hyperlinks to external documents (e.g. HTML, PDF, MS Office® suite documents)
Objects embedded and displayed on any mimic shall be viewable through both the full function client and
web client displays.
PwC 34
5.1.3.7.6. Start-up
The SCADA system shall startup unattended, and without compromising system security. The SCADA server
process shall operate as a Windows® Service. The SCADA server shall start without the requirement for an
HMI client to start. Windows® logon shall be available prior to display client RTUs which must provide
additional security. Shutting down a display client (including on the server node) shall not affect other users
or the server. Administrative privilege shall be required to shut down a SCADA server.
5.1.3.7.7. Configuration
The SCADA software shall provide full seamless On-line configuration of all database parameters including
but not limited to:
• Communication channels
• PLCs and PLC / RTUs
• Points / Tags
• Sequences
• Schedules
• Alarm redirection
• Mimics / Graphics
• Trends/graphs
• Reports
Configuration changes shall be capable of being made from local and remote workstations using Rich
Clients, with appropriate privilege. Configuration changes are to be applied to the Main SCADA server and
seamlessly applied to Standby server and other SCADA server nodes such as user performance sharing
SCADA nodes.
Further, configuration changes made to mimics and other display objects shall be immediately available to
local and remote Rich and Web display Clients without any manual intervention. Changes should be updated
automatically in local caches where appropriate. This facility shall be a native feature of the product and not
require external scripts or customization.
All aspects of the look and feel of the SCADA system, including default field values, shall be configurable. It
is not acceptable for colour regimes, communication parameters and other aspects of the system to be
hardcoded.
It shall be possible to add user defined fields to the SCADA database. These fields should be accessible both
internally and externally to the SCADA system; being exposed via OPC, ODBC, OLE Automation,
XML/SOAP, etc.
The SCADA server shall provide detailed diagnostics concerning its internal operation. The diagnostics shall
be available through capture to a log file as well as online locally on a server and remotely via Telnet and
Web interface.
The SCADA software shall provide the ability to perform a complete audit trail of all database changes down
to the individual property level of objects to ensure complete system integrity and safe system operation.
These details shall be provided as a built-in integrated part of the system and shall include, but not be limited
to the following:
• Time of change
• Object on which change was performed
• Property of the object that was modified
• Property value before and after the change
• User that made the change
• Reason for the change
Stored configuration records should be maintained in the historic database for a configurable time period,
support redundant SCADA server configurations and allow access from standard database interfaces such
as queries and simple mechanisms for displaying and filtering the configuration records
PwC 35
5.1.3.7.8. Alarm Management
The alarm system shall provide facilities where actions can be triggered by alarms. These facilities shall be
provided as a built-in integrated part of the system and shall include, but not be limited to the following:
• Configuration criteria for alarm actions
• Escalate Alarm priority
• Delivery of alarm to users via SMS
• Delivery of alarm to users via E-mail
• Trigger other actions including sequences
• Integrated paging facilities shall be provided without the need for additional software.
• The paging facilities shall include calendar operation for roster based user lists with flexible
interface for reconfiguration of alarm management
Tracking of alarms shall provide as a minimum:
• Alarm activation including point name, state, timestamp, priority
• Alarm de-activation
• Alarm acceptance including time, user responsible, optional comment
• Custom alarm fields for display of additional or operations specific information
Where a full function Rich Client is connected to multiple SCADA systems, alarms from all systems shall be
combined and filtered, based on user privilege and areas of responsibility.
System administrators shall be able to configure user accounts with default filters so tha operator alarm lists
can be confined for users to those areas where they assume responsibility.
Full function Windows & Web clients shall provide indication of alarm condition, with the ability to change
alarm tone, color, and other attributes based on alarm priority.
Full page and window display of the current alarm list to be shown. It shall also be possible to modify the
background color of alarm lists.
Alarm display, acceptance, query and comment entry shall be available via an integrated product Web
interface.
Alarm limit time profiles allowing analog setpoint levels to vary over the course of a day to account for
conditions at the site.
Consequential alarms to allow one (or more) alarms to be suppressed as the result of another alarm
occurring.
Suppressed alarms will be received and processed by the SCADA Server and recorded in the event journal
for future auditing, however the operator shall not be forced to take an action on an alarm where the cause
is known
5.1.3.7.9. Event Journal
The system shall provide, as a built in feature and without the requirement for custom or external software,
facilities for event logging. These facilities shall be separate from the alarm list and include the capability to
insert user comments at any place in the event list.
Event lists shall be obtainable through query or filtered through user entry on a forms-based display.
Event data is to be stored in a time-series relational database. Each event record shall comprise a timestamp,
responsible user, point name, message, and reason for event log.
The event journal shall support the following:
• ODBC / SQL interface to event data
• Filter and browse via full function display client
• Filter and browse from Web client interface
PwC 36
5.1.3.7.10. Historical Data
The SCADA system shall provide a built in data historian with the following facilities as standard features.
These shall be provided without the addition of external software modules:
• Time-series relational database
• ODBC / SQL interface to historical (trend) data
• Historical data to be stored with time-stamp, point quality, alarm status
• Historic storage is to be based on configurable criteria including time between samples,
alarm state change
• Compression capability
Historical files supporting fixed interval sampling only will not be accepted. Where historic data can be
retrieved through communication devices such as PLC / RTU/PLC / RTUs, the
Historic data sub-system shall natively provide the capability to backfill this data in to the historian. No loss
of data or gaps in data as a result of communication or server failure shall be accepted. The vendor must
demonstrate its ability to ensure data integrity and history data recovery. An API shall be included to provide
interface capability with the SCADA database. This shall be based on OLE Automation and/or .NET
The historic data subsystem shall provide fixed and user configurable views of the historic data tables. These
views are required to provide SQL pre-processing and present historic data in aggregate format.
The SCADA server shall provide Historian functions including the capability to validate historic data prior
to exposing it externally to the SCADA system, selectable archiving rates, point-by-point storage
compression regimes, annotation on history samples for tracking comments on operational conditions,
modification of historic data for normalization and correction (tracks previous value and modifying user
and is subject to user privilege), auditing of modified or annotated history.
5.1.3.7.11. System Security & Access
The SCADA system shall provide a high level of inherent security. To this end the SCADA software shall
provide security access down to data point level, and support individual Users, User Groups and a matrix of
system capability and access to any level of the SCADA database.
Full function Rich & Web client interfaces shall require explicit administrative configuration to valid
connection to the SCADA server.
Web interface facilities shall provide the capability to operate the Web interface using SSL and encrypted
data. The Web functionality shall be provided in an integrated way with the web server facility tightly
coupled with the SCADA database. It is not acceptable for the system to utilize IIS or similar external web
interfaces, or require web pages to be “published” from the SCADA system. Changes in configuration to the
SCADA system shall not require additional steps in order to provide modified information to the SCADA
Web interface.
The SCADA system security shall provide the ability to be integrated with Windows domains to authenticate
logon attempts against a trusted domain. Validation should occur across all client interfaces, ensuring that
users utilizing all types of clients are subject to the built in system security policies.
5.1.3.7.12. Open Connectivity
To provide easy access for customized reports and external data manipulation the SCADA software shall
provide inherent OPC and ODBC database connectivity without the need for additional software options or
modules. Integration with standard desktop computer products is essential
The following Open interfaces shall be provided as integrated components of the SCADA system are
required:
• OPC Data Access (OPC-DA) to the SCADA server real-time and configuration database
• ODBC and OLE-DB to the SCADA server real-time database, historian, event / parameter
journal and configuration database
• OPC Historic Data Access (OPC-HDA) to historian
• OPC Alarm & Event (OPC-AE) to event sub-system
PwC 37
• OLE Automation interface to the SCADA server database
5.1.3.7.13. Reports
An integrated reporting package shall be able to generate, print and export reports:
• Triggered by SCADA events
• On user demand
• On timed schedules
Report generation shall use latest technology in database access and be capable of combining data from
multiple databases via ODBC/SQL. This shall include SCADA and non-SCADA databases. Reports shall be
able to be generated in a number of formats including:
• HTML for viewing via Web interface
• PDF format
• CSV format
• MS Office® suite format
Generated reports shall be able to be:
• viewed in Rich Clients and Web Clients
• printed on a local or network printer
• stored on disk file, locally or remotely
• e-mailed to assigned users
5.1.3.7.14. Standard Drivers
• The SCADA system shall provide native support for fully integrated Wide Area SCADA PLC
/ RTU protocols.
• This shall include the capability for supporting all protocols in redundant SCADA server
configurations and support
• redundant communication paths.
• All drivers shall provide the ability to monitor communication statistics, log driver
diagnostics, and provide online
• access to driver and channel diagnostics remotely via Telnet or similar mechanism.
Captured diagnostics shall be able
• to be translated to HTML for analysis in clear human-readable format.
• Apart from PLC / RTU and PLC / RTU communication drivers, the system shall also
support as standard the following drivers:
a. SMS (with TAP and UCP service) to mobile phones and pagers with a GS or
CDMA modem connected directly to the SCADA server.
b. a full function system is required including calendar based rosters
c. SNMP – monitoring of network devices such as routers, computers, UPS, etc.
d. NTP – time server monitoring and alarming
e. ODBC – query data from other databases
f. Windows Performance Monitoring
g. OPC-DA driver
Wide area PLC / RTU protocols shall support:
• local serial port communication
• terminal server serial port communication
• Ethernet LAN communication via TCP and UDP ports
• time synchronization
• presetting output configuration points where configured
• fully integrated incorporation of events from a PLC / RTU
• unsolicited exception reporting
• Where PLC / RTUs utilize the DNP3 communications protocol, those devices must support
the DNP3
• Secure Authentication standard.
PwC 38
All drivers shall support capability to update SCADA database point value / alarm state / point quality /
timestamp. PLC / RTU protocol drivers shall support the ability the backfill time-stamped data into Event
Logs, Historic Data to maintain data integrity in the event of communication failure
The driver architecture shall support user accessible interfaces to access major driver functions. This shall
include, but not be limited to:
• enable / disable PLC / RTU communications
• trigger an integrity poll
• alter communication parameters
Drivers shall maintain current state of target device information, and when used in redundant server
architecture shall retain state information and be able to receive solicited and unsolicited information from
the PLC / RTU immediately following a server transition. It is not acceptable for the system to indicate
communication failure or not be able to receive communication from a remote device during the period of
transition from one server to another
The following protocols shall be supported and integrated with the product:
• Modbus Master serial protocol
• Modbus Slave serial protocol
• Open Modbus/TCP Master protocol
• Open Modbus/TCP Slave protocol
• OPC-DA client driver (for connection to OPC Server driver)
The OPC-DA interface shall include as a minimum, integration with SCADA database value / state / quality
/ timestamp data, support OPC-DA 1.0 and 2.0 specification interfaces, polled and exception modes, tag
browsing.
5.1.3.7.15. Logic
The SCADA system shall support logic sequences with full access to all SCADA system services at run time.
Programming of sequences shall be to the IEC61131-3 international standard and support as a minimum the
following languages:
• Ladder Diagrams
• Function Blocks
• Structured Text
• Sequential Function Charts
Sequences shall be able to me modified and started and stopped online. Sequence changes shall be a native
part of the database and replicated to redundant SCADA servers. Special scripting languages to perform the
control strategy will not be accepted.
5.1.3.8. Process Historian
The historian software should be based on open, standard technologies. The Historian software should help
the plant and IT personnel to optimize operational efficiency by providing a powerful, enterprise-wide
reporting tool that collects, historizes and delivers meaningful reporting data from multiple, disparate
systems. By using the information provided by the Historian, one should be able to make more effective
decisions toward optimizing operational performance.
The package comprising of historian and portal functionalities, should enable the user to accurately store
data for long-term reporting while also giving the user the option of visualizing and accessing the
information through the Historian portal, Excel or Reporting Services.
5.1.3.8.1. Software Details
i. The software should improve production reporting and ad-hoc analysis by connecting, aggregating
and presenting real-time information from multiple disparate systems throughout the enterprise,
allowing corporate, IT, plant and production managers to make more informed and timely
decisions.
PwC 39
ii. The historian should collect all changes in the process tag values, as well as alarm activity, from
within each control system. Each change should be saved with a timestamp and an OPC quality
stamp. Data should be acquired at user-definable rates, including sub-second data acquisition rates.
iii. The historian should support redundant control system links. In the event that one link fails, the
historian should request the data from the other link to the control system. In the event that the
network link to the historian fails, the historian should backfill from the control system’s trend and
alarm systems to acquire data that it could not acquire in real time. Quality flags should be stored
using the OPC status and sub-status definitions in conjunction with customized high-byte sub-
statuses to accurately reflect the status of the SCADA system data at any point in time.
iv. The historian should compress data by saving only changes in values. The data should be stored
directly into tables in the database Server; so that the large number of applications that have
DATABASE connectors can access the data and bring it into various applications. The historian
should leverage the security of the DATABASE Server to enable the user to secure each table, view
and function within the DATABASE Server. The user should be able to utilize Standard DATABASE
audit tools to see if any unauthorized editing of databases has occurred.
v. The Historian should be able to acquire data from SCADA systems via OPC V2 and OPC V3 servers
at sub-second retrieval rates.
vi. The Historian should be provide easy configuration like simple drag-and-drop techniques for
selecting data to be logged from SCADA systems, and a user-defined folder structure for organizing
logged data. Customization of individual tag parameters should be provided through easy-to-use
forms that identify aspects of the data to be logged.
vii. The Historian should offer web functionality. The Web Client should provide maintenance
engineers with a fast way to analyze trend and event data and to compare real-time and historical
data within one interface.
viii. The historian should comprise a Microsoft Excel Client which provides engineers and operations
managers with the calculation tools they need to model and analyze production. It should provide a
high quality reporting system using Reporting Services to build custom reports for any process
application where data be presented graphically, with the ability to drill down for more detail into
any results that may appear out of the ordinary.
ix. The Historian software should connect to one or more plant control systems via OPC. The software
should automatically import the tags, trends and alarms, making them available for immediate
publication. It should support bi-directional data transfer allows data to be read from, or written to
(with security privileges), plant control systems.
x. The historian software should support connections to all type of databases. Once the database data
source is created, it should automatically load the table structure. The software should be designed
to handle both
Data archiving
Plant control system connections integrating plant floor data with existing third-party applications or ERP systems.
xi. Operation of the software with Enterprise Edition of DATABASE Server 2008 R2 should also be
supported, so that users wishing to use the Enterprise Edition can also benefit from data
compression.
xii. The software should use OPC HDA Server as standard protocol for freely connecting to
manufacturing execution systems (MES) delivering a fully integrated solution allowing the
movement of information vertically from the factory floor throughout an enterprise with multi-
vendor systems.
xiii. The software should support OPC DA Client, an industry standard protocol, for connectivity to any
third-party SCADA system. The Historian software should provide direct access to tag alarm and
PwC 40
trend information from within the SCADA systems. This data can be transferred to business
applications or visualized within the Historian’s Web and Excel Clients, enabling data from multiple
SCADA systems to be compared and analyzed or histories to the historian for long term storage and
greater analysis options.
5.1.3.8.2. Reports & Alarms
i. The historian software should use the graphical query builder and report generation capabilities of
Reporting Services to deliver drag-drop-and-click reporting of any data from the historian. The user
should be able to schedule to run the reports based on an advanced scheduler. The functionality to
send scheduled reports to managers by email or recorded in a file share should be provided. In either
case, the user should be able to select to receive the report as HTML, PDF or an Excel spreadsheet.
ii. Alarm management is a set of procedures, practices, tools and systems that jointly assist in making
sure a plant’s alarm system is effective throughout the life of the plant. The historian should provide
pre-configured alarm rationalization reports based on the EEMUA (Engineering Equipment &
Materials Users Association) 191 alarm management guidelines.
iii. The historian software should contain ready-to-use energy reports that can facilitate energy
consumption assessment and potential savings across the equipment level, production lines, an
entire plant or multiple sites.
iv. The package should contain an intuitive visualization tool that allows operators and process
engineers to analyze the cause of process disturbances by bringing together trend and alarm data
on a single integrated display. The user should be given complete flexibility with regards to the ways
in which the pens can be displayed. For example, they can be overlaid or stacked or even moved to
different panes to reduce clutter and make the display simpler and easier to read.
v. The Analysis tool should include features such as true Daylight Savings Time support, accuracy to
millisecond resolution, and individual time axis per pen, customizable toolbars, rich printing and
saving of display settings for easy recall.
PwC 41
5.1.4. Detailed Analysis of Plant Automation
Plant Automation component includes the systems which are needed to automat a Water Treatment Plant.
The major part of this component is Programmable Logical Controller and Area Control Panel.
5.1.4.1. CPU specifications
The processors must have an internal non-volatile memory to store application and data. Processor must also have a reserved slot for a removable cartridge so that the application and data backup can also be performed also on a mobile device.
A program written for one CPU can be executed by another CPU in the range as long as it has sufficient capacity.
It must be possible to connect a PC (programming terminal) or a human-machine interface via a USB port integrated in the processor.
Embedded web server must provide CPU diagnostic, including detailed information on Ethernet system networking.
The Embedded web server must display application variables and advanced diagnostics features (rack viewer, alarm buffer, complete PLC application)
Each processor should have a savable real-time clock which manages:
o The current date and time
o The date and time of the last application shut-down
o The date and time should be managed even when the processor is switched off for 20 days.
NTP server must be provided within the CPU.
The processors must be equipped with ground connection contacts without additional cabling.
The performance capacities of the various processor models are to be expressed in terms of execution time for 1K List-equivalent instructions for the two application profiles defined below: Most powerful controller must process at least:
50 Kinstructions / ms for Boolean application
40 Kinstructions / ms for Numerical application
The PLC must be able to load the program without the use of programming software, just with the use of the memory cartridge.
It must be possible to add modules or add remote I/O islands in the configuration without stopping the controller, as well as changing the application or variables.
Processor must provide cyber-security features, such as real-time memory integrity control, access control…
The complete environmental footprint of the product must be known, such as equivalent CO2 consumption during each phase of product life.
The operating system (OS) must be capable of multitasking with up to 4 periodic tasks and more than 60 event or I/O tasks.
The I/O and channels (counter, etc) of the various modules can be assigned to each task.
The PLC RUN/STOP functions can be remotely controlled by setting the parameters of an input channel.
It must be possible to assign a chosen physical input to prohibit any modification or downloading of the program.
It must be possible to maintain the outputs or set them to fallback position when the PLC switches to STOP mode via channel by channel parameter entry.
Execution of the warm and cold restart procedures is available by system bits which are accessible by the program and terminal.
It must be possible to perform a functional update of the processor by simply downloading the firmware through the dedicated software or the programming software platform. However, it must
PwC 42
also be possible to use a more recent version of the programming software without having to update the firmware of the processor.
To help in debugging applications, it must be possible to set breakpoints and watch points in application so that customer can check all system and data when executing his application. System must also provide Step-by-Step running feature to execute all operations one by one in the application.
Engineering tool must provide a trending tool embedded to display variables at a minimum of 1ms sampling rate
Hot standby synchronization signal link should not be more than 10ms and failure detection time should not be more than 20ms in the worst case.
The processor should be provided with 16MB as minimum of integrated non-volatile memory to save whole application and data, even in redundant configurations. A Removable memory cartridge must provide up to 4 GB of memory capacity
Operating system running on this removable memory cartridge must insure a high level of reliability to be compliant with industrial constraints to support for example extraction of the cartridge during execution.
It must be possible to store the program, comments and symbols in the PLC to enable connection of the programming tool without having the application on it. The "empty terminal" functionality must be possible whichever IEC language is used. It must be also possible to use the memory extension to back up files (production data, recipes, etc)
It must be possible to secure access to application stored on the cartridge to prevent the run of application from any controller
All products must be designed with eco-design requirements (Green Premium)
5.1.4.1.1. Distributed & Remote configurations
The communication functions of IP20 remote I/O modules must be independent of the input and output interface functions. It will therefore be possible to connect any module to the main field bus standards (multi-bus openness) including, amongst others:
o Ethernet 10/100Mbps
o Serial links
o AS-i
System must also support in remote configuration expert modules, such as counting, and weighing functions.
System must support in same network a mix of synchronized and unsynchronized drops and equipment with PLC scan.
Connection to synchronized or unsynchronized drops must be provided through ring topology to insure quick recovery (<50ms) in case of one cable failure.
Supplier must provide an opened system where it must be possible to integrate third party device based on standard technologies.
The supplier must have an IP67 offer. The IP67 dust and damp proof remote I/O modules, equipped with a fast connection system using M23/M12 type connectors, must be able to provide a remote power supply to the modules via a single cable.
5.1.4.1.2. Input and Output Modules
The I/O module assembly will consist of a mounting base, I/O module, and field wiring connector(s).
The I/O module will plug into the base, allowing “Hot Swap” capability where the modules can be inserted and removed without removing power or shutting down communications.
The plug-in connectors will plug into the front of the I/O modules and can be removed without the need to disconnect the wiring.
There must be a locating device for the modules, and automatic checking of conformity with the system software configuration to ensure that errors are avoided during module replacement.
PwC 43
All modules have a display block for identifying module and channel faults: input, output, bus device, axis, etc. These diagnostics are performed without using any special tools.
The modules are fully configurable by setting parameters in the development and runtime software. The parameters are stored in the PLC application and are automatically reloaded by the CPU if a module is exchanged.
All I/O modules should include a front mounted LED status indicator each input or out point to indicate the state of the inputs and outputs.
All modules shall be enclosed in rugged plastic housings with an environmental rating of IP20.
The catalogue should offer high density digital I/O, 64 I/O minimum, on one slot width module.
The high speed communication backplane of the I/O drop will be used to communicate the I/O states, data, and status information between the I/O modules and the communication network interface module for the I/O drop.
The I/O modules shall be capable of connecting directly to 2 and 3 wire devices and is capable of providing the power for the field mounted sensors and actuators.
The digital I/O modules should include versions that will connect to 24 VDC, 120 VAC and 240VAC field devices.
The 24 VDC digital input modules should be able to interface with either IEC type 2 or type 3 field devices
The digital output modules should include protection against reverse polarity, short circuit, and overload of the outputs, with automatic recovery.
The digital input modules should include the option for user selectable input filter time and input polarity.
The digital output modules should include the option for the user to select modes for fault recovery, output polarity, and fallback states.
The digital input modules should be available in versions that have 16, 32 & 64 points that will allow the user to select the number of I/O points that are required at each location.
The analog input modules shall have a maximum of 8/16 channels per module and shall accept 4 -20 mA signals inputs from field mounted transmitters. Input signal conversion shall be a minimum of 12-bit resolution.
The analog output modules shall have a maximum of 8 channels per module and shall convert 12-data bits into proportional 4-20 mA analog output signal.
For temperature measurements the I/O sub-system should include a multi range module of maximum 8
channels of thermocouple input that directly connects to Thermocouples, type B, E, J, K, R, S, and T. There
should be a multi range module of maximum 8 channels of RTD input to connect to RTD’s type Pt. 100, Pt.
1000, Ni 100, Ni 1000, and Cu 10, as well as a mill volt input,± 80 mV.
5.1.4.1.3. Ethernet communication
System must integrate in its communication layers standard Ethernet.
Synchronized and unsynchronized drops with PLC scan can be managed over standard and open Ethernet communication.
Communication network must be the same everywhere in the system, from control level to field level insuring network continuity from top to bottom.
Offer catalog must offer in rack Ethernet modules to build the entire integrated architecture. For example, offer must provide in-rack switches, Wi-Fi access point, and fiber optic converter.
Two types of exchanges of variables must be provided:
o Explicit exchanges (via function blocks integrated in the application)
o Implicit exchanges (Using cyclical variables generated by the single declaration of the device)
No prior declaration or configuration of the transmission or destination device is necessary for using communication function blocks.
PwC 44
A set of dedicated function blocks can be used for the simple setup of communication, doing away with the need for coding communication requests specific to each protocol.
The range must offer processors which have multiple integrated Ethernet connections with at least one Web server for diagnostic purposes, and one service port.
The range must offer separate Ethernet module that extends Ethernet connections with at least one Web server for diagnostic purposes or advanced web server services to control application, local configuration or complete system. System must accept a maximum of 4 of these Ethernet modules.
The PLC must be able to connect to the Ethernet network via integrated ports modules on a shielded twisted pair via an RJ45 connector.
The Ethernet connection must support SNMP agent functions for the standard MIB II base (RFC 1213).
The PLC must be accessible via Ethernet (from a remote site) using a standard Internet browser (Microsoft Internet Explorer type), or any other platform (android, iOS). A Web server must be installed in the PLC. It must provide functions for Ethernet communication diagnostics. These functions must not require any prior configuration or special software. In addition, the use of these functions must have no effect on the PLC scan time.
Variables or animated objects in the Internet browser’s web pages must be refreshed automatically from the PLC using a standard Internet protocol, without having to update the entire page.
The offer must have a solution to enable remote I/O exchanges on Ethernet TCP/IP or EtherNet / IP without any programming in the application. A device must be reconfigured automatically after replacement
There must be a mechanism for checking the bandwidth in order to simulate the load on the connection when it is configured.
5.1.4.1.4. High Availability
The range must at least include a processor designed to be part of a redundant architecture, obeying a principle of redundant controllers which guarantees a switchover without loss of control of the process on occurrence of a failure.
In case of a redundant processor configuration, the system is designed to have a bump less transition (no unattended spike on the IO during switchover)
The processors shall have to be dedicated to the services of the redundancy, and won't have to be associated with any specific coupler, configuration, nor specific programs. The implementation of the redundant solution shall be "plug & play" by design.
The data exchanges between the two redundant processors (Primary and Standby), are using a very high speed link of 1 Gbps.
The whole redundant variable database must be exchanged during each scan time, with a minimal impact on the cycle time of the system.
The user is able to select which variables are redundant in the application
The two processors can be distant up to 15 km. The dedicated redundant connection between the 2 processors can either be using fiber optic or copper RJ45 cable
The application logic program can be modified while the system is running, and without compromising the redundancy function
The redundant system must be seen by the SCADA as a single PLC (one IP address). The system manages in all transparency and automatically the IP address swapping of the Ethernet couplers.
The redundant controllers have their own IP addresses that never swap, in order to connect the engineering tool continuously
The system components internal firmware can be updated while the system is running without losing the redundancy function
The redundant power supplies used must provide a transparent status of their redundancy without extra hardware or wiring
The redundant power supplies must provide natively information about their ageing, to be able to be replaced before failure (preventive maintenance)
PwC 45
The redundant power supplies must use a true redundant technology (one active at a time, the other ready to take full load if needed), not using load sharing technology
5.1.4.1.5. Cyber Security
The system must be compliant with IEC – 62443 standard
The system MUST be Achilles level 2 certified
The system must have passed successfully the CSPN test
The system must be able to secure communication between PLC and engineering workstation providing authentication and integrity of data
The system must be able to secure communication between PLC and SCADA providing authentication and integrity of data
The system must be able to log any PAC security events into any SYSLOG database
The internal firmware of the CPU must be digitally signed and encrypted
The integrity of the firmware must be checked before any application download and at startup of the system
The integrity of the engineering software must be checked on demand
The user must be able to disable the following Ethernet services : FTP/TFTP/HTTP/EIP/DHCP/BOOTP/SNMP
The system provides an access control list for each protocol and each connected IP address
Any modification of the operating mode of the system (Run / Stop / Program modifications . . . . ) must be authenticated
5.1.4.1.6. Standards and certifications
The PLC must conform to the main national and international standards covering electronic equipment for industrial control systems:
a. CE marking according EN 61131-2
b. CSA 22-2 N° 142 (Canadian Standards Association)
c. UL 508 (Underwriters Laboratories)
d. C-Tick ACA (Australian Communication Authority/Australia)
e. CSA 22-2 N° 213 Hazardous Location (CSA)
f. FCC Part 15 – Class A
g. GOST CEI
The PLC must conform to the main certifications relating to marine classification:
a. BV (Bureau Veritas/France)
b. DNV (Det Norske Veritas/Norway)
c. GL (Germanischer Lloyd/Germany)
d. LR (Lloyd’s Register/United Kingdom)
e. RINA (Registro Italiano Navale/Italy)
f. ABS (American Bureau of Shipping / USA)
g. RMRoS (Russian Maritime Register of Shipping / Russia)
The PLC must conform to Ethernet robustness certification :
a. Achilles Level 2
b. Be compliant with IEC – 62443 standard
PwC 46
5.1.5. RTU’s for Distribution & Intake networks
Automation component includes the systems which are needed to automat a Intake & reservoirs. The major
part of this component is Remote terminal Unit and GPRS connectivity modem.
5.1.5.1. RTU Technical Specification
5.1.5.1.1. Major Functionality of RTU
• Functionality to map the field devices
• Provide communication connectivity to the all the slave devices through Serial
Communication or TCP/IP communication
• Provide a communication facility to the field devices through serial communication through
RS232 port via a serial communication device viz. modem etc.
• Should have a ability to collect data from all connected devices, regardless of protocol and
make it available to the control centers & WMS using a LAN,WAN connectivity
• Should act as a protocol translator to ensure interoperability with the protocols defined in
the communication principle section
• Should be capable of handling real time data exchange services to publish or subscribe
information for defined master and slave protocols
5.1.5.1.2. Specifications of RTU
The PLC shall be non-redundant, modular. The controller shall at least include the following base I/O and
further expansion shall be possible using expansion modules .The RTU shall be as per the following
specifications:
• Digital Inputs: 16 (24 VDC)
• Digital outputs: 10 (24 VDC Transistor/ Relay)
• Analog Inputs: 8 (Min.12 Bit resolution)
• Analog Outputs:8 channels/ Module
5.1.5.1.3. Communication protocol for RTU
• The RTU shall possess a minimum of three built-in communication ports with the
following characteristics:
• Two serial port (DTE) jumper-configurable to RS-232 (full or half duplex RTS/CTS
control) or RS-485 (two-wire half-duplex) with operation to 115,200 baud
• One USB 2.0 ports, Type “B” Peripheral
• The RTU shall support asynchronous operating mode, half and full duplex transmission
• The RTU shall support the industry standard DNP3 protocol, with the following minimum
features:
DNP3 Level 2 conformant with most features from Level 3 refer to the Device Profile for additional information
Local and remote configuration via DNP3 and file transfer Peer-Peer communications Routing - serial-serial communications Issue controller commands remotely (file, application, event management,
diagnostic capture, etc.) Reporting to up to 3 independent DNP3 Masters
• The RTU shall support the industry standard Modbus protocol, with the following
minimum features:
Allows up to 65,535 stations in one system.
Ability to transfer complete programs and data over the communication network.
Support high data security techniques such as Cyclic Redundancy Check CRC16
PwC 47
Proprietary protocols will not be allowed.
5.1.5.1.4. Power Distribution Modules
The power distribution modules will provide the power for the sensors and actuators connected to
the Input and Output modules. The power connections to the modules will be through the internal
connections on the I/O drops communication bus to reduce the amount of external wiring.
The power distribution module should include versions that are capable of directly connecting to
120/ 230 volts ac line power in the frequency range from 47 to 63 Hz, or 24 vice power, to provide
the voltage to the sensors and actuators connected to the I/O modules.
The power distribution module shall have separate power connectors to provide dedicated power to
the input sensors and the output modules actuators. This will allow the user to disconnect the power
to the output devices during servicing while maintaining power to the inputs.
5.1.5.1.5. LOCAL HMI for PLC/ RTU
The purpose of Local HMI is to indicate current status of the level, pressure, flow, energy data and water
quality etc.at the field stations.
The HMI shall also act as an aid to facilitate Pop up alarms, enter time delays, and operate the necessary
equipment. The HMI shall have 1 printer port and 1 USB port as a minimum. The HMI shall be Touch screen
with minimum diagonal screen size of 6”
5.1.5.1.6. Programming Software:
The programming software shall allow downloading of Relay Ladder Logic and/or standard C++ programs
from within one package. The software shall allow the user to develop and download the application and
system configuration over communication network via radios, Ethernet, leased and dial-up lines. The PLC
/ RTU shall allow Ladder and/or C++ applications to run concurrently. Any failure in the Ladder application
shall not affect other applications.
The Relay Ladder Logic shall include the following functions:
• Data logging function with time & data
• Modem dialing and control.
• Timers, counters, mathematical functions, memory functions.
• Standard Ladder Logic functions such as coils and contacts.
• Boolean logic functions.
• Bit transfer functions.
• Block transfer functions.
• Scaling function
• Totalizing function
• Flow function
On-line monitoring of Relay Ladder Logic power flow shall be included to facilitate start-up and debugging
of programs.
Relay Ladder Logic program shall be up to 12K words in size, with no fixed limit on the number of networks.
The programming software shall support on-line monitoring and forcing of any register in the protocol
database when utilizing the built-in protocol. Forcing shall write a value to the register and prevent
modification of the register content by the communication protocol or the application software. A global
command to remove all forcing must be included.
In addition to forcing, the software shall be capable of writing a value to any register in the protocol database
but continue to allow the protocol or application software to modify the contents of the register
PwC 48
5.1.5.1.7. Data Logging Functionality
The Controller shall support Data Logging via Removable USB Mass Storage devices which include:
• USB Flash Memory Stick
• USB External Hard Drive
• Log to USB Mass Storage
• USB mass storage device remains connected to controller
• Multiple data logs may be configured to write data to USB storage (Data is buffered to non-
volatile RAM and written once per minute.)
• At some point in time when the USB storage device is removed, the data continues to be
logged, but is stored to internal non-volatile memory.
• When a USB storage device is re-inserted the buffered data is copied to the USB storage
device
The unit must also support IEC 61131-3 programming using Sequential Function Chart (SFC), Functional
Block Diagram (FBD), Ladder Diagram (LD), Structured Text (ST), Instruction List (IL), Flow Chart (FC)
languages using a separate programming tools
5.1.5.1.8. Managed Ethernet Switches
General
Managed Ethernet Switches are considered as key components to ensure system performance and
must be furnished by the same vendor who is supplying the other system hardware and software to
insure compatibility and interoperability.
The Managed Ethernet Switches must be designed to operate in industrial environments with
specifications and MTBF figures that are consistent with the rest of the system.
Switch Features
The system must support a range of Managed Ethernet Switches that includes models that have 4
Ethernet ports up to models that include 24 Ethernet ports.
The basic models of the Switches will support for communications over copper cable distance up to
100 meters. The range must include models that have Fiber Optic communication ports supporting
Multimode fiber optic cable lengths up to 5000m for multi mode or single mode fiber optic cables
lengths up to 30,000m, for long distances and for use in high electrical noise environments.
All models must have loadable firmware that is stored in non-volatile memory. This will allow for
firmware upgrades in the field to take advantage of any new features or capabilities.
The Switches must use an RJ 45 connector for the ports supporting copper wire cables and uses
duplex SC connectors for ports supporting Fiber Optic cable.
The ports of the Switches must support 10/100 Mbps communication rate with an option for ports
that will support 1000 Mbps communications. All ports will include auto negotiation capability for
the communication rate and for half/full duplex modes of operation. Auto crossing (MDI/MDI-X)
must be supported when auto negotiation is active, and there must be a configuration option to
manually set cable crossing (MDI/MDI-X), and communication rate.
The Switches must include as a minimum, front mounted LED Indicators for correct supply voltage
level, communications status, faults, and standby status.
For Ethernet/IP applications, the Switches must have the ability to function as an Ethernet/IP
adapter. This will use the Common Industrial protocol (CIP) for implicit real-time I/O messaging
and explicit messaging to obtain switch information and make limited configuration changes that
are not time critical. The Switches must have the ODVA Declaration of Conformity.
PwC 49
The Managed Switches must support Fast Device Replacement as a method of handling the
configuration of a replacement switch and minimizing downtime in the event of a failure. The
switch configuration can be downloaded from a server to the switch.
Flow control capability in accordance to the IEEE 802.3 standard must be included as a standard
feature of the Switches providing message overload protection during periods of high traffic.
Message priority capability must be included as a selectable feature of the Switches. They must
support 4 priority levels to insure that high priority message traffic is not disrupted by other traffic
during busy periods. The switch will send all data packets with a higher priority level before sending
data packets with the next lower priority level.
Port based VLAN (Virtual Local Area Network) capability in accordance with IEEE 802.1Q must be
available for the Switches to offer the option for the user to create a logical subgroup of devices
within a larger network.
Traffic Limiter capability on a per port basis must be available as a selectable feature to improve
data exchange reliability during periods of high rates of traffic. Traffic limiting must include the
ability to configure a rate limit for all types of data packets transmitted or received.
The Managed Switches must support GMRP (GARP Multicast Registration protocol) and
IGMP/IGMP Snooping for multicast filtering.
To provide synchronization of the system time on the network, NTP (Network Time Protocol) must
be supported, including both the server and client functions.
The Managed Switches must offer RSTP support in at least 2 of the ports to allow the creation of
fast-healing rings.
The Managed Switches must support full LLDP (i.e. transmit, receive and MIB)
Diagnostics
The Managed Ethernet Switches must include diagnostic capability that will enable the user to
monitor the operation of the switch locally as well as from a remote location.
The diagnostic capabilities of the switch should include:
i. Product information, such as model number and manufacturer, Hardware and Firmware
versions, and device capabilities.
ii. Port mirroring that copies all communication traffic passing through one port (source) to
another port (destination).
iii. SNMP Trap that is user configurable, for selected device parameter statuses
iv. Connected device status log
v. Port diagnostics and statistics
vi. Event Logs with up to 2000 events with time stamping
vii. External alarm contact de-energized on fault that can be an input to the controls system.
The Switches must include standard remote monitoring capability that enables network
information to be gathered at a single workstation. The type of information gathered includes
packets sent, bytes sent, packets dropped, statistics by host, by conversations between two sets of
addresses, and selected events.
Switch Configuration
The manufacture must have available all of the product documentation covering the installation,
configuration, redundancy capability, and Web Management interface for remote monitoring.
PwC 50
The configuration of the switch can be performed with either a local direct connection to the
switch or through a network connection. The local connection enables the switch to be
configuration before installation and the network connection will enable configuration of Switches
already installed.
The switch configuration data can be stored remotely on a server connected to the network or
locally backed up to a USB memory backup adapter that would directly plug into the Managed
Ethernet Switch. In the event of a switch failure the configuration can be downloaded from either
storage device to the replacement switch to reduce downtime.
The configuration software will have the ability to detect all of the Switches connected on the
network and display their IP Parameters information.
To protect against access by unauthorized personnel to the switch configuration data, the software
must offer the capability for a user selected password set in the Log In screen of the configuration
software.
Security
To protect against unauthorized access the Managed Ethernet Switch must include security
capability that includes the following:
Port security that is based on the IP address or MAC address that protects every port on the switch
from unauthorized access, by only allowing assigned users access to the port. The settings for port
security are made via a Web based software tool for ease of use that can be accessed from the
engineering station.
SNMP V3 security capability for the Web based user interface that provides encryption for the
access password with a complex calculation for keystrokes, making it difficult to use brute force to
gain access.
Standards and Approvals
The Managed Ethernet Switches should include the following agency approvals:
UL – 508 and 1604
CSA – 22.2 No. 142
CE Mark per EN61131-2
FM Class 1, Div 2
UL1604 Class 1 Div2
C-Tick for Australia
Substation IEC 61850 EMC levels tested
Maritime approval (GL)
5.1.5.1.9. Network Firewalls
General
An Industrial Ethernet Firewalls provides a wide range of security tools for creating secure
zones within an industrial automation environment. Firewalls operate on the basis of rules
established by the process owners, specifying the network actions that will be allowed or
blocked by the device.
Industrial Firewalls are an essential device and the first line of defense in cyber security.
Industrial Firewall Features
Firewalls will provide Ethernet connectivity through on copper cables and fiber
The firewalls will be able to operate in Layer 2 mode, as a switch; in Layer 3 mode, as a router; or
in PPPoE (Point to Point Protocol over Ethernet).
The firewalls will be equipped with Access controls, including:
PwC 51
SNMP v1/v2/v3 password
SSH (Secure shell protocol) access
External authentication
Packet Filter for creating Firewall rules that includes:
Incoming IP packets from device connected to external port
Outgoing IP packets from device connected to internal port
Incoming MAC packets
Outgoing MAC packets
Incoming PPP packets received at serial port
NAT (Network Address Translation) that includes:
P Masquerading
1:1 NAT (network address translation)
Port Forwarding
Network security capabilities that include:
IP Masquerading
1:1 NAT (Network address translation
Port forwarding
DoS (Denial of Service)
Multiple user firewall entries (maximum 32)
VPN (Virtual Private Network) connection capability with up to 256 active VPN connections on
the external port with names assigned.
Firewall Learning Mode (FLM) that analyzes communication traffic and creates firewall rules
Redundancy capability that allows the Firewall and its communication connections to operate in a
redundant configuration for higher availability. Two modes are required:
Network Transparent mode, where one Firewall is connected each into the paths of two
redundantly coupled networks.
Router mode, where a Firewall is used to install a redundant line and a redundant Firewall
for an existing connection between two networks, the Firewall must be configured in the
Router Mode.
Time Protocols available to synchronize the time in the network using SNTP or NTP.
The Firewall Diagnostic capabilities include:
Ports – Utilization, Statistics, and ARPS
Topology Discovery
Device Status
Alarms (traps)
Reports – System Information
Firewall list – MAC and IP address
PwC 52
5.1.5.2. RTU/ Data Logger for Intake & UGR’s
HMI: Graphics Touch Screen Panel
Modems :
Ethernet or serial radios, GSM/GPRS modem,
Third party modems used (PSTN, 3G modems, DSL modem/routers , ,..)
System Security:
RTU should support DNP3 Level 4 subset features, providing both
DNP3 secure authentication
AGA12 encryption of DNP3 protocol
These authentication and encryption services can be used concurrently in the same system
Other Components :
PS, Battery : DC power supply + backup battery ctrl module + battery
Energy : Connection to Utility meter
Motor control : DOL , starter , Soft Starter , Variable frequency drives
Security :. Door switch, key contact
Lightning prot. : PRC / PRI surge protector for telecom/signal
PwC 53
PwC 54
6. Estimated Cost
6.1. Summary
I. Underground Reservoir Cost - 39 locations
S.No Expenditure item Units Unit Price (INR)
CAPEX (INR) AMC No. of year
Total AMC (INR)
Total Cost (INR)
1 Remote Terminal Unit along with enclosure, SMPS+ Relays+ Terminal Box
39 453000 17667000 5% 6 5300100 22967100
2 Local LCD displays (7" Colour) 39 50000 1950000 5% 6 585000 2535000
3 GPRS Modem 39 40000 1560000 5% 6 468000 2028000
4 Online Non-Redundant UPS - 1 KVA with SMF battery
39 150000 5850000 5% 6 1755000 7605000
Total 27027000 35135100
II. WTP Location – considered 1 No WTP
1 PLC (Working and Redundant) with REMOTE I/O PANEL with I/O module, power supply module communication module, etc
1 2000000 2000000 5% 6 600000 2600000
2 Ethernet Switch for connection between PLC and HMI
1 300000 300000 5% 6 90000 390000
3 Online Non-Redundant UPS -5 KVA with SMF battery for WTP Plant
1 1300000 1300000 5% 6 390000 1690000
4 Communication Cable (WTP) 1 500000 500000 5% 6 150000 650000
Total 4100000 5330000
III. Intake Plant Cost - Considered 7 (6 Intake Plants + 1 Clearing Pump House)
PwC 55
1 PLC (Non-Redundant) REMOTE I/O PANEL with I/O module, power supply module communication module, etc complete
7 4120000 28840000 5% 6 8652000 37492000
2 Ethernet Switch and Cable for communication 1 300000 300000 5% 6 90000 390000
3 Online Non-Redundant UPS -3 KVA with SMF battery for In take plants
7 500000 3500000 5% 6 1050000 4550000
4 SCADA & Engineering PC for plant operation 7 500000 3500000 5% 6 1050000 4550000
5 Modem – GPRS/ GSM 7 40000 280000 5% 6 84000 364000
Total 36420000 47346000
IV. Master Control Centre – 1 No
1 SCADA Server with SCADA Software suitable for project requirement ( 1 Main Server + 1 Standby)
1 4000000 4000000 5% 6 1200000 5200000
2 Database Server and PC 1 2000000 2000000 5% 6 600000 2600000
3 Large LED Display – 50” 1 350000 350000 5% 6 105000 455000
4 Operating Station & Engineering station (Workstation)
4 900000 3600000 5% 6 1080000 4680000
5 SCADA Application Software 1 7000000 7000000 5% 6 2100000 9100000
6 Modem – GPRS/ GSM With M2M Gateway
1 550000 550000 5% 6 165000 715000
Total 17500000 22750000
Grand Total (I+II+III+IV)
11,05,61,100
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 56
7. Service Level Agreement
7.1. Purpose of this Agreement
The purpose of this SLA is to clearly define the levels of service to be provided by System Integrator to the
Purchaser for the duration of this contract or until this SLA has been amended. The benefits of this SLA are
to:
a. Trigger a process that applies Purchaser and Supplier management attention to some aspect of
performance only when that aspect drops below an agreed upon threshold, or target.
b. Makes explicit the performance related expectations on performance required by the Purchaser
c. Assist the Purchaser to control levels and performance of services provided by Supplier
d. This SLA is between Supplier and Purchaser
Availability quarter
Deduction as % of the apportioned price of total FMS for SCADA portion of the contract applicable for that site
> 99% NIL
Less than 99% Deduction of 2% of the apportioned price of the apportioned quarterly AMC for every 1% or part there of decrease in availability under 99%.
>98% NIL
Less than 98% Deduction of 2% of the apportioned price of the apportioned quarterly AMC for every 1% or part there of decrease in availability under 98%.
While calculating Availability following shall be considered: The Overall SCADA/DMS System shall be
considered as available if
a. All SCADA applications are available b. All SCADA functions described in the specification are executed at periodicities specified in the
specification. without degradation in the response times c. Information Storage and Retrieval applications are available d. Data exchange with other system is available e. One of the redundant hardware is available so that all the SCADA applications are functional to ensure
the design and performance as envisaged in the DPR Further, Non-Availability of RTU/Data Concentrators shall not be considered for calculating Overall SCADA
Availability.
However each device, including RTU and Servers etc. shall individually exhibit a minimum availability of
98%. Further, the non-availability of following Non-Critical functions shall not be considered for calculations
of SCADA System availability; however these functions should be available for 98% of the time.
a. Database modification and generation b. Display modification and generation c. Report modification and creation
The computation of Availability / Non-availability would be rounded up to 2 decimal places at each Contract Co-
ordination Site on quarterly basis and any deduction in the maintenance charges thereof would be calculated
as stated above on pro-rata basis.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 57
Availability would be on per quarter basis
The formula to be used for availability computation would be as under:
Availability per quarter (per site) = THQ- (S1 x 1+S2 x0.4+S3 x 0.1) x 100%
Where:
THQ is total hours in the quarter
S1 is the total non-available hours in Severity Level-1
S2 is the total non-available hours in Severity Level-2
S3 is the total non-available hours in Severity Level -3
7.2. Problem Severity Levels
Category Definition
Severity 1 – Urgent Complete system failure, severe system instability, loss or failure of any major subsystem or system component such as to cause a significant adverse impact to system availability, performance, or operational capability
Severity 2 – Serious Degradation of services or critical functions such as to negatively impact system operation. Failure of any redundant system component such that the normal redundancy is lost Non-availability of Manpower at control center during working hours
Severity 3 – Minor Any other system defect, failure, or unexpected operation
Severity 4 – General/Technical Help
Request for information, technical configuration assistance, “how to” guidance, and enhancement requests.
Severity-1 (Urgent support)-The entire WMS system is down, In this case the maximum time to
acknowledge the issue is 30.00 Min (between 6:00 Hrs. to 22:00 Hrs.) and maximum time to respond is 1:00
hrs. (Between 6:00 a.m. to 10 p.m.). In case the problem is reported during lean period (22:01 Hrs. to 5:59
Hrs.) downtime will be calculated from the next day. This unplanned downtime will not be considered as a
part of the SLA down time.
Severity-2(Serious)- Services to more than 50% and up to 75% of the WMS system are affected. In this case
the maximum time to acknowledge the issue is 30:00 Min (between 6:00 hrs. to 22:00 hrs.) and maximum time
to respond is 2 hrs. (between 6:00 Hrs. to 22:00 hrs.). In case the problem is reported during lean period (22:01
Hrs. to 5:59 hrs.) downtime will be calculated from the next day. This unplanned downtime will not be considered
as a part of the SLA down time.
Severity-3 (Standard support)-Services to more than 25% and up to 50% of the WMS system are affected.
In this case the maximum time to acknowledge the issue is 30:00 Min (between 6:00 hrs. to 22:00 hrs.) and
minimum time to respond is 3:00 hrs. (between 6:00 hrs. to 22:00 hrs.). In case the problem is reported during
lean period (22:01 hrs. to 5:59 hrs.) downtime will be calculated from the next day. This unplanned downtime
will not be considered as a part of the SLA down time.
Severity-4 (General Technical Help) - Services to up to than 25% of the WMS system are affected. In this
case the maximum time to acknowledge the 30:00 Min (between 6:00 Hrs. to 22:00 Hrs.) and maximum time to
respond is 4:00 hrs. (between 6:00 Hrs. to 22:00 Hrs.). In case the problem is reported during lean period (22:01
Hrs. to 5:59 Hrs.) downtime will be calculated from the next day. This unplanned downtime will not be considered
a part of the SLA down time.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 58
7.3. Breach of SLA
In case the Supplier does not meet the service levels for three (3) continuous time-periods as specified in the
relevant clause, the Purchaser will treat it as a case of breach of Service Level Agreement. The following
steps will be taken in such a case:-
Purchaser issues a show cause notice to the Supplier.
Supplier should reply to the notice within three working days.
Exclusions
The Supplier will be exempted from any delays or slippages on SLA parameters arising out of following reasons:-
a. Delay in execution due to delay (in approval, review etc.) from Purchase’s side. Any such delays will
be notified in written to the IT Team.
b. The network links will be provided by a third party and the Supplier will monitor and report any
problems on behalf of third party. If Supplier notifies and Purchaser approves that the delay or fault
was due to the third party link services then such loss will not be considered for tracking Supplier’s
SLA parameters (Also reduced from total service time).
7.3.1. Monitoring and Auditing
Purchaser will review the performance of Supplier against the SLA parameters each month, or at any
periodicity defined in the contract document. The review / audit report will form basis of any action relating
to imposing penalty or breach of contract. Any such review / audit can be scheduled or unscheduled. The results
will be shared with the Supplier as soon as possible. Purchaser reserves the right to appoint a third-party auditor
to validate the SLA.
7.3.2. Reporting Procedures
The Supplier’s representative will prepare and distribute SLA performance reports in an agreed upon format
by the 10th working day of subsequent month of the reporting period. The reports will include “actual versus
target” SLA performance, a variance analysis and discussion of appropriate issues or significant events.
Performance reports will be distributed to the Purchaser’s IT Team.
7.3.3. Issue Management Procedure
7.3.3.1. General
This process provides an appropriate management structure for the orderly consideration and resolution of
business and operational issues in the event that quick consensus is not reached between Purchaser and
Supplier. It is expected that this pre-defined process will only be used on an exception basis if issues are not
resolved at lower management levels.
7.3.3.2. Issue Management Process
Either Purchaser or Supplier may raise an issue by documenting the business or technical problem,
which presents a reasonably objective summary of both points of view and identifies specific points of
disagreement with possible solutions
Purchaser and the Supplier’s representative will determine which committee or executive level should
logically be involved in resolution
A meeting or conference call will be conducted to resolve the issue in a timely manner. The documented
issues will be distributed to the participants at least 24 hours prior to the discussion if the issue is not an
emergency requiring immediate attention
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 59
Management of Purchaser and Supplier will develop a temporary, if needed, and the permanent solution
for the problem at hand. The Supplier will then communicate the resolution to all interested parties.
In the event a significant business issue is still unresolved, the arbitration procedures described in the
Contract will be used
7.3.4. Change Management:
These metrics are necessary for tracking and reviewing all change activities related to the WMS environment from time to time, ensuring quality of the system is maintained
7.3.5. Service Continuity
These metrics are necessary to ensure that critical CMS components and services can be recovered within
required and agreed time lines as per the Service Continuity plan
Time taken for reestablishment replacement of services and/or components in case of failure . In case of a failure, the services will be re-established / components replaced as per Service Continuity Management Plan developed by the Implementing Agency The IA is responsible for developing and implementing a Service Continuity (Business Continuity Plan) Management plan to ensure that critical WMS components and services can be recovered within required and agreed time scales. It will provide appropriate contingency management plans containing appropriate resilience strategies, recovery and crisis management, based on minimum service requirements, following an interruption to the WMSservice delivery. The Service Continuity (Business Continuity Plan) Management will be approved by Shimla.
7.3.6. Security Management
Security compromises and exploited vulnerabilities or threats and resolutions, in relation to the WMS solution
infrastructure.
Security compromises and exploited vulnerabilities or threats and resolutions, in relation to the WMS solution
infrastructure. The implementer will design and implement appropriate ISMS (Information Security
Management System) for the CMS in accordance with the code of practice for information security management
provided in ISO 27001. The ISMS shall be approved by the CMS Acceptance agency before “Go-live”. As part of
implementing the ISMS, the IA will provide an analysis of the risks and vulnerabilities to which the CMS will be
subjected to and the counter measures proposed. Security related exploits & resolution etc. will be measured on
a weekly basis and reported monthly.
Every breach of security, and every attempt to breach security or exploit a vulnerability or risk, will be reported in the Service Management process.
7.3.7. SLA Change Control
General
It is acknowledged that this SLA may change as Purchaser’s business needs evolve over the course of
the contract period. As such, this document also defines the following management procedures:
A process for negotiating changes to the SLA
An issue management process for documenting and resolving particularly difficult issues
Purchaser and Supplier management escalation process to be used in the event that an issue is not
being resolved in a timely manner
Any changes to the levels of service provided during the term of this agreement will be requested,
documented and negotiated in good faith by both parties. Either party can request a change. Changes
will be documented as an addendum to this document and consequently the contract.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 60
7.3.7.1. SLA Change Process
Both the parties may amend this SLA by mutual agreement in accordance. Changes can be proposed by either
party. Normally the forum for negotiating SLA changes will be Purchaser’s monthly review meetings.
7.3.7.2. Version Control
All negotiated SLA changes will require changing the version control number. As appropriate, minor changes
may be accumulated for periodic release (e.g. every quarter) or for release when a critical threshold of change
has occurred
Management Escalation Procedures
The purpose of this escalation process is to provide a quick and orderly method of notifying both parties that
an issue is not being successfully resolved at the lowest possible management level. Implementing this
procedure ensures that purchaser and Supplier management are communicating at the appropriate levels.
Escalation should take place on an exception basis and only if successful issue resolution cannot be achieved in
a reasonable time frame.
All issues would be raised to the project management team, which is completely responsible for the day to day aspects of the implementation. The project management team shall classify the issues based on their severity level and resolve them within appropriate timelines.
If project management team is unable to resolve an issue, the issue would be escalated to the top management with options/ risks detailed for decision. Top management will make decisions based on the options/ risks presented by the IT team.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 61
8. Capacity Building and Change Management
The objective of Change Management in this context is to ensure that standardized methods and procedures are
used for efficient and prompt handling of all changes to control Smart Street Lights and its respective IT
infrastructure, in order to minimize the number and impact of any related incidents upon service. Changes in
the infrastructure may arise reactively in response to problems or externally imposed requirements, e.g.
legislative changes, or proactively from seeking improved efficiency and effectiveness or to enable or reflect
business initiatives, or from programs, projects or service improvement initiatives. Change Management can
ensure standardized methods, processes and procedures which are used for all changes, facilitate efficient and
prompt handling of all changes, and maintain the proper balance between the need for change and the potential
detrimental impact of changes.
Change management is responsible for managing change process involving:
• Hardware
• Communications equipment and software
• System software
• All documentation and procedures associated with the running, support and maintenance of live systems.
Based on the project implementation strategy, and proposed modules to be implemented, this section
provides details about the Change Management and Capacity Building based on the existing capacity of
ULB.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 62
8.1. Need for Change Management
Deciding to choose the method of organizational change management for the change process within business
comes with many benefits. Organizational change management uses the type of structure that prevents
resistance, and, therefore, prevents failure of the project itself. All too often business implement change without
any type of plan or communication to the parties affected by the change. This, in turn, is the major cause of a
project lacking in the significant factors needed for success.
What Causes the Project to fail?
Several things have to be in place for organizational change management to work. Many projects fail when
certain things do not line up. Some of the major reasons for failure include lack of communication, inexperience
and complexity, technical issues, management problems, and lack of definitive objectives. When change is not
communicated to all parties affected by the change, resistance becomes a huge problem. When you have
employees who are not willing participants, the main thing to suffer is the business itself. Organizational change
management can create a structured model to outline the change process for a successful outcome.
The complexity of the project is another major cause for failure of a project. You can have everyone on board
and willing to participate, but there has to be an understanding involved for the change to take place.
Organizational change management can offer the understanding to be effective. The end result will be an
effective project for everyone to move forward with. Many resources are available regarding organizational
change management that can help simplify the more complex projects.
Project Sponsorship
Project sponsorship usually is defined as the person who actually saw a need for change, and then took the
action needed to implement the change process. With organizational change management, many people can
hold the project sponsorship role collectively. A sponsorship map can be created to show who holds what role,
and what is involved to participate.
When major change is at hand, many parts of the organization will be involved in the process. Specific
departments in the workplace are going to be responsible for tasks that pertain to them individually. For
example, the IT department will not be responsible for changes being made in the finance department, and vice
versa. Sometimes, with organizational change management, a cascade of project sponsorship is involved. This
basically means that leadership will send messages to the departments involved.
The Right Change Style
The right change style is needed to implement the organizational change management process. Different types
of change include collaborative, consultative, directive, and coercive change. With collaborative change, the
target population is involved in the change process. Consultative change targets the population whose views are
sought regarding the change. Directive change is informing the workplace about the changes and why they are
needed. Last, but not least, coercive change is basically telling the workplace that change is taking place, and the
new rules must be obeyed.
Organizational change management may provide various types of change styles, but defines a specific outline
that is easy to follow for the future success of the company or entity involved.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 63
8.1.1. Identification of Stakeholders
Before starting of project stakeholders are identified. Key stakeholders for Smart Water Management project
are;
• Shimla Municipal Corporation
• World Bank
• Project Management Consultant
• The Implementation Agency
• Citizens
• Business Users
8.1.2. Description of Roles and Responsibilities
The roles and responsibilities of the stakeholders involved are mentioned below;
• Shimla Municipal Corporation: The SMC will be the owner of project and will be responsible for
successful implementation of the project. SMC will provide right of way to the implementation agency
for a smooth implementation and issue the necessary Governmental notification/ by-law
• World Bank: The World Bank will be the funding agency and will supervise the project implementation.
• Project Management Consultant: SMC will appoint Project Monitoring Consultant, who will
provide end to end Consultancy assistance to them- right from assistance in selection of Implementation
Agency (IA), to monitoring the services of the IA till the end of contract period. The PMC will undertake
the field works, comprehend the requirements, document the observations, prepare roadmap, redesign
the processes, and help build capacity for the staff and executive resources of the department.
The PMC so appointed/engaged for may be required to design new business strategy and process flows
for various selected services. They will carry out the field study in order to understand the project
requirements, existing mechanism, the present challenges, document the understanding and redesign
an efficient and effective delivery structure, understand the capacity building requirements and help in
creating a facility for development of capacity.
• The Implementation Agency: The Implementation Agency will be responsible for design, develop
and implement the entire project.
• Citizens: Citizen will avail the services that will become live after the project execution
• Business Users: Business users will get associated with SMC for the business purpose and will actively
take part in the tendering process.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 64
8.1.3. Participation by Stakeholders
Participation of stakeholders is mentioned in the table below;
# Stakeholder Group/ Name
Roles and Responsibilities
Level of Influence
Communication Strategy
1 Shimla Municipal Corporation
Define Policies
Approval of works/projects
Monitoring of its departmental functions
Strategic decision making
High Communicate the policy changes, to enable the working group to define and frame work plan.
Awareness creation and sensitization through training programme
2 The World Bank Monitor the overall progress of the project
High Awareness creation for the project being implemented
3 Project Management Consultant/Implementation Agency
Perform duties as per the RFP
Monitoring of progress of the project and submitting its report to MCS
High Written/Verbal communication with other stakeholders on the project execution
4 Citizen Should keep themselves informed about governmental policies
Participate in defining policies & projects
Medium Seek information from SMC for the project being implemented
8.2. Staffing and Deployment Strategy
The staffing and deployment strategy is mentioned here under;
8.2.1. Staffing and Deployment Plan
The resources at data Command & Control centre will be deployed as per below.
I. Water Management Engineer
Responsible for overall water scada management. 5-10 years minimum experience in ICT enabled
Water Scada System with Btech-BE (Civils).
Strong background in designing of the overall water distribution system
II. Centre Manager
Responsible for overall command and control centre management, user SLA commitments,
performance, availability, response time, and problem resolution etc. 5-10 years minimum
experience in facility and/or data center operations/planning/project management with
MCA/Btech-BE (Computers).
Strong background in facilities design with a focus on command & control centre/data centers
Significant project management experience required
Project management certification (PMP) a plus
III. System Administrator
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 65
Responsible for database configuration, scalability, performance, load balancing, OS
administration/management, troubleshooting & Debugging and monitoring of server(s). The
Systems Administrator will provide in-depth technical support and effective problem solving for all
employees.
The desired profile should be minimum B.E (CSC/ECE/EEE)/MCA preferably MBA with 3-4 years’
experience in system administration of RDBM data (Oracle/ MSSQL). Sys admin, win2k, UNIX,
Solaris, etc., server programmer of Java, C, C++, SQL, PLSQL, CORBA etc. Technical certification on
the above is desired. Required for only one shift.
IV. Network Administrators
Responsible for network uptime, security, User and Group Administration, including password
management. Assisting with building and supporting servers. Administering server-side antivirus
protection
The personnel should be well versed with routing and switching devices and technology like AM,
MPLS, wireless, broadband and protocol analysis tool.
3 – 5 years’ experience with server administration.
Working knowledge of server hardware.
V. Maintenance staff (Electrician, Cabling, House Keeping etc.,) – As Required (A/R)
Operate, monitor, maintain, and respond to abnormal conditions in facilities systems. Areas include:
Electrical, Mechanical and Building Monitoring and Control.
Tracking and trending operational characteristics
VI. Technical Support Services (System and Network Engineers)
Responsible for L2 support, H/W & S/W support and would provide help to the control centre
operations and management.
Core team in quick resolution of problems in the technical support team would work on shift basis
and ensure uptime of services.
The desired personnel should be min diploma with 2-3 years exp in technical support services,
operations, IT infrastructure managing and updating customer database with pleasing personality
and good communication skills. Technical certification like CCNA etc. is preferred. Required for 3
shifts.
VII. Facility Management Services
Facility Management Services is required for all the offices.
8.2.2. Staffing and Deployment Process
SMC can opt either of the following below mentioned process to hire the resources:
• Creating vacancies within the department and hire them as government officials
• Or hiring the resources for specific period of time on contract basis.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 66
• Outsourcing the process to the third part recruitment agency. The selection of agency can be done
through tendering process.
8.3. Training Strategy
It will be a crucial task to be handled by SMC in imparting training to all its stakeholders. The SMC should
ensure putting forward their tentative agenda in the subject of Awareness Creation that will ensure both
internal and external stakeholders are made aware of the changes envisaged due to the project.
8.4. Training Need Assessment and Content Development
Implementation agency will impart necessary training to users on ICT enabled water scada. A detailed training
schedule will be made in consultation with the SMC. This training program will include classroom sessions with
hands on sessions and on-the-job training for the ULB employees. Training on different modules would be
imparted in batches of a maximum of 25 trainees per training program.
# Target Stakeholder Mode of Awareness Frequency 1. SMC Users Department wise Training mainly on the
use, benefits and problem solution process.
Monthly for first one year and thereby refresher course quarterly for next one year.
2. Other Government Department officials
Seminars and workshops with the top and middle level officials of different state Government official from city level
Quarterly for first one year
3. Business Users Online training Once in a quarter for first year
Adequate activities should be undertaken seamlessly by the Training Service Provider (TSP) at all concerned
locations to ensure the successful implementation of the smart street light solution. The TSP can be a training
institute/implementation agency or SMC staff etc.
8.4.1. Capacity Building
TSP shall assess the change readiness of the organisation & based on it shall define change management
approach to manage various stakeholder groups on an ongoing basis.
The TSP shall define structure of the leadership as well as execution team to drive the change with clearly
assigned roles & responsibilities.
The TSP shall define measurement tools to measure the impact of change initiatives and track the
ongoing corrective & preventive action.
The TSP shall obtain a sign off on the proposed change management team structure, change management
approach & the measurement tools from the purchaser.
The TSP shall all carry out the periodic review of the training imparted.
8.4.2. Training
The TSP agency shall carry out the Training Needs Assessment.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 67
Based on the assessment, the TSP shall prepare detailed Training and Capacity Building plan for
providing Training to the different stakeholders of SMC.
The Capacity Building & Training Plan would indicate the schedule, scope, resource requirement &
participant details of all the training sessions, training categories & user groups.
The Capacity Building Plan would also indicate tools to track the skill & knowledge of different
stakeholders. The TSP shall obtain a sign off from SMC on the proposed Capacity Building Plan.
The TSP shall carry out the different Capacity Building Trainings for the stakeholders as per the schedule
provided in the approved Capacity Building Plan.
The TSP shall submit the course materials, presentations & any other material used in the Training
programmes to SMC. Hard copy of the training material to be provided to each participant during the
Training session, while soft copy is to be mailed to the participants.
The TSP shall use various predefined forms for gathering data regarding the satisfaction of end users
with the training delivered.
Detailed report regarding each training session (for e.g. attendance levels, proficiency levels of the
participants etc.) is to be submitted to the SMC management.
Exact Reporting formats will be decided and agreed upon by the TSP after approval from SMC.
The details of proposed training to be conducted shall be indicated by the TSP in the Technical Proposal.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 68
9. Monitoring and Evaluation
9.1. Monitoring and Evaluation Framework
Having detailed out all components of the project as provided in the previous sections, it is essential to have
details about controlling of the project at various stages of the project. Thus Monitoring and Evaluation (M&E)
will help in the process of measuring, recording, collecting, processing and communicating information and
assist in project management decisions making. Hence a well-designed, properly functioning project M&E
system would be in place to provide updated information and right time and right frequency in order to
envisage that work is progressing in right direction as per plan and with time limit and budget. The main
feature of monitoring and evaluation is measurement and verification of variables/ indicators for input,
process, output and outcomes/ impact.
A diagrammatical representation of the M&E process has been given in figure shown. M&E will play a critical
role in all the phases’ viz. of the overall project implementation.
INPUTS
Project Plan
Resources
Reporting
Processes
ASP selection
S/w Dev and Testing
OUTPUTS
Online Services
Service Delivery
Trained Staff
OUTCOMES
Improved Process
Revenue
Citizen
IMPACTS
Timelines
Efficiency
Transperancy
MONITORING
EVALUATION
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 69
9.1.1. Clearly Defined Objectives
Following table illustrates the objectives at project and program level M&E;
Stakeholder Illustrative Objectives
World Bank Program Level
Identify state coordinator for Monitoring and Evaluation of ULB
Define scope of M&E for ULB in line with the project requirement
Create M&E plan and oversee its roll out (Physical and Financial progress) ULB level
Design standard reporting templates for Monitoring for capturing data
Provide guidance to involved stakeholders as and when required
World Bank/SMC Project Level
Collect information (progress report) in specific interval
Analyse and monitor the overall growth of project
Identify and address challenges, deviations and risks
Make interventions as and when required and make policy level decisions
9.2. Define Organization’s Roles and Responsibilities
Following table illustrates roles and responsibilities;
Role Illustrative Responsibilities World Bank Oversee the overall progress in terms of physical and financial progress Shimla Municipal Corporation
Co-ordinate with PMC at for determining the overall status
Co-ordinate with implementing agencies at ULB for status update
Oversee the fund utilization
Solve issues and deviations in timely manner
Collect status reports from implementing agencies and report to financing authority
Project Management Consultant
Monitor progress at a day-today basis
Conduct reviews of team
Report timely status to ULB
Report issues and deviations in timely manner
9.3. Approach for Monitoring and Evaluation Process
9.3.1. Monitoring
During the monitoring process, the milestones for the various indicators would be monitored at regular
intervals to determine the status. If any deviations found, control mechanism would be put into place to take
corrective actions at the minimal required period to achieve the desired output. In case of any change in the
project plan the same would be communicated with the output. An approach for Monitoring process has been
presented in the figure below;
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 70
9.3.2. Evaluation
Evaluation would be carried out at Pre and Post implementation Stage of the program. Evaluation performed at
the Pre-implementation stage is Base-Line Survey and one performed Post implementation is End-Line Survey.
Evaluation would also be carried on continuous basis after Program Implementation as Ex-Post
Implementation survey for continuous improvements till achievement of desired goals.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 71
A suggestive approach for M&E would be divided into various sub-activities as mentioned below.
• ‘WHAT’: Identifies what needs to be monitored and evaluated? Various variables/ indicators have been identified for input, process, output as a part of monitoring process and outcome/ impact as a part of evaluation process. The identified indicators would be measured/ verified (in terms of Progress, Timelines, Resources allocated, Deviations, Risks and Funds utilised) against pre-defined plan. Illustrative list of variables/ indicators for input, process, output and outcomes/ impact would be as follows in Table
Phases Variables/ Indicators Input Define plans and schedules
Define framework Process Empowered committee formed
Process mapping and Standardisation
Process of identification of stakeholders
Vendor selection process
Software application requirement gathering
Software development
Testing and integration
Implementation
Capacity building
Risk Management Output Number of personnel trained
Number of existing lights replaced, new poles implemented etc Outcome/ impact Turnaround Time
Percentage increase in revenue
Customer satisfaction level
Customer awareness
HOW: Answers the various modes to be undertaken for Monitoring and Evaluation process.
Monitoring: ULB would take various modes for carrying out the monitoring process
o Framework defined at city level (Monitoring)
o Schedule and Resource Plan defined in the planning phase
o Online Tools developed at city and ULB level
o Quarterly Progress Report formats developed at ULB Level
o Standard formats developed at ULB level
o Team meeting, project review, feedback
o Audit by third party agencies
Evaluation: ULB would use the Performance Report cards to report the progress to carry out the Baseline and End line Survey. The various modes would be
o Reports generated through the developed system
o Feedback from the Citizens
o Surveys
o Questionnaire
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 72
o Engagement of 3rd party
o Usage of self-assessment forms
WHEN: Defines the frequency of the Reporting the Monitoring and Evaluation results. ULB would
determine frequency for reporting and would be appropriately spaced, so that the data collection is not
repetitive or cannot be interpreted to obtain accurate results.
‘WHO: Identify key resources for carrying out the monitoring process. Following table illustrates the same;
Process Persons Responsible Timelines
Develop criteria for selection of Implementation Agency
ULB/Project Management Consultant
2 weeks
Float RFP and Answer to queries
ULB/Project Management Consultant
1.5 weeks
Evaluate Proposals and publish final list
ULB/Project Management Consultant
2 weeks
Meeting with Vendors and final selection
ULB 2.5 weeks
Action Daily Weekly Monthly Quarterly
Informal discussions with team
Staff meetings with managers
Project review meetings with team
Status report
Team building activity
Report to management etc.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 73
10. Assumption and Risk Management
Risk management is important because it gives the ability to figure out methods for which events can be
managed, especially those events that may have an adverse impact on the financial or human capital of the
organization.
Risk management should always be thought of as a process which is continuous. Not only does it allow one to
assess risk, but it also gives us the ability to identify risk as well. By being able to assess and identify risk, it
becomes easier for one to prevent it from occurring, or to quickly address adverse events if and when they do
occur
10.1. Process for Risk Assessment
Vision on Smart City is backed by large budgetary and time commitments and there by expecting large benefits
in service delivery for various stake holders. However, there may be a short fall due to lack of clear
identification, understanding and management of issues/ risks/ barriers related to in various spheres at
appropriate time, which in turn leads to time and cost over-run or project failure. It therefore becomes
imperative to identify and contain the possible reasons for failure or delays in appropriate time and at
appropriate cost. This is where the need of Risk Assessment and Management comes into play and has a
significant role.
10.1.1. Risk Identification
Risks can broadly be classified into:
• Strategy Level Risk: This deals with risks resulting from a strategy level decision or change.
• Project Level Risk: This deals with risks related to the ability to understand and manage the project
complexities and project environment. Not addressing them will result in not delivering the expected
results that can bring in desired benefits.
• Operational Level Risk: These risks will arise out of day-to-day activities and management of the
project from inadequate or failed processes, people, and systems or from external events. The Project
Manager or the Team Leader appointed by ULB would manage these risks on a day-to-day basis.
Following table illustrates the types of identified risks;
Risk Factor Project Risk Title Project Risk Area
Medium
Lack of political will Stakeholder Commitment No decision making power of project implementation committee
Project Management
Lack of technical expertise at project locations Resource Risk Resistance to use Smart Solutions/IT Change Management Risk Legal changes for supporting BPR Functional Risk Parallel manual delivery of services Functional Risk Unavailability of up-to-date MIS Functional Risk ICT applications for smart street lights not implemented
Technology Risk
Low
Resistance to Business Process Engineering Functional Risk Lack of interoperability among systems Technology Risk Lack of Smart infrastructure Technology Risk Lack of ICT resources (quality, quantity, timeliness) Technology Risk Lack of training programs for the department staff Change Management Risk
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 74
Lack of planning of resources and funds Resource Risk Progress of data digitization Functional Risk
10.2. Risk Mitigation Strategy Based on Risk Evaluation Matrix
Risk Mitigation strategy along with Risk Monitoring is explained below;
10.2.1. Risk Mitigation Strategy based on Risk Evaluation Matrix
The risk mitigation communicates how specific risks will be dealt with and the action steps that are required to
carry them out. It gives team members a clear sense of the actions that they are expected to take and provides
management with an understanding of what actions are being taken on their behalf to ameliorate project risk.
The following methods can be taken for mitigating the risk
• Avoidance: Not performing an activity that could carry risk
• Reduction: Methods that reduces the severity of the losses
• Retention: Accepting the loss when it occurs
• Transfer/ Share: Transfer or share the risk with various partners involved
10.3. Risk Monitoring
Risk monitoring is the last major element of risk management - but certainly not the least important! Risk
monitoring is a process of organizing and planning - just as important as strategic, financial, marketing and
human resources planning. Like any good planning, the process should be continual or on-going.
Once the basic risk management plan is in place, monitoring risk means to review it and update it continuously.
• Identify new risks as soon as possible
• Decide where and how to handle that risk
• Look for other risks that might be reduced or eliminated and no longer need coverage
During risk monitoring meetings, existing risks as well as new risks are reviewed and discussed in details by the
Project Team. Through Risk Monitoring, the project team will Implement and direct risk mitigation actions,
Monitor the risk mitigation actions to determine their effectiveness, and revise the risk mitigation strategies as
needed, if required. The team will also assess
• Assess Mitigation Effectiveness - After implementing the Risk Mitigation Plan, the project team will
assess the effectiveness of the risk mitigation actions.
• Reassess Exposure - Evaluating the project's current risk status on a regular basis will address the
dynamic realities of the project. Project team meetings can be venues to raise and report project risk and
risk mitigation actions and results.
• New risks: The project team will also identify the potential new risks and plans to mitigate them.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 75
11. Project Implementation Strategy and Sustainability Plan
Following are the essentials for successful project implementation:
• Adequate formulation
• Sound project organization
• Proper implementation planning
• Advance action
• Timely availability of funds
• Better contract management
• Effective control and monitoring the progress of the project
11.1. Stakeholder’s Involvement
Following table illustrates the benefit of stakeholder’s involvement in the project execution;
Stakeholders Benefit The World Bank Ease of process
Better Project Monitoring
Less paper work & no cumbersome manual processes etc
Shimla Municipal Corporation
Citizen & Business Users Benefits in terms quality & cost of services, provision for customer care, jobs, involvement, environmental issues, etc
Value perceived Project Management Consultant & Implementation Agency
Generation of revenue
Increase of credentials
11.2. Tendering and Bid Process Management
Post the approval of DPR ULB/World Bank will publish the RFP for selection of Project Management
Consultant/Implementation Agency for implementing Smart Water Management in the city of Shimla.
11.3. Project Implementation Strategy
The implementation of the application has been subdivided into two parts – pilot implementation and Roll Out
of the tested application
Pilot Phase
The details of the various activities under the piloting phase of the implementation of the Project are listed
below:
• Study: The Implementation partner will have to understand the city’s As-Is situation, with respect to
existing water management, by doing a detailed site survey of the area.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 76
• Implementation: Design, Develop, Implement, Manage, Operations and Maintenance of identified
services to improve SMC operation and delivers benefits to citizens and provide seamless integration of
smart services and solution
• Testing: Testing is a process of technical evaluation of functionality, operability, scalability and
modularity along with quality of the product. During this period unit testing, integration testing, system
testing, regression testing, performance testing etc will be done. The wok-flow determined in
consultation with the ULB should also be tested for all the applications
• Piloting: Once the implementation and testing is done the pilot location would be ready for go-live.
Roll Out
Any bugs in the system, gaps in functionalities, system inconsistencies and other problems found during the
pilot phase will be fixed prior to a full roll-out. After the go-ahead from the ULB, the implementation will be
rolled out to all the project sites. The activities in this phase are detailed below:
• Infrastructure Supply: The infrastructure will be supplied and installed in sync with the roll-out plan
at all the identified locations
• Implementation: The entire implementation in line to the pilot will be rolled out to the other site
within the city and the connectivity will be established with the command centre.
11.4. Project Phasing Strategy
11.4.1. Exit Plan
The Implementing agency will provide a detailed exit management plan to the ULB before the commencement
of project implementation. The Exit Management Plan to be provided to the department shall deal with the
following aspects of exit management in relation to Project Implementation and the operation & maintenance;
• A detailed program of the transfer process that could be used in conjunction with replacement
implementer including details of the means to be used to ensure continuing provision of the services
throughout the transfer process or until the cessation of the services and of the management structure to
be used during the transfer
• Plans for the communication with such of the implementers sub-contractors, staff, suppliers, customers
and any third party as are necessary to avoid any material detrimental impact on operations as result of
undertaking transfer
• Plans for provision of contingent support to department and replacement implementer for a reasonable
period after transfer
• During the exit management period , the implementer shall use its best efforts to deliver the services
11.5. Sustainability Plan
Procedural, staffing, budgetary and contractual arrangements that will ensure sustainability of project and its
outcomes during and beyond the mission period are mentioned below:
• Procedural Sustainability: The procedures that ensures the smooth functioning of project are:
o Strong decision making power of management authorities like SMC, World Bank etc
o Adequate amount of budgets
o Adequate technical expertise
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 77
o Capacity building at the end of the project
• Resource Sustainability: Adequate amount of human resource will be deployed with diversified
experience.
o The SMC is the Appointing Authority of the staff to be engaged for the project
o The authority have the power to sanction, add, create, abolish such posts as in their opinion are
necessary to manage the project
o No person shall be appointed to any post unless he/she is eligible for the same as per the
qualification prescribed by the ULB
o All the appointment made in the are either on contract basis or full time
• Financial Sustainability: The revenue will be generated by the project during implementation phase
• Contractual Sustainability: Contract agreement will be signed between SMC and other private firms
during the project execution.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 78
12. Project Implementation Schedule
T=Data of Signing of Contract
Si.No. Project Activity Deliverables Responsibility Timelines
1 Supply of Hardware / Software/equipment etc from the date of signing the Contract
• Delivery Challan
• Invoice Copy
• Inspection report from authentic third party
• Warranty certificate issued by respective OEMs for each hardware / software (back to back, in the name of Authority also)
• License in case of software
MAF
Implementation Agency
T+20 weeks
2 Installation, Configuration Integration of Hardware/ Software/ systems
• Device wise Configuration report stating IP Schema
• Routing details
• In case of Software, the report should consist of
• Software Installation Guide and checklist.
• Complete set of Technical/ Operation and Maintenance Manual.
• Report formats for approval of Authority UAT/testing report
• Helpdesk and SLA compliance report
• Configuration change report
• Inventory Reports
Implementation Agency
T+30 weeks
3 UAT and Commissioning of entire system as per scope of work
• UAT Report and Successful Commissioning
• Certificate/ Rectification activities
Implementation Agency
T+32
4 Rectifications based on UAT
• Test reports and configurations
Implementation Agency
T+34
5 Go-Live • All project locations working successfully
Implementation Agency
T+35
6 Operations Phase Satisfactory Working Inspection
• Inspection to be done by Authority followed by submission and approval of Satisfactory Working Inspection Report
SMC T+36
7 Operation & Maintenance All project locations in working condition (after satisfactory inspection)
• Quarterly SLA compliance reports
• Quarterly Preventive Maintenance reports
• Quarterly Configuration change reports
• Quarterly location wise Inventory reports
• Other reports as desired
Implementation Agency
Quarterly after Go-live period
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 79
• Quarterly user report- Location wise
• Quarterly bandwidth utilization report- Location wise
• Quarterly report indicating daily uptime-Location wise
• Quarterly user feedback reports- Location wise
• Quarterly report user complaint- Location wise showing complaint, complaint time & date, solution given, complaint clear time & date
The aforementioned schedule is only indicative.
Detailed Project Report for ICT Enabled Water SCADA for Shimla
PwC 80
Thankyou
