NINTH MODIFICATION OF AGREEMENT NUMBER 8153 (CCS)
• December
This Ninth Modification of Agreement Number 8153 (CCS) ("Ninth Modification") is entered into this 29 _day of November, 2011 ("Execution Date"), by and between the CITY OF SANTA MONICA, a municipal corporation ("City"), and TRAPEZE ITS U.S.A., LLC, a company incorporated under the laws of the State of Delaware ("Trapeze" or "Vendor") and is made with reference to the following:
RECITALS
A. On or about May 30, 2003, the City and Siemens Transportation Systems, Inc., entered into Agreement Number 8153 (CCS) ("Original Agreement") for an Advanced Fleet Management System ("AFMS"), which was subsequently amended by the following:
(i) First Modification dated on or about June 1, 2004 to authorize assignment • of the agreement to Siemens VDO Automotive Corporation; (ii) Second Modification dated on or about June 17, 2004 to increase the amount of compensation;
(ili) Third Modification dated on or about March 21, 2005 to delete certain services and to reduce the contract price;
(iv) Fourth Modification dated on or about March 2, 2006 to delete certain services and to reduce the contract price;
(V) Fifth Modification dated on or about August 11, 2006 to extend the term and amend the deliverables;
(vi) Sixth Modification dated or on about December 8, 2008 to authorize assignment of the agreement to Continental Automotive Systems US, Inc.:; (vii) Seventh Modification dated on or about June 18, 2009 to extend the term and for revised milestone payments, and;
(vili) Eighth Modification dated on or about October 19, 2010 to authorize assignment of the agreement to Trapeze ITS U.S.A, LLC.
The Original Agreement, First Modification, Second Modification, Third Modification, Fourth Modification, Fifth Modification, Sixth Modification, Seventh Modification and Eighth Modification may be collectively referred to as "the Agreement." B. The City and Trapeze desire to enter into this Ninth Modification to modify the Project Schedule to extend completion date, to incorporate the credit to be provided to the City, and to incorporate the Automated Passenger Counter Test Plan, Master Punch List, Systems - 1-
Acceptance Test Plan Variances, and assign the Original Agreement to Trapeze's parent company, in accordance with the terms and conditions set forth herein.
NOW THEREFORE, it is mutually agreed by and between the undersigned parties as follows:
1. RECITALS. The terms of the Recitals are incorporated herein by reference as a term of this Ninth Modification.
2 COMPLETION DATE. The completion date for the installation and acceptance testing of the System and Successful Installation and Final System Acceptance shall be extended to March 31, 2012 ("Completion Date"). The parties hereby delete the Project Schedule attached as Exhibit A to the Seventh Modification and replace it with the Project Schedule attached hereto as Exhibit 9-A and incorporated hereby reference.
3. AUTOMATED PASSENGER COUNTER TEST PLAN. The parties hereby incorporate the Automated Passenger Counter Test Plan ("APC Test Plan") attached hereto as Exhibit 9-B and incorporated herein by reference as the test plan for the Automated Passenger Counter portion of the AFMS. The City has conducted the tests in accordance with said APC Test Plan.
4. PUNCH LIST ITEMS. For clarity and avoidance of doubt, the Master Punch List and Systems Acceptance Test Plan Variances are attached hereto as Exhibits 9-C and 9-D, respectively, and set forth the remaining outstanding items to be completed prior to Final System Acceptance.
5. CREDIT TO CITY. Trapeze agrees to provide the following credits to the City:
(i) the sum of $41,732.94 for the cost of services related to the testing of the Automatic Passenger Counters during May 2009; and (i) the sum of $10,740.00 for the cost of equipment installation services related to the Thomas vehicles. The Performance Milestones set forth in the Seventh Modification will be revised to incorporate said credits as Performance Milestones Numbers 24.2 and 24.3. Accordingly, the Revised Billing Milestone schedule attached hereto as Exhibit 9-E and incorporated herein by reference shall replace and supersede the Performance Milestone set forth in the Seventh Modification.
6. TOTAL CONTRACT AMOUNT. To reflect the credit to City, the total contract amount set forth in the Agreement shall be adjusted to the sum of Five Million Eight Hundred Forty-Eight Thousand Seven Hundred Seventy-Five Dollars and Thirty-One Cents ($5,848,775.31), inclusive of taxes and fees. Accordingly, Section R of the Seventh Modification shall be deleted and replaced with the following:
Total Contract Amount. City agrees to pay Vendor, and Vendor agrees to accept from City, the sum $5,848,775.31, which includes taxes and fees at the rate in effect as of the date of this Ninth Modification, for the System in the following amounts and in - 2-
accordance with the following performance milestones set forth in Section 5.1.1 below.
Changes Per New Total Changes per New Total
Seventh Per Seventh Ninth per Ninth
Modification Modification Modification Modification
Licenses $0.00 $1,491,963.00 $0.00 $1,491,963.00
Hardware ($17,312.00) $2,775,164.21 $0.00 $2,775,164.21 Services ($14,700.00) $1,249,481.42 ($52,472.94) $1,197,008.48 Services-T1 $0.00 $0.00 $0.00 $0.00
Maintenance $0.00 $467,869.53 $0.00 $467,869.53
Rounding Error $0.00 $0.00 $0.00 $0.00
Liquidated Damages ($97,500.00) ($97,500.00) $0.00 ($97,500.00) Management Discount ($1,139.65) ($361,239.65) $0.00 ($361,239.65) Sub Total ($130,651.65) $5,525,738.51 ($52,472.94) $5,473,265.57 Taxes ($1,057.16) $375,509.74 $0.00 $375,509.74
Total ($131,708.81) $5,901,248.25 ($52,472.94) $5,848,775.31
7. ASSIGNMENT. The City hereby consents to the assignment of the Agreement, as amended, from Trapeze ITS U.S.A., LLC to Trapeze Software Group, Inc based upon the following representations and warranties made by Trapeze Software Group, Inc.:
(i) Trapeze Software Group, Inc. agrees to assume all of the obligations and responsibility of the Trapeze ITS USA under the Agreement, including, but not limited to, the indemnity rights, warranties, maintenance provision, software and hardware services and deliverables set forth in the Agreement; and (i) The assignment will have no diminishment in the contractual obligations set forth in the Agreement; and
(iii) Nothing in this assignment modifies or alters the Performance Bond and Payment Bond, Nos. 81926347 dated May 30, 2003, made by and between Siemens Transportation Systems, Inc. and Federal Insurance Company and the City (the "Bonds") set forth in Original Agreement and 8" Modification, which remain in full force and effect.
- 3-
8. FORCE AND EFFECT. Except as expressly modified herein, all other terms and conditions of the Agreement shall be and remain in full force and effect.
IN WITNESS WHEREOF, the parties have caused this Ninth Modification to be executed the day and year first above written.
CITY OF SANTA MONICA,
ATTEST: a municipal corporation
denise Anderm Varien By:
ROD GOULD
JO MARIA STEWART
City Clerk City Manager
APPROVED AS TO FORM:
MARSHA JONES MOUTRIE
City Aftorney
TRAPEZEITS W.S.A., LLC
By:
(FO:
Title:
TRAPEZE SOFTWARE GROUP, INC.
Title: CBO
- 4-
EXHIBIT 9-A
PROJECT SCHEDULE
Task Name Duration Start Finish Predecessors Resource Names Santa Monica Upgrade Plan 108 days Thu 10/27/11 Mon 3/26/12 Contractual Items 21 days Thu 10/27/11 Thu 11/24/11
Trapeze provide Santa Monica Latest Amendment 9 O days Thu 10/27/11 Thu 10/27/11 Santa Monica Review Amendment 9 5 days
Meeting to discuss final Amendments to Amendment 9 1 day Thu 11/3/11 Thu 11/3/11 4 Prepare final Amendment 9 documentation 5 days Fri 11/4/11 Thu 11/10/11 5 Trapeze signed Amendment 9 5 days Fri 11/11/11 Thu 11/17/11 6 Santa Monica sign Amendment 9 5 days Fri 11/18/11 Thu 11/24/11 7 Hardware Upgrade - Procurement & Set up in Cedar Rapids 80 days 10 5 days Fri 11/11/11 Thu 11/17/11 6
11 Order hardware and Software 5 days Fri 11/25/11 Thu 12/1/11 8 12 Lead time for delivery 15 days Fri 12/2/11 Thu 12/22/11 11 13 Receive Equipment 2 days Fri 12/23/11| Mon 12/26/1112 14 Equipment set up and configuration at Cedar Rapids 10 days Tue 12/27/11 Mon 1/9/12 13 15 Deploy Release 27 to equipment at Cedar Rapids 5 days Tue 1/10/12 Mon 1/16/12 14 16 Configure IDS 3 days Tue 1/17/12 Thu 1/19/12 15
17 Regression testing 5 days Fri 1/20/12 Thu 1/26/12 16 18 5 days Fri 1/27/12 Thu 2/2/12 17
19 Resolve variances 10 days Fri 2/3/12 Thu 2/16/12 :18 20 Regression test 5 days Fri 2/17/12 Thu 2/23/12 19
21 Ship equipment to Santa Monica 5 days Fri 2/24/12 Thu 3/1/12 20 22 Operational Review for IDS Configuration Preparation 1.27 days Fri 11/11/11 Mon 11/14/1:
23 Gather Agency Documentation 0.16 days Fri 11/11/11 Fri 11/11/11 24 Dispatcher Training Materials 0.25 hrs Fri 11/11/11 Fri 11/11/11 25 Dispatcher Procedures Manual 0.25 hrs Fri 11/11/11 Fri 11/11/11 24 26 Current Operations Memos 0.25 hrs Fri 11/11/11 Fri 11/11/11 25 27 Emergency Plans related to communications and operati 0.25 hrs Fri 11/11/11 Fri 11/11/11 26 28 Daily Reports 0.25 hrs Fri 11/11/11 Fri 11/11/11 27
29 Identify Dispatcher Data Entry/Info Sources 0.16 days Fri 11/11/11 Fri 11/11/11 23 30 Manual entry into logs 0.25 hrs Fri 11/11/11 Fri 11/11/11 31 Double entry into legacy systems 0.25 hrs Fri 11/11/11 Fri 11/11/11 30 32 Important Manuals available to dispatchers 0.25 hrs Fri 11/11/11 Fri 11/11/11 31 33 Use of external sources of information (camera feeds, 0.25 hrs Fri 11/11/11 Fri 11/11/11 32 web sites, etc.)
Task Name Duration Start Finish Predecessors Resource Names 34 Critical information accessed in dispatch room 0.25 hrs Fri 11/11/11 Fri 11/11/11 33 35 Observe Dispatcher Use of TransitMaster 1 0.28 days Fri 11/11/11 Fri 11/11/11 29 36 What canned messages are answered 0.25 hrs Fri 11/11/11 Fri 11/11/11 37 What vehicle alarms acted on 0.1 hrs Fri 11/11/11 Fri 11/11/11 36 38 What adherence warnings acted on 0.25 hrs Fri 11/11/11 Fri 11/11/11 37 39 How are Late logon/pullout managed 0.25 hrs Fri 11/11/11 Fri 11/11/11 38 40 When are incident reports used 0.25 hrs Fri 11/11/11 Fri 11/11/11 :39 41 Subsystem Health interest 0.1 hrs Fri 11/11/11 Fri 11/11/11 " 40 42 Mechanical Alarm interest 0.1 hrs Fri 11/11/11 Fri 11/11/11 41 43 Any use of service adjustments 0.1 hrs Fri 11/11/11 Fri 11/11/11 42 44 Any use of external sources of information 0.1 hrs Fri 11/11/11 :Fri 11/11/11 43 45 Use of road supervisors 0.25 hrs Fri 11/11/11 Fri 11/11/11 44 46 Mobile dispatcher role 0.1 hrs Fri 11/11/11 Fri 11/11/11 45 47 What real-time role does maintenance play 0.1 hrs Fri 11/11/11 Fri 11/11/11 46 48 What real-time roledispatchers have in-service training p0.1 hrs Fri 11/11/11| Fri 11/11/11 47 49 Role that risk management plays (safety inspectors) 0.1 hrs Fri 11/11/11 Fri 11/11/11 48 50 What work assignment roles used 0.1 hrs Fri 11/11/11 Fri 11/11/11 49 51 System Administration 0.19 days Fri 11/11/11 Fri 11/11/11 35 52 Does the sys admin relate to operations 0.25 hrs Fri 11/11/11 Fri 11/11/11 53 Is there an operations person involved 0.25 hrs Fri 11/11/11 Fri 11/11/11 52 54 What integration with electronic technicians 0.25 hrs Fri 11/11/11 Fri 11/11/11 53 55 Are NT groups used actively in TM 0.25 hrs Fri 11/11/11 Fri 11/11/11:54 56 Level of integration/reliance on Trapeze or Hastus OPS 0.25 hrs Fri 11/11/11 :Fri 11/11/11 55 57 How active is the day-to-day performance monitoring 0.25 hrs Fri 11/11/11 Fri 11/11/11 56 58 Operations Management 0.21 days Fri 11/11/11 Fri 11/11/11 51 59 Is there direct supervision of dispatchers 0.25 hrs Fri 11/11/11 Fri 11/11/11 60 Indentify Route Types 0.25 hrs Fri 11/11/11 Fri 11/11/11 :59 61 Identify Employee types 0.1 hrs Fri 11/11/11 Fri 11/11/11 60 62 Management oversight of dispatch 0.25 hrs Fri 11/11/11 Fri 11/11/11 161 63 Performance Metrics for Operations 0.25 hrs Fri 11/11/11 Fri 11/11/11 62 64 Is management using TM 0.1 hrs Fri 11/11/11 Fri 11/11/11 63 65 What should dispatchers be doing 0.25 hrs Fri 11/11/11 Fri 11/11/11 64 66 Afterhours roles and responsibilites of dispatch 0.25 hrs Fri 11/11/11 Fri 11/11/11 65 67 Observe Dispatcher Use of TransitMaster 2 0.28 days Fri 11/11/11 Mon 11/14/1:58
Task Name Duration Start Finish Predecessors Resource Names 58 What canned messages are answered 0.25 hrs Fri 11/11/11 Mon 11/14/11 69 What vehicle alarms acted on 0.1 hrs Mon 11/14/11 Mon 11/14/1168 70 What adherence warnings acted on 0.25 hrs Mon 11/14/11Mon 11/14/1169 71 How are Late logon/pullout managed 0.25 hrs Mon 11/14/11 Mon 11/14/1170 72 When are incident reports used 0.25 hrs Mon 11/14/11Mon 11/14/1171 73 Subsystem Health interest 0.1 hrs Mon 11/14/11 Mon 11/14/1172 74 Mechanical Alarm interest 0.1 hrs Mon 11/14/11 Mon 11/14/1173 75 Any use of service adjustments 0.1 hrs Mon 11/14/11 Mon 11/14/1174 76 Any use of external sources of information 0.1 hrs Mon 11/14/11 Mon 11/14/1175 77 Use of road supervisors 0.25 hrs Mon 11/14/11 Mon 11/14/1176 78 Mobile dispatcher role 0.1 hrs Mon 11/14/11 Mon 11/14/1177 79 What real-time role does maintenance play 0.1 hrs Mon 11/14/11 Mon 11/14/1178 80 What real-time roledispatchers have in-service training p.0.1 hrs Mon 11/14/11 Mon 11/14/1179 81 Role that risk management plays (safety inspectors) 0.1 hrs Mon 11/14/11 Mon 11/14/1180 82 What work assignment roles used 0.1 hrs Mon 11/14/11 Mon 11/14/1181 83 Pre Deployment tasks 30 days Fri 11/11/11 Thu 12/22/11 84 Write cut over plan 5 days Fri 11/11/11 Thu 11/17/11 6 85 Santa Monica Review Cut Over Plan 10 days Fri 11/18/11 Thu 12/1/11 84 86 Update cut over plan 5 days Fri 12/2/11 Thu 12/8/11 85 87 Santa Monica review cut over plan 10 days Fri 12/9/11 Thu 12/22/11 86 88 Issue Cut-over Plan o days Thu 12/22/11 Thu 12/22/11 87 89 Deployment of new equipment in Santa Monica 17 days Thu 3/1/12 Mon 3/26/12 90 Receive equipment shipment in Santa Monica o days Thu 3/1/12 Thu 3/1/12 21 91 On site pre go live testing 5 days Fri 3/2/12 Thu 3/8/12 90 92 Cutover to new system 2 days Fri 3/9/12 Mon 3/12/12 91 93 System Go live Support 10 days Tue 3/13/12 Mon 3/26/12 92 94 IDS Customer Configuration Exercise 8.25 days Tue 3/13/12 Fri 3/23/12 95 Initial Training 3 days Tue 3/13/12 Thu 3/15/12
96 Customer Project Team - IDS Introduction 0.75 days Tue 3/13/12 Tue 3/13/12 92 97 Sys Admin 1 - IDS Configuration 2.25 days Tue 3/13/12 ¡Thu 3/15/12 96 98 Walkthrough 5.25 days Fri 3/16/12 Fri 3/23/12 95
99 Run through WA 0.75 days Fri 3/16/12 Fri 3/16/12
100 Run through incidents 0.75 days Fri 3/16/12 :Mon 3/19/12 99 101 Run through IR :0.75 days Mon 3/19/12 Tue 3/20/12 100
Task Name Duration Start Finish Predecessors Resource Names 102 Customer feedback 0 days Tue 3/20/12 Tue 3/20/12 101 103 Implement customer feedback 3 days Tue 3/20/12 Fri 3/23/12 102 104 Hardware and Software Upgrade Complete 0 days Mon 3/26/12 Mon 3/26/12 103,93
EXHIBIT 9-B
AUTOMATED PASSENGER COUNTER TEST PLAN (APC TEST PLAN)
APC Testing Plan
1. Introduction
The purpose of this document is to provide a plan for the re-testing of the Automated Passenger Counters (APCs) installed on the Big Blue Bus (BBB) revenue vehicles.
The document will attempt to improve on the process used in previous attempts to validate the accuracy of the APC units based on the lessons learned and provide for a methodology for determining accuracy that is acceptable to both the City and the vendor.
2. Overview
The City and Trapeze ITS have previously attempted to prove the contractually required accuracy of the APC units installed in all revenue vehicles. The main topics for discussion that were identified as areas for improving the testing are as follows:
1. Planning
2. Documentation Required
3. Counting
4. Analysis
5. Reporting
6. Future Maintenance
2.1 Planning
It was determined that all BBB revenue vehicle types require retesting. However, given that the BBB will be retiring the Thomas fleet of vehicles in the upcoming months, it was agreed that this fleet should not be tested and should be removed from the contract.
Prior to commencing with the retest, Trapeze felt it would be of benefit to re-profile the existing buses and have those profiles approved by the APC manufacturer. Additionally, Trapeze staff will analyze existing reports to determine if any APC units are operating abnormally. Any APC unit that is suspect will be inspected and issues resolved. These efforts will help minimize any equipment related failures that were experienced on prior APC testing efforts.
Per the requirements set forth in the contract, 700 is the minimum number of passengers to be used for testing for each bus. There should be at least 700 passengers on the bus and 700 people off the bus.
2.2 Documentation Required
Run sheets will be generated using data from the Trapeze FX scheduling software. These run sheets contain a list of all BBB approved stops along a route. The count sheet will contain sufficient columns so that manual counters can count normal revenue passengers, City staff (i.e., the Motor Coach Operator (MCO) and the manual passenger counters), and non-revenue generating riders such as small children as each of these groups board or alight a vehicle. The total of these counts will be compared to the counts reported by the APC units in the TransitMaster database. The BBB will collect the additional information to compare the counts with those done recently by the tri-annual Line-by-Line analysis effort.
2.3 Counting
The counting process will be similar to that used during April 2009 testing. Listed here is the proposed testing methodology.
The entire fleet of BBB vehicles is equipped with APC units. As testing of each individual vehicle would be a lengthy process, it was agreed to test a representative subset of each vehicle type. 10% of each vehicle type will be tested. If the entire 10% of the vehicle types pass the APC accuracy tests, the BBB will accept that the remaining vehicles of that type have passed the accuracy tests.
Initially, two vehicles of each fleet type will be tested. If both vehicle of a particular type pass the accuracy tests, testing will continue on that fleet. If one or both of the vehicles fail the initial tests, testing of that vehicle type will stop until an evaluation of the failure can be conducted and corrective measures taken.
700 is the minimum number of passengers to be counted for testing the accuracy of the APC units on each vehicle. At a minimum, there should be 700 passengers recorded boarding a vehicle and 700 passenger alighting a vehicle. It is recommend that the manual counting proceed past 700 counts just to assure that both the manual and the APC counts have exceed the 700 minimum numbers.
During previous attempts at verifying accuracy, the City placed three people on each vehicle in order to conduct the counting process. One individual would monitor and count passengers on the front driver area door. Another individual would monitor the rear exit door. The final individual would record counts that were provided by a laptop that was interfaced directly to the APC unit. The laptop counts tended to be problematic due to power issues and loss of the interface connection. For the next tests it has been agreed that the laptop will not be used.
Therefore the City will only have two counters per vehicle, one to monitor the front door and another to monitor the rear. Trapeze will also provided two counter per vehicle that will sit next to the City's individuals.
During previous attempts to verify the accuracy of the APC units, the City employed a third party company to record the City's manual counts. For these tests, the City will use existing BBB staff that already conduct passenger count surveys and are familiar with the process.
All individuals boarding and lighting a vehicle shall be counted. This includes, but not limited to:
children whether being carried, in strollers or walking, and persons aided by mobility devices.
Special care shall be taken to assure that individuals, such as the bus operator, shall be counted as they may pass through the APC unit's defined profile several times while assisting passengers.
The required criteria for the logging of passenger counts on the vehicles are as follows:
• Integrated Vehicle Logic Unit (IVLU) powered on and booted up completely • APC Units powered on
• The Motor Coach Operator (MCO) must be successfully logged into the system The IVLU will remain powered on for a preconfigured amount of time after the MCO turns off the vehicle's engine. Additionally, the system has a preconfigured amount of time before the system automatically logs an MCO off of the system after engine shut down. Both of these times should be noted prior to starting the accuracy test. When the lesser of these two times is reached, the APC units will cease to record counts that are passed into the system database therefore, the manual counters shall continue to count boardings and alightings during the lesser of the two times should the vehicle's engine be shut off.
Should the MCO log off of the system, counting should cease immediately.
2.4 Analysis
An analysis of the date should be performed immediately following the completion of the counting efforts. Data may still be stored on the Integrated Vehicle Logic Unit (IVLU) for several days before being uploaded to the main database. Reports run against the databases that are used in the process for determining the accuracy of the passenger counter should be rerun for several days following the data collection to determine if there have been any changes.
Manual count sheets should be copied and exchanged at the end of the testing of each vehicle.
Initial comparisons between the count sheets and the reports generated from the TDataMart reports will provide a simple comparison of the counts and accuracy rate. Further analysis and use of the formulas set forth in the contract will determine actual accuracy.
2.5 Reporting
The reporting of the results should be simple, concise, and in a clearly understandable format. All formulas shall be clearly comprehendible. Spreadsheets have been used which incorporate the formulas used to determine accuracy. Both parties shall be involved in creating the spreadsheets and documenting the formulas used and to which cell each formula is associated.
2.6 Future Maintenance
To ensure the success of deploying APC units to the entire BBB fleet, methods need to be in place so that the City can easily identify vehicles with APC units that may not be operating within acceptable parameters. Trapeze staff can run weekly reports that highlight buses that are suspects. The BBB shall also be trained on how to run these reports and how to interpret the data.
Trapeze has also been tasked to detail a plan for the continued testing and maintenance of the APC units. Detail of that plan should be incorporated into this document.
EXHIBITS 9-C
MASTER PUNCH LIST
....
trapeze TIS
to Colin, and a resolution strategy is a work in SMA: 1-15-08: IRMA eport has been given to Colin Probert, and the Fixes recommended by Irma will be part of the get tentatively is targeting mid to late February for well plan. Aucutt working on plan approvai, and their visit. This will be negotiated with BBB. SMA (10/26/11 CP| APC 8-3-09: Conti still working on the APC report for 8B8. SMA 10-6-09: APC Report was provided to testing has been Awaiting Jory Wolf on 9-26-09. MDG 2-15-10: Report produced. On Meeting minutes. Recalibration Aucutt completed. acceptance/rejection of
test results which would done. This should be cosed.
be an indication that of the status of the vehicie SMA 8-3-09: Colin to check on contractual requirements for the Data Dictionary: SMA profiling and calibration Previously: Data Dictionary was sent. Please SMA 10-6-09: Contis efforts. verify receipt of tatest DD. Wibben
position is that this is closed, the city disputes this Gerard
SMA: 1-15-08:: For Coltn Probert this is a work In progress. SMA 1-9-08: Per Colin this will happen Aucutt
after System ATP's are reviewed, and comments
888 (08/13707) - Colin to" sent back.
determine if this functionality works
contrary to the versión 27
8BB (10/15/027-N0E requirement.
Probert currently holding up an
activities, this is just an
consistency.
Aucutt. Chad/Sabrina Work In grogress
Version 27
ips-Mon-neec
oin to look at existing contracts and
naintenance contracte
EXHIBIT 9-D
SYSTEMS ACCEPTANCE TEST PLAN VARIANCES
....
Recommendaton
П Spenish voice fhes stil need to be Isaded into the
Ter muts provided is 88s ad 150 managemet
for thai aceptanco or rejectso
to TAPC tsang comploted, awaits fral acceptanos from 88B. consact a bus directly ser the as so san death so dro in
The Transfer Locator was demonstated is Cof in Orsober 2009 and again in Colin to review Global seting charge Chad and Coks w
ha test witsete Bus
Satra working with Steeizeth so get So triggers Chad previded dasabeses shat Subrina should i reseve messages abou
Wak urdi October 20, 2011 for Roel Vis to conn
back with a scluton Corn so speak with raesgenact
Coln to speak with managemert
a bit October 20. 301 or Rol Via s some
Colin to spont we maragement
Mock of Chad Moore to explore with
Dare Futen.
co1.be. Trapeze demonstrated this fundsonality via the SDS decamentaten. i Satdha to fotow un
Might have to walt ons OfS-ManInterface is in
herbace. Wat unes the Versien 28 uggate sin
and location of points and then select a day to 80 Sabrina to meet with Colin and out and test.
BBB
Recommendation Management decision
Tina: Wishes to have the message
New version has a whole section on sent several times. Once a no- Trapeze Status 10/6/2011 calls and tracking. Recommend acknowledgement signal is bile has two types of messages, reliable messages and data Action for a reliable message is dependant on the message conditionai ok with upgrade to 28 received, dispatch should be as suggested by Bill Hiller. notified.
ome reliable messages such as a MDT started or Covert alarm e are re-queued and resent until they are acknowledged. A time ssing message is tried up to three times and then logged in orage. The vehicie location message data grams are sent once 1 discarded. For operator-initiated messages, if the message t get through an indication is provided to the operator. in the I PRTT, and RTT's if these are not acknowledged the sender is Fallback is a critical system failure that needs to be corrected. If the system is in! his time, everyone is informed of the situation. :,there are many indicators that identify something is wrong. uses no longer receive data, the bus is marked with a red X on Map. The message age as reported as part of vehicie details on cle tab and AVL map continues to grow. Eventually vehicles the map and are not availabie in call lists. The system is not es can be sent and require a user acknowledgement. This try to resend if a vehicle is in fallback. Text, canned, and voice lay be selected on the Action tab in the communications dialog. ledgements can be monitored using the communications history t was demonstrated December 2010 in the latest version of IDS : that alarms can be configured based on ssageReceivedDuration to war users of delays in lications with vehicles. An upgrade to the TransitMaster IDS offers functionality that can provide an automated approach to al data communications and Trapeze will work with BBB to e alarms based on message age as demonstrated to the City. d in release version 28.
¿version upgrade. New software can Recommend conditional ok with procedure states that the requirement is met per the aiternate trated how the new IDS system software can support the originai be configured easily to generate this BB has agreed to review and confirm. In December 2010 it was as per. our specifications.
TransitMaster Version 26 was
rent. An upgrade to the TransitMaster IDS solution offers ality that meets this requirement in entirety via canned es and the creation of user defined updating rules. Delivered in demonstrated version 28.
Procedural question. Ask if dispatch
iginal proposal, the response to this requirement was qualified wishes to have this function- statement that the offer was a "Standard feature". An "ack recommend conditional ok with "queue is automatically formed whereby vehicles automatically he queue as they respond. The dispatcher can set a timer to n upgrade depending on contract to remind them if the queue is not empty. The dispatcher can requirements (can show a glance, ail vehicles that have not responded. This was screenshots). The new system ed in our proposal and BAFO comment and was not changed definitely does allow for le SDS phase of the project. To ciarify existing capabilities, configuration of the items showing es that have not been acknowledged are reported within the in the call queue. TransitMaster nications History tab. A warning timer can be configured by the ler for each message depending on the amount of time that they Version 26 was demonstrated. ‹e to allow before being warned about the lack of edgement of the message. A listing of the non-acknowledging an be populated in a call list for a subsequent transmission of the message by the dispatcher. The reason behind this is that the have different responses that require dispatcher evaluation such Acked, Expired, Yes, No, and Pending. Additionally, ments in the latest IDS release demonstrated December 2010 in | lowledgement Pane make it easier to work with Driver on needed. Trapeze requests that dispatch review the existing edgement through auto filters and smart filtering. Further ality to determine if it meets operational needs. Additional ion on these and other related features can be found on pages : of the 01M0151-002-E_ OperationsAVLMapSystem_Rel 23.1 This feature is available in versions
nsitMaster system allows for global and by line settings and or 27 and higher of TransitMaster n of the adherence thresholds as opposed to by time of day. Santa Monica software version does not adhere to the time of Jirement, thus failing this element. An upgrade to the Master IDS solution offers functionality that meets this nent in entirety as demonstrated November 2010.Delivered in This feature is available in versions
ansitMaster system can "require incident report" for selectable 27 and higher of TransitMaster jes and prevent the deletion or clearing of messages that require lent report until the user has created the incident report. The user rompted that the report requires creation unless they try to delete dent. The City agreed to review this with BBB management to if BBB requires a prompt for the creation of an incident report for alarm event for which an incident report is required. Additionally, a demonstrated that with a system upgrade, an IDS action plan ludes an "Incident Report" action item would require the her to indicate completion by adding a check mark to the w. The delete properties of an incident include logic whereby an pening the communication window to listen-in on a silent alarm t cannot be deleted until checked. Also, it was demonstrated how › be recorded that are added to an incident report upon creating ow the notes pane within the communications window permits dent report. This flow of information is designed such that an t report does not take over the screen when in the middle of g an emergency. In addition, automated Email capabilities of ts can be configured. Demonstration of new functionality provided 1 offers functionality that addresses this requirement. Delivered in city November 2010. An upgrade to the TransitMaster IDS ›posal comments state, "All alarms are logged in the database for This feature is available in versions 27 and higher of TransitMaster review." In November 2009 Trapeze demonstrated to the City stration was provided on the SharePoint site. Additionaily, it was this information is stored. A sample query used for the strated in November 2010, that easy access to mechanical alarm a timestamp data is possible in the latest IDS system through the ministration audit history. Audit history is looking at the stored ta. An upgrade to TransitMaster IDS offers further functionality. ed in version 28. Talk to Maintenance and Dispatch-
isting in October 2009 the City took action to review with BBB ement. Demonstration of new IDS functionality provided to the Bill Hiller had problems with his it triggered by LogonFailureReason = Reserved for Maintenance. system - once he shows me the end cember 2010. The new IDS system has ability to create an product, will definitely recommend (rade to the TransitMaster IDS solution offers functionality that conditional ok with upgrade. These this requirement in entirety by creating the necessary Incident items are easily configurable in the ed by the Logon Failure event. Delivered in version 28. new system. Next webex will show the end product.
This feature is available in versions
w IDS system includes the fields Layover Duration and Minutes ayover were demonstrated in November 2010. By creating distinct 27 and higher of TransitMaster • tabs, sorting, and autofilters dispatchers can create views to tand the upcoming layovers and their impacts on revenue service. al Timepoint field can be configured in the same manner to view service status. A total of five distinct tab views can be created. An e to the TransitMaster IDS solution offers functionality that meets uirement for understanding real-time layover and end-of-service Delivered in release 28 Version 28 Upgrade. Confirmed to w IDS system includes the fields Layover Duration and Minutes exist in Version 27 and functionality ayover were demonstrated in November 2010. By creating distinct is in Version 28. : tabs, sorting, and autofilters dispatchers can create views to tand the upcoming layovers and their impacts on revenue service. tal Timepoint fieid can be configured in the same manner to view service status. A total of five distinct tab views can be created. An e to the TransitMaster IDS solution offers functionality that meets uirement for understanding real-time layover and end-of-service Deliver in version 28. surrent version of software, this requirement is met by the late pull This feature is available in versions 27 and higher of TransitMaster rm icon that is displayed in the TMBusOps application display. hicie/driver information is also indicated in red once the ired parameters are met within the TMBusOps pull tab. an t Report is not automatically generated, but can be required for tion by the dispatcher for such an event. The new IDS system is the capability to create a late pullout alarm based on user- d parameters. An incident Report can be required before the it is removed from the queue. This was demonstrated in nality that meets the requirement. Delivered in version 28. iber 2010. An upgrade to the TransitMaster IDS solution offers exist in Version 27 and functionality Version 28 Upgrade. Confirmed to rent software version meets the requirement by the ability of the her to sort the messages within the queues as they see fit. City to is in Version 28. ras the new IDS approach to "priority" and how this is an agency- explanation with BBB.Discussed and demonstrated in November ecision and not arbitrary by dispatcher. However, dispatchers can eir queue based on any column and can work on incidents out of lased on their expertise. Incidents with priority of less than 50 can igned to up to five user configurabie incident queues for filtering ired by the system administrators to account for different es. Alternate actions plans as weil as alternate rule sets can be ing conditions surrounding the same incident. Dispatchers can teir setup with "roaming" capabilities. An upgrade to the Master IDS solution offers agency definabie priority functionality any features to assist in dealing with different operational ios. Deliver in version 28.
Version 28 Upgrade. Confirmed to
irrent software version meets the requirement by the ability of the exist in Version 27 and functionality her to sort the messages within the queues as they see fit. City to is in Version 28. he new IDS approach to "priority" and how this is an agency-wide explanation with BBB. Discussed and demonstrated in November on and not arbitrary by dispatcher. However, dispatchers can sort ueue based on any column and can work on incidents out of order ed to up to five user configurable incident queues for filtering on their expertise. Incidents with priority of less than 50 can be ¡es. Alternate actions pians as well as alternate rule sets can be the system administrators to account for different operating ons surrounding the same incident. An upgrade to the tMaster IDS solution offers agency definable priority functionality 18s. Delive oversier 28% that with the new IDS software the any features to assist in dealing with different operational This feature is available in versions 27 and higher of TransitMaster
on and garage IDs are provided and agency has fuil control on ind sound of PRTT dispiay. An upgrade to the TransitMaster IDS * offers functionaliy that meets the requirement. Delivered in This feature is available in versions
sions). Showed how the status of the Silent Alarm is recorded in ib that tracks a vehicle in an emergency state continuousiy (true in 27 and higher of TransitMaster listory as the dispatcher takes actions. in addition, we reviewed ection and garage ID in details. An upgrade to the TransitMaster slution offers functionality that meets the requirement. Delivered in n 28.
This feature is available in versions
strated in November 2010 that with the new IDS software the 27 and higner of TransitMaster on and garage IDs are provided in the message details. An te to the TransitMaster IDS solution offers functionality that meets quirement. Delivered in version 28 This item is included with Release rember 2010 critical transfers were demonstrated in the existing 27 of TransitMaster. This item is aiso n soffware and demonstrated to be working as designed to meet included in version 23.1 of TransitMaster currently in use by quirement. The City to confirm closed. BBB.
This feature is availabie in versions
rember 2010 a demonstration of the new IDS systems showed 27 and higher of TransitMaster le details can be opened and pinned prior to a voice cail that ys alongside the communications dialog window if the dispatcher ; this information is critical at the time of a cail. Garage ID is visible IDS queue if the user selects to view the column. An upgrade to ansitMaster IDS solution offers functionality that meets the ement. Delivered in version 28. This item is included with Release rember 2010 it was demonstrated in the new IDS system how 27 of TransitMaster le vehicle tabs can be created to sort and filter to display cional information including minutes to last timepoint, minutes until in offers functionality that meets the requirement. Delivered in er, and Layover duration. An upgrade to the TransitMaster IDS n 28.
Version 28 feature
Chad to check if this is a function in
stem design is based on the technology limitation given limited Version 28. Chad to speak with Bill Hiller.
i a problem. Trapeze requests a discussion with BBB to address sional issues this limitation is causing.
Version 28 upgrade will provide for
ze contends the proposed method of importing the schedule data an easier method to merge data. ansitMaster was included in the SDS documentation as accepted City. The City to confirm closed.
Version 28 upgrade
4VLMap help is available online via the integrated help via usOps. Trapeze had proposed that the customer service be ded with the TMBusOps application and that by means of the ecurity features the application be limited to giving them the access : AVL map which contains the online help. This was tested and onstrated to Colin during the week of 10/26/09 and the City pted. The City to confirm closed.
Version 28 upgrade
usOps. Trapeze had proposed that the customer service be e AVL map which contains the online heip. This was tested and instrated to Colin during the week of 10/26/09 and the City pted. The City to confirm closed.
BBB
Management decision
Test Plan Recommendation
OMMENTS Moved to warranty
e Order 7, and will be Moved to warranty
anty.
e Order 7, and will be Moved to warranty
anty.
.........: ..: Moved to warranty
ie Order 7, and will be
Defer to warranty: Part of
The City will review and confirm if OPS/Transitmaster interface ses not currently have further incident report definition is customization. eport, remote disable required by Trapeze. Trapeze is
alarm, vehicle change ready to modify or create incident dherence, detours, Reports given detailed specifications rebox bypass, safety or entertain a credit should BBB
laint & Compliments, decide to create the required
its. These are all Incident Reports themselves.
sfy the requirements.
an create the reports
direction from BBB
ields that should be in
Defer to warranty: Part of
bes not currently have The City will review and confirm if OPS/Transitmaster interface eport, remote disable further incident report definition is customization. alarm, vehicle change required by Trapeze. Trapeze is ready to modify or create Incident dherence, detours, Reports given detailed specifications rebox bypass, safety or entertain a credit should BBB
slaint & Compliments, decide to create the required
orts. These are all Incident Reports themselves.
sfy the requirements.
an create the reports
direction from BBB
ields that should be in
EXHIBIT 9-E
REVISED BILLING MILESTONE
EXHIBIT "9-E"
REVISED PERFORMANCE MILESTONES
Milestone Description MS Billing S
1 Notice to Proceed 310,710.56
2 Vehicle - Survey. - (By Vehicle Type: Bus, 186,426.33 Supvs, PS)
3 Site Surveys Complete 124,284.22
4 Approval of Project Plan 186,426.33
5 Fingerprint Logon Design Approval • 186,426.33
6 Fingerprint Logon Equipment Delivered to 186,426.33
ILG for FAT
Dispatch Center Survey Approval 124,284.22
8 Site Design Approval 186,426.33
9 Dispatch Equipment Delivered to ILG for 248,568.45
FAT
OnStreet Signage Delivered to ILG for FAT 186,426.33
11 Computer Network Design Approval 124,284.22
12 ATP Approval 186,426.33
13 Cutover Plan Approval - Brick Building 124,284.22
14 Network Equipment Delivered to ILG for FAT 310,710.56 15 Vehicle - Mechanical Design Approval - (By 186,426.33 Vehicle Type: Bus, Supvs, PS)
16 Dispatch Center Equipment Approval 186,426.33
17 FAT Approval 186,426.33
18 OnStreet Signage Installed 186,426.33
18.1 OnStreet Signage Installed-CO#7 -2,143.00
19 Prototype Installation - 12 186,426.33
20 Network Equipment Approval 186,426.33
20.1 Contract Mod 1 Addition 77,398.32
21 GeoCode Routes Complete 186,426.33
22 Final Prototype Design Approval 186,426.33
22.1 Damage to Property Credit Memo - CO #5 -17,225.81
Damage to Property Credit Memo - CO #7 -1,139.65
23 Training and Documentation Complete 248,568.45
24 Vehicle Installation - 10 186,426.33
24.1 Contract Mod 7 - Application of Vehicle -53,826.50 Removal Credit (10%)
CO #7 Reduction of 4 Annunciator Systems -3,779.00
CO #7 Reduction of 4 APC -9,591.00
CO #7 Descope 300 Vehicle Operator Quick -600.00
Reference Decals
CO #7 Delete installation on Vehicle #75 -414.00
24.2 CO #9 Passenger Counter Expenses 41,732.94
24.3 CO #9 Delete Installation on Thomas -10,740.00
vehicles
25 Vehicle Installation - 60 186,426.33
25.1 Contract Mod 6 - Application of Vehicle -107,653.00 Removal Credit (20%)
26 Vehicle Installation - 60 186,426.33
26.1 Contract Mod 7 - Application of Vehicle -107,653.00 Removal Credit (20%)
27 Vehicle Installation - 60 186,426.33
27.1 Contract Modification 4 (Vehicle Reduction - -538,264.93 52)
27.2 Contract Modification 7 - 27.1 Applied 538,265.00
Across Multiple Milestones to reflect CO 6
27.3 Contract Mod 7 - Application of Vehicle -107,653.00 Removal Credit (20%)
28 Vehicle Installation Approval 186,426.33
28.1 Contract Mod 7 - Application of Vehicle -80,739.75 Removal Credit (15%)
29 Vehicle Installation - 32 186,426.33
29.1 Contract Modification 4. Vehicle Additions—3 85,531.00
29.2 Contract Mod 7 - Application of Vehicle -80,739.75 Removal Credit (15% of BM 29 Only)
29.3 Contract Modification 7 - Credit for handset -14,700.00 cord length modification and de-scope Street
Index by Route Report
30 ATP Acceptance 186,426.33
30.1 Liquidated Damages -97,500.00
31 Final System Acceptance 497,137.00
31.1 Contract Mod 3. Antenna Site lease refund -30,000.00
31.2 Contract Mod 3. Antenna site lease credit -71,068.58
31.3 Contract Mod 3. T1 cost refund -110,139.00
31.4 Contract Mod 4. Radio Frequency Change 45,948.00
31.5 refuract Mod 7. GPRS Modem Upgrade -785.00
Total (W/Out Tax) 5,473,265.57
A. Except as expressly set forth in this Ninth Modification, all other terms and conditions of the Original Agreement, First Modification, Second Modification, Third Modification, Fourth Modification, Fifth 3,
........
Modification, Sixth Modification, Seventh Modification, and Eighth Modification, shall be and remain in full force and effect.
IN WITNESS WHEREOF, the parties hereto have duly executed this Ninth Modification on the day and year first above written.
TRAPEZE SOFTWARE GROUP, INC.
By: By:
(Signature) (Signature)
Title: Title: