city of phoenix procurement division request for proposal ... · solicitation no. rfp 16-085 (ren)...

CITY OF PHOENIX Procurement Division

REQUEST FOR PROPOSAL

RFP 16-085 (REN)

EMERGENCY MANAGEMENT SYSTEM

PROCUREMENT OFFICER Ray Nader, CPPB

Contracts Specialist II 602-262-7793

[email protected]

TABLE OF CONTENTS


251 W. Washington Street 8th Floor

Phoenix, AZ 85003 Phone: (602) 262-7181

Solicitation No. RFP 16-085 (REN)

of 221

Solicitation Instructions Section I Solicitation Response Checklist Introduction City’s Vendor Self-Registration and Notification Schedule of Events Obtaining a Copy of the Solicitation and Addenda Preparation of Proposal Addenda Licenses Certification Submission of Proposal Withdrawal of Offer Proposal Results Award of Contract City’s Right to Disqualify for Conflict of Interest Offeror Compliance with Health, Environmental and Safety Requirements Proposal Format Solicitation Transparency Policy Protest and Appeals Process

Standard Terms and Conditions Section II Definition of Key Words Used in the Solicitation Contract Interpretation Contract Administration and Operation Costs and Payments Contract Changes Risk of Loss and Liability Warranties City’s Contractual Rights Contract Termination

Special Terms and Conditions Section III

Scope Section IV

Submittals Section V Attachments Section VI

SECTION I - SOLICITATION INSTRUCTIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Please read this before continuing on to the solicitation document.

SOLICITATION RESPONSE CHECK LIST

Check off each of the following as the necessary action is completed.

□ 1. All forms have been signed. All of Section V, Submittals, is included.

□ 2. The prices offered have been reviewed.

□ 3. The price extensions and totals have been checked.

□ 4. Any required drawings or descriptive literature have been included.

□ 5. The delivery information block has been completed.

□ 6. If required, the amount of the bid surety has been checked and the surety has been included.

□ 7. Review the insurance requirements, if any, to assure you are in compliance.

□ 8. The specified number of copies of your offer has been included.

□ 9. Any addenda have been signed and are included.

□ 10. The mailing envelope has been addressed to: City of Phoenix, Procurement, 8th Floor, 251 W. Washington Street, Phoenix, AZ 85003.

The mailing envelope clearly shows: Your company name and address, the solicitation number, and the proposal opening date.

□ 11. The response will be mailed in time to be received no later than 2:00 p.m. local Arizona time.

□ 12. Request for Consideration of Alternate Terms.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1. INTRODUCTION

The City of Phoenix invites sealed proposals for an emergency management system (EMS) and ongoing maintenance for a five-year period commencing on or about June 1, 2016, in accordance with

the specifications and provisions contained herein. This solicitation is available through Arizona Relay Service 7-1-1. Please call TTY 800-367-8939 for assistance.

2. CITY’S VENDOR SELF-REGISTRATION AND NOTIFICATION Vendors must be registered in the City’s e-Procurement Self-Registration System at https://www.phoenix.gov/financesite/Pages/EProc-help.aspx in order to receive solicitation notices, respond to solicitations and access procurement information. The City may, at its sole discretion, reject any offer from an Offeror who has not registered in the City’s e-Procurement system.

3. SCHEDULE OF EVENTS

Proposal Issue Date 12/28/2015

Written Inquiries Due Date 01/22/2016 5:00 P.M., Local Arizona Time Proposal Due Date 01/29/2016

Pre-Proposal Conference 01/13/2016 2:00 P.M., Local Arizona Time

Evaluation Panel Meets 02/17/2016

Interviews (If required) 03/03/2016 (tentative) City Council Approval 05/04/2016

Proposal Submittal Location: Calvin Goode Building City of Phoenix Finance Department Procurement Division 251 W. Washington Street, 8th Floor Phoenix, AZ 85003

Pre-proposal Location: City of Phoenix Phoenix Sky Harbor International Terminal 3 Annex East Conference Room 3420 E Sky Harbor Blvd

Phoenix, AZ 85034

Finalist Interviews: City of Phoenix Phoenix Sky Harbor International Terminal 3 Annex East Conference Room 3420 E Sky Harbor Blvd

Phoenix, AZ 85034 City reserves the right to change dates and/or locations as necessary.

https://www.phoenix.gov/financesite/Pages/EProc-help.aspx




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

4. OBTAINING A COPY OF THE SOLICITATION AND ADDENDA Interested offerors may download the complete solicitation and addenda from

https://www.phoenix.gov/solicitations. Internet access is available at all public libraries. Any interested offerors without Internet access may obtain this solicitation by calling (602) 262-7181 or picking up a copy during regular business hours at the City of Phoenix Finance Department, Procurement Division, 251 W. Washington Street, 8th Floor, Phoenix, AZ.

5. PREPARATION OF PROPOSAL 5.1 All forms provided in Section V, Submittal, must be completed and submitted with your proposal. It is

permissible to copy Section V forms if necessary. Erasures, interlineations, or other modifications of your proposal shall be initialed in original ink by the authorized person signing the proposal. No proposal shall be altered, amended or withdrawn after the specified proposal due time and date. The City is not responsible for Offeror’s errors or omissions. All time periods stated as a number of days shall be calendar days.

Any deviation from this solicitation shall be clearly stated and identified in a separate section titled Request for Consideration of Alternate Terms and must be included with your submittal. Submission of additional terms, conditions or agreements with your proposal may result in rejection of your proposal.

5.2 It is the responsibility of all Offeror’s to examine the entire solicitation and seek clarification of any

requirement that may not be clear and to check all responses for accuracy before submitting a proposal. Negligence in preparing a proposal confers no right of withdrawal after due date and time. Offerors are strongly encouraged to:

A. Consider applicable laws and/or economic conditions that may affect cost, progress,

performance, or furnishing of the products or services. B. Study and carefully correlate Offeror’s knowledge and observations with the RFP document

and other related data. C. Promptly notify the City of all conflicts, errors, ambiguities, or discrepancies which an Offeror

has discovered in or between the RFP document and such other related documents.

5.3 The City does not reimburse the cost of developing, presenting or providing any response to this solicitation. Offers submitted for consideration should be prepared simply and economically, providing adequate information in a straightforward and concise manner. The Offeror is responsible for all costs incurred in responding to this solicitation. All materials and documents submitted in response to this solicitation become the property of the City and will not be returned.

5.4 Offeror’s are reminded that the specifications stated in the solicitation are the minimum level required

and that proposals submitted must be for products or services that meet or exceed the minimum level of all features specifically listed in this solicitation. Proposals offering less than the minimums specified are not responsive and should not be submitted.

5.5 Proposal responses submitted for products considered by the seller to be acceptable alternates to the

brand names or manufacturer’s catalog references specified herein must be submitted with technical literature and/or detailed product brochures for the City’s use to evaluate the products offered. Proposals submitted without this product information may be considered as non-responsive and rejected. The City will be the sole judge as to the acceptability of alternate products offered.

5.6 If provisions of the detailed specifications preclude an otherwise qualified offeror from submitting a

proposal, a written request for modification must be received by the Deputy Finance Director at least




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

seven (7) calendar days prior to the proposal opening. The City may issue an addendum to this solicitation of any approved specification changes.

5.7 Prices shall be submitted on a per unit basis by line item, when applicable. In the event of a disparity

between the unit price and extended price, the unit price shall prevail unless obviously in error. 5.8 Prices offered shall not include applicable state and local taxes. The city will pay all applicable taxes.

For the purposes of determining the lowest cost, the city will not take tax into consideration. Taxes must be listed as a separate item on all invoices.

6. ADDENDA

The City of Phoenix shall not be responsible for any oral instructions made by any employees or officers of the City of Phoenix in regard to the bidding instructions, plans, drawings, specifications, or contract documents. Any changes to the plans, drawings and specifications will be in the form of an addendum, which will be available at https://www.phoenix.gov/solicitations or by calling (602) 262-7181. The offeror shall acknowledge receipt of any/all addendum by signing and returning the document with the proposal submittal.

7. LICENSES If required by law for the operation of the business or work related to this Proposal, Offeror must possess all valid certifications and/or licenses as required by federal, state and local laws at the time of submittal.

8. CERTIFICATION By signature in the offer section of the Offer and Acceptance page, offeror certifies:

The submission of the offer did not involve collusion or other anti-competitive practices.

The offeror shall not discriminate against any employee, or applicant for employment in violation of Federal or State Law.

The offeror has not given, offered to give, nor intends to give at any time hereafter, any economic opportunity, future employment, gift, loan, gratuity, special discount, trip, favor, or service to a public servant in connection with the submitted offer.

9. PRE-PROPOSAL CONFERENCE

Offerors are strongly encouraged to attend the pre-proposal conference at the date and time listed on page 1 of this document.

10. SUBMISSION OF PROPOSAL Proposals must be in the actual possession of the Procurement Division on or prior to the exact time and date

indicated in the Schedule of Events. Late proposals shall not be considered. The prevailing clock shall be the City Finance Department, Procurement Division’s clock. Proposals must be submitted in a sealed envelope and the following information should be noted on the outside of the envelope: Offeror’s Name Offeror’s Address (as shown on the Certification Page) RFP Number RFP Title All proposals must be completed in ink or typewritten. Include the number of copies indicated in the Submittal section.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

11. WITHDRAWAL OF OFFER At any time prior to the solicitation due date and time, an offeror (or designated representative) may withdraw the proposal by submitting a request in writing and signed by a duly authorized representative. Facsimiles, telegraphic or mailgram withdrawals shall not be considered.

12. PROPOSAL RESULTS Proposals will be opened on the proposal due date, time and location indicated in the Schedule of Events at which time the name of each offeror shall be read. Proposals and other information received in response to the Request for Proposal shall be shown only to authorized City personnel having a legitimate interest in them or persons assisting the City in the evaluation. Proposals are not available for public inspection until after award recommendation has been posted on the City’s website.

A preliminary tabulation will be posted on the Procurement Division’s website, https://www.phoenix.gov/finance/business-opportunities/bid-awards-and-recommendations within five (5) calendar days of the proposal opening. The information on the preliminary tabulation will be posted as it was read during the proposal opening. The City makes no guarantee as to the accuracy of any information on the preliminary tabulation. Once the City has evaluated the proposals an award recommendation will be posted on the website. No further notification will be provided to unsuccessful offerors.

13. AWARD OF CONTRACT Award(s) will be made to the overall highest scoring offeror(s). If two or more finalists are tied, the finalist with the lowest cost will be awarded the contract. Notwithstanding any other provision of this solicitation, the City reserves the right to: (1) waive any immaterial defect or informality; or (2) reject any or all proposals or portions thereof; or (3) reissue a solicitation.

A response to a solicitation is an offer to contract with the City based upon the terms, conditions, and specifications contained in the City’s solicitation. Proposals do not become contracts until they are executed by the Deputy Finance Director. A contract has its inception in the award, eliminating a formal signing of a separate contract. For that reason, all of the terms, conditions and specifications of the procurement contract are contained in the solicitation, unless any of the terms, conditions, or specifications are modified by an addendum or contract amendment.

14. CITY’S RIGHT TO DISQUALIFY FOR CONFLICT OF INTEREST The City reserves the right to disqualify any offeror on the basis of any real or apparent conflict of interest that is disclosed by the proposal submitted or any other data available to the City. This disqualification is at the sole discretion of the City. Any offeror submitting a proposal herein waives any right to object now or at any future time, before any body or agency, including but not limited to, the City Council of the City of Phoenix or any court.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

15. OFFEROR’S COMPLIANCE WITH HEALTH, ENVIRONMENTAL AND SAFETY REQUIREMENTS The Offeror’s products, services and facilities shall be in full compliance with all applicable Federal, State and local health, environmental and safety laws, regulations, standards, codes and ordinances, regardless of whether or not they are referred to by the City. At the request of the City representatives, the offeror shall provide the City:

Environmental, safety and health regulatory compliance documents (written safety programs, training and records, permits, etc.) applicable to services requested.

A list of all Federal, State and local citations or notice of violations (including but not limited to EPA, OSHA, Maricopa County) issued against the Offeror or their subcontractors including dates, disposition and resolutions.

The City further reserves the right to make unannounced inspections of the Offeror’s facilities (during normal business hours).

16. PROPOSAL FORMAT The written proposal shall be signed by an individual authorized to bind the Offeror. The proposal shall

provide the name, title, address and telephone number of individuals with authority to contractually bind the company and who may be contacted during the period of the contract. All fees quoted shall be firm and fixed for the full contract period. Each response shall be:

A. Typewritten for ease of evaluation. B. Submitted on 8½ x 11 inch loose leaf paper of at least 30% post-consumer content (no binder, non-

stapled, held together by a clip). C. Set forth in the same sequence as this RFP (i.e., Offerors should respond to this RFP in sequence and

each response should reference the applicable section of this RFP). D. Signed by an authorized representative of the Offeror. E. Submitted with the name(s), title, address, and telephone number of the individual(s) authorized to

negotiate a contract with the City. F. All portions of this RFP contain numbered sections.

17. PREPARATION OF SOLICITATION

All printed, excel spreadsheet, electronic media (CD/DVD, Jump Drive or etc.), build sheets in the Submittal Section must be completed and accurate with your response. It is permissible to copy both sections if necessary. Erasures, interlineations, or other modifications of your solicitation shall be noted by the authorized person signing the solicitation. No submittals shall be altered, amended or withdrawn after the specified solicitation due time and date. The City is not responsible for offeror’s errors or omissions. All time periods stated as a number of days shall be calendar days. Any deviation from this solicitation shall be clearly stated and identified in a separate section titled Request for Consideration of Alternate Terms and must be included with your submittal. Solicitations submitted with additional/alternate terms, conditions or agreements may be considered as non-responsive and rejected. Due to the complexity of the offers and to aid in the evaluation, the offers should contain all required information in tabbed sections as indicated in the electronic spreadsheet. Omissions or alternations of the electronic spreadsheet may be sufficient grounds for the City to consider your offer to be non-compliant.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

The submittal shall include ample written evidence, in the form of technical specification, cut/tear sheets, brochures, pictures, drawing, etc., to demonstrate that all specifications herein have been met and/or exceeded. There is a page maximum for certain parts of the proposal. Other sections are not to be included as part of the maximum page limits. The page maximum limited sections are indicated in the Section description following this paragraph. Any proposal exceeding the total number of pages allowed for the proposal may not be considered in the evaluation. The total number of pages allowed for this proposal is 35 (thirty-five) pages. Any section listed as “Section Subject to Page Limit” will count toward the maximum number of pages allowed. The City requires that the responding RFP be organized in the following major sections:

A. Fee Schedule (Attachment A)

Each proposer shall complete this attachment with all fees associated with implementing the EMS, a one (1) year warranty period following Final Acceptance and annual maintenance fees for 4 additional years on a year by year basis. Separate Phase 1 fees from Phase 2 and Phase 3, the latter two items are considered Add-Alternates to be implemented at the City’s discretion. The annual maintenance fees listed in this attachment shall be used in any agreement options exercised by the City. In addition applicable hourly rates for implementation services should be listed by skillset on an hourly basis. These hourly rates will also be used in any change order process. Hourly rates for post implementation years shall also be disclosed.

B. Compliance Matrix (Attachment B)

For each requirement listed in Attachment B, the proposer must list one of the following responses in the Compliance Code column:

1. WC – to indicate the proposed system will comply with the requirement as part of the core systems 2. RD – to indicate that the proposed system requires development to comply with the requirement 3. IN – to indicate that the proposed system requires the integration with a 3rd party

tool/object/component to comply with the requirement and that this tool/object/component shall be delivered to the City as part of this project

4. NC – to indicate the proposed system will not comply with the requirement

Certain items cannot be non-compliant. Those items are identified in Attachment B Compliance Matrix and a “NC” or non-compliance with those identified items will cause the proposal to be rejected as non-responsive as indicated by the cell being shaded in black.

For each “RD,” “IN,” or “NC” response, the proposer must provide an explanation. Fees associated with all items for which the proposer responded “WC,” “RD,” or “IN” must be included in the proposed Fee Schedule either individually or as a grouping, if appropriate.

C. EMS Functionality (Section subject to page limit)

In addition to the Compliance Matrix, each proposer shall provide a written description of its proposed EMS system functionality. This description should, at a minimum, address each bullet item in Section 18(a) on page 13, Evaluation Criteria, and includes: • System flowchart indicating all major components needed to fulfill the requirements set forth in Scope

of Services, and Attachment C, System Specification Document.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

• Ability to provide key pieces of data, information, and reporting to various internal and external stakeholders, including Aviation Emergency Operations, Aviation Information Technology, City Audit, Law, and external parties (Police, Fire, etc.).

• Ease of interfacing with the stated systems needed for integration by phase. Discuss means and methods for maintaining interfaces in phase with new versions of the systems as they are generally released to the public. Discuss both internal and customer testing of new versions of the interfaces and any expected lag times needed for upgrade planning. Indicate the specific integrations by phase.

• All anticipated customizations, described in detail, and identification of fees on the Attachment A, Fee Schedule, associated with such customizations.

• Anticipated future roadmap for the product and how the application will be continually improved and upgraded. Indicate any industry trade groups, associations that are relevant to the system. Include any user groups that are sponsored any how new functionality is incorporated into the product.

• Include the methods to implement the EMS with little or no modification of proprietary application code.

• Discuss how you provision the software product with the highest levels of stability and data/information security.

• Indicate the application software product usability features, ease of operation to the City, training methodology and delivery for the initial implementation, any subsequent phases, and ongoing post versions.

• Include the approach to initial implementation (first two (2) weeks of go-live) and support during the 60-day endurance period.

• Discuss compliance to project management, quality assurance, testing delivery, testing tools, and how to manage necessary time needed from Aviation Department staff, the accessibility of successful proposer management team corporate hierarchy and any flexibility constraints (for example development/support done offshore).

If there are any inconsistencies between Attachment B, Compliance Matrix, and this description, Attachment B will govern.

D. Qualifications and Experience Statement (Section subject to page limit)

Each offeror shall identify its project manager and key personnel (proposed team) to be assigned to this project and submit information to address each bullet item on page 13, Section 18(d), for each team member as well as for the proposer. In describing experience implementing preference would be given for airport-specific EMS solutions where Airport Operations is responsible to dispatch resources, other citations may include airport-specific EMS installations where Operations does not dispatch resources, and non-airport installations. Proposers should detail the number of years the installation was active in a production mode as well as the names and categories of airports or installations at which it and/or its team members have provided these services. Provide references for each implementation sited that may be contacted, if required. Confirm that the key staff presented can be committed for the initial phase completion of the project. Include any restrictions related to travel and to be on-site when required. Indicate current and expected workloads that may impact availability. Indicate any resources needed either on-site, off-site, equipment, and support. All fees of such resources are to be included in the deliverables. There are no reimbursable expenses to be allowed for any staff. All such fees need to be included in the project Fee Schedule Attachment A. The City reserves the right to approve any staffing changes for the key staff designated on the project once there is an agreement. Furthermore, the Successful Proposer must insure any approved changes follow an orderly handover with all costs related to the handover be borne by the Successful Proposer




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

and having no impact to the agreed to project delivery schedule without authorization from the City Project Manager. All third parties consultants associated to the proposal must be identified in the proposal. Include names, addresses, telephone numbers, responsibilities, and/or product supplied. Indicate historical information, including past project of similar scope and indicate why the consultant is required for the project. Include resumes of primary consultants in the resume section. Briefly describe business history, overall corporate experience, and any potential risks to completing the project including current or expected litigation, threatened litigation, investigation, reorganization, receivership, filing, strikes, audit, corporate acquisition, unpaid judgments or other actions.

E. Scope of Work (Section subject to page limit)

In accordance with the Scope of Work, each offeror shall provide an executive summary describing each of the following components of the proposer’s Approach to Scope:

Overall Approach to Project Management Methodology

Approach to collaborating with stakeholders in the development of process enhancements and workflow improvements to reduce or eliminate the need for application customization

Organizational chart depicting roles and responsibilities of project manager and proposed team

Project timeline including all key phases (planning, development, data migration, testing, etc.), dependencies, (such as proposed project resources) and key project milestones

Proposed schedule and availability of project manager and proposed team

System Design and Implementation Plan

Overall project schedule in basic milestones incorporating the elements stated in the Scope of Work. Note: this will be refined once the Successful Proposer is chosen.

Approach to achieving and maintaining 99.9% system availability; how this can measured and enforced for application design issues that can be attributed to the product

Approach to achieving and maintaining a reasonable user experience in terms of response times attributable to the application design; how this can be measured and enforced

Approach to identifying data to be migrated and to successfully migrating that data to the proposed System

Approach to timely and low-impact software product upgrades

Cost-saving options that do not conflict with system components labeled “NC” in Attachment B Compliance Matrix

Implementation Plan for System implementation that will not interrupt on-going operations

Testing strategies, testing tools, and Test plans, in compliance with the Scope of Work

Training plan, in compliance with the Scope of Work

Budget and Invoicing Invoicing will be for project deliverables delivered and accepted by the City. Under certain

conditions, they City may agree to be invoiced for non-completed deliverables if the progress can easily be measured and the expected deliverable is of long durations. Such cases will need to be negotiated with the City Project Manager. Upon contract award, the Successful Proposer will submit a finalized Deliverables Log (see Exhibit C Sample Deliverables Log) with a value assigned to each deliverable. These can be invoiced in the month following City Acceptance of that deliverable. The City will reserve the final 10% of the project value to be released upon completion of the 60-day Endurance Test period.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Each proposer shall also provide its complete proposed Warranty and Maintenance Plan, in compliance with the Scope of Work.

F. Project Team Resumes

Include for key personnel proposed on page 10, section 17(d), a two (2) page resume highlighting project relevant experience. Include years with current company, years with any previous company, as well as education and training. Resumes shall state clearly any experience specifically related to the Scope of Services and list any similar work successfully completed. Provide a minimum of two (2) references including name of person, phone number, and email address for evaluation.

G. Changes, Exceptions and Deviations

The Offeror shall provide a detailed description of any and all changes, exceptions, or deviations from the requirements set forth in any part of this solicitation.

18. EVALUATION CRITERIA

In accordance with the City of Phoenix Administrative Regulation, 3.10, Competitive Sealed Proposal awards shall be made to the responsible offeror(s) whose proposal is determined in writing to be the most advantageous to the City based upon the evaluation criteria listed below. The evaluation factors are listed in the relative order of importance. A. EMS System Functionality—Compliance Matrix Attachment B — 500 points – Proposed EMS functionality, including compliance with project requirements – Compliance to Aviation Department open architecture, ease of developing and supporting integrations, demonstration of industry and user long-term commitment, ease of support and maintenance – Requirements listed on page 9, Sections 17(a) and (b) B. Fees — 200 points – Phase 1 Total Fees and Pricing Elements – Add alternate: Phase 2 Total Fees and Pricing Elements – Add alternate: Phase 3 Total Fees and Pricing Elements C. Approach to Scope of Services – 150 points – Overall approach to project management methodology – System design and implementation plan – Maintenance plan – Adherence to elements set for in Attachment C – Requirements listed on page 11, Section 17(e) D. Qualifications & Experience of Offeror and Offeror’s Team — 150 points – Experience implementing event management systems at similar airports in size and scope, or other similar installations – Qualifications, certifications, skills, and training associated with security credentialing applications and technologies – Apparent stability of project team and key staff




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

– Requirements listed on page 11 Section 17(d) The overall completeness, accuracy, and quality of the proposal may be taken into consideration.

19. CLARIFICATION AND DEMONSTRATION PROCESS

Offerors may be invited to make a presentation and a product demonstration from a City-provided script, based on the elements listed in Attachment D, Business Use Cases. All Offerors invited to participate will be provided the same script for demonstration. If invited, the Purchasing Office will notify the Offerors of the date and time of the presentation. If demonstrations are conducted, the Purchasing Office shall issue a written request for best and final offers. The request shall set forth the date, time and place for the submission of the best and final offer. The City reserves the right to request clarification on any aspect of an Offeror’s proposal. Demonstrations/Presentations will be solicited only from firms whose proposals are susceptible to being selected for award.

20. INQUIRIES

All questions that arise relating to this solicitation shall be directed in writing to: Ray Nader City of Phoenix, Finance Department 251 W. Washington Street, 8th Floor Phoenix, Arizona 85003 To be considered, written inquiries shall be received at the above address by Friday, January 8, 2016, 2:00 p.m., local Arizona time. Written inquiries may be emailed to [email protected]. Inquiries received will then be answered in an addendum and published on the Procurement Website. No informal contact initiated by Offerors on the proposed service will be allowed with members of City’s staff from date of distribution of this solicitation until after the closing date and time for the submission of proposals. All questions concerning or issues related to this solicitation shall be presented in writing.

21. SOLICITATION TRANSPARENCY POLICY Commencing on the date and time a solicitation is published, potential or actual offerors or respondents(including their representatives) shall only discuss matters associated with the solicitation with the Mayor, any members of City Council, the City Manager, any Deputy City Manager, or any department director directly associated with the solicitation (including in each case their assigned staff, except for the designated procurement officer) at a public meeting, posted under Arizona Statutes, until the resulting contract(s) are awarded to all offers or responses are rejected and the solicitation is cancelled without any announcement by the Procurement Officer of the City’s intent to reissue the same or similar solicitation. As long as the solicitation is not discussed, Offerors may continue to conduct business with the City and discuss business that is unrelated to the solicitation with the City staff who is not involved in the selection process.

Offerors may discuss their proposal or the solicitation with the Mayor or one or more members of the Phoenix City Council, provided such meetings are scheduled through the Procurement Officer conducted in person at 251 West Washington, Phoenix, Arizona, 85003, and are posted as open meetings with the City Clerk at least twenty-four (24) hours prior to the scheduled meetings. The City Clerk will be responsible for posting the




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

meetings. The posted notice shall identify the participants and the subject matter, as well as invite the public to participate. With respect to the selection of the successful Offerors, the City Manager and/or City Manager's Office will continue the past practice of exerting no undue influence on the process. In all solicitations of bids and proposals, any direction on the selection from the City Manager and/or City Manager's Office and Department Head (or representative) to the proposal review panel or selecting authority must be provided in writing to all prospective offerors. This policy is intended to create a level playing field for all Offerors, assure that contracts are awarded in public, and protect the integrity of the selection process. Offerors that violate this policy shall be disqualified.

22. PROTEST PROCESS Staff recommendations to award the contract(s) to a particular offeror or offerors shall be posted on the Procurement Division’s website https://www.phoenix.gov/finance/business-opportunities/bid-awards-and-recommendations. Any unsuccessful bidder may file a protest no later than 7 calendar days after the recommendation is posted on the website. All protests shall be in writing, filed with the Procurement Authority identified in the solicitation and include the following:

Identification of the IFB or other solicitation number;

The name, address and telephone number of the protester;

A detailed statement describing the legal and factual grounds for the protest, including copies of relevant documents;

The form of relief requested; and

The signature of the protester or its authorized representative.

The Procurement Authority will render a written decision within a reasonable period of time after the protest is filed. The City will not request City Council authorization to award the contract until the protest process is completed.

SECTION II - STANDARD TERMS AND CONDITIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1. DEFINITION OF KEY WORDS USED IN THE SOLICITATION

Shall, Will, Must: Indicates a mandatory requirement. Failure to meet these mandatory requirements may result in the rejection of proposal as non-responsive.

Should: Indicates something that is recommended but not mandatory. If the offeror fails to provide recommended information, the City may, at its sole option, ask the offeror to provide the information or evaluate the offer without the information.

May: Indicates something that is not mandatory but permissible.

For purposes of this solicitation, the following definitions shall apply: “A.R.S.” Arizona Revised Statute “Broker, Packager, A firm that is not a manufacturer or regular dealer as defined Manufacturer’s Representative, herein and whose role is limited to that of an extra participant in Jobber” a transaction, contract or project through which fund are passed

in order to obtain services, materials, equipment or product. “Buyer” City of Phoenix, City Procurement Division staff person

responsible for the solicitation. “CBP” U.S. Customs and Border Control. "City" The City of Phoenix "Contractor" The individual, partnership, or corporation who, as a result of the

competitive process, is awarded a contract by the City of Phoenix.

"Contract/Agreement" The legal agreement executed between the City of Phoenix, AZ

and the Contractor. "Contract Representative" The City employee or employees who have specifically been

designated to act as a contact person or persons to the Contractor, and responsible for monitoring and overseeing the Contractor's performance under this contract.

“Days” Means calendar days unless otherwise specified. “Deputy Finance Director” The contracting authority for the City of Phoenix, AZ, authorized

to sign contracts and amendments thereto on behalf of the City of Phoenix, AZ.

“Employer” Any individual or type of organization that transacts business in

this state, that has a license issued by an agency in this state and employs one or more employees in this state. Employer includes this state, any political subdivision of this state and self-employed persons. In the case of an independent contractor,




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

employer means the independent contractor and does not mean the person or organization that uses contract labor. (A.R.S. 23-211).

“EPA” Environmental Protection Agency “FIFRA” Federal Insecticide, Fungicide and Rodenticide Act “FIS” Federal Inspection Services. “Manufacturer” A firm that operates or maintains a factory or establishment that produces on the premises, the materials, supplies, articles or

equipment required under the contract. “Offer” Means bid or quotation. “Regular Dealer” A firm that owns, operates, or maintains a store, warehouse, or

other establishment in which the materials, supplies, articles or equipment of the general character described by the specifications are bought, kept in stock, and regularly sold or leased to the public in the usual course of business. An established, regular business that engages, as its principal business and under its own name, in the purchase and sale or lease of the products in question.

“Offeror” Means a vendor who responds to the Request for Proposal. “Solicitation” Means a Request for Proposal (RFP). “Suppliers” Firms, entities or individuals furnishing goods or services directly

to the City. “Vendor” A seller of goods or services.

2. CONTRACT INTERPRETATION

2.1 APPLICABLE LAW: This Contract shall be governed by the law of the State of Arizona, and suits pertaining to this Contract shall be brought only in Federal or State courts in Maricopa County, State of Arizona.

2.2 IMPLIED CONTRACT TERMS: Each and every provision of law and any clause

required by law to be in the Contract shall be read and enforced as though it were included herein, and if through mistake or otherwise any such provision is not inserted, or is not correctly inserted, then upon the application of either party the Contract shall forthwith be physically amended to make such insertion or correction.

2.3 CONTRACT ORDER OF PRECEDENCE: In the event of a conflict in the provisions of

the Contract, as accepted by the City and as they may be amended, the following shall prevail in the order set forth below:

A. Special terms and conditions B. Standard terms and conditions




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

C. Statement or scope of work D. Specifications E. Attachments F. Exhibits G. Instructions to Offerors H. Other documents referenced or included in the Request for proposal.

2.4 ORGANIZATION – EMPLOYMENT DISCLAIMER: The Agreement resulting hereunder

is not intended to constitute, create, give rise to or otherwise recognize a joint venture agreement or relationship, partnership or formal business organization of any kind, and the rights and obligations of the parties shall be only those expressly set forth in the agreement. The parties agree that no persons supplied by the Contractor in the performance of Contractor’s obligations under the agreement are considered to be City’s employees and that no rights of City civil service, retirement or personnel rules accrue to such persons. The Contractor shall have total responsibility for all salaries, wage bonuses, retirement, withholdings, workmen’s compensation, occupational disease compensation, unemployment compensation, other employee benefits and all taxes and premiums appurtenant thereto concerning such persons, and shall save and hold the City harmless with respect thereto.

2.5 SEVERABILITY: The provisions of this Contract are severable to the extent that any

provision or application held to be invalid shall not affect any other provision or application of the contract which may remain in effect without the invalid provision or application.

2.6 NON-WAIVER OF LIABILITY: The City of Phoenix as a public entity supported by tax

monies, in execution of its public trust, cannot agree to waive any lawful or legitimate right to recover monies lawfully due it. Therefore, any Contractor agrees that it will not insist upon or demand any statement whereby the City agrees to limit in advance or waive any right the City might have to recover actual lawful damages in any court of law under applicable Arizona law.

2.7 PAROL EVIDENCE: This Agreement is intended by the parties as a final expression of

their agreement and is intended also as a complete and exclusive statement of the terms of this agreement. No course of prior dealings between the parties and no usage in the trade shall be relevant to supplement or explain any term used in this Contract. Acceptance or acquiescence in a course of performance rendered under this contract shall not be relevant to determine the meaning of this Contract even though the accepting or acquiescing party has knowledge of the nature of the performance and opportunity to object.

3. CONTRACT ADMINISTRATION AND OPERATION

3.1 RECORDS: All books, accounts, reports, files and other records relating to the contract

shall be subject at all reasonable times to inspection and audit by the City for five years after completion of the contract. Such records will be produced at a City of Phoenix office as designated by the City.

3.2 PUBLIC RECORD: All proposals submitted in response to this invitation shall become

the property of the City and become a matter of public record available for review pursuant to Arizona State law.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

If an offeror believes that a specific section of its proposal response is confidential, the offeror shall isolate the pages marked confidential in a specific and clearly labeled section of its proposal response. The offeror shall include a written statement as to the basis for considering the marked pages confidential including the specific harm or prejudice if disclosed and the City Procurement Division will review the material and make a determination.

3.3 CONFIDENTIALITY AND DATA RECORD: All data, regardless of form, including

originals, images and reproductions, prepared by, obtained by, or transmitted to Contractor or its subcontractors in connection with this Agreement is confidential, proprietary information owned by the City. Except as specifically provided in this Agreement, the Contractor and its subcontractors shall not disclose data generated in the performance of the service to any third person without the prior written consent of the City Manager, or his/her designee. Personal identifying information, financial account information, or restricted City information, whether electronic format or hard copy, must be secured and protected at all times, in accordance with federal, state and local law and, if applicable, in compliance with Payment Card Industry Data Security Standards, to avoid unauthorized access. At a minimum, Contractor must encrypt and/or password protect electronic files. This includes data saved to laptop computers, computerized devices or removable storage devices.

When personal identifying information, financial account information, or restricted City information, regardless of its format, is no longer necessary, the information must be redacted or destroyed through appropriate and secure methods that ensure the information cannot be viewed, accessed or reconstructed. In the event that data collected or obtained by the Contractor in connection with this Agreement is believed to have been compromised, Contractor shall notify the Department's Deputy Chief Information Officer immediately. Contractor agrees to reimburse the City for any costs incurred by the City to investigate potential breaches of this data and, where applicable, the cost of notifying individuals who may be impacted by the breach. Contractor agrees that the requirements of this section shall be incorporated into all subcontractor agreements entered into by the Contractor. It is further agreed that a violation of this section shall be deemed to cause irreparable harm justifies injunctive relief in court. A violation of this section may result in immediate termination of this agreement without notice. The obligations of Contractor under this section shall survive the termination of this Agreement.

3.4 DISCRIMINATION PROHIBITED: Contractor agrees to abide by the provisions of the

Phoenix City Code Chapter 18, Article V as amended.

Any supplier/lessee in performing under this contract shall not discriminate against any worker, employee or applicant, or any member of the public, because of race, color, religion, sex, national origin, age or disability nor otherwise commit an unfair employment practice. The supplier and/or lessee shall take action to ensure that applicants are employed, and employees are dealt with during employment without regard to their race, color, religion, sex, or national origin, age or disability and adhere to a policy to pay equal compensation to men and women who perform jobs that require substantially equal skill,




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

effort and responsibility, and that are performed within the same establishment under similar working conditions. Such action shall include but not be limited to the following: Employment, promotion, demotion or transfer, recruitment or recruitment advertising, layoff or termination; rates of pay or other forms of compensation; and selection for training; including apprenticeship. The supplier further agrees that this clause will be incorporated in all subcontracts with all labor organizations furnishing skilled, unskilled and union labor, or who may perform any such labor or services in connection with this contract. Supplier/lessee further agrees that this clause will be incorporated in all subcontracts, job-consultant agreements or subleases of this agreement entered into by supplier/lessee.

3.5 LICENSES AND PERMITS: Contractor shall keep current Federal, State, and local

licenses and permits required for the operation of the business conducted by the Contractor as applicable to this contract.

3.6 ADVERTISING: Contractor shall not advertise or publish news releases concerning this

contract without the prior written consent of the Deputy Finance Director, and the City shall not unreasonably withhold permission.

3.7 EXCLUSIVE POSSESSION: All services, information, computer program elements, reports, and other deliverables which may be created under this contract are the sole property of the City of Phoenix and shall not be used or released by the Contractor or any other person except with prior written permission by the City.

3.8 OWNERSHIP OF INTELLECTUAL PROPERTY: Any and all intellectual property,

including but not limited to copyright, invention, trademark, trade name, service mark, and/or trade secrets created or conceived pursuant to or as a result of this contract and any related subcontract (“Intellectual Property”), shall be considered work for hire and the City shall be considered the creator of such Intellectual Property. The agency, department, division, board or commission of the City requesting the issuance of this contract shall own (for and on behalf of the City) the entire right, title and interest to the Intellectual Property throughout the world. Contractor shall notify the City, within thirty (30) days, of the creation of any Intellectual Property by it or its subcontractor(s). Contractor, on behalf of itself and any subcontractor(s), agrees to execute any and all document(s) necessary to assure ownership of the Intellectual Property vests in the City and shall take no affirmative actions that might have the effect of vesting all or part of the Intellectual Property in any entity other than the City. The Intellectual Property shall not be disclosed by Contractor or its subcontractor(s) to any other entity without the express written authorization of the City. If by operation of law, the Intellectual Property is not owned in its entirety by the City automatically upon its creation, then Contractor agrees to assign and hereby assigns to the City the ownership of the Intellectual Property. The Contractor agrees to take such further action and execute and deliver such further agreements and other instruments as the City may reasonably request to give effect to this section 3.8.

It is expressly agreed by Contractor that these covenants are irrevocable and perpetual.

3.9 HEALTH, ENVIRONMENTAL AND SAFETY REQUIREMENTS: The Contractor’s

products, services and facilities shall be in full compliance with all applicable Federal, State and local health, environmental and safety laws, regulations, standards, codes and ordinances, regardless of whether or not they are referred to by the City.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

At the request of City representatives, the Contractor shall provide the City:

Environmental, safety and health regulatory compliance documents (written safety programs, training records, permits, etc.) applicable to services provided by the Contractor in this contract

A list of all federal, state, or local (EPA, OSHA, Maricopa County, etc.) citations or notice of violations issued against their firm or their subcontractors including dates, reasons, dispositions and resolutions.

The City shall have the right, but not the obligation to inspect the facilities, transportation vehicles or vessels, containers and disposal facilities provided by the Contractor or subcontractor. The City shall also have the right to inspect operations conducted by the Contractor or subcontractor in the performance of this agreement.

