REVISED CLOSING DATE: JANUARY 23, 2017 12:00 …...Toronto, Ontario M5H 2N2 Elena Caruso, Manager Goods and Services December 23, 2016 Via Internet Posting (4 pages + attachment) ADDENDUM

Michael Pacholok Director

Purchasing and Materials Management Division City Hall, 17th Floor, West Tower 100 Queen Street West Toronto, Ontario M5H 2N2

Elena Caruso, Manager Goods and Services

December 23, 2016

Via Internet Posting (4 pages + attachment)

ADDENDUM NO. 1

REQUEST FOR PROPOSAL NO. 2110-16-3160

CLOSING DATE: JANUARY 9, 2017

For: Telematics Solution for municipal vehicle fleet

(Two-Envelope System)

REVISED CLOSING DATE: JANUARY 23, 2017

12:00 O'CLOCK (NOON) LOCAL TORONTO TIME

I. QUESTIONS & ANSWERS:

Q1. Questions related to item in Page 5

The city has made significant investment in Telematics hardware and the proposed Telematics

Solution will need to interoperate with the existing Telematics currently employed by the city.

a) Does the City have the rights, authorization, and source code from the current Hardware

supplier to be able to meet this demand?

b) Will the City consider an offer that requires new hardware, if current hardware is not

compatible?

c) Does the City want to purchase or rent new hardware?

A1.

a) The City does not have the rights, authorization, or source code from the current hardware supplier. The investment in the existing hardware needs to be preserved, so interoperability with the existing hardware or other business model options need to be provided.

b) The City will consider any solution that meets the City's need to preserve its investment in existing hardware where installed in existing vehicles.

c) The City prefers to purchase the hardware. Please refer to the pricing form in Appendix D of the RFP.

Q2.

Throughout the RFP, it is mentioned that there is telematics hardware in the trucks and the

City is not in a position to purchase new hardware. But then below that it lists

requirements for telematics hardware as well as a few line items in the forms price out new

hardware.

a) Are you looking for a system that includes new hardware or not?

b) You 100% require a system that integrates in with BSM?

2

A2.

a) The City's needs to preserve its investment in existing hardware where installed in existing vehicles. The RFP requirements for the Telematics hardware and references in the price form are included for new hardware the City may purchase for existing vehicles which currently do not have any Telematics or for new vehicles as a part of our vehicle replacement program.

b) The investment in the existing hardware needs to be preserved, so interoperability with the existing hardware or other business model options need to be provided.

Q3. Question Related to item in Page 12

A copy of the City's existing telematics hardware and vehicle deployment is provided for in

Appendix G – City Telematics Inventory.

a) The RFP makes reference to Appendix G. There was a spreadsheet that was included in the

documents released. Is that Appendix G?

b) Will the City provide additional information re: the Existing Telematics Hardware?

A3.

a) The Excel spreadsheet included in the documents released is Appendix G and provides the City's vehicle inventory. This provides the vehicle attributes for reference purposes.

b) The City is not providing any additional information on the existing Telematics hardware. Q4. Question Related to item in Page 71

The City will own all intellectual property rights, including (without limitation) copyright, in and to

all deliverables provided by the Vendor and its subcontractors

a) Our application is protected with property rights and copyrighted

Can the City clarify its position on this point?

A4.

a) This language refers to specific project related deliverables for which the City might engage and pay the Vendor – an example would be a customized report that the Vendor develops for the City using the Vendor's professional services. The Telematics data and information for the City's vehicles provided to the City belong to the City. The City does not require ownership of intellectual property in any of the Vendor's applications.

Q5.

Given the holiday season is upon us and many people will be on vacation, would the City

consider providing everyone a 3 week extension for delivery of the RFP response? This will

allow all participants to put forward higher quality responses for the City’s consideration.

A5.

The City is extending the deadline for the delivery of the RFP response to 12:00 noon (local Toronto time) on January 23, 2017.

Q6.

Would the City of Toronto consider an extension of the RFP because of the upcoming

holiday season?

A6. Please refer to A5.

3

Q7.

The pdf for the requirements is a password protected and doesn’t allow to convert to word,

is it possible to have a word copy for ease of response, if not is it possible to permit copy

and paste option?

A7. The City will not provide the entire RFP requirements in a Word document. The tables in Schedules

1 and 2 that the Proponents are required to fill out and submit along with their Proposal will be provided in an Excel document allowing the Proponents to complete the unlocked cells.

