8M
Date: December 2, 2025
To: Honorable Mayor and Members of the City Council
From: Andrei Yermakov, Information Technology Director
By: Jillian Wade, Sr. Administrative Analyst | [email protected] Subject: Information Technology – Appropriate Funds and Approve a Master Software and Services Agreement for Computer-Aided Dispatch (CAD) System. Expenditure:
Approximately $7,604,992 (General Fund & Non-General Fund: Approximately $760,499.20 Annually) .
RECOMMENDATION
Recommendation of the Information Technology Director that City Council:
1. Appropriate $592,704 from the Capital Improvement Fund, $350,000 from the Measure SST Fund, and $1,142,955 from the Asset Forfeiture Fund to the Computer Aided Dispatch Implementation project (OP50-OP0014); and
2. Approve a master software and services agreement and related service schedules with Versaterm Public Safety US, Inc of Delaware, for an amount of approximately $7,604,992, for the acquisition, implementation, and annual subscription of a Computer-Aided Dispatch (CAD) System to support Torrance Public Safety, for a ten-year period beginning December 3, 2025, and ending December 31, 2035.
FUNDING
Funding is available from the following funding sources:
Funding Source Amount
Computer Aided Dispatch Implementation Project (OP50-OP0014) - Capital Improvement Fund (Pending Appropriation)
$592,704
Computer Aided Dispatch Implementation Project (OP50-OP0014) - Measure SST Fund (Pending Appropriation)
$350,000
Computer Aided Dispatch Implementation Project (OP50-OP0014) - Asset Forfeiture Fund (Pending Appropriation)
$1,142,955
Information Technology Department General Fund Operating Budget (Annual Subscription)*
$5,519,333
Total $7,604,992
*Funding for the annual subscription costs for years 2-10 is anticipated to be available in the fiscal year 2026-27 operating budget and is anticipated to be available in subsequent fiscal years. 1 City Council
December 2, 2025
DISCUSSION
The City’s current Computer-Aided Dispatch (CAD) system, which serves both the Police and Fire Departments, has reached the end of its serviceable life. The existing system lacks the functionality, integration, and reliability needed to meet the operational demands of modern public-safety dispatching. Replacement of this system is necessary to ensure continued service continuity, enhance operational efficiency, and align with current technology standards for emergency response systems.
The proposed integrated public-safety platform will replace the existing CAD system and provide a unified solution to support dispatch operations and field units in both departments. The new system offers enhanced interoperability, improved data sharing, and modern cloud-based capabilities that will strengthen communication between dispatchers and first responders, improve incident management, and support future scalability.
The total procurement request includes a one-time onboarding services fee covering implementation, data migration, configuration, and user training. It also includes a multi-year subscription for software licensing, hosting, and technical support. The proposed ten-year agreement includes a fixed five percent (5%) annual increase, which provides cost predictability and establishes a long-term partnership with a proven public-safety technology provider.
ATTACHMENT
1. Master Subscription Agreement – Versaterm Public Safety US, Inc. 2 3
ATTACHMENT 1
4 5
6 7
8 9
10 11
12 13
14 15
16 17
18 19
20 21
22 23
24 25
26 27
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 1
4 1
5 0
EXHIBIT B
CAD SAAS SERVICE SCHEDULE FOR CLOUD
28 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 2
4 1
5 0
Service Schedule – CAD SaaS
1. This Service Schedule No. 001 is effective as of 10/21/2025 and is made by City of Torrance ("Customer") and Versaterm Public Safety US, Inc. ("Versaterm"). This "Service Schedule" and its schedules (if applicable) are incorporated into that certain Master Software and Services Agreement dated 10/21/2025, between Customer and Versaterm ("MSA"). The terms and conditions that are specific to this Service Schedule are set forth herein.
In the event of a conflict between the provisions of this Service Schedule and the Master Agreement, the provisions of Section 2 a) of the MSA shall control such conflict. Capitalized terms herein will have the meanings set forth in the MSA or the "Definitions" as further defined below.
2. Definitions
Any capitalized word or term used in this Service Schedule but not otherwise defined herein shall have the meaning given to it in the Master Software and Services Agreement.
2.1. “Critical Priority Error” means complete system failure where the Subscription Service is not available for use.
2.2. “High Priority Error” means a serious problem that materially affects the operational use of the Subscription Service.
2.3. “Major Enhancement Release” means a change or new release of the Subscription Service then in use by the Customer containing new functions, features and enhancements that have become part of the standard system.
2.4. “Minor Enhancement Release” means a change or new release of the Subscription Service then in use by the Customer designed to correct Problem(s) and/or provide minor functionality additions.
2.5. “On-Site Software” means Software, as defined in the MSA, that are installed and used on Customer’s own systems or premises, on the license terms set out herein.
2.6. “Problem” means a failure of the Subscription Service to function substantially in accordance with the Documentation.
2.7. "Production Use" means the use of one or more functional application components to collect and manage real customer information for the purpose of serving actual customer needs; this is in contrast to "testing mode", where real customer information may be used, but only for the purpose of evaluation and testing.
2.8. “Support Authority” means the Customer’s designated employee(s) authorized to approve additional, separately billable time & materials support work, beyond that included in this Service Schedule.
2.9. “Support Contact” means Customer’s designated employee, a consultant providing services directly to the Customer, or another designated Customer representative with whom Versaterm will communicate when providing Support. The Support Contact must be knowledgeable about how the Subscription Service is being used and must be familiar with the operating environment under which it is being used.
2.10. “Source Code” means a collection of computer instructions written using a human-readable programming language. Source Code includes all material including, but not limited to, design documentation, User Documentation, reference manuals, libraries for the Software, and interface software, in any form (printed, electronic, or magnetic).
2.11. “Third Party Application” means a third-party service by a Third-Party Provider(s) approved by Versaterm to which the Customer and any Authorized User facilitates Versaterm’s access to, and use of the Subscription Service, via an application programming interface or other means.
2.12. “Third Party Components” means any components of the Subscription Service provided by third parties, including open-source components and third-party proprietary software or services (e.g. Amazon Web Services (AWS)).
29 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 3
4 1
5 0
2.13. “Third Party Data” means any data owned by a third party that the Customer accesses via the Subscription Service
2.14. “Third-Party Providers” means third parties, including other vendors, federal agencies, state/provincial agencies, and local agencies that control products and/or databases with which the Subscription Service are to be interfaced but for the avoidance of doubt shall not include any Third-Party Suppliers.
2.15. “Third Party Suppliers” means any party who provides products and/or services, including Open-Source Software and Third-Party Components that contribute to the overall Subscription Service provided to the Customer by Versaterm.
2.16. “Versaterm Certified Browsers” means acceptable browsers on which Versaterm shall operate its Software. This internal list shall be maintained by Versaterm.
3. Service Schedule Information
3.1. Software and Authorized Users
• Authorized Users
Authorized
Police Sworn Count: 219
Fire Sworn Count: 153
Total 372
The following Software are provided by Versaterm to the Customer:
Versaterm vCAD Police/Fire
Production vCAD Desktop Licenses (Call Taking / Dispatching) Training vCAD Desktop Licenses
Test/QA vCAD Desktop Licenses
Remote vCAD Licenses
Browser Status Screen (BSS) – For Police/Fire
VGI GIS Maintenance Tool
vCAD AVL Integration
AVL Server (to receive GPS from external devices)
Police MDT vCAD Link + AVL Licenses (Concurrent Use)
Police vMobile vCAD Link + AVL Licenses and GPS Tracking (Concurrent Use) Versaterm MDT: Police MDT Licenses
MDT NCIC I/F Licenses
MDT CAD Link Licenses
MDT AVL License
MDT Mapping Licenses
Versaterm Message Controller (VMC)
vMobile
Based on the full scope of work as initially proposed , the following interfaces are provided by Versaterm to the Customer:
JDIC/CLETS/NCIC
Motorola Vesta (https://www.vestapublicsafety.com/solutions/ng911.php) Versaterm GIS (ESRI) Interface
AXON Police RMS Call-For-Service transfer
Fire RMS Call-For-Service transfer
Motorola Radio MCC7500 Radio Push-to-Talk/Emergency
Eventide Voice Recording
Evidence.com / AXON Auto-Tagging
Locution Fire Station Alerting
30 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 4
4 1
5 0
Priority Dispatch ProQA
Tablet Command
FUSUS RTC3
Alarm Program Systems (APS) [Alarm Permits/Billing]
Accela
PulsePoint
3.2. Subscription Term:
Initial Subscription Term: Ten years commencing upon Provisioning.
The current Subscription Term auto renews in accordance with section 3(c) of the MSA.
3.3. Fees:
Versaterm shall send invoices for the below Fees to Customer at the following e-mail addresses:
[email protected] ; [email protected]. Should invoice email address change, Customer shall promptly notify Versaterm.
3.3.1. Onboarding Fee
Based on the full scope of work as initially proposed , the total amount payable for Professional Services is $1,608,943.36 . An invoice for this Fee shall be issued upon commencement of the first Production Period of the Subscription Service and shall be paid in full within forty-five (45) calendar days after the invoice date.
Onboarding Milestones, as identified in the
Statement of Work (Exhibit B) Percentage Payment
Kickoff Meeting 10% $114,824.99
Provisioning (Build the Test Environment) 10% $114,824.99 Configuration Workshop #2 10% $114,824.99
Configuration Workshop #3 10% $114,824.99
Build the Production Environment 10% $114,824.99
Functional Acceptance Testing 10% $114,824.99
Trainer the Trainer Training 10% $114,824.99
Ready for Use (Ready for Training) 15% $172,237.48
Final Acceptance 15% $172,237.48
SubTotal: 100% $1,148,249.86
CAD Interfaces 100% $460,693.50
Total: 100% $1,608,943.36
3.3.2. Subscription Fees
3.3.2.1 Subscription Fees for the Initial Subscription Term
3.3.2.1.1 Subscription Fees Year 1:
Subscription Category Payment
CAD Software Subscription $365,304.00
CAD Interfaces Subscription $91,411.00
Configuration as a Service (CaaS) for CAD and MDT
Subscription $20,000.00
31 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 5
4 1
5 0
Total Subscription $476,715.00
Based on the full scope of work as initially proposed , the annual Subscription Fee for the first year of the Subscription Service is $476,715.00 . An invoice for this Fee shall be issued upon the commencement of the Initial Subscription Term, as described in the Statement of Work and shall be paid in full within forty- five (45) calendar days after the invoice date, which shall set the date for subsequent years. The invoice date for this subscription payment is currently targeted for 02/02/2026.
Total Fees for Onboarding and First Year Subscription: USD: $2,085,658.36
3.3.2.1.2 Subscription Fees for Years 2 through 10:
i. The annual Subscription Fees for the years 2 through 10:
a. shall be paid in full and in advance on the annual anniversary of the Initial Subscription Term start; and
b. may be increased by no more than 5% calculated based on the previous year’s Subscription Fees and is adjusted as defined in the Calculation of Subscription Fees section below.
c. Versaterm shall notify the Customer regarding any pricing increases at least sixty (60) days prior to the beginning of a Subscription Renewal Term.
3.3.2.2 Calculation of Subscription Fees
i. Calculation. During the Production Period, the annual Subscription Fee for the Software as a Service shall be calculated as the number of users in a User Class multiplied by their respective User Cost per Month (UCM) multiplied by 12.
ii. User Classes. As of the Effective Date of this Service Schedule, the User Classes are:
a. Sworn Officers:
Number of Sworn Officers (NSO) is defined as the number of sworn employees as of the date that is ninety (90) days prior to the Subscription Payment Date, as certified by the personnel orders of the Police Department and Fire Department.
The CAD UCM of NSO is currently $106.79 per user. The NSO for the first full year of the Production Period is 372 .
3.3.2.3. Subsequent Subscription Fees
In accordance with the terms of the MSA, following the expiration of the Initial Subscription Term, the Subscription Service shall automatically renew for additional one-year periods. The annual Subscription Fee for subsequent years of the Subscription Services shall be paid in full and in advance on the annual anniversary of the Initial Subscription Term start date and subject to the following yearly price increase. i. Subsequent Subscription Renewal Term. the Subscription Fees for each Subscription Renewal Term may be increased by no more than CPI + 4%, calculated based on the previous year ’ s Subscription Fees.
ii. Versaterm shall notify the Customer regarding any pricing increases at least sixty (60) days prior to the beginning of a Subscription Renewal Term.
3.3.2.4 Itemized Interface Costs
32 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 6
4 1
5 0
i. The costs outlined below are based on the full scope of work as initially proposed and included in the total Onboarding Fee defined in Section 3.3.1 above. Any changes to the project scope, including additional interfaces or modifications, will be billed separately. If the Customer and Vendor mutually agree to remove interfaces from this scope, credit for the removed interfaces will be applied to the final invoice. However, if the credit amount is expected to exceed the total final quoted amount, an adjustment to the milestone payment table in Section 3.3.1 will be required to ensure proper reconciliation of project costs. In addition, the annual Solution subscription cost defined in Section 3.3.2 above for the interface will be adjusted. All changes to scope and associated costs will be documented and require mutual agreement between both parties. ii. Below is an itemized breakdown of all CAD Interfaces initially proposed, including the One-Time Services and Annual Support Costs for each CAD Interface.
Total CAD Interface Cost Summaries
CAD Interfaces
One-Time Service
Cost
Annual Support
Cost
D.1 JDIC/CLETS/NCIC $29,791.30 $0
D.2 Motorola Vesta
(https://www.vestapublicsafety.com/solutions/ng911.php) $53,360.40 $14,048.00
D.3 Versaterm GIS (ESRI) Interface $78,722.50 $37,697.50 D.4 AXON Police RMS Call-For-Service transfer (AXON
and Torrance Data Warehouse)
$23,547.90 $4,936.00
D.5 Fire RMS Call-For-Service transfer (Fire RMS and
Torrance Data Warehouse)
$23,547.90 $4,474.00
D.6 Motorola Radio MCC7500 Radio Push-to-
Talk/Emergency
$29,229.50 $0
D.7 Eventide Voice Recording $14,474.30 $0
D.8 Evidence.com / AXON Auto-Tagging $19,292.00 $6,508.00 D.9 Locution Fire Station Alerting $35,472.90 $0
D.10 Priority Dispatch ProQA (Fire only) $26,961.10 $4,537.00 D.11 Tablet Command $41,997.20 $6,805.00
D.12 FUSUS RTC3 $6,243.40 $1,180.00
D.14 Alarm Program Systems (APS) [Alarm
Permits/Billing]
$12,767.70 $4,083.00
D.14 Accela $59,042.00 $5,962.50
D.15 PulsePoint $6,243.40 $1,180
Total Price $460,693.50 $91,411.00
3.4. Egress and Connectivity
Versaterm will provision redundant Customer VPN end points for up to 2 connections. Each VPN connection has two tunnels that should be configured by Customer to provide redundancy. Customer is responsible for providing and configuring the required Customer Gateway VPN hardware and software.
Customer Data shall be made available for egress for a total of 300 gigabytes per month. Any egress connectivity beyond this rate shall be charged periodically at prevailing rates at the time and shall be paid in full when and as required, and according to the termination provisions set forth in Section 20 “Orderly Termination” of the MSA.
33 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 7
4 1
5 0
3.5. Database / Disk Storage
Initial Database Storage
a. The initial database storage shall be made available as follows:
- a maximum of 200 gigabytes for the CAD Production Databases. - a maximum of 200 gigabytes for the CAD Production Read-Replica Databases. - a maximum of 100 gigabytes (combined) for the CAD Test/Implementation and Training Databases.
b. For each Subscription Renewal Term, an automatic database storage increase of 10% of the initial database storage maximums, as listed in this subsection, will be provided to accommodate storage growth over time. For example, if it is an increase of 10%: Year 1 - 300GB, Year 2 - 330GB, Year 3 - 360 GB, Year 4 - 390 GB, Year 5 - 420 GB.
Initial Disk Storage
a. The initial disk storage (for multimedia attachments and logs) shall be made available for a total maximum of 500 Gigabytes.
b. For each Subscription Renewal Term, an automatic disk storage increase of 10% of the initial disk storage maximum, as listed in this subsection, will be provided to accommodate storage growth over time. For example, if it is an increase of 10%: Year 1 – 500GB, Year 2 – 550 GB, Year 3 – 600 GB, Year 4 – 650 GB, Year 5 – 700 GB
Any storage use beyond these allocations will be charged at the current prevailing rates and shall be paid in full when and as required and in accordance with Section 20 “Orderly Termination” of the MSA.
Versaterm will notify Customer of current database/disk storage consumption prior to the annual subscription renewal to allow Customer can take appropriate action (e.g., increase storage).
4. Onboarding
4.1. Sub Exhibits to this Service Schedule shall include the following documentation detailing each party’s roles and responsibilities for the onboarding of the Subscription Service:
Exhibit B.1 – Statement of Work
Exhibit B.2 – Project Implementation Schedule
Exhibit B.3 – Interface Control Document (ICD)
Exhibit B.4 – Acceptance Test Plan
Exhibit B.5 – Training Plan
Exhibit B.6 – Minimum Client and Peripheral Specifications
5. License
5.1. Compliance
The Customer will be responsible to Versaterm for compliance by Customer and all its Authorized Users of the terms of Section 6 of this Service Schedule.
5.2. License for Use - Subscription Service
Subject to the terms and conditions of the MSA and this Service Schedule, and the payment of the applicable Fees, Versaterm hereby grants to Customer, for use by its Authorized Users, a non-exclusive, non-transferable, non-sublicensable license to access the Subscription Service, as further detailed in Section 3. The Subscription Service shall be accessible through a designated secure internet platform during the Term solely for the Customer’s use in conjunction with the Customer’s operations, and not for resale, access by third parties, or for other commercial purposes. Apart from the rights enumerated herein, the Subscription Service do not include a grant to the Customer of any right to use, nor any ownership 34 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 8
4 1
5 0
right, title, or other interest, in or relating to Subscription Service, nor in any copy of any part of the Subscription Service.
5.3. License for Use - On-Site Software, if applicable
Subject to the terms and conditions of the MSA and this Service Schedule, and the payment of the applicable Fees, and where applicable, Versaterm hereby grants to the Customer, for use by its Authorized Users, a non-exclusive license to use the On-Site Software, as further detailed in Section 3.
The On-Site Software may only be used solely for the Customer’s use in conjunction with the Customer’s operations. Apart from the rights enumerated herein, the license does not include a grant to the Customer, of any right to use, nor any ownership right, title or other interest, in or relating to the On-Site Software, nor in any copy of any part of the On-Site Software.
5.4. Copies of User Documentation
Versaterm will provide Customer with access to the User Documentation, as may be updated from time to time. The Customer may use the User Documentation solely in connection with the use of Subscription Service, and may reproduce the User Documentation, provided that each copy thereby produced shall be marked with Versaterm’s proprietary markings as delivered to the Customer. The Customer shall not use, print, copy, translate or display the User Documentation in whole or part for any reason other than those expressly authorized herein.
5.5. Restrictions on Use
In addition to the license restrictions set forth in Section 4 of the MSA, the Customer and its Authorized Users will not and will not knowingly permit any third party to: (i) share the Customer’s or any Authorized User’s login credentials; (ii) copy, modify, adapt, translate, or make derivative works of the Subscription Service, Third Party Data, or Third Party Components, or otherwise make any use, resell, distribute or sublicense the Subscription Service, Third Party Data or Third Party-Supplied Components other than as permitted herein; (iv) create or augment any mapping-related dataset including a mapping or navigation dataset, business listings database, mailing list, or telemarketing list for use in an implementation that is not connected to the services; (v) hide or obscure any Authorized User’s location with malicious intent or purpose; (ix) permit access or use of the Subscription Service for any activities other than to enhance the Customer’s own services, where reliance solely on or failure to use the Software could lead to death, personal injury, or property damage. The Customer and its Authorized Users will not access the Subscription Service if in direct competition with Versaterm and will not allow access to the Subscription Service by any party who is in direct competition with Versaterm and/or its Affiliates, except with Versaterm’s prior written consent.
5.6. Third Party Applications
If Customer installs or enables a Third-Party Application for use with the Subscription Service, Customer grants Versaterm permission to access Customer Data stored on that Third Party Application as required for the interoperation of that Third Party Application with the Subscription Service. In no event will Versaterm be responsible for any Third-Party Application, or any failure of a Third-Party Application to properly interoperate with the Subscription Service. If Versaterm receives information that a Third-Party Application may violate any applicable laws or third-party rights, Customer will, promptly upon receiving notice of the foregoing from Versaterm, disable any connection between such Third-Party Application and the Subscription Service to resolve the potential violation (and if Customer fails to promptly disable such connection, Versaterm shall have the right to do so).
5.7. Third Party Components
Where there are any inconsistencies or conflict between the terms and conditions of Third-Party Components and the terms herein, such additional terms shall govern the Customer’s use of the applicable Third-Party Component. Third Party Component license(s) are restricted for use solely with Subscription Service.
VERSATERM, NOT BEING THE PROVIDER OR MANUFACTURER OF THE THIRD-PARTY COMPONENTS, NOR THE PROVIDERS' OR MANUFACTURERS’ AGENT, MAKES NO EXPRESS OR
IMPLIED WARRANTY OF ANY KIND WHATSOEVER WITH RESPECT TO THE THIRD-PARTY COMPONENTS AND DISCLAIMS ANY SUCH WARRANTIES THAT MIGHT OTHERWISE EXIST. 35 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 9
4 1
5 0
5.8. Third-Party Data
Customer shall access and use the Third-Party Data in accordance with the terms and conditions of the agreement between the Customer and the provider of such Third-Party Data. VERSATERM, NOT BEING
THE PROVIDER OR MANUFACTURER OF THE THIRD-PARTY DATA, NOR THE PROVIDERS OR MANUFACTURERS’ AGENT, MAKES NO EXPRESS OR IMPLIED WARRANTY OF ANY KIND
WHATSOEVER WITH RESPECT TO THE THIRD-PARTY DATA AND DISCLAIMS ANY SUCH WARRANTIES THAT MIGHT OTHERWISE EXIST.
5.9. Customer Data
As between Versaterm and Customer, Customer owns and shall retain all rights, title, and interest, including, without limitation, all Intellectual Property Rights, in and to Customer Data. Customer shall have the sole responsibility for the accuracy, quality, and legality of the Customer Data, including obtaining all rights and consents necessary to share the Customer Data with Versaterm as set forth in this Agreement.
Versaterm shall not access Customer user accounts or Customer Data except: (i) during data center operations, (ii) in response to services or technical issues, (iii) as required by the express terms of this Agreement, or (iv) at Customer’s written request. Versaterm shall not collect, access, or use user-specific Customer information except as strictly necessary to provide the Subscription Service to the Customer.
5.10. Software Enhancements and Optional Modules
Versaterm shall supply the following, subject to the Customer’s payment of applicable Fees, and subject to and in accordance with the license rights, restrictions, terms, covenants, conditions, warranties, limitations, exclusions, and other provisions set forth herein:
a. Major Enhancement Release(s) and/or Minor Enhancement Release(s) if any, to the Customer at no additional charge.
i. In the event of a Major Enhancement Release, Versaterm will deploy such upgrades to the Customer’s systems, as scheduled in advance, with appropriate notification to the Customer.
Customer shall have 20 days to test the Major Enhancement Release, after which, it becomes part of the Software.
ii. In the event of a Minor Enhancement Release, Versaterm will deploy such updates to the Customer’s system, as scheduled in advance, with appropriate notification to the Customer. With the goal of keeping such environments reasonably current, the Customer shall have 5 days to test the update, after which, the update shall become part of the Software. b. Interface modules that are developed by Versaterm for interfacing the Subscription Service to other software products, provided that such modules are specifically included herein. c. Changes to Subscription Service. Versaterm software operates on a variety of common web browser types. Versaterm reserves the right to provide the Subscription Service using only Versaterm Certified Browsers.
5.11. Disclaimer on Use
THE AUTOMATIC VEHICLE ROUTING RECOMMENDATION COMPONENT (“AVRR COMPONENT”),
IF LICENSED UNDER THIS AGREEMENT, IS INTENDED FOR USE AS ONE FACTOR IN
DETERMINING THE BEST VEHICLE ROUTING FOR THE CUSTOMER AND IS NOT INTENDED TO
BE USED AS THE SOLE SOURCE FOR DETERMINING ROUTING, NOR WHICH VEHICLES TO DEPLOY TO ADDRESS ANY EMERGENCY SITUATION. THE AVRR COMPONENT IS HEAVILY
DEPENDENT ON THE QUALITY OF THE SOURCE MAPPING INFORMATION INPUTTED BY OR ON
BEHALF OF CUSTOMER AND VERSATERM WILL HAVE NO RESPONSIBILITY OR LIABILITY FOR
ANY ROUTING ERRORS AND/OR DELAYS, NOR ANY RESULTANT DAMAGE OR LOSS ARISING AS
A RESULT OF THE MAPPING DATA OR FOR ANY DAMAGES OR LOSS CAUSED BY ANY DECISION MADE OR ACTION TAKEN IN RELIANCE ON THE AVRR COMPONENT.
6. Subscription Support
36 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 10
4 1
5 0
6.1. Site Access
When reasonably requested by Versaterm, the Customer shall provide access to its premises, staff, and authorities, provided Versaterm staff meet the security requires defined in Section 9 of this Service Schedule.
6.2. Software Support
During Production Use, Versaterm may make Support available through access to Versaterm’s designated internet platform, and direct contact with the Customer. Such Support may consist of the periodic review of current outstanding questions and usage issues, new and upcoming releases of Major Enhancement and Minor Enhancements, and the periodic review of potential environment changes that could impact the use of the Subscription Services.
6.3. Regular Telephone Support
During Production Use, Versaterm will make Support available by telephone to the Support Contact at substantially all times from 7:30 a.m. (EST) until 5:30 p.m. (Customer local time) each day except Saturdays, Sundays, and legal holidays in the jurisdiction of the Customer. To the extent possible by telephone, email, and remote communication, Versaterm will attempt to identify and provide a workaround for the Problem and will use reasonable efforts to provide a final solution for the Problem, if that applies.
Versaterm will normally respond to telephone requests for Critical Priority Errors and High Priority Errors within thirty (30) minutes of receipt of the call.
Escalation Path
Customer will receive a current escalation contact directory with direct phone numbers for Versaterm personnel at multiple levels, including executive management. This directory will be updated as organizational changes occur. Customer may escalate issues directly to any appropriate level, including executive leadership, based on the nature and urgency of the matter.
6.4. 7x24 Emergency Telephone Support
Versaterm will provide 7x24 Telephone Support that extends Support for problems identified as Critical Priority Error and High Priority Error to include all hours not already provided for within Regular Telephone Support. 7x24 Telephone Support allows the Customer’s internal support staff that are technically capable and who first troubleshoot the problem, to authorize Versaterm to provide 7x24 Telephone Support.
6.5. Configuration as a Service (CaaS) for CAD and MDT
Versaterm will provide ongoing Configuration as a Service (CaaS) to support CAD and MDT configuration maintenance. This includes scheduled, quarterly updates to select CAD Administration settings and the MDT Designer configuration. These updates will be conducted collaboratively with the Customer and focus exclusively on the items listed in the Scope of Versaterm Responsibilities section below.
Quarterly Update Process
Each quarter, the Customer will maintain and prioritize a list of desired configuration updates. During the final week of the quarter, Versaterm and the Customer will meet to review and agree on a feasible set of updates to be completed as well as the schedule for deployment within each quarter, for instance; o Week 1: Versaterm will complete the agreed-upon updates in the TEST environment. o Week 2: The Customer will review and accept the changes. Once approved, Versaterm will deploy the accepted updates to the PRODUCTION environment.
Out-of-Cycle Updates
Configuration changes outside the quarterly process will only be made under the following conditions:
o A critical feature is non-functional or not operating as intended o A legal or regulatory mandate requires the change
37 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 11
4 1
5 0
o A critical business need has been identified and approved at the agency-wide level Scope of Versaterm Responsibilities under CaaS
Versaterm’s configuration responsibilities under this service are strictly limited to the following settings:
o Versaterm-Managed CAD Configuration Settings
▪ SUPER – CAD
▪ SUPER – Sys Config
▪ Site Config
▪ Custom NCIC Queries (QP, QV)
▪ Status Screen Configs
▪ SUPER – Stations
▪ SUPER – Response Plans
▪ SUPER – Reset User Settings
o Versaterm-Managed MDT Configuration
▪ Full CaaS for MDT Designer
Customer Responsibilities (Not Included in CaaS)
All configuration settings not explicitly listed in the section above are outside the scope of Versaterm’s Configuration as a Service and will are the sole the responsibility of the Customer. This includes, but is not limited to, the following configuration settings:
o Customer-Managed CAD Configuration Settings
▪ SUPER – Users
▪ SUPER – Paging Messages (Groups)
▪ Map Configs (prepare/maintain vGI data)
▪ Special Service Rotations
▪ Device/software compliance with minimum specifications ▪ Map Maintenance (GeoDB and Layers)
▪ Table Maintenance
o Customer-Managed MDT Responsibilities
▪ Device compliance with minimum specifications
▪ Map Maintenance (GeoDB and Layers)
Note : The Customer is responsible for ensuring all devices used with the system meet or exceed minimum performance and compatibility specifications as outlined in the applicable documentation.
6.6. Termination of Corrective Action
Versaterm may, but need not, terminate its corrective efforts under this Exhibit at any time if, in its business judgment:
a. The Customer fails to perform its obligations described herein; or b. The Customer is not using the then current unmodified version of the Software or other versions of the Software then supported by Versaterm; or
c. Versaterm and/or the Customer is not able to reproduce the Problem in the applicable operating environment and verify that the Problem is in fact in the Software and not elsewhere; or d. The Problem is not material; or
e. Further corrective efforts are not appropriate because the Problem has been identified and is caused by an external factor not within Versaterm’s control; or f. Versaterm has declared the Problem as probably being caused by something external to the supplied Subscription Service, such as aberrations within the Customer’s network (LAN and/or WAN and/or related network equipment). Versaterm will terminate work on this Problem unless the Customer authorizes further diagnosis effort that may be billable separately under this Agreement 38 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 12
4 1
5 0
when and if the suspected external problem source is confirmed. If confirmed as being caused by an external source, then such work will be billed on a time and materials basis at the then prevailing hourly rates for Support (whether within or outside normal support hours) and can be authorized by e-mail by the designated Support Authority or other as designated in writing to Versaterm as having that authority.
6.7. Third Party Applications
Responsibilities for Planned Updates.
Customer shall provide Versaterm with prompt notice, and in no case fewer than sixty (60) days’ advance notice, of any update by the Third-Party Provider of a Third-Party Application. Subject to alignment with Versaterm’s cloud patch schedule, Versaterm shall undertake commercially reasonable efforts to patch or update the Software in order to integrate it with the updated Third-Party Application.
Responsibilities for Planned Upgrades.
Customer shall provide Versaterm with prompt notice, and in no case fewer than ninety (90) days’ advance notice, of any planned upgrade by the Third-Party Provider of a Third-Party Application. Subject to alignment with Versaterm’s cloud patch schedule, Versaterm shall evaluate the time and resources required to patch or update the Software in order to integrate it with the upgraded Third-Party Application.
The Parties shall engage in good faith negotiations to agree on the terms (including, without limitation, schedule, and price) on which Versaterm would develop a patch, update, or upgrade to integrate the Software with the Third-Party Application.
7. System Performance and Availability Standards
This Section 7 sets forth the performance and availability standards to which the Versaterm vCAD is expected to perform, provided Customer meets Versaterm’s recommended hardware and network specifications, including server, desktop workstation, and mobile configurations, and that the Customer uses the Software according to its intended design. Minimum Client and Peripheral Specifications are detailed in Sub Exhibit B-6 of this Service Schedule. Specifications and requirements are subject to change to support future Major Enhancement Releases.
The measured times exclude any factors that may be caused by factors outside of Versaterm’s control, such as, but not limited to, the network.
7.1. vCAD Transaction Response Times
The vCAD Software performance is based on transaction response times, which are measured from operator action until visual response is observed or until the operation is completed. Expected response times are not for data-dependent transactions, such as, but not limited to, displaying data lists, displaying dashboards, querying external interfaces, attaching files, printing, or performing browse searches. For such types of data-dependent transactions, the response time results may vary depending on the amount of data involved, the sizes of the files involved, or the types of search criteria entered.
Below defined response times do not include dispatch recommendations/dispatching using AVL or AVRR, unless specified.
The approach taken will be to measure the performance of a series of identified transactions from a vCAD call-taker/dispatcher workstation while the Subscription Service is under normal and reasonable workload within the Production Use environment. Delays caused by the network will not be included in the response times.
When measuring response time, no browse transactions (ad-hoc queries against the database using the browse functions) or vCAD reports will be processed. The response times will be measured from vCAD workstations that meet the recommended workstation requirements as defined herein.
Running a vCAD session (i.e. signed on as a dispatcher), the following times should not be exceeded:
39 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 13
4 1
5 0
Transaction #1 Display “Add Call” form. Measured from the time the ‘add call’ function key is pressed until the form
is displayed. Excludes first time the ‘Add Call’ form
is invoked (form is being cached).
1 second
95% of the time
Transaction #2 Display call in queue - measured from when “ENTER” is pressed on completed call screen and
the call is displayed in the pending queue.
2 seconds
99% of the time
Transaction #3 Validate address (from time last character entered to the display of district/beat/grid or invalid location form or display of matching street list). From time
user tabs out of location field until successful
geocoding occurs. Assumes full street name is
entered or 2 full street names are entered for
intersections.
2 seconds
99% of the time
Transaction #4 Status change for single unit (en route, on scene) - measured from when “ENTER” is pressed and unit
status results are displayed on unit status.
2 seconds
95% of the time
Transaction #5 Retrieve Call using call number as a parameter. - measured from when call number is entered and
“ENTER” is pressed until call is displayed.
2 seconds
99% of the time
Transaction #6 Display the recommended response units for the incident, measured from when the user enters the
DP (Dispatch Recommendation) command to when
the recommended units are displayed on the
dispatcher screen. Assumes non-AVRR dispatch
recommendation of 10 units or under.
2 seconds
99% of the time
Navigational Transactions
Navigational transactions involve the ease of movement from screen to screen or field to field. The response time for navigational transactions is expected to usually take one second (or less).
Examples include:
- Tabbing from field to field in any screen within the Software - Looking up valid values for a coded field
7.2. Availability Standards
During Production Use of the Subscription Service, the vCAD Software shall be available in the production environment 99.99% of the time. Availability applies to the core vCAD Software application as provided by Versaterm in the production environment, excluding downtime attributable to third-party systems, customer infrastructure, external integrations, or causes beyond Versaterm's reasonable control. The following specifications define both availability and the method by which it is calculated:
Availability is expressed as a percentage of the maximum expected availability over a given period. The Software shall be available seven days per week, 24 hours per day. The percentage availability for any period will be calculated as follows:
(Total Hours in Period – Hours System Unavailable) x 100 / Total Hours in Period 40 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 14
4 1
5 0
"Unavailability" is where the vCAD Software is completely and generally unavailable for the Customer’s use (but not the use of any one Authorized User, or subset/group of users; or access from any one vCAD desktop, or group of vCAD desktops), and does not include any unavailability attributable to:
a. Scheduled downtime for maintenance;
b. Scheduled downtime for Major Enhancement Releases and Minor Enhancement Releases; c. scheduled downtime for operating system patch updates; d. downtime for upgrades or updates to system software components and tools integrated as part of the Subscription Services;
e. downtime for upgrades or updates to cloud-based Third-Party Software Components and services integrated as part of the Subscription Services;
f. downtime related to connectivity issues resulting from Customer or third-party-provided or managed Direct Connect or VPN access to hosted server or Customer internal network problems; Customer will be responsible for immediately notifying Versaterm of all third-party-managed VPN access and internal or external (e.g. internet service provider) network problems that arise; g. an incident resulting from data or infrastructure or network provided and/or performed by the Customer;
h. acts or omissions of Customer or any Customer user, Authorized User, or any employee, agent, or independent contractor of the Customer;
i. lack of availability or untimely response from the Customer that require the Customer’s participation for resolution;
j. the Customer’s negligence or breach of the Customer’s material obligations under the MSA or Service Schedule;
k. any other cause(s) beyond Versaterm’s reasonable control, including but not limited to those caused by Third Party Data, Third Party Applications, Third Party Provider, or Third-Party Components or other third-party software, as well as overall internet congestion, denial of service attack, or a force majeure event.
In the event the availability standards, as set forth in this section 7.2, are not met, Customer may request a meeting, which may be conducted in-person, with a Versaterm executive to discuss the issue and develop a remediation plan at no cost to the Customer.
8. Security
8.1. Versaterm agrees that all personnel Versaterm employs pursuant to this Service Schedule shall be subject to Versaterm’s background and security checks and screening (collectively “Background Screening”) at Versaterm's sole cost and expense as set forth in this paragraph. The Background Screening shall include, as a minimum, criminal record checks, local police record checks, and credit checks. Any additional Background Screening required by the Customer must be agreed to by Versaterm and may be at additional cost.
8.2. FBI CJIS Security Addendum. Versaterm agrees to the terms and requirements set forth in the Federal Bureau of Investigation (FBI) Criminal Justice Information Services (CJIS) Security Addendum for the Term of this Service Schedule.
9. Transition Assistance
9.1. Upon termination of the MSA or this Service Schedule for any reason, and subject to Fees due being paid in full, Versaterm will return Customer’s data in a CSV or other mutually agreed upon format for each record (“Record”) and provide them to the Customer for download. Records can be uploaded to Customer’s new system by the Customer or its new vendor. The transition assistance described in this 41 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 15
4 1
5 0
Section 9.1 is included in the Fees. All other Fees are due and payable up to the cut-off date of the Subscription Service.
9.2. As an optional Transition Assistance, Versaterm shall provide, at an additional fee, the database, and other managed services, as mutually agreed upon.
9.3. Notwithstanding the foregoing, Versaterm reserves the right to retain Customer Data on audit logs and server system logs and in support tickets, support requests, and direct communications with Versaterm. [remainder of page left intentionally blank]
42 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B - CAD SaaS Service Schedule for Cloud
Page | 16
4 1
5 0
IN WITNESS WHEREOF, the Parties hereto have executed this Service Schedule as of the day and year indicated below.
Versaterm Public Safety US, Inc.
By: _________________________
Name: _____________________
Title: ______________________
Date: ______________________
By: ________________________
Name: _____________________
Title: ______________________
Date: ______________________
City of Torrance
By: _________________________
Name: _____________________
Title: ______________________
Date: ______________________
By: ________________________
Name: _____________________
Title: ______________________
Date: ______________________
43 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
CAD Onboarding Sub Exhibits
CAD ONBOARDING
SUB EXHIBITS
44 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
CAD Onboarding Sub Exhibits
CONTENTS
1. EXHIBIT B – CAD SAAS SERVICE SCHEDULE FOR CLOUD .....................................................................................1 E XHIBIT B.1 – S TATEMENT OF W ORK
E XHIBIT B.2 – P ROJECT I MPLEMENTATION S CHEDULE
E XHIBIT B.3 – I NTERFACE C ONTROL D OCUMENT
E XHIBIT B.4 – A CCEPTANCE T EST P LAN
E XHIBIT B.5 – T RAINING P LAN
E XHIBIT B.6 – M INIMUM C LIENT AND P ERIPHERAL S PECIFICATIONS 45 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 1
EXHIBIT B.1
STATEMENT OF WORK
46 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 2
CONTENTS
1 Overview.................................................................................................................................................4
1.1 Project Summary and Objectives ......................................................................................................................4
1.1.1 Project Objectives...................................................................................................................................... 4
1.2 Related Exhibits................................................................................................................................................4
1.3 DEFINITIONS..................................................................................................................................................... 4 2 Roles and Responsibilities .......................................................................................................................5
2.1 Project Management Overview ........................................................................................................................5
2.2 Project Management Tools ...............................................................................................................................6
2.3 Project Steering Committee.............................................................................................................................. 6
2.4 Versaterm Project Manager..............................................................................................................................7
2.5 Customer Project Manager ...............................................................................................................................8
2.6 Organizations Responsibilities During the Project .............................................................................................8
2.6.1 Versaterm Responsibilities............................................................................................................................8
2.6.2 Versaterm Project Team ...............................................................................................................................9
2.6.3 Customer Responsibilities............................................................................................................................. 9
2.6.4 Customer Project Team.................................................................................................................................9
2.7 Project Implementation Schedule ...................................................................................................................10
2.8 Task Completion And MILESTONE PAYMENT ..................................................................................................10
2.9 Change Control ...............................................................................................................................................10
2.9.1 Project Schedule Adjustments ....................................................................................................................10
2.9.2 Scope and Cost Change Orders ...................................................................................................................11 3 Software Deliverables ...........................................................................................................................11
3.1 SOFTWARE .....................................................................................................................................................11
3.2 Interfaces – for Go-Live................................................................................................................................... 11
3.3 Interfaces – for Post-Live ................................................................................................................................11
3.4 Redundancy and Backup Deliverables.............................................................................................................11 4 Key Assumptions................................................................................................................................... 12
4.1 Software Version ............................................................................................................................................12 47 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 3
5 Statement of Work Tasks ......................................................................................................................12
5.1 Planning & Contract Definition Phase - Task 1.................................................................................................12 Task #1.3 Execute Contract.................................................................................................................................. 12
5.2 Project Initiation Phase - Task 5 ......................................................................................................................12 Task #5.1 Initiate Project......................................................................................................................................12 Task #5.2 Project Kickoff Meeting (Timeline Milestone #1) .................................................................................12
5.3 Provisioning Phase - Task 7 .............................................................................................................................13 Task #6 Establish AWS Connectivity.....................................................................................................................13 Task(s) #7.1 - #7.5 Build DEV/Test Environment..................................................................................................15 Task #7.6 Prepare a Configuration Lab/Classroom ..............................................................................................16 Task #7.9 Initial CAD Environment Provisioned (Subscription Start) (Timeline Milestone #2) ............................ 16
5.4 GIS – Task 8.....................................................................................................................................................17
5.5 CAD/MDT Implementation & Configuration - Task 9 .......................................................................................19 Task(s) #9.1 - #9.4 CAD/Mobile Configuration Workshops..................................................................................19 Task #9.3 Configuration Workshop #2 Completed (Timeline Milestone #3) ....................................................... 20 Task #9.4 Configuration Workshop #3 Completed (Timeline Milestone #4) ....................................................... 20
5.6 Interface Development Phase - Task 10 ..........................................................................................................21 Task #10 Develop and Install Interfaces...............................................................................................................21
5.7 Build Production Environments – Task 12 (Timeline Milestone #5) ..................................................................22
5.8 Testing Phase - Task 13 ...................................................................................................................................22 Task #13.1 Interface Integration Testing .............................................................................................................22 Task #13.2 Functional acceptance Testing........................................................................................................... 23 Task #13.2.3 Attach Functional Acceptance Testing Acceptance Email (Timeline Milestone #6) ........................24
5.9 Training Phase - Task 14..................................................................................................................................24 Task #7.6 Prepare A Configuration Lab ................................................................................................................24 Task #14.5 Train-the-Trainer Training (Timeline Milestone #7) ...........................................................................25 Task #14.6 Ready For Use Declared (Timeline Milestone #8) .............................................................................. 26 Task #14.8 Agency End-User Training ..................................................................................................................26
5.10 Production Cutover and Close Support - Task 15 ...........................................................................................28 Task #15.1 Prepare Desktops and Mobile Computers .........................................................................................28 Task #15.3 Production Cutover – Go Live ............................................................................................................ 28
5.11 Response Time and Reliability Acceptance Testing – Task 16.........................................................................29
5.12 Final System Acceptance – Task 17 (Timeline Milestone #9) ..........................................................................29 6 Communication Plan .............................................................................................................................30 7 Risk Management Plan..........................................................................................................................31 48 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 4
1 OVERVIEW
This document is the Statement of Work defining the principal tasks, activities and responsibilities of the parties involved in the implementation of the Application Software, interfaces and ancillary products.
This Project is a collaboration between the Parties, City of Torrance, hereafter “Customer” and Versaterm, and is contingent upon both entities fulfilling their respective responsibilities as defined in the Agreement and this Statement of Work.
1.1 PROJECT SUMMARY AND OBJECTIVES
The purpose of this project is to implement Versaterm’s Computer Aided Dispatch (CAD), Mobile Data Terminal (MDT), and associated components to modernize and unify dispatch and field operations for the Torrance Police and Fire Departments. The project will enhance operational efficiency, improve situational awareness and responder safety, and establish a scalable platform for future technology integration across public safety functions.
1.1.1 PROJECT OBJECTIVES
• Implement Versaterm’s CAD system to replace the Customer’s legacy dispatch platform, supporting coordinated emergency response for both Police and Fire Operations. • Deploy the Versaterm Mobile Data Terminal (MDT) solution to enable real-time communication, incident management, and field reporting from police patrol vehicles.
• Configure shared and discipline-specific workflows that meet the operational needs of both departments while leveraging a unified system for dispatch efficiency.
• Integrate essential modules and subsystems such as mapping, unit recommendation, automatic vehicle location (AVL), and resource availability tracking to improve response coordination. • Ensure a reliable, secure, and highly available Software-as-a-Service (SaaS) environment that complies with the Customer’s IT governance policies and meets all applicable public safety security requirements, including data protection, access controls, audit logging, and business continuity standards. • Provide comprehensive training tailored to dispatchers, officers, firefighters, and system administrators to ensure successful adoption.
• Achieve a phased or coordinated go-live for Police and Fire with minimal operational disruption, including thorough testing, cutover planning, and post-implementation support.
1.2 RELATED EXHIBITS
• Exhibit B – CAD SaaS Service Schedule for Cloud
o License Terms
o Annual Subscription Support Terms
o Price and Payment Terms
• Exhibit B.1- Statement of Work (SOW)
• Exhibit B.2- Project Implementation Schedule
• Exhibit B.3- Interface Control Document
• Exhibit B.4- Acceptance Test Plan
• Exhibit B.5- Training Plan
• Exhibit B.6- Minimum Client and Peripheral Specifications
1.3 DEFINITIONS
49 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 5
The definitions provided in this section apply to this Statement of Work (Exhibit B.1 – Police/Fire CAD Statement of Work) and all associated sub-exhibits, including but not limited to the Project Implementation Schedule, Interface Control Document, Acceptance Test Plan, Training Plan, and Minimum Client and Peripheral Specifications. These definitions are intended to ensure clarity and consistency in the interpretation of terms used throughout the SOW and its related documentation. Unless otherwise specified, the terms defined herein shall apply solely to this Statement of Work and its related exhibits and shall take precedence over conflicting terminology used within these exhibits.
Term Definition
Business Day Is any working day that aligns with the Customer’s 9/80 work schedule, excluding Customer-Observed Holidays. Under the 9/80 schedule, Business Days are Monday through Friday, except for alternating Fridays, which are designated as non-working days. Additionally, any holidays officially recognized by the Customer will not be considered a Business Day.
Customer Refers to the City of Torrance, a California municipal corporation. For the purposes of this Statement of Work, the terms "Customer" and "Customer" are used interchangeably to describe the contracting entity receiving services under this agreement.
PM Project Manager
Project The coordinated set of activities, deliverables, and milestones described in this Statement of Work and its related exhibits, undertaken by the Customer and Versaterm to implement the Computer-Aided Dispatch (CAD) System and its associated components. The Project includes all phases of planning, configuration, testing, training, deployment, and post-implementation support necessary to achieve a successful go-live and system acceptance in accordance with the terms outlined herein.
Project Plan A comprehensive document outlining the Project's objectives, scope, timeline, milestones, resources, and responsibilities, serving as a roadmap for execution, monitoring, and successful completion.
Project Status
Documents
Periodic reports that provide an overview of Project progress, key milestones achieved, challenges encountered, risks, budget updates, and next steps.
These documents ensure stakeholders remain informed and aligned with the Project's status and any necessary course corrections.
Subject Matter
Expert (SME)
An individual designated by the Customer or Versaterm who possesses specialized knowledge and expertise in a specific area relevant to the Project.
SMEs are responsible for providing clarifications, validating requirements, reviewing deliverables, and offering guidance to ensure alignment with business objectives and technical standards. Their involvement is essential for decision-making and successful Project execution.
Cyber Incident An event that threatens the confidentiality, integrity, or availability of Customer information systems, data, or network infrastructure. This includes, but is not limited to, unauthorized access, malware infections, denial-of- service attacks, data breaches, or any activity that violates Customer cybersecurity policies or disrupts normal system operations. 2 ROLES AND RESPONSIBILITIES
2.1 PROJECT MANAGEMENT OVERVIEW
50 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 6
The Customer and Versaterm shall each appoint a Project Manager for the Project, each possessing the experience, knowledge, and authority to make decisions and carry out the tasks outlined in the Project Implementation Schedule and this Statement of Work.
The Project Managers will be the primary points of contact between the Parties during the Project.
Each Project Manager shall be responsible for managing their respective organization’s Project Team resources and ensuring that their assigned Project Team members fulfill their responsibilities. Each will have access to resources necessary to complete the project (personnel, documents, physical areas, etc.), and will be responsible for coordinating administrative and technical decisions within the Project.
While both Project Managers will collaborate to coordinate and support the execution of the Project, Versaterm shall have overall responsibility for managing the Project, including coordinating all implementation activities, ensuring timely completion of deliverables, and meeting the Project objectives. Versaterm’s Project Manager shall oversee the day-to-day execution and integration of workstreams to ensure a successful implementation.
2.2 PROJECT MANAGEMENT TOOLS
The following project artifacts will be maintained on the Customer’s SharePoint site:
• Schedule (will be in MS Project format and posted to the Customer’s SharePoint site. All revisions shall be made on the Customer SharePoint file)
• Issues List
• Task List/Action Items
• Change/Decision log
• Risk List/Register
The Customer shall give the Versaterm Project Manager and Lead Implementer access to the above.
If, for whatever reason, the SharePoint site becomes less than an effective method for sharing this information (mutually agreed upon by Customer and Versaterm), an alternative may be created/provided.
2.3 PROJECT STEERING COMMITTEE
The Project Steering Committee is the primary governance body responsible for overseeing the strategic direction and success of the Project. Comprised of executive and departmental leaders, the committee ensures alignment with Customer-wide priorities, resolves escalated issues, and provides cross-functional guidance. • Resource Allocation: The Project Steering Committee is responsible for securing and allocating the necessary resources— financial, human, and material—to ensure the Project's successful execution. This includes obtaining approval for budgets and ensuring the Project team has the tools and support needed to complete the Project efficiently. • Decision Making : As the ultimate decision-maker, the Project Steering Committee resolves escalated conflicts and makes critical decisions that impact the Project's direction. They provide guidance and support to the Project manager, ensuring that decisions are made in the best interest of the organization. • Change Management : The Steering Committee is responsible for reviewing and approving all formal change orders that impact the project's scope, budget, or schedule. The committee ensures that all change requests are aligned with strategic objectives, are appropriately justified, and have been vetted by the Customer’s Project Manager prior to submission. Their oversight ensures that changes are managed in a controlled, transparent, and accountable manner. 51 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 7
• Leadership and Vision: The Steering Committee is responsible for ensuring that the Project team is aligned with the Project's aims and objectives, fostering a cohesive and motivated environment. Their leadership is crucial in guiding the Project toward achieving its goals.
2.4 VERSATERM PROJECT MANAGER
Versaterm shall retain overall responsibility for project management and successful implementation of all deliverables described in this Statement of Work. The Versaterm Project Manager shall coordinate and manage all implementation activities in collaboration with the Customer’s Project Manager. Versaterm’s Project Manager is responsible for, but not limited to, the following:
2.4.1 PLANNING AND EXECUTION
• Develop and maintain Project Implementation Schedule on Customer’s SharePoint site (initial plan will be drafted by Versaterm PM and posted by the Customer. The Versaterm PM will have access to it thereafter.), including milestones, tasks, and dependencies. The initial plan shall be drafted by Versaterm’s Project Manager, approved by the Customer, and maintained thereafter by Versaterm.
• Ensure all Versaterm deliverables, and implementation activities are completed in accordance with the approved Project Implementation Schedule and any authorized Change Orders. • Lead, coordinate, and oversee the installation of all licensed Versaterm Application Software as well as all System Software and Third-Party Software included in the Agreement.
• Coordinate and oversee the development efforts of all contracted interfaces. • Tracking overall Project status.
2.4.2 COMMUNICATIONS
• Prepare weekly project status reports identifying overall project status, recent accomplishments, outstanding issues, risks, action items, and upcoming events.
• Maintain regular communication with Customer’s Project Manager, providing timely responses, no later than five (5) Business Days, to issues raised by the Customer’s Project Manager. • Conduct, or participate in, regular conference calls (e.g. weekly) to discuss project status updates, open issues, and identified risks
• Work with Customer Project Manager and staff to resolve identified issues and mitigate project risks identified in the Project Issues Log as requiring action
• Facilitate communication between Customer resources and Versaterm resources for Project tasks. • Develop the Communication Plan with assistance and input from the Customer Project Manager.
2.4.3 RESOURCE MANAGEMENT
• Manage internal Versaterm resources and efforts (technical tasks, implementation tasks, Support during the Configuration Phase, interface development efforts)
• Communicate with Customer resources regarding work effort in coordination with the Customer Project Manager
2.4.4 CONFIGURATION WORKSHOPS
• Assist the Versaterm Implementation Specialist during onsite Configuration workshops
2.4.5 TRAINING
• Assist the Versaterm Implementation Specialist in conducting Versaterm Trainer Training • Provide onsite support during the Customer Trainer Training; remote support may be provided in lieu of onsite presence if mutually agreed upon by the Customer.
52 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 8
• Provide onsite support during the Customer End-User Training; remote support may be provided in lieu of onsite presence if mutually agreed upon by the Customer.
2.4.6 ROLLOUT
• Provide onsite support during cutover
• Provide front-line support during post-cutover testing and refinement period
2.4.7 OTHER
• Prepare project Change Order Request Forms per the Agreement • Oversee invoice preparation
2.5 CUSTOMER PROJECT MANAGER
The Customer’s Project Manager will serve as the primary point of contact and will support the coordination of Customer-side implementation activities, in collaboration with the Versaterm Project Manager. The Customer’s Project Manager is responsible for the following:
• Maintaining regular communication with the Versaterm Project Manager. • Coordinate the efforts of the Customer’s staff.
• Coordinating Customer activities with the Versaterm Project Manager. • Participating in regular conference calls and onsite meetings with the Versaterm Project Manager to discuss Project status updates, project issues, risks including mitigation efforts, and upcoming activities. • Reviewing Versaterm’s Project status reports.
• Tracking and resolving outstanding Customer issues and action items for Action Item Log. • Providing timely responses, no later than five (5) Business Days, to issues raised by the Versaterm Project Manager. • Facilitating communication between Customer and Third-Party resources and Versaterm’s resources for System Infrastructure, Interface and Data Conversion tasks.
• Managing communications and coordinating project activities with Third-Party vendors directly under contract with the Customer.
• Coordinating Versaterm access (SharePoint, onsite, and remote) • Providing workspace at the Customer’s project site for Versaterm’s Project Team. • Requesting, discussing, and reviewing Change Order Request Forms prepared by the Versaterm Project Manager. • Coordinating approval and execution of Change Orders and Amendments as needed with the Project Steering Committee.
2.6 ORGANIZATIONS RESPONSIBILITIES DURING THE PROJECT
This section describes the roles and responsibilities of key Project resources throughout the duration of the Project.
2.6.1 VERSATERM RESPONSIBILITIES
Versaterm’s overall responsibility is to establish a designated Project Team for the duration of this project that has the expertise to carry out the assigned Project tasks and responsibilities. The Versaterm Project Team will use their expertise to provide information, guidance, and suggestions to the Customer regarding system requirements. They will also provide best practice recommendations and guidance on system requirements, configuration options, implementation strategies, and workflow considerations.
Although Versaterm Project Team members may not be exclusively assigned to the Project, Versaterm shall allocate sufficient personnel time and resources to meet its obligations under this Statement of Work, including adherence to the Project Implementation Schedule.
53 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 9
2.6.2 VERSATERM PROJECT TEAM
The Versaterm Project Team will consist of, but not limited to a Project Manager, an Implementation Specialist, and a Technical Lead.
The Versaterm Implementation Specialist is responsible for delivering the Configuration workshops to the Customer Project Team, performing the configuration of the Versaterm CAD system based on approved Customer requirements, and reviewing business re- engineering options. The Implementation Specialist shall work collaboratively with the Customer Project Manager and Technical SME to gather input and ensure that configuration decisions align with operational needs and technical feasibility. The Implementation Specialist shall provide guidance on best practices for business processes and ensure alignment with the system’s capabilities. The Implementation Specialist shall provide regular updates to the Versaterm Project Manager and proactively flag any configuration dependencies or decisions requiring escalation.
The Versaterm Technical Lead is responsible for delivering the technical aspects of the Project, including performing system configuration, interface coordination, infrastructure guidance, environment preparation, and system integration support. The Versaterm Technical Lead will assist in Configuration workshops, advise on security and performance best practices, and collaborate closely with the Customer Technical Lead. The Versaterm Technical Lead shall participate in technical discussions with Customer- designated third-party vendors and support data conversion planning and testing activities. The Versaterm Technical Lead shall provide regular updates to the Versaterm Project Manager and coordinate directly with the Customer Technical Lead on all technical deliverables and timelines. .
Versaterm shall ensure that sufficient personnel and expertise are assigned to meet the obligations of this Statement of Work and to support successful Project execution. The roles identified above represent the initial core team; however, Versaterm is responsible for augmenting or expanding its Project Team, as needed, to address workload demands, meet Project milestones, and ensure timely completion of the Project.
2.6.3 CUSTOMER RESPONSIBILITIES
The Customer’s overall responsibility is to establish a Project Team for the duration of this Project. The Project Team members should have the expertise to carry out the assigned Project tasks and responsibilities as indicated in this Statement of Work.
Although Customer Project Team members may not be exclusively assigned to the Project, Customer shall allocate sufficient personnel time and resources to meet its obligations under this Statement of Work, including adherence to the Project Implementation Schedule.
The Customer is responsible for providing desktop computers and mobile workstations for the Customer to use during the Configuration phase. The Customer workstations must meet Versaterm’s minimum specifications as specified in Exhibit B.6 – Minimum Client and Peripheral Specifications.
2.6.4 CUSTOMER PROJECT TEAM
The Customer will provide a Project Team consisting of, but not limited to, the following roles, which may change based on project need:
• Project Manager as defined in Section 2.5
• Technical Lead - responsible for providing subject matter expertise on the Customer’s technical environment, including infrastructure, integrations, mapping (GIS), and system access. This role supports Configuration workshops, interface coordination, data extraction and validation, and environment readiness. The Technical SME will work closely with the Versaterm Technical Lead to align technical deliverables and will act as the primary liaison for involving other Customer technical resources as needed to support the Project.
54 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 10
• Police Dispatch SME - responsible for providing subject matter expertise on the Police Department’s dispatching Standard Operating Procedures (SOPs) and current Police CAD functionality. This role supports Configuration workshops, testing, and environment readiness. The Police Dispatch SME will work closely with the Versaterm Implementation Team to align functional configuration of the CAD and will act as the primary liaison for involving other Police Dispatch resources as needed to support the Project.
• Fire Dispatch SME - responsible for providing subject matter expertise on the Fire Department’s dispatching Standard Operating Procedures (SOPs) and current Fire CAD functionality. This role supports Configuration workshops, testing, and environment readiness. The Fire Dispatch SME will work closely with the Versaterm Implementation Team to align functional configuration of the CAD and will act as the primary liaison for involving other Fire Dispatch resources as needed to support the Project.
• Police Mobile SME - responsible for providing subject matter expertise on the Police Department’s Incident Response Standard Operating Procedures (SOPs) and current Police CAD/Mobile functionality. This role supports Configuration workshops, testing, and environment readiness. The Police Mobile SME will work closely with the Versaterm Implementation Team to align functional configuration of the MDT and will act as the primary liaison for involving other Police Incident Response resources as needed to support the Project.
• Fire Mobile SME - responsible for providing subject matter expertise on the Fire Department’s Incident Response Standard Operating Procedures (SOPs) and current Fire CAD/Mobile functionality. This role supports Configuration workshops, testing, and environment readiness. The Fire Mobile SME will work closely with the Versaterm Implementation Team to align operational needs and will act as the primary liaison for involving other Fire Incident Response resources as needed to support the Project.
• Training Lead - responsible for coordinating with Versaterm on the creation of Training materials and strategizing and conducting End User and ongoing Training. This role could be assumed by one/some of the SME’s listed above.
2.7 PROJECT IMPLEMENTATION SCHEDULE
The Project Implementation Schedule will be updated as necessary over the course of the Project. All changes to the schedule will be mutually agreed upon and, if required, documented via the mutually agreed upon Change Order Process.
2.8 TASK COMPLETION AND MILESTONE PAYMENT
When all Task Completion Criteria have been met for each task in this Statement of Work or the corresponding Exhibits, the Versaterm Project Manager will be responsible for providing written notification (via email) to the Customer Project Manager, specifying the task and confirming the criteria that were met.
All such tasks are subject to the Customer’s formal review and approval before being considered accepted, regardless of whether the task is associated with a milestone payment. The Customer Project Manager will notify the Versaterm Project Manager of the approval or will provide written feedback identifying any deficiencies if the task does not meet the defined Task Completion Criteria.
The Customer will retain a copy of the confirmation or feedback for documentation purposes, and milestone payments shall only be made upon the Customer’s formal approval of the corresponding task(s).
2.9 CHANGE CONTROL
To maintain alignment, transparency, and control throughout the course of the Project, the following change control procedures shall apply to any modifications to the Project Implementation Schedule, scope of work, or cost:
2.9.1 PROJECT SCHEDULE ADJUSTMENTS
55 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 11
Minor adjustments to the Project Implementation Schedule that do not affect the Project’s critical path or overall go-live date may be reviewed and approved jointly by the Customer and Versaterm Project Managers. Such adjustments include resource availability changes or internal task re-sequencing that do not impact major milestones.
However, any proposed schedule change that affects the Project’s critical path or results in a delay to the agreed-upon go-live date shall be escalated to the Project Steering Committee for review and approval. The Versaterm Project Manager shall be responsible for updating the Project Implementation Schedule upon approval of the change.
2.9.2 SCOPE AND COST CHANGE ORDERS
All changes that affect the scope of work, deliverables, or cost shall require a formal Change Order, to be reviewed and approved by the Project Steering Committee prior to implementation. Each Change Order must include:
• A description of the proposed change,
• Its impact on the scope, schedule, deliverables, and cost, • Any associated risks or resource implications.
Change Orders shall not be considered authorized or binding until approved in writing by the Customer and incorporated into the Agreement by amendment if required.
3 SOFTWARE DELIVERABLES
This section describes the Project’s software deliverables to be provided by Versaterm. Detailed information regarding some deliverables may be found elsewhere (Interface Control Document (Exhibit B.3). • Cost information for each deliverable is included in Exhibit B - CAD SaaS Service Schedule for Cloud. Options Customer elects to include in the project scope will add cost and will be paid according to the Change Order. Interfaces, options, and priced components that the Customer removes from scope will result in a credit toward cost, as designated by the particular Change Order.
3.1 SOFTWARE
• See Exhibit B – CAD SaaS Service Schedule for Cloud
3.2 INTERFACES – FOR GO-LIVE
• See Exhibit B.3 – Interface Control Document
3.3 INTERFACES – FOR POST-LIVE
• See Exhibit B.3 – Interface Control Document
3.4 REDUNDANCY AND BACKUP DELIVERABLES
The Versaterm cloud CAD makes use of multiple back-end application instances, supporting an active-active configuration, that are load balanced across AWS Availability Zones (AZs). Availability Zones are separate datacenters connected to each other via low latency network links and completely separate infrastructure. This makes the CAD not only highly available, but fault tolerant as well since an outage of a single node or availability zone (datacenter), will not cause an extended outage to the end user (users will be automatically re-directed to the surviving datacenter/nodes where they may have to re-authenticate/login to the CAD). While the Versaterm CAD vCloud configuration provides resiliency across datacenters/AZs, it does not protect against an outage of the entire AWS GovCloud Region.
CAD users connect to the application by means of a highly available load balancer in the AWS infrastructure. The CAD system will utilize Open ID Connect (OIDC) to connect to Microsoft Entra ID for user authentication. 56 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 12
The underlying application and data files are stored across the AZs, which provides resiliency. Multiple copies of the files and database are maintained. This configuration will provide the 99.99% availability requested (See Exhibit B – CAD SaaS Service Schedule for Cloud: Section 7 System Performance and Availability Standards for exceptions) as well as 99.999999999% (11-9s) durability of stored data (for files stored on and backed up to AWS S3 data storage).
All the data in the CAD is encrypted at rest and in transit including database backups and data files. A strict backup mechanism further ensures that the entire environment is safe should any unforeseen problem cause major issues in the main environments. A rotation of daily and monthly snapshot backup files will be copied to AWS’s S3 file storage system, which is encrypted and highly resilient (a minimum of 3 copies of the data is kept).
4 KEY ASSUMPTIONS
4.1 SOFTWARE VERSION
• Versaterm will supply the latest available released version of the products to the Customer at Go-Live. • As a hosted System, Versaterm will keep the products up to date with the latest release, within the parameters of Versaterm’s Update and Upgrade processes.
5 STATEMENT OF WORK TASKS
This section describes the Project’s major implementation tasks, identifying Customer and Versaterm responsibilities, prerequisites, Versaterm deliverables and completion criteria for each task.
The precursors, start dates, durations, and responsible resources for each task are tracked in the Project Implementation Schedule (Exhibit B.2). Statement of Work tasks outlined below and the tasks in the Project Implementation Schedule may not always start and complete in a sequential manner.
5.1 PLANNING & CONTRACT DEFINITION PHASE - TASK 1
TASK #1.3 EXECUTE CONTRACT
The Project will officially start upon the Effective Date of the Agreement.
Leading up to this task, the Customer and Versaterm Project Managers will have coordinated and completed all Scoping and Contract Negotiation efforts and have agreed in principle on the updated framework of the Contract.
VERSATERM DELIVERABLES
• Provide milestone invoice as per Exhibit B – CAD SaaS Service Schedule for Cloud
5.2 PROJECT INITIATION PHASE - TASK 5
TASK #5.1 INITIATE PROJECT
The Project will officially start upon the Effective Date of the Agreement.
TASK #5.2 PROJECT KICKOFF MEETING (TIMELINE MILESTONE #1) Customer and Versaterm Project Managers will collaborate to develop the agenda and materials for the Project Kick-off meeting/workshop to introduce the project to Customer Project Team and key stakeholders. This workshop will include a high- level presentation covering the following topics:
57 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 13
• Overall project scope
• Key contract elements
• Customer Project Team introduction
• Customer Project Team requirements, roles, and assignments • Versaterm Project Team introduction
• Versaterm roles and assignments
• Project Implementation Schedule
• Other key project details (e.g., risks, communication plan, change management)
VERSATERM RESPONSIBILITIES
• Work with the Customer to develop the Kickoff Presentation. • Participate in the Project Kickoff Meeting.
CUSTOMER RESPONSIBILITIES
• Provide location and logistical support for Project Kickoff meeting. • Invite the Project Team and other key stakeholders to attend the meeting. • Participate in the Project Kickoff presentation.
PREREQUISITES
• Project Implementation Schedule has been finalized.
TASK COMPLETION CRITERIA
• Project Kickoff Meeting concluded.
5.3 PROVISIONING PHASE - TASK 7
TASK #6 ESTABLISH AWS CONNECTIVITY
This task is to establish connectivity between the Customer and the vCAD installed in the Versaterm VPC (Virtual Private Cloud) in the AWS GovCloud (US) Region. Separate VPCs are supported for the vCAD Production and Non-Production environments.
A secure redundant connection (tunnel) is being established between the Customer and the Versaterm VPC in the AWS GovCloud (US). It is assumed that all customer access to the Versaterm CAD will be done through this secure connection. That is, a user must first authenticate and connect to the local Customer network before gaining access to the CAD. This applies to all users, including any remote or external users (e.g. court or other). Users will not be able to access the CAD without coming through the established secure tunnel between the Customer and the Versaterm VPC.
All exchanges between the Versaterm applications in the AWS GovCloud (US) and any onsite servers or services (interface servers, FTP servers, etc.) will communicate through the secure connection (tunnel) established between the Customer and the Versaterm VPC in AWS.
The Customer can connect to AWS via either an Internet connection (Customer Gateway IPSec VPN tunnel routable through the Internet), or a Direct Connect connection to AWS. Costs and requirements will differ for each (costs for a Direct Connect link to AWS are not included as part of the costs provided by Versaterm). If using a Direct Connect link to AWS, the Customer will need to provision the Direct Connect connection under their own AWS Account. The Customer would then set up a VPC to do an inter-VPC link to Versaterm’s (transit) VPC in GovCloud.
Redundant connections are recommended to minimize service interruption (either two separate Direct Connect links; two separate Internet connections; or one Direct Connect link and a separate backup Internet connection). 58 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 14
All connections to the Versaterm VPC in AWS GovCloud, whether an Internet connection or Direct Connect link, will go through an encrypted IPSec VPN tunnel. To configure an IPSec VPN tunnel on a Direct Connect link, the Direct Connect link must connect to a public VIF in AWS.
VERSATERM RESPONSIBILITIES
• Work with the Customer to review and finalize connectivity to AWS, including reviewing connectivity requirements, data transfer and network bandwidth requirements, and level of service required (redundancy requirements) • Work with the Customer to confirm how the Customer will connect to AWS (Customer Gateway IPSec VPN tunnel (routable through the internet), or Direct Connect connection to AWS, or combination of both) • Provide a list of network ports and services that need to be enabled (opened) between the Customer local network and AWS (both ways)
• Versaterm will provide a list of supported IPSec VPN hardware to the Customer (for the local customer VPN hardware) compatible with AWS/Versaterm’s VPN solution
• Versaterm will supply requirements to the Customer to connect to our VPN end points in AWS GovCloud (US) • Enable Customer access to the Versaterm VPC(s) in the AWS GovCloud (US) Region • Define routing rules for the Customer provided IP ranges, on the Versaterm core VPN tunnel, for access to any Customer on-premises servers/services Versaterm CAD will need access to (for interfaces, etc.) • Test connectivity with the Customer
CUSTOMER RESPONSIBILITIES
• Provide a local network specialist who can work with the PD and Versaterm to establish the required network connectivity • Review network bandwidth requirements, and network connection redundancy requirements with Versaterm to determine how the Customer will connect to AWS (Customer Gateway IPSec VPN tunnel, or Direct Connect connection to AWS) • Identify onsite servers/services/interfaces Versaterm CAD is to connect to • Provide connectivity to AWS,
o provide a secure connection for access to the Versaterm VPC(s) in the AWS GovCloud (US) Region; the connection must be capable of supporting the Customer bandwidth requirements identified above o to minimize service interruptions, separate, redundant connections are required; dedicated circuits are preferred o if Direct Connect connection(s) to AWS is to be supported (as determined by local bandwidth and other requirements), work with the Customer local telco provider, AWS, AWS Direct Connect Partner, and Versaterm to finalize detailed requirements and establish required Direct Connection(s) to the Versaterm VPC(s) in the AWS GovCloud Region
• Provide Customer Gateway VPN(s),
(for clarity, a Customer Gateway is a physical device or software application on the Customer side of the VPN connection) o provide secure IPSec Customer Gateway VPNs capable of meeting Customer connectivity and bandwidth requirements. Customer Gateway VPNs compatible with the AWS/Versaterm supported platform (as provided by Versaterm) are required. Redundant Gateways/VPNs are also required to minimize service interruption o IPSec Customer Gateway VPNs must support and be certified for FIPS 140-2 o provide Customer Gateway VPN hardware (e.g. Cisco), platform (e.g. ISR Series Routers), and software version (IOS
12.4) to Versaterm
59 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 15
o provide internet-routable IP address for the Customer Gateway VPN(s)’ external interface which Versaterm will use when configuring our VPN end points (value must be static); Customer Gateway VPN(s) may reside behind a device performing network address translations (NAT)
o provide the Customer BGP ASN (Border Gateway Protocol, Autonomous System Number) to Versaterm, if any o identify IP range (IP subnet pre-fixes) for all nodes connecting to the Versaterm VPC(s), including user desktop workstations and any Customer onsite servers the Versaterm CAD will need access to (for interfaces, etc.) o configure Customer Gateway VPN device(s) as required to support access to the Versaterm VPC(s) • Provide a method of local auditing of connections on a per user basis • In the case of IP subnet conflicts, the Customer will be responsible for resolving the conflicts (using NAT translation, or other) on their local network interface
• Test connectivity with Versaterm (for The Customer internal, and remote/external users) • Monitor network and Customer Gateway VPN connections and troubleshoot any issues that arise • Provide 7x24 technical network support
PREREQUISITES
Initiate Project.
DELIVERABLES
• List of required network ports and services that need to be enabled • List of requirements to connect to the Versaterm VPN end points in AWS GovCloud (US Region). • Enable Customer access to the Versaterm VPC(s) in the AWS GovCloud
TASK COMPLETION / ACCEPTANCE CRITERIA
The task will be complete when all the following actions have been completed to the Customer's satisfaction and an Acceptance Certificate has been issued by the Customer for all Deliverables associated with this task. • Customer connectivity is installed, configured, and The Customer is able to connect to the Versaterm VPC in the AWS GovCloud (US) Region.
TASK(S) #7.1 - #7.5 BUILD DEV/TEST ENVIRONMENT
Configure the CAD/MDT server Application Software within the implementation / test VMWare images and install the CAD/MDT desktop Application Software within the designated Implementation Team workspace and on each of the team’s workstations.
System implementation will be conducted on the AWS (Amazon's Web Service) “non-prod” environment. In this configuration the non-prod (non-production use) environment will contain both a test system and a training system. Both systems will be available for implementation use. The test system will be used for interface development and testing while the training system will be used for the core implementation tasks. As interfaces are completed, they will also be installed on the training system in coordination with the Customer’s team.
VERSATERM RESPONSIBILITIES
• Configure the Versaterm server Application Software within the implementation / test VMWare images. • Load mutually agreed upon initial tables such as ‘User Identification Numbers’. • Load the street files, if available.
• Configure the initial CAD and MDT MapViewer.
• Create one operating-system printer and instruct the Customer on how to create additional printers. • Provide the Customer with the CAD desktop Application Software and MDT Application Software for installation on the classroom workstations and the implementation team’s workstations. 60 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 16
CUSTOMER RESPONSIBILITIES
• Assist Versaterm as needed.
• Provide GIS shapefiles and map packages as required to create the Master Street Index file and initial map configuration. • Work with Versaterm to identify the initial tables to be loaded such as ‘User Identification Numbers’. • Create required operating-system printer definitions. • Create user accounts required by the Customer’s Implementation Team to access the Versaterm application suites. • Install and configure the CAD and MDT Customer Application Software on designated workspace and implementation team workstations.
PREREQUISITES
• Project Kickoff Meeting concluded.
• Establish communications to AWS
• Customer has provided local values for select Versaterm CAD tables.
VERSATERM DELIVERABLES
• Versaterm-provided documentation on how to install and configure the Customer module (CAD and MDT) on Customer workstations.
TASK COMPLETION CRITERIA
• The Versaterm server Application Software is configured within the implementation / test VMWare images; and • The CAD/MDT desktop Application Software installed on the workspace and Implementation Team’s workstations and is fully functional.
TASK #7.6 PREPARE A CONFIGURATION LAB/CLASSROOM
Equip a facility that will be available to the Implementation Team throughout the implementation period.
The Customer will provide a workspace(s) that will accommodate all implementation team members during the implementation sessions. This space must remain operational to the implementation team members for the duration of the project for configuration and testing assignments. The workspace must be equipped with two computer projectors, a computer workstation for the instructor, and a computer workstation for each implementation team participant. The minimum effectiveness is space for five Team Members.
VERSATERM RESPONSIBILITIES
• Provide the Customer with desktops, network requirements and projection requirements for the workspace facilities. • Identify the number of workstations required for minimum effectiveness.
CUSTOMER RESPONSIBILITIES
• Provide a suitable workspace facility, including desktop workstations with two monitors for each of the Implementation Team Members, a desktop workstation for the instructor and projection facilities. • Ensure the workstations meet the minimum specifications as set forth in “Exhibit B.6 – Minimum Client and Peripheral Specifications”.
• Provide network access from each workstation to the Versaterm application servers.
TASK COMPLETION CRITERIA
• The workspace is available and fully functional as described above.
TASK #7.9 INITIAL CAD ENVIRONMENT PROVISIONED (SUBSCRIPTION START) (TIMELINE MILESTONE #2) 61 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 17
Configure the CAD and mobile Application Software and install the vCAD/vMDT/vMobile Customer software within the designated Customer’s project classroom workspace and on each of the team’s workstations. This task signifies that the cloud environment has been provisioned, and the annual subscription begins.
VERSATERM RESPONSIBILITIES
• Configure the Versaterm server Application Software installed in the AWS Cloud. • Connect the System to the Customer’s Active Directory. • Load mutually agreed upon initial tables such as ‘User Identification Numbers’. • Load the street files, if available.
• Configure the initial CAD and MDT MapViewer.
• Provide the Customer with the CAD and mobile Application Customer Software for installation on the classroom workstations and the Customer’s project team’s workstations.
CUSTOMER RESPONSIBILITIES
• Assist Versaterm as needed.
• Provide GIS shapefiles and map packages as required to create the master street index file and initial map configuration. • Work with Versaterm to identify the initial tables to be loaded such as ‘User Identification Numbers’. • Create Active Directory user accounts required by the Versaterm and the Customer’s project team to access the Versaterm application suites.
• Install and configure Customer Application Software on designated workspace and project team workstations.
PREREQUISITES
• Provisioning non-production environment.
VERSATERM DELIVERABLES
• Versaterm-provided documentation on how to install and configure the Customer modules on Customer workstations and mobile devices.
TASK COMPLETION CRITERIA
• The vCAD Application Software is configured in the AWS Cloud; and • The CAD and mobile Customer Application Software are installed on the workspace and project team’s workstations and is fully functional.
5.4 GIS – TASK 8
Several components within the System will utilize the Customer provided geographic information system (GIS) data. It is the Customer’s responsibility to provide and maintain the GIS data that will be used by these System components. The GIS Interface Control Document (ICD) in Exhibit B.3 of this SOW establishes the requirements for the System's GIS information.
The Versaterm GIS Interface (VGI) creates the required System GIS data files by extracting the required information from ESRI shape files provided by the Customer.
The successful deployment of the System is contingent upon the Customer providing the required GIS data in the proper format and with the proper content.
62 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 18
As part of this task, Versaterm will provide training to the designated members of the Customer's Implementation team to provide an overview of the System's GIS structure and to review the requirements for the VGI data files. This training will also provide instruction on how to use the VGI tool to extract geo-related information (street names, ranges, intersections, addresses) from the map-based (ESRI) shape and landmark/common place name files for loading into the System's Street Index.
Following this training and throughout the Project, Versaterm will provide assistance and guidance as required to the Customer's GIS personnel in obtaining, merging, pre-processing, and loading the required GIS data into the System and adequately testing and correcting.
VERSATERM RESPONSIBILITIES
• Coordinate and schedule the vGIS training session with the Customer’s project manager. • Provide vGIS training session requirements to the Customer’s GIS lead. • Provide required skills and any pre-requisite training required by trainees. • Provide documentation and material required for the training in a format suitable for reproduction in an electronic format prior to the scheduled training sessions.
• Provide any mutually agreeable updates to the ESRI Geofile section of the Interface Control Document (ICD) Error! Reference source not found. prior to the scheduled Training Session. • Provide network requirements to access the vGIS software tool. • Lead and provide remote vGIS training session that provides an overview of the System's GIS structure, reviews the GIS data file requirements, and provides instructions on how to configure and run the vGIS tool. • Provide the Customer with assistance and guidance in obtaining, merging, processing, and loading the ESRI GIS data into the vGIS and Versaterm’s CAD.
• Assist the Customer’s GIS lead with resolving any issues the Customer encounters. • Respond to Customer questions in a timely manner.
• Assist, as required, with analyzing vGIS errors resulting from loading Customer-provided GIS data into the System.
CUSTOMER RESPONSIBILITIES
• Gather, prepare, and pre-process the required GIS data for the Training Session. • Provide workstations for running/processing the VGI Software tool that meets Versaterm specifications. • With Versaterm assistance, install the VGI Software tool provided. • Coordinate the location and scheduling of the remote VGI Training Session with Versaterm’s Project Manager. • Identify and schedule the VGI Training Session trainees. • Reproduce and provide the required Documentation and training materials to VGI Training Session trainees. • Ensure that the designated trainees attend the scheduled VGI Training Session.
PREREQUISITES
• Configuration workshop #1
• Required GIS data available in the required format and with the proper content.
VERSATERM DELIVERABLES
• GIS data required for the Training Session in the proper format and with the proper content. Fully operational VGI Software tool installed and Configured on Customer provided workstations. • VGI Training trainee pre-requisite training and required skill set. • VGI Training Documentation and material for each trainee. • Completed VGI Training Session per the Project Schedule.
TASK COMPLETION CRITERIA
• Completed VGI Training Session.
• Trainees have been adequately trained on the agreed upon VGI Training topics and are able to use the VGI tool effectively. 63 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 19
5.5 CAD/MDT IMPLEMENTATION & CONFIGURATION - TASK 9
The purpose of the Configuration Phase is to build and configure the System.
These tasks and deliverables include both technical tasks and software familiarity tasks. Technical tasks involve activities such as the setup of the software, the development of the interfaces, testing of data conversion runs, and building agency-specific stylesheets, reports, and dashboard configurations, whereas software familiarity tasks involve a number of activities that take place in the form of Configuration Workshops (most will be held virtually).
Configuration Workshops provide the Customer’s Project Team with an overall understanding of the Versaterm applications and interfaces, including various configuration options. During this Configuration Phase, configuration workshops will be mutually scheduled by the project managers. The workshops focus on reviewing/discussing the needs of each Business Unit that will be using the respective Versaterm solutions. Any additional sessions focused on special topics as deemed appropriate by Customer and Versaterm, will also be mutually scheduled during this phase.
The topics covered in each Workshop week are prepared by Versaterm (designed to provide gradual learning experience), where each day will incorporate a combination of product demonstrations, system configuration explanations, business practice analysis, business workflow process discussions, and some hands-on exercises. In addition to product familiarization, the Workshops also focus on discussing current-versus-future workflow processes, and the impacts the future process will have on the affected end- users.
It is the Customer and Versaterm’s intention to conduct configuration workshops in person at a classroom facility provided by the Customer, unless mutually agreed that a workshop would be conducted remotely. The classroom will remain operational to the Customer’s project team members for the duration of the project for configuration and testing assignments. The classroom facility must include 2 computer projectors, a computer workstation for the instructor and a computer workstation for each Customer’s project team participant. Each workstation should be equipped with two monitors.
TASK(S) #9.1 - #9.4 CAD/MOBILE CONFIGURATION WORKSHOPS
During the Project Kickoff Workshop, Versaterm will have provided the Customer's Project Team with a high-level introduction to the Versaterm CAD and Mobile applications.
The high-level introduction involves an overview of the functionality, features, and configuration options, as well as a discussion of potential re-engineering points. The specific activities include demonstrations of the products, hands-on exercises and group discussions. Versaterm will devote time to the Customer’s Project Team to present their current business practices as a contribution to the discussions regarding business process reengineering. During each subsequent session, Versaterm will provide detailed demonstrations of additional configuration options and will facilitate further discussion of business process re-engineering opportunities. The result of such discussions will provide a roadmap for Versaterm’s configuration activities.
VERSATERM RESPONSIBILITIES
• Coordinate and schedule Configuration Workshops for each line of Business with the Customer’s Project Manager. • Provide an agenda with objectives and business processes to review no less than ten (15) Business Days prior to the scheduled sessions.
• Provide one reproducible copy of the Documentation and any required session materials (User and Configuration guides) in soft copy at least ten (10) Business Days prior to the scheduled workshop. • Conduct in-depth demonstrations of the Application Software, identifying functionality and features supported, re- engineering points and configuration options.
• If possible, provide hands-on exercises for the Project Team members to get familiar with the Systems. 64 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 20
• Assist the Customer's Project Team in reviewing the Customer’s existing business processes and paper forms as compared with System data flow and table options.
• Discuss workflow analysis to assess any required business re-engineering impacts. • Review the System Configuration progress to-date during each Configuration Workshop. • Review outstanding Configuration and business process re-engineering issues. • Document any required Customer business re-engineering points and any issues discussed during Configuration Workshops that need to be resolved.
CUSTOMER RESPONSIBILITIES
• Coordinate the location and scheduling of the Configuration Workshops with the Versaterm Project Manager. • Identify and schedule the Configuration Workshops attendees. • Reproduce and provide the required Documentation and materials (User and Configuration guides) for Configuration Workshops participants in both hard and soft copy formats. • Ensure that designated Configuration Workshops participants fully participate in the scheduled workshop. • Prepare and lead reviews and discussions of the Customer’s existing business processes identified in workshop agendas. • Identify and make notes of known/potential workflow, process, job, and/or report changes.
PREREQUISITES
• Development/Test environment has been set up.
• Application Software has been delivered and installed.
VERSATERM DELIVERABLES
• Configuration Workshop materials (User and Configuration guides) in hard and soft copy format for each workshop participant.
• Delivery of Configuration Workshops.
TASK COMPLETION CRITERIA
• Workshop participants have received sufficient training to navigate and assist with the System Configuration. • Any required Customer business process re-engineering points covered during the workshop have been identified and documented.
• All identified issues have been documented in the Action Items Log. • Configuration Workshops completed.
TASK #9.3 CONFIGURATION WORKSHOP #2 COMPLETED (TIMELINE MILESTONE #3) Versaterm and the Customer shall meet or participate in conference calls to review and Sign-Off on Configuration Phase.
VERSATERM DELIVERABLES
• Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
• The CAD, MDT, and vMobile Configuration Workshop #2 has been completed and accepted by the Customer.
TASK #9.4 CONFIGURATION WORKSHOP #3 COMPLETED (TIMELINE MILESTONE #4) Versaterm and the Customer shall meet or participate in conference calls to review and Sign-Off on Configuration Phase.
VERSATERM DELIVERABLES
65 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 21
• Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
• The CAD, MDT, and vMobile Configuration Workshop #3 has been completed and accepted by the Customer. • Configuration has been accepted, and the Agency is ready for Testing.
5.6 INTERFACE DEVELOPMENT PHASE - TASK 10
TASK #10 DEVELOP AND INSTALL INTERFACES
The Interfaces identified in Interface Control Document (Exhibit B.3) will be developed, installed and tested.
Interface development will follow Agile methodology to allow for contingencies (i.e., certain things can change once both Parties start developing). While Exhibit B.3 - Interface Control Document, serves to provide a high-level definition of the Scope, expectations and roles/responsibilities of each Interface, there is flexibility for making changes to the Interface expectations once the development and testing process begins, so long as Versaterm and the Customer mutually agree to any changes.
Any changes agreed upon are to be documented within Exhibit B.3 - Interface Control Document and must be executed prior to continuing with the Interface development effort.
VERSATERM RESPONSIBILITIES
• Collaboratively, with the Customer and other Interface stakeholders, design, develop and install the Interfaces in accordance with each Interface's ICD.
• Discuss with the Customer and other Interface stakeholders any required changes in Interface Implementation from the Interface's ICD.
• Document additional details and any exceptions and/or deviations from an Interface's ICD in a revised ICD for that Interface.
• Prepare a Change Order or Amendment, whichever is appropriate, for any significant changes to an Interface's ICD. • Schedule Interface tests at least ten (10) Business Days prior to the scheduled testing. • Perform initial testing on the Interfaces and provide the Customer with verification of functionality.
CUSTOMER RESPONSIBILITIES
• Collaboratively with Versaterm and other Interface stakeholders participate in the design, development and installation of the Interfaces in accordance with each Interface's ICD. • Review and approve any required changes to an Interface ICD. • Arrange for execution of mutually agreed upon ICD Change Orders or Amendments. • Provide the most updated Documentation available from appropriate third-party Interface stakeholders as required by Versaterm to complete the Interfaces.
• Provide all liaison support with third-party Interface stakeholders as required to support the installation and testing of the Interfaces.
• Complete the tasks listed as Customer responsibilities specified in Interface Control Document (Exhibit B.3). • Coordinate with Versaterm and third-party Interface stakeholders to schedule Interface tests. • Provide test facilities for the Interfaces.
• Verify the functionality of the Interfaces.
PREREQUISITES
• Set up Development/Test Environment
VERSATERM DELIVERABLES
• Documentation for any changes to the Interface Control Document. 66 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 22
• Design Specifications for each interface defined in Interface Control Document (Exhibit B.3). • Implementation of Interfaces as defined in the Interface Control Document. • Training as appropriate for each interface.
TASK COMPLETION CRITERIA
• Interface Control Documents (ICDs) are updated as required to Implement the Interfaces. • The set of System Interfaces are installed and tested to verify that they operate in accordance with the ICDs contained in the Interface Control Document (Exhibit B.3).
5.7 BUILD PRODUCTION ENVIRONMENTS – TASK 12 (TIMELINE MILESTONE #5) System production use will be conducted on the AWS production environment. In this configuration the production (production use) environment will contain the Production system, which includes a read-only reporting database. This Production system will be installed by Versaterm and will consist of all System implementation data and interfaces (once completed). Although not mandatory, Versaterm does recommend training be performed on the Production system in order to exercise the entire system.
Versaterm will notify the Customer when it is satisfied that the System is ready for Training and Functional Acceptance Testing in the Production Environment.
VERSATERM RESPONSIBILITIES
• Provide the AWS Cloud computing system containing the Production system. • Assist the Customer with AWS networking configurations and ensure access to the AWS Cloud production environment. • Provide details on required ports that must be opened or configured. • Migrate configuration data from implementation / test environment to the production environment (including Customer’s GIS data).
• Conduct informal system testing on the Production environment prior to the formal system testing performed by the Customer.
CUSTOMER RESPONSIBILITIES
• Configure networking for access from the Customer network to the AWS Cloud Production environment. • Ensure all ports/services are opened or configured as per Versaterm requirements. • Conduct system testing on the production environment.
TASK COMPLETION CRITERIA
• The Production environment is configured and tested with Torrance-specific requirements (as configured during system Implementation), and the parties agree that it is operational.
5.8 TESTING PHASE - TASK 13
TASK #13.1 INTERFACE INTEGRATION TESTING
The purpose of the Interface Integration Testing is to demonstrate and verify that all interfaces specified in the Interface Control Document (Exhibit B.3) meet or exceed the functionality and performance, that each interface is operational and ready for Functional Acceptance Testing, and that the data conversion was/will be successful.
The Interface Integration Testing occurs during the Configuration Phase of the implementation as interfaces are completed.
The Interface Control Document (Exhibit B.3) provides details regarding the strategy, schedule, dependencies, environment, problem tracking and remedies, and completion criteria. 67 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 23
An Interface will be excluded from the Interface Integration Testing should the Customer be unable to meet the related Interface Customer responsibilities specified in the ICD. A Change Order or Amendment, whichever is appropriate, will be generated to document any changes.
VERSATERM RESPONSIBILITIES
• Provide the Customer with an electronic version of interface design specifications for the interfaces defined Interface Control Document.
• Coordinate and schedule the Interface Testing efforts with the Customer's Project Managers. • Demonstrate each interface to the Customer’s Project Team. • With the assistance of the Customer's Project Team, test each interface to ensure that it meets or exceeds the functionality and performance measurements specified in the Interface Control Document (Exhibit B.3). • Document and track all defects reported by the Customer. • Review and correct any discrepancies per the Acceptance Test Plan. • Provide training to the Customer on interface setup, configuration, administration and usage of each interface.
CUSTOMER RESPONSIBILITIES
• Coordinate and schedule the Interface Testing efforts with the Versaterm Project Manager. • Identify and schedule Interface Testing with the relevant Customer participants. • Reproduce and provide the interface design specifications from Versaterm to the relevant Customer participants that will be involved in the Interface Testing.
• Ensure that the designated Customer participants attend and participate in the scheduled Interface Testing. • Work with Versaterm to test each interface, identifying the type of correction needed to ensure that each interface conforms to the Interface Control Document (Exhibit B.3). • Retest any interfaces that did not meet the specifications.
PREREQUISITES
• Install of the Development/Test and Production environments • Develop and install interfaces
VERSATERM DELIVERABLES
• A tracking document to track all issues reported.
• Corrections to errors or issues identified during Interface Testing.
TASK COMPLETION CRITERIA
• The Customer has verified that all interfaces operate as specified in the Interface Control Document (Exhibit B.3). • The Customer’s Project Team and other select Customer staff are sufficiently trained to be able to administer, manage, and fully use each interface.
TASK #13.2 FUNCTIONAL ACCEPTANCE TESTING
The purpose of Functional Acceptance Testing is to verify that the fully configured System, including the interfaces specified in the Interface Control Document (Exhibit B.3), and the workflows and business processes such as data entry, reports, notifications, tasks, etc. meet the functional requirements described in the Agreement and system documentation.
The Functional Acceptance Testing occurs after the Configuration Phase and before the Training Phase of implementation.
VERSATERM RESPONSIBILITIES
• Provide support to the Customer as it conducts the Functional Acceptance Testing. • Review, verify, and correct all defects reported by the Customer. 68 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 24
• Review any discrepancies found during the Functional Acceptance Testing. • Correct any functional item that fails a test.
CUSTOMER RESPONSIBILITIES
• Generate any production data files needed for Functional Acceptance Testing. • Report all defects to Versaterm.
• Work with Versaterm to identify the correction needed to ensure that the System conforms to the System's expectations. • Notify Versaterm in writing when Functional Acceptance Testing is completed.
PREREQUISITES
• Configuration Phase
• Interface Testing
• GIS data processed
• Set up the Development/Test and Production environments
VERSATERM DELIVERABLES
• Document and track all defects reported by the Customer.
TASK COMPLETION CRITERIA
• The System and interfaces have been verified by the Customer to operate as specified in the Agreement TASK #13.2.3 ATTACH FUNCTIONAL ACCEPTANCE TESTING ACCEPTANCE EMAIL (TIMELINE MILESTONE #6)
The Functional Acceptance Testing is considered complete when Versaterm has remedied all deviations and the Customer has notified Versaterm that it has completed the Functional Acceptance Tests.
VERSATERM DELIVERABLES
• Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
All Functional Acceptance Testing has been completed, and Customer is ready to proceed with the Training Phase.
5.9 TRAINING PHASE - TASK 14
TASK #7.6 PREPARE A CONFIGURATION LAB
The Customer is responsible for providing and preparing the necessary training facilities for training end users.
VERSATERM RESPONSIBILITIES
• Provide the Customer with the technical requirements for the training facilities.
CUSTOMER RESPONSIBILITIES
• Provide network access requirements for remote training facilities being prepared by the Customer. • Disseminate the technical facility requirements obtained from Versaterm to members preparing training facilities for the Project.
69 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 25
• Establish and disseminate minimum facility and equipment requirements for members preparing training facilities for the Project.
• Ensure that the required training facilities are available and properly configured in accordance with the Project Implementation Schedule.
PREREQUISITES
• Agreement Execution.
VERSATERM DELIVERABLES
• Training facility and equipment requirements.
TASK COMPLETION CRITERIA
• Training facility and equipment requirements are available and disseminated to the members responsible for preparing the Project’s training facilities.
• The required number of training facilities is available and properly configured in accordance with the Project Implementation Schedule.
TASK #14.5 TRAIN-THE-TRAINER TRAINING (TIMELINE MILESTONE #7) Versaterm will provide hands-on training to the Customer’s Project Team members.
VERSATERM RESPONSIBILITIES
• Provide the Customer with a re-settable training database that includes all the Customer’s configurations to date. • Coordinate and schedule the Train-the-Trainer Training with the Customer's Project Managers. • Provide Train-the-Trainer training facility requirements for the Customer's Project Managers. • Provide required skills and any pre-requisite training required by Train-the-Trainer participants. • Produce a reproducible set of Train-the-Trainer Training Documentation that includes the Customer’s requirements, in soft copy.
• Conduct the Train-the-Trainers Training Session, including instructions on re-setting and administering the training database.
CUSTOMER RESPONSIBILITIES
• Assist in adapting the training scenarios to make use of familiar data and to include site-specific policy and/or process flow information.
• Coordinate the location and scheduling of the Train-the-Trainer Training with the Versaterm Project Manager. • Provide a Train-the-Trainer training facility that meets Versaterm's requirements. • Reproduce and provide the required Documentation to Train-the-Trainer Training participants. • Ensure that the designated participants attend the scheduled Train-the-Trainer Training.
PREREQUISITES
• Training facility prepared.
• Testing successfully completed.
VERSATERM DELIVERABLES
• Train-the-trainer training facility requirements.
• Train-the-trainer participants pre-requisite training and required skill set. • Train-the-trainer training documentation for each participant. • Train-the-trainer training
TASK COMPLETION CRITERIA
70 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 26
• Delivery of Train-the-Trainer training, per the Training Plan. • Participants have been adequately trained on the agreed-upon Train-the-Trainer training topics, are able to complete the training assignments/scenarios.
TASK #14.6 READY FOR USE DECLARED (TIMELINE MILESTONE #8) This task signifies that Versaterm has delivered all required software, interfaces, data conversion programs and Train-the-Trainer training and remedied all Critical Priority Error and High Priority Error that are critical for the Customer to start training.
VERSATERM RESPONSIBILITIES
• Issue written notice to the Customer that the System is Ready for Training. • Correct any defects mutually identified by the Customer and Versaterm as having to be corrected prior to the System being ready for the end-user training.
CUSTOMER RESPONSIBILITIES
• Within ten (10) Business Days after receiving Versaterm’s “Ready for Training” notification, review the System's status and outstanding issues list and mutually identify with Versaterm any defects that must be corrected prior to its being used for end-user training.
• Issue a written notice to Versaterm that the System has been verified to be ready for end-user training.
PREREQUISITES
• Set Up and Test Disaster Recovery Environment
• Interface Testing
• Functional Acceptance Testing
• System Performance Testing
• Train-the-Trainer Training
VERSATERM DELIVERABLES
• Written notice to the Customer that the System is Ready for Training, once all defects mutually identified by the Customer and Versaterm have been corrected.
• Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
• Receipt by the Customer of Versaterm's written notice that the System is Ready for Training. • Issuance of a written notice to Versaterm from the Customer that the System has been verified to be Ready for Training.
TASK #14.8 AGENCY END-USER TRAINING
Versaterm-trained Customer trainers will provide just-in-time training to end-users. Versaterm will provide at least one (1) training support resource onsite at Customer facilities for the first five (5) calendar days of the end-user training classes. Given that the training classes may be held at geographically dispersed locations and during various times of the day, the Customer and Versaterm will collaborate to optimize the in-class monitoring of Versaterm’s resource. Versaterm will continue to provide remote support during the Customer’s regular business hours for the remainder of the end-user training period.
VERSATERM RESPONSIBILITIES
• Provide at least one (1) training support resource (on-site) for the first five (5) calendar days of the training classes (total of 10 days on onsite support – i.e. 5 days of one resource onsite for Police End User). • While on-site, assist and observe the Customer-provided trainers and make recommendations on improving the training (if necessary).
71 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 27
• Provide remote support as needed during the end-user training period.
CUSTOMER RESPONSIBILITIES
• Provide adequate training facilities including screen projection resources and enough workstation positions for up to twenty (20) students.
• Coordinate with Versaterm on the use and location of Versaterm's onsite training resources during the first five (5) calendar days of end-user training for the Police Department.
• Train additional trainers as necessary to staff the end-user training. • Schedule and organize the end-user training schedule. • Assign end-users to training classes at each facility. • Assign trainers to training facilities so that at least one qualified trainer is present at each end-user training class. • Prepare the required training documentation and material for each end-user attending a training session. • Ensure that the designated trainers and end-users attend their scheduled end-user training classes.
PREREQUISITES
• Training facility
• Train-the-trainer training
• Ready for Use
VERSATERM DELIVERABLES
• 1 training resource onsite for 5 calendar days each
• Feedback to Customer training resources
TASK COMPLETION CRITERIA
• Completion of end-user training classes (prior to Production Use).
TASK 14.10 FINAL SYSTEM ADMIN TRAINING
Versaterm will provide remote training on administering the System to the Customer’s designated technical administrators. The purpose of this training is to equip the administrators with the ability to monitor CAD and mobile system performance and to perform initial troubleshooting measures when needed. The training will include:
• Architecture overview
• Introduction to the VMC (Versaterm Message Controller)
VERSATERM RESPONSIBILITIES
• Coordinate and schedule the system administration training course with the Customer project manager. • Provide participant skills and previous training requirements. • Provide training documentation electronic format prior to the scheduled training session. • Conduct the system administration training session (including the topics shown above). • Provide training on how to troubleshoot Versaterm application problems.
CUSTOMER RESPONSIBILITIES
• Coordinate the location and scheduling of the system administration training course with the Versaterm project manager. • Identify and schedule the system administration training session participants. • Provide the required documentation and training materials to system administration training session participants. • Ensure that the designated participants attend the scheduled system administration training sessions. 72 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 28
PREREQUISITES
• Production Environment Setup
VERSATERM DELIVERABLES
• Administration training participant pre-requisite training and required skill set. • Administration training documentation and material for each participant.
TASK COMPLETION CRITERIA
• Completed system administration training session.
• Participants have been adequately trained on the agreed upon administration training. • The Customer’s system administrators can perform the administrative functions defined in this task.
5.10 PRODUCTION CUTOVER AND CLOSE SUPPORT - TASK 15
TASK #15.1 PREPARE DESKTOPS AND MOBILE COMPUTERS
The Customer and Versaterm will coordinate the update to all Customer Dispatch Desk Computers that will access CAD. In preparation, all Patrol vehicles and mobile dispatch computers with need MDT installed by the Customer.
VERSATERM RESPONSIBILITIES
• Provide the Customer with the latest specifications and MDT Build.
CUSTOMER RESPONSIBILITIES
• Ensure that all Department computers have been prepared.
PREREQUISITES
• Final MDT Build available.
TASK COMPLETION CRITERIA
• Customer has completed all Computer preparation.
TASK #15.3 PRODUCTION CUTOVER – GO LIVE
• Versaterm will assist and support the Customer in placing the System into Production Use.
VERSATERM RESPONSIBILITIES
• Collaborate with the Customer to determine the date and time of the System cutover for Production Use. • Provide sufficient onsite resources at least one (1) full Calendar Day prior to System cutover to assist the Customer's Project Team in preparing.
• Assist the Customer in placing the system into a Production Use status. • Monitor the initial operation of the System and answer any operational questions raised by the Customer. • Provide sufficient onsite resources to support the first three (3) full calendar days of Production Use.
CUSTOMER RESPONSIBILITIES
• Collaborate with Versaterm to determine the System Cutover date and time. • Provide trained personnel to be the first line of Support. 73 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 29
• Set up and staff a “Go-Live Support Room” to act as a central coordination point for Go-Live issues and support. • Coordinate with Versaterm to schedule the onsite Versaterm resources as needed to support the first three (3) calendar days of Production Use.
PREREQUISITES
• End-User training
VERSATERM DELIVERABLES
• Onsite Versaterm resources in support of the System cutover to Production Use. • Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
• The System is successfully operating in Production Use.
5.11 RESPONSE TIME AND RELIABILITY ACCEPTANCE TESTING – TASK 16 After cutover to live operations, the System will undergo a thirty (30)-day test period. The Customer will use the System for its intended purposes and monitor system reliability, functionality, and performance. Errors will be tracked and remedied per the Acceptance Test Plan (Exhibit B.4).
VERSATERM RESPONSIBILITIES
• Remedy reported issues per the Acceptance Test Plan (Exhibit B.4). • Support the Customer as required during the Reliability Acceptance Test.
CUSTOMER RESPONSIBILITIES
• Operate the System in Production Use.
• Monitor system functionality, performance, and reliability. • Notify Versaterm immediately of any encountered issues that impact the Reliability Acceptance Testing. • Notify Versaterm in writing of the successful conclusion of the Reliability Acceptance Testing.
PREREQUISITES
• System cutover to Production Use
VERSATERM DELIVERABLES
• Correction to any encountered System issues or defects as specified in the Acceptance Test Plan. • System support as specified in Exhibit B – CAD SaaS Service Schedule for Cloud.
TASK COMPLETION CRITERIA
• The System has operated for thirty (30) Consecutive Days without a Critical Priority Error or High Priority Error and a mutually agreeable plan to remedy all other minor errors has been developed and agreed to.
5.12 FINAL SYSTEM ACCEPTANCE – TASK 17 (TIMELINE MILESTONE #9) Final System Acceptance will occur after the completion of the 30-day Reliability Acceptance Testing period without an occurrence of a Critical Priority Error or High Priority Error, and when all other minor errors have been resolved or a mutually agreeable plan to remedy these errors has been developed.
If a Critical Priority Error or High Priority Error occurs during the 30-day Reliability Acceptance Testing period, the 30-day Reliability Acceptance Testing period will begin again at such time there are no Critical Priority Errors or High Priority Errors.
Final System Acceptance will also trigger the Payment Milestone for all Implemented CAD Interfaces. 74 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 30
VERSATERM RESPONSIBILITIES
• N/A
CUSTOMER RESPONSIBILITIES
• Notify Versaterm in writing of Final System Acceptance when all outstanding System issues or defects that preclude Final System Acceptance have been corrected.
PREREQUISITES
• Successful completion of the Reliability Acceptance Testing.
VERSATERM DELIVERABLES
• Provide milestone invoice as per • See Exhibit B – CAD SaaS Service Schedule for Cloud
TASK COMPLETION CRITERIA
• Reliability acceptance tests have been completed successfully. • Customer has provided a written notice of Final System Acceptance to Versaterm. 6 COMMUNICATION PLAN
The purpose of this communication plan is to provide meaningful, timely, and responsive communications that meets the needs of our staff and stakeholders, and ultimately supports a successful project completion, adoption, and utilization of the Versaterm CAD, MDT and VMOBILE. Consequently, the project team and supporting readiness team members will regularly review and update the Plan throughout the project to ensure communication strategies and actions directly support and address key needs of the project, Customer staff, and citizens.
Communications
Product
Audience Key Interests/ Messages Frequency Delivery Method Moderation Level*
Steering Committee
Report
Steering Committee • Strategic alignment
• Project milestones and risks
• Budget and resource updates
• Escalated issues requiring decision
• Approved or pending Change
Orders
• Upcoming critical activities or
decisions
Monthly or
when needed
In person with
PowerPoint
Customer Project
Manager
Weekly Status
Reports
• Customer PM
• Versaterm PM
• TPD & TFD Command
Staff (Optional)
• Status Review
• Current/Recent Activities
• Upcoming Activities
• Communications
• Current Resource Use
• Timeline for Next Few Months
Weekly • Email Versaterm Project
Manager
Meeting Agendas &
Minutes
Meeting participants • Agenda
• Participants
• Minutes
• Action Items
• Decisions
• Identified Risks
As appropriate • Email Versaterm Project
Manager
Command Staff
Briefing
TPD & TFD Command
Staff
• Status Review
• Current/Recent Activities
• Upcoming Activities
• Current Resource Use
• Timeline for Next Few Months
Monthly • In person with
PowerPoint,
SharePoint
and/or
handouts as
appropriate
Customer Project
Manager
75 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.1 – Statement of Work
Page | 31
7 RISK MANAGEMENT PLAN
• Both the Versaterm and Customer Project Managers shall add to the Risk Register (SharePoint list) any reasonable risks that come to their attention – whether the risk is self-identified or suggested by someone else. • Both the Versaterm and Customer Project Managers shall routinely (weekly) monitor and update the Risk Register including mitigation plans.
• When a risk is deemed likely or imminent, either the Versaterm or Customer Project Manager shall initiate the appropriate risk mitigation plan(s) as necessary and notify the appropriate team members. 76 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.2 – Project Implementation Schedule
Page | 1
EXHIBIT B.2
PROJECT IMPLEMENTATION SCHEDULE
77 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.2 – Project Implementation Schedule
Page | 2
78 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.2 – Project Implementation Schedule
Page | 3
79 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.2 – Project Implementation Schedule
Page | 4
80 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 1
EXHIBIT B.3
INTERFACE CONTROL DOCUMENT
81 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 2
CONTENTS
2. JDIC / CLETS / NCIC 3
3. MOTOROLA VESTA E911 13
4. GIS INTERFACE 18
5. POLICE CALL FOR SERVICE TRANSFER 36
6. FIRE RMS CALL FOR SERVICE TRANSFER 39
7. MOTOROLA MCC7500 RADIO SYSTEM (PTT/ERTT) 43
8. EVENTIDE NEXLOG (AUDIO LOGGER) 46
9. AXON EVIDENCE.COM (BODY WORN/IN-CAR CAMERA) INTERFACE 50
10. FIRE STATION ALERTING (LOCUTION) 54
11. PRIORITY DISPATCH PROQA INTERFACE 59
12. TABLET COMMAND 63
13. FUSUS (VMONITOR API INTERFACE) 82
14. ALARM PROGRAM SYSTEMS INTERFACE 84
15. ACCELA INTERFACE 99
16. PULSEPOINT 107
82 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 3
JDIC / CLETS / NCIC
INTERFACE SCOPE
The JDIC interface will provide a query/maintenance transaction interface from the Versaterm CAD, Versaterm Mobile Data Terminal (MDT) and from vMobile. These transactions are delivered to JDIC (the LA County Justice Data Interface Controller) and then onto the state (CLETS, DMV) and national databases (NCIC, NLETS) where they are processed appropriately. The Versaterm NCIC Gateway is used to manage and administer the interface.
The CAD user interface consists of a set of CLETS and NCIC forms that can be used to process query and maintenance transactions. Additionally, a number of transactions (query and maintenance) may be automatically triggered by transactions by special CAD command line requests.
Query transactions from the MDT and vMobile are spawned using the appropriate query form (Query Person, Query Vehicle, etc.). Once a query had been processed, the response is returned to the MDT/vMobile in the form of a message response and appear in the appropriate response “window” of the application.
CAD PROCESS OVERVIEW
From within CAD, the “NCIC” command is used to invoke this facility. Prior to allowing access to this subsystem, a security check is performed against the criteria described in Security and Restricting Access.
Once invoked, the user is presented with a transaction list so they may select the appropriate transaction by either entering the transaction code (e.g. EA, etc.) or by selecting from a list of valid transactions (known as the NCIC transaction code list). Upon entering the transaction code, the appropriate form is displayed. Mandatory fields are indicated by the convention used throughout the Versaterm applications.
The following illustrates a wanted person query form:
Fields with corresponding lookup tables are indicated by the “dropdown” button (Windows convention).
Upon completion of the form and pressing the “OK/Send” button or “Enter” key, form-level edits are 83 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 4
performed (e.g. cross-field edits, mandatory field check, etc.); if an error is encountered, the cursor is placed in the appropriate field and a descriptive error message displayed. Once the transaction has been sent, the user is returned to the transaction selection screen. At this point, the user may continue with other transactions or close the NCIC subsystem and return to the Versaterm CAD.
Responses/Replies from the external system are returned to the users Versaterm CAD vMail mailbox.
CAD AUTO INITIATED CLETS/NCIC TRANSACTIONS
The following auto-initiated transactions are included with the delivery of the Versaterm CAD:
CAD Function Generated CLETS/NCIC transaction
Person name identified in remarks QPER (Person Multi-Query) Vehicle plate identified in remarks QVEH (Vehicle Multi-Query) Command Line Person Name QPER (Person Multi-Query)
Command Line Driver’s License QDL
Command Line Vehicle Plate QVEH (Vehicle Multi-Query)
Command Line Vehicle VIN QV by VIN
Note that the QPER transaction includes queries to CLETS/NCIC Wanted Person, Missing Person, NLETS and LA County Warrant files. The QVEH transaction includes queries to CLETS/NCIC Stolen Vehicle, DMV, NLETS and LA County Vehicle files.
CAD JDIC SPECIFIC TRANSACTIONS
The following JDIC-specific transactions are included with the delivery of the Versaterm CAD:
JDIC Transaction Generated JDIC transaction
BKREL BOOKING UPDATE RELEASE
BKREQ BOOKING NUMBER REQUEST
BOOK BOOK JUSTICE DATA SYSTEM BOOKING INQUIRY (multi-transaction screen)
CWS JDIC COUNTY WARRANT INQUIRY
EI JDIC EVENT INDEX INQUIRY
EIREQ URN NUMBER REQUEST
JAI JUVENILE INQUIRY (multi-transaction screen)
JAIENT JUVENILE ENTRY
LETO JDIC ADMINISTRATIVE MESSAGES
84 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 5
WANT JDIC COUNTY WANT (multi-transaction screen)
WANT3N WIS REQUEST, WIS RELEASE, WARRANT BOOKING/ABSTRACT, RECALL WANT (multi-transaction screen)
Note that these JDIC-specific transaction are only available from CAD.
MDT PROCESS OVERVIEW
The MDT query interface uses pre-defined forms supporting a number of queries. As a by-product of entering a query (e.g. person), the user may tick check boxes to indicate which systems should be queried (e.g. NCIC, State, etc.):
Query Generated transaction
Person query Person Multi-Query
Vehicle query Vehicle Multi-Query
Property item query QA, QG (Query Gun), QB (Query Boat) Once a query had been processed, the response is returned to the MDT in the form of a message transaction and will appear in the MDT message window.
The following is an example of an MDT Person Query form:
Hit Notification: For each query response returned for a query transaction initiated from a MDT, the response will be examined by the system to look for keywords or strings (as defined by the Customer). If a keyword (e.g. Wanted, Stolen, etc.) is found, a hit sound and alert is shown to the unit that ran the query. The keywords list is maintained within the NCIC Admin module available to CAD administrators.
If this keyword list is empty the functionality is automatically disabled. 85 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 6
COMMUNICATION
Network communication to the JDIC interface is via a direct connect over TCP/IP using socket level communications. This direct connection, referred to as the “JDIC line” will be supplied and configured by the Customer and will encompass a dedicated network IP address and network port number. The data exchange methodology will conform the California DOJ standards. The NCIC Gateway provides the state-specific transaction formatting and communication requirements to the individual state interface. The NCIC Gateway also provides central management for NCIC configurations and user access. The following diagram illustrates the system connectivity points for the Versaterm applications (CAD and MDT) to the NCIC Gateway:
SECURITY AND RESTRICTING ACCESS
Security is controlled with a unique security matrix for NCIC – system users must be registered in the Versaterm NCIC security matrix prior to being able to run State/NCIC transactions. Optionally, an expiry date can be maintained where the user is denied access if the current date is greater than the expiry date. For each transaction, the administrator may provide or deny the transaction privileges. Setting security is a supervisor/administrator privilege, accessed through the NCIC Supervisor module.
Versaterm will complete the initial load of these values if the Customer provides in a usable format (e.g. csv or similarly delimited file).
The following screen shot is an example of the NCIC security profile and matrix for a specific user or group:
86 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 7
RESPONSE DESCRIPTION
Each response is returned as a transaction message and placed in the user’s Versaterm mailbox (vMail) or MDT message window. Lines are no more than 80 characters in width. If a query generates multiple responses, each response is delivered as an individual message.
AUDITING AND LOGGING
The NCIC gateway switch provides a facility to log/audit all transactions and corresponding responses to an online database table (searchable via the NCIC Administrator interface). The audit file can grow very quickly so it is recommended that the log is archived & purged frequently or simply just purged (if retention of the audit is not an issue). Versaterm will provide a program which, through a scheduled system facility, will purge and/or archive the logs to readable ASCII files where the site may back them up periodically.
The files are generated on a daily basis, i.e. one file for each day’s transactions.
VERSATERM NCIC SITE CONFIGURABLE TRANSACTION (SCT) FACILITY OVERVIEW The Versaterm interface to national, state and county/regional databases is the Versaterm NCIC subsystem. The Versaterm NCIC subsystem must be configured to recognize every transaction that site requires, where the NCIC subsystem has been identified as the medium by which the transaction is to be passed to an external system. To facilitate as flexible a means as possible for such configuration, an integral part of the Versaterm NCIC subsystem is its Site Configurable Transaction (SCT) Facility that is more informally referred to as the form-painter. While the SCT provides for the definition of forms that are associated with each transaction, it also provides for the definition of field and/or transaction level rules and, of equal importance, for definition of destination-format strings which govern how transactions will be assembled from the individual field details provided by a user.
It is due to the Versaterm NCIC subsystem’s leveraging of these SCT rules and destination-format strings that every transaction to be handled by the subsystem needs to be defined using the SCT. The benefit of this approach is that any NCIC-like transaction can be supported within the NCIC subsystem (e.g.
NLETS message) – it does not have to be configured in an integrated fashion within the Versaterm 87 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 8
application. Further, the Customer is capable to adjust the transactions as the external system requirements change.
The remainder of this section provides high-level insight into how the SCT is used to define transactions that can be made available for use with the Versaterm NCIC subsystem.
SCT FACILITY TRANSACTION DEFINITION
Transactions are maintained using Versaterm’s Site Configurable Transaction (SCT) facility. When first invoked, a list of already defined transactions is presented. From this list, existing transactions can be modified/deleted (i.e. the highlighted entry in the list representing the transaction currently in focus) or new transactions can be created (i.e. the “Add” button).
When defining new transactions, or modifying existing ones, in addition to defining a transaction code, version, type, etc., the ability to define individual fields that comprise the transaction is also required. To facilitate this, a “Modify Form” button under “Open” will open a window, similar to that illustrated below, which will permit transaction fields and labels to be defined:
88 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 9
When a field is defined (as shown above), characteristics such as length, default value, field-level rules, permitted values, picture clauses, lookup-table, etc. can be specified. A field tag-value unique to the transaction must also be specified. This tag-value becomes the name by which the field will be referenced when form level rules and/or destination-formats for the transaction are defined. In addition to fields, the screen painting form also allows for the (optional) definition of labels to make the form readable to the user.
FORM-LEVEL RULES
With the transaction defined, form-level rules and/or destination-formats can be defined. Form-level rules are rules that are applied after the entire form has been specified as opposed to after when an individual field has been entered. Form-level rules can be defined by clicking the “Rules” tab when a transaction is opened and are useful for performing multi-field edits, specifying which destination-formats are to be used and constructing fields that can be used and when populating a destination-format. A sample form- level rules definition might be:
89 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 10
In this case, it is assumed a form has been defined that among others has fields with tag-values of MNU_TYPE and MNU_NUM (i.e. individual fields that when combined would form the NCIC miscellaneous-number - MNU field). If both the MNU_TYPE and MNU_NUM fields above were assigned values when the transaction was being entered then the above rule stipulates that a new variable, MNU, will be assigned the value of the MNU_TYPE field entered on the transaction form, followed by a hyphen (“-”), followed by the value of the MNU_NUM field entered on the transaction form. The resulting MNU variable can then be used later on within the rules section or even used in a destination-format definition.
To specify destination-formats, the “Destinations” tab is clicked on the NCIC transaction window. This causes a window similar to the following to be displayed:
90 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 11
The destination list capability provides flexibility in dealing where a single transaction may be sent to multiple systems.
The destination-format generally conforms to rules that tend to be specific to the state and county level messages-switches that the transaction must navigate. State provided documentation is usually required to define these formats.
When specifying a destination-format, it is usually comprised from a combination of hard-coded literals (e.g. see ACQV, NAM, DOB, etc., outside of brackets/braces above) and/or variables. These variables come from SCT defined constants, from form fields as identified by their tag-value (e.g. see NAM, RAC, DOB, etc., embedded within braces above) and/or from variable names assigned values within the form- level rules section (no example provide above). There is nothing that prevents a hard-coded literal from being the same as a variable name. The destination-format parser distinguishes the appropriate context based on whether or not the value is embedded inside brackets/braces; values inside brackets/braces are variables and values outside brackets/braces are hard-coded literals.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the production environment across data centers provided there is connectivity from the CAD server to JDIC.
INTERFACE TESTING
These tests are intended to ensure the CLETS/NCIC interface is accurate and complete in submitting transactions and delivering responses. The following are descriptions of the tests to be performed for the specific interface during the Functional Acceptance Test period. 91 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 12
FUNCTIONAL AND COMPLETENESS TEST
For each query/maintenance transaction, the site will verify the corresponding transaction is generated.
Invalid combinations are entered to verify edits.
OPERATIONAL TESTS
For each query/maintenance transaction, the site will verify the transaction response. Each response should be compared to the transaction responses returned from the State interface contained in the legacy system.
PERFORMANCE TESTS
The performance tests include a load test where site will run a number of queries from various workstations to ensure the interface can handle the expected workload while routing responses back to the proper originators. External system response time may vary and is outside of the control of Versaterm.
EXCEPTION TESTING
The exception testing consists of “unplugging” the interface to ensure the line failure is detected and that any queries are retained in the outbound queue and subsequently submitted once the failure has been corrected.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
• Assist Versaterm in configuring the JDIC connectivity and configuration parameters. • Configure (and test) required networking components, including firewalls, to enable communication between the Versaterm server environment(s) and JDIC
• Provide remote access to the server environment permitting Versaterm to configure and test remotely, as required.
• With remote assistance from Versaterm, complete any state-required Certification testing • Perform interface testing
VERSATERM RESPONSIBILITIES
• Install and configure the NCIC Gateway software in the implementation server environment (initially) and then within the production server environment.
• With assistance from the Customer, configure socket communication to JDIC. • Install and configure the initial Versaterm NCIC/State/County transaction set (transactions). • Perform initial functional/integration testing of the NCIC interface. • Complete any state-required staff certifications for software providers. 92 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 13
MOTOROLA VESTA E911
The 911 interface provides ANI/ALI information from the Motorola/Vesta 911 System to the Versaterm CAD (vCAD). This interface minimizes the number of keystrokes required to create and populate call-for-service data, provides accurate call-back info, and expedites the call-taker’s call entry when entering 911 calls for service.
PROCESS FLOW
Upon answering a 911 telephone call on the Motorola Vesta System, the call-taker selects the “add by 911” hot- key (e.g. function key) or button on the vCAD window to display the position-related ANI/ALI information within their vCAD window/folder. The vCAD system will display the most recent ANI/ALI information received and present the call-taker with several possible options to create a call, dismiss the call, etc. An illustration of the data and choices are depicted below:
In selecting either the Police or Fire/EMS option, vCAD supports a site configuration option where all data is prefilled into the call mask/form immediately or presents a dialog to the user so they may selectively pre-fill information (e.g. name, address, telephone number) into the call form. If the System is configured to pop-up the selection dialog, the following illustrates the choices available:
Once the data is transferred into the call mask, the address is geo-verified after the user <tabs> through the address field.
93 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 14
The following diagram illustrates data flow from Motorola Vesta system to vCAD:
CELLULAR PROCESSING IN VCAD
Wireless Phase II Call Processing
When a Phase II cellular 911 call is received, vCAD converts the latitude/longitude (lat/long) using the x-y projection provided by the Customer GIS (corresponding to the Master Street Index and maps loaded in vCAD).
By doing this, the interface then attempts to identify the closest known address/intersection. If an exact match is not found, vCAD will display a list of alternate locations for the call-taker to select from. The call-taker also has the option to override the recommended selection and type in a descriptive ‘dispatchable’ location.
Rebidding
Re-bids are received as new ANI/ALI feeds in vCAD. The call taker may choose to create a new call from a rebid ANI/ALI feed. The new call is not automatically linked to the original call however the user has the option to manually link the call to the original call if desired. That being said, the new incoming 911 rebid ANI/ALI record can be automatically linked to the call for service that was generated from the original ANI/ALI feed should the 911 call taking equipment provider (Motorola Vesta) provide rules as to how to match the rebid ANI/ALI information to an original ANI/ALI feed.
Similar is also true for a WPH2 call, where multiple incoming ANI/ALI feeds can be received for a WPH2 call. vCAD has the capability to match the subsequent incoming feeds to the original call if rules can be provided by the call taking equipment provider (Motorola Vesta).
If a 911 ANI/ALI feed (e.g. rebid) is not actioned by the call taker, the ANI/ALI feed is automatically dismissed after a configurable number of seconds (no longer presented to the call-taker). The vCAD administrator may configure the number of seconds within the vCAD System parameters (under the Supervisor module). However, prior to the duplicate ANI/ALI record(s) automatically being dismissed, they will continue to be available and displayed within the call-taker’s vCAD window/folder should they select the “add by 911” hot-key or button.
Note, however, although an ANI/ALI feed may be dismissed, all ANI/ALI feeds are recorded in the vCAD database and available from the Query 911 feature.
SPECIAL PROCESSING
94 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 15
Versaterm is not responsible for the quality of data received from the 911 provider. The data is expected in a fixed field format following rigid conventions. If data is not received in a consistent manner and cannot be parsed programmatically, the call-taker must correct the information. For example, a name is typically received in the following format:
surname, first middle (SMITH, JOHN M)
However, if the 911 directory listing contains deviations from the above (e.g. “SMITH, JOHN & SHIRLEY”), the E-911 Interface would assume “JOHN” as the first name and “&” as the second name. It will be the call-taker’s responsibility to correct the field(s), once pre-filled on the call form.
DATA FORMAT REQUIREMENTS
The final format will be provided to Versaterm prior to interface development and Versaterm assumes the data spill is standard as with other installations.
Note – as part of the ANI/ALI feed, the Motorola Vesta system must include the position of the call-taker handling (answering) the 911 call. Each vCAD call-taking/dispatch Desk will be assigned a unique position ID which is used to present the corresponding ANI/ALI call information to the correct vCAD Desk.
CONFIGURATION
Configuration
Screen or
File
Configuration Setting Possible
Values
Recommended
Setting
E911_Cfg Internal Procedure Call Key
Database Name
TBD
DA_Cfg Database Agent Log File
Logging Mode
TBD
Session_Cfg Automatic Start
Transaction Acknowledgement
Parameter File Name
Log File Name
Timers
vCAD
Parameters |
General
Settings
Notify E911 Abandoned calls by
handle
Yes/No TBD
E911 handle name TBD
E911 Installed Yes/No Yes
Select E911 information to pre-fill
call
Yes/No TBD
Default E911 query 90 days
95 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 16
Seconds before dismiss 180 seconds
Allow placing E911 calls on hold TBD
COMMUNICATION
Communication is provided via two RJ-45 serial communication links from the Motorola Vesta system. Each serial link is connected to a Perle terminal server which converts the serial communications to UDP to communicate with the vCAD server. The Perle Trueport software on the vCAD server will present these internally on the CAD server as serial (com) ports.
In the Customer’s implementation of the Motorola Vesta 911 System, the vCAD system will receive two simultaneous and identical ANI/ALI feeds for each 911 telephone call (one down each link or serial port). Two 911 session handlers will be configured on vCAD. Each session handler will connect to an incoming com port (ANI/ALI feed). Only one session handler will be running at a given time. The local system administrator will be able to shutdown/bring up a session handler as required (e.g. if there is an issue on a line).
Note that all incoming ANI/ALI records processed by vCAD, including duplicate WP2 records and rebids, are captured and logged in vCAD and available from the Query 911 feature.
AUTHENTICATION
This section is not applicable to this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the production environment across data centers provided there is connectivity from the vCAD server to the Perle terminal server (which connects to the serial 911 interface on the Motorola Vesta server).
INTERFACE TESTING
These tests are intended to ensure the interface is functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that whenever the call-taker answers a 911 call, and presses the appropriate vCAD function key/button, the 911 ANI/ALI information is displayed. The test will also confirm the 911 data populates into the appropriate complaint fields and that Phase II wireless x-y coordinates are provided for the map display. The test will confirm that the original 911 data is stored with the call and in the 911 log for later retrieval.
OPERATIONAL TESTS
This test ensures the interface is available after connectivity is lost and re-established. The operator will disconnect Perle device from the call handling equipment and confirm that 911 data is received by vCAD once connectivity is re-established
PERFORMANCE TESTS
The performance test consists of answering a 911 call, pressing the 911 function key/button and having the corresponding ANI/ALI data displayed. The time from pressing the 911 function key until the ANI/ALI data is displayed is not to exceed one (1) second.
96 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 17
Time delays introduced by the Motorola Vesta system, or the network are not included in any time measurements.
EXCEPTION TESTING
The exception test consists of unplugging interface and, after plugging it back in, ensuring that it re-connects and functions.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interface functions as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
• Provide Motorola Vesta system interface specifications • Acquire and install the necessary hardware/equipment including the Perle terminal server to connect the Motorola Vesta server (serial interfaces) to the vCAD server. • Provide the serial cable required with the necessary pinout to connect to the Perle terminal server. • Configure the Perle terminal server as per the requirements provided by Versaterm. • The Customer will provide and install any necessary connectivity from the E 911 System to the vCAD server location(s).
• Provide specifications for the ANI/ALI data stream.
• Assist Versaterm as required as they perform the initial integration testing. • Review the results from Versaterm’s initial integration testing. • Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
• Provide necessary hardware specifications, including those for the terminal server. • Install and check out E911 interface, ensuring that 911 ALI information is stored correctly in the vCAD database. • Configure the vCAD E911 interface.
• Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
97 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 18
GIS INTERFACE
There are various GIS data requirements for the Versaterm CAD and MDT. This section provides an overview and describes the requirements for each of the following components:
• Versaterm GIS Interface (vGIS)
• Versaterm CAD and MDT Maps
• Automated Vehicle Routing and Recommendation (AVRR)
Versaterm understands that GIS requirements continue to evolve and will collaborate closely with the Customer to ensure that the System also evolves as required.
1. VERSATERM GIS INTERFACE (VGIS)
INTERFACE SCOPE
This interface leverages the Versaterm vGIS appliance to read from an ESRI map service or Customer supplied shapefiles to generate the GIS data files (streets, intersections, addresses and common place names) required by the Versaterm CAD.
Once completed, the local GIS data will reside in a set of street index validation tables within the CAD database. The Versaterm CAD will use the local GIS data to validate and geo-code the locations. vGIS creates the GIS data files required by the Versaterm CAD by extracting the required information from ESRI formatted map files (shape files) or reading directly from an ArcGIS map service provided by the Customer. ESRI shape files is the preferred method for performance while removing any connectivity to the ArcGIS map service.
PROCESS FLOW
ESRI formatted shape files will be provided by the Customer, or the Customer will provide the necessary map-service connectivity from the vCloud environment to the Customer ArcGIS server.
The vGIS appliance will permit the Customer to map attributes from the various layers to the CAD application street index data elements. The vGIS program then verifies the data with logical edits and subsequently produces the ASCII file representation of the geo-spatial data, which is then loaded into the Versaterm CAD, via the CAD Street Conversion facility.
The expected result of this process is a comprehensive street index in the CAD for address verification, geo-coding and other spatial-related function and analysis. This process would also be used whenever updates are required to the CAD street index files.
For interim updates that may be required, should the Customer GIS files be out-of-date, the vCAD Street Maintenance facility permits a user, with appropriate security permissions, to manually update the street index data directly. All changes are identified as “locally changed.” Prior to loading a vGIS produced dataset, the locally changed records are unloaded to an ASCII file(s). The administrator may view the file(s) on the server and edit them, as appropriate, or simply append them to the vGIS load files where, upon the subsequent load, the street load edits and rules are applied, and duplicates and/or overlaps will be rejected. An exception report is produced identifying any rejected records.
The following diagram illustrates data flow required to populate CAD geofile:
98 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 19
CONFIGURATION
Configuration instructions are provided in vGIS User Administrator Guide.pdf.
VGIS DATA SOURCE INFORMATION
The data source for vGIS consists of ESRI formatted GIS shape files to be supplied by the Customer. At a minimum, the vGIS requires a street centerline file and at least one patrol boundary layer (to be provided by Customer) and one fire response area boundary layer (to be provided by Customer). vGIS can extract the following information from the provided shape files:
• Street names
• Street ranges (including cross-streets)
• Intersections
• Address points (assuming these can be provided as a shape file) The following information can also optionally be converted:
• Common place names (landmarks)
• Street alias names
While most sites choose to manage their common place names and street alias names outside of the shape files, Versaterm can support importing common place names (landmarks) and street alias names from a text file (see file format requirements below).
DATA FORMAT REQUIREMENTS
vGIS only supports shape files, file geodatabase and map services that contain 2D feature types. Z values are not supported.
All shape files must have the same projection.
99 Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 20
The X and Y coordinates in the street index tables only support integer values. Any decimals will be truncated.
The shape file attributes are mapped to the Versaterm data fields using the vGIS appliance. When necessary, the shape file attributes are cast (converted) to the Versaterm data type during the extract (e.g. the “Char” data type accepts alphanumeric values).
VGIS will process the street centerline layer, the boundary layers (precinct, sector, Fire response zones, etc.), and an address layer. These layers are used to map fields from the ESRI formatted shape files to the fields required by the Versaterm system.
STREET CENTERLINE LAYER
The purpose of the street centerline layer is to extract the address block ranges from each street segment, and to generate intersections.
The fields below are captured from the street centerline layer. There are several fields, which are automatically generated including X-Y coordinates and cross street data.
Fields captured from the street centerline layer
Field Name Data Type Req? Remarks
1 Street Name Char(40) Y Versaterm requires a ‘full street name’ that includes direction, name, and type (e.g., N MAIN ST). If the street network shape file contains a full street name field, it can be used or, alternatively, fields can be mapped to the direction, name, and type fields and the full street name is generated. If the street name, street type, and street direction is provided individually, then the maximum size of the full street name cannot exceed 40 characters. 2 Street
Direction
Prefix
Char(2) N
3 Street
Direction
Suffix
Char(2) N
4 Street Type Char(4) N
5 Left
Municipality
(Customer)
Char(10) Y/N The CAD must be able to uniquely identify an address/street. In Versaterm, the Municipality (Customer) code is required to identify unique street names/addresses. Note a unique code for the Municipality/Customer must be provided (max char(6)), and not the Municipality/Customer Name (e.g. unique codes will need to be provided for neighboring/bordering municipalities/cities should the Customer incorporate GIS from other jurisdictions). If an address is duplicated (e.g., multiple 101 Main St.) within the street network layer, the NB GIS must set the Municipality/Customer code (uniquely) for the addresses, ranges and intersections. If at all possible, the Municipality/Customer code should be part of the underlying GIS information (i.e., a Municipality/Customer field in 100
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 21
the street network layer or a Municipality/Customer polygon layer) but it can be based on a constant value.
6 Right
Municipality
(Customer)
Char(10) Y/N Same as above
7 Left Address
Start
Numeric(6) Y
8 Left Address
End
Numeric(6) Y
9 Right Address
Start
Numeric(6) Y
10 Right Address
End
Numeric(6) Y
11 Leading Zero 3 Char(1) N The Leading Zero field must be populated with a value of “0” for street segments that contain street numbers with leading zeros.
Otherwise it should remain blank.
12 Ring Code Char(10) N The Ring or Gate code option allows the user to extract ring codes from the street network layer. These are usually gated community entry codes that are stored on the map.
13 Remarks Char(40) N The Remarks field can contain any additional information required by the agency. It may also contain 100 Block information. 14 Unique ID Char(20) N The Unique ID must be a unique number within the GIS data set. (The Unique ID provides a cross-reference to the originating source data set). If this does not exist then the feature ID is used. Note the Unique ID is max Char(20).
15 Zip/Postal
Code
Char(10) N
16 Census Tract Char(10) N
17 Local Field 1 Char(10) N
18 Local Field 2 Char(10) N
19 Street Alias
Name
Char(40) Y The Street Alias name can be extracted from the street network layer. However, most agencies manage this information using an external flat file or spreadsheet. See Interface (Text File) Load Requirements below.
STREET CENTERLINE LAYER REQUIREMENTS
• Line segments must be split at the intersection for an intersection to be created. • Intersections are not created if two lines overlay one another. 101
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 22
• Address block ranges will be created for the left and right side of each street segment. Each address range must contain either an even pair or an odd pair of numbers. Mixed ranges are not valid ranges. • The geometry type for this layer must be ‘polyline’.
• The street network layer must contain the entire street network that the agency services. This includes (but is not limited to) interstates and highways, major roads, municipal roads, and local roads. • If multiple shape files are currently used to represent the above layers, the NB GIS is expected to combine/merge them into a single shape file for the use with vGIS. Note, in order to combine layers, the NB GIS is required to use common attribute definitions.
• The street network layer should not contain overlapping street segments containing a different street name for each segment as this can cause vGIS to produce undesirable results. • The street network layer should not contain street segments that are less than 1 map unit (or 1 meter) in length, often referred to as ‘slivers’, as these can cause vGIS to produce undesirable results.
ADDRESS LAYER
The purpose of the address layer is to store the x/y coordinates for every address point, which allows the Versaterm CAD to tag every incident with the x/y coordinates for mapping and analysis purposes.
Fields captured from the address layer
Field Name Data Type Req? Remarks
1 House (civic)
Number
Char(11) Y The Civic Number cannot contain a leading zero. 2 Street Name Char(40) Y Like the street name for the street network layer, a full street name field can be generated from the
direction, name, type, and suffix fields.
3 Street Direction
Prefix
Char(2) N
4 Street Direction
Suffix
Char(2) N
5 Street Type Char(4) N
6 Civic Number Suffix Char(1) N The Civic Number Suffix is a single character at the end of the civic number (e.g., 200A). It can be
provided in its own column or as part of the Civic
Number.
7 Civic Number
Fraction
Char(3) N The Civic Number Fraction can be one of the
following: 1/4, 1/2, 3/4, or it can be provided in its
own column or as part of the Civic Number.
8 Leading Zero Char(1) N The Leading Zero will be populated with a value of “0” if the corresponding civic number should have a
prefix “0” value. Otherwise it will remain blank.
9 Unit Number Char(6) N
102
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 23
10 Unique ID Char(20) N The Unique ID must be a unique number within the GIS data set. The Unique ID provides a cross-
reference to the originating source data set. If a
Unique ID does not exist in the provided shape file
then the feature ID is used. Note the Unique ID is
max Char(20).
11 Ring Code Char(10) N Gate/Building code (if applicable) 12 Place Name Char(40) N The Place Names can be extracted from the address layer. When extracting place names from the address
layer, an address can only be linked to one place
name.
When loading place names from a text file, there can
be multiple place names at an address. See Interface
(Text File) Load Requirements below.
ADDRESS LAYER REQUIREMENTS
• The geometry type for this layer must be ‘point’.
• The Customer must ensure that common naming conventions are used between the street network and address shape files.
• All address points must have a street segment with matching low and high address values. • If the Customer includes data from outside the primary area of responsibility for the PD, it is recommended that the address point layer only be included for the Customer, and not for the neighboring areas. This will be further discussed and reviewed during the implementation configuration sessions.
• The following are examples of address records that would be rejected during vGIS extract:
• Address: ‘2300 CARLING AV’
• Range: ‘2200-2298 CARLING AV’ & ‘2302-2398 CARLING AV’ • This record will be rejected, as it does not fall within a valid range record. • Address: ‘100 MCINLEY BLVD’
• Street Name: ‘MC INLEY BLVD’
• This record would be rejected as it does not match with an existing street name record — note the space after ‘MC ’.
CUSTOM INTERSECTION LAYER
The custom intersection layer identifies those “intersections” from a public safety viewpoint but are not truly intersections from a GIS point of view (such as bridges and railroad tracks). That is, those intersecting points that the general public would naturally identify with. These types of intersections are also used for dispatching purposes or police incidents.
If this type of information is required, then an additional layer may be included to generate additional intersection records. Custom intersections can be provided in one of the following formats:
A- CUSTOM INTERSECTIONS USING LINE LAYERS IN THE STREET CENTERLINE LAYER 103
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 24
Multiple line layers can be used to create intersections with the street centerline layer by overlaying the custom intersection line layers with the Street Layer. The geometry type must be polyline.
An example of this is providing a river layer to overlay the street layer to generate intersections where the rivers cross the street network. The only value required in the custom intersection line layer is the name to be used with the intersecting street.
Custom Intersections using Street Centerline Layers
Field Name Data Type Req
?
Remarks
1 Intersecting Name Char(40) Y
B- CUSTOM INTERSECTIONS USING A SINGLE POINT LAYER
A single point layer can be used to create custom intersections with specific geo-spatial information. The shape file must contain both intersecting street names.
Custom Intersections using a Single Point Layer
Field Name Data Type Req? Remarks
1 Street Name Char(40) Y Versaterm requires a ‘full street name’ that includes direction, name, and type (e.g., N MAIN ST). If the street network shape file contains a full street name field it can be used or alternatively, fields can be mapped to the direction, name, and type fields and the full street name will be generated. If the street name, street type and street direction are provided individually then the maximum size of the full street name cannot exceed 40 characters.
2 Street
Direction
Prefix
Char(2) N
3 Street
Direction
Suffix
Char(2) N
4 Street Type Char(4) N
5 Street Name Char(40) Y
6 Street
Direction
Prefix
Char(2) N
7 Street
Direction
Suffix
Char(2) N
8 Street Type Char(4) N
104
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 25
9 Municipality
(Customer)
Char(10) Y/N The Municipality (Customer) code must be supplied if the Municipality (Customer) for the streets is being extracted from the Street Layer.
10 Remarks Char(40) N
11 County Char(2) N
12 Jurisdiction Char(2) Y/N
13 District
(Precinct)
Char(4) N
14 Zone/Beat
(Sector)
Char(6) Y/N
15 Grid/Atom
(District)
Char(6) Y
VGIS interface can be configured to read response (police patrol boundary) information, namely District/Zone/Grid from the custom intersection layer or to extract response
information from the provided boundary layers. If response information is provided as a part of the custom intersection layer, then the Zone (Sector) field is mandatory and the jurisdiction field is mandatory for multi jurisdiction sites. (Note that for non multi jurisdiction sites, the jurisdiction code must match what is used for the Boundary layer).
COMMON PLACE NAMES (LANDMARKS)
The Versaterm street conversion programs have the functionality to load the common place names (landmarks) into the database from a text file provided by the Customer.
After the initial load of the street centerline and boundary layers, the place names can be either maintained directly through the street maintenance utility or re-loaded into the database (from a text file) as part of subsequent street conversion loads.
Common place names cannot be loaded separately and independently from the street load as they are processed as part of the street load.
The format of the text file accepted by the conversion programs is as follows:
Common Place Name File Format Requirements
Field Name Data Type Req? Remarks
1 Jurisdiction Char(2) Y Jurisdiction (blank if not multi-jurisdictional) – Mandatory if site is multi-jurisdictional
2 House (civic)
Number
Char(11) Y The street address number
3 Full Street
Name
Char(40) Y Full street name (includes street type, name and direction) 4 Unit Number Char(5) N Unit or apartment #
5 Municipality
(Customer)
Char(10) Y Municipality (Customer) Code
6 Place Name Char(30) Y The place name (i.e. BURGER KING) 7 Primary Place
Flag
Char(1) Y Primary (Y) / Alias (A) / blank
In Versaterm, it is possible to have multiple place names linked to the same address. This field is used to specify 105
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 26
place names that are primary place names, alias place
names, and non-primary place names. For example, indicate “Y” if the place name is the primary place name
(CARLINGWOOD MALL – 123 MAIN ST). Provide an “A” if
the place name is an alias or short form (CM). Provide a blank or null if the place name is a non-primary place at the same address (SEARS – a store in CARLINGWOOD MALL).
If SEARS has its own civic address (e.g., 123 MAIN ST - UNIT 2), this should be the prime at 123 MAIN ST – UNIT 2. 8 Effective From
Date
Date N
9 Effective To
Date
Date N
Used to identify historical place names (MM-DD-YYYY)
These fields can be used to specify the period of time during which the place name or a place name alias will be effective. 10 Address
Prefix
Char(3) N Civic number prefix (currently only 0-zero is supported) EXAMPLE:
VI|2300|W MAIN ST|A1|1|TIM HORTONS|Y||||
COMMON PLACE NAME FILE REQUIREMENTS
• The address file is NOT required prior to this file.
• Versaterm does not support place names that begin with numeric data (for example, 24 HOUR FITNESS). In order to use this type of place names, the space between the number and the first word of the name must be removed. For example, “24 HOUR FITNESS” should be entered as “24HOUR FITNESS”. “7-11” can be entered as “711”, “7'11” or “7ELEVEN”. • Place names cannot begin with the word “BLOCK”.
• The following characters are not allowed in place names: ‘&’, ‘.’, ‘-’.
STREET ALIAS NAMES
The Versaterm street conversion programs have the functionality to load the alias street name file into the database.
After the initial load of the street centerline and boundary layers, the alias street names can be either maintained directly through the street maintenance utility or re-loaded into the database (from a text file) as part of subsequent street conversion loads.
The format of the text file accepted by the conversion programs is as follows:
Street Alias Name File Format Requirements
Field Name Data Type Req? Remarks
1 Full Street Name Char(40) Y Full street name (includes street type, name and direction)
106
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 27
2 Municipality
(Customer)
Char(10) Y Municipality (Customer) Code
3 Alias Full Street
Name
Char(40) Y Name as entered (i.e. N MCLEAN ST)
4 Alias Low Numeric N Low value for the range/block face 5 Alias High Numeric N High value for the range/block face EXAMPLE:
MAIN ST E|1|HWY 61|200|244|
VGIS OUTPUT
Once vGIS generate process is completed, up to four ASCII files are generated: street names, ranges, intersections and addresses. These files contain the geo-spatial information required by the system.
STREET NAMES
The street names file contains every unique street that appears on the street network shape file. A unique street is a combination of the full street name and the municipality (Customer). A full street name includes direction, name, and type (i.e., W FOSTER ST).
RANGES
The ranges file contains a record for each block (segment) in the street network shape file. Each record will contain data corresponding to the block – cross reference ID to the street name (in the ‘street names’ file) low- high address values, cross street IDs, district (precinct), zone (sector), grid (district), X-Y coordinates, etc.
INTERSECTIONS
The intersections file contains a record for each intersection in the streets layer. Each record will contain data corresponding to the intersection – cross reference ID to the street name (in the ‘street names’ file), district (precinct), zone (sector), grid (district), X-Y coordinates, etc.
An intersection record is created whenever two streets actually intersect (i.e., intersecting polylines). There are many cases where, from a public safety perspective, additional intersections may be required (e.g. bridges, railroad tracks, etc.). Although these “intersections” are not truly intersections from a GIS point of view, they are locations where an incident may occur, and the location may be required for a subsequent report. If this type of information is required, then additional layers, of the geometry type of polyline, may be included to identify the rivers and railroad track features for instance. If provided, the intersections will be generated by spatially joining with the street network layer.
ADDRESSES
107
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 28
The address file contains a record for each address point in the provided shape file. Each record will contain a cross-reference ID to the street name (in the ‘street names’ file), address number, district (precinct), zone (sector), grid (district), X-Y coordinates, etc.
As part of this process, a file geo-data base (GDB) is also created containing a feature class (layer) for the ranges, intersections and errors. These layers are added to the main ArcGIS Desktop window and provide a visual representation of the street data that is loaded into the Versaterm system. The errors layer will contain any street that has invalid or missing data.
ERROR CORRECTION PROCESS
In addition to the error layer, an error log file is generated which contains the record identifier of each street and an error description. The file may be viewed using Windows notepad or other text file editor. The record identifier may be used to view the source segment on either the feature class or street centerline layer.
The Customer will be able to correct errors prior to loading into the Versaterm system. It is recommended that detected errors are corrected on the base (Customer) GIS data files.
Sample errors may include:
• Street name missing or invalid
• Municipality missing or invalid
• Range low/high values wrong side (odd/even on same side of street) • Overlapping ranges – e.g. range of 2-28 when 24-30 already exists • Duplicate ranges – range 2-28 & 2-28
• Empty geometry – shape field is empty
• Empty geometry – length of polyline is 0
COMMUNICATION
Communication between vGIS and the desktop uses HTTPS as communication protocol.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be available on all environments (Production, Test/Dev and Training).
INTERFACE TESTING
vGIS functional testing ensures that the Customer ESRI formatted shape files can be successfully processed by vGIS, producing the necessary ASCII data files that can be subsequently loaded into the Versaterm database.
These tests are expected to be incremental where the Customer may load vGIS produced ASCII files into the Versaterm system for verification, prior to a full end-to-end test and quality assurance testing.
QUALITY ASSURANCE TESTING
108
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 29
Upon completion of the interface testing, Versaterm and the Customer shall use vGIS produced data files to run a complete GIS validation and load into the Versaterm system.
Once the GIS data is loaded into the database (street index), the Customer will conduct quality assurance tests on the data by performing numerous location data entry trials on the desktop Customer software.
FUNCTIONAL AND COMPLETENESS TEST
VGIS functional testing ensures that the ESRI formatted shape files provided by the Customer can be successfully processed by vGIS, producing the necessary ASCII data files that can be subsequently loaded into the Versaterm database.
These tests are expected to be incremental where the Customer may load vGIS produced ASCII files into the Versaterm system for verification, prior to a full end-to-end test and quality assurance testing
OPERATIONAL TESTS
These tests are not applicable for this interface.
PERFORMANCE TESTS
There are no performance tests associated with this interface.
EXCEPTION TESTS
These tests are not applicable for this interface.
DATA INTEGRITY TESTS
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide GIS information in a single projection in ESRI formatted shape files, geodatabases, or connectivity to the ArcGIS map service.
a. At minimum, this data must consist of a street centerline layer and polygon layer(s) that contains fire districts/zones and jurisdictional boundaries, and police district/zones and jurisdictional boundaries.
b. Work with GIS team to provide GIS information in a single projection in ESRI formatted shape files or connectivity to the ArcGIS map service.
c. If the shape files are to be posted to ESRI ArcGIS Online, provide a mechanism so the shape files can be downloaded from ESRI ArcGIS Online.
d. Provide the GIS shape files to Versaterm for verification and testing as required. e. Verify quality and completeness of the data.
f. Correct vGIS-identified data errors.
g. Perform quality assurance testing within the Versaterm CAD. h. Optional, but highly recommended: an address point layer i. Optional: Provide a list of street type abbreviations and configure the Versaterm CAD with those abbreviations.
j. Optional: Provide the common place name (landmark) file in the format specified within this Section. k. Optional: Provide the street alias file in the format specified within this section. l. Assist Versaterm as required as they perform the initial integration testing. 109
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 30
m. Review the results from Versaterm’s initial integration testing. n. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Provide vGIS software and related documentation including vGIS administrator’s guide (or similar). b. Provide the Customer with instructions and support on vGIS installation. c. Provide the Customer with the required VGI training and support. d. Perform initial street conversion load into the Versaterm CAD database. e. Perform initial integration testing as described in the Interface Testing section above and provide test results to the Customer.
f. Train local authorities on how to perform subsequent street conversion loads into the Versaterm CAD database.
g. Assist in resolving issues arising from the Customer’s quality assurance testing. h. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
2. VERSATERM CAD AND MDT MAPS
The Versaterm MapViewer is the visual mapping component of Versaterm CAD and MDT applications. The MapViewer leverages ESRI Runtime Engine and consumes the following data formats: ESRI map packages, ESRI map services, and ESRI feature services.
The supported map package formats are:
• Tile package (.tpk)
• Runtime geodatabase (.geodatabase)
• Vector tile package (.vtpk)
Versaterm CAD and MDT maps support the same type of map packages, however agencies might choose to create different sets of map packages to be used by Versaterm CAD and MDT applications based on data requirements. For example, public transit and hydro data might be useful on the communications center maps but might not be required on the MDT map.
In addition to the visual components, the MapViewer allows users to query data available for a specific location as well as perform geocoding functions.
The following sections describe the various types of GIS data formats supported by the MapViewer.
AERIAL IMAGERY
Aerial images must be provided as a tile map package or an ESRI map service.
BASE MAP
Base maps can be provided using the following formats:
• Tile package (.tpk)
• Runtime geodatabase (.geodatabase)
• Vector tile package (.vtpk)
110
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 31
ESRI MAP SERVICE
Versaterm CAD and MDT maps can combine multiple map packages and map services in order to display the base map. For example, separate map packages can be provided for streets, hydro, public transit, fire hydrants, etc. This feature provides the ability to select the information that is displayed for each group of users (for example, police dispatchers may see different layers compared to fire dispatchers). Users can toggle the display of various layers (map packages) on and off.
All map packages must use the same coordinate system. This is a technical requirement of the ArcGIS Runtime engine.
INFO MAP PACKAGES
Versaterm CAD and MDT maps provide the ability for users to request additional information for a particular location. The information that is displayed is configurable and can include information such as district/zone, station run order, links to floor plans, owner contact information, etc.
The runtime geodatabase (.geodatabase) map package is required in order to provide this query capability.
The map package should contain only features that the agency plans to use in their queries. Symbology configuration for each layer is not necessary because the features will not be displayed on the map.
GEOCODING MAP PACKAGES
The geocoding geodatabase provides users with the ability to search for specific addresses, intersections, block addresses, etc. The MapViewer geocoding makes use of the Runtime Geodatabase (.geodatabase) data type. The address validation geodatabase file should contain two feature classes:
• Street Layer (required) – contains the street name and address range records to use for address validation.
• Address Point Layer (optional) – contains civic address points to locate and address more accurately. • Common Place Names Layer (optional) – contains common place names (business names).
Street Layer
The street layer is a required data layer for map address validation. This data layer provides functionality such as:
• Suggests matching street names with what the user has entered. • Finds other streets that intersect with the entered street. • Provides the closest intersection to the current GPS position. • Provides closest address blocks to the current GPS position.
To ensure full support for all street features, the street feature class must comply with the following:
• There must be a single layer that contains all streets, highways, or anything that a site wants validated. This layer does not have to be displayed on the map. • This layer should not have items that you do not want validated, like ramps, alleys, etc. • This layer should have coordinates projected properly (i.e., it should be using the same spatial reference as the CAD/MDT map).
• The field values should all be in full uppercase.
The street feature class should contain the following attributes:
111
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 32
Field Data
Type
Mandatory/
Optional
Notes
Shape Feature
Geometr
y
(Polyline)
Mandatory
Full street
name
Text Mandatory Contains the full street name. This is the column that houses the final street name the MDT validates against. (e.g., E MAIN ST W). Note the following rules:
Must not have special characters such as dashes (-)
It is recommended to use abbreviated street types.
Should only have a single space separating each word.
Left starting
civic number
Left ending
civic number
Right starting
civic number
Right ending
civic number
Number
(Integer,
Double,
Float)
Mandatory These fields contain the civic number range records used to validate entered addresses
Left
municipality
code
Right
municipality
code
Text Mandatory Contains the municipality codes that sites use for address validation. Note the following rules:
The code values should match the CAD municipality
codes table (e.g., PORT for Portland).
Use the Left and Right municipality code fields to handle street segments that belong to two municipalities. (i.e., there should only be one record).
The municipal codes should be unique system wide.
Left county
Right county
Text Optional The county fields are optional to help distinguish matching addresses from multiple counties. They are not used in
the validation routine.
Address Point Layer
An address point layer is not a requirement, but it greatly increases the accuracy of locating an address point or finding an address closest to the current GPS location. This layer does not replace the Street Layer outlined above, rather it augments it.
An address point layer must meet the following requirements:
• This layer refers to single points only, and not lines or polygons. • This layer should not have items that you do not want validated, like ramps, alleys, etc. • This layer should have coordinates projected properly (i.e., it should be using the same spatial reference as the CAD/MDT map).
• The field values should all be in full uppercase.
112
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 33
The address point feature class should contain the following attributes:
Field Data Type Mandatory Notes
Shape Geometry
(Point) or
Feature
Geometry
(Point)
Mandatory
Civic
Number
Text or
Number
Mandatory Contains the civic address number. If the site contains leading zero addresses, this column should contain the leading zero.
Full street
name
Text Mandatory Contains the full street name. This is the column that contains the final street name the map validates against (e.g., E MAIN ST W). Note the following rules:
Must not have special characters such as dashes (-).
It is recommended to use abbreviated street types.
Should only have a single space separating each word.
Municipality
code
Text Mandatory Contains the municipality codes that the site uses for address validation. Note the following rules:
The code values should match the CAD municipality codes table (e.g., PORT for Portland).
The municipal codes should be unique system wide.
County Text Optional The optional county field helps to distinguish matching addresses from multiple counties. It is not used in the validation routine.
Common Place Name Layer
A common place name layer is an optional layer that allows users to search locations on the map based on a business name.
Field Data Type Mandatory Notes
Shape Geometry
(Point) or
Feature
Geometry
(Point)
Mandatory
Common
Place Name
Text Mandatory Contains the common place name or business name.
Full Address Mandatory Contains the full address. This is the column that contains the address the map validates against (e.g., 1 E MAIN ST W). Note the following rules:
- Must not have special characters such as dashes (-).
- It is recommended to use abbreviated street types.
- Should only have a single space separating each word.
Municipality
code
Text Mandatory Contains the municipality codes that the site uses for address validation. Note the following rules:
113
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 34
- The code values should match the CAD municipality codes table (e.g., PORT for Portland).
- The municipal codes should be unique system wide.
Feature Layers
MapViewer feature layers contain operational information that is overlaid on top of the base map. While a base map determines how a map should look, features display operational data that changes frequently such as traffic cameras, current events, and geographic events. Feature layers can be configured to display images as well as static videos and live streams. These videos can be played from any feature layer that defines a location linking to the video. Any standard video format (e.g. MP4, WAV, etc.) is supported for static video.
RTMP/RTSP formats are supported for streaming video.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide regional GIS information in either ESRI map package format or as an ArcGIS map service. • At minimum, this data must consist of a street centerline layer and polygon layer(s) that contains fire districts/zones and jurisdictional boundaries, and police district/zones and jurisdictional boundaries.
b. Perform quality assurance testing on the Versaterm CAD and MDT maps to verify quality and completeness of the data.
c. Resolve data issues arising from the Customer quality assurance testing. d. Define internal processes to handle the communication of required GIS data updates and to apply those updates to the source GIS.
e. Work with Customer GIS resources to identify the desired GIS information to be displayed on the CAD and MDT maps.
VERSATERM RESPONSIBILITIES
a. Provide the documentation on GIS file requirements for Versaterm CAD and MDT maps. b. Assist in identifying the cause of issues arising from Customer quality assurance testing. c. Resolve application issues arising from the Customer quality assurance testing.
3. AUTOMATED VEHICLE ROUTING AND RECOMMENDATION (AVRR)
Automatic Vehicle Routing and Recommendation (AVRR) is functionality that enhances Versaterm CAD AVL dispatch recommendations for police units and fire apparatus.
The AVRR method determines the time (and distance) required by the unit/apparatus to get from its current location to the call by calculating the route based on the underlying street network. When calculating a route, AVRR takes into consideration speed limits and road restrictions such as one-way streets and medians. 114
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 35
The AVRR system loads the street network from the native ESRI shapefile storing it in a PostGIS enabled Postgres database to support AVRR functions within CAD. The following fields are captured from the street centerline shapefile. The names of the fields can be different from what is specified in this table.
Field Date
Type
Mandatory Notes
Street
Name
Char(50) Mandatory The street name field must contain a ‘full street name’ that includes direction, name, and type (e.g., N MAIN ST).
Speed
limit
Numeric Mandatory The speed limit. Any street segments with a speed of zero will not be loaded into the system and as a result cannot be routed to.
Direction
of travel
Char(1) Mandatory This field can contain a code representing one of the following conditions:
Indicating a two-way street segment.
Indicating that the traffic direction of the one-way street segment follows the direction of the segment.
Indicating that the traffic direction of the one-way street segment is the opposite to the direction of the segment.
Plan
Segment
Id
Char (20) Optional This is a unique id for each street segment that can be used by the Speed Factor Plan to identify the segment to have the plan applied to.
From
node Id
Large
Integer
Optional The starting and ending node ID assigned to the segment.
Used to determine the segment that intersects with either end. This allows for segments to pass under an overpass and not intersect with the overpass from a routing
perspective.
To node Id Large
Integer
Optional The starting and ending node ID assigned to the segment.
Used to determine the segment that intersects with either end. This allows for segments to pass under an overpass and not intersect with the overpass from a routing
perspective.
Divided
Road
Segment
Char (1) Optional This field can contain a code that describes where along the segment the road is divided by a barrier and cannot be
crossed:
Road is divided at both ends.
Road is divided at the start of the segment.
Road is divided at the end of the segment.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide street centerline layer containing routing data in ESRI shape file format. b. Perform quality assurance testing on the Versaterm CAD and MDT to verify the quality and completeness of the data.
c. Resolve data issues arising from the Customer quality assurance testing. d. Define internal processes to handle the communication of required GIS data updates and to apply those updates to the source GIS.
115
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 36
VERSATERM RESPONSIBILITIES
a. Provide the documentation on AVRR file requirements. b. Perform the initial AVRR data load and assist the Customer with subsequent loads. c. Assist in identifying the cause of issues arising from Customer quality assurance testing. d. Resolve application issues arising from the Customer quality assurance testing.
POLICE CALL FOR SERVICE TRANSFER
INTERFACE SCOPE
The Interfaces transfers police Call-For-Service (CFS) data from the Versaterm Computer Aided Dispatch (CAD) to the Axon Records Management System (RMS).
PROCESS FLOW
CFS data files are transferred to Amazon Web Services (AWS) File Transfer Protocol (FTP) server, which is made accessible to 3rd party vendors via SFTP.
vCAD supports a configuration parameter, by call type, to indicate when a CFS should be transferred to the Police RMS (on call initiation or on call close – trigger the send). In addition, vCAD supports configuration options where specific unit status codes may also trigger the CFS transfer (e.g. at scene).
Once triggered, the calls-for-service will be transferred and then re-sent (i.e. entire call) whenever any subsequent changes or updates are performed to the CAD CFS. A change or update may include a change of information (e.g. address) or any additional details (remarks, dispatches, etc.). The dispatcher may also trigger the send via the CAD command line.
vCAD identifies the CFS as requiring a transfer by placing the CFS key into a queue for processing known as the RMS Gateway. At a pre-configured interval (e.g., 1 minute), the RMS Gateway will transform the CFS into a NIEM-compliant XML format and write the file to designated folders on the Versaterm AWS FTP server making the files available to the Police RMS and the Torrance Data Warehouse. The RMS monitors the folder and transfers files to the RMS server via password-less SFTP.
As the XML file can be written multiple times (i.e., CFS is re-sent), the XML file name remains the same, so the file is always the most recent. It is anticipated the RMS will remove the file (move to an archive/processed folder for backup/debugging purposes).
The following diagram illustrates data flow between vCAD and the Police RMS:
116
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 37
DATA FILE TRANSFER METHOD
To initiate the transfer to the RMS, the CAD system writes an entry into the gateway queue. A special gateway daemon (gw_daemon) monitors the queue and calls a program to process each entry. If the program determines the call should be transferred to the Police RMS, it will create a NIEM XML file in a special transfer directory on the CAD application server. A scheduled transfer script, invoked by a CRON entry, transfers the XML files to the FTP server where they are made available for retrieval by the Police RMS system.
CONFIGURATION
Configuration Screen or File Configuration Setting Possible Values Recommended Setting
Police Call Type Maintenance
Screen
Transfer to RMS On Call Clear
On Call Initiation
TBD
Unit Status Code Maintenance
Screen
Transfer to RMS Transfer on Status
Change
No Transfer
TBD
Jurisdiction Parameters
Maintenance Screen
Transfer Calls Yes/No Yes
Transfer Instructions TBD
Vdxiii.cadsvc.cron Cron (scheduled) entry
for SFTP transfer of
CFS file
TBD
DATA FORMAT REQUIREMENTS
The CFS data is provided in Versaterm NIEM XML file format. The Versaterm NIEM IEPD will be provided prior to the interface development.
The Customer will develop the data field mapping between the Versaterm NIEM XML file and the destination system to determine which Versaterm data elements will be populated within the destination system. 117
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 38
COMMUNICATION
The communication between the RMS and the CAD application server is provided via password less SFTP, using server RSA public/private keys.
AUTHENTICATION
Authentication is accomplished using Versaterm-provided RSA certificate and SFTP credentials.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be made available on all servers (production, dev/test, training and any redundant and/or disaster recovery) within the CAD environment provided network connectivity is available from the Versaterm AWS FTP server to the RMS.
Note that to function in environments other than production, we assume the Customer will interface to the equivalent RMS environment (dev/test, etc.), if applicable.
INTERFACE TESTING
Interface testing is intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for this specific interface during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test will ensure that calls are routed to the correct destination. Further, this test will ensure that by configuring the “Transfer to RMS” flag, calls-for-service are sent (and re-sent) appropriately.
The test will use two call types.
1. Transfer to RMS flag set to “on Call Initiation.”
2. Transfer to RMS “on Call Close.”
Calls will be created using the test call types configured in the CAD. Additionally, the transfer can be initiated from the command line. The user will confirm that calls are transferred to the appropriate destination system as required and on the appropriate intervals.
Upon closing a call, the calls will be updated, and this test will verify that the updated data is transferred to the RMS.
OPERATIONAL TESTS
This test ensures the interface is available (continues to function) after system re-starts or failover. The operator will re-start the system and confirm that CAD calls-for-service are transferred from vCAD.
PERFORMANCE TESTS
The performance test consists of initiating the transfer, either manually or automatically, ensuring the data is transferred. The time from initiating the transfer to the destination is not to exceed 3 minutes. However, delays caused by the destination system in processing the data is not counted in the calculation.
EXCEPTION TESTING
The exception tests consist of disconnecting the interface between AWS FTP server and Fire RMS server(e.g. disable file transfer process between AWS FTP server and Fire RMS server) and after reconnecting, ensure 118
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 39
Fire RMS can reach the AWS FTP server and calls that are queued in CAD while the interface is disconnected are sent.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately, and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Facilitate and/or configure test environments to support testing activity. b. Provide networking access to allow SFTP connectivity between the CAD application server and the FTP server.
c. Work with Versaterm to establish password-less SSH communications between the CAD server and the FTP server.
d. Provide networking access between the FTP server and the Police RMS e. Work with the Versaterm and Police RMS vendor to define the field mapping between the Versaterm CAD NIEM call-for-service file and the destination system.
f. Work with Police RMS vendor to develop programs/scripts to monitor the incoming NIEM call-for-service XML files on the FTP server and transform/load the data into the Police RMS. g. Coordinate with the Police RMS vendor to modify the destination system as required with the ability to ingest the NIEM XML data and to receive and process multiple XML files for the same call-for-service (i.e., CAD updates to an already transferred CFS will result in a subsequent XML file to be transferred). h. Assist Versaterm as required as they perform the initial integration testing. i. Review the results from Versaterm’s initial integration testing. j. Perform integration testing as described in the Interface Testing section above.
VERSATERM RESPONSIBILITIES
a. Provide Versaterm’s NIEM schema file.
b. Assist the Customer, as required, in defining the field mapping between the Versaterm CAD NIEM call-for- service file and the destination system.
c. Provide RSA certificate and SFTP credentials to 3 rd party RMS vendors. d. Configure password-less SSH connectivity between the CAD server and the FTP server. e. Install and configure the necessary gateways to transfer the NIEM XML files from the CAD to the designated folders on the Versaterm Cloud SFTP server.
f. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
FIRE RMS CALL FOR SERVICE TRANSFER
INTERFACE SCOPE
This interface transfers Fire Calls-For-Service (CFS) data from the Versaterm Computer Aided Dispatch (CAD) to the Fire Records Management System (RMS).
PROCESS FLOW
CFS data files are transferred to Amazon Web Services (AWS) File Transfer Protocol (FTP) server, which is made accessible to 3rd party vendors via SFTP.
119
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 40
vCAD supports a configuration parameter, by call type, to indicate when a CFS should be transferred to the Fire RMS (on call initiation or on call close – trigger the send). In addition, vCAD supports configuration options where specific unit status codes may also trigger the CFS transfer (e.g. at scene).
Once triggered, the calls-for-service will be transferred and then re-sent (i.e. entire call) whenever any subsequent changes or updates are performed to the CAD CFS. A change or update may include a change of information (e.g. address) or any additional details (remarks, dispatches, etc.). The dispatcher may also trigger the send via the CAD command line.
vCAD identifies the CFS as requiring a transfer by placing the CFS key into a queue for processing known as the RMS Gateway. At a pre-configured interval (e.g., 1 minute), the RMS Gateway will transform the CFS into a NIEM-compliant XML format and write the file to designated folders on the Versaterm AWS FTP server making the files available to the Fire RMS and the Torrance Data Warehouse. The RMS monitors the folder and transfers file to the RMS server via password-less SFTP.
As the XML file can be written multiple times (i.e., CFS is re-sent), the XML file name remains the same, so the file is always the most recent. It is anticipated the RMS will remove the file (move to an archive/processed folder for backup/debugging purposes).
The following diagram illustrates data flow between vCAD and the Fire RMS:
DATA FILE TRANSFER METHOD
To initiate the transfer to the RMS, the CAD system writes an entry into the gateway queue. A special gateway daemon (gw_daemon) monitors the queue and calls a program to process each entry. If the program determines the call should be transferred to the Fire RMS, it will create a NIEM XML file in a special transfer directory on the CAD application server. A scheduled transfer script, invoked by a CRON entry, transfers the XML files to the FTP server where they are made available for retrieval by the Fire RMS system.
CONFIGURATION
Configuration Screen or File Configuration
Setting
Possible Values Recommended
Setting
Fire Call Type Maintenance
Screen
Transfer to RMS On Call Clear
On Call Initiation
TBD
120
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 41
Unit Status Code
Maintenance Screen
Transfer to RMS Transfer on Status
Change
No Transfer
TBD
Jurisdiction Parameters
Maintenance Screen
Transfer Calls Yes/No Yes
Transfer Instructions TBD
Vdxiii.cadsvc.cron Cron entry for SFTP
transfer of CFS file
TBD
DATA FORMAT REQUIREMENTS
The CFS data is provided in Versaterm NIEM XML file format. The Versaterm NIEM IEPD will be provided prior to the interface development.
The Customer will develop the data field mapping between the Versaterm NIEM XML file and the destination system to determine which Versaterm data elements will be populated within the destination system.
COMMUNICATION
The communication between the RMS and the CAD application server is provided via password less SFTP, using server RSA public/private keys.
AUTHENTICATION
Authentication is accomplished using Versaterm-provided RSA certificate and SFTP credentials.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be made available on all servers (production, dev/test, training and any redundant and/or disaster recovery) within the CAD environment provided network connectivity is available from the Versaterm AWS FTP server to the RMS.
Note that to function in environments other than production, we assume the Customer will interface to the equivalent RMS environment (dev/test, etc.), if applicable.
INTERFACE TESTING
Interface testing is intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for this specific interface during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test will ensure that calls are routed to the correct destination. Further, this test will ensure that by configuring the “Transfer to RMS” flag, calls-for-service are sent (and re-sent) appropriately.
The test will use two call types where:
1. Transfer to RMS flag set to “on Call Initiation.”
2. Transfer to RMS “on Call Close.”
121
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 42
Calls will be created using the test call types configured in the CAD. Additionally, the transfer can be initiated from the command line. The user will confirm that calls are transferred to the appropriate destination system as required and on the appropriate intervals.
Upon closing a call, the calls will be updated, and this test will verify that the updated data is transferred to the RMS.
OPERATIONAL TESTS
This test ensures the interface is available (continues to function) after system re-starts or failover. The operator will re-start the system and confirm that CAD calls-for-service are transferred from vCAD.
PERFORMANCE TESTS
The performance test consists of initiating the transfer, either manually or automatically, ensuring the data is transferred. The time from initiating the transfer to the destination is not to exceed 3 minutes.
However, delays caused by the destination system in processing the data is not counted in the calculation.
EXCEPTION TESTING
The exception tests consist of disconnecting the interface between AWS FTP server and Fire RMS server(e.g. disable file transfer process between AWS FTP server and Fire RMS server) and after reconnecting, ensure Fire RMS can reach the AWS FTP server and calls that are queued in CAD while the interface is disconnected are sent.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately, and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Facilitate and/or configure test environments to support testing activity. b. Provide networking access to allow SFTP connectivity between the CAD application server and the FTP server.
c. Work with Versaterm to establish password-less SSH communications between the CAD server and the FTP server.
d. Provide networking access between the FTP server and the Fire RMS e. Work with the Versaterm and Fire RMS vendor to define the field mapping between the Versaterm CAD NIEM call-for-service file and the destination system.
f. Work with Fire RMS vendor to develop programs/scripts to monitor the incoming NIEM call-for-service XML files on the FTP server and transform/load the data into the Fire RMS. g. Coordinate with the Fire RMS vendor to modify the destination system as required with the ability to ingest the NIEM XML data and to receive and process multiple XML files for the same call-for-service (i.e., CAD updates to an already transferred CFS will result in a subsequent XML file to be transferred). h. Assist Versaterm as required as they perform the initial integration testing. i. Review the results from Versaterm’s initial integration testing. j. Perform integration testing as described in the Interface Testing section above.
VERSATERM RESPONSIBILITIES
a. Provide Versaterm’s NIEM schema file.
b. Assist the Customer, as required, in defining the field mapping between the Versaterm CAD NIEM call- for-service file and the destination system.
122
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 43
c. Provide RSA certificate and SFTP credentials to 3 rd party RMS vendors. d. Configure password-less SSH connectivity between the CAD server and the FTP server. e. Install and configure the necessary gateways to transfer the NIEM XML files from the CAD to the designated folders on the Versaterm Cloud SFTP server.
f. Perform initial integration testing as described in the Interface Testing section above and review results with the Customer.
MOTOROLA MCC7500 RADIO SYSTEM (PTT/ERTT)
This interface displays radio identifier, unit and officer information on the CAD status screen whenever an officer keys (i.e. presses the Push-To-Talk button) their portable or vehicle mobile radio (PTT). This interface also displays an emergency warning message to all CAD status screens and an indicator on the CAD maps when an officer presses the emergency key/button on their radio (ERTT).
PROCESS FLOW
The Versaterm MCC7500 voice radio interface (MC75PTT) receives, and processes push-to-talk (PTT) and emergency (ERTT) transactions received from portable and vehicle mobile radios. The Versaterm developed MC75PTT application, installed on an MCC7500 console, connects the Motorola Voice Radio system to the CAD system.
The radio identifier received from the MCC7500 will be validated against Customer maintained tables in the CAD database to retrieve the appropriate Officer and/or Unit ID information. This information will then be reflected on CAD Status Screen marquees as configured by the mapping of radio talk groups/channels to coverage areas (positions).
The PTT information (unit/officer and radio identification) information will be displayed on the CAD status screen marquee, at only those dispatch consoles configured for the talk group or coverage area mapping, that particular unit/officer is assigned.
ERTT unit/officer and identification will be displayed on the CAD status screen marquee at all dispatch consoles (i.e. wherever the status screen is displayed).
To distinguish the PTT received between a portable radio and an in-car radio, CAD prefixes an indicator of ‘(P)’ for portables radios and ‘(U)’ for in car radios on the Status Screen marquee. 123
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 44
INTERFACE INSTALLATION
The Versaterm MC75PTT interface module is developed using the Motorola supplied MCC7500 Application Programming Interface (API) and Software Developer’s Kit. This application must be installed on an MCC7500 console.
The MC75PTT interface module can also be installed on a secondary MCC7500 console, for redundancy. Should the primary console fail (down), the secondary MCC7500 radio interface module will connect to the VMC and process transactions. Note that the primary and secondary MCC7500 consoles must be identically configured, and not changeable or reconfigurable by a user, otherwise functionality and behavior could differ and cause unexpected behavior.
CONFIGURATION
The following configurations are associated with this interface.
Configuration Screen or File Details
Portable Radio table
portable_id
The CAD Administrator enters the portable radio identifications into the CAD ‘Portable Radio’ table. The radio identification number entered in the CAD “lid” field (up to 32 characters) maps to the CAD portable radio number (up to 6 alphanumeric). The portable radio may be optionally assigned permanently to a warden – recorded in the ‘Officer Identification Number’ table (this may be overridden at sign-on or during the shift).
Vehicle ID table
vehicle_id
The CAD Administrator maps vehicle mobile radios ID to the vehicle ID in the ‘Vehicle ID’ table within CAD. Optionally, the mobile radio ID can be updated / overridden at MDT sign-on. See the “Versaterm CAD / Radio Configuration User/Administrator 124
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 45
Guide” for full configuration details (Version 7.6 Edition 1.0 or higher).
VmcConfig.vcfg This configuration file located on the MCC7500 console that has the MC75PTT application installed on it must be updated with the connection details for the VMC.
Mc75Config.vcfg This configuration file located on the MCC7500 console that has the MC75PTT application installed on it must be configured to enable the PTT and ERTT functions.
TalkGroup.vcfg This configuration file located on the MCC7500 console that has the MC75PTT application installed on it must be updated to include the talkgroups that need to be monitored.
DATA FORMAT REQUIREMENTS
Data transmissions (message formatting and flow control) are provided as identified in the Motorola MCC7500 SDK.
COMMUNICATION
Communication from the VMC to the Versaterm MCC7500 radio interface module (MC75PTT), residing on the MCC7500 console, is provided via a TCP/IP communication link.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be made available on all environments provided connectivity between VMC application server and the MCC7500 console is available. The interface can be enabled/disabled by configuring the appropriate interface configuration parameter in the interface section of the local server resource or similar configuration file.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. Below are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
The test includes pressing the PTT and ERTT buttons from the portable or from in car radio and ensuring the Unit/Officer information is displayed on the status screen marquee. For PTT transactions the information is displayed on status screen marquee of the dispatch consoles responsible for that particular area of the Unit/Officer. For ERTT transactions, the information is displayed at all dispatch consoles with a status screen displayed.
OPERATIONAL TESTS
This test ensures after system reboots the interface is available and able to communicate with MCC7500 console.
125
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 46
PERFORMANCE TESTS
The performance tests are measured from the time the Motorola MCC7500 system delivers the event until the time the event is displayed on the CAD status screen. The Versaterm interface will not require more than 2 seconds in processing the transaction. Excluded from any measurement is network time (e.g. Radio Network) or external system processing time.
EXCEPTION TESTING
This test includes shutting down the connectivity (i.e. pulling the plug) to the Motorola network and ensuring that the Versaterm interface will automatically re-connect once connectivity is re-established.
No queuing or notifications occur with this interface.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide a dedicated MCC7500 console for this interface. b. Configure network access to permit the VMC system to connect to the MCC7500 console. c. Provide Versaterm with remote access to the designated MCC7500 console (if possible). If remote access is not possible, install the Versaterm interface on the designated MCC7500 console. d. Be responsible for any costs associated with any Motorola provided component, documentation, or software (SDK, etc.) as well as any Motorola lab fees, technical engineer fees, or other Motorola fees. e. Configure the CAD tables (portable_id, vehicle_id, officer_number, and message handles, etc.) as required.
f. Liaise with Motorola technical authorities during interface configuration and testing. g. Assist Versaterm as required as they perform the initial integration testing. h. Review the results from Versaterm’s initial integration testing and provide written acceptance of the tests. i. Perform integration testing as described in the Interface Testing section above.
VERSATERM RESPONSIBILITIES
a. Install and test the MCC7500 interface.
b. Perform initial integration testing as described in the Interface Testing section above and provide test results to the Customer.
c. Provide assistance and guidance through the Customer acceptance tests.
EVENTIDE NEXLOG (AUDIO LOGGER)
INTERFACE SCOPE
126
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 47
This interface provides a one-way metadata transfer from the Versaterm CAD system to the Eventide NexLog audio logger system. The CAD system transmits user information and incident numbers to NexLog, where the data is associated with corresponding audio recordings. This allows NexLog users to search for and display call recordings based on CAD incident numbers, improving correlation between voice and dispatch records.
PROCESS FLOW
When a user signs on to the CAD desktop application, the CAD application server submits the logged-on user’s metadata to the NexLog system, provided the desk position is associated with recorder channel(s). The metadata is also submitted when a user signs off from CAD. The purpose of submitting the CAD user metadata is to have the user logged on or off the NexLog activity table for recorder channel tagging purposes. User metadata sent from CAD includes desk identification, recorder channel(s) associated to the desk, the desk IP address as well as the first and last name of the user.
Upon startup of the CAD server daemon, a list of all actively signed on CAD positions, with an associated recorder channel, is submitted to the NexLog system for recorder synchronization purposes.
Additionally, when a call for service is created from a position that is associated to a recorder channel(s), the system will first check to see if the ‘how received’ value of the call is configured to be transferred to the NexLog system (e.g. 911, Telephone). If so, the incident metadata is submitted to the NexLog system. Incident metadata includes the recorder channel(s) associated to the CAD position and the incident number. Incident transactions are submitted as ATTACH to the NexLog system.
CAD transactions are only submitted to NexLog for CAD desk position that are associated to one or more recorder channels. That is, if a given CAD position is not associated to any recorder channel, CAD does not send any transactions, for that CAD position to the NexLog system.
For any transaction sent to NexLog from a CAD position that is associated to more than one recorder channel, separate transactions are sent for each recorder channel associated to that CAD desk position.
CONFIGURATION
A configuration file exists on the CAD application server (eventide_config.json) to define the connection hostname, port number as well as to map each CAD desk position to the corresponding recorder channel(s).
Each CAD desk position can have one or more associated recorder channel(s).
This config file contains the following settings:
Configuration field name Description
hostname Eventide NexLog hostname for CAD to use when submitting transactions for that particular environment (test or production) port Port number for CAD to use when submitting transactions for that particular environment (test or production)
127
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 48
desks An array of desk_id, recorder_channels and recorder hostname/port fields exist, associating each position’s desk ID to the eventide recorder channel.
For example:
{
"desks": [
{
"desk_id": "POS1",
"recorder":
{
"hostname": "nexlog1.customer.local",
"port": 5000,
"channels": [ "26" ]
}
},
{
"desk_id": "POS2",
"recorder":
{
"hostname": "nexlog2.customer.local",
"port": 5000,
"channels": [ "31" ]
}
}
]
}
How Received A configuration option in the JSON file exists to configure the ‘how received’ values that trigger a transfer to the NexLog system.
For example:
“how_received”: [“A”, “D”. “9”]
Additional configuration settings: "test_mode": 0,
“attach_at_time”:true,
DATA FORMAT REQUIREMENTS
Data transmissions (command formatting and flow control) are provided as identified in the Eventide document titled "Communications Division NexLog API Manual - Models NexLog740, NexLog 840 – NexLog Recorder Software v2.8" (file name: MediaWorks User Manual.pdf).
COMMUNICATION
Communication between the vCAD application server and the Eventide system is provided via TCP/IP protocol.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be made available on all servers (production, implementation/test, and disaster recovery) provided connectivity between CAD application server and the NexLog API is available. The interface can be enabled/disabled by configuring the appropriate CAD interface configuration parameter on CAD application server.
128
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 49
INTERFACE TESTING
These tests are intended to ensure the interface is functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
This test consists of signing on to CAD, creating various calls, signing off CAD and ensuring the transactions are transmitted to the NexLog system.
OPERATIONAL TESTS
This test ensures after system reboots the interface is available and able to communicate with the NexLog system.
PERFORMANCE TESTS
The performance test consists of ensuring that user sign on, sign off and creating E911 call for service within CAD are published to the NexLog API within two seconds. Excluded from any measurement is network time (e.g. network between CAD and NexLog API) and external system processing times from the NexLog API service.
EXCEPTION TESTING
The exception testing consists of disconnecting the network between CAD and NexLog API and ensuring communication is resumed once connectivity is re-established.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interface functions as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Coordinate with Eventide technical staff to assist in the interface development and testing. b. Provide the communication link between the NexLog API and the CAD application server for TCP/IP protocol.
c. Provide a test facility for the interface.
d. Assist Versaterm as required as they perform the initial integration testing. e. Review the results from Versaterm’s initial integration testing. f. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Install and configure the CAD interface to publish data to the NexLog API. c. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
129
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 50
AXON EVIDENCE.COM (BODY WORN/IN-CAR CAMERA) INTERFACE
INTERFACE SCOPE
This interface provides dispatch information to AXON Evidence.com. The metadata information sent to AXON from CAD is then applied to video-evidence files in Evidence.com.
PROCESS FLOW
Only Calls-For-Service where Police units are dispatched are subject to this interface. The interface process extracts vCAD metadata of the dispatched unit(s) for transfer/upload to Evidence.com. The extracts are initiated by a scheduled process/job (24-hour intervals) contained within the vCAD application server. The scheduled process searches for CFS cleared/closed within the past 96 hours. For each CFS meeting the criteria, the dispatched officer data is extracted into the Evidence.com metadata format (comma-delimited file).
The resulting CSV file is written to a designated shared folder on the vCAD application server. The file(s) are transferred via SFTP to a designated transfer folder on a Customer supplied FTP server where Evidence.com can access the file to ingest the data.
The CAD-RMS Integration Customer, provided by AXON, is installed on the FTP server and monitors the designated transfer folder for new text files submitted from CAD.
The following diagram illustrates the process of the CAD data file transfers to Evidence.com:
CONFIGURATION
Configuration
Screen or File
Configuration
Setting
Possible
Values
Recommended Setting
RSA Public Keys To be provided by Versaterm in order
to establish password-less SFTP
connectivity
Vdxiii.cadsvc.cron Cron scripts that
generate files for
Axon
Evidence.com and
transfer them to the
Customer FTP
server
TBD
DATA FORMAT REQUIREMENTS
130
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 51
The data files created by Versaterm CAD conform to AXON’s file specifications as defined in the document titled “Evidence.com CAD-RMS Integration Service Guide” (file name: “AXON – Evidence.com CAD-RMS Integration Service Guide Rev D.pdf”).
The following table describes the order and the fields in the data files that is generated from the CAD system:
AXON
Field
Name
AXON Description Required
or Optional
by AXON
Versaterm Field
Name
Versaterm
Comments
Event ID The unique ID of the event. The data
in the column may reflect
INCIDENT#, CADIncidentNumber,
or a similar field.
Required Cc_data.jur +
cc_data.occ_yea
r +
cc_data.occ_nu
m
Format: JJYY-
NNNNNNNNNN
Where JJ is
jurisdiction. NNN is
unique incident
number
Officer
Badge ID
The unique badge ID assigned to
the officer. This ID must exactly
match the officer badge ID assigned
to the Axon camera in
Evidence.com. If badge IDs differ
between systems, this must be
resolved during the implementation
process.
Required Dc_data.officer_
no
Or
dc_data.officer_
no2
For two officer units,
a separate row is
generated using
officer_no2
database field
Officer
Dispatched
DateTIme
The start time of the officer event.
Used to define the beginning of the
time range that the start time of the
officer's video evidence file must be
within. Dispatched times must be in
ISO 8610-compliant format, either
using UTC or timezone offset.
• UTC format example — 2015-
11-13T21:35:42Z
• Timezone offset format
example — 2015-11-
13T21:35:42-08:00
The difference between the
dispatched and cleared times must
be greater than 0 (zero) but less
than 8 hours.
Required dc.data.dispatch
_time
Date and time of
officer dispatched.
131
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 52
Officer
Cleared
DateTime
The end time of the officer event.
Used to define the end of the time
range that the start time of the
officer's video evidence file must be
within. Cleared times must be in ISO
8610-compliant format, either using
UTC or timezone offset.
• UTC format example — 2015-
11-13T21:35:42Z
• Timezone offset format
example — 2015-11-
13T21:35:42-08:00
Required Dc_data.inservic
e_time
Date and time of
officer going in-
service.
Report
Number
The RMS ID of the report about the
CAD event. If no RMS ID is
available, this field can be empty.
Optional Unavailable
Title A title for the event. Optional Unavailable
Tag Text labels that apply to the event. If
you include more than one Tag field,
the heading should be “Tag” for
each of them.
Optional Unavailable
Category The CAD event type code of the
event. Evidence.com uses the event
type provided in this column to
determine which retention category
is assigned to matching video
evidence files.
Optional Cc_summary.fin
al_case_type
CAD’s incident final
case type code
Category2 Incident clearance code Optional Cc_summary.cle ared_by
CAD’s cleared by
code (1 character in
length)
Street Street address or intersection of the
event. This information should be
recognizable by Bing Maps;
otherwise, location based
Evidence.com features will be
unavailable for video evidence files
matched to the event.
Optional Cc_seen_at.addr
ess or
cc_data.address
In addition to the
location where the
call occurred on, if
an incident response
location is present
the cc_seen_at table
is used (e.g.
c_seen_at.address),
representing the
location where the
132
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 53
units responded to.
Otherwise, if no
response location is
present, cc_data
table is used.
Customer The full name of the Customer in
which the event occurred.
Optional cc_seen_at.muni
cipality or
cc_data.municip
ality
Translation of the
municipality code is
sent.
State/Provi
nce
State/Province in which the event
occurred.
Optional Hardcoded “NB”
ZIP Code The postal code within which the
event occurred.
Optional Addres_history.z
ip
Sample CAD data extract file:
event_id,officer_badge_id,officer_dispatched_datetime,officer_cleared_datetime,report_number,title,tag, ,category,category2,street,Customer,state,zip_code
SJ23-10100,A1234, 2018-09-09T16:12:53-0800,2018-09-09T16:15:47-0800,,,,TSTOP,C,696 JOANNE DR,SJ,NB,94402
SJ23-10100,A2345, 2018-09-09T16:13:25-0800,2018-09-09T16:16:42-0800,,,,TSTOP,C,696 JOANNE DR,SJ,NB,94402
COMMUNICATION
The communication between the vCloud SFTP Folder and Axon’s CAD-RMS Integration Customer is provided via password less SFTP, leveraging RSA public keys. The Axon CAD-RMS Integration Customer application is responsible for sending the data to Evidence.com.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the production server. This interface is also available from the implementation/test server by configuring the CAD-RMS Integration Customer to monitor a separate folder on the FTP server, where the test files are sent from the implementation/test CAD application server.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
133
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 54
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that the CAD application server submits the CAD data files to the FTP server.
OPERATIONAL TESTS
This test ensures the CAD application server is able to send files to the FTP server via SFTP after the FTP server reboots. The administrator will reboot the FTP server and ensure the SFTP file transfer to FTP server is available.
PERFORMANCE TESTS
There are no performance tests associated with this interface. The extracted CAD files are transferred to the vCloud FTP server daily and processed as received.
EXCEPTION TESTING
The exception testing consists of disconnecting the network between CAD application server and the FTP server, after reconnecting, ensure CAD application server is able to resume file transfers to the FTP server via SFTP.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Configure the FTP server, meeting AXON’s minimum server requirement, for the CAD-RMS Integration Customer.
b. Provide network connectivity between the FTP server and the CAD application server supporting sftp. c. Coordinate with AXON technical staff to assist in the interface development and testing. d. Install and maintain the CAD-RMS Integration Customer on the same FTP server. e. Assist Versaterm with server RSA public key installation on FTP server after each upgrade. f. Assist Versaterm as required as they perform the initial integration testing. g. Review the results from Versaterm’s initial integration testing. h. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Develop, install, and configure the CAD data extracts for AXON interface. b. Install and configure Versaterm SFTP script to send CAD data files to FTP server where AXON Customer monitors.
c. Copy CAD server public key to FTP server, for password less SFTP transfers from CAD server after each CAD application server upgrade.
d. Provide assistance and guidance in the testing process. e. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
FIRE STATION ALERTING (LOCUTION)
134
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 55
INTERFACE SCOPE
This interface consists of one-way communication between Versaterm CAD and Locution Fire Station Alerting System (PrimeAlert). This interface will provide for:
• Automatically sending dispatch information to the station when dispatching apparatus from that station • Sending move-up information to PrimeAlert
• Sending unit status updates to PrimeAlert
Information received from vCAD is used by PrimeAlert to make voice announcements at the appropriate stations.
Acknowledgement transactions are sent back to CAD for Dispatch and Unit Status Message transactions. CAD will notify appropriate dispatchers if the messages were not delivered to the stations.
PROCESS FLOW
When a transaction needs to be sent to PrimeAlert, CAD generates a transaction and sends it to the Versaterm Message Controller (VMC) where it is queued for processing. Once processed, the appropriate VMC plug-in formulates the appropriate transaction (ASCII encoded TCP/IP message) and sends it to PrimeAlert.
PrimeAlert will respond with two acknowledgement messages. The first message will be an acknowledgement of receipt, and the next message will be a status message for each station dispatched. If the acknowledgement message indicates a failure to play the message at a station, CAD will notify appropriate dispatchers by sending a CAD message.
The following diagram illustrates the process of the vCAD sending alerts to Locution:
CONFIGURATION
Configuration Screen or File Configuration Setting Possible Values Recommended Setting CAD Configuration Settings
– EMS&Fire Setting
Station Alerting Interface
Installed
Yes/No Yes
Send Lat/Long on
dispatch
Yes/No Yes
Alert Station By Both call & unit tone
numbers
Call Tone Number
Unit Tone Number
Both call tones and unit codes
Station Print Enabled Yes/No No
Automatically opens PA Yes/No No
135
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 56
VMC Configuration Settings VMC System Name TBD
Station Configuration
Screen
Station Alerting Tone TBD
Apparatus Configuration
Scree
Apparatus Alerting code TBD
VMC System Configs Remote IP TBD
Remote Port TBD
Reconnect Timeout 0-999 10
Backup IP (optional TBD)
Backup Port (optional TBD)
Ack Timeout 0-999 5
Alert/Status Timeout 0-999 30
DATA FORMAT REQUIREMENTS
Transactions generated by Versaterm CAD conform to Locution System’s specifications as defined in the document titled “Application Programming Interface (API) Document for Interfacing to the PrimeAlert/CADVoice System” Revision 4.3.8 dated July 31, 2018.
The following transactions are supported by the interface:
1. Dispatches: sending CAD incident data to PrimeAlert.
2. Station Move Ups: sending apparatus move-up data to PrimeAlert.
3. Unit Status Messages: sending apparatus status changes to PrimeAlert.
Fields sent to PrimeAlert with Dispatch transaction:
PrimeAlert Field
Name Versaterm Field Name Versaterm Comments
Incident Number
(IBN)
cl_data.rin Format: JJYYNNNNNNNNN
Where JJ is jurisdiction such as TF for Torrance
Fire. NNN is unique incident number
Jurisdiction (JR) Call jurisdiction Extracted from Incident number above Stations station.alert_code List of stations where the message should be played
Units (UN) app_stat.alert_code Dispatched apparatus
Alert Tones (TP) fire_status_codes_tones.alert
_status
Incident Type (IN) cl_data.call_type Type of incident
136
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 57
PrimeAlert Field
Name Versaterm Field Name Versaterm Comments
Priority (PR) cl_data.priority Priority of the incident Street Address
Location (ST)
cl_data.address Location of the incident
Apartment (AP) cl_data.apt_no
Cross street (SCN) address_history.cross_streets
Common place name
/ landmark (LK)
cl_data.place_name
Business name/Landmark
Area, Map Zone, etc.
(AR)
cl_data.grid
Alarm Level (AL) cl_data.alarm_level
Incident Comments
(ICN)
Initial remarks
(cl_remarks.remarks)
X coord (AX) cl_data.x_coordinate,
Y coord (AY) cl_data.y_coordinate
Radio Channel (RC) cl_data.tactical_channel
Message (MSN) Dispatch remarks
Fields sent to PrimeAlert with Station Move Ups transaction:
PrimeAlert
Field Name Versaterm Field Name Versaterm Comments
ANNOUNCE
MENT
TARGET
App_stat.orig_stn Unit’s current station
UNIT(UNS) App_stat.app_id Apparatus ID to be moved up
137
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 58
PrimeAlert
Field Name Versaterm Field Name Versaterm Comments
Destination
Station(NM)
App_stat.stn target Station ID
Fields sent to PrimeAlert with Unit Status Messages transaction:
PrimeAlert
Field Name Versaterm Field Name Versaterm Comments
UNIT App_stat.app_id Unit Identifier, for example E21
STATUS
CODE
App_stat.app_status Status of the unit, for example AQ
LOCATION App_stat.stn Station where the unit is located. If the unit is not at the station, this field is set to “RADIO”
COMMUNICATION
The communication between the vCAD server environment and the Locution PrimeAlert server is provided via TCP/IP sockets.
Communication between VMC and PrimeAlert is asynchronous meaning that it will not wait for the response.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be available on all environments (Production, Test/Dev and Training) provided communication to PrimeAlert can be established.
Note, to enable this interface on Test/Dev and Training environments, the Customer will be required to provide a test PrimeAlert system.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that whenever a dispatch is sent to a single apparatus within a station, the correct information is sent to the station of the apparatus. Another test will include dispatching two apparatus from two different stations and ensuring that correct information is sent to both stations. 138
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 59
Additional tests confirm that appropriate transactions are sent to PrimeAlert system when apparatus are moved up or change status.
OPERATIONAL TESTS
This test ensures the interface is available (continues to function) after system re-starts or failover. The operator will re-start the system and confirm that transactions are sent to PrimeAlert.
PERFORMANCE TESTS
The performance test consists of dispatching a unit and measuring the number of seconds between the time the command is issued until it reaches the alerting system. The time lapse should not exceed two seconds.
Time delays introduced by the 3rd party system, or the network are not included in any time measurements.
EXCEPTION TESTS
The exception testing consists of disconnecting the network link between the VMC and the PrimeAlert server and confirming that error messages are delivered immediately to the CAD dispatcher when a station alert is requested. Further tests confirm that, after re-connecting the link, the communication resumes.
DATA INTEGRITY TESTS
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Facilitate and/or configure a test environment to support testing activity. b. Coordinate with Locution technical staff, as required, to assist in the interface development and testing. c. Provide network connectivity between vCAD and Locution PrimeAlert. d. Assist Versaterm as required as they perform the initial integration testing. e. Review the results from Versaterm’s initial integration testing and confirm that the interface works as required.
f. Perform integration testing as described in the Interface Testing section (above).
VERSATERM RESPONSIBILITIES
a. Install and configure the interface.
b. Perform initial integration testing as described in the Interface Testing section above and provide results to the Customer.
c. Assist and support the Customer testing.
PRIORITY DISPATCH PROQA INTERFACE
INTERFACE SCOPE
139
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 60
This interface consists of a two-way data exchange between vCAD and ProQA Emergency Medical Dispatch (EMD) and ProQA Fire and ProQA Police. The interface is designed so that the call-taker leverages the triage functionality within ProQA and adjusts the call-type, on the Call-For-Service (CFS) within vCAD.
Details on the ProQA application can be found at the following WEB link: http://www.prioritydispatch.net .
PROCESS FLOW
This interface first delivers initial vCAD CFS data to ProQA when invoking a ProQA session. The CFS data is ingested into ProQA to triage with ProQA configured questions asked of the reporting party (RP) by the call taker.
The call-taker continues triaging the call in ProQA asking further questions until the ProQA software has sufficient information to make an emergency response recommendation. At each ProQA send point the data is returned to vCAD where vCAD updates the CFS notes with the ProQA comments.
The latest supported version of the ProQA application is 5.1. Future upgrades of ProQA software may require vCAD changes and need to be coordinated with Versaterm.
The following diagram illustrates data flow between ProQA and vCAD:
CONFIGURATION
Configuration Screen or File Configuration Setting Possible Values Recommended Setting Call Type Maintenance Trigger External Triage
Interface
Yes/No TBD
CAD Configuration | Site
Settings
Auto Query Entities True/False True
Delete Cache After
Complete
True/False True
EMS Application Name Medical.exe
EMS Case Type TBD
EMS Install Path C:\Program Files
(x86)\PriorityDispatch\ProQA\Medical.exe
EMS Installed True/False True
EMS Port Number 2400
EMS Special Service
Code
TBD
Fire Application Name Fire.exe
Fire Case Type TBD
140
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 61
Fire Install Path C:\Program Files
(x86)\PriorityDispatch\ProQA\Fire.exe
Fire Port Number 2300
Fire Special Service
Code
TBD
Local IP Address 127.0.0.1
Police And Or Fire
Installed
Police
EMS&Fire
Both
Not Applicable
TBD
Police Application Name Police.exe
Police Case Type TBD
Police Install Path C:\Program Files
(x86)\PriorityDispatch\ProQA\Police.exe
Police Port Number 2200
Police Special Service
Code
TBD
ProQA Legacy Version Ture/False TBD
Update Only Mode
Enabled EMS
True/False TBD
Update Only Mode
Enabled Fire
Ture/False TBD
Update Only Mode
Enabled Police
True/False TBD
External Triage Program ProQA
CAD Configuration | Site
Settings
Local IP Address 127.0.0.1
External Triage Program ProQA
E_pqa_kq_config.xml
F_pqa_kq_config.xml
P_pqa_kq_config.xml
Various settings that
control the format of the
narrative documents that
ProQA produces for
CAD calls.
DATA FORMAT REQUIREMENTS
Not applicable for this interface.
COMMUNICATION
Communication is handled at the Windows level between the vCAD app and ProQA desktop software, which is responsible for communication with ProQA server. Communication uses TCP protocol on the configured port.
AUTHENTICATION
Not applicable for this interface.
141
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 62
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
As this interface is available at the CAD workstation, the interface is always available.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures the initial CAD incident data elements (incident number, address, optional phone number and optional caller name) are transferred to ProQA and that ProQA is successfully invoked. Additionally, this test ensures the appropriate CAD incident updates take place and that a desk message containing the reconfiguration recommendation is delivered to the controlling CAD dispatch position(s).
OPERATIONAL TESTS
These tests ensure that CAD is able to invoke and re-connect to ProQA after reboots. A number of different CAD incident types will be used during these tests (e.g. call types that invoke ProQA and others that do not).
These tests ensure that the appropriate incident type updates are made in CAD based on the information returned from ProQA.
PERFORMANCE TESTS
The performance tests consist of ensuring the transfer of data to the ProQA software occurs within 2 seconds. This time is defined as the time taken to make an initiation request and pass the appropriate data to ProQA. This time excludes the time taken for ProQA to actually start if it is not already a running Windows application and/or the time it takes for ProQA to display the CAD data in ProQA.
This test also ensures that updating a CAD incident with data returned from ProQA occurs within 2 seconds.
This time is defined as the time taken to update the CAD incident and deliver a desk message once CAD successfully receives the data transfer from the ProQA software.
Excluded from any measurement is desktop processing time (e.g. desktop anti-virus scanning tools between CAD and ProQA).
EXCEPTION TESTS
The exception testing consists of attempting to invoke ProQA when it is already engaged with another CAD incident, ensuring a prompt is displayed in CAD indicating another active call is already in progress.
DATA INTEGRITY TESTS
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Purchase, install and configure the ProQA software on the CAD dispatch workstations. b. Configure vCAD and ProQA call types and ensure they match. c. Assist Versaterm as required as they perform the initial integration testing. d. Review the results from Versaterm’s initial integration testing. 142
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 63
e. Perform integration testing as described in the Interface Testing section (above). f. Test the interface to confirm it functions as specified.
VERSATERM RESPONSIBILITIES
a. Install and configure vCAD with ProQA interface components. b. Perform initial integration testing as described in the Interface Testing section (above) and review test results with the Customer.
c. Assist and support Customer testing.
TABLET COMMAND
INTERFACE SCOPE
This interface contains the following distinct interface touch points:
1. Transfer of incident and related unit information
This interface provides a one-way transfer of Fire incident and related unit information from the Versaterm CAD to the Tablet Command system. Transactions are initiated from CAD when incidents are added, updated, and closed as well as units dispatched, unit status changes, remarks added, and special services dispatched.
2. Transfer of updated incident and unit information
This interface accepts unit status changes, call remarks, station moves, and apparatus busy codes initiated from the Tablet Command system into the Versaterm CAD.
3. Real-time Unit Status and GPS Data
This interface provides the ability for the Tablet Command system to pull unit status and GPS data from the Versaterm CAD.
143
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 64
PROCESS FLOW
1.1. TRANSFER OF INCIDENT AND RELATED UNIT INFORMATION
This interface provides a one-way transfer of fire incident and related unit information from the Versaterm CAD to the Tablet Command system.
1.1.1. Process Flow
The vCAD publishes all Fire active incident and unit status information to the Tablet Command in real time. Transactions are initiated from CAD when incidents are added, updated, and closed as well as units dispatched, unit status changes, remarks added, and special services dispatched.
A Tablet Command configuration file exists on the CAD application server to map each CAD jurisdiction code to a corresponding fire department identification number (FDID). The interface will include the FDID that corresponds to the CAD incident’s jurisdiction within the transactions.
Upon sending transactions from CAD to the Tablet Command API, an HTTP status code is returned to the CAD system indicating success or otherwise. Any request sent from CAD that does not return a success status code from the Tablet Command API is resent from CAD with 5-second intervals, for up to (5) five retry attempts.
The interface submits heartbeat transactions to the Tablet Command API at 1-minute intervals.
1.1.2. Configuration
Configuration Screen or File Configuration Setting Possible Values Recommended Setting /Comments $VDXFILES/etc/tc_config.json api_key Tablet command API Key for CAD to use when submitting transactions
staged_status_code Staging unit status code (e.g. SG) that will be sent to Tablet Command
queue_type_filters Call queue type (e.g. ‘R’) from which CAD should send call information to Tablet Command. Blank will
send calls from any queue.
process_apps_not_in_queueTure/False This setting determines if unit status should be sent to Tablet Command regardless if the call is in the
filtered queue type or not. This depends on the
‘queue_type_filters’ configuration. For example, if
only calls from “R” queue are to be sent to Tablet
Command, setting this value to true, will also send
unit status when the call in the active ‘A’ queue.
jurisdiction_filters List call jurisdictions that are to be sent to Tablet Command. For example, to only send Fire calls and
not EMS call, list all Fire jurisdiction in this setting with no EMS jurisdiction listed.
jurisdiction_to_agency Mapping of specific vCAD jurisdiction to FDID (agency id).
/usr/local/bin/setup_cadenv.ca-
torrance
GID_LIST cad.tcifc Setting that enables Tablet Command interface. 144
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 65
1.1.3. Communication
Tablet Command API services are exposed to the CAD application server to facilitate the requests from CAD. Web API requests made to Tablet Command API are handled immediately (synchronously).
The communication between CAD and Tablet Command is via RESTful API using HTTPS protocol. The responses conform to JSON format as defined in the Tablet Command documentation titled “TABLET COMMAND API” (file name: Tablet Command API Documentation.pdf”
1.1.4. Authentication
For each environment (e.g. implementation/test and production environments) a unique API user credentials are provided by Tablet Command in order to access the corresponding Tablet Command API service page for that environment.
1.1.5. Web Service Definition
The RESTful transactions initiated from CAD conform to JSON standards as defined in the Tablet Command documentation titled “TABLET COMMAND API” (file name: Tablet Command API Documentation.pdf”)
1.1.6. Data Format Requirements
The following data field mapping between the Versaterm CAD and Tablet Command illustrates which Versaterm data elements will be populated within the various transactions. 145
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 66
Incident
TC Key TC Description TC Example TC Note Versaterm CAD data field
Versaterm
Notes/Attributes
AgencyID Unique FDID
number per
agency
Example: “07090"
07090 This number is provided by State or Federal
government and is unique to the agency. A
CAD can serve one or multiple agencies.
Multiple agencies can be submitted via one
interface or one API key. Please contact
Tablet Command support if you do not have
an FDID number.
FDID number based on
agency jurisdiction.
CAD configuration
file to map agency
jurisdiction to
agency’s FDID,
based on incident
jurisdiction,
IncidentNumber Incident Number 2839291 Incident number unique to the incident. Cl_data.rin CAD Record identification
number
Format:
JJYYNNNNNNNNNN
Where JJ is
jurisdiction such as
TF for Torrance Fire,
YY is the year and
NNN is unique
incident number
TransactionID Agency-based
unique
transaction
number assigned
for the inbound
transaction.
919292 This number should be unique to the
transaction. For example, you could take
unixtimestamp+incremental_id.
This field is required by Tablet Command API,
but is used only for logging and
troubleshooting purposes.
CAD generated
alpha numeric serial
number.
146
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 67
EntryDateTime Date and time call
was created in
dispatch (CAD)
system.
2013-05-27T
15:53:51-0700
Incident time is calculated using this value.
Formatted with ISO 8601
cl_data.occ_time Time when the call
was saved
StreetName Name of Street CAD Systems that do not support components address information should
leverage the StreetName to upload their
address line information.
Cl_seen_at.address or
cl_data.address
In addition to
location where the
call occurred on, an
incident response
location can be
recorded. If a
response location is
specified, then the
cl_seen_at table is
used (e.g.
cl_seen_at.address).
Otherwise, if no
response location is
present,
cl_data.address is
sent.
CustomerOrLocalit
y
San Francisco cl_seen_at.municipality
or cl_data.municipality
CAD municipality
code translation.
Longitude GPS Longitude of
the incident
location.
-122.4183 Strongly preferred to send GPS lat / long.
If GPS longitude and latitude are not
provided, Tablet Command app will do a
street lookup From address provided.
Longitude Incident Longitude
Latitude GPS Latitude of
the incident
location.
37.7750 Strongly preferred to send GPS lat / long.
If GPS longitude and latitude are not
provided, Tablet Command app will do a
street lookup from address provided.
Latitude Incident Latitude
147
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 68
X X value for State
Plane coord
6143341 cl_seen_at.x_coordinat
e or
cl_data.x_coordinate
Incident X
coordinate based on
StatePlane
coordinates.
Y Y value for State
Plane coord
1957575 cl_seen_at.y_coordinat
e or
cl_data.y_coordinate
Incident Y
coordinate based on
StatePlane
coordinates.
StatePlane State Plane name NAD_1983_StatePlane_California_III_FIPS_04 03_Feet
Hardcoded “NAD_1983_StatePl
ane_California_III_FI
PS_0403_Feet“
Unit array list of units see unit data
dictionary
below
see Unit data dictionary below
Comment array list of
comments and/or
notes
see comment
data dictionary
below
see comment data dictionary below
CrossStreet1 Closest cross
street to incident
address.
Main Street Presented to the user at the incident
overview screen.
Address_history.cross_
street
Combined cross
street 1 and 2.
Example: “NE street
1 & street 2”
CrossStreet2 2nd closest cross
street to incident
location.
Someother
Street
Presented to the user at the incident
overview screen.
Unavailable
ClosedDateTime Time the incident
was closed or
archived.
2013-05-27T
15:53:51-0700
We use closed date/time to indicate that that
incident was closed and does not need to be
displayed anymore.
In case your cad system does not provide a
closed date time, please set this field to a
cl_data.clear_time
148
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 69
timestamp that is in the future, that is as far
(long) as you want the incident to remain
open (for example 30 minutes).
AgencyIncidentCall
TypeDescription
Agency
description of the
incident type.
This is displayed to the user and should be
identical to what the user or dispatcher sees
for type of call.
cl_data.call_type Translation of the
CAD call type code.
TBMap Thomas Brothers
Map Page in
format “261J6"
(map page + grid
coordinates).
261J6 cl_seen_at.district or
cl_data. district
FireMap FireMap is the
local agencies
unique agency
map page.
1234 This can be used with an agency configurable
base URL to open a custom URL scheme
within iOS. An example, would be providing a
map page file number that can be looked up
in another PDF management application e.g.
GoodReader.
cl_seen_at.response_n
o or
cl_data.response_no
DistrictNumber District number
can be utilized to
send a District
Number with the
incident.
4242 Text or numbers cl_seen_at.district or
cl_data. district
StreetNumber Number related
to physical
address on the
street.
321 Sending entire
address in single
‘StreetName’ field
above.
Predirectional N Sending entire
address in single
‘StreetName’ field
above.
149
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 70
StreetSuffix Sending entire
address in single
‘StreetName’ field
above.
Postdirectional Sending entire
address in single
‘StreetName’ field
above.
Suite Suite or
apartment of
building
321 cl_seen_at.apt_no
or
cl_data.apt_no
Apartment number
of incident location,
if available.
CallReceivedDateTi
me
Already being sent
as ‘EntryDateTime’
fieild above.
CommandName Command name
of the incident if
provided by CAD.
Main Street
Command
Unavailable.
TacticalChannel Tactical channel
assigned if
provided by the
CAD.
TAC1 cl_data.tactical_channe
l
CommandChannel Command radio
channel
assignment if
provided by the
CAD.
CMD4 Unavailable
LocationComment Common name of
the location
Rialto Tower cl_seen_at.place_na
me
150
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 71
Units
TC Key TC Description TC Example TC Note Versaterm CAD data field Versaterm Notes/Attributes
UnitDispatchNum
ber
Identification
number or key
value associated
with a dispatched
unit.
This number should remain the same for all
updates for this unit. If the unit clears the
incident and is subsequently dispatched
again to the same incident a new number
should be assigned.
app_stat.app_id Used as key in Tablet
Command.
UnitID This is the unit
identification
number of the
resource assigned
to the incident.
For Example: “E1"
or “PM255" would
E1 app_stat.app_id Unit identification
number.
or
cl_data.place_name
Building Building number
of a large
apartment
complex
B This can be letters or numbers Unavailable
Floor Floor number of a
large apartment
complex
12 This can be letters or numbers Unavailable
151
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 72
be Engine 1 or
Paramedic 255.
TimeArrived Arrival time of the
unit.
2013-07-
01T13:19:04-
0700
fdp_data.at_scene_time
TimeCleared Time the unit
cleared the
incident.
2013-07-
01T13:19:04-
0700
Fdp_data.inservice_time
or
fdp_data. returning_time
The greater value is
sent.
For example, if
returning time is past
the in service time,
the returning time is
sent to TC.
TimeDispatched Time the unit is
dispatched or
assigned to the
incident.
2013-07-
01T13:19:04-
0700
fdp_data.dispatch_time
TimeEnroute Time unit is
responding to the
incident.
2013-07-
01T13:19:04-
0700
fdp_data.enroute_time
TimeStaged Time the unit is
staged for the
incident.
2013-07-
01T13:19:04-
0700
This may not be provided by the CAD. Status_times.status_time Based on staging status code configured
in CAD.
152
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 73
TimePatient Time the unit calls
At Patient.
2013-07-
01T13:19:04-
0700
This may not be provided by the CAD. Unavailable
TimeTransporting Time the unit starts
a transport.
2013-07-
01T13:19:04-
0700
Fdp_data. transport_time
TimeAtHospital Time the unit
arrives at an ED.
2013-07-
01T13:19:04-
0700
Unavailable
Personnel Array of assigned
personnel.
Count and order will be respected by Tablet
Command. If two personnel are sent, the unit
count will be updated to 2 from its default
value.
The order in which the personnel are sent in
the array is the order in which Tablet
Command will display the personnel. e.g. if
Captain, Engineer, and Firefighter are sent in
that order of personnel then Tablet
Command will respect that.
Personnel
TC Key TC Description TC Example TC Note Versaterm CAD data field Versaterm Notes/Attributes
153
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 74
PersonnelID Personnel
ID associated with
person assigned.
1234 App_personnel.personnel
_no
ID of responder
PersonnelRank Rank which person
is assigned to unit.
Firefighter This is how the user will be displayed on the unit when the unit is inspected.
Unavailable
PersonnelName Name of person
assigned to unit.
Smith, John App_personnel.translatio
n
Name of responder.
PersonnelWorkCo
de
Work code of
person assigned to
this unit.
TradeOn Optional Unavailable
PersonnelNote Note that may
come from staffing
software or other.
Replacing
James
Optional Unavailable
Dispatch Notes or Comments
TC Key TC Description TC Example TC Note Versaterm CAD data field Versaterm Notes/Attributes
Comment Note by
dispatcher or CAD
Multiple
callers.
Cl_remarks.remarks Comments added in
CAD.
CommentSource Type of note or
comment.
Unit Hardcoded “Remarks” or “Special
Services”
154
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 75
Options are:
Dispatcher,
Caution, Unit,
Other.
CommentDateTim
e
Time the
comment was
entered.
2013-07-
01T13:19:04-
0700
cl_remarks.last_update_d
ate
Date of comment
added to CAD.
155
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 76
1.1.7. Business Continuity/Interface Availability
The interface can be made available on all servers (production, test, and training and any redundant and/or disaster recovery) within the CAD environment provided network connectivity is available from vCAD server environment to Tablet Command.
Note that to function in environments other than production, we assume the Customer will interface to the equivalent Tablet Command system (test, etc.)
1.1.8. Interface Testing
These tests are intended to ensure the interface is completely functional as designed. Below are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
This test consists of dispatching an apparatus to a call on CAD and making sure that call information and apparatus information are sent to Tablet Command. This test will also ensure that once the call is cleared on CAD, it is also cleared on Tablet Command.
OPERATIONAL TESTS
This test ensures the connectivity is re-established and data is transferred from vCAD to Tablet Command after vCAD system is re-started.
PERFORMANCE TESTS
The performance tests will consist of ensuring that call and unit information are sent to Tablet Command within 2 seconds of unit being dispatched. Time delays introduced by the Tablet Command system, or the network are not included in any time measurements.
EXCEPTION TESTING
The exception testing consists of disconnecting the network link between vCAD and Tablet Command and after reconnecting, ensure vCAD is able to re-establish its connection to Tablet Command RESTful API.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
1.1.9. Responsibilities
CUSTOMER RESPONSIBILITIES
a. Coordinate with Tablet Command technical staff to assist in the interface development and testing.
b. Configure network access to allow communications between the CAD and Tablet Command API. 156
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 77
c. Provide a test facility for this interface.
d. Assist Versaterm as required as they perform the initial integration testing. e. Review the results from Versaterm’s initial integration testing. f. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Install and configure the interface.
b. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
2.1. TRANSFER OF UPDATED INCIDENT AND RELATED UNIT INFORMATION This interface accepts unit status changes, call remarks, station moves and apparatus busy codes initiated from the Tablet Command system into the Versaterm CAD.
2.1.1. Process Flow
The Tablet Command system will initiate transactions to publish unit status changes, call remarks, apparatus station moves and apparatus busy codes to the Versaterm CAD. When Tablet Command initiates the transaction, data is sent to vCAD API installed on the on-premise Windows appliance. vCAD API will forward the transaction to the appropriate VMC (Versaterm Message Controller) plug- in, which forwards the transaction to vCAD.
The following diagram illustrated the data flow from Tablet Command to vCAD.
2.1.2. Supported Transactions
The following transactions are supported by the interface:
• Unit Status Changes (Enroute, Onscene, etc.)
• Call Remarks
• Station Moves
• Apparatus Busy Codes (Activity codes)
This interface requires that the provided unit IDs, station IDs, status codes and activity codes be valid values/codes within the Versaterm CAD system. That is, the interface will not perform data mapping to map external values to the values configured within the CAD system.
2.1.3. Configuration
157
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 78
Configuration Screen or File Configuration Setting Possible Values Recommended Setting /Comments C:\ProgramFiles
(x86)\vCAD_API_3.1\ConfigFiles\VmcConfig.vcfg
Enabled True
TargetHost VMC server host name
ListenPort TBD
appsettings.json LogLevel TBD
AllowedHosts TBD
Authentication
(Username/Password)
TBD
HttpsInlineCertFile Specifies the path to an SSL certificate in PFX format
SocketForwarderSettings
(Hostname)
localhost
SocketForwarderSettings
(Port)
the port that the API will use to connect to
AVLServer on and forward transactions
SocketForwarderSettings
(Timeout)
5 AVIF.exe Properties Run this program as an
administrator
Yes
LogConfig.xml Configuration settings related to logging VMC Plug-in Configuration Type OTHER
Enabled Y
VMC Process Input Input
VMC Process Output Output
Timeout 120
Message Timeout 60
Message # of re-send
attempts
3 Read Timeout 60
Expects EOT N
Throttle 2
Expects broadcasts N
Max Length 99999
2.1.4. Data Format Requirements
The web service transactions initiated from Tablet Command conform to JSON standards as defined in the vCAD Connector API and SDK Document Version 1.0 and the corresponding vCAD- connector.yaml file.
2.1.5. Communication
The Versaterm API is installed on a virtual Windows VM server and accepts requests from the Tablet Command System. Requests made to the Versaterm API are handled immediately (synchronously) and forwarded to the Versaterm VMC for processing.
The communication between Tablet Command and the Versaterm API is via JSON Web services using HTTPS protocol. The web services are defined in the vCAD Connector API and SDK Document Version 1.0 and the corresponding vCAD-connector.yaml file.
2.1.6. Authentication
158
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 79
Versaterm will provide Tablet Command with username and password to be used with HTTP basic authentication on the RESTful request by providing base64 encoded username and password.
2.1.7. Business Continuity/Interface Availability
The interface can be made available on all servers (production, test, and training and any redundant and/or disaster recovery) within the CAD environment provided network connectivity is available from vCAD server environment to Tablet Command.
Note that to function in environments other than production, we assume the Customer will interface to the equivalent Tablet Command system (test, etc.) Additional Windows appliances would be required to support this interface in multiple environments.
2.1.8. Interface Testing
These tests are intended to ensure the interface is completely functional as designed. Below are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
This test consists of updating unit status, adding remarks to a call, performing a move-up and placing an apparatus on a Busy Code in Tablet Command and ensuring that the updates are displayed on vCAD.
OPERATIONAL TESTS
This test ensures the connectivity between Tablet Command and vCAD APIs is re-established and data is transferred from Tablet Command to vCAD after vCAD system is re-started.
PERFORMANCE TESTS
The performance tests will consist of ensuring that unit status changes are displayed on vCAD within 2 seconds after being made on Tablet Command.
Time delays introduced by the Tablet Command system, or the network are not included in any time measurements.
EXCEPTION TESTING
The exception testing consists of disconnecting the network link between vCAD and Tablet Command APIs and after reconnecting, ensure Tablet Command is able to re-establish its connection to vCAD API.
DATA INTEGRITY TESTING
It is the responsibility of the Customer and the RPAs to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
2.1.9. Responsibilities
CUSTOMER RESPONSIBILITIES
159
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 80
a. Coordinate with Tablet Command technical staff to assist in the interface development and testing.
b. Provide a virtual Windows server to host the Versaterm API. c. Provide remote access to the Windows server to Versaterm staff for installation and ongoing support purposes.
d. Configure network access to allow communications between the VMC, the Windows server and Tablet Command.
e. Ensure unit/station IDs, status codes and activity codes configured in the Tablet Command system match the corresponding values configured in the Versaterm CAD system. f. Configure network access to allow communications between the Tablet Command system and the Versaterm API.
g. Provide a test facility for this interface.
h. Assist Versaterm as required as they perform the initial integration testing. i. Review the results from Versaterm’s initial integration testing. j. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Install and configure the interface.
b. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
3.1. REAL-TIME UNIT STATUS AND GPS DATA
This interface provides the ability for the Tablet Command system to receive unit status and GPS data from the Versaterm vMonitor BSS REST API.
3.1.1. Process Flow
The vCAD publishes all active call and unit status information to the vMonitor (BSS) database in real time. This interface uses a Restful API hosted on the Versaterm server called from the Tablet Command application allowing Tablet Command to pull active CAD data into the Tablet Command server. The Tablet Command application is configured to pull CAD data in BSS at no less than 5- second intervals.
3.1.2. Configuration
This section is not applicable to the interface.
160
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 81
3.1.3. Data Format Requirements
The RESTful transactions conform to JSON standards as defined in the vMonitor BSS REST API document.
3.1.4. Communication
The communication between Tablet Command Connect application and the BSS will be through a Restful API following the Versaterm vMonitor BSS REST API SDK.
3.1.5. Authentication
Versaterm will provide Customer ID and secret to Tablet Command. When Tablet Command Customer connects to vMonitor API, the Customer ID and secret will be verified against a file stored on the CAD server. If the Customer is verified successfully, an API token will be returned to Tablet Command.
3.1.6. Business Continuity/Interface Availability
The interface can be made available on all servers (production, test and training and any redundant and/or disaster recovery) within the CAD environment provided network connectivity is available from vCAD server environment to Tablet Command.
Note that to function in environments other than production, we assume the Customer will interface to the equivalent Tablet Command system (test, etc.)
3.1.7. Interface Testing
These tests are intended to ensure the interface is completely functional as designed. Below are descriptions of the tests to be performed for the specified interface functionality during the functional acceptance test period.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that the BSS database is populated with active call and unit status information.
OPERATIONAL TESTS
This test ensures the Tablet Command application is able to reconnect to the Restful API and pull data after system reboots. The BSS server will be shutdown/re-started and ensure BSS services are started as well as communications between Tablet Command to the Restful API is established.
PERFORMANCE TESTS
The performance tests will consist of ensuring that updates to active calls and unit status changes performed within CAD are published to the BSS database within 2 seconds. Excluded from any measurement is network time (e.g. network between CAD and BSS).
EXCEPTION TESTING
161
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 82
The exception testing consists of disconnecting the network link between Tablet Command and vCAD and after reconnecting, ensure Tablet Command is able to re-establish connection to BSS API.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
3.1.8. Responsibilities
CUSTOMER RESPONSIBILITIES
a. Provide network connectivity between Tablet Command and the BSS server. b. Coordinate with Tablet Command technical authorities to assist in the interface configuration and testing.
c. Assist Versaterm as required as they perform the initial integration testing. d. Review the results from Versaterm’s initial integration testing. e. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Provide the Customer with the Versaterm vMonitor BSS REST API SDK. b. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
FUSUS (VMONITOR API INTERFACE)
INTERFACE SCOPE
This interface provides real-time incident and unit status information for consumption by 3 rd party systems (Fusus).
PROCESS FLOW
The Versaterm Computer Aided Dispatch (CAD) publishes active call, unit status, and AVL information to the Versaterm Monitor (vMonitor) Postgres database in real time. This interface provides a Restful based API hosted on the vMonitor server allowing analysts or 3 rd party systems to pull data from the vMonitor Postgres database. The vMonitor API is configured to limit requests at a frequency of no less than five (5) second intervals.
162
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 83
DATA FORMAT REQUIREMENTS
The data will conform to the Versaterm API specifications (bss_rest_api_dox.docx Edition 1.0.0) the Customer is responsible to map the data elements to the 3rd party system (Fusus).
COMMUNICATION
The communication to the vMonitor API is provided via RESTFUL web services using HTTPS protocol.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface can be made available, or not, from the production, training, and test environments provided network access to the vMonitor API is available.
INTERFACE TESTING
These tests are intended to ensure the interface is functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
These tests ensure that the vMonitor database is populated with active call and unit status information. a) Create a call and verify that the call exists in the vMonitor database. b) Dispatch one or more units to a call and verify that the updated information is published to the vMonitor database.
c) Change the status of a dispatched unit (e.g. Enroute, Onscene) and verify that the updated information is published to the vMonitor database
OPERATIONAL TESTS
This test ensures the Fusus application is able to reconnect to the vMonitor API and pull data after system reboots. The vMonitor server will be shutdown/re-started and ensure vMonitor services are started as well as communications between Fusus and the vMonitor API is established. This test ensures the vMonitor API is available after system reboots. 163
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 84
a) Restart the CAD application server and ensure connectivity to the vMonitor API can be established.
PERFORMANCE TESTS
This test ensures the data from CAD is published to the vMonitor API within 2 seconds. Excluded from any measurement are any time delays introduced by the network. a) Add a call and measure the number of seconds between call creation until the information is available from the vMonitor API.
EXCEPTION TESTS
These tests ensure the interface responds as expected when connectivity between the CAD application server and the destination system is disconnected, and reconnected. a) Disconnecting the network link between the CAD application server and the system requesting the data. Reconnect the network link between and ensure the 3rd party system is able to reestablish a connection to the vMonitor API.
DATA INTEGRITY TESTS
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a) Configure network access to allow communications between the vMonitor server and the system requesting the data.
b) Develop or coordinate in the interface development and testing. c) Assist Versaterm as required as they perform the initial integration testing. d) Review the results from Versaterm’s initial integration testing and provide written acceptance of the tests.
e) Perform integration testing as described in the Interface Testing section above.
VERSATERM RESPONSIBILITIES
a) Provide the Customer with the vMonitor BESS REST API and SDK Documentation. b) Enable the API.
c) Provide the Customer with an API key and Customer code for the interface. d) Provide assistance and guidance in the development and testing process. e) Perform initial integration testing as described in the Interface Testing section above and provide test results to the Customer.
f) Provide assistance to the Customer as they perform integration testing.
ALARM PROGRAM SYSTEMS INTERFACE
164
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 85
INTERFACE SCOPE
The interface provides connectivity between the Customer Alarm Permit System (APS) and the Versaterm Computer Aided Dispatch (CAD) System.
This interface contains 2 distinct interface touch points:
1) Import of Alarm Permits from the alarm permit system into the Computer Aided Dispatch (vCAD) system.
2) Transfer of alarm-related calls-for-service to the Alarm systems (for management and billing purposes).
PROCESS FLOW
Alarm Permits Import
Once per day, the Customer alarm system provides alarm permit transaction files. Each morning, a scheduled task (cron) on the CAD server (alarm_ftp.sh) is executed to transfer, using SFTP, the alarm permit data files from a ‘Customer’ share on the FTP server to the CAD server and invokes the Versadex Alarm Upload process.
The Alarm Upload process consists of an alarm upload API provided by Versaterm (4GL software program). This program will upload permitted alarm data including an alarm subscriber along with an optional alarm company and alarm contact information into the Versadex CAD.
A results file is produced indicating if a record failed or if a warning is produced (e.g. a record is loaded with an invalid address). If a record already exists for the permit number, it is updated regardless of the action code (add or update).
The results file is placed back to the originating FTP server. If no errors and warnings are encountered, the file will be empty.
Alarm Permits Transaction File
The file names for the Alarm Permits Transaction files from Customer alarm system are con_phone, alarm_co and alarm_sub.
Once the SFTP transfer of the files to the CAD server is complete, the originating files on the FTP servers are renamed to *.processed.YYYYMMDD. It is the Customer’s responsibility to archive the old files as required.
165
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 86
Layout - Alarm Permits Transaction File
The alarm upload program uses alarm permit input files provided by Customer alarm system to update tables in the CAD database. The following table lists the required input files, the CAD table that each file updates, and the type of information managed by each.
Input file CAD table Type of information
alarm_co alarm_company
Contains information about alarm companies, including
address and contacts. Leave this file blank if the Alarm Companies will be maintained from within CAD and not
from the interface.
alarm_sub al_data Contains information about alarm subscribers con_phone con_phone Contains subscriber contact information
The input files must be in ASCII pipe-delimited ( | ) format. The input files must follow the layout specified in the Alarm Permits Input File Layout section. If there is no data in an input file, a blank file with the proper file name must still be provided for the alarm upload program to run properly.
When the alarm upload program runs, it checks the directory for the necessary input files. If any files are missing, or there are any problems with the upload, the upload program aborts, and an alarm API exception report is generated. The file naming convention for the exception file is exception.yyyymmdd.
If all three input files are available, the alarm upload program updates the CAD alarm tables. The alarm_company table is updated first. The existing content of the alarm_company table is deleted and replaced by data from the alarm_co input file. If the alarm_co file is blank, the contents of the alarm_company table are not deleted. If a certain number of records are rejected, the upload program logs an error to alarm_upd.log and reverts to the original alarm_company table content. Records are rejected if they are missing mandatory information.
The al_data table is updated using the alarm_sub file which consists of alarm subscriber information. This file must have a transaction flag at the beginning of each record. The valid transaction flags are:
▪ A to add the subscriber record
▪ D to delete the subscriber record as well as its contacts ▪ M to modify the subscriber record.
If the transaction flag for a subscriber record is set to A or M, the system verifies that the alarm company code for the record exists in the alarm_company table. If the alarm company does not exist in the alarm_company table, the record is rejected, and an error is logged in alarm_upd.log. If the alarm company is listed in the alarm_company table, the upload program checks the al_data table for an entry with a matching alarm number. Depending on how the site is configured, the upload program could instead use a combination of the alarm number and the alarm company code.
If a matching entry exists, the record is updated. If no matching entry exists, the record is added. Subscriber addresses are verified against existing street names and street ranges. If an invalid address is detected, the record is added, and a message is logged in alarm_upd.log indicating that the address should be reviewed.
166
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 87
To update the con_phone table, the upload program uses the con_phone input file consisting of alarm contact information and verifies that the alarm number is valid. If there is a matching subscriber, the program deletes all entries in the con_phone table for the subscriber and inserts the new contact information. If no matching subscriber is found, a message is logged in alarm_upd.log and the record is rejected.
The con_phone input file must contain all of the contacts for a subscriber, even if the information for a contact has not changed. If one contact is added or changed, all of the contact information for that subscriber must be included in the input file. To remove one of the contacts for a subscriber, you must remove that contact from the file but still include the remaining contacts for the subscriber.
Alarm Permits Input File Layout
The following tables describe the file layout required for each input file. All input files must be supplied in pipe (‘|’) delimited ASCII format.
alarm_co file layout
Field name Data type Mandatory/Optional1 Description
company_code Alpha(3) M Company code
company_type Alpha(1) M Company type code2 (for example, A – alarm installer)
company_name Alpha(40) M Alarm company business name
Address Alpha(75) M Company business address
Zip Alpha(10) O Company address zip code
area_code Alpha(3) NA Company location area code (*This field is no longer used*)
phone_area_code Alpha(3) O Company phone area code
Telephone Alpha(8) O Company phone number
fax_area Alpha(3) O Company fax area code
fax_phone Alpha(8) O Company fax number
contact_type1 Alpha(1) O Contact type code of first company contact 3 (for example, M – manager)
contact1 Alpha(30) O Name of first company contact
phone_type1 Alpha(2) O Phone type code of first company contact 4 (for example, P – pager)
area_code1 Alpha(3) O Phone area code of first company contact phone1 Alpha(8) O Phone number of first company contact extension1 Alpha(6) O Extension number of first company contact contact_type2 Alpha(1) O Contact type of second company contact 3 (for example, M – manager)
contact2 Alpha(30) O Name of second company contact
167
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 88
phone_type2 Alpha(2) O Phone type code of second company contact4 (for example, P – pager)
area_code2 Alpha(3) O Phone area code of second company contact
phone2 Alpha(8) O Phone number of second company contact extension2 Alpha(6) O Extension number of second company contact
contact_type3 Alpha(1) O Contact type code of third company contact 3 (for example, M – manager)
contact3 Alpha(30) O Name of third company contact
phone_type3 Alpha(2) O Phone type code of third company contact 4 (for example, P – pager)
area_code3 Alpha(3) O Phone area code of third company contact phone3 Alpha(8) O Phone number of third company contact extension3 Alpha(6) O Extension number of second company contact
Customer Alpha(15) O Customer for company business address Province/State Alpha(4) O Province or State for company business address
Notes:
1 If you cannot provide information for an optional field, leave the field position blank to maintain the fixed number of fields within each record. You must specify a value for a mandatory field. 2 Must match a value in company_type table in CAD database. 3 Must match a value in contact_type table in CAD database. 4 Must match a value in phone_type table in CAD database.
Sample record:
003|A|BL ALARM MONITORING CO.|123 KING ST|K1K0C8|613|613|8313482|613| 2231434|M|JOHN BRUCE|C|613|5890129|26|M|DALE LENNER|C|613|5789273|27|G|ROB MITCHELL|C|613|2382398|28|OTTAWA|ON|
alarm_sub file layout
Field Name Field Type Mandatory/Optional1 Description Transaction Alpha(1) M Type of transaction (A for add, M for modify, or D for delete)
168
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 89
Jurisdiction Alpha(2) M Jurisdiction (leave blank spaces if not multi- jurisdictional)
alarm_num Alpha(10) M Permit number
company_code Alpha(3) M Related alarm company code
alarm_type Alpha(1) O Alarm type code 2 (for example, A – audible security)
alarm_case_type Alpha(6) M Related alarm case type3
work_hours Alpha(75) O If the subscriber is a business, the hours it is open location_type Alpha(2) O Location type code 4 (for example, RS – residence)
assoc_company Alpha(3) O Associated alarm company code (for example, installer)
Location Alpha(40) M Location alarm is installed
Apartment Alpha(10) O Apartment/unit number alarm is installed municipality Alpha(4) M Municipality code for location
mail_addr Alpha(75) O Mailing address
Customer Alpha(15) O Customer
Province Alpha(4) O Province
postal_code Alpha(10) O Postal code
County Alpha(2) O County code for location
District Alpha(6) O District code for location
Zone Alpha(6) O Police zone/beat for location
Grid Alpha(6) O Grid or quadrant for location
X_coord Integer O X coordinate (long)
Y_coord Integer O Y coordinate (long)
Remarks Alpha(300) O Associated remarks for a permitted alarm comp_name Alpha(40) O Alarm owner surname
comp_first Alpha(20) O Owner first name
comp_middle Alpha(20) O Owner middle name
comp_phone_type Alpha(2) O Owner phone type code5 (for example, P – pager) comp_area_code Alpha(3) O Owner phone number area code
comp_telephone Alpha(8) O Owner phone number
comp_bus_ptype Alpha(2) O Owner business phone type code5 (for example, P – pager)
comp_bus_area Alpha(3) O Owner business phone number area code 169
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 90
comp_bus_tele Alpha(8) O Owner business phone number
comp_bus_ext Alpha(6) O Owner business phone number extension comp_bus2_ptype Alpha(2) O Owner business phone type code5 (for example, P – pager)
comp_bus2_area Alpha(3) O Owner business phone number area code comp_bus2_tele Alpha(8) O Owner business phone number
comp_bus2_ext Alpha(6) O Owner business phone number extension comp_fax_area Alpha(3) O Owner fax/business phone number area code comp_fax_phone Alpha(8) O Owner fax/business phone number penalty_status Alpha(6) O Current alarm penalty status (agency use) downgrade_priority Smallint O Current downgraded dispatch priority downgrade_date Date O Date dispatch priority downgraded (mm/dd/yyyy) until_date Date O Date downgrade period ends (mm/dd/yyyy) permit_expiry_date Date O Date alarm permit expires (mm/dd/yyyy) permit_review_date Date O Date alarm permit is to be renewed (mm/dd/yyyy) last_update Date O Date record was last updated
op_code Alpha(6) O Operator code of last person to update record op_jurs Alpha(2) M Jurisdiction of person who last updated record cad_owner Alpha(1) M Ownership of the alarm (Police, Fire or Both) cad_access Alpha(1) M Users from which system can access alarm (Police, Fire or Both)
Dispatch Alpha(1) O Dispatch flag (Should a dispatch occur for this subscriber?)
Notes:
1 If you cannot provide information for an optional field, leave the field position blank to maintain the fixed number of fields within each record. You must specify a value for a mandatory field. 2 Must match a value in alarm_type table in CAD database. 3 Must match a value in case_type table in CAD database. 4 Must match a value in location_type table in CAD database. 5 Must match a value in phone_type table in CAD database.
Sample record:
A|PP|1289234970|003|A|3401|MONDAY THROUGH FRIDAY 9AM-5PM, SATURDAY & SUNDAY 9AM- 2PM|IN|BB|601 DUNDAS ST|14A|1|1298 RIVER DRIVE|OTTAWA|
ONTARIO|K2K0T6|12|15|976|987|8|9|THIS LOCATION HAS MULTIPLE ENTRY POINTS. THE 170
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 91
SECURITY GUARD IS TO PERFORM UNSCHEDULED INSPECTIONS BUT HAS A PAGER THAT ALERTS HIM IF SOMEONE TRIES TO CONTACT HIM|KELLY|BOB|L| P|613|4442387|P|613|4192837|125|P|613|8272834|122|613|7623784|SUSPEND|9|01/12/2002| 02/12/2002|03/12/2002|03/01/2002|01/01/2002|888B|SL|P|B|Y|
con_phone file layout
Field name Field type Mandatory/
Optional1 Description
alarm_number Alpha(10) M Permit number
alarm_company Alpha(3) M Related alarm company code
Jurisdiction Alpha(2) M Jurisdiction (Blank if site is not multi- jurisdictional)
contact_type Alpha(1) O Contact type code2 (for example, M – manager) contact_name Alpha(30) O Contact name
work_phone_type Alpha(2) O Contact work phone type code3 (for example P – pager)
work_area_code Alpha(3) O Contact work area code
work_phone Alpha(8) O Contact work phone number
work_ext Alpha(6) O Contact work extension number
home_area_code Alpha(3) O Contact home area code
home_phone Alpha(8) O Contact home phone number
Notes:
1 If you cannot provide information for an optional field, leave the field position blank to maintain the fixed number of fields within each record. You must specify a value for a mandatory field. 2 Must match a value in contact_type table in CAD database. 3 Must match a value in phone_type table in CAD database.
Sample record:
1237198302|003|PP|M|JEFF RUSH|C|613|8762973|126|613|984991 Results file for the Import of Alarm Permits data
The following describes the results file sent to the source system. Note that the field layout is fixed length and will only contain exceptions. That is, Versadex does not generate a success message but only when there is a problem with the data.
The file naming convention for the results file is exception.yyyymmdd.
171
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 92
Field Name Data Type (M)andatory/
(O)ptional
1 Alarm Permit
Number
Char(7) M
2 Result Message Char(72) M
Scheduled task (cron) for the Import of Alarm Permit data The following is the cron entry installed on the CAD server, scheduled to run at 0300, that is responsible for transferring and processing the Customer alarm permit data. 0 3 * * * ( SETUPFILE=; export SETUPFILE; ${VTMSCRIPTDIR:-/usr/local}/bin/VTMcron CADSVC \\\${RUNTIME}/scripts/alarm_ftp.sh CoT_alarm_config.xml pdxftp CoT-APS CoT-APS \\\${ALARMIN} \\\’\\\’ exception \\\${ALARMOUT} load_alarm mcs 121 )
Alarm Calls-for-Service Transfer
The transfer consists of unloading police calls-for-service with an initial call type identifying it as alarm. A scheduled task (cron) on the CAD server (alarm_ftp.sh) is executed once per day (at 5 AM, 0500) where it searches for all alarm-related calls for service for the previous day and unloads them into the individual files, as specified in the appropriate file layout (described below). Note that the jurisdictions and call type codes are configured in the configuration file and can be modified as required. See section titled ‘Configuration File’ for details.
Alarm Calls for Service file layout
The following describes the alarm-related CFS file layout. The file naming convention for the file sent to Customer APS is CoT_YYMMDD.DAT.
Field Name Field Type Description
jurisdiction Alpha(2) Agency/jurisdiction
rin Alpha(15) Call internal ID number
172
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 93
occ_num Integer Call number
occ_date Date/Time Call date/time
date_added Date Date call added
queued_type Alpha(1) Queue type
time_queued Date/Time Date/Time call queued
case_type Alpha(6) Initial call type
place_name Alpha(50) Call address place name address Alpha(75) Call address
apt_no Alpha(10) Address apartment/suite number
ring_code Alpha(10) Address/building ring code phone_type Alpha(2) Phone type code (cell, pager, etc.)
area_code Alpha(4) Telephone area code
telephone Alpha(8) Telephone number
company_code Alpha(3) Alarm company code
alarm_no Alpha(10) Alarm number
priority Integer Call priority
zone Alpha(6) Call zone (patrol zone)
grid Alpha(6) GIS Grid
municipality Alpha(10) Customer/municipality code county Alpha(2) County code
district Alpha(6) GIS District
x_coordinate Integer X coordinate
y_coordinate Integer Y coordinate
how_received Alpha(1) Call received code
comp_name Alpha(40) Caller last name
comp_first Alpha(20) Caller first name
comp_middle Alpha(20) Caller middle name
comp_phone_type Alpha(2) Caller telephone type code comp_area_code Alpha(3) Caller telephone area code comp_telephone Alpha(8) Caller telephone number
comp_address Alpha(75) Caller address
173
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 94
comp_apt_no Alpha(10) Caller address apartment/suite number
comp_bus_ptype Alpha(2) Caller business phone type code
comp_bus_area Alpha(3) Caller business telephone area code
comp_bus_tele Alpha(8) Caller business telephone number
comp_bus_ext Alpha(6) Caller business telephone extension
last_update_date Date/Time Date/time call last updated final_case_type Alpha(6) Final call type
time_received Date/Time Date/time call received dispatch_time Date/Time Date/time call Dispatched enroute_time Date/Time Date/time first unit En Route at_scene_time Date/Time Date/time first unit At Scene clear_time Date/Time Date/time call cleared
call_taker_desk Alpha(6) Call taker position
call_taker_id Alpha(6) Call taker ID
report_flag Alpha(1) Offense report required (Y/N) reporting_officer Alpha(6) 1st reporting officer ID reporting_officer2 Alpha(6) 2nd reporting officer ID case_status Alpha(1) Call status
cc_relation Alpha(1) Related call indicator
cleared_by Alpha(79) How cleared dispo code
cleared_desk_id Alpha(6) Clearance desk position
cleared_op_code Alpha(6) Clearance operator ID
clear_remarks Alpha(124) Clearance remarks
total_dispatches Integer Number of dispatched units total_entities Integer Number of related entities total_supplements Integer Number of supplemental
total_followups Integer Number of follow ups
initial_remarks Alpha(355) Initial call remarks
Scheduled task (cron) for the Alarm Calls for Service Transfer 174
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 95
The following is the cron entry installed on the CAD server, scheduled to run at 0500, that is responsible for unloading alarm calls and transferring them to the Customer FTP site. 0 5 * * * ( SETUPFILE=; export SETUPFILE; ${VTMSCRIPTDIR:-/usr/local}/bin/VTMcron CADSVC \\\${RUNTIME}/scripts/alarm_ftp.sh MCS_alarm_config.xml pdxftp CoT-APS CoT-APS \\\${ALARMOUT} null MCS \\\${ALARMOUT} unload_call mcs 121 )
CONFIGURATION
There will be one configuration file for each source system. The configuration file for the Customer Alarm System is called $VDXFILES/etc/MCS_alarm_config.xml) and contains various settings and defaults used by this interface.
The configuration contains the following settings:
Setting Description Used by
Alarm
Permits
Import
Used by
Alarm
Calls-for-
Service
Transfer
Initial value for MCS
company_code Contains the default
alarm company code
that will be used if
the company code
provided in the
Alarm Permits
Transaction file does
not exist in CAD.
Yes 191
infile_format File name for the
incoming Alarm
Permits Transaction
file
Yes mcs-alarm.txt
outfile_format File name for the
Alarm-Calls-for-
Service output file
Yes MCS_YYMMDD.DAT
error_log_content This setting is used
by the Alarm API
process. The alarm
API can be used to
load Alarm
Companies; Alarm
Permits and Contact
names. The first
digit of this field
indicates if errors are
to be generated for
the loading of Alarm
Companies, the
second digit
Yes 010
175
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 96
indicates if errors are
to be generated for
the loading of Alarm
Permits and finally
the third digit
indicates if errors are
to be generated for
Contact names.
In this particular
interface, only Alarm
Permits will be
loaded into the
system, therefore,
the value should be
set to 010.
outfile_include_single_call Indicates if the
output for the Calls-
for-Service transfer
will be contained in a
single file or a file for
each call.
0 – each alarm call-
for-service will be
contained in a single
file
1 – there will be a
separate output file
for each alarm call-
for-service
Yes 0
outfile_directory Directory on the
CAD server where
the Calls-for-Service
output files are
created. Can be an
environment
variable or a full
path.
Yes ALARMOUT
extract_format 1 – field delimited
2 – fixed length
3 – legacy
4 – XML format
Yes 3
call_added_without_alrm_num 1 - Exclude calls
added without alarm
number
Yes 0
176
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 97
0 - Include calls
added without alarm
number.
ignore_false_alarm 0 – do not include
false alarm calls
1 – include false
alarms calls
Yes 1
extract_calltypes Contains a list of call
types to be included
in the Calls-for-
service transfer
Yes ALRMA, ALRMB,
ALRMS, ALRMR,
ALRMH
extract_jurs Contains a list of
jurisdictions to be
included in the Calls-
for-service transfer
Yes PM, PG, PT
legacy_con_phone Is the con_phone file
in the legacy format
1 perform_transformation Should the incoming
alarm file be
transformed into the
required 3 files
(alarm_co,
alarm_sub,
con_phone)
0 DATA FORMAT REQUIREMENTS
Refer to Process Flow above for Data Format Requirements.
COMMUNICATION
The communication between CAD application server and the Customer FTP server is provided via password less SFTP, using server RSA public keys.
AUTHENTICATION
Not applicable for this interface.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the production server. This interface is also available from the implementation/test server by configuring the alarm system to the test folder on FTP server for transferring alarm files and monitoring for call files, where test files are sent from the implementation/test CAD application server. This interface can also be available from the disaster recovery server, providing the CAD DR application is able to communicate with the FTP server. 177
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 98
INTERFACE TESTING
These tests are intended to ensure the interface is functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that the CAD application server submits and receives the alarm data files from the Customer FTP server.
OPERATIONAL TESTS
This test ensures the CAD application server is able to communicate with the FTP server via SFTP after system reboots. The CAD application server will be shutdown/re-started and ensure CAD services are started as well as the SFTP file transfers to/from FTP server is available.
PERFORMANCE TESTS
There is no performance tests associated with this interface. The extracted CAD files are transferred to the Customer FTP server daily and processed as received.
EXCEPTION TESTS
The exception testing consists of disconnecting the networks between CAD application server and the FTP server, after reconnecting, ensure CAD application server is able to resume file transfers to the FTP server via SFTP and ensuring that files destined to the SFTP server, queued while the interface is “down”, are sent.
DATA INTEGRITY TESTS
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide a list of call-type codes that will identify that the call is alarm related. b. Provide network connectivity between the FTP server and the CAD application server. c. Coordinate with the alarm company technical staff to assist in the interface installation, configuration and testing.
d. Install and maintain the Customer FTP server for SFTP transfer. e. Assist Versaterm with server rsa public key installation on FTP server after each upgrade. f. Test the interface.
VERSATERM RESPONSIBILITIES
a. Develop, install and configure the interface.
b. Modify the Call for Service File to include the case_number. c. Install and configure Versaterm SFTP script to transfer alarm data files between FTP server and CAD application server.
178
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 99
d. With Customer assistance, copy CAD server public key to FTP server, for password less SFTP transfers from CAD server after each CAD application server upgrade. e. Provide assistance and guidance in the development and testing process.
ACCELA INTERFACE
This interface comprises two distinct interface touch points:
1) Accela Hazard Data Retrieval from vCAD
2) Address Related Information Transfer from Accela to vCAD
ACCELA HAZARD DATA RETRIEVAL FROM VCAD
The first part of this interface touch point pulls vCAD location-based hazard and caution information into Accela. This data, typically derived from responder safety flags, caution notes, or situational hazards, is associated with specific addresses and is imported into Accela to alert end-users of potential risks linked to a given location. The interface ensures that Accela users receive a high-level notification regarding the hazard. Should additional context or detail be required, users can contract the Communications Center for further details.
The second aspect of this interface touch point is to provide information from building and fire inspections along with pre-fire plan walkthroughs to CAD users and emergency responders for a call.
PROCESS FLOW
The first part of this interface enables Accela to retrieve location-based hazard information from the vCAD system by connecting to the reporting database designed for integrations and analytics.
The data retrieval process is initiated by the Accela system on a scheduled basis, using read-only access.
It is the responsibility of the Accela system to structure its queries to retrieve only the hazard categories relevant to their use case.
The following diagram illustrates the first interface touch point, Accela Hazard Data Retrieval from vCAD:
179
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 100
The second part of this interface enables vCAD to get updated Address Related Information from Accela via an XML file that is sent to the Versaterm SFTP server on a scheduled basis to be imported into the vCAD.
The following diagram illustrates the second interface touch point, Address Related Information Transfer from Accela to vCAD :
CONFIGURATION
Configuration Description Configuration Details
User Access Credentials Versaterm will create a read-only database user account for the reporting database
Connection credentials will be securely provided to
the customer
DATA FORMAT REQUIREMENTS
Prior to development, Versaterm will provide the customer with a data dictionary containing the relevant table and field definitions for accessing hazard information from the reporting database. This documentation will support the Accela team in constructing appropriate queries for retrieving the required data.
COMMUNICATION
Accela connects to the Versaterm-hosted reporting database over a secure connection established through the customer’s internal network. Communication occurs over TCP. The port to be determined during interface implementation.
AUTHENTICATION
Access to the reporting database is authenticated using username and password credentials assigned to a read-only database user. Versaterm will generate and securely provide these credentials to the customer for use by the Accela system.
180
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 101
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the Production, Development and Training environments provided access between vCAD and Accela is available.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test consists of creating, modifying, and deleting a variety of hazard records within vCAD, some configured with hazard categories designated for transfer to Accela, and others that are not. The goal is to verify that only the appropriate records are transferred, and that the corresponding data is correctly received and available within Accela.
PERFORMANCE TESTS
There are no performance tests associated with this interface.
EXCEPTION TESTING
This test verifies that if connectivity between the Accela system and the reporting database is temporarily lost, Accela can automatically re-establish the connection and resume retrieving hazard data without manual intervention.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide network connectivity from the Accela system to the vCAD reporting database. b. Coordinate with Accela technical staff to assist in the interface development and testing. c. Assist Versaterm as required as they perform the initial integration testing. d. Review the results from Versaterm’s initial integration testing. e. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Provide database access credentials for the reporting database. b. Supply a data dictionary outlining table and field definitions. c. Provide assistance and guidance in the development and testing process. d. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
ADDRESS RELATED INFORMATION TRANSFER FROM ACCELA TO VCAD 181
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 102
This interface touch point supports the transfer of address-related information collected in Accela, such as structural risks, access limitations, or occupancy concerns, into vCAD. The goal is to ensure that public safety personnel have immediate access to critical building inspection or property risk information within the vCAD environment, enabling informed decision-making during emergency response.
PROCESS FLOW
This interface is triggered automatically as part of a scheduled nightly process.
File Delivery
The customer is responsible for generating and placing an XML file containing the new or updated address-related information into the Versaterm SFTP folder. The structure and contents of this file are documented in the “Data Format Requirements” section.
File Retrieval and Processing
On a nightly basis, the Versaterm system retrieves the XML file from the SFTP location and processes each record contained within it. Each record is geo-validated against the vCAD Street Index. Records that pass validation are inserted into the CAD Premise table, making the information available to the vCAD users.
Exception Handling
Records that fail geo-validation are logged in an exception file. The exception file is placed back onto the SFTP site for the Customer to review and take corrective action.
Nightly, an XML file is provided via SFTP for Versaterm to import into the CAD Premise table.
CONFIGURATION
Configuration Description Configuration Details
Scheduled Task The import process (ext_accela_load.42r) is configured to execute once per day
Execution time to be determined during interface
implementation.
DATA FORMAT REQUIREMENTS
The following data elements are included in the XML file. 182
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 103
Field in Accella Type Len Null
LoadID Int NOTNULL
OccupancyID int NOTNULL
ADDRESS_ID nvarchar 40 NULL
ADDRESS_NUMBER nvarchar 10 NULL
STREET_DIRECTION nvarchar 2 NULL
STREET_NAME nvarchar 40 NULL
STREET_TYPE nvarchar 10 NULL
DIRSUF nvarchar 2 NULL
ADDRESS_OTHER nvarchar 5 NULL
ADDRESS_UNIT nvarchar 6 NULL
CUSTOMER nvarchar 30 NULL
ZIP_CODE nvarchar 12 NULL
Combined_ADDRESS_UNIT_SuiteNumber varchar 10 NULL
StreetAddress varchar 100 NULL
SuiteNumber varchar 10 NULL
StreetAddressRevised varchar 150 NULL
MapNumber varchar 10 NULL
BusinessName varchar 50 NULL
BusinessManagerName varchar 36 NULL
BusinessPhone varchar 20 NULL
PropertyOwnerName varchar 36 NULL
PropertyOwnerPhone varchar 20 NULL
PropertyManagerName varchar 36 NULL
PropertyManagerPhone varchar 20 NULL
SquareFeetTotal int NULL
PropertyUse smallint NULL
PropertyUseDescription varchar 100 NULL
ConstructionType smallint NULL
ConstructionTypeDescription varchar 50 NULL
HazardOfContents varchar 20 NULL
HasSprinklers bit NULL
IsFullySprinklered bit NULL
HasStandpipes bit NULL
HasHoodSystem bit NULL
HasFireAlarm bit NULL
HasAboveGroundTanks bit NULL
HazardScore int NULL
HasFirePump bit NULL
HasKeybox bit NULL
183
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 104
HasHazMat bit NULL
IsHighRise bit NULL
FloorsAboveGrade tinyint NULL
FloorsBelowGrade tinyint NULL
ContactName01 varchar 36 NULL
ContactName02 varchar 36 NULL
ContactName03 varchar 36 NULL
ContactName04 varchar 36 NULL
ContactName05 varchar 36 NULL
ContactName06 varchar 36 NULL
ContactName07 varchar 36 NULL
ContactName08 varchar 36 NULL
ContactName09 varchar 36 NULL
ContactName10 varchar 36 NULL
ContactPhone01 varchar 20 NULL
ContactPhone02 varchar 20 NULL
ContactPhone03 varchar 20 NULL
ContactPhone04 varchar 20 NULL
ContactPhone05 varchar 20 NULL
ContactPhone06 varchar 20 NULL
ContactPhone07 varchar 20 NULL
ContactPhone08 varchar 20 NULL
ContactPhone09 varchar 20 NULL
ContactPhone10 varchar 20 NULL
PrePlanLink varchar 512 NULL
The data is provided in a single XML file using the following format. <Records>
<record>
<b1_alt_id> </b1_alt_id>
<LoadID></LoadID>
<b1_alt_id> </b1_alt_id>
<LoadID></LoadID>
<OccupancyID></OccupancyID>
<ADDRESS_ID></ADDRESS_ID>
<ADDRESS_NUMBER></ADDRESS_NUMBER>
<STREET_DIRECTION> </STREET_DIRECTION>
<STREET_NAME> </STREET_NAME>
<STREET_TYPE> </STREET_TYPE>
184
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 105
<CUSTOMER> </CUSTOMER>
<ZIP_CODE></ZIP_CODE>
<StreetAddress> </StreetAddress>
<StreetAddressRevised> </StreetAddressRevised>
<MapNumber></MapNumber>
<BusinessName> </BusinessName>
<BusinessManagerName></BusinessManagerName>
<BusinessPhone></BusinessPhone>
<PropertyOwnerName></PropertyOwnerName>
<PropertyOwnerPhone></PropertyOwnerPhone>
<SquareFeetTotal></SquareFeetTotal>
<PropertyUseDescription> </PropertyUseDescription>
<ConstructionType> </ConstructionType>
<ConstructionTypeDescription> </ConstructionTypeDescription> <HazardOfContents></HazardOfContents>
<SprinklerValveLocation> </SprinklerValveLocation>
<HasSprinklers></HasSprinklers>
<HasStandpipes></HasStandpipes>
<HasHoodSystem></HasHoodSystem>
<HasFireAlarm></HasFireAlarm>
<HasFirePump></HasFirePump>
<HasKeybox></HasKeybox>
<HasHazMat></HasHazMat>
<IsHighRise></IsHighRise>
<FloorsAboveGrade></FloorsAboveGrade>
<FloorsBelowGrade></FloorsBelowGrade>
<PropertyManagerName></PropertyManagerName>
<PropertyManagerPhone></PropertyManagerPhone>
<ContactName01></ContactName01>
<ContactName02></ContactName02>
<ContactName03></ContactName03>
<ContactName04></ContactName04>
<ContactName05></ContactName05>
<ContactName06></ContactName06>
<ContactName07></ContactName07>
185
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 106
<ContactName08></ContactName08>
<ContactName09></ContactName09>
<ContactName10></ContactName10>
<ContactPhone01></ContactPhone01>
<ContactPhone02></ContactPhone02>
<ContactPhone03></ContactPhone03>
<ContactPhone04></ContactPhone04>
<ContactPhone05></ContactPhone05>
<ContactPhone06></ContactPhone06>
<ContactPhone07></ContactPhone07>
<ContactPhone08></ContactPhone08>
<ContactPhone09></ContactPhone09>
<ContactPhone10></ContactPhone10>
<PrePlanLink></PrePlanLink>
</record>
</Records>
COMMUNICATION
Communication is conducted via SFTP over port 22, using key-based (password less) authentication for secure access.
AUTHENTICATION
This interface utilizes password less SFTP authentication using RSA public/private key pairs.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the Production, Development and Training environments provided access between Accela and the FTP folder is available.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that premise information is successfully ingested into the vCAD as part of the scheduled process. This test confirms that the newly submitted premise records are added or updated records reflect the intended changes.
PERFORMANCE TESTS
186
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 107
There are no performance tests associated with this interface.
EXCEPTION TESTING
This test verifies that if connectivity between the Accela system and the SFTP server is temporarily lost, Accela can automatically re-establish the connection and resume submitting XML files without manual intervention.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide network connectivity between Accela and the Versaterm SFTP folder. b. Coordinate with Accela technical staff to assist in the interface development and testing. c. Assist Versaterm as required as they perform the initial integration testing. d. Review the results from Versaterm’s initial integration testing. e. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Configure the import process.
b. Generate and provide the customer with RSA keys for connection to the FTP share. c. Provide assistance and guidance in the development and testing process. d. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
PULSEPOINT
This interface provides up-to-date call and unit status information to the PulsePoint server making it available to end users accessing the PulsePoint application.
PROCESS FLOW
The Versaterm Computer Aided Dispatch (vCAD) publishes all active call and unit status information to the vMonitor (BSS) database in real time. This interface uses a Restful API hosted on the Versaterm server called from the PulsePoint Connect application allowing the PulsePoint to pull active vCAD data into the PulsePoint server. The PulsePoint application is configured to pull vCAD data in BSS at no less than 5-second intervals.
187
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 108
CONFIGURATION
Not applicable for this interface.
DATA FORMAT REQUIREMENTS
The data will conform to the Versaterm API specifications (bss_rest_api_doc.docx Edition 1.0.0) The Customer is responsible to map the data elements to the 3rd party system (PulsePoint).
COMMUNICATION
The communication between PulsePoint Connect application and the BSS will be through a Restful based API following the Versaterm vMonitor BSS REST API SDK.
AUTHENTICATION
Authentication is done using the predefined Customer ID and secret provided by Versaterm. API token is returned by the vMonitor API if credentials are verified successfully.
BUSINESS CONTINUITY/INTERFACE AVAILABILITY
This interface is available from the Production, Training, and Test vCAD environments. During system implementation the vCAD process will be tested on the vCAD Test system and ported to the Train system.
Once in production use the Train and Test query can be turned off or run on an as needed basis.
INTERFACE TESTING
These tests are intended to ensure the interface is completely functional as designed. The following are descriptions of the tests to be performed for the specified interface functionality during the Functional Acceptance process.
FUNCTIONAL AND COMPLETENESS TEST
This test ensures that the BSS database is populated with active call and unit status information. 188
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.3 - Interface Control Document
Page | 109
OPERATIONAL TESTS
This test ensures the PulsePoint Connect application is able to reconnect to the Restful API and pull data after system reboots. The BSS server will be shutdown/re-started and ensure BSS services are started as well as communications between PulsePoint to the Restful API is established.
PERFORMANCE TESTS
The performance tests will consist of ensuring that updates to active calls and unit status changes performed within vCAD are published to the BSS database within 2 seconds. Excluded from any measurement is network time (e.g. network between vCAD and BSS).
EXCEPTION TESTING
The exception testing consists of disconnecting the PulsePoint connectivity to the Restful API and after reconnecting, ensure PulsePoint is able to re-establish its connection to the Restful API.
DATA INTEGRITY TESTING
It is the responsibility of the Customer to conduct in-depth testing of the interface to ensure overall data integrity, that data is processed appropriately and that the interfaces function as required.
RESPONSIBILITIES
CUSTOMER RESPONSIBILITIES
a. Provide network connectivity between PulsePoint and the BSS server. b. Coordinate with PulsePoint technical authorities to assist in the interface development and testing. c. Assist Versaterm as required as they perform the initial integration testing. d. Review the results from Versaterm’s initial integration testing. e. Perform integration testing as described in the Interface Testing section above and confirm that the interface works as required.
VERSATERM RESPONSIBILITIES
a. Provide the Customer with the Versaterm vMonitor BSS REST API SDK. b. Perform initial integration testing as described in the Interface Testing section above and review test results with the Customer.
189
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 1
EXHIBIT B.4
ACCEPTANCE TEST PLAN
190
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 2
CONTENTS
OVERVIEW 3
1 I NTERFACE I NTEGRATION T ESTING ...................................................................................................................................................3
1.1 O BJECTIVES .............................................................................................................................................................3
1.2 S TRATEGY ...............................................................................................................................................................3
1.3 S CHEDULE ...............................................................................................................................................................3
1.4 D EPENDENCIES .........................................................................................................................................................3
1.5 S ERVER E NVIRONMENT ..............................................................................................................................................4
1.6 P ROBLEM T RACKING AND R EMEDIES ..............................................................................................................................4
1.7 C OMPLETION C RITERIA ...............................................................................................................................................4 2 F UNCTIONAL A CCEPTANCE T ESTING .................................................................................................................................................4
2.1 O BJECTIVES .............................................................................................................................................................4
2.2 S TRATEGY ...............................................................................................................................................................4
2.3 S CHEDULE ...............................................................................................................................................................5
2.4 D EPENDENCIES .........................................................................................................................................................5
2.5 S ERVER E NVIRONMENT ..............................................................................................................................................5
2.6 P ROBLEM T RACKING AND R EMEDIES ..............................................................................................................................5
2.7 C OMPLETION C RITERIA ...............................................................................................................................................6 3 R ELIABILITY A CCEPTANCE T ESTING ..................................................................................................................................................7
3.1 O BJECTIVES .............................................................................................................................................................7
3.2 S TRATEGY ...............................................................................................................................................................7
3.3 S CHEDULE ...............................................................................................................................................................7
3.4 D EPENDENCIES .........................................................................................................................................................7
3.5 S ERVER E NVIRONMENT ..............................................................................................................................................7
3.6 P ROBLEM T RACKING AND R EMEDIES ..............................................................................................................................7
3.7 R ELIABILITY / D OWNTIME D EFINITION ............................................................................................................................7
3.8 C OMPLETION C RITERIA ...............................................................................................................................................8 4 F INAL S YSTEM A CCEPTANCE ..........................................................................................................................................................9 5 D EFECT C LASSIFICATIONS ..............................................................................................................................................................9 191
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 3
OVERVIEW
This Exhibit describes the parameters involved in the Acceptance Test Plan which will be used per the Agreement and Statement of Work. The Acceptance Test Plan involves three (3) types of acceptance tests:
• Interface Integration Testing
• Functional Acceptance Testing
• Reliability Acceptance Testing
The procedures to conduct each type of acceptance test are documented within each test plan (below). The Customer has the primary responsibility of conducting the Acceptance Tests, where Versaterm will support and assist the Customer as required. 1 INTERFACE INTEGRATION TESTING
1.1 OBJECTIVES
The purpose of Interface Integration Testing is to demonstrate and verify that all interfaces specified in the Interface Control Document meet or exceed the functionality and performance expectations, and that each interface is operational and ready for Functional Acceptance Testing.
The process of testing the interfaces also provides the Customer with the knowledge necessary to complete the Functional Unit Testing for each interface.
1.2 STRATEGY
As each interface is developed and installed, Versaterm will remotely assist the Customer’s Project Team with performing testing.
Versaterm will demonstrate each interface to Customer personnel to confirm that it adheres to the specifications documented in the Interface Control Document. The Customer personnel will test and verify the results.
Errors will be tracked and remedied.
1.3 SCHEDULE
The Interface Integration Test is formally scheduled for five (5) Business Days and will be conducted in accordance with the Project Schedule. However, individual interfaces are expected to be tested as they are ready during the Interface Development and Testing task. The Interface Integration Test period may be extended beyond the initial five (5) Business Days if there are confirmed discrepancies that prevent the Interface Integration Test from being completed successfully within the initial five (5) Business Days.
1.4 DEPENDENCIES
Integration Testing has the following dependencies:
• Install the Production Environment in the Cloud
• Develop and install interfaces.
192
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 4
• Configure the Application Software.
• For each interface that involves another application/system, a test/development system to which the Versaterm system can connect must be available, or a plan must be in place to enable the required testing.
1.5 SERVER ENVIRONMENT
Interfaces will be tested in the Cloud Production Environment prior to the System being used for Production Use. After cutover to Production Use, any interface not previously tested will be tested in the Development/Test Environment prior to being installed in the Production Environment for final testing.
1.6 PROBLEM TRACKING AND REMEDIES
Each discrepancy/issue will be documented in the Issues List.
Within ten (10) Business Days of finding and documenting a discrepancy that can be classified as Critical Priority Error or High Priority Error, in Section 6 of this document, Versaterm will correct the issue and then request, in writing, that the Customer retest the interface.
The Customer shall repeat the failed Interface Test within ten (10) Business Days of receipt of Versaterm’s written request and shall advise Versaterm, in writing, of the results within five (5) Business Days of the test’s completion.
Discrepancies that are classified as Minor Error will not prevent the Integration Test from being successfully completed.
1.7 COMPLETION CRITERIA
Integration Testing will be considered successfully completed when all of the following criteria are met:
• The Customer has verified that all interfaces operate as specified in the Interface Control Document • The Customer’s Project Team and other select Customer staff are sufficiently trained to be able to administer, manage, and fully use each Interface.
• The Customer confirms, in-writing, of either acceptance, rejection or conditional acceptance of the interface integration tests for each interface within five (5) business days of completing the final tested interface. 2 FUNCTIONAL ACCEPTANCE TESTING
2.1 OBJECTIVES
The purpose of Functional Acceptance Testing is to verify that the fully configured System, including the interfaces specified in the Interface Control Document, meets the functional requirements described in the Agreement.
2.2 STRATEGY
The Customer will develop a Standard Acceptance Test Plan suitable for verifying the solution’s functionality. Customer workflow processes will be the basis of the Test plan. These processes will be documented during system implementation by the Customer for use during the test period.
193
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 5
At the conclusion of Functional Acceptance Test development task, the Customer may use the tests to perform independent testing of the system prior to the formal Functional Acceptance Testing task. With assistance from Versaterm, the Customer will conduct Functional Acceptance Tests on the system to verify that functionality meets the test scenarios and tests.
During the Functional Acceptance Testing task, the Customer will track whether requirements pass or fail tests. If a requirement fails a test, it will be classified as a “Failure” if related to a software application error, and Versaterm shall have up to ten (10) business days to correct any Failure or provide a Customer-approved approach for correcting the Failure. Once a Failure is corrected, Versaterm and the Customer will conduct additional testing of that requirement to verify that it passes the test.
The system will be deemed to have passed Functional Acceptance Testing when all scenarios and requirements pass the test or the Customer approves Versaterm-proposed workarounds or approaches to remedy Failures. The Customer will conduct Functional Acceptance Testing with remote support from Versaterm. During Functional Acceptance Testing, Versaterm will be immediately available to answer questions and address any issues. Errors will be tracked and remedied.
2.3 SCHEDULE
The Functional Acceptance Testing period should not exceed fifteen (15) Business Days and will begin according to the mutually agreed upon Project Implementation Schedule and after Versaterm has provided the Customer with written notice that the System is ready for Functional Acceptance Testing. If the Customer does not believe the System is ready for the Functional Acceptance Test, it will provide the reasons in writing to Versaterm within five (5) Business Days of receipt of Versaterm’s notification.
The Functional Acceptance Testing period may be extended if there are confirmed defects that prevent the Functional Acceptance Test from being completed successfully. Functional Acceptance Testing must be successfully completed before Versaterm-delivered Trainer-Training and End-User training can commence.
2.4 DEPENDENCIES
Functional Acceptance Testing has the following dependencies:
• Production Environment Infrastructure available in the cloud • Integration Testing completed
• Enhancements have been installed in the Test Production environment • Geofile loaded
• Validation tables populated
• Workflows configured
• For each Interface that involves another application/system, a test/development system to which the Versaterm system can connect must be available, or a plan must be in place to enable the required testing.
2.5 SERVER ENVIRONMENT
The Functional Acceptance Tests will be conducted in the Production Environment prior to the System being used for Production Use.
2.6 PROBLEM TRACKING AND REMEDIES
194
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 6
The Customer will document each discrepancy between observed functionality and the Agreement specifications. The Customer will provide, in writing, a list of the discrepancies and defects to Versaterm. The Customer and Versaterm Project Managers will mutually agree on the classification of each defect according to the definitions in Section 5 of this document.
Each discrepancy/issue will be documented in Customer’s SharePoint Issues List.
Within ten (10) Business Days of receiving written notification of Functional Acceptance Testing discrepancies, Versaterm will either:
• Correct confirmed defects that prevent Functional Acceptance Testing from being completed successfully and then request, in writing, that the Customer repeats the failed Functional Acceptance Testing component(s) that resulted in the defects; or
• Provide a mutually agreeable solution to confirmed defects consisting of either a future System patch correction that will be installed at a mutually agreeable time period, or a mutually agreeable workaround.
Versaterm must remedy all defects classified as Critical Priority Errors or High Priority Errors before Functional Acceptance Testing is completed and training begins. The Customer and Versaterm Project Managers will mutually agree on any Minor Errors that must be remedied before training begins, Production Use occurs, or Final System Acceptance, and which can be remedied in a future release.
All defects will be documented and reported to Versaterm, and Versaterm will provide a schedule and/or mitigation procedure for all reported defects.
The Customer shall repeat the failed Functional Acceptance Testing within ten (10) Business Days of receipt of Versaterm’s remedy for an error, and shall advise Versaterm, in writing, of the results within five (5) Business Days of the test’s completion.
2.7 COMPLETION CRITERIA
Functional Acceptance Testing will be considered successfully completed when all of the following criteria are met:
• The System and Interfaces have been verified by the Customer to operate as specified in the Agreement. • All scenarios and requirements have passed the test, or the Customer has approved Versaterm-proposed workarounds or approaches to remedy unresolved Failures.
195
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 7
3 RELIABILITY ACCEPTANCE TESTING
3.1 OBJECTIVES
Reliability Acceptance Testing ensures that the System continues to operate according to the specifications contained within the Agreement for thirty (30) consecutive calendar days after the System cutover to Production Use.
3.2 STRATEGY
After cutover to Production Use, the System will undergo a thirty (30)-day test period. The Customer will use the System for its intended purposes and monitor system reliability, functionality, and performance. Errors will be tracked and remedied.
3.3 SCHEDULE
Reliability Acceptance Testing begins immediately following System cutover to Production Use. It ends when the System operates at an availability level of 99.99% for thirty (30) consecutive days without a Critical Priority Error or High Priority Error, and the Customer and Versaterm have mutually agreed upon a plan to remedy all Minor Errors.
3.4 DEPENDENCIES
Reliability Acceptance Testing is dependent on the System being enabled for Production Use.
3.5 SERVER ENVIRONMENT
Reliability Acceptance Testing will be conducted in the Production Environment in the Cloud.
3.6 PROBLEM TRACKING AND REMEDIES
The Customer will use the System for its intended purpose and monitor the System for defects. The Customer will document in writing and report to Versaterm any System defects encountered. The Customer and Versaterm Project Managers will mutually classify each defect according to the definitions in this Exhibit.
The Customer will immediately inform Versaterm by telephone upon discovery of a Critical Priority Error or High Priority Error, and Reliability Acceptance Testing will immediately stop. The Customer will follow-up with a written notification of the defect to Versaterm. Once the problem is resolved, Reliability Acceptance Testing will start over from day one (1) and a new thirty (30)- Day Reliability Acceptance Test period will begin.
Discovery of a Minor Error will not stop the Reliability Acceptance Testing. Versaterm will attempt to remedy Minor Errors during the Reliability Acceptance Testing period. If Versaterm is not able to fix a Minor Error during the Reliability Acceptance Testing period, Versaterm and the Customer will develop a mutually acceptable plan to remedy the defect in a future fix release.
3.7 RELIABILITY / DOWNTIME DEFINITION
The System will be considered “down” (i.e., not available to end-users) if a Critical Priority Error or High Priority Error is encountered during the Reliability Acceptance Testing period using the following approach:
196
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 8
Critical Priority Error ─ Critical errors that are defined as Loss of Data, Corruption of Data, or Loss of Productive Use of the Application. In the event this type of error occurs, the Customer will immediately notify Versaterm, and the Reliability Test period will be cancelled. Versaterm personnel shall promptly resolve the problem at no additional cost to Customer and a new Reliability Test period will begin. Upon receipt of a Critical Priority software correction, Customer has 72 hours to test the software correction and resume productive use. If Customer does not place the software correction into production within 72 hours, the new Reliability Test period will begin. Once the System operates for thirty (30) consecutive days without a Critical Priority Error, the Reliability Test will be complete.
High Priority Error ─ Non-critical errors defined by incomplete operation of a single system application where a procedural workaround is available, and productive use of the system is impacted. In the event this type of error occurs, Customer will immediately notify Versaterm, and the Reliability Test period will be suspended. Versaterm personnel shall resolve the problem at no cost to the Customer. Once repaired, the Reliability Test period will recommence at the point where it was suspended.
Upon receipt of a High Priority Error software correction, the Customer has 48 hours to test the software correction and place it into production. It the Customer does not place the software correction into production within 48 hours, the Reliability Test period will resume, and the Reliability Test period will recommence at the point where it was suspended.
Failures outside of Versaterm’s control, such as individual workstation failures (e.g., a Windows operating system failure, insufficient memory, etc.), will not be considered System defects and will not affect the outcome of the Reliability Acceptance Testing as long as there is productive use of the System on other workstations.
If System unavailability is mutually agreed upon and scheduled for the purpose of Application Software updates, performance tuning, file backups, or other processes typical in an operational environment, the System will not be considered unavailable and will not impact the successful completion of Reliability Acceptance Testing.
The System will also not be considered unavailable if other factors such as the network, external agency, operator, or Cloud environment are mutually determined by the Customer and Versaterm to be the cause of encountered defects.
If the System’s unavailability is attributed to any integrated Third-Party product, both Parties will first assist each other in identifying the root cause. Once the defect has been corrected or a mutually agreeable workaround has been implemented, the System will be considered available again.
If the System’s unavailability is attributable directly to a Third-Party product interfaced or integrated with the System that is beyond Versaterm’s control, then the System shall be considered available from the point at which the defect was originally reported to Versaterm.
If the System is unavailable because of other factors that are beyond Versaterm’s control (e.g., Force Majeure, catastrophic network failures, Third-Party product Interfaces not provided by Versaterm, etc.) and these factors result in users not being able to make production use of the System, at the sole discretion of the Customer, Reliability Acceptance Testing will be suspended until the System can be placed in Production Use again. When the System is placed into Production Use again, the Reliability Acceptance Test will be resumed from the point at which it was suspended.
During the Reliability Acceptance Testing period, Versaterm will not stop the System (force it to be unavailable for Production Use), upgrade the Application Software, or otherwise negatively impact the operational status of the System without the written permission of the Customer. The System will continue to operate to the best of its abilities even while/if the Reliability Acceptance Testing has been suspended due to encountered defects.
3.8 COMPLETION CRITERIA
197
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.4 – Acceptance Test Plan
Page | 9
Reliability Acceptance Testing is considered complete when the System has operated for thirty (30) consecutive Days without a Critical Priority Error or High Priority Error and a mutually agreeable plan to remedy all other Minor Errors has been developed. 4 FINAL SYSTEM ACCEPTANCE
Final System Acceptance will occur after the completion of the 30-day Reliability Acceptance Testing and when a mutually agreeable plan to remedy all minor Errors has been developed. 5 DEFECT CLASSIFICATIONS
The Customer and Versaterm will classify all found defects according to the following definitions for error levels:
Critical Priority Error ─ Critical errors that are defined as Loss of Data, Corruption of Data, or Loss of Productive Use of the Application.
High Priority Error ─ Non-critical errors defined by incomplete operation of a single system application where a procedural workaround is available, and productive use of the system is impacted.
Minor Error ─ Cosmetic errors that are defined as configuration issues that can be corrected by Customer, data integrity issues that must be addressed by Customer, Help file documentation errors, or enhancements that can be made in the future to the presently released version. Minor issue relating to a specific component of the System that does not affect the productive use of the System or component. Examples include a field that is right-justified rather than left-justified or the usage of an inconsistent font.
198
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 1
EXHIBIT B.5
TRAINING PLAN
199
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 2
CONTENTS
1 TRAINING PLAN OVERVIEW 3
1.1 Training Facilities..............................................................................................................................................3
1.2 Initial Training Approach...................................................................................................................................3
1.2.1 Versaterm Train-the-Trainer Training.......................................................................................................3
1.2.2 Versaterm Internals Training ...................................................................................................................3
1.2.3 End-User Training ....................................................................................................................................4
1.2.4 Post-Implementation Training .................................................................................................................5
1.3 Final Training Approach ............................................................................................................5 2 COURSE OUTLINES 5
2.1 Call-Taker/Dispatcher Training (DP) ........................................................................................................... 5
2.1.2 System Administrator Training (CAD_SUP_ADMIN) .................................................................................6
2.1.3 MAP Administration & VGI (MAP) ...........................................................................................................7
2.1.4 Police Mobile (vMDT,vMobile) Instructor Training (MDT_P) ....................................................................7
2.1.5 Fire Mobile (vMDT,vMobile) Instructor Training (MDT_F) ........................................................................8
2.1.6 Mobile Administrator Training (MDT_ADMIN).........................................................................................9
2.1.7 Remote CAD and Browser Status Screen Instructor Training (RCAD) ..............................................9 200
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 3
1 TRAINING PLAN OVERVIEW
This document describes Versaterm’s recommended training approach for the implementation of the Versaterm CAD and Mobile software applications and is intended to be used as a guide to planning and delivering training to all users.
The Training Plan and approaches may be refined and further elaborated as required during the Project, where the Customer and Versaterm will collaborate and mutually agree on any refinements.
This document also describes the course outlines that Versaterm will deliver to the Customer trainers and a sample of the courses the Customer may replicate to all users.
1.1 TRAINING FACILITIES
Amongst other requirements, the training facilities are required to meet CJIS security, support network encryption, and support physical access requirements.
The facilities are also expected to be dedicated solely to Versaterm application training during the end- user training periods, without requiring daily software re-installation and infrastructure re-configuration.
The following is a list of requirements/recommendations for the training facilities:
• At least fifteen (15) dedicated workstations that meet the minimum Versaterm CAD and Mobile application requirements.
• At least one additional workstation for the training instructor. • Dedicated network access provided between each workstation and the Versaterm servers. • At least one overhead projector and screen that is viewable by all trainees (i.e., from each training workstation) and that is able to display the contents of the training instructor’s workstation monitor(s).
• One whiteboard with Dry-Erase markers.
• A network printer which is configured to be the default printer for each workstation.
1.2 INITIAL TRAINING APPROACH
Following the completion of the Configuration and Initial Testing phases of the Project Implementation Schedules, the Training phase will take place shortly after. The proposed training approach first starts with Versaterm Trainer- Training followed by End-User Training.
1.2.1 VERSATERM TRAIN-THE-TRAINER TRAINING
This first level of training is where Versaterm will provide hands-on training to the Customer’s Project Team members. This will take place over a one-week period for vCAD, vMDT and vMobile. These training weeks will be composed of the training courses documented in Section 2, except for the Internals Training course. At the conclusion of Versaterm's Trainer-Training, it is expected the attendees will be prepared to conduct End-User training.
1.2.2 VERSATERM INTERNALS TRAINING
This training is where Versaterm will provide training to the Customer’s System Administrators. This will be 1 day in duration and provided by webcast. At the conclusion of this training, the Administrators will 201
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 4
understand the Versaterm CAD database structures so that they can develop ad-hoc and custom reports; the System structure; conventions used by Versaterm within the database; the Datamart, and release upgrade procedures, specifically changes to the database schema.
Note: Due to the material to be covered, this course will be tailored specifically for the Customer where Customer-specific reports and queries will be used as samples.
1.2.3 END-USER TRAINING
Following the completion of the Trainer-Training, Versaterm will assist the Customer with strategizing their End-User Training plans.
Versaterm’s recommended End-User training strategy starts with identifying the affected user groups, the courses to be taught and the duration of each course (who, what, and how long). Once these key factors are identified, the training strategy involves planning the logistics and training schedules (who, when and where).
1.2.3.1 STEP 1: IDENTIFY USER GROUPS
The first step involves identifying all the affected Customer user groups that will require training.
For example: Call Takers, Dispatchers, Patrol, Fire Personnel, Analysts, System Administrators, etc.
1.2.3.2 STEP 2: IDENTIFY TRAINING COURSES (AND ESTIMATED DURATION) Following the identification of the affected user groups, the second step involves identifying the training courses that will be taught. While identifying the courses, the course objectives, the course outline, the course content, and the targeted audience will be determined at a high-level, along with the estimated duration of each course (in hours).
1.2.3.3 STEP 3: ASSIGN COURSES TO EACH USER GROUP
Following the identification of user groups and training courses, the next step involves matching up the courses to each user group based on what they will need to be trained on to perform their everyday jobs. Once the training needs of each user group are identified, the estimated total amount of training time (per user group) can be determined. For example: Dispatchers will require training courses X, Y and Z which amount to a grand total of 32 hours of training.
Once all the above is determined, the next step in planning the End-User Training involves figuring out the logistics and the schedules. This specifically focuses on the coordination of trainers, trainees, training facilities (and setup), and scheduling logistics (i.e. will training be required 7 days a week, and in the evenings, and can multiple training classes be conducted simultaneously, etc.).
1.2.3.4 TARGET AND TIMING RECOMMENDATIONS FOR INITIAL END-USER TRAINING Ideally, all end-users would be trained prior to the production cutover date, however, as end-users may be on vacation, sick, between promotions, or otherwise unavailable to attend the training, Versaterm recommends that End-User Training be targeted for approximately 85% of affected end-users.
202
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 5
In addition, Versaterm recommends that End-User training be delivered within a maximum of five (5) weeks, prior to the production cutover date. This approach is referred to as “Just in Time” training, a timely strategy that eliminates the need for refresher training. This approach reduces potential knowledge loss if training were delivered over an extended period of time, too far from the production cutover date.
With the “Just in Time” approach, trained end-users will be able to immediately use the production CAD system as of the production cutover date.
1.2.4 POST-IMPLEMENTATION TRAINING
For the minority percentage of end-users who will not receive training prior to the production cutover date, Versaterm recommends post-implementation training for these end-users.
Likewise, for the end-users who require refresher training after the production cutover date, Versaterm recommends that the Customer develops an on-going training plan to accommodate post-implementation training needs.
1.3 FINAL TRAINING APPROACH
As the Project Implementation Schedule may be impacted by the type of functionality that will be implemented at go-live, the final training approach will be refined during the Project. 2 COURSE OUTLINES
This section describes the course outlines that Versaterm will deliver to the Customer trainers.
The definition of a “course” (as used in this document) refers to the in-depth training of either a functional area or set of areas within the applicable Versaterm application. For each course listed below, a course code is identified in parentheses. The course code may be used when identifying the makeup of a course.
Notes:
• Each course may be modified or tailored as necessary, and each user group may receive multiple courses.
• The time allotted and number of trainees for each course are provided as guidelines. • Versaterm does not provide any training for Microsoft Windows. If the Customer requires such training, it is expected that this level of training will be acquired by the Customer from a Third Party.
2.1 CALL-TAKER/DISPATCHER TRAINING (DP)
Course Duration 3 days
Prerequisite None
Intended Audience Communication center call-taker, dispatcher and supervisory personnel who will be responsible for taking emergency calls for assistance and dispatching required emergency response units.
203
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 6
Course Approach In order to achieve the objectives below, Versaterm will prepare various CAD scenarios that will exercise the functions described.
These scenarios will be based on “typical” cases that will have been provided by the Customer, prior to training.
The Customer will provide a classroom with 10 desktop workstation positions, one for each student.
Course Objectives The CAD call-taker/dispatch operators will:
A. Know how to sign on and sign off units
B. Know how to add, dispatch and clear calls
C. Know how to add calls via E-911, alarm number
D. Know how to maintain unit activity information (both case- related, and when not on a case)
E. Know how to retrieve calls (by number, by date or from the active or dispatch queues)
F. Know how to move calls between queues
G. Know how to view history at a particular address
H. Know how to retrieve hazard, alarm, itinerary and contact records on an address
I. Know how to obtain a hard copy (printout) of a call
J. Know how to navigate the status screen
K. Know how to navigate the MapViewer
L. Know how to set and stop unit timers
M. Know how to query against NCIC
N. Know how to use the vMail facility
O. Know how to use the Notepad facility to view lists
P. Know how to use the on-line help facility
Q. Know how to add calls retro-actively
2.1.2 SYSTEM ADMINISTRATOR TRAINING (CAD_SUP_ADMIN)
Course Duration 1 day
Prerequisite Call Taker/Dispatcher Training
Intended Audience Users who are responsible to maintain table codes, security, user access, run reports, etc.
Course Approach Since this course will involve a subset of the individuals from the previous call-taker/dispatcher course, the information covered in this course will focus on supervisor/administrator specific items.
Maximum of 1 person per workstation.
Course Objectives The Supervisor and Administrator will:
A. Understand the implications and parameters in specific CAD tables (call types, busy codes, setting up Police and Fire responses and response modifiers, etc.)
204
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 7
B. Know how to create and maintain users and their security privileges and password
C. Know how to add and maintain Notepad and Topic entries D. Know how to add calls retro-actively
E. Know how to use the mail system, and how to define mail groups
F. Know how to manage the various queue types
G. Know how to reconfigure a given user’s beat/zone responsibility and status screen layout
H. Know how to set up the shift duty table
I. Know how to set up a status screen
J. Know how to maintain the street index (GEO code) file including common place names and alias street names
K. Know how to maintain address information (hazard records, alarm records, itinerary records, night list records, etc.)
2.1.3 MAP ADMINISTRATION & VGI (MAP)
Course Duration Up to 1.5 days
Prerequisite None
Intended Audience Users who are responsible for maintaining maps on the desktops and laptops as well as GIS (or non-GIS personnel) who are responsible for providing street data for the CAD.
Course Approach This course is conducted via webcast.
Due to the material to be covered, this course will be topic-based, as opposed to scenario-based. Some functions will be demonstrated, while others will be executed by the student himself/herself.
The students for this course are expected to have some technical computer aptitudes and familiarity with Windows.
Maximum of 1 person per workstation.
Course Objectives The students will:
A. Create custom views (based on event location, specific X,Y coordinate, current viewing area, etc.)
B. Create custom themes (based on map packages required for specific Police/Fire user groups)
C. Set ‘info bar’ display properties
D. Define and setup icons for the dynamic layers (queued calls, active calls)
E. Setting display properties for the tracking layer (AVL) F. Learn to configure and use the VGI tool to produce street load files for the CAD
2.1.4 POLICE MOBILE (VMDT,VMOBILE) INSTRUCTOR TRAINING (MDT_P) 205
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 8
Course Duration Up to 1 day
Prerequisite None
Intended Audience General audience of users who will use the Police vMDT and vMobile on a day-to-day basis. Supervisors and/or administrators are expected to attend this course.
Course Approach Versaterm will prepare scenarios based on sample data provided beforehand by the Customer. This approach has the advantage of making the training more effective, since familiar and realistic situations are used.
This course will permit hands on and “refreshers” as necessary (i.e., much of it is iterative and practice sessions).
Maximum of 1 student per laptop computer
Course Objectives The student will:
A. Know how to sign on and sign off
B. Know how to receive a dispatch
C. Know how to change status
D. Know how to perform an on-view (self-initiated)
E. Know how to perform NCIC queries for persons, vehicles and property
F. Know how to query addresses
G. Know how to query CAD for unit status and pending queue H. Know how to lock/unlock the vMDT and vMobile
I. Know how to send messages to CAD and to other devices J. Know how to review logs
2.1.5 FIRE MOBILE (VMDT,VMOBILE) INSTRUCTOR TRAINING (MDT_F) Course Duration Up to 1 day
Prerequisite None
Intended Audience General audience of users who will use the Fire vMDT and vMobile on a day-to-day basis. Supervisors and/or administrators are expected to attend this course.
Course Approach Versaterm will prepare scenarios based on sample data provided beforehand by the Customer. This approach has the advantage of making the training more effective, since familiar and realistic situations are used.
This course will permit hands on and “refreshers” as necessary (i.e., much of it is iterative and practice sessions).
Maximum of 1 student per laptop computer
206
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 9
Course Objectives The student will:
A. Know how to sign on and sign off
B. Know how to receive a dispatch
C. Know how to change status
D. Know how to query addresses
E. Know how to query CAD for unit status and pending queue F. Know how to lock/unlock the vMDT and vMobile
G. Know how to send messages to CAD and to other devices H. Know how to review logs
2.1.6 MOBILE ADMINISTRATOR TRAINING (MDT_ADMIN)
Course Duration Up to 1 day
Prerequisite None
Intended Audience Administrators responsible for setting up and maintaining the Police and Fire vMDT and vMobile software on the mobiles as well as troubleshooting mobile traffic.
Course Approach The trainer will “walk through” the various system and programming components of the vMDT and vMobile. Emphasis will be placed on the hardware & software configuration as well as the various components (mobile workstations, smartphones, Message Controller, etc.) which comprise the Mobile Workstation infrastructure.
One installed MDT and vMobile is required.
Course Objectives The students will:
A. Know how to install/upgrade and configure software on the mobile devices
B. Know how to adjust configuration parameters
C. Know how to monitor mobile traffic, review logs, etc.
D. Understand components in the mobile architecture
E. Know how to use the MDT designer to configure the layout of the MDT
2.1.7 REMOTE CAD AND BROWSER STATUS SCREEN INSTRUCTOR TRAINING (RCAD) Course Duration .5 day
Prerequisite None
Intended Audience General audience of users who will be using Remote CAD and Browser Status Screen to monitor CAD calls and activity.
Course Approach Versaterm will prepare scenarios based on sample data provided beforehand by the Customer. This approach has the advantage of 207
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.5 – Training Plan
Page | 10
making the training more effective, since familiar and realistic situations are used.
This course will permit hands on and “refreshers” as necessary (i.e., much of it is iterative and practice sessions).
Maximum of 1 student per workstation.
Course Objectives The student will:
A. Know how to view a unit status listing
B. Know how to view a listing and details of active and pending incidents
C. Know how to query activity logs
D. Know how to maintain address related records
208
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 1
EXHIBIT B.6
MINIMUM CLIENT AND PERIPHERAL
SPECIFICATIONS
209
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 2
CONTENTS
Overview ...................................................................................................................................................3 1 Workstation Recommendations ..............................................................................................................4
1.1 CAD Customer Computers (with Maps)..................................................................................................4
1.2 Mobile Data Computers (with Maps) .....................................................................................................5
1.3 vMobile 2.0 .............................................................................................................................................6 210
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 3
OVERVIEW
This document identifies the Minimum Client and peripheral specifications to be supplied by the Customer, in order to run the Versaterm CAD and Mobile Application Software and adhere to the system performance and availability standards specified in Exhibit B – CAD SaaS Service Schedule for Cloud.
The specifications included in this document are subject to change to support future Product Upgrades.
When applicable, Versaterm will provide the Customer with updated specifications and recommendations. 211
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 4
1 WORKSTATION RECOMMENDATIONS
The following provides the recommended workstation configurations:
1.1 CAD CLIENT COMPUTERS (WITH MAPS)
ComputerAn IBM-compatible computer with full Windows Desktop Operating System Display
1024 x 768 resolution, 256 colors (High color 16-bit or higher recommended) Higher resolution – CAD will adjust to higher resolution, but it may appear small
Multiple Monitors (two or more) per desktop are recommended If running multiple monitors, a graphic card capable of driving multiple monitors is required
Video
Graphics card with DirectX support
Accelerated graphics card able to drive multiple monitors Operating SystemMicrosoft Windows 10 (version 1803 or later recommended) Memory6 GB minimum, 8GB recommended
CPUIntel or AMD 2.5 GHz dual core processor
Hard Drive80 GB recommended; 60 GB minimum.
Network Interface Card
(NIC)100 mbps Ethernet network adaptor, 1GB preferred
Other Software
Microsoft .NET 4.7.2 Framework
Visual Studio 2017 redistributable (32 bit)
Adobe Reader
Windows Media Player for MapViewer animation (optional) HTML5 supported browser (Chrome – recommended, Microsoft Edge, Safari, Firefox).
Usage
• vCAD desktop Client installation
• vRMS (browser based) access
• RemoteCAD (webCAD) / Browser Status Screen access,
• Other non-Versadex installations (e.g. Web browser, email, word processor, etc....) RemoteCAD/WebCAD
212
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 5
Browsers: modern web browser (Versaterm has certified Chrome; Edge will also work, as should Safari Mobile)
Operating System: Windows / iOS / Android
Memory: 8GB recommended
Other Software: a PDF Viewer is also needed to preview PDFs
1.2 MOBILE DATA COMPUTERS (WITH MAPS)
ComputerAn IBM-compatible computer with full Windows Desktop Operating System PeripheralsMouse or pointing device, COMM port, USB ports Touchscreen recommended Video
Minimum: 1440x900 resolution
Accelerated graphics card: 1GB recommended / 512MB minimum Operating SystemWindows 10 version 2004 or later
Memory16GB recommended / 4GB minimum
CPU2.2 ghz minimum. i5 or i7 recommended.
Hard Drive200GB recommended / 80GB minimum
Other Software
HTML5 supported browsers (such as Microsoft Edge, Safari, Firefox or Chrome)
.Net 4.7.2 Framework or higher
Windows Media Player for audio
Usage
• Versaterm Mobile Data Terminal (vMDT) installation (with the use of maps) • Versaterm Mobile Report Entry (vMRE) installation
• vRMS (browser based) webRMS
• Other non-Versadex installations (e.g. Web browser, email, word processor, etc....) 213
Versaterm Public Safety Inc. & City of Torrance
SaaS Agreement #
Exhibit B.6 – Minimum Client and Peripheral Specifications Page | 6
1.3 VMOBILE 2.0
Device The vMobile application runs on Android and iOS.
Devices must meet the following operating system requirements in order to run vMobile 2.0:
• Android: version 8.0 or greater
• iOS: version 12.0 or greater
Additional requirements:
• VPN software to allow secure communication between the devices and the VMC server. o Communication between devices and the VMC is through WebSockets on port to be specified in during implementation.
• Mobile Device Management software for deploying the application and updates ** Versaterm highly suggests testing with the desired device before purchasing it to ensure that vMobile operates correctly on the chosen device.
214