3.10 COMPLIANCE WITH LAWS: Contractor agrees to fully observe and comply with all applicable Federal, State and local laws, regulations, standards, codes and ordinances when performing under this Contract regardless of whether or not they are referred to by the City. Contractor agrees to permit City inspection of Contractor’s business records, including personnel records to verify any such compliance.

Because the Contractor will be acting as an independent contractor, the City assumes no responsibility for the Contractor’s acts.

3.11 LAWFUL PRESENCE REQUIREMENT: Pursuant to A.R.S. §§ 1-501 and -502, the City of Phoenix is prohibited from awarding a contract to any natural person who cannot established that he or she is lawfully present in the United States. In order to establish lawful presence, this person must produce qualifying identification and sign a City-provided affidavit affirming that the identification provided is genuine. This requirement will be imposed at the time of contract award. In the event the prevailing responder is unable to satisfy this requirement, the City will offer the award to the next-highest scoring responder. The law does not apply to fictitious entities such as corporations, partnerships and limited liability companies.

3.12 CONTINUATION DURING DISPUTES: Contractor agrees that notwithstanding the existence of any dispute between the parties, insofar as is possible, under the terms of the contract, the Contractor shall continue to perform the obligations required of Contractor during the continuation of any such dispute unless enjoined or prohibited by an Arizona Court of competent jurisdiction.

3.13 EMERGENCY PURCHASES: The City reserves the right to purchase from other

sources those items which are required on an emergency basis and cannot be supplied immediately from stock by the Contractor.

3.14 STRICT PERFORMANCE: Failure of either party to insist upon the strict performance of

any item or condition of the contract or to exercise or delay the exercise of any right or remedy provided in the contract, or by law, or the acceptance of materials or services, obligations imposed by this contract or by law shall not be deemed a waiver of any right of either party to insist upon the strict performance of the contract.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

4. COSTS AND PAYMENTS 4.1 PAYMENT TERMS: The City shall make every effort to process payment for the

purchase of material or services within 30 calendar days after receipt of a correct invoice unless a good faith dispute exists to any obligation to pay all or a portion of the account. Payment terms are specified in the proposal.

4.2 PAYMENT DEDUCTION OFFSET PROVISION: Contractor acknowledges that the City

Charter requires that no payment be made to any Contractor as long as there is an outstanding obligation due to the City. Contractor agrees that any obligation it owes to the City will be offset against any payment due to the Contractor from the City.

4.3 LATE SUBMISSION OF CLAIM BY CONTRACTOR: The City will not honor any

invoices or claims which are tendered one (1) year after the last item of the account accrued.

4.4 DISCOUNTS: Payment discounts will be computed from the date of receiving

acceptable products, materials and/or services or correct invoice, whichever is later to the date payment is mailed.

4.5 NO ADVANCE PAYMENTS: Advance payments are not authorized. Payment will be

made only for actual services or commodities that have been received. 4.6 FUND APPROPRIATION CONTINGENCY: The Vendor recognizes that any agreement

entered into shall commence upon the day first provided and continue in full force and effect until termination in accordance with its provisions. The Vendor and the City herein recognize that the continuation of any contract after the close of any given fiscal year of the City of Phoenix, which fiscal year ends on June 30 of each year, shall be subject to the approval of the budget of the City of Phoenix providing for or covering such contract item as an expenditure therein. The City does not represent that said budget item will be actually adopted, said determination being the determination of the City Council at the time of the adoption of the budget.

4.7 MAXIMUM PRICES: The City shall not be invoiced at prices higher than those stated in

any contract resulting from this proposal. Offeror certifies, by signing this proposal that the prices offered are no higher than the lowest price the Offeror charges other buyers for similar quantities under similar conditions. Offeror further agrees that any reductions in the price of the goods or services covered by this proposal and occurring after award will apply to the undelivered balance. The offeror shall promptly notify the City of such price reductions.

4.8 F.O.B. POINT: All prices are to be quoted F.O.B. delivered, unless otherwise specified

elsewhere in this solicitation.

5. CONTRACT CHANGES 5.1 CONTRACT AMENDMENTS: Contracts shall be modified only by a written contract

amendment signed by the Deputy Finance Director and persons duly authorized to enter into contracts on behalf of the Contractor.

5.2 ASSIGNMENT - DELEGATION: No right or interest in this contract nor monies due

thereunder shall be assigned in whole or in part without written permission of the City,




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

and no delegation of any duty of Contractor shall be made without prior written permission of the Deputy Finance Director, which may be withheld for good cause. Any assignment or delegation made in violation of this section shall be void.

5.3 NON-EXCLUSIVE CONTRACT: Any contract resulting from this solicitation shall be

awarded with the understanding and agreement that it is for the sole convenience of the City of Phoenix. The City reserves the right to obtain like goods or services from another source when necessary.

5.4 AUTHORIZED CHANGES: The City reserves the right at any time to make changes in

any one or more of the following: (a) specifications; (b) methods of shipment or packing; (c) place of delivery; (d) time of delivery; and/or (e) quantities. If the change causes an increase or decrease in the cost of or the time required for performance, an equitable adjustment may be made in the price or delivery schedule, or both. Any claim for adjustment shall be deemed waived unless asserted in writing within thirty (30) days from the receipt of the change. Price increases or extensions of delivery time shall not be binding on the City unless evidenced in writing and approved by the Deputy Finance Director prior to the institution of the change.

6. RISK OF LOSS AND LIABILITY 6.1 TITLE AND RISK OF LOSS: The title and risk of loss of material or service shall not

pass to the City until the City actually receives the material or service at the point of delivery; and such loss, injury, or destruction shall not release seller from any obligation hereunder.

6.2 ACCEPTANCE: All material or service is subject to final inspection and acceptance by the City. Material or service failing to conform to the specifications of this contract shall be held at Contractor's risk and may be returned to the Contractor. If so returned, all costs are the responsibility of the Contractor. Noncompliance shall conform to the cancellation clause set forth in this document.

6.3 GENERAL INDEMNIFICATION: Contractor shall indemnify, defend, save and hold

harmless the City of Phoenix and its officers, officials, agents, and employees (hereinafter referred to as “Indemnitee”) from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorneys’ fees, and costs of claim processing, investigation and litigation) (hereinafter referred to as “Claims”) for bodily injury or personal injury (including death), or loss or damage to tangible or intangible property caused, or alleged to be caused, in whole or in part, by the negligent or willful acts or omissions of Contractor or any of its owners, officers, directors, agents, employees or subcontractors. This indemnity includes any claim or amount arising out of or recovered under the Workers’ Compensation Law or arising out of the failure of such Contractor to conform to any Federal, State or local law, statute, ordinance, rule, regulation or court decree. It is the specific intention of the parties that the Indemnitee shall, in all instances, except for Claims arising solely from the negligent or willful acts or omissions of the Indemnitee, be indemnified by Contractor from and against any and all claims. It is agreed that Contractor will be responsible for primary loss investigation, defense and judgment costs where this indemnification is applicable. In consideration of the award of this contract, the Contractor agrees to waive all rights of subrogation against the City, its officers, officials, agents, and employees for losses arising from the work performed by the Contractor for the City.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.4 INDEMNIFICATION – PATENT, COPYRIGHT AND TRADEMARK. The Contractor shall indemnify and hold harmless the City against any liability, including costs and expenses, for infringement of any patent, trademark or copyright or other proprietary rights of any third parties arising out of contract performance or use by the City of materials furnished or work performed under this contract. The Contractor agrees upon receipt of notification to promptly assume full responsibility for the defense of any suit or proceeding which is, has been, or may be brought against the City of Phoenix and its agents for alleged infringement, as well as for the alleged unfair competition resulting from similarity in design, trademark or appearance of goods by reason of the use or sale of any goods furnished under this contract and the Contractor further agrees to indemnify the City against any and all expenses, losses, royalties, profits and damages including court costs and attorney’s fees resulting from the bringing of such suit or proceedings including any settlement or decree of judgment entered therein. The City may be represented by and actively participate through its own counsel in any such suit or proceedings if it so desires. It is expressly agreed by the seller that these covenants are irrevocable and perpetual.

6.5 FORCE MAJEURE: Except for payment of sums due, neither party shall be liable to the

other nor deemed in default under this contract if and to the extent that such party's performance of this contract is prevented by reason of force majeure. The term "force majeure" means an occurrence that is beyond the control of the party affected and occurs without its fault or negligence. Force majeure shall not include late performance by a subcontractor unless the delay arises out of a force majeure occurrence in accordance with this force majeure term and condition. If either party is delayed at any time in the progress of the work by force majeure, the delayed party shall notify the other party in writing of such delay, as soon as is practical, of the commencement thereof and shall specify the causes of such delay in such notice. Such notice shall be hand-delivered or mailed certified-return receipt and shall make a specific reference to this provision, thereby invoking its provisions. The delayed party shall cause such delay to cease as soon as practicable and shall notify the other party in writing when it has done so. The time of completion shall be extended by contract modification for a period of time equal to the time that results or effects of such delay prevent the delayed party from performing in accordance with this contract.

6.6 LOSS OF MATERIALS: The City does not assume any responsibility, at any time, for the protection of or for loss of materials, from the time that the contract operations have commenced until the final acceptance of the work by the project manager.

6.7 DAMAGE TO CITY PROPERTY: Contractor shall perform all work so that no damage to

the building or grounds results. Contractor shall repair any damage caused to the satisfaction of the City at no cost to the City.

Contractor shall take care to avoid damage to adjacent finished materials that are to remain. If finished materials are damaged, Contractor shall repair and finish to match existing material as approved by the City at Contractor's expense.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7. WARRANTIES

7.1 GUARANTEE: Unless otherwise specified, all items shall be guaranteed for a minimum

period of one (1) year from date of acceptance by the City against defects in material and

workmanship. At any time during that period, if a defect should occur in any item that item

shall be replaced or repaired by the Contractor at no obligation to the City except where it

be shown that the defect was caused by misuse and not by faulty design. 7.2 QUALITY: Contractor expressly warrants that all goods or services furnished under this

contract shall conform to the specifications, appropriate standards, and will be new and free from defects in material or workmanship. Contractor warrants that all such goods or services will conform to any statements made on the containers or labels or advertisements for such goods, or services, and that any goods will be adequately contained, packaged, marked and labeled. Contractor warrants that all goods or services furnished hereunder will be merchantable, and will be safe and appropriate for the purpose which goods or services of that kind are normally used. If Contractor knows or has reason to know the particular purpose for which City intends to use the goods or services, Contractor warrants that goods or services furnished will conform in all respect to samples. Inspection, test, acceptance of use of the goods or services furnished hereunder shall not affect the Contractor’s obligation under this warranty, and such warranties shall survive inspection, test, acceptance and use. Contractor’s warranty shall run to City, its successors, and assigns.

7.3 RESPONSIBILITY FOR CORRECTION: It is agreed that the Contractor shall be fully

responsible for making any correction, replacement, or modification necessary for specification or legal compliance. In the event of any call back, Contractor agrees to give the City first priority. Contractor agrees that if the product or service offered does not comply with the foregoing, the City has the right to cancel the purchase at any time with full refund within 30 calendar days after notice of non-compliance and Contractor further agrees to be fully responsible for any consequential damages suffered by the City.

7.4 LIENS: Contractor shall hold the City harmless from claimants supplying labor or

materials to the Contractor or his subcontractors in the performance of the work required under this contract. Contractor shall provide written certification that all liens against materials and labor have been satisfied, before the City will make payment.

7.5 QUALITY STANDARDS OF MATERIAL AND SERVICES: If desired by the City,

items/services proposal shall be subjected to testing, dissection or analysis by a recognized testing laboratory or consultant selected by the City to determine that the material(s) submitted for proposal conform to the proposal specifications. The cost of testing, dissection or analysis shall be borne by the offeror.

7.6 REPAIR AND REPLACEMENT PARTS: Repair or replacement parts for existing

equipment may be accomplished by the Contractor using other than original equipment manufacturer's (OEM) parts. However, all parts or equipment furnished must be equal or exceed that of the original equipment manufacturer(s) in material and warranty.

7.7 WORKMANSHIP: Where not more specifically described in any of the various sections

of these specifications, workmanship shall conform to all of the methods and operations of best standards and accepted practices of the trade or trades involved, and shall include all items of fabrication, construction or installation regularly furnished or required




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

for completion of the services. All work shall be executed by personnel skilled in their respective lines of work.

8. CITY’S CONTRACTUAL RIGHTS

8.1 RIGHT TO ASSURANCE: Whenever one party to this contract in good faith has reason

to question the other party's intent to perform, the former party may demand that the other party give a written assurance of this intent to perform. In the event that a demand is made and no written assurance is given within five (5) days, the demanding party may treat this failure as an anticipatory repudiation of this contract.

8.2 NON-EXCLUSIVE REMEDIES: The rights and remedies of the City under this Contract

are non-exclusive. 8.3 DEFAULT IN ONE INSTALLMENT TO CONSTITUTE BREACH: Each installment or lot

of the agreement is dependent on every other installment or lot and a delivery of non-conforming goods or a default of any nature under one installment or lot will impair the value of the whole agreement and constitutes a total breach of the agreement as a whole.

8.4 ON TIME DELIVERY: Because the City is providing services which involve health,

safety and welfare of the general public, delivery time is of the essence. Delivery must be made in accordance with the delivery schedule promised by the Offeror.

8.5 DEFAULT: In case of default by the offeror, the City may, by written notice, cancel this

contract and repurchase from another source and may recover the excess costs by (1) deduction from an unpaid balance due; (2) collection against the proposal and/or performance bond, or (3) a combination of the aforementioned remedies or other remedies as provided by law.

8.6 COVENANT AGAINST CONTINGENT FEES: Seller warrants that no person or selling

agent has been employed or retained to solicit or secure this contract upon an agreement or understanding for a commission, percentage, brokerage, or contingent fee, excepting bona fide employers or bona fide established commercial or selling agencies maintained by the seller for the purpose of securing business. For breach or violation of this warranty, the City shall have the right to annul the contract without liability or in its discretion to deduct from the contract price a consideration, or otherwise recover the full amount of such commission, brokerage or contingent fee.

8.7 ESTIMATED QUANTITIES OR DOLLAR AMOUNTS (REQUIREMENTS CONTRACTS

ONLY): Quantities and dollar amounts listed are the City’s best estimate and do not obligate the City to order or accept more than City’s actual requirements during period of this agreement, as determined by actual needs and availability or appropriated funds. It is expressly understood and agreed that the resulting contract is to supply the City with its complete actual requirement for the contract period, except that the estimated quantity shown for each proposal item shall not be exceeded by 10 percent without the express written approval of the Deputy Finance Director, Procurement Division. Any demand or order made by any employee or officer of the City of Phoenix, other than the Deputy Finance Director, Procurement Division or designated representative, for quantities in excess of the estimated quantities and dollar amounts shall be void if the written approval of the Deputy Finance Director was not received prior to the Contractor's performance.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

8.8 COST JUSTIFICATION: In the event only one response is received, the City may require that the offeror submit a cost proposal in sufficient detail for the City to perform a cost/price analysis to determine if the proposal price is fair and reasonable.

8.9 WORK PRODUCT, EQUIPMENT AND MATERIALS: All work product, equipment, or

materials created or purchased under this contract belongs to the City and must be delivered to the City at City’s request upon termination of this contract. Contractor agrees that all materials prepared under this contract are “works for hire” within the meaning of the copyright laws of the United States and assigns to City all rights and interests Contractor may have in the materials it prepares under this contract, including any right to derivative use of the material.

9. CONTRACT TERMINATION

9.1 GRATUITIES: The City may, by written notice to the Contractor, cancel this contract if it is found that gratuities, in the form of entertainment, gifts or otherwise, were offered or given by the Contractor or any agent or representative of the Contractor, to any officer or employee of the City making any determinations with respect to the performing of such contract. In the event this contract is canceled by the City pursuant to this provision, the City shall be entitled, in addition to any other rights and remedies, to recover or withhold from the Contractor the amount of the gratuity.

9.2 CONDITIONS AND CAUSES FOR TERMINATION: This contract may be terminated at

any time by mutual written consent, or by the City, with or without cause, upon giving thirty (30) days written notice to Contractor. The City at its convenience, by written notice, may terminate this contract, in whole or in part. If this contract is terminated, the City shall be liable only for payment under the payment provisions of this contract for services rendered and accepted material received by the City before the effective date of termination. Title to all materials, work-in-process and completed but undeliverable goods, will pass to the City after costs are claimed and allowed. The Seller shall submit detailed cost claims in an acceptable manner and shall permit the City to examine such books and records as may be necessary in order to verify the reasonableness of any claims.

The City reserves the right to cancel the whole or any part of this contract due to failure of Contractor to carry out any term, promise, or condition of the contract. The City will issue a written notice of default to Contractor for acting or failing to act as in any of the following:

In the opinion of the City, Contractor provides personnel who do not meet the requirements of the contract;

In the opinion of the City, Contractor fails to perform adequately the stipulations, conditions or services/specifications required in this contract;

In the opinion of the City, Contractor attempts to impose on the City personnel or materials, products or workmanship, which is of an unacceptable quality.

Contractor fails to furnish the required service and/or product within the time stipulated in the contract;




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

In the opinion of the City, Contractor fails to make progress in the performance of the requirements of the contract and/or give the City a positive indication that Contractor will not or cannot perform to the requirements of the contract.

9.3 CONTRACT CANCELLATION: All parties acknowledge that this contract is subject to cancellation by the City of Phoenix pursuant to the provision of Section 38-511, Arizona Revised Statutes.

SECTION III – SPECIAL TERMS AND CONDITIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1. FOB POINT Prices quoted shall be FOB Destination unloaded and installed.

2. PRICE All prices offered shall be firm and fixed for the term of the contract.

3. PERFORMANCE SURETY REQUIREMENTS A performance surety in the amount of ten percent of the total contract amount shall be provided by the Contractor immediately after notice of award. The City of Phoenix will not issue a written purchase order or give notice to proceed in any form until the surety is received by the Procurement Division. The performance surety must be in the form of a bond, cashier's check, certified check or money order. Personal or company checks are not acceptable unless certified. If surety is in the form of a bond, the company issuing the surety must be authorized by the Insurance Department of Arizona to transact business in the State of Arizona or be named on the approved listing of non-admitted companies. A Certificate of Deposit (CD) issued by a local Phoenix bank may also be used as a form of surety provided that the CD is issued jointly in the name of the City of Phoenix and the Contractor, and that the Contractor endorses the CD over to the City at the beginning of the contract period. Interest earnings from the CD can be retained by the Contractor.

4. BOND REQUIREMENT FOR CBP FIS SECURITY AREA All air carriers, tenants, contractors and vendors, whose employees are required to conduct business in the CBP FIS security area are required to post a bond with CBP, guaranteed by surety, to assure compliance with CBP FIS security rules and regulations. This is generally an “Active” continuous CBP form 301 bond. Companies must provide CBP with a copy of the bond on file, including the name of the surety company, the IRS number, the surety number and the location where the bond is filed. If there is no active bond on file, the application shall be supported by an Airport CBP Security Area Bond, as set forth in Appendix A of Part §113, CBP Regulations (19 CFR, Part §113). The employer shall post a separate Airport CBP Security Area Bond at each airport of operation. (At this time, we encourage use of the Form 301 Bond). The face value amount of the bond specifies the maximum liability of the surety. Determinations as to bond face value sufficiency will be based on the number of covered employees and the employer’s general compliance history. The minimum face value of the bond required by CBP will be dependent upon how many employees will require access to the CBP FIS Security area; • Less than 15 employees $25,000 • Between 15 to 25 employees $50,000 • More than 25 employees $100,000 However, the CBP Port Director may elect to raise the face value due to historical compliance of the airport company. A company must have a valid bond in order to have employees with CBP FIS security seals. Bond links: Link to Department of Treasure list of surety companies: http://www.fms.treas.gov/c570/index.html

http://www.fms.treas.gov/c570/index.html




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Link to CBP Q&A on CBP bonds: http://www.cbp.gov/linkhandler/cgov/trade/priority_trade/revenue/bonds/qa_bonds.ctt/q_and_a_bonds.doc

5. AWARD Award will be made on an "all or none" basis. Submittal prices must be shown for each item listed. Solicitations submitted without individual item prices listed will be considered as non-responsive and rejected.

6. METHOD OF ORDERING (PURCHASE ORDERS) Issuance of written purchase order(s) by the Procurement Division. Contractor shall deliver items and/or services only upon receipt of a written purchase order issued by the Procurement Division. All Contractor invoices and packing/delivery tickets must include the City of Phoenix purchase order number.

7. METHOD OF INVOICING Invoice must include the following: A. City purchase order number, requisition number, or contract agreement number. B. Items listed individually by the written description and part number. C. Unit price, extended and totaled. D. Quantity ordered, back ordered, and shipped. E. Applicable tax. F. Invoice number and date. G. Requesting department name and "ship-to" address. H. Payment terms. I. FOB terms.

8. METHOD OF PAYMENT Contractor will be paid on a monthly basis in arrears. Invoices must contain the agreement number or bid number under which the purchase was awarded. Contractor to submit monthly invoice to:

9. INDEMNIFICATION: (PROFESSIONAL SERVICES – TECHNOLOGY SERVICES) Contractor (“Indemnitor”) must indemnify, defend, save and hold harmless the City of Phoenix and its officers, officials, agents, and employees ( “Indemnitee”) from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorneys’ fees, and costs of claim processing, investigation and litigation) ( “Claims”) caused, or alleged to be caused, in whole or in part, by the negligent or willful acts or omissions of Contractor or any of its owners, officers, directors, agents, employees or subcontractors in connection with this Contract. This indemnity includes any Claims arising out of or recovered under the Workers’ Compensation Law or arising out of the failure of Contractor to conform to any federal, state or local law, statute, ordinance, rule, regulation or court decree. It is the specific intention of the parties that Indemnitee will, in all instances, except for Claims arising solely from the negligent or willful acts or omissions of Indemnitee, be indemnified by Contractor from and against any and all Claims. Contractor will be responsible for primary loss investigation, defense and judgment costs where this indemnification applies. In consideration of the award of this Contract, Contractor waives all rights of subrogation against Indemnitee for losses arising from the work performed by Contractor for the City. The obligations of Contractor under this provision survive the termination or

http://www.cbp.gov/linkhandler/cgov/trade/priority_trade/revenue/bonds/qa_bonds.ctt/q_and_a_bonds.doc

http://www.cbp.gov/linkhandler/cgov/trade/priority_trade/revenue/bonds/qa_bonds.ctt/q_and_a_bonds.doc




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

expiration of this Contract. INSURANCE REQUIREMENTS: Contractor and subcontractors must procure and maintain until all of their obligations have been discharged, including any warranty periods under this Contract are satisfied, insurance against claims which may arise from or in connection with the performance of the work hereunder by the Contractor, his agents, representatives, employees or subcontractors. These insurance requirements are minimum requirements for this Contract and in no way limit the indemnity covenants contained in this Contract. The City in no way warrants that the minimum limits stated in this section are sufficient to protect the Contractor from liabilities that might arise out of the performance of the work under this contract by the Contractor, his agents, representatives, employees or subcontractors and Contractor is free to purchase additional insurance as may be determined necessary. MINIMUM SCOPE AND LIMITS OF INSURANCE: Lessee shall provide coverage with limits of liability not less than those stated below. An excess liability policy or umbrella liability policy may be used to meet the minimum liability requirements provided that the coverage is written on a “following form” basis. Commercial General Liability – Occurrence Form Policy shall include bodily injury, property damage and broad form contractual liability coverage. General Aggregate $2,000,000 Products – Completed Operation Aggregate $1,000,000 Personal and Advertising Injury $1,000,000 Each Occurrence $1,000,000 The policy must be endorsed to include the following additional insured language: "The City of Phoenix is named as an additional insured with respect to liability arising out of the activities performed by, or on behalf of the Contractor". Automobile Liability Bodily Injury and Property Damage coverage for any owned, hired, and non-owned vehicles used in the performance of this Contract Combined Single Limit (CSL) $1,000,000. The policy must be endorsed to include the following additional insured language: "The City of Phoenix is named as an additional insured with respect to liability arising out of the activities performed by, or on behalf of the Contractor, including automobiles owned, leased, hired or borrowed by the Contractor. Worker's Compensation and Employers' Liability. Workers' Compensation Statutory Employers' Liability Each Accident $100,000 Disease – Each Employee $100,000 Disease – Policy Limit $500,000




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Policy must contain a waiver of subrogation against the City of Phoenix. This requirement does not apply when a contractor or subcontractor is exempt under A.R.S. 23-901, AND when such contractor or subcontractor executes the appropriate sole proprietor waiver form. Technology Errors and Omissions Liability (if the Contractor provides technology services or products The policy must cover errors and omissions or negligent acts in the delivery of products, services, and/or licensed programs for those services as defined in the Scope of Services of this contract Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the professional liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed. Network Security and Privacy Liability (if the Contractor has access to any personal or confidential data, the Contractor should be required to evidence Network Security and Privacy Liability coverage in addition to Technology Errors and Omissions) The policy must cover but not be limited to 1) coverage for third party claims and losses with respect to network risks and invasion of privacy, 2) crisis management and identify theft response costs, 3) cyber extortion, 4) computer fraud coverage, and 5) funds transfer loss. Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the network security and privacy liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed. Media Liability (if the Contractor is involved in the production or publication of content) The policy must cover any and all errors and omissions or negligent acts in the production or publication of content, including but not limited to plagiarism, defamation, libel, slander, false advertising, invasion of privacy and infringement of copyright, title, slogan, trademark, service mark and trade dress Each Claim $1,000,000 Annual Aggregate $1,000,000 In the event that the media liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed. ADDITIONAL INSURANCE REQUIREMENTS: The policies shall include, or be endorsed to include, the following provisions:




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

On insurance policies where the City of Phoenix is named as an additional insured, the City of Phoenix shall be an additional insured to the full limits of liability purchased by the Lessee even if those limits of liability are in excess of those required by this Lease. The Lessee's insurance coverage shall be primary insurance and non-contributory with respect to all other available sources. NOTICE OF CANCELLATION: For each insurance policy required by the insurance provisions of this contract, the Contractor must provide to the City, within two (2) business days of receipt, a notice if a policy is suspended, voided or cancelled for any reason. Such notice shall be mailed to City of Phoenix Finance Department, Purchasing Division, 251 W. Washington Street, Phoenix, Arizona 85003; emailed to: [email protected] ACCEPTABILITY OF INSURERS: Insurance is to be placed with insurers duly licensed or authorized to do business in the state of Arizona and with an “A.M. Best” rating of not less than B+ VI. The City in no way warrants that the above-required minimum insurer rating is sufficient to protect the Contractor from potential insurer insolvency. VERIFICATION OF COVERAGE: Lessee shall furnish the City with certificates of insurance (ACORD form or equivalent approved by the City) as required by this Lease. The certificates for each insurance policy are to be signed by a person authorized by that insurer to bind coverage on its behalf. All certificates and any required endorsements are to be received and approved by the City before the Lease commences. Each insurance policy required by this Lease must be in effect at or prior to commencement of this Lease and remain in effect for the duration of the Lease. Failure to maintain the insurance policies as required by this Lease or to provide evidence of renewal is a material breach of contract. All certificates required by this Lease shall be sent directly to City of Phoenix, Deputy Finance Director/Purchasing, 251 West Washington, Phoenix, Arizona 85003. The City Department, Lease agreement number and location description are to be noted on the certificate of insurance. The City reserves the right to require complete, certified copies of all insurance policies and endorsements required by this Lease at any time. DO NOT SEND CERTIFICATES OF INSURANCE TO THE CITY'S RISK MANAGEMENT DIVISION. APPROVAL: Any modification or variation from the insurance requirements in this Lease must have prior approval from the City of Phoenix Law Department, whose decision shall be final. Such action will not require a formal lease amendment, but may be made by administrative action.

mailto:[email protected]




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

10. AVIATION SECURITY PROCEDURES CONTRACTOR AND SUBCONTRACTOR WORKER BACKGROUND SCREENING: Contract Worker Background Screening Contractor agrees that all contract workers and subcontractors [collectively “Contract Worker(s)”] that Contractor furnishes to the City pursuant to this Contract shall be subject to background and security checks and screening (collectively “Background Screening”) at Contractor’s sole cost and expense as set forth in this Section. The Background Screening provided by Contractor shall comply with all applicable laws, rules and regulations. Contractor further agrees that the Background Screening required in this Section is necessary to preserve and protect public health, safety and welfare. The Background Screening requirements set forth in this Section are the minimum requirements for this Contract. The City in no way warrants that these minimum requirements are sufficient to protect Contractor from any liabilities that may arise out of Contractor’s services under this Contract or Contractor’s failure to comply with this Section. Therefore, in addition to the specific measures set forth below, Contractor and its Contract Workers shall take such other reasonable, prudent and necessary measures to further preserve and protect public health, safety and welfare when providing services under this Contract. A. Background Screening Requirements and Criteria Contractor agrees that it will verify legal Arizona worker status as required by Arizona Revised Statutes (A.R.S.) § 41-4401. Contractor further agrees that it will conduct a background check for real identity/legal name on all Contract Workers prior to proposing the Contract Worker to the City. B. Additional City Rights Regarding Security Inquiries In addition to the foregoing, the City reserves the right but not the obligation to: (1) have a Contract Worker be required to provide fingerprints and execute such other documentation as may be necessary to obtain criminal justice information pursuant to A.R.S. § 41-1750(G)(4) or Phoenix City Code § 4-22; (2) act on newly acquired information whether or not such information should have been previously discovered; (3) unilaterally change its standards and criteria relative to the acceptability of Contract Workers; and (4) object, at any time and for any reason, to a Contract Worker performing work (including supervision and oversight) under this Contract. C. Contractor Certification By executing this Contract, Contractor certifies and warrants that Contractor has read the Background Screening requirements and criteria in this Section, understands them and that all Background Screening information furnished to the City is accurate and current. Also, by executing this Contract, Contractor further certifies and warrants that Contractor has satisfied all such Background Screening requirements as required. A Contract Worker rejected for work under this Contract shall not be proposed to perform work under other City contracts or engagements without the City’s prior written approval. D. Terms of This Section Applicable to all of Contractor’s Contracts and Subcontracts Contractor shall include the terms of this Section for Contract Worker Background Screening in all contracts and subcontracts for services furnished under this Contract including, but not limited to, supervision and oversight services.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

E. Materiality of Background Screening Requirements; Indemnity The Background Screening requirements of this Section are material to the City’s entry into this Contract and any breach of this Section by Contractor shall be deemed a material breach of this Contract. In addition to the indemnity provisions set forth in Section II 6.3 of this Contract, Contractor shall defend, indemnify and hold harmless the City for any and all Claims (as defined in Section II - 6.3) arising out of this Background Screening Section including, but not limited to, the disqualification of a Contract Worker by Contractor or the City for failure to satisfy this Section. F. Continuing Duty; Audit Contractor’s obligations and requirements that Contract Workers satisfy this Background Screening Section shall continue throughout the entire term of this Contract. Contractor shall notify the City immediately of any change to a Background Screening of a Contract Worker previously approved by the City. Contractor shall maintain all records and documents related to all Background Screenings and the City reserves the right to audit Contractor’s compliance with this Section pursuant to Section IV item #42 Audits.

11. CONTRACT WORKER ACCESS CONTROLS, BADGE AND KEY ACCESS REQUIREMENTS A CONTRACT WORKER SHALL NOT BE ALLOWED TO BEGIN WORK IN ANY CITY FACILITY WITHOUT: (1) THE PRIOR COMPLETION AND THE CITY’S ACCEPTANCE OF THE REQUIRED BACKGROUND SCREENING; AND (2) WHEN REQUIRED, THE CONTRACT WORKER’S RECEIPT OF A CITY ISSUED BADGE. A BADGE WILL BE ISSUED TO A CONTRACT WORKER SOLELY FOR ACCESS TO THE CITY FACILITY(S) TO WHICH THE CONTRACT WORKER IS ASSIGNED. EACH CONTRACT WORKER WHO ENTERS A CITY FACILITY MUST USE THE BADGE ISSUED TO THE CONTRACT WORKER. A. Badges After receipt of the badge application, the Contract Worker will proceed to the Badging Office for processing of the badge application and issuance of the badge. The City will not process the badge application until the Contract Worker satisfies the required Background Screening (as defined herein). The Contract Worker shall comply with all requirements and furnish all requested information as requested by the Badging Office. Any and all fees associated with security badging will be assessed in compliance with Phoenix City Code § 4-22. Current badging procedures and fees are available for review at: https://skyharbor.com/security/BadgingInformation B. Key Access Procedures If the Contract Worker’s services require keyed access to enter a City facility(s), a separate key issue/return form must be completed and submitted by Contractor for each key issued. 1. Stolen or Lost Badges or Keys Contractor shall report lost or stolen badges or keys to the City immediately. A new badge application or key issue form shall be completed and submitted along with payment of the applicable fees prior to issuance of a new badge or key.

https://skyharbor.com/security/BadgingInformation




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

2. Return of Badges or Keys All badges and keys are the property of the City and must be returned to the City at the Badging Office within one (1) business day of when the Contract Worker’s access to a City facility is no longer required to furnish the services under this Contract. Contractor shall collect a Contract Worker’s badge and key(s) upon the termination of the Contract Worker’s employment; when the Contract Worker’s services are no longer required at the particular City facility(s); or upon termination, cancellation or expiration of this Contract. 3. Contractor’s Default; Liquidated Damages; Reservation of Remedies for Material Breach Contractor’s default under this Section shall include, but is not limited to the following: (a) Contract Worker gains access to a City facility(s) without the proper badge or key; (b) Contract Worker uses a badge or key of another to gain access to a City facility; (c) Contract Worker commences services under this Contract without the proper badge, key or Background Screening; (4) Contract Worker or Contractor submits false information or negligently submits wrong information to the City to obtain a badge, key or applicable Background Screening; or (5) Contractor fails to collect and timely return Contract Worker’s badge or key upon termination of Contract Worker’s employment, reassignment of Contract Worker to another City facility or upon the expiration, cancellation or termination of this Contract. Contractor acknowledges and agrees that the access control, badge and key requirements in this Section are necessary to preserve and protect public health, safety and welfare. Accordingly, Contractor agrees to properly cure any default under this Section within three (3) business days from the date notice of default is sent by the City. The parties agree that Contractor’s failure to properly cure any default under this Section shall constitute a breach of this Section. In addition to any other remedy available to the City at law or in equity, Contractor shall be liable for and shall pay to the City the sum of one thousand dollars ($1,000.00) for each breach by Contractor of this Section. The parties further agree that the sum fixed above is reasonable and approximates the actual or anticipated loss to the City at the time and making of this Contract in the event that Contractor breaches this Section. Further, the parties expressly acknowledge and agree to the fixed sum set forth above because of the difficulty of proving the City's actual damages in the event that Contractor breaches this Section. The parties further agree that three (3) breaches by Contractor of this Section arising out of any default within a consecutive period of three (3) months, or three (3) breaches by Contractor of this Section arising out of the same default within a period of twelve (12) consecutive months, shall constitute a material breach of this Contract by Contractor and the City expressly reserves all of its rights, remedies and interests under




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

this Contract, at law and in equity including, but not limited to, termination of this Contract.

12. LEGAL WORKER REQUIREMENTS The City of Phoenix is prohibited by A.R.S. § 41-4401 from awarding a contract to any Contractor who fails, or whose subcontractors fail, to comply with A.R.S. § 23-214(A). Therefore, Contractor agrees that: A. Contractor and each subcontractor it uses warrants their compliance with all federal immigration laws and regulations that relate to their employees and their compliance with § 23-214, subsection A. B. A breach of a warranty under paragraph 1 shall be deemed a material breach of the contract that is subject to penalties up to and including termination of the contract. C. The City of Phoenix retains the legal right to inspect the papers of any Contractor or subcontractor employee who works on the contract to ensure that the Contractor or subcontractor is complying with the warranty under paragraph 1.

13. POST AWARD CONFERENCE After award the Contractor may be required to participate in a Post Award Conference for the purpose of ensuring a complete understanding of the requirements.

14. SOFTWARE SUPPORT Contractor agrees to offer for each software program licensed to the City a Source Code Escrow Agreement that provides for release of the source code version of the licensed software program from escrow upon the occurrence of certain release events, including Contractor’s failure to provide required maintenance services as agreed; any rejection or termination of the License Agreement by Contractor or its successors or representatives in breach of the provisions of the License Agreement including in all events any rejection or termination of the License Agreement or any proposal to do so under Title 11 of the United States Code, as now constituted or hereafter amended (the “Bankruptcy Code”), or any other federal or state bankruptcy, insolvency, receivership, or similar law; (b) failure of a trustee, including Contractor as debtor in possession in any bankruptcy case hereafter filed by or against Contractor to assume the License Agreement within fifteen (15) days after the filing of the initial bankruptcy petition or to perform the License Agreement within the meaning of Section 365(a)(4)(i) of the Bankruptcy Code; (c) the termination of substantially all of Contractor’s ongoing business operations relating to the subject of the License Agreement and (d) any liquidation of Contractor, or any sale, assignment, or foreclosure of or upon assets that are necessary for the performance by Contractor of its responsibilities under the License Agreement and any agreed upon Support or Maintenance Agreement.

SECTION IV - SCOPE OF WORK



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1.0 INTRODUCTION 1.1 The City of Phoenix Aviation Department seeks software and services to implement an

Emergency Management System (EMS) as a comprehensive replacement to the current Computer Aided Dispatch (CAD) system at the Phoenix Sky Harbor International Airport.

1.2 The successful offeror shall provide a comprehensive EMS system to be used by the Airport

Command Center (CC) as a keystone application. Services to be provided include a fully tested, stable system running on the City technical infrastructure, with the necessary business capabilities with both full warranty and maintenance support.

2.0 SCOPE 2.1 The Aviation Department seeks an “out-of-the-box” EMS solution that substantially incorporates

the requirements set forth in this solicitation. The Aviation Department anticipates subsequent Phoenix-specific requirements being met through scripting, industry standard Application Programming Interfaces (APIs), or by process reengineering options within the Aviation’s Operations Division. The Aviation Department reserves the right to reject suggested customized code in favor of other options.

2.2 Additionally, any required code customization should not affect future application version

upgrades, either minor or major. If required to maintain PHX operability for version upgrades, custom code migration must be supported by successful proposer in each future application version as part of the generally available version without additional fees beyond maintenance fees quoted during the term of this agreement or any subsequent maintenance agreement.

2.3 A full description of all services required is listed below. Other relevant business documents are

included for better understanding of the requirements:

Exhibit D, Scope of Services Process Flow

Attachment B, Compliance Matrix

Attachment C, System Specification Document

Attachment D, Business Use Cases

Attachment E, Concept of Operations

Attachment F, Current Conditions

Attachment G, Systems Descriptions

