% This file is part of the
% The Online BRT Planning Guide
%
% DO NOT EDIT THIS FILE MANUALLY!
%
% This file has been automatically generated from its sources
% using the OBRT tool:
%  tool version: 364c3e5
%  haxe version: 3.4.0
%  runtime: JS
%  platform: Linux

\chapter{19}{Technology}
\label{volume:technology:chapter:technology}
% @ guide/19-technology/technology.src: lines 1-6: code points 1-46

\quotation{Any sufficiently advanced technology is indistinguishable from magic.}{Arthur C. Clarke, author and inventor, 1917–}
% @ guide/19-technology/technology.src: lines 5-6: code points 1-46

Information technology (IT) systems are an important component of high-quality BRT systems. BRT services are designed to cater to large passenger volumes and must deliver fast, accurate, and reliable services in the form of financial transactions, customer information, and operations systems. IT systems address the complexities of day-to-day operations management, reducing manpower and contributing to sizable cost savings. Over the years, the level of integration has increased so that IT now takes a system-oriented approach. IT can be leveraged to foster cooperation among the various transport modes and coordinate management of mobility systems. This chapter provides broad guidance on the planning, implementation, and operations of IT systems. For a more comprehensive guide to IT systems for BRT and bus systems, refer to the World Bank Toolkit on Intelligent Transport Systems.\par
% @ guide/19-technology/technology.src: lines 9-17: code points 1-59

\tabletitle{1}{Key IT System Functions}
\label{chapter:technology:table:key-it-system-functions}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=6\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=23\tablemodule#}\cr
	\color{gray75}\bfseries \emphasis{Operations Monitoring}& \color{gray75}\bfseries \begin{itemize}
\item Ensures on-time performance by facilitating information sharing among the control center, stations, and buses;% @ guide/19-technology/technology.src: lines 22-22: code points 6-121
\item Documents system operations for determining compensation for the bus operator.% @ guide/19-technology/technology.src: lines 22-22: code points 122-205
\item Generates data that can be used to improve service efficiency and system performance.% @ guide/19-technology/technology.src: lines 22-23: code points 206-0
\end{itemize}
% @ guide/19-technology/technology.src: lines 22-23: code points 6-0

 \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}\emphasis{Customer Information}&
	\color{gray50}\begin{itemize}
	\color{gray50}\item In stations, the IT system informs passengers of upcoming departure times and destinations;% @ guide/19-technology/technology.src: lines 25-25: code points 6-102
	\color{gray50}\item On buses, electronic displays indicate the destination;% @ guide/19-technology/technology.src: lines 25-25: code points 103-163
	\color{gray50}\item In buses, the IT system informs passengers of upcoming stop names and transfer opportunities;% @ guide/19-technology/technology.src: lines 25-25: code points 164-262
	\color{gray50}\item Emergency notifications.% @ guide/19-technology/technology.src: lines 25-26: code points 263-0
	\color{gray50}\end{itemize}
	\color{gray50}% @ guide/19-technology/technology.src: lines 25-26: code points 6-0
	\color{gray50}
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}\emphasis{Fare Collection}&
	\color{gray50}\begin{itemize}
	\color{gray50}\item Records sales, payment collection, and system usage;% @ guide/19-technology/technology.src: lines 28-28: code points 6-63
	\color{gray50}\item Provides opportunities to integrate fare payment mechanism across multiple transport modes.% @ guide/19-technology/technology.src: lines 28-29: code points 64-0
	\color{gray50}\end{itemize}
	\color{gray50}% @ guide/19-technology/technology.src: lines 28-29: code points 6-0
	\color{gray50}
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}\emphasis{Signal Control}&
	\color{gray50}\begin{itemize}
	\color{gray50}\item Facilitates efficient junction management and signal priority for buses.% @ guide/19-technology/technology.src: lines 31-32: code points 6-0
	\color{gray50}\end{itemize}
	\color{gray50}% @ guide/19-technology/technology.src: lines 31-32: code points 6-0
	\color{gray50}
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}\emphasis{Fleet Management}&
	\color{gray50}\begin{itemize}
	\color{gray50}\item Manages manpower and allocates duties;% @ guide/19-technology/technology.src: lines 34-34: code points 6-49
	\color{gray50}\item Schedules maintenance.;% @ guide/19-technology/technology.src: lines 34-35: code points 50-0
	\color{gray50}\end{itemize}
	\color{gray50}% @ guide/19-technology/technology.src: lines 34-35: code points 6-0
	\color{gray50}
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}\emphasis{Surveillance Systems}&
	\color{gray50}\begin{itemize}
	\color{gray50}\item Ensures station security.% @ guide/19-technology/technology.src: lines 37-38: code points 6-0
	\color{gray50}\end{itemize}
	\color{gray50}% @ guide/19-technology/technology.src: lines 37-38: code points 6-0
	\color{gray50}
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/technology.src: lines 19-38: code points 1-9

\section{1}{Vehicle Tracking}
\label{volume:technology:chapter:technology:section:vehicle-tracking}
% @ guide/19-technology/191-vehicle-tracking.src: lines 3-72: code points 1-9

\quotation{Don’t worry, sweetie, don’t worry. Nobody in New York notices a bus until it’s about to hit them!}{Samantha, "Sex and the City", 1998}
% @ guide/19-technology/191-vehicle-tracking.src: lines 5-6: code points 1-36

IT systems can aid in the management of bus operations from a central control center (CCC). Known as automatic vehicle monitoring (AVM) systems, such systems preserve reliability by helping the BRT system maintain planned headways. They also allow the CCC to respond to unexpected levels of demand, disruptions, and emergencies such as bus breakdowns, riots, or traffic jams. The CCC can respond with corrective measures such as vehicle substitution, added vehicles on the line, or driver replacement. The CCC also uses the data produced by the AVM to record all arrival and departure times at stops, time points for calculating the service performance index, and restructure service plans (see Section 19.6 Management Information Systems).\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 8-15: code points 1-9

An AVM system consists of a number of key components:\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 17-17: code points 1-53

A CCC, from which the operations are managed. CCC computers run AVM software, which facilitates a wide range of service management processes;\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 19-20: code points 1-38

A global positioning system (GPS)–equipped device on each bus that records the distance and time logs and maintains the record of driver duty and attendance schedules. This information is transmitted to the CCC in real time;\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 22-24: code points 1-21

A communications system between the vehicle and the CCC that can prompt the driver with service information, and facilitates driver communication with the CCC.\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 26-27: code points 1-50

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/ae1631fa150fb10e63a27ce1cc5ceea9978a5250.jpeg}
		\fignote{1}{The automatic vehicle location system.\label{chapter:technology:figure:the-automatic-vehicle-location-system}}{Prodigy Electronics.}
	}
\fi

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/62ce3706392721e76802994497e9b8bec3d93c9c.jpeg}
		\fignote{2}{TransMilenio control center for BRT operations management in Bogotá.\label{chapter:technology:figure:transmilenio-control-center-for-brt-operations-management-in-bogot}}{ITDP}
	}
\fi

The functional requirements of an AVM system depend on the organization modalities and operation procedures adopted by the agency implementing the BRT. Two important planning issues should be considered when organizing the CCC:\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 33-35: code points 1-8

Degree of centralization: some transport operators establish a single, centralized control center from which all of the operations are managed. Other transport operators decentralize operations management. In this case, the AVM system allows client access from any workstation connected via the web and makes control and monitoring functionalities available at different locations;\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 37-40: code points 1-72

Degree of hierarchy: for either centralized or decentralized systems, AVMs can be configured for a single implementing agency or multiple agencies. In the latter case, appropriate access\slash{}read\slash{}write rights must be defined in order to guarantee the confidentiality of data. Recorded data transmitted from vehicles and gathered by the CCC are stored in the same database, but one agency can monitor and manage the information only from its own system.\par
% @ guide/19-technology/191-vehicle-tracking.src: lines 42-47: code points 1-0

\tabletitle{2}{Descriptions of AVM Devices}
\label{chapter:technology:table:descriptions-of-avm-devices}
\halign to 46\tablemodule{%% requires the ifoddpage package
\relax\checkoddpage\ifoddpage\else%
	\kern -16\tablemodule%
\fi%
	\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=40\tablemodule#}\cr
	\color{gray75}\bfseries Component& \color{gray75}\bfseries Description \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}Mounting&
	\color{gray50}Built into the dashboard or over the bus dashboard near the driver seat\cr
	\noalign{\vskip 2mm 
}	\color{gray50}GPS unit&
	\color{gray50}To assure accurate geographic location, track the distance logs and calculate trip kilometers, bus journey speeds, etc.\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Wireless Communication Module (WCM)&
	\color{gray50}Based on high-speed data transmission protocols like GSM\slash{}CDMA\slash{}WCDMA, interface to transmit location information wirelessly to CCC and receive alerts and on-the-air updates. In addition, the WCM should have integrated two-way communication facility between driver and CCC through speakers and microphones\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Driver Interface Unit (DIU)&
	\color{gray50}This module has alphanumeric keypads, an LCD screen to display text messages relayed from CCC, and basic information stored within BCU, such as route details, duty log information, etc. LED indicators for alerts and system status updates. Drivers should be able to send and receive predefined text messages and read them on the screen. DIU allows the driver to log on his duty information, such as driver badge number, change route details, trip start time, and schedules information\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Bus Control Unit (BCU)&
	\color{gray50}BCU is essentially an integrated unit composed of modules like WCM, GPS, and DIU. It may be like an onboard computer CPU with partial integration, with few logical units, and interface with other external components such as the GPS module, etc. To log location data, store other data like the bus-route database, send Passenger Information System (PIS) information received from CCC to on-bus displays and speakers. This controller shall be the interface between all on-bus devices. It shall transmit location information through a secure wired connection to on-bus PIS to make audiovisual announcements\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Integration&
	\color{gray50}BCU unit should be able to allow Automatic Fare Collection (AFC) devices, such as handheld ticketing machines with card validators, to use the BCU’s wireless communication module as a data path to transmit AFC data to CCC. The BCU should have flexibility to incorporate a short-range wireless and wired interface to allow it to act as a data path between on-bus AFC devices and the CCC\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Primary Output&
	\color{gray50}BCU should be able to help the CCC generate the following primary output reports: vehicle start-stop, driver begin-end shifts, daytime operations summary and fleet status, detailed activity, bus speeds, alerts, unit on\slash{}off reports.\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/191-vehicle-tracking.src: lines 47-72: code points 1-9

\section{2}{Customer Information}
\label{volume:technology:chapter:technology:section:customer-information}
% @ guide/19-technology/192-customer-information.src: lines 3-65: code points 1-9

\quotation{The number one benefit of information technology is that it empowers people to do what they want to do. It lets people be creative. It lets people be productive. It lets people learn things they didn’t think they could learn before, and so in a sense it is all about potential.}{Steve Ballmer, businessman, 1956–}
% @ guide/19-technology/192-customer-information.src: lines 5-6: code points 1-35

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/9c4a494e67daed13bea35e7759170742d11f5a58.jpeg}
		\fignote{3}{Bus tracking interface in Chicago.\label{chapter:technology:figure:bus-tracking-interface-in-chicago}}{Chicago Transit Authority.}
	}
\fi

The passenger information system (PIS) relays real-time, pre- and in-trip information on bus arrivals, destinations, and service changes or disruptions in stations. The PIS can also disseminate this information through the web, SMS, and other platforms. Displays on the outside of buses indicate the destination of the vehicle. In buses, voice and visual announcements inform passengers of upcoming stations and transfer opportunities. The information that feeds the PIS is generated through data provided by the AVM system, and is transmitted to stations via hard wiring and\slash{}or GPRS (General Packet Radio Service). Onboard information is programmed in advance of the journey and uploaded to the onboard device.\par
% @ guide/19-technology/192-customer-information.src: lines 10-17: code points 1-0

\tabletitle{3}{Onboard PIS Components}
\label{chapter:technology:table:onboard-pis-components}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=7\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=10\tablemodule#}\cr
	\color{gray75}\bfseries Display Area& \color{gray75}\bfseries Display Type& \color{gray75}\bfseries IT Component& \color{gray75}\bfseries Output \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}Front side of bus&
	\color{gray50}Visual&
	\color{gray50}LED board&
	\color{gray50}Route name and number\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Rear side of bus&
	\color{gray50}Visual&
	\color{gray50}LED board&
	\color{gray50}Route name and number\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Sides of the bus&
	\color{gray50}Visual&
	\color{gray50}LED board&
	\color{gray50}Route name and number\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Inside the bus&
	\color{gray50}Audiovisual&
	\color{gray50}LED board, Speakers, LCD screens&
	\color{gray50}Next station, advertisements, general messages\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/192-customer-information.src: lines 17-43: code points 1-9

