dfw aacs - architecture requirements matrix

ATTACHMENT B Solicitation No. 8005426Automated Access Control System Installation and Maintenance Services

Mandatory (M) Will Fully Comply Exception or Clarification Optional

(O) Comments /Explanation Comments /Explanation

Future (F) (Provide and Reference separate attachments, as required)

(Provide and Reference separate attachments, as required)

1 User Groups for the New AACS

1.01

The AACS will be the primary tool for acknowledging and responding to PACS Alarms, as well as managing security events handled by TacComm.

The AACS will also be used by other organizations to manage and monitor the PACS, investigate security activities, record /review card holder violations and research insider threat situations.

M

1.02

The AACS, via the PSIM, will be accessible from any console within TacComm at the IOC, and other workstations located throughout the DFW campus with the appropriate credentials and permissions, allowing for better access to current status and historical data.

M

1.03

TacComm - Will be the 24/7 primary user of AACS to manage and respond to all PACS alarms, employee portals, AOA vehicle gates, TSA checkpoints and exit lanes, and performing video forensics of security events.

M

1.04

CBP – Handles operations for the DFW Federal Inspection Services (FIS) facilities. CBP is responsible for the security of the DFW Customs Security Area (CSA) environment.

CBP staff located in Terminal D (OCC) will use AACS (via the PSIM) during their operating hours, for monitoring and responding to PACS alarms, access attempts, duress alarms, Man Trap conditions, perform investigations of badge holders, access transactions, historical alarm and event logs associated with the FIS analysis.

M

DFW AACS - Architecture Requirements Matrix

Airport Requirement Integrator Response

# Description of Feature Capability

AACS Integrator RFP AACS Architecture Req of 73

Printed on 3/4/2021

Solicitation No. 8005426Automated Access Control System Installation and Maintenance Services








1.05

Access DFW – manages all credentialing and access control provisioning for authorized access to DFW locations.

Access DFW, located in Terminal B, Badge office will use the AACS (via the PSIM) to interface with both (old and new) PACS, and the ACMS (HID SAFE) , support investigations of card holder/ badge use and door transactions; and to perform current and historical, card holder research.

M

1.06

ASD – provides civilian security officers to augment security operations that do not require a formal police response.

ASD, located at DPS HQ, is responsible for ensuring DFW complies with all federal security regulations, and will use AACS (via the PSIM) for investigations of card holders, access transactions, historical alarms and event logs. They will be able to update badge records with known violations and perform video forensics for compliance issues and insider threat analysis.

ASD Staffs AOA Vehicle Gates as well. They will use the AACS (via the PSIM) at AOA gates to research card holder data of card presented at gate.

M

1.07

DPS Police – will use AACS (via the PSIM) to perform criminal investigations that include review of card holder data, historical access control transactions and event logs.

DPS Police, located at DPS HQ, will perform forensic PACS and video reviews, as well as police related efforts associated with insider threat analysis.

M


Printed on 3/4/2021









2 Network Architecture

2.01

There are multiple existing networks at DFW. The DFW Security LAN supports Airport Security, which includes the existing and new PACS systems, The new PSIM, and the Video Management System.

The Criminal Justice Information Services (CJIS) LAN supports the CAD System. The DFW operations network supports the Situational Awareness Platform and DFW business related systems.

M

2.02

Due to the variety of regulatory compliance, and operational policies these networks are physically separate and will remain separate. The current network architectures in place are planned to remain as it is currently deployed throughout the system implementation process. The diagram below depicts all the relevant networks and the associated applications that reside on them.

M

2.03

Due to the integration requirements between AACS and other applications on diverse networks, firewalls exist to provide for secure communications and data transfer between AACS and the other applications. The firewalls allow for granular control of what data can traverse the firewall, which direction the data will travel, and which applications may interact with each other.

M


Printed on 3/4/2021









2.04

System to System communication will facilitate data sharing using a data specific and directional specific model. This is to enable AACS to receive and send incident management and workflow management data as required to support the rules engine functionality and automate the overall workflow.

M

2.05

One integration that needs to occur is between the new AACS and the Situational Awareness System (SAS).

The AACS contains SSI Information, and needs to feed summary security data to the SAS in order to have a holistic of AACS systems Status.

TacComm Operators, shall have the ability to selectively provide non SSI information on Security Events to the SAS to enable the SAS to have insight into events occurring at the airport.

M

2.06

There are other networks which contain systems which need to provide data to the AACS. The separate networks contain all associated network controls to facilitate stand-alone operation. This data flow control will be achieved at the firewall utilizing Access Control Lists (ACL).

M

2.07DFW ITS is responsible for all firewall configurations. AACS contractor must work with DFW ITS to support firewall rules and access control lists.

M

2.08Data must always be protected / encrypted throughout the infrastructure. This includes Data at Rest, Data in Motion, and Data in Use.

M


Printed on 3/4/2021









Figure 1 High Level Architecture Diagram


Printed on 3/4/2021









3 Multiple Server Environments

3.01The new Saab PSIM will be built on the existing Saab SAS Platform which has been implemented in 3 environments.

M

3.02 The new Lenel OnGuard PACS will be implemented in 3 environments. M

3.03 The Production Environment will be fault tolerant, high availability and fully redundant M

3.03.01

Primary Production - The primary production environment shall be one of two operational hosting locations for the PACS applications.

Each will be a hot standby for the other in a virtual machine environment.

M

3.03.02

Secondary Production – The secondary production environment will be a hot standby for the primary system. It will have complete data replication so that if the primary fails, the secondary can take over in near real time. It will be hosted in a second data center geographically diverse from the primary system.

The two production environments may be viewed as a single environment with redundancy/failover capabilities.

M


Printed on 3/4/2021









3.04

Development Environment – It is expected that changes to the new PSIM and new PACS configurations will happen frequently. New device types will be added, new locations will need to be supported, new integrations will be added, new operational procedures will be added, and new functionality may be added. It is important all these changes are developed and controlled in a standalone development environment.

The Development Environment will implement redundant servers in order to be able to test failover and HA capabilities. These redundant servers do not need to be in diverse data centers. Workstations for the Development Environment will be housed in a AACS Development/Test Lab. 3 workstations will be available for development and testing in the Development Lab.

Once completed in the development environment any modifications, fixes, upgrades to either the PSIM and/or the PACS will be thoroughly tested in the Test/Training Environment.

M


Printed on 3/4/2021









3.04

Test/Training Environment – The Test/Training environment will be used to test new functionality, integrations and other software changes. This environment can be used as a pre-production testing environment.

No changes will be made to the production environment until they pass tests in the test environment.

This environment will also serve as the training platform for conducting all training on the AACS. It will be used for training all staff prior to implementation. Following implementation, it will be used for training new staff and recurring training for existing staff when new functionality is added to the AACS.

Workstations for the Test/Training Environment will be housed in a Test/Training Lab. The Test/Training Lab will have 7 AACS workstations available for use in testing and training activities.

M


Printed on 3/4/2021









4 Redundant High Availability Architecture

4.01

Due to AACS being classified as a mission critical system to airport operations, the production environment will be architected for continuity of operations. It will have built in redundancy in hardware, software and communications to enable resiliency, so that if one component fails the backup will take over in near real time

M

4.02

The new AACS and the new PACS application will reside on virtualized servers in the data centers. These redundant data centers are geographically diverse for disaster recovery preparedness.

M

4.03 The AACS must support a 24x7 operation with 99.999% up time. M

4.04

The new OnGuard PACS will be implemented in a virtual environment using Stratus Hypervisor and/or VMware Hypervisor for virtual machines. This environment will be in an environment dedicated to security applications. Contractor may be asked to procure and install all hardware and software. After system acceptance the system will be administered by DFW ITS.

M


Printed on 3/4/2021









4.05

The new Saab PSIM and the new OnGuard PACS must be designed with full redundancy and high availability (HA) and no single point of failure. System must be architected to recover from hardware failure loss without manual intervention and without loss of data or transactions. Servers will be active/active. To support infrastructure protection, access management and system performance, the existing Saab Platform and the new PACS servers will be connected to DFW F5 appliance and load balanced.

M

4.06 The system configuration should provide redundancy for every PSIM and PACS server and associated storage. M

4.07

the new PACS redundant servers shall be physically separated in two diverse DFW data centers and supplied with appropriate emergency (UPS or generator) power and cooling. The existing Saab Platform currently are.

M

4.08

The AACS (PSIM and PACS) shall provide for continuity of operations. This may be accomplished by using mechanisms such as clustering, failover during upgrades, database replication to support this requirement.

M

4.09The AACS ( PSIM and PACS) shall be scalable and allow for the addition of users, devices, sensors and Integrated Systems.

M

4.10

The diagram in Figure 2 below depicts the AACS system hosted in both data centers for redundancy, connectivity to multiple networks and connectivity to system workstations.

M


Printed on 3/4/2021









4.11

