291
Attachment B Draft Technical and Functional Requirements Redundant Central System The proposer shall provide a detailed description of the proposed solution and price for a separate, physically redundant site located at the agency’s disaster recovery site in Sacramento. Proposers shall include any assumptions and information that would allow AC Transit to make a decision on this option. Proposers shall include any project management, design, installation, testing, and training costs associated with this option. AC Transit shall be able to purchase this option at the quoted price any time from NTP through System Acceptance. 1.1.1 Redundant Central Systems (Priced Option, not included in evaluation) NUMBER DESCRIPTION CODE ALTERNATE REQUIREMENT LANGUAGE FOR CM/E PROPOSAL SECTION REFERENCE 1.1.1.1.a The central system shall be fully redundant. The Contractor shall implement and integrate a parallel backup central system at a location separate from the primary central system. The backup central system shall maintain full operation indefinitely, with automatic and immediate failover if the primary central system becomes not fully operational. 1.1.1.1.b The central system shall have redundant connections to the cellular data WAN link, voice radio system WAN link, and AC Transit’s WAN to garages and user workstations. 1.1.1.1.c The backup system shall have provisions to connect temporary workstations directly to the backup system if needed. ERROR: REFERENCE SOURCE NOT FOUND 1

PROJECT SYNOPSIS  · Web view2014. 6. 19. · Protection shall be provided against radio frequency and electromagnetic interference (RFI/EMI) emission sources, as well as internal

  • Upload
    others

  • View
    3

  • Download
    0

Embed Size (px)

Citation preview

PROJECT SYNOPSIS

Attachment B

Draft Technical and Functional Requirements

Redundant Central System

The proposer shall provide a detailed description of the proposed solution and price for a separate, physically redundant site located at the agency’s disaster recovery site in Sacramento. Proposers shall include any assumptions and information that would allow AC Transit to make a decision on this option. Proposers shall include any project management, design, installation, testing, and training costs associated with this option. AC Transit shall be able to purchase this option at the quoted price any time from NTP through System Acceptance.

Redundant Central Systems (Priced Option, not included in evaluation)

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The central system shall be fully redundant. The Contractor shall implement and integrate a parallel backup central system at a location separate from the primary central system. The backup central system shall maintain full operation indefinitely, with automatic and immediate failover if the primary central system becomes not fully operational.

The central system shall have redundant connections to the cellular data WAN link, voice radio system WAN link, and AC Transit’s WAN to garages and user workstations.

The backup system shall have provisions to connect temporary workstations directly to the backup system if needed.

When the primary system becomes available after an outage, the backup system should automatically revert operation back to the primary system.

Redundant central site servers shall be located at the Disaster Recovery site in Sacramento.

Hosted Central System

The proposer shall provide a detailed description for a vendor hosted central system solution. This shall include any assumptions and information that would allow AC Transit to make a decision on this option. Proposers shall include any project management, design, installation, testing, and training costs associated with this option. Proposers shall also identify how this option differs from the proposed technical solution with respect to delivery, implementation and warranty.

Additional Onboard Equipment

As part of the proposal, a comprehensive list of unit prices for all onboard equipment provided as part of the deployment shall be provided. AC Transit shall be able to purchase additional units, without limitation, at the quoted prices for three years following system acceptance.

Additional Contractor Provided Software Licenses

As part of the proposal, the Proposer shall provide a comprehensive list of unit prices for all software licenses delivered as part of the deployment. AC Transit shall be able to purchase additional software licenses, without limitation, at the quoted prices for three years following system acceptance. All additional software modules or functions not purchased or installed prior to system acceptance shall also be included as part of this price list and installation prices shall also be included.

Extended Hardware Warranty

As part of the proposal, the Proposer shall provide a unit price for AC Transit to at its option, extend the warranty for all hardware by a period of one (1), two (2), three (3), or five (5) years. AC Transit shall be able to purchase any of these warranty extensions at the quoted prices for up to the conclusion of the original warranty.

Extended Software Maintenance and Warranty

As part of the proposal, the Proposer shall provide unit prices for extended software maintenance services and warranty, for a period of one (1), two (2), three (3), or five (5) years. AC Transit shall be able to purchase any of these warranty extensions at the quoted prices for up to the conclusion of the original warranty.

Additional Training Vouchers

As part of the proposal, the Proposer shall provide unit prices for training vouchers for the training sessions provided as part of the deployment. Each voucher shall be redeemable for a class listed in section 15.2 for additional specific training with a stated maximum number of students in the session. AC Transit shall be able to purchase these additional vouchers at the quoted prices for up to three years following system acceptance.

Part II: Technical Requirements

Proposers are required to submit a completed Compliance Matrix indicating compliance with the System Requirements. Proposals received without a Compliance Matrix shall be rejected as non-responsive. A single response must be provided for all system requirements in the Compliance Matrix. Proposals with missing, incomplete, or ambiguous responses in the Compliance Matrix may be deemed non-responsive. Proposers must indicate compliance with system requirements as defined in the table below. Proposers are encouraged, but not required to reference other sections in the proposal that describe more fully the features called for in the Compliance Matrix.

Proposers shall clearly indicate in the Proposer’s written Technical Proposal:

whether or not the solution for any requirement is not included in the Proposer’s product as “Off the Shelf” (i.e. will require development), and

for all responses indicating “E” clearly describing how the solution exceeds the requirement.

Response Code

Definition

F

Fully Compliant – Function or feature fully complies with AC Transit’s requirements. Responses that are qualified by exceptions or limitations, etc. in the Compliance Matrix shall be considered the equivalent of “N” (does not comply).

E

Exceeds Requirements – Function or feature provided is both fully compliant, and exceeds AC Transit’s requirements. The Proposer shall provide alternate requirement language to AC Transit’s requirement, to which they commit to fully comply. AC Transit can opt to use either the alternate requirement language or the original language – in both cases the Proposer will be understood to be fully compliant (“F”).

CM

Complies with Modified Requirement – Proposers shall provide suggested alternate requirement language to in the comments column of the compliance matrix. The “CM” will be equivalent to a response of “F” if AC Transit opts to change the requirement as proposed, or to a response of “N” if AC Transit opts to not change the requirement. If alternate requirement wording is not proposed in conjunction with a “CM” response, the response shall be considered “F” for the requirement as originally worded.

N

Does Not Comply – Proposer does not comply with AC Transit’s requirement. Accompanying comments are discouraged.

AC Transit reserves the right to request more information for all responses listed.

Central SystemsHardwareGeneral

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The central system shall provide all needed functions defined under these specifications, delivered in a turnkey manner where any equipment, software or work needed to create a complete system are part of the Contractor scope even if not explicitly referenced.

System hardware shall include at minimum all needed computer processing devices, keyboards and navigation devices, and displays for devices, workstations and servers as well as for all networking and communications equipment.

The central system shall reside on an AC Transit IT subnet, as opposed to being a separate “stand-alone” network.

Central site servers shall be provided with the following redundancy features:

1. All disk arrays shall be fully redundant on all servers with automatic failover.

2. Hot standby or clustered servers shall be provided with automatic failover to maintain full CAD/AVL functionality in the event of a complete or partial server failure.

The system shall include a data archiving and retrieval solution which will be approved by AC Transit.

The system design shall meet AC Transit standards for data recovery. These will be provided by AC Transit during the initial design phase

The system shall be designed for continuous operation without the need to manually “reboot” computers or devices. Necessary scheduled reboots shall not impact day-to-day operations.

System availability shall be 99.99% or better. For central systems, non-availability shall be determined by dividing total out-of-service time by total operating time. Out of service time shall include unplanned system maintenance only.

The central system shall automatically recognize any stoppage, failure, failover, or lock-up of a process and automatically log the problem, attempt a restart if appropriate, and notify control and the system administrator.

All system Graphical User Interface (GUI) displays shall be created within one (1) second from user request at a workstation physically connected to the network.

Radio voice call setup time – the process of Radio call set-up (when a controller requests that the system have a mobile radio go to a talkgroup, notify the operator to pick up the handset, and notify the controller that the call has been set up) shall be completed at least 95% of the time in five (5) seconds or less and never require more than ten (10) seconds. This call setup procedure shall not require more than two (2) mouse clicks to complete. Termination of the call shall be completed within one (1) second.