\tabletitle{4}{4 Off-Board PIS Components}
\label{chapter:technology:table:4-off-board-pis-components}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=12\tablemodule#}\cr
	\color{gray75}\bfseries Display Area& \color{gray75}\bfseries Display Type& \color{gray75}\bfseries IT Component& \color{gray75}\bfseries Output \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}Stations&
	\color{gray50}Visual&
	\color{gray50}LED board&
	\color{gray50}ETA, route name, route number, platform number, general messages\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Terminals&
	\color{gray50}Audiovisual&
	\color{gray50}LED board; speakers;&
	\color{gray50}ETA, route name, route number, platform number, general messages\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Depots&
	\color{gray50}Audiovisual&
	\color{gray50}LED board; speakers;&
	\color{gray50}Route name, route number, general messages, staff instructions\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/192-customer-information.src: lines 44-65: code points 1-9

\section{3}{Fare Collection}
\label{volume:technology:chapter:technology:section:fare-collection}
% @ guide/19-technology/fare-collection.src: lines 3-75: code points 1-69

\quotation{When you buy a ticket, you’re basically voting for whatever you see.}{David A. R. White, actor, screenwriter, and producer, 1970–}
% @ guide/19-technology/fare-collection.src: lines 5-6: code points 1-61

IT systems for fare collection handle revenue management, financial management systems, and automatic fare collection (AFC). BRT systems function well with off-board, automatic fare collection systems, which reduce vehicle boarding times, allow the rapid introduction of new tariffs and services, reduce revenue leakage, provide data to support system optimization, and support integrated ticketing across multiple modes. Fare collection consists essentially of revenue management processes. The income received by the BRT agency and its expenses are managed by IT systems.\par
% @ guide/19-technology/fare-collection.src: lines 8-13: code points 1-54

BRT stations have fare collection cabins where passengers may recharge electronic fare-payment media or purchase single-ride media. Passengers are able to use smart cards or other payment media at access control barriers inside the stations. These devices read the payment medium, determine if the medium has sufficient value, and then deduct the appropriate fare. The fare payment data are transmitted to the CCC via the station server.\par
% @ guide/19-technology/fare-collection.src: lines 15-19: code points 1-31

The AFC system may be integrated with payment mechanisms on feeder buses and other non-BRT buses. Passengers use electronic media or buy tickets from conductors using handheld ticketing machines. At the end of a shift, the information is downloaded to a terminal server, where it is transmitted to CCC.\par
% @ guide/19-technology/fare-collection.src: lines 21-23: code points 1-92

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/4f39fdf1764a82416f7c52525c0faa7829acf020.png}
		\fignote{4}{Electronic Ticketing and Smart Card Recharge Overview.\label{chapter:technology:figure:electronic-ticketing-and-smart-card-recharge-overview}}{Prodigy Electronics.}
	}
\fi

Data from all AFC transactions are stored at the CCC. Authorized BRT agency staff can view the financial transaction data through a secure dashboard developed by the IT service provider. The BRT agency can use the output from the AFC system to monitor financial performance on a continual basis. The BRT agency and an IT service provider may jointly staff the CCC. Cash collection from stations and terminals can be the responsibility of a service provider or bank. The service provider issues a daily report on total cash collection, and the bank issues a daily deposit report to the BRT agency.\par
% @ guide/19-technology/fare-collection.src: lines 28-33: code points 1-78

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/72998c3a8ed2911c64cfd72b76cf242bb0193f1d.png}
		\fignote{5}{Handheld Ticket Machine.\label{chapter:technology:figure:handheld-ticket-machine}}{ITDP}
	}
\fi

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/3509836a7e218ea7401ddd47e78b2c1d80d66b17.jpeg}
		\fignote{6}{Handheld smartcard reader.\label{chapter:technology:figure:handheld-smartcard-reader}}{ITDP}
	}
\fi

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/ffeef0dafc4caaab8a238c351e8ad4825b2bbc77.jpeg}
		\fignote{7}{Onboard smartcard reader.\label{chapter:technology:figure:onboard-smartcard-reader}}{ITDP}
	}
\fi

\tabletitle{5}{AFC Devices Required in Different Parts of the System}
\label{chapter:technology:table:afc-devices-required-in-different-parts-of-the-system}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=8\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=8\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=12\tablemodule#}\cr
	\color{gray75}\bfseries Device& \color{gray75}\bfseries Place of Deployment& \color{gray75}\bfseries Function \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}Handheld Ticket Machine&
	\color{gray50}&
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Fig 19.5&
	\color{gray50}Onboard&
	\color{gray50}Issue paper tickets\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Fig 19.5&
	\color{gray50}Off board&
	\color{gray50}For use in emergency situations, like power failure at stations\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Smart Card Reader&
	\color{gray50}&
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Fig 19.6&
	\color{gray50}On the handheld ticketing device&
	\color{gray50}Read the smart card and deduct appropriate fare\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Fig 19.7&
	\color{gray50}Onboard&
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Fig 19.8&
	\color{gray50}Off-board&
	\color{gray50}\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/fare-collection.src: lines 40-73: code points 1-9

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/a253d4aad03c88c41cdcb0148e144069d40ce62d.jpeg}
		\fignote{8}{Off-board smartcard reader\label{chapter:technology:figure:off-board-smartcard-reader}}{ITDP}
	}
\fi

\section{4}{Signal Control}
\label{volume:technology:chapter:technology:section:signal-control}
% @ guide/19-technology/194-signal-control.src: lines 3-14: code points 1-80

Automatic signaling systems respond to real-time changes in traffic volumes to offer priority to BRT vehicles and reduce intersection delay for all users. Techniques for signal management for bus priority include: single-phase and cycle adjustments, bus-only turns, and bus-only phases. For the management of priority for buses at traffic signals, it is necessary to balance the objective of improving the public transport performances against the impacts of doing so in mixed traffic. In some cases, bus frequencies may be so high that signal priority would result in continuous green lights, and therefore is not practical. Coordination between the BRT agency and other entities responsible for traffic management is necessary to arrive at a common set of criteria for managing signaling systems.\par
% @ guide/19-technology/194-signal-control.src: lines 5-12: code points 1-69

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/d2ee6ac0092f9518e8db636e4592c1041ea93a1b.jpeg}
		\fignote{9}{Signal control system.\label{chapter:technology:figure:signal-control-system}}{Sumitomo Electric.}
	}
\fi