Q8.

After reviewing the documents contained in the RFP package it’s unclear to us how many

current vehicles have telematics devices installed and how many vehicles require new

telematics devices. Can you clarify how many basic and advanced units are currently using

the VIB? Can you confirm the total number of vehicles (new and existing) to be included in

the RFP?

A8.

The estimated quantities for vehicles with existing and potential Telematics units is provided in Table 1 of the RFP. For the pricing form the unit information is prepopulated. To clarify, there is no relationship between the VIB units and the Telematics units. The City uses the VIB technology for automated authorization for fuel dispensing and for automated vehicle meter readings at the time of fuel dispensing. The current use and requirements for Telematics are shown in Table 1 of the RFP.

Q9.

Also can you clarify that if a vendor was able to offer a replacement device at no cost for

existing VIB that the City of Toronto would be open to replacing the existing VIB?

A9.

The RFP is for Telematics only. To clarify, there is no relationship between the VIB units and Telematics units. The City is not open to replacing the existing VIBs.

Q10.

Can you explain how the City formulated the Estimated Unit Annual Quantity in Table 1 of

the Appendix D – Price Form? Item No. 1-6 seem to be a multiplication of the number of

vehicles times the number of months? The numbers don’t breakdown clearly though.

A10.

The City has multiplied the number of units by the applicable number of months to obtain the quantity.

II. REVISIONS:

Please refer to the Request for Proposal (RFP) document in your possession and be advised of the following: R1. The following replaces Section 4.4 Schedule of Events in the RFP:

RFP Issue Date: December 9, 2016 Voluntary Proponent Meeting: December 16, 2016 Deadline for Proponent questions: January 11, 2017 Last Day for issuing an Addendum (if required): January 16, 2017 RFP closing date (12:00 noon local Toronto time): January 23, 2017 Date evaluation expected to complete: February 17, 2017 Approval and award date: April 2017

4

Contract start date: May 2017

R2. Section 7 aa) on page 11 will be amended to read as follows:

aa) In-Cab camera system for both inward facing and roadway facing to obtain more accurate accident reconstruction and account and driver actions in case of such an event. The City's goal is to implement video based driver risk management in order to provide coaching and training for its drivers. A camera system provides the opportunity for driver behaviour modification along with providing the recorded events. The Proponent's service needs to include screening and flagging of events and occurrences based on the City's standards.

R3. Schedule 1, Table N, Number 100 on page 50 will be amended to read as follows:

The Proponent's In-Cab Camera System allows for video based driver risk management for driver coaching and training. The Proponent provides screening and flagging of events and occurrences based on the City's standards. The Proponent's In-Cab Camera System provides vehicle location and engine related (speed, harsh braking, etc.) information, video data and location in the event of an accident in order to improve the reconstruction of an accident to provide driver coaching.

R4. Schedule 2, Definitions – "Response" on page 54 will be amended to read as follows:

“Response” means a callback by a qualified support specialist for the purpose of resolving a Defect after the customer provides a Support Request to Vendor.

R5. Schedule 2, Priority Levels, b) on page 56 will be amended to read as follows:

b) Priority 2 (P2) or MAJOR DEFECT: means a significant, but not immediately critical, part of the Solution is unusable, creating some business impact. Examples of Major Defects include but are not limited to:

Users are unable to access offerings of the Solution where no alternative methods

of access are available; The Solution is interrupted and there is a risk of recurrence. There may be a

significant impact on City's ability to do business or other evidence of performance degradation or intermittent failure and interruptions; and

An issue that is likely to become a P1 if not resolved within Defect Resolution targets.

All other terms and conditions remain the same. Please attach this addendum and the completed Microsoft Excel worksheet to your Request for Proposal document as it will be included as part of your proposal and will be governed accordingly. NOTE: Proponents are reminded that they are required to acknowledge all addenda in the spaces

provided on the Proposal Submission Form 1 or your proposal will be declared non-compliant.

Should you have any questions regarding this addendum, please contact Supervisor, Robert Babin at (416) 392-7178 or by e-mail at [email protected]

Sincerely, Robert Babin, Supervisor Purchasing, Goods and Services II

mailto:[email protected]

Addendum No.1 - Dec.23, 2016

1. Basic Telematics (Tables A – M)

2. Advanced Telematics (Tables A – M)

3. Asset tracking Telematics (Tables A – M)

4. Portable Telematics (Tables A – M)

5. In-cab camera system including driver mentoring and basic Telematics (Table N)

6. CVOR compliance solution (Table O)

7. Driver behaviour and safety (Table P)

Table A: Telematics General Yes (X) No (X) Comments (if any)Proposal Page

No.

1

The proposed Solution has a proven history of successful operation with municipal applications

such as, but not limited to: Fire Services (Support vehicles), Parks, Forestry & Recreation (pickup

trucks, riding mowers), Transportation Services (line painting, sweepers, salt spreading, snow

ploughing), Solid Waste Management (refuse trucks, litter vacuums), Transit (cars, pickups, vans)

and Water and Wastewater (cars, sewer vacuum trucks).

2

The Solution operates in field conditions experienced in the daily operation of all City of Toronto

fleet vehicles & equipment such as mechanical sweepers, salt spreaders, sidewalk ploughs,

loaders, patrol, field investigators, refuse trucks, litter vacuums, ambulances, riding mowers,

pickups, vans, sedans, etc.

3The equipment can operate in temperatures ranging from -25

o C to +50

o C and operating humidity

up to 95%

4The Telematics unit is mounted securely inside the vehicle’s cab. The Solution operates on vehicle

electric power (12V or 24V).

5The Telematics unit is designed to go into sleep mode with minimal current draw (i.e., 5mA or

less) so as not to damage or drain the vehicle battery.

6The antenna is suitable for all equipment mounting (i.e. permanent or magnetic mount) and a

suitable tamper proof cable in varying lengths is provided.

7The proposed Solution is able to interface to on-board discrete sensor inputs and 3

rd party data

logging systems.

Schedule 1 Tables

Business and Functional Requirements

Proponent needs to indicate a Yes or No answer and provide comments if any as well as the Proposal Page number in the columns provided in the table below. Either column for "Yes"

or the column for "No" must be filled out with an "X" for marks to be assigned for evaluation purposes.


8

The overall Solution is capable of tracking, storing and reporting the movements and actions of a

fleet of various vehicle types e.g. sedans, hybrid sedans, SUVs, pickups, vans, class 4 – 8 trucks,

litter vacuums, etc. in real-time. Collection of data includes all GPS, sensor and engine data

required by the City and being collected by the Telematics unit.

Data transmission rate is configurable. Some vehicles will require real-time reporting (every 1, 5,

10, 30 seconds, 1 minute) while others will require less frequent updates (3 minutes, 5 minutes) or

on-demand (i.e., for trailers, generators, air compressors, etc.).

Solution should have the ability to report on event changes and distance or a combination thereof.

10Event reporting includes turn by turn reporting (i.e. 15 degree change in directional heading causes

GPS data to be sent and this allows ramps and other infrastructure to be covered).

11 Positional accuracy is within industry standard (i.e., less than 2.5 meters.)

12The GPS receiver is able to track coarse acquisition code and link one frequency on at least 16

parallel continuous tracking channels with an update rate to be once per second.

13Time to first fix is 25 seconds or less for a cold start and warm start and 1 second for a hot start for

reacquisition after losing GPS signal.

14The Solution has a dead reckoning option or other means of aiding GPS information when GPS

coverage is poor or unavailable in cases such as a vehicle indoors or underground.

15The Solution is compatible with the City of Toronto’s IT environment: Windows and Explorer

latest version(s).

16The Solution allows for future enhancements that can allow for easy configuration, expansion and

scalability.

17 The Proponent has a Disaster Recovery Plan for business continuity for the City.

9


Table B: Configuration /Administration/ Security Yes (X) No (X) Comments (if any)Proposal Page

No.

18Solution provides Telematics information to a user only after authorization and authentication of

employee (system user) is completed.

19The user interface presents those vehicles and permissions about which the user has authorization

to know the location and status information i.e., partitioned on a Division or work group basis.

20Multiple authorized users are able to access the information simultaneously from multiple

locations.

21Each vehicle in the Solution and on the map can be given a unique identifier as determined by the

City e.g. unit number.

22

User permission level is done in the Solution and user privileges are based on assigned username

and password. System will allow modification of the number of vehicles to be monitored, sensors

to be monitored and monitor characteristics. User access levels is configurable for type of user

role (i.e. administrator, management, customer service/dispatch).

23All data collected and data transferred is encrypted and secured from unauthorized access and be

in accordance with the City of Toronto Corporate Security Policies.

24 The list of authorized users as determined by the City is accommodated.

