Needs Analysis and Overallhimachalservices.nic.in/hpridc/Need Analysis and Overall System... · Project Manager: Raj Mallela Revisions 1 08 September 2016 ... 3.3.2 Current Road Maintenance

Needs Analysis and Overall

System Architecture - FINAL

Consulting Services for

Technical Assistance to Help Upgrade

Road Maintenance Management

System to Road Management System in

the State of Himachal Pradesh

Contract No. HPSRP (Loan 4860-IN & 8199-IN)

Prepared By Prepared For

HIMS Limited Joint Venture with

SATRA Infrastructure Management

Services Pvt Ltd

Himachal Pradesh Road and Other

Infrastructure Development Corporation

Limited

July 2016

SATRA Infrastructure Management Services Pvt Ltd

605, Ashoka Bhoopal Chambers S.P.Road, Begumpet Secunderabad – 500 003, Telangana, India [email protected] www.satragroup.in

Quality Assurance Statement

Client:

Himachal Pradesh Road and Other Infrastructure

Development Corporation Limited (HPRIDC)

Prepared by:

Balamurali Alapati,

Rajshekar Gotimukul

Report Name:

Needs Analysis and Overall System Architecture

Reviewed by:

Raj Mallela, Ashik Hussain

Project/Contract Number:

For HPRIDC: 4860-IN & 8199-IN

For SATRA: 01041013

Approved for issue by:

Raj Mallela

Date of Issue:

July 2016

Project Manager:

Raj Mallela

Revisions

1 08 September

2016

Comments received from HPRIDC vide letter PW-SRP-

RIDC/Procurement-RMS/Vol-V-2570 dated 31 August

2016

Consulting Services for

Technical Assistance to Help

Upgrade Road Maintenance

Management System to Road

Management System in the State of

Himachal Pradesh

mailto:[email protected]

http://www.satra-iman.com/

Consulting Services for Technical Assistance to Help Upgrade Road Maintenance Management System to Road Management System in the State of

Himachal Pradesh

i

Table of contents

1. Executive Summary 9

1.1 Introduction 9

1.2 Background of the Project 9

1.3 Objectives of the Project 10

1.4 Scope of Services 11

1.5 Review of Existing RMMS 11

1.6 Review of Current Processes and Practices 12

1.7 Proposed Road Management System (RMS) 13

1.7.1 Comparison of As-Is and To-Be RMS System 14

1.7.2 Institutional Setup 15

1.8 Data Requirements for RMS 15

1.9 Data Collection Method 16

1.10 Simplified Data Collection for RMS (Rural Roads) 17

1.11 Budgeting and Maintenance Planning 17

1.12 Key Consideration for RMS System Architecture 17

1.12.1 Technical Challenges 18

1.12.2 Deployment Challenges 18

1.13 Conclusion 18

2. Introduction 20

2.1 Introduction 20

2.2 Outline of the Needs Analysis and Architecture Report 20

2.3 Background for the Project 21

2.4 Objectives of the Project 21

2.5 Scope of Services 22

VOLUME I: 24

3. Needs Analysis 25

3.1 Review of Existing RMMS System 25

3.1.1 Strengths of RMMS system 30


Himachal Pradesh

ii

3.1.2 Weakness of RMMS system 31

3.2 Review of current data formats 31

3.2.1 Understanding of current data formats 31

3.2.1.1 Road Inventory Data 31

3.2.1.2 Road Condition Data 35

3.2.2 Strengths of current data formats 38

3.2.3 Weakness of current data formats 38

3.3 Policy, Processes and Practices 38

3.3.1 Current Road Maintenance Policy 38

3.3.2 Current Road Maintenance Processes & Practises 39

3.3.2.1 Preparation of Annual Maintenance Plan 40

3.3.2.2 Scheduling and Annual Maintenance Calendar 41

3.4 Organisational structure 44

3.5 Technical and Managerial Capabilities 45

3.5.1 Duties of Mate 45

3.5.2 Duties of Work Inspector 46

3.5.3 Duties of Junior Engineers 46

3.5.4 Duties of Assistant Engineers 47

3.5.5 Duties of Executive Engineers 47

3.6 Proposed RMS system 47

3.6.1 Background 47

3.6.2 Proposed Functionality 48

3.6.3 Conceptual Design 49

3.6.3.1 Location Reference Management System (LRMS) 49

3.6.3.2 Road Information System (RIS) 51

3.6.3.3 Bridge Information System (BIS) 52

3.6.3.4 Traffic Information System (TIS) 53

3.6.3.5 Pavement Management System (PMS) 54

3.6.3.6 HDM-4 Interface 56

3.6.3.7 HDM-4 Calibration 58

3.6.3.8 Routine Maintenance Management System (RMMS) 60


Himachal Pradesh

iii

3.6.3.9 ROW Features Information Management System (RWFIMS) 62

3.6.4 Institutional Setup 63

3.6.4.1 RMS Cell 63

3.6.4.2 Sustainability Framework 64

3.7 Data Collection for RMS (SH & MDR) 65

3.7.1 Introduction 65

3.7.2 Deciding What Data to Collect 65

3.7.3 Guiding Principles 66

3.7.4 Levels of Data Collection 66

3.7.5 Information Quality levels 66

3.8 Data Collection Items 68

3.8.1 Data Collection Categories 68

3.8.2 Location Reference 69

3.8.2.1 Network Details 69

3.8.2.2 Road Alignment Details 70

3.8.2.3 Administrative Details 70

3.8.3 Road Inventory 70

3.8.3.1 Suggested IQL 70

3.8.3.2 Number of Lanes 70

3.8.3.3 Road Type 70

3.8.3.4 Pavement Surface Type 71

3.8.3.5 Pavement Surface Material 71

3.8.3.6 Carriageway and Formation Width 71

3.8.3.7 Shoulder Material 72

3.8.3.8 Shoulder Width 72

3.8.3.9 Side Drain Type 72

3.8.3.10 Cross Section 72

3.8.3.11 Terrain Type 72

3.8.3.12 Road Furniture (Optional) 73

3.8.3.13 Wayside Amenities (Optional) 73


Himachal Pradesh

iv

3.8.3.14 Geometry 74

3.8.3.15 Land Use Type (Optional) 74

3.8.3.16 Utilities (Optional) 74

3.8.3.17 Annual Rainfall 74

3.8.3.18 Facilities 75

3.8.3.19 Right of Way (ROW) 75

3.8.4 Pavement – Functional 75

3.8.4.1 Roughness 75

3.8.5 Pavement – Structural 75

3.8.5.1 Rut Depth (Optional) 76

3.8.5.2 Pavement Deflection 76

3.8.5.3 Pavement Composition 76

3.8.5.4 Pavement History 76

3.8.6 Pavement Surface Condition 76

3.8.6.1 Surface Distresses 76

3.8.7 Other Condition 77

3.8.7.1 Shoulder Condition 77

3.8.7.2 Side Drain Condition 77

3.8.7.3 Road Furniture Condition 78

3.8.8 Traffic 78

3.8.8.1 Volume 78

3.8.8.1.1 Seasonal Correction Factor 78

3.8.8.2 Axle Load 79

3.8.8.3 Road User Cost (RUC) 79

3.8.9 Structures 80

3.8.9.1 Structure Inventory 80

3.8.9.2 Structure Condition 81

3.8.9.3 Culvert Inventory 83

3.8.9.4 Culvert Condition 84

3.8.10 Others 85


Himachal Pradesh

v

3.8.10.1 ROW Video (Optional) 85

3.8.10.2 Ongoing/Committed Projects 85

3.9 Method of Data Collection 85

3.9.1 Background 85

3.9.2 Basis of Selection 86

3.9.3 Available Methods 86

3.9.3.1 Walkthrough (Manual) 86

3.9.3.2 Windshield 87

3.9.3.3 Video Logging 88

3.9.3.4 Automated (Equipment) Measurements 89

3.9.3.5 Transcription from Records 90

3.9.4 Suggested Methods 90

3.10 Frequency of Data Collection 91

3.10.1 Introduction 91

3.10.2 Basis of Selection 91

3.10.3 Suggested Frequency 91

3.11 Simplified Data Collection for RMS (Rural Roads) 92

3.11.1 Frequency & Method of Data Collection 94

3.12 Budgeting and Maintenance Planning 94

3.12.1 Routine Maintenance 94

3.12.2 Emergency Maintenance 95

3.12.3 Non-Routine Maintenance Strategy 95

3.12.4 Road Section Rating and Prioritisation 96

3.12.4.1 SH & MDR Roads 96

3.12.4.2 Rural & Other Roads 96

VOLUME II: 100

4. System Architecture 101

4.1 Key Consideration 101

4.1.1 Technical Challenges 101

4.1.2 Deployment Challenges 101


Himachal Pradesh

vi

4.2 Architectural Requirements 101

4.3 Architecture Evolution 102

4.4 Functional Architecture 103

4.5 Technical Architecture 104

4.5.1 Presentation Layer 105

4.5.2 Web Services 105

4.5.3 Business Layer 105

4.5.4 External Services 106

4.5.5 Data Access Layer 106

4.5.6 Database 106

4.5.7 Exception Handling and Logging 107

4.5.8 Reporting 107

4.5.9 User Management 107

4.6 Non-Functional Requirements 107

4.6.1 Scalability 107

4.6.2 Availability 108

4.6.3 Performance 108

4.6.4 Maintainability 109

4.6.5 Security 109

4.6.6 User Experience 110

4.7 Physical Architecture 110

4.8 Hardware and Software Requirements 111

4.8.1 Appreciation of Current HPPWD/HPRIDC IT Infrastructure 112

Annex-I: Rural Roads Data Collection Formats 113

Annex-I: Rural Roads Data Collection Formats


Himachal Pradesh

vii

ABBREVIATIONS

AMP Annual Maintenance Plans

BI Bump Integrator

BIS Bridge Information System

BOT Build, Operate and Transfer

BOOT Build, Own, Operate and Transfer

BOLT Build, Operate, Lease and Transfer

COTS Commercial Off the Shelf

CRN Core Road Network

DCL Data Collection Limited, New Zealand

EIC Engineer-in-Chief

FWD Falling Weight Deflectometer

FY Financial Year (Fiscal Year)

GIS Geographical Information System

GoHP Government of Himachal Pradesh

GOI Government of India

GPS Global Positioning System

HDM-4 Highway Development & Management Model Software

HIMS HIMS Ltd, New Zealand

HO Head Office

HPPWD Himachal Pradesh Public Works Department

HPRADMS Himachal Pradesh Road Accident Data Management System

HPRIDC Himachal Pradesh Road and Other Infrastructure Development Corporation Limited

HPSRP Himachal Pradesh State Roads Project

IBRD International Bank for Reconstruction and Development

IR Inception Report

IRI International Roughness Index

IT Information Technology

LAN Local Area Network


Himachal Pradesh

viii

LRMS Location Reference Management System

MDR Major District Roads

MORD Ministry of Rural Development, Government of India

NH National Highway

NRRDA National Rural Road Development Agency

PMGSY Pradhan Mantri Gram Sadak Yojana

PMS Pavement Management System

PWD Public Works Department

RFP Request for Proposal

RIS Road Information System

RMS Road Management System

RMMS Road Maintenance Management System

RO Regional Office

ROW Right of Way

ROMDAS Road Measurement Data Acquisition System

RWFIMS Right-of-Way Features Information Management System

SATRA SATRA Infrastructure Management Services Pvt Ltd, India

SH State Highways

SNP Modified Structural Number

TIS Traffic Information System

TNA Training Needs Assessment

TOR Terms of Reference

VR Village Roads

WBM Water Bound Macadam

Consulting Services for Technical Assistance to Help Upgrade Road Maintenance Management System to Road Management System in


9

1. Executive Summary

1.1 Introduction

The State Government of Himachal Pradesh (GoHP) through Government of India

(GOI) had received a loan from International Bank for Reconstruction and

Development (IBRD) for implementation of Himachal Pradesh State Roads Project

(HPSRP), and intends to utilize a portion of this loan to finance Consultancy Services

for Technical Assistance to help and establish Road Management System (RMS), so

that it could be used for all State core road network (CRN) in Himachal Pradesh.

Himachal Pradesh Road and Other Infrastructure Development Corporation Limited

(HPRIDC) awarded the consultancy services contract entitled, Consulting Services for

Technical Assistance to Upgrade Road Maintenance Management System to Road

Management System in the State of Himachal Pradesh, with Contract No. 4860-IN &

8199-IN to HIMS Ltd, New Zealand in joint venture with SATRA Infrastructure

Management Services Pvt Ltd, India. The project commenced on 25 May 2016 with an

expected completion date of 24 May 2018.

1.2 Background of the Project

The construction and maintenance of the State Highways (1,504 km), Major District

Roads (2,139 km) and Rural Roads (27,575 km) totalling to 31,218 km are being

looked after by the Himachal Pradesh Public Works Department (HPPWD). While NHs,

SHs and MDRs carry the bulk of the traffic and are the principal carriers of economic

activities, the State Core Road Network (CRN) comprises of SHs, MDRs and Other roads

connecting NHs in the State with the rural and other roads, totalling to 4,200 km.

The HPPWD has developed a computerised Road Maintenance Management System

(RMMS) for rural roads, SHs, MDRs and Other roads. The software was developed

under the Pradhan Mantri Gram Sadak Yojana (PMGSY), Rural Roads Project in 2007.

Using the RMMS, HPPWD prepares an annual core road network condition report for

rural roads and State roads. On the basis of an indicative budget, annual maintenance

plans (AMPs) focussing on prioritizing periodic and rehabilitation works are prepared.

The program is produced to a timeframe that meets the government’s budgeting cycle

and is revised in an iterative process as more accurate forecasts of the next FY budget

become known.

However, the RMMS has its own limitations, particularly in the following functional

aspects:

It lacks the necessary data fields required to prioritise higher class road network

using economic evaluation;

It lacks interfacing facilities with generally accepted maintenance needs tools such

as HDM-4;

Current system for data collection on 16 forms is too complex for rural roads.

The HPPWD/HPRIDC intends to upgrade RMMS to RMS to significantly improve and

rationalize decision making in planning, programming, funding, and procurement in the



10

allocation of resources in road sector in order to make the best use of public funds in

preserving the road networks at an acceptable level of serviceability. The proposed

upgrade of RMMS will improve the technical capacities, skills and management

capabilities of the HPPWD/HPRIDC, thus improving the ability of the State Government

of Himachal Pradesh (GoHP) and its subordinate agencies to manage efficiently and

cost-effectively road maintenance and improvement activities.

1.3 Objectives of the Project

The overall objective of the Consultancy Services is to improve the quality and delivery

of the services of the HPPWD in planning and programming. The more specific

objectives are:

Review the existing MS-Access based Road Information System in use at HQ and

Field Units;

Creation of additional fields and other information in RIS for its use in latest version

of Highway Development & Management Model (HDM-4) software;

Carry out any changes in the MS Access software for compatibility of data for

producing reports/outputs as per the need of the Client including enhancing

Querying/Reporting;

Develop and establish a middleware for linking modified RIS with HDM for smooth

transfer of data between the two or linking which will include data import and

export facilitates between the RMS and other applications and between various

applications and report generation modules. RMS shall be configured, customized

to meet technical, functional and administrative requirements of the Client;

Carry out compliance/pilot testing and validation of all various modules/every sub-

programs/sub-systems and entire upgraded system after full interface with HDM

software;

Transfer skills and procedures to an adequate number of staff in the

HPPWD/HPRIDC for hand-holding and training of trainers to sustain the use of the

HDM and RMS during as well as after the end of these services;

Providing implementation, operation and maintenance support (intermittent) to

HPPWD and HPRIDC for 24 months after all mandatory testing and validations and

third party user acceptance test - Response time of not more than 24 hours and

rectification time of not more than 72 hours. That will include trouble shooting,

resolving any problems faced by the HPPWD/HPRIDC, minor modifications and

refinements required in the system to improve its effectiveness based on the

feedback information collected from its use, and removing bugs from the Software.

Thus along with the development and implementation of tools, improvements to the

operational context and capacity building will be vital to the success of the project. This

project will assist HPPWD/HPRIDC in the whole maintenance planning, programming

and implementation cycle. The system applications adopted will, together with

organisational capacity development, be instrumental in improving the overall

efficiency and sustainability of the HPPWD.



11

1.4 Scope of Services

The broad scope of the Project is to upgrade RMMS to RMS. The specific tasks included

the following, which are summarised from the broad scope mentioned in the TOR:

Study existing Road Maintenance Management System, assess and identify the

strengths and weaknesses of the current data format, processes, planning and for

maintenance management practices, decision-making process, organisational

structure, and technical and managerial capabilities of the HPPWD/HPRIDC and

propose changes aimed at providing adequate support for the RMS and ensuring

that upgraded system will be efficient, effective and sustainable;

Establish and implement Road Management System based on the need analysis

and gaps of the current system;

To provide training to identified HPPWD/HPRIDC staff in the use and maintenance

of the system;

Upgrade RMS with the following components, using (COTS) Commercial Off the

Shelf :

o GIS linked Road Information System (RIS);

o Bridge Information System (BIS);

o Pavement Management System (PMS);

o Road Maintenance Management System (RMMS);

o Right-of-Way Features Information Management System (RWFIMS);

o Traffic Information System (TIS);

o HDM Planning Tool for road investment maintenance prioritisation.

RMS should be capable of interfacing with other Geographic Information System

(GIS) applications of GOHP like revenue maps and forest maps to facilitate easy

access to tabular data residing within the RMS.

Undertake a Road and Bridge Condition survey and collect the required inventory

data for input into the Road Management System (as per the quantities

mentioned);

Define required human resources and organisation structure to manage Road

Management System (RMS) and define plans for training programs required to use

the upgraded system.

1.5 Review of Existing RMMS

A Road Maintenance Management System (RMMS) is information based computer

package which facilitates maintenance management-planning tool, based on objective

data, providing a systematic and uniform approach to Planning, Programming, and

Budget.

The RMMS is a simple Microsoft Access based database with Visual Basic as frontend

and Crystal Reports as Reporting tool, which captures data pertaining to traffic, road

and bridge inventory and dimensional parameters, location, pavement structure as

originally laid; pavement intervention history and age of the latest layer, pavement and



12

bridge condition and inventory of roadside land use and structure. The format is

provided to all field offices of HP where the updated data is fed in and then transferred

to the HQ in Shimla by CD or e-mails. This data is then interfaced with back-end

software which analyses and prioritizes the road stretches based on the road conditions

and other important factors for each road.

Brief objectives of the RMMS are given below based on our preliminary review.

Integrate all PWD road management activities from inventory to generation of

reports;

Help PWD in decision making process and ensure that road maintenance remains

regular and timely;

Assist PWD in planning, Programming, Budgeting, Monitoring and Implementation

of their Annul Maintenance Plan for their entire road network;

Improve the present database in terms of integration of data with other data,

security and accuracy of data by designing uniform database;

Provide up to date information for Senior management personnel for making

effective decisions;

Flexibility to accommodate changes for future enhancements from the current

database to any Relation Database Management System with or without much

changes to the existing database design;

Operate under computer systems and software compatible with the existing

systems being used by PWD.

To have a uniform and user friendly interface for accessing.

The existing system has been highly successful; however, HPPWD/HPRIDC recognizes

that the current application has several deficiencies with the key issues being:

Obsolescence technology due to unsupported software (Visual Basic 6);

Poor usability of the desktop client;

No centralised access by its Zonal and Divisional offices.

The advantages of converting the existing system to a web-based system with

inclusion of other modules are:

Reduced risks associated with dependency on single or limited users;

Reduced duplication of similar data maintained by multiple departments;

Increased efficiency of sharing of same data across departments/divisions/zones;

Increased efficiency of road maintenance planning and operation;

Enhanced capacity for operation and maintenance of RMS.

1.6 Review of Current Processes and Practices

HPPWD is currently using 16 data collection templates defined for Road Inventory &

Condition, Bridge & Culvert Inventory & Condition data and Traffic Volume data. These

data collection formats have been reviewed and proposed to use separate formats for

SH & MDR and Rural roads.



13