The switching transport extends from two primary Data Centers (DC), DC-1 and DC-2. As per DFW ITS Operating Standards, all application servers are housed in the Data Centers, and all key DFW facilities are serviced by redundant and diverse routing from the facility to each of the Data Centers. .

M

4.12

To comply with ITS Operating Standards, the primary and redundant application servers will be in DC-1 and DC-2. It is anticipated that most users will operate using thin-client workstations.

TacComm and CBP users will access shared desktop resources in both DCs via network transit. Each workstation will have a minimum of 2 Ethernet Cat. 6A connections run to it for physical diversity to different network switches.

All other user workstations will connect via a single Cat 6A Ethernet cable.

M

4.13

In the event of the TacComm @ the IOC becoming unavailable, the existing AOC has been designated as a backup location for IOC Operations, using production AACS (PSIM) workstations. TacComm operators will move to the AOC

M

4.13.01AACS (PSIM) workstations in the AOC must be configured to handle the same operations as those in the TacComm.

M

4.13.02AACS workstations in the AOC must be able to be brought online and operational within 15 minutes of the decision to move operations to the AOC.

M


Printed on 3/4/2021










Printed on 3/4/2021









Figure 2 High Level Network Block Diagram


Printed on 3/4/2021









5 AACS Servers and Database

5.01AACS Integrator/contractor shall specify in their proposal the types and quantities of servers required to implement all three PACS environments.

M

5.02DFW will provide space and power in the data centers to house the servers. Contractor may be asked to procure and install all server hardware.

M

5.03Database, Interface and application servers will run on separate virtual machines. CPU, memory, and storage resources shall be protected within VM environment.

M

5.04Servers and storage shall be sized to support 5 years of data and 3 times the estimated storage requirements to support start-up operations.

M

5.05 Servers shall be sized to support at a minimum, and will support 50% growth: M

5.05.01 10,000 incoming alarms/day M5.05.02 3000 Portals M

5.05.03 2000 Multi-Class / Multi-Factor Authentication Card Readers M

5.05.04 60,000 Active Credentials M5.05.05 140,000 Total Badge Holders M5.05.06 150,000 Badge Transactions / Day M5.05.07 1500 events/day M5.05.08 10 events/minute M5.05.09 8,500 devices (cameras) M5.05.10 100 Intercom Stations M5.05.11 Storage for 5 years of event logs. M


Printed on 3/4/2021









5.06 Servers shall be built to support the following technical requirements at a minimum: M

5.06.01 Stratus Hypervisor and/or VMware Hypervisor M

5.06.02 Licensing for Shared Storage or vSAN stretched cluster to support Storage HA functions M

5.06.03Windows 2016 Data Center. VMs should be deployed to meet the system specifications of the PACS manufacturer

M

5.06.04

Licensing for SQL Server 2017 or Oracle 18c should be deployed for the database environment (unless PACS manufacturer requires a different database version of either)

M

5.06.05 25% Spare compute and storage resources should remain available in each physical host M

5.07 Detailed sizing information will be documented during detailed design phase of project. M

5.08 Contractor may be asked to be responsible for procuring and installing all server hardware. M

6 Commercial Off the Shelf (COTS) Software

6.01

Contractor shall specify in their proposal the types and quantities of all COTS software licenses required to implement all three PACS environments. This includes operating systems, data base management systems, VMware, antivirus software, and any other licenses required to implement the PACS system in a secure manor.

M

6.02 Contractor may be asked to be responsible for procuring and installing all COTS software. M

7 Workstations and Printers


Printed on 3/4/2021









7.01 Each AACS operator will be equipped with a desktop configuration provided and installed by DFW ITS. M

7.02

Contractor shall specify in their proposal the types and quantities of all workstation hardware and COTS software requirements necessary to support all users of the AACS in both in the TacComm, backup WS at AOC, CBP at the Terminal D, CBP OCC, and other DFW user locations.

M

7.03Contractor will propose the appropriate desktop configuration based on individual user requirements and functions performed.

M

7.04

The desktop must be suitable for running business critical and geo-spatial applications requiring stability, reliability, strong performance, and application specific features and optimization for things like multiple graphics and video windows; complex data manipulation; and other resource-intensive visualizations.

M

7.05

The desktop will be a high-end, GIS graphics capable workstation/CPU with minimum quad core, solid state drive storage, 16-32 GB RAM, and high memory graphics cards (e.g. 2xNVIDIA Quadro). All desktops will be outfitted with two network interface cards (NICs).

M

7.06Critical desktops will have two network connections to provide redundant network connections fed from different Communication Rooms.

M

7.07 All workstations will be under building generator power and UPS (30 minutes). M

7.08Printer and copier services will be provided by DFW and made available through work group printer/copiers distributed through the TacComm.

M


Printed on 3/4/2021









7.09

DFW ITS will procure and install all workstation hardware and COTS software. PACS contractor will be required to install any additional client software on these workstations needed to support their application.

M

8 Monitors

8.01Contractor shall specify in their proposal the types and quantities of all monitor requirements necessary to support users of the PACS application.

M

8.02

Each TacComm and CBP console position must be capable of displaying:• Active Event Screen• Event Summary Screen• Card Holder Screen• 4 Video Feeds• Alarm summary screen• PACS dashboard, Query and report screen

M

8.03 Other user locations will only require 0-2 video feeds, and 3 of the other screens listed above. M

8.04Contractor shall specify recommended layout for monitors at each user location for most efficient operation.

M

9 Users and Devices

9.01 The AACS will be accessible to authorized organizations/users. M

9.02 The AACS must be sized to support twice the number of users anticipated. M


Printed on 3/4/2021









9.03

User Definitions: 1. Number of Users: Total number of users having access to the AACS on a regular basis whose primary responsibility is managing security events. They may be from multiple organizations and on multiple shifts. 2. Number of Workstations: Total number of workstations that could be connected to the system. 3. Concurrent Users: Total number of users or workstations that will normally use the system simultaneously. 4. Mobile users: Number of users accessing the AACS mobile application from mobile devices such as smart phones, laptops and MDTs. 5. Concurrent Mobile Users: Total number of mobile devices that will normally access the AACS mobile application simultaneously.

M

9.04 The table below depicts estimated quantities of users and workstations required for the AACS. M


Printed on 3/4/2021









Org/Location UsersConcurrent

UsersWorkstations Mobile Users

Concurrent Mobile Users

TacComm 34 10 10 0 0CBP 6 2 2 0 0 ASD 6 2 2 10 2ASD @ AOA Gates 20 8 8 8 2Police 10 2 2 10 2Access DFW 4 2 4 0 0ITS – CS 4 2 2 2 1 Test/Training Facility 10 10 10 4 4Development Facility 3 3 3 1 1Sys Admin 8 3 3 2 1Backup IOC @ AOC Facility 5Other 5 2 2 2 1TOTALS 97 46 53 37 12


Printed on 3/4/2021









10 Systems Integration

10.01The AACS will be integrated with several systems to allow for collection of data, alarm response, and effective management of security events.

M

10.02

The diagram below depicts a conceptual picture of AACS system integration requirements in relation to other systems, and the data flows to and from the respective systems.

M


Printed on 3/4/2021









Figure 3 Systems Integration Concept


Printed on 3/4/2021









10.03 Arrows indicate the direction of data flows and the color indicates the network which the data will flow across. M

10.04 Detailed workflows for PSIM implementation are in the SOW Appendix 1 M

10.05The systems that the contractor must integrate with AACS are documented in the SOW, A summary chart is provided in the SOW appendix 2

M

10.06Detailed interface definitions will be defined and formalized by the contractor during Requirements Validation and Design phases.

M

11 Integration Methodologies

11.01

Integration of AACS with other Airport systems will be through open architecture protocols and standard interfaces. AACS Integrator /contractor will use a set of technology services to provide an integration path for all technology solutions at the Airport in alignment with enterprise architecture principles, information exchange, messaging, information management and service delivery.

M

11.02

Interface technologies may include:• pre-integrated Gateways (e.g. NICE; Everbridge; Infor);• open API tools (e. g Lenel OnGuard)• adaptors• XML based messaging• and software developer kits (SDKs).

M

11.03Standard design process and deliverables for interfaces including the development of formal Interface Control Documents (I CDs) for each interface will be required.

M


Printed on 3/4/2021









11.04

If the Provider has an existing (certified and supported) interface or adaptor to a system (e.g. NiceVision connector) it will be considered for use to accomplish a systems integration.

M

11.05

All data and services available within the AACS Platform shall be available to DFW authorized and Roles based authenticated consumers using web-based API’s. These API’s shall include the following features and functions –

M

11.05.01Provide for information security functions for Airport API’s with API key verification and network access control parameters.

M

11.05.02API discovery portal, which enables third parties to search, discover, explore and test APIs available from the Airport.

M

11.05.03Provide a development framework for API’s at the Airport, making API development internal to the Airport easier and more consistent.

M

11.05.04Monitor API connections to internal systems and track data transferred, and resources consumed within internal systems.

M

11.05.05 Track, monitor, and report on API usage from external or internal calls. M

11.05.06Support multi-tenancy platform, enabling connections from cloud to on premise, and on premise to on premise for internal and external systems.

M

11.05.07 The AACS must provide, and shall support tools which allow for encryption of data at rest and data in motion. M

11.05.08 The AACS shall enforce a role-based policy for network access and authorization to data services and APIs. M


Printed on 3/4/2021









11.05.09 The AACS’ s API will support inbound and outbound actions. M

11.05.10Configuration of a new device shall not require a product release of software. Configuration shall be done via a user interface or database application configuration.

M

12 Implementation/Migration Strategy

12.01

In order to help ensure a smooth implementation of the new AACS, including the new PSIM and new PACS with minimal risk, the system will be implemented in (pre planned) phases as detailed in the SOW

M


Printed on 3/4/2021










Printed on 3/4/2021


video

Mandatory (M) Will Fully Comply Exception or Clarification

Optional (O) Comments /Explanation Comments /Explanation Future (F) (Provide and Reference separate attachments as required) (Provide and Reference separate attachments as required)

13 General AACS Functionality

13.01The AACS, via the PSIM, must have the ability to manually or automatically create an event with the occurrence of pre-defined events.

M

13.02

The AACS / PSIM workstation display area(s) shall be configurable. Operator shall be able to set the number of fields displayed at one time, the size and arrangement of the fields in the total display area.

M

13.03 The AACS/PSIM will support saving layouts for future use on a per user basis. M

13.04

The AACS, via the PSIM shall assign all new events to a AACS operator: this operator, based on the Alarm Monitoring assigned Role, will be the events owner and will be responsible for acknowledging and resolving the event.

M

13.05The Alarm Monitoring assigned operator Role of the AACS must have the ability to create, display, update and close an event.

M

13.06 The AACS must be able to message/email others from any AACS screen. M

13.06.01 AACS must be able to define multiple message templates. M

13.07

The AACS, via the PSIM, must have the ability to filter and correlate events based on: a. Time of occurrence b. Location c. Type of event d. Pre –existing Conditions.

M

13.08

The AACS must 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.

M

13.09AACS, via the PSIM must have capability to automatically escalate an event due to a lack of response

M

DFW AACS - System Functionality Requirements Matrix


# Description

AACS Integrator RFP System Functionality Req, of 73

Printed On 3/4/2021


video





# Description

13.10The AACS must have the ability to display entire chronological history of an event with audit trail of all entries with time stamp and user id.

M

13.11 The AACS must provide easy navigation to access maps, video files and forms associated with an event. M

13.12

The AACS, via the PSIM, will support forms to be completed associated with an event. Completed forms will be stored with the event log and accessible for viewing.

M

13.13The AACS will have a common event summary/dashboard page which is configurable by system administrators.

M

13.14

The AACS, via the PSIM, will facilitate authorized users to obtain video camera selection from the video management system, intercom calls, card holder record data for review and edit, BVS alarm and record holder data for review and edit, real time LPR and/or Toll Tag data aqusition from respective systems, data agregation, PACS alarm monitoring, configuration, and reporting, as well as incident response, event notifications,

M

13.15 The AACS must have the ability to support multiple monitors at a single position as a single logical monitor. M

13.16 The AACS must have the ability to interface to specified systems. M

13.17

The AACS must be accessible from any workstation given network access restrictions, user credentials/roles, and permissions. Other DFW applications must be accessible from the same workstation.

M

13.18 The AACS must have the ability to receive signal/data/message from other systems M


Printed On 3/4/2021


video





# Description

13.19

The AACS must have the ability to generate standard and customized reports. It must support reports on any data element relative to other data element over different dates and times. Historical reporting shall include data from the PACS, BVS, the PCS, and the ACMS.

Special attention shall be made to provide access to Lenel OnGuard available reports. The AACS via the PSIM shall make these reports available to authorized users.

M

13.20

Queries and reporting functions must not disrupt the operational system. Any data more than 30 days old will be moved to a separate data store for query and reporting capabilities.

M

13.21 AACS must have enough storage capacity to support a minimum of seven years of event logs. M

13.22 The AACS must have the ability to export event data or search results into various file formats (e.g. CSV, PDF). M

13.23 The AACS must have the ability to export event select data to other systems (e.g. SAS, CAD). M

13.24The AACS must have the ability to customize user interfaces and user functions to match required Response Plans.

M

13.25

The AACS must have a note pad function to record notes not associated with an alarm or event. The note pad inputs must be viewable by all similar role based AACS operators, and the system admin.

M

13.26AACS must be able to copy an image from the active or playback video and send image/clip to predefined list of authorized recipients

M

14

14.01 General Event Management Requirements

14.01.01The AACS, via the PSIM Alarm Management Role will support the creation, management and tracking of security events occurring at the airport.

M

AACS Event Management Requirements


Printed On 3/4/2021


video





# Description

14.01.02Once created events will be assigned to an individual responsible for responding to and resolving the event.

M

14.01.03 Events will be displayed in multiple formats for the AACS operator convenience. M

14.01.04

The AACS will provide continuous alarm/event logging and recording and an audit log that allows for post-event after-action forensic review detailing the event situation and the action taken.

M

14.02 Event Creation/Update/Closing Requirements

14.02.01 The AACS, via the PSIM Alarm Management Role shall permit event creation in either of two ways: M

14.02.01.01 Manually, by operator with the appropriate permissions M

14.02.01.02 Automatically, by the PSIM based on pre-defined triggers or conditions. M

14.02.02

The AACS, via the PSIM Alarm Management Role must have the ability to create an event by entering just the event type. This creation of an event generates a drop-down list or Response Plan for recommended response.

M

14.02.03

The AACS, via the PSIM Alarm Management Role must have the ability to classify the event type using definable event type codes. The AACS must support up to 200 different event types. Operator must be able to view a list of event types and priorities to choose from.

M

14.02.04The AACS, via the PSIM Alarm Management Role shall allow creation of new event with/without a geographical location.

M

14.02.05The AACS, via the PSIM Alarm Management Role, must automatically assign a unique number to each event created.

M

14.02.06The AACS, via the PSIM Alarm Management Role must have the ability to record one or more caller names and locations to an event record.

M


Printed On 3/4/2021


video





# Description

14.02.07 The AACS, via the PSIM Alarm Management Role shall allow setting and changing event location. M

14.02.08The AACS, via the AACS Alarm Management Role shall be able to assign a location of an event by pointing and clicking on a map.

M

14.02.09

The AACS, via the AACS Alarm Management Role shall allow the user to set the type, priority, description, time, response procedure of the manually created event.

M

14.02.10The AACS, via the AACS Alarm Management Role must have the ability to automatically assign a priority based upon pre-defined event priorities.

M

14.02.11The AACS, via the PSIM Alarm Management Role must have the ability to override pre-defined event priority.

M

14.02.12

The AACS, via the PSIM Alarm Management Roles hall allow editing the event type, priority and description. Upon editing event priority, operator that is managing the event should get visual notification that the priority was changed.

M

14.02.13

The AACS, via the PSIM Alarm Management Role 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).

M

14.02.14

The AACS, via the PSIM Alarm Management Role must have ability to enter/edit caller information manually including caller name, address, and telephone number.

M

14.02.15The AACS, via the PSIM Alarm Management Role shall allow attaching map, video snapshots and video and audio links to the event log.

M

14.02.16

The AACS, via the PSIM Alarm Management Role shall allow adding comments to the event. Each comment shall be logged with the operator user id and time stamp.

M


Printed On 3/4/2021


video





# Description

14.02.17 Once time stamped, data entered into a log cannot be changed. Data can be appended. M

14.02.18The AACS, via the PSIM Alarm Management Role shall allow operator to execute the event response plan.

M

14.02.19The AACS, via the PSIM Alarm Management Role shall log all response plan tasks executed by the operator.

M

14.02.20

The AACS, via the PSIM Alarm Management Role shall update the event record on all operator workstations for any activity associated with the event ensuring a consistent common operational view of the event status.

M

14.02.21Alarm Management Role Operators must be able to forward an event to another operator for action but be able to continue to add information into event.

M

14.02.22The AACS, via the PSIM Alarm Management Role must have the ability to record the source data of the call, i.e., radio, phone, wireless, intercom, etc.

M

14.02.23The AACS must have the ability to store chronological history of all entries and edits to the alarm and event record.

M

14.02.24The AACS must have the ability to update event and alarm records automatically when status changes.

M

14.02.25 Alarm Management Role operators must have the ability to close an event. M

14.02.26

The AACS, via the PSIM Alarm Management Role shall allow the operator to add an event summary and to include associated video and audio links and snapshots before or after closing an event.

M

14.02.27

Any closed event may be reopened by an Alarm Management Role Operator, and additional information added to the event, but previous information cannot be changed. When reopened it becomes an active event again and should be shown on active event screen

M


Printed On 3/4/2021


video





# Description

14.02.28

The AACS, via the PSIM must not allow an event to be closed unless response plan procedures are complete, or this safeguard is overridden by an Alarm Management Role operator. If overridden by operator this must be recorded in the event log.

M

14.02.29 Alarm Management Role Operators must be able to add data to a closed event without reopening the event and making it an active event.

M

14.03 Active Alarm /Event Display Requirements

14.03.01 The AACS shall display all active alarms/events in a unified list and on a map. M

14.03.02 When closed, an alarm/event must be removed from the active alarm/event list and map. M

14.03.03The active alarm/events list must be sortable on predefined criteria (e.g. priority, longevity, type, location, operator).

M

14.03.04

Upon clicking on an event in the active events list the AACS via the PSIM will display the alarm/event details. Details should include, (but not limited to): a. Date and time the alarm/event occurred b. Type of alarm/event c. Location and source of the alarm/event d. Priority of the alarm/event e. Operator/group assigned to resolve the event f. relevant response plan and status g. logged activities performed on the alarm/event, h. attachments (video, audio, forms) I. source alarm/device j. Nearest two (2) cameras.

M

14.03.05Active alarm/events shall be color coded to allow any operator to quickly distinguish between the different event types and priorities.

M


Printed On 3/4/2021


video





# Description

14.03.06

The AACS, via the PSIM, shall include full map capabilities in the context of the alarm/event where authorized operators can select map, layers, interact with on-map items, etc.

M

14.03.07The AACS, via the PSIM shall allow zooming in on the alarm/event location on a map. The selected event icon should be highlighted.

M

14.03.08

The AACS, via the PSIM, shall allow viewing recorded video from the time of the alarm/event. The AACS should deduce the relevant camera based on the alarmed device or event location.

M

14.03.09 The AACS, via the PSIM, shall enable opening all event related video (live and recorded). M

14.03.10

The AACS. via the PSIM, shall allow viewing details of alarms associated with an event. Details should include source device and its related devices, alarm meta data, alarm attached images.

M

14.03.11The AACS. via the PSIM, shall allow zooming in on the attached alarms map location and playback of alarm related video.

M

14.03.12The AACS. via the PSIM, must have the ability to display a current list of last 10 access control transactions associated with a specific door.

M

14.04 Alarm/ Event Assignment Requirements

14.04.01

Every AACS alarm /event shall have a life cycle consisting of the following stages: a. New b. Assigned c. In Process d. Closed

M

14.04.02

When an alarm/ event is first created, it shall be given a state of New. When an Alarm Response Role operator acknowledges the event, the event shall be considered Assigned, and then In Process.

M


Printed On 3/4/2021


video





# Description

14.04.03

The AACS shall assign all new events to the Alarm Response Role based AACS operator that acknowledges the event. This operator will be the event’s owner and will be responsible for resolving the event.

M

14.04.04AACS Alarm Response Role operators must have the ability to transfer an event to another Alarm Response Role operator.

M

14.04.05

The AACS must notify the Alarm Response Role operators of new alarms/events transferred to them. The AACS shall visually notify operators upon receiving new events.

M

14.04.06 Alarm Response Role Operators must acknowledge alarm/events transferred to them. M

14.04.07 The AACS shall assign an event to the user that creates the event. M

14.04.08 The AACS shall log and display the time and the username of the operator that accepted the event. M

14.04.09The AACS shall allow only the owning operator to close the event unless overridden by an operator. If overridden, this will be captured in the event log.

M

14.05 Operational Workflow Requirements

14.05.01

The workflows, response plans, and standard operating procedures (SOP) to be implemented in the TacComm and CBP are contained in the SOW Appendix 1. The contractor will be responsible for implementing these in the AACS.

M

14.05.02 The AACS must be able to automatically create an event when triggering rules have been met. M

14.05.03

For Alarm Response type Events, the AACS, via the PSIM, must automatically provide Response Plans to operator when an event is created, and event type entered.

M


Printed On 3/4/2021


video





# Description

14.05.04The AACS. via the PSIM, shall allow Alarm Response Role operators to execute an Alarm Response based event response plan.

M

14.05.05 The AACS. via the PSIM, shall allow an operator to multitask between events. M

14.05.06 The AACS. via the PSIM, shall log all response plan tasks executed by the operator. M

14.05.07 The AACS. via the PSIM, shall present response plan execution overall progress to the operator. M

14.05.08

Response Plan actions can branch to other Response Plan action plans (e.g. suspicious bag action plan can branch to explosive device action plan if warranted) but maintain a link to the original/parent event.

M

14.05.09

Response Plans can change based on new information entered about an event (e.g. 1st responder confirms injuries, response plan changes to include “call EMS”).

M

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

M

14.05.11The AACS. via the PSIM, shall support both manual selection and automatic selection (based on event that triggered the event) of command recipient.

M

14.05.12 The AACS. via the PSIM, shall automatically set the priority that will be associated with the event type. M

14.05.13

The AACS shall allow operator to easily change the Response Plan procedures in real time when the current situation demands such changes. The changes will be recorded in the event log.

M

14.05.14The AACS must implement an alert notification if Response Plans are not carried out in a configurable time frame.

M


Printed On 3/4/2021


video





# Description

14.05.15

Multiple Alarm Response Role operators must 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.

M

14.05.16Events will be assigned to a single Alarm Response role operator that acknowledges an alarm or creates an event.

M

14.05.17 Tasks within an event response plan must be able to be assigned/distributed to a specific operator. M

14.05.18

Alarm Response Role based Operators must be able to perform the following actions regarding tasks: a. Task Assignment acknowledgement b. Update status c. Complete task d. Cancel task e. Transfer task f. Mark as in progress

M

14.05.19 Completed tasks should disappear from user’s task list or be shown as completed. M

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

M

14.05.21

The AACS. via the PSIM, must alert Alarm Response Role operator every time a new event requiring dispatch is created (based on SOP). Alert remains until acknowledged by operator.

M

14.05.22 The AACS. via the PSIM, must alert operator when tasks timeout, or status changes M

14.05.23The AACS. via the PSIM, must support a timeout feature for events and response time with user definable interval timers.

M


Printed On 3/4/2021


video





# Description

14.05.24All notifications sent when a response or event times out must be automatically written to event and resource logs.

M

14.06 Send AACS Alarm/ Event Data to SAS

14.06.01

For every alarm/event processed by the AACS, via the PSIM, the Alarm Response Role or Alarm Management Role based operator must have the ability to send status information about the Alarm/Event to the IOC's Situational Awareness System in order to notify the IOC of a security event.

Status information shall not contain any SSI or PII data. Timing of the message is at the discretion of the Alarm Response or Management Role based operator.

M

14.06.02

When managing any event, the Alarm Response and/or Management Role based operator must at any time be able to send one of the following messages to the SAS: a. Alarm/ Event notification data b. Alarm/Event status updates regarding the security alarm/event

M

14.06.04 Send Event Notification Data M

14.06.04.01

After creating an event in AACS via the PSIM, at any time a Alarm Response or Alarm Management Role based operator feels it is appropriate, without hindering response to the event, the operator must have ability to send event data to the SAS.

M


Printed On 3/4/2021


video





# Description

14.06.04.02

Message must contain the following: a. Unique AACS Event Identifier b. Event Type c. Priority d. Location e. Type of Alarm f. Time Stamp of Event g. Textual Description of Event

M

14.06.05 Send Event Updates Regarding a Security Event M

14.06.05.01

As an event progresses and the response to event is carried out, a Alarm Response or Alarm Management Role based operator at any time the operator feels appropriate without hindering response to the event, must have ability to send event update/status data to SAS.

M

14.06.05.02

The message must contain the following a. Unique AACS Event Identifier b. Event Type c. Event Status I. Event in progress ii. Officer/Guard Enroute iii. Officer/Guard Arrived iv. Event closed d. Textual description of event status (optional) e. Time Stamp of Status Update

M

14.07 Send CAD Event Data to AACS


Printed On 3/4/2021


video





# Description

14.07.01

CAD operators will need to keep AACS Alarm Response operators informed of CAD events.

CAD operator may have created an event independently or may have created an event having received a message from AACS via the PSIM asking for dispatch support for a AACS event.

For every event processed in the CAD, the CAD operator must have the ability send a message to the AACS, via the PSIM, to notify the PSIM of a CAD event and its status.

This action is always at the discretion of the CAD operator. No message will contain any CJIS, SSI, or PII data. Timing of the message is also at the discretion of the CAD operator.

M

14.07.02

When managing any event, the CAD operator must at any time be able to send one of the following messages to the AACS, via the PSIM: a. Event notification data b. Event updates regarding a security event

M

14.07.03 Send CAD Event Notification Data to AACS M

14.07.03.01

After creating an event in CAD, at any time the operator feels appropriate without hindering response to the event, the CAD operator will send event data to AACS operator by means of email, Everbridge message or phone.

M


Printed On 3/4/2021


video





# Description

14.07.03.02

Message must contain the following: a. Unique CAD Event Identifier b. Event Type c. Priority d. Location e. Point Descriptor f. Type of Alarm g. Time Stamp of Event h. Textual Description of Event