Automatic Group Data Updates With Selected Functions – When a controller selects a function that involves a group of vehicles the position and status data for the vehicles being displayed shall be updated by the system within ten (10) seconds of the selection. The vehicle/operator information available on the regular display shall also be available on these special displays.

The system shall report the updated location of any vehicle within ten (10) seconds of request from OCC.

The system shall report location of all GPS-equipped assets within a Controller selected geographic region, within 30 seconds of request from OCC.

All displays shall use pedestal mounted “flat screen” LCD technology with minimum 22 inch diagonal measure, with four (4) displays provided (including pedestals) for each workstation position.

CAD/AVL and Radio functions for each controller workstation shall be performed using a single keyboard and mouse, with a separate keyboard and mouse for administrative activities (standard AC Transit utilities such as email, internet, and MS Office suite).

The system shall be integrated with the data communications system. The system shall lose no functionality if AC Transit changes cellular providers to use cellular technology that operates at similar or higher speeds.

Dragging the cursor bar for a scrollable list shall cause instantaneous redisplay of the list in time with movement of the cursor bar.

Faults detected on field equipment (detected and transmitted by VLU) shall raise an alarm on the controller and maintenance computer within 60 seconds after receiving the alarm within the central system.

All system measurements shall be displayed in US Customary units (inches, feet, yards, miles). All system measurements shall be stored in US Customary units (inches, feet, yards, miles).

The system shall be time synchronized with AC Transit’s Microsoft Domain Controller NTP servers.

The system shall receive and store from each unit the location latitude/longitude information associated with the unit, along with date, time, vehicle, block, operator, run, route, trip, and odometer reading.

Unless otherwise specified, all central (office) and redundant central systems’ Contractor provided equipment shall have a minimum 40,000 hours MBTF.

All network hardware shall at a minimum, meet AC Transit hardware standards. The proposer shall identify in this proposal any proposed alternatives to these standards.

Unless otherwise approved for selected onboard equipment, Internet Protocol (IP) references whether for internal or external use shall use a 4 octet IP address instead of Domain Name System (DNS) aliases. AC Transit will host and define these IP addresses.

Garage WLAN Access Points

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The Contractor shall provide wireless Access Point (AP) coverage at all AC Transit Bus Depots to enable WLAN connectivity for data exchange between the onboard VLU and the central system via the Bulk Data Transfer as defined in section 8.5.2.

The WLAN coverage area available for bulk data transfer at the garages shall include the shed/maintenance area where the vehicles are to be parked. The Contractor shall review the plans for each garage and design the optimal locations for the APs (including the orientation of antennas) to satisfy all bulk data transfer requirements. The APs shall be located such that the wireless link capacity between each vehicle parked in the coverage area and the central system is 54Mbps or greater at all times.

The VLU shall be able to authenticate automatically when the vehicles enter inside the Wi-Fi accessible zone and shall access the WLAN without needing manual intervention.

The WLAN equipment shall be rated for outdoor use or be installed in an appropriate weatherized NEMA 4x rated enclosure capable of withstanding direct water spray.

Lightning arrestors shall be installed to vendor specifications on all exterior APs.

The WLAN equipment shall be IEEE 802.11n compliant.

The WLAN equipment shall be IEEE 802.11i compliant or shall be Wi-Fi Protected Access 2 (WPA2) certified by the Wi-Fi Alliance with AES encryption. Each single AP shall have a minimum 2x3, Dual Frequency, MIMO configuration.

The APs shall support 5.0 GHz frequencies. The APs shall be capable of supporting multiple SSID’s and assign separate SSID’s to separate VLANs. The APs shall be able to support WMM (Wi-Fi multimedia).

The Contractor shall provide a WLAN controller at all three garages. The WLAN controller and wireless APs shall support the following functions:

1. The WLAN controller shall automatically detect and configure the wireless APs.

2. The WLAN controller shall provide full control of the wireless APs.

3. Wireless APs shall monitor radio frequency characteristics including receive signal strength, noise, and interference (from other 802.11 radios) on all channels in its operational frequency band. The data shall be collected and analyzed by the WLAN controller.

4. The WLAN controller shall use the real time radio frequency monitoring information received from the Wireless APs to optimize the WLAN capacity.

5. The WLAN controller shall assign radio channels to each Wireless AP to avoid interference and channel conflicts.

6. The WLAN Controller shall dynamically control the transmit power of each Wireless AP to maximize WLAN coverage and performance while minimizing interference with neighboring Wireless APs in the WLAN system.

The Contractor shall coordinate all installation activities for the WLAN at the garages with the AC Transit Project Manager. No installation shall occur until the contractor has been given clearance to proceed by AC Transit.

Network Hardware

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

AC Transit will provide the physical network and networking equipment for the CAD/AVL to connect all system equipment (e.g. controller consoles, servers, WLAN access points) using its existing corporate network.

System Test/Development Environment

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The central system shall include a separate System Administration and test/development environment installed at the AC Transit Operations Control Center. For test/development, this environment shall be entirely disconnected from the production central system, which shall enable potential changes to the software configuration to be developed and tested at AC Transit prior to the implementation in the production central system.

The central system test environment shall incorporate sufficient hardware and software to comprise an adequate small-scale representation of the entire production system including servers, workstations, databases, storage, networking, onboard equipment, onboard equipment interconnections, voice communications and data communications. Two CAD/AVL training units simulating bus conditions shall be used as part of the test/development environment after their need as part of the training is complete.

This workstation shall be configured identically to the other workstations. User privileges shall be defined by the user account setup and granted upon login.

The central system test/development hardware, software and communications configuration shall be approved by AC Transit as part of the design review process.

Workstations

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

All workstations shall use Dynamic Host Configuration Protocol (DHCP) for IP address assignment, unless otherwise approved by AC Transit.

The Contractor shall provide and implement hardware for AC Transit with capacity adequate to support AC Transit applications and other Contractor applications involved in the solution, maps, data, and associated files required for operation, with 100% expansion capacity of the specified hardware.

Electrical and Environmental

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The contractor shall specify any additional power requirements for the Proposed CAD/AVL back office equipment.

All servers, wiring, network, back-up power/filtering units shall fit within 19 inch racks, and meet seismic zone 4 code requirements. All wiring shall be clearly labeled and physically supported using support devices that are compatible with the supplied racks. Plans for rack layout shall be submitted in advance for approval by AC Transit.

Each rack shall include an integrated mounted Keyboard, Video and Mouse (KVM) console.

Equipment installed in AC Transit offices or facilities shall operate from a nominal line voltage of 120 or 208 Voltage Alternating Current (VAC), within voltage tolerances of +10% to -10%, and a frequency range of 57 to 64 Hz.

All device enclosures shall contain an easily accessible master circuit breaker that shall remove power from the equipment when tripped. Circuit breakers shall clearly indicate when they have been tripped.

All enclosures, chassis, assemblies, panels, switch boxes, terminal boxes, and exposed metal equipment shall be grounded.

Conductors carrying 50 volts or more shall not be bundled with any lower voltage conductors.

Wire dress shall allow sufficient slack for three additional “re-terminations” without excess tension.

Wire splices shall not be permitted.

Wire and cable ties shall not be so tight as to cause indentation and damage to the insulation.

Adhesive-mounted bases shall not be used to support wire ties or cable supports.

All conductors within each enclosure shall be installed free from metal edges, bolt heads, and other sharp or interfering points.

All conductors providing connections between components shall be provided with strain-relief, and be clear of moving objects that could damage either the conductor or the object.

Where wires pass through openings, appropriate bushings shall be provided to protect the integrity of the wiring insulation.

All terminations and cables shall be clearly indexed, labeled and schematically identifiable.

All wire labels shall be non-metallic and shall resist standard lubricants and cleaning solvents.

When components are connected to each other through individual wires, the wiring shall be incorporated into a wiring “harness,” where each branch of each circuit can be separated from others for troubleshooting.

Protection shall be provided against radio frequency and electromagnetic interference (RFI/EMI) emission sources, as well as internal conductive or inductive emissions.

The Contractor shall be responsible for securing all relevant electrical certifications and shall be responsible for any costs associated with the certification process and/or inspections.