25 There will be no additional fees for setup or removal of users.


Table C: Hardware/Firmware/Middleware Yes (X) No (X) Comments (if any)Proposal Page

No.

The Proponent offers a wide variety of Telematics units to meet simple tracking requirements

and/or complex system integrations.

This is to accommodate the various requirements for the wide range of fleet assets operated by the

City and its contractors.

27

All wireless hardware meets Industry Canada radio frequency standards for wireless devices and is

not known to cause any health or safety concerns and is certified on the cellular network by the

cellular carrier.

28

Basic Telematics unit:

Simple Tracking unit has a minimum be able to interface up to five (5) digital sensor inputs, two

(2) dedicated outputs, one (1) USB port and CANBus connection.

29Asset tracking Telematics unit:

Capable of one to two transmissions per day to locate assets such as generators, snow melters, etc.

30Portable tracking Telematics unit:

For use in vehicles and equipment with high turnover e.g. vehicles in a rental program.

31

Advanced Telematics unit (with on-board systems integration functionality):

Telematics control unit is able to interface with up to ten (10) digital sensor inputs, four (4) analog

to digital inputs, four (4) dedicated outputs and three (3) serial communication ports for third-party

on-board machinery.

32 The Telematics unit is capable of remote configuration and one (1) second reporting intervals.

Vehicle remote configuration is web browser-based, which is capable of logging into the

Telematics unit to:

- Set distance and time reporting intervals

- Set destinations for data communications

- Sensor status changes and expansion of devices

34Firmware is remotely upgradeable over-the-air (OTA) via wireless network from a central

location.

35

Firmware has reporting capability on degrees (bearings): meaning the reporting frequency can be

every 100 meters, 5 seconds, and 15 degrees of bearing change. This provides coverage for areas

such as on and off ramps and short street segments.

36 USB input provides connectivity to any on-board USB device.

37Advanced Telematics unit is equipped with an on-board Operating System with a Web Server

Platform, hard drive supports a minimum 2GB storage.

26

33


Wireless data transmission is provided through commercial wireless data services by a licensed

and certified Wireless Telecommunications Provider servicing the GTA and surrounding areas.

Where multiple equipment and/or wireless data networks are available, the vendor chooses the

equipment and/or network that will supply the highest reporting frequency between transmissions

sent from the on-board equipment to the database system at equal or lesser costs to the City. The

City's preferred commercial carriers are Telus Mobility - EVDO/HSPA, Rogers Wireless -

EDGE/HSPA and Bell Mobility EVDO/HSPA.

All data transmission and data storage ensures the integrity and security of all data. All solutions

incorporate adequate security measures to ensure that no foreign or substitute data can be injected

into any communications and that all data can be identified and validated as only coming an

authorized device.

38


Table D: Live Data Yes (X) No (X) Comments (if any)Proposal Page

No.

39

Store and forward capability: The Solution is able to store at a minimum 1,000 records of GPS and

Telematics data when the cellular signal is weak or lost and sent when the cellular connection is

regained.

The Solution is able to interface to control systems such as:

· CompuSpread CS230, CS440 & CS550

· Dickey John Control Point & Flex 4

· Epoke

· Cirus

· Force America SSC5100 & 5100ex

· Roadwatch

· Controlpoint temperature sensors

· Linetech paintguns.

The Solution allows viewing of a vehicle in motion leaving tracks or “breadcrumbs” as it travels

with arrow indicators for direction and showing all operations (GPS & sensor services data) as

they occur including exact street location.

The Solution allows users to view the above mentioned data for their entire fleet or select a

specific vehicle(s) for a login session using a filter tool.

42The Solution is able to use warning indicators that activate when the vehicle is not in motion for a

set time period.

43The Solution is able to provide real time exception reporting capabilities to immediately send

customizable exception parameters via an email

44In addition to live data, the Solution is able to download data to pre-determined WIFI areas set up

by the City e.g., fuel sites.

45The Solution has the ability to present vehicle types using both unique icons and colours to be

determined by the user.

46 The Solution has a screen refresh rate of no greater than ten (10) seconds.

40

41


Table E: Telematics and Sensor Services Yes (X) No (X) Comments (if any)Proposal Page

No.

47The Solution is able to provide each data packet from the Telematics unit and at a minimum

contain all GPS data, Telematics data captured from the vehicle, and sensor data.

48 The Solution is able to send the collected data automatically to a data centre within Canada.

49

The Solution is able to provide functionality for additional integration capabilities to on-board

discrete sensory interfaces and 3rd

party data logging system through RS232, USB, and/or RJ45

latest SAE port connections.

The Solution is able integrate through OBDII and/or CANBUS with discrete sensors such as, but

not be limited to:

· M5-Fuel Focus

· Compactor on/ off

· Lifting arm on/ off

· Blade & Wing up/ down

· Plough up/ down

· Brooms up/ down

· Water on/ off

· Spreader on/ off

· Panic Buttons

· Lights on/ off

· Sirens on/off

· Vactor on/ off

· Door open/ close

· Box up/ down

· Lightbar on/ off

· Paint Gun on/ off

· PTO Sensors (capturing PTO time)

· Vacuum on/ off

· Mechanical Lift on/ off

· Cutter on/ off

· In-vehicle and remote panic buttons

50


The Advanced Unit/ System is able to integrate with these salt spreader control systems:

· CompuSpread CS230, CS440 & CS550

· Dickey John Control Point & Flex4

· Epoke

· Cirus

· Force America 5100 EX/ SSC5100

· Component Tech (GL-400, ACS)

· Schmidt-Stratos

· Accucast

· ACE

52

For all salt spreader controls, the data is collected, stored and reported whenever a change to any

of the following fields occurs: solid material type (e.g. salt/sand), solid material spread rate, solid

material spread width, gate setting, blast on/off, pause on/off, liquid material spread rate, preset

on/off, and error status – depending on the availability for the particular spreader controller.

The Advanced Unit/ System is able to integrate to additional on-board data logging devices

including but not limited to:

· Road temperature sensors (i.e. RoadWatch – SS System, Vaisala/Quixote/Control

products temperature sensors)

· Driver ID systems (Key Fobs, Swipe Cards)

· Mobile Data Terminals (for two way communication, and messaging applications)

53

51


Table F: Vehicle Data Yes (X) No (X) Comments (if any)Proposal Page

No.

The information from the vehicle/equipment to the database includes the following real-time as

well as recorded historical information:

· Vehicle speed, direction and location

· Ignition key on or off

· Engine idling vs. running time comparisons

· Time and distance by each monitored sensor

· Stop time data

The Salt Spreader information collected includes:

· Material being used, Dry material application rate (kg/km)

· Wet material application rate (L/km)

· Spinner mode (single, dual, side rear)

· Pause status

· event type (over speed, exceptions)

· error event status.

The Solution has real time spread rates and other information based on information received from

the vehicle’s spreader control system.

The unit interfaces to sensors on the spreader units to determine the status of salt discharge.

The material detect sensor is able to detect if material is being applied to the road surface or not.

Proponent is able to provide data from all salt spreader controllers into one report. Users are able

to select key performance indicators (KPI) such as multiple or individual vehicles and date(s) and

timeframe for each report.

Report output includes but is not limited to:

· vehicle ID

· date/time

· vehicle spreading time/distance

· deadheading time/distance

· vehicle total travel time/distance

· dry material usage (kg/km)

· liquid material usage avg. application rate.

54

55

55

57


58

The Proponent provides, installs, removes and re-installs sensors in good working order to monitor

the status. Alternatively, the vendor is able to train City fleet staff or up-fitters to perform

hardware installations and simple troubleshooting.

The Street Sweeper information collected includes metrics such as:

· date and time started

· time completed

· right side sweeping time and kilometers

· left side sweeping time and kilometers

· total sweeping time and kilometers

· total dead head time and kilometers

· total time and kilometers travelled

· idle time

· average sweeping speeds.

The Paint Gun information collected includes metrics such as:

· date and time started

· completed

· particular paint gun in use

· painting time and kilometers

· total time and kilometers travelled

· idle time.

61

The Telematics control unit is able to communicate with equipment sensors installed on the

vehicle to report their present status and changes to their status in real-time. The sensors, such as

proximity switches, infrared, magnetic read switches, micro limit switches or equivalent are able to

communicate their present status to the equipment with necessary cabling connected to onboard

equipment when required.

59

60


Table G: User Interface Yes (X) No (X) Comments (if any)Proposal Page

No.

62

Users are able to view the position of their fleet vehicles on the Proponent's web-hosted software-

as-a-service (SaaS) using Microsoft Explorer, a Windows-based desktop computer or mobile

device. The primary display is a map view of fleet vehicle(s) and indicate the status of vehicles on