Himachal Pradesh Rural Roads maintenance Policy 2015 notified by the Govt. of H.P is

being followed. The policy takes into consideration the Government’s commitment to

funding and ensuring transparency in its working, bidding, e-tendering, contract

management and implementing rural road maintenance.

The existing technical and managerial staffs of HPPWD are very familiar with the data

formats and manual data collection procedures. They are not aware of usage of

automated data collection equipment’s such as ROMDAS. Only couple of staff at HQ are

familiar with usage of such equipment.

1.7 Proposed Road Management System (RMS)

Road Management System (RMS) will have the following sub-modules (components):

GIS linked Road Information System (RIS): This is a database linking different road

data items. It will be accessed either from a centrally linked server or as a

distributed database, which is independent of any network. GIS will be used as the

basic platform for all spatial features for road assets. Furthermore, the components

will be accessible via an Internet Browser for reporting purposes only.

Bridge Information System (BIS): This is a database linking different bridge data

items. The BIS database shall contain sufficient attributes to maintain the bridge

diary besides some 3 to 4 critical attributes to determine investment and

rehabilitation needs in bridges.

Pavement Management System (PMS): This will cover preservation of existing road

network as well as expansion which may cover new links, multi-laning, or capacity

increases. The PMS will be developed using HDM planning tool, which will include

deterioration prediction model for bituminous pavements. The processes will

include, but are not limited to:

o network-level planning;

o project-level planning;

o multi-project programming and budgeting;

o optimization of projects under budget constraints;

o overall network performance monitoring and evaluation against projected

targets.

Routine Maintenance Management System (RMMS): This application will be created

for determining routine maintenance investments for sections not receiving periodic

maintenance or improvements in that year.

Right-of-Way Features Information Management System (RWFIMS): This

application will be created to maintain all features such as structures, utility

services both below and above ground, trees etc, within the Right of Way (ROW)

and to generate strip maps showing these features. All required information and

maps will be supplied by HPPWD/HPRIDC.

Traffic Information System (TIS): This will be linked to the RIS. This will have

facilities for storing regular and special traffic counts as well as the outcome from

specific studies and also to interface with RADMS to show accident statistics.



14

1.7.1 Comparison of As-Is and To-Be RMS System

The details of the existing RMMS system (As-Is) is given in section 3.1 above and

details of the proposed RMS system (To-Be) is given in section 3.6 above. The

summary of comparison As-Is and To-Be system is given below in Table 1.1

Table 1-1: Comparison As-Is and To-Be System

S.No. Feature / Function Existing RMMS (As-Is) Proposed RMS (To-Be)

Modules

1 GIS linked RIS Available without GIS Available

2 PMS with HDM4 Available without HDM4 Available

3 GIS linked BIS Available without GIS and

maintenance needs

Available

4 RMMS Available Available

5 RWFIMS Available Available

6 TIS Available without Axle load

data

Available

Technical Features

1 Web based system No Yes

2 System Architecture Old and obsolete Latest / current

3 Centralised database No. Multiple versions of

database exists

Yes

4 Historical Data with Flagging

latest data

No Yes

5 Data accuracy and range

validations

Partially Yes

6 Bulk import of data No Yes

Functional Features

1 Use of Axle Load data and

traffic capacity ratios for CRN

roads

No Yes

2 Generation of Strip maps

showing ROW features

No Yes

3 Prioritization and ranking

system based on economic

and other factors

It is not done on basis of

economic analysis

Yes



15

S.No. Feature / Function Existing RMMS (As-Is) Proposed RMS (To-Be)

4 Generate yearly needs for

road widening, pavement

strengthening, bridges and

maintenance

No. it only generates

maintenance needs for

roads.

Yes

5 Preparation of multi-year

rolling program for network

improvement

No Yes

6 Referencing system Needs improvement Issues will be addressed

1.7.2 Institutional Setup

Institutionalization means ‘to make part of a structured and well-established system’.

Aspects considered to be important in institutionalization of an RMS are those that are

similar for any management system. They should include:

Establishment of an organizational unit with specific responsibility for the system;

Establishment of a budget for the operation of the entire system, including all

staffing, equipment, data collection (contract or in-house), field travel, etc.;

Presence of appropriately qualified personnel, with good management skills, with

access to and control over their budget;

Specific and detailed job responsibilities for all aspects of the system;

A program for continual quality improvement;

Clear management reporting; and,

A regular audit of all elements and the taking of corrective actions where

necessary.

In order to fulfil the above mentioned institutionalization requirements, we propose for

establishing an organizational unit (RMS cell).

At present HPPWD is not having good institutional set-up to sustain the present RMMS

system. It is manned at HPPWD HQ by 1-2 junior level staff.

1.8 Data Requirements for RMS

The cost of data collection tends to be the largest component of managing and running

RMS. Further, the direct benefit of frequent (or regular) collection of information should

be justified for continual allocation of funds for collection of information. Hence, the

data requirements including method and frequency of collection were chosen very

carefully, after thorough review of all plausible options, to provide the anticipated

sustainability to the RMS.

The collection of data items suggested for the purpose of development and subsequent

update of the RMS is given in Table 1-2.



16

Table 1-2: Data Collection

Data Item Selection Method

Annually

Surface distresses Mandatory Windshield / Video logging

Roughness Mandatory Automated

Shoulder and Drain condition Mandatory Windshield

Traffic volume and Axle loads Mandatory Manual / ATCC / Transcription

Other condition Optional Windshield / Video logging

Structures condition Mandatory Visual

ROW video Optional Automated

Every 5 Years

Network * Mandatory Automated

Road Inventory * Mandatory Windshield / Video logging /

Transcription

Pavement deflection, Composition and

History

Mandatory Automated / Transcription

Structures inventory Mandatory Visual

* Validation survey suggested every 5th year subject to availability of funds and considering the

reliability of the data obtained from other sources.

1.9 Data Collection Method

The data will be collected by using semi-automated and some automated equipment for

inventory and condition items. Survey will be performed continuously in each direction

at speeds of 30 km/h to 50 km/h. The visual condition data will be recorded over 500

m interval and inventory data will be recorded as they occur or change. A summary of

the data items to be collected and proposed method are given in Table 1-3.

Table 1-3: Method of Data Collection

Date Item Equipment / Method Module / Source

Location Reference ROMDAS DMI, Keyboards and Trimble SPS 461 or

equivalent

Road Inventory ROMDAS Keyboard

Visual condition ROMDAS Keyboard

Roughness ROMDAS Bump Integrator



17

Date Item Equipment / Method Module / Source

Bridge Inventory Visual Aided by tape measure and still camera

Bridge Condition Visual Aided by tape measure and still camera

Culvert Inventory Visual Aided by tape measure and still camera

Culvert Condition Visual Aided by tape measure and still camera

Pavement Deflection

(Strength)

FWD In-Vehicle mounted double mass

Pavement History Test pits / Transcription Test Pit survey / Zonal and Divisional

offices etc.

Axle Load Static Axle load pads Portable pads

ROW Video (Optional) ROMDAS HD Video

Traffic Volume Counts Manual Traffic 3 day count surveys

The location of the inventory features can be obtained through the chainage

measurement (from DMI) and GPS coordinates (from DGPS).

1.10 Simplified Data Collection for RMS (Rural Roads)

Presently the existing RMMS is catering for rural roads, SH and MDR’s. However,

maintenance requirements of SH and Rural roads are different. Rural roads may not

require such large number of data items. A simple PCI based data is proposed for

prioritisation of maintenance activities.

Presently the data collected involving large number of data attributes which involve a

huge human effort, makes the field teams either to fill in partial or incomplete and/or

false data. Hence, it is proposed to simplify the data collection procedures.

1.11 Budgeting and Maintenance Planning

The Pavement Management System (Planning and Budgeting tool) will be used for

rating and prioritisation of SH & MDR roads.

The priority for assessing the non-routine road needs for preservation of the Rural &

Other road network will be done by calculation of a Road Condition Index and will be

undertaken within the RMS database, using selected road condition data collected

during the annual item condition data survey carried out prior to November each year.

The percentages and ratings for each selected defect will be automatically calculated

for use in developing the final prioritisation list.

1.12 Key Consideration for RMS System Architecture

We believe that HPPWD/HPRIDC currently faces several key business and technical

challenges that must properly be addressed to ensure that the proposed RMS is

efficient and sustainable. Some of these challenges are listed below:



18

1.12.1 Technical Challenges

The technical challenges faced by HPPWD/HPRIDC include:

To provide uninterrupted access to users;

To provide centralized data storage and archival for all the sites around Himachal

Pradesh State;

To minimize effort (cost) of deployment, including both hardware and software;

To reduce cost of server maintenance;

To provide a complete scalable solution, considering the future growth of

HPPWD/HPRIDC.

To provide a flexible reporting model, to match HPPWD/HPRIDC reporting

requirements.

1.12.2 Deployment Challenges

The deployment challenges faced by HPPWD/HPRIDC include:

To support full scale-out capability, including upgrading hardware and software

without changing the source code;

To support high availability capability, including meeting peak capacity with one

failed node;

To provide maximum performance within the system architecture;

To support high maintainability, with minimum or no downtime to deploy patches

and upgrades to the application and/or the operating system;

To support role, area and access based security;

To provide similar or better user experience.

1.13 Conclusion

Road Measurement Data Acquisition System (ROMDAS) from New Zealand will be used

to collect most of the road inventory and condition data. Axle Load Surveys of 24 or 12

hours duration using static Axle weigh pads equipment will be carried out at 40 given

locations on representative basis i.e. loaded full, partial or empty. HD video camera will

be used for recording general alignment of ROW view of the core road network. FWD

test will be conducted at an interval of 1 km. The classified traffic volume count

surveys will be carried out for 24-hours for three (3) continuous days, both bounds at

the identified 40 survey stations.

Road Management system will be developed/configured using HIMS COTS system with

the following modules:








19





20

2. Introduction

2.1 Introduction

The State Government of Himachal Pradesh (GoHP) through Government of India

(GOI) had received a loan from International Bank for Reconstruction and

Development (IBRD) for implementation of Himachal Pradesh State Roads Project

(HPSRP) and intends to utilize a portion of this loan to finance the Consultancy

Services for Technical Assistance to help and establish Road Management System

(RMS), so that it could be used for all state core road network (CRN) in Himachal

Pradesh.

Himachal Pradesh Road and Other Infrastructure Development Corporation Limited

(HPRIDC) awarded the consultancy services contract entitled, Consulting Services for

Technical Assistance to Upgrade Road Maintenance Management System to Road

Management System in the State of Himachal Pradesh, with Contract No. 4860-IN &

8199-IN to HIMS Ltd, New Zealand in joint venture with SATRA Infrastructure

Management Services Pvt Ltd, India. The project commenced on 25 May 2016 with an

expected completion date of 24 May 2018.

2.2 Outline of the Needs Analysis and Architecture Report

This report is divided into two volumes as follows:

Volume 1: Needs Analysis;

Volume 2: Overall System Architecture;

The scope of each volume is described below:

Volume 1: Needs Analysis

This volume includes the scope stipulated in Section 2.4.1 and 3.2 of TOR. This

includes:

Study of existing RMMS and identify strengths and weakness ;

Propose RMS System;

Proposed data collection items, method and frequency of collection;

Proposed budgeting and maintenance planning.

Volume 2: Data Collection Framework

This volume includes the scope stipulated in Section 2.4.2 and 3.3 of TOR. This

includes:

Overall System Architecture;

Hardware & Software requirements;

Study of existing IT infrastructure.



21

2.3 Background for the Project

The construction and maintenance of the State Highways (1,504 km), Major District

Roads (2,139 km) and Rural Roads (27,575 km) totalling to 31,218 km are being

looked after by the Himachal Pradesh Public Works Department (HPPWD). While NHs,

SHs and MDRs carry the bulk of the traffic and are the principal carriers of economic

activities, the State Core Road Network (CRN) comprises of SHs, MDRs and Other roads

connecting NHs in the State with the rural and other roads, totalling to 4,200 km.

The HPPWD has developed a computerised Road Maintenance Management System

(RMMS) for rural roads, SHs, MDRs and Other roads. The software was developed

under the Pradhan Mantri Gram Sadak Yojana (PMGSY), Rural Roads Project in 2007.

Using the RMMS, HPPWD prepares an annual core road network condition report for

rural roads and state roads. On the basis of an indicative budget, annual maintenance

plans (AMPs) focussing on prioritizing periodic and rehabilitation works are prepared.

The program is produced to a timeframe that meets the government’s budgeting cycle

and is revised in an iterative process as more accurate forecasts of the next FY budget

become known.

However, the RMMS has its own limitations, particularly the following functional

aspects:

It lacks the necessary data fields required to prioritise higher class road network

using economic evaluation;

It lacks interfacing facilities with generally accepted maintenance need tools such

as HDM-4;

Current system for data collection on 16 forms is too complex for rural roads.

The HPPWD/HPRIDC intends to upgrade RMMS to RMS to significantly improve and

rationalize decision making in planning, programming, funding, and procurement in the

allocation of resources in road sector in order to make the best use of public funds in

preserving the road networks at an acceptable level of serviceability. The proposed

upgrade of RMMS will improve technical capacities, skills and management capabilities

of the HPPWD/HPRIDC, thus improving the ability of the State Government of Himachal

Pradesh (GoHP) and its subordinate agencies to manage efficiently and cost-effectively

road maintenance and improvement activities.

2.4 Objectives of the Project

The overall objective of the Consultancy Services is to improve quality and delivery of

the services of the HPPWD in planning and programming. The more specific objectives

are:

Review the existing MS-Access based Road Information System in use at HQ and

Field Units;

Creation of additional fields and other information in RIS for its use in latest version

of Highway Development & Management Model (HDM-4) software;

Carry out any changes in the MS Access software for compatibility of data for

producing reports/outputs as per the need of the Client including enhancing

Querying/Reporting;



22

Develop and establish a middleware for linking modified RIS with HDM for smooth

transfer of data between the two or linking which will include data import and

export facilitates between the RMS and other applications and between various

applications and report generation modules. RMS shall be configured, customized

to meet technical, functional and administrative requirements of the Client;

Carry out compliance/pilot testing and validation of all various modules/every sub-

programs/sub-systems and entire upgraded system after full interface with HDM

software;

Transfer skills and procedures to an adequate number of staff in the

HPPWD/HPRIDC for hand-holding and training of trainers to sustain use of the

HDM and RMS during, as well as after the end of these services;

Providing implementation, operation and maintenance support (intermittent) to

HPPWD and HPRIDC for 24 months after all mandatory testing and validations and

third party user acceptance test - Response time of not more than 24 hours and

rectification time not more than 72 hours. That will include trouble shooting,

resolving any problems faced by the HPPWD/HPRIDC, minor modifications and

refinements required in the system to improve its effectiveness based on the

feedback information collected from its use, and removing bugs from the Software.

Thus along with the development and implementation of tools, improvements to the

operational context and capacity building will be vital to the success of the project. This

project will assist HPPWD/HPRIDC in the whole maintenance planning, programming

and implementation cycle. The system applications adopted will, together with

organisational capacity development, be instrumental in improving the overall

efficiency and sustainability of the HPPWD.

2.5 Scope of Services

The broad scope of the Project is to upgrade RMMS to RMS. The specific tasks included

the following, which are summarised from the broad scope mentioned in the TOR:

2. Study existing Road Maintenance Management System, assess and identify the

strengths and weaknesses of the current data format, processes, planning and for

maintenance management practices, decision-making process, organisational

structure, and technical and managerial capabilities of the HPPWD/HPRIDC and

propose changes aimed at providing adequate support for the RMS and ensuring

that upgraded system will be efficient, effective and sustainable;

3. Establish and implement Road Management System based on the need analysis

and gaps of the current system;

4. To provide training to identified HPPWD/HPRIDC staff in the use and maintenance

of the system;

5. Upgrade RMS with the following components, using (COTS) Commercial Off the

Shelf :






23





6. Undertake a Road and Bridge Condition survey and collect the required inventory

data for input into the Road Management System (as per the quantities

mentioned);

7. Define required human resources and organisation structure to manage Road

Management System (RMS) and define plans for training programs required to use

the upgraded system.



24

VOLUME I:

NEEDS ANALYSIS



25

3. Needs Analysis

3.1 Review of Existing RMMS System

The Himachal Pradesh Public Works Department (HPPWD) is already using the existing

Road Maintenance Management System (RMMS) for SHs, MDRs, Rural & Other roads.

The RMMS was established in the State of Himachal Pradesh under World bank funded

Pradhan Mantri Gram Sadak Yojana (PMGSY) Rural Roads Project-I in the year 2007.

HPPWD is running this system successfully since then.

A Road Maintenance Management System (RMMS) is information based computer

package which facilitates maintenance management-planning tool, based on objective

data, providing a systematic and uniform approach to Planning, Programming, and

Budget.

The RMMS is a simple Microsoft Access based database with Visual Basic as frontend

and Crystal Reports as Reporting tool, which captures data pertaining to traffic, road

and bridge inventory and dimensional parameters, location, pavement structure as

originally laid; pavement intervention history and age of the latest layer, pavement and

bridge condition and inventory of roadside land use and structure. The format is

provided to all field offices of HP where the updated data is fed in and then transferred

to the HQ in Shimla by CD or e-mails. This data is then interfaced with back-end

software which analyses and prioritizes the road stretches based on the road conditions

and other important factors for each road.

Brief objectives of the RMMS are given below based on our preliminary review.

Integrate all PWD road management activities from inventory to generation of

reports;

Help PWD in decision making process and ensure that road maintenance remains

regular and timely;

Assist PWD in planning, Programming, Budgeting, monitoring and implementation

of their Annul Maintenance Plan for their entire road network;

Improve the present database in terms of integration of data with other data,

Security and accuracy of data by designing uniform database;

Provide up to date information for Senior management personnel for making

effective decisions;

Flexibility to accommodate changes for future enhancements from the current

database to any Relation Database Management System with or without much

changes to the existing database design;

Operate under computer systems and software compatible with the existing

systems being used by PWD.

To have a uniform and user friendly interface for accessing.



26

The roadway and pavement related data required for the RMMS is required in two

distinct but interconnected operations; road inventory and road condition. The data

flow chart is given in Figure 3-1.

Road Inventory:

Road Name, Category and Location;

Road Sections

Pavement and Surface types;

Pavement Structure and Treatment history;

Road Condition

Pavement surface condition;

Cross drainage condition;

Roadside condition;

Traffic by number and type; and

Pavement surface roughness.



27

Figure 3-1: Flow diagram of RMMS system

HPPWD is currently preparing periodic and other maintenance using RMMS. The

categories of road maintenance include:

Routine Maintenance;

Emergency Works;

Periodic Maintenance; and

Rehabilitation.

A schematic representation of the RMMS operations is given in Figure 3-2.



28

Figure 3-2: Maintenance Management System Operations

Once the data is entered into the system, based on a simple rating analysis, the

maintenance needs are determined as shown below Figure 3-3



29

Figure 3-3: Criteria for Maintenance Needs in Existing RMMS

The Road Priority Index (RPI) will be determined to assign the maintenance priority in

case of budget constraints. RPI will only be used and added to overall rating when

funding constraints are imposed to provide a final ranking and road section

prioritization for maintenance as shown in Figure 3-4



30

Figure 3-4: Road Priority Index (RPI)

3.1.1 Strengths of RMMS system

Some of the major strengths of the RMMS, derived from our initial quick review are:

For a rural road network, this level of prioritization and ranking is fairly robust and

good;

Able to generate yearly maintenance requirement and prioritisation needs

effectively.



31

3.1.2 Weakness of RMMS system

Some of the major shortcomings of the RMMS, derived from our initial quick review

are:

Technical Issues

No Centralised data / system access is available. Multiple versions of MS access

databases are available and difficult to select the correct database.

Data transfer from field offices to HQ is not efficient or secured;

Crystal Reports Tool needs to be installed and expert user is required to

generate critical / advanced reports.

Most of the functionality including validation rules are hardcoded, hence editing

of the source code is required in case of any changes even in data fields;

Interfacing with maintenance need tools, such as HDM-4 is not provided for