\section{5}{Surveillance}
\label{volume:technology:chapter:technology:section:surveillance}
% @ guide/19-technology/195-surveillance.src: lines 3-24: code points 1-86

\quotation{There cannot be a crisis today; my schedule is already full.}{Henry Kissinger, diplomat and political scientist, 1923–}
% @ guide/19-technology/195-surveillance.src: lines 5-6: code points 1-58

Surveillance systems in and around stations, in vehicles, and at other facilities can improve personal security for BRT customers. Surveillance can also be used to enhance enforcement against busway violations and to detect blockage or incidents. Real-time footage can also help the CCC respond to surges in passenger demand. The most common ITS-related security technology is CCTV (closed-circuit television). Video surveillance systems typically consist of two components:\par
% @ guide/19-technology/195-surveillance.src: lines 8-12: code points 1-44

Video cameras and a recording and processing unit in buses and stations;\par
% @ guide/19-technology/195-surveillance.src: lines 14-14: code points 1-72

Control center system for display and logging of footage.\par
% @ guide/19-technology/195-surveillance.src: lines 16-16: code points 1-57

In the case of onboard surveillance, planners must determine whether the objective is only to log frame images to be viewed later or to allow for real-time viewing at the CCC. The latter requires high-speed communication connectivity for real-time data transfer. Although the image quality is low to moderate, it allows the CCC to assess what is occurring on the vehicle during an emergency situation. Online image transfer can be activated by the driver pushing an alarm button. For offline management, recordings are transmitted to the control center post-event, when the bus is in the depot or terminal. The images can be viewed on an as-needed basis (e.g., in case of reported incident, police request).\par
% @ guide/19-technology/195-surveillance.src: lines 18-24: code points 1-86

\section{6}{Management Information System}
\label{volume:technology:chapter:technology:section:management-information-system}
% @ guide/19-technology/196-management-information-system.src: lines 3-67: code points 1-50

\quotation{All of the biggest technological inventions created by man—the airplane, the automobile, the computer—says little about his intelligence, but speaks volumes about his laziness.}{Mark Kennedy, politician, 1957–}
% @ guide/19-technology/196-management-information-system.src: lines 5-6: code points 1-33

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/0dd019435ea730e2a39064d8dee56c8d8443b2b8.jpeg}
		\fignote{10}{The management information system.\label{chapter:technology:figure:the-management-information-system}}{ITDP.}
	}
\fi

The management information system (MIS) uses data from the AVM and fare collection systems to generate information to aid in optimizing planning and service. The information generated can support a wide range of planning, analysis, reporting, and administrative functions. This includes service planning, scheduling, resource optimization, performance, and contract management. The MIS helps identify loopholes and deficiencies in the system and make quick decisions to address any shortcomings.\par
% @ guide/19-technology/196-management-information-system.src: lines 10-14: code points 1-67

The IT service provider can develop a graphic dashboard that provides real-time output pertaining to bus operations and financial transactions. For example, the dashboard can have different modules and tab functions to show summaries of real-time passenger boarding at various stations, tickets issued, buses in operation, bus positions, and bus speeds. There can be many different types of output reports generated for personnel at different levels of management. The reports can be provided on a daily, weekly, and monthly basis.\par
% @ guide/19-technology/196-management-information-system.src: lines 16-21: code points 1-18

\ifxetex
	% disabled for now
\else
	{  % group required to avoid fignote settings escaping
		\img{\hsize}{technology/assets/820fd38038cade0b276ef81b985a153cc40a6375.jpeg}
		\fignote{11}{Example of a dashboard screen.\label{chapter:technology:figure:example-of-a-dashboard-screen}}{GPS Integrated.}
	}
\fi

\begin{itemize}
\item Bus operations reports can include the following:% @ guide/19-technology/196-management-information-system.src: lines 25-26: code points 1-0
\item Trip summary;% @ guide/19-technology/196-management-information-system.src: lines 26-27: code points 1-0
\item Bus equipment fault summary;% @ guide/19-technology/196-management-information-system.src: lines 27-28: code points 1-0
\item Bus service disruption, speed violations, unauthorized stoppage, vehicle breakdown, infrastructure damage, accidents, etc.;% @ guide/19-technology/196-management-information-system.src: lines 28-30: code points 1-0
\item Route summary (number of buses, kilometers operated, average speed, alerts summary, infractions, performance in comparison with previous weekly and monthly average);% @ guide/19-technology/196-management-information-system.src: lines 30-32: code points 1-0
\item Operations summary of individual bus (kilometers operated, hours in operations, average speed, alerts summary, infractions, performance in comparison route average over past week and month);% @ guide/19-technology/196-management-information-system.src: lines 32-34: code points 1-0
\item Summary of bus operations by depot;% @ guide/19-technology/196-management-information-system.src: lines 34-35: code points 1-0
\item Summary of bus operations by terminal;% @ guide/19-technology/196-management-information-system.src: lines 35-36: code points 1-0
\item Staff and duty schedule reports;% @ guide/19-technology/196-management-information-system.src: lines 36-37: code points 1-0
\item Financial reports.% @ guide/19-technology/196-management-information-system.src: lines 37-37: code points 1-24
\end{itemize}
% @ guide/19-technology/196-management-information-system.src: lines 25-37: code points 1-24

Staff duty and schedule reports are required to be maintained in order to comply with prevailing labor practices and plan for systems operations and management. Staff and duty reports can include:\par
% @ guide/19-technology/196-management-information-system.src: lines 39-40: code points 1-93

\begin{itemize}
\item Bus driver login reports;% @ guide/19-technology/196-management-information-system.src: lines 42-43: code points 1-0
\item Noncompliance issues of different drivers for the shift;% @ guide/19-technology/196-management-information-system.src: lines 43-44: code points 1-0
\item Bus operators supervision and maintenance staff login reports;% @ guide/19-technology/196-management-information-system.src: lines 44-45: code points 1-0
\item Asset management and materials inventory at depots and CCC;% @ guide/19-technology/196-management-information-system.src: lines 45-46: code points 1-0
\item Maintenance and supervision staff login reports;% @ guide/19-technology/196-management-information-system.src: lines 46-47: code points 1-0
\item Administration and CCC staff login reports;% @ guide/19-technology/196-management-information-system.src: lines 47-48: code points 1-0
\item All staff service hours and leave reports;% @ guide/19-technology/196-management-information-system.src: lines 48-49: code points 1-0
\item Reports on staff requirement, accumulations, benefits, perks, etc.;% @ guide/19-technology/196-management-information-system.src: lines 49-50: code points 1-0
\item Alerts to transport authority for duties towards staff like salary payments, leave approvals, material requirements, judgments and decisions, etc.;% @ guide/19-technology/196-management-information-system.src: lines 50-52: code points 1-0
\item Reports on violation of duty terms and conditions by staff.% @ guide/19-technology/196-management-information-system.src: lines 52-52: code points 1-65
\end{itemize}
% @ guide/19-technology/196-management-information-system.src: lines 42-52: code points 1-65

Financial reports can include the following:\par
% @ guide/19-technology/196-management-information-system.src: lines 54-54: code points 1-44

\begin{itemize}
\item Payment for journey by passengers by purchase of paper tickets or use of smart cards;% @ guide/19-technology/196-management-information-system.src: lines 56-57: code points 1-0
\item Payment toward purchase and recharge of a smart card;% @ guide/19-technology/196-management-information-system.src: lines 57-58: code points 1-0
\item Fines paid by passengers;% @ guide/19-technology/196-management-information-system.src: lines 58-59: code points 1-0
\item Daily cash collection at stations;% @ guide/19-technology/196-management-information-system.src: lines 59-60: code points 1-0
\item Payment to bus operator and different subcontractors like fuel pump attendants, etc.;% @ guide/19-technology/196-management-information-system.src: lines 60-61: code points 1-0
\item Payment to various service providers of the system like IT service provider, housekeeping agency, fare collection agency, other vendors supplying stationery and assets to transport authority, electricity and communication bills, etc.;% @ guide/19-technology/196-management-information-system.src: lines 61-64: code points 1-0
\item Payment for civil works and infrastructure construction and maintenance;% @ guide/19-technology/196-management-information-system.src: lines 64-65: code points 1-0
\item Payment to auditors;% @ guide/19-technology/196-management-information-system.src: lines 65-66: code points 1-0
\item Compensation to staff, passengers, and contractors;% @ guide/19-technology/196-management-information-system.src: lines 66-67: code points 1-0
\item All other administrative costs and payments.% @ guide/19-technology/196-management-information-system.src: lines 67-67: code points 1-50
\end{itemize}
% @ guide/19-technology/196-management-information-system.src: lines 56-67: code points 1-50

\section{7}{Planning and Implementation for IT Systems}
\label{volume:technology:chapter:technology:section:planning-and-implementation-for-it-systems}
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 3-38: code points 1-68

\quotation{All things are created twice; first mentally; then physically. The key to creativity is to begin with the end in mind, with a vision and a blue print of the desired result.}{Stephen Covey, author, 1932–2012}
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 5-6: code points 1-34

\subsection{1}{Feasibility Study}
\label{volume:technology:chapter:technology:section:planning-and-implementation-for-it-systems:subSection:feasibility-study}
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 8-38: code points 1-68

For any proposed IT investment, it is strongly recommended to carry out an in-depth feasibility study of the system to be implemented. The feasibility study is the opportunity to specify the functional requirements and objectives to be achieved. The feasibility study is also an opportunity for all internal and external stakeholders to understand the ITS and its long-term potential. The study must also define the milestones and expected outcomes at each stage of the end of implementation. It will also facilitate the planning and management of the implementation process, within the specified budget constraints and deadlines.\par
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 10-15: code points 1-100

The feasibility report should include the following components:\par
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 18-18: code points 1-63

\begin{itemize}
\item Context analysis: service typology and dimensions;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 20-21: code points 1-0
\item Identification of the actors involved;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 21-22: code points 1-0
\item Functional, technical, and operational specifications for each component and subsystem;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 22-23: code points 1-0
\item Technological infrastructure analysis, exiting network performance and coverage, and existing devices, software, and databases with which the IT system to be implemented will be integrated;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 23-25: code points 1-0
\item Implementation plan;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 25-26: code points 1-0
\item Maintenance process and related operational procedures;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 26-27: code points 1-0
\item Investment\slash{}operational costs and benefits;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 27-28: code points 1-0
\item Modalities for the purchasing of the system (service or direct investments), possible cofinancing sources;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 28-29: code points 1-0
\item Performance and quality gains, including ridership and revenue gains;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 29-30: code points 1-0
\item Data generation and ancillary system support;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 30-31: code points 1-0
\item Corporate capacity;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 31-32: code points 1-0
\item Risk assessment;% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 32-33: code points 1-0
\item Legal requirements of ITS solutions\slash{}technologies (i.e., communication technologies and related laws).% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 33-33: code points 1-107
\end{itemize}
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 20-33: code points 1-107

The feasibility study should enable the leaders\slash{}owners of the BRT agency to make a sound business decision on whether to proceed with the IT investment, with a reasonable understanding of the system capacity, anticipated benefits, investment and lifecycle costs, and implementation risks. It should provide the implementers with sufficient guidance to proceed to detailed design.\par
% @ guide/19-technology/197-planning-and-implementation-for-it-systems.src: lines 35-38: code points 1-68

\section{8}{Implementation Phasing}
\label{volume:technology:chapter:technology:section:implementation-phasing}
% @ guide/19-technology/198-implementation-phasing.src: lines 3-223: code points 1-61

\quotation{It is not always what we know or analyzed before we make a decision that makes it a great decision. It is what we do after we make the decision to implement and execute it that makes it a good decision.}{William Pollard, clergyman, 1828–93}
% @ guide/19-technology/198-implementation-phasing.src: lines 5-6: code points 1-37

Preparation of implementation schedule is very important in deployment of IT systems for BRT. The aim is to minimize the organizational\slash{}operational impacts, avoiding large-scale problems that frequently occur when complex systems are introduced in a single step. Each phase must be clearly identified through a milestone. The implementation phase should be defined on the basis of realistic timing and carefully estimated deadlines. This will help avoid common problems such as delays, contract-conflicting behavior of contractor, effort\slash{}resources required by contracting body\slash{}transport operator, etc. The definition of a step-by-step implementation plan and the setup of related milestones facilitates the management of penalties due to delays during the implementation (sign-off of each phase, positive results of the testing procedure, final acceptance, etc.).\par
% @ guide/19-technology/198-implementation-phasing.src: lines 8-16: code points 1-43

