1 Scope of Work -- Electronic Validating Farebox 1.1 Function The farebox shall be installed on a bus, adjacent to the driver and in proximity to the front door. It shall be positioned so that an entering passenger may easily insert the required fare into the farebox using coins, tokens, and/or bills of multiple denominations. A display shall be positioned so as to be visible to the passenger when entering the bus, and shall be able to display fare information and other transaction data as determined by transit property. An operator control unit (OCU) with keyboard and multi-line display, installable anywhere within the bus driver area, shall enable the bus operator to monitor and control the farebox, and to enter fare and ridership information as required by the transit property. The farebox shall be an electronic validating farebox capable of electronically validating and verifying all coins, tokens, and bills inserted for payment. All coins, tokens, and bills shall be automatically identified by denomination, without operator action. All invalid coins, bills, and tokens shall be automatically rejected and returned to the passenger. All coins, tokens, and bills shall be deposited into a single cashbox, with all bills neatly and tightly stacked face down. The farebox shall be capable of connecting to other devices over industry standard interfaces including SAE J-1708, SAE J-1587, IrDA, and Vending Equipment Interface (VEI) Specification over RS-232, RS-485, and TCP/IP. These other devices include ticket processing units, smart card reader/writers, and other such devices as designated by the transit property. The farebox shall function under the environmental and operational conditions stated herein and shall be designed and manufactured to provide a high degree of security against forced entry and/or unauthorized manipulation. The farebox shall permit the passenger to easily and rapidly insert the required fare and will automatically ascertain that the correct fare has been paid, and signal the operator through an audible signal and through the operator control unit. The farebox shall provide specific information regarding daily operation, including revenue collected, types and quantity of fares collected, driver/route identification, and other information needed to account for revenue and monitor the equipment. The data collection and recording capabilities of the farebox shall be described below. 1.2 Fare Collection System The farebox shall be delivered as part of a complete bus fare collection system consisting of: - electronic validating fareboxes, - Garage Revenue Stations (GRS), - Money Room System (MRS), and - Central Host Computer (CHC). The fare collection system shall be designed so that a single computer can act as the Garage Revenue Station, Money Room System, and Central Host Computer. 1.3 Open System Design The farebox and fare collection system shall be designed in conformance with open systems standards and shall be free of non-standard, proprietary technology. At a minimum, the following recognized standards for data communications will be supported: - IrDA compliant hardware (for contactless, infra-red probing of data from the farebox), - J-1587, - J-1708, - TCIP, and - VEI. All software for the farebox, Garage Revenue Station, and Money Room System will be developed using either C, C++, SQL, or Java(TM). Where required for performance or efficiency reasons, assembler code may be used for critical functions or routines. All workstation software shall be delivered with a graphical user interface and shall be developed using Java(TM) and SQL. All database interaction with the Central Host Computer will conform to the ODBC standard. The Central Host Computer shall be delivered using a modern relational database system, such as Informix(TM), Oracle(TM), or Sybase(TM). 1.4 Year 2000 Ready The farebox and the fare collection system shall be delivered "Year 2000" ready, i.e., all software, databases, computers, data, clocks, calendars, and devices delivered as part of the fare collection system shall properly and automatically perform the transition into year 2000, including the correct calculation of leap year, without any special preparations or procedures. The fare collection system shall be fully and completely tested for year 2000 prior to delivery and installation. A "Fare Collection System Year 2000 Compliance Survey" documenting all tests and analysis for year 2000 shall be presented for review and acceptance prior to the delivery of the fare collection system. Additionally, a "Company Year 2000 Compliance Survey" shall be required documenting that the farebox manufacturer has addressed all of its internal year 2000 issues, assuring that year 2000 will not cause any interruption in internal operations affecting the development, manufacturing, and support of the fare collection system. This document shall be delivered for review and acceptance prior to the delivery of the fare collection system. 1.5 Secure, Automatic Revenue Audit Trail The farebox and fare collection system shall be designed in a manner that establishes a direct audit trail between revenue deposited into a farebox ("registered revenue") and revenue counted in the money room ("deposited revenue"). This audit trail shall link the registered revenue and deposited revenue on a farebox by farebox basis. Commingling of revenue from multiple fareboxes prior to the counting of revenue in the money room shall not be permitted. The fare collection system shall provide the following functions to support the secure revenue audit trail: - each cashbox shall be delivered with a unique electronic ID resistant to duplication and counterfeiting, - the farebox shall read the cashbox electronic ID upon insertion of the cashbox and periodically during revenue service, - the farebox shall record and track all revenue deposited into the cashbox, along with all other transactional detail information, and shall report this data to the Garage Revenue Station when probed for data during revenue service, - the farebox shall be capable of storing no less than thirty (30) days of full revenue and transactional detail information, without resorting to storing such information in summary form, - the Garage Revenue Station shall transmit all cashbox revenue data to the Central Host Computer, - the cashbox shall securely close and automatically lock prior to removal from the farebox, and the cashbox shall be designed to prohibit removal from the farebox unless it is in a closed and locked state, - after removal from the farebox, no revenue within the cashbox shall be visible or accessible, - unlocking of the cashbox to access the revenue shall not be possible without the "cashbox revenue key," which shall be available only in the money room, - when the cashbox is counted in the money room, the Money Room System shall: 1) read the cashbox ID, 2) record all revenue removed from the cashbox by denomination and quantity, and 3) transmit this information to the Central Host Computer, and - the Central Host Computer shall compare the registered revenue and counted revenue on a cashbox by cashbox basis, and shall automatically report any and all discrepancies. 1.6 Stacking of Bills Bills shall be neatly and tightly stacked within the cashbox by the farebox and shall be uniformly "faced." Manual stacking and facing of bills in the money room prior to counting shall not be necessary or required. 1.7 Automated Cashbox Inventory System The fare collection systems shall be delivered with an automated cashbox inventory system capable of tracking the location and status of every cashbox. The cashbox inventory system shall also monitor cashboxes so that they can be flagged as "missing" if they are not processed within a configurable period. The cashbox inventory system shall require no special data entry, but shall use data generated automatically by the farebox and the Money Room System to track the location, and to determine the state of every cashbox. The cashbox inventory system shall provide all reports and on line inquiry programs necessary to track and manage the cashbox inventory. Additionally, all applications necessary to track and correct cashbox handling errors and other exception conditions shall be delivered as part of the system. Every cashbox shall be marked with one of five possible inventory states: - installed (cashbox installed in a farebox), - to be counted (cashbox removed from a farebox during revenue service), - empty (either: 1) cashbox contents counted in the money room, or 2) new cashbox added to inventory, or 3) cashbox repaired and returned to service), - out of service - repair (cashbox damaged and sent for repair), or - out of service - no repair (cashbox removed from active inventory). Cashboxes shall also be tracked by location. For example, "installed" cashboxes shall be tracked by the farebox number in which the cashbox is installed, "to be counted" cashboxes shall be tracked by cashbox cart number, etc. The cashbox inventory system shall produce inventory reports by location so that periodic audits of cashbox cart contents, out of service cashbox inventory, etc., can be performed. The cashbox inventory system shall permit "maximum transition times" to be defined for certain cashbox states. If a cashbox remains in a state beyond the maximum transition time, it shall be flagged as "missing." An inventory history of each cashbox shall be maintained to assist in tracking "missing" cashboxes. The automated cashbox inventory system shall be delivered with all programs necessary to add cashboxes into inventory, enter in adjustments to correct handling errors, enter in explanations for exceptions and processing problems, etc. The cashbox inventory system shall also be designed to protect cashbox data, and shall permit the definition of security levels for all cashbox inventory functions. 1.8 Farebox Revenue Service Threshold The fare collection system shall permit the setting of revenue service thresholds. Revenue service thresholds shall define when the cashbox shall be exchanged after data is probed from the farebox by the Garage Revenue Station during revenue service. Revenue service thresholds shall be used to disable cashbox exchange unless the contents of the cashbox warrant it. The fare collection system shall support the setting of revenue service thresholds based upon the contents of the cashbox at the time farebox data is probed during revenue service: - coins in the cashbox, either by value or by percentage of cashbox coin capacity, - bills in the cashbox, either by value or by percentage of cashbox bill capacity, - total value of revenue within the cashbox, or - numbers of days since last cashbox exchange. The fare collection system shall permit the simultaneous setting of any of the revenue service thresholds. Cashbox exchange shall be required whenever one or more of the revenue service thresholds have been met. If no revenue service thresholds are set, the fare collection system shall require cashbox exchange whenever the farebox data is successfully probed by the Garage Revenue Station during revenue service. 1.9 Farebox Reliability The farebox shall be designed for the highest degree of reliability. It shall be capable of operating sixty (60) days mean time between failure. The farebox's electronic circuit boards, including electronic components, shall be capable of operating an average of ten thousand (10,000) hours between failures. Failure is defined as: A cessation of function to the point where the equipment is unable to function properly; when continued operation poses a threat to the equipment, driver, passengers, garage personnel or others; or an occurrence which does not cause the equipment to be inoperable, but requires some form of maintenance attention to restore normal function beyond what can be provided by the driver. Mean time to repair an inoperative farebox shall not exceed ten (10) minutes. Repair is defined as: The diagnosis, removal, and replacement of one or more defective assemblies (such as a coin mechanism, bill transport, electronic board, etc.) in order to restore the farebox to working condition. Repair of the defective assembly is not included in mean time to repair. Failures due to abuse, vandalism, operation beyond standards, or lack of maintenance as required in the Contractor's instructions, shall not be included in any reliability calculations. 1.10 Farebox Description 1.10.1.1 Construction The farebox shall be of rugged stainless steel construction, and shall not exceed 10.25 inches by 10.5 inches in width, or 20.5 inches in height. The farebox shall be able to be pole mounted, elevated above the bus floor. The farebox shall also be available with a pedestal for floor mounting. 1.10.2 Coin Acceptor The farebox coin acceptor shall electronically validate coins and tokens using technology such as electronic field displacement to determine type and denomination. The coin acceptor shall be software programmable to permit the addition of new coin types as required. The coin acceptor shall be capable of distinguishing twelve (12) different coins and tokens. Invalid coins shall be returned to the passenger. 1.10.3 Bill Acceptor The bill acceptor shall electronically validate bills using optical and magnetic identification technology, and shall be able to accurately and securely distinguish valid bills by denomination. Invalid bills shall be returned to the passenger through the bill insertion slot. 1.10.4 Passenger Display The farebox shall be delivered with a high visibility, fully graphic vacuum fluorescent display capable of providing the passenger with information, transaction assistance, advertising messages, etc. 1.10.5 Operator Control Unit (OCU) The farebox shall be delivered with an Operator Control Unit (OCU) for operator entry of commands, ridership information, etc., and to display transactional information, errors, prompts, etc., to the operator. The OCU shall connect to the farebox using a durable armored cable and shall be mountable up to ten (10) feet from the farebox. The OCU shall have a high visibility vacuum fluorescent display capable of displaying two (2) lines of 20 characters each. The OCU keyboard shall consist of: - a fixed numeric input pad with the numbers 0 through 9, plus a "function" and an "enter" key, and - 20 "soft" keys that can be configured to allow the operator to perform any farebox command with a single keypress. The 20 soft keys shall consist of one (1) group of four (4) large keys arranged along the rightmost portion of the keyboard, and two (2) groups of eight (8) standard size keys. The OCU keypad cover shall consist of a single rugged, low cost, flexible piece upon which legends can be printed to designate soft key assignments. Keypad covers shall be replaceable with a simple maintenance procedure when soft keys are reconfigured. The OCU keyboard shall be large enough to allow easy use by the operator, and shall provide mechanical feedback to the operator on each keypress. 1.10.6 Cashbox The cashbox shall store both coins and bills, and shall store bills tightly and neatly stacked and faced. The bill storage area in the cashbox shall be at the top of the cashbox so that bills are held above and out of any moisture that may collect in the cashbox during rainy or snowy conditions. The bill storage area within the cashbox shall be able to be increased or decreased through the removal and replacement of the bill storage insert within the cashbox. Removal and replacement of the bill storage insert shall require only a simple maintenance procedure. The cashbox shall be capable of being configured for three (3) different bill capacities: 1) a maximum of 500 bills, 2) a maximum of 750 bills, or 3) a maximum of 1,000 bills. When configured for a maximum 500 bill capacity, the cashbox shall provide a minimum of 195 cubic inches for coin storage. When configured for a maximum 750 bill capacity, the cashbox shall provide a minimum of 150 cubic inches for coin storage. When configured for a maximum 1,000 bill capacity, the cashbox shall provide a minimum of 110 cubic inches for coin storage. The cashbox shall be of a molded polymer construction with stainless steel reinforcement where required. Rough service shall not cause the cashbox to become distorted or inoperable. A fully loaded cashbox, if dropped in the upright position to a hard floor and landing on its bottom or bottom corner from a height of 36 inches, will suffer no operational impediment or security breach. The cashbox will not distort when filled to capacity. The cashbox shall not weigh more than 9.5 pounds when empty. Each cashbox shall be delivered with a unique electronic ID that is readable by the farebox and the money room counting station. This ID shall also be printed on the cashbox in text and bar code formats. The cashbox shall be designed so that it securely locks prior to being removed from the farebox during revenue service. Access to the contents of the cashbox shall only be possible using revenue keys available only in the money room. After removal from the farebox, the cashbox shall not be able to be reinserted into a farebox until it has been opened, and its contents counted, in the money room. 1.10.7 Optional Weather Tight Cover For an additional cost, the farebox is to be provided with a weather tight cover. This cover will be of a durable canvas or vinyl material which will protect the farebox from airborne dust, dirt, and moisture. The cover must be easily installed and removed in less than one (1) minute. The cover must be able to withstand repeated cycles of installation and removal without being damaged or causing damage to the farebox or other devices. 1.11 Farebox Capacity The farebox shall automatically monitor the level of bills and coins deposited in the cashbox, and shall notify the operator when the cashbox reaches a user configurable percentage of bill and/or coin capacity. When coin capacity reaches 100%, the farebox shall notify the operator and automatically disable coin acceptance. After coin acceptance is disabled, the farebox will reject all inserted coins and return them to the passenger. When bill capacity reaches 100%, the farebox will notify the operator and automatically cease accepting bills. The farebox passenger display shall be configurable to automatically notify passengers when coin and/or bill acceptance is turned off. 1.12 Farebox Operation 1.12.1 Farebox Operating Environment The farebox shall be able to operate without any degradation in performance under the following environmental conditions: Storage temperature-40 degrees to +140 degrees F degrees-40 degrees to +66 degrees C) Storage humidity5 to 99% (non-condensing) Operating temperature+25 degrees to +115 degrees F (-4 degrees to +44 degrees C) Operating humidity20 to 99% (non-condensing) Thermal shock1 degrees per minute drop in temperature over 15 degrees F range between 115 degrees F and 60 degrees F Operating vibration1.5G, 5 to 200Hz (on all axes) ShockUp to 5g (instantaneous) Inclination0 degrees to 10 degrees off vertical unsustained Primary voltage+12 volts DC nominal; operation from +9 to +18 volts DC (10 minutes up to 25 volts DC) Electromagnetic interference10 V/m, bands a, b, c; 300V arcs in nearby equipment The farebox shall remain operational in the presence of the following contaminants: airborne particles, grease, oil, and other contaminants accumulated on coins, tokens, and bills within reasonable limits, including bent and mutilated "street money." 1.12.2 Electrical Power The farebox shall have the following electrical characteristics: - Power supply+12 volts DC (bus battery) - Operating range+9 to +18 volts DC - Current (basic farebox)5 amps max (in operation), 0.8 amps (idle) Current (farebox with TPU)8 amps max (in operation), 0.8 amps (idle) - Power (basic farebox)60 watts max Power (farebox with TPU)96 watts max The farebox shall be protected against damage, loss, or modification of data caused by: - Lower or higher voltage in the range of -12 volts DC to +25 volts DC. - Spikes of 10ms up to 1000 volts DC. The farebox power supply shall include adequate filters and other provisions to regulate the bus-supplied voltage and suppress power spikes and noise which could contribute to erroneous signals or generation of data. The power supply shall be rendered immune to electrical interference caused by such items as fluorescent lights, bus alternators, air conditioning units, radios, etc. Adequate protection against transient surges in the bus power supply shall be incorporated to the extent necessary to prevent damage to electronic components. Loss or restoration of power shall not result in any major corruption of the data in farebox memory. The farebox shall be unaffected by electromagnetic radiation from bus equipment, including radio, lights, electronic destination signs, air conditioners, and generators. The farebox shall not emit EMI or RFI that produces harmful interference with other on-board electronic devices and systems. 1.12.3 Accuracy Requirements The farebox shall electronically validate all coins, tokens, and bills, rejecting invalid coins and bills and returning them to the passenger. The metallurgical signature of all presented coins and tokens shall be used to determine validity. Bills will be validated using optical and/or magnetic technology. Distinguishing coins by diameter and bills by length shall not be satisfactory. Coin and bill validation shall be configurable in software or firmware, so that new bills and coins can be added by updating the software or firmware. Hardware modifications shall not be required to a add the acceptance of new bills and coins. The farebox shall electronically validate and distinguish twelve (12) different coins and/or tokens. Invalid coins and tokens, counterfeit coins and tokens, slugs, and foreign coins shall be rejected and returned. The farebox shall electronically validate and distinguish up to four (4) denominations of U.S. bills presented in two orientations, face up. The farebox will accept 95% of valid coins and tokens on first insertion, and 99.8% of valid coins on second insertion. The farebox will accept 95% of valid bills on first insertion and 99.8% of valid bills on second insertion. 1.12.4 Secure Jam Clearance Feature The driver shall be able to securely access the coin and bill transport path in order to clear jams and obstructions. Access for secure jam clearance shall be controlled by key and by user password. Password access shall be capable of limiting secure jam clearance access to either: 1) operators, 2) supervisors, or 3) maintenance personnel. Additionally, the fare collection system shall be capable of issuing and managing "one time passwords" for access to the secure jam clearance area. One time passwords shall be valid for a single farebox and a single operator and shall be valid for only a single five (5) minute period. One time passwords shall be valid for only one use for the farebox, operator, and time period required. Such one time passwords can be issued by dispatchers to operators over radio or mobile phone connection to the bus when needed to clear farebox jams. Every access of the secure jam clearance area shall be recorded by the farebox in the farebox transactional data. The secure jam clearance feature shall not allow access to any money that has entered or passed through the bill or coin electronic validator unit. The cashbox and the cashbox contents shall not be visible or accessible during the secure jam clearance procedure. During the secure jam clearance procedure, all coin and bill transport and validator units shall be disabled. It shall not be possible to enable coin and bill processing without terminating the secure jam clearance procedure. The farebox shall be configurable to remove the secure jam clearance function entirely. 1.12.5 Audible Alerts The farebox shall be able to produce an audible signal to alert the operator and/or passenger of errors or events, including, but not limited to: - coin rejected, - bill rejected, - coin jam, - bill jam, - coin jam cleared, - bill jam cleared, - fare registered by operator command, - fare registered automatically by farebox, - cashbox coin area 90% full, - cashbox coin area full, - cashbox bill stacker 90% full, - cashbox bill stacker full, and - invalid operator command entered. The farebox shall be capable of producing not less than 20 separate and distinct audible signals, and shall be configurable to permit the association of any of these audible signals with any alert. Audible alerts shall also be able to be suppressed. 1.12.6 Farebox Operation -- Coins/Tokens 1.12.6.1 Coin Mechanism The farebox shall be capable of accepting up to twelve (12) different coins and tokens, including U.S. pennies, nickels, dimes, quarters, half dollars, and Susan B. Anthony dollar coins ($1.00), or Canadian pennies, nickels, dimes, quarters, half dollars, one dollar coins, and two dollar coins. The farebox shall be capable of being programmed to associate up to two coins with a single denomination, so that different series of coins can be accommodated. The coin validator shall be programmable so that tokens, coins, and coin series can be quickly and easily added, modified or deleted. Coin and token identification and acceptance shall be fully software controlled, and it shall require no modification to farebox hardware to add, change, or delete a coin or token type. 1.12.6.2 Coin Processing Speed The coin mechanism shall be capable of automatically and continuously processing coins and tokens at an insertion rate of not less than ten (10) items per second sustained. 1.12.6.3 Coin Slot The coin slot shall allow rapid insertion of coins and tokens by passengers. It shall be funnel-shaped to direct inserted coins into the farebox and shall admit no coin or token larger than a half dollar. Its design shall deter entry of paper into the coin slot and minimize coin jams. 1.12.6.4 Coin Return All invalid coins shall be returned to the passenger in the coin return slot. The coin return slot shall be clearly visible to the passenger and marked with the legend "Coin Return." The farebox shall be capable of producing an audible alert when coins are rejected to alert the operator and passenger. This audible alert shall be configurable for sound type and level, and shall be able to be suppressed. 1.12.6.5 Deformed Coins The coin mechanism shall be capable of handling deformed coins, i.e., coins that, within certain limits, are bent or bulged, not perfectly round, or have attached foreign matter. The farebox shall process and accurately count: - Coins bent or bulged having overall thickness ranging up to 0.020 inch greater than the coin's standard thickness. - Coins having attached, relatively complete uniform layers of foreign material (such as epoxy, solder or hardened gum) ranging up to 0.040 inch in thickness. - Coins not perfectly round (examples: squashed or flat edges) having diameters up to plus or minus 0.020 inch different from standard at the point of deformity. The farebox shall be resistant to jams or malfunctions created by coins outside the limits defined above, but shall not be required to accept such coins as valid. 1.12.7 Farebox Operations -- Dollar Bills The farebox shall be capable of validating and counting $1, $5, $10, and $20 bills, presented face up in either of two (2) orientations. Invalid bills shall be rejected and returned to the passenger. The farebox shall be capable of validating and accepting U.S. bills of "street quality." Foreign bills, counterfeit bills, partial, torn, and mutilated bills will be rejected. 1.12.7.1 Bill Processing Speed The farebox shall be capable of accepting, validating, and stacking a bill in two (2) seconds. 1.12.7.2 Bill Stacking After validation, bills shall be automatically transported to the cashbox and shall be tightly and neatly stacked face down. The bill compartment of the cashbox shall employ a spring or compressible foam so bills are kept securely stacked regardless of the number of bills stored in the cashbox. 1.12.7.3 "Accept Next Bill" Function The farebox shall be capable of allowing the operator to bypass bill validation and to manually designate the denomination of a bill. The "Accept Next Bill" command shall permit acceptance of a worn or mutilated bill that cannot be electronically validated by the farebox, but that the operator, upon visual inspection, determines to be valid. After operator entry on the OCU of the "Accept Next Bill" command, the next bill inserted into the farebox will be transported directly to the cashbox without validation. After the bill is stacked, the farebox will automatically return to normal operation (i.e., electronic validation of all bills). The farebox transactional data will record every instance of the "Accept Next Bill" command, to permit tracking should discrepancies appear in the money room when the cashbox contents are counted. The farebox shall be configurable to limit the "Accept Next Bill" by bill denomination, or to remove the "Accept Next Bill" function entirely. 1.12.7.4 "Accept Ticket" Function The farebox shall be capable of accepting tickets, passes, and other paper documents through the bill acceptor. Such documents will be the approximate width and length of dollar bills. To accept such documents, the driver will enter the "Accept Ticket" command and designate the document type. After entry of this command, the next documents inserted into the bill acceptor will be advanced to the cashbox and stacked, bypassing bill validation. Farebox transactional data will record every "Accept Ticket" command. 1.12.8 Farebox Self Test and Diagnostics The farebox shall automatically test all components and functions: 1) on every power up, 2) on the start of a new shift, and 3) when commanded by the operator. Errors detected during this self test function shall be recorded in the farebox transactional data, and displayed to the operator on the OCU display. The performance of the farebox shall be continuously monitored during operation, and all errors, exceptions, anomalies, etc., shall be recorded in the farebox transactional data reported to the operator on the OCU. 1.12.9 Automatic Jam Sensing and Jam Clearance The farebox shall continuously monitor the coin and bill handling systems, and shall be able to automatically sense and report bill and coin jams. All detected jam conditions shall be recorded in the farebox transactional data, and displayed to the operator on the OCU display. Upon sensing a jam, the coin and/or bill processing shall be disabled until the jam is cleared. The operator shall be able to attempt to clear coin jams and bill jams through OCU commands. After completion of the jam clearance function, coin and/or bill processing shall be automatically enabled. 1.12.10 Operator Log on/Log off Prior to the farebox entering revenue service, the operator shall be required to successfully log on. Successful log on shall require a valid operator ID, operator password, and valid route/run/trip information. Operator IDs and passwords shall be securely maintained at the Central Host Computer (CHC), and shall be downloaded to the farebox during data probing. Route/run/trip validity information shall also be maintained at the CHC, and shall be used by the farebox to insure that route/run/trip information is correctly and accurately entered by the operator during log on. The farebox shall also support temporary (relief) operator log on, supervisor log on, and manager log on. Non-revenue service log ons shall be possible for maintenance and revenue technicians. At a minimum, the following security levels shall be settable for operators: - normal operator, - supervisor, - manager, - maintenance technician, and - revenue service technician. The required security level for all farebox functions and commands shall be configurable. Functions and commands requested from operators with insufficient security shall be denied, and a transaction documenting this denial shall be recorded in the farebox transactional data. 1.12.11 Automated Interface to Bus Dispatch System As an option, there shall be available an automated interface to a bus dispatch system for driver log on for fareboxes with magnetic Ticket Processing Units or smart card processing units. The automated interface shall be delivered with an RS-232 serial port interface, and complete documentation on how to accomplish communications to, and integration with, standard bus dispatch systems. 1.12.12 Communication of Farebox Data to Garage Revenue Station As part of the revenue service process, and prior to the removal of the cashbox, the farebox shall connect to the Garage Revenue Station for the probing of revenue and transactional information. Connection to the Garage Revenue Station shall use high speed, contactless, infrared (IR) communications based upon the IrDA hardware standard. Probe data of 50 kilobytes shall transfer in not more than six (6) seconds. Probe access security shall be guaranteed by use of cryptographic authentication (using DES or other approved standard) prior to all probe functions. At no time shall a cryptographic key be stored or transmitted in the clear. After revenue and transactional information is transferred to the Garage Revenue Station, any control or configuration information required will be downloaded from the Garage Revenue Station to the farebox. Upon successful completion of all data transfer with the Garage Revenue Station, the farebox will automatically open the revenue door if revenue thresholds have been met, permitting removal of the cashbox. The farebox date and time shall be synchronized with the Garage Revenue Station upon every successful connection. The Garage Revenue Station shall be capable of downloading over the IR connection to the farebox complete new farebox software in less than six (6) minutes. 1.12.13 Farebox Operations -- Farebox Transactional Data The farebox will securely and accurately record all transactional information, including sales data, operational errors and exception conditions, ridership information, and operator commands. At a minimum, the farebox will record a complete transaction on the following events: - all payment transactions, - all ridership registration transactions, - all operator commands, - farebox power off, - farebox power on, - operator log on, - operator log off, - secure jam clearance door opened, - secure jam clearance door closed, - successful data probe of transactional data, - unsuccessful data probe of transactional data, - successful download of farebox configuration data, - unsuccessful download of farebox configuration data, - revenue door opened (at times other than revenue service after successful data probing), - revenue door closed, - cashbox removed, - cashbox inserted, - farebox errors and failures, - security errors and intrusions, - coin jams, - clearance of coin jams, - bill jams, - clearance of bill jams, and, - new fare table selected. In addition to transactional data, the farebox shall maintain running counts by operator shift of other items such as total number of coins rejected, total number of bills rejected, etc. Under no circumstances shall the farebox discard detail data or substitute summary data, except as configured by the transit property. All transaction and revenue data shall be date and time stamped to the highest resolution of the available clock. All transaction and revenue data shall be assigned a unique (per farebox) 32 bit incrementing record sequence number at the time it is recorded. 1.12.13.1 Farebox Data Storage The farebox shall provide adequate data storage capacity to accurately and securely store a minium of 4 megabytes of transactional data. The farebox shall be capable of retaining transactional data for a minimum of 10 years without power. When the capacity of the farebox data storage is reached, the farebox shall suspend normal service and indicate that data probing is required. Transactional data shall be communicated to the Garage Revenue Station (GRS) when data is probed prior to revenue service. After successful data probing, the farebox shall continue to retain the transactional data until such time as the GRS directs that the data can be deleted from the farebox. At any time the farebox shall be able to be probed for transactional data for the current revenue shift (data for cashbox currently installed) or for any previous revenue shifts still stored. The GRS shall not direct the farebox to delete the transactional data for any revenue shift unless directed by the Central Host Computer (CHC) after successful receipt and processing of that data by the CHC. 1.12.13.2 Farebox Supply Monitoring The farebox shall monitor and record each instance of the primary power source dropping below nine (9) volts. The farebox shall also monitor and record each instance of the primary power source dropping below nine (9) volts, but not to zero (0). This information shall be available on the farebox for operator inquiry. Also, after data probing, these transactions will be available on the Central Host Computer (CHC) for on line inquiry and reporting. Power supply monitoring information may be used to determine possible problems with bus battery power systems. 1.12.13.3 Route/Run Segmenter All fareboxes shall be delivered with a route/run segmenter. The route/run segmenter shall permit the operator to indicate when a route/run segment has completed, and a new segment has begun. A record shall be recorded in the transactional data indicating the segment change, date and time of segment change, etc. There shall be no limitation on the number of segments possible for a route/run. 1.12.13.4 Fare Sets and Fare Categories The farebox shall allow up to 20 fare sets to be available for selection either automatically based upon route/run/trip information, or by operator command. The fare sets available for operator selection can also be restricted by route/run/trip information. Each fare table will allow up to 100 different fare categories to be registered by the operator. Fare tables will provide, at a minimum, the following information: - default fare for automatic fare registration, - time/day validity (so that fare sets can be restricted by time of day and/or day of the week), and - route/run/trip validity. The fare categories available for selection within a fare table shall be configurable. Fare categories shall be assignable to any OCU soft key to permit rapid selection by the operator. At a minimum, each fare category within a fare table will define the following information: - name (e.g., "adult full fare," "student fare," etc.), - fare payment type (e.g., "cash fare," "flash pass," "register only - no payment," etc.), and - fare amount. 1.12.13.5 Farebox Operations -- Payment Acceptance While in revenue service, the farebox will be capable of continuously and automatically accepting and validating all coins, tokens, and bills presented for payment. Coins and bills that are successfully validated will be deposited into the cashbox, and their value will be added to the "payments received" display on the OCU and on the passenger display. The quantity and type of tokens validated and accepted will also be displayed to the operator and the passenger as part of the "payments received" display. The value of all coins, bills, and tokens accepted by the farebox will be added to the "payments received" display and will be considered "unallocated revenue" until either: - the operator presses a ridership registration command (i.e., "full adult fare," "student fare," etc.) allocating the revenue to a particular fare, or - a configurable timeout period expires and the farebox automatically allocates the revenue to the default fare. The farebox shall be configurable to produce an audible alert whenever payment equaling the value of a "default fare" for the current fare table is entered. The farebox shall record all monies presented as payment, including: - date and time of payment (to the highest resolution of the embedded clock), - number and denomination of coins validated and accepted as payment, - number and denomination of bills validated and accepted as payment, - number of coins rejected and returned to passenger and date and time of rejection, and - number of bills rejected and returned to passenger and date and time of rejection. 1.12.13.6 Farebox Operation -- Ridership Registration The farebox shall permit the operator to enter fare ridership information through the OCU, and shall match such ridership information to payments where possible. Ridership information can be selected by the operator by entering the command with the OCU, or by pressing the OCU "soft key" that has been assigned to the fare category. The ridership registration shall be recorded in a manner that will permit the matching of ridership information with payment information. 1.12.13.7 Farebox Operation -- Errors/Exceptions The farebox shall record all errors and exceptions, including errors resulting from jammed bills or coins, mechanical malfunctions, operator errors, and all such conditions where the normal operation of the farebox may be disrupted, including software exception conditions. An individual record with date, time, and other relevant details, shall be written for each occurrence of an error or exception. Errors and exceptions shall be recorded in such detail that an analysis of this information shall represent a full and complete picture of the farebox performance. 1.12.14 Pass and Ticket Processing Unit (TPU) As an option, an auxiliary Pass and Ticket Processing Unit (TPU) shall be offered which is capable of installation in a variety of different mounting points for passenger and driver convenience. The TPU shall issue and read multiple types of magnetic documents and print transactional and remaining value upon the face of the tickets. The TPU shall interface to the farebox for purposes of electrical supply and data collection and shall be operated under the control of the farebox. The unit shall be configurable to allow use as a transfer issuer/reader, and to process stored value and/or multi-trip passes and tickets. The TPU shall be fully programmable, including all display messages, via input from the farebox operator control unit and/or through configuration data downloaded to the farebox at the time of revenue service. The Pass and Ticket Processing Unit shall be linked to the farebox via a serial data connection. All data collected by the TPU shall be conveyed to the memory of the farebox and be removed when data is probed from the farebox at the time of revenue servicing. 1.12.14.1 TPU Operation The TPU shall employ an entry/exit slot which is convenient to both the driver and the passenger. A supply of unencoded tickets/passes shall be held in a receptacle convenient to the driver. Issuance of tickets/passes shall be initiated by commands entered on the OCU, then an unencoded ticket/pass shall be inserted into the entry slot of the TPU. The ticket/pass is then encoded and printed according to its intended use. Passengers entering the bus will insert their ticket/pass into the entry slot. The ticket/pass will be read and, depending upon the mode of operation, will either read, re-encode, and print, or simply read and return the ticket/pass to the passenger. 1.12.14.2 TPU Mounting The TPU shall be mounted on one bracket secured to a pole, bulkhead, or a farebox. This bracket shall house the connector which provides power and communications. 1.12.14.3 TPU Printing The Pass and Ticket Processing Unit shall employ either dot matrix or direct thermal printing technology to print fully formed and highly legible alphanumeric characters on required surfaces of the ticket. If an ink ribbon is used for dot matrix printing, it shall be contained within an easy to replace continuous loop cartridge. 1.12.14.4 TPU Speed The TPU shall be capable of high speed operation which will not hold up the entry of passengers onto the bus. A simple read-only operation such as reading a monthly pass shall be accomplished in 0.4 seconds. A read/write transaction shall be accomplished in 0.5 seconds. A read/write/print transaction shall be accomplished in approximately 1.0 second. 1.12.14.5 Bad Number and Passback Checking The Pass and Ticket Processing Unit shall employ means of communications to and from the farebox to enable recording of each ticket number issued and presented by a passenger. In addition, means shall be established to download lists of bad card numbers to the farebox at the time of farebox probing for daily operational data. Passes/tickets presented to the TPU shall be checked against this list, and shall be rejected by the TPU if the pass/ticket is on the list. 1.12.14.6 Change Card Use The Pass and Ticket Processing unit shall have the ability to provide change between the required fare and the inserted money. The change shall be in the form of a specially printed stored value card which is encoded by the TPU. The encoded card shall be valid for the payment of fare, or shall be returnable for refund of fare overpayment. 1.12.14.7 Ticket Encoding The TPU mechanism shall be designed to work with a paper or plasticized card of the standard ISO credit card format (2 1/8" x 3 3/8"). The magnetic stripe can be located either in the center or on the side of the card. The mechanism shall incorporate separate read and write heads to speed the throughput of the card. 1.12.14.8 TPU Construction The TPU shall be enclosed in a rugged metal case which will withstand normal operational use over an extended period without obvious physical damage or functional degradation. 1.12.14.9 Environmental The pass and ticket processing unit shall be rated to the same shock and vibration standards as applied to the farebox and operate in the same environmental conditions. 1.12.14.10 TPU Display The pass and ticket processing unit shall employ a display consisting of at least a 16 character, full alphanumeric, dot matrix liquid crystal "supertwist" display or similar technology. The display shall be backlit with an integral Liquid Crystal Display (LCD) panel. The unit shall provide a wide angle of view and ensure adequate clarity in all levels of light. The text displayed on the display normally will prompt a passenger through a transaction. The wording, order of messages and their appearance shall be fully customizable. 1.12.15 Magnetic "Swipe" Reader As an option, the farebox shall include a "swipe" reader capable of reading at least one ISO standard magnetic track from credit card sized (2 1/8" x 3 3/8"), 0.010" thickness paper or plasticized ticket media. The magnetic reading head(s) shall have a rated lifetime of at least 300,000 reads. The reader shall be easily accessible by the passenger and be installed in the top of the farebox casing. 1.12.16 Smart Card Processing As an option, the farebox shall provide an interface to smart card reading units which may be either internal or enclosed in an external interface unit. Smart card reading units shall enable passengers to use either contact or contactless IC chip cards (depending upon technology chosen) to pay for trips and/or access other services such as transfers. Provisions shall be made in the design of the farebox to include sufficient processing capacity and communications ports to accommodate deployment of smart card-based fare media, either initially or in the future. Physical mounting points for either internal or external smart card "targets" or readers shall be identified in drawings supplied as part of documentation package. 1.12.17 Connectivity As an option, the farebox shall provide industry standard connections to other vehicle mounted devices using either J-1708, RS-232, or RS-485. 1.13 Through Wall System for Cashbox As an option, the fare collection system shall be delivered with a through wall system enabling the secure, one-way passing of cashboxes containing revenue into the money room, and the secure, one-way return of counted and empty cashboxes out of the money room. 1.14 Cashbox Cart As an option, the fare collection system shall be delivered with a cashbox cart capable of storing and transporting cashboxes from the Garage Revenue Station (GRS) to the money room, and back. 1.15 Garage Revenue Station (GRS) The fare collection system shall be designed so that a single computer can act as the Garage Revenue Station, Money Room Computer, and Central Host Computer. The Garage Revenue Station (GRS) shall be used by the revenue service clerk during the revenue service procedure to: 1) probe the farebox for transactional data, and 2) download farebox configuration data such as fare tables, OCU command layouts, etc. The GRS shall securely authenticate the connection to the farebox prior to data transfer, and shall be capable of encrypting all messages exchanged with the farebox using the Data Encryption Standard (DES) algorithm, or other approved cryptographic standard. The GRS shall be either: - a standalone computer installed in a bus garage, or - a portable, light weight, hand held computer that can be easily and comfortably mounted in a holster on the belt of the revenue service technician, or - one of the functions on a single computer hosting the GRS, Money Room System, and Central Host Computer functions. The GRS shall communicate with the farebox using a contactless, high speed infrared (IR) connection based upon the IrDA hardware standard. Communications between the GRS and the farebox shall be automatic when the IR data probe is pointed facing the farebox and within three (3) feet of the farebox. If the GRS is a standalone computer, or is installed on the CHC, the IR data probe shall be connected to the computer by a flexible, retractable cable up to 100 feet in length. If the GRS is a hand held computer, the GRS shall connect with the Central Host Computer (CHC) through a wireless RF link and an RF base station. The hand held GRS shall be continuously on line with the CHC whenever it is within 500 feet of the RF base station. As an option, the hand held GRS may use a docking station as an alternative to the RF link. The garage revenue system shall communicate with the CHC to transfer farebox data, and to receive farebox control and configuration information. The GRS shall securely authenticate the connection to the CHC prior to data transfer, and shall encrypt all messages exchanged with the CHC using the Data Encryption Standard (DES) algorithm, or other approved cryptographic standard. 1.16 Money Room System (MRS) The Money Room System (MRS) shall consist of one (1) Money Room Computer (MRC) and one (1) or more counting stations. 1.16.1 Counting Station Each counting station shall consist of an automated bill counter, automated coin counter, and a cashbox ID reader. To process a cashbox at the counting station, the money room clerk shall: - remove the cashbox from the cashbox cart and place into the counting station, - read the cashbox ID, - open the cashbox with the "cashbox revenue key," - removed the stacked and faced bills from the cashbox and count them in the automated bill counter, and - return the open and empty cashbox to the cashbox cart. The counting station shall be designed so that coins drop out of the cashbox into the automated coin counter when the cashbox is opened. The counting station shall be designed so that a single money room clerk can process at least 400 cashboxes in a single eight hour shift. 1.16.2 Money Room Computer (MRC) The fare collection system shall be designed so that a single computer can act as the Garage Revenue Station, Money Room Computer (MRC), and Central Host Computer. The MRC shall connect to one or more counting stations to collect cashbox revenue count information. The money room computer shall transmit this information to the Central Host Computer. 1.17 Central Host Computer (CHC) The fare collection system shall be designed so that a single computer can act as the Garage Revenue Station, Money Room Computer, and Central Host Computer (CHC). The Central Host Computer (CHC) shall be an industry standard computer platform using either Windows NT or the UNIX operating system. The CHC shall collect all revenue and transactional information from all Garage Revenue Stations, and all cashbox count information from the Money Room System. This information shall be stored in an industry standard relational database using either Informix(TM), Oracle(TM), or Sybase(TM), and shall be available for on line inquiry and reporting. The CHC shall be delivered with a graphical user interface for on line query, reporting, and configuration. The CHC shall be delivered with daily, weekly, and monthly programs reporting revenue and transactional information, plus exception reports listing errors, out of balance conditions, revenue count discrepancies, unprocessed cashboxes, etc. The CHC shall be delivered with all documentation and instructions necessary to modify all report programs, or to create new reports.