Office installed equipment shall maintain specified performance while operating in a controlled environment of +32°F to +110°F and relative humidity (non-condensing) of less than 90%

SoftwareGeneral

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

Core CAD/AVL operational components (controller workstation, servers, WLAN access points via firewall, remote access servers, etc.) shall reside on separate virtual LANs on this network within an address space and numbering convention to be provided by the agency.

Management information, reporting, and general purpose workstation shall reside on AC Transit’s corporate LAN and the Contractor shall be responsible for providing any interfaces required in order to make CAD/AVL applications available on those workstations without the need to procure or use a separate workstation for the CAD/AVL functions.

The Contractor shall develop a comprehensive System Security Plan, which identifies the system elements that require protection, potential threats and risks, and mechanisms, procedures, and processes to deter, detect, and neutralize such threats and risks. The plan shall also identify any expectations or responsibilities of AC Transit related to the provision of system security. This plan must be reviewed and approved by AC Transit.

The system shall provide AC Transit configurable access control based on AC Transit’s Active Directory Logons for the following user groups and classifications:

0 .User groups will be based on the major system functions to be provided and will be determined as part of the system design. Examples include system administrators, controllers, etc. A minimum of ten (10) user groups shall be supported.

1 Each user group shall support a minimum of four (4) user classifications such as “User”, “Super User”, “Supervisor” and “Administrator”.

2 The system shall include functionality to assign a master set of privileges to each user group and activate a certain subset or combination of privileges for each specific user classification.

The system shall include reasonable flexibility to add, delete and modify the user groups and classifications, and to adjust the privileges assigned to each classification as part of normal system operations.

AC Transit will be responsible for assigning all system access privileges, and the Contractor shall comply with AC Transit requirements for strong password protection and password change policies. Password change policies may be different between central site servers, controller workstations, and on-board equipment.

Passwords shall be displayed encrypted.

User and database schema owner password maintenance shall include the ability of the user to periodically change passwords in a simple and straightforward manner.

Preference shall be given to implementation which provides the user with a single Graphic User Interface (GUI) based password change mechanism. No password shall be embedded at the user workstation level, and no password shall be unencrypted at the application server level.

The Contractor shall adapt the CAD/AVL user authentication mechanism to integrate with the existing server authentication system at the time of system acceptance using a design consistent with current architecture.

The system shall allow AC Transit personnel with assigned privileges to reset forgotten passwords.

Application logons, logoffs, and failed logons shall be logged, secured, and available in a report for auditing purposes.

At a minimum, the CAD/AVL software shall provide the following alarms to AC Transit specified groups:

A network device or communications fault;

A security breach;

A device fault;

A failed or incomplete data transfer; and,

Server services failure.

All alarms shall be logged and stored in a database along with a history of corrective actions. Users with associated privileges shall be able to manually override alarms. Alarms that are manually overridden shall reactivate at a System Administrator – defined period until corrective action is taken and the alarm cleared.

The CAD/AVL software shall generate a device status report for queried vehicles that provides all mutually agreed onboard devices in use, which vehicle they are assigned to, date of last software or firmware update, current software or firmware version, and current schedule, route and stop version information; and system faults during the day.

The system shall include generate and disseminate real-time transit traveler information to the regional 511 system, agency-owned infrastructure, and web/mobile services.

The system shall update real-time arrival predictions and generate service alerts based upon real time service adjustments and measures implemented by Control, including:

1. Cancelled Service;

2. Detours (planned and ad hoc);

3. Drop off only; and

4. Additional of supplemental service (‘trippers’) in addition to scheduled trips.

Real-time arrival predictions for services operated under headway management mode shall report predicted arrival times based on actual arrivals rather than scheduled arrivals.

The system shall automatically generate and implement real-time arrival information adjustments and service alerts based on real-time service conditions and CAD measures. At no time shall information presented through the real-time passenger information system contradict actual expected service based on real-time conditions.

Network

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The system shall be an end-to-end IP based solution.

The Contractor shall provide documentation describing in detail their monitoring applications for servers and other central systems necessary for the CAD/AVL system.

Database

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

All software shall use the Microsoft SQL server relational database management systems, for consistency with the overall software environment at AC Transit.

All software shall provide a comprehensive purge capability that minimizes database storage requirements and purges archived records from online storage.

The contractor shall provide a comprehensive data archive, backup, and recovery plan and the equipment and systems necessary to implement the plan.

The system shall incorporate all needed hardware and software tools to archive and un-archive data offline, and to restore any data to online systems needed for system recovery.

Functionality shall be provided to execute routine backups through AC Transit’s existing network backup system. Contractor software shall be configured to work with AC Transit backup software daily or weekly to backup all critical components.

The contractor shall provide specifications for the archival database to hold a minimum of five (5) years of data based on the contractor estimated space requirements.

The contractor shall provide secure long term databases that will hold a rolling 3 years of all CAD/AVL data retained for claims and legal purposes.

CAD/AVL SoftwareGeneral

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The contractor shall supply a full-featured (by industry standards) CAD/AVL software functionality that has been previously proven in transit operations.

The CAD/AVL software shall be integrated with the data communications system. The CAD/AVL software will lose no functionality if AC Transit changes cellular providers or cellular technology that operates at similar or better speeds.

CAD/AVL software shall be able to detect failures and restart processes automatically.

CAD/AVL software shall continuously check for service failures and relay status on the CAD/AVL display.

The CAD/AVL software shall allow controllers to seamlessly switch the handset between the voice radio and telephone headset.

CAD/AVL software functional capabilities shall be the same across all controller workstations provided for the system.

The CAD/AVL software shall provide representation and management of fixed route service by the following:

1. Run: This refers to the complete piece of work for an operator (duties) that may include vehicle changes during the course of the day.

2. Block: This refers to the complete piece of work for the vehicle or driver, which may include multiple routes/interlined trips, and operators.

3. Route: This refers to the overall route identifier, under which there would be a series of patterns.

4. Trip: This refers to a specific one‐way trip for the vehicle related to start/end times and points.

5. Timepoints/Stops: Timepoint refers to a point along a route where trips are assigned arrival or departure times. A stop is defined as an established location where public transport customers may board or alight from a transit vehicle in revenue service.

The system shall include a user interface that is user friendly, accessible, and intuitive for all users.

The CAD/AVL software shall use typical MS Windows‐style GUI conventions such as resizable windows, point and click, right click context menus, drop‐down menus, toolbars, color displays, icons, drag and drop, scroll bars, scroll Wheel mouse, status bars, etc.

The CAD/AVL software shall support mouse and keyboard inputs with all key features supported by keyboard shortcuts.

The CAD/AVL software shall provide easy‐to‐read displays when controllers are situated a standard distance from the display (i.e. 20/20 vision at a distance of three (3) feet).

The CAD/AVL software shall allow individual controllers to:

1. Logon with appropriate password;

2. Logoff; and

3. Enter standby or “break” mode that will automatically transfer work assignments to another controller without requiring controllers to logoff the system.

A minimum of three (3) levels of CAD/AVL software access shall be allowed including:

1. Supervising Controller – Ability to adjust all CAD software preferences

2. Standard Controller – Ability to adjust preferences (such as vehicle status color indications or icons)

3. System Administrator – Ability to adjust all CAD/AVL software preferences

The CAD/AVL software shall save all user preferences by user logon so that users may access their saved preferences from any CAD workstation.

Access to the CAD/AVL software shall be managed by a single sign‐on solution that integrates with AC Transit’s existing network authentication system at the time of system acceptance.

The CAD/AVL software shall allow users to automatically reset forgotten passwords by use of a security question.

The CAD/AVL software shall provide an onscreen indication showing controller status for all workstations including incident queues, active calls, etc.

All CAD/AVL workstations shall provide user friendly on‐line manuals and help functions.

Drop down menus or equivalent shall allow controller access to PDF versions of AC Transit procedures, phone database tables, processes, and read/write to checklists.

The system shall allow controllers to remove a specific vehicle from the voice and data communications reporting set for a configurable (by AC Transit) amount of time.

The intent of this is to limit communication error messages at OCC when a vehicle is experiencing a long‐term voice and data communications issue.

The system will maintain a log of all messages and incidents, which can then be sorted and accessed by all available fields to include specific incident, incident type, date, operator, controller, and other fields.