The plan can be made by consultants\slash{}advisers to the transport authority jointly seeking inputs from the authority. The plan should highlight important milestones to be achieved, deadlines, time frame for implementation including resource mobilization, equipment procurement, demo and testing, actual fitments, staff hiring, etc. The preparation of pre-implementation plan facilitates transport authorities to know well in advance about budget requirements and the time span that will be required by the service provider to commence system operations. It helps transport authorities plan for and allocate their monetary and manpower resources accordingly.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 18-24: code points 1-31

Project-management tools should be used, with detailed time line and resource tracking and analysis, manpower allocation of tasks, milestones, dependency analysis, critical path analysis, responsibility assignment, etc. The initial planning should commence during the detailed design phase, so that there is a clear vision of how the ITS deployment will be achieved. This will ensure that adequate resources have been mobilized, responsibilities are clear, and potential barriers have been foreseen and mitigated. The plan should be comprehensive and cover all aspects of the ITS deployment through to installation, testing\slash{}commissioning, sign-off, and the initial operational period.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 26-32: code points 1-68

\subsection{1}{Tendering}
\label{volume:technology:chapter:technology:section:implementation-phasing:subSection:tendering}
% @ guide/19-technology/198-implementation-phasing.src: lines 34-142: code points 1-9

At a general level, the main objective of the procurement process is to select a supplier whose proposal complies with the technical objectives and requirements determined by the implementing agency, and offers the lowest cost among the bidders. The overall tendering procedure should be defined so that the financial factor only comes into play among the bidders whose proposals are acceptable in technical terms. Various tendering schemes are available to achieve this objective. A typical tendering procedure includes the following steps:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 36-42: code points 1-0

\begin{enumerate}
\item Tender specifications;% @ guide/19-technology/198-implementation-phasing.src: lines 42-43: code points 1-0
\item Invitation to tender (which may follow from prequalification);% @ guide/19-technology/198-implementation-phasing.src: lines 43-44: code points 1-0
\item Pre-bid meeting;% @ guide/19-technology/198-implementation-phasing.src: lines 44-45: code points 1-0
\item Proposal application and evaluation;% @ guide/19-technology/198-implementation-phasing.src: lines 45-46: code points 1-0
\item Negotiation and contracting.% @ guide/19-technology/198-implementation-phasing.src: lines 46-46: code points 1-36
\end{enumerate}
% @ guide/19-technology/198-implementation-phasing.src: lines 42-46: code points 1-36

The tender specifications must clearly identify the systems\slash{}tools (hardware, software) and the support services in order to allow bidders to define the price. The overall cost estimation should include not only the cost of the technology (individual hardware and software components), but also the costs related to the operation and support services (e.g., total days for the installation in different depots, meeting with contractors, resources necessary for detailed design, management, etc.).\par
% @ guide/19-technology/198-implementation-phasing.src: lines 48-52: code points 1-77

The following are key articles of tendering prescriptions and contractual rules:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 54-54: code points 1-80

\begin{itemize}
\item Award criteria (technical and financial qualification criteria, experience). The mutual relevance between technical and financial criteria must be defined in such a way to preserve the technical value of the proposal. The most common approach is to require bidders to submit the financial proposal in a separately sealed envelope. The technical proposal is evaluated first, and only proposals with a satisfactory technical score (or which are deemed to be compliant) proceed to the stage of financial assessment. There are various ways to define evaluation criteria and related calculation formula. The options usually relate to the relevance the Client should assign to the criteria. Factors used as technical criteria are: technical quality of the proposal, quality of the maintenance service, description of the implementation modalities, technical assistance for the start up of the system, technical documentation, etc.;% @ guide/19-technology/198-implementation-phasing.src: lines 56-65: code points 1-0
\item Warranties. Warranties can be of different form and objective: requirement for the eligibility of the offer, for the compliance of the implementation to technical specifications and contract rules, for the compliance of services and prescriptions after the implementation is completed (in case also the operation of system\slash{}service is contracted). The tender should oblige the bidder to provide unlimited software licenses. Unlimited software licenses means not only that the licenses are not time limited, but also that no extra costs will occur in case of the license up-scaling (e.g., increase of vehicles connected to the AVM, of equipped depots for data upload and download, etc.). The tender documentation should require bidders to declare\slash{}list the cost of each device, component, or services (onboard terminal, onboard unit, gate, contact\slash{}contactless reader, training day, etc.). It should also require that the contractor is obliged to maintain these prices for a specified time period (e.g., five years in case of up-scaling of some system components);% @ guide/19-technology/198-implementation-phasing.src: lines 65-76: code points 1-0
\item Technical specifications and annexure. Technical specifications of products required and annexure are based on the main results of a feasibility analysis. It is recommended to focus on functionalities and operative requirements rather than technology solutions and technical features of each component. Functional specifications should be described in terms of “operational scenarios.” This provides the bidder with sufficient freedom to propose the most effective solution, while still meeting the client requirements. The specifications should not include technical conditions or requirements that could be seen as a restriction of open competition, or that give an unfair advantage to a specific bidder. Restriction on competition could occur if the tender specifies the use of a specific type of equipment, or a specific piece of software, even though other makes could equally do the job. It is reasonable to state a preference for something if it is already in widespread use in the organization, but it is not reasonable to make it mandatory if there is no technical barrier to alternatives. Sometimes, integration is required between a proposed system and an already existing system. In this case, the previous supplier will have strong advantage of thorough understanding of the existing system and knowledge of the amount of work involved in the integration. To overcome this, the tender process should provide all the information about existing system including system description, functionality, data elements, etc. The technical specifications part of the bid document should mention in general the requirements of the system, of various gadgets and compulsion of certified standards. The annexure section should provide bidders with all the required formats for bid submission like cover letter, price bid, declaration form, power of attorney, etc.;% @ guide/19-technology/198-implementation-phasing.src: lines 76-94: code points 1-0
\item Implementation timeline. This should include milestones and corresponding payments;% @ guide/19-technology/198-implementation-phasing.src: lines 94-95: code points 1-0
\item Service level benchmarks and service provider obligations. This should include penalties for inadequate performance and procedures for conflict resolution.% @ guide/19-technology/198-implementation-phasing.src: lines 95-96: code points 1-51
\end{itemize}
% @ guide/19-technology/198-implementation-phasing.src: lines 56-96: code points 1-51

