Attachment B - SMART PSDS Compliance Matrix.pdf

Instructions: Please read carefully

Ref No. Requirement Proposed

Compliance Status (C/N/CM)

Proposed Modified Requirement Text (required for CM or where the requirement is exceeded)

Proposal Reference (Section No. & Page No.)

1 3. Information Technology (IT) Requirements

2 3.1 General

The selected vendor, referred to as the “Contractor” in the rest of this document, shall provide the hardware and configuration details for installing the system (1) at the location identified by

SMART (site installation approach). SMART does prefer a virtualized server if possible depending on specs and storage requirement needs as well as growth or (2) at a data center proposed by the Contractor (hosted approach). The data center selected for installation of the system must be approved by

SMART.

The software applications shall include context sensitive help capability.

The software applications must run fully in the user context and shall not require elevated permissions or administrative permissions on the desktop.

All software applications must utilize the Microsoft Operating

System consistent with current SMART upgrades, patches and service packs on the servers and desktops. The following

Microsoft products must be used:

7 • Microsoft Office Suite: 2010;

• Microsoft Windows Desktop Operating System (OS): Windows

7 and Windows 8.1 (Windows 10 ready is preferred);

• Microsoft Windows Server OS: Windows 2008 R2, Windows

2012 R2; and

• Microsoft Structured Query Language (SQL) Server: SQL Server

2008 R2 Enterprise edition and SQL Server 2012 R2 Enterprise

Edition.

11 All software applications must support role-based security.

The Contractor is required to notify SMART when new releases of software applications become available, and when current releases and related systems are no longer supported.

The Contractor must comply with the SMART’s change management process when making any changes to supported systems; these changes must be reported to the SMART project manager.

The Contractor shall implement a test environment, with all software components installed on parallel hardware at SMART, where software updates and configuration changes can be tested prior to being implemented in the production system.

Any future updates or upgrades must be tested in the test environment before being implemented on production servers.

All software upgrades or changes required by the Contractor must be made in an SMART test environment and certified prior to moving into a production environment. Any on-board firmware changes must be tested first in a “bus-in-box” type test bench before installing them on vehicles.

16 3.2 Required Infrastructure

17 3.2.1 Hardware

The Proposer shall provide the specifications for hardware that comprises the proposed central system, including the required number of workstations for all users. Proposers shall provide the server hardware requirements required to support the proposed solution since SMART may procure the hardware from a supplier other than the Contractor and may decide to use the site installation approach.

For site installation, SMART reserves the right to confirm the specifications of the Contractor-recommended and supplied hardware and SMART reserves the right to offer virtualization within the current infrastructure as a potential replacement for hardware.

The proposer is required to indicate the compliance status relative to each individual requirement listed in the Compliance Matrix. For each requirement, the proposer must indicate whether their proposed system shall comply (C); not comply (N); or comply only if SMART accepts a proposed modified version of the requirement (CM). Please carefully read each requirement before indicating compliance status as this Compliance Matrix will become part of the contract between SMART and successful proposer. Further, the proposal evaluation scoring shall not be significantly impacted by noting N or CM as long as the proposer can comply with the key PSDS requirements.

No additional commentary shall be provided for responses of “C” or “N” unless the proposer exceeds the requirement (see below). For each requirement marked with a “C” or “CM,” proposers are required to provide a reference to exactly where in the proposal there is a description of how this requirement shall be met. Proposers must provide at least the section and page numbers of the part of the proposal that verifies the claim that the proposer complies with the requirement. A response of “CM” should be used only to indicate that the proposer shall comply if the requirement wording is changed to specific alternate text that must be provided by the proposer in the column provided. A response of “CM” shall be equivalent to a response of “C” if the SMART agrees to change the requirement as proposed, or equivalent to a response of “N” if SMART decides to not change the requirement. If alternate requirement wording is not included in the matrix in conjunction with a “CM” response, this shall be treated as an “N” response.

In the situation where the proposer exceeds the stated requirement, the proposer must indicate a response of “C” for the compliance status and must provide an explanation as to how that requirement exceeds the original requirement.

The Proposer shall supply the specifications for workstations and tablets, which SMART may procure from suppliers other than the Contractor.

21 3.2.2 Software

The successful Contractor shall provide software and specifications for hardware that comprise the proposed central system, including the required number of licenses for all users.

The cost of each component shall be provided per the instructions on the Price Proposal Form.

The Contractor shall either provide their proposed system’s source code to SMART, establish an escrow account with the exact version of the source code being implemented at SMART, or provide an alternative solution to ensure that SMART has unrestricted access to and use of the source code in the event the Contractor ceases to exist, ceases to support the application, or otherwise terminates its relationship and/or ownership to the product.

The Contractor shall supply the specifications for workstations and monitors, which SMART will supply and/or procure.

