Loading...
HomeMy WebLinkAboutTiburon Inc; 2014-12-09;AMENDMENT NO. 1 TO MASTER SUPPORT AGREEMENT TIBURON INC. Amendm nt No. 1 is entered into and effective as of the a~ day of ---=~¥~w...Jl...!...._.l..)!,.~~.------' 2016, amending the agreement dated December 9, 2014 (the "Agree ent") by and between the City of Carlsbad, a municipal corporation, ("City"), and Tiburon Inc., ("Contractor") (collectively, the "Parties"). RECITALS A. On December 9, 2014 the Parties executed an Agreement for support services that was effective July 1, 2014 relating to the Police Departments Computer Aided Dispatch and Mobile system previously developed and implemented by Contractor; and B. The Parties desire to alter the Agreement's scope of work to include services to (1) move the currently installed Computer Aided Dispatch(CAD) system from a physical to a virtual server, and (2) implement an interface between the CAD system and the Police Records Management System (NetRMS); and C. The Parties have negotiated and agreed to a supplemental scope of work and fee schedule for services to move the CAD system to a virtual server, which is attached to and incorporated by this reference as Exhibit "A", Scope of Services and Fee to Move CAD to a Virtual Server. D. The Parties have negotiated and agreed to a supplemental scope of work and fee schedule for the CAD to NetRMS interface, which is attached to and incorporated by this reference as Exhibit "B", Scope of Services and Fee for a CAD to NetRMS Interface. NOW, THEREFORE, in consideration of these recitals and the mutual covenants contained herein, City and Contractor agree as follows: 1. In addition to those services contained in the Agreement, as may have been amended from time to time, Contractor will provide those services described in Exhibit "A". 2. That the fixed price fee for services to be provided pursuant to Amendment Number 1 is sixty one thousand two hundred and twenty five dollars ($61 ,225) as further set forth in Exhibit A and Exhibit B. 3. That the annual maintenance fee for the CAD to NetRMS interface is four thousand five hundred dollars ($4,500) and will be prorated and paid at renewal of the existing support term to adjust the term to be co-terminus with the existing annual term that begins on the first of July of each calendar year according to the Agreement. 4. Contractor will complete all work described in Exhibit "A" within nine (9) months of the Effective Date of this Amendment Number 1. The work described in Exhibit "B" herein will be scheduled to commence at a mutually agreeable (City, Contractor, and City's RMS vendor) date. 5. All other provisions of the Agreement, as may have been amended from time to time, will remain in full force and effect. City Attorney Approved Version 1/30/13 Item #6 September 27, 2016 Page 5 of 35 6. All requisite insurance policies to be maintained by Contractor pursuant to the Agreement, as may have been amended from time to time, will include coverage for this Amendment. 7. The individuals executing this Amendment and the instruments referenced in it on behalf of Contractor each represent and warrant that they have the legal power, right and actual authority to bind Contractor to the terms and conditions of this Amendment. CONTRACTOR By: (sign here) Blake Clark, Chief Financial Officer (print name/title) By: (sign here) (print name/title) CITY OF CARLSBAD, a municipal corporation of the State of California ATTEST: ~ &.lli-: o6{ BARARAENGLESON~ City Clerk If required by City, proper notarial acknowledgment of execution by Contractor must be attached. If a corporation, Agreement must be signed by one corporate officer from each of the following two groups: Group A Chairman, President, or Vice-President Group B Secretary, Assistant Secretary, CFO or Assistant Treasurer Otherwise, the corporation must attach a resolution certified by the secretary or assistant secretary under corporate seal empowering the officer(s) signing to bind the corporation. APPROVED AS TO FORM: City Attorney Approved Version 1/30/13 2 Item #6 September 27, 2016 Page 6 of 35 EXHIBIT "A" SCOPE OF SERVICES AND FEE TO MOVE CAD TO A VIRTUAL SERVER Remotely, Tiburon will provide the services to move the current product Computer Aided Dispatch server from a physical server whose name is SCCADAPP01 (CADLIVE) to a virtual server (VM). All work will be completed remotely during Tiburon's normal business hours Monday through Friday (0800 -1700). All work will be supervised by a City of Carlsbad employee. Requirements: • Virtual Machine that runs the CAD Application may not share its DataStore with other VM's vDisks. • New VM Datastore has 15k spindles on that datastore. This is implied by the doc but not specified. Tiburon Responsibilities 1. Stage CommandCAD including all interfaces residing on SCCADAPP01 (CADLIVE) to new VM provided by the City. 2. Test interfaces where feasible. 3. Cut over to new CAD Server. 4. Upon Client's testing, correct any discrepancies in operation based on the Scope Description. Client Responsibilities 1. Designate a person to be the principal point of contact for all technical questions and administrative arrangements relating to this Proposal. 2. Provide supervised remote access to Tiburon. 3. Create a new VM machine following the attached Guidelines and adhering to the Requirements above. 4. Test CommandCAD on new VM after Tiburon installs CommandCAD on new VM. 5. Test interfaces if possible (may require switching an interface from Live to the VM machine). 6. Client is responsible for swapping any physical interface connections from old to new server. 7. Client will adhere to CAD Network guidelines document with regard to Firewalling, Backups and Antivirus on new server. 8. Client will ensure NIC conforms to CAD Network Guidelines and appropriate ports are open for CAD join operation and communication with database. 9. As required, coordinate the participation of non-Tiburon provided third parties and outside agencies. 10. Complete testing of the modified code within ten (10) business days from receipt of Tiburon's notification the code is ready for testing to ensure conformance with the Scope Description. Fee and Payment Schedule Item Description Fee Move CAD to Virtual server 2,800 Project Management 875 Total $3,675 3 Item #6 September 27, 2016 Page 7 of 35 Payments will be made upon the following milestones at the listed percentages Milestone Percentage Delivery of statement of work 50% Cutover to new CAD Server 50% Completion Criteria This work will be considered complete ten ( 10) business days after Tiburon has provided Client with written notification that virtual CAD server is in production. If Client does not confirm completion with a sign off letter presented by the Tiburon project manager within ten (10) business days of submittal of such letter, or otherwise notifies Tiburon in writing why completion sign-off has not been provided any final invoice(s) will be issued and will be payable in accordance with the payment terms of this Proposal. 4 Item #6 September 27, 2016 Page 8 of 35 EXHIBIT "B" SCOPE OF SERVICES AND FEE FOR CAD TO NETRMS INTERFACE Scope Description Tiburon will provide the services to create an interface from CAD to NetRMS according to the specifications attached in Exhibit "C", NetRMS Interface Requirements Document. All work will be completed remotely during Tiburon's normal business hours Monday through Friday (0800 -1700). All work will be supervised by a Carlsbad Police Department employee. The City will assign a Project Manager to act as the primary point of contact for the City for this project. Assumptions • Interface is uni-directional, CommandCAD to NetRMS. • Data is sent as it exists in CommandCAD and does not include any translation or modification. • Does not include any changes to CommandCAD database field sizes. • Transfer is configurable via settings in File Maintenance Agency table "Transfer At" field. The A enc can select three from the below choices: r 90 -Transferred at case assignment r 80 -Transferred at first call dispatch 1 r 70 -Transferred at first call onscene r 60 -Transferred at unit onscene r 50 -Transferred at first call okay r 40 -Transferred at unit okay r 30 -Transferred at first call transport comr r 20 -Transferred at unit transport complete r 1 O -Transferred at unit clearing r 5 -Transferred at call closure • Only data available in CommandCAD will be sent. If NetRMS has data fields that do not exist in CommandCAD, the data will be empty in the xml. • Does not include any logic related to fields such as "if field x = y, then do something". • Does not include logic to interrogate the CommandCAD data to satisfy a field in NetRMS. For example, if NetRMS requires a flag or indicator to be set to Y or N, and CommandCAD does not have that indicator but data exists within the data that could be interrogated to set a Y or N, that interrogation logic is not included. • Does not include adding text to xml data. Motorola's IRD v2 in Section 4.6 talks about sending multiple Cases for a single CAD incident. Tiburon needs to clarify that if multiple Cases are assigned to a single CAD incident, Tiburon CAD will send separate INC01 and INC02 files for each Case. Tiburon's CAD does not have the ability to combine the multiple cases within a single INC01 and INC02 as it seems that the specification is requiring. • If data in CAD, such as Personnel number for example, must match corresponding table entries in NetRMS, then Client will ensure the table values match. However, field sizes in CommandCAD will not be changed to match NetRMS field sizes. Tiburon Responsibilities 1. Provide the interface per the Scope Description. 5 Item #6 September 27, 2016 Page 9 of 35 2. Install the interface in Client's test environment. 3. Upon Client's testing, correct any discrepancies in operation based on the Scope Description. 4. Install the interface in Client's production environment. Client Responsibilities 1. Designate a person to be the principal point of contact for all technical questions and administrative arrangements relating to this Proposal. 2. Provide VPN access to Tiburon. 3. Coordinate the participation of non-Tiburon provided third parties and outside agencies. 4. Complete testing of the interface within ten ( 10) business days from receipt of Tiburon's notification the code is ready for testing to ensure conformance with the Scope Description. Fee and Payment Schedule Item Description Fee NetRMS Interface 25,000 NetRMS Interface Implementation Fee 24,500 Project Management 8,050 Total $57,550 NetRMS Annual Maintenance 4,500 Payments will be made upon the following milestones at the listed percentages Milestone Percentage Milestone 1: Delivery of statement of work 50% Milestone 2: Ten (10) days after installation in 50% the Client's production environment without any issues rendering the interface inoperable. Issues not caused by the Tiburon interface, or not under Tiburon's direct control shall not be considered as causing the interface to be inoperable. Completion Criteria This work will be considered complete ten (10) business days after Tiburon has provided Client with written notification that Milestone 2 is complete. If Client does not confirm completion with a sign off letter presented by the Tiburon project manager within ten (10) business days of submittal of such letter, or otherwise notifies Tiburon in writing why completion sign-off has not been provided any final invoice(s) will be issued and will be payable in accordance with the payment terms of this Proposal. 6 Item #6 September 27, 2016 Page 10 of 35 EXHIBIT "C" This Interface Requirements Document (IRD) describes the uni-directional interface between CAD and Motorola's NetRMS Records Management System for Agency. The purpose of this interface is to transfer CAD Call for Service (CFS) information to NetRMS. In this document, the following references shall apply: "Customer" shall refer to the City of Carlsbad. "CAD" or "CAD system" shall refer to the Computer-Assisted Dispatch ("CAD") system Customer uses CAD to manage incident information, including dispatch and call for service requests. The uni-directional interface described in this IRD defines an interface that will allow for the transmission of CFS data from CAD to the NetRMS application. No manual intervention will be required to initiate the CFS data exchange. CAD provides dispatch services to Customer in response to calls-for-service received. Many of the calls-for-service result in a dispatcher's initiating an "incident" in CAD, which generally requires a response by Customer. During the time that each incident is open (being worked by a call-taker or dispatcher), the CAD application collects the incident related data entered by the users. Once the incident is closed, all incident data is stored as a CFS record. Customer uses the Motorola N etRMS to maintain a central repository of Incident Records and other records management related data Following entry of the appropriate Call for Service information, the CAD system will send the CFS record to NetRMS. NetRMS will then populate a CFS record with the data received from CAD, as defined further in this IRD. Motorola Responsibilities 1. Installation and configuration of the NetRMS components required to support this interface. 2. Provide technical support to Customer or to a third-party as required to implement this interface on the CAD side. Customer Responsibilities 1. Providing Local Area Network (LAN) connectivity between CAD and the N etRMS system. 2. Insure CAD is configured to provide a combined XML file (Call and Unit data) for CAD incidents. 3. Ensure that support is provided from other vendors, as required for interface integration. Other Assumptions 1. This IRD is written with the assumption that the interface will provide CAD Incident Records to 7 Item #6 September 27, 2016 Page 11 of 35 the NetRMS upon incident creation, when an incident is updated by the below recommended triggers, and after the incident is closed in CAD. 2. The CFS Record created by the interface will be read-only in the NetRMS system. 3. Mapped Code Table field values must match between CAD and NetRMS. Application Versions NetRMS vl.94.2 or later San Diego Build. Acronyms and Definitions ARJIS -Automated Regional Justice Information System CAD -Computer Aided Dispatch CFS -Call For Service IRD -Interface Requirements Document LAN -Local Area Network RMS -Records Management System TCP/IP -Transport Control Protocol/Internet Protocol XML -Extensible Markup Language NTFS -New Technology File System References 633607978333695000 5604.xml CAD Export XML file The communication of incident related data from CAD to NetRMS occurs automatically and is transparent to the CAD and NetRMS users. Logical Interconnection The data exchange between CAD and NetRMS takes place via an XML file. The CAD server creates an XML file that contains the incident data when the incident in closed in the CAD application. Incident Data will include the CAD INCOl record and an INC02 entry for each unit involved. 8 Item #6 September 27, 2016 Page 12 of 35 CAD ,---------------I ' CAD ' ' ' Client ' ' ' Workstations _ -· LAN based File System Environment II,,. -CAD .... NetRMS Server Figure -1. CAD to NetRMS Interface, Logical Data Flows Equipment Interconnection The CAD Server transmits data to the NetRMS CAD Interface via a shared file folder accessible on Customer's network by both systems. There is no physical interconnection between the two systems. The CAD Server shall "drop" files containing the CAD Call for Service information into the shared folder, from which they will be retrieved, processed, and then deleted by the NetRMS CAD Interface process. The exact location of the shared folder is configurable in the NetRMS CAD Interface and is up to Customer to determine. The NetRMS CAD Interface simply requires that the folder be accessible as a Windows NTFS folder and be read/writeable by the CAD Interface software. Functional Description Data exchange between CAD and the NetRMS systems takes place via the creation of an XML file by the CAD server. This XML file will be written into a Windows-based NTFS shared folder. This folder will be located in the LAN environment that can be accessed by CAD and NetRMS. The NetRMS interface components will monitor the designated folder share and will detect the creation of the XML CAD export file. Upon detection, the NetRMS interface components will open the XML file and parse the data into a NetRMS CFS record according the specified field mapping. Upon successful creation of the NetRMS CFS record the CAD created XML incident file will be deleted. The CAD export record can be created upon multiple different conditions on the CAD system. At a minimum, the CAD system must create and forward the XML file as soon as possible when any of the following conditions occurs: • Assignment of a Case Number to a CAD Incident (whether this is the first Case Number or 9 Item #6 September 27, 2016 Page 13 of 35 any subsequently assigned Case Number); note that this also applies to any CAD Incident that is re-opened and has one or more new Case Numbers added to the Incident; • Closure of a CAD Incident previously reported to NetRMS (i.e., where at least one Case Number has been assigned to the Incident); note that this also applies to any CAD Incident that is re-opened and then re-closed, if at any point that Incident had one or more Case Numbers assigned. It is recommended, but not mandatory that the CAD Incident data is also transferred to NetRMS when an Incident already being reported has any change of assigned Units. It is recommended and acceptable, but not required, for all CAD Incidents to be reported to NetRMS, whether or not the Incident is ever assigned any Case Numbers. It is recommended and preferred, but not required, that CAD only send an XML message for a particular Incident when one of the following conditions occurs: • There is a new Case Number assigned to the Incident • The Incident Status is changed to Closed • There is a change of Units assigned to the Incident • ( optionally) A new Incident is created The interface will analyze the CaseNo field in the XML export and if a value is present the system will query the cases table to determine if a case with the same case number exists. If the case number already exists the system will continue with the CFS creation and associate the CFS with the existing case. If the case number does not already exist the system will create a new Case Folder with the provided number and then continue with the CFS creation processes and associate the new CFS with the newly created Case Folder. Multiple Case Numbers may be included for a single incident. For multiple Case Numbers each number will be evaluated separately and a Case Folder created for each. Note: Only one CFS record will be created for calls with multiple reports. The following is a general overview of the processing of an XML file: 1. Retrieve the next available XML file from CAD (in date/time order) 2. Validate the XML and field values 3. If the Call for Service (CFS) incident Identifier does not exist in NetRMS, then create a new CFS record 4. Update the CFS record with the data from the XML (Note~ any previously existing information in the CFS record is completely overwritten with the new data.) 5. If the XML contains one or more Case Numbers, then a. If the Case Number does not exist, then create a new Case folder b. Associate the Case folder with the CFS record 6. If the XML contains one or more INC02 record(s) with Personnel numbers, then for each Personnel record included in the XML 10 Item #6 September 27, 2016 Page 14 of 35 a. If the Personnel record is not already associated to the Case folder, associate the Personnel record to the Case 7. If the XML was processed without errors, commit the changes to the NetRMS database and move the XML file to the "processed" folder (from which it will be automatically deleted after a configurable period of time) 8. If the XML was unable to be processed successfully, discard the NetRMS changes and move the XML to the "failed" folder (Note~ this folder is not automatically monitored or reported. It is Customer's responsibility to inspect this folder if there are indications that any CAD messages failed to arrive at NetRMS.) 11 Item #6 September 27, 2016 Page 15 of 35 CAD Incident XML DATA CAD Incident XML data shall consist of two types of Incident data records, referred to as Incident (INCOl) and Incident Unit (INC02) data records. Each XML file shall consist of one INCOl record, and each INCO 1 record may include zero or more INC02 records ( one INC02 record for each Unit assigned to the Incident). Any field with a "Field Type" of "constant" must be present and must contain the XML tag and field values shown. Any field designated as any other type ( e.g., "int", "varchar xx", etc.) may be omitted entirely if there is no associated value available to provide, or may be included as just the Begin and End Tags ( e.g., "<division></ division>"). Any field designated as "datetime" must contain a valid XML date/time value ("xs:dateTime" type), of the format: yyyy-mm-ddThh:mi:ss (e.g., "2015-09-13Tl5:42;19"). The time component must be in 24-hour format. Any field designated as "varchar" should not include any leading or trailing spaces. Any field designated as "bit" should contain either a "O" or a "l" character ( or no character if the value is not being provided). NOTE -these record formats include many fields which are not used in the NetRMS CAD Interface. The complete field list is included below, and unused fields may be included in the messages, but unused fields will be ignored by the interface if present. In the following record definitions, required fields will be shown in BOLD text, and unused field will be italicized. Fields that are neither Bolded nor Italicized contain additional information that will be recorded in the NetRMS Call For Service records, but are not required to be supplied in every message. Note that some "not required" fields are in fact critical to proper operation, such as the "casenumbers" field, which is required in order cause the NetRMS CAD Interface to automatically open a NetRMS Case and perform officer assignments to the Case. However, these fields may not have data available at all times (such as between initiation of a CAD Incident and subsequent assignment of a Case Number to that Incident), and are thus not mandatory/required in every message. 12 Item #6 September 27, 2016 Page 16 of 35 Incident Data (INC01) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The Incident Data (INCOl) record shall contain the information about the incident, using the fields and XML tags as defined below. rmsiteml constant <?xml version="l.0" ?> rmsitem2 constant <Doc> rmsitem3 constant <HEADER> rmsitem4 constant <MESSAGE TYPE Update </MESSAGETYPEI ID> D> rmsitemS constant <DESTINATION RMS </DESTINATIONN NAME> AME> rmsitem6 constant <P ACKETTYPE> INCOl <IP ACKETTYPE> rmsitem7 constant <MESSAGELOG CurrentTime </MESSAGELOGTI TIME> ME> rmsitem8 constant </HEADER> rmsitem9 constant <ROW> id int Record ID of the <id> response_ master_ </id> response master incident.id incident master incident n varchar Number uniquely <master incident response_ master_ </master incident n - -- ---umber 20 identifies incident number> incident.master i umber> ncident number custom _jur _ number varchar Custom number <custom _jur _ numb CusN </custom _jur _ number 20 generated by interface er> > or incident rim_ custom _jur _ n varchar Custom jurisdiction <prim_ custom _jur _ PrimCN </prim_ custom _jur _ n umber 20 number generated by number> umber> interface response_ date datetime Date incident was <response_ date> response_ master_ </response_ date> created incident.response date - agency_ type var char Agency in which the <agency_ type> response_ master_ i </agency_ type> 30 call was created ncident.agency _ ty pe jurisdiction varchar Jurisdiction of the call <jurisdiction> response_ master _i </jurisdiction> 30 ncident.jurisdiction ** Not Supported** division varchar Division of the call <division> response_ master _i </division> 30 ncident. division battalion varchar Battalion of the call <battalion> response_ master _i </battalion> 30 ncident. battalion beat* varchar Beat Number <beat> Beat number* </beat> 30 sector* var char Beat Number <sector> Beat number* </sector> 30 13 Item #6 September 27, 2016 Page 17 of 35 ,ft~;"' I jW 0: =; f if,ici~ ~1~/z"~-3;,A~"Jf:~"" ": / °' u)< ""~ ; 0 " " 0%0 0 $ 0 0 0 A --0 e 0 A 0 0 00 ~~e;t" =: JllieliilU&e1 "WI 0--~ t~J@ef!JII!S!~iBlttlm 0 " r : "~"!Begim~agip" -Jirira1:ll;lnei:0 . ;Bual fflag: , 0 ] ~~"'-'"* :::*1 -~ ~"' "'_&0:@ 11::":._~i~'lt 1r:"';'0=j d""~ bk\~:::"'}::~ -f fif!vfigJ "":,m2 @! 1 -= $$ ,;= '110 ~ = »~ "",;;; "5'"' ==rrc ~~ *~ " 0 0'. B\@ = 21 station varchar Station code of the <station> station code </station> 30 !Primary unit 22 response_ area varchar Geographical <response_ area> response_ master _i </response_ area> 30 boundary defining ncident. response_ a which units and rea !Personnel are responsible for an incident 23 response _time_ crite date time The mandated <response _time_ cri response _master _i </response _time_ crite ria response time from teria> ncident.response _t ria> dispatch to arrival on-ime criteria - scene 24 response _ylan varchar Plan which specifies <response _ylan> response_ master _i </response _ylan> 30 units VisiCAD should ncident. response _y recommend for an Zan incident 25 incident_ type var char Incident type to which <incident_ type> response_ master_ i </incident_ type> 30 problem nature of ncident.incident_ ty incident belongs pe 26 problem varchar Incident problem <problem> response_ master _i </problem> 30 nature ncident.problem 27 priority_ number int A number representing <priority_ number> response_ master _i </priority_ number> the incident's priority ncident.priority _ nu mber 28 tpriority _ description varchar Description of incident <priority_ descripti response_ master _i <!priority_ description 30 priority on> ncident.priority _ de > scription 29 location name var char Premise location <location name> response_ master_ i </location name> ---50 ncident.location n - ame 30 housenumber varchar Incident address <house_number> response_master _ </house_number> 10 house number incident.house nu mber 31 house number suffi varchar Incident address house <house number suf response_ master_ i </house number suffi ------ X 10 number suffix fix> ncident.house nu x> - mber suffix - 32 prefix_ directional var char Incident address prefix <prefix_ directional response_ master_ i </prefix_ directional> 22 directional > ncident.prefix _ dire ctional 33 name_ component varchar Address street name <name_ component response_ master _i </name_ component> 40 component > ncident.name com -ponent 34 post_ directional var char Incident address post <post_ directional> response_ master _i </post_ directional> 22 directional ncident. post_ direct ional 35 street_type var char Incident street type <street_ type> response_ master_ i </street_type> 15 reference ncident.street_ type 14 Item #6 September 27, 2016 Page 18 of 35 l,4= ~-~~;: ~s£~s % ;""= ,;_""lf'r•% i"" 4; 0"7::0 /0= '° -"~-=y:/; ~:'':: :*~;88 =~~!;~>+~ ::~4~;::~~;,:,,;,;::~~J = «"";:~"~~:7!f;Yff:':wffj;:z:,irJ:;::t,,;J~~ ~~llgjN Bw ilielQ;Re~0 ' r:; !0 ))lJiefqiUesi10iil:1iom* ~0:;: ':iflegin,!lag;:: ~: :::qielitw"l"iilu~" f v~~vlmli<Jmii::0 ~'*'~ ~ % :::~"',,~ ,,;~ ~ *! ;, «/ vvi Sf::: v:11ftq~f; :"''::"'1Vi;Jt::v:':°'~~;/4=,2ffJ%,/:/ ,i °' f,,= ~ =B::~'0;""';; ; "'=V ;:: :sfJt:::JP?f~:~vv:'h~~:#:sf~:"~G~""""" :~~~;:iv:::~::~::JPS= 36 apartment varchar Incident address <apartment> response_ master _i </apartment> 10 apartment ncident.apartment 37 city var char City in which incident <city> response_ master_ i </city> 35 occurred ncident.city 38 state varchar 5 State/province in <state> response_ master _i </state> which incident city is ncident.state located 39 postal code var char Postal code for <postal_ code> response_ master_ i </postal_ code> 10 incident address ncident.postal_ cod e 40 county varchar County in which <county> response_ master _i </county> 30 incident address is ncident. county located 41 location_ type varchar If premise, type of <location_ type> response_ master _i </location_ type> 30 premise (e.g., hospital, ncident. location_ ty school, bank, etc.) tpe 42 longitude int Alphanumeric <longitude> response_ master_ i </longitude> characters indicating ncident.longitude longitude boundaries of degrees minutes and seconds for the address of the incident 43 latitude int Alphanumeric <latitude> response_ master _i </latitude> characters indicating ncident.latitude latitude boundaries of degrees minutes and seconds for the address of the incident 44 map_info varchar Incident address map <map_info> response_ master _i </map _info> JO page and grid ncident.map _info reference (mapbook ** Not Supported lookup) ** 45 cross street varchar Closest cross street to <cross street> response_ master _i </cross street> --80 incident ncident. cross stree - t 46 methodofcallrcvd varchar Way in which <methodofcallrcvd> response_ master _i </methodofcallrcvd> 30 emergency call was ncident.methodofc received ( e.g., 911, allrcvd walk-in, etc.) 47 call_ backyhone varchar Calling party's call <call_ back _yhone> response_ master _i <lcall _ back_yhone> 20 back phone number ncident.call back - phone 48 caller_ type varchar Type of caller (e.g., <caller_ type> response_ master _i </caller_ type> 30 lfamily member, ncident.caller _type doctor, member of the 1,public, etc.) 49 caller name var char Name of calling party <caller name> response_ master_ i </caller name> --30 ncident.caller nam - e 15 Item #6 September 27, 2016 Page 19 of 35 50 caller_location_nam varchar If calling from a e 50 premise such as a hospital, name of the premise 51 caller _address varchar Address of calling 80 party 52 caller_apartment varchar If calling from an 10 apartment, apartment # 53 caller _city varchar City in which calling 35 party is located <caller _location_na me> <caller _address> <caller _apartment> <caller _city> response_master _ </caller _location_na incident.caller _loc me> ation_name response_master _ </caller_address> incident.caller _ad dress response_master _ </caller _apartment> incident.caller _a pa rtment response_master _ </caller_city> incident.caller _city 54 caller state varchar 5 State in which calling <caller state> party is located response_ master_ i </caller_ state> ncident.caller state 55 caller _postal_ code var char Postal code for the 10 address associated with the calling party 56 caller_ county varchar County in which caller 30 is located 57 caller _location _pho varchar Phone at caller's ne 20 address 58 time _phonepickup datetime Timestamp for phone pickup 59 time firstcall datetime Timestamp for first keystroke was entered for the incident 60 time_ callenteredque date time Times tamp for when ue call was saved in waiting incident queue 61 time_ calltakingcom date time lete Timestamp for when call taking was completed 62 time incident under datetime Timestamp for when incident was under control 63 time callclosed datetime Timestamp for when incident was closed <caller _postal_ code response_ master _i </caller _postal_ code> > ncident.caller _post al code <caller _county> response_ master _i </caller_ county> ncident.caller cou nty <caller _location _ph response_ master_ i </caller _location _pho one> ncident.caller loca ne> tion_phone <time _phonepickup response_ master _i </time _phonepickup> > ncident. time _phon epickup <time firstcall> response_ master_ i </time firstcall> ncident.time firstc alltakingkeystroke <time_ callenteredq response_ master _i </time_ callenteredqu ueue> ncident. time calle eue> nteredqueue <time_ calltakingco mplete> response_ master _i </time_ calltakingcom ncident. time call ta lete> kingcomplete <time _incident _und response_ master _i </time incident unde er> ncident.time incid r> ent under control <time call closed> response_ master_ i </time callclosed> ncident.time callcl osed 16 Item #6 September 27, 2016 Page 20 of 35 64 time senttoothercad datetime 65 time first unit assi datetime gned Timestamp for when call transferred to remote CAD, used in CAD2CAD interface Timestamp for when the first unit was assigned to the incident 66 time _first_ unit _enro datetime Timestamp for when ute the first unit was enroute to the incident 67 time first unit arri datetime ved Timestamp for when the first unit arrived at the scene of the incident <time senttootherc response_ master _i </time senttootherca ad> ncident. time sentt d> oothercad <time first unit as response_ master _i </time first unit ass1 signed> ncident.time first gned> unit_ assigned <time _first_ unit_ en response_ master _i </time _first _unit_ enr route> ncident. time _first_ oute> unit enroute <time_ first_ unit_ arr response_ master _i </time first unit arri ived> ncident.time first ved> unit arrived 68 elapsed_callrcvd2in datetime Elapsed time between <elapsed_callrcvd2 response_ master _i <lelapsed _ callrcvd2in ncident. elapsed_ ca queue> llrcvd2inqueue queue when call was inqueue> received and call was saved in the waiting incident queue 69 elapsed_callrcvd2ca datetime Elapsed time between <elapsed_callrcvd2 ltakdone when the call was caltakdone> received and call taking was completed 70 elapsed_inqueue_2_ datetime Elapsed time between 1rst call was saved in the waiting incident queue and the first unit was assigned <elapsed _inqueue _ 2_first> response_ master _i <lelapsed _ callrcvd2c ncident.elapsed_ca altakdone> llrcvd2 caltakdone response_ master _i </elapsed _inqueue _ 2 ncident. elapsed _in _first> queue_ 2 _firstassig n 71 elapsed_ callrcvd2fir datetime stassign Elapsed time between call was received and the first unit was assigned <elapsed_ callrcvd2 response_ master _i <lelapsed _ callrcvd2fi 72 elapsed_ assigned2fi datetime rstenr Elapsed time between call was saved in the waiting incident queue and the first unit went enroute 1rstassign> ncident.elapsed_ca rstassign> llrcvd2firstassign <elapsed_ assigned 2firstenr> response_ master _i </elapsed_ assigned2fi ncident. elapsed_ as rstenr> signed2firstenrout e 73 elapsed_enroute2fir datetime Elapsed time between <elapsed_ enroute2f response_ master _i </elapsed_ enroute2fir stat 1rst unit went enroute and first unit was at scene irstat> ncident.elapsed_en stat> route2firstatscene 74 elapsed_callrcvd2ca datetime Elapsed time between <elapsed_callrcvd2 llclosed when call was callclosed> received and when call was closed 75 calltaking_performe varchar Name of user <calltaking_perfor d_byt 25 performing call taking med_ by> 17 response_ master _i <lelapsed _callrcvd2c ncident. elapsed_ ca all closed> llrcvd2 call closed response_ master _i </calltaking_performe ncident.calltaking_ d _ by> performed_ by Item #6 September 27, 2016 Page 21 of 35 76 callclosing_yerform varchar Name of user who ed_by 25 closed the call 77 calldisposition _yerf varchar Name of user who armed 25 entered call disposition 78 zxed _time _yhonepi datetime ckup Read-only time stamp or time phone was ickedup 79 zxed time callenter datetime Read-only time stamp edqueue or time call entered 80 zxed time calltakin datetime gcomp Read-only time stamp or time call taking was completed 81 zxed time callclose datetime Read-only time stamp d when call was closed <callclosing_yerfor response_ master _i </callclosing_yerform med_by> ncident.callclosing ed_by> ___performed_ by <calf disposition _ye rformed> <fixed _time ___phone ickup> response_ master _i </calldisposition _yerf ncident.calldisposi armed> tion _ye1formed _ by response_ master _i </fixed _time _yhonepi ncident.fixed_time ckup> _yhonepickup <fixed _time_ callent response_ master _i </fixed _time_ callente eredqueue> ncident.fixed_time redqueue> _callenteredqueue <fixed _time_ calltak response_ master _i </fixed _time_ calltaki ingcomp> ncident.fixed_time ngcomp> _ calltakingcomplet e <fixed _time_ callclo response_ master _i </fixed _time_ callclos sed> ncident.fixed_time ed> call closed 82 zxed time senttoot datetime Read-only time stamp <fixed _time _sentto response_ master _i </fixed _time _senttoot hercad when call was othercad> ncident.fixed _time hercad> 83 emd used 84 cis used 85 determinant 86 roqa _ casenumber 87 senttobilling_jlag 88 ani number 89 ali_info int int varchar JO varchar JO bit varchar 20 varchar 50 transferred to remote senttoothercad CAD Incident ProQA <emd used> reference, indicated PROQA was used for call Incident protocol <cis used> reference, indicates VisiCAD protocol was used for call Incident's PROQA <determinant> determinant Incident's PROQA <proqa _ casenumbe case number r> Incident sent to billing <senttobilling_jlag ag > Incident automatic <ani number> number identification information Incident ALI <ali_info> (automatic location information) 18 response_ master _i </emd used> ncident.emd used response_ master _i <leis used> ncident.cis used response_ master _i </determinant> ncident. determinan response_ master _i <lproqa _ casenumber ncident.proqa _ cas > enumber response_ master _i <lsenttobilling_jlag> ncident.senttobillin g_jlag response_ master _i <Jani number> ncident.ani numbe r response_ master _i </ali_info> ncident. ali _info Item #6 September 27, 2016 Page 22 of 35 varchar 30 channel Primary tactical channel for radio communication on the incident 92 alternate tac chann varchar Alternate to primary el 30 TAC channel 93 call_ disposition varchar Disposition by which 30 call was closed 94 cancel reason varchar Reason why call is 30 cancelled 95 late_flag varchar Flag to indicate if call 1 was late and response time criteria was not met 96 whichqueue varchar Indicator for which 1 VisiCAD queue incident is currently 97 confirmation_ numb varchar Confirmation number er 20 or patient transport 98 building varchar Building in which 10 incident occurred 99 caller_ building varchar Building from which 10 calling party is making the call 100 certification _level varchar Incident certification 10 level 101 base _response_ num varchar Response number for ber 20 zrst unit assigned to incident 102 call is active int Flag to indicate if call is active 103 call source var char Where call originated 30 ( e.g., doctors office, public phone, etc.) 104 multi _patients int Indicates multiple patients for a transport response_ master _i ncident.command > channel <primary _tac_ chan response_ master _i </primary _tac_ chann nel> ncident.primary _ta el> c channel <alternate tac cha response_ master _i </alternate _tac_ chan nnel> ncident.alternate t nel> ac channel <call_ disposition> response_ master _i </call_ disposition> ncident.call_ dispos ition <cancel reason> response_ master _i </cancel reason> ncident. cancel rea son <late _flag> response_ master _i </late _flag> ncident. late _flag <whichqueue> response_ master _i <lwhichqueue> ncident. whichqueu e <confirmation_ num response_ master _i </confirmation_ numb her> ncident. confirmati er> on number <building> response_ master _i </building> ncident. building <caller _building> response_ master _i </caller _building> ncident.caller buil ding <certification _level response_ master _i </certification _level> > ncident. certificatio n level <base _response_ nu response_ master _i </base _response_ num mber> ncident. base _respo ber> nse number <call is active> response_ master _i </call is active> ncident.call is act ive <call source> response_ master _i </call source> ncident.call source <multi _patients> response_ master _i </multi _patients> ncident.multi _patie nts 19 Item #6 September 27, 2016 Page 23 of 35 105 call_ back _phone_ ex varchar Extension number of <call_ back _phone_ response_ master _i </call_ back _phone_ e t 9 call-back phone ext> ncident. call back xt> number 106 num aniali calls int Count of duplicate <num aniali calls response_ master _i </num aniali calls> - - ANIALI calls received > ncident.num aniali calls 107 delay _reason varchar Reason entered for <delay _reason> response_ master _i </delay _reason> 30 why unit is delayed ncident.delay _reas on 108 remiseid varchar Premise location code <premiseid> response_ master _i </premiseid> 30 ncident.premiseid 109 casenumbers** function Case numbers for the <casenumberlist> delimiter: </casenumberlist> incident. Please note <casenumber> there could be multiple case numbers for a single incident. 110 responsecomments Start oflncident <commentlist> comments. Please note there could be multiple comments for a single incident. Individual comment <comment> Comment text </comment> within the list End oflncident </commentlist> comments. 111 ackid pass-m <ackid> Passin: AckID </ackid> 112 unit_ assignment pass-in Placeholder within <units_ assigned> INC02 records </units _assigned> INCOl message to build INC02 structure 113 row end constant </ROW> 114 docend constant </Doc> * Beat_Number -The Beat Number must exactly match a Beat defined in NetRMS. Note that Beat numbers may have leading zeroes, in which case the the leading zeroes must be included in this field. Beat "01" is not the same as Beat "1 ". For historical reasons, the Beat should be included in both the "Beat" and "Sector" fields to ensure proper processing. ** Case Numbers -Case Numbers must be exactly as they are to be entered/referenced in the ARJ/5 system. There is no re- formatting of Case Numbers in NetRMS. If a Case Number is received from CAD as "15-00012345", it will be used throughout NetRMS and be transmitted to ARJ/5 as "15-00012345". t "calltaking_performed_by" -if present, this must contain a valid NetRMS Personnel No value from the Personnel table. This is similar to the "emp_id" field in the INC02 record. 20 Item #6 September 27, 2016 Page 24 of 35 Unit Data (INC02) An INC02 record will be included for each Unit assigned to the incident. ] jurisdiction pass-in <jurisdiction> CusNuml </jurisdiction> ** Not Supported ** : custom _jur _ nu varchar Unit's jurisdiction number <custom _jur _ num response_ master _inci </custom _jur _ num mber 20 her> dent.master incident her> ~ radio name --varchar Unit's radio call sign JO <radio name> number response_vehicles_ass </radio name> igned. radio_ name L1 time_ assigned date time Times tamp for when unit was assigned <time_ assigned> response _vehicles_ ass </time_ assigned> igned. time_ assigned : date_ assigned datetime Timestamp for date unit was <date_ assigned> assigned E time_ enroute datetime Timestamp for when unit went enroute <time enroute> ' date enroute datetime Timestamp for date unit went <date enroute> enroute E time_ arrivedat datetime Timestamp for when the unit <time_ arrivedatsc scene arrived at scene ene> S date_arrivedat datetime Date of when the unit scene arrived at scene 1 ( time time con datetime Time unit made patient tact contact 11 date time con datetime Date unit made patient tact contact 1: time_ depart _s date time Times tamp for when unit 1: IL 1: cene departed scene of the incident date_ depart _s datetime Date unit departed the scene cene of the incident time _staged datetime Timestamp for time unit was staged at the incident date _staged datetime Date when unit was staged at the incident <date arrivedatsc ene> <time time conta --ct> <date time conta ct> <time_ depart _see ne> <date_ depart _see ne> <time _staged> <date _staged> 21 (hh:mm:ss) response_ vehicles_ ass </date_ assigned> igned.time _ assigned (mm/dd/yy) response_ vehicles_ ass </time enroute> igned. time_ enroute (hh:mm:ss) response _vehicles_ ass </date enroute> igned. time_ enroute (mm/dd/yy) response_ vehicles_ ass </time arrivedatsc igned. time_ arrivedats ene> cene (hh:mm:ss) response _vehicles_ ass </date arrivedatsc igned. time_ arrivedats ene> cene (mm/dd/yy) response_ vehicles_ ass </time time cont a igned. time_ contact ct> (hh:mm:ss) response_ vehicles_ ass </date time conta igned. time_ contact ct> (mm/ddlyy) response _transports. ti </time_ depart _see me_depart_scene ne> (hh:mm:ss) response _transports. ti </date_ depart _sce me_depart_scene ne> (mm/dd/yy) response_ vehicles_ ass </time _staged> igned. time _staged (hh:mm:ss) response_ vehicles_ ass </date _staged> igned. time _staged (mm/dd/yy) Item #6 September 27, 2016 Page 25 of 35 estination Timestamp for when unit arrived at transport destination response _transports. ti </time_ arrive_ dest me arrive destination ination> - - (hh:mm:ss) 1 date arrive d date time Date when unit for when unit <date_ arrive_ dest response _transports. ti </date_ arrive_ dest estination arrived at destination ination> me arrive destination ination> (mm/ddlyy) 1 time time del datetime ayed _ availabil ity 1 date time de! datetime ayed _ availabil ity Timestamp for when unit went to delayed available status Timestamp for the date the unit went to delayed available status 2 time call clea datetime Time unit cleared call red 2 datetime Date unit cleared call 2 odometer enr oat Odometer value of vehicle enroute to scene 2 odometer atsc oat Odometer value of vehicle at ene scene 2 odometer bac oat Odometer value of vehicle in kinqtrs quarters 2 number_ of_ vie int Number of patients seen tims seen 2 primaryunit* * bit Flag indicating if unit is primary unit assigned to incident 2 officers start constant 2 emp_id* varchar Personnel ID of officer 30 assigned to the vehicle 2 officers end constant 3 pass-m 3 id int <time _time_ delay ed _ availability> <date _time_ delay ed _ availability> <time call cleare d> <date call cleare d> <odometer enrout e> <odometer atscen e> <odometer backin qtrs> <number _of_victi ms seen> <primaryunitflag> <officers> <emp_id> <ackid> <master incident id> - response_ vehicles_ ass </time _time_ delay igned. time_ delayed_ a ed _ availability> vailability (hh:mm:ss) response_ vehicles_ ass </date _time_ delay igned.time _delayed_ a ed _availability> vailability (mm/dd/yy) response_ vehicles_ ass </time_ call_ cleare igned. time_ call_ clear d> ed (hh:mm:ss) response_ vehicles_ ass </date_ call_ cleare igned. time_ call_ clear d> ed (mm/dd/yy) response_ vehicles_ ass </odometer enrou igned. odometer_ enrou te> te response_ vehicles_ ass </odometer atscen igned.odometer _atsce e> ne response_ vehicles_ ass </odometer backi igned. odometer_ backi nqtrs> nqtrs response_ vehicles_ ass </number _of_victi igned.number _ of_ vie ti ms seen> ms seen response_ vehicles_ ass </primaryuni tflag> igned.primaryvehiclef lag NetRMS </emp_id> PersonnelNo value from the Personnel table* </officers> AckID </ackid> response_ vehicles_ as </master incident signed.master _incide id> nt id * The 11emp_id" field must contain a string that must exactly match the assigned PersonnelNo value in the NetRMS 22 Item #6 September 27, 2016 Page 26 of 35 Personnel table for the assigned officer. This is typically a combination of an agency prefix and a 4-digit ARJIS identifier, such as "EC1234", "SH0443", etc. If no match is found, the officer specified in the record will not be assigned to the Case by the Interface. ** If no "primaryunit" field is received with a "1" value, the first officer in an INC02 record will be assigned as the primary officer in NetRMS. CAD Incident to NetRMS CFS Record Data Mapping ' C lla'a~e; 0 Wame 0 0 Call For Service The following table defines the data mapping between the CAD incident record XML data and its corresponding NetRMS data field. The "Seq Ref' and "CAD Field Value" column entries refer back to the corresponding numbered fields in the INCOI and INC02 record definitions above. All other fields in the NetRMS VI .94 San Diego Build CFS DM should default to empty values and not be required entries. 0 -- _ ~iia ~ieW:iaE:!ep -: i][atalei !lame ~ --'-CeltllmE'ii ~ Se!!t , C~l1DHiftrer€1 ~allile -~ama: ' / s0 ;y'* ;,, -: Rel 0 --------/ --,'l ' / / ' / 0 0 -0/ -~ - Event ID CFS CFS No 11 master_incident_number Received CFS Received 59 time_firstcall Dispatched 65 time_first_unit_assigned Arrived CFS Arrived 67 time first unit arrived -- - Cleared CFS Cleared 63 time call closed Event Created CFS CFS Date 14 response_date Dispatcher CFS DispatcherlD 75 calltaking_performed_by Source CASO CFS CallSource 103 call source Location CFS Location location_name -- 0 - CASD_CFS StreetNumber 30/ house_number I house_number_suffix 31 StreetDirection 32 prefix_directional StreetName 33 name_component StreetD i rection Su 34 post_ directional ffix StreetType 35 street_ type 23 -,_ - 0 Item #6 September 27, 2016 Page 27 of 35 CASO CFS City Code CASD_CFS csz CFS Grid Beat Jurisdiction Jurisdiction Map Coordinate X Coordinate Y Longitude CASD_CFS Latitude CASD_CFS Reporting Party CFS Address CFS csz CFS csz CFS csz CFS Phone CFS Call Type CASO CFS Event Type Reported Offense CFS Verified Offense Disposition CASD_CFS 24 apartment CommonPlaceNa me CityCode City State Zip Grid Sector jurisdiction Map xCoord yCoord longitude latitude Contact ContactAdd ress ContactCity ContactState ContactZip ContactPhone CallType EventType ReportedOffense CID Offense CFSDisposition 36 response_ master _incident_ apartment 29 location name city 37 City 38 State 39 Postal_code 19 20 Beat 16 jurisdiction 42 longitude 43 latitude 49 caller name 50-Caller_location_name; caller_address, 52 caller_ apartment 53 caller_city 54 caller_state 55 caller_postal_code 57 caller_location_phone 46 methodofcallrcvd 25 incident_type 93 call_disposition Item #6 September 27, 2016 Page 28 of 35 Subject Information Notes Priority CASO CFS Priority 27 priority_number Classification Classification CID Vehicle Vehicle Vehicle License Vehiclelicense Tow Company TowCompany Agency Agency agency_type 15 agency_type Controlling Organization ID Organization Cases CASD_CFSCa Case ID 109 CaseNumber ses Deputies Officers Officers Officer emp_id 28 emp_id Name FullName Address Address csz csz Notes Notes Commentslist 110 Comment Note: Data from CAD will include all Units/Personnel referenced to the incident. In addition an indicator will be required to denote the primary unit of the incident Business Rule: Only Call/Incidents containing Case Numbers will result in a NetRMS Case folder being created and/or officers assigned to the Case associated to the Incident. Calls received without a Case Number will be recorded in the Call For Service (CFS) table, but will not generate any Case folders or Case assignments. Business Rule: The Report Number format/mask will be accepted by NetRMS as received in the XML file. Changes in the mask, sequence, and/or format of the number are outside the scope of this interface. Business Rule: The interface will analyze each CaseNo provided in the XML export and determine if a Case with the same case number exists within NetRMS. If the case number already exists, the system will continue with the CFS creation and associate the CFS with the existing case. If the case number does not already exist, the system will create a new Case Folder with the provided number and then continue with the CFS creation processes and associate the new CFS with the newly created Case Folder 25 Item #6 September 27, 2016 Page 29 of 35 Business Rule: For multiple Case Numbers included with an Incident/Call, each Case Number will be evaluated separately and a Case Folder created or linked as determined by the evaluation. Case identifiers associated with a given call are stored in CASD CFSCases. Business Rule: For incidents with multiple units involved an INC02 record will be embedded in the INCOl record for each involved unit. Business Rule: All Officers associated with Units (INC02 Records) will be validated against the Personnel Table ofNetRMS and entered into the Officer grid within the CFS DM ofNetRMS. Business Rule: Call data received in the XML file for existing CFS records will be considered an update to the CFS record. All previously received CFS information will be overwritten with the updated call data. Note: Previously created case Folders will be updated as necessary with the updated call data. E Performance The following performance specifications apply as noted in two different conditions: Normal Operation (no "backlog", Interface is running, processing CAD Incidents as they arrive from CAD) When in normal operational mode, incoming CFS messages from CAD should be processed within 1-2 minutes of the completed delivery to the NetRMS Interface. As long as there is no pre-existing "backlog" of records, no incoming CFS message should take more than 5 minutes to be completely processed by the Interface. "Processed" means that the NetRMS CFS record(s) have been created and/or updated, any NetRMS Case Folders have been created for any Case numbers contained in the CAD CFS records, and any associated Officers in the CFS records have been assigned to the Case in NetRMS. Interface Service Restart after outage The NetRMS Interface may experience "outages". These may be caused intentionally (planned system outages or upgrades), or be the result of system, application, or even Interface error conditions. When the NetRMS Interface is restarted after an outage of any duration, or initially started, there may be CAD CFS messages awaiting processing by the Interface. To ensure that no information is lost, these messages must be processed in the order in which they were delivered by the CAD system. This is considered a CFS "backlog". Processing the "backlog" can take several seconds per message, up to 30 seconds each, depending on the content of the messages. Further, the size of the backlog is entirely dependent on how many CAD CFS messages have been forwarded from the CAD system and the arrival of additional messages while the Interface is processing the backlog. Therefore, the time before the "backlog" is fully processed and normal operations resume cannot reasonably be predicted. 26 Item #6 September 27, 2016 Page 30 of 35 While a "backlog" is being processed, incoming CAD CFS messages will stack up in the backlog and cannot be processed until all records preceding the new messages have been processed. Thus, Case Folder creations and Officer assignment record creations will be delayed. Note: All Performance information above is contingent on all incoming CAD CFS messages being fully compliant with the Interface specification. If any CAD CFS messages are received that are malformed or contain data inconsistent with the specification, processing of those messages and any subsequent messages may be delayed and/or interrupted as a result. Also, should CAD send excessive numbers of messages (i.e., more than one message per CAD operator action), and these excessive messages continue for any significant time period, this could artificially create a "backlog" and result in delayed processing of the messages. Monitoring Security Normal monitoring of the CAD to NetRMS interface is the responsibility of Agency. This would include monitoring that the CAD system is forwarding information to the NetRMS system and that the N etRMS CAD interface is operational. There are no notifications associated with the interface. If the interface shuts down, or is terminated, there are no notifications generated. It is the responsibility of Agency to implement any automated detection of interface status and/or notifications. In particular, any XML messages received from CAD that cannot be successfully processed are automatically moved from the incoming shared folder to an error folder. There are no automated notices should this occur. It is Customer's responsibility to monitor this folder, either manually or with some automated detection system. E Testing of the CAD to NetRMS interface requires the entry of sample incidents into CAD and the verification that the incident information is transferred correctly to NetRMS This test plan may be revised prior to final signoff. 1. Verify assignable roles of Create; Delete; View; Edit and Search for Call for Service Records. Navigation 1. Verify Navigation links from Lobby under Operations/Uniform Patrol Division to the Call for Service data view. Call for Service Record Transfer from CAD 1. Enter an incident on CAD. Make sure that all applicable fields that are mapped to 27 Item #6 September 27, 2016 Page 31 of 35 NetRMS as identified in Section 4.3.5 (Data Mapping) are completed in the incident record. 2. Add a Case Number to the Open Call 3. Navigate to the CFS (Call For Service) data view in NetRMS 4. Verify the main CFS data view opens properly. Select the "All Calls for Service" data view 5. Verify that the CFS record previously entered on CAD is visible in the data view. 6. Open the CFS record previously entered on CAD. Tab through fields to verify that all CFS parameters identified in Section 4.3.5 are in the CFS record and are identical to the parameters entered on the original incident record in CAD. Close the NetRMS CFS record. 7. From the CFS Data View verify the Case Number(s) are visible. 8. Select a Case Number and verify the link to the Case Folder. 9. Verify the Case Folder information is correctly populated based on the CFS data. 10. Close the incident record on the CAD system. 11. Navigate to the CFS data view in NetRMS. 12. Select the "All Calls for Service" data view 13. Verify that the CFS record previously entered on CAD is visible in the data view. 14. Open the CFS record previously entered on CAD. Tab through fields to verify that all CFS parameters identified in Section 4.3.5 are in the CFS record have been updated based on the updated (Closed) call received from CAD. Close the NetR._\1S CFS record. 15. Repeat Steps 7 - 9 for Case Number I Case Folder verification. The following Notes are applicable to the interface. 1. If the CAD interface is capable of sending multiple Cases for a single CAD incident (i.e., multiple Case Numbers issued against a single Call-for-Service), as each Case Number is issued, the CAD system must insert a text line in the incident Comments that identifies the added Case Number. The text line must contain at least the two following text fragments in the sequence shown, which must occur on the same line (i.e., not be interrupted by a carriage return, line feed, or other end of line/end of field character): • "Case Number" • "<CaseNumber>" -e.g. "13001234" 28 Item #6 September 27, 2016 Page 32 of 35 The fragments must each be preceded and followed by at least one space character, and/or must begin or end the text line. Fragments are not case sensitive. Examples of acceptable format strings are: • "Case Number 13001234 issued on incident 130012223" • "Issued CASE NUMBER to Unit 1A12 -13001234" • "CAD Incident 13-0020035, Dispatcher 1B32 Attached Case Number -13012345 to unit 1A12" 2. Beat number strings must exactly match the Beat numbers as entered in NetRMS. If Beats are entered in NetRMS with leading zeroes, the Beat numbers passed from CAD must contain the same leading zeroes. Beat "012" is not the same as Beat "12", and Beat "A 15" is different from Beat "AO 15". 3. Agency Personnel identified in messages ( officers and dispatchers) must be defined in the NetRMS Personnel database table, and the Personnel identifier value sent in the XML from CAD must exactly match the PersonnelNo in the NetRMS Personnel table. These fields are the "Emp _ ID" and "DispatcherID" fields in the XML. Any prefixes/suffixes used in the NetRMS Personnel table must be included in the field as sent from CAD (i.e., if the Personnel table has "LM1234" in the PersonnelNo field, the CAD system must send "LM1234" in the DispatcherID and/or Emp _ ID fields in order for the records to be properly linked to users. 4. Map information and Jurisdiction fields are not supported from non-Motorola CAD systems. These fields expect special contents only provided in a Motorola CAD/Records suite. H ENTS Sample export XML file (Copy file and paste onto local hard drive to open.) NetRMS 10091213442 6.46.xml 29 Item #6 September 27, 2016 Page 33 of 35 ACTION BY UNANIMOUS WRITTEN CONSENT OF THE BOARD OF DIRECTORS OF TRITE CH SOFTWARE SYSTEMS The Undersigned, constituting all of the members of the Board of Directors ofTriTech Software Systems, a California corporation (the "Corporation"), pursuant to Section 307(b) of the California Corporations Code, hereby adopt by unanimous written consent, the resolution attached hereto as Annex 1. This Action by Unanimous Written Consent may be signed via facsimile and/or in one or more counterparts, each of which shall be deemed an original, and all of which shall constitute one instrument. This Action by Unanimous Written Consent shall be filed with the minutes of the proceedings of the Board of Directors of the Company. IN WITNESS WHEREOF, the undersigned have executed this Action by Unanimous Written Consent effective as of February 24, 2016. Chris Mal~J ey Chairman Tony Eales Director Blake Clark Director Page I of2 Item #6 September 27, 2016 Page 34 of 35 ANNEXl RESOLUTION OF THE BOARD OF DIRECTORS OF TRITECH SOFTWARE SYSTEMS SIGNATURE AUTHORITY WHEREAS, TriTech Software Systems, a California Corporation (the "Corporation") prepares and submits written proposal documents for the sale and license of its products and services in accordance with formal procurement procedures required by prospective clients and exiting clients; and WHEREAS, the Board of Directors (the "Board") of the Corporation desires to clarify and document the signature authority of certain executive officers for the limited purpose of signing said proposal documents and resulting sales contracts. NOW, THEREFORE, BE IT RESOLVED THAT, the Board authorizes and grants signature authority to Tony Eal es, President and Chief Executive Officer, or in his absence, Blake Clark, Chief Financial Officer, limited to the submission of proposal documents prepared in response to Requests for Proposal (RFP), Requests for Tender (RFT), Requests for Quotation (RFQ), or Requests for Information (RFI); and the resulting client contract related thereto entered into by the Corporation; and RESOLVED FURTHER, that the officers of the Corporation be, and each of them hereby is, authorized and directed, for and on behalf of the Corporation to take such further action and execute such additional documents as each may deem necessary or appropriate to carry out the foregoing resolution. Page 2 of2 Blake Clark Secretary Date I / Item #6 September 27, 2016 Page 35 of 35 MASTER SUPPORT AGREEMENT This IVIaster Support Agreement (this "Agreement") is entered into this day of Decei^er2014, but effective as of July 1, 2014 (the "Effective Date"), by and between the City of Carlsbad, a municipal corporation (the "Client") and Tiburon, Inc., a Virginia corporation having its primary place of business at 3000 Executive Parkway, Suite 500, San Ramon, California 94583 ("Tiburon"). WHEREAS, the Client has determined that it desires to obtain from Tiburon certain support services relating to a computer automated system previously implemented by Tiburon for the Client; and WHEREAS, Tiburon is qualified to provide the support services specified in this Agreement and, subject to the terms and conditions set forth in this Agreement, Tiburon desires to provide such support services; NOW THEREFORE, in consideration of the mutual covenants contained herein, the Client and Tiburon hereby agree as follows: 1. Definitions Capitalized terms used herein and in any exhibit hereto shall have the definitions set forth on Exhibit 1 attached hereto and incorporated herein by this reference, unless otherwise defined herein. 2. Scope of Work 2.1. Basic Support. Subject to the terms and conditions set forth in this Agreement, Tiburon shall provide the following support for the Covered Applications ("Basic Support"). (a) Application Errors. Tiburon will correct Errors in any of the Covered Applications discovered by the Client during the term of this Agreement, provided (a) the Client provides all information regarding such Error that may be requested by Tiburon in accordance with Section 5.1 hereof (Technical Service Requests], (b) such Error is reproduced by the Client in accordance with Section 5.13 hereof (Error Reproduction), and (c) the Client has provided Tiburon with remote access to the System as required under Section 5.2 hereof (Remote Access). (b) Client Support Center (CSC). Tiburon will provide toll-free telephone support for operational and technical assistance. Support for Priority 1 Calls relating to Tiburon's Computer Aided Dispatch (CAD) software applications, Corrections Management (JailRECORDS, Premier IMS, JMS and CorrMedica) software applications. Mobile Dispatch (MobileCOM) software applications. Message Switch System (MSS) software applications and any critical interfaces to those systems shall be available twenty four hours a day, seven days a week (24x7). Support for all other calls and other Tiburon applications will be available during Tiburon's normal support hours of 8:00 a.m. to 5:30 p.m. local time in the Client's time zone (not including weekends and Tiburon holidays). Tiburon reserves the right to charge reasonable call-out fees for any call received other than during Tiburon's normal support hours. Support will be provided in accordance with the attached Warranty and Maintenance Guidelines, which are attached hereto and incorporated herein as Exhibit 7. (c) Status Reports. Tiburon will provide the Client with a monthly status report (a "Monthly Status Report"). Each Status Report will include a summary of site activity and a summary of requests by the Client for technical services delivered in accordance with Section 5.1 hereof (Technical Service Requests). Each Monthly Status Report will be delivered to the Client in accordance with the notice provisions set forth in Section 25 hereof (Notices). (d) Back-Ups. Subject to the Client's obligations under Section 5.4 hereof Page 1 of 16 Master Support Agreement (Maintenance and Back-Ups), Tiburon will support the Client in maintaining and/or updating the Back Up Schedule and Procedures, attached hereto as Exhibit 6. (e) NCIC, NIBRS/UCR, and NFIRS Updates. Tiburon will provide updates to the Covered Applications for Client use and installation in response to legal requirements mandated by the National Crime Information Center (NCIC), the National Incident Based Reporting System/Uniform Crime Reporting (NIBRS/UCR), and the National Fire Incident Reporting System (NFIRS) when such requirements necessitate modification(s) to the Source Code relating to any Covered Application and are necessary for the proper performance of the Covered Application. Any other changes, including but not limited to, those mandated or offered by any state, county, city or municipal governmental entity, as weli as changes to any Protocols are outside the scope of this Agreement. (f) Operations Review. So long as the Client's annual fees for the Tiburon Applications hereunder exceed Seventy Five Thousand Dollars ($75,000) in the aggregate, Tiburon will be available to visit the Clients facilities at least once every three (3) years to meet with management, operations and other Client personnel to conduct an operations review of the Covered Applications and the System and an analysis of the Clients automation requirements. A report will be produced to include observations and recommendations regarding the Client's use of the Covered Applications and the System. Tiburon will work with the Client to document this review in the form of a multi-year automation plan. 2.2. Support Options. In addition to Basic Support, the Client may purchase support options as may be available from time to time. The terms and conditions for each Support Option shall be set forth in a separate exhibit which, upon payment of the required annual fee for such Support Option, shall automatically become part of this Agreement and shall be subject to the terms hereof. The Client may discontinue any Support Option by providing Tiburon at least ninety (90) calendar days prior written notice identifying the Support Option to be discontinued; provided, however, that such discontinuance shall not be effective until the next occurring Payment Date. 2.3. Enhancements. From time to time, the Client may request Tiburon to provide under this Agreement services and materials to furnish, install and implement an Enhancement. The installation and implementation of such Enhancement shall be provided on a fixed-price basis. No Enhancement shall be provided under this Agreement unless (a) this Agreement is amended as necessary or appropriate to incorporate the Enhancement Terms relating to the Enhancement; (b) the Enhancement Terms are attached to this Agreement as a new exhibit and, except as specifically set forth therein, are subject to the terms of this Agreement; (c) the Enhancement Terms include terms regarding final acceptance of the Enhancement; (d) the Enhancement Terms provide that, upon final acceptance of the Enhancement, Exhibit 2 to this Agreement shall be amended to incorporate the Enhancement as a Covered Application subject to the Client's payment of any necessary additional support fees relating to the Enhancement; and (e) the Enhancement Terms provide that, upon final acceptance of such Enhancement, the Software License Agreement shall be considered amended as necessary or appropriate to grant to the Client the appropriate rights to use the Enhancement, subject to payment in full of all amounts due under the Enhancement Terms. 2.4. Out of Scope Services. From time to time, the Client may request Tiburon to provide under this Agreement certain Out of Scope Services. Tiburon shall be under no firm obligation to perform any Out of Scope Services, but shall undertake to make a good faith effort to perform such services to the extent that it is capable of doing so without substantially interfering with its other obligations under this Agreement or with its obligations to its other clients. Any Out of Scope Services shall be provided, at Tiburon's option, on a fixed-quote basis with payment milestones or on a time and material basis at Tiburon's then current technical service rates plus all related travel, per diem and other expenses invoiced as incurred. No Out of Scope Services shall be provided under this Agreement unless: (a) this Agreement is amended as necessary or appropriate to incorporate the terms relating to the Out of Scope Services; (b) those terms are attached to this Agreement as a new exhibit and, except as specifically set forth therein, are subject to the terms of this Agreement; and, (c) those terms include agreed-to criteria regarding completion of the work, if applicable. Page 2 of 16 Master Support Agreement 3. Term The term of this Agreement shall commence on the Effective Date and shall continue in effect for a period of 1 year, subject to the annual appropriation of funds by the City Council, which shall automatically renew for additional one (1) year periods upon appropriation of funds by the City Council. Client agrees to notify Tiburon in writing prior to the start of any subsequent renewal term if the City Council has failed to appropriate funds for the following renewal period. Additionally, Tiburon agrees to provide Client with the annual support pricing at least ninety (90) days prior to the start ofthe following annual maintenance period, to sign and return agreed upon annual amendments within 10 business days, and invoice Client at least 30 days in advance of the agreed upon renewal date provided City Council has apportioned funds for the annual renewal at least forty-five (45) days prior to the renewal date. In the event that Tiburon fails to provide the required annual support pricing and/or the required invoice pursuant to the expressed provisions of this section. Client may terminate this Agreement in accordance with Section 13 below. 4. Fees and Payment 4.1. Annual Support Fees (a) Basic Support. The Client shall pay an annual fee for Basic Support for each of the Covered Applications. The amount of such annual fee shall be set forth on Exhit)it 2 attached hereto and incorporated herein by this reference and shall be paid in advance on or prior to the expiration of any Warranty Period applicable to such Covered Application and, thereafter, on each Payment Date during the term of this Agreement. (b) Support Options. The Client shall pay an annual fee for any requested Support Options. The amount of such annual fee shall be set forth on the exhibit pertaining to such Additional Support Option and shall be paid on or prior to the commencement of any services relating to such Additional Support Option and, thereafter, on each Payment Date during the term of this Agreement unless such Additional Support Option has been discontinued in accordance with Section 2.2 hereof (Support Options). (c) Enhancements and Out of Scope Services. Payment shall be as stated in the applicable Enhancement/Out of Scope Services proposal. 4.2. Annual Adjustments. The fees payable pursuant to Section 4.1(a) and Section 4.1(b) hereof (Annual Support Fees) may be increased on an annual basis by no more than five percent (5%) upon at least ninety (90) days prior written notice to the Client. Such increase shall become effective on the next occurring Payment Date. 4.3. Invoices. Invoices pursuant to Section 4.1 hereof shall be payable on or prior to each Payment Date during the term of this Agreement or shall be payable within thirty (30) days of receipt unless otherwise specifically provided. 4.4. Consequences of Late Payment. Failure to make timely payments when owed shall result in interest accruing at the rate of one and one-half percent (1.5%) the total non-disputed invoice amount per month for each month the payment is past due, or such amount as allowed by law, whichever is less. Failure to pay any amount owing on a non-disputed invoice hereunder when such amount is due shall constitute a material default under this Agreement and may result in the termination, or at Tiburon's discretion suspension, of this Agreement in all or part. The Client shall reimburse Tiburon for all collection fees, including reasonable attorneys' fees and expenses, incurred by Tiburon in connection with the collection of any amount owing hereunder. Tiburon will not invoice Client until the City Council has appropriated the annual funds for renewal of this Agreement. Page 3 of 16 Master Support Agreement 7 5. Client Responsibilities 5.1. Technical Service Request. The Client shall provide all information requested by Tiburon necessary to complete its Technical Service Request form for each request for technical services. Enhancements, and Out of Scope Services. 5.2. Remote Access. Client will provide high-speed VPN remote access to approved Tiburon employees according to the then current CJIS policy. Tiburon shall not be responsible for any costs relating to the procurement, installation, maintenance and use of such equipment and all associated telephone use charges. Tiburon shall use the data connection solely in connection with the provision of its services hereunder. The Client may be required to run tests deemed necessary by Tiburon following each remote access as requested by Tiburon. 5.3. Physical Access. When necessary, the Client will provide Tiburon employees escorted physical access to the System. After normal business hours, the Client shall ensure that one of the Technical Support Coordinators designated under Section 5.11 hereof (Technical Support Coordinators) can be reached by phone or pager to (a) provide physical access to the System within two (2) hours of Tiburon's request for such access, and (b) remain on-site until Tiburon determines that there is no longer a need for physical access. 5.4. Maintenance and Back-Ups. The Client shall take reasonable steps to ensure that maintenance and back-up activities relating to the Covered Applications and the System, including without limitation backing up databases and journal logs, purging out of date records and running reports and performing diagnostics, are carried out in accordance with the schedule and methodology specified in Exhibit 6 (Back Up Schedule and Procedures) attached hereto and incorporated herein by this reference. 5.5. Data Input. The Client shall enter, update and maintain the input data as required for satisfactory operation of the Covered Applications, and be responsible for the accuracy of all Client-provided data. 5.6. Third-Party Product Support. The Client shall obtain, pay for and maintain in effect during the term of this Agreement the technical support contracts for certain Third-Party Products as specified on Exhibit 4 attached hereto and incorporated herein by this reference, and shall ensure that, in addition to authorizing the Client to request support services there under, each such support contract also expressly authorizes Tiburon to request support services there under on the Client's behalf. 5.7. System Security. The Client shall ensure that the security of the System conforms in ail respects to the federal, state, and/or local mandated law enforcement telecommunications requirements. 5.8. System Change, Alteration, or Modification. The Client shall ensure that, with respect to each Covered Application, such Covered Application is installed only on the Authorized Server and only at the Authorized Site. The Client shall ensure that each Authorized Site conforms in all respects to the Site Specifications set forth on Exhibit 5 attached hereto and incorporated herein by this reference (the "Site, System and Network Specifications"). The Client shall ensure that no change, alteration or modification is made to the System Configuration, including IP addresses ofthe Authorized Servers, VPN client and method of high speed access, without the prior written notification of Tiburon; provided, however, that said notification is not intended to constitute in any manner Tiburon's approval, certification, endorsement, or warranty of the System Configuration or System performance. 5.9. Database Content Change Authorization. Client shall maintain a system to ensure that only authorized personnel have the ability to make changes to the content of the Clients database and that a list of all such authorized personnel (and any updates thereto) be promptly delivered to the Tiburon Client Support Center. Each request for any change to a Clients database shall be accompanied by a signed letter of authorization from the Chief of Police or Acting Chief of Police, acting in the absence of the Chief of Police, and shall contain all details ofthe requested change. Tiburon cannot assist Client personnel other than those on the most current authorization list. Page 4 of 16 Master Support Agreement 5.10. Authorized Client Representative. The Client shall designate, In a written notice delivered in accordance with Section 25 hereof (Notices), a single Individual to act as the Clients authorized representative for purposes of this Agreement (the "Client Representative"). Such individual shall serve as the primary contact to coordinate: (a) all matters relating to this Agreement; (b) Client's compliance with its responsibilities under this Agreement; and (c) shall coordinate appropriate schedules in connection with Tiburon's services under this Agreement. The Client may change the intjlvidual designated hereunder by providing Tiburon advance written notice delivered in accordance with Section 25 hereof (Notices) designating the new individual authorized to act as the Client Representative. 5.11. Technical Support Coordinators. The Client shall designate, In a written notice delivered in accordance with Section 25 hereof (Notices), one or more individuals to act as the Client's technical support coordinator (a "Technical Support Coordinator"). The Client shall ensure that each Technical Support Coordinator designated hereunder shall have received the training required under Section 5.12 hereof (Training) and shall otherwise be familiar with the Covered Applications and the System. The Client shall ensure that, at all times, a Technical Support Coordinator Is available (a) to screen operational assistance calls and handle operational problems, where appropriate; (b) to provide access to the System as required under Section 5.3 hereof (Physical Access); (c) to provide on-site technical assistance as required by Tiburon to aid Tiburon in performing Its services hereunder; and (d) to review all Monthly Status Reports delivered hereunder. The Client may change any individual designated hereunder by providing Tiburon with advance written notice delivered in accordance with Section 25 hereof (Notices) designating the new Individual authorized to act as a Technical Support Coordinator. 5.12. Training. The Client shall ensure that all Technical Support Coordinators and other personnel have received the necessary training and othenwise maintain sufficient personnel with sufficient training and experience to perform its obligations under this Agreement. 5.13. Error Reproduction. Upon detection of any Error in any of the Covered Applications, the Client shall provide Tiburon a listing of command input, resulting output and any other data. Including databases and back-up systems, that Tiburon may reasonably request in order to reproduce operating conditions similar to those present when the Error occurred. 5.14. TSR Review. The Client and Tiburon shall meet as may be reasonably requested by either party to discuss operational Issues and the status of the Covered Applications and the other components of the System, and as required to provide timely responses to issues identified by Client or Tiburon related to maintenance of the Covered Applications or the other components of the System. The Client and Tiburon shall invite key personnel to participate In the TSR review process as necessary. 6. Exclusions 6.1 Failure to Observe Obligations. Basic Support provided hereunder Is expressly conditioned on the observance of the responsibilities of the Client set forth in Section 5 hereof (Client Responsibilities) and in the Software License Agreement. Any Additional Support Option provided hereunder Is expressly conditioned on the observance of the responsibilities of the Client set forth in Section 5 hereof (Client Responsibilities), in the Software License Agreement and in the exhibit pertaining to such Additional Support Option. 6.2 Erroneous Reported Problems. If Tiburon performs diagnosis of erroneously reported problems, the Client may be charged for such services at Tiburon's then current technical service rates plus all related travel, per diem and other expenses invoiced as incurred. Examples of common causes of erroneous reported problems are as follows: • If a Client representative "accidentally" deletes any record from the system. • If a Client representative enters invalid or incorrect data using the Tiburon application or any Tiburon provided component. • If a Client uses Tiburon provided backup scripts as provided, then changes the script and Page 5 of 16 Master Support Agreement necessary/critical files are not being backed up. • If a Client representative does not change out the backup tapes in the tape drive or establish a tape rotation system based on Tiburon recommendations. • If a Client has a fire prevention system installed in a server room that is not recommended by the hardware manufacturer, damage is caused to the server, and data cannot be recovered. • If a Client does not follow appropriate procedures for data entry or update as provided in the Tiburon documentation or provided during Tiburon training in the application and records become "broken". • If a Client representative is not properly trained and the issue being raised has been reported multiple times by the Client representative and the issue is deemed a training Issue. • If a Client representative violates any local, state, federal, or international law using any Tiburon application or Tiburon provided component." 6.3. Failure of Remote Access. If the Ciient falls for any reason to provide remote access to the System as required by Section 5.2 hereof (Remote Access), Tiburon will, at the Client's request, provide on-site services to correct an Error to the extent otherwise required hereunder and will charge the Client for such services at Tiburon's then current technical service rates plus all related travel, per diem and other expenses invoiced as incurred. 6.4. Unauthorized Modifications. Tiburon Is under no obligation to correct any Error In any of the Covered Applications if the Error is due to a modification or alteration to such Covered Application in violation of the terms of the Software License Agreement or relates to any portion of such Covered Application that has been affected by software not developed and/or installed by Tiburon. Tiburon is under no obligation to correct any problems caused by any modification or alteration to any component of the System or to the System Configuration in violation of the terms of this Agreement or caused by software or hardware not developed and/or installed by Tiburon. If requested by the Client, Tiburon will provide technical support services to resolve such problems pursuant to Section 2.4 hereof (Out of Scope Services). 6.5. Unauthorized Use. Tiburon is under no obligation to correct any Error in any of the Covered Applications or any problems with any other component of the System if such Error or other problem is caused by (a) accident, neglect, misuse or abuse on the part of any party other than Tiburon; (b) is due to exposure to conditions outside the range of the environmental, power and operating specifications provided by Tiburon in the Site Specifications set forth in Exhibit 5; or (c) use of any of the Covered Applications or any other component of the System for any purpose other than that for which it was originally acquired. If requested by the Client, Tiburon will provide technical support services to resolve such problems pursuant to Section 2.4 hereof (Out of Scope Services). 6.6. Third-Party Products. Tiburon shall tiave no responsibility for correcting or resolving any errors, defects or failures in any Third-Party Products other than Maverick Mapping. Tiburon's only obligation with respect to such Third-Party Products is to assist with the coordination of support services with the appropnate third-party vendor to the extent such support services are available to the Client. In addition, Tiburon agrees to support the set up and configuration of WebSphere and Client, at their cost, agrees to maintain a separate support contract with IBM for maintenance and support services of WebSphere. If in the opinion of Tiburon a support request relating to WebSphere requires the assistance of IBM, Client agrees to facilitate such IBM support and if in the process of IBM providing such support an additional configuration change is required, Tiburon agrees to assist with such configuration change. 6.7. Third-Party Product Compatibility. Unless specified on Exhibit 2, Tiburon shall have no responsibility for any Third-Party Product provided and installed on or integrated into the System by any other party without Tiburon's prior written authorization, including but not limited to responsibility for the installation and integration of any such Third-Party Products, the condition, operation and performance of any such Third-Party Products, the compatibility of any such Third-Party Products with the Covered Applications, and any impact any such Third-Party Products have on the overall operation or performance of Page 6 of 16 Master Support Agreement any of the Covered Applications or any other component of the System. If requested by the Client, Tiburon will provide technical support services pursuant to Section 2.4 hereof (Out of Scope Services) to resolve any operation or performance problems relating to any of the Covered Applications or any other component of the System caused by any such Third-Party Products or to assist with the integration of any such Third-Party Products with or into any of the Covered Applications or any other component of the System. 6.8. General Disclaimer. EXCEPT AS MAY BE EXPRESSLY SET FORTH HEREIN, TIBURON DISCLAIMS ALL WARRANTIES WITH RESPECT TO ANY OF THE COVERED APPLICATIONS OR ANY OTHER COMPONENT OF THE SYSTEM, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF SUITABILITY, MERCHANTABILITY, AND/OR FITNESS FOR A PARTICULAR PURPOSE. 7. Protection of Confidential and Proprietary Information 7.1. All Client Confidential Information shall be held in strict confidence by Tiburon, and Tiburon shall not, without the Clients prior written consent, disclose such information to any person or entity other than to Tiburon's employees or consultants legally bound to abide by the terms hereof and having a need to know such information in connection with Tiburon's performance of the services hereunder, or use such information other than in connection with the performance of the services hereunder. The term "Client Confidential Information" shall include all Client data and other written information of a confidential nature clearly labeled by the Client as being confidential. Tiburon understands and agrees that the unauthorized use or disclosure of Client Confidential Information may irreparably damage the Client. In the event of Tiburon's breach or threatened breach of any of the provisions in this Section 7.1, the Client shall be entitled to an injunction obtained from any court having appropriate jurisdiction restraining Tiburon from any unauthorized use or disclosure of any Client Confidential Information. 7.2 The Client will regard Tiburon's files and data, Tiburon's Software and Documentation, and any other information or data provided by Tiburon that is clearly labeled "confidential" or "proprietary" as Tiburon's confidential information. The Client will not release or provide access to third parties, except the Client's consultants and contractors working on or with the System who agree to abide by the terms of this provision, without the prior written consent of Tiburon. The above obligations do not apply to any information which: (a) Is already in the public domain at the time of disclosure or later becomes available to the public without a breach of this Agreement; (b) Was, as between the Client and Tiburon, lawfully in the possession of the recipient without obligation of confidentiality, prior to receipt under this Agreement; (c) Is received independently from a third party free to lawfully disclose the information; (d) Is the subject of a judicial subpoena or similar process for disclosure in connection with any action or proceeding, provided that notice ofthe demand is provided to allow an opportunity to seek a protective order or other appropriate remedy prior to disclosure; or (e) Is independently developed. 7.3 Public Records Act Requests. In the event the Client receives a request under the California Public Records Act for Tiburon's confidential information, the Client will promptly notify Tiburon. Within seven (7) calendar days after receiving the notice, Tiburon will inform the Client whether Tiburon objects to disclosure of the requested information. If Tiburon does not object to disclosure or if Tiburon fails to respond to the Client within seven (7) calendar days, the Client will be relieved of its confidentiality obligation with respect to the requested information and may release the requested information. Page 7 of 16 Master Support Agreement If Tiburon does object to disclosure, then the Client will decline to produce the requested information and Tiburon will indemnify, defend, and hold the Client harmless from and against all claims, damages, costs of litigation and attorney fees arising out ofthe declination. 7.4. Notwithstanding Section 7.1 or Section 7.2 hereof, neither Client Confidential Information nor Tiburon Confidential Information shall include information which the recipient can demonstrate by competent written proof (a) is now, or hereafter becomes, through no act or failure to act on the part of the recipient, generally known or available or otherwise part of the public domain; (b) is rightfully known by the recipient without restriction on use prior to its first receipt of such information from the disclosing party as evidenced by its records; (c) is hereafter furnished to the recipient by a third party authorized to furnish the information to the recipient, as a matter of right and without restriction on disclosure; or (d) is the subject of a written permission by the disclosing party to disclose. 7.5. Notwithstanding Section 7.1 or Section 7.2 hereof, or any other provision hereof, disclosure of Client Confidential Information or Tiburon Confidential Information shall not be precluded if: (a) such disclosure is in response to a valid order of a court or other governmental body of the United States or any political subdivision thereof; provided, however, that the recipient of such confidential information shall first have given notice to the other party and shall have made a reasonable effort to obtain a protective order requiring that the information to be disclosed be used only for the purposes for which the order was issued; (b) such disclosure is necessary to establish rights or enforce obligations under this Agreement, but only to the extent that any such disclosure is necessary; or (c) the recipient of such confidential information received the prior written consent to such disclosure from the disclosing party, but only to the extent permitted in such consent. 7.6. The obligations hereunder with respect to each item of Client Confidential Information and Tiburon Confidential Information shall survive the termination ofthis Agreement. 8. Insurance Tiburon shall procure at its own expense and maintain at all times while Tiburon is performing services under this Agreement at the Client's facilities, (a) a comprehensive general liability insurance policy including coverage for contractual liability for obligations assumed under this Agreement, blanket contractual liability, products and completed operations and owner's and contractor's protective insurance; and (b) comprehensive automobile liability insurance policy including owned and non-owned automobiles. Liability coverage shall be equal to or greater than the limits for claims made under the California Tort Claims Act with minimum coverage of $1,000,000 per occurrence (combined single limit for bodily injury and property damage claims) or $1,000,000 per occurrence for bodily injury and $100,000 per occurrence for property damage. Liability coverage shall be provided on an "occurrence" basis. "Claims made" coverage will not be acceptable. Upon the Clients written request, Tiburon shall provide the Client with a certificate of insurance evidencing Tiburon's compliance with the requirements of this section. Any such certificate shall provide that coverage under the policy cannot be canceled and restrictive modifications cannot be made until at least thirty (30) days prior written notice has been given to the Client. 9. Limitation of Liability TIBURON'S LIABILITY TO THE CLIENT FOR ANY CLAIM, WHETHER IN TORT, CONTRACT OR OTHERWISE, SHALL BE LIMITED TO THE ANNUAL MAINTENANCE FEES PAID HEREUNDER FOR THE PERIOD IN WHICH THE CAUSE OF ACTION OCCURRED. IN NO EVENT SHALL TIBURON BE LIABLE TO ANY PARTY FOR LOSS OR DAMAGES DUE TO ERRORS IN ANY OF THE COVERED PageSof 16 Master Support Agreement APPLICATIONS, OPERATOR ERROR, OR DATA CORRUPTION OR INACCURACIES. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY DAMAGES RESULTING FROM LOSS OF PROFIT OR BUSINESS, OR FOR ANY SPECIAL, INDIRECT, PUNITIVE, INCIDENTAL OR CONSEQUENTIAL DAMAGES, WHETHER ARISING IN AN ACTION OF CONTRACT, TORT OR OTHER LEGAL THEORY AND REGARDLESS OF WHETHER SUCH PARTY KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES. THE LAWS IN SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, AND THE ABOVE LIMITATION OR EXCLUSION SHALL BE CONSTRUED SO AS TO GIVE IT THE MAXIMUM PRACTICAL EFFECT WITHOUT VIOLATING SUCH LAWS. 10. Indemnification 10.1 General Obligation. Tiburon agrees to indemnify, defend and hold the Client and its officers, agents, and employees harmless from and against any and all claims, losses, damages, obligations, liabilities and expenses (including attorney fees) arising from: (a) Any infringement of any copyright, trademark, patent, or other proprietary right, or misappropriation of any trade secrets in connection with any Tiburon developed Software, Documentation, Services or other Products supplied by Tiburon in connection with this Agreement; (b) Any act(s) of negligence or willful misconduct by Tiburon or any of its agents, employees or subcontractors, including, but not limited to, any liability caused by an accident or other occurrence resulting in bodily injury, death, sickness or disease to any person(s) or damage or destruction to any property, real or personal; or (c) The Clients refusal to produce Tiburon's confidential information pursuant to a request to review public Client records, after receiving a request for the item and after being instructed by Tiburon not to produce it; or (d) Any claims by any persons or entities supplying labor or material to Tiburon in connection with the performance of Tiburon's obligations under ttiis Agreement. (e) NOTWITHSTANDING THE FOREGOING, IN NO EVENT SHALL TIBURON BE LIABLE FOR ANY LOSS OR DAMAGES RELATED TO THE OPERATION, DELAY, OR FAILURE OF THE SOFTWARE OR EQUIPMENT PROVIDED BY TIBURON OR FOR THE ACCURACY OR COMPLETENESS OF DATA, AND UNDER NO CIRCUMSTANCES SHALL TIBURON BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES. 11. Informal Dispute Resolution 11.1. The parties to this Agreement shall exercise their best efforts to negotiate and settle promptly any dispute that may arise with respect to this Agreement in accordance with the provisions set forth in this Section 11.1. (a) If either party (the "Disputing Party") disputes any provision of this Agreement, or the interpretation thereof, or any conduct by the other party under this Agreement, that party shall bring the matter to the attention of the other party at the eartiest possible time in order to resolve such dispute. (b) If such dispute is not resolved by the Technical Coordinators responsible for the subject matter ofthe dispute within ten (10) business days, the Disputing Party shall deliver to the first level of representatives below a written statement (a "Dispute Notice") describing the dispute in detail, including any time commitment and any fees or other costs involved. Page 9 of 16 Master Support Agreement 3 (c) Receipt by the first level of representatives of a Dispute Notice shall commence a time period within which the respective representatives must exercise their best effort to resolve the dispute. If the respective representatives cannot resolve the dispute within the given time period, the dispute shall be escalated to the next higher level of representatives in the sequence as set forth below. (d) If the parties are unable to resolve the dispute in accordance with the escalation procedures set forth below, the parties may assert their rights under this Agreement. Escalation Timetable Tiburon Client (Business Davs) Representative Representative 0 to 5"^ Client Liaison Chief Technology Officer 6* to 10* CSC Director Chief of Police or designee 11 * to 15"^ Executive Officer City Attorney 11.2. Notwithstanding the fact that the parties may be attempting to resolve a dispute in accordance with the informal dispute resolution procedures set forth in Section 11.1 hereof, the parties agree to continue without delay all their respective responsibilities under this Agreement that are not affected by the dispute. 11.3. Notwithstanding the foregoing, either party may, before or during the exercise of the informal dispute resolution procedures set forth in Section 11.1, apply to a court having jurisdiction for a temporary restraining order or preliminary injunction where such relief is necessary to protect its interests pending completion of such informal dispute resolution procedures. 12. Service Warrantv During the term ofthe Maintenance and Support Agreement between the parties, Tiburon agrees that it will remedy any faiiure, malfunction, Defect or nonconformity in the System, as follows: 12.1 Priority One TSRs For purposes of this Agreement, a "Priority One TSR" is defined as the entire system (i.e.: CAD, MobileCOM, Law RECORDS, Jail RECORDS, Message Switch) is down, a major component (i.e.: State Interface) is unavailable, or a major component or function does not work properiy for which no reasonable work around acceptable to Client is available. There is no acceptable workaround to the Client to allow them to use System or component to continue operations. Impacts all or most users, halts or severely impacts critical operations, or database integrity is compromised. Client agrees not to unreasonably withhold acceptance of a workaround. Tiburon agrees that it will respond with as many qualified and knowledgeable representatives as necessary within thirty (30) minutes after notification by the Client, to remedy a Priority One TSR. The representatives will furnish uninterrupted, continuous efforts or a plan acceptable to the Client to remedy the Priority One TSR on an emergency basis. During this time, Tiburon's representatives will provide a status report to the City's Technical Coordinator every two (2) hours until the Priority One TSR is remedied. Ifthe Priority One TSR is not remedied within twenty-four (24) hours of its initial report, Tiburon will take all measures necessary to restore the System or the major subsystem to operation, including sending technical support personnel to the Client's installation site(s) immediately.. 12.2 Priority Two TSRs. For purposes of this Agreement, a "Priority Two TSR" is defined as a major component or function does not work properiy for which a reasonable workaround acceptable to the City is available. Normal operations impaired, but can continue. Client agrees not to unreasonably withhold acceptance of a workaround. Page 10 of 16 Master Support Agreement For Priority 2 TSRs that are reported at or before sixty (60) days prior to the next scheduled quarteriy maintenance release, Tiburon will include such fixes in the next quarterly maintenance release, unless otherwise agreed to by the parties. Priority 2 TSR's that are not reported sixty (60) days prior to the next quarterly maintenance release will be resolved and included in the maintenance release following the next quarterly maintenance release. Priority 2 TSR's will be resolved as specified above contingent upon the Client having a current maintenance agreement in place and paid in full as well as all outstanding accounts receivable not disputed by the Client in current good standing with nothing past due. Any invoice that is being disputed by Client must be disputed in good faith and Client agrees to provide Tiburon with a detailed written description as to why such invoice is being disputed. Such detailed written description must be supported by language in the Agreement for such a dispute to be considered in good faith. Without undue delay, the parties agree to work in good faith with one another to verify the claims of the dispute and to develop a resolution plan to remedy such claims. Once the claims in the dispute have been resolved, the Client agrees to process said invoice for payment. 12.3 Priority Three TSRs. For purposes of this Agreement, a "Priority Three TSR" is defined in section 4.2 ofthe Warranty & Maintenance Support - Guidelines and Options, attached in Exhibit 7. Tiburon agrees that Priority 3 TSRs will have priority for inclusion in the next scheduled maintenance release as time may permit. 12.4 Priority Four TSRs. For purposes of this Agreement, a "Priority Four TSR" is defined in section 4.2 ofthe Warranty & Maintenance Support - Guidelines and Options, attached in Exhibit 7. Tiburon agrees to resolve Priority Four TSR's as follows: Enhancement Requests will be assigned to a Sales representative for follow up with the client. Informational requests will be addressed as quickly as possible based on resource availability. 12.5 Cumulative Failures. Cumulative, contemporaneous failures, regarding the same functionality, regardless of their individual priorities, will be regarded as a Priority One TSR if, in the Client's determination, they result in the Client have essentially no effective use of the System or a major subsystem. 12.6 Permanent Cure. If the Client accepts a workaround or other temporary cure as the remedy for any reported TSR, Tiburon shall provide a permanent correction or cure within one hundred eighty days (180) days after the permanent cure becomes available, or with the next scheduled release of fixes after the permanent cure becomes available, whichever is sooner. 13. Termination 13.1. Termination for Failure of License. In the event that the license relating to any of the Covered Applications is terminated or becomes unenforceable for any reason, Tiburon's obligation to provide any support hereunder for such Covered Application shall immediately and automatically terminate. 13.2. Termination for Other Defaults. Subject to completion of the dispute resolution procedures set forth in Section 11.1 hereof (Informal Dispute Resolution), in the event that either party hereto materially defaults in the performance of any of its obligations hereof), the other party may, at its option, terminate this Agreement, by providing the defaulting party thirty (30) days' prior written notice of termination delivered in accordance with Section 25 hereof (Notices), which notice shall identify and describe with specificity the basis for such termination. If, prior to the expiration of such notice period, the defaulting party cures such default, or provides a mutually agreed upon correction plan to remedy such a default that cannot be reasonably remedied within thirty (30) days, termination shall not take place. Page 11 of 16 Master Support Agreement 6 13.3. Termination Without Cause. Either party hereto may terminate this Agreement without cause by providing the other party at least ninety (90) days' prior written notice of termination delivered in accordance with Section 25 hereof [Notices]. The effective date for any termination pursuant to this Section 13.3 shall be the next occurring Payment Date. 13.4. Consequences of Termination. Upon termination of this Agreement for whatever reason, (a) Tiburon shall be under no further obligation to provide support or any other services hereunder; (b) Tiburon shall return to the Client all Client Confidential Information in Tiburon's possession and shall certify in a written document signed by an officer of Tiburon that all such information has bteen returned; (c) the Client shall return to Tiburon all Tiburon Confidential Information in the Client's possession but not including any such information licensed to the Client under the Software License Agreement, (if such licenses have been fully paid for) and shall certify in a written document signed by the Client Representative identified in Section 5.10 hereof (Authorized Client Representative) that all such information has been returned. Upon termination by Client for default, pursuant to Section 13.2 above, Tiburon agrees to refund Client the unused portion ofthe annual payment for the annual maintenance year in which the Agreement was terminated (the refund shall be calculated from the effective date of the termination through the end of the then current annual maintenance term, not to exceed twelve (12) months). All provisions of this Agreement that by their nature would reasonably be expected to continue after the termination of this Agreement shall survive the termination of this Agreement. 14. Independent Contractor Status The Client and Tiburon are independent contractors under this Agreement, and nothing herein shall be construed to create a partnership, joint venture, or agency relationship between the parties hereto. Neither party shall have any authority to enter into agreements of any kind on behalf of the other and shall have no power or authority to bind or obligate the other in any manner to any third party. The employees or agents of one party shall not be deemed or construed to be the employees or agents of the other party for any purpose whatsoever. Each party hereto represents that it is acting on its own behalf and is not acting as an agent for or on behalf of any third party. 15. Assignment Neither party hereto may assign its rights or obligations under this Agreement without the prior written consent of the other party, which consent shall not be unreasonably withheld; provided, however, that Tiburon may assign this Agreement to its successor in connection with a sale of its business without obtaining consent of any party, however, Tiburon shall notify Client immediately upon effectuation of such assignment. Subject to the foregoing, each and every covenant, term, provision and agreement contained in this Agreement shall be binding upon and inure to the benefit of the parties' permitted successors, executors, representatives, administrators and assigns. 16. No Third Party Beneficiaries This Agreement is entered into for the sole benefit of the Client and Tiburon and, where permitted above, their permitted successors, executors, representatives, administrators and assigns. Nothing in this Agreement shall be construed as giving any benefits, rights, remedies or claims to any other person, firm, corporation or other entity, including, without limitation, the general public or any member thereof, or to authorize anyone not a party to this Agreement to maintain a suit for personal injuries, property damage, or any other relief in law or equity in connection with this Agreement. 17. Governing Law All questions concerning the validity, operation, interpretation, construction and enforcement of any terms, covenants or conditions of this Agreement shall in all respects be governed by and determined in accordance with the laws of the State of California without giving effect to the choice of law principles thereof. The United Page 12 of 16 Master Support Agreement Nations Convention on the International Sale of Goods shall not apply to any transactions contemplated by this Agreement. 18. Venue All legal proceedings brought in connection with this Agreement may only be brought in a state or federal court located in the County of San Diego, State of California. Each party hereby agrees to submit to the personal jurisdiction of those courts for any lawsuits filed there against such party arising under or in connection with this Agreement. 19. Advice of Counsel Each party hereto has been afforded the opportunity to consult with counsel of its choice before entering into this Agreement. The parties waive the provisions of California Civil Code Section 1654 such that any ambiguity in this Agreement may not be construed against either party. 20. Amendment No amendment or other modification of this Agreement shall be valid unless pursuant to a written instrument referencing this Agreement signed by duly authorized representatives of each of the parties hereto. 21. Waiver In order to be effective, any waiver of any right, benefit or power hereunder must be in writing and signed by an authorized representative of the party against whom enforcement of such waiver would be sought, it being intended that the conduct or failure to act of either party shall imply no waiver. Neither party shall by mere lapse of time without giving notice or taking other action hereunder be deemed to have waived any breach by the other party of any of the provisions of this Agreement. No waiver of any right, benefit or power hereunder on a specific occasion shall be applicable to any facts or circumstances other than the facts and circumstances specifically addressed by such waiver or to any future events, even if such future events involve facts and circumstances substantially similar to those specifically addressed by such waiver. No waiver of any right, benefit or power hereunder shall constitute, or be deemed to constitute, a waiver of any other right, benefit or power hereunder. Unless othenwise specifically set forth herein, neither party shall be required to give notice to the other party, or to any other third party, to enforce strict adherence to all terms of this Agreement. 22. Force Majeure Neither party will be liable for any failure or delay in the performance of its obligations under this Agreement (and the failure or delay will not be deemed a default of this Agreement or grounds for termination) if both of the following conditions are satisfied: (1) the failure or delay could not have been prevented by reasonable precautions, and cannot reasonably be circumvented by the non-performing party through the use of alternate sources, work-around plans, or other means; and (2) the failure or delay is caused, directly or indirectly, by reason of fire or other casualty or accident; strikes or labor disputes; inability to procure raw materials, equipment, power or supplies; war, terrorism or other violence; any law, order, proclamation, regulation, ordinance, demand, or requirement of any governmental agency or intergovernmental body other than a party hereto; or any other act or condition beyond the reasonable control of the non-performing party. Upon the occurrence of an event which satisfies both ofthe above conditions (a "Force Majeure Event"), the non-performing party will be excused from any further performance of those obligations under this Agreement affected by the Force Majeure Event for as long as (a) the Force Majeure Event continues; and (b) the non-performing party continues to use commercially reasonable efforts to recommence performance whenever and to whatever extent possible without delay. Upon the occurrence of a Force Majeure Event, the non-performing party will immediately notify the other party by telephone (to be confirmed by written Page 13 of 16 Master Support Agreement 17 notice within two (2) business days of the failure or delay) of the occurrence of a Force Majeure Event and will describe in reasonable detail the nature of the Force Majeure Event. 23. Severability If any provision of this Agreement shall for any reason be held to be invalid, illegal, unenforceable, or in conflict with any law of a federal, state, or local government having jurisdiction over this Agreement, such provision shall be construed so as to make it enforceable to the greatest extent permitted, such provision shall remain in effect to the greatest extent permitted and the remaining provisions of this Agreement shall remain in full force and effect. 24. Entire Agreement This Agreement sets forth the final, complete and exclusive agreement and understanding between Tiburon and the Client relating to the subject matter hereof and supersedes all quotes, proposals understandings, representations, conditions, warranties, covenants, and all ottier communications between the parties (oral or written) relating to the subject matter hereof. Tiburon shall not be bound by any terms or conditions contained in any purchase order or other form provided by the Client in connection with this Agreement and any such terms and conditions shall have no force or effect. No affirmation, representation or warranty relating to the subject matter hereof by any employee, agent or other representative of Tiburon shall bind Tiburon or be enforceable by the Client unless specifically set forth in this Agreement. 25. Notices All notices, requests, demands, or other communications required or permitted to be given hereunder shall be in writing addressed to the parties at their respective addresses set forth below and shall be deemed to have been duly given when (a) delivered in person; (b) sent by facsimile transmission indicating receipt at the facsimile number where sent; (c) one (1) business day after being deposited with a reputable overnight air courier service; or (d) three (3) business days after being deposited with the United States Postal Service, for delivery by certified or registered mail, postage pre-paid and return receipt requested. All notices and other communications regarding default or termination of this Agreement shall be delivered by hand or sent by certified mail, postage pre-paid and return receipt requested. Either party may from time to time change the notice address set forth below by delivering notice to the other party in accordance with this section setting forth the new address and the date on which it will become effective. If to Tiburon: Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon, California 94583 Attention: Contracts Manager Phone: 925-621-2700 Fax: 925-621-2799 If to the Client: Public Safety IT Manager City of Carisbad - Police Department 2560 Orion Way Carlsbad, CA, 92010 Phone: 760-931-2176 Fax: 760-931-8473 26. Construction Page 14 of 16 Master Support Agreement The paragraph and section headings used in this Agreement or in any exhibit hereto are for convenience and ease of reference only, and do not define, limit, augment, or describe the scope, content or intent of this Agreement. Any term referencing time, days or period for performance shall be deemed calendar days and not business days, unless otherwise expressly provided herein. 27. Counterparts This Agreement may be signed in two or more counterparts, each of which shall constitute an original, and both ofwhich shall constitute one and the same document. (THE REMAINDER OF THIS PAGE IS INTENTIONALLY LEFT BLANK) Page 15 of 16 Master Support Agreement 28. AUTHORITY The individuals executing this Agreement and the instruments referenced in it on behalf of Tiburon each represent and warrant that they have the legal power, right and actual authority to bind Tiburon to the terms and conditions of this Agreement. Tiburon, Inc. CITY OF CARLSBAD, a municipal corporation of the State of California (sign here) Duane W. Bell (sign here) (print name/title) ATTEST: BARBARA ENGLEgro City Clerk If required by City, proper notarial acknowledgment of execution by contractor must be attached. If a corporation. Agreement must be signed by one corporate officer from each of the following two groups. Group A Chairman, President, or Vice-President Group 8 Secretary, Assistant Secretary, CFO or Assistant Treasurer Otherwise, the corporation must attach a resolution certified by the secretary or assistant secretary under corporate seal empowering the offlcer(s) signing to bind the corporation. APPROVED CELi Assistant City Attorney Page 16 of 16 Master Support Agreement EXHIBIT 1 To Master Support Agreement DEFINITIONS This Exhibit is attached to, incorporated into, and forms a part of the Master Support' Agreement, dated . 20<f/-between Tiburon and the Client (herein referred to as the "Agreement"). Capitalized terms used in the Agreement or any exhibit thereto shall have the definitions set forth herein unless othenwise defined In the Agreement. In the event of conflict between the terms and conditions set forth herein and those set forth in the Agreement, the temns and conditions set forth in the Agreement shall prevail. 1. "As-Built Specifications" shall mean, with respect to any of the Covered Applications, the specifications for such Covered Application delivered to the Client upon the Client's acceptance of such Covered Application, as the same may be modified or supplemented from time to time to reflect Enhancements provided hereunder. 2. "Authorized Server" shall mean, with respect to any of the Covered Applications, the server identified as corresponding to such Covered Application on Exhibit 2 attached to the Agreement and incorporated therein by reference. 3. "Authorized Site" shall mean, with respect to any of the Authorized Sen/ers, the address and room number identified as corresponding the such Authorized Server on Exhibit 2 attached to the Agreement and incorporated therein by reference. 4. "Communications Interfaces" shall mean ethernet networking, serial connectivity to net clock and ANI/ALI, serial connectivity to HACMP, national, state and local governments, TCP/IP or other routing statements. 5. "Covered Application" shall mean each software application developed by Tiburon in accordance with the As-Built Specifications relating thereto which application is identified as a Covered Application on Exhibit 2 attached to the Agreement and Incorporated therein by reference, including all Maintenance Modifications thereto, all Derivative Works thereof, and all related Documentation. 6. Database Administration (DBA) Support shall mean services available to Clients to assist in the administration ofthe system database. 7. "Derivative Works" shall mean, with respect to any Covered Application, any translation, abridgement, revision, modification, or other form in which such Covered Application may be recast, transformed, modified, adapted or approved afterthe Effective Date. 8. "Documentation" shall mean, with respect to any Covered Application, those printed instructions, manuals, and diagrams pertaining to and furnished with such Covered Applications. 9. "Enhancement" shall mean, with respect to any Covered Application, a computer program modification or addition, other than a Maintenance Modification, that alters the functionality of, or adds new functions to such Covered Application and that is integrated with such Covered Application after the Effective Date, or that Is related to a given Covered Application but offered separately by Tiburon after the Effective Date., 10. "Enhancement Terms" shall mean, with respect to any Enhancement provided pursuant to the Agreement, the mutually negotiated terms and conditions specifically relating to an Enhancement and included as part of tiie Agreement in accordance with Section 2.3 (Enhancements) thereof. Page 1 of 3 Master Support Agreenient Extiibit 1, Definitions 11. "Error" shall mean, with respect to any Covered Application, a defect in the Source Code for such Covered Application that prevents such Covered Application from functioning In substantial conformity with the As-Built Specifications pertaining thereto. 12. "Maintenance Modification" shall mean, with respect to any Covered Application, a computer software change integrated with such Covered Application during the term of the Agreement to correct any Errors therein, but that does not alter the functionality of such Covered Application or add new functions thereto. 13. "Object Code" shall mean computer programs assembled or compiled from Source Code In magnetic or electronic binary form on software media, which are readable and usable by machines, but not generally readable by humans without reverse-assembly, reverse-compiling, or reverse-engineering. 14. "Out of Scope Services" shall consist of any services provided under this Agreement that are outside the scope of those sen/ices specifically and expressly identified under, and provided pursuant to. Section 2,1 (Basic Support), Section 2.2 (Support Options) or Section 2.3 (Enhancements) of the Agreement 15. "Payment Date" shall mean a specific annual date that is agreed to between the Client and Tiburon. 16. "Protocol" shall mean the method governing exchange or transmission of data between devices, Examples include, but are not limited to TCP/IP, SNA, CDPD, RNC, RS232. 17. "Software License Agreement" shall mean any software license agreement between Tiburon and the Client pursuant to which Tiburon has granted a limited license to use the Covered Applications in accordance with the terms and conditions thereof, as the same may be amended or otherwise modified from time to time. 18. "Source Code" shall mean computer programs written in higher-level programming languages, sometimes accompanied by English language comments. Source Code is intelligible to trained programmers and may be translated to Object Code for operation on computer equipment through the process of compiling. 19. "System" shall mean the Client's computer automated system consisting of the Covered Applications combined with any of the Authorized Servers, the operating systems installed on each of the Authorized Sen/ers, any database or other third party software products installed on any of the Authorized Servers, any PC or other workstation equipment having access to any of the Covered Applications, any Communications Interfaces installed on any of the Authorized Servers, any network communications equipment and any other third party software, wiring, cabling and connections and other hardware relating to any such Authorized Servers, workstation or network communications equipment located at any of the Authorized Sites. 20. "System Configuration" shall mean the configuration for the System other than the Covered Applications existing as of the Effective Date together with any modifications or alterations thereto permitted hereunder, Including without limitation the configuration of the Authorized Servers, any operating system Installed on any of the Authorized Servers, any database or other third party software products installed on any of the Authorized Sen/ers, any PC or other workstation equipment having access to any of the Covered Applications, any network communications equipment and any other third party software, wiring, cabling and connections and other hardware relating to any such Authorized Server, workstation or network communications equipment located at any of the Authorized Sites. 21. "Third-Party Products" shall mean all software and hardware components of the System other than the Covered Applications. Page 2 of 3 Master Support Agreement Extiibit 1, Definitions 22. "Warranty Period" shall mean, with respect to any Covered Application, the warranty period for such Covered Application set forth on Exhibit 2 attached to the Agreement and incorporated therein by reference. Page 3 of 3 Master Support Agreement Exhibit 1, Definitions EXHIBIT 2 To Master Support Agreement COVERED APPLICATIONS This Exhibit is attached to, incorporated into and forms part of the Master Support Agreement, dated , 20_, between the Client and Tiburon (herein referred to as the "Agreement"). Capitalized terms used herein shall have the definitions set forth In the Agreement, unless othenwise defined herein. In the event of conflict between the terms and conditions set forth herein and those set forth in the Agreement, the terms and conditions set forth in the Agreement shall prevail. Tiburon will provide the Basic Support described in Section 2.1 (Basic Support) of the Agreement for the software applications identified in the table below. .The annual fee for such support shall be as set forth in the table below. Such support will commence upon the expiration of any applicable Warranty Period as set forth In the table below. CLIENT*-M1270-14 Covered Application Hardware List Period Maintenance Period Start Date End Date Annual Fee CommandCAD *See Below 12 Mo 7/1/14 6/30/15 $36,736.00 Data Warehouse *See Below 12 Mo 7/1/14 6/30/15 $1,702.00 WebQuery *See Below 12 Mo 7/1/14 6/30/15 Included 911 Mapping 12 Mo 7/1/14 6/30/15 $12,295.00 MobileCOM & Mobile 12 Mo 7/1/14 6/30/15 $23,301.00 Mapping MSS 12 Mo 7/1/14 6/30/15 $21,383.00 LVS 12 Mo 7/1/14 6/30/15 $10,000,00 LVS- Prorated 7 Mo 12/3/13 6/30/14 $5,767.00 GOT - Prorated 7 Mo 12/3/13 6/30/14 <$467.00> Credit - • One time credit to <$4,246.12> satisfy Amendment 7 refund Total $106,470.88 Authorized Site City of Carisbad 2560 Orion Way Carisbad, CA 92008 Page 1 of 2 Master Support Agreement Exhibit 2, Covered Applications "Hardware List SCCADDBOIv-Virtual SQL DB, FM TEST , LVS TEST SCCADAPP01 - Stratus CAD LIVE SCCADMQOIv-Virtual State Interface SCCADMQ02V - Virtual State Interface SCCADWEBOIv-Virtual FM LIVE, LVS LIVE SCCADAPPTEST01V - Virtual CAD TEST SCCADDW01V-Virtual DW, Distribution, MobileCOM, Map Distribution SCCADMAPOIv-Virtual Map Setup Page 2 of 2 Master Support Agreement Exhibit 2, Covered Applications X EXHIBIT 3 To Master Support Agreement This Exhibit, by mutual agreement, Is not being used and this cover page remains to serve as a place holder to maintain proper exhibit numbering throughout the Agreement only - Page 1 of 1 Master Support Agreement Exhibit 3 ex. ^' EXHIBIT 4 To Master Support Agreement THIRD-PARTY SUPPORT CONTRACTS This Exhibit is attached to, incorporated into and forms part of the Master Support Agreement, dated , 20 , between the Client and Tiburon (herein referred to as the "Agreement"). Capitalized terms used herein shall have the definitions set forth in the Agreement, unless otherwise defined herein. In the event of conflict between the terms and conditions set forth herein and those set forth In the Agreement, the terms and conditions set forth in the Agreement shall prevail. ~ This Exhibit shall follow this cover page • Page 1 of 1 Master Support Agreement Exhibit 4, Third Party Support Contracts EXHIBIT 5 To Master Support Agreement SITE, SYSTEM AND NETWORK SPECIFICATIONS This Exhibit is attached to, incorporated into and forms part ofthe Master Support Agreement, dated , 20_, between the Client and Tiburon (herein referred to as the "Agreement"). Capitalized terms used herein shall have the definitions set forth in the Agreement," unless othenwise defined herein. In the event of conflict between the terms and conditions set forth herein and those set forth In the Agreement, the terms and conditions set forth in the Agreement shall prevail. " This Exhibit will be completed during System Implementation Page 1 of 1 Master Support Agreement Exhibit 5, Site, System and Network Specifications CommandCAD Server SCCAOAPPOIv CommandCAD Uva MSS Live / Reformat Designer Mapping for CommandCAD Live Interfaces File li/lalntenanca Client Live Nolo MSS Uvo can he seated oof onto sepamlo se/vei tor ianjonmlailauona Wore Acicliliansl Silo Oixttsler Recovary, and'or Ro/Tio(» servei s may also be i>aii of KOI" system CommandCAD Test Server/Machine SCCADAPPTESTOfv CommandCAD Test MSS Test Mapping for CommandCAO Test Tast CommandCAD Interface File liflalntenancB Client Test Application Live Server SCCADWEBOIv File Malntenancelive Location Verification Services WgbQuery Live/Test Database Server SCCADDB01V SQL Server Live Database Test Database File Maintenance Test Location Verillcatlon Services Test Data Warehouse Server SCCADDWOIv SQL Server Data Warehouse LIVE/TEST SQL Server Reporting Services CommandCAO Distribution Map Distribution MobileCOM Installers .oNFIDENM Carisbad CommandCAD 2.6 File IVlaintenance 2,8 Mapping 5.3 MobileCOM 5.3 WebQUERY 7.9 Pile Maintenance TEST SCCA0APf»TEST02v File Maintenance TEST Location Verification Services (TEST) Map Setup Machine Map Satup MQ-1 State Interface MQ-2 State Interface SCCAOMQ02 Wo/e All c.0ivefs me capoblo of seallncf out via clustering, Notwoili Load BuiiiiKing or movmg ii spoafic /ote to a new rtmc-i'MH III must ba a now machine ami i>o! one already perfomtimj a rola) mmm. EXHIBIT 6 To Master Support Agreement BACK UP SCHEDULE AND PROCEDURES This Exhibit is attached to, incorporated into and forms part of the Master Support Agreement, dated , 20_, between the Client and Tiburon (herein referred to as the "Agreement"). Capitalized terms used herein shall have the definitions set forth in the Agreement, unless otherwise defined herein. In the event of conflict between the terms and conditions set forth herein- and those set forth in the Agreement, the terms and conditions set forth in the Agreement shall prevail. " This Exhibit shall follow this cover page - Page 1 of 1 Master Support Agreement Exhibit 6, Back Up Schedule and Procedures V 3 Tiburon Master Support Agreement Exhibit 6 Back Up Schedule & Procedures General Notes on Backups This document describes the procedures to backup the minimum set of files required to recover application and/or data files In the event of a hardware failure or data loss. These procedures assume that if the server needs to be completely rebuilt/restored, the system files may need to be restored prior to restoring these files. This may include the need to reinstall the operating system files and any other required supporting applications (PC Anywhere, WinZip, etc.). In addition, the client may choose to backup other files on the servers or use utilities to simplify total system recovery in the event a server is completely lost or all data is lost. This is acceptable as long as the precautions listed above are followed. In particular, the application file folders should be backed up without locking the files. Locking these files during the backup could cause undesirable effects to the application. CAD Backups Introduction Regular backups are essential to preserve the CAD system data in the unlikely event of a catastrophic hardware failure or other major problem. While the server may include fault- tolerant and/or redundant systems, serious hardware or software failures resulting in data loss are still possible. In addition, events such as fire, fiood, or other general disasters can destroy equipment. It may be desirable to store a copy of backups on-site so that they are readily available; however, Tiburon recommends that an off-site copy be maintained in case the Center, and its contents, are damaged or destroyed. How and when the database is backed up will depend on the database used (Oracle or SQL Server) as well as the needs of the individual client site. CAD System Backups A backup of the functioning CAD system is not necessary. Current "static" data (i.e., data maintained in the File Maintenance tables/database including geo data), and "dynamic" data (i.e., calls, units, assignments, current seqijence values, histories, etc.) are present on each active workstation, and on the server; static data and histories are stored in the database as well (provided there have not been major changes without a synchronize, in the case of static data; and that It has been up as a functioning CAD file server, in the case of histories). Only a total loss of all computers participating in the CAD system will cause this data to be lost, and backups of the data can quickly become out-of-date as new calls are entered, units are assigned, etc. For these reasons, it is neither required nor feasible to perform backups of the CAD system files on each workstation and server. When backing up CAD workstations or the CAD server hard drive, do not use software that "locks" files to writmg—if this is not possible, the backup should exclude the CAD directory (which contains the "Startup.exe" and other programs) as well as all the directories inside It. The CAD files must be updated in real-time based on the system activity; locking these files so that they cannot be written will prevent the workstation from keeping up with the CAD system, which will cause CAD to fatally exit on that workstation (to preserve data integrity). If this occurs, the workstation can be restarted once the backup Is complete (or has at least passed the CAD directory). Until the backup is done with the CAD flies, the CAD system will simply crash itself if it is prevented from writing to the files. Page 1 of 5 20060803 Tiburon Master Support Agreement Exhibit 6 Back Up Schedule & Procedures Note: If the workstation.ini file is customized on some machines. It may be worthwhile to back it up. Tiburon also recommends a backup of any non-distributed .ini files that are present Reinstalling and connecting to the CAD system will restore everything else. In addition to the Oracle or SQL database, the other item that must be backed up is the distribution directory on the CAD distribution Server (see the As-Built Documentation to identify the Software Distribution server for the CAD system). If the current distribution is lost, Tiburon can replace it; however, we cannot replace gny site-customized .ini or .hip files that were set for distribution. CAD Operations During a Backup The CAD system should not be shut down to perform backups. The individual CAD workstations continue operating while the backup Is being performed. The database server also remains active and the database is available for queries and other transactions throughout the backup process. Note: The CAD server may run slightly slower during backups. The only potential adverse effects are longer response times for history inquiries and synchronizing operations. Database Backups - Oracle Starting with Oracle Version 91, Tiburon production database backup is performed using the Oracle Recovery Manager Tool (RMAN). Prior to Oracle 9i, the production database backup was performed using a Tiburon database backup script. Tiburon Implements a hot backup scheme for the production database. This means that the production database can remain open and allow normal activity while the database is being backed up. It is important to note that the database hot backups are special backups and are only performed using special tools such as RMAN. Simply copying the database flies while the database is open for normal operations using the operating system copy command is not appropriate, as such backup files are not useful for database recovery purposes. The Tiburon Oracle hot backup Is primarily a full disk backup of the production database. In addition to backup of the data files, this process also backs up the archive log (Journal) files. The backup is scheduled to run nightly. Upon backup completion, this process places the backed up database files in a dedicated backup directory. This backup directory is then copied to a Tape device as part of the Tiburon master backup. The availability of backups on disk considerably reduces the recovery time. Tiburon will work with client to define the disk space requirements for database disk backups during the database sizing stage ofthe project. Database Backups - SQL Server Tiburon SQL Server 2000 production database backup is performed using SQL Server Enterprise Manger maintenance plans. Tiburon implements a hot backup scheme for production databases. This means the production database can remain open and allow normal activity while the database is being backed up. It is important to note that the database hot backups are special backups and are only performed using special tools such as SQL Server Enterprise Manager maintenance plans. Simply copying the database files while the database is open for normal operations using the operating system copy command is not appropriate as such backup files are not useful for database recovery purpose. The Tiburon SQL Server hot backup is primarily a full disk backup of the production database. In addition to backing up the data flies this process also backs up the Transaction logs for the production database. The backup is scheduled to run nightly. Upon backup completion, this process places the backed up database files in a dedicated backup directory. In addition to Page 2 of 5 20060803 Tiburon Master Support Agreement Exhibit 6 Back Up Schedule & Procedures backing up the Tiburon production database, Tiburon SQL Server backup also includes maintenance plans for performing disk backup of MASTER, MSDB and MODEL system databases. The backed up files for these databases are also placed in the dedicated backup directory. This backup directory is then copied to a Tape device as part of the Tiburon master backup. The availability of backups on disk considerably reduces the recovery time. Tiburon will work with client to define the disk space requirements for database disk backups during the database sizing stage of the project RMS Backups System Backup Requirements for RMS/TI These procedures do not address the requirements for backing up an Oracle or SQL Server database; the same procedures as described above for the CAD database files apply to the RMS database files. On the RMS/TI server there should be an "RMS_Ti" folder; within that folder are additional folders for the production (prd) and training (tm) systems. The components to be backed up from these directories are addressed below.- Firstly, under the production folder there should be at minimum three additional directories: • Bin • Datrms • Dmp Bin Directory From the Bin Directory, only "RmsTiSystem.ini" and any other configuration files should be backed up. Other configuration files would include batch files used in place of the script files used In the UNIX environment. These are usually files called from within applications for FTPing or uploading either from or into the system, such as "Autocite.bat", "btpawn.parm" and "btcite.parm". It may be easier to determine what can be ignored by the backup in this directory: all executables (.exe), dynamic link libraries (.dll), COBOL-generated files (.gnt) and system tables (.tab). There are currently eight (8) additional shared memory files which should also be ignored; those files have names associated with the site and system settings outlined In the "RmsTiSystem.ini" configuration file. They will have names similar to the following: {sitename}.Prd.commands {sitename}.Prd.commands {sitename}.Prd.fields {sitename}.Prd.fields {sitename}. Prd. master {sitename}. Prd. master {sitename}.Prd.MessageQueues.dat {sitename}.Prd.MessageQueues.dat {sitename}. MessageCount dat {sltename}.Prd.MessageCount.dat {sltename}.system {sltename}.Prd.system {sitename}.Prd.uxappl1 {sltename}.Prd.uxappl1 {sitename}.Prd.uxiob {sitename}. Prd. uxiob Datrms Directory From the Datrms directory, all files except SSFLxfl should be backed up. However, these files should not be locked by the backup process. Page 3 of 5 20060803 Tiburon Master Support Agreement Exhibit 6 Back Up Schedule & Procedures Dmp Directory As far as the operation of the system is concerned, nothing from the Dmp directory should be backed up, as these are all dynamic files that will be recreated when the system Is restarted and contain no static data. Next, under the training folder there should be at minimum five (5) additional directories: • Bin • Batch • Datrms • Dmp • Tables Bin, Datrms and Dmp Directories From the Bin, Datrms and Dmp directories, the process should be the same as production above. Batch Directory Everything from the Batch directory should be backed up. Tables Directory Everything from the Tables directory should be backed up. GUI Distribution ^ The As-Built Documentation should be reviewed to locate the server and folder name for the RMS distribution files. This folder should be added to the system backup of that server. As mentioned eariier, use the same procedures as described under the CAD/Ti section for the backup if the Oracle or SQL server database files. Tiburon CARS Directories The Directory paths may differ slightly by name; however, the targeted files should not. Look for a Volume named "Programs" (nomnally the D; Volume). There are two directories that need to be backed up: TibCars, and TlbCars Base. GUI Distribution , ^ ^. Sometimes the CARS Server is used as the GUI Distribution for RMS and/or CAD workstation distribution. If your CARS server Is also the GUI Distribution sen/er, please Include these distribution folders in the Daily Backups. These can normally be found under the D: (Program) Volume These folder names should be RMS_Dlstrib, RMS_TI. If your CARS Server is also your Tiburon WEB Application server, please backup the RMS_WEB Directory which is normally found under the D: Volume. A review of the As-Built Documentation will identify the location of all distribution folders. WebQuery Server The WebQuery servers do not contain any user data, only the web page files. All user data is stored on the associated CAD, CARS or RMS server. However, the web page files should be backed up on a regular basis to simplify restoration of the server In the event of hardware failure or data loss. If any of the following folders are on the server they should be backup up: Inetpub, TibRoot Tiburon, RMS_Web. Page 4 of 5 20060803 2^1 Tiburon Master Support Agreement Exhibit 6 Back Up Scheduie & Procedures UNIX® System backups The Tiburon UNIX systems require two types of backups; one for the Tiburon Application and database, and one for the operating system (OS). The OS backup should occur monthly or when any major OS-related or password changes, occur. The OS backup normally backs up just OS volume groups (Logical Volumes) and should be a Bootable Backup (normal place on a tape medium), and provide a complete OS system recovery in case of total equipment loss. The Tiburon Application and database backup should encompass the Tiburon Application file systems, database files, and the output files of the Oracle database backup files, if applicable. The two basic types of Tiburon Application files, CAD (Computer Aided Dispatch) and RMS (Records Management System), are copied to a magnetic media tape device along with the output from the Oracle backup procedures and the RMSDATA backup routines (if required). The Log files used to review the completeness of the Tiburon backup ufilities are normally stored in the UNIX System directory "/tmp/backup or /tmp/backuplogs". The RMS Application system's RMSDATA backup logs are stored in the "/{mount point}/{system type}/log" directory In text log files called "daily.*" The Oracle backup utility stores the Oracle output database files in the filesystem location of "/{mount point}/oracle/orabackup/{$ORACLE_SID}/, /{ mount polnt}/oracle/orabackup/{$ORACLE_SID}", or some variant of that naming convenfion Depending on the magnefic tape device used to store the Tiburon backup data the Tiburon master backup utilities can vary in complexity. The master backup utilities should be launched daily from the system's crontab service. If required, Tiburon will set up the backup process for each Tiburon Application and ensure functionality of the Tiburon-supplied backup scripts. Changes to those scripts shall only be made by Tiburon technical staff. Any changes requested by the Client shall be requested through the Tiburon Account Manager and/or the Tiburon "HEAT" system. Page 5 of 5 20060803 EXHIBIT 7 To Master Support Agreement WARRANTY AND MAINTENANCE GUIDELINES This Exhibit is attached to, incorporated into and forms part of the Master Support Agreement, dated Vc-C.^ 20l<^'between the Client and Tiburon (herein referred to as the "Agreement"). Capitalized terms used herein shall have the definitions set forth In the Agreement, unless otherwise defined herein. In the event of conflict between the terms and conditions set forth herein and those set forth in the Agreement, the terms and conditions set forth in the Agreement shall prevail. ~ This Exhibit shall follow this cover page - Page 1 of 1 Master Support Agreement Exhibit 7, Warranty and Maintenance Guidelines TIBUR#IN Warranty & Maintenance Support - Guidelines & Options October 1, 2013 Tiburon, Inc. 3000 Executive Parkway Suite 500 San Ramon, CA 94583 (925) 621-2700 Warranty & Maintenance Support Version 6.0 Guidelines & Options Table of Contents 1. INTRODUCTION ; 2 2. DEFINITIONS 3 2.1 PROJECT 3 2.2 PROJECT IVIANAGER 3 2.3 WARRANTY / IVIAINTENANCE SUPPORT 3 2.4 CLIENT SUPPORT CENTER (CSC) 3 2.4.1 Helpdesk Specialist 3 2.4.2 CSC Engineer 3 2.4.3 Client Liaison ..' 3 2.4.4 Executive Director - Client Service & Support 4 2.5 TIBURON SERVICE REQUEST (TSR) 4 2.6 PRIORITY 4 2.7 ACCOUNT MANAGER 4 3. TRANSITION FROM PROJECT (OPERATIONS) TO SUPPORT (CSC) 5 4. WORKING WITH THE SUPPORT CENTER (CSC) 6 4.1 SUBMITTING A TSR 6 4.2 TSR PRIORITIES 6 4.3 REPORTING A TSR : 6 4.4 EMERGENCY AFTER HOURS ASSISTANCE 7 4.5 CLIENT RESPONSIBILITIES 1 4.6 SERVICE REQUEST LIFECYCLE 8 4.6.1 TSR Status 8 4.6.2 Case Escalation 9 4.6.3 Case Closure 9 5. OTHER SERVICES 10 5.1 ENHANCEMENT REQUESTS 10 5.2 STEERING COMMITTEE ISSUES 10 5.3 TRAINING REQUESTS 10 5.4 DBA AND SYSTEM ADMINISTRATION SUPPORT SERVICES 11 5.4.1 Level 1 Database Administration (DBA) Support 11 5.4.2 LeveU System Administration Support 11 6. OPTIONAL MAINTENANCE PROGRAMS 12 6.1 "24x7" SUPPORT FOR ADDITIONAL TIBURON SYSTEMS 12 6.2 DATABASE ADMINISTRATION (DBA) SERVICES / SYSTEM ADMINISTRATION (SA) SERVICES 12 7. ADDITIONAL INFORMATION 14 7.1 DOCUMENTATION LIBRARY (COMING SOON) ., 14 7.2 CRYSTAL REPORT / SSRS REPORT SHARING POOL (COMING SOON) 14 7.3 CLIENT TSR REPORTS (COMING SOON) 14 7.4 KNOWLEDGE BASE (COMING SOON) 14 7.5 CUSTOMER FORUM (COMING SOON) 14 7.6 TIBURON USER GROUP 14 7.7 PRODUCT STEERING COMMITTEES 15 Tiburon, Inc. October 1,2013 Page i Warranty & Maintenance Support Version 6.0 Guidelines & Options 1. INTRODUCTION This document provides a description of the service programs avaiiabie to Tiburon's warranty and maintenance clients with a current and valid Master Support Agreement (MSA). This document defines both standard and optional support programs, and outlines the process for woricing with Tiburon to report, track, and resolve issues. NOTE: The service programs and the terms and conditions contained herein are those available as ofthe date of this document; these service offerings, as well as terms and conditions are subject to change without notice. Tiburon, Inc. October 1, 2013 Page 2 Warranty & Maintenance Support Version 6.0 Guidelines & Options 2. DEFINITIONS The following terms are used throughout this document: 2.1 PROJECT A Project is an activity governed by a contract or contract amendment and a statement ofwork. It can be a new implementation for a new client, an upgrade for an existing client, or a modification or add-on application or interface for an existing client. 2.2 PROJECT MANAGER A Tiburon Project Manager is assigned to all projects defined above. The Project Manager is responsible for the successful delivery of all services related to the contract or contract amendment. The Project Manager schedules and coordinates the participation of all Tiburon resources needed to deliver on the contract. The Project Manager reports to a Director in the Operations Division. 2.3 WARRANTY / MAINTENANCE SUPPORT When a Project is completed, the support transitions to a warranty or maintenance support level as defined by the contract. When the Project is deemed completed, the Project Manager conducts a tumover of the client and associated applications to the assigned Client Liaison and the Client Support Center (CSC). 2.4 CLIENT SUPPORT CENTER (CSC) The Client Support Center (CSC) provides 24 x 7 support to all Tiburon clients with a valid and current Master Support Agreement (MSA). CSC staff is comprised ofthe following resource types: 2.4.1 HELPDESK SPECIALIST The Helpdesk Specialists field all telephone calls placed to the CSC and process all email sent to support(gtiburoninc.com. They log all issues and updates received in the third party application used by Tiburon to support all clients, and assign the issues based on established protocols. The Helpdesk Specialists report to the Executive Director - Client Service & Support. 2.4.2 CSC ENGINEER CSC Engineers report to a Team Lead in the CSC who reports to the Executive Director - Client Service & Support. They are responsible resolving for ali issues reported to the CSC and communicating with the client. If additional expertise is needed to resolve an issue, it may be assigned to an individual outside of the CSC for resolution. 2.4.3 CLIENT LIAISON A Client Liaison is assigned to clients with a valid and active Master Support Agreement, and reports to the Executive Director - Client Service & Support. The Client Liaison is the first point of escalation for all client issues reported to the CSC. The Client Liaison works hand-in-hand with each assigned Client to ensure that Tiburon is addressing issues reported to the CSC in a manner that addresses the Client's needs Tiburon, Inc. October 1, 2013 Page 3 Warranty & Maintenance Support Version 6.0 Guidelines & Options in a timely fashion. The Client Liaison conducts regularly scheduled TSR review meetings with their Clients and works with technical staff in the CSC and in other Tiburon departments for issue resolution. 2.4.4 EXECUTIVE DIRECTOR - CLIENT SERVICE & SUPPORT The Executive Director - Client Service & Support is a member of the Tiburon Management Team and reports to the Vice President, Client Service & Support. The Executive Director - Client Service & Support creates policies and procedures related to Client Service and Support, and direct the efforts of all support personnel. The Executive Director - Client Service & Support is die second point of escalation for all issues reported to the CSC. 2.5 TIBURON SERVICE REQUEST (TSR) Issues reported to the Client Support Center (CSC) are referred to as Tiburon Service Requests (TSRs). Each TSR is recorded in the third party application used by Tiburon to record client issues and assigned to the Tiburon team responsible for supporting the client and the system at the time the issue is reported. Priority 1 TSRs are assigned down to an individual resource based on the Tiburon on-call list maintained by the CSC. 2.6 PRIORITY Priority refers to the operational criticality of a specific service request. Tiburon uses a Pl - P4 convention with a Priority 1 issue being defined as an application or server failure that prevents continued use or operation ofthe System, impacts all or substantially all operators using the System, halts or severely impacts critical System operations or endangers the integrity of any database. Complete priority descriptions can be found in section 4.2 ofthis document. 2.7 ACCOUNT MANAGER The Tiburon Account Manager Program has been established to enhance the relationship between our public safety client base and the Tiburon public safety organization. The Account Manager reports to the Senior Vice President, Corporate Development-and Customer Advocacy, and provides a proactive approach to client interaction, enhancing the communications between Tiburon and our clients. The Account Manager acts as an advocate and coordinator on behalf of the client with the existing Tiburon client facing support organizations. The Account Manager is also a regular avenue for communication of emerging technologies and programs from Tiburon that have a positive impact on our clients. Through this relationship Tiburon is able to better understand our clients' current and ftature environment and strategic direction and is better able to align both organizations strategic goals to ensure continued success. The Account Manager program enhances the effectiveness of Tiburon's existing client facing personnel and programs. For active projects, the client still deals directly with the assigned Project Manager on all project-specific issues. On support issues, the client works through the Client Support Center (CSC) and their assigned Client Liaison.. Tiburon, Inc. October 1, 2013 Page 4 Warranty & Maintenance Support Version 6.0 Guidelines & Options 3. TRANSITION FROM PROJECT (OPERATIONS! TO SUPPORT (CSC) At system cutover, the client systems transition from the project phase to the warranty or maintenance programs. Leading up to this major milestone, Tiburon staff members, including the Project Manager, Client Liaison, Account Manager, Engineering, Deployment, and CSC Engineering resources participate in an internal System Assurance Review (SAR). This ensures that all parties are aware of the client configuration, connection information, applications installed, cutover plan and schedule, as well as other information specific to the client implementation. This information is logged in the third party application used by Tiburon for Client Support. When the project has been completed, there is another internal system assurance review between all involved parties to transition the client from Operations / Project mode to CSC / Support mode. The Project Manager schedules a tumover meeting with the client to introduce the Client Liaison to the Client. Tiburon, Inc. October 1,2013 Page 5 ^2 Warranty & Maintenance Support Version 6.0 Guidelines & Options 4. WORKING WITH THE SUPPORT CENTER (CSC) The CSC functions as the single point of contact for ongoing client support issues once the Tiburon applications are live and the project is completed. Tiburon's Client Liaisons oversee the CSC activities for their assigned clients. The Client Liaison also works closely with the Client's Account Manager in order to keep them updated on overall service needs. 4.1 SUBMITTING A TSR Client may contact the CSC to report an issue by telephone, email, or via the third party Self Service application provided for this purpose. Priority 1 issues must be repotted by telephone 24 x 7 to ensure optimum response to the issue. 4.2 TSR PRIORITIES When submitting a TSR, Tiburon asks that clients use the priority definitions below. *tflk)ri#Level Category Deflnition Priority 1 Critical The entire system (i.e.: CAD, Records) or a major component (i.e.: State interface, paging) is unavailable. Client cannot use system to continue operations. Impacts all or most users, halts or severely impacts critical operations, or database integrity is compromised. NOTE: For priority 1 issues, clients must contact Tibiu-on by telephone. With the exception of CAD, Message Switch, and Jail Records support which is "24x7", Clients must have purchased the "24x7" support option to submit Pl issues outside ofbusiness hours (8 am - 5 pm) in the Client's time zone. Priority 2 High A major component or function does not work properly. Impacts an individual or small group, Normal operations impaired, but can continue. Priority 3 Normal Impacts an individual or small group. Service can be delayed until a mutually established time. A workaround may exist, but is inefficient. Priority 4 Informational Issue is informational or educational in nature. Enhancement requests and Steering Committee issues should be reported as Priority 4 TSRs. 4.3 REPORTING A TSR The preferred method of contact for CSC for Client issues is outlined in the table below: I'i Issue 1 Priority •f Service ^ | ITcliTred Contact Method Priority 1 24 hours a day, 7 days a week, 365 days a year Contact the CSC via Telephone CSC Telephone: 877.445.2110 Backup Phones: 925.621.2720 Tiburon, Inc. October 1,2013 Page 6 43 Warranty & Maintenance Support Version 6.0 Guidelines & Options Priority 2 thru Priority 4 8 am-5 pm in the Client's time zone Submit a case via telephone, email, or the third party Self Service application provided. 510.579.4609 510.579.1714 If for any reason Clients cannot reach us on the toll free number. Clients can reach us on our backup phones. Please call the altemate number(s) in the order listed. Email: support(S),tiburoninc.com Self Service Access: http://CSC.tiburoninc.com:81 SO/HeatWebUI/hss/HSS.isn Priority 2 thru Priority 4 8 am-5 pm in the Client's time zone Submit a case via telephone, email, or the third party Self Service application provided. 4.4 EMERGENCY AFTER HOURS ASSISTANCE Emergency assistance after regular business hours is subject to the following special condition: "24x7" support is standard for all CAD, Corrections, and Message Switch systems. If a Client selects the "24x7" service option for any other Tiburon applications, remote support for Priority 1 TSRs for those applications is also provided on a 24 x 7 basis. If a Client requests after hours support for an application without "24x7" coverage, support is subject to a call-out fee in addition to time and materials charges. 4.5 CLIENT RESPONSIBILITIES In order to provide maintenance support services to clients, Tiburon requires that clients: • Limit TSRs to one reported problem in each TSR logged. • Include enough pertinent detail in a reported problem to effectively reproduce and diagnose it. • Provide physical access to the system during normal business hours when needed, and have a technical resource reachable afterhours that Tiburon staff can contact should the need arise. • Maintain remote access along with the ability to upload and download files to server(s) without third-party interaction • Restrict the use of CAD workstations to Tiburon Applications only, eliminating internet connectivity and the use of things like sti-eaming media, internet games and other applications that can negatively interact with the CAD system. • Ensure that maintenance and back-up activities relating to the Covered Applications and the System, including, without limitation, backing up databases and joumal logs, purging out of data records, running reports, and performing diagnostics, are carried out in accordance with the schedule and methodology laid out by Tiburon. • Ensure that the System conforms to the "Site System and Network Specifications". • Maintain a system to ensure that only authorized personnel have the ability to make changes to the Client's database and that a list of all such authorized personnel (and any updates thereto) be promptly delivered to the Tiburon Application Support Center. Each request for any change to a Client's database shall be accompanied by a signed letter of authorization from the Client's Authorized Client Representative, and shall contain all details of the requested change. Tiburon cannot assist Client personnel other than those on the most current authorization list. • Designate a single individual to act as the Client's authorized representative who is (a) authorized to act on the Client's behalf wath respect to all matters relating to this Agreement; (b) shall ensure the Client's compliance with its responsibilities under this Agreement; and (c) shall coordinate appropriate schedules in connection with Tiburon's services under this Agreement. The Client may Tiburon, Inc. October 1,2013 Page 7 li L Warranty & Maintenance Support Version 6.0 Guidelines & Options change the individual designated hereunder by providing Tiburon advance written notice designating the new individual authorized to act as the Client Representative. Ensure that Technical Support Coordinators and other personnel have received sufficient training on all aspects of flie Tiburon system that they are supporting, and have the experience to perform its obligations. 4.6 SERVICE REQUEST LIFECYCLE The TSR lifecycle can vary depending on the complexity of the issue being reported. Some TSRs will move from "Open" to "In Progress" and "Closed" without a need for validation. Other TSRs require a validation step where the TSR is first "fixed" in the Client's Training system and validated with the Client before moving to Production and tiien placed in "Test Request" status for final client confirmation prior to closure. Our CSC team works with clients to not only validate the resolution of the case, but to confirm the resolution prior to closing it. 4.6.1 TSR STATUS As a TSR moves through Tiburon's service request lifecycle the overall case stattis will change, statuses and definitions below are those currently in use: The Case Status Definition New Defauh status used for all 'new' cases coming into the CSC. TSRs in "New" status reflect no one is currentiy assigned to research or resolve the issue. Once the Project Manager or Client Liaison discusses new issues with their client, the issue is prioritized for resolution and the appropriate Team Leader is notified for assignment. In Progress StatiJS used to indicate TSR has been assigned to an individual for resolution. Failed QA Test Statijs used to indicate that fix did not pass Tiburon QA testing. Failed Client Test Stattis used to indicate fix did not pass client's testing. Need Info Status used to indicate that the additional information is needed to resolve the TSR. Information needed is detailed in the Status / Solution field. A TSR in NEED INFO status for 30 or more calendar days witiiout any update will be closed. Ifthe issue occurs again, it should be reported as a new issue witli supporting information and screen sliots if applicable. On Hold Status used to place TSR in a HOLD state pending action by Tiburon or action by the Client. Pending action will be detailed in the Status / Solution field. A TSR in ON HOLD status for 30 or more calendar days without any update will be closed. Ifthe issue occurs again, it should be reported as a new issue with supporting information and screen shots if applicable Pending Engineering Status used to indicate that the issue has been reassigned from the CSC to Engineering for resolution. Monitor Status used to indicate TSR is currentiy in 30-day monitor period. Usually used to monitor recurrence of an issue after implementation of a fix (typically when complete validation is not feasible). Also used when issue cannot be readily investigated pending occurrence of another event. A TSR in MONITOR status for 30 or more calendar days without any update wili be closed. Ifthe issue occurs again, it should be reported as a new issue with supporting information and screen shots if applicable. Tiburon, Inc. October 1,2013 Page 8 Warranty & Maintenance Support Version 6.0 Guidelines & Options Test in TRN Stattis used to indicate that a fix has been implemented in client's ttaining system. Testing by client and confirmation of fix is required before fix will be moved to client's production environment It is important that TSRs in this status are addressed by client within 30 calendar days so that untestedfixes do not remain in the client's system for an unreasonable period of time. It is impossible to manage clean code lines with potential faes that have not been tested as requested. Test Request Status used to indicate that fix has been applied in the client's production system. Validation of fix by the client is required, however, A TSR in TEST REQST status for 30 or more calendar days without any update will be closed. Ifthe issue occurs again, it should be reported as a new issue with supporting information and screen shots if applicable. Closed Stattis used to indicate that the TSR has been closed with the concurrence of the client (or 30 days have passed with no further communication from the client, as noted above). Once in Closed stattis, a TSR is no longer editable to any other status. 4.6.2 CASE ESCALATION If for any reason a Client feels that a TSR needs to be escalated for resolution, the first point of contact is the assigned Project Manager or Client Liaison. If this escalation does not produce an acceptable plan and resolution, the second point of contact is the Operations Director (for projects) or the Executive Director - Client Service & Support. 4.6.3 CASE CLOSURE The CSC staff will work with clients to validate TSR resolution prior to closure. Once an issue has been validated by the client, Tiburon will confirm and close the case. If after 30 calendar days there has been no communication from the Client advising that the issue has not been resolved, the CSC staff will close the case. Tiburon, Inc. October 1,2013 Page 9 Warranty & Maintenance Support Version 6.0 Guidelines & Options 5. OTHER SERVICES 5.1 ENHANCEMENT REQUESTS Enhancement Requests may be identified in several ways: • In evaluating a TSR, it is determined that the existing solution is fimctioning as designed. • A Client wants to extend their Tiburon solution or obtain additional optional services, and requests a quote for new functionality. Once a TSR is identified as an enhancement request, die case is updated to reflect this and assigned to the Client Liaison. The Client Liaison contacts and advises the Client ofthe new classification. The TSR is then assigned to the Account Manager and the TSR is closed. Once the Account Manager is notified of this request, the following actions occur: • The Account Manager works with the Client to clarify the request and produce the requirements for Engineering to quote the request • Engineering and/or Operations evaluates the request, determining the mix of customized development, configuration, testing and documentation required to deliver the request • The Account Manager takes the information from Engineering and produces a quote for die Client • The Client is asked to review and either accept or reject the proposed enhancement. • Once the enhancement proposal is accepted, the delivery is handled by Tiburon's Operations Department. 5.2 STEERING COMMITTEE ISSUES Clients can submit a Steering Committee request for discussion and potential inclusion in Tiburon's baseline when they encounter a situation where a system change or additional feattire would enhance the functionality ofthe system. Steering Committee requests can be submitted via the Self Service application using the Call Type of Steering Committee. Steering Committee cases are assigned to a Tiburon Product Manager and the TSR is placed in an ON HOLD stattis. After the issue is vetted at the Tiburon User Group, the issue is updated with the recommendations ofthe Steering Committee and Closed. 5.3 TRAINING REQUESTS Tiburon's Training Team is available to work with clients. Each member on Tiburon's Training Teatn is a subject matter expert in specific Product. They support the implementation ofeach Client solution through configuration, validation, testing and training. After the Tiburon Applications are live, clients who have additional needs for training can work with their Account Manager to create a custom, fee- based program. Tiburon, Inc. October 1,2013 Page 10 7 Warranty & Maintenance Support Version 6.0 Guidelines & Options 5.4 DBA AND SYSTEM ADMINISTRATION SUPPORT SERVICES 5.4.1 LEVELI DATABASE ADMINISTRATION (DBA) SUPPORT Level 1 Database Administration (DBA) Support is a standard feattire of Tiburon's Master Support Agreement (MSA). Level 1 DBA Support services include the creation of production and ttaining databases to be used by the Tiburon applications for clients that do not have their own database administtation (DBA) capabilities. Database services offered as part of the Level 1 DBA Support do not include preventive monitoring of the Client's databases. The Client's DBA is responsible for periodic database backups, backup functionality monitoring, periodic database maintenance, and database recoveries in the event of disaster. During the project phase, before "go live," Tiburon is available to assist with the database backup configuration. Thereafter, Tiburon will be available primarily for consultation to diagnosis/resolve database problems that are directly related to the Tiburon applications. 5.4.2 LEVELI SYSTEM ADMINISTRATION SUPPORT Tiburon provides Level 1 System Administration (SA) Support as a standard feature of the Master Support Agreement (MSA). For clients who have qualified System Administtators, this plan provides the minimum assistance needed to ensure that operating systems, hardware, and networking function properiy to support the Tiburon applications. Tiburon will provide support ranging from information-only, to applying minor changes (designation of minor change reserved to Tiburon), to providing resolution only for problems that may be encountered by supported Tiburon applications. Tiburon, Inc. October 1,2013 Page u Warranty & Maintenance Support Version 6.0 Guidelines & Options 0. OPTIONAI MAINTENANCE PROGRAMS Tiburon's Account Manager will work with the Client to identify the support programs that meet Client needs and to develop associated pricing. The matrix below describes the standard Level 1 services as well as the Level 2 and Level 3 services offered. 6.1 "24x7" SUPPORT FOR ADDITIONAL TIBURON SYSTEMS "24x7" support is standard for all CAD Products. It is optionally available for all other products. For assistance in adding this support for other systems, clients should contact their Account Manager. 6.2 DATABASE ADMINISTRATION (DBA) SERVICES / SYSTEM ADMINISTRATION (SA) SERVICES Tiburon offers optional added-cost Database Administration Support and System Administtation service plans including Level 2 and Level 3 Extended Services. These Service Levels are compared side by side in the matrix below. ' Database Services Level 1 1 evel 2 i Level t Set UD aonlication databases / Set up database backup to disk / Expand database disk space allocations as needed / Support for Database Issues on Tiburon Applications Business Day (8x5) 24x7 24x7 * ' ' Maintain Database Backup Scripts / 24x7 Support for Database Issues on Tiburon Applications / " ^ — Disaster Recoverv Planning and Set-Up ./ Perform Database Recovery Procedures ./ Monthly Report Maintain database system accounts and passwords / 3"^ Party support login access Twice Monthly Database Health Check & Maintenance •/ Database Upgrade Support Monitoring of Backup Logs Monthly 2x Monthly Examination of Backup Tapes Monthly 2x Monthly Database Health Check & Maintenance Monthly 2x Monthly Database Tuning & Performance Monitoring Monthly 2x Monthly Rebuild Indexes Annually 2x Annually Recovery Dry Run Annually 2x Annually Tiburon, Inc. October 1,2013 Page 12 Warranty & Maintenance Support Version 6.0 Guidelines & Options 1,; Systems .Administration Services *' Level I *Xevel2 Le v el Backup Planning Consultation and Scripts (UNIX only) / Set-Up of Backup Scripts (UNIX only) / High-Availability Cluster Application Restart y / Expansion of File system Disk space Allocations Application of Operating System Patches for Tiburon Applications Remote Monitoring for System Health Business Day (8x5) 24x7 Support Perform Application Backup Activities Business Day (8x5) 24x7 Support Operating Systems, Hardware and Networking Assistance Business Day (8x5) 24x7 Support Remote System Administration 24x7 Support Perform Performance Analysis, Report and Adjustments to System Performance Parameters Annually Review of Hardware and operating System on Named Services and Provide a Written Report Monthly Tiburon, Inc. October 1,2013 Page 13 Warranty & Maintenance Support Version 6.0 Guidelines & Options 7. ADDITIONAL INFORMATION 7.1 DOCUMENTATION LIBRARY (COMING SOON) All current-version baseline documentation is posted in the Documentation Library for Client access and download. This includes documentation for all cu.rrent product version baseline releases. A link to this Documentation Library can be found on the Tiburon Support Website. 7.2 CRYSTAL REPORT / SSRS REPORT SHARING POOL (COMING SOON) Clients can submit Crystal Reports or SSRS Reports to be posted in the Sharing Pool, which will accessible by all Tiburon clients. 7.3 CLIENT TSR REPORTS (COMING SOON) Standard SSRS Reports are available for clients to obtain a formatted report of their TSRs or a non- formatted report in csv format. Reports may include all Open Cases (not closed) or All Cases regardless of status. 7.4 KNOWLEDGE BASE (COMING SOON) Clients can submit a string search against Call Description and Status/Solution data in the HEAT database to see if an issue had been submitted and a resolution is available to a common issue. The inquiry can also be filtered by System Type. 7.5 CUSTOMER FORUM (COMING SOON) The Customer Fomm will allow communications between Tiburon clients on common issues or topics. 7.6 TIBURON USER GROUP The Tiburon User Group provides an important vehicle for communicating with other users and Tiburon staff Each year, Tiburon hosts a User Group conference, offering training sessions, presentations and product demonstrations. The annual conference enhances communication among users, introduces new products and product upgrades, and provides working sessions focused on specific areas of user interest. Each agency can send as many representatives to the annual conference as desired, at the then ciurent per attendee registtation fee. The attendee fees help to offset a portion of the expenses we incur to ensure a high-quality event for our clients. Tiburon, Inc. October 1, 2013 Page 14 Warranty & Maintenance Support Version 6.0 Guidelines & Options 7.7 PRODUCT STEERING COMMITTEES Product Steering Committees allow Tiburon clients to participate in product development and direction for all major Tiburon applications. Each Product Steering Committee is composed of a chairperson elected by the Tiburon User Group, and up to five additional members selected by the chairperson. The Product Steering Committee members solicit input from Tiburon clients licensed for each product line, and compile suggested product changes to discuss at the annual Product Steering Committee meetings, which are held in the spring. A Tiburon product advocate and Tiburon product technical lead attend the annual Product Steering Committee meetings. Each session begins with a full demonstration of the current product version, followed by a discussion of potential changes and enhancements. As a result of these discussions, the Product Steering Committees determine which changes will be applied to the next product version. Product Steering Committee information is accessible via the password protected area of Tiburon's website. Posted information includes annual Product Steering Committee Enhancement lists, as well as Product Steering Committee issues submitted by clients for discussion at the next annual Product Steering Committee meeting. Tiburon, Inc. October 1,2013 Page 15 CERTIFICATE OF LIABILITY INSURANCE DATE(MM/DDA'YYY) 09/12/2014 THIS CERTIFICATE IS ISSUED AS A MATTER OF INFORMATION ONLY AND CONFERS NO RIGHTS UPON THE CERTIFICATE HOLDER. THIS CERTIFICATE DOES NOT AFFIRMATIVELY OR NEGATIVELY AMEND, EXTEND OR ALTER THE COVERAGE AFFORDED BY THE POLICiES BELOW. THiS CERTiFiCATE OF INSURANCE DOES NOT CONSTITUTE A CONTRACT BETWEEN THE ISSUING INSURER(S), AUTHORIZED REPRESENTATIVE OR PRODUCER, AND THE CERTIFICATE HOLDER. IMPORTANT: If the certificate holder is an ADDITIONAL iNSURED, the policy(ies) must be endorsed. If SUBROGATiON IS WAIVED, subject to the terms and conditions of the policy, certain poiicies may require an endorsement. A statement on this certificate does not confer rights to the certificate holder in iieu of such endorsement(s). PRODUCER Aon Risk Insurance Services west, Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 LOS Angeles CA 90017-0460 USA CONTACT NAME: PRODUCER Aon Risk Insurance Services west, Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 LOS Angeles CA 90017-0460 USA K.Ex.): «6« 283-7122 fAX 800-363-0105 PRODUCER Aon Risk Insurance Services west, Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 LOS Angeles CA 90017-0460 USA E-MAJL ADDRESS: PRODUCER Aon Risk Insurance Services west, Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 LOS Angeles CA 90017-0460 USA INSURERISI AFFORDING COVERAGE NAICtf INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER A Pacific Indemnity Co 20346 INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER B Federal Insurance Company 20281 INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER C Continental Casualty Company 20443 INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER D INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA iNSURER E INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER F 2 o X COVEFIAGES CERTiFiCATE NUiVIBER: 570055110893 REVISION NUiVIBER: THIS IS TO CERTIFY THAT THE POLICIES OF INSURANCE LISTED BELOW HAVE BEEN ISSUED TO THE INSURED NAMED ABOVE FOR THE POLICY PERIOD INDICATED NOTWITHSTANDING ANY REQUIREMENT, TERM OR CONDITION OF ANY CONTRACT OR OTHER DOCUMENT WITH RESPECT TO WHICH THIS CERTIFICATE MAY BE ISSUED OR MAY PERTAIN, THE INSURANCE AFFORDED BY THE POLICIES DESCRIBED HEREIN IS SUBJECT TO ALL THE TERMS, EXCLUSIONS AND CONDITIONS OF SUCH POLICIES. UMITS SHOWN MAY HAVE BEEN REDUCED BY PAID CLAIMS. Limits shown are as requested PfiLlfiV EFF (MM/DD/YYYYl 59/51/2014 Tusir LTR TYPE OF INSURANCE INSD OTR] WVD POLICY NUMBER PfiLliV EXP MM/DD/YYYYl -mums COMMERCIAL GENERAL LIABILITY CLAIMS-MADE j X I OCCUR 35911053 EACH OCCURRENCE 0c DAMAGE TO RENTED PREMISES (Ea occurrence) MED EXP {Any one person) PERSONAL & ADV INJURY GEN'L AGGREGATE LIMIT APPLIES PER: POLICY [7]^^^^°; [7] LOC GENERAL AGGREGATE PRODUCTS - COMP/OP AGG AUTOMOBILE LIABILITY 7355-87-29 09/01/2014 09/01/2015 COMBINED SINGLE LIMIT (Ea accident) ANY AUTO ALL OWNED AUTOS HIRED AUTOS BODILY INJURY ( Per person) UMBRELLA LIAB EXCESS LIAB SCHEDULED AUTOS NON-OWNED AUTOS BODILY INJURY (Per accident) PROPERTY DAMAGE (Per accident) OCCUR CLAIMS-MADE L4030957581 09/01/2014 09/01/2015 EACH OCCURRENCE DED RETENTION WORKERS COMPENSATION AND EMPLOYERS' LIABILITY ANY PROPRIETOR / PARTNER / EXECUTIVE OFFiCER/MEMBER EXCLUDED? (Mandatory in NH) If yes, descnbe under DESCRIPTION OF OPERATIONS below 71739717 09/01/2014 09/01/2015 Y PER STATUTE OTH- ER E.L. EACH ACCIDENT E.L. DISEASE-EA EMPLOYEE E.L, DISEASE-POLICY LiMIT $1,000,000 $1,000,000 $10,000 $1,000,000 $2,000,000 $2,000,000 $1,000,000 $10,000,000 $10,000,000 $1,000,000 $1,000,000 $1,000,000 r o DESCRIPTION OF OPERATIONS / LOCATIONS / VEHICLES (ACORD 101, Additional Remarits Schedule, may be attached if more space is required) City of carlsbad, its officers, employees, and volunteers are included as additional insureds under the general liability coverage as required by contract with the named insured. CERTIFICATE HOLDER CANCELLATION city of Carlsbad Attn: Senior Systems Administrator 2560 Orion Way Carlsbad CA 92008 USA SHOULD ANY OF THE ABOVE DESCRIBED POLICIES BE CANCELLED BEFORE THE EXPIRATION DATE THEREOF, NOTICE WILL BE DELIVERED IN ACCORDANCE WiTH THE POLICY PROViSIONS. city of Carlsbad Attn: Senior Systems Administrator 2560 Orion Way Carlsbad CA 92008 USA AUTHORIZED REPRESENTATIVE ©1988-2014 ACORD CORPOF?ATION. All rights reserved. ACORD 25 (2014/01) The ACORD name and logo are registered marl<s of ACORD CERTIFICATE OF PROPERTY INSURANCE DATE CMM/DD/YYYY) 09/12/2014 THIS CERTIFICATE IS ISSUED AS A MATTER OF INFORMATION ONLY AND CONFERS NO RIGHTS UPON THE CERTIFICATE HOLDER. THIS CERTIFICATE DOES NOT AFFIRMATIVELY OR NEGATIVELY AMEND, EXTEND OR ALTER THE COVERAGE AFFORDED BY THE POLICIES BELOW. THIS CERTIFICATE OF INSURANCE DOES NOT CONSTITUTE A CONTRACT BETWEEN THE ISSUING INSURER(S), AUTHORIZED REPRESENTATIVE OR PRODUCER, AND THE CERTIFICATE HOLDER. If this certificate is being prepared for a party who has an insurable interest in the property, do not use this form. Use ACORD 27 or ACORD 28. PRODUCER Aon Risk Insurance Services west. Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 Los Angeles CA 90017-0460 USA COIJTACT NAME: PRODUCER Aon Risk Insurance Services west. Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 Los Angeles CA 90017-0460 USA r/Sc°.'Nc.E.,): (866) 283-7122 800-363-0105 PRODUCER Aon Risk Insurance Services west. Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 Los Angeles CA 90017-0460 USA E-MAIL ADDRESS: PRODUCER Aon Risk Insurance Services west. Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 Los Angeles CA 90017-0460 USA CUST^IRID.: 570000051058 PRODUCER Aon Risk Insurance Services west. Inc. LOS Angeles CA Office 707 wilshire Boulevard Suite 2600 Los Angeles CA 90017-0460 USA iNSURER(S) AFFORDING COVERAGE NAiC # INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA iNSURERA Federal Insurance Company 20281 INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER B INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER C INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURERD INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER E INSURED Tiburon, Inc. 3000 Executive Parkway, Suite 500 San Ramon CA 94583 USA INSURER F COVERAGES CERTiFiCATE NUMBER: 570055110828 REVISION NUIVIBER: LOCATION OF PREMISES/ DESCRIPTION OF PROPERTY (Attach ACORD 101, Additional Remarics Schedule, if more space is required) THIS IS TO CERTIFY THAT THE POLICIES OF INSURANCE LISTED BELOW HAVE BEEN ISSUED TO THE INSURED NAiWED ABOVE FOR THE POLICY PERIOD INDICATED NOTWITHSTANDING ANY REQUIREMENT, TERM OR CONDITION OF ANY CONTRACT OR OTHER DOCUMENT WITH RESPECT TO WHICH THIS CERTIFICATE MAY BE ISSUED OR MAY PERTAIN, THE INSURANCE AFFORDED BY THE POLICIES DESCRIBED HEREIN IS SUBJECT TO ALL THE TERMS, EXCLUSIONS AND CONDITIONS OF SUCH POLICIES. LIMITS SHOWN MAY HAVE BEEN REDUCED BY PAID CLAIMS. INSR LTR TYPE OF INSUFiANCE POLiCY NUMBER POLiCY EFFECTIVE DATE (MIUI/DD/YYYY) 09/01/2014 POLiCY EXPIRATiON DATE (MM/DD/YYYY) 09/01/2015 COVERED PROPERTY X PROPERTY CAUSES OF LOSS EARTHQUAKE 55W1655 DEDUCTIBLES BUILDiNG PERSONAL PROPERTY BUSINESS INCOME w/o Extra Expense EXTRA EXPENSE RENTAL VALUE BLANKET BUILDING BLANKET PERS PROP BUVNKET BLDG & PP ALL RISK-Subject to Exclusions Bikt PP Ded X INLAND MARINE CAUSES OF LOSS NAMED PERILS All Risk TYPE OF POLiCY Contractors Eqp POLICYNUMBER 35911023 ..09/01/2014 09/01/2015 Scheduled Equipment Scheduled Equipment CRIME TYPE OF POLICY BOILER & MACHINERY / EQUIPMENT BREAKDOWN SPECIAL CONDITIONS / OTHER COVERAGES (Attach ACORD 101, Additional Remarks Schedule, if more space Is required) City of Carlsbad Attn: Senior Systems Administrator 2560 Orion Way Carlsbad CA 92008 USA SHOULD ANY OF THE ABOVE DESCRIBED POLICIES BE CANCELLED BEFORE THE EXPIRATION DATE THEREOF, NOTICE WILL BE DELIVERED IN ACCORDANCE WITH THE POLICY PROVISIONS. City of Carlsbad Attn: Senior Systems Administrator 2560 Orion Way Carlsbad CA 92008 USA AUTHORIZED REPRESENTATIVE ACORD 24 (2009/09) © 1995-2009 ACORD CORPORATION. All rights reserved. The ACORD name and logo are registered marks of ACORD /XCORD AGENCY CUSTOMER ID: 570000051058 LOC#: ADDITIONAL REMARKS SCHEDULE page _ of AGENCY Aon Risk Insurance services west, inc. NAMED INSURED Tiburon, Inc. POLICY NUMBER See Certificate Number: 570055110828 NAMED INSURED Tiburon, Inc. CARRIER See certificate Number: 570055110828 NAIC CODE NAMED INSURED Tiburon, Inc. CARRIER See certificate Number: 570055110828 NAIC CODE EFFECTIVE DATE: ADDITIONAL REMARKS THIS ADDITIONAL REMARKS FORM IS A SCHEDULE TO ACORD FORM, FORM NUMBER: ACORD 24 FORM TITLE: Certificate of Property Insurance INSURER(S) AFFORDING COVERAGE NAIC n INSURER INSURER INSURER INSURER Ifa policy below does not include limit information, refer to the corresponding policy on the ACORD ADDITIONAL POLICIES certificate form for policy limits. INSR LTR TVPE OF INSURANCE POLICV NUIVIBER POLICV EFFECTIVE DATE (IVIM/DD/VVYV) POLICV EXPIRATION DATE (MM/DD/VVVV) COVERED PROPERTV INLAND MARINE installtn Flotr 35911023 09/01/2014 09/01/2015 Installation $2,000,000 ACORD 101 (2008/01) © 2008 ACORD CORPORATION. All rights reserved. The ACORD name and logo are registered marks of ACORD THIS DOCUMENT HAS A TRUE DOCUCHECK'" WATERMARK AND VISIBLE FIBERS DISCERNIBLE FROM BOTH SIDES NOT TRANSFERABLE BUS. NUMBER 1218302 •; ' DATEISSUEO i , 5/29/2014 • (SIC CODE 737c1 , OWNER FIRM OR (MRPbRATION NAME . BUSINESS NAME MAILINQ ADDRESS: CITY AND STATE GITY OF CARLSBAD"^ \ ' / (JOSf IN CONSPICUOUS PtACE ^ 1635 Faraday Ave, Carlsbad CA 92008 ( ' \ :. J ,' BUSINESS ^GISTRATION CERTIFICATE IhapanM.ftmiveaqMrailMnkMd b«rw.l* AniMtlib.bMlMMMrtilVMltfwfuM .'HwllMmMlsul4«cttoer«nmf^^k«fMlnsliyllw8Maa^ -• i^'".-"*') .: •.:.'.^. . .'y SIC DESCRIPTION . : ,\ Computer Programming Services TIBURON, INC. TIBURON, INC 3000 EXECUTIVE PKWY STE 500 SAN RAMON, CA :9^583-2300 BUSINESS:tOCATION 3000 EXEGIJTIVE PKVVY STE 500 EXPIRATION DATE , ,,; <•'.-• 1/31/2015 KEEP FOR YOUR RECORDS BUSINESS TAX RECEIPT , BUS. NO. 1218302 DATE ISSUED 5/29/2014 SB1186 Penalty , 08.010(35) $1.00 $37.87 $75.75 r BALANCE $0.00 TAXES PAID IN ACCORDANCE WITH CITY BUSINESS TAX ORDINANCE CITYOFCARLSBAD THIS DOCUMENT IS ALTERATION PROTECTED AND REFLECTS FLUORESCENT FIBERS UNDER UV LIGHT