higher order roads;

Linkage to GIS is either not developed or not functioning;

Interfacing with other legacy systems, such as Project Management Information

System (PMIS) is not provided (requires source code changes);

The system architecture is old and obsolete in the current context;

The application development framework (Visual Basic) is obsolete and no

support is available for Microsoft;

Other components, MS Access and Crystal Reports require major upgrade or

possibly replacement.

Functional Issues

This does not take into account the traffic capacity ratios, cost requirement for

different interventions, the axle-load data, pavement deterioration models and

widening options etc. which will become essential when applying the model to

the core network roads;

Location reference management (editing, splitting or merging of links and

roads) and history network changes are not maintained;

HDM4 interface is not available;

Data entry is tedious (no bulk import facility provided);

Facilities for recording actual maintenance performed or exclusion of committed

projects sections from analysis are not provided;

3.2 Review of current data formats

HPPWD is currently using 16 data collection templates defined for Road Inventory &

Condition, Bridge & Culvert Inventory & Condition data and Traffic Volume data. These

data collection formats have been reviewed and detailed in the following sections.

3.2.1 Understanding of current data formats

3.2.1.1 Road Inventory Data

Road Inventory data is collected using following forms

RDS01 – Road Section Determination Detail: used to capture the following:

Road Location details;

No. of Lanes;



32

Top surface type.

RDS01(A) – Road Sections, Average Top surface width Determination Detail: used

to capture the following:

Road Location details;

Length of survey section;

Carriageway width;

Surface area.

RDS01(B) – Road Inventory Detail: used to capture the following:

Average Right of Way in m;

Average Formation Width in m;

Embankment / Cutting / Both;

Month of year of Construction;

Pavement Thickness in mm;

Sub grade Type;

Sub Grade Thick in m;

Sub Grade CBR in %;

Sub Base Type;

Sub Base Thick in mm;

Base Layer - I Type;

Base Layer - I Thick in mm;

Base Layer - II Type;

Base Layer - II Thick in mm;

Original Surface Layer Type;

Original Surface Layer Thick in mm;

1st Treatment Type;

1st Treatment Thickness mm;

1st Treatment Month & Year;

2nd Treatment Type;

2nd Treatment Thickness mm;

2ndTreatment Month & Year;

3rd Treatment Type;

3rd Treatment Thickness;

3rd Treatment Month & Year;

Shoulder Type;

Left Shoulder Width in m;

Right Shoulder Width in m.

RDS02 – Bridge, Major culverts and Cause Ways (>=6M Span) Inventory Detail:

used to capture the following:

Structure Type;

Structure No.;

Chainage (km);

Structure Name;

Constriction Year;

Constriction type;

Structure Length in m;

Span Type;

No. of Spam / Vents;

Clear Carriage Way in m;



33

Footpath Yes / No;

Name of Stream / River;

Foundation Type;

Foundation Size (LxBxD) in m;

Cut Off Wall (U/S) Type & Size (LxBxD) in m;

Cut Off Wall (D/S) Type & Size (LxBxD) in m;

Abutment (Near) Type;

Abutment (Near) Size (LxBxD) in m;

Abutment (Far) Type;

Abutment (Far) Size (LxBxD) in m;

Pier Type;

No. of Piers;

Pier Size (LxBxD) in m;

Cross Head Type & Size (LxBxD) in m;

Wing Wall Type & Size (LxBxD) in m;

Super Structure Type;

Hand Rail Type;

Bearings Type;

Wearing Coat Type;

Parapets in No.;

Guide Posts in No.;

Sins With Legend in No.;

Batter Protection Type;

Highest Flood Level in m;

Deck Level in m;

General Bridge Condition (Good/Fair/Poor);

RDS03 – Culvert and Side Drains Inventory Details: used to capture the following:

Culvert Type;

Culvert No.;

Culvert Chainage in km;

Vent Size (mm) or (WxH) in m;

No. of Vents;

Culvert Length in m;

Head Wall/Abutment Type;

Head Wall/Abutment Size (LxWxH) in m;

Toe Wall Type;

Toe Wall Size (LxWxH) in m;

Catch Pit Type;

Catch Pit Size;

Hand Rail Type;

Parapets in No.;

Guide Posts in No.;

Wing Wall Size (LxWxH) in m;

General Condition (Good/Fair/Poor);

Drain Side Left/Right;

Drain Type (Lined/Unlined);

Drain Shape (U/V);

Drain Size (WxD) in m;

RDS04 – Habitation Inventory Detail: used to capture the following:

Section Chainage in km;



34

Connected Habitations in No.;

Name of Connected Habitation;

Habitation Code;

Total Population;

All Weather Road: Yes / No;

Motorable Road: yes / No;

Terrain Type Plain, Rolling, Hilly, Mountainous: Yes / No;

Annual Rain fall Light<700 mm, Medium 701-1500 mm, Heavy 1501 mm and

above: Yes / No;

Educational Facilities Elementary, Secondary and above: Yes / No;

Health Facilities Sub-Centre and PHC/CHC and above: Yes / No;

Administrative Head Quarter Division, Block, District: Yes / no;

Other Facilities Tourist Place, Religious Place and Telephone Booth: Yes / No;

RDS05 – Signs/Furniture, Marker posts and Miscellaneous Inventory Detail: used to

capture the following:

Signs / furniture Type , Legend in no;

Distance Markers Hectometre Stones, Kilometre Stones, Five Kilometre Stones,

Historic Markers in no.;

Guard Stones Side (Left/Right/Both);

Edge Stones in No.;

Guide Posts in no.;

Parapets type in No;

Intersections Chainage in km;

Intersections Side (Left/Right/Both);

Intersections to (Road No as per DRRP);

Hand Pump in No.;

Water Tanks in No.;

Electricity Poles in No.;

Telephones in No.;

Tree in No.

RDS-GIS – Road Side Inventory Detail: used to capture the following:

Rest House: Yes / No;

Circuit House: Yes / No;

Rain Shelter: Yes / No;

Bus Stand: yes / No;

Parking Place: Yes / No;

Railway Station: yes / No;

Rest Place (Hotel): Yes / No;

Water Spring: Yes / No;

Land Slide Prone Area: yes / No;

Accident prone Area: yes / No;

Foggy Area: yes / No;

Mining Area: Yes / No;

Snow Bound: Area Yes / No;

Desert: Yes / No;

Arboriculture (Plantation): Yes / No.

RDS06 – Retaining Walls / Breast Walls Inventory Details: used to capture the

following:



35

Retaining Walls / Breast Walls Chainage in km;

Construction Type;

Footing (LxWxH) in m;

Bottom Width in m;

Top Width in m;

Height in m.

RDS07 – Traffic Inventory Details: used to capture the following:

Traffic Survey Station;

Chainge in Km;

Date From;

Date to;

Time (taking time period of 30 Minutes);

Buses Up and Down in No.;

Trucks / Truck Trailors (Rear Axle-I, II, Multi Axle) Up and Down in No.;

Tractors Up and Down in No.;

Car & Jeeps Up and Down in No.;

Auto Rickshaws Up and Down in No.;

Two Wheelers Up and Down in No.

3.2.1.2 Road Condition Data

RCS01 – Road Section, Condition (Damage/Defects) Determination Details: used to


BT Pavements

o Potholes in Sq.m;

o Edge break > 200mm in metre;

o Surface Rutting > 25mm in Sq.m;

o Surface Depressions > 25 mm in Sq.m;

o Single Cracking > 5mm in Sq.m;

o All Cracking in Sq.m;

o Ravelling in Sq.m;

o Delamination in Sq.m;

o Bleeding & Patching in Sq.m;

o Surface Failure in Sq.m.

CC pavements

o Joint Sealant in m;

o Cracked Concrete in Sq.m.

Unpaved Pavements

o Surface Rutting > 50 mm in m;

o Potholes in Sq.m;

o Ravelling in Sq.m;

o Edge breaks in Sq.m;

o Gullies > 40 mm in Sq.m;

o Camber Flat / Depressed in m;

o Pavement Thickness Remaining > 50 mm in mm;

o Surface Failure in Sq.m.

Shoulders

o Low Shoulder / Edge Drop >50 mm in m;

o Deformed / Scoured Shoulder in m;

o High Shoulder in m;

Road Side Drainage



36

o Unlined Drain Blocked >30% in m;

o Lined Drain Blocked >20% in m;

Parapets in Nos.

o Parapets Damaged;

o Parapets Missing;

Kilometre Stones (No)

o Kilometre Stones Damaged;

o Kilometre Stones Missing;

o Five Kilometre Stones Damaged;

o Five Kilometre Stones Missing;

o Total Kilometre Stone Damaged;

o Total Kilometre Stone Missing;

Other Defects / Damage

o Guard Stones Missing in No.;

o Hectometre Stones Missing in No.;

o Signs / Furniture in No.;

o Vegetation / Debris in SQM;

RCS01(A) – Road Section, Pavement Roughness (Non BI assessment)

Determination Details: used to capture the following:

Section Chainage in km;

Most Comfortable & Safe Vehicle Speed (km/Hr);

General Condition;

Paved Surface IRI.

RCS01(B) – Retaining wall & Breast Wall Condition (Damage / Defects)

Determination Details: used to capture the following:

Retaining Wall & Breast wall Chainage in km;

Construction Type;

Retaining Wall & Breast wall Damage in Cubic metre;

Land Slide Cubic metre;

Snow Fall Cubic metre.

RCS01(C) – Flexible Pavement Deflection (B.B.D Test) Determination Details: used

to capture the following:

Chainage of Testing Point in Km;

Test Point (Left / Right);

Pavement Temperature in 0C;

Soil Characteristics

o Type;

o Plasticity Index;

o Moisture Content in %;

Dial Gauge Reading

o Initial;

o Intermediate;

o Final;

Measured Rebound Deflection in mm;

Rebounded Deflection after Correction for 8170 KG in mm;

Rebounded Deflection After Temperature correction in mm;

Seasonal Correction Factor;

Final Deflection after Seasonal Correction in mm.



37

RCS02 - Bridge, Major culverts and Cause Ways (>=6M Span) Condition

(Damage/Defects) Details: used to capture the following:

Structure Type;

Structure No.;

Chainage (km);

Structure Name;

Constriction type;

Structure Length in m;

No. of Spans / Vents;

Debris & Vegetation in SQM;

Railing in m;

Drainage Spouts in No.;

Approach Slab in SQM;

Signs in No.;

Repainting in SQM;

Protection Walls in Cubic Metre;

Stream Maintenance in Cubic Metre;

Deck Jointing in m;

Bridge Deck in SQM;

Super Structure Cubic Metre;

Sub Structure Cubic Metre.

RCS03 - Culvert Condition (Damage/Defects) Determination Details: used to


Culvert Type;

Culvert No.;

Culvert Chainage in km;

Vent (WxH) in m;

No. of Vents;

Vent Cubic Metre / Metre;

Silt Cubic Metre;

Head Wall/Abutment

o Right Hand Side / Near Side in Cubic Metre;

o Right Hand Side / Far Side in Cubic Metre;

o Total Quantity in Cubic metre;

Catch Pit

o Right Hand Side in Cubic Metre;

o Left Hand Side in Cubic Metre;

Aprons

o Up Stream Side in Cubic Metre;

o Down Stream Side in Cubic Metre;

o Total Quantity in Cubic metre;

Scouring

o Up Stream Side in Cubic Metre;

o Down Stream Side in Cubic Metre;

o Total Quantity in Cubic metre.



38

3.2.2 Strengths of current data formats

Some of the major strengths of the current data formats, derived from our initial quick

review are:

Data collection formats are very detailed enough which is good for project level

analysis;

These are suitable for SH and MDR roads only;

3.2.3 Weakness of current data formats

Some of the major shortcomings of the current data formats, derived from our initial

quick review are:

Data collection formats are too cumbersome which makes the field teams either to

fill in partial or incomplete and/or false data;

These data formats are not suitable for Rural roads as these are low traffic roads

and such a detailed analysis is not required;

It takes lot of time to collect such a detailed data manually.

3.3 Policy, Processes and Practices

3.3.1 Current Road Maintenance Policy

Himachal Pradesh Rural Roads maintenance Policy 2015 has been notified by the Govt.

of H.P on 30th March 2015 and is in place. The policy takes into consideration the

Government’s commitment to funding and ensuring transparency in its working,

bidding, e-tendering, contract management and implementing rural road maintenance

as under:

Introduce a system of working out present asset value of the road network at the

end of financial year;

Constitute a State level committee to work out realistic norms for maintenance of

rural roads covering Routine, Periodic, Emergency Maintenance and Special

Repairs;

Overall responsibility for efficient planning management and delivery of rural road

maintenance shall be of HPPWD including coordination with other departments

handling the work of rural roads. A dedicated Planning, Budgeting and Monitoring

(PBM) Unit, in the PWD Head Quarters to be headed by a Superintending Engineer,

which shall be responsible for Planning, Budgeting and Monitoring of all

maintenance works of the road network under the overall guidance of the Engineer-

in-Chief, HPPWD;

To ensure allocation of adequate and timely availability of funds needed for

maintenance of rural roads as per Annual Maintenance Plans, prepared by the

HPPWD, a dedicated maintenance fund shall be created on the basis of funds

already created for maintenance of PMGSY roads;

Govt. shall constitute a Standing Empowered Committee to decide on annual

allocation of funds for maintenance of different categories of roads with reasonable

share for rural roads based on the percentage of rural roads with respect to the

total road network. The EC may comprise of Secretary Finance, Secretary (PW),

Engineer-in-Chief, HPPWD and other representatives/ consultants;



39

Explore avenues for mobilising of additional funds for reducing the gap between the

funds required and those made available for maintenance of rural roads;

Formulate an Action Plan for time bound removal of maintenance backlog of the

rural road network so that the network is brought to an acceptable level of service.

HPPWD shall institute an annual performance evaluation system to inform the

government about the delivery of maintenance and condition of the rural road

network as a result of funds allocated for the purpose;

HPPWD shall simplify the existing Road Maintenance & Management System

(RMMS) for rural roads to prepare Annual Maintenance Plans for each PIU, based

on scientific condition assessment of the road network;

Set up Special Zonal Task Forces in each PWD zone to deal with emergency

situations arising due to natural disasters, headed by Zonal Chief Engineer, SE

(Design) of the Zone and concerned SE of the Circle as members;

The field units of HPPWD shall collect/outsource the collection of road condition

data and inventory data and capture the condition of roads through

photographs/videography (having longitude & latitude) of locations and such details

shall be uploaded suitably on the department website;

Some pilot works of maintenance shall be undertaken jointly by PIU of HPPWD and

relevant blocks/gram panchayats and steadily move towards devolving

maintenance responsibility in respect of rural roads to Panchayati Raj Institutions.

Similar pilot project shall be undertaken with the involvement of local community

participation;

Training shall form an integral part of Institutional strengthening of the HPPWD. For

this, HPPWD shall formulate a calendar of training programmes for its technical

officers at various levels. Training modules shall be developed for imparting both

on-site as well as off-site training to field staff. Training programmes shall also

include study tours aimed at exposing officials to national/ international best

practices;

HPPWD shall extend support in providing outreach programmes in enhancing the

training facilities for Class C and Class D contractors in implementation of

maintenance works;

The HPPWD shall identify and pilot innovative maintenance models and

technologies. These innovations shall be in the form of piloting and adopting

different models of outsourcing maintenance works which could be in the form of

Performance Based Maintenance Contracting (PBMC), Community Contracting or a

hybrid system involving combination of PBMC and conventional Engineering,

Procurement and Construction (EPC);

The HPPWD shall undertake road user satisfaction surveys every three years on its

rural road network and display the results on the website;

3.3.2 Current Road Maintenance Processes & Practises

Road maintenance requires careful planning, supervision and control. It may be divided

into two parts such as:

1. Preparation of annual maintenance plan;

2. Scheduling and annual maintenance calendar.



40

3.3.2.1 Preparation of Annual Maintenance Plan

An Annual Maintenance Plan for any road network shall comprise primarily of the

following components:

Road Inventory Survey;

Road Condition Survey;

Road Priority Index (RPI);

Updated Schedule of Rates;

Cost Estimate;

Prioritization of maintenance activities based upon the available budget;

Scheduling of activities for management, procurement and execution.

The maintenance management cycle with the various steps and their logical sequence

necessary for achieving an effective maintenance management system is depicted in

Figure 3-5.

Figure 3-5: Maintenance Management Cycle

Maintenance Works consists of all works of routine maintenance, periodic maintenance,

road rehabilitation including pavement strengthening, special repairs and emergency

maintenances. The PBM Unit initiates maintenance activities as follows:

Periodic Renewal cycle of 5 years is adopted for roads traversing altitude above

2,000m (snow bound areas) and 6 years for roads traversing altitudes below

2,000m (non-snow bound areas);

HPPWD Specifications are used for State works and Ministry of Rural Development

(MoRD) Specifications are used for PMGSY works;



41

The Field Units (Divisional Offices) are responsible for carrying out the Road

Inventory and Road Condition Surveys as per prescribed procedures. The road

condition surveys are carried out at every 100 m interval by the Junior Engineers in

charge of the respective sections;

3.3.2.2 Scheduling and Annual Maintenance Calendar

The Budgeting and Maintenance Planning schedule followed by HPPWD is as follows and

the Annual Calendar of Road Maintenance Activities is followed as given in Table 3-1.

The surveys will commence immediately after the cessation of monsoon in October

and completed by 15th November;

The survey data is uploaded on the Road Maintenance Management System

(RMMS) by the Divisional Offices by 1st week of December;

The data is processed and results of the entire road network are generated by the

PMGSY HQ staff by 31st December;

PWD HQ finalizes the priority list for Annual Maintenance Plan (AMP) and

disseminates the same to all field offices by 15th January. The field Executive

Engineers on receipt of the approved AMP preforms another verification to confirm

that the roads appearing in the AMP with respect to their jurisdiction actually

qualify for Periodic Renewal and revert back to the HQ by 31st January with full

justification in case any substitution is required. Annual Maintenance calendar is

hoisted on departmental website by March;

Field offices initiate preparation of estimates and invitations for bids for works

proposed to be contracted out for the approved chainages of various roads

immediately and works shall be awarded by 25th March;

Implementation will commence by 10th April except for the tribal areas where the

working season normally starts in May end/June;

The Superintending Engineers in charge of field circles will closely monitor the

progress of the above activities in respect of their jurisdictions;

The Junior Engineer will prepare monthly Maintenance Plan of the roads and

forward it to the Assistant Engineer one week before the commencement of the

respective month for approval;

Table 3-1: Annual Calendar of Road Maintenance Activities

Sr.

No.

Item of Work Intervention

Standard

Response

Time

Frequency Remarks

1 2 3 4 5 6

1. Cleaning/desilting of road side drain/gutter

Thrice

i) February

ii) May and June

iii) August and September and as and when required

i.e. blockade more

than one-fourth

Water diverted out of

drain onto roadway

Causing a

hazard to

traffic

Immediate

Obstruction or Siltation

impeding flow

Blocked by

more than one-

fourth of the

size of the drain

14 days and

prior to

monsoon



42

2. Pothole Filling

Collection of patch repair

material for Bituminous

roads

i) January and

February

ii) July and September

Collection of patch repair

material for WBM repair

i) January and

February

ii) July & August

Pothole filling in

Bituminous and rigid

pavement with maximum

dimension more than

200mm, cracks, edge breaks,

ruts and depressions

All potholes

≤75mm depth

Cracks >5mm in width

Edge Breaks

>150mm in width

Ruts >50mm in depth Depressions >50mm in depth

21 days Immediate on

their occurrence

Pothole filling in WBM with

maximum dimension >200mm

Depth > 75mm 21 days

Pothole filling in Gravel/

Katcha surface

Depth

>50mm

Width

>300mm

45 days

3. Filling edges of

bituminous surfaces and

replenishing/ lowering

earthen/ hard shoulders

Difference

more than (-)

50mm/ (+)

0mm

Before and after

monsoon and as

and when required i.e.

when the

requirements as

specified are

exceeded as per

Col. 3

4. Dressing of berms Before and after

monsoon and once in

between

