The URL can be used to link to this page

Home My WebLink About5.D.2. Automatic Vehicle Locating Draft Operating Agreement `�,/J.�• GTY OF SHAKOPEE I Memorandum � � !"'' "", r _ � � �� I �� ' �� TO: Honorable Mayor and City Council Mark McNeill, City Administrator FROM: R. Michael Leek, Community Development Director SUBJECT: AVL/SMARTCoM Draft Operating Agreement MEETING DATE: January 3, 2012 � INTRODUCTION: The Metropolitan Council (Met Council) has asked the City to enter into the attached operating agreement regarding and AVL (i.e. automatic vehicle locating) system known as SMARTCoM. DISCUSSION: The AVL equipment is installed on the buses which Shakopee uses in connection with the BlueXpress. The equipment apparently does allow for tracking bus locations, but to i date it has not allowed the City's contract provider (Schmitty & Sons Transit, Inc.) to generate useful information and reports using the system. , Staff has concerns about the agreement as follows; , , • The City has had no role in selecting the equipment and software, or negotiating the terms of the agreement with the provider of the SMARTCoM system; ' • The agreement obligates the city to pay costs for maintenance (Article V) and , software (Article VII) which are not fully know, and which the City has no control � over. � In light of those concerns, staff had this agreement reviewed by the City Attorney, �� James Thomson. Mr. Thomson did not identify any specific concerns, and noted that if � there were issues or problems, the City could get out of the agreement with sixty (60) , � days' notice. At this time only a few of the suburban transit providers (e.g. Maple Grove) have ' ' adopted the SMARTCoM agreement, while others such as Plymouth and Prior Lake have had concerns similar to those outlined above and have not approved entering into the , operating agreement. ; � H:\CC\2012\1-3-12\AVL Agreement_01032012.docx Page 1 I, _ I � ALTERNATIVES: 1. Offer and approve a motion directing the appropriate City officials to enter into the I I SMARTCoM agreement as presented; 2. Offer and approve a motion declining to enter into the SMARTCoM agreement at � this time, and direct staff to communicate the City's concerns in writing to the Met � Council; i 3. Defer action on the SMARTCoM agreement for additional information regarding other suburban transit providers' adoption. I TRANSIT ADVISORY COMMITTEE RECOMMENDATION: On December 15, 2012 the TAC reviewed the draft agreement, and recommended to the City Council that it decline to execute the agreement at this time and communicate the concerns outlined above to the Met Council. I ACTION REQUESTED: Offer and approve a motion declining to enter into the SMARTCoM agreement at this time, and direct staff to communicate the City's concerns in writing to the Met Council; I o /'> �� -, �� R. Michael Leek Community Development Director � I � � � I i � H:\CC\2012\1-3-12\AVL Agreement_01032012.docx Page 2 � � i __ _ _ _ . _ __ _ ._ _ _ _ I I � � CITY OF SHAKOPEE , Memorandum T . O• Shakopee Transit Advisory Commission TAC � ) FROM: R. Michael Leek, Community Development Director ' � I � SUBJECT: AVL/SMARTCoM Draft Operating Agreement MEETING DATE: December 15, 2011 I INTRODUCTION; I � I The f�letropoiitan Council (f�et Councii) nas asiced ine �ity to enter into the attached '�� operating agreement regarding and AVL (i.e. automatic vehicle locating) system known , as SMARTCoM. I ' DISCUSSION: I � The AVL e ui ment is installed on the buses which Shako ee uses in conne � q p p ct�on with . I � the BlueXpress. The equipment apparently does allow for tracking bus locations, but to date it has not allowed the City's contract provider (Schmitty & Sons Transit, Inc.) to 'i generate useful information and reports using the system. � Staff has concerns about the agreement as follows; i • The Cit has had no role ' I y m selectin the e ui ment and software or ne i� � g q p , got ating the terms of the agreement with the provider of the SMARTCoM system; ! • The agreement obligates the city to pay costs for maintenance (Article V) and � software (Article VII) which are not fully know, and which the City has no control ' over. I In li ght of those concerns, staff had this a reement reviewed b the Cit Attorne g Y Y Y, James Thomson. Mr. Thomson did not identify any specific concerns, and noted that if ' her w t e ere issues or problems, the City could get out of the agreement with sixty (60) ; I da s' notice. ' Y I At this time only a few of the suburban transit providers (e.g. Maple Grove) have adopted the SMARTCoM agreement, while others such as Plymouth and Prior Lake have ! had concerns similar to those outlined above and have not approved entering into the �, operating agreement. ' I i H:\TRANSIT\TransitCommission\12152011_AVL Agreement.docx Page 1 i I i � ALTERNATIVES: 1. Recommend to the City Council that the City enter into the SMARTCoM agreement I as presented; �� 2. Recommend to the City Council that the City enter into the SMARTCoM agreement I with revisions; 3. Defer action on the SMARTCoM agreernent for additional information regarding I other suburban transit roviders' ado tion. I p p I � � STAFF RECOMMENDATION: I i Because of the concerns outlined above, staff recommends alternative no. 3 above, i.e. I , defer action for additional information on ado tion b other u r p s bu ban transit roviders. Y P I � � I �CTI�(v RE�u�STE�: i I �I Defer action on the SMARTCoM agreement for additional information r�garding �th�r � suburban transit providers' adoption. � � I � °i � J I -/�� .�/�f 1 �`�� -' J� I i R. Michael Leek I � Community Development Director � i I i i I i I I � I i i I i � I � H:\TRANSIT\TransitCommission\12152011_AVL Agreement.docx Page 2 � I I i - - — — — - — - - - - � FINAL DRA.FT July 29, 2010 INTERAGENCY AGREEMENT I St. PauUMinneapolis Advanced Regional Transit Communications/Management �I (SMARTCoM) Operating Agreement � i This Interagency Agreement ("Agreement") is made and entered into this day of I , 2010, by and between the . [Part� , a I � �� ,, (" ") and the Metropolitan Council, a publ�.� corporation and political I �� subdivision of the State of Minnesota ("Council"). �� `� I �� I � � �� t , �. °�� RECITALS �& � "� � �i�� I � �' 1. The Council owns and operates, and may contract for, most o��3� �r��ional bus � I transit system in the Minneapolis-St. Paul metropolitan area. ¢�� 2. The Council owns a dispatch and fleet management system referred to in this I ��y� � Agreement as the SMARTCoM Systeza;�`�'�SMARTCoM") which when installed in buses I �,� �� enhances bus service and operations by' �£aci11-#��g,�ixed time connections, service quality I � ��f ;�� monitoring, bus security, route scheduling, e�hanced far��t��tion, and provision of real-time I �- � � �,�, �-;; ,. � customer information. � ' � f"'' � 3. Pursuant to its powers under Minnesota law, including Chapter 473 and Sections ' I �� 471.59, the Council may enter into interagency agr',�ements with other transit providers in which �;,;� , other trans�� may utilize SMARTCoM under the terms and conditions of such j � ;.:� � 2 � agreem�ts in order to e�iance their respective and coordinated operations, thereby allowing I ��, � ��., �� searnless��nmunication cc� ectivity not only between the Council's and I �� 7� bus transit �ems but bet��n and among the bus systems of other transit providers in the I y,�; �� ; . Metro area. �" �' ..� � ��,� I � � �<= � .,:, 4. Part �; `Provider as that term is defined below in this Agreement and owns � and/or operates, or may contract operations for, a bus transit system in the Minneapolis-St. Paul I i metropolitan area. I � 5. Pursuant to its powers under Minnesota Statutes , Partv may enter into I an agreement with the Council to use the Council's SMARTCoM for the purposes stated above � in Recital No. 3. � � i � � I I July 29, 2010 I 6. The Council and Partv have determined that it is in their mutual best interests to enter into this Agreement which sets forth the terms and conditions for use of SMARTCoM by I � Partv . � I , NOW, THEREFORE, for valuable consideration the sufficiency and receipt of which is I hereby acknowledged, the Parties agree as follows: I I � � AGREEM�NT I �� L Purpose � � I I � The purpose of this St. PauliMini�eapolis �� Advanced Regional Transit � Communications/Management (SMARTCoM) sys�� (Jperatin� Agreement ("Agreement") is to , � define the rights and obligations of the Parties with resp��t t�a�� wnership, operation, maintenance i and use of SMARTCoM. Definitions used in this Agreern�i�t, including terms in the Recitals I � °� � and this Section l, are found in Section 2 of this Agreement. �� a� I � II. Definitions I �� r: , Agreement �,�`�� reement" �neans the St. Paul/Minneapolis Advanced Re�ional Transit I �; : , Communications/Manage�a.e�at (S�+�A�.TCoM) Operating Agreement, i � , � � ;� � �� ; � :,., p x ' � ,� ;`� � �PC. "APC" means �,t.�omated Pas�eriger Counter, a device that counts and tracks the � ��,,� number of people entering and exifr�i a b�s. I `�� . ;..,, � � -_ <� I AVL. "AVL" means Automated Vehicle Location, a technological system that tracks the � location of a vehicle. � � � Components. "Components" means equipment that is part of the SMARTCoM System including mobile data terminals, data radios, IVLU, automated passen�er counters, in-vehicle I antennas, wireless access points, cablin�, antenna, and associated equipment, covert alarm button i I or switch. '� Council. "Council" means Metropolitan Council. ' I Council Network. "Council Network" means the computer networlc used and maintained bv the Metropolitan Council for communicatin� between com uter svstems. i � � ' y I � I � l July 29, 2010 Data. "Data" means representation of facts, concepts, and instructions in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means including the collections of information, facts, and events intended to be organized and used to present information in a usable format. � TVLU. "IVLU" means integrated vehicle logic unit, an on-board computer system that enables fleet management. � .. � � `�� '�� ,-; _��_�J aintenance Agreement. "Maintenance Agreem��# means the SMARTCoM : � �r II {�:..�.-E-�1�.1>'_ � � � �,� � � � �� "�'�� maintenance agreement entered into between Met Council an� Ver�t`�.�t�� r �� ' Database. "Database" means the organized system that stores SMA�,.�CCoM data. �� e .� �� 1`�et�� Transi�. "Metro Transit" means the division of the T�etrop�l��n Council primarily responsible for operations of the Council's regular route transit �'msystem in the metropolitan area. � , ��r MTS. "MTS" means Metrop�t`��t�n�:ttTransportation Services, a division of the �»,�� Metropolitan Council responsible for Transportati� �'].aa�ning and contracted services in the � � � �'. Metro olitan area. 1 ��°.. �� z.�� r �-;�;.� s.r r A�� Operating Costs. "Operating Costs" me�a,t� those expenditures for the cost of operations, � ��... �: i administration, and maintenance of the AVL and AP� system. �, �� PartlC�a��g T7ser or Users. "Participating User or Users" means a party or parties �;�,, '�;:. �. other tka�an� Part with'wlxoz� the Council has entered into an ab eement for use of SMARTCoM. � � �;�:.. � €`. I Pa=rty "Party" mean�#�ither the Council or a Regional Transit Provider. ��,�.� � � �. � Provider �`Provider" rneans either the Council or a Regional Transit Provider as defined h P; � in Minnesota Statute 473 3$$ �� e Regional AVL�`'Operations Committee. "Regional AVL Operations Committee" means the group of representatives from the Council, Part and other Participating Users which, with I respect to SMARTCoM, reviews and approves amendments to Approaches and Practices and I I Regional Standard Operatin� Procedures, oversees regional training, and resolves SMARTCoM operations and maintenance issues and reviews and recommends changes to the SMARTCoM System. 3 _ 3uly 29, 2010 Regional Transit Provider. "Regional Transit Provider" mean transit provider, apart l i from Metro Transit, providing fixed route transit service in the region. I SMARTCoM System. "SMARTCoM" means the St. Paul/Minneapolis Advanced I Regional Transit Communication Management System that facilitates transit service and fleet I management.. ��; Software. "Software" means the central control and processing of AVL functions, ; - �� i including driver software for data collection and data disseminatzc��"°t�.�3.evices, the Internet and web �' ��:�� interfaces. � �5 � �� i3 �,. SOP. "SOP" means Standard Operating Procedure. I �; I System. "System" means the SMARTCoI�2 System. �� :�� : �':�; ,,' VVarranty. "Warranty" means the warranty for equipment or software provided by the AVL vendor. �,��. �: �,� � � . . Vendor. "Vendor" means the cornpa� �i�avidmg the Regional AVL System and its � �� warranty. �� t� �° ti�� III. Ownership of SMART�oM �,. �� l. General Ownership. Except as o specifically provided below in this �.. Agreement, th��uncil owns the SMARTCoM System, including all Components thereof s�, �" ��., wherever�located or installed, including all Components in the Council's re�ional vehicle fleet, in ��, � Pa ,�� W�hicle fleet, ga�r��s or other facilities and buildings, the Council's Transit Control � Center, anc��'��lier Council ovc�ied or controlled buildinbs, garages and facilities. �. 2. S�D:,f�vare OwaCtership. The Council shall own the central system equipment �'�� F�� including the SMARToM� System software, licenses for software, servers housing the software �;?° and all equipment ne��ssary for those servers to run and operate the SMARTCoM System as needed. Nothing in this Agreement shall constitute a conveyance, grant or transfer of ownership of any pre-existing to this Agreement real, personal, or intellectual property owned by Partv , and Partv shall continue to exercise exclusive ownership of all property and equipment previously constructed, installed, or integrated on or with Partv's property. I 4 �' � July 29, 2010 3. Data Hosting and Use. The Council shall host the Data generated from the SMARTCoM equipment and the Databases created to house the data. Sub'ect to the � J requirements and restrictions of Minnesota Statutes ("Data Practices Act"), Partv has the right to use Data and Databases during the term of this Ab eement for purposes related to their participation in the SMARTCoM system. In accordance with the provisions of this Agreement and the provisions of any Agreement between the Council and a Participating User, [Partvl and any Participating User may draw any data from the Databases, as long as the drawing of data does not affect the overall operations of the Database and network or the operations of the Council, PL artvl and any Participating User. � Part agrees to follow the Data and Reporting polic�;�escri��d in Exhibit A. .�;�; . $..�.5..�.�: C�e•. - �� $�i.� �''{`, �ij a�3 IV. Installatit�� r . �� :� �� S Purchase.and Installation. As of the date of this Agre�';�.ent, the Council has purchased � ��. . �� ,_ �.,E and paid for the SMARTCoM System and the Council s Vendt��-�has, at Council's expense, �� ,.. installed Components in the fleet vehicles operated by [Partyl, and in [Party's] �ara¢es or other ; ._ �,�. ' facilities owned or oper�fi�cl�� [�artv]. As of the date of this Agreement the Components �°„ � � installed by Council's �e:udor are �onnected to the SMARTCoM System. �� : �� , V. Op�r�ions ai�i� NT��n�enance/Cost Allocation I G� �iL.e., .r,�L�'C��=G`c�}• �'�f —% �a.G.Q.. ..�'.�"�i °' Ji'�.. I �'„ � -��''� " , �1. Party's Responsibil"i��£o�'N Maintenance Agreement Costs. Partv shall i � be responsible for operating and ma'u�aining the SMARTCoM Components located in the fleet i I vehicles operated by [Partv] in accordance with the terms and conditions of this Agreement � I including all Exhibits hereto. [Party] is responsible for providing at its cost electrical power to the SMARTCoM access point in its garage or facility and for supplying its own materials and ! ' equipment necessary to interface with the SMARTCoM Software, including supervisory or operational support. [Partv] shall be responsible for maintenance, repair, replacement, and �I � Operating Costs of any kind not included in the SMARTCoM maintenance agreement associated I with Components on regional fleet vehicles it operates and maintains. 2. Council's Responsibility for Non-Maintenance Agreement Costs. The Council shall be responsible for operating and maintaining in accordance with the terms of this I I 5 I I i _ ___ _ _ _ _ __ July 29, 2010 I A�reement servers and network components including, but not limited to, wireless access points, associated wiring, network connec�ivity to the [P�'s] garage, including routers and T-1 �� connectors, and infrastructure located within the Council Network. , The Council shall be responsible for maintenance, repair, replacement, and Operating Costs of �'� any kind not included in the SMARTCoM maintenance agreement associated with Components it operates and maintains. I� � �� .s� I Part ] hereby grants to Council the right to enter up� � its vehicle fleet, garages, buildings or other facilities with prior notice to and consent��'��'ty] for the purpose of the �� ` � { Council fulfilling its responsibilities under this Agreement `�� 4 �. 3. Allocation of Maintenance Agreement Costs. [Partv] sli�. ��hare the costs of I � �� , '� the SivI�TCoIVI IVIaintenance Agreement based upon the percentage of the ms�trt�mental vehicle I fleet that it operates and maintains. The percentage is calculated as follows: , Number of instrumented vehicles (both revenue and non-revenue) from fleet operated b fy Partv„1 ' Total number o��nstrumented vehicles in fleet . G ��L�� f�%..�'..�' � � ; �, �� I i The Council shall pay the Vendor fo�r the'��naairitenance costs in accordance with the terms , of the Maintenance Agreement and shall invo�ce t1�c [P__a��;�'o�``a pro-rata portion of such costs based upon the above percentage. [Partv] sha�� pay such �invoices within thirty (30) calendar days. I � s With consultation of [Party], the negotiatis�ns the Maintenance Agreement including I �, costs shall be sc��e�� he esponsibility and at the discretion of the Council. 'I s � �'��k � ��. ` � � . �.�� . '� ,;: �, ::. , Council Resg�nsibility for Software/Database Operation. The Council shall � �. .., be responsib�� for operatmg �ic� maintaining the SMARTCoM Software and Databases. '� ��. 5. �C�iin�liance ��vith Approaches and Practices and Regional Standard � � � ,� ,' � Operating Procedu�res,,�� [` Partv 1 hereby agrees to comply with and be ;�:�� ;,, bound by Approaches� Practices attached hereto as E�hibit A including all attachments and as amended from time to time in accordance with the procedures set forth in Section VII and IX of this Agreement. I i Further, [Party] hereby a�rees to comply with and be bound by the Regional Standard Operating Procedures attached hereto as Exhibit B as amended from time to time in accordance I with the procedures set forth in Section VII and IX of this Agreement. � � 6 I � � � .�uiy 29, 2010 The Council shall require, through written agreement, that other Participating Users which have had installed and are using SMARTCoM in their vehicle fleets, garages and/or other facilities shall operate the SMARTCoM System based upon the Approaches and Practices attached hereto as Exhibit A, as amended, and the Regional Standard Operating Procedures attached hereto as Exhibit B, as amended. I, VI. Operations and Maintenance - Warra��es;�� Manual, Maintenance Agreemen� �`: I F � � � � ' Vendor Compliance Requirements. Council and [�;_�rtv] agr��.�o operate and maintain , �:, � :�� the SMARTCoM System and Components for which each is responsible p�3r�uant to the terms of �� ; I, � this Agreement in accordance with the applicable manufacturer's Waxranty, ��,�o�ry of which is I, � �� 4 �', attached hereto and incorporated herein, as Exhibit C. Further, Council and �[P�] agree to , comply with applicable provisions of standard manufacturer's specifications and requirements '� � i and Vendor-supplied manuals, as amende�l�nd [Partv] agrees to participate in and comply with �� . the applicable provisions of t L} e Mair}�enance A�e�ment as amended all of which specifications ' �'-�,�� x , , ��° � i =�" and re uirements o erations manual and 'Maint `` '��. ! q � p en��: greement, as amended, are more � � � �; specifically described, referenced and detailed u�:�he manufacturer's Warranty attached hereto as �, Exhibit C. �� The Council shall re uire throuQh written a ' Q �ement that other Partici t q b �` pa in� Users which I �_� have installed and are using SMARTCoM in their vehicle fleets, garages and/ar other facilities shall operate the SMARTCoM Systems and the Components for which they are responsible pursuant to the terms of this Agreement in compliance with the terms and provisions of this i Section VL � � VII. Approaches and Practices and Regional Standard Operating Procedures Operating Procedures Compliance. The Council and [Party] shall operate the I SMARTCoM System based upon this Agreement, mutually agreed Approaches and Practices, I and Rerional Standard OperatinQ Procedures as amended from time to time in accordance with I ' this Agreement. As of the date of this Agreement, the mutually agreed upon Approaches and Practices and Reaional Standard Operatin� Procedures are attached hereto and incorporated herein as Exhibits A and B, res ectivel . �i P Y � 7 'I i � � _ ____ _ __ _ i July 29, 2010 ' The Council shall require through written agreement that other Participating Users which i have installed and are using SMARTCoM in their vehicle fleets, garages and/or other facilities i shall operate the SMARTCoM System and the Components for which they are responsible pursuant to the terms of this Agreement in compliance with the A�proaches and Practices and Re�ional Standard Operatin7 Procedures, attached hereto as Exhibits A& B, as amended from ' time to time in accordance with the terms of the Agreement. [Partv] shall, together with the , Council and other Participating Users, be a member of and participate in a Regional AVL i Operations Committee established and organized by the Council, which shall establish I procedures far periodic review of and consideration of�,amendments to the Approaches and ' � Practices and Re�;ional Standard Operatin� Procedures ��c��i hereto as Exhibi�s A and B. Any ��i �r�endments tc the Apprca�hes ar� PiaCiiCeS ar�d�:Re�iana�i Standard Ot�eratin� rrocedures �.; � attached hereto and incorporated herein as Exhibits A�� B r��e'��ivel��, shall be considered by , aP � ' the Regional AVL Operations Committee in accordan�e��aith the procedures set forth in �� :� Section IX of this Agreement. If an amendment to the Ap�ir��ches and Practices and/or the '� � ��. :�':' Regional Standard Operating Procedures is approved in accord�3ce with Section IX of this ��'"'; Agreement, the amended Approaches and Practices and/or the ReQional Standard O�eratin� � � Procedures shall be ineo�or �� ,�.nto and become a part of this Agreement as a new E�hibit A � �� and/or B, as applicable without th� enecessity of formally amending this Agreement as provided ,.� � R sr, ; . , in Section XVL � , '� �, ��, : � �� ,�. � _: , Kti g �, - �� G��T., Changes to SMARTCoM � �� I �� F I r Software/Hardware Change� to SMARTCoM. Software and hardwaxe changes to the � SMARTCoM S stem shall be made in accordance with Sec io Q y t n IX of this A and shall , be managed by Metro Transit. Metro Transit shall notify all Participating Parties of chanbes to ''� the s stem rior e Q v' ' y p to th chan ia email to Partner s re resentatives on the Re ional AVL P g I Operations Committee. Participating Partners can suggest fixes, enhancements, and changes to ! the system to the Regional AVL Operations Committee for discussion and approval in � accordance with Section IX of this Agreement. Metro Transit shall have the sole responsibility � of negotiating approved enhancements with the Vendor and shall not unduly cause delay of implementation. Participating Partners shall share the financial cost for implementing fixes, � � changes, or enhancements that benefit the region based on the percenta�e of the instrumented I I i 8 � �� II ' July 29, 2010 regional fleet they operate. Any Partner may propose changes to the system that are specific to its needs in accordance with Section IX of this Agreement. Individual Partners shall bear the financial cost for implementing the changes they propose that are specific to the Partner. To the extent possible, any changes to the SMARTCoM System shall not negatively impact any Participating Partner. . � ;� ��,.. IX. Regional AVL Operations Comm��t;ee ; � I ��.,. � � l. Committee Established. The Council h�� es�a��.shed a Regional AVL � � �� Operations Committee to review and approve amei�dments to `the Approaclies and Practices and � Reaional Standard Operatin� Procedures, incorporated into this Agreement�a5 �xhibits A and B, � �` to oversee the regional SMARTCoM training program, to resolve SMARTCol��s�peration and �,M , �,. maintenance related issues, and to review and recommend changes to the SMARTCoM System. , The Regional AVL Operations Commit�� structure is found in Exhibit D. � _�� 2. Resolution of Issues �i"I'�i'.e �rocess for resolution of issues related to '� _ �� SMARTCoM as listed above and for review and pc��s�b1e amendment of the Approaches and � : �� .;, �� ;,.. Practices and Regional Standard Operatin� Proced'ures is a�'fcillows: ;., a. A member of the Regional AVL`��Jperations Committee may present a change to �- the SMARTCoM System, an issue regarding ope�ation or maintenance of SMARTCoM or the SMARTCoM traimng program, or a proposed amendment to the Ap�roaches and Practices and �� ;� � �. Re�ional �'��t�c�arc� OO ��a��.tin� Procedures to the Re�ional AVL Operations Committee. �,� . ,�� , : �,�. If the Reg�,t��►al AVL Operations Committee, in accordance with its procedures, , �� ry authorizes��. change to or ��resolution to an operations, maintenance or training issue or an � �� : � ; �� amendment to the Approaches and Practices and ReQional Standard Operatin� Procedures, the � . �-� resolution or amendment is�rresented by the Regional AVL Operations Committee to the Metro , :�, , � :, Transit's Director of `�$its Operations for approval. If the Metro Transit's Director of Bus Operations does not agree with the Regional AVL Operations Committee's authorization for the � resolu2ion of the issue or the amendment and the disagreement cannot be resolved between the Regional AVL Operations Committee and the Metro Transit's Director of Bus Operations, the I issue or amendment is presented to the Council`s Director of its Transportation Services Division, Metro Transit's General Manager , and Executive Directors of Participating Providers I for resolution, � 9 I - — I __ _ __ i July 29, 2010 � b.2. If a member of the Regional AVL Operations Committee disagrees with a chanQe I to or a resolution to an operations, maintenance or training issue or an amendment to the �I At�proaches and Practices and Re�ional Standard O�eratine Procedures, the issue or amendment i is presented to the Council's Director of its Transportation Services Division, Metro Transit's General Manager, and Executive Directors of Participating Providers for resolution c. If the Council's Director of Metropolitan Transportation�Services, Metro Transit's � � I General Manager, and Executive Directors of Participating Provid��rs cannot jointly resolve the I disagreement, they present the disagreement to the Counctl's ��gional Administrator for � �, resolution. � � ::, � d. If the Council's Regional Administrator cannot resolve �ie '�disa�reement the �I ?__:::> � disagieement s�iail be piesented to the ��I�t �ounciii STA Poiicy �ommitiee for resc�iuiion. , e. If the Met CounciliSTA Policy Committee cannot resolve the disagreement, the I disagreement shall be presented to the Met Council for final resolution. � �� £ Upon resolution of the d�sagreement in accordance with the procedure in this I � � Section IX, the Regional AVL Operations ��mrrixtte��shall authorize the resolution of the issue I ,- } or amendment in accordance with the resoluti�n of �he disagz�r��i�nt. � � �� . � u� � E ,- � ` �° _ � `�� ^ �� X �ithdrawalfxom Agreement i +� � �� r. � �� „�,, � 1. Withdrawal by��'arty r A PartS may witl��raw from this agreement upon serving si�ty '' � �;� .. . � s �. '� i (60) calendar days written no��e of inteiit `�o zcancel to the other Partv and to the Participating '� �..,�.. .__ Users. Upon notice of withdrawal, �lanni�g shall ensue between Party and the Council to ensure ', �.. a lo�ical decommissioning of the S1�ARTCoM sSTstems and the recommissioning of systemic �: functions that were available before the SMARTCoM installation. Withdrawal of a Party may I� also require decommissioning effort related to the SMARTCoM system that will continue to be , I used by Parties who have not withdrawn. ' The withdrawal of one Participating User's participation in this agreement shall not affect i the participation of any other Farticipating User of the SMARTCoM System, or tne respective rights, duties and obligations of the other Participating Users as set forth in the agreements � ' between Participating Users and Metropolitan Council. � If [P arty ] chooses to withdraw from this Agreement, the Council shall remove garage access points and associated networking infrastructure at [Party's] e�:pense. The Council shall � I � 10 , '�� uI 29 �Q�O Y � � � remove on-board equipment and restore associated pre-SMARTCoM functionality at [Pa� � � expense. The Council shall maintain software to allow [Party's] ability to return to pre- � SMARTCoM functionality and the [Party] shall provide equipment to return to that level of I � functionality. Any data generated from the SMARTCoM System shall remain in the � SMARTCoM System. I If the Council withdraws from the Agreement with [Party], the Council shall remove � � vehicle and garage equipment and restore associated pre-SMARTCoM functionality at the i i Council's expense. I 2. Default. A Party shall be in default under this agreement if it fails to comply � � �� .. with the terms of this agreement. Non-compliance is d�;#ermined by the Regional AVL � . • `� • � Oper�±�or.s Commi±tPe ��entified in Sect�on IX. U��i� dPter_m:r�,tion of non-cornpliance, the �� `� �� Council or Provider shall notify the non-complying Pa "��,f th.��ela�med non-compliance. Upon , � �� ,�.�j'� � default by the non-compliant Party and failure to cure saic� c��ault within 30 days of notice, the �� non-complying Party will be withdrawn from this agreement as�t�.�lined in Section X.1. If this ��s � �, I abreement is terminated due to default by a Party, the Council shall�t�t be precluded from � �, recovering actual damages to which it may be entitled and may exercise any other rights it has in I � � Iaw or equity to secure p�r�orr��2ce of this agreement. i �� `� ,� � ; , I �� '� �.�.� � �� , I � X� �xpans�� ARTCoM System i I � � � 1. Participating Use��s o,� the date of this Agreement, the Participating Users of �� , �.".,F.,..., f: , SMARTCoM System are� "�`� as follows: Metropolitan Council, � i � . Each P arty who is a Participating User as of the � � date of this Agreement has entered into a written agreement with Met Council with substantially I the same terms and conditions as is contained in this Ab eement. � I � 2. Expansion of System. The Council may allow, at its sole discretion, other parties I to become Farticipating Users of the SMARTCoM System by entering into a written agreement I I with such party. Costs for installing Components and Software and integrating Components and � Software into the SMARTCoM System shall be paid for by the joining party. � I i 11 � i � _ _ _ _ i 3uly 29, 2Q10 � � The written agreements entered into between the Council and additional parties joining I I the SMARTCoM System shall contain substantially the same terms and conditions as is � contained in this Agreement. � I 3. Effect on Other Participating Users. To the extent possible, Council's decision I to allow the addition of a party as a Participating User may not affect the participation of any I other Participating User in the SMARTCoM, or the respective rights,�duties and obligations of ! the other Participating Users under their respective written agreemeri�s wit�i�the Council_ I �� -: 4. New Participating User - Cost Sharing �►en �, new Participating User is I ,,:- i added to the SMARTCoM System, the calculation for cost s�iaring as ��'t�v�ded in Section V of I °�. this Agreement shall be prorated and bo in into effect on the date the ne� �',articipating Party � �� . � siaris using the SPv1ARTCoM System. � �- ` � , �iII. Liabiiity � Responsible for �wn Acts. Each�F' �rty agrees that it will be responsible for its own acts I Z � `t �. and the results thereof, to the extent author�e��y�Che 1aw, and shall not be responsible for the I � � .�� -: � � acts of the other Parties and the results thereo�' T�.��`Metr��o�i� Couneil's liability is governed � � - � by the provisions of Minnesota Statutes chaptez` 466 and tlie Metropolitan Council's obliQation I under �his paragraph shall not be construed to negate or abridge or otherwise waive, with respect � �:�,'; to the Metropolitan Council's liability limits of Minnesota Statutes chapter 466. The [ Partv's ] I � � I liability is� goi�ertmed�by the provisions of Minnesota Statutes chapter 466 and [Part��'s]'s � �;� . I obli�atz�ns under this p�ra�raph shall not be construed to negate or abridge or otherwise waive, I "� , z�„�� witli�respe� to [Partv's]'s liab��ity limits of Minnesota Statutes chapter 466. � � a � � ��; ^ I `�'�"� � �� III. Terrn � � �� "�z�' �:'� . . ' �� 3 � � � �� Term of Agre�ment and Renewal. linless terminated earlier in accardance with the �,""' provisions in Section XIV of this Ab eement, this Abreement shall be effective until December I 2013. Thereafter, and subject to the termination provisions in this agreement, this Agreement i ' shall automatically renew for subsequent one-calendar year terms unless either Party gives written notice to the other Party, prior to the begi�ing of the subsequent calendar year, that it � I does not wish to renew the master lcase agreement. I � I � i 12 � I ,� � , I 3uly 29, 2010 I XIV. Termination Termination Of Agreement. This A reement ma be terminated b: i aareement of g Y Y �) b 'I the Parties to this Agreement, or (ii) by the Council in the event of the withdrawal or termination of funding for the SMARTCoM System Project upon sixty (60) days prior written notice; or (iii) the withdrawal of a Partv from this Agreement ursuant to Section X of this Aareement. Eace t p b P as otherwise rovided herein u on termination of the A reement �a�� of the obli at' p � p , ions and g � �° g duties of the Parties under this Agreement shall be extinguishe��nd no shall have any 'I �� : �. �� further liability to any of the other parties arising out of the A�reemenfi � Upon termination of this Agreement pursuant to this�=�,,Section �V, the Council shall remove SMARTCoM Components and Software from the [P�'s] garag��ildings and/or � _.�� ..�� her a e� a �T ot facilities t the shar d ex ense of both Parties if thi A me ,_> p s b r e e n t i s t e r m i n a t�' i �� " c o n s e n t o f ��,;.. Y i both Parties and at the expense of the withdrawing Party if pursuant to (ii) or (iii) above in this Section XIV. � XV. Applicable Provisions of Law Compliance with Federal, State, Local Law. Each Party shall, at its sole expense, � �� promptly comply with al��ap��t�.ble federal, state and local Iaws, regulations and ordinances � � � �,:.. now in force or wlu��i or� may: hereafter be in force, relating to or affecting the ownership, � ��r o eration maintenance of�h -: Cosn �' . nts or in the erformance � . . . p , � p� , p o f t h e i r r e specti ve obligations , ,�,�a�-� < �� ti� �,� ��7 Q �.;� sa� �;,;. under this A reement. � a � s �. �� :� All parties agree to abide by��ll�a,pplicable State, Federal and local laws, regulations, and �,.. -. �% � ordinances regarding confidential infoimation concerning individuals and/or data including but not limited to information made non-public by such laws ar regulations. I � XVI. General Provisions l. Records. All records kept by the Council and [Party] with respect to the performance of each of their responsibilities under the Agreement shall be subject to e�:amination by the representatives of each party hereto, All data collected, created, received, maintained or disseminated for any purpose by the activities of the [Partv] and the Council I pursuant to this Agreement shall be governed by Minnesota Statutes, chapter 13, as amended, and the Minnesota Rules implementing such act now in force or hereinafter adopted. Each party 13 July 29, 2010 ' will only be responsible for responding to government data requests that are directed to their respective a�encies. '� 2. Employees of Council. All employees of the Council and all other persons � engaged by the Council in the performance of any work or services required or provided for ' herein to be performed by the Council shall not be considered employees of the [Partv] and any and all claims that may or might arise under the Worker's Compensation Act or the Unemployment Compensation Act of the State of Minnesota on behalf of said employees while ' so engaged, and any and all claims made by any third parties as a consequence of any act or omission on the part of said employees while so engaged, or any of the work or services provided to be rendered herein, shall in no way be the o1��iQatinn or responsibility of the [Partv]. 3. E��;�yees �f t �� [ �'art - � �. hll e,rnp��yees oi `�he [ Pa�iv j arid ali other persons I <�� ° en�aged by the (Partv] in the performance of any v�x� or F�e7 required or provided for i ` � �,� � �`��' � � herein to be performed by the [Party] shall not be consideret��employees of the Council, and any �� ; �.: and all claims that may or might arise under the Wor`k�ar'�. Compensation Act or the ' ,_ ;> Unemployment Compensation Act of the S�ate of Minnesota on beli�lf of said employees while so engaged, and any and all claims made by any third parties as a consequence of any act or ,� � ; = omission on the part o£.�s�icl'--;em�loyees while so en�aged, or any of the work or services �'�~�, , provided to be render�c��.erein, sh'aII �' in no way be the obligation or responsibility of the Council. � 4. Civil Ri �`ts. ; A Iicable provisions of Minnesota and federal law and any � � g 1��,� �� , � , ; z:;' +�.r,.� �.+,., �:, applicable local ordinance rela'�iri� to civi ng`��s and discrimination and the Affirmative Action I � Polic statement of the Part and �°t�ie Council shall be considered a art t' a I y [_�] ,_ �, p af his A as , a � , thou�h fully set forth herein. k 5. Entire Agreement. It is understood and a�reed that the entire ADreement between the parties is contained herein and that this Abreement supersedes all oral agreements and negotiations between the parties relating to the subject matter hereof. All items referred to in � this Agreement are incorporated or attached and are deemed to be a part of this Agreement. 6. Amendment. Any alterations, variations, modifications or waivers of provisions '� of this Agreement shall only be valid when they have been reduced to writing as an amendment i to this Agreement signed by the parties hereto. j 7. Provisions Severable. The provisions of this Agreement shall be deemed ' severable. If any part of this Agreement is rendered void, invalid, or unenforceable, such I 14 �, � I I July 29, 2010 renderin shall not affect the validit and enforceabilit of th g y y e remainder of this Ab eement unless the part or parts which are void, invalid or otherwise unenforceable shall substantially impair the value of the entire Agreement with respect to the parties. One or more waivers by � said party of any provisi�n, lerm, cunciiliun ur covenant shall nul be c�nslrued by lhe other parly as a waiver of a subsequent breach of the same by the other party. I 8. Binding on Successors. The covenants of this Agreement shall be binding upon a �` � _.,.. and inure to the benefit of the parties hereto, their successors and ass?tgns. '`' ; fl. 9. Third Party Contracts. The Council and the [�'��grees to include adequate � �� ,r �' provision to ensure compliance with this Agreement by eac�Yi�lower tie��rd party contract for operations and maintenance of the SMARTCoM system and components. �� ', � �!� 10. N�tices. �ny notice ar demand, which may �r must be given oi in��e �by a pa�'iy ' , �� hereto, under the terms of this Agreement or any statute or ordinance, shall be�in� writing and � shall be sent certified mail or delivered in erson to the other art addressed as p foliows: I P Y� ��;� \� I � �� `�Y �, � �� 5. I � � .,. �, y � .. � � I il �� ,��; . �_'` � .�=� , y. Metropolitan Council =<`[Partv] , ��_: Attn: Re ional Admznistrator � � g <:�� i .: 390 North Robert Street � � �,. � �� St. Paul M� ��';��{�.1� ' � ��" :, �� "'" �� W1tI1 CO �t� � ��'; 1�Y� ,�.;; ! � , ��_ �� ;, General Man�.gex, Metro Traia,sit � � � � � ✓ ;. � 10. Recita'ls., �ncorporated. The Recitals are incorporated and made a part of this �p,;. � a`' Agreeznent. � � IN TESTIMONY WHEREOF, the parties hereto have caused this Agreement to be executed by their respective duly authorized officers as of the day and year first above written. I ; ' Approved as to Form: '� i � � 15 I July 29, 2010 � i By: Its: I Attomey Date: ', METROPOLITAN��OUNCIL '� � .,>�� . . I a ublic co orat�tin anc�"' olitical subdivision p rP � .. P I P of the State of.��esota Approved as to Form: � � 4: �: � '� $y: �� `�, .o �� . � Its. � �.:, „ �, �. � � �i Uffice of General Counsel ' � �� `� ' � �� ;� � � �' Date.: "a� � �' � � I ��Y.;.a��, Ili �� 3� I qu��:� II ��, I .�'"��'',: I I . I �� : � I �`� �� II �� r � ''" I � a � x � z ��, i � : '�' '� "" ,%`�� j ' � � �� I � �� h �, ��., w � �, �� ..� � �. ��> I II 1 � � i I ' i I , 16 ' I i �� Exhibit A Approaches and Practices Updated 06/07/2010 DRAFT ' ��,. � °'�� I �� . '� �w �� `�� I � � , �, I � ,,, ,� �� .� �� ,� i � �,�� , li � , 6�� ; �, ' 'i;, � ' �� , �� a. I : ��, �. °� , � �� ,�� I ��m '�� - � �� ,� � �� .;' � I ��•,. �';;�. � r � ��< �� I -� �� ' ��,. � ,�„ ��` �' I � �. � uy� �, ' F�� `��. ' °�,�: ' ��, � f , �� -. � �� ,,� � ' � e � �. f_: � %� �� ';� � ��- �� I i � � � i � I � '' � � i 1.0 Data Summary Updated OS/17/2010 I This section summarizes the policies/procedures relating to data a;reed to by Metro Transit and � Regional Transit Providers (RTPs) participating in the Regional AVI, Deployment effort. �� l.l. Login Conformity I 1.1.1. Bus Operator Numbers All Drivers shall have unique six-digit numeric ID numbers. The first two di�its shall refer to I the garage and the remaining 4 dijits shall refer to the driver (assigned by the provider). I � � Item No. Descri tion Dafe Initiated ��' 70XXXX- MVTA 71 XXXX � 72XXXX- Southwest Transit � z� I ' 73XXXX � � �`� ' � i 74XXXX- First Transit I 7�XXXX Spring StreetlComo �:,�' 76XXXX Lorenz � � Robinson �I 77XXXX Transit Team I :. I 78XXXX Anoka County � � 79XXXX B1ueXpress � = i 80XXXX- ;Reserve Future � 89XXXX I I ��= �� .» � � �%'` �I � 1 1 2. Block and.Dut r Num�b.ers ', ti Blocks.-are defined as the trips operate�d by a single vehicle from pullout to pullin. (These � � include ir�-service trips, �pullouts, pullins and deadheads.) A Piece is part of a Block. Block Numbers'shall range between 0000-9299 for Metro Transit and 31000 to 38899 for RTPs. Duty is define8.a�°�the wark covered by an operator. A duty is made up of one or mare ', pieces, i.e. one or��i0re`blocks or pieces of blocks. An operator may cover one or more duties in a day. Duty Numbers for RTPs shall be a five-digit number beginning with either a 3(for Regular Duty) or a 4(for Resource Duty). Backup Duty numbers (in case the driver is I unable to log in with the Regular Duty number} are six digit numbers beginning with a 23. A , ran�e of Duty numbers are reserved for Resource Duty numbers, which are to be used for I work unrelated to regular service and include activities such as training, maintenance, emergency operations, and bus changes. , I I 2 I , � I � Reaional Block and Duty Number Ran es Provider Block Number Duty Number Resource Backup Duty Range Range BIocWDuty Range * Ran e Metro Transit (including 0000 — 9099 0000 — 9099 9100-9199 10000 — 19999 contracts) 9200 — 9299 9200 — 9299 9300-9999 20000 — 29999 Met Council 31000 — 31899 31000 — 31899 40000 — 43999 51000 — 51999 Transit Team 31000 — 31099 31000 — 31099 41000 — 41099 51000 — 51099 � First Transit Blaine 31100 — 3 ll 99 31100 — 31199 41100 — 4l 199 51100 — 51199 First Transit Spring/ 31200 — 31299 31200 — 31299 41200 — 41299 51200 — 51299 Como Lorenz — Blaine 31300 — 31399 31300 — 31399 41300 — 41399 51300 — 51399 Lorenz — Spring Lk Park 31400 — 31499 3] 400 — 3 1499 '°. 41400 — 41499 51400 — 51499 Universiry of Minnesota 31900 — 31999 31900 — 31999 41900 — 4] 999 51900 — � 1999 MVTA 34000 — 34899 34000 — 34899 4'400Q — 44999 �4000 - 54899 Priar Lake, Shakopee, 35500 — 3�899 35500.,- 35899 4�500 — 45999 5��00 - 55899 Scott County Southwest Transit 36000 — 36899 36000 — 3689� 46000 — 46999 "' S6000 - �6899 Pl mouth 37000 — 37899 370D0 - 37899 , 47000 — 47999 57000 - 57899 Maple Grove 38000 — 38899 38000 �.:3$899 48000 — 48999 58000 - 58899 * Backup Duty Numbers are used when the operator_is�.�,nable to log in with the regular duty number. �� . �. �� „_ .. r �.: The SMARTCoM Resource Logon Duty nurnbers:.�or RTPs are shown on the table on the following page. `� 9; �� , � � ��= . "� ��, � ' .�, � �• 4 -� ;� �� '', 9 Y � � ` � �� ' ��;.� < � � �; ��; ��' � 3�� <�� ,;.. �A� h� �, � ��;: � � �, �- , � , �:j 3 � � � 4 : � � �8.� ��„ � ,�:�. �`�.�� I �� . T s �~ � :..:�:;��' , �� : �. l I i I I I I 3 I I i ' SMARTCoM Resource Logon Duty Numbers — Part 1 SNL.ARTCoNI Logon Run ID'Descx•iption ' Transit First First Transit Lorenz ' Lorenz Univ of Logon Croup Team TransiY'' Sp►•ing/'Como Slaine, SLP MN Name ', Blaine Fixed Route Back Logon for Operatars � 1000 - S ll 00 - 51200 -� 1?99 51300 - � 1400 - 51500 - Backup Logon after logon to regular run # � 1099 51199 51399 51499 51599 fails Emerg Ops Emergency Operations Bus 41000 4l l00 41200 41300 41400 4150Q (S100) provided upon request by Public Safety a�encies Training BIAB Bus-In-A-Box (BIAB) 41001 41101 41201 41301 41401 41�01 , Training Trng Oper (In In Service Trainin� Bus (Non- 41002 - 41 l02 - 41202 - 4,1270 �� 41302 - 41402 - 41502 - ! Serv) Instructor) 41010 41110 � 41310 41410 41510 �� Trng Oper (NIS) Not in Service Trainin� Bus 41011 - 41111 - 41211 - 41Z20 . 41311 - 41411 - 4]511 - (Non-Instructor) 41020 41i20 41320 41420 41520 Trng Instr (In Training - Instructor operatin� 41021 - 41121 - � - • 41221 - 41230 �` ��41321 - 41421 - 41521 - Serv.) In Service 41030 41i30 '41_�0 41430 41530 Trng Instr (NIS) Training - Instructor operatin� 41031 - 4l 131�- 41231 - 41240 4133] -<��" 41431 - 41531 - �� NotIn Service 41040 41140 4134�" 41440 41540 Special Serv Special Service (Revenue or 41050 - 41150 -�� •. �1250 - 41259 41350 - 414�0 - 41550 - Non-Revenue,includin; Bus 41059 41159 41359 41459 41559 Brid�es) Extra Service Extra Service/Fill In 41060'- 4� 160 - 41260 -�11269 41360 - 41460 - 41 �60 - 41069 '��4116� �� 41369 41469 41569 Staged - Spec Special Event Sta�ed bus 41070 - 41170- '�_41270 -�41?79 41370 - 41470 - 41570 - Event(S98) 41079 41I79� 41.i79 41479 41579 Staged - Regular Regular On-call bus siationed � 41080 - �41180 - �1T280 - 41289 41380 - 41480 - 41��0 - in strategic locations��for use 41089 �" -- 41189 41389 41489 41559 �� on bus changes and fill ins Transport Bus used as;Lran frorn.one 41090 ^: 41190 41290 41390 41490 41590 Vehicle facility td�another R�and to/from relief (Used by.either Mechanic or Operator) ', ' i Maint Road Test Mainte�ance Road Test �� 4`1091 4ll9] 41291 4139] 41491 41591 �� (Maintenance use only by,all �� garaves)` Maint Vendor Maintenance Vendor Use �'�� 41092 41192 41292 41392 41492 41�92 �'� Only (Interstate, etc ) I Technician Electronic Tecnnician Use 41093 41193 41293 41393 4149� 4159� I Only Maint Misc Miscellaneous Maintenance 41094 41194 41294 41394 41494 41594 Non-revenue support vehicle tise Only � Default/ Test Default Login ID to be used 41095 41195 41295 41395 41495 41595 Login ONLY for testing when Normal or Manual Login ID � does not work I Road Call/ Bus Road Cal( or Bus Change 41099 41199 41299 41399 41499 41599 Change (Used by either Mechanic or Operator) , , 4 I I , i SMEiRTCoM Resource Logon Duty Numbers — Part 2 � S11�AR�`Co17 Logon . MVTA Prior�Lk, '�� SW'�� Plym ��MG `��Future� Logon Group Shak, Scott Transit Name Cty ' Fized Route Back Logon for Operators �4000 - >j�00 - �6000 - 57000 - 58000 - 59000 - ' Backup Logon after logon to regular run # �4899 55899 �6899 57899 58899 59899 fails Emerg Ops Emergency Operations Bus 44100 45100 46100 47100 48100 48100 (S 100) provided upon request by Public Safety agencies I Training BIAB Bus-In-A-Box (BIAB) 44900 45900 46900 47900 48900 48900 Training Trng Oper (In In Service Training Bus (Non- 44901 - 45901 - 46901 - ` 47901 - 48901 - 48901 - I Serv) Instructor) 44910 45910 46910 47910 48910 489I0 Trng Oper (NIS) Not in Service Training Bus 44911 - 45911 ' 46911,'r ;, 47911 - 48911 - 48911 - (Non-Instructor) 44920 45920 �.- 46920,��",, 47920 48920 48920 Trng Instr (In Trainin� - Instructor operatinQ 44921 - 45,921= ; " 46921 - �7921 - 48921 - 48921 - Serv.) in Service 44930 >�5930 46930 °>:47530 4fi930 48930 ' Trng Instr (NIS) Training - Instructor operating 44931 - ��5931 - 46931 - 47931- 48931 - 48931 - � NotIn Service 44940 ' :,45��940 �-; 46940 47940'� 48940 48940 Special Serv Special Service (Revenue or 44950 - 459'SQ ,"" 46950 - 47950 - 48950 - 48950 - Non-Revenue, including Bus 44959 45959 : 46959 47959 489�9 48959 Bridges) ! '� Extra Service Extra Service/Fill In 44960 : 45960 - 4696p -`' 47960 - 48960 - 48960 - 44969 ' "=.-Q5969 46969 47969 48969 48969 Staged - Spec Special Event Staged bus 44970-�- �S9',70-„ 4��970 - 47970 - 48970 - 48970 - Event (S98) 44979 _'�� 45979 ,�-�`�46979 47979 48979 48979 Staged - Regular Re�ular On-call bus stafioned 44980 45980 -., 46980 - 47980 - 48980 - 48980 - in strategic locations for use -u 44989 45989 46989 47989 48989 48989 �: on bus chanjes.and:�ll.ins I � �` Transport Bus used as ��ransport frorn ot�e� °°�4�990 45990 46990 47990 48990 48990 Vehicle facilityto another & and to/from relief (L�sed by either "` �x3 ! F � � Meehanic or Operator) Maint Road Test Maintenance Road Test ' "44991 45991 46991 47991 48991 48991 (Maintenance use only by aIl garages) � ��'� � Maint Vendor Maintenance Vendor Use " 44992 45992 46992 47992 48992 48992 Only (Interstate; e�o )„ �,`� � � Technician Electronic Technician Use 44993 45993 46993 47993 48993 48993 Only Maint Misc Miscellaneous Maintenance 44994 45994 46994 47994 48994 48994 Non-revenue support vehicle Use Only DefaulU Test Default Login ID to be used 44995 45995 46495 47995 48995 48995 LoQin ONLY for testinj when Normal or Manual Login ID does not work Road Call/ Bus Road Call or Bus Change 44999 45999 46999 47999 48999 48999 Chan�e (Used by either Mechanic or Operator) 5 I � i 1.1.3. Pattern Number �i Pattern Numbers are internally assigned by HASTUS. 1.1.4. Vehicle Number , Providers with significant numbers of vehicles are assigned an independent number range and I the Provider is responsible for assigning numbers to individual vehicles within that range. Providers with smaller fleets are included within the Other Regional Provider range. Assigning numbers to individual vehicles within the range identified in the following table will be done in consultation with the Metropolitan Council's MTS Manager of Fleet Services. Vehicle Number RanQes Provider Name ASSiQned Ra'nae of'Numbers Metro Transit 0-3999, 7100-9999 MVTA 000-4999 -. Southwest Transit �000-�999 Metro Mobility b]00-6599-or b1000-93199 or 64100-64] 99 Scott County 64000-64099 Other Reaional Providers: ia Buses 6000-6099 or 60000-60999 b b_ • Plymouth Metro Link Small Buses 6600-6699 or v4?00-66999 • Maple Grove • Shakopee �. • Prior Lake • MTS Contracts �'.. �� The following 2-'letter pre, ia v�ii'�l� be used in front of the bus number in TransitMaster to help dispatchers quickl}� identify the�rovider. :, I Provider:�Iiientifer for TransitMaste�r TM Bus Pravider Provider Bus Garage Identifier ##### Metro Transit FB-##### Anol:a C'�ounty First Transit — Blaine � FS-##### . MTS First Transit — Spring Street & Sprinb (Como) LB-##### MTS Lorenz — Blaine LS-##### 'MTS ' Lorenz — S rinQ Lk Pk (Robinson) MV-##### MVTA MV'TA — E an & Burnsville PL-##### Plymouth First Transit — Spring Street & Sprin� (Como) �� PS-##n## Prior Lake, Shakopee Schmitty & Sons (Pillsbury) SW-##### Southwest Southwest Transit TT-##### MTS Transit Team ' � 1_1.5. On�oin�Svstem WaiverMaintenance , Providers will send Metro Transit waivers when the change of route lasts more than one day. I Metro Transit will enter the waiver into the TransitMaster system. � I 6 I I � � II Providers will enter waivers in the TransitMaster s stem for their own route when the chan�e Y b to route lasts up to one day. Providers will implement and maintain waivers according to SOP regarding Waiver Creation Criteria & Procedures. 1.2. GeoCoding 1.2.1. Collection, Stora�e, and Transmission of Geo-Code Data Geo-code data collection shall be performed in accordance with the procedures identified in Appendix B of the SMARTCoM Route Management Survey Tool document. � �". Geo-code data shall be stored in the TransitMaster Database which is maintained by Metro . Transit. 3- Geo-code data shali be transmitted to Metro Transit for entry into t1�e�'xansitMaster database. I 1.2.2. Methods and Standards for Route Survev Geo-coded data shall be consistent with the methocls.and stai�dards identified in:the I SMARTCoM Route ManaQement Surve Tool doc�inent. : ' a y , � F �''�' �. _ � 1.2.3. Route Survev Responsibilities� �`- , Providers shall be responsible for performing,ath�ir own geo-coding�activities except for those I under contract with Met Council's Metropolitan Tian�portation_S�ervices (MTS). MTS shall � perform geo-coding activities for those subwrba,tX.servic0 pr,c��u��lers under contract to it. �% � , ,,,,, � Geo-code activit�es for daily ai�ti,.�new pick responsibilities are identified in the SMARTCoM Route Management Survey Tool document. ,�,. � VJhere Rag�on�l Transit Provider rou�e seginents overlap Metro Transit route segments, MTS � shallMbe responsibl�=�or„geo-cocling overlapping route segments. 1.2:4:, Route Map Files Metro Transit.shall provide route map files for all providers. I � 1.3. Schedule Changes 1.3.1. Creating Schedules ChanQes in HASTUS Schedule Data Entered into HASTUS Schedule data entered into HASTUS shall include: • Routes ' � • Stops I • Trips • Blocks • Duties 7 � �I i ! Major and Minor Schedule Changes The minimum amount of time in advance of a schedule change must be t]le followin� durations before the change takes effect: ' • Minor changes — 14 days ■ Minor changes include chanQes such as: �' • Addition, moving, or removal of bus stops • Shifting individual trip times • Adjustments to running times on a single route • Addition or removal of a small number of new trips , • Major changes — 60 days advance notice of a proposed chanae, including draft I schedule y I, — 30 days notice of final detail schedules (with bus stop information) � � � ■ Major changes include changes such as: • Restructuring one or more,routes � • Char.�e� r� rp,,�rP p�r��r � � � �� :. � • Shifting multiple trip times a 3 • Adjustment to runnin� times on multiple routes � Metro Transit will implement majar schedule changes on a regular quarterly schedule based on the following general schedule: � • The first week of March ` • The first or second week o� June (or last week of�vla�,� � � . The Saturday after Labar Day �`��'�� I • The first or second week of De,cember �� ' � Exact schedule change =dates for the followi�g year will ba��provided in October of the each '� year. All regional providers are rec�uested to implement their major schedule changes on the same schedu]e whenever }�ossible. This will reduce the overal] work effort to prepare I � schedule in HASTUS .and update the TransitMaster�system. � !' . � � �� ' Special Sc'riedules Sepazate schedules shall be created for weekday, Saturday, Sunday, and Special Schedule i operations. Special Schedules iriclude;�� • Holidays (New Years:Day, Memoria] Day, July 4`�', Labor Day, Thanksgiving, .< Christmas; Sunday schedule operations) i •�� ;�educed Servi�e Days (The day after Thanksgiving, Christmas eve and/or the ' day after Christmas depending on the year, July 3` andlor July 5`� dependin� on the yearl '' I • University of Minnesota Breaks (the same reduced schedule is run for all U of M breaks) I • Start of Fall Semester for University of Minnesota (one week of special service � startin� the Tuesday after Labor Day) • State Fair (added trips during the 12 days of the State Fair; there are separate additions for weekday, Saturday, Sunday, and Labor Day) � Regional providers may prepare special schedules for these or any other special service days. , The detail information for these special schedules must be provided to Metro Transit on the � same timeline as major cllanges. Advance notice and draft schedules are required at least 60 days before the special service day and final schedules are required 30 days before. In some cases, when a provider has many special service days or when the special service days �I I 8 �� j I have few changes from the base schedule, alternative arrangements will be required to manage the special schedules in TransitMaster. , 1.3.2. Creatin Schedule ChanQes in TransitMaster g � Schedule files shall be entered into TransitMaster the Thursday before the new schedule takes �� effect. The schedule files shall include the following interface files: • Timepoints — List of all uniquc timcpoints (four charactcr codcs assi�cd by I Metro Transit) I • Stops — List of all unique stops. Multiple stops might be lat the same location. �' Data includes: ■ Numeric identifier (assigned by Metro Trans,it}'� "�� ,.. _.: ■ Stop location (on street, at street, corner nuirz°ber) � ■ Stop details (e.g. amenities, etc.) , • Routes — List of all unique routes. Data incluties. �� 3 �I ; ■ Route number and description (�f3°chara�ter limit� ��;,, � ��.-. � = Runnir�g tulle by tiir�e oi day an� day�of week • Route Direction — List of unique rou�e/directior�pairs • Route Timepoints — ardered sequence o�zimepoints for each route an� direction • Patterns — List of al] unique patterns of st�ps;foi� an}��given route � • Route Stops — List of stops for each patterri:,Data includes: I ■ Ordered bus stops �or the route by direc�xion • Blocks — List of blocks w�ith start and end time and locat�ion � ■ Vehicle type � ■ Garage assignments ��; ■ Pullout time, pullout routing, pullout�distance ■�'u111� time, pullin routing, pullin distance I � ■ �Deadheaii��,trip duration, r'outing, and distance � � • Trips �,°i��t of trips ;i�vith route, directio�n, pattern and block de�aiIs. Data includes: ■ Uni.que tr-ip number ■ Sequence of buses �n th� trip , ,. "'� "� Overhead;�sign code teXt , �• Trip Stops ��- List of �mes for each stop on each trip � ``� �',� Runs In�� .. � ation on �. ��w blocks are t Qet � • orm ho pu to her into runs. Data includes: ■ Wark�'or operator for the day (or portion of the day) � ■ Block�iumber of each piece ,. Start-and end tine of each i c ,= P ee �'�� Dut�y type ,� ,� � �� 1.33. Schedule MerginQ Schedule Merge is the TransitMaster process to update the bus schedule that the system uses. , Schedules are updated in TransitMaster only after si�nificant chanaes to the schedule. New '� , schedules shall be transferred to holding location for buses by 4:30 P.M. the Thursday before �, � the new schedule is to take effect. New schedules shall be activated 12:00 A.M. the Saturday ' I the new schedule �s to take effect. i � � I I 9 I I __ ___ � � I 2.0 Maintenance Summary I Updated OS/24/2010 � This section summarizes the policies/procedures relating to SMARTCoM system maintenance ', agreed to by Metro Transit and Regional Transit Providers (RTPs) participating in the Regional AVL Deployment effort. 2.1. Software Issues 2.1.1. TransitMaster Software Issues Providers can participate in standing weekly meetings with Trapeze and notify Trapeze of issues regarding TransitMaster software and Met Council of issues regarding geo-coding and ! access to Council network. This aroup shall re art to the Re�=ional AVL O erations i � P � P Committee on a monthly basis. i 2.2. Hardware Maintenance 2.2.1. On-Going Hardware Maintenance A��reement ��; �� '� � Metro Transit and Regional Providers will enter i ito one aar;eement with the vei�dor of the �� TransitMaster system for on-going hardware and �oftti��are support. Metro Transit will charge back to each provider a percentage of the cost based on the percenta�e of the re�ional fleet they operate. Hardware, software, and on-site support;provided by the vendor are identified in the I TransitMaster SuppordMaintenance Agreement. T�ardware shall include the in-vehicle loaical ' unit (IVLU), mobile data terminal (MDT) autom�.t�C�a�s�nger counter (APC). � � � 2.2.2. Vehicle Data Radio and Vehic]e Cab�.inR Maintenance I Each provider is responsible for maintainin� data radios and cabling on their fleet through I � one of three options: � ° � ° � � j � a) repaiiirig�ar�d replacing the radios' ar�d7or cabling using personnel within their organ�ization. ; b� sending the radios and/or cabling to a local company for repair, or �� );3sending radios andior to Metro Transit for lVletro Transit staff to repair. �� , _ v � � �, - I Each provicl�r_is responsible for problem detection, dia and confirming correction of , problems after rnaintenanee, and problem documentation and record keeping. Providers can I have either their own staff or another party remove and replace radio hardware and cabling. 2.?.3. Vehicle MDT and APC Maintenance I � Each provider or its maintenance contractor will have a technician who has participated in Trapeze-approved training (TM501 Mobile Data Equipment) to perform technical support for i ; , mobile data terminals and APCs on their fleet. Each rovider is res o i e ns bl for r p p p oblem � detection and diagnostics, reporting problems to Trapeze technical support, hardware removal I ' and/or repair per Trapeze instructions, shipping hardware to Trapeze, installation of repaired I, hardware or replacement, confirming correction of problems, and problem documentation '� and record keeping. I i I 10 I � , � I Providers will return mobile data terminals and APCs to Tra eze for re air/re lacement P P P following the Return Material Authorization (RMA rocedure identified in the )P TransitMaster Support/Maintenance Agreement. 2.2.4. Garaae Access Points i Met Council is responsible for maintaining access point hardware in provider garages and the associated network. Each provider is responsible for problem detection, diagnostics, and reporting access point problems to Met Council technical support. � 23. Software Maintenance �. '` �� , - �, 2.3.1. Onboard Computer Software and IVLU . . . �. Each provider or its mamtenance contactor will have a technician vi?ho.has participated in Trapeze-approved training (TM501 Mobile Data Equipment�� to perform technical support � for the cr.-�ca: d ce:npute: and so�wa: e(�rE-?VLT,.J) en th�i ilyy Each pxu.�ide: is � responsible for problem detection and diagnostic�, reporting problems to Trapeze te�chnical support, hardware removal and/or repair per �'rapeze instruct�ons, shipping hard�ware to Trapeze, installation of repaired hardware or replacernent, conf'i�ming correction of problems, ' and problem documentation and record keeping. � ,, �:m � Providers will return on-board compuCer� �� Trapeze far rep�ir/replacement following the ' Return Material Authorization (RMA) proce�u�re.,.identified in t�e �2`7ansitMaster Support/Maintenance Ageement. E�� ; ,. �, S F; e � 2.3.2. TransitNlaster Software j Metro Transit w�1l,inaintain TrailsitMaster softv�!are located on a server at the Transit Control Center. Metro Transit �ui11 hav� a Trapeze-approverUtrained technician to perform technical support for the Transitivlaster soi�ware. Metr,o Transit is responsible for problem detection ', and diagnQSt.tCS problems to Trapeze technical support, software configuration per TraJ�e�e �instructions, confirmi%�gxcorrection of problems, and problem documentation and � recor�l keeping. ' �, . I 2.3.3 =. Software U�erades and Patches Metro Transtt�vill send a notice to providers of any upcoming TransitMaster software upgrades at ]east �two,weeks prior to the upgrade. Metro Transit will also send providers a notice of any patches to the TransitMaster software priar to the upload of the patch. � 2.4. TransitMaster Softvvare Disruption ! 2.4.1. Planned and EmerQency Fallback l i Providers will follow the TransitMaster Fallback Notification Regiona] SOP, included in � Exhibit B. I 11 I I I I i _ � I �, 3.0 System Setu and Configuration Summa P 1 ' 3 ' Updated 10/21/2009 � This section summarizes the policies/procedures relating to SMARTCoM system setup agreed to II by Metro Transit and Regional Transit Providers (RTPs) participating in the Regional AVL Deployment effort. � 3.1. Route Partitioning Providers will assign vehicles to fleets by assigning them duty numb.ers. Providers will assiQn � fleets to Work Assignments. y i I Providers will ]og onto TransitMaster and choose a worl: assi��nrnent that is designated to I their aQency so that they are able to see messages for only their a�encys vehicles and so that � their vehicles are not able to be seen by other a�encies. By clloosin` a work assignment when �I they iog in, operators avoid confusion of seein; v�hicles outside ot their fie�t and having I operators from other agencies seeing additional vi�nicles. The TransitMaster'.system allows providers to adjust settin�s for maps to view only vehicles tliey manaae. , =. � 3.2. User and AppIication Features:Access Rights and.System User Groups Access rights to TransitMaster features will be'assiRned tluough user aroups. Metro Transit will provide an initia] setup of user group access iights that may�change over time. These �� user group access rights shall be managed �t the svstem°le�el�by Metro Transit. Providers � may request changes to �ser.group access rigtits at any tirrie'to the TransitMaster System �� Administrator. ' I Providers will commi�nicate to"�vletro Transit what employees are members of their user groups and what access rights their user group�'should have. Metro Transit will set those � access rigk�ts arid��-user �roup inembers'in ttie��ransitMaster system. Each Provider will have I the foilowinQ user roups: I I b g � • Dispatch I � �� Customer Ser�ice �� •'�..Supervisor � : I • i1�Ianagement I • 1Vlait�tenance �� ' i ., � 33. RTP Access `from non-Metro Transit Network The Council will provide providers access to the TransitMaster user interface throu�h a Citrix , Client interface. Providers will be able to access this Citri�; Client interface from any com uter with internet access. I P i 12 ' �I � i 4.0 Operations Summary Updated 12/22/2009 This section summarizes the policies/procedures relating to operations ab eed to by Metro Transit and Regional Transit Providers (RTPs) participating in the Regional AVL Deployment effort. 4.1. Regiona( Standard Operating Procedures Providers ab ee to the Regional Standard Operating Procedures (SOPs) that must be performed by all providers to ensure regional functionality. Region�l� SOPs ab eed to by al] providers are found in E�ibit B— Regional Standard Operating P These Regional � SOPs are: �� • Covert/Overt Alarm Response • TransitMaster Work Assignment Use ��; � ,,� u • Text Messaging — Daily Operations Use ��''r�- �� • �ervice Adjustment use � �� ; : h: • TransitMaster Fallback Notification � �� • Geo-Code File Transfer Process = . �� • Waiver Maintenance Process 3 �`` � , y» - °..,. • TransitMaster User Support Process �� ., Providers will use their own Provider 'specifi�.SOPs for proc�dures.rhat provide local control � � of their equipment and use of data but do �nof°affect regional operations. i Regional SOPs shall be,deueloped or changed,� uvith appro��l�by the Regional AVL � Operations Committee ari�l'autl�orized by the"Metro Transit Director of Bus Transportation. I Upon approval an�l authorization, Metro Transit shall distribute the mutually a�eed upon � SOPs to provide'rs . I � :; m. � � �� , 4.2. Trainme �:; ; �, � ,� � The=�egional AVL Op�rations�Cornm'ittee will provide review and oversight of the provid�rs' training prograins. Providers shall provide training materials to the Committee to � review in order to provid��cansistency between providers' training. Providers wil� be responsible f'or-:training their own staff. �-'.^ �' 13 '� i I I � ' 5.0 Reporting/Use of Data Summary Updated 06/07/2010 This section summarizes the policies/procedures relating to date use and reporting agreed to by Metro Transit and Regional Transit Providers (RTPs) participating in the Re�ional AVL � Deployment effort. � I 5.1. Data Use and Reporting � �.1.1. Guiding Principles '� These basic principles will guide the development of more snecifc practices related to ' storage and use of both operational and historic data �enerated by the TransitMaster system. � • All AVL/APC data generated by TransitMaster will be stored L�y Metro Transit ' • All providers are guaranteed access to data for their fleet within reasonable limits of ; system and network availability as determined.6y the�T:ansitMaster 5��stem Administrator • Any provider may make a copy of their data <�nd� store it on their own data� systems 'I • All AVL/APC data will be visib]e to all providers � • All providers may use other providers' data tc� support their day-to-day operations. (Examples: monitor connections, observe flow of buses in shared corridors, investi�ate incidents and custorner complaints; ete.}. Notification and/ar consent are not necessary for these data uses, eacept as identified in the "Data lise in Investiaations" section below. I • All providers may use other providers' data to su�port their `'internal planning activities. I Agencies shall provide written notification�-of thes° acti�t�ities. (Examples: route planning, � system analysis, .ete:� � • No provider rnay report ptiblically on any.other provider's data witl�out express written consent of the otl�er provider��. I 5.1.2., Data Use in InvestiQations I I � A provid�i can��use data to investigate incidents and customer complaints involvina its vehicle I, or per`sonnel. When a p�ovider is-conducting an investigation and finds that another I x_ provitler's vehicle or personnel �is°involved, the provider originating the investigation will ; notify the appropriate provider, turn over any relevant information Qathered during the i� investigation, and either coordinate with the provider or cease its investigation in accordance �� with the procedures described in RAVL 02.04 —"Operational Use of Historic AVL Data". Consistent with�the Quidin� principles, the provider originating the investigation may not publicly report the data from the other provider without express written consent of the other i provider. � 5.1.3. AVL Data i AVL data is stored in the TransitMaster database. There are several different databases used for different purposes. Raw data from the buses is processed each night and stored in a reporting database. The reportin� database can be queried to provide individual schedule ' adherence observations. , �.1.4. AVL Reports I � �I Metro Transit has developed a large library of Crystal reports plus an Excel macro for extracting AVL data from the TransitMaster databases. Metro Transit will wark with RTPs to 14 I � I identify which reports are useful and then to modify the reports to work for the RTPs' specific service. The number of reports may be limited based on staff availability. If a large number of reports are requested by RTPs, alternate plans will be required, either to hire outside assistance in modifying the reports, or to cover the added cost of Metro Transit staff time for the work. Reports will be made available to all providers via the Presentation Server. RTPs will be able to develop their own reports in Crystal Reports, Excel, or other tools that ' use ODBC. RTPs will be required to review report queries with Metro Transit staff before implementation to avoid problems that disrupt the reporting data�i�ase or violate agreements with Trapeze. 5. L�. APC Data In additior. t� +.he stan�ar� A.pC matchir.g proce�s ��ovide� by Trapeze, Metro Transit has developed a separate program to process APC data and match it to the correet trip and stop. Metro Transit can not guarantee the accuracy of.AEC data;�;but is committed`�o��achieving the highest level of accuracy that is practical. Metro Transit will process all APC data in the system, ineTuding that generated by both Metro Transit and non-Metro Transit buses, us2ng,�he same processi'�:The resulting data will be stored in a database outside of the Trans7t`1Vlaster.,system. All pro�iders will have access to both this data source as well as the Trape��e ApC�r�pqrting data �'�� ; � �' It is the responsibility,of ail:pr.oviders to review the APC data for accuracy. Any further correction or change� fo AT'C data must be conducted by the providers and stored in the providers' data s�!s#ems. Metro Transit will aceept requests to ctaange the base APC data processing system, and will consider.,them _only if they �� " °� � � � �,.;; a) do not neQafively;�impact'�ha,processmg of Metro Transit APC data, and b) can be accomplis]i�Ci without �xcessive staff or system resources. � � t. 5.1:6: ` APC Reports =< Metro Transit has c3evelopecl a set of APC reports in Excel. These reports are all based on our separate rep.orting database. These Excel reportS,�ill be made available to all providers via Presentation Server. Any modifications to APC reports for specific needs are the responsibility of each provider. Metro Transit will modify reports as necessary for internal use. 5.1.7. Dia�nostic Reports There are several diagnostic reports that are available to identify problems with the hardware on the vehicle and/or the schedule data. Providers will be instructed on which diagnostic reports should be run on a regular basis and how to interpret and act on the results. 5.1.8. Data Quality 15 i � The quality of reporting data is directly linked to the quality of the schedule data, good maintenance of the equipment, and proper use of the system (login, ]ogout, etc.). Metro Transit will assist RTPs in identifying the source of data quality problems, but may not be able to address these issues if the above factors are not addressed. ��'��:� � ,� � �� ,�: � �� ;�; s� � '�� r�� - �� :� ,,:�� _ `' � a '� �. a�, �� v �� 3 ��- 3 �k � y �Rai �� a�F �Zu � �' Y �� 3 , � � ; � , 3 �`x' W Y q3 � � F � � Hi 3, � �-:::� S £ A � � 1 �` .: ��' . . � �:. LS . � �„" � � ,� ?;� �'. � � ' ! +�� „ ...°i .' 1 .. :a7:� �� F { �� :. ;;i�' ��,;: �.' � , 3.,�.,; a? .. �� .� � �_.�.� ,?' � s' �l� �:�, `" � i ` �� -; � � � ...• �A�� .� 16 I , � � 6.0 Administration Summary U dated 06/07/20 ] 0 P This section summarizes the policies/procedures relating to administration agreed to by Metro Transit and Regional Transit Providers (RTPs) participating in the Regional AVL Deployment effort. 6.1. Provider Aareement Administration b .. 6.1.1. Re�ional AVL Operations Committee Process *Tentative* -. When an issue re�arding the operations and maintenance, including costs � related to operations and maintenance, of the SMARTCoM:systeni�arises, a provider shall present the issues to the Regional AVL Operations Committee. Tlie'�'Cr.ucture and decision � v., making process of the Regional AVL Operations Committee.is descrrlied in the RAVI, �• Comr:littee and Resoluticn cf Issues docum.ent If there is an issue between the Regional AVL O�erations Committee and the Ivl�tro Transit Director of Bus Transportation that they cannot reso`�ue, the issue shall be dealt'with using the process described in Section IX of the SMARTCoM ��O�erating Agreement. � �I 6.1.2. Institutional Elements of Chan�es to SMARTCoNI . � ,3 `:. New Providers ; : ,, = _;, � � New providers can be admitted with written con�enf'from Che �Metropolitan Counci] and by �� signing a SMARTCoMsTransit System Operating Ab eement. Providers must provide public ' transit service in the region I�I�W providers s�iall be responsible far the cost of installing equipment and intEgrating it �vit�i the existing�SIvIARTCoM system. � Chan�es to Contract Ser�lces �'' , ,,,; r� � If Metropolitan Transportataon�Services chariges a contract provider, Metropolitan Council will r�move all �ar.age poi�ts and associated network hardware and reinstall it at the ne��contract provider'.s��facility:��M.atropolitan Council will remove all on-board equipment � and�reinstall it on the new:contract,provider's vehicles. MTS shall pay for this work. Adding Facilities ' In the event fhat a provider adds a garage for operating and maintaining instrumented regional fleet vehicles, IVletropolitan Council will perform a site survey of the new facility, � procure and install all garage access points and associated network hardware, configure the I hardware and connect it to the Met Council Network. The provider will pay for this work at a ' price ageed upon with the Metropolitan Council prior to the work. � Discontinuina Use of Facilities In the event that a provider stops using a garase for operating and maintaining instrumented regional fleet vehicles, Metropolitan Council shall disconnect and remove all garage access points and associated network hardware. The provider shall pay for this work at a price agreed upon with the Metropolitan Council prior to the work. ChanQin� Facilities � � 17 I i i In the event that a provider moves to another facility, Metropolitan Council shall disconnect, I move, perform a site survey at the new facility, and reconnect all garage access points and associated network hardware and reinstall and reconfigure the hardware. The provider shall pay for this work at a price agreed upon with the Metropolitan Council prior to the work. Addin�Vehicles If a provider adds a regional fleet vehicle, either far expansion or replacement, Metropolitan I, Council shall install, connect, and test the on-board equipment and integrate it with the ' SMARTCoM system. Additional regional fleet vehicles should be prewired to allow easy installation of on-board SMARTCoM equipment. Metropolitan Council may use either its staff or a contractor to perform this work. The Council shall pay for equipment and installation in new buses up to the maximum amounts shown in the foiiowing table until the Vehicle Fleet Policy is formally adopted, which will then supexs�de the amounts listed below: � 30'/ 40'/ Articulated/ Small Buses Used for ' ��n:all Buses with No Commuter Coaches Fixed Routes � Regional Fare I I Ccllection E ui ment '� Expansion Packabe of Ancillary Package of Ancillary A�'L/MDC equipment �� Items including Item� includmg -_ , and instaliafion: �� Regional AVL, Rejional'AVL""`" $5,000 ' equipment and equi��ment and , installation: $35,500 installation: $3��,500 I APC equipment and; , APC equipment�and � � installation: $5,000 ; '� irastallation: �5.000 � Replacement Package of Ancillary Package of Ancillary AVL/MDC equipment Items including �� Items�including �"�'' and installation: $500 Regional AVL Regional AVL Equipmen�`az�d installation: $6,00 �� installation: $35,500 '� � APC eguipment and APC installation: �500 � ; instaliation: $5,000 � i.,, ,�, . Metro Transit shall update the S�ARTCoM system to reflect the changes. Removinr Vehicles � If a provider removes a vehicle from the regional fleet and disposes of it, the provider shall be responsible fox disconnecting and removing the on-board equipment, unless otherwise approved in writing by the''Council. The provider may use its staff, an authorized contractor, I I , or Metropolitan "Councif staff to perform this work. If the Provider uses Metropolitan Council staff, the provider shall pay for this wark at a price agreed upon with the Metropolitan Council prior to the work. Metro Transit shall update the SMARTCoM system to reflect the changes. I Addition of an Emplovee I Providers shall submit a Netwark Login ID Request form to the Metropolitan Council Service Desk for any new employee that needs access to the TransitMaster software. The Service Desk shall create a Met Council Network account for the new employee, notify the new ' employee of his/her Met Council Network account login, and route the Network Login ID Request form to the TransitMaster System Administrator within five business days from the � 18 � , ( , receipt of the request. The TransitMaster System Administrator shali create a TransitMaster � account for the employee and notify the new employee of his/her TransitMaster account login within five business days of receipt of the Add/Delete Employee form. i � , Termination of an Emplovee � Providers shall follow the processes described below in the event of termination of an I I � employee: ' A) Scheduled Termination: The provider shall submit a Request to Terminate Network User Account form to the Service Desk at least five business days before the scheduled I termination e. . retirement, voluntar de arture of an em lo ee with access to the � g Y P ) P Y TransitMaster system. The Service Desk shall schedule the deactivation of the ��, � , e o i ew r c un employee s M t C unc I N t o k a co t for the end of the day of;the employee s de arture. The Service Desk shall forward the information°�Q`the TransitMaster S stem P Y �. , I � I Administrator to deactivate the employee's TransitMa�zer acco�nt on the day of their I departure. B Immediate Termination: Providers sha11 call the Mefro'�f�litan C�ounG�1 Service Desk a � I ) , p t �I �.n, ,. E�51-6Q2-] 498 to report the immediate terminatian of �n employee witFi access to the � ' TransitMaster system. The Service Desk sha11 deactivate the terminated ernployee's Met I Council Network account as soon as possib�le and repart'the termination to�t}ie` � ; TransitMaster System Administrator, who shall deactivate`the terminated employee's j TransitMaster account as soon as possible. The provider shall also submit a Request to , Terminate Network User Account form to the Service Desk for processing. � � � .:, , � �� ,,. �. i - ,� �. � i l i � a,� I '� r a,.. , a' �"'�- i > ti; <,. �s � �; . I � v Ye �, y � ; w � � f I II : ` �'' S � �,� �z � ; � � , I , � � � :� '� � � l i � '' ='-� � ' � , .�� :; � i ?' � „; � I � � , � � %'' .: � � t im � � � �� , ' � � �� I � � � ct : � � , �� .`;:.. �:?.�E I ^ �u. 5 � �i.-�`^'�" � .. � �� 3}x �^� � i�� f "� y i :��' I I � i Il �i , , I � I � i I 1 I 9 I ' I '-- --- _ _ — — - -- - — � Exhibit B Regional Standard Operating Procedures Updated OS/28/2010 DRAFT ��i List of ReQional SOPs Date Revision No. Document Subsection Descri tion Distributed & Date 01 _ 02 _ Work Assi�nment Use 09/14/09 1 01 01 Covert/ Alarms 12/16/09 T -------....-- ------------ -.....�.-- ------- ------------ 02 02 TextMessaging—Daily 09/14/09 1-01/20/2010 I Op_erations Use ' 02 02 Text Communicarions 01 /20/ 10 During Emergency — ------- O erarions --- -- I 01 03 TransitMaster Fallback 09/14/09 _ _ _ Notification __ ___ _ � 04 03 TransitMaster User 05/�5/10 1- 04/19/2010 ', Su ort Process 03 02 Service Adjustment lise 12/16/09 � 03 03 Waiver Maintenance 10/07/09 ^ 02 03 Geo-code File Transfer 09/14/09 ^ Process ' i I i I I ' i � _ _ ___ ____ . _ _ __ __ ____ � I I I �� Regional AVL Project SOP 'I TransitMaster- Work assignment Use Section: RAVL Document #: O1 ' Subsection: 02 Total Pages: 3 � Issued By: Regional AVL Operations Issue Date: 9/14/09 Committee ' , Prepared By Christine Kuennen, Manager TCC, Revision No: 1 � Metro Transit I Approved By Christy Baill}�, Aeting Director Bus I �:'�::S�S�:'¢�i`cIJYL, ��i;'^ �.2RSi`t I Note Reviewed and approved by RAVL Revision Date: 1/20/10 �� Operations Committee on 9/10/09. I at I U d ed 1/20/09 to add ste s 5 and 6 P P re. setting Work Assignment View l i� Filter ', To establish consistent practice amongst agencies in the daily use of the ', Pur . pose TransrtMaster Work Assignment feature. '�� Agency groups: Each agency will have one or more work assignment role � designated within their group. A group is represented by a�ency initials, as I I defined in the attached document. Definitions Work Assignment Role: A spec�c role within an agency group that the user lobs into that sorts incoming calls, system and adherence messa�es. I I All Users under normal daily operating conditions are required to be User logaed into their defined work assignment role(s) at all times. , Requirements Authorizations beyond normal use must be obtained by the TCC Operations Mana�er, or designee. Work Assignment Roles 1. After loaain� in to TransitMaster, click on Operations from the menu bar, then select "Operations/Work As ;i��;vn��rlt Roles". 2. Or, click on the Work Assignment Roles icc n`�� . Procedure 3. Select role appropriate to agency group. The specific role for lo� on will be defined in the individual aqency's work assianment � schedule, if applicable. v 4. Under Operations menu, select Work Assignment View Filter. � Metropolitaa Council V Building communities chat work r - _ __. . . . - - . _ . _ __ I Page 2 of 3 Rev. 5. Under View menu, select Save Current Layout. 6. Users must obtain permission from the TCC Operations Manager at Metro Transit in order to operate Transit Master without use of Work Assignments. I 7. When logged into work assignments, system messages appropriate to the rou will be routed to the users deskto . Each a enc g P p g Y shall establish internal protocol on how users should manage their work assignment roles when a user needs to leave thei�� console unattended. Estabiishing a�:d 1VIQintaininb �bency Gro�ps ar.� `J`Jark Assibnments • Agencies will notify the Metro Transit System Administrator in - order to define or make updates to their Agency Groups and Work Assignment Roles. This notification should be provided at least 1 week ahead of the eapected chanbe. • Individual agencies are responsible to maintain an internal schedule and/or rotation of work assignment roles that are suited to their operations. . . . • It is recommended that RAVL Agencies consider the�r work assignment roles and routes and vehicles distribution prior to the beginning of each pick. Any changes to this procedure must be approved by the RAVL Operations Committee. Notifications The Metro Transit System Administrator must be notified of all needed updates or changes to their Agency Groups and/or Work Assibnment Roles. Reports None. TransitMaster User Guide, paae 34. MetCouncil Regional AVL deployment understandin; on system, set-up References issues. SSO1 Section 1.2 MT onlv — Work Assianment roles chanae memo � Metropolitan Council V Irry�rouc rcK(irniaLannlnHlu.�enr+sinaylobui emrwmy _ - - -- -- II _ _ ___ . I Page 3 of 3 Rev. � i I � Metropolitan Council V lnqmroc rc�7irx�u! cvirqxliliirncss in a gloiwi ernnamy i I _ _ _ . . . . . ___ — ___._ . _ ._— . _ .._ _ __.. __.— _ —__: . I ' ;�,��'' ��r��a�l��an �r�� Regional AVL Project i SOP I Covert/Overt Alarm Response Section: RAVL Document #: O1 Subsection: Ol Total Pages: 2 Issued By: RegionalAVL Operations Issue Date: 12/16/09 I Committee I Prepared By Christine Kuennen, Manager TCC, Revision No: Metro Transit � Approved By Christy Eailly, Acting Director Bus I T'ransportaiion, iVletro Transit Note Revision Date: I To ensure proper response to Regional Transit emergency calls received Purpose by the Metro Transit Police Dispatch at the TCC. To ensure the safety and security of Regional Transit Operators and customers. i Definitions Covert: Synonymous with "Silent" Alarm. A button devise /alarm installed in hidden Iocation in the Driver's area of a bus. Fressing the j I buttons triggers an emergency message to all TM Bus Operations users. I If installed, a covert mic may be opened for purpose of listening to bus � activity. Overt: Also known as "Emergency Request to Tallc". A small round red � ' button in the upper left corner of the MDT. Pressing the buttons triggers an emergency message to all TM Bus Operations users. User Metro Transit TCC will act on all emergency calls received. Requirements Individual providers have the responsibility to determine whether to � � install and use the Covert/Overt alarm features of the system. , When Covert/Overt alarm is received, an audible alarm sounds and an Procedure "Emergency" icon flashes on the screen within TransitMaster. The AVL I map display will center on and track the vehicle. I l. TCC Police Dispatcher will dispatch call to the Transit Police Squad in the patrol area and coordinate response, providing the followin; information: , I • Bus Number, Route Number, Service Provider, location and direction of �ravel. , • TCC will monitor bus movement and provide updates to MTPD. 2. Once squads are en route, the TCC will contact Provider's dispatch to notify of MTPD response, provide ETA, and gather any known � details of the emergency. I � Metropolitan Council II Buitding communittes that work i I Page 2 of 2 Rev. , 3. Individual Providers are responsible to contact local Police/Fi1'e/EMS I and/or private security for their own emergencies. � Providers who are unable to stafftheir dispatch desk at all times of service must provide their staffing schedule to the Manager of TCC. TCC will contact local Police/FireBMS and/or private security on the provider's behalf durin� such times. The details of this arrangement will be maintained under separate agreement. 4. Individual Provider dispatch will update TCC on details and status of I the emergency, as known, including local PD/Emergency, and/or I private security response. 5. Individual providers are responsible to dispatch supervisory and other I GY�ic't 1'eS�viiS� �O �.iii�iy�,llCle�. U}�Oi11'�CiLi�St pravi��rs ma �% �i7Z contacted to provide additionai operational support under separate mutual aid agreement. Individual providers are responsible to provide notification of i emer�encies per their own chain of command structure. Notifications I Individual providers will provide TCC with dispatch phone #'s durin� all ' hours of service. 1. TCC Supervisor managing call will complete a Special Situation � Report documenting the alarm received and the response. 2. If alarm is False, TCC will complete and forward an Electronic Radio � , Reports Defect Report. 3. Each Provider will complete a report for their agency per their own protocol. ' 4. Upon request, TCC will provide a copy of Metro Transit's SSR to the provider involved. References TCC SMARTCoM Guide pages 5, 7. � Re�ional Provider Vehicle Ident�cation list I I � � � I � � Metragolitan Council � lrnproue re.qionuL mnyxfltiirness in o ralobcd ecnnamy � I I I , ��' ��r+�p�+�l�t�.n ��c�:l ,� Re ional AVL Pro' g �ect SOP Text Messaging- Daily Operations Use Section: RAVL Document #: 02 , Subsection: 02 Total Pages: 2 Issued By: Regional AVL O erations Issue Date: 9/14/09 P Committee Prepared By Christine Kuennen, Manager TCC, Revision No: 1 Metro Transit � Approved By Christy Bailly, Acting Director Bus Transportation,lVletra'�ransj� , Note Reviewed and approved by RAVL Revision Date: 1/20/10 � Operations Committee on 9/10/09. Updated 1/20/10 to include shared route instructions. ' Purpose To establish consistent practice amongst agencies in the daily use of the TransitMaster Text Message feature. Text message — Text Message sent to MDT by user from Bus Operations � ' Module. I Store and Forward (SF) Allows user to store a message in system for Definitions defined duration. '� List Feature which allows user to add more than one vehicle, route, group to the text message distribution list. Repeat Interval Allows user to put the messaae on a schedule to repeat � at defined interval. User Defined by individual providers. � Requirements ' Procedure �dividual providers have the authority and responsibility to determine their own internal procedures related to the use of text messaging, except as indicated below: � i �' Authoritv to Send messages: Individual providers are not authorized to send text messages outside of their own fleet, including in cases of emergencies. Shared Routes: When one or more providers operate a shared route, the normal use of i ROUTE for sending text messaffes is prohibited. Instead, the use of a pre- � built route LIST is required, selecting the route number by provider. See example below. I ' � Metropolita.n Ccruncil L3utkiin�q-canmunUtes thai.uarlt I _ I I Page 2 of 2 � Rev. Metro Transit is responsible to maintain these lists each pick. , .. � ,� „ �� __. . � �..,;,� _ _.. , `,a. � I �� -`W�� i7estinahor �� -- — -r � i Enter Itsr+: G�11 list actiaated( — � Te�f i�rficar: ��` � SE�trP &�o:M�tacd �, ' F5 Pte 731 � VJKD'Y � Ca� : � #�oF!t�� :3 � � I L �! �F5Rte722-W�:U'Y � �� . ��r I � LB Rte 62 • SAT ! av' I VeMicle iiaute. LB Rte �62 - WKDY � � � � � ' � � 1 �� s �::_ � '� � i I � � Dtia'et F{eet� . � ��iT Rte 62 - S.4T ( � '�' : : � MT Rte 62 - tiJKDY ; � : � ��laek GrauF tviT Rte 721 •V�lKDY j , � MT RCe 722 - SAF � �� List � � ! I � � '� 1 r�4VL TEST Create � � i r�ll �T�STList ? i � xALL CALL - All M T B uses ? — u�E st�,�� , � Forwa�ding � -- � �----- -- - � r. ; � l:leat List '� � : ��•.<< Canc�l �eResh � � .._.�._____ _�� ,. __�.�_,.W.�.. _ ,..m. a ,e � � � In situations where individual text messages may benefit other �� providers, users are advised to utilize the Communications History feature. This feature may be used as a shared resource of information. � • The Repeat Interval feature is not to be used. This is due to I historical concerns with the frequency of inessages causing system slowdowns and lock-ups. In situations where unplanned detour messages or other operational messages may affect another provider`s service, dispatch centers shall notify each other by phone or by email group. Notifications Any changes to this procedure must be approved by the RAVL Operations Committee. i � Reports None References TransitMaster User Guide, page l 6, 17. 22 � � I I � Metropnlitan Cauneil , I V� ln�fmynr revrurrrui. orn+prlfflrn�ru�.a v� a xi:u'r�c�i ce•c.wmy I I I �I � �'��'��'�` �'��°`�� Regional AVL Project SOP Text Messaging — Emergency Operations llse ��, Section: RAVL Document #: 02 Subsection: 02 Total Pages� 3 Issued By: RegionalAVL Operations Issue Date: 1/20/10 Committee � Prepared By Christine Kuennen, Manager TCC, Revision No: Metro Transit I Approved By Christy Bailly, Acting Director Bus Transg�ortatio�, Nde4ro Transit Note Revision Date: ' Purpose To establish consistent practice amongst agencies in Emergency use of the TransitMaster Text Message feature. Text message — Text Message sent to MDT by user from Bus Operations Module. Definitions Store and Forward (SF) Allows user to store a message in system for I defined duration. � Repeat Interval Allows user to put the message on a schedule to repeat I , at defined interval. User Defined by individual providers. Requirements Procedure Individual providers have the authority and responsibility to determine their own internal procedures related to the use of text messaging, except I as indicated below: i Repeat interval The Repeat Interval feature is not to be used. This is due to historical concerns with the frequency of inessages causing system slowdowns and lock-ups. I Authoritv to Send messages: '' Individual providers are not authorized to send text messages outside of ! � their own fleet, includin� in cases of emerffencies. b b Shared Routes: I� When one or more providers operate a shared route, the normal use of ROUTE for sending te� messa�es is prohibited. Instead, the use of a pre- built route LIST is required, selecting the route number by provider. See � example below. I Metro Transrt is responsible to maintam these Iists each pick. ' I � NYetropolitan Council ' i II Building communities that work ��, Page 2 of 3 Rev. I � �� . = - , _ � �� ,��..,. � .� Clestinatio�� -- -- -- I i � �'� Enter It�m: CaU�list acti�,dfedl __ � ( .Tert Acfirar� List � � �t � ,� , ro r �� i � � ��c &�o ad) �� rCaIILr.�: #o(�tem.>:;3 � � � �FSRter?2-WKDY � � � 6ro ? � I �� LBRte62•9AT I �i � � � } J�hicle� fioute :� � LB Rte 62 - WKDY i �Y; �� g j tw1T Rte 62 - 5AT �` '� L?ri�ier �� Fleei , ti1T Rte 62 - WKDY � � P�iT Rte 721 - WY.DY � �� ( Block ;�Group � � � � ' MT Fte722-SAT � Rurr , �� List"""'` . _ Greute .. J � � � � i ` �RAVLTEST ,._._ I�I, = � � Ali -1TEST List ` � 1 � '' 1 x4LL CALL • AlI MT Buses i � i ,.o. Ube � 2�'� � � i , rorw�rding j � i i� ; � �� =r � Cancel Relresh, � _�''<<' 1 e` � � i Sharing information I In emergency situations where another provider's operation, and/or public safety will benefit from texted information, the followin� process will be used to communicate the te�ct message information: • Individual agencies will notify other providers through I e-mail distribution b oup that an emergency text � message has been placed that may affect other , providers. This message will contain the details of the '� message to include: -Location affected - Content of text message I -Duration of inessage if Store and Forward (SF). • Individual providers will send updates to others through I '� , the use of same e-mail distribution when emeraency has been cleared. � • The Regional AVL Operations workgroup will create, ' maintain and distribute an email distribution list for all I providers for use in this contea�. I • Each provider will create and maintain an e-mail distribution process that can be accessed by their users for this purpose during emergency operations. • The Communications History feature within Transitmaster will be used as a shared resource of � information for text messa�es that have been distributed. �'', I � � I Notifications �y changes to this procedure must be approved by the RAVL �' Operations Committee. � � Metropolitan Council ' V lmrn'ouc rcrc�iwc¢l cv�ryxtili�rness In a globul ccrorwrny . , __�I _ I Page 3 of 3 i Rev. I � Written documentation or TM Incident report where available, is to be created when an emergency text message has been sent that may affect Reports other providers. Each provider will determine their own method of documentation. Documents are to be stored and maintained separately by each agency provider. Reports may be shared between providers under provisions agreed upon in separate SOP. References TransitMaster User Guide, pa�e 16, 17, 22 Emer�encv Text E-distribution list I • �� I I � I � � Metrapolitan Council V Iny�roue rGqia�al coiryxfifiirness in a plobul eror�rqy — —. J I � `��"°��'��' ��'�� Regional AVL Project SOP i i TransitMaster Fallback Notification �'�� i Section: RAVL Document #: O1 i Subsection: 03 Total Pages: 2 �! Issued By: Regional AVL Operations Issue Date: 9/14/09 Committee I Prepared By Christine Kuennen, Manager TCC, Revision No: � Metro Transit ��, Approved By Christy Saili3�, Acting Director Bus I '�'rat�s�crtati�n, l�ieiro i ransit Note Reviewed and approved by RAVL Revision Date: I Operations Committee on 9/10/09 i To establish a standard voice fallback procedure to ensure proper �, Purpose communication and coordination amonast agency users. � Fallback: Term used to describe system status when Transitmaster I I Definitions Application is down. This can be due to system failure, planned ', maintenance, or software upgrade. ' User Affects all users of the Transitmaster system. I I Requirements Prior to taking the system down, Metro Transit will notify all Regional '! Procedure providers of the TransitMaster system, as well as other impacted personnel. This notification is to specify the expected duration of the ! outage. Metro Transit will repeat this notification upon system start-up. Individual providers are responsible to keep TCC informed of changes to 'i phone numbers or email contacts required for this notification. This I update shall be provided to the Manager of the TCC, by email. I, NOTE: Users should take note that the Covert and Overt alarms will not I ' work during system fallback and take steps to identify alternative communication procedures for the duration of the fallback period. �� Metro Transit IS will notify Regional Providers by e-mail, as far in �� advance as possible, and at the same tune internal users are notified, of ! Notifications . . � any period of down time or disruption to the TransitMaster system. I � Immediately prior to a scheduled system outage, TCC staffwil( make I notifications to users accord' Q m to attached call list . � Once notified by TCC, individual providers are responsible to make any further notifications to affected users within their own agency. W Metropolitan Couacil v � V Bui[ding rnmmunities that work i i � i Page 2 of 2 I Rev. �� Any changes to this procedure must be approved by the RAVL Operations Committee. I i Reports TCC will document the Fallback period on TransitMaster SSR. References None. i I I I I � I � I � � � Metropolitan Council V lny�ioue regiwialmrtyx4liirness in a.gt�! c�nwmy I . ._ ___ -- _ . .. ._ _ _ .. _. _ _ . I i I �`� ��"�°� �� Regional AVL Project � SOP TM User Suppor# Proce�s ' , Section: RAVL Document #: 04 �� Subsection: 03 Total Pages: 5 I Issued By: Regional AVL Operations Issue Date: 12/16/09 I Committee I Prepared By Christine Kuennen, Manager TCC, Revision No: 1 �' Metro Transit I Approved By Christy Bailly, Director Bus irar.spertaiion, �eira : ransit Note Revision Date: 4/19/10 Purpose To ensure efficient user end support for TM system and provide guidelines and response expectations for su ort to the end user. PP � Power user- Individual(s) identified at each a�ency who will provide � Definitions expert level user support to others. I �, I User Individual providers will identify at least one individual at their agency ' Requirements who will be a"power user" and therefore able to train, lead and assist others in the use of the TM system applications and procedures. i '�� Metro Transit will share any TransitMaster User �uides and MDT trainin; I ; � materials that are internally developed in an effort to assist provider ' ' agencies in the use of the system. It is recommended that agencies identify an internal tracking mechanism to identify and troubleshoot system issues. See `Blue Card" template attached as used by Metro Transit. Procec3ure If an end user requires assistance in the course of daily operational use of I the system, the following process may take place in an effort to resolve I quickly. �, 1. End user will contact identified agency Power User in an effort to ' troubleshoot the problem. 2. If Power User needs further troubleshooting assistance, they may � contact the TCC for assistance if issue has unmediate operational impact. i 3. If issue is unable to be resolved or is identified as needina further b support issue, the agency will take steps to resolve the issues as follow, depending on the source of the concern: i � Metropolitan Council �/ Bu(tdln,q mmmunit(es that u�ork �. I I _7 Rev. Procedure Hardware Maintenance Issues: Contact Trapeze for technical support and resolution per terms of warranty and established maintenance agreement. See RMA Process Attachment. Trapeze CRG Return Form TransitMaster Svstem Administration and TM Waivers: i Rosalind Salters, System Admin for Metro Transit at 612-349-7788, may be contacted for general support and questions regarding TM user configuration. All other issues should be forwarded to the Service Desk for resolution. , Geo-coding issues/off course/off route issues With exception of MVTA and SW Metro, geo-coding will be provided exclusively by MTS for tlie durat;ofi oi �he contract. A merge process must take place before any geo-coded changes are activated in the system. A schedule of known merge dates will be maintained by Metro Transit and provided to the RAVL Ops Committee annually. Any changes or updates to the list shall be provided to the RAVL Ops Committee. The merge schedule is at the direction of Metro Transit System administrator. If a provider needs to have a merge considered on their behalf, notice must be provided at least 7 days in advance. Metro Transit agrees to provide a current list of missing intervals at each I RAVL Ops Committee meeting. All questions and related issues should be forwarded to John Harper at MTS for resolution within the geo-code or waiver maintenance process. (see separate procedures RAVL 03.02 and RAVL 03.03). An approximate 1 week turnaround to process the geo-coding change should be expected. Delays beyond one week will be communicated to the I provider. If a data issue is unable to resolved through normal geo-coding process, the issue will be brought forth to the MetCouncil Data Quality Group for resoIution. Network Connection/Citrix Issues All connections/Citrix issues need to be logged through the Metropolitan Council Service Desk. You can reach the Service Desk by phone (651)602-1498 or by email ServiceDesk(a�metc.state.mn.us. Their hours of operation are Mon-Fri from 7:OOam — 4:OOpm. If the issue happens I � Metropolitan CounciY � Improx� rr:yiorm! mntpe:tilii.rncs� in a�lobat c�wnonu� Rev. outside of normal service hours, the recorded message will provide directions to contact after hours support by calling the IS pager at (952)394-1547. When calIing the Service Desk; be prepared to give your name, user (login) ID, garage location, phone number, and reason for the call. Service Desk staffwill record your request for service and follow up will be made in a timely manner. If you need to call the after hours pager, please lea�e a number where you can be reached in the next 20 minutes and someone will return your call. At the time you contact the IS Service Desk by phone or the afterhours pager, a incident ticket will be created and the information that you provide will be included in the ticket for future reference. When the ticket is o�efie�i, you �v::::e�eive a;�ce;pt o; the �icket �y� email. � he recei�t will provide information about the ticket that will include: date and time opened, summary of your issue, an eta regarding when the incident is expected to be resolved. The incident eta is determined by its assi�ned level of priority and is included in every ticket Denerated. Priority is based on: Incident Prioritization and Response lt is the responsibility of IS to properly categorize incidents and caller's responsibility to provide appropriate detail when requesting support. To provide the response times listed, it is imperative that notification be made by telephone. Notifications received by other means may result in delays. ' Priority 1 Incidents. Definition. Critical wark for the business unit cannot continue until the incident is resolved and there is NOT a manual or alternative work-around or temporary solution. A"Service Disruption Notice" will be forwarded throuah the IS , Service Desk during business hours, to appropriate recipients during business hours and at their earliest opportunit_y. The disruption notice will provide an � ETA for either resolution of the service outage or when the next communication � update will occur. A final service disruption notice will occur once the service has been restored. User Action: Call the Service Desk at 612-6� 1-1498 for all Priority 1 Incidents (do not e-mail. If after hours, the call will roll over to the on-call pager system. Be as detailed as possible in describin� the situation. Response time: Corrective action will begin irrunediately and will continue until corrected. Priority 2 Incidents. Definition. Critical work for the business unit cannot continue until the incident is resolved, but there IS a manual or alternative work-around or temporary � 1Vletropoli�an Council I� lny�rouc rt-yionn! mm�liliie�ness ui a globril ecvnomy I I Rev. solution. Response time. • 70 % of the corrective actions will occur within 6 business hours. • 80% of the corrective actions will occur within 8 business hours. • Corrective actions exceeding 16 business hours will require an evaluation and a review with the Metro Transit Business Liaison. Priority 3 Incidents ' Definition. A non-critical incident. Response time. • 70 % of the corrective actions wil] occur within 24 business hours I ' • 80% of the corrective actions will occur within 32 business hours � • Corrective actions exceeding 40 business hours will require an evaluation and a review with the Metro Trar�sii �usiness Liaison. Work orders � Definition. Requests for IS to perform new, typically non-remedial work. , • Requests for new PCs or PGrelated hardware will be coordinated through the Information Technology Request (ITR) process, submitted by MTS. • All other work orders (i.e., adding a new user, moving a user's PC, etc.) will be handled solely through the IS Service Desk. Response time. • 70 % of work orders will be completed within 10 business days from time of receipt of required materials. i • 80 % will be completed within 12 business days • Responses exceeding 15 business days will require an evaluation and a review with the Metro Transit Business Liaison. � Out of compliance requests for support or "Walk-up Business" i Definition. Requests made by a user directly to non-service desk IS staff � performing services for another user. ��, • Ab eed response time ' • The non-service desk IS staff will attempt to answer questions and will provide the user with the procedure to follow when service is needed • The non-service desk IS staff will check-in with the service desk before responding to an `emer�ency request' from a user. Schedulin of Service Outa es g g IS will confer with the Metro Transit Business Liaison (or designee) when scheduling service outages. Minimize the Impact of Service Outages: ' • IS and requester will confer and agree upon scheduling of all service � Metropolitan Gouncil � �I 7nN�nuc� rt.°gionn! cnmpcttliirnc•>s in a 91abu1 eaxiumy I I Rev. � outages and will, to the extent possible, schedule outages during time periods and days of lower system usage. Communicate Outages Appropreately: • All planned outages will be communicatad by IS to the ReqionalOpsGroup e-mail group, the members of which will be identified by the RAVL Ops Committee. • The IS Service Desk must be informed of all application outages. • Requester will supply the Service Desk with word'mg to be used to communicate with impacted users who may call the Service Desk with questions or comments regardin� a scheduled outage. If the issue is unable to be resolved in an acceptable manner, it may be presented to the RAVL Operations Committee for discussion and rPs� � Transit Provicier Account Maaagement Providers will be expected to manaQe account access to the Metropolitan Council network. Providers will be expected to complete a ne�� user rec�uest form provided by the Service Desk. Providers will be expected to notify the Service Desk immediately following the termination of any employee with access to the network. Adding Bus Operators The task of Addin; new Bus Operators into system will be completed by each provider, through the Citrix application provided by MTS. I I I Notifieations per process noted above process. ' Reports N/A Metro Transit "Blue Card" Template. , RMA Process Attachment. References Trapeze CRG Return Form Request for Network Lo�in ID RegionalOps Group e-mail list , 2010 Known Merge Dates I �� , � � � Metropolitan Council I V Imprrnx• rtr�ional mmpctiliirnca�s in a�lo'v<ll ecvnw�ry � i � I ', .��. ��trr� �x�t�a�n ��+�� . . ''� � Regional AVL Pro�ect SOP � Service Adjustment lJse Section: RA,VL Document #: 03 Subsection: 02 Total Pages: 2 Issued By: RegionalAVLOperations Issue Date: 12/16/09 Committee Prepared By Christine Kuennen, Manager TCC, Revision No: Metro Transit � Approved By Christy Bailly, Acting Director Bus '�ransportztion,lVietra T. Aen�it Note Revision Date: I To ensure accurate system data is reflected in Transitmaster data Purpose reporting and Customer Information Systems such as Nextri and Real , P� i Time Signs. , � Service Adjustment is a tool within TransitMaster that allows the user to Definitions enter single day/current day changes to scheduled service, such as fills and extra service, into the system database. User Only authorized users should enter service adjustments. Those authorized Requirements �'�'ill be determined within each provider agency. Procedure In normal Operational circumstance, anytime there are known, but I � i unplanned changes to scheduled service, a service adjustment must be entered. Examples of need for a service adjustment are: replacement trips as a result of service delays or breakdowns, extra service to assist overloads, and missed service, � During unusually busy periods such as snowstorms or emergency events, providers will still attempt to enter service adjustments as long as it is operationally feasible to do so. This is in attempt to offer the best information possible to our riding public and to ensure the most accurate � system data possible. Notifications None , Reports None References Reaional Transit Service Adiustment Guide ' o n oua iI ' Metr ol��ta C c P � � f3uitcttr{q�comnzuntties�ihat uwrk � I I I � °� �'��"�°`��' �°�� Regional AVL Project j SOP Waiver Maintenance Process Section: RAVL Document #: 03 I Subsection: Q3 Total Pages: 2 Issued By: Regional AVL Operations Issue Date: 10/07/09 ' Committee Prepared By Christine Kuennen, Mana er TCC Revision No: g � Metro Transit Approved By Christy Baill �, Actin Director Bus 3 g Transpc; tat:or�, P.�Ie�ro Transit Note Revision Date: Purpose To establish consistent practice amongst agencies in the establishment � and maintenance of Transitmaster s s y tem timepoint waivers. Definitions Timepoint Waiver is a filtering feature of the TransitMaster System that allows users to designate how the system treats timepoint crossing � I information for display and reporting purposes. A variety of waivers are used, for a variety of purpose. See attached I a� document, Re�ional Transrt Waiver Guides and Standards for detailed definitions. Yellow —Sheets � Yellow covered packets that the Metro Transit Bus Stop Coordinator creates to reflect upcoming changes to bus stops, timepoints, patterns and/or routing. The top pa�e �ives the route number(s), the effective date, Definitions the descri tion of the chan e, who initiated the chan e contact erson's P g g� P I extension, additional information as needed. The subsequent page(s) give � old/current routing patterns followed by the new/updated version of the routing patterns. � Yellow Sheets allows the geocoder to or anize information kee track of � � , p any changes to bus stops, timepoints, patterns and/or routing and make the necessary chanaes in a timely manner in order to keep bus operations �� running efficiently and up to date. These Yellow Sheet changes will take effect after a scheduled mer�e. The tool required to create system waivers and perform maintenance User functions is within TM Planner, a Metro Transit System Adminstration Requirements function. As a result, all waiver maintenance for the region will be performed by Metro Transit Geo-coder. ', ' � 11Zetropalitan Council L3utidtr�9��ntunf!{es:that uwrk I I I _ _ _ ___ __ ____ Page 2 of 2 � Rev, �I PCOC@SS The geo-coders working on Regional Transit waivers will follow an �, established work process, as follows: � All waivers will be entered and maintained according to the Re�ional ' Transit Waiver Guide and System Standards. � All waivers will be entered using standard formatting. See attached �uide. As service changes are required, Metro Transit will track chanaes using ' the Yellow Sheet Process, with all system timepoint waiver changes ; documented. I In advance of any change, Metro Transit Service Development will notify Notifications the Transit System Administrator and TCC geo-coder of all upcoming l changes aifec�ir�g s�r�vic�. � TCC eocoder will document all chan�es and action taken in an Excel I �! Repor�s g � � spreadsheet called "YellowIncomingWSChan�es" Re�ional Transit Waiver Guide and Svstem Standards � References Service Change "Yellow Sheet" process I MetCouncil Rebional AVL Deployment Understanding on Data Issues. ' �� , ' ' . � I � � , '��i � I I � Metrapoli�an Cauncii I �� I 1 rnE rwxr ttKrarridt evm�x�t(u�xYrrzus ir� u<r'�Y�! cxxr�ennF! I il i I �� r�►��€ta�, +��+��e� � Regional AVL Project SOP Geo-Code File Tra nsfer Process Section: RAVL Document #: 02 � Subsection: 03 Total Pages: 2 Issued By: RegionalAVLOperations fssue Date: 9/14/09 Committee Prepared By Christine Kuennen, Manager TCC, Revision No: Metro Transit � Approved By Chrisiy Bailly, Acting Director Bus I Trans ortation 1:�`,etro Transit P � Note Revision Date: � Purpose To establish consistent practice amongst agencies in the file transfer i process for geo-coded files. I Definitions Geo-coding is the process by which locations and time points on a route I segment are surveyed in the field and entered into TransitMaster using the ' Route Management survey tool. Locations are entered in latitude and ' Iongitude format so as to be recognized by the GPS system installed on I vehicles. I Yellow —Sheets I � Yellow covered packets that the Metro Transit Bus Stop Coordinator I ' creates to reflect upcoming changes to bus stops, timepoints, patterns I and/or routing. The top pabe gives the route number(s), the effective date, the description of the change, who initiated the change, contact erson's � P extension, additional information as needed. The subsequent page(s) give old/current routing patterns followed by the new/updated version of the routing pattems. Yellow Sheets allows the geocoder to organize information, keep track of I ' any changes to bus stops, timepoints, patterns and/or routing and make � the necessary changes in a timely manner in order to keep bus operations running efficiently and up to date. These Yellow Sheet changes will �ake � effect after a scheduled mer�e. � Merge is the process by which newly surveyed data and schedule file data is uploaded to the systems database to be subsequently downloaded to affected vehicles. A merges can take place anytime significant schedule changes take place. The merge schedule is at the direction of Metro I Transit System administrator. i �, Il�etro olitau Cauncil I � P i /I f3uttdir�c��cortununfties that uwrk I I I , Page 2 of 3 Rev. I I User Affects designated provider geo-coder and Metro Transit's Transitmaster � Requirements System Administrator. � Process Geo-Coders workin� on Regional Transit files will follow an established I work process, as follows: I 1. Obtain missing int's,dh's,PO's,PI's list from Metro Transit TCC ' Systems Adminstrator. 2. Obtain route files from Metro Transit TCC Systems Adminstrator and I place files in folder on laptop. � 3. Survey(geocode) the routes. 4. As routes get completed, place files in shared director5r, (TBD) on I Council network. � 5. Keep own t�acl:-up c^py of th� ��pleted routes(�les) a� backup. 6. Continue this until all routes have been coded or you receive new � routes from Metro Transit TCC Systems Adminstrator. Schedule Chanaes- I The Metro Transit Geo-coder will notify regional provider �eo-coder of any upcoming chan�es to bus stops, timepoints, patterns and/or routing. Regional service changes reflected in yellow sheets will require follo��- I up by the geo-coder and make require re-survey for any affected geo- !I coded locations Yellow Sheet Process- I ' 1. Bus stop Coordinator makes the Yellow Sheets. � 2. TCC eocoder receives the Yellow Sheets via interoffice mail. � � 3. TCC geocoder sorts the Yellow Sheets by Metro Transit (MT) routes and Regional Fleet (RF) routes. �, 3. TCC eocoder puts the information in an Excel s readsheet called � P "Ye1lowIncomingWSChanges" to electronically keep track of progress. , The spreadsheet has the effective date, routes, location by ID, route i� direction, on street, at street, to street, the chanaes needed to be made, the status of the change, date completed, and any previous intervals. �� I 4. On the Yellow Sheet, after documenting the data on the spread sheet, I I TCC geocoder puts a checkmark to the top right corner. 5. TCC geocoder makes copies of the RF Yellow Sheets and interoffice '', mail the Yellow Sheets to the RF Supervisor to jive to the RF geocoder. I 6. Geocoder brings paper copies of the Yellow Sheets with them when aeoCOdln I b b 7. Geocode the changes on the most current files. If the chan�es cannot I be made on the files, then reguest new files after a new merge takes ' - place. Example- the Yellow Sheet has changes for the 19 line dated I �� 8/23/09 and the files were given to you on the 22 The 19 line may not � ' � MetropaIitau Cauncil �/ /rnf�ewkr re»urr�ai.awipeffex�.r�x�s in a n�>bcd.<xwnurm{ I I I � I -- — . . _— ----� - --- — --I Page 3 of 3 ' Rev. have the Yellow Sheet changes in its f le. This Yellow Sheet would be set I aside until the next merge, then ask Metro Transit TCC Systems Adminstrator to create the 19 along with the other files. 9. After the changes to the Yellow Sheets have been coded, initial, date and write "done" in the top right hand corner. I 10. As Yellow Sheets are completed, RF emails the TCC geocoder the list of Yellow Sheets to be sent back to TCC, using in the Subject line "Completed Yellow Sheets" 11. For RF, send the Yellow Sheets back to TCC geocoder via interoffice mail so the changes can be documented. � 12. On the Excel spreadsheet, the TCC geocoder updates the spreadsheet with date and status. 13. Use a 3-hole punch to the completed Yellow Sheets and file them by date in a 3-ring binder for one (1) year in the TCC. Mer es Metro Transit TCC Systems Adminstrator will communicate merge dates as they need to be, to include regional participants. If a provider needs to have a merge considered on their behalf, she will require at least 7 days advance notice. When a merge takes place, updated files will be created and the process starts again. If you can't complete the routes before a merge, send Roz what has been completed so the data can be saved. � As files are completed, gea-coders must notify Metro Transit System I Notifications Administrator by email. As yellow sheets changes are completed, Regional Provider Geo-coders must notify Metro Transit geo-coder, by email. Reports N/A , , References MetCouncil Regional AVL Deployment Understanding on Data Issues, sec�ion 2.0-2.4, 3.0-3.3 I � � Metropc►litan Cauncil /I' ln�eorua�: n_xrivrrstarniput:eiutirou.�t� 4ra W�fxx€.reonr��rE;{. I � I I _ —__ — I . _ _ _ __ I 1.0 Trapeze Warranty I � l.l. From Attachment 2, Section 6 of Contract for Met Council Proiect Number 35774 I 6. WARRANTY The Goods sold hereunder are subject to the following warranties: Seller agees to repair or replace at its discretion, without charge, any such equipment, which is defective as to design, workmanship or material, and , which is returned to Seller at its factory, transportation prepaid, provided: (i) Notice of the c]aimed defect is given Seller within one (1) year from � date of delivery and equipment is returned in accordance with Seller's i instructions. ' (ii) Such equipment shall not be deemed to be defective if, due to exposure to any condition in e�cess of those published in the Product specification, it shall fail to operate in a normal manner. , (iii) Seller's obligations with respect to sucl� equipment are conditioned , up;,n t;e prcpe; instaL'at;�n and �peration oi such equipmeni by lsuyer in �i accordance with Seller's written directions. (iv) The warranty stated in this Section 6 shall be void if such equipment is '� altered or repair is attempted or made by other than Seller or Seller's j authorized service center. Seller warrants that any software delivered hereunder, either embedded in l equipment described herein or specifically designed for use in or with such equipment, will substantially provide the function(s) set forth in the i applicable specification (or absent a specification, as described in the i applicable Service Bulletin). Seller will, at is option, without charge, � revise or replace such nonconforming software provided: (i) Notice of the claimed defect is given Seller within one (1) year from the � date of delivery or one hundred eighty (180) days from the date of first , installation, whichever occurs first. , (ii) Software shall not be deemed to be defective if the software or the host medium is exposed to any computer virus or to any condition in excess of those published in the applicable specification(s) �I (iii) Seller's obligations are conditioned upon the proper installation and ! operation of software and the host medium in accordance with Seller's �� written instructions. � (iv) The warranty stated in this Section 6 shall be void if such software (or its host medium) is altered or alterations are attempted) by other than Seller �� or Seller's authorized service center. ' Buyer agrees to pay for all service expenses not covered by this warranty at Seller's then current Standard Service Rates. i NO OTHER WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY OR OF FITNESS FOR A PARTICULAR PURPOSE SHALL BE APPLICABLE ' TO ANY EQUIPMENT SOLD OR SOFWARE DELIVERED � HEREUNDER, AND THE FOREGOING SHALL CONSTITUTE THE BUYERS SOLE RIGHT AND REMEDY UNDER THIS AGREEMENT. i � 1.2. From Attachment 5, Scope of Work of Contract for Met Council Project No. 35774 Warran I The Warranty period for this project shall be one (1) year, commencing upon completion of the final vehicle installation, as defined in this , document, with the knowledge that a punch-list may be generated for ' completion during the Warranty period. The Warranty, as defined in ! Attachment 2 of this document, covers the following: ' o Equipment installed at each respective Facility; ' o Equipment installed on each vehicle associated with the respective Facility; � � � o A list of vehicles and their associated Facility wil] be , � included as art of the ro'ect documentation I P p J As the Warranty period nears fulfillment, or upon request by Metro Council_, [TrapP�P] may provide Maintenar_ce A�,reement quotes for each i of the respective Facilities and their associated vehicle Equipment. I i I I I I i I ' I I I � � ,I _ . _ i i �I 2A Trapeze Warranty Process Guide[ines , RETURN MATERIAL AUTHORIZATION ("RMA"1 PROCESS All items refumed fo Seller must have the following informafion presented prior to the issuing of a Retum I Maferial Aufhorizafion ("RMA') number: the reason for return (as specific as possible), the ifem(s) part number(s), serial number (s) ('rf it exists) and Buyer contact. For vehicle installed equipment it will be required that the vehicle id, vehicle make/model and vehicle yearbe provided. The above dafa will be used to troubleshoot fhe problem with the Buyer contact on the phone. lN�dh vehicle '' information we will be able to share with you rf this vehicle has had a problem in the pasf, if this vehicle make/model has had a run of issues or if this vehicie year seems to have problems. By doing this proactively Seller's intent is to minimize Buyers down time as much as possible. � RETURN MATERIAL AUTHORIZATION ("RMA") REQUEST ' Buvers who have equipment needinq reoair or reolacement shall follow the below procedure: ! 1. Buyer (or authorized representative) has failed equipment needing repair or replacement. I 2. Buyer (or authorized representative) provides to Seller's Representative: Part Number, Serial Number, �, Quantity, and Detailed Problem Description with Unit(s) by caliing 86C 778-5572, or via e-mail to sherry.cook@trapezeits.com. A complete and accurate descript+on of the condition or problem af the , component or unit and the initial troubie shooting shall be done by the Buyer (or authorized representative). i 3. For seriaGzed items in which Seller maintains configuration records (i.e. RIVLU, RVLU), the Buyer (or ' authorized representative) will provide the following information from the top level installed in the vehicie: , Top Level Part Number, Top Level Serial Number, IVLUNLU Serial number, and radio serial number. I, 4. The information provided in step three (3) will be used to update the configuration management records in i the factory. This ensures Seller has accurate records of components installed in a given top level. I � 5. Seller issues RMA number to the Buyer (or authorized representative) by phone or email. � 6. Buyer (or authorized representative) is to give estimated time of shipping the failed componentlunit to � Seller. I 7. Buyer (or authorized representative) places ali equipment (EXCEPT NLU's) in a nonstatic bag along with ' a copy of Warranty Repair Tag (below). IVLU's shall be sent in an ESD static sensitive bag. Seller will �i provide non-static bags at Buyer's request. Buyer shall place a copy of the Warranty Repair Tag Form, which shall be provided by Seller at the time of the report, inside the box or taped to the outside of the bag of the failed unit. Buyer (or authorized representative) shall pack all returned units carefully, using packing peanuts and bubble wrap when necessary. All returns are Buyer property and must be protected dunng I shipping and through the entire return process. , 8. AIf serial number/identification tags must be left on the units. Only one (1) RMA should be used per faifed , component/unit. Please do not put a failed radio from one (1) unit and a failed IVLU from another unit in the ', same chassis. When IVLU's and radios are swapped between units, the records are no longer accurate. If mixed components come back in the same chassis, it is difficult to track and defays return to the field. 9. The Buyer (or authorized representative) shall reference the RMA number on the outside of the box when �, returning the unit and send it to: ' Trapeze ITS 5265 Rockwell Drive NE I Cedar Rapids, IA 52402 I �I �I � , -- � � �� Exhibit D I I j Regional AVL Operations Committee Structure ' Updated 7/29/2010 I � �; , '� � � I I , I ' � I , I I I , I � � , �' I , i _ _ ___ _ _ Regional AVL Operations (RAVL Ops) Committee � Committee Purpose Il �i To review and approve amendments to the Approaches and Practices and Reqional Standard Operating Procedures, to oversee the Regional Transit Training Program, to resolve SMARTCoM operational and maintenance related issues and to review and recommend changes to the SMARTCoM system. �, Committee Structure Committee Chair: As appointed by the Director of Bus Operations, Metro Transit. Current Chair is Brian � Funk, Metro Transit. Role of Chair: . Determine meeting schedule and agenda . Track status of action items and ensure resolution in timely manner � Cvi7iii'iUfilCcat2 SiBiUS Oi iSSucS tv �GiiiiiiltiEc memb • Liaison with and invite participation of subject matter experts from Council departments to I � inform committee and ensure effective resolution of issues. • Work towards Consensus Agreement on all issues brought forth to committee , • Acting as the agent of Metro Transit's Director of Bus Operations, the chair will carry forward '� committee recommendations and SOPs to the Director of Bus Operations for approval • Bring forth issues lacking consensus agreement to Director of Bus Operations for resolution � per Section IX of Interagency Operations Agreement. i Committee Members: The Committee is comprised of designated Operations Managers from all Regional Transit Providers participants of the Regional AVL Project. Members are designated as either Members with Decision ' Making Authority, or Contributing Members. � Only those members with Decision Making Authority participate in the Committee's formaf authorization of ' amendments, agreements, Standard Operating Procedures(SOP), recommendations, and decisions. I Contributing members have valuable operational insight that will be considered in the resolution of issues �, that are brought forth to the Committee. However these members do not participate in the formal approval process. Members with Decision Making Authority: � I 'I • Christine Kuennen, Manager Transit Control Center, Metro Transit (Committee Chair) , • John Harper, Supervisor Contracted Services- Metropolitan Transportation Services (MTS) I • Jim Sweeney, Operations Manager, Southwest Transit � • Bernie Maciej, Transit Coordinator, City of Plymouth l • Michael Leek, City of Shakopee I • Jane Kansier, City of Prior Lake ', • Mike Opatz, City of Maple Grove The above members may send designated representatives from within their own agency to act as proxy on their behalf. j � Contributing members: � • Doug Loos, Lorenz • Steve Youmans, Michael Richter -Transit Team '� • Tom Knier, Jim Baldwin, Dave Keller - First Transit I • Kim Olson- Schmitty and Sons I Updated 7/29/10 I I, � I ' I • Mark Schermerhorn- Anoka County Role of all members: . Attend all RAVL meetings regularly or send representative . inform leadership within own agency of issues in order to obtain the authority needed to make decisions • Carry out action items in timely manner and report back to committee • Work towards consensus agreement on all issues . Liaison with and invite artici ation of sub'ect matter ex ert wi hin n p p � p s t ow agency to inform and to ensure effective resolution of issues • Distribute SOP and other informational items as needed to stakeholders within own agency. . Members may send designated representatives to act on their behalf and invite subject matter experts to participate as needed to resolve issues. Subject Matter Experts: � Subject Matter Experts are invited to participate in committee meetings as needed and are relied upon to inform the committee and assist in resolution on a variety of issues and action items. The following are a list of subieci matter experts who hdve experience an� accou�tability to the project who currently atten� meetings and/or receive meeting minutes. This list will remain fluid and may expand or change as �I needed. • Gary Nyberg, Manager Transit Systems Technology, Metro Transit . Rosalind Salters, TCC Systems Administrator, Metro Transit I � • Rick Brehm, Southwest Transit I . Phil Larson, First Transit . Rebecca McBride, MTS . Rick Pauisen, Trapeze , . Marty Geyer, Met Council Information Services . Emie Zahradka, Met Council Information Services . William Gustafson, Metro Transit Business Systems Manager I, • Janet Hopper, Metro Transit Service Development . Marcia Rossman, Metro Transit Service Development �, • Phil Larson, First Transit ' • AJ Olson, Deputy Chief Transit Police • Chad LeVasseur, Communications Manager, Metro Transit I Committee Approvals and Resolution Process: ' The RAVL Committee recognizes shared purpose and benefit to our region in the cooperative and I efficient use of the SMARTCoM System amongst agencies. The Committee wili employ a Consensus ' Decision Making process whereby the Committee will seek general agreement of most participants as , well as the resolution or mitigation of minority objecfions. � All Amendments, Regional Standard Operating Procedures, or significant changes to the SMARTCoM ' system as recommended by the Committee shall be approved by the Council's Director of Bus I '� Operations. , Any issue for which the Committee is unable to reach consensus agreement shall be brought forth by the I Committee Chair to the Executive directors of the disputing agencies, including the Metro Transit Deputy � Chief Operating Officer, the Chief Operating Officer or the General Manager, the Council's Director of ' i ransportation Services, and the Executive Director of the provider agency. I � Updated 7/29/10 I � �