when it last reported including vehicle ID, date, time, location, speed, direction and sensor status

(ignition key on/off).

63

The Solution has the capability to enter an address or select a landmark to display at a minimum

the 5 closest vehicles to that location including vehicle ID & distance to the specified location

(also known as closest vehicle dispatch capability).

64

The map display is such that vehicle position and status updates on screen based on input from the

end-user, additionally, end-users are able to view the status of monitored on-board vehicle

equipment with each fix or report.

The Solution has easy ‘intuitive’ navigation as per up-to-date industry standards (i.e. navigator bar

and/or tabs for easy access to various functional screens).

Tools include but are not be limited to:

· Map navigational tools (zoom in/out, center, pan, etc.)

· Automatic Vehicle(s) Location Tool

· Breadcrumbs

· Filter Tool to select a vehicle or group of vehicles

· Historical data

· Reports

66User interface utilizes point and click features as much as possible to increase ease of use and limit

input user error.

67User has options to select from different map views such as operational districts in order to

accommodate varying business requirements.

68

Upon vehicle ignition, the vehicle automatically reports to the Solution. No operator interface is

necessary to begin transmitting position and sensor data. All information on vehicle status is stored

and is accessible through an online database.

69

Telematics unit wake up feature is provided to ensure uninterrupted service when ignition is off for

a period of time. The time to set Telematics unit wake up feature will be at the discretion of the

City of Toronto.

70 Reports are available for users by interactively selecting an area using the map interface.

71 The Proponent is able to configure or customize for the user needs.

65


Table H: Mapping Yes (X) No (X) Comments (if any)Proposal Page

No.

72The Solution is able to use Open GIS based format such as the City's GIS data and make the data

accessible to third party developers.

73 All mapping requirements adhere to the City's Framework and Protocol.

74The information captured by the equipment is fully integrated with SQL and/or Oracle technology

and adaptable as technology changes.

75User is able to toggle back and forth between mapping interface such as Google Maps (satellite

view), third party maps and client maps without having to close screens.

76

The Solution is able to provide live service maps where roads can be displayed in different colors

such as green for serviced roads and red for not serviced roads on mapping systems such as

Google, Esri and others e.g. City Winter Road Maintenance Map:

https://www1.toronto.ca/wps/portal/contentonly?vgnextoid=e00aa24f6a05f410VgnVCM1000007

1d60f89RCRD&WT.rd_id=plowto

https://www1.toronto.ca/wps/portal/contentonly?vgnextoid=e00aa24f6a05f410VgnVCM10000071d60f89RCRD&WT.rd_id=plowto






Table I: Reports YES (X) NO (X) Comments (if any)Proposal Page

No.

77Collected data is accessible online for a period of up to twenty-four (24) months after start up.

Data beyond the 24 months is archived and available for seven (7) years upon client request.

78The Solution provides easy to use reporting tool formats such as PDF, HTML and Microsoft

Office tools to provide all reported data and the Proponent's reports are downloadable.

The Solution is able to generate standard summary reports based on data supplied and user’s input

in spreadsheet and/or html formats:

· Dashboard report e.g. higher level reports suitable for senior management and

elected officials

· Activity summary e.g. summarize the activities of particular vehicle types in a specific

time period such snow plowing

· Fleet/Driver violation report e.g. speed travelled on a particular road

· Vehicle Trip Summary and details report e.g. details on a particular trip segment with

telemetry data such as salt spread

· Minimum Maintenance Standards Compliance e.g. demonstrate compliance for road

clearing as defined by regulation

· Material Usage e.g. application rates for liquid and solid materials

· Reports can be based on a single or group of vehicles, all vehicles and/or activities by

user supplied boundaries.

· Any activity is made available for replay for all vehicle(s) or routes. Replay time

frame and vehicles to be displayed will be determined by the City of Toronto users. Users

are able to generate a map based report that shows the historical animated track of a

vehicle. The user is able to select the time period and the vehicle(s) to display. The report

allows the user to step through the data one point at a time (for every GPS report) in both a

forward and reverse direction and dynamically update the vehicle location on the map. The

playback also has fast forward and rewind capabilities. The detailed information collected

at each point can also be dynamically updated and shown on screen.

79


80

Playback history includes the ability to leave tracks or “breadcrumbs” depicting progress and

direction along a roadway. This function enables the user to view data that has been collected from

the vehicle.

Users are able to generate standard reports summarizing vehicle activity by selecting the