Attachment H, Acronyms

2.4 Firms shall be asked to address this project in three phases. The phases correspond to the intended integrations being implemented. The core product will be implemented in the first phase. 2.4.1 Phase One shall be to implement the core system along with the integrations to Video Surveillance System (VSS), Geographic Information System (GIS), Emergency Notification System (ENS) and Digital Voice Recorder (DVR). 2.4.2 Phase Two shall be to implement integration to the Enterprise Building Integrator including Access Control and Alarm Monitoring System (ACAMS), Fire Enterprise Business Integrator (FEBI), Digital Monitoring System (DMS), and to mobilize the EMS.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

2.4.3 Phase Three shall be to implement integrations to the Operations Security Portal (OSP), mobile Work Order Management System (xPort) and the emergency phone system (Vesta).

2.5 Because of the large scope of this project, it is the intent of the City to fund and complete each phase separately. Funding is currently available for Phase One, with subsequent funding to be secured for phases two and three. However, if there are opportunities to implement Phase Two or Three without impacting the overall schedule, such options can be listed in the discussion of Approach to Scope.

3.0 GENERAL 3.1 Consultant shall analyze, plan, configure, and test the implementation and integration of the

Emergency Management System (EMS) into the City’s VMware Server production environment. Implementation of the EMS shall be conducted in a manner that will enable the City’s Aviation Command Center (CC) to continue with the existing application prior to actual product implementation. Implementation of the EMS cannot adversely affect the CC.

3.2 The final deliverable shall be a fully functional EMS that conforms to the System Specification

Document (SSD) (provided as Attachment C) and Compliance Matrix (provided as Attachment B). 4.0 TECHNOLOGY PROJECT MANAGEMENT METHODOLOGY 4.1 The implementation and integration of the EMS shall be performed in accordance with the

Aviation Technology Project Management Methodology depicted in Exhibit A. 5.0 PLANNING PROCESS 5.1 The Consultant shall organize and schedule a sufficient number of planning sessions with various

City staff members in order to develop a complete understanding of the project and to obtain confirmation by the City of this understanding prior to commencing detailed planning for the EMS implementation. Consultant shall, in collaboration with the City, determine the actual number of sessions necessary, but should plan for up to ten (10). Consultant shall be responsible for preparation of the associated agenda and minutes, and for any other items that may result from the planning sessions.

6.0 DELIVERABLES 6.1 Overview

6.1.1 The EMS Project includes the planning, design, configuration, test, training, implementation, as well as operations and maintenance of an EMS. Exhibit D provides a detailed project process flowchart. Project scope includes, but is not limited to, the following services:

Project Management and coordination

Requirements Validation

System Design

System Build, Configuration, and Integration

System Installation and Configuration

System Testing




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Training

System Warranty and Maintenance

6.1.2 During the execution of the Project, the Consultant shall submit the necessary documents required. Project Management documents shall conform to the Aviation Technology Project Management Methodology standards (refer to Exhibit A) or as agreed to with the City Project Manager. All project documentation and submittals mentioned throughout this Scope of Services are described in detail in Section 6.10 and are listed with due dates in Table 1.

6.1.3 In general, all submittals need to be delivered as a draft version initially to allow the City

to review and provide feedback. Upon successful incorporation of feedback, an updated version is to be submitted for consideration of approval. To that extend, the Consultant needs to account for sufficient time in the project schedule for the draft, review, finalization, and acceptance process.

6.1.4 The Consultant shall provide a detailed plan for warranty and maintenance support.

There shall be three (3) major consecutive periods of warranty support.

6.1.5 The Project will be implemented in up to three (3) Phases. The functional scope of each Phase is prioritized based on business requirements in the SSD (Attachment C). At a minimum, all work associated with Phase 1 will be included in the initial contract. City reserves the right to include portions of later phased implementations as required.

6.2 Roles and Responsibilities

6.2.1 City Responsibilities

For the test/training environment and the production environment the City will provide the following:

Hardware provisioning and implementation – includes servers, switches, routers, storage devices, workstations, peripherals, and other hardware related items and/or as detailed in the SSD)

Internet access

Network connections and LAN configuration

Hardware and operating software maintenance

System administration

1st level maintenance support and help desk for the EMS - users with questions or issues will call City Helpdesk.

VPN and network access for computers operated by the Consultant requiring access to City resources; this is subject to City policies on such access.

6.2.2 Consultant Responsibilities

The Consultant will provide the following:

Any hardware or software needed by the Consultant at their own facility for design, development, and configuration tasks.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Any hardware or software needed by the Consultant for personal use while on-site at the Airport.

Provisioning as detailed in SSD

Recommendations for backup procedures and sizing

EMS application software (licenses, installation, and maintenance) for production and test/training environments

Coordination with all required City system vendors for purposes of systems interface development

Development of selected systems integrations as defined in the implementation for each phase.

Obtaining appropriate background checks and security credentials necessary to perform the work.

6.3 Project Management Requirements

6.3.1 Initial Submittals. The Consultant shall submit two items within 14 calendar days after receiving the Notice to Proceed (NTP). These items will be reviewed by the City Project Manager.

Deliverables Log and Procedures (see Section 6.10.2)

Consultant Contacts & Escalation (see Section 6.10.3)

6.3.2 Project Management Plan. The Consultant shall submit a Project Management Plan (see Section 6.10.5.) for approval by the City within 30 calendar days after receiving the Notice to Proceed (NTP).

6.3.3 Project Execution. Consultant shall conduct a project kickoff meeting no more than six

(6) weeks after NTP. Consultant will present the complete Project Management Plan. 6.3.4 Project Status Reports. Consultant will provide weekly Project Status Reports beginning

14 days after NTP (see Section 6.10.4). At the discretion of City, weekly or mutually agreed upon interval project status meetings will be conducted to review the project status.

6.4 Discovery/System Requirements Validation. Within 14 days of the after NTP, the Consultant will

meet with City staff and conduct site surveys and interviews to refine the requirements contained in the SSD to create an Updated SSD (see Section 6.10.6) to be submitted to the City. In addition, the Consultant will provide a Hardware and System Requirements Document (see Section 6.10.7). Both submittals are to be submitted two weeks prior to the System Requirements Review (SRR), during which they will be reviewed and approved before proceeding to the system design phase.

6.5 System Design and Prototype

6.5.1 System Design

6.5.1.1 The EMS shall integrate with other systems as defined in the Updated SSD. The EMS shall be designed to facilitate the collection of data from several sources, present that data in a useful and well-planned manner to the end users, and




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

allow monitoring and control as required of those systems from a single coordinated station.

6.5.1.2 The EMS shall be configured, managed, and operated taking into account the

information presented in the Concept of Operations (ConOps) (Attachment E) unless otherwise agreed to with the City Project Manager. The development of the business rules, based on City requirements for the EMS and the systems the EMS integrates with it, shall be a collaborative effort between the City and the Consultant.

6.5.1.3 The Consultant is encouraged to develop requirements using a prototype

application in an iterative manner. This method has worked well in the past and allows intended users to have a better understanding of the system before it is deployed. Some level of iterative development should be built into the project schedule.

6.5.2 Design. Upon City approval of the updated SSD and the Hardware and System

Requirements Document, the Consultant shall begin system development, interface development, and product configuration to meet system requirements. Consultant will develop a preliminary design of the EMS for validation of user interfaces and ease of use.

6.5.3 Unit Test Environment Installation. The City will provide a Unit Test environment at the

Airport to be used by the Consultant for the EMS testing and for training of system users and administrators. Consultant will install the prototype EMS software in this test environment. In addition, the Consultant will implement the EMS on a training workstation at the current CC/AEOC to be used by CC personnel to familiarize themselves with the system. Consultant shall complete test system installation and EMS configuration in accordance with the schedule agreed upon with the City.

6.5.4 User Feedback Design

6.5.4.1 Upon implementation of the preliminary design of the EMS in the test/training

environment, Consultant will conduct user validation and system configuration workshops. City system users will exercise the preliminary system design and provide feedback on specific functionality, ease of use, standard operating procedures, screen displays, screen layouts, maps, reports, and other user related functions. This is not a system test. It is an opportunity to refine the EMS configuration and design to meet user needs and expectations before the final design phase.

6.5.4.2 After sufficient iterative design and prototyping, the Consultant will develop and

submit two week prior to the System Design Review (SDR) the following design documentation:

System Design Document (SDD) (see Section 6.10.8)

Interface Control Document (ICD) (See Section 6.10.9)

Updated Hardware and System Software Requirements Document (see Section 6.10.10)

Acceptance Test Plan & Procedures (see Section 6.10.11)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.5.4.3 Details of these documents are provided in Section 6.10. All documentation must be approved by the City.

6.5.4.4 Consultant will obtain approval from the City for these submittals during the SDR

before proceeding with system installation phase in the test environment. 6.6 System Installation and Functional & System Tests – Test/Training Environment

6.6.1 System Installation. Upon successful completion of SDR, Consultant shall provide a clean install of the EMS in the test/training environment for initial Acceptance Testing. Consultant will conduct an Acceptance Test Readiness Review (ATRR) to ensure resources are available and everything is in place for initial Acceptance Testing.

6.6.2 Acceptance Test – Test/Training Environment. Using the Acceptance Test Plan &

Procedures approved at SDR, testing performed and documented by CC personnel. The Acceptance Testing will consist of Functional Tests traced back to the functional requirements listed in the Updated SSD.

6.6.3 System Acceptance – Test/Training Environment

6.6.3.1 One (1) week following the completion of testing, the Consultant shall deliver an Acceptance Test Report, based on the documented test results provided by CC personnel, documenting test activities and results. As part of this Test Report, the Consultant shall prepare and submit an Acceptance Punch List containing the items that either failed the test or need to be changed as a result of the test. The City will determine if the system is ready for implementation in the production environment and training (see Section 8.) can commence.

6.6.3.2 It is desired to have some kind of automated mechanism or process during this

testing phase to be used later, as addressed in Section 6.7.2.

6.6.4 System Testing. Following successful Acceptance Testing in the test/training environment, Consultant will deliver the following submittals to be approved by the City before System testing can commence:

System Test Plan & Procedures (see Section 6.10.13)

Training Plan (see Section 6.10.14)

System Implementation/Go-Live Plan (see Section 6.10.15)

Quality and Performance Monitoring Plan (see Section 6.10.16) 6.7 System Installation and Validation – Production Environment

6.7.1 Production Environment Installation. City will provide production equipment for the EMS. The Consultant will be responsible for a clean installation of the EMS software after successful completion of Acceptance Testing in the test/training environment. The Consultant will provide written procedures for such a clean installation. Consultant shall complete system installation in accordance with the schedule agreed upon with the City. Consultant will conduct a System Test Readiness Review (STRR) to ensure resources are available and everything is in place for System Testing.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.7.2 System Test – Production Environment. Using the approved System Test Plan, CC personnel will manually test a key set of functions, and documented the results. System Tests will be performed, includes the following:

System Security Requirements

System Administration Requirements

System Access and Privilege Requirements

System Failover and Recovery Requirements

System Performance Requirements

Where available, the use of previously developed automated mechanisms will be used.

6.7.3 System Acceptance – Production Environment. One (1) week following completion of testing, Consultant shall deliver a System Test Report and a System Punch List (see Section 6.10.17).

6.7.4 Go-Live Readiness Review

6.7.4.1 Following successful System Testing in the production environment, Consultant

will undergo a Go-Live Readiness Review (GLRR). At the GLRR, the City will review the System Test Report and Punch List and ensure no major issues will prevent system go-live. Based on this review, the City will determine if system is acceptable for operational use

6.7.4.2 Prior to the GLRR, the Consultant shall also deliver the following documentation

to be reviewed and approved:

14-Day Post Go-Live Support Plan (see Section 6.10.19)

60-Day Endurance Support Plan (see Section 6.10.20)

System Manuals (See Section 6.10.21)

Software Licenses (see Section 6.10.22)

6.7.4.3 These two support plans in this list, will be developed jointly and agreed to, in writing, by Consultant’s Project Manager and the City’s designated Project Manager prior to the start of final system acceptance.

6.7.4.4 Upon City approval of the GLRR, Consultant will cut over the EMS. Data

migration from the old systems to the new system will be implemented. Upon successful completion of system go-live, will be granted and City will begin beneficial use of the new EMS.

6.8 Training

6.8.1 Overview

6.8.1 The selected Consultant shall develop and implement a comprehensive training program based on the approved Training Plan for all required City staff. It shall be implemented through the use of formal classroom training, training in the test/training environment, and other forms of training that the selected Consultant shall propose.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.8.2 The Consultant shall instruct designated personnel in the operation, design, and

layout of the EMS. The training means shall be a combination of training classes as well as individual instruction as necessary. The training shall cover system configuration, operation, start up, and use. The training schedule is subject to City approval. The Consultant shall:

Prepare and submit training materials (see Section 6.8) and conduct all training.

Conduct training at the City training shall consist of classroom and hands-on training on the EMS installed in the test/training environment

Complete training in a maximum of two weeks prior to the system becoming operational and utilized by the City.

6.8.3 The Consultant shall conduct the required training at times and locations

coordinated by the City. The class schedules must accommodate shift schedules of City personnel and must be approved in advance. If twenty (20) calendar days or more have elapsed between training and system go-live, selected Consultant must provide retraining of those involved.

6.8.4 Training shall be conducted by experienced Consultant personnel using an

adequate number and amount of training material. Consultant shall identify all training/staff prerequisites for certification.

6.8.5 A digital version of all course materials shall be provided to the City for use in

future training. The Consultant shall supply a video recording of each training course

6.8.2 System Administration and Monitoring Training

6.8.2.1 The Consultant shall provide training for City system administrators and those

that will be performing Level 1 support. This training shall:

Cover all EMS administration and monitoring functions, basic fixes, configurations, etc.

Provide an overview of the complete system structure including hardware, software, and networks.

Describe all functions and applications needed to perform system administration.

6.8.2.2 At a minimum system administrators must be able to:

Monitor system operations

Access system logs containing warnings and error notifications

Run audit and system health statistics and print reports

Define user roles and user account configuration and management

Manage and configure EMS software

Develop, add, edit, and configure user views, Response Plans, Dashboard, and automated business rules.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.8.2.3 This training will cover the reparative and preventative maintenance tasks for the system. It will provide an in-depth trouble diagnostic tutorial with a trouble-shooting flow chart.

6.8.3 User Training

6.8.3.1 All City staff that will use the system will be instructed in all aspects of the EMS

components and application software, which are needed to perform their duties. The Consultant should provide a dedicated trainer to accommodate the needs of the CC and may require off-hour training sessions for a 2-week period. User training will include at a minimum the first two (2) types:

CC Dispatcher Training – All EMS functions performed by dispatchers and other CC staff will be covered to include, at a minimum, creating events, managing resources, creating response plans, monitoring alarms, accessing and controlling video feeds, and working with Maps. The ability to customize user-defined parameters, response procedures, and other configurable items will be covered in detail.

CC Operator Training – EMS functions for management and field staff will be covered to include, at a minimum, updating events, viewing event logs, viewing dashboards, and running reports.

Mobile Users Training – EMS functions intended for mobile users accessing the system using a tablet or similar device will be covered to include at a minimum, acknowledging assignment, updating events, viewing maps, and documents.

6.8.3.2 Consultant will offer additional/refresher training sessions on new releases as

part of the warranty/maintenance fee throughout the warranty period. 6.9 Final Acceptance - System Go-Live

6.9.1 In accordance with the 14-Day Post Go-Live Support Plan and the 60-Day Endurance Support Plan, final system acceptance will occur in three (3) stages. Prior to the start of the 14-day Post Go-Live, the Consultant shall submit the Warranty and Maintenance Plan (see Section 6.10.23) to be approved by the City before the one-year Regular Warranty Period commences.

6.9.2 14-day Post Go-Live. Consultant support resources shall be present at the site to

address any issues related to implementation and provide such support in as quick a timeframe as possible. On-site close coverage is expected for this period with consideration made that the system is 24/7 365 operation. This acceptance phase will be controlled through the 14-Day Post Go-Live Support.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.9.3 60-day Endurance. Assuming a stable system is in place, the project will transition to a 60-day Endurance test period. This test period will be controlled through the 60-Day Endurance Support Plan.

The Endurance testing must be completed and accepted by the City before final payment is made and the retainage account is released to Consultant. Problems that interrupt the system from general use as designed are considered major defects, the presence of which would restart the Endurance Test once the defect is corrected and tested. To obtain Final Acceptance the following must be completed:

All punch list items from preliminary Acceptance & System Testing completed

Resolution of post go-live issues completed

Successful completion of first 14 days

Successful completion of 60-day Endurance

Adherence to the System Test Plan & Procedures metrics and measurements

All submittals and documentation delivered (see Section 10.)

All training complete

All Software Licenses delivered

6.9.4 1-year Regular Warranty Period. This is the first year of the normal support and maintenance scheme.

6.10 Submittals and Documentation

6.10.1 All documentation (text, graphics, illustrations, etc.) described in this section must be delivered in both digital/electronic and hardcopy/paper formats unless otherwise agreed to with the City Project Manager. The documentation shall be produced in .docx format accompanied by an Adobe PDF file. The documentation and drawings shall meet the requirements of the SSD. Consultant must supply sufficient time for City review and comment and any required revisions. Table One depicts the required delivery schedule of all submittals.

6.10.2 Deliverables Log & Procedures

The Consultant shall create and maintain a log which lists all major planned submittals, including descriptions of items, dates submitted, response dates, and status of submittals. A dollar value shall be assigned to each submittal. Invoices will include values of the deliverables provided to the City and accepted unless otherwise agreed to by the City Project Manager. Large deliverables may be broken out in % complete upon agreement with the City Project Manager. The Deliverables log will be the basis for invoicing and payments as the project progresses. A Sample Deliverables Log is provided in Exhibit C.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.10.3 Consultant Contacts & Escalation

The Consultant shall submit Company contact information, including:

Organizational chart as applicable to this project

Project management and technical staff names, emails, and cell phone contact information.

Project escalation chart 6.10.4 Project Status Reports

The Consultant shall provide to the City Project Manager weekly Project Status Reports to include progress made, milestone reached, issues & risks identified, remedial actions taken to solve these issues and mitigate these risks, and next steps outlined.

6.10.5 Project Management Plan

The Consultant shall develop a Project Management Plan, consisting of multiple components; some of them are discussed as separate submittals. These components include:

Restatement of Scope of Services which should align with the proposed solution

Work Breakdown Structure (WBS) listing activities at the task level with durations at five (5) days or less at the lowest level. Task descriptions of each discrete activity to include the following for each task: o WBS number o Narrative description o Planned start date o Duration o Planned resources (staff, lab, etc.) o Dependencies (including dependencies upon other tasks, Aviation Department,

and 3rd party tasks) o Owner

Project Schedule – to be created in GANTT format showing dependencies and critical path.

Deliverables Log & Procedures

Description of project controls to be utilized for cost and schedule management

Consultant Contact & Escalation

Communications Plan for maintaining high level of communications with the Aviation Department and the CC design and construction vendor. This should include the following: o Project kickoff and orientation meeting o Requirements validation period o Escalation criteria for open issues, which might affect delivery with an escalation

organizational chart o Weekly email status report (from kickoff until final acceptance) which identifies:

The activities completed in the last week The activities planned for the next three weeks including Consultant, City,

and 3rd party activities Project risk analysis and risk mitigation approach




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Current schedule for completion

Open action Items 6.10.6 Updated System Specification Document (SSD)

Consultant shall deliver an Updated SSD after conducting site surveys and validating system requirements with the City. Any clarifications/ discrepancies related to systems architecture, use cases, data structures, functional requirements, phasing, integration, and reports shall be clarified and incorporated into this Updated SSD.

6.10.7 Hardware and System Software Requirements Document

The Consultant shall provide the City with an initial set of recommended hardware and system software requirements necessary for the EMS procurement, implementation, and installation by the City. For each type of product required for the EMS, the Consultant shall provide, at a minimum, recommended requirements, including features, performance, and sizing requirements.

6.10.8 System Design Document (SDD)

The Consultant shall deliver an initial SDD after a successful SRR. The SDD will describe the system architecture, functional capabilities, and all aspects of system communications, interfaces, security, software, hardware (supplied by the City), performance, and maintainability. Consultant is responsible for coordinating with all City system vendors, as required, to develop system interfaces to the EMS using the Oracle SOA platform.

6.10.9 Interface Control Document (ICD)

Consultant shall deliver an ICD describing in detail all the interfaces to the each of the systems integrated with the EMS. The ICD should contain a description of each system interface, the purpose of the interface, a mapping of functional requirements in the SSD that the interface helps meet, data elements exchanged, and the business rules that govern the exchange of information. The business rules should cover formatting, sequencing, error detection, commands, performance characteristics, and workflow.

6.10.10 Updated Hardware and System Software Requirements Document

Upon City approval of this initial set during the SRR, the Consultant shall provide an Updated document based on final requirements and design activities.

6.10.11 Acceptance Test Plan & Procedures

The Consultant shall deliver an Acceptance Test Plan and test procedure documents. The Plan shall address the functional requirements, system access and security requirements, system admin functions, system monitoring and reporting functions, and cover each user’s ability to use the EMS with full functionality. The Plan shall also detail test procedures and test scripts, which in turn identify the test steps, test sequences, and test acceptance criteria with a sign-off of each test by City representatives. The Plan shall detail the objectives of all tests including taking into account any pertinent




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

information as provided in the ConOps (Attachment E) and any business rules implemented. The tests shall clearly demonstrate that the EMS and the systems integrated with it, fully comply with the requirements. Acceptance shall be in the environment designated as test and prior to installation of the system in the designated production environment.

6.10.12 Acceptance Test Report & Punch List

The Consultant shall deliver, based on the documented test results provided by CC personnel, an Acceptances Test Report, including a Punch List. The Acceptance Test Report will document all Acceptance Test activities and results, including system performance and any defects found. Each test case executed shall have a City staff member initial in witness of the execution of that test case. The Acceptance Punch List will contain the items that either failed the Acceptance Test or need to be changed as a result of it.

6.10.13 System Test Plan & Procedures

The Consultant shall deliver for approval an EMS Test Plan and Procedures document. The Plan shall address the a subset of the major functional requirements, system access and security requirements, system admin functions, system monitoring and reporting functions, and cover each user’s ability to use the EMS with sample functionality. The test scripts shall identify test steps, test sequences, and test acceptance criteria with a sign off of each test by City representatives. The Plan shall detail the objectives of all tests including ensuring that the complete configuration has been installed correctly in the production environment and that all major functions work as designed. Some level of performance testing and stress testing must be employed to ensure that he environment is resilient and robust enough to serve the Aviation Department. The tests shall clearly demonstrate that the EMS and the systems integrated with it, fully comply with the requirements.

6.10.14 Training Plan

Consultant shall submit a detailed Training Plan considering all EMS users and administrators. It will provide a syllabus for each course to cover user training, system administration, system configuration, and system maintenance. A schedule for the delivery of all training courses and related material accommodating staff shift requirements must be included in the submittal. The Plan shall be developed in accordance with the training program requirements.

6.10.15 System Implementation/Go-Live Plan

Consultant shall deliver a System Implementation/Go-Live Plan describing the schedule for the EMS implementation as well as City coordination activities and tasks for go-live to operational service. It shall include implementation in both the test and production environments and subsequent to testing, the data migration/data base loading of the live EMS. A schedule of activities for both Consultant and City staff will be included, as will be dependencies between tasks. This Plan must address the following:

Prerequisites to System Go-Live




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Site readiness criteria

Notification Plan and procedures to all involved during go-Live

Responsibilities of all parties involved during go-live

Tasks and dependencies of all Consultant, City, and 3rd party responsibilities

Measures to ensure there are no outages of existing systems

Roll-back process and procedures if go-live does not go smoothly.

6.10.16 Quality and Performance Monitoring Plan

The Consultant shall deliver a Quality and Performance Monitoring Plan after successful Acceptance Testing. The plan will provide means and methods for the measurement of performance attributable to system design.

6.10.17 System Test Report & Punch List

The Consultant shall deliver, based on the documented test results provided by CC personnel, a System Test Report, including a Punch List. The System Test Report will document all System Test activities and results, including system performance and any defects found. Each test case executed shall have a City staff member initial in witness of the execution of that test case. The System Punch List will contain the items that either failed the Acceptance Test or need to be changed as a result of it.

6.10.18 Training Material

The Consultant shall deliver training manuals and other course material (in English) in accordance to Section 8. Training participants shall receive two (2) printed and a digital copy of all training & course material and other and pertinent documentation. Course material shall include, at a minimum, a course overview, prerequisite subjects/knowledge, objectives, and standards for evaluation/successful completion.

6.10.19 14-day Post Go-Live Support Plan

The Consultant deliver for approval an EMS 14-Day Post Go-Live Support Plan. Special considerations need to be made to accommodate the need for an onsite response team with 24 hour availability.

6.10.20 60-Day Endurance Support Plan

The Consultant shall deliver for approval an EMS 60-day Endurance Support Plan. It is designed to run the application in true production mode with the provision that Consultant shall be responsible to fix any problem(s) related to the services provided during that period. The Plan shall designate what constitutes high, medium, and low priority defects and under what conditions the Endurance Test must be stopped so that fixes can be applied and the Endurance Test either restarts from the beginning, or continues from where it stopped.

6.10.21 System Manuals

The Consultant shall deliver the following manuals and guidance documentation:

User Manuals




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Administration Manuals

Operations Manuals

Backup Procedures

Maintenance Manuals

System Customization Guide for user configurable item

Application Installation and Configuration Guide.

6.10.22 Software Licenses

The Consultant shall provide software licenses for each type of software provided by the Consultant for the project. The software licenses shall be suitable for the quantities of users and equipment defined for the project. All licenses shall be issued to the City.

6.10.23 Warranty and Maintenance Plan

Consultant shall deliver a Warranty and Maintenance Plan listing all components of their versions, publisher names, start and end date of coverage. It shall also include the service levels assigned, the means to identify critical versus non-critical problems, toll free numbers, web URLS, and staff names in hierarchical order for escalations etc. refer to the details as provided in Sections 6.3 through 6.9.

# Submittal Scope of Work

References Desired Due Date or

as agreed to with City PM

I. Deliverables Log 6.10.2 14 days after NTP

II. Consultant Contacts & Escalation

6.10.3 14 days after NTP

III. Project Status Reports

6.10.4 weekly starting 14 days after NTP

IV. Project Management Plan 6.10.5 30 days after NTP

V. Updated System Specification Document

6.10.6 2 weeks prior to SRR

VI. Hardware and System Requirements Document

6.10.7 2 weeks prior to SRR

VII. System Design Document 6.10.8 2 weeks prior to SDR

VIII. Interface Control Document 6.10.9 2 weeks prior to SDR

IX. Updated Hardware and System Requirements Document

6.10.10 2 weeks prior to SDR

X. Acceptance Test Plan & Procedures

6.10.11 2 weeks prior to SDR

XI. Acceptance Test Report & Punch List

6.10.12 1 week after Acceptance Test

XII. Systems Test Plan & Procedures

6.10.13 3 weeks prior to System Test

XIII. Training Plan 6.10.14 3 weeks prior to Training

XIV. System Implementation/ Go-Live Plan





Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

# Submittal Scope of Work

References Desired Due Date or

as agreed to with City PM

XV. Quality and Performance Monitoring Plan


XVI. System Test Report & Punch List

6.10.17 1 week after System Test

XVII. All Training Material 6.10.18 1 week prior to Training

XVIII. 14-Day Post Go-Live Support Plan

6.10.19 30 days prior to GLRR

XIX. 60-Day Endurance Support Plan

6.10.20 30 days prior to GLRR

XX. System Manuals 6.10.21 1 week prior to GLRR

XXI. Software Licenses 6.10.22 1 week prior to GLRR

XXII. Warranty and Maintenance Plan

6.10.23 30 days after GLRR

Table 1. Submittal Delivery Schedule.

Legend: NTP – Notice to Proceed SRR – System Requirements Review SDR – System Design Review GLRR – Go-Live Readiness Review

7.0 Warranty/Maintenance Services 7.1 The Consultant shall provide 1-year warranty and maintenance, beginning at Final Acceptance,

with four (4) 1-year options. Maintenance services begin each year on the anniversary date of the Final Acceptance of the system one year after the warranty period started.

7.2 Warranty includes all products supplied as part of Consultant solution. It includes all product

upgrades, versions, and new releases at no additional cost. Consultant shall provide patches or updates recommended by the manufacturer or publisher as well as any software upgrades and patches to the software provided by Consultant per contract year. Consultant will provide a notice with detailed information including release notes and installation procedures along with the software revisions to the City.

7.3 This notice will include, as a minimum, the identification of the defects being corrected, any

modifications required to the operations, any effects the software revision will have on system performance, and any associated software or hardware changes that will have to be implemented as a result of the software revision. The City must be provided the option of choosing whether or not to implement the software revision, and be given the information by Consultant necessary to make a satisfactory decision. Actual installation timing will be at the discretion of the City in consultation with the Consultant. All upgrades and software application changes shall be tested and certified or approved in writing by Consultant before being submitted to the City for installation.

7.4 For system fixes, no additional costs will be incurred by the City for Consultant restoring system to

normal operations. Warranty service and repair work shall be performed by personnel, who have been trained, certified and experienced in the operation and maintenance of the installed system. Service technicians shall have the appropriate experience to perform such work, as accepted by the City. Pre-assigned backup technicians shall be available to replace primary technicians who are unavailable due to personal or business reasons.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7.5 1st Level Maintenance. 1st level maintenance will be performed by the City, and include level

maintenance functions include answering trouble calls with regard to the EMS. 1st level triage of the problem will be performed and if not resolved by City staff, 1st level maintenance will call the EMS Consultant help desk. Consultant shall provide adequate training for City staff to perform this task as part of the training and its deliverables.

7.6 2nd Level Maintenance. 2nd level maintenance will be performed by the EMS Consultant. The

costs for 2nd level maintenance are to be included in the warranty and maintenance line item. 2nd level maintenance functions include the following: 7.6.1 When 1st level maintenance has failed to resolve an issue and calls for software support,

Consultant shall try and diagnose and repair the problem remotely. Consultant shall be available 24x7 365 days per year via toll free phone number and web portal. Consultant shall provide an event number, ETA to problem resolution, and provide resolution details. Trouble calls will be categorized into two categories as determined by the City:

Non-critical Items: these are defined as failures or problems, which do not affect the overall safety, security, or operation of the Airport. For example, the loss of a redundant workstation would usually be considered non-critical.

Critical Items: these are defined as failures or problems, which affect the overall safety, security, or operation of the Airport. The failure of a system interface resulting in the loss of functionality of the EMS would be an example of a critical item requiring immediate remedy including but limited to performance metric failures.

7.6.2 Non-critical items: Problems should be acknowledged by the Consultant within 30

minutes of the notification. Acknowledgement may be by email or phone call to the originator. The Consultant shall diagnose and remedy the problem during normal working hours of the next day. The initial response shall be:

In the morning of the next day if the problem report is received before noon of the previous day

By the afternoon of the next day if problem report is received before close of business the prior day.

Normal business hours are defined as 8 AM to 5 PM Arizona Time Monday thru Friday.

7.6.3 Critical items: Problems should be acknowledged by the Consultant within 30 minutes of the notification. Acknowledgement may be by email or phone call to the originator. The Consultant shall remedy the problem within 8 hours, the Consultant must respond on-site to critical item calls within 24 hours of the initial call to diagnose and remedy the problem. All critical item repairs must be completed prior to the technician leaving the site.

7.6.4 Escalation: If critical problems are not resolved within 4 hours of initial response, the

issue will be escalated to PHX Aviation Technology management.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7.7 3rd Level Maintenance

7.7.1 3rd level maintenance will be performed by the EMS Consultant. The costs for 3rd level maintenance are to be included in the warranty and maintenance line item. 3rd level maintenance functions include the following:

Application and database level support beyond routine tasks

Services required to establish workarounds

Fixes for system bugs and deficiencies where the system is not performing in accordance with established documentation.

7.7.2 The Consultant will provide such services in a reasonable timeframe following prolong

outages not being resolved by the 2nd level maintenance function. Consultant may be called upon to participate in conference calls as part of a response team and may have to come on-site to resolve such problems. Major problems preventing effective use of the system not being resolved or without a resolution plan within 72 hours are candidates for this process.

7.7.3 Consultant shall provide on an annual basis a report of all warranty and/or maintenance

events performed for that year. The City reserves the right to request such a report from time to time to review and audit the content. At minimum, the report should be supplied in electronic format that can be manipulated such as spreadsheet indicating each event recorded, who initially recorded it, City contact, dates and times, description of the event, what was done to resolve it, when it was resolved and returned to the City, and any notes or interim responses.

7.8 Software Maintenance

7.8.1 The Consultant must provide EMS software maintenance support during the warranty period.

The Consultant is required to correct all known software bugs reported by 1st level maintenance. The Consultant will participate in the City’s established Change Management Procedures process for reporting and correcting software issues.

Any firmware updates and or programming changes, configuration changes etc. must be coordinated and approved by the City. The Consultant is expected to document the rollout and back out procedures.

7.8.2 Consultant shall act as the single point of contact for the City for maintenance related to

all software purchased regardless of whether they are proprietary to the Consultant or 3rd party products.

7.8.3 Additional support hours beyond warranty and maintenance services will be provided at

the standard rate(s) for the appropriate service by skillset as listed in Attachment A Fee Schedule.

7.8.4 In accordance with the submitted Warranty and Maintenance Plan, the Consultant shall

establish a recommended Service Level Agreement (SLA) that defines the severity of problems and the associated response time based on categories used by the City. The criteria established for response escalation will be negotiated with the City.

SECTION V - SUBMITTAL



Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________

Solicitation Due Date: January 29, 2016 Solicitation No. RFP 16-085 (REN)

of 221

Please submit one original and eight copies of the Submittal (Section V). In addition to the items listed in Section I #17, Preparation of Solicitation, please submit only Section V, do not submit a copy of the entire solicitation document. This offer will remain in effect for a period of 120 calendar days from the bid opening date and is irrevocable unless it is in the City’s best interest to do so. Original submittal shall be loose-leaf, no binder, non-stapled, held together by a clip. Copies may be clipped or stapled. One electronic copy of the proposal in Microsoft Word (.docs) or Excel (.xlsx) on a standard USB device. An accompanying PDF version may also be included for reference only, however an electronic version in native format is mandatory. 1. PREPARATION OF SOLICITATION

All printed, excel spreadsheet, electronic media (CD/DVD, Jump Drive or etc.), build sheets in the Submittal Section must be completed and accurate with your response. It is permissible to copy both sections if necessary. Erasures, interlineations, or other modifications of your solicitation shall be noted by the authorized person signing the solicitation. No submittals shall be altered, amended or withdrawn after the specified solicitation due time and date. The City is not responsible for offeror’s errors or omissions. All time periods stated as a number of days shall be calendar days. Any deviation from this solicitation shall be clearly stated and identified in a separate section titled Request for Consideration of Alternate Terms and must be included with your submittal. Solicitations submitted with additional/alternate terms, conditions or agreements may be considered as non-responsive and rejected. Due to the complexity of the offers and to aid in the evaluation, the offers should contain all required information in tabbed sections as indicated in the electronic spreadsheet. Omissions or alternations of the electronic spreadsheet will be sufficient grounds for the City to consider your offer to be non-compliant. The submittal shall include ample written evidence, in the form of technical specification, cut/tear sheets, brochures, pictures, drawing, etc., to demonstrate that all specifications herein have been met and/or exceeded Offeror shall organize and submit their response (printed and electronic) in the following order: A. Section IV, Scope (excluding pre-delivery and warranty checklist) B. Request for Consideration of Alternate Terms (if applicable) C. Evaluation literature, illustrations, specification sheets, blueprints, and photos. D. Build sheets, Technical, Product, Tear Sheets, etc. The following instructions are provided to assist proposers in completing the Fee Schedule. Proposers should add rows as needed. The City is not responsible for any errors on the Fee Schedule. Each proposer is responsible for ensuring the integrity of all worksheet formulas. Any pricing inconsistency will be resolved in the City’s favor.

2. EMS CORE APPLICATION AND MODULES SECTION—ATTACHMENT A: Proposers must list by phase the application modules, broken out by type of license and any other modules needed to meet the project requirements listed in the Request for Proposal. If modules are bundled or included in the price of the base application, list each on a separate line with a zero fee. Prices shall be all inclusive i.e. they shall include applicable taxes. In the event taxes cannot be assessed, a clearly stated note shall include that the item is subject to tax and what that the




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________


of 221

current tax is. Proposers must list the fees for annual maintenance on a year by year basis starting from end of warranty which is one (1) year after final acceptance for a total of four (4) years of maintenance.

3. INTEGRATIONS SECTION—ATTACHMENT A: Integrations to other systems required as listed by Phase shall be listed on the Fee Schedule and must be priced. If integrations are bundled or included in the base price of the proposed EMS application, list each on a separate line with a zero fee. Proposers must list the applicable tax and fees for annual maintenance similarly to the EMS Core application and Modules Section. In the event taxes cannot be assessed, a clearly stated note shall include that the item is subject to tax and what that the current tax is. Proposers must list the fees for annual maintenance on a year by year basis starting from end of warranty which is one (1) year after final acceptance for a total of four (4) years of maintenance.

4. PROFESSIONAL SERVICES SECTION—ATTACHMENT A: Proposers must list all hourly rates required to implement the proposed EMS application. Assume all skillsets in Phase One unless a new skillset must be used in a subsequent phase. In the event of new skillset added, include rates for subsequent years even though they may supersede skillsets in Phase One. All rates will be used in the event of a change control situation. Provide rates based on a skillsets. Change orders will require that all charges be listed in hours and skillsets as submitted and accepted by the successful proposer. List hourly rates in years 2–5 in appropriate cells.

5. Total Implementation Cost Phase 1: This price must be inclusive of everything for the Phase One implementation. All costs associated with any additional modules or integrations identified as needed by the successful proposer during the course of this project not included in this Total Project Implementation Cost shall be borne by the successful proposer.

Phase 1 Total Cost

Project Implementation Cost Phase 1 Subtotal (no tax)

First Year Warranty

Years 2–5 Maintenance Fees

Total Project Implementation Cost* Phase 1

$

Tax Amount (for taxable items)

*The Total Project Implementation Cost must include the Total Application and Modules Cost, Total Integrations Cost, and Total Professional Services Cost to implement Phase One of the project.




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________


of 221

6. Total Implementation Cost Phase 2 Add Alternate: This price must be inclusive of everything for the Phase Two implementation. All costs associated with any additional modules or integrations identified as needed by the successful proposer during the course of this project for Phase Two not included in the Total Implementation Cost Phase Two Add Alternate shall be borne by the successful proposer.