For hosted approach, the Proposer shall clearly define the approach for software hosting and access (e.g., Citrix’s independent computing architecture [ICA] protocol, Microsoft’s remote desktop protocol [RDP] over secure virtual private network (VPN) connection, completely web-based application accessible via hypertext transport protocol secure [HTTPS]) on standard web browsers (e.g., Microsoft Edge [preferred], Mozilla

Firefox, Google Chrome and Apple Safari).

The Contractor shall implement a test environment, with all software components installed (1) on parallel server hardware at

SMART (site installation) or (2) at the data center (hosted installation), where software updates and configuration changes can be tested prior to being implemented in the production system. Any future updates or upgrades must be tested in the test environment before being implemented on production servers.

All software upgrades or changes required by the Contractor must be made in the test environment and certified prior to moving into a production environment.

Using a hosted approach, at least two parallel data centers in two different geographic locations shall be utilized.

The Central system shall be setup in redundant configuration by default. So, if the primary application fails, the secondary application that is configured to run in hot-standby mode shall automatically start running as the primary application to ensure fail-safe operation. Each Proposer shall provide a clear description of their approach for enabling redundant server configuration.

For hosted solution, Proposers shall describe the minimum computer hardware and browser requirements (e.g., minimum

Random Access Memory [RAM] requirements for map rendering, java run-time environment [JRE] for java-based web applications).

31 3.3 Information Security

The Contractor shall be asked to comply with best practices with all areas of IT Security as outlined by Health Insurance

Portability and Accountability Act (HIPAA) rules. SMART has specific policies in the following areas, if you require additional information please contact SMART IT to discuss in more detail.

33 • Acceptable Use

34 • Automatic Log-Off

35 • Data Backup

36 • Emergency Access to HER

37 • Encryption and Decryption

38 • IT Risk Management Program

39 • Malware Protection

40 • Password Management

41 • Portable Computing Device Privacy and Security

42 • Privacy and Security of Protected Health Information

43 • Termination of Access

44 • Transmission Security

45 • Unique User ID

46 • Workstation Use and Security

47 All software applications must support role-based security.

The Contractor shall follow the SMART IT Security Policies, which will be provided at a later date.

For a locally-installed solution, all software applications must have the ability to use Windows Authentication based upon

Active Directory setup. For a hosted solution, please describe the administrative needs to add users to the system.

The methods used for encrypting stored passwords must be disclosed. Industry standard encryption methods utilizing at least 256 bit encryption techniques are required.

The Proposer must disclose provisions to secure the database in its proposal.

Any vulnerabilities or exploits discovered by the Contractor or others for the proposed application must be reported to SMART immediately with a proposed mitigation strategy.

The Contractor shall support Microsoft security patches and updates within fifteen (15) days of release.

The system must track all activities performed by software users for auditing purposes (e.g., system configuration changes, trip booking, modifications and client data editing).

The methods used for encrypting stored passwords must be disclosed. Industry standard encryption methods utilizing at least 256 bit encryption techniques are required. Applications may not store or transmit passwords in clear text.

Any software which stores personally identifying information, including but not limited to, “unique identifier number,” driver’s license numbers, etc., or any financial information, such as credit card numbers, bank routing information, etc., must fully protect the information for the entire duration of SMART’s use of the software, as defined in the eventual contract with the successful Contractor, and disclose the methods of protection used, access protection methods, and life cycle handling of this data. Industry standard encryption methods utilizing at least 256-bit encryption techniques are required.

Any HIPAA-related information must be protected in the database and application according to the law (e.g., display only last four digits of the Social Security Number (SSN)).

The Contractor shall supply SMART with current HIPAA test results or be willing to be tested with regards to compliance with HIPAA policies on a yearly basis.

59 3.4 Database

All database-related components of the solution (e.g. tables, stored procedures, scripts, extensible markup language [XML] schema, and related information) shall be fully accessible and available for support and use by SMART and SMART staff.

Proposer’s solutions should be developed and configured using prescribed standards for SQL Server, and be flexible enough to run in consolidated database environments with other applications using different schemas and virtualization.

Data shall be retained in a read-only historical database for use by management and other SMART staff to plan and assess system performance, and to address inquiries, conflicts and other related issues.

The system shall allow all such data to be retrieved, even if it has been archived.

All queries made to the database shall be logged for audit purposes. SMART shall have the ability to view these logs when required.

The online data storage system shall ensure data integrity in the event of a disk-drive failure.

In addition, the system shall include a means of archiving transaction data, or restoring data from an archive, while the system is in operation. It shall not be necessary to shut down the database to perform a successful backup operation.

Proposers shall determine and describe the need and procedure for an incremental, daily or other time frame-based backup of data. Other needs related to the archiving of data, such hardware and software, shall also be determined and described by each Proposer.

Data kept for archive purposes must be in location that is still subject to all HIPAA testing and be tested for compliance on a yearly basis.