The system shall notify AC Transit customer service automatically by email and/or CAD/AVL text messaging of significant service disruptions, such as unusual delays, incidents, detours, or missed trips. The criteria to determine “significant” shall be configurable by AC Transit.

The CAD/AVL software shall allow the controller to designate and/or undesignated specific stops, routes or blocks “free running.”

Schedule adherence shall not be indicated to operators, supervisors, or controllers for routes or blocks designated as “free running.”

The CAD/AVL software shall provide the following basic views, which can be sorted by all available fields, in addition to the message queues:

1. Map displays (allowing for multiple map windows and zoom settings);

2. Route displays indicating vehicles relative to stops along a route;

3. Vehicle lists of all vehicles active in the system;

4. Operator lists of all operators logged into the system;

5. Trip lists of all trips currently active in the system;

6. Incident or event lists (for work assigned to controller or vehicle‐specific) which shows all actions conducted through the CAD/AVL;

7. Summaries of pull‐out/pull‐in status by first/last timepoint, location, block, and depot in separate summaries;

8. Linear headway display (“Bus Spacing” display); and

9. Operator First Name, Last Name, and employee ID.

Controllers and Street Supervisors shall have the ability to filter the vehicle location display by the following options:

1. Runboard (e.g. Regular or Special)

2. Route number;

3. Route pattern;

4. Trip;

5. Division;

6. Vehicle type;

7. Vehicle number;

8. In‐service and on‐schedule (by an AC Transit configurable period);

9. Behind schedule (by an AC Transit event configurable period);

10. Running early (by an AC Transit configurable period);

11. Out of service;

12. Last known location of powered down vehicles;

13. Not logged in;

14. Emergency/panic alarm activated;

15. Off‐route (by an AC Transit configurable distance);

16. Communications status; and

17. Free Running Time.

Other filters shall be able to be added easily by the AC Transit system administrator.

It shall be possible for routes to be assigned to multiple controller roles (e.g. fixed route controller, AC Transit personnel, or street supervisor) simultaneously by some or all of the same criteria listed in the above requirement.

Workstations shall be integrated and appear to controllers as a seamless integrated solution regardless of the number or types of applications actually running.

The system shall support and provide displays of operator, trip and vehicle rosters/lists.

The system shall automatically write to the CAD/AVL database when vehicle is at a normal layover schedule and location point.

The system shall allow operators to indicate that vehicle is in layover status if layover occurs at a non pre‐assigned layover point.

The software shall accommodate a “fictitious” block for training or testing purposes. A controller shall be able to insert this block at any time without disrupting regular service block.

The system shall provide controllers with interlining information about a specific route, block or vehicle.

Interlining information shall be used by the system to identify impacts of late pullouts, detours and/or bus‐bridge assignments and notify controllers of these impacts.

System shall provide AC Transit customizable route attributes, (e.g., high frequency, interlining routes, etc.) allowing for route prioritization in different classifications.

CAD/AVL software shall allow for planned special events with additional supporting functions such as:

1. Predefined special routes,

2. Predefined detours,

3. Predefined text messages, to operators for the event buses.

Mechanics, engineers, trainers, etc., that are operating buses, shall have unique login identification so that CAD/AVL software can identify and track and correlate with non‐service status including:

1. Training,

2. Dead‐head,

3. Replacement vehicle, and

4. Testing.

The system shall not allow duplicate block ID’s with operator logon. If more than one (1) operator logs onto the same block, an automated message shall be sent to both operators to verify login. The situation shall also generate an automated message to OCC.

CAD/AVL software shall allow controllers to update the status of unassigned Operators as “Available” or “On‐Assignment.” This status update shall be available on all controller workstations.

All incoming incidents to each CAD/AVL console shall be able to generate an audible tone(s) to notify the controllers. All audible alarms shall be adjustable, in both volume and tone, by the system administrator.

All drop‐down look up menus shall allow manual alphanumeric input to select desired item(s) (i.e. Combo box). The intent of this feature is to eliminate the need to scroll through a list to find the desired item.

CAD/AVL software shall support the ability of controllers to issue special instructions to ad hoc or predefined geographic areas (e.g., area around an intersection, transit center, yard, etc.), which the controller can select to be sent either to routes crossing through the defined zone or to all vehicles within the selected area.

CAD/AVL software shall provide real‐time notification to controllers of significant traffic delays and road closures. Information shall include only incidents that cause delay and are part of a transit route, and shall note lanes blocked, start time of incident, and anticipated clearance of the traffic incident.

CAD/AVL software shall provide controllers with the appropriate contact information (including phone numbers and radio talk groups) for agencies during incidents, based on coach location within specific jurisdictions.

CAD/AVL software shall allow for geographic distribution of functions among OCC controller positions. For example a functional work split might include one controller focusing on all maintenance, incident and/or event issues, while others focus on service management (on‐time performance, and connection protection) or route‐based management.

Diagnostic and troubleshooting information shall be accessible through the Central System or Remote Dispatch Application (RDA) by a Controller or Street Supervisor to assist Operators with troubleshooting MDT problems

Contractor system shall support the capability for OCC to indicate that a bus stop is not in service, and have that information propagate to all routes and lines serving that stop.

Vehicle Tracking

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

Controllers need to be able to “track” a particular vehicle or portable radio by selecting each from a list of all available devices to be displayed on the AVL map.

The performance and output of the CAD/AVL data and mapping software must be accurate, correctly reconciling to stop and street locations.

All OCC workstation displays and information (on a single workstation, as well as across all workstations) shall be consistent and show current and identical status within ten (10) seconds of one another.

The base frequency for updates to the location of each vehicle on the data network shall be no longer than every 30 seconds. Any messages sent to/from the vehicle shall force a location update.

The system shall indicate any vehicle that is not reporting back on regular intervals and/or over multiple polling cycles.

CAD/AVL shall be able to accept location data from sources without MDTs, such as nonrevenue vehicles and portable radios, and display all resources as distinct layers and icons on the CAD/AVL maps.

CAD/AVL system shall track location and status of any GPS enabled device, such as nonrevenue vehicles including field supervisors, maintenance, transit security, etc. These shall be illustrated as different icons for vehicle type and status. Other than the GPS enabled devices supplied under this work, AC Transit will be responsible for supplying the GPS data feed. Contractor will provide required input parameters and access into the CAD/AVL software.

CAD/AVL system shall allow the controller to enter known cancelled blocks of service in advance, and this information shall be made available to other components of CAD/AVL such as pull‐out status, all performance summary displays, etc.

The CAD/AVL software shall allow user(s) to manually relocate stale and/or non-communicating coaches to an AC Transit defined location (e.g. vehicles towed to garages).

The CAD/AVL software shall be configured to allow customized filtering of GPS enabled devices by preconfigured groups (e.g. customer service, fare technicians, supervisors, etc.) tracked by real‐time GPS coordinates.

CAD/AVL software shall be able to query the system at regular intervals to determine the location and number of buses that have not moved but should be moving (e.g. “Stuck”) within specific, AC Transit‐configurable time periods. The CAD/AVL software shall be able to show all stuck vehicles simultaneously on the AVL map. Automatic notifications shall be sent to Control when such vehicles are identified, as well as when a stuck vehicle begins moving again (e.g. “Unstuck”).

Communication

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The Contractor shall interface the CAD/AVL central system hardware and software with the voice radio consoles installed by AC Transit (Motorola MCC7500).

The voice radio consoles interface shall allow the controllers to set the voice radio consoles talkgroup using the CAD/AVL software.

The system shall set the priority of incoming calls through an alarm function. This shall be set through a series of AC Transit configurable parameters that the incident recorder selects as information is entered into the system.

Communications status shall be displayed to controllers where: communications with a vehicle are lost, recent position reports for a vehicle are not available, and sent messages that were not received due to communications failure. This shall be displayed as an icon or similar on both the message queue (as appropriate) and the AVL display. The parameters for these communication status notifications shall be configurable by AC Transit.

When an item from the queue is selected, the system shall automatically provide controllers with vehicle information such as route, block, schedule, interlining and transfer data as well as operator information including full time, part time, regular, regular relief, extra board, and vacation relief.

The system map shall center on the vehicle when the controller selects a message or incident related to that vehicle. This feature shall be configurable by AC Transit, based upon message type, and/or by having the controller select a message with the zoom/center option.

All CAD functions shall be supported by automatic messaging to trips/vehicles/operators and confirmation messages to OCC, and shall be logged in the CAD/AVL database.

CAD/AVL shall provide a summary table or display that demonstrates the level of communications “reliability” with vehicles currently in operation.

All route or vehicle specific data communications (text messages or controller actions) shall be saved and forwarded to or from vehicles that may be out of communications at the time of the origination of the message (up to either a preset duration on the message or within a single operations day). Once the system confirms that communications have been re‐established, the fixed‐end or mobile equipment will resend the saved message. Once data communications have been re‐established the fixed end and mobile VLU/MDT gear shall send duplicate messages only one time until “acknowledged” by the recipient” via a data “ack” message.

The CAD/AVL software shall provide controllers with the ability to temporarily suspend vehicle late threshold and late‐pull out threshold status messages from appearing in the status message queue.

The CAD/AVL software shall allow for the potential to integrate with the AC Transit phone system that will allow controllers to use a single headset to switch between the phone and voice communications systems.

CAD/AVL shall support a RTT, PRTT, and EA method of voice radio communications.

Voice communications RTT, PRTT and EA requests shall be separately highlighted and displayed in the communications queue.

Only one (1) RTT and PRTT shall be displayed in the queue for each vehicle attempting to make a call. A PRTT will replace a RTT should the vehicle change from RTT to PRTT, whereas repeated presses of RTT or PRTT will simply update the existing message in the communications queue.

Controllers shall be able to initiate voice communications by double‐clicking RTT or PRTT messages.

Once connected, the message will display as being handled by the connecting controller on all workstations displaying that message.

RTT and PRTT shall not disappear off the communications queue until such time as they are dealt with by a controller or deleted by a controller.

PRTT shall be displayed as the highest priority in the communications queue with the exception of emergency alarms.

All queue priority levels and destinations (i.e., database only, specific controllers, etc.) shall be configurable by AC Transit personnel or system administrator.

Controllers shall be able to select a listen‐in or default talk‐group which will transmit all voice communications for that talk‐group until another mode of communications is selected. This shall not interfere with controllers’ ability to perform other voice calls.

Controllers shall be able to initiate voice communications by selecting voice communications function:

1. On a vehicle on the AVL map

2. Pressing the appropriate hot key

3. Pressing a function specific icon on the CAD/AVL display

4. On the specific vehicle in the vehicle list, specific block or run list, or operator badge/name list

5. Dragging around (or rubber‐banding) selection on the AVL map around an area with communications to each vehicle within the selected areas

6. Selecting the route, yard, or specific vehicle IDs (VIDs) for communications

The system shall notify the controller when the call cannot be setup and present the controller with a choice to cancel the call or to continue trying to set up the call and notify the controller when it was successful.

The system shall notify the controller visually and by tone when a call has connected and the controller may begin speaking.

Controllers shall be able to conduct the following type of voice calls:

1. One‐way group calls between the controller and multiple vehicles defined by:

a. Individual and/or multiple route(s) (including all vehicles currently interlining on that route)

b. Specifically identified vehicles

c. Rubber band or map selection of all vehicles within a selected area in the map

d. Predefined graphical areas

e. By all buses from a specific Division/depot

f. By all buses in the fleet

g. Conference calls between OCC, buses, and support vehicles.

2. PA announcements on‐board a specific vehicle or group of vehicles as defined in (1) above.

3. Calls to a predefined talkgroup.

System shall automatically and immediately locate and update vehicle information (route, location, status, etc.) when controller takes a call.

The system shall automatically notify controllers after a certain, AC Transit configurable amount of time has passed, that a call or event has not been resolved/closed. The automatic notification shall be completely configurable by the AC Transit for the time and event type. AC Transit personnel shall be able to override the preset notification time frame, up to double the preset time.

Calls initiated from portable radios to OCC shall provide a unique radio ID, which will be correlated with a name assigned to the radio and displayed to the controller.

Controllers shall be able to interrupt active radios over the air.

The CAD/AVL software shall support the ability for controllers to be able to switch between headsets and microphones during voice communications.

System Administrator shall be able to disable/deactivate active mobile and portable radios over the air.

A “right click” on a message in the queue shall provide the controller an option to open a voice call to the message initiator.

Mobiles and portables shall be capable and configured for over the air programing (OTAP) when operated on a Motorola Astro P25 system.

The integrated CAD/AVL-Voice Radio System shall provide a private call capability to any bus through the use of the bus number and a keypad equipped radio. This will require a translation of bus number to radio identification number and a private call. The bus number shall be entered via the keypad directly, without having to scroll through and select a bus number from a list or menu.

Portable radios will include the functionality to initiate a private call to any bus through the use of the bus number and a keypad equipped portable radio. The bus number shall be entered via the keypad directly, without having to scroll through and select a bus number from a list or menu.

Portable radios will include the functionality to provide their GPS coordinates to the CAD/AVL system on a periodic basis, when queried, when an emergency alarm is activated, and when the “Man-Down” button or feature is activated.

Mobile radios on non-revenue vehicles will include the functionality to provide their GPS coordinates on a regular or ad hoc basis as determined by the CAD/AVL system.

The CAD/AVL system shall establish calls on the system for routine calls to individual vehicles. Other vehicles shall not hear these calls.

The dispatcher shall be able to dynamically establish 2-way communications with a selection of multiple buses.

CAD and Radio functions shall be performed using a single keyboard and mouse, with a separate keyboard and mouse for the administrative (standard AC Transit utilities such as email, internet, MS Office suite, etc.) activities.

The Radio dispatch consoles shall allow for the potential to integrate with the AC Transit phone system that will allow dispatchers to use a single headset to switch between the phone and voice communications systems. AC Transit’s current Dispatch phone system is Cisco Call Manager 7.0

All mobile and portable radios must support the emergency alarm functionality as defined in CAD/AVL and Communications System: Request for Proposals Scope of Work Section 8.4.5 – Emergency Alarm

Text Messaging

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The system shall provide two (2) ‐way text messaging between transit vehicles and controllers. Controllers shall have the capacity to initiate a text message by:

1. Selecting a message from the queue;

2. Selecting vehicle(s) from a list;

3. Selecting route(s), (including the option for all current and future vehicles interlining on that route) from a list;

4. Entering an operator ID, VID or group ID, Division ID;

5. Entering a route ID or block ID;

6. Rubber band or map selection of all vehicles within a selected area in the map;

7. Predefined graphical areas; and

8. Fleet wide.

The CAD/AVL software shall include “canned” (pre‐defined) and free form text messaging functionality to the fleet MDTs that will support a text message range with a minimum of one (1) character to 256 characters long. All canned messages shall be configurable by AC Transit.

The CAD/AVL software shall provide for a minimum 40 “canned” messages per device type (MDT, RDA, Desktop, etc.) that may be broadcast from vehicles with MDTs to control.

The canned messages shall be separable into three (3) categories:

1. Fixed route canned messages available on all fixed route vehicles;

2. Canned messages available through the CAD/AVL workstation;

3. AC Transit Configurable (future grouping) available for a separate to be defined vehicle subset;

Canned text message types shall be determined by AC Transit and configured into the appropriate MDTs and CAD/AVL software. Where appropriate, canned responses to canned messages shall be available to both the vehicle and controller, and responses will also be determined by AC Transit. Changes to canned messages will be uploaded through AC Transit WLAN.

CAD/AVL software shall allow controllers to request confirmation of acknowledgement (ACK) responses that indicates a text message was received and read.

Controllers shall be able to sort/filter the confirmation or acknowledgement responses in a summary table display by the following:

1. Acknowledged responses (including timestamp of when operators responded)

2. Date and Time responded

3. Non‐responding vehicles

4. Operator ID

5. Vehicle ID

The system shall automatically resend ACK request messages to all non‐responding vehicles after an AC Transit configurable amount of time has passed.

The controller shall be able to reply to a message in the queue in either a canned response or free‐form text message by double‐clicking on the appropriate message.