Phase 2 Total Cost

Add Alternate Cost: Phase 2 Subtotal (no tax)

First Year Warranty



$


* Include any elements that are Phase 2 in the cost sheets from Application and Modules Cost, Integrations Cost, and Professional Services Cost to implement Phase 2 of the project.

7. Total Implementation Cost Phase 3 Add Alternate: This price must be inclusive of everything

for the Phase Three implementation. All costs associated with any additional modules or integrations identified as needed by the successful proposer during the course of this project for Phase Three not included in the Total Implementation Cost Phase Three Add Alternate shall be borne by the successful proposer.

Phase 3 Total Cost

Add Alternate Cost: Phase 3 Subtotal (no tax)

First Year Warranty



$


* Include any elements that are Phase 3 in the cost sheets from Application and Modules Cost, Integrations Cost, and Professional Services Cost to implement Phase 3 of the project.




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________


of 221

8. PAYMENT TERMS Contractor offers a prompt payment discount of _______% _______ days to apply after receipt of invoice or final acceptance of the products, whichever is later. If no prompt payment discount is offered, enter 0 in the % space to indicate net 30 days, otherwise payment terms shall be 2% 20 days, net 30 days; effective after receipt of invoice or final acceptance of the products, whichever is later. Payment terms offering less than 20 days will not be considered in the price evaluation of your bid. Any prompt payment terms offered must be clearly noted by the Contractor on all invoices submitted to the City for the payment of goods or services received.

9. REFERENCES Contractor shall furnish the names, addresses, and telephone numbers of a minimum of three (3) firms or government organizations for which the Contractor is currently furnishing or has furnished, in the past, completed service of similar size and scope. Company Name Address Reference Telephone Number Email address Company Name Address Reference Telephone Number Email address Company Name Address Reference Telephone Number Email address




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________


of 221

OFFER TO THE CITY OF PHOENIX: The Undersigned hereby offers and agrees to furnish the material and or service(s) in compliance with all terms, conditions, specifications, and addenda issued as a result of solicitation and any written exceptions in the offer. Arizona Sales Tax No.

Use Tax No. for Out-of State Suppliers

City of Phoenix Sales Tax No.

Taxpayer’s Federal Identification No. : If recommended for contract award, Offeror agrees to provide its federal taxpayer identification number or as applicable its social security number to the City of Phoenix for the purposes of reporting to appropriate taxing authorities, monies paid by the City of Phoenix under the awarded contract. If the Offeror provides its social security number, the City will only share this number with appropriate state and federal officials. This submission is mandatory under 26 U.S.C. § 6041A.

OFFEROR MUST BE IN COMPLIANCE AT THE TIME OF AWARD

Enter City’s Registration System ID Number Located at City’s eProcurement website (see SECTION I –

INSTRUCTIONS - CITY’S REGISTRATION)

Offeror has read, understands, and will fully and faithfully comply with this solicitation, its attachments and any referenced documents. Offeror certifies that the prices offered were independently developed without consultation with any of the other offerors or potential offerors. Authorized Signature Date Printed Name and Title Company Name

Address

City, State and Zip Code

Telephone Number

Company’s Fax Number

Company’s Toll Free #

Email Address




Phoenix, AZ 85003 Phone: (602) 262-7181

Company Name___________________________________________________________


of 221

ACCEPTANCE OF OFFER The Offer is hereby accepted. The Contractor is now bound to sell the materials or services listed by the attached contract and based upon the solicitation, including all terms, conditions, specifications, amendments, etc. and the Contractor’s Offer as accepted by the City. This contract shall henceforth be referred to as Contract No. . The Contractor has been cautioned not to commence any billable work or provide any material or service under this contract until Contractor receives purchase order, or contract documentation.

City Clerk Approved as to form this 19 day of November, 2014

This document has been approved as to form by the City Attorney and is on file with the City Clerk. It need not be submitted to the City Attorney for approval unless the form document is altered.

CITY OF PHOENIX, a municipal corporation Ed Zuercher, City Manager

Jim Campion, Deputy Finance Director

Awarded this ______ day of _____________, 2015.

EXHIBIT A: AVIATION TECHNOLOGY PROJECT MANAGEMENT METHODOLOGY



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

EXHIBIT B: SUPPLEMENTAL TERMS AND CONDITIONS TO ALL AIRPORT AGREEMENTS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

A. Definitions

1. "Airport" means Phoenix Sky Harbor International Airport, Phoenix Deer Valley Airport and/or Phoenix Goodyear Airport, in accordance with the context of the contract.

2. "Contract" includes any and all City of Phoenix Aviation Department contracts, subcontracts, agreements, leases, subleases, licenses, permits, concessions or other documents, however denominated that grant or convey a right or privilege on an Airport, and to which this Exhibit is annexed and made a part thereof.

3. "Contractor" means every lessee, sublessee, licensee, permittee, concessionaire or other person, firm or corporation exercising a right or privilege on an airport pursuant to a contract, and includes Contractor's heirs, personal representatives, successors-in-interest and assigns.

4. "Premises" means the leasehold or site occupied by Contractor pursuant to the lease, license or permit that is the subject of this Contract.

B. Assurances

1. Contractor shall furnish its services on a fair, equal and not unjustly discriminatory basis to all users of the Airport.

2. Contractor shall charge fair, reasonable and not unjustly discriminatory prices for each unit or services; provided that, Contractor may be allowed to make reasonable and non-discriminatory discounts, rebates or other similar types of price reductions to volume purchasers. Non-compliance with this requirement shall be a material breach of this Contract for which the City of Phoenix shall have the right to terminate this Contract and any estate created herewith, without liability therefor; or, at the election of the City of Phoenix or the United States, either or both of said Governments shall have the right to judicially enforce said requirement.

3. Contractor warrants that no person shall, on the grounds of race, creed, color, national origin, sex, age or handicap, be excluded from participating in any activity conducted on or from the Premises, or otherwise be excluded from the benefits offered by Contractor to the general public. Contractor further warrants that it will comply with all pertinent statutes, Executive Orders, and rules promulgated thereunder, to assure that no person is excluded on the grounds of race, creed, color, national origin, sex, age, or handicap.

4. As a part of the consideration for this Contract, Contractor does hereby covenant and agree that in the event facilities are constructed, maintained, or otherwise operated on the Premises for a purpose for which a DOT program or activity is extended for another purpose involving the provision of similar services or benefits, Contractor shall maintain and operate such facilities and services in compliance with all other requirements imposed pursuant to Code of Federal Regulations, Title 49, DOT, Subtitle A, Office of the Secretary of Transportation, Part 21-Nondiscrimination in Federally-Assisted Programs of the Department of Transportation--Effectuation of Title VI of the Civil Rights Act of 1964, as said regulations exist and may be amended from time-to-time.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

If this Contract is a lease, then this Covenant is hereby made a covenant running with the land for the term of the lease, and is judicially enforceable by the United States.

5. As a part of the consideration of the Contract, Contractor does hereby covenant and agree

that: (1) no person on the grounds of race, color or national origin shall be excluded from participation in, denied the benefits of, or be otherwise subjected to discrimination in the use of said facilities; (2) in the construction of any improvements on, over or under such Premises and the furnishing of services thereon, no person on the grounds of race, color or national origin shall be excluded from participation in, denied the benefits of, or otherwise be subjected to discrimination; and that the contractor shall use the Premises in accordance with all other requirements imposed pursuant to 49 C.F.R. Part 21, as it may be amended. If this Contract is a lease, then this Covenant is hereby made a covenant running with the land for the term of the lease, and is judicially enforceable by the United States.

6. The foregoing discrimination covenants are a material part of this Contract and for breach thereof the City of Phoenix shall have the right to terminate this Contract and to reenter and repossess the Premises and facilities thereon, and hold the same as if said Contract had never been made. This provision does not become effective until the procedures of 49 CFR Part 21 are followed and completed, including expiration of appeal rights.

7. Contractor agrees to insert the foregoing six provisions in any contract by which Contractor grants a right or privilege to any person, firm or corporation to render accommodations and/or services to the public on or from the Premises.

8. Contractor agrees that it will undertake an affirmative action plan in conformance with 14 CFR Part 152, Subpart E, to insure that no person shall on the grounds of race, creed, color, national origin or sex be excluded from participating in any employment, contracting or leasing activities covered in 14 CFR Part 152, Subpart E. Contractor assures that no person will be excluded on such grounds from participating in or receiving the services or benefits of any program or activity covered by Subpart E. Contractor further agrees that it will require its covered suborganizations to provide assurances to Contractor that they similarly will undertake affirmative action programs and that they will require like assurances from their suborganizations, as required by 14 CFR Part 152, Subpart E.

9. City of Phoenix reserves the right to further develop, improve, repair and alter the Airport

and all roadways, parking areas, terminal facilities, landing areas and taxiways as it may reasonably see fit, free from any and all liability to Contractor for loss of business or damages of any nature whatsoever to Contractor occasioned during the making of such improvements, repairs, alterations and additions.

10. The City of Phoenix reserves the right, but is in no way obligated to Contractor, to maintain and keep in repair the landing area of the Airport and all publicly owned facilities of the Airport, together with the right to direct and control all activities of Contractor in this regard.

11. Contractor acknowledges that this Contract is subordinate to any existing or future agreement between the City of Phoenix and the United States concerning the development, operation or maintenance of the Airport. In the event that FAA or its successors require modifications or changes in the Contract as a condition to the obtaining of funds for improvements at the Airport or as a requirement of any prior grants, Contractor hereby consents to any and all such modifications and changes as may be reasonably




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

required and agrees that it will adopt any such modifications or changes as part of this Contract.

12. The Contract is subordinate to the reserved right of the City of Phoenix, its successors and

assigns, to occupy and use for the benefit of the public the airspace above the Premises for the right of flight for the passage of aircraft. This public right of flight shall include the right to cause in said airspace any noise inherent in the operation of any aircraft through said airspace or in landing at or taking off from, or operation on an Airport.

13. Contractor agrees to comply with the notification and review requirements as required by

Title 14 of the Code of Federal Regulations, 14 CFR Part 77- Objects Affecting Navigable Airspace, in the event future construction of a structure is planned for the Premises, or in the event of a planned modification of a structure on the Premises. Contractor shall submit the required FAA Form 7460-1— Notice of Proposed Construction or Alteration—and provide documentation showing compliance with the federal requirements. Once the FAA has completed the aeronautical study, Contractor shall provide to the City of Phoenix the FAA determination letter on proposed construction and any impact to air navigation. Contractor covenants for itself, its successors and assigns that it will not erect or permit the erection of any structure or permit the growth of any tree, on the Premises above the mean sea level elevation for: (1) Phoenix Sky Harbor International Airport, 1,133 feet; (2) Phoenix Goodyear Airport, 968 feet; (3) Phoenix Deer Valley Airport, 1,476 feet. As a remedy for the breach of said covenant the City of Phoenix reserves the right to enter upon the Premises and remove the offending structure or cut the offending tree, all at the expense of Contractor.

14. Contractor, by accepting this Contract, covenants for itself, its successors and assigns that

no use will be made of the Premises that might in any manner interfere with the landing and taking off of aircraft from the Airport, or otherwise constitute a hazard to air navigation. As a remedy for the breach of said covenant the City of Phoenix reserves the right to enter upon the Premises and cause the abatement of such interference, all at the expense of Contractor.

15. Contractor acknowledges that nothing contained in this Contract shall be construed to grant

or authorize the granting of an exclusive right within the meaning of 49 U.S.C. §40103(e). 16. This Contract and all the provisions hereof are subordinate to whatever rights the United

States now has or in the future may acquire affecting the control, operation, regulation and taking-over of the Airport, or the exclusive or non-exclusive use of the Airport by the United States during a time of war or national emergency.

17. If the Contract involves construction, the contractor shall carry out the project in accordance

with FAA airport design, construction and equipment standards and specifications current on the date of project approval.

18. Contractor is encouraged to use fuel and energy conservation practices.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

C. City of Phoenix Equal Employment Opportunity Requirement

1. If Contractor is by this Contract a supplier to, or lessee of, the City, then the requirements of the Phoenix City Code, Chapter 18, Article V applies, including the agreement that:

“Any supplier/lessee in performing under this contract shall not discriminate against any worker, employee or applicant, or any member of the public, because of race, color, religion, sex, national origin, age, or disability, nor otherwise commit an unfair employment practice. The supplier and/or lessee shall ensure that applicants are employed, and employees are dealt with during employment without regard to their race, color, religion, sex, national origin, age, or disability, and shall adhere to a policy to pay equal compensation to men and women who perform jobs that require substantially equal skill, effort, and responsibility, and that are performed within the same establishment under similar working conditions. Such action shall include but not be limited to the following: employment, promotion, demotion or transfer, recruitment or recruitment advertising, layoff or termination; rates of pay or other forms of compensation; and selection for training; including apprenticeship. The supplier further agrees that this clause will be incorporated in all subcontracts with all labor organizations furnishing skilled, unskilled and union labor, or who may perform any such labor or services in connection with this contract.” Supplier/lessee further agrees that this clause will be incorporated in all subcontracts, job-consultant agreements or subleases of this agreement entered into by supplier/lessee.

If the supplier/lessee employs more than thirty-five employees, the following language shall be included as the last paragraph to the clause above:

“The supplier/lessee further agrees not to discriminate against any worker, employee or applicant, or any member of the public, because of sexual orientation or gender identity or expression and shall ensure that applicants are employed, and employees are dealt with during employment without regard to their sexual orientation or gender identity or expression.”

2. Documentation. Suppliers and lessees may be required to provide additional

documentation to the Equal Opportunity Department affirming that a nondiscriminatory policy is being utilized.

3. Monitoring. The Equal Opportunity Department shall monitor the employment policies

and practices of suppliers and lessees subject to this article as deemed necessary. The Equal Opportunity Department is authorized to conduct on-site compliance reviews of selected firms, which may include an audit of personnel and payroll records, if necessary.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

D. Immigration Reform and Control Act of 1986 (IRCA)

Contractor understands and acknowledges the applicability of the IRCA to it. Contractor agrees to comply with the provisions of IRCA as it applies to its activities under this Contract and to permit the City of Phoenix to inspect its personnel records to verify such compliance.

E. Conflict of Interest

Contractor acknowledges that the terms and conditions of Arizona Revised Statutes (A.R.S.) § 38-511 are incorporated into this Contract.

F. Legal Worker Requirements The City is prohibited by A.R.S. § 41-4401 from awarding an agreement to any contractor who

fails, or whose subcontractors fail, to comply with A.R.S. § 23-214(A). Therefore, Contractor agrees that:

1. Contractor and each subcontractor it uses warrants their compliance with all federal

immigration laws and regulations that relate to their employees and their compliance with § 23-214, subsection A.

2. A breach of warranty under paragraph 1 shall be deemed a material breach of the Agreement and is subject to penalties up to and including termination of the Agreement.

3. The City retains the legal right to inspect the papers of the Contractor or subcontractor employee(s) who work(s) on this Agreement to ensure that Contractor or subcontractor is complying with the warranty under paragraph 1.

G. Disadvantaged Business Enterprise Requirements

1. To the extent that this Contract is covered by 49 CFR Part 26, Contractor agrees that this Contract is subject to the requirements of the U.S. Department of Transportation Regulations at 49 CFR Part 26. The Contractor or subcontractor shall not discriminate on the basis of race, color, national origin, or sex in the performance of this contract. The Contractor shall carry out applicable requirements of 49 CFR Part 26 in the award and administration of DOT assisted contracts. Failure by the Contractor to carry out these requirements is a material breach of this contract, which may result in the termination of this contract or such other remedy as the recipient deems appropriate.

Contractor agrees to include the foregoing statement in any subsequent Contract that it enters and cause those businesses to similarly include said statement in further agreements.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

2. To the extent that the Contract is a concession agreement covered by 49 CFR Part 23, the concessionaire or contractor agrees that it will not discriminate against any business owner because of the owner's race, color, national origin, or sex in connection with the award or performance of any concession agreement, management contract, or subcontract, purchase or lease agreement, or other agreement covered by 49 CFR Part 23.

The concessionaire or contractor agrees to include the above statements in any subsequent concession agreement or contract covered by 49 CFR Part 23, that it enters and cause those businesses to similarly include the statements in further agreements.

EXHIBIT C: SAMPLE DELIVERABLES LOG



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Item # WBS Submittal / Milestone

Description Planned Delivery

Date % Value $ Value

Actual Delivery

Date

PHX Acceptance

Date

Invoice #

Invoice Date

Paid (Y /N)

Notes

I. TBD Submittal Deliverables Log Completion

$ -

II. TBD Submittal Consultant Contacts and Escalation Completion

$ -

IV. TBD Submittal Project Management Plan Completion

$ -

V. TBD Submittal

Updated System Specifications Document Completion

$ -

VI. TBD Submittal

Hardware and Software Requirements Document Completion

$ -

VII. TBD Submittal Systems Design Document Completion

$ -

VIII. TBD Submittal Interface Control Document Completion

$ -

IX. TBD Submittal

Updated Hardware and Software Requirements Document Completion

$ -

X. TBD Submittal Acceptance Test Plan and Procedures Completion

$ -

M1 TBD Milestone Acceptance Test Readiness Review Completion

$ -

XI. TBD Submittal Acceptance Test Report & Punch List Completion

XII. TBD Submittal Systems Test Plan and Procedures Completion

$ -

XIII. TBD Submittal Training Plan Completion

$ -

EXHIBIT C: SAMPLE DELIVERABLES LOG



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Item # WBS Submittal / Milestone Description

Planned Delivery Date % Value $ Value

Actual Delivery Date

PHX Acceptance Date

Invoice #

Invoice Date

Paid (Y /N) Notes

XIV. TBD Submittal System Implementation/Go Live Plan Completion

$ -

XV. TBD Submittal Quality and Performance Monitoring Plan Completion

$ -

M2 TBD Milestone System Test Readiness Review Completion

$ -

XVI. TBD Submittal System Test Report & Punch List Completion

$ -

XVII. TBD Submittal Training Material Completion

$ -

XVIII. TBD Submittal 14-Day Go-Live Support Plan Completion

$ -

XIX. TBD Submittal 60-Day Endurance Support Plan Completion

$ -

XX. TBD Submittal System Manuals Completion

$ -

XXI. TBD Submittal Software Licenses Completion

$ -

M3 TBD Milestone 14-Day Go Live Completion 08/11/17

$ -

XXII. TBD Submittal Warranty and Maintenance Plan Completion

$ -

M4 TBD Milestone 60-Day Endurance Test Completion 10/15/17 10.00% $ - This must be 10%

M5 TBD Milestone Warranty Services Commencement 10/15/17 $ -

Total

100.00% $xxx,xxx Total Project Implementation Cost Phase 1

Post Acceptance

Warranty Services Commencement 100.00% $xxx,xxx Agreed to Warranty Fee

EXHIBIT D: SCOPE OF SERVICES PROCESS FLOW



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

ATTACHMENT A: FEE SCHEDULE



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

The following instructions are provided to assist proposers in completing the Fee Schedule.

Proposers should add rows as needed. The City is not responsible for any errors on the

Fee Schedule. Each proposer is responsible for ensuring the integrity of all

worksheet formulas. Any pricing inconsistency will be resolved in the City’s favor.

EMS Core Application and Modules Section: Proposers must list by phase the application

modules, broken out by type of license and any other modules needed to meet the project

requirements listed in the Request for Proposal. If modules are bundled or included in the

price of the base application, list each on a separate line with a zero fee. In the event taxes

cannot be assessed, a clearly stated note shall include that the item is subject to tax and what

that the current tax is. Proposers must list the fees for annual maintenance on a year by year

basis starting from end of warranty which is one (1) year after final acceptance for a total of

four (4) years of maintenance.

Only Phase 1 items should be carried forward to the project implementation total. Anything in Phases Two or Three should be considered as add alternates which may be chosen for implementation by the City at their Discretion. Place Phase Two and Phase Three totals in a separate line as listed.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Phase Application and Modules by

Phase if applicable

Number Required

Unit Cost Pre-Tax Total Cost

Tax Applicable

%

Total Cost with Tax if applicable

Warranty Year 1

Maint Year 2

Maint Year 3

Maint Year 4

Maint Year 5

Notes

1 (List Module or Application)

$ $ $ $ $ $ $ $

1 $ $ $ $ $ $ $ $

1 $ $ $ $ $ $ $ $

1 $ $ $ $ $ $ $ $

2 $ $ $ $ $ $ $ $

2 $ $ $ $ $ $ $ $

3 $ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

Total Application and Modules Cost Phase One Items Only: Carry this amount to the Total Project Implementation Cost

$ $ $ $ $ $

Total Application and Modules Cost Phase Two Items Only: Carry this amount to the Add Alternate Phase Two

$ $ $ $ $ $

Total Application and Modules Cost Phase Three Items Only: Carry this amount to the Add Alternate Phase Three

$ $ $ $ $ $




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Integrations Section: Integrations to other systems required as listed by Phase shall be

listed on the Fee Schedule and must be priced. If integrations are bundled or included

in the base price of the proposed EMS application, list each on a separate line with a

zero fee. Proposers must list the appl icable tax and fees for annual maintenance

similarly to the EMS Core application and Modules Section. In the event taxes cannot be

assessed, a clearly stated note shall include that the item is subject to tax and what that the

current tax is. Proposers must list the fees for annual maintenance on a year by year basis

starting from end of warranty which is one (1) year after final acceptance for a total of four (4)

years of maintenance.

Only Phase One items should be carried forward to the project implementation total.

Anything in Phases Two or Three should be considered as add alternates which may be

chosen for implementation by the City at their Discretion. Place Phase Two and Phase Three

totals in a separate line as listed.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Phase Integrations and Basis for Number

Required

Number Required

Unit Cost Total Cost Before

Tax

Tax Applicable

%

Warranty Year 1

Maintenance Year 2

Maintenance Year 3

Maintenance Year 4

Maintenance Year 5

Notes

Example Phase 1 - VSS - Basis is # of cameras

$ $ $ $ $ $ $ $

Phase 1 - ESRI - Basis is # of ….

$ $ $ $ $ $ $ $

Phase 1 - ENS - Basis is …. $ $ $ $ $ $ $ $

Phase 1 - DVR - Basis is $ $ $ $ $ $ $ $

Phase 2 - EBI - Basis is $ $ $ $ $ $ $ $

Phase 2 - FEBI - Basis is $ $ $ $ $ $ $ $

Phase 2 - DMS - Basis is $ $ $ $ $ $ $ $

Phase 2 - Mobile - Basis is $ $ $ $ $ $ $ $

Phase 3 - OSP - Basis is $ $ $ $ $ $ $ $

Phase 3 - xPort - Basis is $ $ $ $ $ $ $ $

Phase 3 - Phone System $ $ $ $ $ $ $ $

$ $ $ $ $ $ $ $

Total Integrations Cost Phase 1 Items Only: Carry this amount to the Total Project Implementation Cost

$

$ $ $ $ $

Total Integrations Cost Phase 2 items Only: Carry this amount to the Add Alternate Phase 2

$ $ $ $ $ $

Total Integrations Cost Phase 3 items Only: Carry this amount to the Add Alternate Phase 3

$ $ $ $ $ $




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Professional Services Section: Proposers must list all hourly rates required to implement the

proposed EMS application. Assume all skillsets in Phase One unless a new skillset must be used in a

subsequent phase. In the event of new skillset added, include rates for subsequent years even though

they may supersede skillsets in Phase One. All rates will be used in the event of a change control

situation. Provide rates based on a skillsets. Change orders will require that all charges be listed in

hours and skillsets as submitted and accepted by the successful proposer. List hourly rates in years 2–

5 in appropriate cells.

Only Phase 1 items should be carried forward to the project implementation total. Anything in Phases Two or Three should be considered as add alternates which may be chosen for implementation by the City at their Discretion. Place Phase Two and Phase Three totals in a separate line as listed.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Phase Professional Services Hours Required

Hourly Rate Cost

Total Cost Year 2 Rate Year 3 Rate Year 4 Rate Year 5 Rate Notes

1 List each Skill Set Description

$ $ $ $ $ $

1 $ $ $ $ $ $

1 $ $ $ $ $ $

1 $ $ $ $ $ $

2 $ $ $ $ $ $

2 $ $ $ $ $ $

3 $ $ $ $ $ $

$ $ $ $ $ $

$ $ $ $ $ $

$ $ $ $ $ $

$ $ $ $ $ $

$ $ $ $ $ $

Total Implementation Cost Phase 1 Items Only: Carry this amount to the Total Project

$ N/A N/A N/A N/A

Total Implementation Cost Phase 2 Items Only: Carry this amount to the Add Alternate Phase 2

$ N/A N/A N/A N/A

Total Implementation Cost Phase 3 Items Only: Carry this amount to the Add Alternate Phase 3

$ N/A N/A N/A N/A

ATTACHMENT B: COMPLIANCE MATRIX



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Table of Content Event Management System Architecture

Back End Infrastructure

Servers

System Administration Requirements

Systems Integration

Data Base

Mobile Devices

Printers

Users and Devices

Security Requirements

Functional Requirements

General Event Management System Functionality

Roles

Business Rules/ Response Planning Requirements

Response Plan Creation/ Editing

Operational Workflow Requirements

Event Management Requirements

Event Creation/ Update/ Closing Requirements

Active Event Display Requirements

Event Assignment Requirements

Resource Management Requirements

Resource Planning Requirements

Resource Dispatching and Tracking Requirements

Resource Mapping and Display Requirements




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Event Management System Query and Report Requirements

Standard and Customized Reports

Search Capabilities

Executive Dashboard Requirements

Event Management System Interface Requirements Phase 1

Video Surveillance System (VSS)

Geographic Information System (GIS)

Map Editing and Content Requirements

Geo-Location Requirements

Map Display Requirements

Map Display and Operational Requirements

Emergency Notification System (ENS)

Digital Voice Recorder (DVR)


Enterprise Building Inegrator (EBI)

Access Control and Alarm Monitoring System (ACAMS)

Fire Enterprise Business Inegrator (FEBI)

Digital Monitoring System (DMS)

Mobile Devices


Operations Security Portal (OSP)

XPort

Phone System (Vesta)

Event Management System Performance Requirements




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

WC = Will Comply as part of core systems; RD = Will comply - Requires Development with comments; IN = Will comply - requires integration with comments; NC = Will Not Comply with comments

SSD Section Requirement Description Compliance Code Comments

WC RD IN NC

EVENT MANAGEMENT SYSTEM ARCHITECTURE

Section 3 Event Management System Architecture

There will be no additional VMware or server operating system licenses necessary if Windows is used as the operating system. Licensing shall be included without additional cost if another operating system is used, by the Contractor, for test servers, workstations and the database unless it will reside on the Oracle Exadata system.

The EMS shall be based on a server-based platform housed in the Airport's data center as described below in Section 3.

It may be client/server based or web server/web browser based (preferred).




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 3.1 Back End Infrastructure

The City would like an EMS design that allows for redundant application and database servers to reside on separate hosts within the VMware cluster to protect against interruptions in service that may result from high availability events and/or routine maintenance of systems such as applying security patches.

The City has standardized on system backup software that relies on VMware snapshot and windows volume shadow copy services to capture the backups. The EMS must be compatible with these services, and not be operationally impacted by them.

The EMS servers must be capable of running in the Airport's existing back end infrastructure as virtual machines.

Section 3.2 Servers

Virtualization using VMware is the standard method for deploying servers, and Windows Server 2012 R2 is predominantly used as the guest operating system.

Database and application servers will run on separate virtual machines.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 3.3 System Administration Requirements

1 The EMS shall support virtualization technologies to run on VMware VSphere platforms.

2 The EMS administrators shall be able to control and configure permissions, actions, views, and device restrictions by user-ids, or user groups within the EMS.

3 The EMS shall support user groups and user role definitions. User ids will be associated to roles and be given associated privileges/permissions.

4 The EMS shall be able to log and track all logins access and unauthorized access attempts.

5 The EMS shall be able to configure and save workstation preferred layouts by user-id or user group so that it comes up automatically when user logs into the application.

6 The EMS shall maintain an audit log of all data creation, update, and deletion tied to user-id.

7 The EMS shall include an Application Programming Interface (API).

8 The EMS shall include a Software Development Kit (SDK) that allows third parties to integrate with the EMS.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


9 The EMS shall support a monitoring tool indicating the status of all EMS components and status of externally connected systems.

Section 3.4 Systems Integration

1 The EMS shall be based on an open architecture.

a This means that any function can be accessed either through the existing user interface or has an API that can access the function programmatically.

b Data architecture shall be published as a generally available function so that programs may access the underlying data for reporting or information integration to other systems.

2

The Oracle Service Oriented Architecture (SOA) suite of middleware is the preferred method to accomplish all system integrations with the EMS. If the contractor has an existing interface or adaptor to one of the systems in Table 2 Systems to be integrated with EMS already developed it can be used to accomplish a systems integration.

a Any new developed integration, not already established, shall be accomplished using Oracle SOA.

b In accordance with the submittal requirements, the Contractor will specify the exact Oracle SOA modules and quantities of licenses needed to support the EMS and system interfaces.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 3.6 Data Base

The consultant may use either SQL or Oracle Database software.

Section 3.7 Mobile Devices

The EMS will need to support at least 100 mobile devices when phase 2 is implemented.

Section 3.8 Printers

Printers for the EMS will be networked printers at distributed locations in the CC. The EMS must be capable of printing in color on paper sizes up to 11”x17”.

Users and Devices

Section 4 Users and Devices

The EMS will be accessible to staff in the CC, other airport campus facilities and remotely via VPN.

1

Users: Users having access to the EMS on a regular basis whose primary responsibility is managing events. They may be from multiple divisions and on multiple shifts. This includes laptops with remote access, but not using a mobile EMS application.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


2 Concurrent Users: Total number of users or workstations that will normally use the system simultaneously.

3 Mobile Users: Number of users accessing the EMS mobile application from mobile devices such as smart phones, laptops, and MDTs.

4 Concurrent Mobile Users: Total number of mobile devices that will normally access the EMS mobile application simultaneously.

c Ability to assign access to functions, screens and/or databased upon user role.

3 Every authorized user of the EMS system shall be assigned to a pre-defined selection of roles that will define the features and functions of the system that this user will be permitted to access.

4 The system must support antivirus program scans without disruption to the EMS system and database. The current antivirus program installed at the Airport is Symantec Endpoint Protection version 12.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Functional Requirements

Section 6.1 General Event Management System Functionality

1 The EMS shall have the ability to launch other applications in their native mode from within the EMS.

2 The EMS shall have the ability to manually or automatically create an event with the occurrence of pre-defined incidents.

3

The EMS shall assign all new events to an EMS operator/group: this operator/group will be the events owner and will be responsible for acknowledging and resolving the event. All members of this group can input to this event and close the event.

4 The EMS shall have the ability for members of designated groups to create, dispatch, display, update, and close an event.

5 The EMS shall have the ability to filter and correlate events based on:

a Time of occurrence

b Location

c Type of event

e Other parameters that can be defined by the user