M

14.07.04 Send CAD Event Updates Regarding a Security Event to AACS M

14.07.04.01

As an event progresses and the response to event is carried out, CAD operator at any time the operator feels appropriate without hindering response to the event, must have ability to send event status message data to the AACS.

M

14.07.04.02

The message must contain the following a. Unique CAD Event Identifier b. Event Type c. Event Status I. Event in progress ii. Officer/Guard Enroute iii. Officer/Guard Arrived iv. Event closed d. Textual description of event status (optional) e. Time Stamp of Status Update

M

14.07.05

Upon receipt of message from CAD, AACS will create event in AACS. AACS must assign a unique identifier and link the CAD unique identifier to the AACS event.

M

17.07.06

AACS operator may conduct video camera analysis for the CAD event and return video description and/or snapshot to CAD operator. This will be recorded in the AACS event as well.

M

14.08 Send AACS event data to CAD


Printed On 3/4/2021


video





# Description

14.08.01

An AACS event may require dispatch. In this circumstance an Alarm Response or Alarm Management Role based operator must be able to send an AACS event notice to the CAD regarding the event. The message must contain the following: a. Unique AACS event identifier b. Event Type c. Textual description of event d. Time stamp

M

14.08.02

As a result of AACS event message, CAD operator will create an event in CAD and perform dispatch. CAD operator will send CAD event data to the AACS, via the PSIM which will receive CAD data and update AACS event. AACS must be able to link CAD event and AACS event

M

14.08.03The AACS must be able to send AACS event updates to CAD with the unique CAD event identifier associated with the AACS event.

M

15 AACS Query and Report Requirements

15.01 Standard and Customized Reports

15.01.01

So as to have efficient operating performance the PSIM portion of the AACS must have two data stores. One for operational data and one for historical data. Running historical reports and queries will not impact performance of operational data store

M

15.01.01.01Operational data store will contain data for up to 15 days. After 15 days data will be moved to historical data store

M

15.01.01.02 Historical data store will contain 5 years of AACS data M


Printed On 3/4/2021


video





# Description

15.01.02

The AACS, via the PSIM, 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.

M

15.01.03

The AACS data will reside in two locations, an active database and a historic database. The active database will have 15 days of current event activity. The historic database will contain 5 years of event history.

M

15.01.04

The AACS. Via the PSIM must be able to run reports on data available in interfacing systems (e.g. run a badge history report from data in PACS, BVS, and ACMS).

M

15.01.05

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 an attached printer, and to save the reports in all the following formats: a. XML b. CSV (comma delimited) c. PDF d. MHTML e. Excel f. TIFF g. Word

M

15.01.06 The reporting function shall include the following types of reports: M

15.01.06.01Event summary – summary report of all events – selectable by date/time range, geographic area, coverage area, event type;

M


Printed On 3/4/2021


video





# Description

15.01.06.02

Event detail – detail report of one or more events with attachments, chronological activity timeline and the main event lifecycle information – selectable by 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

M

15.01.06.03

Event List Report – crosstab report showing event counts by event type, time of day, and day of week – selectable by date/time range, geographic area, coverage area, organization, event type;

M

15.01.06.04

End-of-shift – summary report showing all events worked or in progress for a specific timeframe – selectable by date/time range, geographic area, coverage area, organization, event type;

M

15.01.06.05

Operator activity – summary report showing events on which AACS Alarm Role Based operators worked – selectable by date/time range, user ID;

M

15.01.06.06 Users – summary report of registered users in the AACS system; M

15.01.06.07 Code List – summary report of codes – selectable by code type; M

15.01.06.08Alarm Report – summary report showing history of alarms selectable by date/time range, alarm ID, alarm type;

M

15.01.06.09Devices Report - summary report showing history of devices - selectable by date/time range, device ID;

M

15.01.06.10 Card Holder Report – detailed history of card holder and card usage M


Printed On 3/4/2021


video





# Description

15.01.06.11 Call statistics M

15.01.06.12 Top event locations. M

15.01.06.13

Operator Performance Reports/Quality Assurance Program Reports – reports of individual operator activities on the system, all events they managed in a specified time frame, the actions taken and the time to resolve each event

M

15.01.07

AACS, via the PSIM, must be capable of running reports on demand or automatic report generation based or predefined parameters. This shall include the ability to use pre-configured Lenel OnGuard Reports.

M

15.01.08 Report access will be based on operator permissions to access the report data. M

15.01.09 The AACS, via the PSIM will have the ability to maintain distribution lists for standard reports. M

15.01.10The AACS, via the PSIM, will have the ability to generate and send reports as part of event Response Plan.

M

15.01.11 The AACS, via the PSIM, will have the ability to define report parameters by date/time range. M

15.01.12 The AACS, via the PSIM, will have the ability to view output before printing. M

15.01.13

The existing Picture Perfect PACS does not store more than 3 months of event data. CARMA a Lenel/GE product is used to generate historical reports of PACS event data off loaded from the PP PACS system. The AACS Integrator/ Contractor must migrate historical PACS records from CARMA into the new Lenel OnGuard PACS database in order to be able to support historical queries and reporting of AACS events

M

15.02 Search Capabilities


Printed On 3/4/2021


video





# Description

15.02.01The AACS, via the PSIM, will support Ad hoc query and reporting capability with the ability to build and save queries and reports for future use.

M

15.02.02The system shall provide search capabilities on all events, physical access points, alarms, LPR and/or Toll tag data, and card holders.

M

15.02.03The system shall provide event record search capability based on event number, type, description, time and severity.

M

15.02.04The system shall display event records search results in a tabular structure that supports sorting within results.

M

15.02.05 The system shall allow viewing selected events details. M

15.02.06 Based on the event type, the system shall provide type specific fields as search parameters. M

15.02.07 The system shall allow attaching of an event record to an active event. M

15.02.08The system shall allow searching based on overrides implemented by operators (e.g. operator overrides SOP procedures)

M

15.02.09 The system shall allow exporting the events search results into a tabular file format (e.g. CSV). M

15.03 Executive Dashboard Requirements


Printed On 3/4/2021


video





# Description

15.03.01

The system shall provide users with dashboards that indicate the overall status and health of all connected airport security systems.

Multiple dashboards must be configurable based on varying organizational requirements. A dashboard for each primary user group will be created during the design phase (e.g. one for Access DFW, one for TacComm, one for DPS Police, etc.).

Dashboards will display current event metrics such as Active Critical Events, Open alarms, Operational Statistics.

The AACS, via the PSIM, shall support updating the SAS with a dashboard that displays current Security System Status, including total number of door forced, door held open and card holder alarms.

M

15.03.02

Select DPS management shall have access to a dashboard which includes performance data related to alarm handling and alarm response time, number of active alarms, average event response time, active event resolution time.

M

15.03.03The dashboards should include counts and graphs displaying number of alarms and events and by severity and by type distribution graphs.

M

15.03.04

The dashboards should include a map for laying out the information geographically. System Administrator should be able to set the map and its extent.

M

15.03.05 The system shall allow administrators to customize the dashboard data configuration and layout. M


Printed On 3/4/2021


video





# Description

16 AACS Interface Requirements with Other Systems

16.01 Physical Access Control System (PACS) Interface Requirements

16.01.01

The existing physical access control system is Picture Perfect, maintained by Siemens. The new PSIM, as part of the new AACS will need to be integrated with Picture Perfect

M

16.01.02DFW has selected Lenel OnGuard as its new PACS. The new PSIM, as part of the new AACS will need to be integrated with OnGuard.

M

16.01.03

The new Lenel OnGuard will be implemented and transitioned over a period of time. The new PSIM will need to support this transition and maintain an interface with both Access Control Systems until the existing Picture-Perfect system is taken out of service at the end of the transition period.

M

16.01.04

As part of the PACS Transition Process, DFW will be renaming all of the PACS doors with a uniform naming convention. The AACS, via the new PSIM, must provide correlation between the existing and new door naming schema, such that historical data requests by the new door number will provide all associated historical data associated with the specific portal.

M

16.01.05 The AACS must maintain historical records from both existing and new PACS for a period of 5 years M


Printed On 3/4/2021


video





# Description

16.01.06

AACS, via the PSIM, shall be able to show six screens associated with PACS: a. Access Points Summary Screen b. Alarm Summary Screen c. Card Holder Screen d. Video Display Screen e. PACS Active Events Screen f. GIS Map Screen

M

16.01.07

The PACS access point Summary screen shall display every access attempt. The screen will continuously scroll as each access attempt is recorded. The following data should be displayed: a. Date/time b. Door/Device ID c. Point Descriptor d. Condition (granted, change, comms.) e. Badge Number f. Access result (granted, denied) g. Card Holder Name with Photo

M

16.01.08

PACS Alarm Summary Screen shall display every alarm condition that occurs. The following data will be displayed (subject to data availability from integrated system): a. Date/Time b. Location c. Point Descriptor d. Alarm Type (Forced, too long, inactive, etc.) e. Card Holder Badge Number f. Card Holder Name g. Camera associated