i.e. February/ March,

June, August and

September

5. Restoration of rain cuts and

side slopes

September and as and

when required



43

6. Cleaning of Cross-

Drainages

Debris and silt reducing

effectiveness of structure,

broken or cracked structure

causing instability, under

mining or not functioning

properly

Blocked by more

than one-fourth

of the size of the

culvert opening

14 days Twice (May and October)

and as and when

required i.e. blockade

more than one-fourth of

the opening

Deformation of culvert, its

invert and alignment

45 days prior to

monsoon

7. White washing of

Parapets, Guide Stones,

Tree Trunks etc.

Twice (April and

October)

8. Re-fixing disturbed

caution boards, other

signage etc.

Once and as and

when required

9. Re-fixing displaced Km.

stones, 200m stones,

guard stones, guard rails

Once and as and

when required

10. Cutting of branches of

trees, pruning shrubs

Once (October)

11. Removing wild seasonal

growth on berms and

from road side

structures

Twice (March and

September)

12. Painting of Km. stones,

Numbering of culverts, Road

markings etc. including

history of road on Km.

stones

Once (April/

November)

13. Maintenance of T & P All round the year

14. Removal of

encroachment All round the year



44

3.4 Organisational structure

Himachal Pradesh Public Works Department is responsible for the operation and

maintenance of the entire road network under its jurisdiction. The

administrative control of the department rests with the Secretary to the Government of

Himachal Pradesh. The Engineer-in-Chief is overall in-charge of the department. The

construction and maintenance of the network comprising State Highways, Major District

Roads and Rural Roads is supervised by the Zonal Chief Engineers who have control

over the field Circles with each circle headed by a Superintending Engineer. These

circles are further divided into field Divisions each headed by an Executive Engineer.

Similarly, these field divisions have a number of sub-divisions headed by an Assistant

Engineer. The Assistant Engineers are assisted by a number of Junior Engineers each of

whom is in-charge of a section. The Junior Engineers are in turn assisted by Works

Inspectors/Mates etc.

A dedicated Planning, Budgeting and Monitoring (PBM) Unit in the PWD is headed by a

Superintending Engineer who is responsible for Planning, Budgeting and Monitoring

of all maintenance works of the road network under the overall guidance of the

Engineer-in-Chief. This unit comprises of one Executive Engineer, two Assistant

Engineers, two Junior Engineers, one Draftsman and two Computer Operators. The

Deputy Controller (F&A) will assist the Superintending Engineer of the PBM Unit in all

financial matters.

Technical audit of sample stretches as well as quality inspections is conducted by the

Quality Control wing of the PWD.

A snapshot of the total strength of the HPPWD is given in Table 3-2

Table 3-2: HPPWD Staff Strength

Position Number

Engineer-in-Chief 1

Engineer-in-Chief (QC & D) 1

Chief Architect 1

Chief Engineers 7

Superintending Engineers 35

Senior Architect 4

Executive Engineers 108

Architect 8

Assistant Engineers 374

Assistant Architect 13

Junior Engineers 1,342

Total Number of Staff 1,894

The organisation structure of HPPWD is given in Annex IV.

It is understood that currently HPPWD is operating RMMS with one or two staff.



45

3.5 Technical and Managerial Capabilities

The existing technical and managerial staffs of HPPWD are very familiar with the data

formats and manual data collection procedures. They are not aware of usage of

automated data collection equipment such as ROMDAS. Only couple of staff at HQ are

familiar with usage of such equipment.

It is understood that they have collected data for about 900 km of SH & MDR network

since the procurement of ROMDAS equipment in 2007-08.

Only couple of staff at HQ PMGSY department are familiar with Data processing,

analysis and generation of annual maintenance plans.

Duties of various HPPWD staff are mentioned below:

3.5.1 Duties of Mate

To report to Work Inspector/ Junior Engineer.

To mark daily attendance of labour working under him.

To help in the layout, marking, checking the quality and quantity of work done by

the labour and get the work executed as per instructions.

To assist the Work Inspector/Junior Engineer in taking out the

measurement for daily work done by labour.

To display necessary caution boards from safety point of view as per standard

layout.

To report to his senior about any causality, accident, encroachment of Government

property or any type of serious damage to the Government property within his

beat.

To maintain T & P and sign boards under his charge.

To carry out jobs of semi-skilled nature connected with his trade along with his

gang.

General supervision over un-skilled labour.

To get cement/composite mortar prepared in his presence as per instructions of

Junior Engineer/Work Inspector.

To report about damages to structures, kilometer stones etc. and keeping them in

position.

To comply with any instructions given by his immediate superior.

Daily labour report, D.L.R.

To ensure adequate quantum of work being done by gang and that it conforms to

norms.

To keep account of permanent articles, for example direction boards, trees, drums

etc. in his beat.



46

To ensure providing and proper upkeep of diversion boards.

3.5.2 Duties of Work Inspector

To report to Junior Engineer.

To maintain daily diary of the work done and to put up to the Section Incharge

every alternate day.

To maintain daily receipt/daily consumption of material consumed.

To help in preparing estimates for minor works and repairs.

To ensure execution of work according to specifications and drawings.

To take round of various bridges and roads under his charge on regular basis and

report to section in-charge about repairs to be done. He shall also assist to plan out

a programme for such repairs in advance and ensure their execution through the

department labour within the specified period.

To assist Junior Engineer in taking out measurements and distributing work to

labour daily and checking their attendance.

To estimate and indicate rough quantities of materials required

To take measurement of daily work done.

To ensure adequate quantum of work being done by gang and that it conforms to

norms

To maintain material account at site and account of traffic signs.

To report about unauthorized constructions and encroachments on government

premises.

To comply with the instructions given to him by his immediate officer.

To ensure submission of daily report.

To see that log books are filled daily for machinery and that machinery is parked

properly.

To maintain details of land width and check encroachments. (xvii)To ensure proper

maintenance of speed humps and caution boards including their painting.

3.5.3 Duties of Junior Engineers

Inspection and supervision of works as per prescribed norms.

Recording the progress of both casual and regular labour in the Measurement Book

(MB) and ensuring that the output of labour matches with the norms specified for

different tasks.

No progress in MB be entered as ‘unsusceptible to measurement’ and progress of all

activities be recorded.

Reporting observations to higher authorities.

Preparing estimates for repairs after conducting condition survey of roads.



47

Reporting about closure of road/obstructions due to any of the following reasons;

Over toping/breach;

Landslides;

Earth quakes;

Accident;

Any other reason (specify);

Arranging for removal of obstructions such as dead animals, trees and other debris

lying on road.

Enumerating safety measures and restoration works in case of flood damages and

breaches, and submit reports on opening of traffic/completion of restoration.

3.5.4 Duties of Assistant Engineers

Inspection and supervision of works as per norms.

Reporting observations with suggestions for remedial action to higher authorities.

Getting estimates prepared and checked after conducting surveys and site

investigations.

Reporting about heavy rain fall in the area and consequent rain damage.

Enumerating action on the report of Engineering subordinates regarding

obstructions, accidents etc.

Enumerating safety measures and restoration of (both temporary and permanent)

works in case of flood damages and breaches.

3.5.5 Duties of Executive Engineers

Inspection and recording of observations as per prescribed norms.

Planning and finalization of nature of maintenance activities e.g. surface repair, etc.,

and prepare to CD works etc.

Arranging men, materials and machinery in advance as per requirements.

Finalizing action on reports of Assistant Engineers and also on safety measures,

diversions in case of breaches and flood damages.

Coordination with various agencies like Traffic Police, Local Administration, Publicity

Media etc., in case of emergency repairs, interruption to traffic by road blockage,

etc.

Initiate steps for finalizing permanent restoration works.

3.6 Proposed RMS system

3.6.1 Background

The RMS will be developed to cater to two set of operations: one for the SH and MDR

road network and other for Rural / Other road network. This web-based system will



48

become a comprehensive Asset Register capable of providing a variety of information

to wider stakeholders, both internal and external with a click of a mouse. Further, users

are able to drill down the map to audit and extract information available within the

system. The system will have facilities for determining the maintenance needs not only

on current condition but also considering the Life Cycle Cost (LCC) analysis.

TOR stipulated simple, flexible but sustainable RMS to be deployed as part of this

Project. Therefore, our focus will be on conceptualising, designing and deploying a

simple and sustainable RMS.

3.6.2 Proposed Functionality

Proposed Road Management System (RMS) will have the following functions/sub-

modules (components):

GIS linked Road Information System (RIS): This is a database linking different road

data items. It will be accessed either from a centrally linked server, or as a

distributed database which is independent of any network. GIS will be used as the

basic platform for all spatial features for road assets. Furthermore, the components

will be accessible via an Internet Browser for reporting purposes only.

Bridge Information System (BIS): This is a database linking different bridge data

items. The BIS database shall contain sufficient attributes to maintain the bridge

diary besides some 3 to 4 critical attributes to determine investment and

rehabilitation needs in bridges.

Pavement Management System (PMS): This will cover preservation of the existing

road network as well as expansion which may cover new links, multi-laning, or

capacity increases. The PMS will be developed using HDM planning tool, which will

include deterioration prediction model for bituminous pavements. The processes

will include, but are not limited to:

o network-level planning;

o project-level planning;

o multi-project programming and budgeting;

o optimization of projects under budget constraints;

o overall network performance monitoring and evaluation against projected

targets.

Routine Maintenance Management System (RMMS): This application will be created

to determine routine maintenance investments for sections not receiving periodic

maintenance or improvements in that year.

Right-of-Way Features Information Management System (RWFIMS): This

application will be created to maintain all features such as structures, utility

services both below and above ground, trees etc, within the Right of Way (ROW)

and to generate strip maps showing these features. All required information and

maps will be supplied by HPPWD/HPRIDC.

Traffic Information System (TIS): This will be linked to the RIS. This will have

facilities for storing regular and special traffic counts as well as the outcome from

specific studies.



49

3.6.3 Conceptual Design

The conceptual design of various modules of the proposed RMS was determined based

on the ToR requirements. The detailed functional and technical details of the proposed

RMS are explained below:

3.6.3.1 Location Reference Management System (LRMS)

Location Reference Management System (LRMS) will be developed to maintain

centralised location referencing for RMS. The LRMS forms the core of the RMS, a

system that defines and enforces proper referencing conventions of the roads and

associated assets. RMS will include facilities for linear and geo-referencing (spatial)

features.

The primary functions proposed for Location Reference Management (LRM) are:

to enter, validate and store location referencing data (Road, Link, Node, LRP etc.);

to manage location referencing data for all modules of RMS;

to merge, break, retire links / sections;

to modify location referencing data and trigger relevant changes in other modules

of RMS;

to detect inconsistencies in the location reference system and generate consistent

reports;

to maintain historical changes in the road network.

Process and data flow of LRMS is presented in Figure 3-6.



50

Location Reference Management System

CreateNode

LRPs

Link /

Section /

Route

ModifyNode

LRPs

Link /

Section /

Route

DeleteNode

LRPs

Link /

Section /

Route

Break / Merge / Retire: Link / Section / Route

Data Validation

Centralised

Relational

Database

Data

GPS Coordinates

(km stone, centre

line, node,

chainage)

Satellite Maps /

SOI Maps/

Other Maps

Administrative

boundaries,

GIS Layers

Road Category

Administrative

Setup /

Geographical

Information

Linear / chainage

(km stone, centre

line, node)

LRMS Engine

Generate

Report

Detect

inconsistency

in the

Location

Reference

Data

Correct

Figure 3-6: Process Flow of Location Reference Management

Location reference management is one of the most critical tasks of RMS. It is

recommended that the maintenance of location referencing only be undertaken by an

advanced user such as the Administrator. It is important to understand the road

network definition and its linkages with other attribute data, such as, inventory and

condition data, prior to defining or updating location reference data. The sequence of

operations for both defining and updating location reference data is critical. Any undue

change of the location reference data may break the critical link with attribute

information, thus making data inaccessible and in the end RMS non-functional. It is

recommended to exercise utmost care when working with location reference data. A

sample layout of the advanced options of LRMS is depicted in Figure 3-7.



51

Figure 3-7: Sample LRMS Options

3.6.3.2 Road Information System (RIS)

Road Information System (RIS) or Asset Register (AR) will be developed to store assets

inventory, condition and other relevant information. RIS will provide information to

other sub-systems (modules) within RMS.

Detailed inventory and condition data of Bridges will be stored in Bridge Information

System (BIS).

RIS will have the following key functions:

Enter and store inventory data;

Enter and store spatial data;

Enter and store condition data;

Enter and store pavement condition data;

Enter and store pavement strength data;

Manage historical data;

Identify most recent data;



52

Provide facilities for adhoc and statistical queries;

Provide GIS platform to view network and other attribute data;

Provide summarised (and current) attribute data to other modules such as PMS,

BIS, AIS etc;

Generate thematic maps, tabular reports and charts;

To interface GIS data with other Geographic Information System (GIS)

applications of GOHP like revenue maps and forest maps.

The process flow of RIS is presented in Figure 3-8.

Road Information System

CreateInventory,

Condition

structural

strength

ModifyInventory,

condition,

structural

strength

Retire /

DeleteInventory,

condition

structural

strength

Data Validation

View, Flag Most Recent, Commit, Historical Data

Centralised

Relational

Database

Stored Data

Traffic, Axle

LoadProject Info

Accident

GIS Thematic

Maps

Tabular / Chart

Reports

User

Defined

Reports

Engine

Generate Report

Detect

inconsistency

in the Data

Identify

correctio

ns

Data Input

Pavement

Strength Data

Lookup

Condition Data

Visual /

Equipment

Road inventory

Category, Type,

Width, RoW

width etc

Spatial Data,

Video / Images Data to

other

Modules

(PMS etc)

Figure 3-8: Process Flow of Road Information System

3.6.3.3 Bridge Information System (BIS)

The main purpose of the Bridge Information System (BIS) will be to identify and plan

bridge repairs and improvements in a systematic way, enabling early identification of

deficiencies and applying preventive maintenance. BIS will store bridge inventory and

condition data and source other requisite data from other sub systems, i.e. road

inventory data and traffic data etc. The Decision Tree analysis approach will enable

HPPWD to assess maintenance and rehabilitation needs including preventive

maintenance.

The preliminary process flow of Bridge Information System is given in Figure 3-9.



53

Bridge Information System

Centralised

Relational

Database

GIS Thematic

Maps

Tabular / Chart

Reports

System Setup(One time, and it can be adjusted

by users, based on requirement)

Decision Tree

Unit Cost

Analysis Engine

Run Decision Tree

Assign Priority

Index

Data Input

Images,

Documents,

Drawings

Bridge

condition

Bridge Inventory

Spatial Data

Adjust

Quantity,

Cost

Repair, Maintenance

and Rehabilitation List

with Cost

Figure 3-9: Bridge Information System Process Flow

3.6.3.4 Traffic Information System (TIS)

The Traffic Information System will stores traffic volume data, as well as data from axle

load surveys. This is intended to produce a range of different kinds of analysis/results,

including assignment of traffic on the network, estimation of AADT and traffic growth

forecasts.

TIS will provide following data to other modules of RMS internally and automatically

once invoked by them:

Average Annual Daily Traffic (AADT);

Traffic Composition;

Vehicular Growth Rates;

Vehicle Damage Factor (VDF) etc.

TIS will store the following data:

continuous counts from permanent traffic count stations;

7-day classified traffic counts;

short-term (< 3 day) classified traffic counts;

traffic growth rates;

vehicle fleet characteristics;



54

sample hourly flow data;

processed weigh-in-motion or axle load survey data (i.e. aggregated statistics as

opposed to measurements of each vehicle), if available.

Traffic Information System

Centralised

Relational

Database

GIS Thematic

Maps

Tabular / Chart

Reports

System Setup(One time, and it can be adjusted by

users, based on requirement)

Equivalent PCU

SCF and Socio-

Economic

Equivalent Std

Axle Loads

Elasticity Values

Analysis Engine

AADT

K and D Factor

Vehicle Damage

Factor

Growth Rate

Data Input

Axle Load

Survey data

Traffic count

data for varying

time period viz.

7/3/1 days

Spatial Data

(Traffic count

post locations)

Accident Data

from RADMS

Figure 3-10: Typical Traffic Information System Process Flow

3.6.3.5 Pavement Management System (PMS)

The major functions of the Pavement Management System (Planning and Budgeting

tool) are:

Preservation: What is the appropriate periodic maintenance strategy to preserve

the road asset;

Improvement: What maintenance treatments are required for pavements whose

condition requires a major treatment before periodic maintenance can be applied;

Capacity Augmentation: What capacity (width) is required for current and future

traffic loading.

HDM-4 analysis engine, based on sound engineering and economic priority principles, is

capable of undertaking both strategic and project level analysis appropriate for a

typical road agency such as HPPWD. The HDM-4 based system will have following key

functions:



55

Facility to interface with RIS for obtaining location referencing data;

Homogeneous sectioning methods for dividing roads into appropriate sections for

maintenance;

Data aggregation methods;

HDM-4 input files;

Thematic maps and summary reports.

Process flow of Pavement Management System is given in Figure 3-11.

Figure 3-11: Pavement Management System Process Flow

One of the critical tasks of this sub-system is to determine the appropriate

“Homogeneous Sections”. To facilitate this process, a user interactive edit tool will be

developed in addition to the auto generation of homogeneous sections. A sample

screenshot is given in Figure 3-12.



56

3.6.3.6 HDM-4 Interface

For the PMS application, we will connect the RMS with established and widely accepted

economic evaluation model based on sound engineering and economic priority

principles, capable of undertaking both strategic and project level analysis at the

appropriate organizational levels, namely; Highway Development and Management

Model (HDM-4) latest version.

The latest version of HDM-4 economic evaluation model shall be capable of the

following types of analysis, which should cover both road condition and capacity

improvements.

Network level planning;

Project level planning;

Multi-project programming and budgeting;

Optimization of projects under budget constraints;

Overall network performance monitoring and evaluation against projected targets.

Network Level Planning (Programme Analysis)

The annual work programme (multi-year rolling programme) focuses on treatments on

discrete road sections, needing maintenance. The following definition will be adopted:

Programme Analysis deals primarily with prioritisation of a defined long list of candidate

road projects into a one-year or multi-year work programme under defined budget

constraints. It is essential to note here that, we are dealing with a long list of candidate

road projects selected as discrete segments of a road network.

The multi-year rolling programme will comprise of: (i) identification (road

segment/section); (ii) work programme and treatment; (iii) estimated output; (iv)

estimated costs; and (v) economic priority ranking.

Figure 3-12: Sample Layout of Editing of Homogeneous Sections



57

We will, together with HPPWD, develop and establish the best approach suited for the

context of HPPWD. The PMS will be the key application in this. As part of Performance

Indicators (PIs) analysis and enhancements, we will review existing targets. We will

measure the achievements compared to current targets and investigate reasons for not

meeting targets (if this is the case). Based on this knowledge, we will develop a new

and improved set of targets which is realistic under the given resource constraints. This

means that targets will be set by realistic projected measures under realistic budget

levels, in order to ensure that the new targets set are ambitious, but also achievable.

A typical output from the programme analysis is shown in Figure 3-13.

Figure 3-13: Multiyear Rolling Programme

Project Level Analysis

We will carry the project level analysis studies for CRN in about 830 km for different

technically feasible options such as periodic maintenance, resurfacing, rehabilitation,

reconstruction, widening and geometric improvement etc. Based on the data collected,

these options will be framed in consultation with professors of IIT / Research

Institutions in India working in this area and then discuss it with HPPPWD/HPRIDC.

The analysis will be done using a life-cycle cost and other approaches using HDM-4

model.

Project analysis is carried out to evaluate one or more road projects or investment

options. The application analyses a road link or section with user selected treatments,

with associated costs and benefits projected annually over the analysis period.

Economic indicators are determined for different investment options based on which

the preferred option is selected. We propose this option to include different technically

feasible options such as periodic maintenance, resurfacing, rehabilitation,

reconstruction, capacity improvement, and other improvement and betterment works

in the system.

Sample analysis outputs are shown below for a project level analysis as given below.



58