As a standard practice, the bid submission process should follow a two-cover system: one sealed cover with technical bid and the other with financial bid. To perform the evaluation phase of the technical part of the bid proposals, an iterative methodology can be used. The evaluation is based on the repeated identification of the evaluation factors (at N+1 level) that contribute to the evaluation of each criteria\slash{}sub criteria (at N level) according to the weighted factors. This methodology is applied starting from the bottom level of criteria or sub-criteria defined in the tendering documentation, up to the level that is considered appropriate. One example of this methodology is based on a scoring system. The bidder must score minimum marks as specified in technical capability criteria. Sample criteria and their corresponding weights are presented in Table 19.6.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 98-106: code points 1-36

\tabletitle{6}{Technical Criteria for the Bidding Process}
\label{chapter:technology:table:technical-criteria-for-the-bidding-process}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=24\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\cr
	\color{gray75}\bfseries Criteria& \color{gray75}\bfseries Points \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}The number of projects for smart card-based AFC solutions to be used in bus\slash{}rail-based public transport services, implemented in the past seven years and the cost for each project should be more than \_\_\_ USD. 20 Points for each project subject to a maximum of 100 points.&
	\color{gray50}100\cr
	\noalign{\vskip 2mm 
}	\color{gray50}1. Number of AFC smart card clearinghouse solutions delivered in the past seven years by the bidder that clear and settle revenue between multiple independent transit operations operating various modes of transport systems; and\slash{}or; 2. Service providers that manage AFC infrastructure, implemented in the past seven years.;&
	\color{gray50}50\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Vehicle tracing\slash{}PIS display\slash{}AFC system\slash{}vehicle dispatching and scheduling\slash{}depot management system&
	\color{gray50}150\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Overseas Experience:; International experience of projects costing more than one million US dollars (10 points for each project subject to a maximum of 50 points);&
	\color{gray50}50\cr
	\noalign{\vskip 2mm 
}	\color{gray50}CVs of the key professionals (employees or full-time consultant)&
	\color{gray50}50\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Quality System Certification&
	\color{gray50}50\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Number of Projects for which at least 50 Units of Turnstiles\slash{}Flap Gates supplied\slash{}commissioned in Public Transit System during the last three years from the due date of tender. (Per Project—10 Points up to maximum of 5 Project)&
	\color{gray50}50\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Project execution methodology (to be judged through a write-up of not more than 5,000 words and presentation)&
	\color{gray50}200\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Total Marks&
	\color{gray50}700\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Minimum Qualifying Marks Required&
	\color{gray50}490\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/198-implementation-phasing.src: lines 108-142: code points 1-9

\subsection{2}{Implementation Oversight}
\label{volume:technology:chapter:technology:section:implementation-phasing:subSection:implementation-oversight}
% @ guide/19-technology/198-implementation-phasing.src: lines 144-212: code points 1-29

Each and every step of implementation has to be carefully planned, supervised, and monitored. An IT deployment team should be established at an early stage, and ideally at least some of its members should be involved in the functional specification and detailed design phases. This is necessary to ensure that they have a deep understanding of what the IT system should achieve and how it is intended to work. Building relevant expertise and capacity of this team can be achieved by:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 146-150: code points 1-64

\begin{itemize}
\item Engaging consultants and technical experts for roles such as project management, system integration, design verification, system and component testing, system commissioning, supplier interface;% @ guide/19-technology/198-implementation-phasing.src: lines 152-154: code points 1-0
\item Bringing in IT and software specialists who have experience with complex IT projects and system integration (not necessarily in the ITS or even transportation domain);% @ guide/19-technology/198-implementation-phasing.src: lines 154-156: code points 1-0
\item Partnering with cities and\slash{}or transport operators who have ITS system experience, and who are willing to act as mentors and perhaps provide some of their staff on a support basis or temporary reassignment;% @ guide/19-technology/198-implementation-phasing.src: lines 156-158: code points 1-0
\item Organizing study tours for the team at places where such systems are already successfully functional;% @ guide/19-technology/198-implementation-phasing.src: lines 158-159: code points 1-0
\item Enrolling a third party as a project management consultant with expertise in sector.% @ guide/19-technology/198-implementation-phasing.src: lines 159-159: code points 1-90
\end{itemize}
% @ guide/19-technology/198-implementation-phasing.src: lines 152-159: code points 1-90

The team may be built up as deployment approaches, gradually bringing in people from the units that will utilize the ITS functions, and from support functions that will be involved in the installation and commissioning (e.g., maintenance section, IT department). The team should have members with different skills and professional backgrounds in order to cover all the required domains (technical, financial, operative, management, etc.). Capacity building is essential and needs to be carefully planned and adequately resourced. This will include core skill training, up-skilling, and training and skill transfer by suppliers.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 161-166: code points 1-108

The testing procedure takes place at the end of each implementation phase (milestone) and at the end of the realization (for final acceptance of the whole system). The testing of the results of each phase (both intermediate and final) is organized into three different levels:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 168-170: code points 1-71

\begin{itemize}
\item Quantitative and technical congruency of system supply and components;% @ guide/19-technology/198-implementation-phasing.src: lines 172-173: code points 1-0
\item Functional test (base\slash{}core functions, other functions);% @ guide/19-technology/198-implementation-phasing.src: lines 173-174: code points 1-0
\item Performance test.% @ guide/19-technology/198-implementation-phasing.src: lines 174-174: code points 1-23
\end{itemize}
% @ guide/19-technology/198-implementation-phasing.src: lines 172-174: code points 1-23

The testing procedures should be devised and agreed with the supplier(s), and conducted either in-house or by an independent firm with the relevant expertise. The conformance of the system is based on the following verifications:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 176-178: code points 1-24

\begin{itemize}
\item Actual number of installed components;% @ guide/19-technology/198-implementation-phasing.src: lines 180-181: code points 1-0
\item Technical and operational conformity of installation activities;% @ guide/19-technology/198-implementation-phasing.src: lines 181-182: code points 1-0
\item Presence of software licenses;% @ guide/19-technology/198-implementation-phasing.src: lines 182-183: code points 1-0
\item Technical documents and manuals included in the object of the contract.% @ guide/19-technology/198-implementation-phasing.src: lines 183-183: code points 1-77
\end{itemize}
% @ guide/19-technology/198-implementation-phasing.src: lines 180-183: code points 1-77

Functional tests measure the level of responsiveness of functions to contractual specifications: they can be divided in tests of a single subsystem and of the whole system. Each functionality must be tested under a wide range of operational conditions. Functional tests prove that the function complies with specification (during the specified test). Performance tests measure how long the system is able to provide the functionality properly over a certain time period or number of tests. The positive verification of each milestone (phase) testing leads to the processing of related payment. If not all the results of the testing are positive the contracting authority can decide if:\par
% @ guide/19-technology/198-implementation-phasing.src: lines 185-191: code points 1-65