M

16.01.09 All new alarms shall alert the operator with a visual and audio alert. M

16.01.10 All alarms shall be acknowledged by the operator. M

16.01.11 The AACS will be capable of creating an event automatically if pre-defined conditions are met. M


Printed On 3/4/2021


video





# Description

16.01.12

Card Holder Screen will automatically display when alarm occurs, and access is denied. The data comes from the integration with Safe system. The following data shall be displayed: a. Cardholders Name b. Cardholder date of birth c. Picture of cardholder d. Company and job title of cardholder e. Cardholder Status (active, inactive, expired, not authorized)

M

16.01.13The AACS, via the PSIM, shall support an automatic association between access events and card holders who triggered them.

M

16.01.14Additional details regarding the cardholder shall be readily accessible from card holder screen, via the ACMS Integration

M

16.01.15

Video Display Screen will automatically display live video of camera associated with a forced door alarm or door held open alarm.

Operator shall be able to view video live or prerecorded from any camera selected.

Live and loops of both sides of the door, breach direction views, center map to alarmed icon and audio must be available.

M

16.01.16

The AACS, via the PSIM' s Active Events Screen will display a list of all active Access Control events. Operator will be able to create new events or work active events from this screen.

M

16.01.17 The AACS shall show PACS device icons on the GIS map. M

16.01.18

GIS Map Screen will automatically display a map of the surrounding area associated with an alarm event. All map functions will be available from this screen.

M


Printed On 3/4/2021


video





# Description

16.01.19 From the Alarm Summary screen, the operator shall be able to lock and unlock doors and recycle gates. M

16.01.20 Details of any alarm shall be accessible by clicking on the alarm. M

16.01.21

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.

M

16.01.22The AACS, via the PSIM shall ensure video associated with forced and held open alarms is recorded and links stored in the alarm record.

M

16.01.23The AACS, via the PSIM shall have ability to generate user defined Access Control reports from the AACS screen.

M

16.01.24

AACS, via the PSIM shall display alarm details upon alarm selection. Details should include source device and its related device, alarm metadata, and alarm attached images.

M

16.01.25AACS, via the PSIM shall display the alarm record, its details, its location and related video in a single screen if desired.

M

16.01.26AACS, via the PSIM, shall display the alarms on a timeline and allow jumping to the video for the time an alarm occurred.

M

16.02 Access Control Management System (ACMS) Interface Requirements

16.02.01

The current ACMS is the SAFE Identity Management System by HID (Formally Quantum Secure)

The existing PP PACS has limited integration with the ACMS.

The New Lenel OnGuard PACS shall be integrated with this system.

M


Printed On 3/4/2021


video





# Description

16.02.02 Authorized AACS users shall have access to cardholder data from the PSIM. M

16.02.03

The AACS shall be able to obtain a complete record associated with the cardholder and the cardholder’s access transaction history. The following data shall be accessible: a. Cardholders Name b. Cardholder date of birth c. Cardholder full address d. Picture of cardholder e. Company and job title of cardholder f. Cardholder Status (active, inactive, expired) g. Cardholder violations h. Access transactions

M

16.02.04Authorized users shall be able to query all cardholders in the system, their access privileges, photos and card information.

M

16.02.05The AACS, via the PSIM, shall automatically display cardholder information when access control alarms are triggered by cardholder.

M

16.02.06The operator shall be able to query cardholder history given badge number date and time parameters.

M

16.02.07 The AACS, via the PSIM shall be able to attach ACMS data to the event log M

16.02.08The operator shall be able to query cardholder information and run historical reports from a PSIM screen.

M

17 Interface Requirements to other Systems

17.01 SAS Interface Requirements

17.01.01For SAS to have a holistic view of activities at the airport, AACS will upload selected (non SSI/CJIS) security event data to SAS.

M


Printed On 3/4/2021


video





# Description

17.01.02

When an alarm or emergency event notification is received in TacComm, it causes an event to be created in the AACS, via the PSIM.

The Alarm Response or Alarm Management Role based AACS operator shall be able to upload event data to the SAS.

Upload to SAS will be automatic for predefined event types.

M

17.01.03

The Alarm Response or Alarm Management Role based AACS operator must be able to upload event data to provide situational awareness of events being managed by the AACS in SAS. The SAS shall be able to display a list of active security events. AACS event data will include at a minimum: a. Event Type b. Event Priority c. Event Location d. Event Status e. Event Operator f. Any other data in the log (except for SSI and PII data) will also be uploaded at discretion of AACS operator, to include attached video and audio records, actions taken, operator notes, etc.

M

17.01.04For any AACS event uploaded to SAS, AACS will automatically send AACS event updates to SAS when they are entered into AACS.

M

17.01.05

After event resolution within AACS, AACS must be able to upload pertinent event log data to SAS. This allows SAS to maintain comprehensive historical data regarding all events at the airport.

M

17.03 Mobile Device Interface Requirements

17.03.01The AACS will provide for a mobile device application to support alarm and event management operations.

M


Printed On 3/4/2021


video





# Description

17.03.02

Mobile Devices include the following: a. Smart phones b. Laptops c. Tablets d. Mobile device terminals

M

17.03.03

Responding resources will have the ability to update their statuses: a. Acknowledge b. Enroute c. Arrive d. Clear e. Available f. Out of service g. Emergency

M

17.03.04 Responding resources will be able to create, edit, add comments/update an event log. M

17.03.05 Responding resources will be able to query events in the AACS data base. M

17.03.06

Responding resources will be able to support messaging between devices and groups (user definable), and announcement capability to the entire mobile active resources on duty.

M

17.03.07Responding resources will have ability to save and search messages with attachments (video, photos) from the device

M

17.03.08 Responding resources will be able to acknowledge a notification it receives from the system M

17.03.09 Responding resources will have ability to show static map as well as real time map display. M

17.03.10 Responding resources will receive action item as part of response plan from AACS or operator M


Printed On 3/4/2021


video





# Description

17.03.11

Mobiles will support a mapping application to: a. Show directions from current location to event location, dependent upon GPS. b. Zoom in on map. c. Find a location on a map. d. Identify latitude/longitude coordinates. e. Display event id on a map

M

17.03.12Mobiles shall support access to the video managemetn system to enable opening all event related video (live and recorded).

M

17.03.13 AACS must be able to record phone ID and user id of mobile user logging on to the system. M

17.03.14 AACS must perform automatic log off for mobile after 5 minutes of inactivity. M

17.03.15AACS will log and provide for an audit trail of all communications sent and received between mobiles and AACS with time stamp, user ID and location.

M

17.03.15

AACS must support the following mobile devices a. Android b. iPhone c. other devices via a web-based application

M

17.04 Biometric Verification System (BVS) Interface Requirements


Printed On 3/4/2021


video





# Description

17.04.01

DFW will be implementing a new Biometric Verification System. The contractor will support the selection of BVS (as detailed in the SOW)

The purpose will be for staff to be authenticated at selected Portals, using two factors of identification. Their badge and a biometric signature.

The Biometric Verification will match badge ID to the biometric signature presented. If they don’t match, an alarm will be created, and access will not be granted at that Portal. The Biometric Verification System will keep a log of all attempts to authenticate.

M

17.04.02 All alarms from the system will be sent to AACS, via the PSIM, for event management M

17.04.03

On receipt of a BVS alarm AACS, via the PSIM, will automatically create an event and auto populate the event record with event type, location, time stamp, Card holder and biometric event information.

M

17.04.04

AACS shall be able to query system logs to search authentication attempt history sorted by various factors such as: a. Date/Date range b. Card Holder ID c. Biometric Presented d. Authentication Result

M

18 CBP Specific Requirements

18.01

CBP manages the FIS area of the airport. They will have access to AACS, via the PSIM,.in order to manage the portals, call and duress pushbuttons, and cameras specific to the FIS.

M


Printed On 3/4/2021


video





# Description

18.02

AACS, via the PSIM. must be able to allow selective monitoring of a subset of available devices. CBP may only manage FIS related doors, devices, alarms and cameras in the FIS.

M

18.03 CBP must be presented AACS alarms for sensors in the FIS. M

18.04 CBP must be able to control cameras within the FIS. M

18.05

All AACS functionality will be available to CBP operators in the FIS only limited to devices in the FIS. This includes, event management, response plan/ SOPs, GIS MAP interfaces, camera selections, card holder information, and queries and reports.

M

18.06 The same types of screens will be available to CBP limited to presenting FIS data only. M

18.07 CBP will be able to query and run reports associated with AACS devices in the FIS. M

18.08

CBP Officers, in the CBP Operations Command Center shall have the ability to use a PSIM screen based ManTrap sysetem to manually lock selected Exit Doors, when related FIS controlled and monitored exit doors are breached. The mantrap system shall requre that an pushbutton is pressed an held when the preconfigured event based system is activated.

Specific configuration details associted with this special event and the interacion with the PACS shall be developed during the requirements validation phase on the project.