vehicle(s), date, and timeframe. Information includes but is not be limited to KPIs:

· Speed

· Idle times

· Stop times

· Distance Traveled (km)

· Hours Traveled

· Number of Stops

· PTO time usage

· Vehicle Status (i.e. stopped, moving, etc.)

In addition to standard reports, the Solution is capable of generating exception reports for KPIs

such as

· Speeding above posted road speed limits

· Idle time

· Zones (geofence)

· Input based exceptions (i.e. Panic buttons, PTO times, etc.)

· Harsh braking and excessive acceleration

· Not using seat belt

· Collision and air bag deployment

All exceptions are displayed in real-time on applications and can be sent automatically to specified

users via email

83

The Solution provides an easy to use reporting tool to provide vehicle and material information

such as date, time started, time completed, total kilometers traveled, total kilometers spread,

material usage (kg.), application rate, Liquid usage, liquid application rate, and totals of the above

information per snow event/storm.

84

A Percent of Route/Road Complete report. This report indicates the percentage of the roads within

a route that has been serviced within a certain timeframe. A map also displays roads within a route

that is not complete and displays roads that have been completed and the number of times the road

has been serviced and by what vehicle number within a certain timeframe.

81

82


85

The Solution provides an easy to use reporting tool to provide road patrol frequency reports such

as the Provincial Minimum Maintenance Standard for Road Patrol