\begin{itemize}
\item The test should be entirely repeated and the implementation activities\slash{}installation of the next phase should be stopped (waiting for positive verification of repeated tests). In this case no payment will be processed—this situation implies major incompliance from the supplier side and the presence of critical factors impeding the work progress;% @ guide/19-technology/198-implementation-phasing.src: lines 193-197: code points 1-0
\item The test should be partly repeated, the system functionalities and performances are such to go on with the implementation activities\slash{}installation for next phase. A percentage of the payment will be transferred to the supplier, and the remaining quota will be paid too when current problems are solved—in these situations incompliance is less significant and has no impact on the following stages of work.% @ guide/19-technology/198-implementation-phasing.src: lines 197-200: code points 1-83
\end{itemize}
% @ guide/19-technology/198-implementation-phasing.src: lines 193-200: code points 1-83

The supply and installation of components does not imply that these components are operated by the transport companies (or accepted by the contracting body). It is normal to have a period of live operation and debugging: even more the start-up and operation of the system is mandatory to allow the overall IT system(s) to be tested in live conditions in order to detect problems that were not apparent in the testing of the individual units. The positive results of the phase test regulates the payments but they do not mean the final acceptance of the testing: all hardware and software products should not be accepted until they have passed the final testing where each component and subsystem will be tested as part of the comprehensive system. The guarantee should commence its period from the date of final acceptance of the system (positive acceptance tests). The reference date for the guarantee should not become the date of the installation of each component, or its initial testing. Project personnel need to be cautioned on what they sign off on at various testing phases.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 202-212: code points 1-29

\subsection{3}{Pilot Demonstration}
\label{volume:technology:chapter:technology:section:implementation-phasing:subSection:pilot-demonstration}
% @ guide/19-technology/198-implementation-phasing.src: lines 214-223: code points 1-61

A pilot demonstration will help identify and solve problems before the overall system comes online. The subsequent phases are managed as “extensions” of the components and consolidation of functionalities. Payments should be scheduled according to each implementation milestone in terms of the percentage of the total price. Each payment would be carried out after the successful test planned for each phase. The last payment (i.e., 10 percent of the total) should be linked to the successful final testing (acceptance) of the overall system and to the proven compliance with all the contract obligations. Value and timing of the payments will assure adequate cash flow for the provider (especially in the first phase of the implementation), without leaving the BRT agency overexposed.\par
% @ guide/19-technology/198-implementation-phasing.src: lines 216-223: code points 1-61

\section{9}{Monitoring and Evaluation}
\label{volume:technology:chapter:technology:section:monitoring-and-evaluation}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 3-59: code points 1-61

\quotation{A truthful evaluation of yourself gives feedback for growth and success.}{Brenda Johnson Padgitt, author, 1970–}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 5-6: code points 1-39

Continuous monitoring of the IT deployment is required to ensure that the bidder adheres to prescribed quality and standards and provides the materials that are agreed as per contract. Monitoring and evaluation can be jointly carried out by the IT team and project management firm as a third party inspection. In order to ensure that the service provider adheres to required service standards and delivers quality output, the implementing agency should select performance indicators and include corresponding benchmarks in the IT operator contract(s). Some examples of performance indicators and desired service levels are presented in Table 19.7. For a full description of performance indicators, see the World Bank’s document, “ITS Toolkit for Intelligent Transport Systems (ITS) for urban passenger transport”.\par
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 8-16: code points 1-21

\tabletitle{7}{Sample Performance Indicators and Benchmarks}
\label{chapter:technology:table:sample-performance-indicators-and-benchmarks}
\halign to 30\tablemodule{%
	\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=6\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\hbox to 0.5\tablemodule{}&
	\hbox to 0.5\tablemodule{}\vtop{\sffamily\footnotesize\noindent\hsize=5\tablemodule#}\cr
	\color{gray75}\bfseries Service& \color{gray75}\bfseries Parameter& \color{gray75}\bfseries Desired Service Level& \color{gray75}\bfseries Metric& \color{gray75}\bfseries Penalty \cr
	\noalign{\vskip 1mm} \hline \noalign{\vskip 2mm} 
	\color{gray50}Project; Management;&
	\color{gray50}Submission of reports&
	\color{gray50}100\%&
	\color{gray50}Minutes of meetings&
	\color{gray50}2\% of monthly CCC charges for every default\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Data Center Operations&
	\color{gray50}MIS reporting of health checkup of all; systems and modules; installed;&
	\color{gray50}95\%&
	\color{gray50}Report&
	\color{gray50}0.2 \% of monthly charges\cr
	\noalign{\vskip 2mm 
}	\color{gray50}Incident \& Management&
	\color{gray50}Resolution of ticket logged in incident; management tool&
	\color{gray50}99\%&
	\color{gray50}Reports generated from ticket logging system&
	\color{gray50}0.5\% of monthly charges\cr
	\noalign{\vskip 2mm 
}}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 19-44: code points 1-9

\subsection{1}{Additional References}
\label{volume:technology:chapter:technology:section:monitoring-and-evaluation:subSection:additional-references}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 46-59: code points 1-61

Several bodies have worked toward creating standards for IT systems:\par
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 48-49: code points 1-0

\begin{itemize}
\item In the USA, the National ITS Architecture is published at . This website also contains detailed technical information and guidance on how to use it;% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 49-51: code points 1-0
\item In Europe, the ITS System Architecture is called FRAME (http:\slash{}\slash{}www.frame-online.net\slash{}node\slash{}38).% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 51-51: code points 1-99
\end{itemize}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 49-51: code points 1-99

Communication protocols:\par
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 53-54: code points 1-0

\begin{itemize}
\item TPEG for transmission of language independent multimodal travel and traffic information systems, from the format\slash{}technical solution to exchange data;% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 54-56: code points 1-0
\item DATEX\slash{}DATEXII for traffic data, RDS-TMC over radio communication;% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 56-57: code points 1-0
\item SIRI in the domain of public transport;% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 57-58: code points 1-0
\item WFS\slash{}WMS specifications, xml protocol, etc.;% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 58-59: code points 1-0
\item Location referencing (AGORA-C, OpenGIS standard, etc.).% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 59-59: code points 1-61
\end{itemize}
% @ guide/19-technology/199-monitoring-and-evaluation.src: lines 54-59: code points 1-61