M

18.09CBP must be able to access card holder data and card holder history for staff associated with FIS based alarms and access transactions.

M


Printed On 3/4/2021


video





# Description

The AACS must have the capability to have alarm monitoring of the FIS performed by TacComm when the CBP Operations command Center is closed after CBP hours. CBP is the primary responder for FIS area alarms during active hours and TacComm after hours.

M

19 DPS Police Specific Requirements

19.01

DPS Police Unit includes Police Officers and Police Detectives. They also are responsale for the Insider Threat Task Force.

DPS police will have access to AACS, via the PSIM, in order to view live and recorded video and historical access control system data in order to perform access control anomaly analysis and Insider Threat investigations, which inlcudes access to card holder.

M

19.02 They will not acknowledge or clear alarms, but must be able to view current and historical event logs M

19.03 DPS Police must be able to query and generate reports from AACS M

19.04 DPS must be able to view AACS dashboard M

19.05They must have access to view current and historical card holder information to include history from all cards issued to the same employee over time.

M

19.06 They must be able to view historic video recordings associated with card usage history M

19.07 Via the PSIM, they must be able to track card holders on a map based on access points used or attempted. M

19.08

Police officers will need access to AACS from mobile devices in the field. They must be able to view dashboard, send event updates to AACS and perform queries commensurate with their roles and permissions within AACS.

M

19.09 The PoliceRole, must be able to deactivate a badge from the PSIM workstation M


Printed On 3/4/2021


video





# Description

20 Access DFW Specific Requirements

20.01

Access DFW is responsible for the credentialling function associed with the AACS. They primarily utalize the ACMS in this role.

They will utalize the PSIM, in order to view Access Control System information (door configuration, review and evaluate current and historical access control data, and perform access control/anomaly investigations), view Live and Recorded Video and to access data in the ACMS.

M

20.02 They will not acknowledge or clear alarms, but may view current and historical event logs M

20.03

They must have access to the GIS based maps with icons of all door readers/devices. They must be able to click on an icon and get history of the transactions at that door/device and the access categories assigned to the door.

M

20.04They must have access to the GIS maps with icons of all door cameras. They must be able to click on camera and get video of camera at that location.

M

20.05 They must be able generate reports against employee, access and alarm databases M

20.06They must have access to view current and historical Employee Database and be able to add employee / badge/ access violation to employee records

M

20.07 They must be able to access AACS Dashboards M

20.08 They must have ability to deactivate AOA vehcile permits via the PSIM, and in the field M

20.09 They must be able to deactivate a badge or change its status from the PSIM. M

21 DPS ASD Specific Requirements


Printed On 3/4/2021


video





# Description

21.01

The ASD group includes Security Officers that patrol the Terminal Complex the AOA Perimeter, and staff the AOA vehicle gates. ASD does employee /vehicle inspections, and perform security related investigations.

M

21.02

ASD must be able to access AACS, via the PSIM in order to view Live and Recorded Video and Access Control System information, including door configuration, zone information, review and evaluate current and historical access control data, and perform access control/anomaly investigations

M

21.03 ASD must have access to the GIS Map views and map functionality available in PSIM. M

21.04 They will not acknowledge or clear alarms, but must be able to view current and historical event logs M

21.05 They must be able to generate reports against employee, access, and alarm databases M

21.06They must have access to view current and historical Employee Database and be able to add employee / badge/ access violation to employee records

M

21.07 They must be able to access AACS Dashboards M

21.08They must be able to deactivate a badge, AOA vehicle Permit, or programable smart key from the PSIM interface.

M

21.09 They must be able to access real time and historical badge status and access attempt data. M

21.10 AACS must be able to track card holders on a GIS map based on access points used.or attempted. M

21.11They must have access to view current and historical card holder information to include history from all cards issued to the same employee over time.

M


Printed On 3/4/2021


video





# Description

21.12 ASD must be able to report security violations directly into the AACS, using the PSIM as a user interface. M

21.13 ASD officers will need access to AACS from mobile devices in the field. M

22 AOA Vehcile Gate/Guard Booth Requirements

22.01

The AACS must be accessible via the PSIM for ASD Staff at either AOA vehcile gates with either a PSIM workstation or mobile device.

At gates ASD shall be able to view alarms, access control and biometric transaction, and video associated with their gates. They cannot respond to alarms.

M

22.02

ASD officers must be able to view card holder, biometric data and card holder violatoin data, as well as vehicle permit data associated with the badge holders and vehciles that present at their assigned vehcile gate in order to process card holder and vehciles at AOA gates

ASD officers at Vehcile gate shall have the cabpabity to annotate Vehicle access and badge holder trasnaction data as well as deactive Badges and Vehicle Permits if requied.

M

22.03

ASD officer must be able to interact with the ACMS (HID SAFE) for visitor management and escort vetting functions, including the use of driver's license readers from the PSIM interface at AOA Vehcile gates

M

22.04

The system must be able to link video, card/biometric transactions, along with escort/visitor data as an access transaction for gate control. The AACS needs to support Gate Automation /record keeping at the gate.

M


Printed On 3/4/2021


Mandatory (M) Will Fully Comply Exception or Clarification Optional (O) Comments /Explanation Comments /Explanation Future (F) (Provide and Reference separate attachments as required) (Provide and Reference separate attachments as required)

23 Information Security Requirements

23.02

Contractor shall follow the ISO 27002 standard, including all published requirements to maintain appropriate administrative, technical and physical safeguards, and other security measures.

M

23.03AACS contains SSI information. The Contractor and the design shall follow 49 CFR Part 1520 – Protection of Sensitive Security Information

M

23.04

The ACMS portion of the AACS contains PII data. The Contractor and the design shall follow NIST Special Publication 800-53, including all published requirements to maintain appropriate administrative, technical and physical safeguards, and other security measures for PII data.

Contractor must develop an Information Security Plan for the AACS in accordance with the NIST standard.

M

23.05

Contractor must implement the referenced DFW Data Classification Policy and protect confidential information transmitted and stored within the AACS system.

M

23.06 Contractor must abide by and implement the referenced DFW System User Administration Policy M

23.07

AACS is designated as a critical system for DFW operations. As such the AACS contractor must develop a Disaster Recovery Plan/System Recovery Procedures in accordance with the referenced DFW ITS System Disaster Recovery Policy

M


# Description

DFW AACS - Information Security Requirements Matrix

AACS Integrator RFP AACS - Information Security Req of 73

Printed On 3/4/2021




# Description


23.08

The AACS system shall include an account management functionality that is used to define user profiles, groups and roles. This will ensure only authorized users can log into the AACS and restricts the features and functions the users are permitted to access (e.g. CBP can only monitor, manage FIS AACS devices, alarms and associated cameras).

M

23.09

Policies and procedures for access and control of data, devices, and cameras shall be developed and implemented for the AACS.

Control polices and procedures must protect access to SSI and PII data that may reside in the AACS system files.

M

23.10Data in AACS must be encrypted, both in transit and at rest. AACS will follow TLS 1.2 encryption standard.

M

23.11The AACS must implement information security controls that comply with NIST SP 800-53 standards for high impact confidential systems.

M

23.12

Every authorized user of the AACS shall have a user profile that accomplishes the following: a. Contains information that identifies the user, including the user’s id and password b. Assigns the user to a role and/ or group that determines the user’s permissions regarding the various system features and functions c. Ability to grant access to functions, screens and/or data based upon user group

M

23.13

The system will provide the capability for administrative personnel to enter identifying information about the user and to assign the user to one (and only one) pre-defined role.

M


Printed On 3/4/2021




# Description


23.14The AACS shall require each user to enter a username and password combination in order to log into the application.

M

23.15

The AACS shall allow administrators to: a. Terminate, block or force users to change passwords upon the next logon attempt, b. Support advanced authentication policies including password length, special characters and maximum number of logon attempts before denying access

M

23.16The AACS shall interoperate with Microsoft’s Active Directory (AD) to authenticate all personnel authorized to access the AACS.

M

23.17The system must support antivirus and malware program scans without disruption to the AACS system and data base.

M

23.18Any software application configuration changes to the solution shall adhere to the DFW change management process and procedures.

M

23.19

Any Remote access to the AACS will be accomplished via secure VPN. Only authorized DFW ITS system administrators will have remote access to the production system. System providers will have remote access to the development environment.

M


Printed On 3/4/2021


Mandatory (M) Will Fully Comply Exception or Clarification Optional (O) Comments /Explanation Comments /Explanation

Future (F) (Provide and Reference separate attachments as required) (Provide and Reference separate attachments as required)

24 System Monitoring Tool

24.01

AACS (both PSIM and PACS ) will support a system monitoring tool indicating the status of all AACS components and status of interfaces to externally connected systems.

M

24.02The monitoring tool shall monitor system availability and resource utilization, and communications integrity.

M

24.03

The monitoring tool shall have remote access to support remote diagnostic capabilities, upgrades and maintenance on the development environment. No remote access will be allowed on production environment by other than DFW ITS staff.