The system administrator account shall not be used with SQL server applications. If it is, the solution must allow SMART staff to change the system administrator password on a periodic basis without limitations.

70 The Contractor must provide the following:

71 • Scripts in order to recreate database;

72 • An entity relationship diagram;

• Database schema with a data dictionary detailing all database entities (e.g., tables, columns, and attributes; and

• Recommended practices document for support and maintenance of the database.

75 3.4.1 General

The system shall allow PSDS system data to be retrieved, even if it has been archived.

In addition, the system shall include a means of archiving transaction data, or restoring data from an archive, while the system is in operation. It shall not be necessary to shut down the database to perform a successful backup operation.

The Proposer shall determine and describe the need and procedures for an incremental, daily or other time frame-based backup of the data (but not less than daily). Other needs related to the archiving of the data shall also be determined and described by the Proposer.

79 The Contractor must provide the following:

• Scripts in order to create and recreate database schemas, stored procedures;

81 • Entity relationship diagrams;

• Database schema with a data dictionary detailing all database entities (e.g., tables, columns, and attributes); and

• Documentation of recommended practices for support and maintenance of the database.

84 3.4.2 Data Management

Data shall be retained in a database for use by SMART staff to plan and assess operational, financial and system performance, and to address inquiries, conflicts and related issues. Storage capacity must be large enough to retain operational history data for at least two fiscal years.

After two fiscal years, the operational and financial data will be archived in a “non-live” database, and will remain readily accessible when needed. (“Non-Live” database refers to a “read-only” database that is not being accessed by any application.

This database may not be up and running all the time and can be shut down or restarted, as needed.)

Data backup for both live and non-live databases must be archived at redundant offsite locations.

Proposers must describe the time it would take to restore the data into the database from the backed-up files in the event of a database crash.

The Contractor shall develop a long-term archival plan to store information on optical (e.g., Digital Versatile Discs [DVD]) or magnetic storage (e.g., external hard drives) devices in coordination with SMART. This data should be stored in such a way that it is mountable or searchable, and arranged by year so, as it moves beyond the number of years mandated in SMART’s document retention policy, it can be permanently destroyed.

The Proposer shall determine and describe in their proposal the need and procedures for an incremental, daily backup of the data. Other needs related to the archiving of the data, such hardware and software, shall also be identified and described by the Proposer.

91 3.4.3 Data Logging and Retrieval

All incoming and outgoing data shall be stored in a read-only historical database for retrieval, analysis, display and printing.

This historical information shall include all data exchanged between vehicles and dispatch (e.g., location data, vehicle logon/logoff data, device alarms, and canned data messages);

and all central software user logons and logoffs.

The stored data shall be time and date stamped, and shall contain sufficient information to enable selective sorting and retrieval based on user-specified selection criteria. At a minimum, the following sorting and selection criteria shall be supported for accessing the historical data from both the online and archived storage: date and time, GPS latitude/longitude, vehicle number, vehicle operator number, dispatcher number, run number, and incident type (where needed).

95 3.5 Data Access

The database structures and any proprietary interfaces shall be documented in the proposal.

The proposed system shall follow an open architecture model, providing the capability for SMART to independently develop system interfaces or enable integration with other internal or third-party systems. The use of standard network communication protocols (e.g., Transmission Control

Protocol/Internet Protocol [TCP/IP] and system interfaces (e.g., Open Database Connectivity [ODBC] for databases) is required.

SMART shall be allowed royalty-free access to the database tables, and royalty-free use of the data and interfaces. If necessary, SMART shall be allowed to extend such access and use to third party vendors for integration purposes.

All system data shall be the property of SMART and shall be immediately available to SMART. The Contractor shall acknowledge in writing that SMART will own any and all data and the database where the data resides.

100 3.6 Customer Support

Customer support shall be available 24 hours a day, 365 days a year. All technical requests from SMART must be addressed within one hour of the notification of a problem. If an issue requires a longer timeframe for resolution, SMART must be advised accordingly and an expected reasonable timeframe for resolution must be provided.

SMART must be able to view the status of their support request(s) at any time through an online tracking system to be provided by the Contractor.

For on-site support, the proposal shall include a list of the support firms, their support responsibilities and the response arrangements.

The Contractor shall arrange for support from one or more qualified firms to be available on-site on a four-hour response basis when needed by SMART to assist with fault diagnosis or component replacement.

If a support firm does not respond within the agreed-to response timeframe, or when a support firm is not able to provide the needed support, the Contractor shall provide, during the warranty period, supplementary support in accordance with an agreed-to escalation procedure. The escalation procedure can initially involve telephone support, but must culminate in the Contractor providing on-site support, if needed. The proposal must define the proposed support escalation procedures.

SMART must be able to view the status of their support request(s) at any time through an online tracking system to be provided by the Contractor.

107 3.6.1 Site Installation

The Contractor will provide needed service technicians to assist with installation of product within the SMART network. SMART will make available, resources to assist with all aspects of installation with regards to personnel or additional system needs if virtualization approach is deemed possible. The

Contractor will be required to comply with current data center restriction policies and must be willing to submit to background check if deemed necessary by the data center. SMART personnel will accompany contractor staff at all times during the installation and may assist as needed.

109 3.6.2 Hosted Approach

Customer support shall be available 24 hours a day, 365 days a year. All technical requests from SMART must be addressed within one hour of the notification of a problem. If an issue requires a longer timeframe for resolution, SMART must be advised accordingly and an expected timeframe for resolution must be provided.

SMART must be able to view the status of their support request(s) at any time through an online tracking system to be provided by the Contractor.

All servers, routers, switches, data center security and facility power shall be monitored electronically 24 hours a day, 365 days a year. In the event there are any out of tolerance conditions with any server components, technical support shall be automatically notified. The technical support must respond to these issues within one hour of notification.

The data centers to be used for hosting must have existing scheduled routine maintenance and emergency situation management plans. Proposers must submit maintenance schedules and emergency plans with proposal for contractor review.

The data centers must comply with all HIPAA requirements as pertains to security and verification of credentials as well as any access to physical systems containing SMART data.

115 3.6.3 Follow-up Analysis

The Contractor shall provide onsite follow-up analysis, including a written report on the findings of this analysis, on how the system is being used and provide training to address the issues.

This follow-up analysis shall be conducted every six months under the warranty period and the first visit shall be conducted six months after the system acceptance. The follow-up analysis report shall categorize discovered issues under the following categories:

117 • Issues due to lack of training;

118 • Issues that require configuration changes;

• Issues that require system enhancements and can be addressed by upgrading to a more recent version of the system;

and

• Issues that require system enhancements and will be fresh development for the Contractor.

121 3.7 Software Updates and Upgrades

Proposers must describe their maintenance update and upgrade approaches in their proposals.

Proposers shall describe the difference in processes and costs associated with updates and upgrades.

The Contractor is required to notify SMART at least one month in advance of the installation when new software releases become available.

The Contractor is required to notify SMART at least six months in advance when it is expected that the current releases and related systems will no longer be supported.

The Contractor shall ensure that all existing software configurations are protected after the system has been upgraded or updated for the entire duration of the time when

SMART uses the product.

The Contractor must comply with SMART’s change management process when making any changes to supported systems. These changes must be reported to the SMART Project Manager.

128 4 Wireless Data Communication Requirements

129 4.1 General

The Proposer shall describe the data communication infrastructure required to satisfy the following communication needs for this project:

• Wireless data communication between vehicles located at

SMART facilities and the central system; and

• Wireless data communication between the central system and all revenue vehicles throughout SMART’s service area.

The Proposer shall identify the specific on-board and central hardware and software that will be required to establish a wireless communication infrastructure.

The Proposer shall identify the necessary cellular data requirements for their proposed solution and include such pricing in the cost proposal using the Price Proposal Form.

135 4.2 Wireless Data Communications

The Proposer shall provide estimates of the bandwidth required for data exchange between the central system and vehicles (in terms of megabytes [MB] per month per unit).

The Contractor shall provide a report to monitor data usage by vehicle on a monthly basis.

138 4.2.1 Wireless Data Communications Network

Proposers are required to submit a solution that shall provide data communication as stated in Section 4.1. The solution shall ensure the transfer of data between the central system and each vehicle in the SMART Connector fleet via a cellular data connection.

The proposed communications protocol shall follow the open system interconnection (OSI) model.

SMART will select a cellular data provider in consultation with the Contractor, suitable to support the data communications requirements of the system as best available based on the cellular communications options commercially available to

SMART.

Proposers shall describe any additional power backup provisions that will be incorporated into the proposed system to maintain operation of the central system, including the cellular data gateway during a power supply failure, and for how long power can be so maintained.

The description of the proposed communication solution shall include at least the following information:

1. Description of the communications protocol to be used (e.g., inter-asterisk exchange [IAX], session initiation protocol, skinny call control protocol [SCCP], and extensible messaging and presence protocol [XMPP]);

2. Description of any data compression and encryption techniques being used for data packets exchanged between

SMART vehicles and the central system. In the event when no encryption is being used, Proposers must clarify the steps taken to ensure data security over the public wireless network; and

3. Information on the bandwidth needed to support the data exchange between vehicles and the central system. Proposers shall assume that location updates shall be provided at an interval of 15 seconds or less from each vehicle. Further, location updates shall be provided at the time of vehicle departure from each pickup and dropoff.

147 4.2.2 On-Board Hardware

148 4.2.2.1 Data Communication Hardware

The Contractor shall provide cellular data modem and other relevant hardware for system data communication needs using a commercial cellular network.

The Contractor shall conduct a coverage test, or rely on already available data provided by SMART’s IT staff, to determine the carrier with best data coverage in the SMART service area.

151 4.2.2.2 Antenna Hardware

If applicable, proposed antenna hardware shall help limit the number of antenna hardware to be installed on each vehicle. An antenna which can support a combination of global positioning system (GPS) connection, cellular network connection and wireless fidelity (Wi-Fi) connection using a single unit (e.g., dual-mode antenna, tri-band antenna) may be used for the proposed solution.

153 The Contractor must use low-profile antenna hardware.

154 4.2.2.3 On-board Mobile Router Gateway (OMRG)

The modem shall provide a cellular connection over the cellular network to be selected by SMART.

The Proposer shall describe the ability of modems and supporting hardware (e.g., network card) to support multiple types of wireless data networks using a single hardware unit

(e.g., 5G, 4G/3.5G, 3G type cellular data connectivity over a particular carrier network).

The modems shall have the ability to utilize a 5G or 4G wireless data connection when such networks are available. The proposed hardware shall be able to automatically switchover to a lower bandwidth network (e.g., from 4G to 3G) in the event a higher bandwidth connectivity is not available.

The hardware may also have the capability to utilize Institute of

Electrical and Electronic Engineers (IEEE) 802.11x (commonly known as wireless fidelity [Wi-Fi]) or 802.16x (commonly known as wireless interoperability for microwave access [WiMax]) hotspots where such networks are available.

The modem/router shall support Quality of Service (QoS) in order to ensure protected bandwidth for multiple sub-channels.

The CAD/AVL data will need to be guaranteed a QoS to maintain desired throughput for simultaneous transmission of both types of data. The same will be true for video that is provided by an on-board video surveillance system.

The vehicular modem must be capable of withstanding normal wear and tear, dust and water intrusion, and weather conditions associated with field use inside paratransit vehicles.

161 4.2.3 Central Wireless Communication Gateway Software

162 4.2.3.1 General

A mobile data communications gateway shall be established with the cellular data carrier selected by SMART to enable the central system to exchange data messages over the leased cellular accounts with vehicles. The gateway internet connection shall be sufficient to support a data rate that can simultaneously carry all the data traffic for the entire fleet.

The gateway shall have the ability to support multiple wireless networks simultaneously.

The gateway shall be setup in a highly redundant configuration.

The Proposer shall describe the wireless coverage of the proposed cellular carrier. The Proposer’s solution must not depend on a specific cellular carrier.

The Contractor, in coordination with SMART’s IT staff, shall arrange for a pool plan with the selected cellular carrier for the

SMART fleet to accommodate all vehicles.

The Proposer shall provide the following information in the proposal in terms of megabytes (MB) per month per unit based on their experience: bandwidth required for data exchange between the central system and vehicles.

The software shall process data messages in the order they are received or based on their associated priorities to be defined by

SMART.

SMART shall provide the required data connectivity and firewall configurations to the cellular data provider.

171 4.2.3.2 Data Message Processing

The software shall process data messages received from the vehicles, and pass these to the central software.

The software shall process data messages received from the central software and pass these to an individual vehicle or a group of vehicles.

The system shall log relevant details about a data message including but not limited to the following:

175 • Sender and receiver of a message;

176 • Type of the message; and

• Follow-up action to a message, if applicable (e.g., acknowledgement).

178 4.3 Wireless Local Area Network (WLAN) Data Exchange

179 4.3.1 General

Wireless communication between vehicles and the central system will be provided at SMART’s office using Institute of

Electrical and Electronics Engineers (IEEE) 802.11x WiFi hotspots.

The Contractor shall install WLAN access points at SMART’s office to upload and download data when vehicles are within close proximity to the office, as necessary. The Contractor must coordinate with SMART's IT staff for approval of access point locations.

The Contractor shall conduct a survey of SMART’s office to determine the number of wireless access points required.

The service set identifier (SSID) for access points shall be not broadcast publicly and must be accessible to only SMART vehicles. The access points shall avoid significant signal availability outside of the intended coverage area.

WLAN access points shall be installed such that wireless signals are not obstructed by any barrier.

185 4.3.2 Access Point Hardware

The WLAN access points shall support the Wireless Protected

Access 2 (WPA2) security standard, or an approved alternate superior security standard ratified by the time of implementation. SMART shall have the ability to independently change the encryption keys as often as desired.

SMART shall have the ability to independently adjust the signal strength of each WLAN access point.

SMART shall approve the specifics of proposed access point locations, signal levels and antenna type/orientations for an acceptable balance between expected coverage in outlying parts of the intended coverage area and minimizing signal availability outside the facilities. WLAN access points shall meet or exceed the following environmental capabilities:

• Non-operating (storage) temperature: -40 to 185°F (-40 to

85°C);

190 • Operating temperature: -4 to 131°F (-20 to 55°C); and

191 • Operating humidity: 5 to 97 percent (non-condensing).

WLAN access points must be National Electrical Manufacturers

Association (NEMA) 4 or IP65 rated for dust and water resistance.

193 4.3.3 WLAN Data Transfer Support Software

The WLAN data transfer support software shall manage the

WLAN data transfers between vehicles and the central software using the new garage WLAN. Wi-Fi hotspots will be required at

SMART’s office to upload/download the following information to/from SMART vehicles:

195 • Schedule/manifest data to vehicles; and

196 • Configurations, firmware upgrades, and patches to vehicles.

Once a vehicle has successfully associated with a SMART WLAN access point, the WLAN data transfer software shall receive the file uploads initiated by the on-board mobile data terminal

(MDT).

When the WLAN data transfer software has a download available for a vehicle that has successfully associated with a

SMART WLAN access point, the WLAN data transfer software shall check with that MDT whether it has already received that download and if not initiate and complete that download.

Any new download file shall be downloaded to the entire fleet within one day, if each vehicle returns to WLAN coverage each night and is configured to remain on for a set time configurable by SMART (e.g., at least 15 minutes after the ignition is turned off).

The system shall report on the status of the current status of downloads (e.g., download in progress, downloaded or download failed) for the SMART fleet.

Updates or changes to schedule data shall be able to be downloaded prior to their effective date for service and then accessed the first time a driver logs on for service for that effective date.

202 5 GIS and Mapping

203 5.1 Map Source

The Proposer shall identify the source of GIS maps data to be used for the proposed PSDS system. It is assumed that the

Contractor will supply the base map, unless SMART specifies otherwise. If the base map is supplied by the Contractor, the

Contractor is required to provide updates to the map within two weeks from the date when the updates are available. Third-party mapping systems (e.g., Google Maps, Bing Maps) may be used as far as they meet the requirements described in in this specification.

205 5.2 Built-in GIS Support

The software shall incorporate GIS capabilities that allow users to view maps of the service area and individual trip patterns, each at various specified user-defined zoom levels. GIS features shall be closely integrated with the individual modules of the

PSDS system and access to maps shall be seamless within the

PSDS system modules.

In addition to supporting the primary demand-response service functions, the GIS functionality of the proposed software shall support other GIS analyses and be capable of converting geographic files from other sources (e.g., Tele Atlas or Navteq) to the format used by the Contractor’s GIS (e.g., MapInfo or

ESRI).

208 5.3 Spatial Layer Management

209 5.3.1 Map Overlay

GIS functionality shall include the ability to develop overlays for the coverage of municipal, township, census tracts or block groups, and zip code boundaries.

The system shall allow overlay of terrain, aerial or satellite layers on base maps when such layers are available.

212 5.3.2 Definition and Management of Geographic Boundaries

The system shall allow definition of polygon layers when such layers are not readily available for overlay. The system shall allow the user to assign a specific service characteristic to a polygon layer. These characteristics shall include but are not limited to the following:

• Agency service area for demand response, linehaul/fixed-route, microtransit and other services;

• Americans with Disabilities Act (ADA) complementary paratransit service area;

216 • Town boundaries; and

217 • Fare zones.

218 5.3.3 Definition of Physical Barriers

The system shall allow the definition or import of physical features that act as barriers to routing (e.g., rivers and lakes, road closures).

The system shall recognize these barriers when routing vehicles.

221 5.3.4 Definition of Point of Interest (POI) Locations

The system shall be capable of defining and displaying point files that may represent landmarks, SMART bus stops, major transfer points, major destinations of travel, or other POI locations (e.g., hospitals/medical centers, assisted living facilities, shopping centers, tourist attractions).

223 5.3.5 Import/Export of Map Layers

The system shall have the ability to import and export map layers in standard geographic file formats (e.g., Environmental

Systems Research Institute’s [ESRI’s] SHP file format or Keyhole

Markup Language [KML] format).

The system shall have the ability to import location data

(customer address or POI database) if available in standard

“point” file format (SHP or KML) that consist of latitude and longitude data.

226 5.4 Management of Spatial Attributes

The system shall allow authorized users to edit the base map layers (e.g., to add new streets, change municipal boundaries, define any incomplete address ranges).

A service area map shall include current data for all street segments to ensure, in part, that every segment is appropriately connected in the network and contains the necessary data for scheduling. For each street segment, this data shall include at a minimum a defined street name and address range, and segment speeds by time of day and day of week. The street network definition shall include segment characteristics (e.g., speed limits, one-way direction).

229 5.5 Geocoding

The system shall have full geocoding capability, allowing the system to locate the address on the map for an address input.

The geocoding capability shall be seamlessly integrated with relevant features in the rest of the PSDS system (e.g., address input in the Reservations module, discussed later in Section 6.5).

The street segments database shall be sufficiently complete to assure a geocoding success rate of 90 percent or better based on a sample of addresses developed by SMART. The system shall be capable of handling various abbreviations of names (e.g. St.

for Street and Av. or Ave for Avenue) in the geocoding process.

232 5.6 Miscellaneous GIS Features

233 5.6.1 Distance Computation

The system shall allow the user to calculate the distance between points or along a specified portion of the street or road network.

The system shall allow the software user to select the unit of measurement (e.g., feet, mile) when computing distance.

236 5.6.2 Zoom/Pan

The system shall allow software users to zoom in, zoom out and pan map views.

The system shall allow software users to zoom in to a street-level view.

The system shall allow software users to select custom zoom level (e.g., 400% or 50%).

The system shall provide an “inset” view that can be turned on or off by users. The inset view shall display an overview map within the detailed map view and shall allow “pan” capability.

241 5.6.3 Save and Reload Map View

The system shall allow users to bookmark or save a particular view on the screen.

243 The system shall allow users to reload saved map views.

244 5.6.4 Spatial Search

The system shall allow geographic search within PSDS modules and shall support search based on at least the following data:

246 • Customer address;

247 • Trip origin or destination location;

248 • Current vehicle location; and

249 • POI location.

The system shall be able to identify whether or not a customer address is located within a buffer zone (e.g., ¾ mile) around a

SMART route. The parameter for the buffer zone shall be configurable.

The PSDS shall allow a user to view a list of all trips to a location or town within a specific time frame. This allows users to see which drivers are already in the area to do non-scheduled trips.

This shall be displayed in a map view including real-time vehicle locations and in a table.

252 5.6.5 Legend

The system shall have the ability to display legend of the layers included in the GIS subsystem. The use shall have the ability to turn this feature on or off, as needed.

254 5.6.6 Printing

The system shall be capable of printing maps to peripheral devices (e.g., printers, plotters) directly attached to a workstation or available over a Local Area Network (LAN) or wireless LAN.

The system shall allow users to print and save a PDF version of the map view.

The system shall provide users the ability to format the layout of maps before printing. As a minimum the following capabilities shall be available: adjusting margins, adding title, adding legend.

258 5.7 Visualization

The system shall display vehicle locations on the map when such data is available from vehicles (see Section 10.2.1.3 for AVL tracking).

The vehicle icon on the map view shall display additional information (e.g., operator id, vehicle id) upon user request if such information is available in the system (please see Section

6.10 for MDT interface).

The map view shall support context sensitive menus and shall allow users to communicate with vehicles directly from the map view when such capabilities are implemented by SMART (please see data communication requirements in Section 4).

262 5.8 Map Update Process

The system shall provide SMART the capability to update the base map, whether it is supplied by the Contractor or by another source.

Map updates, when available, must be made to the mapping data stored on the SMART server or hosted system. Map updates should not be performed while a user is accessing the map.

For Contractor provided maps, SMART shall be notified in advanced of the map update schedule.

266 5.9 Integration of Real-time Traffic Information

Integrating real-time traffic information with the mapping/GIS as well as utilizing this information in scheduling and dispatching is required.

The software shall respond automatically to road conditions such as traffic congestion, weather, and vehicle breakdowns by using real-time traffic and mapping information to predict estimated time of arrival (ETA) and estimated time of completion (ETC) for trips within a customer-defined pickup window. The system shall automatically alert dispatchers to any deviations from the schedule and include a method of providing updates to riders via mobile app notifications or automated voice or text messages.

The system shall provide map views to visualize individual, multiple, or all vehicle routes, as selected by the user, that include real-time vehicle location and underlying street map, traffic information, and trip information.

5.10 Third-party Mapping (Google Maps, Google Earth, Bing

Maps, MapQuest) Overlay/Integration [Optional]

The system shall have the ability to utilize a third-party GIS subsystem for geographic information display when built-in GIS capabilities are not available. When both capabilities are available in the proposed solution, the Proposers shall provide a comparison of features available in both GIS subsystems in their proposals.

Proposers must describe any user-licensing terms and conditions associated with using third-party mapping products.

273 6 Paratransit Scheduling and Dispatching Software (PSDS)

274 6.1 Existing Trip and Client Database Conversion

The Contractor shall be responsible for converting the following databases from DDS Wireless ADEPT™ (existing software) at

SMART:

276 • Existing client database; and

277 • At a minimum, the most recent year client trip history.

The Contractor will work with the SMART Project Manager to develop a list of fields that will be converted from the existing database to the new database. This development shall include the logic required to populate fields in the new database that have no match in the old database.

In the event that certain fields within the existing client and trip history databases, and associated business logic to derive those fields are not supported in the selected system, the Contractor shall notify SMART and negotiations shall be held to determine the importance of the field and whether SMART will require customization of the system client database structure to incorporate new fields.

The Proposer must explain how the conversion is accomplished.

The proposal shall identify specific quality control procedures to ensure that data is accurately converted and to ensure its integrity.

Prior to performing any data conversion, the Contractor must prepare and deliver a data conversion plan to SMART for review and approval.

283 6.2 Client Registration

The client database shall include at least the fields shown in

Table 2. Specific characteristics associated with the entry of data elements are described after the name of the data field.

285 Table 2. Required Client Data Fields

286 Data Type/Data Field Name and Requirement

Demographics / Eligibility Determination/Client name. The system shall require entry of first name, last name, middle initial and suffix (e.g., Sr., Jr., III). When entering data, the system shall detect and alert the user if there may already be a client database entry under this name. Different clients with the same name shall be allowed.

Demographics / Eligibility Determination/Client’s date of birth.

The system shall require entry of the client date of birth using an interactive calendar interface or drop-down menu, or by entering the date manually. The system shall automatically calculate the client age, expressed in years, based on the current date and the date of birth information.

Demographics / Eligibility Determination/Client’s gender. The system shall allow for manual entry or for the field to remain blank.

Demographics / Eligibility Determination/Client’s eligibility status. The system shall allow user selection from a pre-defined list of eligibility definitions that include physical and mental disabilities as well as DHHS categories such as protective custody. An “other” category shall be provided to allow manual entry of explanatory notes.

Demographics / Eligibility Determination/ Income data to determine eligibility for low income programs. Income data is not required. If not provided, the client will not be eligible for certain trips available to low income individuals.

Address / Phone/Client’s home address. This text field becomes the default pickup address in the absence of another address that is identified as the default pickup address (see below in

Client’s common locations).

The system shall allow entry of an address that contains a “½” or

“c/o” and shall ensure that the full address is printed on the manifest (e.g., 123 ½ West Market St.).

Address / Phone/Client’s mailing address if different than the home address. This text field is used in case the client uses a non-street mailing address. The system shall allow entry of an address that contains a “½” or “c/o” and shall ensure that the full address is printed on the manifest (e.g., 123 ½ West Market

St.).

Address / Phone/Client’s common locations. The system shall allow multiple address entries for common client pickup locations. If none are entered, the client’s home address shall become the default pickup address. The locations shall be text fields and allow all characters necessary to accurately store and print on the manifest (e.g., 123 ½ West Market St.).

Address / Phone/Directions to assist in locating pickup address.

The system shall allow entry of a text field for special instructions for subsequent printing on manifests to assist in locating the client address. For example, where it is known that the actual address is different from the geocoded address, this would be noted in this text field for the manifest

Address / Phone/Client phone numbers. Multiple fields for home phone, work phone including phone extension, mobile phone and phone number where messages can be left (if different from other phone numbers). The system shall require that one of these numbers is identified as the default client contact phone number. All fields that contain phone numbers shall contain the standard 10 digits for a phone number (xxx-xxx-xxxx).

Address / Phone/Backup client contact. The system shall allow entry of a backup client contact phone number.

Contacts/Care-giver/emergency contact name, address and phone number to be used in the event of an emergency. The system shall allow entry of the name, address and phone number of a client’s care-giver/emergency contact.

Contacts/Caseworker/social worker contact name, address and phone number. The system shall allow entry of the name, address and phone number of a client’s caseworker/social worker.

Comments / Notes / Special Needs/Client’s mobility aid(s). The system shall allow entry in a field indicating whether the client uses a mobility aid. The system shall allow selection from among a list of pre-defined mobility aids that includes an “other” category and allows manual entry of explanatory notes. The system shall allow entry of more than one type of mobility-aid.

Comments / Notes / Special Needs/Disability status. The system shall require entry in a field specifying disability status.

The system shall allow user selection from a pre-defined list of disability definitions that includes an “other” category and allows manual entry of explanatory notes.

Comments / Notes / Special Needs/Client car seat. The system shall allow entry in a field indicating whether the client requires a car seat. The system shall allow entry of the type of car seat in a drop down box, with the following options listed: 5 point, High back, Flat and None.

Comments / Notes / Special Needs/Client mode restriction. The system shall allow entry in a field indicating if the client is restricted to a particular mode of transportation.

Comments / Notes / Special Needs/Manifest comments. This system shall allow entry of comments or information that will appear on all manifest trip entries for that client. The system shall allow a scheduler to view these comments and notes when taking a reservation.

Comments / Notes / Special Needs/Additional information. This system shall allow entry of additional information about the client in a text field. Information in this field shall not appear on any manifest trip entry for that client since it may contain HIPAA-sensitive information.

Funding / Billing/Authorization date. The system shall allow entry of a date defining when the client is authorized to begin receive service. If this field is left blank the client is authorized to receive service.