The following will be included as part of the programme and/or project level analysis

multi-project programming and budgeting;

optimization of projects under budget constraints;

overall network performance monitoring and evaluation against projected targets.

3.6.3.7 HDM-4 Calibration

It is understood that HDM-4 is used as the ‘analysis engine’ in the PMS. In order to

secure reliable analysis output it is imperative that HDM-4 is calibrated to local

conditions. We will perform the calibration and adaptation as needed. The current

traffic and condition data in the RMMS, together with additional data from other

sources will provide an important data pool for this calibration and will presumably

support a Level 2 calibration focussing on the most sensitive data (data with high

impact elasticity on the analysis output). Road data from research centres or from IITs

or other Universities will also be consulted in this respect. We will calibrate HDM-4 for

the Indian conditions preferably hill roads according to the research carried out in India

by any IIT/ research institution in India and will take the help of IIT/ Research

Institutions in India in certifying the parameters.

There are three levels of calibration that is generally carried out (as described in

Volume 5: A Guide to Calibration and Adaptation of the HDM-4 documentation), as

given in Table 3-3.

Table 3-3: HDM-4 Calibration Levels

Level Scope of Calibration Applicability

1: Basic

Application

(Low Level)

Adopts many default values, calibrated

most sensitive parameters with best

estimates, desk studies or minimal field

surveys

General planning, quick

prioritization,

preliminary screening

2: Calibration

(Medium

Level)

Measurement of additional input

parameters, moderate field surveys to

calibrate key predictive relationships to

local conditions, slight modification of the

model source code

Project appraisal,

detailed feasibility

3: Adaptation Requires major field surveys and Research and



59

Level Scope of Calibration Applicability

(High Level) controlled experiments, develop new and

locally specific relationships

development

Figure 3-14 shows the efforts (resources and time) required for different levels of

calibration. For HDM models, there are three types of calibration carried out as given

below:

RDWE Unit Costs: This includes unit costs of maintenance treatments or road

works. Ex: cost of DBST, cost of AC surfacing, etc;

RUC Unit Costs: All input parameters related to Road User Costs (RUC) and Vehicle

Operating Costs (VOC). Ex: vehicle replacement cost, cost of tyres, cost of fuel,

cost of time delays, etc;

RDWE Models: Calibration or adjustments of Road Deterioration and Works effects

(RDWE) models. Ex: cracking initiation coefficient, roughness progression

coefficient, roughness reset after an overlay, etc.

Figure 3-14: HDM-4 Calibration Efforts

The TOR recommends Level 2 calibration of road works costs (that is RDWE Unit Costs

as described above). The scope of the Level 1 and Level 2 calibration is given in Table

3-4 (Level 3 is related to fundamental research and development of models which is

out of the scope a project of this nature).

Table 3-4: HDM-4 Calibration Details

Level RDWE Unit Costs RUE Unit Costs RDWE Models

1 Unit costs from previous Vehicle replacement costs Desk study of previous



60

Level RDWE Unit Costs RUE Unit Costs RDWE Models

reports/studies/agency’s

schedule of rates

and some limited fuel and

vehicle details.

reports and studies and

general engineering

experience.

2 Unit costs from previous

reports/studies/agency’s

schedule of rates. Estimation of

Rates from basic material and

labour rates where reliable Unit

Costs information is not

available.

Vehicle replacement

costs, speed, fuel

consumption, tyre

consumption, parts

consumption and fixed

costs related vehicle life

and utilization.

Model calibration from

data collection

We propose to perform Level 2 calibration for RDWE Unit Costs and RUE Unit Costs and

Level 1 for RDWE Models. The calibration of the HDM4 is very much dependent on the

quality and extent of the data available. Therefore, the possibility, scope and extent of

calibration will depend on the data available.

The enhanced models will continuously be tested throughout the period of the Services.

3.6.3.8 Routine Maintenance Management System (RMMS)

Routine Maintenance Management System (RMMS) will be developed to undertake

routine maintenance activity for road assets. Routine maintenance will be an important

sub-system in overall framework of RMS. Proper utilisation of this system will be a

preventive maintenance and will lead to preserve large and low value assets.

The system will be used for assigning pre-defined routine maintenance treatments on

candidate sections not having periodic maintenance / improvement works. RMMS

ensures improving the quality of the performance of the routine maintenance through

standardisation of activities including Specifications, Performance Standards, Quantity

Standards, & supervision.

The annual needs for routine maintenance activities for the candidate analysis sections

are assessed through maintenance feature inventory and condition rating, quantity

standards and unit rate. Quantity standards are expressed as the annual number of

units of work as per the applicable unit for each activity based on the condition of the

Asset (refer to Figure 3-15).



61

Figure 3-15: Routine Maintenance Needs

Annual needs (total work quantity) are assessed by multiplying the road network

maintenance feature inventory data by the quantity standards of the work activities.

The process flow is given in Figure 3-16.



62

Routine Maintenance Management System

Centralised

Relational

Database

GIS Thematic

Maps

Tabular / Chart

Reports

System Setup(One time, and it can be adjusted

by users, based on requirement)

Decision Tree

Criteria

Unit Cost

Annual Work

Programme and

Estimates

Analysis Engine

Extract RM

Section

Work

Quantity for

Point Assets

Total Work

Quantity

Prepare

preliminary

programme

Assign

Priority Index

Total RM

Cost

Run Decision

Tree

Assign

Adjusted Cost

Prepare Final Programme

Figure 3-16: Routine Maintenance Management System Process Flow

3.6.3.9 ROW Features Information Management System (RWFIMS)

ROWFIMS will be created to:

maintain all features such as structures, utility services both below and above

ground, trees etc, within the Right of Way (ROW)

generate strip maps showing these features.

HPPWD have simple road infrastructure maps of roads at divisional level. These maps

and databases will be integrated with RMS. Essentially RWFIMS will be a GIS based

frontend with several layers prepared from the data to be provided by HPPWD. All

required data for developing and implementing RWFIMS will be supplied by

HPPWD/HPRIDC.



63

3.6.4 Institutional Setup

Institutionalization means ‘to make part of a structured and well-established system’.

Aspects considered to be important in institutionalization of an RMS are those that are

similar for any management system. They should include:

Establishment of an organizational unit with specific responsibility for the system;

Establishment of a budget for the operation of the entire system, including all

staffing, equipment, data collection (contract or in-house), field travel, etc.;

Presence of appropriately qualified personnel, with good management skills, with

access to and control over their budget;

Specific and detailed job responsibilities for all aspects of the system;

A program for continual quality improvement;

Clear management reporting; and

A regular audit of all elements and the taking of corrective actions where

necessary.

In order to fulfil the above mentioned institutionalization requirements, we propose for

establishing of an organizational unit (RMS cell).

At present HPPWD is not having good institutional set-up to sustain the present RMMS

system. It is manned at HPPWD HQ by 1-2 junior level staff.

3.6.4.1 RMS Cell

It is proposed to have a separate RMS Cell within HPPWD/HPRIDC to maintain, monitor,

sustain and institutionalise the proposed RMS system. The proposed RMS cell

tentatively consists of team grouped under various heads like Data collection &

Loading, Data Processing Management & Reporting, Maintenance Planning, GIS, IT,

Social & Environmental and Traffic & Transport Economist.

Figure 3-17: RMS Sustainability

Data collection & Loading: The responsibility of this team is to regularly collect data

and load into the system.

Data Processing Management & Reporting: The responsibility of this team is to

verify process and approve the data collected, so that the data can be loaded into the

system. Also responsible to maintain the system up to date and generate various

reports from the system whenever requested.



64

Maintenance Planning: The responsibility of this team is to run the PMS and RMMS

processes and generate yearly annual maintenance plans and multi-year rolling plans.

GIS: The responsibility of this team is to verify the survey road alignments and making

shape file of the new road network and updating whenever changes in the road

classification and alignment occurs.

IT: The responsibility of this team is to address any technical issues with RMS system,

perform system admin activities of RMS system.

Social & Environmental: The responsibility of this team is to regularly update the

social, environmental and socio-economic parameters within the RMS system.

Traffic & Transport Economist: The responsibility of this team is to support the

maintenance planning team in running the HDM-4 analysis and generate annual

maintenance needs.

3.6.4.2 Sustainability Framework

The implementation of a sustainable road management system should consider:

The agency to collect the required data and keep them current;

Technical knowledge required to operate and subsequently improve the system, if

and when the need arises;

Knowledge and computer skills available within the agency;

Staff training programmes in the area of pavement management.

Figure 3-18: RMS Sustainability



65

3.7 Data Collection for RMS (SH & MDR)

3.7.1 Introduction

Data collection is expensive. Each data item collected requires time, effort, and money

to collect, store, retrieve, and use. The first rule of data collection is that data should

never be collected because "it would be nice to have the data," or because "it might be

useful someday."

This section addresses a number of issues that road managers face when determining

exactly what their data requirements are and how to select the appropriate data

collection technologies to meet those requirements.

3.7.2 Deciding What Data to Collect

Regarding road management data, the first question usually asked is, "What data

should we collect?" Many agencies start by asking an internal team to compile a "data

wish list." Other agencies first take inventory of their currently available data and try to

implement road management systems using that data. Both approaches should be

avoided. The real questions that should be asked are:

What decisions do we need to make to manage the network?

What data are needed to support these decisions?

Can we afford to collect these data initially?

Can we afford to keep the data current over a long time period?

Several agencies have become so mired in data collection that data collection appears

to be an end in itself. Large sums of money are spent collecting data, with little to show

in the form of more efficient and cost-effective decisions.

Excessive data collection is probably one of the top five reasons road management

systems (RMS) are abandoned. The systems are seen as data intensive and too

expensive to sustain. To avoid these misperceptions, Paterson and Scullion (1990)

have provided approaches for deciding what data should be collected and how it should

be collected:

Confirm whether the data are actually required: An RMS is often used to

assist in making management decisions. If the data does not have a bearing on

either the RMS output or management decisions, it should not be collected. A

common problem arises when agencies try to collect project-level data for network-

level analysis. This means that data are collected in a much more detailed manner

than is required for analysis, thereby wasting time and money;

Consider the total cost: With any RMS, the commitment is not for a one-time

needs survey. Some inventory data need only to be collected once and require

updating when there are changes in the network, such as new roads or

realignments. However, some data changes rapidly, especially data on auxiliary

information such as signs and markings. Implementation of a road management

process is a commitment to a permanent change in the way roads are managed.

This means that the data collected must be kept current. This can be both difficult

and expensive, if excessive data are collected;



66

Minimize data collection: Generally, the greatest temptation is to collect too

much data, or in too much detail. When this proves to be unsustainable, data

collection will cease, compromising the value of the RMS. If the data are not kept

current, management decisions may be misguided and the RMS could become

irrelevant to planning.

3.7.3 Guiding Principles

The guiding principles should always be:

Collect only the data that is needed;

Collect data to the lowest level of detail sufficient to make appropriate decisions;

and

Collect data only when they are required.

When considering data collection methodologies, pilot studies are very useful. In the

pilot implementation, all proposed data should be collected to determine the collection

costs, as well as the appropriateness of the data collected.

Implementation can, and should be incremental. Implementation should include

considerations on what data to collect at each level and ensure that the data are kept

current. A RMS should never be finished; as it matures and data collection processes

change, other data elements can, and should be added.

3.7.4 Levels of Data Collection

Data collection may be considered as belonging to one of the following three levels:

Network-level data should answer the general planning, programming, and policy

decisions supported by the network-level RMS;

Project-level data should support decisions about the best treatment to apply to

a selected section of road. As these data are collected, they can be stored to create

a more complete database over time. However, a method must be established to

keep the data current; and

Research-level data should be established to collect detailed data on specific

attributes to answer selected questions.

These differences are addressed in the following section on information quality levels.

3.7.5 Information Quality levels

As described in Bennett and Paterson (2000), imagine looking out of an airplane

window, just as you are about to land. You recognize the landscape by a bend in the

river, or the way a thread-like highway cuts through the landscape. The plane draws

nearer, and you can make out your neighbourhood, then your home, your car. You

have been looking at the same spot throughout the descent, but the “information”

available to you became enhanced. While from high above you had enough macro-level

information to determine what town you were looking at, you needed a different kind of

micro-level information to determine precisely where your car was. You have just

experienced first-hand the principle behind Information Quality Levels (IQL), introduced

by Paterson and others in 1990.



67

IQL helps us structure road management information into different levels that correlate

to the degree of sophistication required for decision making and methods for collecting

and processing data. In IQL theory, very detailed data (‘low-level data’) can be

condensed or aggregated into progressively simpler forms (higher-level data), as

shown in Figure 3-19.

Figure 3-19: IQL Levels

In road management, five levels of data have been identified as given in Table 3-5.

Table 3-5: IQL Level Description

IQL Level Precision / Detail

1 Most comprehensive level of detail, such as would be used as a reference

benchmark for other measurement methods and in fundamental research.

Would also be used in detailed field investigations for an in-depth diagnosis

of problems, and for high-class project design. Normally used at project-

level in special cases, and unlikely to be used for network monitoring.

Requires high level of staff skills and institutional resources to support and

utilise collection methods.

2 A level of detail sufficient for comprehensive programming models and for

standard design methods. For planning, it would be used only on sample

coverage. Sufficient to distinguish the performance and economic returns of

different technical options with practical differences in dimensions or

materials. Standard acquisition methods for project-level data collection.

Would usually require automated acquisition methods for network surveys

and use for network-level programming. Requires reliable institutional

support and resources.

3 Sufficient detail for planning models and standard programming models for

full network coverage. For project design, would suit elementary methods



68

IQL Level Precision / Detail

such as catalogue-type with meagre data needs, and low-volume

road/bridge design methods. Can be collected in network surveys by semi-

automated methods or combined automated and manual methods.

4 The basic summary statistics of inventory, performance and utilisation, (?)

of interest to providers and users. Suitable for the simplest planning and

programming models, but for projects, it is suitable only for standardised

designs of very low-volume roads. The simplest, most basic collection

methods, either entirely manual or entirely semi-automated, provide direct

but approximate measures, and suit small or resource-poor agencies.

Alternatively, the statistics may be computed from more detailed data.

5

Represents a top level such as key performance indicators, which typically

might combine key attributes from several pieces of information. Still

higher levels can be defined when necessary.

Therefore, the data requirements should be in line with the network level information

to complement the general planning, programming, and policy decisions supported by

the network-level RMS.

3.8 Data Collection Items

3.8.1 Data Collection Categories

Paterson and Scullion (1990) have identified the data requirements and categories.

According to this report, the categories that are relevant to the road management are

listed in Table 3-6.

Table 3-6: Data Collection Categories

Category Application / Purpose Details

Road Inventory Network planning Network/Location

Geometry

Furniture/Appurtenances

Environs

Pavement Pavement management and

maintenance

Condition (Functional)

Structure (Structural)

Structures Bridge (and culverts)

management and maintenance

Inventory

Condition

Traffic Maintenance management

Transport planning

Volume

Loading

Accidents

Finance Strategic planning

Unit costs

Budget



69

Revenue

Activity Project management Projects

Interventions

Commitments

Resources Resource management

Other applications / purpose

Institutional

Materials

Equipment

In line with the Contract, this report deals with the first five categories, which are:

Road Inventory;

Pavement;

Structures;

Traffic;

Finance.

As mentioned in our proposal, we have selected the following specialists to provide

input, advise, suggestions, review and approval on the items as stipulated in the TOR:

Dr. Veeraraghavan from IIIT, Chennai;

Dr. A.K.Agarwal from CRRI, Delhi;

Dr. P. K.Sarkar from School of Planning and Architecture (SPA), Delhi.

However, in case of non-availability of above mentioned members due to

unforeseen circumstances, at the time of project delivery consultant will make

alternate arrangement in consultation with HPRIDC/HPPWD Client.

3.8.2 Location Reference

3.8.2.1 Network Details

In the linear referencing system, Roads are divided into multiple Links. Each Link has

Nodes and Location Reference Points (LRPs). The Nodes and Location Reference Points

(LRPs) must be defined in terms of both the chainage and GPS coordinates.

All linear chainages must be measured using a Distance Measurement Instrument

(DMI) with an accuracy of 0.1 m per 100 m (0.1%) or better. Chainages are measured

continuously from the start to the end of the link. At each node and LRP, the offset

must be reset to zero. The DMI transducer is recommended to be installed in the

survey vehicle such that it will be close to the road centreline and thereby minimise

loss of accuracy due to turning movements.



70

3.8.2.2 Road Alignment Details

The road centreline is a notional reference line that generalises and approximates the

true centreline to an accepted and known accuracy. The geo-coordinates of the nodes,

LRPs and centreline must be recorded and reported and corrected for differential

positioning. The data are to be provided in a mapping coordinate system that is agreed

before the survey commences.

The geo coordinates must be measured using either real time differentially corrected

Global Positioning System (DGPS) equipment or post processed for differential

correction. The differentially corrected coordinates must be at least 95% of confidence

level/reliability and ± 1.0 meter horizontal accuracy and 95% of confidence level/

reliability and± 2.0 meter vertical accuracy or better GPS data. This means that for 5%

of time the information given will be less accurate than 1.0 meter.

The GPS referencing must be made as close to the road centreline as possible and

practical. The reference for altitude has to be made at the pavement surface. The geo-

coordinates must be reported continuously at no more than every 10.0 meter. In the

case of a divided carriageway, the location data shall be that describing the centreline

of the carriageway. All centrelines must have the correct and complete topology (e.g.

intersecting roads must intersect) and a unique centreline must be provided for each

link.

3.8.2.3 Administrative Details

The administrative boundaries of the road sections, such as District, Division, Sub-

division and Block etc. must be collected as much as possible in the field. All missing

information must be collected from the Zonal and Divisional offices.

3.8.3 Road Inventory

3.8.3.1 Suggested IQL

It is preferable to collect the Road inventory data in accordance with IQL -2. These data

items should be reported when there is a change in the particular attribute.

3.8.3.2 Number of Lanes

Every road section must be categorised into one of the types detailed below or as

agreed by the Client before the survey starts:

Single lane - 1;

Intermediate lane – 1.5;

Two lane - 2;

Four lane - 4;

Four lane carriageway;

3.8.3.3 Road Type

Every road section must be categorised into one of the types detailed below or as

agreed by the Client before the survey starts:

All Weather Roads – Yes/No;



71

Motorable Route – Yes/No;

3.8.3.4 Pavement Surface Type

The pavement surface type should be categorised as agreed before the survey

commences. As a minimum, the following must be recorded:

BT Type;

CC Type;

WBM Type;

Gravel Type;

Katcha / Earthen Type.

3.8.3.5 Pavement Surface Material

The pavement surface material should be categorised as agreed before the survey


O G Premixed Carpet BT Penetration Grade - PC (P);

O G Premixed Carpet BT Emulsion RS -1 - PC (E);

Mixed Seal Surfacing – MSS;

Semi Dense Bituminous Concrete – SDBC;

Bituminous Concrete - BC;

Bituminous Macadam – BM;

Dense Bituminous Macadam – DBM;

Seal Coat Type – B – SC-B;

Slurry Seal – SS;

Plain Cement Concrete - PCC

Water Bound Macadam - WBM;

G-1, G-2, G-3 layers;

Gravel – Gravel GR-I;

Katcha / Earthen Type.

3.8.3.6 Carriageway and Formation Width

As a minimum, it is required to identify carriageway widths in the following bands:

< 3.05 m;

3.05 m – 5.50 m;

5.50 m - 7.0 m;

7.0 m - 9.0 m;



72

3.8.3.7 Shoulder Material

The shoulder material should be recorded using the codes to be agreed before the

survey commences. As a minimum, the following should be recorded:

Granular Soil - GS;

Natural Earth - NE;

Paved Shoulder - PS;

Hard Shoulder - HS;

None - NA.

3.8.3.8 Shoulder Width

Shoulder width should be recorded for both the left and right side paved and unpaved

shoulders using the following bands:

No shoulder;

< 1.0 m;

1.0 m - 2.0 m;

> 2.0 m.

3.8.3.9 Side Drain Type

The type of the side drain should be recorded for both the left and right side using the