When a controller receives a message from a vehicle operator, the system shall display the route, block, vehicle, vehicle ID, operator’s name, employee number, location, route schedule adherence (RSA) or headway status, time and pattern.

Controller shall be able to schedule text messages to be sent at logon or at some future time, to notify operators of route changes, detours, or special announcements. Regardless of whether or not the message requires a response from the operator, there shall be a notification to the controller if the message was not received or viewed by the operator for some reason.

The system shall notify the controller if a text message was not received and allow the controller to cancel the message, or to continue trying and notify the controller when it was successful.

The system shall indicate the status (i.e. successful, failed, or pending) of sent messages in the message queue.

Controllers shall be able to filter, search, and sort messages in the text message queue by status, time, vehicle, operator, and division.

Controllers shall be able to cancel, recall, edit or modify messages. Cancelled and recalled messages shall be logged, but disappear from the visible message queue. Controllers shall also have the ability to access, modify and reinstate cancelled and recalled messages that are no longer in the visible message queue.

All changes made to messages and incidents shall be tracked.

Every message sent to a vehicle requires the receiving VLU to generate an automated acknowledgement that the message was received by that vehicle. All acknowledgement messages shall have a 95% (or higher) successful throughput, which shall be tested and verified during all stages of fleet installation.

The CAD/AVL software shall monitor the acknowledgement status of all transmitted data and automatically resend messages to vehicles that have not acknowledged.

The CAD/AVL software shall provide a tabular report for every sent message that has not been acknowledged by all expected vehicles, showing acknowledgement status by vehicle. This tabular report shall have the ability to cancel the message from further resending to vehicles that have not received or acknowledged the message.

The CAD/AVL software shall provide the ability for Controllers to send free form and canned text messages to the ASA readerboards.

Emergency Alarm

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software shall support emergency alarms (covert). When acknowledging an alarm the CAD/AVL software shall zoom and center the map display on the alarming vehicle and locate the nearest street supervisor vehicle when selected by the controller. The scale for the zoom shall be configurable by AC Transit.

The CAD/AVL software shall allow controllers to downgrade emergency alarms to a lower message priority, or upgrade lower priority messages to an emergency alarm. The CAD/AVL software shall log all alarm status changes (create, upgrade, downgrade, and cancel).

Activation of an emergency message shall place the vehicle in a priority status for frequency of location and message updates which will result in vehicle location and status updates at a rate that is configurable by AC Transit.

Activation of a covert alarm shall activate a covert microphone for “listen‐in” mode for an AC Transit configurable time, unless downgraded by a controller.

The CAD/AVL software shall provide a continuous audible alert to OCC when a covert alarm is activated until a controller acknowledges the alarm.

The CAD/AVL software shall provide an AC Transit configurable, audible and visual alert to OCC, Road Supervisors, and others using the system when an emergency alarm is activated, and the CAD/AVL system shall monitor that vehicle continuously until otherwise specified by OCC.

Controllers shall be able to prolong “listen‐in mode” or immediately re‐enable “listen-in” mode.

Other Alarms

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software shall be capable of indicating schedule adherence for all in‐service fixed route vehicles.

The default criteria for “running late” and “running hot” shall be AC Transit configurable in minutes behind schedule and minutes ahead of schedule. AC Transit shall be able to configure three levels in minutes for ahead of or behind schedule by route of globally. In addition, the CAD shall provide a separate AC Transit configurable “Late” parameter specifically to support transit signal priority (TSP) and other needs.

CAD shall allow early and late schedule adherence messages to be filtered so as not to display in the communications queue.

Schedule adherence shall be determined on the vehicles and communicated to the central system for display on the CAD workstations.

The CAD/AVL software shall generate an off‐route Attention Request (AR) message for vehicles deviating from routes by an AC Transit configurable distance. There shall also be a tool that allows the system to receive detour and alternate route information that prevents the off‐route notification when a bus is on the detour or alternate route.

CAD shall support reporting to downstream systems (e.g., Real‐time public information) the current vehicle path (e.g. Scheduled, Scheduled Detour, Unscheduled, etc.).

The CAD/AVL software shall generate an automated message for vehicles that have not performed a wheel chair lift test prior to pull out after an AC Transit configurable amount of time or if coach has crossed a geographic threshold.

Map Displays

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software shall include a map-based GUI. The GUI shall support various map views, with full zoom, pan and auto-centering capability. Users shall also have the option to display a tabular user interface and a schematic display for a given route.

The CAD/AVL software shall use GIS data from Tom Tom, as provided by AC Transit for the map display. Utility software shall be provided to enable AC Transit to independently incorporate future GIS data updates into the map.

The GUI shall allow CAD/AVL users to view the map, including a selectable combination of layers, at various user-defined zoom levels. Layers to be not displayed at each specific zoom level even when selected shall be configurable.

The GUI shall use color-keyed icons to represent vehicles based on schedule status and other attributes being tracked. The icon locations shown shall be updated based on the vehicle location as tracked by the system. The GUI shall indicate the vehicle identifier (up to 8 alphanumeric characters in length). The GUI should enable selecting vehicles to perform data transactions based on Vehicle ID, Block, Badge #, or Route/Run. Controllers shall be able to use the software to request an immediate update for the location of any given vehicle.

Icons shall be distinct for each type of fleet vehicle, and use color or other visual indications (e.g. other icon modifications, popup messages) to signify status. Thresholds for changes in indicated status changes shall be configurable (e.g. change from early to on-time and from on-time to late). The status configuration shall be defined through the design review process.

The CAD/AVL software shall be able to display different portable radio and other GPS enabled subgroups as unique icons and filter which of these subgroups are displayed.

The system shall also bring up the flags if the controller hovers the cursor over the resource location icon.

Icons shall allow for the display of an AC Transit configurable status such as:

1. In‐service and on‐schedule (by an AC Transit configurable period)

2. Behind schedule (by an AC Transit configurable period)

3. Running early (by an AC Transit configurable period)

4. Out of service

5. Not logged in

6. Emergency/covert alarm activated

7. Off‐route (by an AC Transit configurable distance)

8. Communications interruption

9. Vehicles at a layover

10. Last known location of powered down vehicles

11. Stale and/or non‐communicating vehicles

12. “Stuck” or non‐moving vehicles

13. “Available” for unassigned vehicles, Security, etc. available for use

14. “Unavailable” for resources responding to incidents

The digital mapping system shall be compatible with and able to import, all layers from AC Transit’s GIS data.

The controller shall be able to open, close, tile, or resize map windows.

The map display shall be capable of displaying a variety of geographic features with names. It shall be possible for controllers to independently set features to be visible or hidden by map layer without limitations on the numbers of layers. At a minimum, the map display shall display these features:

1. Freeways and highways (with appropriate shields and alternate names)

2. Major and minor streets (with appropriate names)

3. Rail track

4. Transit centers

5. Transfer points

6. Bus stops and stations

7. Landmarks

8. Rivers, lakes, and other major bodies of water

9. Parks

10. City, county, and police boundaries/ jurisdictions.

11. Agency maintenance yards

12. Airports, hospitals, police stations, fire stations, and schools

13. Any landmark designated by AC Transit.

The map view shall include functionality for pan, zoom in/out, window zoom, and multiple map displays. The map display shall be AC Transit configurable to display different levels of detail (such as street names) at different zoom levels.

The map view shall support multiple preset map windows accessible by tabs or other windows style methods. Controllers shall be able to configure map windows unique to their workstation logon.

The map display shall automatically update the display when new mapping, schedule, stop or spatial data becomes available to the CAD/AVL software.

The CAD/AVL software shall be capable of tracking the last known location and direction of powered down GPS enabled devices.

The controller shall be able to center a map view on a vehicle, or track a vehicle by:

1. Selecting the vehicle on the map display

2. Entering the block, vehicle, operator ID, or route

3. Selecting the vehicle from a list of vehicles

4. Selecting a message from the queue

5. Selecting the operator from a list of operators

6. Selecting the block from a list of blocks

Controllers shall be able to center a map view by entering a specific intersection and/or address or by clicking a location.

Controllers shall have the ability to create, delete and change map views specific to their log‐on profile.

The system shall include a function that allows for the identification of supervisor, and support vehicles and GPS enabled Security mobile and portable radios closest to an individual vehicle selected by the controller, and shall include the type and ID of the support vehicles or the portable radio.