6 The EMS shall have the ability to display a current list of all active events, text based list, and graphical display on a map. Different icons will be displayed based on different types of events and varying event statuses.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.1 General Event Management System Functionality (cont'd)

7 The EMS shall have the ability to display entire chronological history of an event or resources with audit trail of all entries with time stamp and user id.

8 The EMS shall provide easy navigation to access maps, cameras, devices, files, and forms associated with an event.

9 The EMS shall support editable forms to be completed with an event.

a Completed forms will be stored with the event log and accessible for viewing.

10 The EMS shall have a common event summary/dashboard page which is configurable by system administrators and end users. Multiple dashboard layouts will be possible, not just one.

11 The EMS shall facilitate:

a video surveillance

b alarm monitoring

c incident response

d event notifications

e resource dispatch functionality

12 The EMS operator shall have the ability to view and manage resources/devices of different types monitored by the system.

13 The EMS shall have the ability to support multiple windows across multiple monitors at a single position.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.1 General Event Management System Functionality (cont'd)

14 The EMS shall have the ability to manage resources responding to an event.

15 The EMS shall have the ability to interface to specified systems using the Oracle SOA suite 12c or higher when applicable.

16 The EMS shall have the ability to receive signals/data/messages from other systems (e.g., alarm condition or event).

17 The EMS shall have the ability to generate standard and customized reports.

18 The EMS shall have the ability to search event data and export as reports in various file formats (e.g., CSV, PDF).

19 The EMS shall have the ability to customize user interfaces and user functions to match required Response Plans.

20 The EMS shall have a notepad function to record notes not associated with an event.

21

The EMS shall include a robust context-based help module to include but not limited to: training files, FAQ’s, best practices, and other insights. It must include the ability for Administrators to edit or supplement the help modules content.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.2 Roles

1 At minimum, the EMS shall support an Administrative and a User role with the following capabilities:

a Administrator Role functionality:

i System configuration

ii System management

iii Integrated systems management

iv User/Account management

v Security management (system security)

vi Audit and user tracking

vii System status and trouble-shooting

viii All user role capabilities

b User Role functionality:

i Multiple user roles that can be defined as necessary

ii System screens designed, laid out, and configured to support the functions and user interfaces with all the integrated systems.

iii User configuration mechanisms, allowing a high-level configuration of alert settings or Response Plan settings based on user-defined requirements and Business Rules.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.2 Roles (cont’d)

iv Monitoring alarms and creating event logs.

v System status screens, including EMS and integrated systems status

vi On-line access for help and troubleshooting

Section 6.3 Business Rules/ Response Planning Requirements

Section 6.3.1 Response Plan Creation/ Editing

Note: Response Plan will also be known as a Checklist.

1 The EMS shall include an event Response Planning module. This module will include an interactive, graphical-based editor to handle the Response Plan creation process.

2 The Response Plan editor shall allow operator to save specific steps so that they can be incorporated into other Response Plans without the necessity of re-creating them each time.

3 The Response Plan editor shall allow existing Response Plans to be incorporated into new Response Plans, allowing operator to create complex operations procedures with minimal effort.

4 The Response Plan editor shall support adding manually initiated device command tasks in the response procedures. Device command tasks should include camera control, control doors, dispatch, sending message, etc.

5 The Response Plan editor shall have a Form Manager module to create preconfigured forms to collect event data and to import custom forms from external sources.

Section 6.3.1 Response Plan Creation/ Editing (cont’d)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.3.1 Response Plan Creation/ Editing (cont’d)

6

The EMS shall have the ability to associate a form with event types, tasks, and Response Plans. Forms can be filled out in real-time to collect and save event details (e.g., bomb threat, hazardous material, alert form, accident report, etc.).

7 The Response Plan editor shall be able to create drop down lists, check boxes to facilitate easy and accurate data entry, to include user definable call taker questions linked to event types.

8 Response Plans shall include conditional branches of actions to take based on decision point responses.

9 Response Plan actions shall be independent or dependent on other actions.

10

Each event type shall be associated with a specific Response Plan(s), so that when a specific event type is triggered, the Response Plan presented to operator is specifically designed to address and resolve the characteristics of that event type.

11 The EMS shall allow configuring and executing event triggering rules. Multiple triggering rules can be set per event type.

12 The EMS shall be able to define triggers that cause an automatic action when it occurs (e.g., specific status reached - then the EMS sends messages).

13 The EMS shall have the ability to modify and adapt Response Plans without taking the EMS off line.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.3.2 Operational Workflow Requirements

1 The EMS shall be able to automatically create an event when pre-defined criteria has been met.

2 The EMS shall allow users to manually create events.

3 The EMS shall automatically provide Response Plans to operator when an event is created.

4 The EMS shall allow operator to execute the event Response Plan.

5 The EMS shall allow an operator to multitask between events.

6 The EMS shall log all Response Plan tasks executed by the operator.

7 The EMS shall present Response Plan execution overall progress to the operator.

8 Response Plan actions shall carry over to other related events.

9 Response Plans shall change based on new information entered about an event (e.g., 1st responder confirms injuries, Response Plan changes to include medical procedures).

10 The Response Plan shall support automatic or manual initiation of device and EMS commands when an event is created.

11 In case of automated function, the EMS shall allow operator to continue working while command is being executed.

12 The EMS shall support both manual selection and automatic selection (based on event that triggered the event) of the device to receive a command.

13 The EMS shall manually and automatically set the priority that will be associated with the event.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.3.2 Operational Workflow Requirements (cont’d)

14 The EMS shall allow operator to supplement the Response Plan procedures in real-time when the current situation demands such changes. The additions will be recorded in the event log.

15 The EMS shall display an alert notification if Response Plans are not carried out in a configurable time frame or by the closure of the event. Alert notifications are configurable based on user roles.

16 Multiple operators shall be able to work on events simultaneously. If one operator completes a required action, it is noted in the log and is complete for all others working the event.

17 Events shall be assigned to a single operator or group for management, and reassigned if required.

18 Tasks within an event Response Plan shall be able to be assigned/distributed to a specific operator or group of operators.

19 Operators shall be able to perform the following actions regarding tasks:

a Task assignment/acknowledgement

b Update status

c Complete task

d Cancel task

e Reassign task

f Mark as in progress

g Supervisor may reassign task to a different operator




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.3.2 Operational Workflow Requirements (cont’d)

20 Completed tasks shall be shown as completed.

21 All actions performed on tasks shall be time-stamped and recorded in database along with user id or operator performing the action.

22 The EMS shall have the ability to assign (dispatch) a resource in response to an event.

23

The assigned resource shall come from a resource database of available response resources (Operations, Police, Fire, etc.). The EMS shall provide the ability to add resources “on the fly” without accessing the database manager.

24 The EMS shall alert operator every time a new event requiring action is created. Alert remains until acknowledged by operator.

25 The EMS shall alert operator when tasks timeout or status changes.

26 The EMS shall support a timeout feature for events and resources with user definable interval timers.

27 All notifications sent when a resource or event times out shall be automatically written to event & resource logs.

Section 6.4 Event Management Requirements

Section 6.4.1 Event Creation/ Update/ Closing Requirements

1 The EMS shall permit event creation in either of two ways:

a Manually: By operator with the appropriate permissions

b Automatically: by the EMS based on pre-defined triggers or conditions.

2 The EMS shall have the ability to create an event by selecting an event type.

3 The creation of an event shall display a Response Plan.

4 The EMS shall have the ability to classify the event using definable event type codes.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.4.1 Event Creation/ Update/ Closing Requirements (cont’d)

a The EMS must support an unlimited amount of event types.

5 The EMS shall allow creation of a new event with/without a geographical location.

6 The EMS shall allow setting and changing event location.

7 The EMS shall be able to assign a location of an event by pointing and clicking on a map or selecting from a list of default locations.

8 The EMS shall automatically assign a unique number to each event created.

9 The EMS shall have the ability to record one or more caller names and locations to an event record.

10 The EMS shall allow the user to manually create an event that does not fall into an existing event type and set the type, priority, description, time, and response procedure.

11 The EMS shall have the ability to automatically assign a priority-based upon pre-defined event priorities.

12 The EMS shall have the ability to override pre-defined event priorities.

13 The EMS shall capture as much information as possible from integrated systems at time of event creation and populate the event record (type, time, location, and alarm data).

14

The EMS shall have ability to override ANI/ALI (Automatic Number Identification / Automatic Location Identification) interface (if enabled) and enter/edit caller information manually including caller name, address, and telephone number.

15 The EMS shall allow editing the event type, priority, and description.

16 The EMS shall allow attaching map & video snapshots and video files to the event.





Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC



17 The EMS shall allow adding comments to the event. Each comment shall be logged with the operator id and time stamp.

18

All data entered will be stored in the event log with an operator id and time stamp. All entries into the event log or event details can be edited, however an audit log of any changes will be maintained with an associated date, time stamp, and operator id.

19 The EMS shall allow operator to execute the event Response Plan.

20 The EMS shall log all Response Plan tasks executed by the operator.

21 The EMS shall update the event log on all operator workstations for any activity associated with the event ensuring a consistent common operational view of the event status.

22 Operators shall be able to accomplish individual tasks on the same event simultaneously.

23 The operator shall have the ability to close an event.

24 The EMS shall allow the operator to add an event resolution and to attach files before closing an event.

25 Any closed event shall be reopened and additional information added to the event.

26 The EMS shall allow an event to be closed even if the Response Plan procedures are incomplete; however the supervisor will be notified of the incomplete Response Plan.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.4.2 Active Event Display Requirements

1 The EMS shall display all active events in a unified list and on a map, if applicable.

2 The active events list shall be sortable on pre-defined criteria (e.g., priority, longevity, type, location).

3 The event details displayed in the active events list shall be configurable to include (but not limited to):

a Date and time the event occurred

b Type of event

c Location of event

d Priority of the event

e Response Plan and status

f Attachments

g Source alarm/device (if applicable)

4 Active events shall be visually differentiated to quickly distinguish between the different event types and priorities. This shall be configurable by administrator.

5 The EMS shall include standard mapping capabilities including pan/zoom and feature selections such as layers, as well as interact with on-map items, etc.

6 The EMS shall allow viewing of live and recorded video from the time of the event. It is preferred that the EMS should display the relevant camera(s) based on the alarmed device or event location.

7 The EMS shall allow viewing details of alarms associated with an event.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.4.2 Active Event Display Requirements (cont’d)

8 The EMS shall allow selection of a camera from a map display and to bring up live and recorded video.

Section 6.4.3 Event Assignment Requirements

The EMS shall provide a method of event/task assignment. Event or task assignment shall not be restricted to an individual user. Event/Task management shall be conducive to a team environment.

1 The system shall allow operators/groups to acknowledge events assigned to them.

2 The EMS shall log and display the time and the user name of the operator that accepted the event.

Resource Management Requirements

Section 6.5 Resource Management Requirements

Section 6.5.1 Resource Planning Requirements

1 The EMS shall have a resource management module to create and edit a database of resources, such as personnel (police, fire fighters, etc.) and vehicles (buses, fire trucks, etc.).

2 The resource management module shall be able to define the types of resources (e.g., Fire Fighters, PD, Ops, Buses, etc.)

3 The resource management module shall be able to define skill sets required to respond to different event types (e.g., bomb assessment skills required to respond to bomb threats).

4 The resource management module shall be able to define areas of coverage.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.5.1 Resource Planning Requirements (cont’d)

5 The resource management module shall be able to define searchable data/attributes associated with resources. Data can be defined as static or dynamic, such as:

a Static data (name, type, skills, areas of coverage, contact info, shift schedule)

b Dynamic data (availability, event assigned to, activity, current status, current location).

6 The resource management module shall be able to bulk upload resource lists into the EMS resource library.

7 The resource management module shall be able to assign resources to hierarchical organizations/groups.

8 The resource management module shall be able to assign a resource to a particular coverage area.

9 The resource management module shall be able to assign a resource as backup to other coverage areas.

10 The resource management module shall be able to create icons for all resources and their attributes (color, blinking, status) for map displays.

11 The operator shall be able to put resources onto a response list and take resources off of a response list.

12 The resource management module shall have a scheduling function for resources (e.g., Police, dispatchers, Ops, etc.)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.5.1 Resource Planning Requirements (cont’d)

13 The resource management module shall have the ability to put personnel on shift and take off shift.

14 The resource management module shall be able to establish pre-defined shift schedules (Rosters) for personnel so shifts are put on duty and made available for assignment automatically by the EMS.

15 Updates to the resource database shall be immediately available in real-time to operators.

16 The EMS shall keep an audit trail and storage of each resources attribute history and user id of operator who made the changes (skill sets changed, contact info changed).

Section 6.5.2 Resource Dispatching and Tracking Requirements

1 The EMS shall provide Command Center functionality to dispatch (aka assign) and track field staff and resources

2 Under optimal condition the EMS shall allow the sorting of active events by resource:

a Single resource maybe assigned to multiple events

b Multiple events might be assigned to a single resource




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.5.2 Resource Dispatching & Tracking Requirements (cont'd)

3 Mobile device users should have the functionality described in Section 6.8.2.

4 The EMS dispatch functionality shall to be a user-friendly, intuitive, and dedicated tool.

5

The EMS shall be able to prominently display a list of appropriate resources available to assign to an event when an event Response Plan calls for it. The EMS must take into consideration resource skills, assigned coverage areas, schedule, availability, etc. in determining their appropriateness to respond.

6 The operator shall be able to manually assign a resource in the event record and have the ability to abort assignment request.

7 The EMS shall be able to automatically update the event record with resources assigned.

8 The operator shall be able to assign a specific resource to respond to an event.

9 The operator shall be able to take a resource off of a lower priority event and dispatch that resource to another event.

10 The operator shall be able to manually update the status of a resource.

11 The EMS shall provide automatic notification to the operators of resource shortage (based upon number of active events versus available resources).




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.5.2 Resource Dispatching & Tracking Requirements (cont'd)

12 The EMS shall keep an audit trail and storage of each resources history including events they responded to, date/time stamp, event number.

13 The EMS shall automatically update the event record every time a resource sends new report or new status.

14 The operator shall be able to call up more detailed information about the resource and its status.

15 The EMS shall provide the ability to message resources with mobile devices.

Section 6.5.3 Resource Mapping and Display Requirements

1 The EMS shall be able to display current status of assigned resources in a visually differentiated manner.

2 The operator shall be able to tailor the display to show selected coverage zones on a map with icon indicating current resource status.

3 The EMS shall have a “Find Nearest Resource” function; by clicking on an event location on a map the EMS will determine and display the nearest resources to that location.

4 By clicking on the resource, the EMS shall display details about that resource (type, skill, availability, contact info). The operator must then have the ability to assign a resource to respond to the event.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.5.3 Resource Mapping and Display Requirements (cont’d)

5 The EMS shall provide real-time locations of available and responding resources (if GPS enabled) and update locations of resources on a map automatically.

6 The operator shall be able to place resources on a map with a drag and drop.

7 The operator shall be able to move an icon/resource on a map from one location to another.

8 The operator shall be able to remove a resource icon from a map.

9 The operator shall be able to declutter the resource map.

Event Management System Query and Report Requirements

Section 6.6 Event Management System Query and Report Requirements

Section 6.6.1 Standard and Customized Reports

1 The EMS shall include a reporting function that allows operator to generate, format, and print reports on various aspects of the system’s operation and performance, including devices, events, resources, etc.

2

The reporting function shall allow operator to select the data in the reports to produce customized reports, to display the reports on the client workstation, to send the reports to a network printer, and to save the reports in at least the following formats:

a XML

b CSV (comma delimited)

c PDF

d HTML




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.6.1 Standard and Customized Reports (cont'd)

e Excel

f Word

3 The reporting function shall incl. at a minimum these types of reports

a Event Summary – a summary report of all events – selectable by variables such as: date/time range, geographic area, coverage area, event type

b

Event Detail – a detail report of one or more events with attachments, chronological activity timeline, and the main event lifecycle information – selectable by variables such as: date/time range, geographic area, coverage; area, organization, event type, specific event number, range of event numbers. Includes videos, snapshots, message & email history, and files associated with the event & related linked/parent events

c Event List – a crosstab report showing event counts by event type, time of day, and day of week – selectable by variables such as: date/ time range, geographic area, coverage area, organization, event type;

d Resource Usage – a summary report showing all resource history/ utilization for an organization – selectable by variables such as: date/ time range, geographic area, coverage area, organization, event type;

e End-of-shift – a summary report showing all events worked, or in progress, for a specific timeframe – selectable by variables such as: date/time range, geographic area, coverage area, organization, event type;

f Operator Activity – a summary report showing events on which particular EMS operators worked – selectable by variables such as: date/time range, user id;

g Resource Activity – a summary report showing events to which particular resources were sent – selectable by variables such as: date/time range, resource id;

h Users – a summary report of registered users in the EMS system;




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.6.1 Standard and Customized Reports (cont'd)

i Code List – a summary report of codes – selectable by variables such as: code type;

j Alarm Report – a summary report showing history of alarms – selectable by variables such as: date/time range, alarm id;

k Devices Report – a summary report showing history of devices – selectable by variables such as: date/time range, device id;

l Available Resources – a list of available resources – selectable by variables such as: date/time range, geographic area, coverage area, organization;

m Resource Details/History – a summary report - selectable by variables such as: date/time range, geographic area, coverage area, organization;

n Call Statistics summary report;

o Most Common Event Locations summary report.

4 The EMS shall be capable of both running reports on demand or produce automatic reports based or pre-defined parameters.

5 Report access will be based on operator permissions to access the report data.

6 The EMS shall have the ability to maintain distribution lists for standard reports.

7 The EMS shall have the ability to generate and send reports as part of an event Response Plan.

8 The EMS shall have the ability to define report parameters by date/time range.

9 The EMS shall have the ability to preview output before export.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.6.2 Search Capabilities

1 The EMS will support ad hoc query and reporting capability with the ability to build & save queries and reports for future use.

2 The EMS shall provide search capabilities on all event, alarm, and resource records.

3 The EMS shall provide event record search capability based on event number, type, description, time/date, and severity.

4 The EMS shall display event records search results in a tabular structure that supports sorting within results.

5 The EMS shall allow drill down into selected search results.

6 The EMS shall allow attaching of an event record to an active event.

7 The EMS shall allow exporting the events search results into various file formats.

Section 6.6.3 Executive Dashboard Requirements

1 The EMS shall provide supervisors with a dashboard that indicates the overall status and health of the airport.

2 The dashboard shall include performance data related to alarm handling and follow alarm response time as well as the number of active alarms.

3 The dashboard shall include performance data related to event handling and follow average event response time as well as active event resolution time.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.6.3 Executive Dashboard Requirements (cont’d)

4 The dashboard shall include counts and graphs displaying number of alarms and events; as well as have the capability display by severity and by type distribution graphs.

5 The dashboard shall include a map for laying out the information geographically. An administrator shall be able to set the map and its extent.

6 The EMS shall allow administrators and/or supervisors to customize the dashboard data configuration and layout to include thresholds related to overall health and status, among others, of the Airport.


Section 6.7 Event Management System Interface Requirements Phase 1

1

The EMS is expected to complement existing systems by providing common features of the existing systems and aiding in the execution of advanced features in their native interfaces. Administrators need the ability to choose which features execute in the EMS and which one execute in the native interfaces.

Section 6.7.1 Video Surveillance System (VSS)

1 The EMS shall support multiple manual camera control mechanisms, including but not limited:

a Controlling the camera from a map showing camera icon




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.1 Video Surveillance System (VSS) (cont’d)

b Controlling the camera by means of a mouse

c Controlling the camera by means of a physical joystick

2

The EMS workstation display area shall be configurable. Operator shall be able to set the number of views displayed at one time as well as the size and arrangement of the views in the total display area. The EMS shall support saving layouts for future use on a per user basis.

3 The EMS shall be able to display multiple videos feeds at a time in the display area.

4 The EMS shall be able to show camera icons shown on map.

5 The EMS shall be able to show the camera fields of view overlaid on a map.

6 The EMS shall be able to display video of closest camera associated with a specified (point and click) location on a map.

7 The EMS shall allow operator to select an area on a map and direct the system to show all cameras with field of view to that area.

8 The EMS shall allow operator to view video at a specific location on a map by selecting the camera at that location on the map and opening in its native software.

9 The EMS shall provide the ability to view live and recorded video based on authorization and privileges for pre-defined users.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.1 Video Surveillance System (VSS) (cont’d)

10 The EMS shall support rules-based automatic camera(s) selection and Pan-tilt-zoom (PTZ) settings upon preset conditions.

11 The EMS shall enable the operator to run video playback instantaneously while viewing real-time video of the same camera on a split screen.

12 The EMS shall have the ability to select a video frame/snapshot from any camera and export to a standard graphic file format.

13 The EMS shall have the ability to extract recorded video from any camera and export to a standard video file format.

14 The EMS shall support playback functions such as: fast forward, rewind, frame by frame, slow motion.

15 The EMS shall be able to display live, archived, and time stamped video.

Section 6.7.2.1 Map Editing and Content Requirements

Note: The City will supply all necessary maps, photos, shapefiles, etc. The Consultant will work with Technology to establish the necessary objects needed.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


1

The EMS shall support maps of the airport that show the airfield, terminals, runways, parking lots, and other infrastructure on the site. The EMS shall also superimpose icons representing cameras, devices, alarms, and events on the map to provide operator with a complete and up-to-the-minute situational awareness picture of the site.

2 The EMS software shall provide support for a common mapping interface across all systems and devices.

3 The EMS shall be able to display features based on floor level.

4 Operators shall be provided the capability to define and display a geographical area and the devices and events located within the geographical area.

5 The EMS shall allow defining coverage areas associated with cameras and resources.

6 System Administrators shall be able to specify the type of icons that are displayed for multiple objects




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.2.1 Map Editing and Content Requirements (cont’d)

a Device types

b Resource types

c Event types in the system

7 The EMS shall support a minimum of 200 different icon types

8 Configurable visual attributes (color, blinking) of each icon shall indicate its current status.

9 The EMS shall provide decluttering tool for layers.

Section 6.7.2.2 Geo-Location Requirements

1

System shall be able to support a location database of textual descriptions of locations. Textual description of locations are common names to describe locations on a map such as the airport terminals, parking lots, entrances, exits, runways, and concessions. The textual description is a customer-designed name that depicts a location-based upon their naming schema. Textual descriptions must be tied to geographic coordinates. The EMS system shall be able to function using this descriptive text location. The EMS shall then support associating cameras, resources, etc. within the same geographic location.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.2.2 Geo-Location Requirements

2 The EMS shall support the ability to automatically geo-reference and align a floor plan to real world latitude, longitude, altitude co-ordinates to accommodate floor plans with varying orientations and scales.

3 Operator shall have the ability to enter and edit location information including descriptive text.

4

Operators shall be able to manually place resources on a map background by ‘drag and drop’ action. Upon this action, geographical coordinates for the selected location shall be automatically stored with the resource record in the EMS database.

5 The EMS shall allow editing a resource’s location by locating it on the map.

6 Operators shall have the capability to display the location of GPS-equipped mobile devices such as cell phones, vehicle-mounted cameras, and other mobile devices.

7 The EMS shall update the maps of all logged-in operators whenever new location data that is received from GPS tracked devices.

8 The EMS shall support spatial analysis tools including, but not limited to: distance calculator, area calculator, buffering tool, etc.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.2.3 Map Display Requirements

1

The EMS shall provide a layering mechanism to enable the operator to determine the content of the information that appears on the map. The purpose of this mechanism is to allow the operator to group ‘like objects’ together for display purposes and to determine which of these groups shall appear on the map at any given time.

2 The EMS shall support at a minimum two types of layers:

a Base Map layer, which shall consist of layers from the GIS to be configured by an Administrator.

b

Dynamic layers, which shall consist of objects added manually by the operator or automatically by the EMS when they satisfy the pre-defined rules and conditions associated with the layer. The contents of the map will change dynamically as new objects (e.g., events, responders, unified command) are created that satisfy the conditions.

3 The EMS shall provide certain default layers to assist operator in managing on-screen objects. Default layers shall include at a minimum:

a A layer that automatically captures all objects created and located by the operator currently using the client workstation




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


b

A layer that automatically captures all events currently displayed in the active events list. If the active events list is currently employing a filter to restrict the number or event types shown, this layer will synchronize with the events list and show only those events

c A layer that automatically captures all events assigned to the operator currently using the client workstation

d A layer that captures all resources/responders in a geographic area

e A layer that automatically depicts a specific event and its associated responders/ resources assigned to the event, when the event is selected by the operator

f A customized layer created by an operator that can be saved and recalled when desired.

4 The EMS shall allow ordering the layers in a logical structure.

5 The EMS shall allow adding monitored device layers and place device icons on them.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.2.3 Map Display Requirements (cont'd)

6 The EMS shall allow removing a device from a specific layer.

7 The EMS shall be able to display one or multiple layers at a time.

8 The EMS shall allow adding layers from external sources.

9 The EMS shall enable operator to show\hide device layers.

Section 6.7.2.4 Map Display and Operational Requirements

1 The EMS shall support all standard map operational and navigational capabilities, including at a minimum:

a Adjust map brightness/contrast

b Move map left/right and up/down

c Zoom in/out on map. Levels of detail should increase/decrease as operator zooms in and out

d Rotate map clockwise/counterclockwise

e Establish and return to home position

f Expand to full screen/return to normal size

g Show/hide map grid

h Jump to previous/next map view

i Plot and display distances on the map

j Save current map view in a file

k Select objects on the map

l Easily distinguish between objects and events close to each other on the map.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.2.4 Map Display and Operational Requirements (cont'd)

2 The EMS shall display icons representing each surveillance camera on the map.

3 The EMS shall display an icon at the location of each alarm on the map. The display shall be color-coded to indicate alarm status.

4 The EMS shall display icons representing each device on the map. The display shall be color-coded to indicate device status.

5 The EMS shall display icons representing events on the map. The system shall create event icons whenever a new event is created in the EMS.

6 The EMS shall allow interacting with a device (play video for cameras, close relays) from the map.

7 The EMS shall have the ability to display all icons (vehicles, people, and devices) inside a defined coverage zone.

8 The EMS shall have the ability to draw arbitrary shapes and zones on a map.

9 The EMS shall display device coverage area on the map.

10 The EMS shall allow showing\hiding the coverage area for a single or all devices.

11 The EMS shall allow adding point of interest markers that can also include links to other maps and will be used as on-map hyperlinks.

12 The operator shall be able to control amount of information displayed on a map at any given time.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC



13 The EMS shall cluster devices whose icons overlap so that the map is not cluttered when zooming out.

14 The EMS shall allow operators to request to see live video from cameras whose coverage area is covering a point on the map selected by the operator.

15 The EMS shall support playing live video for cameras or for devices that has related camera.

16

The EMS shall support geo-association, i.e., clicking on an area of interest on the map and as a result, automatically showing all the devices which have coverage of the location, it also includes playing live video from the relevant camera.

17 The EMS shall automatically identify and present the nearest assets (responders, cameras, devices) related to an event based on its location.

18 The EMS shall have the ability to track movements of objects with location-based technologies on a map.

19 When an event is created, the map display shall be able to automatically center on event location.

20 The EMS shall have the ability to search for devices on a map based on type/name.

21 The EMS shall have the ability to capture and send/save snapshots of maps.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC



22 The EMS shall have the ability to search map based on location (e.g., address, marker, concourse #, etc.).

Section 6.7.3 Emergency Notification System (ENS)

1 The EMS shall be able to initiate notifications to pre-defined personnel through the Emergency Notification System (ENS).

2 The EMS shall be able to define conditions, triggers, and event types that require notifications to be sent and who the addressees would be.

3 The EMS shall be able to automatically populate a message based on event type and pre-defined conditions.

4 The EMS shall determine recipients based on event type and location information of the event or within a geographic footprint.

5 The operator shall have the ability to view notifications associated with an event.

6 The EMS shall provide a message status/history function. It must have the ability to view/search:

a when message was created

b who the sender was

c when message was sent and acknowledged

d who the addressees were.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.7.4 Digital Voice Recorder (DVR)

1 The EMS operator shall be able to search voice recordings by time and source (radio, phone).

2 The EMS operator shall be able to create a file of the desired voice recording, for the source, date/time and duration specified, and attach recorded voice files to an event record.

3 Searchable database shall be restricted to specific pre-defined user roles.



Section 6.8.1 Enterprise Buildings Integrator (EBI)

The EBI system includes: Access Control and Alarm Monitoring System (ACAMS), Fire Enterprise Business Integrator (FEBI), and the Digital Monitoring System (DMS). The requirements in this section apply to all alarm systems integrated with the EMS (limited only by device capabilities). The EMS shall allow specific alarm management functions based on user roles defined by the administrator.

1 The operator shall have the ability to monitor and control alarm systems from the EMS.

2 The EMS shall display alarms in a tabular list.

3 The EMS shall present the operator with a logical tree that contains devices of different types.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.1 Enterprise Buildings Integrator (EBI) (cont'd)

4 The EMS shall have the ability to filter and limit alarms that are displayed on the screen (e.g., just ACAMS, just FEBI, just DMS).

5 The EMS shall allow searching the device tree by device name or device type.

6 The EMS shall indicate the device type by an icon.

7 The EMS shall display a pop-up for a device with its details when clicked.

8 The EMS shall support single-click easy access from device to its GIS map location. When the link is clicked, the GIS map view shall change to display the appropriate view with the highlighted relevant device.

9 Alarms shall be automatically displayed on a map.

10 The EMS shall display on a map all cameras and devices associated with the alarm.

11 The EMS shall visually and audibly alert operators upon receiving new alarms.

12 The EMS shall display the alarm record details upon alarm selection. Details should include source device and its related devices, alarm data, alarm attached images.

13 The EMS shall allow viewing recorded video from the time of the alarm. System should deduce the relevant camera based on the alarmed device and its related cameras.

14 The operator shall be able to easily view a camera associated with device.

15 The EMS alarm summary view shall enable users to pause/continue the real-time scrolling of alarms.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC



16 The EMS shall provide easy links directly from the alarms list to video cameras related to the device.

17 The EMS shall have the ability to display groups of devices based on user-defined criteria (e.g., status, type).

18 The operator shall be able to detect the current status of a device (locked, normal, unlocked, power failure, communications failure, etc.) based on the icon displayed.

19 The operator shall have the ability to operate/control devices from an EMS workstation (open, lock, unlock, etc.).

20 The operator shall have the ability to access the control functions of an alarm by clicking on the device icon on a list or map.

21 The EMS shall have the ability to define triggers, alarm correlations, and conditions to automatically create an event in the EMS. Not all alarms are events in the EMS.

22 The EMS shall update the alarm record on all operators’ workstations when an operator acknowledges or clears an alarm.

23 The EMS shall log and display the time and the user name of the operator that acknowledged or cleared the alarm.

24 Operator shall be able to create an event from an alarm and pertinent data automatically populated in the event record.

25 Operator shall have ability to manually create an event based on an alarm and EMS would automatically populate event record with associated device information.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC



26 The EMS shall be able to automatically send notification to maintenance techs based on pre-defined conditions and alarms.

27 The EMS shall be able to filter and correlate alarms so as not to flood system with alarms.

28 The EMS shall be able to correlate multiple alarms into a single alarm event.

29 All alarms shall be acknowledged by the operator.

30 The EMS alarm functionality shall support querying the history of alarm records of individual devices. It shall be possible to display the history or generate a report.

Section 6.8.1.1 Access Control and Alarm Monitoring System (ACAMS)

1 The EMS shall be able to support multiple windows, which may include:

a Access Summary Screen

b Alarm Summary Screen

c Badge Holder Screen

d Video Display Screen

2

The Access Summary Screen displays every access attempt around the Airport. The screen will continuously scroll as each access attempt is recorded. The data that is displayed shall be configurable and may include but not limited to:

a Date/time

b Device id

c Point descriptor




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.1.1 Access Control and Alarm Monitoring System (ACAMS) (cont'd)

d Condition (granted, change, comms.)

e Badge number

f Access result (granted, denied)

g Card holder name

3 The Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed shall be configurable and may include but not limited to:

a Date/time

b Location

c Point descriptor

d Alarm type (Forced, too long, inactive, etc.)

e Cardholder badge number

f Cardholder name

4 Badge Holder Screen shall automatically display when alarm occurs and access is denied. The data that is displayed will be configurable and may include:

a Cardholders name

b Cardholder date of birth

c Picture of cardholder

d Company and job title of cardholder

e Cardholder status (e.g. active, inactive)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.1.1 Access Control and Alarm Monitoring System (ACAMS) (cont'd)

5 The Video Display Screen shall automatically display live video of camera(s) associated with any ACAMS alarm. Operator shall be able to view video live or prerecorded from any camera selected.

6 The EMS shall be capable of creating an event automatically if pre-defined conditions are met.

7 The EMS shall support an automatic association between access events and badge holders who triggered them.

8 Research of alarms shall be supported. Alarm details shall be searchable based on location, date/time, source, description, alarm condition, access reason, and cardholder name or badge number.

9 The EMS shall ensure video associated with forced and too long alarms is recorded and stored in the alarm record.

10 The EMS shall have ability to generate user-defined Access Control reports.

Section 6.8.1.2 Fire Enterprise Business Integrator (FEBI)

1 The EMS shall be able to support multiple windows, which may include:

a Alarm Summary Screen

b Video Display Screen

2 The Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed will be configurable and may include but not limited to:

a Date/time

b Location

c Point descriptor

d Alarm type (active fire, supervisory, verify, trouble, etc.)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.1.2 Fire Enterprise Business Integrator (FEBI) (cont'd)

3 Where possible the Video Display Screen shall automatically display live video of camera(s) associated with any FEBI alarm. Operator shall be able to view video live or prerecorded from any camera selected.

4 Research of alarms shall be supported. Alarm details shall be searchable based on location, date/time, source, description, alarm condition.

5 The EMS shall ensure video associated with FEBI alarms is recorded and stored in the alarm record.

6 The EMS shall have ability to generate user-defined FEBI reports.

Section 6.8.1.3 Digital Monitoring System (DMS)

Digital Monitoring System (DMS) alarms include Automated External Defibrillators (AEDs), Covert Alarms (TSA checkpoints, Info Counters, Admin Offices, Parking Exit Booths), Elevator override keys, escalators, moving walkways, pump house, and Check Point roll up gates.

1 The EMS shall be able to support multiple windows, which may include but not limited:

a Alarm Summary Screen

b Video Display Screen

2 Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed will be configurable and may include but not limited to:

a Date/time

b Location




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.1.3 Digital Monitoring System (DMS) (cont’d)

c Point descriptor

d Alarm type (AED, Covert, etc.)

3 Where possible the Video Display Screen shall automatically display live video of camera associated with any DMS alarm. Operator shall be able to view video live or prerecorded from any camera selected.

4 From the Alarm Summary screen the operator shall be able to control DMS devices.

5 Research of alarms shall be supported. Alarm details shall be searchable based on location, date/time, source, description, alarm condition.

6 The EMS must ensure video associated with DMS alarms is recorded and stored in the alarm record.

7 The EMS must have ability to generate user-defined DMS reports.

Section 6.8.2 Mobile Devices

1 The EMS shall provide a mobile device application to support event management operations outside the Command Center.

2 Mobile Devices to include but not limited to the following:

a Smart phones

b Tablets




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.2 Mobile Devices (cont’d)

3 Responders with mobile devices shall have the following capabilities:

a Status updates to include but not limited to:

i Acknowledge

ii En route

iii Arrive

iv Clear

v Available

vi Out of service

vii Emergency

b Able to create, edit, add comments/update an event

c Able to query events in the EMS database

d Able to support messaging between devices & groups (user-definable), and announcement capability to the entire mobile active resources on duty

e Ability to save, search, and delete messages with attachments (video, photos) from the device

f Able to acknowledge a notification it receives from the EMS

g See on the mobile device all resources assigned to an event

h Ability to assign additional responder(s) to an event




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.8.2 Mobile Devices (cont’d)

4 Mobiles shall support a mapping application to:

a Utilize base maps from published ESRI GIS

b Ability to show a real-time map display

c Show relative bearing from resource location to event location, dependent upon GPS

d Utilize all standard mapping functions

e Display event id or resource ID on a map

5 The EMS shall be able to record the International Mobile Equipment Identity (IMEI) phone ID and user ID of mobile user logging on to system.

6 The EMS shall use GPS location of mobile responders to recommend the closest resource to the event based upon user-defined event types & distance parameters.

7 EMS shall provide for an audit trail of all communications sent and received between mobiles and EMS with time stamp, user ID, and location.


Section 6.9.1 Operations Security Portal (OSP)

1 The EMS operator shall have access to cardholder data from the EMS screen.

2 The following data must be accessible:




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.9.1 Operations Security Portal (OSP) (cont’d)

a Cardholders name

b Cardholder date of birth

c Picture of cardholder

d Company and job title of cardholder

e Cardholder status (active, inactive, etc.)

3 The operator shall be able to query all badge holders in the system, their access privileges, photos, and badge information.

4 The EMS shall automatically display badge holder information when access control alarms are triggered by badge holder.

5 The operator shall be able to query badge holder history given badge number date and time parameters.

6 The EMS shall be able to attach OSP data to the event log.

Section 6.9.2 XPort

1 The EMS operator shall be able to create a work order from the EMS screen and upload to XPort.

2 The EMS shall be able to auto populate the work order from appropriate data in the event record.

3 Operator shall be able to query XPort and view all work orders and their status associated with a specific event.

4 The EMS shall alert operator when all work orders associated with an event have been completed.

5 Operator shall have ability to launch XPort application from the EMS.

Section 6.9.3 Phone System (Vesta)

1 The EMS shall support the current Vesta telephone operation from the workstation.

2 Inbound calls will typically be answered on the Vesta interface.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.9.3 Phone System (Vesta) (cont’d)

3 Outbound calling can be initiated from the Vesta or the EMS interface.

a The EMS shall support direct entry of digits for dialing and pass those to the Vesta (e.g.,: “602-555-1212”)

b The EMS shall support sending pre-loaded phone numbers and/or speed dials (e.g., “Fire Dispatch”) from the EMS as part of a preconfigured Response Plan task.

c The EMS shall support call back of the phone # attached to the event.

4 The EMS shall automatically populate an event record with the phone number of the current line the operator is using when available and the start time of the call.

a If the call was inbound the information retrieved from the Vesta system will include caller id, dialed number, and dialing number.

b If the call is outbound the information retrieved from the Vesta will include the dialed number, extension, and start time.

5

The EMS shall be able to cause the Vesta system to initiate a conference call using digits directly entered into the EMS or speed dials or preloaded data in a Response Plan task to add someone to the current call in progress. Conference calls joining two or more lines on the Vesta will be performed on the Vesta and not the EMS.

6 The EMS operator shall be able to use phone intercom with other operators in the Command Center.

7 The EMS shall have the capability to put a call into a parking space in the Vesta.

a The EMS shall remember the parking space location and allow any operator to retrieve that call when that event is active on their desk.

b The event shall have an indication of a parked call as long as the call is parked.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


WC RD IN NC


Section 6.9.3 Phone System (Vesta) (cont’d)

c The Vesta will be configured to auto ring back a call that has exceeded a preset timer threshold.

8 The operator shall have access to phonebook/directory in phone system.

9 Operator shall be able to drag and drop caller id and phone number into event log.

ATTACHMENT C: SYSTEMS SPECIFICATION



Phoenix, AZ 85003 Phone: (602) 262-7181

__________________________________________________________________________________


of 221

Phoenix Sky Harbor International Airport

Event Management System

System Specification Document




Phoenix, AZ 85003 Phone: (602) 262-7181

__________________________________________________________________________________


of 221

Document Approval and Revision History

Date Author Version Change Reference Approved by Date




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1. PURPOSE The document provides the technical and functional requirements that the Event Management System (EMS) is expected

to have. It forms the basis for the Compliance Matrix (see Attachment C) that must be filled out by the Proposer.

2. INTRODUCTION In order to help ensure a smooth implementation of the new EMS, the system will be implemented in phases. The initial

phase will provide the core event management functionality with some systems integrated. Each subsequent phase will

either integrate additional systems and devices adding functionality in a controlled manner or introduce a new platform to

access the system. Figure 1 depicts the systems to be integrated with the EMS. The different colors represent the phase

of implementation in which the integration will take place. However, if there are existing integrations that can easily be

implemented without affecting the desired end date, the City would be interested in discussing how those integrations can

be implemented earlier without impacting the desired end date for the phase 1 activities.

Figure 1 - Systems and Platform Integration by Phase




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

3. EVENT MANAGEMENT SYSTEM (EMS) ARCHITECTURE

The Event Management System (EMS) will be installed on at least three environments:

1. Production

2. Test/Training

3. Unit Test

There will be no additional VMware or server operating system licenses necessary if Windows is used as the operating system. Licensing shall be included without additional cost if another operating system is used, by the Contractor, for test servers, workstations and the database unless it will reside on the Oracle Exadata system.

The EMS shall be based on a server-based platform housed in the Airport’s data center as described below. It may be client/server based or web server/web browser based (preferred).

The EMS shall be scalable and allow for the addition of users, devices, sensors, and integrated systems.

3.1. Back End Infrastructure

The back end infrastructure at the Airport is architected as a consolidated infrastructure within an offsite primary and

secondary data center using blade servers, SAN storage, and VMware software. The secondary data center is a

warm site, and is only activated in the event of a disaster.

VMware High Availability (HA) is utilized to provide high availability within the primary data center, to protect against

host server hardware failures. VMware Site Recovery Manager (SRM) is utilized to provide site failover to the

secondary data center in the event of a disaster that removes the primary data center from service. It should be noted

that VMware HA and SRM do not provide for seamless failover. HA events are typically restored within minutes and

occur automatically to restart the affected guest virtual machines on another host. SRM is manually initiated by

systems staff and a full restore of a given system could take hours to complete depending on the priority sequence in

which systems are brought back online.

Scaling of system resources within the guest operating system is accomplished through “hot add” within VMware

vCenter to increase processor and memory allocations as needed to meet performance requirements that may

increase due to scaling of the environment post implementation.

The back end infrastructure has no existing standard for application/database redundancy or load balancing. VMware

fault tolerance is not utilized in the environment due to its inherent limitations. The City would like an EMS design that

allows for redundant application and database servers to reside on separate hosts within the VMware cluster to

protect against interruptions in service that may result from HA events and/or routine maintenance of systems such as

applying security patches. Proposals for providing application/database redundancy or load balancing for the

purposes of the EMS must include clear understanding of the benefits as well as limitations of the proposed solution.

The City has standardized on system backup software at the Airport that relies on VMware snapshot and windows

volume shadow copy services to capture the backups. The EMS must be compatible with these services, and not be

operationally impacted by them.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

3.2. Servers

The EMS servers must be capable of running in the Airport’s existing back end infrastructure as virtual machines.

Virtualization using VMware is the standard method for deploying servers, and Windows Server 2012 R2 is

predominantly used as the guest operating system. System resource requirements for the virtual machines shall be

provided to the City by the Consultant, in accordance with the Submittal Requirements, as detailed in Scope of

Services and should reflect what is required in a virtual environment.

Database and application servers will run on separate virtual machines. The City has standardized on the use of SQL

Server and Oracle for database back end. If Oracle is selected, the database will reside within the Oracle Exadata

system.

3.3. System Administration Requirements

1. The EMS shall support virtualization technologies to run on VMware VSphere platforms.

2. The EMS administrators shall be able to control and configure permissions, actions, views, and device

restrictions by user-ids, or user groups within the EMS.

3. The EMS shall support user groups and user role definitions. User ids will be associated to roles and be given

associated privileges/permissions.

4. The EMS shall be able to log and track all logins access and unauthorized access attempts.

5. The EMS shall be able to configure and save workstation preferred layouts by user-id or user group so that it

comes up automatically when user logs into the application.

6. The EMS shall maintain an audit log of all data creation, update, and deletion tied to user-id.

7. The EMS shall include an Application Programming Interface (API).

8. The EMS shall include an Software Development Kit (SDK) that allows third parties to integrate with the EMS.

9. The EMS shall support a monitoring tool indicating the status of all EMS components and status of externally

connected systems.

3.4. Systems Integration

1. The EMS shall be based on an open architecture. This means that any function can be accessed either

through the existing user interface or has an API that can access the function programmatically. Data

architecture shall be published as a generally available function so that programs may access the underlying

data for reporting or information integration to other systems.

2. The Oracle Service Oriented Architecture (SOA) suite of middleware is the preferred method to accomplish all

system integrations with the EMS. If the contractor has an existing interface or adaptor to one the systems in

Table 2 Systems to be integrated with EMS already developed it can be used to accomplish a systems

integration. Any new developed integration, not already established, shall be accomplished using Oracle

SOA. The City will provide the Oracle SOA infrastructure. In accordance with the submittal requirements, the

Contractor will specify the exact Oracle SOA modules and quantities of licenses needed to support the EMS

and system interfaces. Today, as shown in Table 1, the City has the following licenses at the Airport:




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Product Description/License Type Quantity

WebLogic Suite – Processor Perpetual 6

Web Logic Suite – Named User Plus Perpetual 60

Unified Business Process Management Suite – Processor Perpetual 6

Unified Business Process Management Suite – Named User Plus Perpetual 60

WebLogic Server Management Pack Enterprise Edition – Processor Perpetual 6

WebLogic Server Management Pack Enterprise Edition – Named User Plus

Perpetual

60

SOA Suite for Oracle Middleware – Processor Perpetual 6

SOA Suite for Oracle Middleware – Named User Plus Perpetual 60

SOA Management Pack Enterprise Edition – Processor Perpetual 6

SOA Management Pack Enterprise Edition – Named User Plus Perpetual 60

Table 1 Current Oracle Licenses

Details of the systems to be integrated are contained in Table 2.

System Name Network Publisher Version # Desired minimum phase

implementation

Computer Aided Dispatch (CAD)

Response Workstation/ Police Status Monitor

PDS Public Safety Systems Inc.

2.66.9/7.50.1 N/A


Xprotect Smart Client

PDS Milestone 2014 1


ArcGIS PDS ESRI Inc. 10.3.1. 1


NICE Inform Client PDS NICE 6.1.0.158 1


Everbridge Mass Notification

Enterprise Everbridge N/A 1


EBI PDS Honeywell R410.2 2

Fire Enterprise Business Integrator (FEBI)

EBI Fire LAN Honeywell R410 2


EBI PDS Honeywell R410.2 2

Mobile N/A 2

Operations Security Portal

Safe Enterprise Quantum Secure, Inc.

4.x 3




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Name Network Publisher Version # Desired minimum phase

implementation

(OSP)

SAP Plant Maintenance

XPort Enterprise

In-house developed mobilization of SAP PM

N/A 3

Phone System VESTA

Plant Equipment (Now: Airbus DS)

2.2 3

Table 2 Systems to be integrated with EMS

3.5. Network Infrastructure

The City’s network infrastructure at the Airport is divided into two main local area networks (LAN) – Enterprise and

PDS. These two networks are connected together through firewalls between dedicated physical connections on city-

owned fiber – these connections do not transverse the Internet. Interconnectivity can be established between systems

on either LAN as needed by City network engineers.

The Enterprise LAN serves City and contract staff with office collaboration tools and services such as email, SAP, file

shares, printing, etc. Some of the systems used by the Command Center (CC) are served from the Enterprise LAN

such as XPort (mobilized work order management system), GIS, and ENS.

The PDS LAN is dedicated to serving the Airport’s business systems such as EMS, VSS, ACAMS, etc. The PDS LAN

infrastructure is architected using a Layer 3, full MPLS design with Fusion Routing and CISCO ASA service modules

with virtual firewall contexts for each VRF (Virtual Routing and Forwarding). The network is a mesh design with

redundant core switches, as well as dedicated redundant distribution switches for each of the eight geographic

distributions, which includes the two (2) data centers. The core and distribution switches are redundantly

interconnected at 10 GBPS (gigabytes per second). All access layer switches are redundantly connected to their

respective distribution switches at 1 GBPS.

Workstations in the CC will be configured with VMware workstation software allowing dedicated instances of Windows

to be run concurrently. The workstations will have dedicated network interface cards physically connected to each

LAN at 1 GBPS. The CC will have redundant access switches installed for each LAN. For added redundancy, every

other workstation will be connected to a different access switch to prevent an access switch failure from causing a

complete outage in the facility.

Figure 2 logically represents the connectivity for the network connections associated with implementing the EMS.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Figure 2 - EMS Architecture Concept

3.6. Database

The Consultant may use either SQL or Oracle Database software.

3.7. Mobile Devices

City staff use smart phones (both android and iPhone) and Tablets today. In the future, some Mobile Terminal

Devices may be implemented in the Operations Field Vehicles. It is anticipated that the EMS will need to support at

least 100 mobile devices when Phase 2 is implemented.

3.8. Printers

Printers for the EMS will be networked printers at distributed locations in the CC. The EMS must be capable of

printing in color on paper sizes up to 11”x17”.

Emergency Notification System

Event Management System

WEB EOC

Resource Management

SystemEMAIL

Xport

Enterprise Business Integrator

Video Surveillance System

Geo-Spatial Information System

Digital Voice Recorder

PDS LAN ENTERPRISE LANFW FW

PDS LAN ACCESS SWITCH

PDS LAN ACCESS SWITCH

ENTERPRISE LAN ACCESS

SWITCH

ENTERPRISE LAN ACCESS

SWITCH

Command Center/AEOC Workstations

Representative Applications Accessible from the Two LANS




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

4. USERS AND DEVICES

The EMS will be key to maintaining smooth operations at the Airport. It will be a key source for communicating accurate,

current, and consistent information to all staff with a need to know. Therefore, the EMS will be accessible to staff in the

CC on workstations, other airport campus facilities, and remotely via VPN.

User Descriptions:

1. Users: Users having access to the EMS on a regular basis whose primary responsibility is managing events. They

may be from multiple divisions and on multiple shifts. This includes laptops with remote access, but not using a

mobile EMS application.

2. Concurrent Users: Total number of users or workstations that will normally use the system simultaneously.

3. Mobile Users: Number of users accessing the EMS mobile application from mobile devices such as smart

phones, laptops, and MDTs.

4. Concurrent Mobile Users: Total number of mobile devices that will normally access the EMS mobile application

simultaneously.

The estimated number of devices the EMS will need to monitor and support are indicated by Phases in Table 3.

Estimated Number of Devices by Phase One Way Two Way

Phase 1

# of Cameras 1311

Phase 2

Fire (FEBI) 8547

Access Control (ACAMS) 796

Digital Monitoring System (DMS) 402

Mobile Devices 100

TOTALS 8949 2207

Table 3 Estimated EMS Devices/Sensors Supported

5. SECURITY REQUIREMENTS

1. The EMS system shall use Microsoft Active Directory integration for authentication. EMS roles will be managed within

the application to assign permissions.

2. Every authorized user of the EMS system shall have a user profile that accomplishes the following:

a. Active Directory single sign on should be an option.

b. Assigns the user to application roles and user groups that determine the user’s permissions regarding the

various system features and functions.

c. Ability to assign access to functions, screens and/or databased upon user role.

3. Every authorized user of the EMS system shall be assigned to a pre-defined selection of roles that will define the

features and functions of the system that this user will be permitted to access.

4. The system must support antivirus program scans without disruption to the EMS system and database. The current

antivirus program installed at the Airport is Symantec Endpoint Protection version 12.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6. FUNCTIONAL REQUIREMENTS

6.1. General Event Management System Functionality

1. The EMS shall have the ability to launch other applications in their native mode from within the EMS.

2. The EMS shall have the ability to manually or automatically create an event with the occurrence of pre-defined

incidents.

3. The EMS shall assign all new events to an EMS operator/group: this operator/group will be the events owner and

will be responsible for acknowledging and resolving the event. All members of this group can input to this event

and close the event.

4. The EMS shall have the ability for members of designated groups to create, dispatch, display, update, and close

an event.

5. The EMS shall have the ability to filter and correlate events based on:

a. Time of occurrence

b. Location

c. Type of event

d. Other parameters that can be defined by the user

6. The EMS shall have the ability to display a current list of all active events, text based list, and graphical display on

a map. Different icons will be displayed based on different types of events and varying event statuses.

7. The EMS shall have the ability to display entire chronological history of an event or resources with audit trail of all

entries with time stamp and user id.

8. The EMS shall provide easy navigation to access maps, cameras, devices, files, and forms associated with an

event.

9. The EMS shall support editable forms to be completed with an event. Completed forms will be stored with the

event log and accessible for viewing.

10. The EMS shall have a common event summary/dashboard page which is configurable by system administrators

and end users. Multiple dashboard layouts will be possible, not just one.

11. The EMS shall facilitate video surveillance, alarm monitoring, incident response, event notifications, and resource

dispatch functionality.

12. The EMS operator shall have the ability to view and manage resources/devices of different types monitored by

the system.

13. The EMS shall have the ability to support multiple windows across multiple monitors at a single position.

14. The EMS shall have the ability to manage resources responding to an event.

15. The EMS shall have the ability to interface to specified systems using the Oracle SOA suite 12c or higher when

applicable.

16. The EMS shall have the ability to receive signals/data/messages from other systems (e.g., alarm condition or

event).

17. The EMS shall have the ability to generate standard and customized reports.

18. The EMS shall have the ability to search event data and export as reports in various file formats (e.g., CSV, PDF).

19. The EMS shall have the ability to customize user interfaces and user functions to match required Response

Plans.

20. The EMS shall have a notepad function to record notes not associated with an event.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

21. The EMS shall include a robust context-based help module to include but not limited to: training files, FAQ’s, best

practices, and other insights. It must include the ability for Administrators to edit or supplement the help modules

content.

6.2. Roles

At minimum, the EMS shall support an Administrative and a User role with the following capabilities:

Administrator Role functionality:

1. System configuration

2. System management

3. Integrated systems management

4. User/Account management

5. Security management (system security)

6. Audit and user tracking

7. System status and trouble-shooting

8. All user role capabilities

User Role functionality:

1. Multiple user roles that can be defined as necessary

2. System screens designed, laid out, and configured to support the functions and user interfaces with all the

integrated systems

3. User configuration mechanisms, allowing a high-level configuration of alert settings or Response Plan settings

based on user-defined requirements and Business Rules

4. Monitoring alarms and creating event logs

5. System status screens, including EMS and integrated systems status

6. On-line access for help and troubleshooting.

6.3. Business Rules/Response Planning Requirements

6.3.1. Response Plan Creation/Editing

Note: Response Plan can also be referred to as a Checklist.

1. The EMS shall include an event Response Planning module. This module will include an interactive,

graphical-based editor to handle the Response Plan creation process.

2. The Response Plan editor shall allow operator to save specific steps so that they can be incorporated into

other Response Plans without the necessity of re-creating them each time.

3. The Response Plan editor shall allow existing Response Plans to be incorporated into new Response Plans,

allowing operator to create complex operations procedures with minimal effort.

4. The Response Plan editor shall support adding manually initiated device command tasks in the response

procedures. Device command tasks should include camera control, control doors, dispatch, sending

message, etc.

5. The Response Plan editor shall have a Form Manager module to create preconfigured forms to collect event

data and to import custom forms from external sources.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6. The EMS shall have the ability to associate a form with event types, tasks, and Response Plans. Forms can

be filled out in real-time to collect and save event details (e.g., bomb threat, hazardous material, alert form,

accident report, etc.).

7. The Response Plan editor shall be able to create drop down lists, check boxes to facilitate easy and accurate

data entry, to include user definable call taker questions linked to event types.

8. Response Plans shall include conditional branches of actions to take based on decision point responses.

9. Response Plan actions shall be independent or dependent on other actions.

10. Each event type shall be associated with a specific Response Plan(s), so that when a specific event type is

triggered, the Response Plan presented to operator is specifically designed to address and resolve the

characteristics of that event type.

11. The EMS shall allow configuring and executing event triggering rules. Multiple triggering rules can be set per

event type.

12. The EMS shall be able to define triggers that cause an automatic action when it occurs (e.g., specific status

reached - then the EMS sends messages).

13. The EMS shall have the ability to modify and adapt Response Plans without taking the EMS off line.

6.3.2. Operational Workflow Requirements

1. The EMS shall be able to automatically create an event when pre-defined criteria has been met.

2. The EMS shall allow users to manually create events.

3. The EMS shall automatically provide Response Plans to operator when an event is created.

4. The EMS shall allow operator to execute the event Response Plan.

5. The EMS shall allow an operator to multitask between events.

6. The EMS shall log all Response Plan tasks executed by the operator.

7. The EMS shall present Response Plan execution overall progress to the operator.

8. Response Plan actions shall carry over to other related events.

9. Response Plans shall change based on new information entered about an event (e.g., 1st responder confirms

injuries, Response Plan changes to include medical procedures).

10. The Response Plan shall support automatic or manual initiation of device and EMS commands when an

event is created.

11. In case of automated function, the EMS shall allow operator to continue working while command is being

executed.

12. The EMS shall support both manual selection and automatic selection (based on event that triggered the

event) of the device to receive a command.

13. The EMS shall manually and automatically set the priority that will be associated with the event.

14. The EMS shall allow operator to supplement the Response Plan procedures in real-time when the current

situation demands such changes. The additions will be recorded in the event log.

15. The EMS shall display an alert notification if Response Plans are not carried out in a configurable time frame

or by the closure of the event. Alert notifications are configurable based on user roles.

16. Multiple operators shall be able to work on events simultaneously. If one operator completes a required

action, it is noted in the log and is complete for all others working the event.

17. Events shall be assigned to a single operator or group for management, and reassigned if required.

18. Tasks within an event Response Plan shall be able to be assigned/distributed to a specific operator or group

of operators.

19. Operators shall be able to perform the following actions regarding tasks:




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

a. Task assignment/acknowledgement

b. Update status

c. Complete task

d. Cancel task

e. Reassign task

f. Mark as in progress

g. Supervisor may reassign task to a different operator

20. Completed tasks shall be shown as completed.

21. All actions performed on tasks shall be time-stamped and recorded in database along with user id or operator

performing the action.

22. The EMS shall have the ability to assign (dispatch) a resource in response to an event.

23. The assigned resource shall come from a resource database of available response resources (Operations,

Police, Fire, etc.). The EMS shall provide the ability to add resources “on the fly” without accessing the

database manager.

24. The EMS shall alert operator every time a new event requiring action is created. Alert remains until

acknowledged by operator.

25. The EMS shall alert operator when tasks timeout or status changes.

26. The EMS shall support a timeout feature for events and resources with user definable interval timers.

27. All notifications sent when a resource or event times out shall be automatically written to event & resource

logs.

6.4. Event Management Requirements

6.4.1 Event Creation/Update/Closing Requirements

1. The EMS shall permit event creation in either of two ways:

a. Manually: By operator with the appropriate permissions

b. Automatically: by the EMS based on pre-defined triggers or conditions.

2. The EMS shall have the ability to create an event by selecting an event type.

3. The creation of an event shall display a Response Plan.

4. The EMS shall have the ability to classify the event using definable event type codes. The EMS must support

an unlimited amount of event types.

5. The EMS shall allow creation of a new event with/without a geographical location.

6. The EMS shall allow setting and changing event location.

7. The EMS shall be able to assign a location of an event by pointing and clicking on a map or selecting from a

list of default locations.

8. The EMS shall automatically assign a unique number to each event created.

9. The EMS shall have the ability to record one or more caller names and locations to an event record.

10. The EMS shall allow the user to manually create an event that does not fall into an existing event type and set

the type, priority, description, time, and response procedure.

11. The EMS shall have the ability to automatically assign a priority-based upon pre-defined event priorities.

12. The EMS shall have the ability to override pre-defined event priorities.

13. The EMS shall capture as much information as possible from integrated systems at time of event creation and

populate the event record (type, time, location, and alarm data).




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

14. The EMS shall have ability to override ANI/ALI (Automatic Number Identification / Automatic Location

Identification) interface (if enabled) and enter/edit caller information manually including caller name, address,

and telephone number.

15. The EMS shall allow editing the event type, priority, and description.

16. The EMS shall allow attaching map & video snapshots and video files to the event.

17. The EMS shall allow adding comments to the event. Each comment shall be logged with the operator id and

time stamp.

18. All data entered will be stored in the event log with an operator id and time stamp. All entries into the event

log or event details can be edited, however an audit log of any changes will be maintained with an associated

date, time stamp, and operator id.

19. The EMS shall allow operator to execute the event Response Plan.

20. The EMS shall log all Response Plan tasks executed by the operator.

21. The EMS shall update the event log on all operator workstations for any activity associated with the event

ensuring a consistent common operational view of the event status.

22. Operators shall be able to accomplish individual tasks on the same event simultaneously.

23. The operator shall have the ability to close an event.

24. The EMS shall allow the operator to add an event resolution and to attach files before closing an event.

25. Any closed event shall be reopened and additional information added to the event.

26. The EMS shall allow an event to be closed even if the Response Plan procedures are incomplete; however

the supervisor will be notified of the incomplete Response Plan.

6.4.2. Active Event Display Requirements

1. The EMS shall display all active events in a unified list and on a map, if applicable.

2. The active events list shall be sortable on pre-defined criteria (e.g., priority, longevity, type, location).

3. The event details displayed in the active events list shall be configurable to include (but not limited to):

a. Date and time event occurred

b. Type of event

c. Location of event

d. Priority of event

e. Response Plan and status

f. Attachments

g. Source alarm/device (if applicable)

4. Active events shall be visually differentiated to quickly distinguish between the different event types and

priorities. This shall be configurable by administrator.

5. The EMS shall include standard mapping capabilities including pan/zoom and feature selections such as

layers, as well as interact with on-map items, etc.

6. The EMS shall allow viewing of live and recorded video from the time of the event. It is preferred that the EMS

should display the relevant camera(s) based on the alarmed device or event location.

7. The EMS shall allow viewing details of alarms associated with an event.

8. The EMS shall allow selection of a camera from a map display and to bring up live and recorded video.

6.4.3. Event Assignment Requirements

The EMS shall provide a method of event/task assignment. Event or task assignment shall not be restricted to an

individual user. Event/Task management shall be conducive to a team environment.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

1. The system shall allow operators/groups to acknowledge events assigned to them.

2. The EMS shall log and display the time and the user name of the operator that accepted the event.

6.5. Resource Management Requirements

6.5.1. Resource Planning Requirements

1. The EMS shall have a resource management module to create and edit a database of resources, such as

personnel (police, fire fighters, etc.) and vehicles (buses, fire trucks, etc.).

2. The resource management module shall be able to define the types of resources (e.g., Fire Fighters, PD,

Ops, Buses, etc.)

3. The resource management module shall be able to define skill sets required to respond to different event

types (e.g., bomb assessment skills required to respond to bomb threats).

4. The resource management module shall be able to define areas of coverage.

5. The resource management module shall be able to define searchable data/attributes associated with

resources. Data can be defined as static or dynamic, such as:

a. Static data (name, type, skills, areas of coverage, contact info, shift schedule)

b. Dynamic data (availability, event assigned to, activity, current status, current location).

6. The resource management module shall be able to bulk upload resource lists into the EMS resource library.

7. The resource management module shall be able to assign resources to hierarchical organizations/groups.

8. The resource management module shall be able to assign a resource to a particular coverage area.

9. The resource management module shall be able to assign a resource as backup to other coverage areas.

10. The resource management module shall be able to create icons for all resources and their attributes (color,

blinking, and status) for map displays.

11. The operator shall be able to put resources onto a response list and take resources off of a response list.

12. The resource management module shall have a scheduling function for resources (e.g., Police, dispatchers,

Ops, etc.)

13. The resource management module shall have the ability to put personnel on shift and take off shift.

14. The resource management module shall be able to establish pre-defined shift schedules (Rosters) for

personnel so shifts are put on duty and made available for assignment automatically by the EMS.

15. Updates to the resource database shall be immediately available in real-time to operators.

16. The EMS shall keep an audit trail and storage of each resources attribute history and user id of operator who

made the changes (skill sets changed, contact info changed).

6.5.2. Resource Dispatching and Tracking Requirements

The EMS shall provide Command Center functionality to dispatch (aka assign) and track field staff and resources.

Under optimal conditions, the EMS shall allow the sorting of active events by resource, wherein a single resource

maybe assigned to multiple events or multiple events might be assigned to a single resource. Mobile device

users shall have the functionality described in Section 6.8.2.

1. The EMS dispatch functionality shall to be a user-friendly, intuitive, and dedicated tool.

2. The EMS shall be able to prominently display a list of appropriate resources available to assign to an event

when an event Response Plan calls for it. The EMS must take into consideration resource skills, assigned

coverage areas, schedule, availability, etc. in determining their appropriateness to respond.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

3. The operator shall be able to manually assign a resource in the event record and have the ability to abort

assignment request.

4. The EMS shall be able to automatically update the event record with resources assigned.

5. The operator shall be able to assign a specific resource to respond to an event.

6. The operator shall be able to take a resource off of a lower priority event and dispatch that resource to

another event.

7. The operator shall be able to manually update the status of a resource.

8. The EMS shall provide automatic notification to the operators of resource shortage (based upon number of

active events versus available resources).

9. The EMS shall keep an audit trail and storage of each resources history including events they responded to,

date/time stamp, event number.

10. The EMS shall automatically update the event record every time a resource sends new report or new status.

11. The operator shall be able to call up more detailed information about the resource and its status.

12. The EMS shall provide the ability to message resources with mobile devices.

6.5.3. Resource Mapping and Display Requirements

1. The EMS shall be able to display current status of assigned resources in a visually differentiated manner.

2. The operator shall be able to tailor the display to show selected coverage zones on a map with icon indicating

current resource status.

3. The EMS shall have a “Find Nearest Resource” function; by clicking on an event location on a map the EMS

will determine and display the nearest resources to that location.

4. By clicking on the resource, the EMS shall display details about that resource (type, skill, availability, contact

info). The operator must then have the ability to assign a resource to respond to the event.

5. The EMS shall provide real-time locations of available and responding resources (if GPS enabled) and update

locations of resources on a map automatically.

6. The operator shall be able to place resources on a map with a drag and drop.

7. The operator shall be able to move an icon/resource on a map from one location to another.

8. The operator shall be able to remove a resource icon from a map.

9. The operator shall be able to declutter the resource map.

6.6. Event Management System (EMS) Query and Report Requirements

6.6.1. Standard and Customized Reports

1. The EMS shall include a reporting function that allows operator to generate, format, and print reports on

various aspects of the system’s operation and performance, including devices, events, resources, etc.

2. The reporting function shall allow operator to select the data in the reports to produce customized reports, to

display the reports on the client workstation, to send the reports to a network printer, and to save the reports

in at least the following formats:

a. XML

b. CSV (comma delimited)

c. PDF

d. HTML

e. Excel




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

f. Word

3. The reporting function shall include at a minimum the following types of reports:

a. Event Summary – a summary report of all events – selectable by variables such as: date/time range,

geographic area, coverage area, event type;

b. Event Detail – a detail report of one or more events with attachments, chronological activity timeline,

and the main event lifecycle information – selectable by variables such as: date/time range, geographic

area, coverage area, organization, event type, specific event number, range of event numbers. Includes

videos, snapshots, message and email history, and files associated with the event and related

linked/parent events;

c. Event List – a crosstab report showing event counts by event type, time of day, and day of week –

selectable by variables such as: date/time range, geographic area, coverage area, organization, event

type;

d. Resource Usage – a summary report showing all resource history/utilization for an organization –


type;

e. End-of-shift – a summary report showing all events worked, or in progress, for a specific timeframe –


type;

f. Operator Activity – a summary report showing events on which particular EMS operators worked –

selectable by variables such as: date/time range, user id;

g. Resource Activity – a summary report showing events to which particular resources were sent –

selectable by variables such as: date/time range, resource id;

h. Users – a summary report of registered users in the EMS system;

i. Code List – a summary report of codes – selectable by variables such as: code type;

j. Alarm Report – a summary report showing history of alarms – selectable by variables such as:

date/time range, alarm id;

k. Devices Report – a summary report showing history of devices – selectable by variables such as:

date/time range, device id;

l. Available Resources – a list of available resources – selectable by variables such as: date/time range,

geographic area, coverage area, organization;

m. Resource Details/History – a summary report - selectable by variables such as: date/time range,

geographic area, coverage area, organization;

n. Call Statistics summary report;

o. Most Common Event Locations summary report.

4. The EMS shall be capable of both running reports on demand or produce automatic reports based or pre-

defined parameters.

5. Report access will be based on operator permissions to access the report data.

6. The EMS shall have the ability to maintain distribution lists for standard reports.

7. The EMS shall have the ability to generate and send reports as part of an event Response Plan.

8. The EMS shall have the ability to define report parameters by date/time range.

9. The EMS shall have the ability to preview output before export.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

6.6.2. Search Capabilities

1. The EMS will support ad hoc query and reporting capability with the ability to build & save queries and reports

for future use.

2. The EMS shall provide search capabilities on all event, alarm, and resource records.

3. The EMS shall provide event record search capability based on event number, type, description, time/date,

and severity.

4. The EMS shall display event records search results in a tabular structure that supports sorting within results.

5. The EMS shall allow drill down into selected search results.

6. The EMS shall allow attaching of an event record to an active event.

7. The EMS shall allow exporting the events search results into various file formats.

6.6.3. Executive Dashboard Requirements

1. The EMS shall provide supervisors with a dashboard that indicates the overall status and health of the airport.

2. The dashboard shall include performance data related to alarm handling and follow alarm response time as

well as the number of active alarms.

3. The dashboard shall include performance data related to event handling and follow average event response

time as well as active event resolution time.

4. The dashboard shall include counts and graphs displaying number of alarms and events; as well as have the

capability display by severity and by type distribution graphs.

5. The dashboard shall include a map for laying out the information geographically. An administrator shall be

able to set the map and its extent.

6. The EMS shall allow administrators and/or supervisors to customize the dashboard data configuration and

layout to include thresholds related to overall health and status, among others, of the Airport.

6.7. Event Management System (EMS) Interface Requirements Phase 1

The EMS is expected to complement existing systems by providing common features of the existing systems

and aiding in the execution of advanced features in their native interfaces. Administrators need the ability to

choose which features execute in the EMS and which one execute in the native interfaces.

6.7.1. Video Surveillance System (VSS)

1. The EMS shall support multiple manual camera control mechanisms, including but not limited:

a. Controlling the camera from a map showing camera icon

b. Controlling the camera by means of a mouse

c. Controlling the camera by means of a physical joystick

2. The EMS workstation display area shall be configurable. Operator shall be able to set the number of views

displayed at one time as well as the size and arrangement of the views in the total display area. The EMS

shall support saving layouts for future use on a per user basis.

3. The EMS shall be able to display multiple videos feeds at a time in the display area.

4. The EMS shall be able to show camera icons shown on map.

5. The EMS shall be able to show the camera fields of view overlaid on a map.

6. The EMS shall be able to display video of closest camera associated with a specified (point and click) location

on a map.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7. The EMS shall allow operator to select an area on a map and direct the system to show all cameras with field

of view to that area.

8. The EMS shall allow operator to view video at a specific location on a map by selecting the camera at that

location on the map and opening in its native software.

9. The EMS shall provide the ability to view live and recorded video based on authorization and privileges for

pre-defined users.

10. The EMS shall support rules-based automatic camera(s) selection and Pan-tilt-zoom (PTZ) settings upon

preset conditions.

11. The EMS shall enable the operator to run video playback instantaneously while viewing real-time video of the

same camera on a split screen.

12. The EMS shall have the ability to select a video frame/snapshot from any camera and export to a standard

graphic file format.

13. The EMS shall have the ability to extract recorded video from any camera and export to a standard video file

format.

14. The EMS shall support playback functions such as: fast forward, rewind, frame by frame, slow motion.

15. The EMS shall be able to display live, archived, and time stamped video.

6.7.2. Geographic Information System (GIS)

6.7.2.1. Map Editing and Content Requirements

Note: The City will supply all necessary maps, photos, shapefiles, etc. The Consultant will work with

Technology to establish the necessary objects needed.

1. The EMS shall support maps of the airport that show the airfield, terminals, runways, parking lots, and

other infrastructure on the site. The EMS shall also superimpose icons representing cameras, devices,

alarms, and events on the map to provide operator with a complete and up-to-the-minute situational

awareness picture of the site.

2. The EMS software shall provide support for a common mapping interface across all systems and devices.

3. The EMS shall be able to display features based on floor level.

4. Operators shall be provided the capability to define and display a geographical area and the devices and

events located within the geographical area.

5. The EMS shall allow defining coverage areas associated with cameras and resources.

6. Administrators shall be able to specify the type of icons that are displayed for multiple device types,

resource types, and event types in the system. The EMS shall support at a minimum 200 different icon

types.

7. Configurable visual attributes (color, blinking) of each icon shall indicate its current status.

8. The EMS shall provide decluttering tool for layers.

6.7.2.2. Geo-Location Requirements

1. System shall be able to support a location database of textual descriptions of locations. Textual description

of locations are common names to describe locations on a map such as the airport terminals, parking lots,

entrances, exits, runways, and concessions. The textual description is a customer-designed name that

depicts a location-based upon their naming schema. Textual descriptions must be tied to geographic




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

coordinates. The EMS system shall be able to function using this descriptive text location. The EMS shall

then support associating cameras, resources, etc. within the same geographic location.

2. The EMS shall support the ability to automatically geo-reference and align a floor plan to real world

latitude, longitude, and altitude co-ordinates to accommodate floor plans with varying orientations and

scales.

3. Operator shall have the ability to enter and edit location information including descriptive text.

4. Operators shall be able to manually place resources on a map background by ‘drag and drop’ action. Upon

this action, geographical coordinates for the selected location shall be automatically stored with the

resource record in the EMS database.

5. The EMS shall allow editing a resource’s location by locating it on the map.

6. Operators shall have the capability to display the location of GPS-equipped mobile devices such as cell

phones, vehicle-mounted cameras, and other mobile devices.

7. The EMS shall update the maps of all logged-in operators whenever new location data that is received

from GPS tracked devices.

8. The EMS shall support spatial analysis tools including, but not limited to: distance calculator, area

calculator, buffering tool, etc.

6.7.2.3. Map Display Requirements

1. The EMS shall provide a layering mechanism to enable the operator to determine the content of the

information that appears on the map. The purpose of this mechanism is to allow the operator to group ‘like

objects’ together for display purposes and to determine which of these groups shall appear on the map at

any given time.

2. The EMS shall support at a minimum two types of layers:

a. Base Map layer, which shall consist of layers from the GIS to be configured by an Administrator.

b. Dynamic layers, which shall consist of objects added manually by the operator or automatically by the

EMS when they satisfy the pre-defined rules and conditions associated with the layer. The contents of

the map will change dynamically as new objects (e.g., events, responders, unified command) are

created that satisfy the conditions.

3. The EMS shall provide certain default layers to assist operator in managing on-screen objects. Default

layers shall include at a minimum:

a. A layer that automatically captures all objects created and located by the operator currently using the

client workstation

b. A layer that automatically captures all events currently displayed in the active events list. If the active

events list is currently employing a filter to restrict the number or event types shown, this layer will

synchronize with the events list and show only those events

c. A layer that automatically captures all events assigned to the operator currently using the client

workstation

d. A layer that captures all resources/responders in a geographic area

e. A layer that automatically depicts a specific event and its associated responders/ resources assigned

to the event, when the event is selected by the operator

f. A customized layer created by an operator that can be saved and recalled when desired.

4. The EMS shall allow ordering the layers in a logical structure.

5. The EMS shall allow adding monitored device layers and place device icons on them.

6. The EMS shall allow removing a device from a specific layer.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7. The EMS shall be able to display one or multiple layers at a time.

8. The EMS shall allow adding layers from external sources.

9. The EMS shall enable operator to show\hide device layers.

6.7.2.4. Map Display and Operational Requirements

1. The EMS shall support all standard map operational and navigational capabilities, including at a minimum:

a. Adjust map brightness/contrast

b. Move map left/right and up/down

c. Zoom in/out on map. Levels of detail should increase/decrease as operator zooms in and out.

d. Rotate map clockwise/counterclockwise

e. Establish and return to home position

f. Expand to full screen/return to normal size

g. Show/hide map grid

h. Jump to previous/next map view

i. Plot and display distances on the map

j. Save current map view in a file

k. Select objects on the map

l. Easily distinguish between objects and events close to each other on the map.

2. The EMS shall display icons representing each surveillance camera on the map.

3. The EMS shall display an icon at the location of each alarm on the map. The display shall be color-coded

to indicate alarm status.

4. The EMS shall display icons representing each device on the map. The display shall be color-coded to

indicate device status.

5. The EMS shall display icons representing events on the map. The system shall create event icons

whenever a new event is created in the EMS.

6. The EMS shall allow interacting with a device (play video for cameras, close relays) from the map.

7. The EMS shall have the ability to display all icons (vehicles, people, and devices) inside a defined

coverage zone.

8. The EMS shall have the ability to draw arbitrary shapes and zones on a map.

9. The EMS shall display device coverage area on the map.

10. The EMS shall allow showing\hiding the coverage area for a single or all devices.

11. The EMS shall allow adding point of interest markers that can also include links to other maps and will be

used as on-map hyperlinks.

12. The operator shall be able to control amount of information displayed on a map at any given time.

13. The EMS shall cluster devices whose icons overlap so that the map is not cluttered when zooming out.

14. The EMS shall allow operators to request to see live video from cameras whose coverage area is covering

a point on the map selected by the operator.

15. The EMS shall support playing live video for cameras or for devices that has related camera.

16. The EMS shall support geo-association, i.e., clicking on an area of interest on the map and as a result,

automatically showing all the devices which have coverage of the location, it also includes playing live

video from the relevant camera.

17. The EMS shall automatically identify and present the nearest assets (responders, cameras, devices)

related to an event based on its location.

18. The EMS shall have the ability to track movements of objects with location-based technologies on a map.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

19. When an event is created, the map display shall be able to automatically center on event location.

20. The EMS shall have the ability to search for devices on a map based on type/name.

21. The EMS shall have the ability to capture and send/save snapshots of maps.

22. The EMS shall have the ability to search map based on location (e.g., address, marker, concourse #, etc.).

6.7.3. Emergency Notification System (ENS)

1. The EMS shall be able to initiate notifications to pre-defined personnel through the Emergency Notification

System (ENS).

2. The EMS shall be able to define conditions, triggers, and event types that require notifications to be sent and

who the addressees would be.

3. The EMS shall be able to automatically populate a message based on event type and pre-defined conditions.

4. The EMS shall determine recipients based on event type and location information of the event or within a

geographic footprint.

5. The operator shall have the ability to view notifications associated with an event.

6. The EMS shall provide a message status/history function. It must have the ability to view/search:

a. when message was created

b. who the sender was

c. when message was sent and acknowledged

d. who the addressees were.

6.7.4. Digital Voice Recorder (DVR)

1. The EMS operator shall be able to search voice recordings by time and source (radio, phone).

2. The EMS operator shall be able to create a file of the desired voice recording, for the source, date/time and

duration specified, and attach recorded voice files to an event record.

3. Searchable database shall be restricted to specific pre-defined user roles.


6.8.1. Enterprise Buildings Integrator (EBI)

The EBI system includes: Access Control and Alarm Monitoring System (ACAMS), Fire Enterprise Business

Integrator (FEBI), and the Digital Monitoring System (DMS). The requirements in this section apply to all alarm

systems integrated with the EMS (limited only by device capabilities). The EMS shall allow specific alarm

management functions based on user roles defined by the administrator.

1. The operator shall have the ability to monitor and control alarm systems from the EMS.

2. The EMS shall display alarms in a tabular list.

3. The EMS shall present the operator with a logical tree that contains devices of different types.

4. The EMS shall have the ability to filter and limit alarms that are displayed on the screen (e.g., just ACAMS,

just FEBI, just DMS).

5. The EMS shall allow searching the device tree by device name or device type.

6. The EMS shall indicate the device type by an icon.

7. The EMS shall display a pop-up for a device with its details when clicked.

8. The EMS shall support single-click easy access from device to its GIS map location. When the link is clicked,

the GIS map view shall change to display the appropriate view with the highlighted relevant device.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

9. Alarms shall be automatically displayed on a map.

10. The EMS shall display on a map all cameras and devices associated with the alarm.

11. The EMS shall visually and audibly alert operators upon receiving new alarms.

12. The EMS shall display the alarm record details upon alarm selection. Details should include source device

and its related devices, alarm data, alarm attached images.

13. The EMS shall allow viewing recorded video from the time of the alarm. System should deduce the relevant

camera based on the alarmed device and its related cameras.

14. The operator shall be able to easily view a camera associated with device.

15. The EMS alarm summary view shall enable users to pause/continue the real-time scrolling of alarms.

16. The EMS shall provide easy links directly from the alarms list to video cameras related to the device.

17. The EMS shall have the ability to display groups of devices based on user-defined criteria (e.g., status, type).

18. The operator shall be able to detect the current status of a device (locked, normal, unlocked, power failure,

communications failure, etc.) based on the icon displayed.

19. The operator shall have the ability to operate/control devices from an EMS workstation (open, lock, unlock,

etc.).

20. The operator shall have the ability to access the control functions of an alarm by clicking on the device icon

on a list or map.

21. The EMS shall have the ability to define triggers, alarm correlations, and conditions to automatically create an

event in the EMS. Not all alarms are events in the EMS.

22. The EMS shall update the alarm record on all operators’ workstations when an operator acknowledges or

clears an alarm.

23. The EMS shall log and display the time and the user name of the operator that acknowledged or cleared the

alarm.

24. Operator shall be able to create an event from an alarm and pertinent data automatically populated in the

event record.

25. Operator shall have ability to manually create an event based on an alarm and EMS would automatically

populate event record with associated device information.

26. The EMS shall be able to automatically send notification to maintenance techs based on pre-defined

conditions and alarms.

27. The EMS shall be able to filter and correlate alarms so as not to flood system with alarms.

28. The EMS shall be able to correlate multiple alarms into a single alarm event.

29. All alarms shall be acknowledged by the operator.

30. The EMS alarm functionality shall support querying the history of alarm records of individual devices. It shall

be possible to display the history or generate a report.

6.8.1.1. Access Control and Alarm Monitoring System (ACAMS)

1. The EMS shall be able to support multiple windows, which may include:

a. Access Summary Screen

b. Alarm Summary Screen

c. Badge Holder Screen

d. Video Display Screen

2. The Access Summary Screen displays every access attempt around the Airport. The screen will

continuously scroll as each access attempt is recorded. The data that is displayed shall be configurable

and may include but not limited to:




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

a. Date/time

b. Device id

c. Point descriptor

d. Condition (granted, change, comms.)

e. Badge number

f. Access result (granted, denied)

g. Card holder name

3. The Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed shall

be configurable and may include but not limited to:

a. Date/time

b. Location

c. Point descriptor

d. Alarm type (forced, too long, inactive, etc.)

e. Cardholder badge number

f. Cardholder name

4. The Badge Holder Screen shall automatically display when alarm occurs and access is denied. The data

that is displayed will be configurable and may include:

a. Cardholders name

b. Cardholder date of birth

c. Picture of cardholder

d. Company and job title of cardholder

e. Cardholder status (e.g., active, inactive)

5. The Video Display Screen shall automatically display live video of camera(s) associated with any ACAMS

alarm. Operator shall be able to view video live or prerecorded from any camera selected.

6. The EMS shall be capable of creating an event automatically if pre-defined conditions are met.

7. The EMS shall support an automatic association between access events and badge holders who

triggered them.

8. Research of alarms shall be supported. Alarm details shall be searchable based on location, date/time,

source, description, alarm condition, access reason, cardholder name or badge number.

9. The EMS shall ensure video associated with forced and too long alarms is recorded and stored in the

alarm record.

10. The EMS shall have ability to generate user-defined Access Control reports.

6.8.1.2. Fire Enterprise Business Integrator (FEBI)

1. The EMS shall be able to support multiple windows, which may include:

a. Alarm Summary Screen

b. Video Display Screen

2. The Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed will be

configurable and may include but not limited to:

a. Date/time

b. Location

c. Point descriptor

d. Alarm type (active fire, supervisory, verify, trouble, etc.)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

3. Where possible the Video Display Screen shall automatically display live video of camera(s) associated

with any FEBI alarm. Operator shall be able to view video live or prerecorded from any camera selected.


source, description, alarm condition.

5. The EMS shall ensure video associated with FEBI alarms is recorded and stored in the alarm record.

6. The EMS shall have ability to generate user-defined FEBI reports.

6.8.1.3. Digital Monitoring System (DMS)

Digital Monitoring System (DMS) alarms include Automated External Defibrillators (AEDs), Covert Alarms

(TSA checkpoints, Info Counters, Admin Offices, Parking Exit Booths), Elevator override keys, escalators,

moving walkways, pump house, and Check Point roll up gates.

1. The EMS shall be able to support multiple windows, which may include but not limited:

a. Alarm Summary Screen

b. Video Display Screen

2. Alarm Summary Screen displays every alarm condition that occurs. The data that is displayed will be

configurable and may include but not limited to:

a. Date/time

b. Location

c. Point descriptor

d. Alarm type (AED, Covert, etc.)

3. Where possible the Video Display Screen shall automatically display live video of camera associated with

any DMS alarm. Operator shall be able to view video live or prerecorded from any camera selected.

4. From the Alarm Summary screen the operator shall be able to control DMS devices.


source, description, alarm condition.

6. The EMS must ensure video associated with DMS alarms is recorded and stored in the alarm record.

7. The EMS must have ability to generate user-defined DMS reports.

6.8.2. Mobile Devices

1. The EMS shall provide a mobile device application to support event management operations outside the

Command Center.

2. Mobile Devices to include but not limited to the following:

a. Smart phones

b. Tablets

3. Responders with mobile devices shall have the following capabilities:

a. Status updates to include but not limited to:

i. Acknowledge

ii. En route

iii. Arrive

iv. Clear

v. Available

vi. Out of service

vii. Emergency




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

b. Able to create, edit, add comments/update an event

c. Able to query events in the EMS database

d. Able to support messaging between devices & groups (user-definable), and announcement capability to

the entire mobile active resources on duty

e. Ability to save, search, and delete messages with attachments (video, photos) from the device

f. Able to acknowledge a notification it receives from the EMS

g. See on the mobile device all resources assigned to an event

h. Ability to assign additional responder(s) to an event

4. Mobiles shall support a mapping application to:

a. Utilize base maps from published ESRI GIS

b. Ability to show a real-time map display

c. Show relative bearing from resource location to event location, dependent upon GPS

d. Utilize all standard mapping functions

e. Display event id or resource id on a map

5. The EMS shall be able to the record International Mobile Equipment Identity (IMEI) phone id and user id of

mobile user logging on to system.

6. The EMS shall use GPS location of mobile responders to recommend the closest resource to the event based

upon user-defined event types & distance parameters.

7. EMS shall provide for an audit trail of all communications sent and received between mobiles and EMS with

time stamp, user id, and location.


6.9.1. Operations Security Portal (OSP)

1. The EMS operator shall have access to cardholder data from the EMS screen.

2. The following data must be accessible:

a. Cardholders name

b. Cardholder date of birth

c. Picture of cardholder

d. Company and job title of cardholder

e. Cardholder status (e.g., active, inactive)

3. The operator shall be able to query all badge holders in the system, their access privileges, photos, and

badge information.

4. The EMS shall automatically display badge holder information when access control alarms are triggered by

badge holder.

5. The operator shall be able to query badge holder history given badge number date and time parameters.

6. The EMS shall be able to attach OSP data to the event log.

6.9.2. XPort

7. The EMS operator shall be able to create a work order from the EMS screen and upload to XPort.

8. The EMS shall be able to auto populate the work order from appropriate data in the event record.

9. Operator shall be able to query XPort and view all work orders and their status associated with a specific

event.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

10. The EMS shall alert operator when all work orders associated with an event have been completed.

11. Operator shall have ability to launch XPort application from the EMS.

6.9.3. Phone System (Vesta)

1. The EMS shall support the current Vesta telephone operation from the workstation.

2. Inbound calls will typically be answered on the Vesta interface.

3. Outbound calling can be initiated from the Vesta or the EMS interface.

a. The EMS shall support direct entry of digits for dialing and pass those to the Vesta (e.g.,: “602-555-1212”)

b. The EMS shall support sending pre-loaded phone numbers and/or speed dials (e.g., “Fire Dispatch”) from

the EMS as part of a preconfigured Response Plan task.

c. The EMS shall support call back of the phone number attached to the event.

4. The EMS shall automatically populate an event record with the phone number of the current line the operator

is using when available and the start time of the call.

a. If the call was inbound the information retrieved from the Vesta system will include caller id, dialed

number, and dialing number.

b. If the call is outbound the information retrieved from the Vesta will include the dialed number, extension,

and start time.

5. The EMS shall be able to cause the Vesta system to initiate a conference call using digits directly entered into

the EMS or speed dials or preloaded data in a Response Plan task to add someone to the current call in

progress. Conference calls joining two or more lines on the Vesta will be performed on the Vesta and not the

EMS.

6. The EMS operator shall be able to use phone intercom with other operators in the Command Center.

7. The EMS shall have the capability to put a call into a parking space in the Vesta.

The EMS shall remember the parking space location and allow any operator to retrieve that call when that

event is active on their desk.

The event shall have an indication of a parked call as long as the call is parked.

The Vesta will be configured to auto ring back a call that has exceeded a preset timer threshold.

8. The operator shall have access to phonebook/directory in phone system.

9. Operator shall be able to drag and drop caller id and phone number into event log.

7. EVENT MANAGEMENT SYSTEM PERFORMANCE REQUIREMENTS

Note: Performance requirements to be imposed on the Consultant apply to application design issues. Interruptions in the

network are not the responsibility of the Consultant. As listed in the Scope of Services (Attachment B Exhibit A),

Consultants should include ways to measure and conform to stated performance requirements within the control of the

Consultant only.

1. The EMS should be 99.9% available (less than 9 hours down time/year), achieved through redundancy and fault

tolerance techniques.

2. ANI/ALI data transfer to EMS should occur in less than 1 second, or a mutually agreed upon time.

3. The EMS should present Response Plan in less than or equal to 1 second, or a mutually agreed upon time.

4. The EMS should validate event location under 2 seconds, or a mutually agreed upon time.

5. The EMS should provide a resource/responder recommendation in less than or equal to 2 seconds.

6. Device details should be presented in less than or equal to 3 seconds, or a mutually agreed upon time, using a

publically available cellular network augmented by a protected WIFI system when possible.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7. Resource status updates between the EMS and mobile devices should be completed in less than or equal to 3

seconds, or a mutually agreed upon time.

8. Alerts should be presented in less than 1 second, or a mutually agreed upon time.

9. Event updates presented on all screens in less than or equal to 3 seconds, or a mutually agreed upon time.

10. The EMS record storage should be sized to support 2 years of historical event data on line.

ATTACHMENT D: BUSINESS USE CASES



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

This attachment includes the following components: Use Case Index – lists all Use Cases developed for the Scope of Services, and indicates which EMS users will be involved, as well as which

interactions with other systems are relevant.

EMS Context Overview Diagram – presents, at a high level, how the users and other systems interact with the EMS.

Use Case Narratives – present detailed descriptions of each Use Case, including actors, required data elements, and data flow between integrated systems.

Use Case Process Flows – presents annotated flow charts of each Use Case.

Major EMS Event Types – lists some of the major event types the EMS shall be able to address. This is an incomplete list and will be updated and expanded as system requirements are finalized prior to system design.

Use Case Index

Use Case ID

Use Case Name EMS User Other Systems' Interaction

UC 01 Create/Manage Event (P1) Supervisor; Dispatcher; Command Center Operator (Non-Dispatch)

VSS; GIS; DVR; ENS; Windows

UC 02 Close Event / Create Related Event Supervisor; Dispatcher n/a

UC 03 Create an EMS Checklist Supervisor n/a

UC 04 Generate a Report Supervisor; Dispatcher; Command Center Operator (Non-Dispatch)

n/a

UC 05 Relate Existing Events Supervisor; Dispatcher n/a

UC 06 Reopen/Edit a Closed Event (P1/P2/P3)

Supervisor; Dispatcher VSS; GIS; DVR; ENS; Windows; EBI (ACAMS, FEBI, DMS); Mobile Devices; Phone; Radio; xPort; OSP


VSS; GIS; DVR; ENS; Windows; EBI (ACAMS, FEBI, DMS); Mobile Devices


VSS; GIS; DVR; ENS; Windows; EBI (ACAMS, FEBI, DMS); Mobile Devices; Phone; Radio; xPort; OSP




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case Narratives

Use Case ID UC 01

Use Case Name Create/Manage Event (P1)

Description This Use Case Process Flow depicts the general process of creating and managing events during Phase 1; many events have various commonalities, therefore, it is not necessary to chart every event type individually. Event creation is done manually in EMS based on external event data received by dispatcher. After event creation, the EMS will automatically display an initial event-specific checklist. Any event task with no automated function that is performed by the dispatcher outside of the EMS, is captured as one general process step: “Complete non-EMS Checklist Items”. The “Manage Event” process inside EMS (resulting in automated actions) is shown as a green-colored grouped process and includes the general tasks performed by the dispatcher. The automated system functions triggered by dispatcher decisions/actions are depicted as an orange-colored grouped process and they can happen at any time.

Primary Actors (EMS Users)

Dispatcher

Supervisor

Command Center Operator (Non-Dispatch)

Secondary Actors (Other Systems)

S1 - VSS (interaction from within EMS) S2 - DVR (interaction from within EMS) S3 - GIS (interaction from within EMS) S4 – ENS (interaction from within EMS) S5 – Windows OS/Explorer

Required Data Capture Elements during Event Creation

D1 – Event/Alarm Type D2 – Event/Alarm Location D3 – Caller Name D4 – Caller Phone Number D5 – Event Details

Data to/from External Systems during Event Management

The EMS will interface with several external systems and share data to accomplish desired tasks. The following list includes examples of common expected data types. Full details are included in the EMS specifications:

Video files (S1-VSS)

Audio files (S2-DVR)

Map files with GIS Data (S3-GIS)

Active Events (S4-ENS)

MS Office, pdf, image, and other files (S5-Windows)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case ID UC 03

Use Case Name Create EMS Checklist

Description This Use Case depicts the process of creating static and dynamic checklists for the use of dispatchers in the EMS. The checklists may employ decision points which prompt checklist updates by modifying checklist items. A checklist, once created, can be applied to multiple event types.


Supervisor


n/a

Required Data Capture Elements

n/a

Data to/from External Systems

n/a

Use Case ID UC 02

Use Case Name Close Event / Create Related Event

Description This Use Case flow depicts the conclusion of an event, which can result in (a) the closing of the event or (b) relating the current event to a new event. What sets this use case apart from others is, that it always starts with an active event.


Dispatcher

Supervisor


n/a


Transferable event data


n/a




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case ID UC 05

Use Case Name Relate Existing Events

Description This Use Case depicts relating two or more previously created events, which may be open or closed. This process also identifies existing event relationships for one or more of the selected events, and prompts for replication of those relationships.


Dispatcher

Supervisor


n/a


n/a


n/a

Use Case ID UC 04

Use Case Name Generate Report

Description This Use Case depicts the process of generating fully customizable reports in EMS. Report parameters would be customizable based on numerous EMS data fields. A newly created or customized report needs to be able to be saved as a template.


Dispatcher

Supervisor



n/a


n/a


n/a




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case ID UC 06

Use Case Name Reopen/Edit a Closed Event (P1/P2/P3)

Description This Use Case Process Flow depicts the actions taken when a user to wishes to continue to work with an event that was previously closed. The EMS will present the event from the point it was last closed. This Use Case covers all three phases.


Dispatcher

Supervisor


Phase 1

S1 - VSS (interaction from within EMS)

S2 - DVR (interaction from within EMS)

S3 - GIS (interaction from within EMS)

S4 – ENS (interaction from within EMS)

S5 – Windows OS/Explorer

Phase 2

S6 – EBI [ACAMS/FEBI/DMS] (interaction from within EMS)

S7 – Mobile Devices

Phase 3

S8 – Radio System

S9 – Phone System

S10 – xPort

S11 – OSP


D1 – Event/Alarm Type

D2 – Event/Alarm Location

D3 – Caller Name

D4 – Caller Phone Number

D5 – Event Details


Phase 1






Phase 2

Alarm data (S6-EBI)

Mobile device data update & sync (S7 – Mobile Devices)

Phase 3

Radio data (S8-Radio System)

Caller ID/Location (S9-Phone System)

Work order details (S10-xPort)

Badgeholder Information (S11-OSP)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case ID UC 07


Description This Use Case Process Flow depicts the general process of creating and managing events during Phase 2; many events have various commonalities, therefore, it is not necessary to chart every event type individually. Event creation is done manually or automatically in EMS based on external event data received by dispatcher or an integrated system. After event creation, the EMS will automatically display an initial event-specific checklist. Any event task with no automated function that is performed by the dispatcher outside of the EMS, is captured as one general process step: “Complete non-EMS Checklist Items”. The “Manage Event” process inside EMS (resulting in automated actions) is shown as a green-colored grouped process and includes the general tasks performed by the dispatcher. The automated system functions triggered by dispatcher decisions/actions are depicted as an orange-colored grouped process and they can happen at any time.


Dispatcher

Supervisor



S1 - VSS (interaction from within EMS) S2 - DVR (interaction from within EMS) S3 - GIS (interaction from within EMS) S4 – ENS (interaction from within EMS) S5 – Windows OS/Explorer S6 – EBI [ACAMS/FEBI/DMS] (interaction from within EMS) S7 – Mobile Devices










Alarm data (S6-EBI)

Mobile device data update & sync (S7 – Mobile Devices)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case ID UC 08


Description This Use Case Process Flow depicts the general process of creating and managing events during Phase 3; many events have various commonalities, therefore, it is not necessary to chart every event type individually. Event creation is done manually or automatically in EMS based on external event data received by dispatcher or an integrated system. After event creation, the EMS will automatically display an initial event-specific checklist. Any event task with no automated function that is performed by the dispatcher outside of the EMS, is captured as one general process step: “Complete non-EMS Checklist Items”. The “Manage Event” process inside EMS (resulting in automated actions) is shown as a green-colored grouped process and includes the general tasks performed by the dispatcher. The automated system functions triggered by dispatcher decisions/actions are depicted as an orange-colored grouped process and they can happen at any time.


Dispatcher

Supervisor



S1 – VSS (interaction from within EMS) S2 – DVR (interaction from within EMS) S3 – GIS (interaction from within EMS) S4 – ENS (interaction from within EMS) S5 – Windows OS/Explorer S6 – EBI [ACAMS/FEBI/DMS] (interaction from within EMS) S7 – Mobile Devices S8 – Radio System S9 – Phone System S10 – xPort S11 – OSP










Alarm data (S6-EBI)

Mobile device data update & sync (S7-Mobile Devices)

Radio data (S8-Radio System)

Caller ID/Location (S9-Phone System)

Work order details (S10-xPort)

Badgeholder Information (S11-OSP)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Use Case Flow Charts




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Major EMS Event Types

Event Name Description of Current Process

AED Alarm An Automatic External Defibrillator is pulled from its pedestal and an alarm is generated on DMS (EBI). Dispatcher will send a police officer to investigate the scene.

Aircraft Diversion Dispatchers receive information of a diverted aircraft. Information is passed on to the Airside Operations Supervisor. In some cases an ENS message is sent.

Alert An aircraft reports an emergency to the FAA Control Tower. The Control Tower informs multiple responders of the emergency. IMS is activated. Multiple Police, Fire and Operations units are dispatched. ENS messages are sent.

Alert Drill The FAA Control Tower and Fire department conduct a drill of alert response. Operations is notified of the drill.

Badge Alarm (Lost, Stolen, Terminated, Expired, Inactive)

An alarm is received on ACAMS. Operations and PD are dispatched to locate the subject.

Bomb Threat A bomb threat is submitted to the airport. Police and Security operations are notified of the threat. If valid, areas are evacuated.

Covert Alarm A silent alarm is pushed at a workstation around the airport. Police are dispatched to investigate the scene.

DMS Alarm – Access Related An alarm related to unauthorized entry is received via the DMS (EBI). Police are dispatched to investigate the scene.

Door Forced Open Alarm A portal is opened without a badge being presented to the ACAMS reader. Alarm is received on ACAMS. Dispatcher investigates the validity of the alarm by reviewing history and video. If valid, police and operations are dispatched.

Elevator Override Key A Fireman’s Elevator Key or Over-ride Key is used to summon an elevator that has access to a sterile or restricted area. Alarm is received via DMS. Police and Operations are dispatched to investigate. Work order center is notified to check elevator.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


Fire Alarm Monitoring System Indication

Dispatchers monitor the Fire Enterprise Building Integrator (FEBI). System sounds alarms and warnings for various types of situation that require response from Fire Department or maintenance personnel. Active (red) alarms warrant immediate emergency (Fire) response.

Fire Department Service Call

The fire department is requested for assistance with a non-emergency or non-medical service such as a lift assist, hot fueling, etc. Field units are notified of the response as information only.

Firearm Image TSA or a Police Officer advise that a “firearm image” has been identified by an x-ray operator at one of the TSA security checkpoints. Call is received via telephone (3311) or radio. Police are dispatched.

Fuel Spill Any fuel spill will implement an immediate fire response. Calls usually are received via telephone (3311), but can be via radio.

Laser Strike A laser strike to an aircraft does not damage the aircraft however, it possess the ability to temporarily blind pilots or passengers. Reports are called in via telephone (3311).

National Weather Service Advisory

During severe weather, the National Weather Service will advise the airport of potentially hazardous weather conditions. Call are received via telephone (3311).

Reported Fire Reported fires that occur in areas not monitored by FEBI (roadways, surface parking lots, ramp areas, curbs, etc.). Reports are received via radio and telephone (3311).

Security Incident/Breach The majority of security situations fall under this category. These events are considered a lower threat and do not close the security checkpoints or halt air traffic. A major security breach (incident) that warrants the closing of security checkpoints and the halting of air traffic.

Sky Train Event Any situation that interrupts the Sky Train system.

Standard Medical The fire department is requested for a medical issue. Field units are notified of the response. Operations responds. This event type may include many types of medical scenarios.

Standard Police Response

The police are requested for an incident or report. This event type may include many types of police scenarios.

Stuck Elevator All elevator emergency phone calls are received via telephone (3311). If the passengers are needing emergency assistance, appropriate responding parties are dispatched.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


Too Long Alarm (ACAMS)

A badge holder has been granted access and has proceeded through the portal, but the portal has not completely closed or is being held open. Dispatcher investigates the validity of the alarm by reviewing history and video.

Traffic Stop (PD) When a police officer stops a vehicle for investigation.

Vehicle Accident The severity of the accident is determined and the appropriate response is dispatched.

Vehicle Pursuit Dispatchers are informed of an active vehicle pursuit that is entering or on the airport. Additional police units are notified of the event. Field staff are advised to remain vigilant and in safe areas. Neighboring municipalities are notified of the chase.

Weather Event - Lightning

The Lightning Detection System monitors atmospheric electric charge and actual lightning strikes. Three ranges initiate dispatcher response: 10 mile, 5 mile, and 3 mile.

ATTACHMENT E: CONCEPTS OF OPERATIONS (CONOPS) [TOBE]



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Executive Summary

This Concept of Operations (ConOps) report (Report) presents recommendations for the future Phoenix Sky Harbor International Airport (PHX or Airport) Command Center (CC) and Airport Emergency Operations Center (AEOC). These two centers will exist in a new shared facility space, and therefore, the recommendations are based on an integrated multi-discipline approach The philosophy of a multi-discipline facility is simple: by integrating all day-to-day functions in a common location, customer service and Airport operations will experience marked improvement in work-flow efficiencies and situational awareness. This approach also addresses the need to expand the current AEOC space, which is too confined to allow efficient operations. Such a concept is not a new one. Facilities of this type have been established in the airport environment for many years and typically grow organically over time, assuming more responsibilities in order to best serve the needs of the airport. These facilities generally provide a basic set of combined services, including day-to-day communication and support for terminal, landside, and airside operations; security; facilities; customer service; and command and control during irregular operations (IROPS) or other emergency conditions. While the idea behind these centers is simple, an integrated approach does not necessarily come easily. Entities and organizations functioning autonomously do not always see the need or understand the benefit of close cooperation with others. This impasse is typically made more difficult by incompatible systems and procedures, staff operating near their limits, and constrained resources and budgets. Fortunately, PHX is an exception to this. Management and employees, covering a wide range of divisions, sections, and related disciplines, embrace the concept of cooperating and working together in a consolidated environment. The Airport leadership also understands that in order to accomplish this approach successfully, technology in general, and systems in particular, need to be integrated to provide optimal efficiency and improved streamlined business processes. Although PHX supports this concept, the Airport does currently face challenges. Primarily, the Airport is challenged by how to adequately provide and/or assign staffing resources in order to optimally represent the various operating divisions/sections and related budgets to support integrated technology. Also, the Airport is, at the time of writing this Report, uncertain in regard to the possibilities of obtaining additional staff. Independent of hiring new resources, PHX desires to add a position of Airport Duty Manager (ADM) to oversee the operation of the Airport on a daily basis. In case the ADM role is absent shared part-time between other Operations Supervisors will be implemented. In addition, the chief challenges and deficiencies with the IT systems supporting the CC and the AEOC are related to the lack of convergence of information and the aging of existing technology and systems. This Report addresses these challenges and the Airports objectives, as well as the needs and requirements of an integrated, multi-disciplinary approach. The Report, therefore, (a) presents two alternative staffing operating models to reflect the reality of possibly obtaining additional Full Time




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Equivalent Employees (FTEs). It also (b) recommends the replacement of existing technologies as well as the implementation of new IT system, including a new Event Management System (EMS) as a core information solution. Operations for the current AEOC are compatible with the National Incident Management System (NIMS) Incident Command System (ICS), therefore a change model is not recommended in that regard. The two operating models differ in regard to the use of FTEs. One model considers utilization of existing staff without the addition of FTEs, whereas the other includes the use of additional FTEs. The associated staffing schedules and representation by specific disciplines in each model is, therefore, different. Independent of the existence of the ADM role, the current dispatchers will be represented fairly close to today’s model. However, five of the six positions will move from a defined parameter of duties for a specific position to a more uniform approach. The ACAMS position will look like the other positions yet remains fully focused on supporting airport security. The other dispatch positions will have similar workstation configurations. The Facilities staff will fulfill similar duties as today, but function from a different geographic area. Certain roles will have additional supervisory positions added. New FTE’s would be added staff for Facilities division. Their presence on opening day, however, is not required. The IT position will also function similarly to today’s structure but also in a different geographic location. Terminal and Airside Operations may be represented in a part-time capacity until more FTEs are acquired to fill a yet to be staffed Airport Duty Manager (ADM). They will operate from the CC whenever possible, especially during an IROP or emergency situation. Staffing roles are further explained in this report. The above mentioned technology challenges & deficiencies are being addressed in the new CC and AEOC. PHX will be implementing state-of-the-art hardware at each position, video walls for display of pertinent information, and video-to-all. The Airport will also migrate to a VoIP telephone system, replace the existing radio system, and implement a new Event Management System. The new EMS will fulfill two primary functions. First, it serves as a real-time tool supporting the CC response to incidents at the airport, Secondly, it will become the historical documentation database of every incident and how the Airport responded. By doing so, it will provide multiple benefits, including providing all the data and information needed to respond to an event quickly and succinctly, aiding in simplifying and automating response procedures that staff will need to address to properly and correctly respond to emergencies and irregular events, providing a record for the purposes of lessons learned, and help staff and management improve safety and efficiencies of daily operations.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Command Center (CC)

Background

Bringing multiple disciplines with diverse operational perspectives into one work space for daily operations serves to improve the operations and efficiency of PHX. When divisions/sections engage in this manner, individuals gain a better understanding of each department’s responsibilities and objectives. Close communication improves situational awareness to more quickly and efficiently manage issues. The effect is similar to how the Airport utilizes the AEOC during large events. Constant interaction allowing situation and solution discussions in close proximity improves communication and responses during any type of events. Bringing the appropriate staff and technology together also enables the organization be proactive instead of reactive. There are four distinct steps to establishing a successful multi-discipline Command CC Center:

1. Bringing the staff together in a common location. 2. Providing them with an operational plan that maximizes effectiveness and delivers the greatest

value to the Airport. 3. Providing a suitable space that offers not only a safe, comfortable environment with structural

integrity to withstand physical threat, but also the capacity for growth and change to at least the year 2025.

4. Deploying supporting technology that eliminates inefficiencies and provides the highest degree of situational awareness along with efficient flow of current and accurate information to field operations.

In order to ensure that viable options are recommended, the project team first developed initial goals that were shared and agreed upon by the PHX staff during the first planning process. The following discusses two primary goals the Airport should strive for and the supporting operational and technological solutions to achieve each goal. These goals may be realized over time and adjusted accordingly. Goal #1 - Enhanced situational awareness of activities at PHX with the following enhancements:

Common event management system

Collocation of staff

Better face-to-face access similar to AEOC operations, but daily for IROPs

Access and display of real-time, critical information

Clear and logical information from the field and systems

Dashboard viewing availability from any workstation both inside and outside of the CC.

Goal #2 - Improve efficiency of operations and response:

Enhanced room layout

Acoustically comfortable space, supportive of ease of communications( e.g., dampened HVAC, acoustical floor, wall, and ceiling treatments, use of headsets, etc.)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Good sight lines across space (e.g., good visibility of shared monitors from position to position, specifically in regard to supervisor work station access)

Status indicators for each dispatch position (e.g., busy, free, emergency call, etc.)

Supportive of cabling and power installation as well as ease of relocation or reconfiguration of consoles and equipment with minimal disruption (e.g., raised floor/console)

Room for growth (until 2025)

Intelligent use of technology and integration to support efficiency

Common computer platforms and configurations with a full suite of common software: o Reduced keyboard, mouse, and CPU counts o Single sign-on to the extent possible o Customizable dashboards o Integration of information and systems to allow easy population of key data from one

system to another automatically, i.e., eliminate redundant manual data entry o Event Management System with built-in standard operating procedures (SOP), decision-

making and searchable software, GIS capabilities, VSS integration and the ability to add voice or radio dialogue to an event through the Nice Voice Recording System

o Support of real-time and historical events and operations o Trending capability and report writing

Operating Models

There are two operating models (A and B) for the CC. Model A uses existing staff without any additional FTEs, whereas Model B includes FTEs as well as an Airport Duty Manager (ADM) position. Note, the total number of positions can be found in Table 1 in the Staffing section. Model A This model, as shown in Figure 1, does not incorporate any additional FTEs but utilizes existing staff that will relocate from their current location to the new CC. The figure generally represents those functions found within the CC and illustrates the lines of communication between the various positions.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Figure 3 Organization Chart - Command Center with Oscar 20, 30, 50

Figure 1 shows that the lines of communication go through the Supervisor. The lines of communication from divisions/sections outside of the CC will almost always start at the dispatch level or be resolved through Supervisor intervention. The Supervisor, Oscar, and Facilities positions are represented as peers and will work together to resolve events such as IROPs. The clouds represent the direct lines of authority which remain unchanged from the current organization. Most of the dispatchers and supervisor responsibilities do not change in the new CC with the exception of those responsibilities related to the improved software integrations expected from the EMS. These integrations resolve any of the positions from having to physically relocate to do their jobs. One dispatch position remains as a specific assignment for ACAMS because of the focus needed by the dispatcher supporting police responses. Position responsibilities will be assigned by the Supervisor. Most other duties may be performed from any other position. The Facilities positions represent work currently done at another location of the Airport. In this case, only the job location will change, not the function. Without additional FTEs the positions of the Facilities Decision Maker and System Monitor/Planner (User Tech) cannot be full time positions in the CC. Instead, they will be available on a part-time basis and will be reflected as such in the schedule. The IT position also represents current FTEs and job functions that will be performed in the new CC. The Oscars 20, 30, and 50 (Terminal Operations) positions will be expected to work from the CC unless




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

they are needed in the field. They will perform administrative and logging tasks while operating from the CC.C. Model B This model, as shown in Figure 2, incorporates the optimal use of FTEs as well as the addition of an Airport Duty Manager (ADM). The ADM would be the highest ranking authority in the CC (similar to how the AVCOM Director oversees the AEOC)even though staff working together have direct lines of communication to other divisions/sections as reflected by the cloud symbols..

Figure 4. Organization Chart – Command Center with Airport Duty Manager.

Recommendations

Based on Figure 4 B, it is recommended that PHX build a space considering future growth until 2025. There are several positions that can be occupied on Day 1, including the Facilities Work Order, Facilities System Monitor/Planning, and Baggage Handling System (BHS). There are also User Tech and Decision Maker positions, which may start as part-time rather than dedicated full-time. The Oscar 20, 30 and 50 positions may represent the Airfield, Landside, and Terminal Operations in the CC. Again, they will be expected to work from the CC unless they are needed in the field. Oscars are expected to respond to the CC in the instance of an IROP. This is the same for Security, Ground

Supervisor

Airport Duty Manager

Part Time

TSA

FacilitiesWorkOrder

IT

FacilitiesSystem

Monitor/Planner

FacilitiesBHS

Facilities Decision

Maker

Working Within the Center

Command Center with Airport Duty Manager (ADM)

Dispatch

Emergency

Preparedness Facilities

Parking

GT Security

Terminal

Landside/Airside

IT

TSA

Operations

Superintendent




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Transportation and Parking divisions. Management will need to advise the Oscars of staffing expectations in the part-time role. There are areas where improved efficiency will be obtained by eliminating the need to geographically rotate dispatcher positions during a shift. With the new EMS providing most of the required information to most of the positions, the number of physical rotations in a day to different physical locations will not be needed. Rotating responsibilities through a daily shift schedule still allows for cross-training without interrupting current operations. It is also recommended that the Dispatchers, Airside, Landside, Terminal, and Facilities groups gather at the beginning of each shift for a 10-15 minute briefing. This briefing could begin even prior to the new CC being as it helps building relationships and improves lines of communication. The new CC should continue to help improve communications when collocated together with the AEOC. This may be a first step towards a culture change that a multi-discipline center requires to operate more effectively. PHX airport staff already work very well together, so a briefing can only enhance communications. Lastly, the integration of new and existing systems should be carefully planned and phased in over time. It is recommended that with an anchor EMS, the first phase core systems to integrate should be the Geographic Information System (GIS), Digital Voice Recorder (DVR), Emergency Notification System (ENS), and Video Surveillance System (VSS), with a plan developed for integrating additional systems in the future based on operational benefits and budget, thereby better managing expectations.

Staffing

Table 1 and Table 2 represent all of the available positions in the new CC and when they are expected to be staffed according to shifts. The tables graphically represents the user/position, number of staff, existing FTEs, future FTEs and the variance in the numbers form the first programming study.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Table 1. Command Center Seats.

Table 2. Variance in Seats from Command Center Programming Study.

An example of a head count on shift 1 Monday through Friday with no additional FTE’s using existing staff is 12 persons. With additional FTEs that number on shift 1 would increase to 14 due to the addition of an ADM and Facilities Decision Maker. The final number of seats will be better determined once the design of the CC begins. Future growth positions will be visually represented in the CC with




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

furniture installation, but will not have the IT systems deployed. It is not practical to invest in installing IT systems in all of the consoles until they will be occupied. Position Descriptions Each position as shown in Tables 3 through 13, is described according to its:

Purpose

Availability

Need for additional FTEs

Space Requirements

Responsibilities

Level

Schedule

The following positions are covered:

Dispatch

Dispatch ACAMS

Dispatch Supervisor

Facilities Decision Maker

Facilities User Tech

Facilities BHS

Facilities Work Order

Oscar 20/50

Oscar 30


Information Technology

Dispatch

Purpose To provide overall call taking and triage calls

Availability Day 1

Additional FTE’s Required

None

Space Requirements

Five 1-person consoles

Responsibilities

1. Answers incoming emergency and paging and information: x3311 calls x3300 calls x2202 calls

2. Monitors EBI including FEBI and DMS (Digital Monitoring System) (covert alarms at parking exits, information booths, checkpoints and police offices, and Automated External Defibrillator (AED) alarms), and alarms in general.)

3. Passively monitors and surveys all VSS cameras.

4. Prepares video clips from VSS for dissemination to parties upon request to requestors such as the TSA, Police, Risk Management, and the Public.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Dispatch

5. Sends out notification using the ENS regarding alerts, breaches, and any other situation that might impact airport operations.

6. Monitors the Aviation PD radio talk group.

7. Passively monitors the PSAP frequency and talk group, (a common channel for Phoenix Police Department).

Maintains constant awareness of the status of all Aviation Police Officers and updates this information as it changes.

8. Prioritizes all emergency and security incidents that occur at the airport.

9. Actively monitors paging software.

10. Monitors Lightning Detection System and broadcast warning to field units.

11. Receives, dispatches, and enters work orders into Xport: M-F 1500-0600 and 24/7 on Saturday-Sunday and Holidays.

12. Communicates updated and precise information to airport staff and the traveling public.

13. Enters incidents into the EMS

14. Will cover SKYHARBOR radio frequency and monitor other talk groups during IMS situations.

15. Broadcasts Alerts, Medicals, and Fires.

16. Passively monitors the Fire Computer Aided Dispatch.

17. Supports overall CC activities as needed.

18. Serves as support during IROPs and/or emergencies.

Level The position would be an aviation Dispatcher City staff – Communications Dispatcher/AVN.

Schedule

1. 24/7

2. Covered 365

3. Three shifts: a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 3. Position Description – Dispatch.

Dispatch ACAMS

Purpose To monitor the Access Control and Alarm Monitoring System (ACAMS) and respond to alarms as well as support the CC.

Availability Day 1


None

Space Requirements

1-person console

Responsibilities

1. Answers incoming public x3300 calls. Answers incoming internal x3302 calls. Monitors the ACAMS activity.

4. Monitors Airside Operations radio talk group.

5. Identifies or broadcasts Airfield Security Breaches, Door Forced Open




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Dispatch ACAMS

alarms, etc.

6. May monitor other EBI alarms.

7. Passively monitors and surveys all VSS cameras.

8. Answers incoming paging phone calls as needed.

9. Enters incidents into the EMS.



Level The position would be an aviation Dispatcher City staff – Communications Dispatcher/AVN

Schedule

1. 24/7 2. Covered 365 3. Three shifts

a. 0600 to 1430 b. 1400 to 2230

c. 2200 to 0630 Table 4. Position Description – Dispatch ACAMS.

Dispatch Supervisor

Purpose To provide overall supervision of call taking and call triage as well as support for ACAMS.

Availability Day 1


None

Space Requirements

2-person console

Responsibilities

1. Oversees all dispatch activities.

2. Monitors all ACAMS activities.

3. Functions as back up for all dispatch activities: a. Monitors EBI including FEBI and DMS (Digital Monitoring System)

(covert alarms at parking exits, information booths, checkpoints and police offices, and Automated External Defibrillator (AED) alarms), and ACAMS.

b. Passively monitors and surveys all VSS cameras. c. Prepares video clips from VSS for dissemination to parties upon request

to requestors such as the TSA, Police, Risk Management, and the Public.

d. Sends out notification using the ENS regarding alerts, breaches, and any other situation that might impact airport operations.

e. Listens to voice traffic at other positions. f. Answers incoming public x3300 calls. g. Answers incoming internal x3302 calls. h. Answers paging and information line. i. Actively monitors paging software. j. Passively monitors the PSAP talk group. k. Monitors Lightning Detection System and broadcast warning to field

units.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Dispatch Supervisor

l. Receives, dispatches, and enters into Systems Application. Product work orders: M-F 1500-0600 and 24/7 on Saturday-Sunday and Holidays.

m. Broadcasts Alerts, Medicals, and Fires. n. Passively Monitors the Fire Computer Aided Dispatch. o. Monitors all IMS talk groups and incidents. p. Communicates updated and precise information to airport staff and the

traveling public. q. Enters incidents into the EMS.

4. Creates shift reports.

5. Updates dispatch schedules.

6. Assign specific shift responsibilities/breaks

7. Supports overall Command Center activities as needed as the point of contact.


Level The position would be an aviation Dispatcher City staff – Aviation Supervisor 1 level.

Schedule

1. 24/7 2. Covered 365 3. Four shifts

a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

d. Flex shift (10 hours) Table 5. Position Description – Dispatch Supervisor.


Purpose

To monitor daily operations and building system health, especially for critical systems such as life/safety, energy management, BHS, and vertical transportation.

To provide advance planning and leadership during irregular operations, system outages, or closures due to maintenance or construction activities, and larger scale events.

Availability Day 1


1-person console

Space Requirements

3 new, 2 existing Avn. Sup. II’s to be upgraded for a total of 5 FTE’s

Responsibilities

1. Monitors airport maintenance and construction activities, passenger/baggage loads, planned special events.

2. Provides operational “look-ahead” to F&S staff for MX planning purposes.

3. Ensures MX planning activities are prioritized correctly and appropriate responses have been taken.

4. Monitors work order assignments and ensure appropriate performance




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


metrics are being met.

5. Interacts with all airport stakeholders.


7. Serves as lead decision maker for Facilities during IROPs and/or emergencies until EOC stood up.

Level The position would be an aviation Facilities City staff – Aviation Supervisor III, Grade 35/unit 7

Schedule

1. 24/7 2. Covered 365 Three shifts:

a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 6. Position Description – Facilities Decision Maker.

Facilities User Tech

Purpose To monitor and provide repair response for various building systems.

Availability Day 1


2 – Utilize 3 existing staff

Space Requirements

1-person console

Responsibilities

1. Monitors building systems: a. Honeywell EBI monitoring equipment b. xPort c. SAP (Work orders)

2. Creates, assigns, and dispatches staff for work orders & close out. 3. Supports overall CC activities, as needed. 4. Serves as support for Facilities group during IROPs and/or emergencies.

Level The position would be an aviation Work Order City staff – User Technology Specialist, Grade 228/unit 2

Schedule

1. 24/7 2. Covered 365 3. Three shifts:

a. 0600 to 1430 b. 1400 to 2230

c. 2200 to 0630

Table 7. Position Description – Facilities User Tech.

Facilities BHS




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Facilities BHS

Purpose To monitor the status of the BHS and respond appropriately.

Availability Day 1


None

Space Requirements

1-person console

Responsibilities

1. Oversees BHS.

2. Oversees BHS contractor performance.

3. Responds to Airline and TSA needs.

4. Initiates and coordinates BHS contingency plans as needed.

5. Formulates reports as needed.


7. Serves as support for Facilities group during IROPs and/or emergencies.

Level The position would be an Aviation City staff – Building Equipment Supervisor level Grade 32/unit 7

Schedule


a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 8. Position Description – Facilities BHS.


Purpose To manage maintenance request calls.

Availability Day 1


None, utilize 3 existing

Space Requirements

Three 1-person consoles

Responsibilities

1. Triages initial call.

2. Sets priorities.

3. Dispatches appropriate personnel.

4. Closes out work orders when complete.


6. Serves as support for Facilities group during IROPs and/or emergencies.

Level The position would be an aviation Work Order City staff – Support Service Aide Grade 324/Unit 3

Schedule

1. Five days per week 2. Monday through Friday

a. 0600 to 1800 b. Two persons 0600 to 1430




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


c. One person 0930 to 1800

Table 9. Position Description – Facilities Work Order.

Oscar 20/50

Purpose To provide oversight of all activities in the CC with a focus on Landside and Terminal subject matter expertise.

Availability Day 1 as available


None

Space Requirements

2-person console

Responsibilities

1. Oversees:

a. Common use kiosks

b. Ticket counters

c. Early bag checks

d. FIS kiosk

2. Interacts with stakeholders a. Airlines b. Tenants c. TSA

3. Schedules personnel.

4. Manages Shift logs

5. Schedules Gates.


7. Serves as lead decision maker for their sections during IROPs and/or emergencies.

Level The position would be an aviation Operations City staff – Supervisor II level.

Schedule

1. 24/7 2. Covered 365 3. Three shifts

a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 10. Position Description – Oscar 20/50.

Oscar 30

Purpose To provide oversight of all activities in the airfield as well as well as provide support to the CC.

Availability Day 1

Additional FTE’s None




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Oscar 30

Required

Space Requirements

2-person console

Responsibilities

1. Oversees:

a. FAR Part 139 inspections

b. Gate management

c. RONs

d. Remote parking

e. Ground boarding

f. Early bag checks

2. Interacts with stakeholders a. Airlines b. Tenants c. TSA

3. Manages NOTAMs


5. Manages Shift log

6. Approves Leave slips

7. Schedules Gates.


9. Serves as lead decision maker for the Airfield group during IROPs and/or emergencies.

Level The position would be an aviation Operations City staff – Supervisor II level.

Schedule

1. 24/7 shared with airfield response activities 2. Covered 365 3. Three shifts:

a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 11. Position Description – Oscar 30.


Purpose To provide oversight of all activities in the CC as well as provide Airside, Landside, and Terminal subject matter expertise.

Availability TBD


5

Space Requirements

2-person console




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


Responsibilities

1. Oversees:

a. Gate management

b. RONs

c. Remote Parking

d. Ground Boarding

e. Ticket Counters

f. Common use kiosks

g. Ticket counters

h. Early bag checks

i. FIS kiosk

2. Serves as lead decision maker for CC.

3. Interacts with stakeholders: a. Airlines b. Tenants c. TSA

4. Manages NOTAMs.


6. Manages Shift logs.

7. Schedules Gates.


Level The position would be an aviation Operations City staff – Supervisor III level.

Schedule


a. 0600 to 1430 b. 1400 to 2230 c. 2200 to 0630

Table 12. Position Description – Airport Duty Manager.


Purpose To provide Aviation-wide Help Desk – First Level Support and be the primary system support within the CC.

Availability Day 1


1-person console

Space Requirements

To be determined depending on staffing levels and shifts covered desired on Day 1 and in the future.

Responsibilities

1. Takes help desk calls.

2. Provides basic diagnostics.

3. Provides Subject Matter Expertise for EMS CC systems triage.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221


4. Provides preventive maintenance.

5. Patches systems.

6. Monitors Network Operations Center (NOC).

7. Manages Triage calls: a. Determines who to call out b. Needs to determine escalation of calls

8. Utilizes Remedy/Force as the logging software, cloud-based platform enterprise issues:

a. Internet b. email

9. Provides staff support (supplemental staff contractors) for common use equipment

a. City contractors will remain first level support b. SIDA will take next level

Level The position would be an aviation IT City staff – Entry Level Technician; 1st shift after hours and supervisor on 2nd shift. 3rd shift technician may respond to CC as necessary.

Schedule

1. 5 days a week 1700 to 0600

2. Two days a week holidays / 24 hours per day

3. Covered 365

4. Two shifts: a. 0600 to 1430 b. 1400 to 2230

5. One shift part time: a. 2200 to 0630

Table 13. Position Description – Information Technology.

Lines of Authority

The lines of authority as shown in Figures 1 & 2 delineate the direct reporting lines for staff. This is not a change from the current organization. However, when working collaboratively in the CC, there is a dotted line relationship between the various divisions/sections represented.

Staffing Schedule

Until additional FTEs are added to extend some functions to a 24/7/365 availability, these functions may be filled by existing staff on the shift which is in the greatest need of support. The 30 minute staff overlap on each shift change from all the divisions/sections will make it conducive to have a multi-discipline shift brief to enhance communication and culture within the CC environment.

Airport Emergency Operations Center (AEOC)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Background

Most airports are familiar with the National Incident Management System (NIMS) and the Incident Command System (ICS). PHX incorporates the use of these tools and plans and practices all types of response management under the NIMS ICS umbrella. It is generally agreed that, because airports rely upon outside resources when an incident or event outstrips their ability to manage it on their own, it makes it valuable for the Airport and their regional disaster response partners to share a similar preparedness platform. Assets, such as hazardous materials response teams, bomb squads, hostage negotiation units, decontamination units, volunteer organizations, and other specialists, are typically brought in from outside the airport if needed during an incident. Those as well as other assets exist within government structures—counties, states, or federal agencies—and those jurisdictions follow NIMS, if not “by-the-book” then very close to it. PHX works closely with a number of stakeholders outside of the City, including FBI, TSA, FAA, mutual aid, airlines, and tenants among others. It is important that all responders utilize a common structure and terminology. NIMS is an outgrowth of all-hazards planning as promoted during the late 1970s which led to FEMA’s Federal Response Plan (FRP). The FRP was the first step in organizing specific emergency response functions and assigning lead and support agencies for each function, such as ESF-1Transportation, ESF-5 Emergency Management, ESF-8 Public Health and Medical Services, and so forth. State and local government departments aligned themselves to their Federal counterparts in adopting the FRP for state and local emergency planning. For nearly 10 years the FRP stood as the recommended guideline. Newer versions of the FRP eventually followed, but the basic plan remains at the core of the subsequent iterations: the National Response Plan and the currently used National Response Structure and NIMS. Also, during the last decades of the twentieth century, another related system was being developed – the Incident Command System (ICS). Originating out of the wild land firefighting sector as a solution for better resource management among multiple agencies and across state lines, the ICS is applicable to all manner of incident command situations. It essentially is an emergency services personnel management system for on-scene responders and staff in an Emergency Operations Center (EOC). In the case of PHX it is the Airport Emergency Operations Center (AEOC), as not to be confused with City or County EOCs, managed under the umbrella of NIMS ICS. The ICS is a flexible system that also assigns particular positions to specific functions and can be expanded as needed depending on the demands of the situation. These assignments within the ICS structure may be made with various airport staff and are not specific to any one department. However, some divisions/sections lend themselves to certain assignments by virtue of their day-to-day expertise such as Airside Operations as the Operations Section Chief or Facilities as the role of Logistics Section Chief. Federal Aviation Regulation (FAR) Part 139 certificated airports are no longer in a position to opt out, rather, FAA requires that airports reflect NIMS in their Airport Emergency Plans (AEP) and pursue ICS




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

and NIMS training for their employees. Compliance with NIMS standards is a requirement for disaster preparedness funding, including any funds sought to support training. PHX has a good ICS program and conducts regular training either online or in practice during real and/or drilled events. Utilizing a good structure diminishes the length of the event as well as the loss of life and property or environmental damage. PHX has the structure and programs in place, but is hampered by the geographic foot print of the space. The new AEOC will provide for greater space and layout for those necessary staff to collaborate better during times of emergencies or events.

Operating Models

During emergencies, the major divisions/sections at the Airport – Operations, Facilities, IT, Security, Ground Transportation, and Parking – assemble in the AEOC and collaborate to respond to an event bringing with them each divisions/sections’ expertise. The AEOC may serve as the center of the emergency if it is either a geographically wide-spread event for whatever reason a center point for a Command Post (CP) is not practical such as during a natural widespread disaster. The AEOC may also serve as support to field staff by coordinating plans and resources away from the high stress environment which the on-scene command may be dealing with. The AEOC oversees the big picture of the airport while helping the on-scene responders and yet trying to keep the airport operating. This type of environment, with appropriate staff on hand, leads to a quicker resolution and the return to normal services. The operating models will follow the NIMS ICS structure as mandated by the FAA and reflected in Lines of Authority Figures 3 & 4.

Recommendation

The Airport currently has protocols for activating the AEOC and making assignments based on the level of activity and needs of the event. Usually, a high ranking manager will activate the AEOC. Today, this highest ranking individual during afterhours may be an Oscar 20 or 30. By the time personnel are notified to respond to the airport to staff the AEOC, the Oscar 20 or 30 positions may be relieved by the AVCOM Director Position and return to their normal duties or they could be staffed in a position within the ICS structure such as Planning Section Chief or Operations Section Chief. In the case where the airport has successfully staffed an ADM in the CC it is recommended that this person may activate the AEOC until relieved by another staff person. In this case, the ADM would return to the CC to run the day-to day operations. It is intended that the AEOC would relieve the CC from most of the event management so that the Center could concentrate on keeping airport operations running to the extent possible given the impacts from the event. During emergency operations when the AEOC is staffed, it is also recommended to include a dispatcher to act as a liaison between the AEOC and the CC in order to synchronize the most accurate and timely information between the two centers. PHX currently follows some of the ICS protocols but may not have fully adapted all the nomenclature for position descriptions within the NIMS ICS structure. More training utilizing the ICS nomenclature is recommended. The job descriptions in this report speak to the ICS functions. Utilizing the structure in major events is a requirement by the FAA.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Shortly after the new AEOC facility is opened, it is further recommended that a dry run of various events is simulated. It should include bringing into the new AEOC stakeholders from within the airport environment as well as from the outside The purpose is for the familiarization with both logistically finding the new AEOC and getting acquainted with the room layout, support tools, and technology available. PHX currently deploys an IT support system for events known as WEB EOC. It is recommended the Airport continue to utilize this as the primary tracking database for events in the AEOC. Reports can be exported and added to the new EMS expected to be implemented in the new CC. This ensures all reportable documentation the airport is interested in tracking is housed in one platform. The EMS platform will be used to support the daily logging of airport events and reports in the CC. It will also be available in the AEOC as another tool if necessary.

Staffing

The number of persons responding to the AEOC will be able to be increased from the current count given the Center’s larger footprint. Table 14 indicates the positions by discipline as well as the ICS organization nomenclature such as Section Chiefs and Liaisons. The numbers represent the positions accounted for in the AEOC. Every position is not necessarily staffed for every event, however the space will be able to accommodate the necessary responders in case of a large scale emergency. Staff should only respond to the AEOC when invited and given a role. A sign-in and tracking document will ensure that only persons necessary for the event are in the AEOC. This is important in order to make sure staff is accounted for and persons are not freelancing activities associated with the event. It is especially relevant as to ensure all staff are not “burned out” in the first operational period. Some staff should be identified for the next operational period and relieved from duty so they are ready for their shift. This is most true when a long-term event is expected.

Position Seats

AVCOM DIR 2

Operations Section Chief 2

Logistics Section Chief 2

Planning Section Chief 2

Finance Section Chief 1

Day to Day Section Chief 1

PIO 2

Administration 1

Airlines 2

Emergency Manager 1

Scribe 1

Dispatcher Liaison 1

Liaison (i.e. Red Cross/County Health) 1




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Position Seats

TSA 1

Police 2

Fire 2

IT 1 Flex (Landside, Airside, Terminal, GT, Parking, Security) 2

Total 27

Table 14. AEOC Staffing Positions.

Position Descriptions Position descriptions in the AEOC are either related directly to the ICS structure or as a support role identified by PHX. NIMS ICS uses a common set of terms that most responding agencies and mutual aid responders understand and expect to use in emergency situations. These common terms make up the ICS organization configuration. This ICS organization chart can be compared to any business structure which displays a person’s title, responsibilities, and lines of communication represented through the structure. The same holds true for an ICS configuration. Whether staff are reporting to their daily job or in the AEOC, it is important to understand what their role is in the organization.

In the Field

Incident Commanders in the Field

This role is assigned to the lead response agency’s incident commander (IC) who is responsible for the immediate tactical response. Or there may be a Unified Command (UC) where the lead role is shared, for example by Aircraft Rescue Firefighting (ARFF), Police, and Oscar 30. The IC or UC is responsible for tactical operations related to that specific event/incident.

The IC or UC is responsible for developing and communicating an incident action plan (IAP). The IAP may be either written or verbally communicated. The IC/UC will consult with the other members of the command and general staff on actions to be taken and issues that arise, and in concert with other stakeholders. The gathering point in the field is at the Command Post (CP) which is either the IC or someone from the UC’s vehicle or staff, who may utilize the Airport’s mobile command vehicle. Should the severity of the event need further support, a request to activate the AEOC should be communicated.

Transition to AEOC Activation

The activation of the AEOC can happen through various means. The IC/UC may notify the CC and ask for an activation. Management may advise the CC that they are responding to activate; or some events, such as an aircraft accident, will automatically trigger the activation. During normal hours, senior management staff would respond to fill the positions needed based on event




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

type and scale. Also, persons assigned to the CC would likely be only minimally impacted. After hours, it is likely that the Oscar 20, 30, or 50 on duty would respond to activate as the temporary AVCOM Director and request staff accordingly. If the airport establishes the ADM position in the CC, the ADM may temporarily respond to activate the AEOC until relief staff arrive at the airport. The concept of the AEOC is to take the weight of the event off the CC so the CC can manage the normal activities of the airport not associated with the event. This is an ideal concept and in the real world staff that normally support the CC may temporarily have to support the AEOC. A Dispatcher from the CC may likely be staffed as a Liaison to the AEOC.

In the AEOC

AVCOM Director in the AEOC

This is normally assigned to a senior airport manager. This role is one where a senior individual with a strong comprehensive understanding of the airport and its operations, manages support to the response, activates additional incident/event response as necessary, and provides direction on measures to continue operations on the unaffected portions of the airport. This position keeps an eye on both the event and the daily operations of the airport to lessen the impact of one to the other.

AVCOM has overall control and responsibility of the incident. Upon activation of the AEOC, AVCOM can be any Operations Supervisor II up to and including the Aviation Director. AVCOM establishes the ICS structure, including assignment of Section Chiefs, Liaisons, and Support Officers. AVCOM’s main focus is on strategic planning and the “big picture” and the impact of the incident from a broad perspective, including:

Providing direction, advice, and guidance to the Operations section handling tactical aspects of the incident;

Approving and continually evaluating and modifying the incident action plan (IAP), as necessary;

Maintaining overall control of the communications process and information flow between AEOC, Unified Command Team / Unified Command Vehicle, and other responders, as necessary;

Facilitating regular verbal updates from EOC participants as to maintain situational awareness on specific responder efforts;

Ensuring that goals and objectives of the Section Chiefs are met; and

Terminating incidents.

Operations Section Chief

This role, reporting to the IC/UC or AVCOM Director, is generally responsible for the tactical response to an incident/event, and depending on the scope of the event, may have a number of strike teams or branches reporting to it. The Operations Section Chief’s responsibilities include coordinating with tactical operations at the incident/event site as well as with the IC/UC for status updates, processing resource requests, providing updates to/from the Staging Area Manager (if in place), overseeing the Logistics and Planning Sections, and coordinating air




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

resources on site. Some of the subordinate staff to the Operations Section Chief may include outside stakeholders, depending on the incident itself, their expertise, and their agency’s level of involvement. The Operations Section Chief may also be staffed in the AEOC as the lead coordinator for the IC/UC in the field.

Logistics Section Chief

This position is usually assigned to Airport Maintenance personnel who possess knowledge about all the potential resources available to support an incident/event response, and can acquire resources supporting the effort (including those in a staging area). A Maintenance Supervisor can usually marshal resources not organic to the emergency response organization to quickly support the response.

Planning Section Chief

The Planning Section Chief is responsible for planning actions covering a 12- 24 hour time frame. This may be referred to as the Support Officer to the AVCOM Director. The responsibilities include managing staff schedules, establishing and updating the IAP, recording situational status and resource status, and eventually designing the demobilization plan. Normally, if an event warrants the staffing of the Planning Section Chief, it is usually indicative of the AEOC having to be be activated.

Finance/Administration Section Chief

A Senior Manager of Finance is best suited for this position, with additional support staff as needed. This position is also referenced as the Administration position by PHX. The purpose of the position is to support the event/incident IC and associated staff. It represents as much of a process as it does a person. The processes should be coordinated ahead of any event and include access to forms and an accounting system set up to track costs associated with the event. This tracking could be set up in the airport’s financial system or in an Excel or Access database format. This position is responsible for tracking the incident/event in terms of procurements, use of resources from an HR standpoint, staff costs, and other outside support costs that may evolve. It is ultimately responsible for appropriate documentation of the event in order to process claims or reimbursements from federal or state coffers. This manager will provide advice on financial issues that may arise from the incident/event and approve final resolutions on compensation and claim cases.

Day-to-Day Section Chief

This position is unique to airport incidents/events, and not part of the formal FEMA ICS nomenclature. It represents the person responsible for managing the other aspects of keeping the airport open and operating during an event. Resources are needed for both the day-to-day management and the event management, and are best coordinated in the AEOC. This person is usually an Airport Operations staff or similar employee. The duties revolve around monitoring and managing non-emergency or irregular operations responses to issues besides the incident/event at hand. It also includes ensuring to the extent possible that normal operations are not affected.

Scribe




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

This position provides administrative support to AVCOM and all AEOC responders, as necessary. Duties include initiating AEOC activation by turning on lights, computers, and other equipment as necessary; taking notes; utilizing the VSS system; and cooperating with CC and IT staff.

Liaison Officer

The Liaison Officer is a key resource for the AVCOM Director, and functions in the capacity to coordinate with outside agency responders, such as federal and mutual aid responders, not physically represented in the AEOC. These responders, however, may possibly be deployed later as needed, or are providing support or assistance in roles not directly impacting the incident/event scene, e.g., Airlines, American Red Cross, or the National Transportation Safety Board (NTSB).

Public Information Officer (PIO)

This is a key role in any incident/event. This position is responsible for briefing the media and managing press releases,. This position must gain approval of the AVCOM Director before releasing any information to the public. In the case of a joint information operations center supporting a regional incident/event, the PIO will further coordinate with other agencies on information releases. The PIO will also designate a media area. This role usually needs a number of support staff so that the PIO is free to handle media while others are watching and tracking news reports and social media posts.

TSA

TSA will develop and maintain coordination with TSA Supervisory staff and provide updates to AEOC staff of any TSA related issues related to equipment and overall personnel.

Police

Police will provide coordination of law enforcement activity on the Airport property and will provide at least hourly updates to AEOC staff.

Fire (ARFF)

Fire will provide coordination and support to Operations and Day-to-Day Section Chiefs, and will provide at least hourly updates to AEOC staff.

Flex

This position will be staffed by specific expertise when needed, and might include representatives from Security or Parking.

Emergency Manager

This position should help consult and coordinate the players in the AEOC. The Emergency Manager serves as the Subject Matter Expert (SME) for the Airport’s emergency plans.

IT




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

This position may be supported by two staff members and will provide any needed technical support in the AEOC.

Airlines

Airlines will liaison with their corporate headquarters and local staff.

Lines of Authority

For the purposes of this report the organization focus is on the AEOC. However, it is important to understand the relationship to the field command staff. The IC/UC should have a direct line of communication to the AEOC. The field CP should be responsible for directing tactical activities in the field. The AEOC should support those activities. Oftentimes, the IC/UC communicates through the Operations Section Chief to make requests and updates. The IC/UC could also communicate directly to the AVCOM Director depending on how the Center is staffed. In times when there is a field command staff and the AEOC is not activated, the following basic chart, as shown in Figure 3, supports this response. Lines of authority/communication are shown throughout. Often times the General Staff responsibilities are retained by the IC/UC.

Figure 5. Field Command ICS Organization Chart.

When the AEOC is staffed, generally the role of the section chiefs may transfer to the AEOC. Each command structure is subject to the needs of the event and can be expanded or contracted as applicable. In the case of an aircraft accident the AVCOM Director is the overarching authority within




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

the AEOC, although this role does not necessarily have authority over the tactical command the IC/UC in the field. Figure 4 shows represents an organizational breakdown option for managing the AEOC and lines of communication to the field CP.

Figure 6. AEOC ICS Organization Chart.

ATTACHMENT F: CURRENT CONDITIONS [ASIS]



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

This attachment provides an overview of the current Command Center (CC), including its challenges and deficiencies, systems used, and the dispatch position configurations and responsibilities.

Current Command Center (CC) Overview

The Command Center serves as the central point to maintain situational awareness of all airport operations. It is a 24x7x365 facility which overseas and maintains the overall internal and external communications activity. Using the current CAD system, the dispatchers operating the CC manage approximately 800 calls per day. Of these, approximately 60 result in either police, fire, or operations personnel being dispatched to respond to an event.

Challenges & Deficiencies

The chief challenges and deficiencies with the IT systems supporting the current CC, as discussed below, are related to the lack of convergence of information and the aging of existing technology and systems.

1. Proliferation of Hardware – Most of the systems used by dispatchers in the CC are standalone. This has resulted in a proliferation of hardware at the dispatchers’ desks. There are multiple workstations, each with associated keyboard and mouse devices, as well as up to 12 monitors for certain positions.

2. Older Systems – Much of the technology in the CC is old and needs updating. 3. Position-Specific Configurations – The standalone independent systems also impose a need to

designate specific positions for specific functions. For this reason, the dispatchers are required to rotate to different desks to perform different functions within a shift. That means they need to be trained in all the systems so they can substitute for each other. .If a dispatcher relieves another from a position, even temporarily, they have to physically move to another position that has the systems needed to perform the role.

4. Lack of Integrated Data – Very few systems are integrated with each other. This necessitates the dispatchers having to access several systems independently in order to combine information associated with an event and then reenter that information into a documenting and reporting system.

5. Old and Unsupported Computer Aided Dispatch (CAD) System – The CAD system used by the airport was purchased by the City of Phoenix many years ago. It is no longer supported by the vendor so no enhancements or fixes are available. The dispatchers use the CAD today to document all events and to track the police units assigned to each event. The CAD lacks event management functionality needed to adequately record, respond, and report on events at the airport.

6. No Automated Response Plans – There are no automated Standard Operating Procedures (SOPs), check lists, or other tools for the dispatchers to use. Response Plans are kept in manuals, and dispatchers require extensive training in order to respond to events correctly. They must learn the response procedures for over 50 different event types.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

7. No CAD Access for Field Personnel – Field personnel do not have access to the CAD system. Since the CAD documents event status and history, field operations staff need to call the Command Center in order get current event status and updates. This distracts the dispatchers from properly and effectively responding to the event.

The new CC, in conjunction with the new Event Management System (EMS), will correct these challenges and deficiencies. The new EMS will not only serve as a real-time tool supporting the CC response to events at the airport, but will also become the historical and corporate depository of what happened and how the Airport addressed and reacted to the situation.

Systems Used in the Current CC

There are a multitude of system currently used in the existing CC, with additional ones being available in the new CC. Refer to Attachment H for a description of the currently used systems in the following list.

Computer Aided Dispatch (CAD)




Fire Enterprise Business Integrator (FEBI)

Fire CAD



xPort

Paging


Lightning Detection System (LDS)

Enterprise Workstation


Phone System

Radio System

Local Area Networks - PDS, Fire, Enterprise

Dispatcher Functions

Dispatchers in the current CC are responsible for answering emergency calls, managing the event response, and recording the event history. There are currently 26 budgeted dispatcher positions working across all three shifts. During the day and swing shifts there are usually five (5) dispatchers and one supervisor; although at times a 6th dispatcher is on the schedule. The dispatchers rotate responsibilities throughout the shift. The dispatch functions/positions include:

1. Switchboard




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

2. ACAMS 3. Sky Harbor 4. Patrol 5. Call Taker 6. Supervisor

1. Switchboard Position

The switchboard position system configuration, as shown in Figure 1, is as follows: Upper Level:

1. VSS 2. AirVue (FIDS, Paging, VSS) 3. Analog CCTV

Lower Level:

4. Enterprise workstation 5. CAD 6. CAD 7. Vesta telephone 8. Motorola radio

Figure 1. Switchboard Position System Configuration

Switchboard Position Responsibilities

Handles the airport’s public line x3300, internal line x3302, and courtesy phone answering.

Functions as the backup to answer x3311 airport emergency calls.

Utilizes the Vesta system.

Handles airport paging calls and courtesy phone requests on a separate Aastra phone line.

Functions as the primary paging operator. Passenger paging is done through a queue in the Passenger Information and Paging System (PIPS); however, dispatchers can override it to make emergency announcements or priority pages.

Receives forwarded internal calls, if any these are not answered at the intended destination (Administrative, Badging, Lost and Found, etc.).

Answers all ringdown calls for Goodyear Airport, Deer Valley Airport, Fire Stations 19 and 29, and all checkpoints except D1NT4.

Receives, dispatches, and enters work order into xPort work for facilities personnel when the work order center is not open.

Covers SKYHARBOR radio frequency during IMS situations.

Sends out notifications using the Emergency Notification System (ENS) regarding alerts, breaches, and any other situation that might impact airport operations.

Handles any other duties assigned by a Supervisor.

2. Access Control and Alarm Monitoring System (ACAMS)




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

The ACAMS position systems configuration, as shown in Figure 2, is as follows: Upper Level:

1. VSS 2. VSS 3. ACAMS 4. ACAMS 5. ACAMS

Lower Level:

6. Enterprise workstation 7. CAD 8. CAD 9. Vesta telephone Figure 2. ACAMS Position System Configuration. 10. Motorola radio

ACAMS Position Responsibilities

Monitors airside traffic and communicates with Airside Operations (Oscar 30) to advise them of security related issues.

Dispatches security related calls.

Serves as a back-up to a short-staffed Switchboard position or during high-volume periods.

Deactivates SIDA badges during “after-hours”.

Handles any other duties assigned by a Supervisor.

3. Sky Harbor Position

The Sky Harbor position system configuration, as shown in Figure 3, is as follows: Upper Level:

1. FEBI 2. Analog CCTV 1. Fire CAD read-only monitor 2. Passenger Paging 3. Analog CCTV

Lower Level: 3. Enterprise workstation 4. CAD 5. CAD 6. Vesta telephone Figure 3. Sky Harbor Position System Configuration. 4. Motorola Radio

Sky Harbor Radio Position Responsibilities




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Monitors the Sky Harbor radio talk group.

Functions as the main link for emergency service for field units.

Broadcasts Alerts, Medicals, and Fires.

Actively Monitors the Honeywell Fire Alarm system (FEBI).

Passively Monitors the Fire CAD. Fire is not directly dispatched from the CC; only Fire Alarm Room Operators perform that function. The dispatchers at this position, however, monitor, communicate, and enter the call information into CAD. Without the Fire CAD monitor the CC would not necessarily know when Fire is dispatched unless they were informed.

Functions as the liaison between Operations, Police, and Fire, among others.

Monitors all IMS talk groups and incidents.

Sends out notifications using the ENS regarding alerts, breaches, and any other situation that might impact airport operations.

Receives, dispatches, and enters work orders into xPort when the work order center is closed.

Functions as the backup to answer x3311 airport emergency calls.

Answers ringdowns for aircraft alerts from the FAA Air Traffic Control Tower (ATCT, Tower).

4. Patrol Position

The Patrol position system configuration, as shown in Figure 4, is as follows: Upper Level:

1. Analog CCTV 2. 911-Xtend (read-only 911 monitoring)

Lower Level:

5. CAD 3. CAD

4. CAD

5. Vesta telephone

6. Motorola Radio

Large Monitor:

8. VSS and Lightning Detection Figure 4. Patrol Position System Configuration.

Patrol Position Responsibilities

Monitors the Aviation Police Department radio talk group and provides support to police.

Monitors the PSAP frequency - a common channel for Phoenix Police Department.

Maintains constant awareness of the status of all Aviation Police Officers and updates this information in CAD as it changes.

Prioritizes all emergency and security incidents that occur at the airport.

Logs information received and/or transmitted.

Enters in all incidents into the Police CAD.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Monitors Lightning Detection System and broadcast warning to field units.

5. Call Taker Position

The Call Taker position system configuration, as shown in Figure 5, is as follows: Upper Level:

1. VSS 2. VSS 3. DMS 4. DMS 5. Analog CCTV

Lower Level:

6. Enterprise workstation 7. CAD 6. CAD Figure 5. Call Taker Position System Configuration. 7. Vesta telephone 8. Motorola radio

Call Taker Position Responsibilities

Takes all emergency calls on x3311 entering the Command Center.

Answers incoming elevator emergency calls.

Answers incoming Pedestrian Emergency Duress System (PEDS) calls.

Monitors DMS (Digital Monitoring System), including covert alarms at parking exits, information booths, checkpoints and police offices, Automated External Defibrillator (AED) alarms.

Monitors and surveys all VSS cameras.

Prepares video clips from VSS for dissemination to parties (such as TSA, Police, Risk Management and the Public) upon request.

Sends out notification using the ENS regarding alerts, breaches, and any other situation that might impact airport operations.

6. Supervisor Position

The supervisor position system configuration is comprised of those system the CC considers most relevant from a managerial standpoint.

ATTACHMENT G: SYSTEM DESCRIPTIONS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Description


System provides security controls for access to secure areas on the PHX proper in compliance with Federal security regulations. ACAMS is one component of the Honeywell Enterprise Business Integrator (EBI) system. EBI monitors several sensor types around the airport, including also Fire Alarm and the Digital Monitoring System. ACAMS is currently integrated with the OSP systems. Key security locations with an ACAMS portal also have a video call up when an alarm is triggered. Not all video cameras are accessible from ACAMS, however.

Automatic Vehicle Identification (AVI) System

System used by Ground Transportation to identify vehicles entering the Airport campus.

Dynamics AX Microsoft accounting system used by Parking Operations for accounts receivables.

Baggage Handling Systems / Explosive Detection System (BHS/EDS)

Explosives Detection System for checked baggage. System will be monitored by facilities personnel in the new Command Center.

Computer-Aided Dispatch (CAD)

The dispatchers utilize a legacy PSSI CAD system that was originally procured by the City for the Phoenix Police Department. This system is quite old and is no longer supported by the vendor, which limits the options for future improvements. This system is used by the CC to create records of incidents, calls, and responses. It is also utilized to track police officers assigned to the Airport, as well as fire fighting vehicles. The Phoenix Fire Services has its own CAD system and the Airport CC does not track that personnel. Operations’ staff, including Landside (Oscar 20s) and Airside (Oscar 30s), are not generally tracked in the CAD system. When Operations staff are part of a response, this is noted in the event log in CAD. The dispatchers enter approximately 80 events/day into the CAD.

Crash Phone/ CBC/Ringdowns

Direct lines to the Command Center from the ATCT, Fire Stations and TSA checkpoints. Used to report aircraft alerts, fires and security breaches.


The DMS monitors strategically located Covert Alarms (at checkpoints and parking exits, for example) as well as Automatic External Defibrillator (AED). This system also services other devices, such as escalators, moving walkways, etc. It is also a component of the Honeywell EBI.


This system, provided by NICE, records all telephonic and radio transmissions. The Database can be searched for voice recordings based on time frame desired.

Event Management System (EMS)

The EMS is the management system for all airport centric events. The dispatchers in the command center have primary responsibility for keeping the event log current. The dispatcher




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Description

liaison position in the AEOC will have full EMS read and write permission for updating event data gathered in the AEOC. However, the EMS will be accessible from each position in the AEOC through the enterprise workstation. From the event log AEOC participants may view the current status and the airport resources assigned to respond to the event. Anyone with appropriate permission may view the current event log and add information into the log.


The ENS provides rapid notification to staff during emergencies. The Everbridge system is used for mass notification of employees and tenants. Currently the system only utilizes pagers, phones and emails to send notifications.

FieldPort System developed by PHX to support airside operations with airfield inspections and work order creation.

Fire CAD Computer Aided Dispatch system used by Phoenix Fire Services. The CC dispatchers have read-only access to the Fire CAD.

Fire Enterprise Buildings Integrator (FEBI)

This airport-wide fire alarm system is also a component of the Honeywell EBI. It includes mass evacuation notices interfaced to audio portions of the audible fire alarm paging system. The Fire Alarms are on a separate network from all other systems.


This system provides geospatial reference for system meta-data. The airport uses it to support property management, security, airport facility mapping of the airport, both airside, landside and terminal. All cameras, alarms, locks, gates, airport equipment have been located on the maps. Current GIS is an ESRI system. Aviation plans to use GIS Technology to support land acquisition, property management, security, and airport facilities mapping programs. All alarms, cameras, and other devices have been located on the GIS maps.

Enterprise Buildings Integrator (EBI)

New building monitoring system by Honeywell for Facilities. It integrates the display and monitoring of several facility systems, including the 3 Honeywell EBI Systems (ACAMS, FEBI, and DMS).

Enterprise Workstation

This is the standard City workstation provided to city employees. From such a workstation staff can send emails and access the Internet, as well as several other applications that reside on the Enterprise LAN (such as GIS, ENS, xPort, SAP, SAFE OSP, Aerobahn, AVI, Web EOC, Fieldport, and Remedyforce).

Local Area Network (LAN)

PDS - This is the primary airport LAN providing connectivity for a number of airport application systems. It was recently upgraded to consolidate several disparate LANS into one.

Fire LAN - Fire Alarm switches are on a separate network.

Enterprise LAN - City network that provides City-wide connectivity for email, servers, printers, phones, SAP, and Internet access.




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Description

Lightning Detection System (LDS)

The Vaisala system provides early warning to field units of approaching lightning storms to prevent personal injury to airfield workers. LDS is monitored in the Command Center and lightening warnings are broadcast from the Command Center.


The airport implemented the Quantum Secure SAFE product for the airport badging system. Currently, this system is integrated with ACAMS.

Paging The Airport is utilizing ComNet/SITA’s AirportVoice for audible and visual paging.

Phone System The primary phone interface in the current CC is the Airbus Vesta system which provides a computer screen telephone interface with pre-programmed speed dials. The Vesta system is connected to a Nortel analog PBX which runs the CC calls and is interfaced to the City’s POTS (plain old telephone service). However, this system is currently scheduled for upgrade which would facilitate the removal of the Nortel PBX. There is a ringdown telephone system used for Terminal 4 security breaches. The city is planning an upgrade to its VoIP.

Parking Revenue Control System (PRCS)

System used by Parking Operations to manage finances.

Radio System The radio system is a shared resource for the City and County. However, PHX has its own dedicated radio site. It has recently undergone a conversion to the 700MHz spectrum and simultaneous upgrade of the soft interface to the Motorola MCC7500. There are approximately 800 hand-held units in use.

Remedyforce Helpdesk system hosted by the City for recording and tracking all IT issues.

Skytrain Inter-terminal transportation system. A Skytrain monitoring position will be located in the new Command Center.

TSA systems Proprietary system TSA agents use at the airport. TSA will implement their own software in the new Command Center.


The VSS system provides activity monitoring at Sky Harbor International Airport in secure and public areas, such as the passenger check points and entrances to the airfield. The Command Center visually monitors alarmed events on the VSS system and has the ability to review archived video stored on disc. The current VSS product is Milestone. The system is integrated with the access control system, ACAMS. This system will be accessible from the Emergency Manager position, Scribe position and the Dispatcher Liaison position in the AEOC.

Video Wall A video wall of displays will be installed in the new Command Center and AEOC. The controller shall provide the capability for users to manage video wall displays. The system shall support the display of analog and digital, live and recorded video data




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

System Description

and computer-generated displays such as web pages. At a minimum the following feeds will be available for viewing on the displays: CNN, VSS, GIS, NEXRAD Weather.

WebEOC A cloud-based product owned by the City to keep all involved parties up-to-date on event status. Participants in an event in an AEOC activation commonly use this tool to track events. The benefit of WEB EOC is that organizations outside the airport have access to it. In an emergency that covers a large geographic area and many jurisdictions, everyone can be appraised of the others actions. This is the primary tool used for event status by participants in an AEOC activation.

xPort The Airport uses an in-house developed web services front end to SAP called xPort to create and track work orders for maintenance at the Airport. During normal business hours this process is handled by a dedicated Work Order Center. During times when the Work Order Center is not open (evenings, weekends, and holidays), the CC takes all calls and dispatches work orders in xPort.

ATTACHMENT H: ACRONYMS



Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Acronym Meaning

ACAMS Access Control Monitoring System

AED Automatic External Defibrillator

AEOC Airport Emergency Operations Center

ANI/ALI Automatic Number Identification / Automatic Location Identification

API Application Programming Interface

AS-OPS Airside Operations (radio talk group)

ATC Air Traffic Control

ATCT Air Traffic Control Tower

AVI Automatic Vehicle Identification

AVN Aviation Department

AVPD Aviation Police Department (radio talk group)

BHS Baggage Handling System

CAD Computer Aided Dispatch

CBP Customs and Border Protection

CC Command Center

CONOPS Concept of Operations

COTS Commercial Off-the-Shelf

CRR Cutover Readiness Review

DMS Digital Monitoring System

DVR Digital Voice Recorder

DVT Deer Valley Airport (ICAO designation)

EBI Enterprise Buildings Integrator

EDS Explosive Detection System

EMS Event Management System

ENS Emergency Notification System

EOC Emergency Operations Center

FAA Federal Aviation Authority

FAR Federal Aviation Regulation

FBI Federal Bureau of Investigations

FCC Federal Communications Commission

FD Fire Department

FEBI Fire Enterprise Buildings Integrator

FIDS Flight Information Display System

FIS Federal Inspection Station

FRP Federal Response Plan

FTE Full-time Equivalent Employee

GBPS Gigabytes per Second




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Acronym Meaning

GIS Geographic Information System

GYR Goodyear Airport (ICAO designation)

HA High Availability

HAZMAT Hazardous Materials

ICAO International Civil Aviation Organization

ICD Interface Control Document

ICE Immigration and Customs Enforcement

ICS Incident Command System

IMS Incident Management System

IROPS Irregular Operations

IT Information Technology

LAN Local Area Network

MPLS Multiprotocol Label Switching

MSEL Multi-Select

NIMS National Incident Management System

NTP Notice to Proceed

O-20 Oscar 20

O-30 Oscar 30

O-50 Oscar 50

OSP Operations Security Portal (Badging System)

PD Police Department

PDS Protective Distribution System

PED Pedestrian Emergency Duress

PHX Phoenix Sky Harbor International Airport (ICAO designation)

PIO Public Information Officer

PIPS Passenger Information Paging System

PRCS Parking revenue Control System

PSAP Public Safety Answering Point

PTZ Pan-tilt-zoom

SDD System Design Document

SDK Software Development Kit

SDR System Documentation Review

SHIA Sky Harbor International Airport

SKYHARB Sky Harbor (radio talk group)

SLA Service Level Agreement

SOA Service-Oriented Architecture

SOP Standard Operating Procedure




Phoenix, AZ 85003 Phone: (602) 262-7181


of 221

Acronym Meaning

SRM Site Recovery Manager

SRR System Requirements Review

SSD System Specification Document

ST19 Station 19

ST29 Station 29

TSA Transportation Security Administration

VPN Virtual Private Network

VRF Virtual Routing and Forwarding

VSS Video Surveillance System

WBS Work Breakdown Structure

WOC Work Order Center

city of phoenix procurement division request for proposal ... · solicitation no. rfp 16-085 (ren)...

Documents