codes to be agreed before the survey commences. As a minimum, the following types

of drain should be recorded:

Open unlined;

Open lined;

Covered lined;

No drain.

3.8.3.10 Cross Section

The cross-section of the roadway should indicate whether it is a cut or fill, on

embankment. As a minimum, the following should be recorded:

Cut;

Fill;

both;

Level.

3.8.3.11 Terrain Type

The terrain categories should be agreed before the survey commences. As a minimum,

the terrain must be recorded as:

Plain;

Rolling;



73

Hilly;

Mountainous.

3.8.3.12 Road Furniture (Optional)

The location and type of the road furniture for urban/rural roads should be recorded.

The type of road furniture to be collected should be agreed before the survey


Number of Signs and Legend (Informatory, Regulatory, Warning, etc.);

Number of Distance Markers (Hetometere stones, Kilometre stones);

Number of Guard Stones (Edge stones, Guide Posts) and its location (Left, Right,

Both) ;

Number of Parapets and Type (Stone Masonry in CM, Dry Stone Masonry, PCC,

etc);

Intersections / Junctions locations, Side and Road No. intersecting with;

W-Metal Beam Crash Barrier;

Others (Trees).

3.8.3.13 Wayside Amenities (Optional)

The type of wayside amenities to be recorded should be agreed before the survey


Rest House;

Circuit House;

Rain Shelter;

Bus stand;

Parking lot/Truck layby;

Railway station;

Restaurant/Motel;

Water Spring;

Landslide Prone Area;

Accident Prone Area;

Foggy Area;

Mining Area;

Snow Bound Area;

Desert;

Telephone Booth;

Toll Plaza;

Petrol pump/minor repair shop.



74

3.8.3.14 Geometry

The following data should be measured using automated continuous devices.

Data Parameter Unit Accuracy

Horizontal alignment Super elevation degrees 5%

Radius of curvature m/l/m 5%

Vertical alignment Grade % 5%

Transverse gradient Cross fall % 5%

Speed Design kmph

Operational kmph

3.8.3.15 Land Use Type (Optional)

The land use type for each road link shall be recorded as agreed with Client before the

survey starts. As a minimum, the following must be recorded:

Residential;

Commercial;

Industrial;

Agricultural;

Water bodies;

Public/community use;

Forest reserve;

Mixed.

3.8.3.16 Utilities (Optional)

It is suggested to collect information on the above and on ground Utilities. The type of

utilities to be recorded should be agreed before survey commences. As a minimum, the

following must be recorded:

Hand Pumps;

Water Tanks;

Electricity Poles;

Telephone Polls.

Any visibility of underground utilities, such as Optical fibre cables, Gas line, Water line,

Oil line and Sewer line should be recorded.

3.8.3.17 Annual Rainfall

Annual rainfall information should be collected from secondary sources, such as

respective Zonal / Divisional Offices and recorded as follows:



75

Light < 700 mm;

Medium 701 – 1500 mm;

Heavy >1501 mm.

3.8.3.18 Facilities

Facilities information should be collected from secondary sources, such as respective

Zonal / Divisional Offices and recorded as follows:

Educational Facilities;

Medical Facility;

Market Place;

Industry;

Tourist Place;

Religious Place.

Administrative head quarter (Sub-division, Division, Block, District);

3.8.3.19 Right of Way (ROW)

The legal (or visible) Right-of-Way (ROW) must be recorded. In case the ROW

boundary stones are either missing or not seen from the carriageway, then information

should be collected from secondary sources, such as respective Zonal / Divisional

Offices.

3.8.4 Pavement – Functional

A functional evaluation includes collection of information about surface characteristics

that directly affect users’ safety and comfort, and its own serviceability. In a functional

evaluation, the main parameters included are skid resistance and surface texture in

terms of safety, as well as roughness in terms of serviceability.

3.8.4.1 Roughness

The longitudinal profile must be measured using a World Bank Class 3 roughness

device Bump Integrator and Roughness must be determined from this profile and

reported in International Roughness Index (IRI) in m/km. The system must have the

ability to measure roughness under ‘Stop and Go’ conditions. The term ‘Stop and Go’ is

used to specify that roughness data shall be collected at standard traffic and field

conditions i.e. even if vehicle is stopped or slowed down due to traffic or any field

conditions.

3.8.5 Pavement – Structural

A structural evaluation includes collection of information on whether the pavement

structure is performing satisfactorily under traffic loading and environmental conditions.

The main parameters include structural performance, pavement distresses, and

mechanical/structural properties. Note that several pavement distresses indirectly lead

to functional problems such as asphalt pavement bleeding, which affects skid

resistance, or faulting in jointed concrete pavements, which affects roughness.



76

3.8.5.1 Rut Depth (Optional)

The transverse profile must be measured using non-contact sensors. The rut depth

must be expressed as the maximum vertical depth in mm for each wheel path under an

equivalent 2.0 meter straight edge.

3.8.5.2 Pavement Deflection

The deflection measurements must be taken by the In-vehicle mounted Falling Weight

Deflectometer following the IRC 115-2014, Guidelines for Structural Evaluation and

Strengthening of Flexible Road Pavements using FWD.

The geophones (sensors) spacing preferably be kept at 0, 200, 300, 450, 600, 900 and

1500 mm measured from the centre of the applied load. The load pulse must be

applied through a loading plate of diameter of 300 mm. The loading plate must have a

rubber pad of at least 5 mm thickness.

3.8.5.3 Pavement Composition

The pavement composition must be compiled either by digging the test pits and

analysing the material or from the available ‘As-built’ drawings and recent maintenance

records. Possible sources include available project completion reports, drawings,

maintenance records and consultation with field staff etc. This method is quick and

affordable compared to direct measurement under the favourable scenario, such as

availability of proper maintenance records.

3.8.5.4 Pavement History

Pavement maintenance history data must be acquired from office records available with

Zonal or Divisional offices. As a minimum, the following must be recorded:

Year of last surfacing;

Thickness of last surfacing;

Type of last surfacing;

Year of pavement construction/reconstruction.

3.8.6 Pavement Surface Condition

Pavement surface condition is although part of structural aspect but given the method

and frequency of the data, it is separately considered.

3.8.6.1 Surface Distresses

The following pavement surface distresses at a maximum interval of 500 m must be

recorded:

BT Pavements

Potholes in % of the surface area;

Ravelling in % of surface area;

Edge break in % of the length;

Rut in % of the surface area;



77

Depressions in % of the surface area;

Cracking in % of the surface area;

Pavement Failure in % of the surface area;

Surface Texture < 2 m2 in % of the surface area;

CC pavements

Joint Sealant in % of the surface area;

Cracked Concrete > 100 mm in % of the surface area.

Unpaved Pavements

Surface Failure in % of the surface area;

Potholes in % of the surface area;

Edge breaks in % of the surface area;

Edge drop in % of the surface area;

Camber Flat / Depressed in % of the surface area;

Gravel Thickness in mm;

3.8.7 Other Condition

3.8.7.1 Shoulder Condition

The shoulder condition must be recorded as per requisite IQL for both the left and right

side shoulders. The aim is to identify any unwanted defects, which may affect

pavement performance. As a minimum, the following must be recorded:

Good;

Fair;

Bad;

Failed or non-functional;

Shoulder elevation with respect to pavement edge (level, above, below).

3.8.7.2 Side Drain Condition

The drainage condition must be recorded as per the requisite IQL for both the left and

right hand side drains. The aim is to identify any drainage problems, which may affect

pavement performance. As a minimum, the data must be recorded as per the following

quality indicators:

Good;

Fair;

Bad;

Failed or non-functional.



78

3.8.7.3 Road Furniture Condition

The road furniture items must be recorded. The aim is to identify proper functioning of

the furniture, which is directly to road safety. As a minimum, the data must be

recorded as per the following quality indicators:

Good;

Fair;

Bad;

Failed or non-functional.

The condition data must be collected for the following assets:

Parapets;

Retaining walls;

Breast walls;

Kilometre stones;

Guard stones;

Road Signs;

Vegetation / debris;

Other damage (landslide / snow fall).

3.8.8 Traffic

3.8.8.1 Volume

Classified traffic volume count must be carried out for 3 (three) days (continuous,

direction-wise) at the selected survey stations during normal period. The following

vehicle classification system shall be considered:

Buses

Trucks – Single Axle

Trucks – Two Axle

Trucks – Multi Axle

Tractors

Cars/Jeeps

Auto Rickshaws

Two Wheelers

3.8.8.1.1 Seasonal Correction Factor

Seasonal Correction Factor (SCF) is a parameter which is used to address the variations

in the traffic volumes as per the season. This factor is applied on ADT for arriving at the

Annual Average Daily Traffic (AADT). HPRIDC/HPPWD has to provide this SCF

region/zone/location-wise.



79

The formula used to estimate the AADT is as

AADT = SCF * ADTi

Where ADTi - is the average ADT of 7 days of month i

3.8.8.2 Axle Load

Axle load surveys shall be performed using Axle Weigh Pads. As per the IRC: 37-2012

the minimum sample size for survey shall be followed as shown in the Figure below. A

minimum sample size as per the number of commercial vehicles must be weighed

selected on random/systematic sampling method. Axle load survey must be carried out

along with the traffic volume survey at the same location.

Figure 3-20: Sample Size for Axle Load Survey

The axle load survey must be carried out in both directions for a divided carriage ways

and one direction for un-divided carriageways at each site for duration of 48 hours.

3.8.8.3 Road User Cost (RUC)

Road user costs are conducted to identify the costs incurred by the vehicle operators

and by the traveling public. There are basically three main components of RUC, namely

Vehicle Operating Cost (VOC), Time cost and Accident cost.

The data to be collected for the below mentioned components

VOC

o Fuel;

o Tyres;

o Engine Oil;

o Maintenance;

o Depreciation.

Time Costs

o Working Time;



80

o Commuting Time;

o Leisure Time;

o Commercial Time.

Accident Costs

o Fatality;

o Non-Fatality Injury;

o Property Damage.

3.8.9 Structures

3.8.9.1 Structure Inventory

The inventory of the main structural features of each bridge must be collected

according to the details stipulated for IQL III. At the minimum, the following features

must be included:

Structure location;

Structure number;

Structure type (Bridge/Major Culvert/Solid Cause Way/ Vented Cause

way/Skewed/Curved, etc.);

Structure Name;

Construction Year;

General Configuration

o Construction Type (PSC/RCC/PCC/Steel/Suspension/Arch/Others);

o Structure Length;

o Span Type (Single/Multi/Vented/Flush etc.);

o No. of Spans/Vents;

o Clear Carriageway;

o Footpath (Yes/No);

o Name of Stream / River;

Foundation

o Type (Open / Deep);

o Size;

Sub Structure

o Abutment Type (PCC, RCC, Stone Masonry, Dry Stone Masonry, Wire

Crates etc);

o Abutment Size;

o Pier Type (PCC, RCC, Stone Masonry, Dry Stone Masonry, Wire Crates etc);

o No. of Piers;



81

o Pier Size;

o Wing wall Type (PCC, RCC, Stone Masonry, Dry Stone Masonry, Wire

Crates, etc);

Super Structure

o Type (Slab, T-Beam, Box, Girder etc);

o Hand Rail Type (RCC, Pipe Railing etc.);

o Bearings Type (Rocker, Roller etc.);

o Wearing Coat Type (RCC, Mastic Asphalt etc.);

Other Facilities

o No. of Parapets;

o No. of Guide Posts;

o No. of Sign;

o Batter Protection Type (PCC, RCC, Stone Masonry, Dry Stone Masonry,

Wire Crates etc);

o Highest Flood Level (HFL);

o Mining activities (within 500 meter upstream & downstream of bridge site);

o Vertical Clearance

o Deck Level;

o Design Load for Bridge displayed or not;

o Meandering behaviour;

o Details of Utilities

3.8.9.2 Structure Condition

The structure condition survey must include routine inspection to evaluate the condition

of the existing structure following the IQL-III level. The main objective of structure

inspections is to identify and quantify defects and deterioration, which may be caused

by exceptional over-loading, material degradation or intrinsic weaknesses. The

structure condition survey shall comprise a visual rating of the condition of each

structure element (abutments, piers, superstructure etc.). At the minimum, the

following condition affected parameters are collected:

Drainage Condition of road near Bridge

Bitumen Wearing Coarse bridge surface and footpaths

Concrete wearing course

o Cracking

o Spalling

o Reinforcement exposed

o Poor concrete

o Kerbs



82

o Foothpaths

o Parapet, Railing and Crash barrier

o Steel or aluminium parapets

o Masonry parapets

o Expansion joint at Abutment & Piers

o Blockages in Waterway

o Superstructure

o Damages to girders, trusses or bracings

Concrete Beams

o Cracking

o Spalling

o Reinforcement exposed

o Poor concrete

Steel Girders and Bracings

o Corrosion

o Cracking

o Loose bolts / rivets

o Deterioration of paint

Steel Trusses

o Deterioration of paint

o Corrosion

o Bends in members, joints

o Loose bolts/rivets

Deck Condition

All Bearing Condition

Masonry Arches

Abutment, Wingwall, and Retaining Walls

o Cracking

o Spalling

o Settlement / bulging crates

o Bulging

Embankments and Fill in front of abutments

o Stone Pitching Slope Protection

o Slope protection with crates



83

o Pitching protection with concrete blocks

o Bed protection

o Concrete bed protection and Aprons

Piers

o Cracking

o Poor painting

o Spalling

o Corrosion

Non-Structure Damages / Defects

o Area of Debris & Vegetation;

o Length of Railing;

o No. of Drainage Spouts;

o Area of Approach Slab;

o No. of Signs;

o Area of repainting;

o Volume of Protection Walls;

o Volume of stream maintenance;

o Structure Damages / Defects

o Length of Deck Jointing;

o Area of Bridge Deck;

o Volume of Super Structure;

o Volume of Sub-Structure;

o Overall structure Condition (Good, Fair, Poor);

Maintenance Details

o Year of strengthening of bridge components done with details;

o Strengthening / new construction of bridge required or not;

o Test for load carrying capacity of bridge required or not

This survey must also indicate anything that may affect the integrity of the structure

such as channel erosion/blockage, defective bearings/expansion joints.

Digital images must be taken of any observed defects.

3.8.9.3 Culvert Inventory

The inventory of the main structural features of each culvert must be collected

according to the details stipulated for IQL III. At the minimum, the following features

must be included:

Culvert location;



84

Culvert number;

Culvert type (RCC Hume Pipe, RCC Slab, RCC Box, Solid Cause Way, Vented Cause

Way, Scupper, Syphon etc);

Size of vents;

Number of vents;

Culver Length;

Headwall/Abutment Type (Stone Masonry in CM, PCC, RCC etc.);

Headwall/Abutment Size;

Toe Wall Type (Stone Masonry in CM, Dry Stone Masonry, PCC, Wire Crates etc.);

Toe Wall Size;

Catch Pit Type (Stone Masonry in CM, Dry Stone Masonry, PCC, Wire Crates etc.);

Catch Pit Size;

Hand Rail Type (Pipe Railing, RCC railing etc.);

No. of Parapets;

No. of Guide posts;

Wing wall type (Stone Masonry in CM, Dry Stone Masonry, PCC, Wire Crates etc.);

Wing wall size;

3.8.9.4 Culvert Condition

The culvert condition survey must comprise rating of functional and structural condition

through visual rating of the condition of each culvert element (pipe/box, inlet and

outlet structures). At the minimum, the structural rating codes will be of the form:

Debris, Vegetation

Settlement of parts of culvert

Scour at the end of culvert or edge of Apron

Barrels

Aprons

Headwalls

Defects/Damage

o Vent cubic meter/meter;

o Volume of Silt;

o Volume of Head wall / Abutment;

o Volume of Catch Pit;

o Volume of Aprons;

o Volume of Scouring;

o Overall Condition (Good, Fair, Poor).



85

This survey must also record the functional condition in terms of degree of

silting/blockage, erosion downstream of the culvert and evidence of overtopping.

Digital images must be taken of any observed defects.

3.8.10 Others

3.8.10.1 ROW Video (Optional)

The visible right-of-way (ROW) must be directly digitised and stored at 1920 x 1080

pixel or better. The data may be collected as either continuous or on a time or frame

based system. Location identification information must be superimposed on each frame

and a playback system that facilitates easy review and location of specific road sections

must be included.

3.8.10.2 Ongoing/Committed Projects

Ongoing or committed projects must be recorded from available sources, such as

Zonal, Divisional, and Head Offices, etc.

3.9 Method of Data Collection

3.9.1 Background

The cost of data collection tends to be the largest component of managing and running

a management system, such as RMS. Further, the direct benefit of frequent (or

regular) collection of information is always questioned and is continually subject to

budgetary scrutiny. It is, therefore, important to select data acquisition technology that

is appropriate to the objectives, resources and modus operandi of the agency.

The criteria that can guide the selection of the data collection method are:

Reliability: A trade-off between the accuracy of the method and its productivity

(relative to the IQL and accuracy required for the data);

Accessibility (Resources): Deals with the efforts required to transfer the data from

the collection medium to the database, the capability for reviewing and verifying

the data before storage, and the speed and accuracy with which transference to

storage can be made;

Affordability: Includes technical support, staff and financial resources required to

sustain the data acquisition process continually through the annual operations of

the agency.

Manual or Semi-automated methods, which are relatively slow, human resource-

intensive and require manual data transfer for database, are appropriate when the

network is small, the traffic volumes are low and the survey crew costs of conducting

the survey are inexpensive. Automated methods, particularly composite

instrumentation that measures several items simultaneously, are often fast and provide

direct data transfer, but they are usually expensive and are thus suited to large or

heavily trafficked networks, and to agencies that have maintenance support for

sophisticated electronic equipment.



86

3.9.2 Basis of Selection

The factors that could influence the selection of method include:

IQL and accuracy of the data;

Frequency and sampling density of the surveys (use of data in network-level or

project-level applications);

Size of the network to be surveyed;

Management of data acquisition, whether centralised, decentralised or contracted,

(and the feasibility for sharing the service with another agency); and

Technical skills, maintenance support, staff resources and financial resources of the

agency.

3.9.3 Available Methods

Most commonly available methods are described below:

3.9.3.1 Walkthrough (Manual)

As the name suggests, this method includes recording of the (inventory or condition)

data by a team of “pedestrian observers” usually on a sampling basis. Most items are

recorded by code indicating the presence, location and attributes of the item. The

precision of location and length attributes depend on the information quality level being

sought. A visual observation method of manual measurement method assisted by tools

(such as measuring wheel or tape measure) is adopted considering the accuracy

desired.

Various formats will be used on the paper form used by an observer to record the field

data, each format tailored to the individual agency's approach. Transcription of the field

data to computer records should be made as soon as possible after data collection, and

preferably should proceed in parallel to the field surveys. In most occasions, data is

recorded over a representative section (inspection length) of length varying between

10% and 20% of the link/section length to be surveyed. This method is suitable for

small networks. This method can be used for both inventory and condition.

Lately, handheld computers or data loggers are being used to minimise data

transfer efforts in the office.

A live example is the annual condition survey currently being practised in New Zealand.

First 20 m of the Link (Treatment Length) is excluded from the inspection. Next 50 m,

which is considered as the representative section for the successive 500 m, is inspected

by walkthrough method aided by a measuring wheel and tape measure as depicted in

Figure 3-21.



87

Figure 3-21: Walkthrough Method (10% Sampling)

3.9.3.2 Windshield

This method includes recording the data from a moving vehicle on a paper or directly

into the electronic media (Computer). A popular modification of the manual recording

method is direct entry of the data into electronic format in the field, eliminating the

need for later transcription, while also improving the practical logistics of handling

papers, codes, etc.

Commercially-available hand-held Computers or Laptops which are programmed by

application specific software have the advantage over manual recording on paper

media. Commercial microcomputer keyboards, carrying a template to indicate special

functions assigned to the keys, allow for a wider range of types of entry and comments

than hand-held computers, but can only be used with an on-board computer or laptop

computer.

Several data items such as road and pavement inventory and condition parameters can

be collected simultaneously. The use of a voice-recognition device for data entry is