The controller shall be able to review on the map display in a separate window the chronological sequence of reported locations for a specified GPS enabled device over a specified time period.

The software shall provide controls to view the entire sequence of reported locations accurately from the beginning of the time period or to step through the sequence incrementally forwards or backwards.

The system shall allow replay for a single GPS enabled device, selected set of GPS enabled devices or all GPS enabled devices on the selected map view for selected time period.

The system shall allow selection of any time period for the historical data.

The replay data shall include location reports, schedule adherence data or other collected information associated with the GPS enabled device available in the CAD/AVL software.

All users accessing the CAD/AVL software, including workstation users, shall be able to access the location playback function.

The CAD/AVL software shall allow the ability to switch easily between the operational and the flashback view.

Performance Summaries

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software screens shall provide access to a route display showing the locations of all vehicles in service along a specified route, along with supporting information such as:

1. Headways

2. Gapping

3. Schedule status

4. Scheduled departure

5. Current route

6. Next route

7. Controller action (added trip, etc.)

The software shall provide a service summary display that summarizes schedule adherence, gapping/bunching, headways, and status by route and geographical area.

Routes displayed for each controller shall be filtered to include either all routes or only those routes being currently operated. This service summary data shall be captured in an easily readable report format.

The CAD/AVL software shall provide tables displaying all current schedules and adherence by route, block, branch, vehicle ID, stop pattern and operator.

Performance summary displays shall allow for “drill‐down” selection by controllers where a controller can select a route of interest and bring up the associated route display. From the route display, controllers shall be able to bring up block and vehicle tables.

The software shall provide a pull‐in/pull‐out summary display for controllers that can be sorted by status of lateness, depot, VID, operator number, and first and last name.

The software shall provide a summary display for all active incidents for that operating day.

Resource Status Displays

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

CAD/AVL software shall provide a resource status summary display which allows a window view of:

1. Current support vehicle status (busy, available, assigned minor mechanical repairs, incident numbers being dealt with, etc.) as indicated through the Remote Desktop Application.

2. Current field support personnel status notes as entered by OCC based on voice communications.

3. Information that can be populated into an incident such as employee name, badge number, vehicle number, unit ID, location, etc.

Display shall be able to filter resources by geographic area, incident or by assignment and shall include Winter Operations and Incident Command components for large incidents.

Controllers shall be able to manually enter resource status into the resource status display screen.

Status of all field resources shall be displayed on all workstations regardless of controller work assignments.

Controllers shall be able to enter communications and other notes into the resource display which will be saved and stored in the CAD/AVL database. Maintenance incidents shall be transferred to the AC Transit Database.

Controllers shall be able to locate the following screens and information from the resource status display:

1. Location of support resource on the AVL map.

2. Copies of active and current day incident forms dealt with by that support resource on the RDA.

Controllers and RDA users shall be able to set status of RDA users (e.g. available, on break/ lunch, unavailable, etc.) and assignment information such as current assignment, finished assignments, time assigned and who made the assignment, etc. Status information set by OCC shall be recorded by the central system.

Incident Management

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The system shall document events/incidents with automated prompts for specific types of information, based on AC Transit’s incident requirements. System shall provide unique incident ID number so that other documents and/or photos can be linked.

CAD/AVL software shall support an integrated incident/event forms functionality which operates in conjunction with the other CAD/AVL functions and displays.

CAD/AVL software shall be able to distinguish service adjustments separate from other incidents and events.

Controllers shall be able to initiate an incident/event by:

1. Selecting an incident/event generation function via hotkey, drop down menu, or button on a toolbar.

2. Selecting an incident/event generation function in relation to a particular vehicle from the AVL map or message queue, with the appropriate CAD/AVL available information populating the incident/event automatically.

3. Selecting an incident/event generation function from a vehicle list, block table, or stop list display with the appropriate CAD/AVL available information populating the incident/event automatically.

4. Automatic incident/event generation when certain AC Transit configurable CAD/AVL events (i.e. covert alarms) occur.

The CAD/AVL software shall support the ability to tag an incident record with an index or link to specific CCTV frame(s)/snippets in the future.

The CAD/AVL software shall generate a unique, progressive identification for each incident/event regardless of re‐booting the system. No CAD/AVL incident/event identification number shall be repeated.

During System Design, forms and management for up to five (5) incident/event types shall be specifically developed with AC Transit based on existing data requirements. These events shall be developed in a series of meetings and workshops with agency staff to include:

1. A preliminary meeting to discuss how the Contractor solution supports incident/event functionality including constraints and operational limitations, as well as user options for accessing the information from CAD/AVL.

2. A detailed workshop to identify incident/event types and internal functions of each type which may include:

a. Auto fills of information based on vehicle, block, route, nearest stop, time of day, day of week, and other relevant information available through CAD/AVL.

b. Mixed use of free text entry and drop down menus, radio buttons, or similar to quickly allow controllers to complete the information.

c. Use of required entry fields which must be completed before a form is closed.

d. Use of email forward functions to AC Transit configurable email distribution lists with key summary data from the incident/event including incident number, incident type, route, vehicle, operator number, time of day, location, severity of incident, etc. Selection of and sending to AC Transit configurable email distribution lists may be automatic depending on the incident type.

e. Tracking of specific incident/event history and users modifications of incidents/events by user, time of day, etc.

f. Locking of incident/event pages so that they may not be modified by more than one user at a time, yet allowing simultaneous modification of another page.

g. Ability to set the status of incident/event.

h. Ability to view all current incidents/events.

i. Ability to sort views of all incidents/events during an operating day by type of incident, incident status, time of day, incident creator, etc.

j. Forwarding of incident/event information to support vehicle selected by OCC.

k. Return of incident/event with controller notification if the forms are not addressed by support vehicles (through the RDA) within an AC Transit configurable period of time.

3. A follow‐up detailed workshop including Contractor experts and AC Transit staff to review draft forms of each type and review operations of these forms.

4. A final workshop/meeting as needed to finalize the specifics of the incident/event and their operations.

The system shall allow AC Transit the ability to develop additional incident/event types at its sole discretion.

Incident reports, message queues (Attention Request Queues), and the CAD/AVL shall be directly integrated as follows:

1. The ability to create an incident/event in CAD/AVL by selecting a vehicle in CAD/AVL (either from a list or a map display).

2. Displaying of vehicle status relating to incidents.

3. Ability to center and quickly locate a vehicle on a map once an incident is generated.

4. Ability to bring up a stop display to note the nearest stop in comparison with the current vehicle location.

The user interface for incident reports and message queues shall use Windows quick access features (widgets) such as buttons, check boxes, radio buttons, drop down menus, speed key combinations, AutoComplete, etc.

The user interface shall support “speed keys” and “auto fill” for incident reports and message queue fields.

The CAD/AVL software shall include functionality to reopen incidents/events to add additional information regarding an incident or event. Each event shall contain a time/date/user stamp to note such information related for creation and with each set of edits.

The CAD/AVL software shall notify users trying to access an incident/event if the incident/event is already accessed by another user. Multiple users shall not be allowed to modify the same incident simultaneously. Additional users shall be notified that the incident is under the control of another user granted read‐only access until the incident is released by the editing user.

The CAD/AVL software shall support routing of messages and incidents between controllers based on work assignments, previous dealings with the vehicle/incident, and ability to pass information between subsystems.

Maintenance related operational data collected from CAD/AVL shall be made available to the Maintenance Division (online/remotely) to allow for diagnosis.

CAD/AVL software shall support the ability to transfer forms between controllers and Street Supervisors who are using RDA.

The CAD/AVL software shall allow controllers to respond to only one (1) incident report at a time. Incidents that are waiting for additional information or resources and have not been resolved can be placed on hold or back into the queue.

The CAD/AVL software shall allow controllers to forward specific incident types to distribution groups. Types of incidents and distribution groups shall be configurable by AC Transit.

Immediately upon closing an incident report, it shall be available to edit and/or review by other users.

The CAD/AVL software shall ensure that all incidents are assigned to a controller for response.

Transfer Protection

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

Pre‐planned, protected transfers shall be obtained from the Hastus schedule data and imported to CAD/AVL.

CAD/AVL shall allow transfer protection parameters to be configured by AC Transit in advance for each transfer pair to include:

1. Time period during which a late feeder bus will prompt a message to wait on the receiving bus.

2. Time period to allow for passengers to transfer from one bus to another.

3. Time period after which the transfer will be considered failed and the receiving bus receives the message to proceed.

4. How many minutes in advance of projected arrival at the transfer point for the incoming vehicle will the system start projecting whether the arrival is not expected until after the receiving bus would have needed to be released.

The CAD/AVL system shall include service management tools that alert controllers when a critical transfer or “meet” is not going to happen and a decision is needed. The alert shall be in a visual and auditory format that can be configured (i.e. auditory alarm can be turned off) by controllers.

Controllers shall be able to manually enforce a protected transfer to indicate the receiving bus should hold for a longer duration than the base configuration.

Controllers shall be able to release protected transfer(s).

Controllers shall be able to identify and initiate an ad hoc or parameter based protected transfer through the use of a dialogue box with the appropriate parameters to be filled out by the controller.

Configuration

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software shall allow for the distribution of work amongst controllers by configurable groups of routes, service types, geographic area, operational function, VID, blocks, routes or trips, with all data associated with a block, or trips on that route being directed to particular controllers. The workload assignment shall be such that no active route can remain unassigned. Regardless of route assignments, all controllers must have the ability to see and monitor all vehicles in the system at all times.

The system shall allow messages and incidents to be “routable” and assigned to the appropriate controller based on work assignments and/or time based parameters. All follow ups, updates, and related messages for that vehicle or block shall be routed to the same controller and also available for display to all controllers.

1. The queues shall be AC Transit configurable and sorted based on priority, user, or workstation.

2. Certain messages, both to and from a vehicle, shall be routable to the desktop application running at the Division from which the vehicle is assigned.

Division based roles shall provide filtering that includes all of the following:

1. Scheduled blocks by specified Division

2. Scheduled personnel by specified Division

3. Assigned vehicles by specified Division

The following types of vehicle status shall be flagged as exceptions, through the use of a different color or other means. They shall also trigger an alert directed to the controllers:

1. Behind schedule by a n AC Transit configurable period

2. Running early by an AC Transit configurable period

3. Not logged in

4. Off‐route by an AC Transit configurable distance

5. Emergency/panic alarm activated

6. Late pull‐out by an AC Transit configurable period

7. Leaving a layover late by an AC Transit configurable period

CAD/AVL software shall allow AC Transit configuration of map icons (color and/or base icon), so that the following operational conditions can be easily seen on the map display:

1. All conditions from prior requirement above

2. Layover, and/or ignition off

3. Extra Service

4. Bus Bridge

5. Special Events

6. Winter Operations

7. Non‐Revenue scheduled trips (pull In, pull out, deadhead, training, etc.)

8. Non‐Revenue unscheduled trips (road trades, etc.)

Controllers shall have an option to query a list of all vehicle operators currently driving a route, including at least the following information:

1. Operator name

2. Operator Status such as: full time, part time, regular, regular relief, extra board, vacation relief

3. Employee number

4. Route number

5. Vehicle number

6. Trip number

7. Home Division

8. Time vehicle departed base

9. Time operator due back to base;

10. Whether the operator is returning the vehicle to base or being relieved in the field.

The CAD/AVL software shall allow controllers to add, delete, or temporarily replace/reassign operators by vehicle and block. Operator assignments shall be automatically updated as operators sign‐in/out of their vehicle’s MDTs.

The CAD/AVL software shall allow controllers to view vehicle details such as vehicle type, make/model, Division assignment, route assignment, schedule adherence, block/trip, Vehicle ID number, and run number.

Schedule adherence shall be visible to the controller system wide (by geographic area, by route, or by severity of schedule deviation) via a minimum of these methods:

1. Color or style of vehicle icons displayed in the map display;

2. List or table of vehicles noting schedule adherence;

3. List or route diagram noting schedule adherence by vehicle on that route;

4. System wide summary of schedule adherence by route;

5. Block list of schedule adherence in tabular format; and

6. Route that is flagged in the message queue that is having overall schedule adherence problems.

The CAD/AVL software shall allow the controller to “temporarily” adjust the thresholds under which a vehicle is considered:

1. Running “hot” or early – by number of minutes

2. Running late – by number of minutes

3. Running off route – by unit distance

Controllers shall have the option to see a list of routes and/or vehicles that are currently affected by a detour in time order by the next affected vehicle in one (1) or both directions.

When a controller selects a block, CAD/AVL software shall provide quick access (pull down menu, quick keys, etc.) to other information, including: paddle (block schedule), headways, relief points, operator status (regular relief, extra board, mini‐run, etc.).

Service Adjustment

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

The CAD/AVL software shall include functionality for adjustments to service including as a minimum:

1. Modifications to time points to support service adjustments such as detours, alternate routes, etc.

2. Cancel or add blocks/trips

3. Adjust for temporary detours

4. Reassign or remove vehicles from certain routes or blocks (e.g. may be required by a mechanical issue or bus bridge).

The system shall include management for a series of standard service restoration/correction functions including:

1. Detour – Activate predefined detours for service routes.

2. Ad‐hoc Detour – Create short term detours for accidents/incidents and events.

3. Delete/Add a Trip – Delete or add trip to a block to adjust service levels.

4. Replace a Vehicle/Operator – Assign a replacement vehicle and/or operator to take over service from a scheduled block that cannot continue for any reason.

5. Skip Stop – Notify an operator to bypass a series of stops to restore headways, with the ability to identify and log the starting and stopping point for the skip stop measure.

6. Initiate headway management instead of schedules. The headway mode will automatically evenly distribute the vehicles on the route. In this mode, schedule adherence will not be monitored, but controllers will receive indications that instead highlight instances of bunching and/or gapping.

The CAD/AVL software shall be capable of displaying adjusted timed transfer points, RSA, vehicles, and routes/trips. Adjusted information will be available for real‐time data feed.

CAD shall support the assignment of buses to “fictitious” blocks, routes that do not have schedule adherence and route IDs.

Controllers shall be able to transmit detour directions/instructions for buses to any vehicle/resource in the field.

All CAD service adjustments shall be logged and disseminated to AC Transit Customer Service and other staff. Information dissemination triggers, timing, and staff to be contacted will be configurable by AC Transit.

For all controller service adjustments, lost service miles and hours shall be calculated and stored by CAD for later reporting. Lost service and miles shall be displayed to control.

The CAD/AVL software shall include functionality for the display of multiple screens from multiple OCC workstations on a large screen or video wall display.

CAD shall provide a tool that provides a prioritized list of vehicles available for “fill” service and/or other ad‐hoc needs, such as “Bus‐Bridge.” The rules for this tool shall be completely configurable by AC Transit.

System shall store all detours for future use. These may be deleted by the System Administrator, if the detour is determined to be undesirable.

CAD shall allow controllers to enter and transmit ad‐hoc detours or detours by “clicking” each stop and turn position on the AVL map.

CAD shall highlight detours and allow Controllers to highlight and save a graphic/map view of the detour to be forwarded to:

1. MDTs

2. Customer service and other users via e‐mail and fax.

Bus Bridging

number

Description

Code

Alternate requirement language for cm/e

Proposal section reference

CAD shall recommend replacement vehicles and drivers taking into consideration status of the potential replacement driver (full/part time, regular, Extra Board, vehicle schedule, vehicle maintenance required, operator assignments, etc.).

CAD shall support OCC with the ability to electronically access AC Transit’s Extra Board (currently managed manually).

CAD shall support Control with the ability to identify the number and location (garage) of available vehicles for assignment to Bus Bridges, service restorations (e.g. fills or trades), and other ad hoc service adjustments (e.g. gap filling to restore consistent service headways).

System shall automatically notify Window Controllers for events that impact requests for vehicles.

System shall support different classifications of Bus Bridges, including: planned and unplanned and within both, major or minor.

System shall identify available and appropriate vehicles for unplanned bus bridge if vehicles need to be pulled from service, factors shall include vehicle capacity, driver experience, minimizing impact on other routes (interlining, transfer, etc.).

The system shall be able to denote high priority bus routes with color-coding or other means in order to addre