(http://www.canlii.org/on/laws/regu/2002r.239/20051019/whole.html) as a guide and also using

the City of Toronto Road Classification System

(http://www.toronto.ca/transportation/road_class.htm) to determine minimum road patrol

frequency. An exception report to the Provincial Standard is produced and be available from the

Proponent in the form of an e-mail to various recipients within the City of Toronto, on a timeframe

given by various users, as determined by the City of Toronto.

86

The Solution provides an easy to use reporting tool to provide vehicle information. For example,

sweepers: date, time started, time completed, right side, left side and/or both side sweeping time,

total sweeping time, total deadhead time, total time, right side, left side and/or both side sweeping

kilometers, total kilometers swept, total deadhead kilometers, total kilometers traveled, idle time

and average speed while sweeping.

87The Solution has the capability to track vehicle usage e.g. engine hours, odometer for use in

monitoring and planning for maintenance cycles.

88The Solution has the capability to support City requests for additional customized reports. The

City recognizes that Professional Services at additional cost may be required.

89Custom reports i.e. not provided as standard reports are available upon request using Professional

Services rates and process.

90A custom report once developed is then a standard report available to all City users and it is

included as part of the Solution thereafter.


Table J: Warranty, Maintenance and Support Services Yes (X) No (X) Comments (if any)Proposal Page

No.

91The Proponent provides supply, installation, maintenance and removal of the Telematics Solution

or trains Fleet Services or designates accordingly.

92

Telematics units are covered by warranty for a minimum of one (1) year from the date of

installation. Maintenance, repair and support are provided during the warranty and non-warranty

periods.

93 Remote and on-site diagnostics, maintenance and technical support are provided.

94 Subcontracting of any services meets the service levels set out by the City.

95 The Proponent has the ongoing support structure, contact phone and email, processes, etc.

Table K: Training Services Yes (X) No (X) Comments (if any)Proposal Page

No.

96

All training on Solution functionality, training manuals and installation of all hardware are

available from the Proponent and can be provided at various City facilities throughout the City or

other appropriate location(s).

97

Training is available on-site in an in-class style, consisting of ½ day sessions or online (webinars)

as requested by the City. In-class training sessions accommodates up to 15 people per session.

Training material is provided as hard copy and available electronically.

Table L: Additional Optional Hardware Yes (X) No (X) Comments (if any)Proposal Page

No.

98

The Proponent considers additional requirements for optional hardware such as temperature

sensors for trucks to measure road and ambient air temperature; operator or drive ID technology;

etc.

Table M: Public Information Systems Yes (X) No (X) Comments (if any)Proposal Page

No.

The Proponent is able to provide vehicle location data (GPS) and other relevant data from their

system to public websites operated by the City via an Application Program Interface (API) that:

· Allow users to identify and extract select data

· Allow city web applications to access the API over HTTP, HTTPS, RESTful

webservice via an internet connection

· Is capable of replying to API requests using JSON (JavaScript Object Notation) and

KML

99


Table N: In-Cab Camera System Yes (x) No (X) Comments (if any)Proposal Page

No.

100

The Proponent's In-Cab Camera System allows for video based driver risk management for driver

coaching and training. The Proponent provides screening and flagging of events and occurrences

based on the City's standards. The Proponent's In-Cab Camera System provides vehicle location

and engine related (speed, harsh braking, etc.) information, video data and location in the event of

an accident in order to improve the reconstruction of an accident to provide driver coaching.

101In-cab camera system allows for both inward facing and roadway facing information to obtain

more accurate accident reconstruction and account and driver actions in case of such an event.

102In-cab camera system works with high speed mobile communications technology capable of

transmitting video data, location and engine data downloads.

103In-cab camera system has configurable video data, location and engine data transmission speeds

e.g. once/second.

104In-cab camera system configurable alarm input triggers including but not limited to brakes, horn,

seat belt, and speed.

105 Proponent has a data centre for video data, location and engine data within Canada.

106 Supports minimum 170 degrees of view for high definition pillar-to-pillar camera viewing angle.

107In-cab camera system has the feature for operator identification either visually with the camera or

by another means e.g. separate logon, swipe-on.

108Supports Dual Secure Digital (SD) card design to increase storage times before the data overwrites

itself.

109 Has Automatic SD card formatting in the event of corruption or error to prevent data loss.

110 Has tamper-resistant design for all exposed hardware.

111 Power to the camera and related equipment is hard-wired from vehicle's 12V or 24V supply.

112 Camera has minimum 680 X 480 colour resolution and H264 compression.

113In-cab camera system has speed and G-force related algorithms and calibration to prevent

unnecessary alarms from being triggered.

114In-cab camera system is capable of detailed driver reporting to be used for mentoring and training

purposes


115Videos are customizable by filtering for specific incidents only such as operation in excess of a

certain speed.

116All hardware, applications and related components are approved for use in Ontario by The

Ministry of Transportation.

117In-cab camera system has standard reports and alerts that can be sent to pre-determined City of

Toronto Users.

118 Installation and setup of system using installers at City yards and approved by the City.


Table O: Commercial Vehicle Operator's Registration (CVOR) Solution Yes (X) No (X) Comments (if any)Proposal Page

No.

Proponent has dedicated device-based, wireless automated solution for CVOR compliance

allowing for:

· Pre and post-trip vehicle inspections including ability to attach digital photographs

· Positive indication of pre and post-trip check points, and ability to store data on a mobile

device for a maximum of 30 days

· Mandatory and positive driver identification via login and repetitive prompts to driver if not

entered

· Pre and post-trip vehicle inspection records can be retrieved as required for internal or

external reporting and audits

· Allows vehicle operation even if driver does not perform necessary steps as outlined above

120All wireless hardware meets Industry Canada radio frequency standards for wireless devices and is

not known to cause any health or safety concerns and is certified by the cellular carrier.

121All hardware, applications and related components meet the need of the Ministry of

Transportation.

122All data storage, data quality validation, forms, reports and online presentation are provided as

part of the Solution.

123 Standard reports and alerts are sent to pre-determined City users.

124Reports which are not time-sensitive can be sent using least data cost approach such as City's Wi-

Fi when vehicle returns to yard.

125 User training for City of Toronto staff using online (webinar), and classroom formats is provided.

126 Installation and setup of system using installers at City yards and approved by the City.

127The CVOR Solution meets the requirements of the Ministry of Transportation in the Province of

Ontario, Canada.

119


Table P Driver Behaviour and Safety Yes (X) No (X) Comments (if any)Proposal Page

No.

128In-cab mentoring that provides immediate feedback to the driver in case of harsh braking,

excessive speeds, fast turning, etc.

129Driver scorecard based on driver behaviour indicators such as hard braking, fast acceleration,

speeding using comparison with posted speed limits, lane deviation, etc.

131Immediate email notification for collision, air bag deployment and not using seat belt while

driving

132Ability to prioritize events and identify and set-up those for immediate email notification versus

less frequently (i.e., once a day in a report format)

130

Availability of driver scorecard utilizing the above mentioned indicators; data quality validation;

elimination of false positive results; and data and reports storage is managed by the Vendor and

available to City as part of the Solution.

Documents

REVISED CLOSING DATE: JANUARY 23, 2017 12:00 …...Toronto, Ontario M5H 2N2 Elena Caruso, Manager Goods and Services December 23, 2016 Via Internet Posting (4 pages + attachment) ADDENDUM