M

24.04

All system faults including failures in communications, network failures, interface failures, failures in receiving scheduled and known data updates, shall be viewable on an administrator’s workstation. The monitoring system shall initiate both an audible and visual alarm of any system failures/problems at the administrator workstation and add the alarm to the system logs.

M


# Description

DFW AACS - System Administration Requirements Matrix

AACS Integrator RFP AACS System Administration Req of 73

Printed On 3/4/2021





# Description


24.05

Upon PSIM and PACS server failures, the system administrator shall receive a warning message on the system administrator workstation, and an e-mail, pager, or text message notification, notifying him/her of the failure. Server failure shall include any hardware or software-based failure. Should a component fail, the system shall immediately notify the system administrator via the monitoring system.

M

24.06

All failures of the system shall be logged at a central control point (e.g. Monitoring Server). The failure shall initiate alarms and reports (e.g., time and date of failure event).

M

24.07

The monitoring system shall provide the local system administrator monitor and control workstation user with current operational status and notification alerts and alarms for the following: a. interfaces with other systems; b. system firewalls and routers; c. system servers; d. PSIM and PACS user workstations not reachable

M

24.08

The monitoring system workstation shall have a dashboard screen providing the following: a. active color icons indicating all equipment status; b. audible alerts for equipment failure; and c. text notification for alerts including primary resolution steps and helpdesk resources.

M


Printed On 3/4/2021





# Description


24.09

The monitoring system shall provide critical alarm notifications in the following methods: a. notification to on-site monitoring system user workstation as noted above; b. notification to Airport select staff via email; c. notification via ENS d. notification to Airport select staff via text message and/or pager; and e. notification to AACS System provider helpdesk.

M

24.10 All IP addresses of system components must be monitored by the system, including all servers. M

24.11 The Contractor must provide all VLAN information required for monitoring by the system. M

24.12

The Contractor must provide detail design information regarding data outlet types, locations and port counts needed to support the AACS System.

M

24.13

The AACS monitoring system will provide 24x7x365 monitoring capability to include tracking, logging and notification of System usage and failure events and alerts.

M

24.14

The system shall include diagnostic capabilities that automatically detect and correct when possible, failures in the system and automatically alert the system administrator when a failure occurs. A system console message and an error log will be part of the automated process.

M


Printed On 3/4/2021





# Description


24.15

The monitoring system shall be capable of determining status of network connections and if a path is available from any systems interface or user WS.

M

24.16

The Contractor shall provide a remote helpdesk/call center 24x7 and toll-free phone number to receive trouble calls from 1st level maintenance.

M

24.17The Contractor shall log and track all incoming trouble calls and support trouble shooting and remote diagnostics until full resolution.

M

24.18

The Contractor shall provide the Airport with access to the monitoring system data to view and to pull trouble tickets, logs of alerts and other system events and reports.

M

25 System Logging and Reporting

25.01

Contractor must implement system logs and audit trails of AACS (PSIM and PACS ) system activities in accordance with reference DFW Audit Logging and Monitoring Standards

M


Printed On 3/4/2021





# Description


25.02

The AACS (PSIM and PACS) will include a logging and reporting function that allows DFW system administrators to generate, format, and print reports on various aspects of the system’s operation and performance. Report data is limited to the information logged/archived by the application.

Logged data will be maintained on the systems for 12 months and then archived on a monthly basis. All logged data shall be accessible to the Airport to view and must be accessible by the Airport utilizing a REST API.

M

25.03 Audit Trail

25.03.01

AACS (PSIM and PACS) will provide for an audit trail of all communications sent and received between systems, devices, alerts and system events and failures.

M

25.03.02AACS (PSIM and PACS) will provide an audit trail of all user activity. All logged items will be time stamped and tied to user-id.

M

25.03.03All activity logs will be maintained in the system for a minimum of 60 days. Logs will be archived after the agreed upon period.

M

25.04 Reporting

25.04.01

The reporting function shall allow AACS (PSIM and PACS) system administrator to select the system data in the reports to produce customized reports, to display the reports on the administrator workstation, to send the reports to an attached printer, and to save the reports.

M


Printed On 3/4/2021





# Description


25.04.02

Standard reports required will be defined during the requirements validation phase. At a minimum, the reporting function shall include the following types of reports: a. System resource Usage report - summary report showing all resource history/utilization for a system resource, selectable by date/time range; b. System failure/fault reports c. System access report – all login attempts, failed logins, and all users who accessed the system with time stamp d. System performance report – statistics of all system performance metrics measured.

M

25.04.03 The system shall provide the ability to maintain distribution lists for standard reports. M

25.03.04

The Contractor submit a Quality of Service (QOS) report on a monthly basis. At a minimum, the QOS report must contain the following:

M

25.03.04.01 System Alert/Event Log; M

25.03.04.02 Hardware Maintenance Log (Failed components and MTBF); M

25.03.04.03 Software changes occurring that month; and M


Printed On 3/4/2021





# Description


25.03.04.04

System Availability Calculations a. Total availability for the month b. Types of failures c. Time of day of failures d. Duration of failures e. Performance metrics report as specified in the performance requirements.

M

26 General System Administration Requirements

26.01 PACS will support virtualization technologies. M

26.02

System administrators will be able to set user-ids and passwords for each user. Permissions, actions, views, and device restrictions will be configurable to user-ids, or user groups.

M

26.03System must support user groups and user role definitions. User ids will be associated to roles and be given associated privileges/permissions.

M

26.04User roles may be configured to include time of day, alarm management, no alarm management, camera views, devices by location.

M

26.05 System will support the creation of device groups and device authorizations. M

26.06System administrators will be able to determine and customize authentication policies for the PACS

M

26.07AACS (both PSIM and PACS) will be able to support specific terminal/workstation authorization settings

M


Printed On 3/4/2021





# Description


26.08AACS (PSIM and PACS) will support system access authorization based on userid and time of day.

M

26.09AACS (PSIM and PACS) will be able to log and track all logins access and unauthorized access attempts.

M

26.10

AACS (PSIM and PACS) will be able to configure and save workstation preferred layouts by user-id or user group so that it comes up automatically when user logs onto the application.

M

26.11

The AACS (PSIM and PACS) will support configuration and customization capabilities determined by user-id, user group and permission levels.

M

26.12AACS (PSIM and PACS) will maintain an audit log of all data creation, update, and deletion tied to user-id.

M

26.13AACS administrator must be able to perform system backups without interfering with system operations

M

26.14 PSIM and PACS must be able to be restored from back up by system administrator M

26.15

Patches and updates to COTS software implemented within the PSIM and/or the PACS will be performed by DFW ITS. Patches,

Fixes and upgrades to the AACS application software will be performed by the AACS Integrator / contractor. The Contractor must implement a change control procedure in coordination with DFW ITS for implementing any changes to AACS software.

M


Printed On 3/4/2021



27

27.01All system functionality should be 99.99% available, achieved through redundancy and fault tolerance design techniques.

M

27.02PSIM design should be sized to assume 100% of a possible 50 concurrent users, with a 100% spare capacity (totaling 200% concurrent users).

M

27.03PSIM shall present response plan in less than or equal to three seconds after the receipt of associated subsystem data by the AACS.

M

27.04 Requested camera video feed displayed in two seconds following creation of the UDP video stream. M

27.05

GIS Maps shall be fully rendered and available for use within three seconds after opening a new instance. The loading of external map sources that occur after the three seconds should not adversely affect system functionality while these sources are in the process of being displayed.

M

27.06

Subsystems shall integrate with the AACS in a way that mitigates stale data being presented due to refresh intervals. Data should be presented in near real-time to the PSIM.

M

27.07

PSIM shall provide a resource/responder recommendation in less than or equal to three seconds after the receipt of associated subsystem data by the AACS.

M


# Description

DFW AACS - System Performance Requirements Matrix

AACS Integrator RFP AACS System Performance Req, of 73

Printed On 3/4/2021




# Description

DFW AACS - System Performance Requirements Matrix

27.08

Accurate device details shall be presented in less than or equal to three seconds after the request is submitted by a PSIM user (initiated by from a GIS map or device tree selection).

M

27.09

Resource status updates between AACS and mobiles should be completed in near real-time, with the latest update being no later than three seconds old.

M

27.10

Alerts shall be presented within one second to the AACS via the PSIM User Interfaces.

This requirement is measured from the time the associated information is first received by the subsystem’s services. GIS Maps and alert lists shall dynamically update when new, or updated, items are pushed to the PSIM Clients.

M

27.11

Events shall be presented within three second to the AACS via the PSIM User Interfaces.

This requirement is measured from the time the associated information is first received by the subsystem’s services. GIS Maps and event lists shall dynamically update when new, or updated, items are pushed to the PSIM Clients.

M

27.12AACS / PSIM System datastore should be sized for five years of historical event and alarm data, including associated data provided by subsystems.

M

AACS Integrator RFP AACS System Performance Req, of 73

Printed On 3/4/2021