particularly useful for multifunction surveys where the observer is performing several

functions simultaneously, because it leaves the hands free. The device recognises

specific terms (calibrated to the individual observer's voice), and records those digitally

in whatever codes are assigned to the item and its attributes. Used in conjunction with

photo logging, the method provides an immediate electronic file of data, which can be

automatically processed with conventional methods. Currently, this method is highly

popular for network level surveys and is practised by several agencies in both the

developing and developed countries.

A typical arrangement of the windshield survey is depicted in Figure 3-22.



88

Figure 3-22: Windshield Survey

3.9.3.3 Video Logging

This is very similar to Windshield method that involves recording of data from a moving

vehicle. The survey vehicle is fitted with single or multiple cameras to record desired

data. Video logging has been in use for some years, using video footages of the road

and road reserve to create a permanent record of inventory and condition features.

Individual features may be transcribed manually to a digital inventory database, but

some agencies simply store the film as the reference medium and review it when

required.

The videos are usually reviewed manually, and defects or desired data items are

recorded either through visual (subjective) assessment or through a combination of

manual measurement and Image Processing (IP) techniques. Lately, the Videos are

analysed using full blown Image Processing (IP) technology to digitise images using

appropriate software and record them in digital form. However, the reliability of the

outcome (data) depends on the IP technology and processing software.

The advantages of this method are that the "data' can be collected with fairly basic

skills, the logging vehicle can move at virtually the same speed as traffic, and review

can be conducted by experts at any time without having to revisit the field, which can

result in significant amount of time being saved.

This method is more suitable for recording pavement condition parameters and other

visible features. Examples are ARRB Hawkeye Video and ROMDAS Pavement Video.

Lately, LiDAR technology has also became popular to record some road related

information. A sample Video measurement is depicted in Figure 3-23.



89

Figure 3-23: Video Image Rating

3.9.3.4 Automated (Equipment) Measurements

This method involves deploying a combination of electronic and/or mechanical

equipment, such as Laser Profilometers, Bump Integrators or Ground Penetration Radar

(GPR) etc. The equipment will automatically measure the appropriate data with minimal

or no intervention. The data is recorded in digital form, making it instantly and directly

available as soon as the survey is completed. This eliminates the need for data

transcription or transfer into electronic format. However, data from this equipment may

require further processing or formatting before they are loaded into the database.

This method is commonly employed for recording pavement condition and structure

aspects. A typical equipment mounted vehicle is given in Figure 3-24.

Figure 3-24: Automated Measurement Equipment (FWD)



90

3.9.3.5 Transcription from Records

This method includes collecting information from other sources, which already have

information with them, popularly known as data collection through secondary sources.

This involves referring to published or available information, such as detailed

engineering drawings, project completion reports, First Information Reports (FIRs),

other office records or documents from archives and then transcribing them into digital

form for the database.

Usually, the level of detail is high (more precise), such as detailed project reports or

as-built drawings etc. It has the advantages of precision, and of containing even more

data than required to be stored in the database. It is vitally important to ensure that

these data represent 'as-built' conditions. If the records and drawings are not explicitly

endorsed as as-built, then the data should be verified in the field. The reliability of the

data depends on the type of source and time, as to when it was collected or compiled.

This can be an arduous process, and invariably yields an incomplete coverage of the

network since records usually do not exist for some links.

This method is suitable for limited data categories, such as pavement structure and

inventory items.

3.9.4 Suggested Methods

The suggested methods are described in Table 3-7.

Table 3-7: Suggested Collection Methods

Category Data Items Suggested Method

Location reference Network Equipment

Alignment Equipment

Administrative Transcription or Windshield

Road Inventory Geometry Equipment

ROW Transcription or Windshield

All others Windshield

Pavement Roughness Equipment

Deflection Equipment

Composition * Transcription

History Transcription

Surface condition and Edge

damage

Windshield

Other Condition All items Windshield

Traffic Volume Equipment or Manual



91

Axle load Equipment

Structures Inventory and Condition Manual

Others ROW Video Manual

* For more accurate and reliable data, Equipment based data collection (GPR) is recommended

subject to funds availability.

3.10 Frequency of Data Collection

3.10.1 Introduction

The frequency of surveys for monitoring road, bridge, or traffic conditions has an

important bearing on the cost of surveys and the sustainability of data collection. Data

should be collected only as frequently as is required to ensure proper management of

the road network. The frequency can vary depending upon the data of interest.

3.10.2 Basis of Selection

The selection of frequency of data collection is guided by the following factors:

Level of data collection (Network or Project);

Intended use of the data (Planning or programming etc.);

Method of data collection (sampling or continuous);

Significance of the Network (Main roads or connecting roads etc.);

Type of funding (public funds or private funds or loan/grant);

Availability of resources (In-house or outsourced);

Compliance with Business plan (support from senior management).

3.10.3 Suggested Frequency

The usually suggested frequency for various data items is given below.

Road Inventory Data are typically collected as a one-off exercise. They are then

updated when changes are made to the road. It is suggested to verify/update the data

every five to seven years depending on the reliability of the data from other sources.

Base year information is suggested to be collected using method suggested in Chapter

5. It is then suggested to collate information from other sources, such as DPRs, project

completion reports, NHAI and MORTH offices and reports from Concessionaries etc for

continual updating of the inventory information. The database must be validated

through a direct survey in 5 to 7 years interval subject to availability of funds.

Pavement Structural Data are usually collected at different frequencies, depending

on the road class. Pavement strength data are collected in three to five years interval.

The frequency needs to be sufficient to identify major changes that will influence road

maintenance decisions. Pavement composition and history data must be collected

through other sources as described above.

Pavement Functional Data are suggested to be collected at frequent intervals,

preferably each year. The frequency needs to be sufficient to identify major changes,

which will influence road maintenance decisions.



92

Pavement Surface Condition Data are suggested to be collected at frequent

intervals, preferably each year. The frequency needs to be sufficient to identify major

changes, which will influence road maintenance decisions.

Structures Inventory Data are typically collected as a one-off exercise, similar to

road inventory. It is suggested to validate/update the data every five to seven years

depending on the reliability of the data collected from other sources subject to

availability of the funds.

Structures Condition data tends to be collected in two cycles. Routine inspections

are suggested once a year (twice a year for critical or strategic bridges) while detailed

inspections are suggested at longer intervals, typically of the order of five years.

Traffic Data are usually collected at designated traffic count stations. It is suggested

to collect short-term counts (typically seven days for traffic volumes and one day for

axle load) at selected (fixed or varying) locations each year. Accidents information is

suggested to be updated every year.

3.11 Simplified Data Collection for RMS (Rural Roads)

Presently the existing RMMS is catering for Rural roads, SH and MDR’s. However, the

maintenance requirements of SH and Rural roads are different. Rural roads may not

require such large number of data items. A simple PCI based data is proposed for

prioritisation of maintenance activities.

Presently the data collected involving large number of data attributes involve a huge

human effort, which makes the field teams either to fill in partial or incomplete and/or

false data. Hence, it is proposed to simplify the data collection procedures. Following

are the simplified data collection items for rural and other roads.

Road Inventory

Terrain Type;

Carriageway Width in m;

Embankment height in m;

Cross section Type;

Surface Type and Thickness;

Base Type and Thickness;

Sub-base Type and Thickness;

Sub-grade Type and Thickness;

Shoulder Type ;

Shoulder width in m;

Side Drain Type (Left and Right);

Side drain depth in m;

Junction Type and Location;

All/Fair weather road (AWR/FWR);

Rainfall in mm;

Habitation (Administrative office, School, College, Medical Facilities, Police

Station, Post office, Market, Tourist Place, Religious Place etc.)

Road Condition

Overall condition rating (PCI);



93

Structures Inventory & Condition

Location;

Type and Size;

Overall Structural condition.

Traffic

AADT.

Pavement Treatment History

Construction Date/Year;

Resurfacing Date/Year;

Rehabilitation / Upgrading Date/Year;

Periodic Renewal Date/Year.

Road Condition for Routine Maintenance

Pavement Surface

Top Surface condition;

Base course condition;

Sub-base condition;

Sub-grade condition;

Side drain condition;

Off Carriageway (Left and Right side)

Bush clearing (width);

Clear side drains (depth);

Clear mitre drains (depth)

Shoulder repair;

Side slope repair.

Carriageway

Debris removal;

Pothole patching in m2;

Base course repair in m2;

Crack sealing in m;

Resealing in m2;

Thin Asphalt overlay in m2;

Rejuvenation / fog spray in m2;

Light grading in m2;

Camber reshaping in m2;

Structures

Culvert/head wall repair in m;

Repair retaining wall;

Minor bridge repair;

Road Furniture

Repair road signs in No.;

Replacement of road signs in No.;

Road Marking repair in m;



94

Road Marking renewal in m.

The data collection formats are given in Annex-I.

3.11.1 Frequency & Method of Data Collection

A comprehensive data collection survey is required to be undertaken annually covering

all aspects of the pavement, drainage, roadway, signage, major structures and all road

related items.

The data collection is done manually by visual inspection. The inventory data is

collected as and when there is a change in the network and condition should be

collected every year after monsoon season and surveys must be completed no later

than November each year to ensure that the maintenance budget is prepared

representing the real needs of the road network for inclusion in the budget and that the

contractor, for multiple year contracts, is well informed of his future requirements.

3.12 Budgeting and Maintenance Planning

The Public Works Department requires the road to be maintained to an acceptable

level, and sets the Intervention Level and Rectification Standard to ensure that this

requirement is met. It is important that the annual budget reflects this standard to

enable an achievable outcome.

The funding or resources budgeted for Routine Maintenance should not be redirected to

other activities. Once the basic maintenance is reduced, more major defects are

normally the outcome. Only the funds remaining after costing the full Routine

Maintenance should be available for non-routine maintenance.

Formal inspections, informal information/requests, and emergencies, whether by direct

works or contract, dictate the level and urgency of outstanding work. Having gathered

the information, forethought has to be given to the organisation’s priorities and

strategies before a Works Program is constructed.

3.12.1 Routine Maintenance

Routine maintenance requirements are determined by undertaking the annual road

item condition survey and assessing the quantity of each maintenance item required to

be corrected.

The required minimum budget is determined by multiplying these quantities, taking

into account sections proposed for Non-routine works, by the set of unit rate costing

available for each item within the Schedule of Rate Analysis for Road Maintenance.

Roads continue to deteriorate with time due to traffic, weather, age and terrain;

therefore, an allowance of 10 - 15% is added to the quantities to cover normal

deterioration throughout the year.



95

3.12.2 Emergency Maintenance

Emergency maintenance is limited to the immediate work required to reopen the asset

and making it safe for the road user and preventing further damage. This includes

removal of debris, undertaking temporary repairs, slips, snow clearances, providing a

detour or bypass or similar works.

Repairs are generally of a temporary nature and will require permanent works to be

included from within the existing budget or programmed in future periodic or

upgradation programs.

Emergency maintenance is considered the most important component of maintenance

and, therefore, an allowance must be made each year to cover these works. The

amount of funds required can be predicated using past records.

3.12.3 Non-Routine Maintenance Strategy

The Executive Engineer must ensure that the strategy for non-routine maintenance, i.e.

periodic maintenance, Provisional Items and minor rehabilitation, is scoped, budgeted,

and approved at the commencement of each financial year. Once the strategy is set,

measurable quantities and budgets are forecast by program selecting the required data

and inserting it into the Road Section Rating and Prioritisation as indicated in Section

3.12.4. A list of roads suitable for selection of periodic maintenance is then provided for

further review and final selection. The following list alludes to the processes carried out

surrounding the budgeting for non-routine maintenance:

Pre Budget

Carry out the annual Condition State Survey to ascertain the quantity of all defects in

each section. Items to be used in the analysis are:

Potholes for BT roads;

Pavement edge break (horizontal) for BT & WBM;

Pavement surface cracks for BT roads;

Pavement surface failure for all roads;

Surface texture for BT roads;

Pavement edge drop (vertical) for all roads;

Unsealed shoulder deformation for all roads;

Shoulder drainage for paved roads;

Joint sealant failure in concrete roads;

Broken and cracking for concrete roads;

Roughness of all road surfaces;

Pavement defects in unpaved surfaces;

Camber in unpaved roads;

Pavement thickness in unpaved roads (remaining life);

Estimating the remaining life of surface;

Exclude all sections of road programmed to be undertaken by other funding

sources;

Set a work strategy to address the considered major problems;

Prioritise activities in accordance with strategies set in the Road Section Rating

and Prioritisation Model:



96

Insert quantities into Engineers Estimate and assess required funding

recourses; and

Send recommendation report to higher authority requesting approval to the

maintenance program

Post Budget

Compare approved budget against recommendation.

Where budget constraints are imposed, rerun the Road Section Rating and

Prioritisation Model, take into account RPI and reprioritise road section

activities.

Taking into account that routine and emergency maintenance takes

precedence, readjust the prioritised work list to meet the balance of the revised

budget.

Where considered appropriate, reassess and adjust routine and emergency

maintenance strategies to provide more cost effective use of funding.

Ensure Maintenance Engineers are aware of their limitations in approval of non-

routine maintenance activities.

3.12.4 Road Section Rating and Prioritisation

3.12.4.1 SH & MDR Roads

The Pavement Management System (Planning and Budgeting tool) will be used for

rating and prioritisation of SH & MDR roads.

3.12.4.2 Rural & Other Roads

The priority for assessing non-routine road needs for preservation of the Rural & Other

road network will be done by the calculation of a Road Condition Index and will be

undertaken within the RMS database, using selected road condition data collected

during the annual item condition data survey carried out prior to November each year.

The percentages and ratings for each selected defect will be automatically calculated

for use in developing the final prioritisation list.

The RCI calculation undertaken within the RMS database uses the criteria shown in

Table 3-9 and Table 3-10 to develop a road section priority rating.

Road Priority Index (RPI)

All roads must receive some maintenance every year, if a sustainable road network is

to continue to operate effectively.

Road hierarchy classification (road importance) is normally used for systematic

allocation of maintenance funding under funding constraints. There is currently no road

hierarchy for roads in India and, therefore, it is proposed to use a simple system,

taking into account road classification, population (potential traffic generation), town

infrastructure, distance to markets, terrain, bus route, etc. to develop a Link (road)

Priority Index for each village. This appears to be a fair assessment of prioritisation of

roads by importance.



97

RPI will only be used and added to overall rating when funding constraints are imposed

to provide a final ranking and road section prioritisation for maintenance.

Table 3-8: Road Priority Index

Road Priority Index for ( VR )

Indicator

Rating

0 1 2 3 4 Max

A **Traffic or

(PCU) Below 50 50 – 200 200 – 500 Above 500 6

B Population

serviced** Below 50 50 - 499 500 - 999

1000 and

above 6

C Terrain Plain Rolling Hilly Mountainous 3

D Rainfall (mm)

Light

<700mm

Medium

701-1500

Heavy 1501

& above 2

E Education

facilities No Elementary

Secondary and

above 2

F Tourist/

Religious No Yes 2

G Health facility None Sub centre

CHC/PHC&

Above 2

H Market &

Industry No

Market or

Industry

Market &

Industry 3

I xx Road

Classification VR

MRL Through

road 4

Maximum RPI

value 30

** Due to importance double scores are given to traffic and Road Classification.

Where traffic counts are available traffic will take precedence.



98

Table 3-9: Road Condition Index Calculation Rating Chart (Paved)

ROAD CONDITION RATING CALCLATION CHART FOR VR AND MRL

Defect Type Percentage of Damage

Name Criteria

PAVED ROADS

Roughness *** IRI(No) <6 6-<10 10-<13 13-<15 =>15

Potholes all < 1 1-5 5-10 10-20 =>20

Edge breaks all <1 1-15 15-30 =>30

Ruts and

Depressions

all <1 1-<5 5 -<15 15-<30 =>30

Surface cracks all <1 1-5 5-15 >15

>5 mm <1 1-5 5-15 >15

Pavement

failures

all < 1 1-5 5-10 10-20 =>20

Surface texture <2 m2 < 1 1-5 5-10 10-20 =>20%

Shoulder

deformation

edge drop/

>50 mm <1 1-5 5-10 10-30 =>30

Shoulder

drainage

High/Flat < 1 1-10 10-30 30-50 =>50

Joint sealant all < 1 1-10 10-25 25-50 =>50

Broken

/Cracked

Concrete

>100 mm <10 10-20 20-30 =>30

Remaining

Life***

% of

design

>80 <80-60 <60-40 <40-20 <=20%

Rating 0 1 2 3 4

Rating Score <=8 >8 -19 >19-27 >27-34 >34

Maintenance

Required

Minor

Maintenance

Routine Periodic

Maintenance

Holding/

Rehabilitation

Upgradation



99

Table 3-10: Road Condition Index Calculation Rating Chart (Unpaved)

ROAD CONDITION RATING CALCLATION CHART FOR VR AND MRL

Defect Type Percentage of Damage

Name Criteria

UNPAVED ROADS

Roughness***K

m/hr

all 40-50 30-40 30-20 20-15 <15

Potholes /Edge

breaks

all <1% 1-10% 10-20% 20->30% >30%

Surface failures all < 1% 1-5% 5-10% 10-20% >20%

Edge drop

(WBM)

>50 mm <1% 1-5% 5-10% 10-30% >30

Camber Low/Flat <5% 5-10% 10-20% 20-50% >50%

Thickness for

gravel

all >100 >75 >50 <50

Remaining

Life***

% of

design

>80 <80-60 <60-40 <40-20 <20%

Rating 0 1 2 3 4

Rating score <6 >6-9 >9-13 >13-19 >19

Road Condition Very Good Good Fair Poor Very Poor

Maintenance

Required

Minor

Maintenance

Routine Periodic

Maintenance

Holding/

Rehabilitation

Upgradation



100

VOLUME II:

SYSTEM ARCHITECTURE



101

4. System Architecture

4.1 Key Consideration

We believe that HPRIDC/HPPWD currently faces several key business and technical

challenges that must properly be addressed to ensure that the proposed RMS is

efficient and sustainable. Some of these challenges are listed below:

4.1.1 Technical Challenges

The technical challenges faced by HPRIDC/HPPWD include:

To provide uninterrupted access to users;

To provide centralized data storage and archival for all the sites around the State;

To minimize effort (cost) of deployment, including both hardware and software;

To reduce cost of server maintenance;

To provide a complete scalable solution, considering the future growth of

HPRIDC/HPPWD.

To provide a flexible reporting model, to match HPRIDC/HPPWD reporting

requirements.

4.1.2 Deployment Challenges

The deployment challenges faced by HPRIDC/HPPWD include:

To support full scale-out capability, including upgrading hardware and software

without changing the source code;

To support high availability capability, including meeting peak capacity with one

failed node;

To provide maximum performance within the system architecture;

To support high maintainability, with minimum or no downtime to deploy patches

and upgrades to the application and/or the operating system;

To support role, area and access based security;

To provide similar or better user experience.

4.2 Architectural Requirements

The system architecture has been finalised considering the following:

Centralised Architecture: RMS should work on a Service Oriented, centralized

Server Architecture mode rather than Desktop version, as it exists today.

Ability for End Users to Work from Remotely: Users of all levels in the

HPPWD/HPRIDC, i.e. headquarters, Circle and Division offices, engaged in planning

and managing the road network under HPPWD/HPRIDC control shall be able to

access the system.



102

Import/Export: RMS should be able to export to Excel all the road network data

stored on the RMS.

Compliance to HPRIDC/HPPWD Technology Standards: RMS should ensure that this

system is in line with the overall IT and MIS policy of the State and the

department.

4.3 Architecture Evolution

This section lists various options considered for the RMS architecture along with their

perceived benefits and constraints. The best fit for RMS requirements was arrived at

after analysing each of the following options.

Service based Architecture: RMS should follow a Service Centric Architecture where the key functional processes are exposed as Services to clients. These clients could be

external systems (on homogeneous or heterogeneous platforms) or interactive end users accessing RMS either through desktop or laptop systems.

RMS Front End: The following were the key considerations behind the decision between a web based front end and a desktop Client front end.

Table 4-1: RMS Front End

Feature Web Based System Desktop Based System

Software Setup/

Installation

Very simple

Software is installed at one

location i.e. on the server.

Tedious

Software is required to be

installed on every

desktop/laptop.

Centralized Database

Yes

Database can be located at

HO and users from various

locations can access the

system.

No

Requires WAN connectivity

or separate databases to be

maintained at HO and other

offices with regular database

synchronization.

Licensing Cost

Low

Only One Multi User

(Server) License is sufficient

High

Each desktop requires a

single (one seat) license.

Patches/Upgrades

Seamless

Patches/upgrades are applied

on the server.

Manual

Patches/upgrades are

applied on all desktops/

laptops manually.

Hardware/Software

Cost of Client System

Low

Processing of the application

High

Processing of the application



103

occurs on the server. Client

systems can have minimum

hardware and software.

occurs on the Client,

therefore, requires high end

configuration.

Support and

Maintenance Costs Low High

Performance

Medium

Depends on internet

bandwidth (recurrent cost).

High

Depends on LAN/WAN

network bandwidth (one

time cost).

Based on the above comparison, web based architecture shall be adopted.

4.4 Functional Architecture

The diagram below depicts data/objects flow across the layer for a sample use case

(Road Network Data). Following are the high level classes identified as part of Road

Network Data use case.

Road Inventory View: this is a view class inherited from ASP.Net Web Api’s IView

class. This will act as code behind class for an ASP.Net RoadInventoryView.aspx.

Road Inventory Controller: this is the controller class inherited from ASP.Net

WebApi IController class. This will hold all the logic related to view class.

Road Inventory Business: this is the business class built for client side business

logic validation for Road Inventory function.

Road Inventory Service Proxy: this is the service proxy class built as a wrapper to

RISService JSON.

RIS Service: this is the JSON/REST service build to provide the required data

management related to RIS module. It will have methods like GetInventoryData,

GetConditionData etc.

PMS Work Flow: this is the JSON/REST workflow component to provide workflow for

PMS. i.e. Create Homogeneous Section, Edit Sections, Export data for HDM-4 etc.

PMS Data: this is ADO.Net data access classes to provide PMS related data

manipulation and retrieval capability.

The diagram below depicts the Functional Architectural View of RMS sample modules.



104

Figure 4-1: Functional Architecture

4.5 Technical Architecture

The web based system will be built to support all modern browsers (IE 10 and above,

Firefox 27 and above, Chrome 30 and above, Opera 17 and above, Safari 5.1 and

above).

The proposed technical architecture is depicted in Figure 4-2.



105

Figure 4-2: Technical Architecture

4.5.1 Presentation Layer

The presentation layer will be built using MVC pattern for HTML and JavaScript /

JQuery, the Model (M of MVC) will connect to the web services at the server

asynchronously in response to user requests at the View. Models at this point will be

pure JSON objects. AngularJS framework will be used to support the controllers and

views where controllers will handle the required changes in the views and maintain the

overall state of the application.

4.5.2 Web Services

Web services will expose the required objects as JSON to the clients; the focus will be

to develop a REST like interface using ASP.Net WebApi.

4.5.3 Business Layer

The business validations and actions such as sectioning, batch process etc. will be

handled in this layer.



106

Figure 4-3: Layered Architecture

4.5.4 External Services

For long running processes that require state management, external services will be

facilitated that will take the load off from the web services. These services will interact

with the web service by means of API to define locks on the objects as well as send

information regarding task progress.

4.5.5 Data Access Layer

The data access layer will essentially perform two types of tasks, work with known

objects essentially configuration related and work with unknown objects essentially

data related to assets.

To support these specific requirements, the first case will be dealt with using an ORM to

reduce boiler plate code.

NHibernate/EF will be used as the ORM.

The second case will be dealt with by constraining the data access to specific objects;

hence, allowing simple queries for filtering, querying and validations.

4.5.6 Database

The system will support an SQL Server 2008 and above. Data providers will be made

for supporting other databases.



107

4.5.7 Exception Handling and Logging

Generic exceptions with defined numbers will be used for all exception handling; the

number will define the location of the exception.

Various types of exceptions will be pre-defined for use; the aim will be to reuse any

specific .Net exceptions.

Nlog will be used as the logging framework owing to its support for configuration as

well as wide range of logging targets.

4.5.8 Reporting

“MS Excel” will be used to generate and render reports.

4.5.9 User Management

User management will be handled basically by extending the IPrincipal and IIdentity

interfaces. These will then check the access level of the current user based on action,

module and asset.

4.6 Non-Functional Requirements

4.6.1 Scalability

The design of RMS will support full scale-out capability with which additional hardware

can be added to the system without the need to make changes in the code.

Following sections describe how the architecture achieves scalability.

Web Server Scalability

Session state will not be maintained in the web server. Session state will be stored in

SQL Server database using the session management features of ASP.NET. Without web

server state, it would be possible to deploy as many web servers as required with a

load balancing mechanism that shares the load among the servers. This will also

facilitate maintenance activities in some of the servers without affecting the

functionality of the system. The hardware load balancing is recommended as the load

balancing mechanism for RMS.

The Network Load Balancing (NLB) clustering feature of Windows Server can also be

used as the load balancing mechanism. NLB is a built-in feature of Windows Server that

comes without any additional cost and it does not need any additional hardware. It is

the most cost effective mechanism to implement load balancing. NLB clustering can

support up to 32 nodes.

Business Services Scalability

Business services will be designed using the service oriented architecture (SOA)

paradigm. The business services can be deployed in the web server or on one or more

dedicated servers. ASP.Net WebAPI will be used for communication to the service layer

from the ASP.NET UI layer. Load balancing can be done with multiple business service

servers. Hardware load balancing can be used for load balancing similar to web server

load balancing.



108

Database Scalability

For database scalability, scale-up at CPU level is recommended as opposed to scale-out

at server level for other servers. The database server should be an SMP (Symmetric

Multiprocessing) server with capability to add additional CPUs in future. Windows

Server Enterprise edition can support up to 8 CPUs while Windows Server Data centre

edition can support up to 64 CPUs.

4.6.2 Availability

Load Balancing

With Hardware Load Balancing, availability requirements can be met along with

scalability. For web servers and business service servers, availability can be achieved

with appropriate capacity planning. The system should be able to meet peak capacity

requirements with one failed node.

Hardware Load Balancing can be used to completely eliminate downtime associated

with deploying patches by using rolling upgrades. Rolling upgrade is performed by

taking redundant cluster nodes gracefully offline, upgrading them, and then bringing

them back online. This process is repeated until all cluster nodes have been

successfully upgraded.

Transaction Replication with Log Shipping

For database availability, a fail-over mechanism based on transaction replication with

Log shipping is recommended. Since a downtime of up to 8 hours is acceptable for

RMS, transaction replication with Log shipping will be more cost effective than server

clustering that gives a much higher level of availability (fail-over in one minute). The

fail over database is the staging database.

The application will be using the primary database server, while a fail-over database

server will be up with log shipping configured to happen as fixed time interval from the

primary database to the fail-over database. At any point, the fail-over database will be

older than the primary database by the log shipping interval. If log shipping is

configured to happen once in every hour, the fail-over database will lag behind the

primary database by one hour. In the event of failure of the primary database, the

application can switch to the fail-over database if the primary database could not be

brought up within acceptable amount of time. With the log shipping technique disaster

recovery requirements can also be addressed by having the fail-over server physically

placed far away from the primary database server. The distance between the two

servers would depend on the disaster recovery policy of HPRIDC/HPPWD / Hosting

provider.

4.6.3 Performance

RMS will be designed to give maximum performance within the architectural

requirements. This section describes the techniques that would be employed to

improve performance.

Data Caching at Web Server Level: Caching of relatively data will be done in the web

server. The cache will be in the memory space of the web server process the hosts

ASP.NET. Caching in web server is aimed at reducing frequent access to database and



109

improve on performance. Data caching would be done for reference data and other

data that may not change frequently. Mechanisms will be built-in to automatically

release the cached data after a specific amount of time and to control the total size of

the cache.

Minimum Browser Refresh: The ASP.NET pages will be designed to minimize the refresh

of the browser screen during HTTP requests. This will be achieved with a combination

of frames, div’s and iframes.

Reducing Page Reloads with Angular JS - SPA: With the AJAX, web services can be

called directly from the browser using JavaScript. The approach to reduce page reloads

is to make web service calls from the browser in response to events that need to be

processed in the server side. If, for example, there is a requirement to do a database

access on click of a button in a page, the usual approach of having a server side event

for the button would result in a post of the entire page to the server and a full re-

download of the page after the server event is completed. With the AJAX, a web service

call will be made from the browser to perform the server side processing and the

results returned by the web service call will be populated in the page using dynamic

HTML features. Note that web service access will be using SOAP/REST protocol on top

of the HTTP/HTTPS protocol. No additional ports need to be opened to allow web

service calls from the browser.

Paging: Pagination of the data will be done when large amounts of data are returned

from the web server.

Caching in Browser: Caching of reference data and other relatively static data would be

done in the browser. This will be achieved using frames and JavaScript variables that

will hold the cached data.

Optimised Web User Interface: Better network performance can be achieved by

optimising the user interface to use lesser network bandwidth. All pages will be

designed to have a download size that is within a fixed upper limit to give a better

network performance.

4.6.4 Maintainability

With the help of hardware load balancing described earlier, it would be possible to

deploy patches and upgrades to the application or the operating system without any

downtime. Rolling upgrade is performed by taking redundant cluster nodes gracefully

offline, upgrading them, and then bringing them back online. This process is repeated

until all cluster nodes have been successfully upgraded.

RMS will have mechanisms to produce detailed logs of application errors. Mechanisms

for analysing the performance of the application will be provided with support for

detailed tracing of the execution paths of the application. This would help in managing

the performance of the application as the application evolves.

4.6.5 Security

Authentication

RMS will use ASP.NET forms authentication to authenticate users against registered

users in the system.



110

Secure Communication

HTTPS will be used for communication between browser and the web server. Using

HTTPS for the entire application will have an impact on performance because of the

computational and network overhead caused by the encryption process. Considering

that RMS users will be within the corporate network that is secured from external

access, it may be advisable to consider using HTTPS only for requests that transfer

sensitive data, like the initial login request.

User Access Control

User access will be controlled at every HTTP request. Following actions will be

performed to authorize every HTTP request.

The authentication ticket that is sent to the server through a session cookie will be

validated to ensure it is a valid ticket issued by a successful user login and is not

expired.

The page level access will be checked to verify that the user is authorized to view

the requested page. The check will be based on user roles like location

administrator and global administrator.

A HTTP request will go through for further processing, only if the above two checks are

successful.

Data level authorization like ensuring a location user gets to see only the data in

his/her location will be handled by the business logic components that would filter the

data retrieval based on the users’ location/segment/role.

Information of user roles, location and segment assignments would be stored in RMS

database.

4.6.6 User Experience

The user interface will be web based single page application built using Angular JS

framework.

4.7 Physical Architecture

The layered architecture provides scalability to the solution. The infrastructure

architecture facilitates for load-balanced web/application server and a highly available

database server. For Load-balanced web / application server an OS cluster will be

deployed above fault tolerant network architecture.

The IIS Web servers are load balanced using Network Load Balancing (NLB) Clustering.

Availability requirements can be met along with scalability. For web servers and

business service servers, availability can be achieved with appropriate capacity

planning. The system should be able to meet peak capacity requirements with one

failed node. The below diagram depicts proposed Physical Architecture.



111

Internet

Primary ISP

Secondary ISP

Primary

FirewallSecondary Firewall

SecondaryPrimary

Primary Secondary

Domain Controller, LDAP Server

Computer Computer

UserUser

Roaming Users

Remote office users

HO LAN

HO Users

App

Server

Database ServerBackup

Database Server

VM

Controller

Honeypot Probe

Web Server

On DMZ

GIS Server

Figure 4-4: Physical Architecture

4.8 Hardware and Software Requirements

The Hardware and Software configuration envisaged for the proposed RMS is listed in

Table 4-2.

Table 4-2: Hardware and Software Requirements

Specifications Hardware Software

Web Server HP Proliant BL 460C Generation

8 Blade Server

Intel Xeon E5-2600v2

processors, 4 cores Max #2

processors

2 Hot Plug Disk Bays, 2.5 inch

Smart Carrier

2 Port 10Gb Ethernet 534 or

554 FLB FlexLOM

128 GB memory

3 year Onsite warranty

MS Windows Server

Datacenter 2012

IIS 8.0

ASP.Net Framework

4.5

Application

Server

MS Windows Server

Datacenter 2012

IIS 8.0

ASP.Net Framework

4.5

GIS server either (Geo

Server / MapServer /



112

Or

Any Equivalent Server

ArcGIS)

Database

Server

MS SQL Server

Enterprise Edition

2012(2x2 Core)

Client

Desktop

Any normal Desktop/Laptop For Admin Users:

HDM4 Version 2 and

Web browser

For normal users -

Web browser (IE v 11

or above, Firefox v 25

or above, Chrome v 33

or above)

The key elements to be considered for the server room or data centre are:

Facilities in a full functional datacentre floor;

o Building in place;

o Data centre Room built and ready including raised floor;

o Uninterrupted power supply including power generators, UPS, power busses

and PDUs;

o Uninterrupted temperature controllers including Chillers and Compressors;

o Fire suppression with appropriate zoning and monitoring;

o Communication penetrations, risers and distribution frames;

o Physical security infrastructure.

Security;

Power requirements;

Communication links;

Temperature controls;

Physical layout;

Monitoring & management systems.

4.8.1 Appreciation of Current HPPWD/HPRIDC IT Infrastructure

It is understood that most of the staff are provided with either desktop/laptops in HQ

or other offices and are LAN/WAN connected through BSNL broadband. The WAN

connectivity to Zonal offices is connected through HIMSWAN. All the offices are

provided with internet connection with some offices having limited bandwidth. All the

servers are hosted outside HPPWD office at State Data Centre as Co-Location

installation. All the systems are Windows based systems using Windows 7/8 and

Chrome/Firefox browsers, hence Microsoft platform based COTS is proposed for RMS

system.



113

An

nex-I

: R

ural

Ro

ad

s D

ata

Co

llecti

on

Fo

rm

ats

RRDCS-01

CODE: CODE: CODE:

Ro

ad L

and

Wid

th

Form

atio

n W

idth

Car

riag

ew

ay W

idth

BT

WB

M/M

etal

Eart

hen

Gra

vel

Nu

mb

erN

um

ber

Typ

e

Tota

l Len

gth

(Wat

erw

ay s

pan

) w

idth

(m)

Hab

itat

ion

Co

de

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

CD1 H1

CD2 H2

CD3 H3

Signature:

INVENTORY OF RURAL ROADS

Pre

do

min

ant

Soil

Typ

e

Terr

ain

Typ

e

All-

wea

ther

Ro

ad (

AW

R)

or

Fair

-wea

ther

Ro

ad (

FWR

)

Co

nd

itio

n R

atin

g (P

CI)

Certification:

Certified that the above information is correct.

Name: Designation:

B: Provide the following details of all type of RURAL ROADS in the Block

Width

(m)

Length per Surface Type

(Km) Existing CD Works

List of

Habitation

on the Road

Sr. N

o.

Nam

e o

f R

oad

Ro

ad C

od

e

Cat

ego

ry o

f R

oad

(O

DR

/VR

/Oth

ers)

Len

gth

(K

m)

(Ex.

12

.93

5)

ANNEX 1: RURAL ROAD DATA COLLECTION FORMATS

A: REFERENCE DATA

STATE: DISTRICT: BLOCK:

RRDCS-02

Kilometer: to Date of preparing inventories:

Date of upgrading: / /

1 2 3 4 5 6 7

1 Year of Construction

2 Year of last rehabilitation/Upgradation

3 Crust thickness Equivalent (mm)

4 Present wearing Coat (type)

5 Type of shoulder

6 X-section cutting/filling (ave. ht.)

7 Junction

8 Annual rainfall (mm)

9 Traffic in year 2013-14

10 Year of last periodical renewal.

11 PCI

12 Routine Maintenance done

PAVEMENT COMPOSITION OF RURAL ROADS

Particulars

Sr.

No

KM

Name rural road : PWD Dn.: / Sub Dn.:

RRDCS-03

km

of

`+000 1 2 3 4 5 6 7 8 9 0

Shoulder Condition

Side drain Condition

Pothole

Cracking

Edge break

Ravelling

Depression

Shoulder Condition

Side drain Condition

Culvert Condition

Bridge Condition

PCI - 1-Good, 2-Fair, 3-Poor

Date: Date: Date:

Surveyed by: Checked by: Counter-signed by:

Stru

ctu

res

PCI

PCI

Rig

ht

sid

e

PCI

PCI

PCI

Car

ryag

ew

ay

PCI

PCI

PCI

PCI

Sub-division:

Pavement Condition Unit

Left

sid

e PCI

PCI

District: Project: Page:

Division: Chainage

ROAD CONDITIONRoad Name:

Road Category: Length:

RMS-01

km

of

`+000 1 2 3 4 5 6 7 8 9 0

Q-ty

Bush clearing (width)

Clear side drains (silted up to 50% )

Clear side drains (silted up to 100%)

Excavate cross drains(depth<30cm)

Lower berm

Shoulder repair (-50mm)

Side slope cutting repair

Pothole repair (area)

Crack sealing (crack > 5mm)

Crocodile crack (area)

Edge break (width)

Revelling (area)

Depression (area)

Bush clearing (width)



Excavate cross drains(depth<30cm)

Lower berm

Shoulder repair (-50mm)

Side slope cutting repair

Clear culvert/small bridge

Clear inlets and outlets

Repair culvert/small bridge

Repair road signs

Maintenance of Kilometre stone

Maintenance of 200 m stones

Maintenance of Parapets

Maintenance of Guard stones

Surveyed by: Checked by: Counter-signed by:

m

m2

m2

m2

m3

Date: Date:

m2

m

m

Page:

Date:

m2

Rig

ht

sid

eC

arry

age

way

Stru

ctu

res

no.

no.

no.

no.

no.

no.

m3

m2

m

m2

m2

m2

Proposed Maintenance Activities

Left

sid

e

Unit

Length:

m2

m

m

m

Division:

Sub-division:

Chainage

m2

m2

m2

Road Name:

Road Category:

Project:

ROUTINE MAINTENANCE

District:

RRDCS-04

Date :

From Hrs.

To Hrs.

From Hrs.

To Hrs.

From Hrs.

To Hrs.

From Hrs.

To Hrs.

Total for day

Note: Record traffic volume by tally marks [four vertical strokes followed by a diagonal stroke for the 5th vehicle]

Cyc

les

Cyc

le R

icks

haw

s

Tru

cks

Bu

ses

State :

Hour Vehicle Class

Rem

arks

Sea

son

:

Po

st H

arve

st

An

imal

Dra

wn

Veh

icle

s

Mo

tori

zed

tw

o-

wh

eele

rs

Car

s, J

eep

s, V

ans,

Thre

e-w

hee

lers

Agr

icu

ltu

ral

Trac

tors

/Tra

ilers

Ligh

t C

om

mer

cial

Veh

icle

s

TRAFFIC VOLUME COUNT

Name of Road :

Location on Road :

District :

RRDCS-04(A)

Day

Car

s, J

eep

s,

Van

s, T

hre

e-

wh

eele

rs

Mo

tori

zed

tw

o-

wh

eele

rs

Ligh

t C

om

mer

cial

Veh

icle

s

Tru

cks

Agr

icu

ltu

ral

Trac

tors

/tra

ilers

Bu

ses

Cyc

les

Cyc

le R

icks

haw

s

An

imal

Dra

wn

Veh

icle

s

Tota

l

Day 1

(date)

Day 2

(date)

Day 3

(date)

Total

Average Daily

Traffic

PCU Factor 1 0.5

1.5 3 1.5 3 0.5 2

4.0

fo

r h

ors

e d

raw

n

6.0

fo

r b

ullo

ck

dra

wn

Average Daily

Traffic PCUs

State :

Vehicle Class

Traffic Census - Abstract

Name of Road :

Location on Road :

District :