Milind Borkar
Strategic Growth Advisor, Vicon
This section is focused on best practices and considerations for integrating elements of airport physical security systems. Systems integration is the coupling of various discrete hardware and software systems into a unified system. The objective of assembling individual pieces into a whole functioning unit often requires detailed planning that clearly defines the operational requirements of the integrated system, the functional requirements of the integrated components, and the internal interfaces between all components as well as all external (input and output) interfaces.
Well-conceived and tested, integration can provide the airport operator with several benefits:
- Improved Situational Awareness: On-going monitoring of a situation can be enhanced using information from door activity, fence sensors, video surveillance, networked communications, weather, news, and even flight management functions. Increasing amounts of information may be necessary for inclusion in the post-incident report and compilation of this information using manual processes can be challenging.
- Improved Operating and Security Efficiencies: Integration automation promotes consistency in response as integrated system can map to standard operating procedures and streamline common steps for event management. Airports can correlate information across systems for greater situational intelligence. Analytic engines can proactively monitor physical access control system information in coordination with information from credentialing systems or other identity-based data sets such as security violations.
- Legacy System Migration: Integration platforms can assist in the migration of legacy systems which involve different vendors, types of equipment, and software. An integration platform can present a logical view of two or more systems, converging them into a common presentation for operators.
Integration can also introduce complexities into security system design which are best mitigated by the careful determination of operational requirements (the ConOps process) technical specifications that address component compatibility details, and proof-of-integration testing. The complexity of the process usually necessitates an iterative approach where small pieces are integrated together in steps with each step resulting in a larger functional unit until the whole system is successfully integrated together, so that the end result meets the user’s requirements.
Integrated systems can provide a range of decision-making resources and tools for operators. Those tools can automate some response processes (e.g., alert notifications) or guide response actions. Integrated tools also provide platforms through which response activities can be coordinated and directed though a range of tools including radio, data and telephony.
Integration Process
Figure 1 diagrams the major process for integrating physical security systems.
a) Detection/ Perception Airport decision makers can draw upon a variety of system inputs including – Fire Alarms, Pressure Sensors, Motion Sensors, Audio Sensors, Physical Access Control Systems (PACS) including credentialing systems, Perimeter Intrusion Detection Systems (PIDS), Video Surveillance Systems, including both visible CCTV and infrared sensors, Computer-Aided Dispatch (CAD) systems, Geographical Information Systems (GIS), Building Automation Systems (BAS), CBRNE sensors, Global Positioning System (GPS) data, Network Communications including network monitoring systems, and Human assets equipped with voice or data communications devices-radios cellphones, data terminals. Sensor data may come directly into a common platform, or it may be filtered or prioritized by management software such as VMS, PIDS, BAS or CAD systems.
In addition to sensory data there are a range of other information sources that help to develop a picture of an incident or occurrence, i.e., situational awareness. These inputs can include – Event Management Systems (Web EOC, eTeam, Esponder), Work Order and Maintenance Management Systems, GIS Data, FIDS Data, Personnel Data (Biometrics/ Credentialing), Key Control Management Programs, Gate Management Systems, Airfield Management Systems, and Safety Management Systems.
b) Assess/ Analyze This phase of the integration process should begin with a ConOps, this being the best means of determining operational requirements from which technical specifications and decision rules can be derived. Some tools like CAD, PIDS, CMMS and VMS programs can help in bringing meaning to differing pieces of data and relating that to action programs. PSIM software generally provide richer integration linking more data fields and supporting security functions across the full operational spectrum.
c) Direction/ Response Integration is most effective when it supports the actions of responders. The focus of system integration is to facilitate the operator’s access to and ability to exploit, in real time, information converged from diverse sensors and other inputs. Integration at the system level enables intelligent decision-making to be applied for response functions. This occurs through subsystems designed for task execution including radio/ telephone/ data communication systems; automated command to remote access points or barrier or access control systems; mass notification systems; and alarm/ audio and public address systems.
The extent to which these inputs and functions should be integrated will vary for each airport operator. Defining operational requirements by a thorough ConOps is the first step in this process. The criteria for making these decisions should be:
- (a) identifying threats, vulnerabilities, and associated operational and technical solutions;
- (b) supporting operator response capabilities while reducing workloads and stress at all levels, but especially in the SOC;
- (c) implementing solutions in the most cost-effective manner; and
- (d) providing for upgrades and support over the life cycle of the security system for all if its elements.
The outputs of system engineering will include documentation of the system design, trade-off studies of system and component alternatives, system and component specifications, estimates of probable cost, management plans and schedules, contractual documents etc. Model specifications are available from several sources, but two sections of the Construction Standards Several industry groups have standardized protocols for digital video systems and for their integration with other elements of physical security systems. Their common goal is improved hardware and software compatibility, but each group has its own focus, and their standards differ in important respects including their span of coverage and how they specify and test for compatibility compliance.
- The Open Network Video Interface Forum (ONVIF) is composed of most of the leading manufacturers of video hardware and software. ONVIF standards focus on camera, encoder, and software compatibility including VMS and PSIM integration.
- The Physical Security Interoperability Alliance (PSIA) also includes video manufacturers as members, but it also includes leading access control hardware and software manufacturers and suppliers of building automation systems. PSIA’s emphasis is on making these elements interoperable, e.g., being able to hand off access control alerts so that video imagery and decision-making software can utilize such information.
- The Security Industry Association (SIA) is working on access control integration using specifications of leading access control hardware and software manufacturers, which have been regarded by many system integrators as de facto standards for many years.
All of these groups have published specifications and/ or standards, which continue to be developed and refined, and all continue to expand their memberships.
Stating that an item of equipment such as a video camera, ‘complies’ with a published industry standard does not assure that it will interoperate with ‘compliant’ products of other manufacturers. Even within a given camera product line, there can be models which comply with a given standards while other models do not comply. Equipment specifications, however detailed, are not sufficient to reveal to an airport operator the full level of operational performance or the compliance of a specific device to a standard. Always check equipment model details against the standards to which they have been tested, and whenever possible physically test the products under local operational and environmental conditions of use.
A major issue is often the ability to upgrade or replace an item of hardware or software independently of a manufacturer’s proprietary design data and protocols.
Airport design and procurement packages should:
- Cite open standards and specifications.
- Require that any exceptions to these standards and specifications be identified and be individually justified in system proposals.
- Require the demonstration of hardware and software compatibility and multi-vendor interoperability during proposal evaluations, preferably by setting up a laboratory environment of airport systems and equipment where such testing can be conducted.
Choosing a Platform
Before the widespread adoption of networked digital systems, most security systems were integrated around access control devices. Access control systems were the first line of defense, alerting security staff to unauthorized intrusions and providing basic video coverage of these events. Not all incidents are triggered by a physical security breach, nor do all incidents carry a physical security risk. Such incidents are geared more towards airport operations, but nevertheless they are issues that arise and must be addressed.
As security systems became more complex, as users increased the quantities of video cameras, and as all of these devices became networked the integration platform of choice shifted to video management. For basic systems, i.e., where the inputs are mainly access readers and video cameras, the platform of choice has been a Video Management System (VMS). When more unconventional devices are included, for which custom drivers are required, or when intelligent decision rules for SOC operators are required, the platform of choice has become Physical Systems Information Management (PSIM) software.
Developed for system-level integration, PSIM software is intended to interface disparate sensors and other equipment into a unified, common operator presentation. Most of these presentations are video based, in part because the quantities of video cameras usually far exceed the quantity of access control readers but also because video is provides the ‘intelligence’ needed for enhanced situational awareness and decision making in Security Operations Centers.
The system-level capabilities of PSIM come at a cost, not just for the customized device-specific drivers that are required but it also makes the airport more dependent on the PSIM vendor to train its operating personnel and to keep all elements of the integrated system current and protected from incompatibilities. The incompatibility issue is not unique to PSIMs – it is also an issue for VMS integration, as when a camera firmware update can neuter video analytic functions – but a PSIM, with its broader device coverage and greater device interdependencies, may be more vulnerable as a result – and could become a single-point of failure.
Smaller airports may only require that video coverage be available for access control and intrusion events; integration might only require that events be displayed as video from cameras near the event using two side-by-side video monitors – one for access event data and logs, perhaps shown in association with a map or an engineered drawing of the event area, and a second to display video from cameras in the vicinity of the event.
Larger airports, or where large numbers of video cameras are installed, will usually require a higher level of integration. While both access control and video platforms can serve this purpose, VMS is currently the platform of choice. Moving to more complex PSIM solutions should be done only after carefully analyzing, and documenting, the expected benefits, risks, and costs.
Physical Security Information Management Systems (PSIM)
PSIM is a Command and Control Center concept intended to improve Situational Awareness, Situation Management, and Situation Reconstruction.
Situational Awareness Situational Awareness is about an operator being fully aware of events and activities and their on-going status. Situational Awareness can be achieved through countless ways, ranging from simple emails and phone calls to multiple computers sharing one desk, up to a fully integrated desktop unit where all the information is combined and filtered to give complete view of situations in real time.
Situation Management Situation Management is about an operator knowing what to do next, or in case a task may be automated, ensuring that the system knows what to do next, without delay and with complete consistency. Situation Management is particularly important for scenarios where operators are experiencing heavy incident workloads, or during periods of highly stressful incidents, or when operators are fairly new and inexperienced or when there are changes to the standard operating procedures that would otherwise need to be communicated out via training classes.
Part of Situation Management involves engaging other people and systems and this is typically done through system integration and mobile devices. Just as a dynamic workflow engine guides the system and operators through the tasks of prioritized incidents, it is also responsible for all escalations, so when for example someone is asked a question, if the answer is not given within a specified time limit it will escalate a response.
Situation Reconstruction Situation Reconstruction builds on lessons from experience. PSIM solutions typically provide rich reports because they automatically combine data from multiple systems, e.g. video, access, fire etc. In addition to these static reports, graphs showing trends can provide insight for change. For example, which types of incidents are most common, how does their frequency vary over time, how long does it take to resolve a given category of incident, etc. The final assist is to reconstruct a given situation – to play it back in slow motion to see how it unfolds. This could include all aspects of the incident including video, radio, voice telephony, asset movements tracked on a GIS-coordinated map, systems and sensors providing real-time data and exactly who did what and when. Virtual re-enactment of an incident provides insight as to how people, systems and processes performed, and what changes should be made to improve system effectiveness.
Operational Benefits and Architecture While the various subsystems focus on security, especially trying to stop unwanted things from happening, PSIM recognizes that nothing can stop the flow of incidents that a control center must handle – but it can provide the tools to manage them better, faster, smoother and more consistently. For hierarchical PSIM-based integrated systems, the software is the portal to all the other systems. It consolidates and prioritizes all the relevant information from all the components into a single cockpit or dashboard view as well as presenting the most likely functions (e.g. open a door, move a camera, acknowledge a smoke alarm).
Beyond the role of integration for increased situational awareness, PSIM plays a central role in situation management, using digital representations of standard operating procedures, so that the system will lead operators through the process of who should do what and when. Many VMS and PACS do a satisfactory job of integrating other systems, so this is not the main reason to consider PSIM. A PSIM solution is sub-system agnostic; any vendor’s subsystem should be supportable. PSIM software is meant to accept more vendors than VMS or PACS software, and over time this results in many elements of integration becoming available as off- the-shelf modules.
A potential single point of failure is an upgrade to the PSIM itself, which could affect all the subsystem connections. For this reason, good PSIM software will isolate core PSIM functionality from the gateways or connections to the components. This means that upgrading PSIM is possible without affecting the components A to Z. PSIM software will typically adopt a client-server architecture. The server, which should include hardware and or software-based redundancy, communicates with the components, and the same guidelines of component and network redundancy outlined above apply here. Operator workstations as well as other information display components such as video walls, act as clients to the PSIM server, and depend on the network for connectivity.
It may also be useful to extend the PSIM functionality beyond physical security and into the domain of operations. A PSIM could, for example, be used to manage situations and learn from how they evolved, to manage non-security and non-safety events such as a leaking toilet, an obstructed conveyor belt, over-crowding or preparation for an approaching severe weather front.
The PSIM should accept new components to be integrated without changing the version of the software. This independence is critical; if adding one new component changes the core software, this could at best require complete system testing from scratch, and at worst, require that all the other component integrations be updated. Each component might eventually require expansion, e.g., more cameras, more doors or more perimeter sensors, and a PSIM should be designed to cope with such expansions. It is rare to see limits on sensor counts, but there is still a practical limit, which is unique to each PSIM, the server it is running on and the database and physical storage it uses, each combination of components and types of sensors and each IT network and available bandwidth. As the system expands, there may or may not be performance implications.
Because it uses a hierarchical architecture, PSIM software can provide for reconstructing an incident for training, event evidence or continuous system improvement. For example it is easier to understand how an entire situation started and evolved if there is a way to present the video, the audio (including radios), the status of all the relevant sensors and visually tracking mobile assets on a GIS map. An integrated report which is interactive is complementary to a static audit report of who did what and when, but is arguably more valuable because of the ability to ‘re-enact’ the incident in real time.
System Component Interoperability
System component interoperability is a measure of how well one or more elements of a security system are able to work with other systems. Interoperability takes several forms. At the system level, it is primarily a communications issue where information must be exchanged among system elements. At the system component level, it can be an equipment interface issue such as circuit board or connector compatibility or software compatibility, especially when different vendors are involved and different protocols are used. Achieving interoperability requires well defined interface specifications, vendor commitments, and tight control of system and component configurations throughout both the design and the implementation processes.
Ideally, interoperability should happen in a plug-and-play context, i.e., without having to modify electrical and mechanical interfaces or write software patches, however, interoperability is a system integrity issue and should be controlled by tested, proven open standards using established verification processes. It may only be possible to identify and resolve interoperability issues, by using a test bed in which the elements are physically connected, continuity is verified, and they are run through their entire range operational scenarios.
System Interfaces
Originally direct integration was possible using RS232, RS485, and other protocols, which linked two components such as an access control unit and an analog video matrix switch. This elementary integration has been superseded by IP as the ubiquitous method for system communication, allowing rapid bidirectional communication of any kind of digital data between any number of components over any distance. The software interfaces of such components are commonly published allowing third parties to create integrations. They are variously known as Application Programmer’s Interface (API) or Software Development Kit (SDK), gateways or protocols.
- Look for modern architectures: In general, modern architectures that use communications technologies like xml and web services will be easier to integrate than systems built on older architectures.
- Check Vendors’ Application Programming Interfaces (APIs): APIs are the “gateway” for data to pass in and out of systems, and the availability of an API can mean the difference between a relatively simple integration and costly, complex, custom integration. Vendors’ approach to APIs vary widely; some openly publish their APIs, others charge significant sums, and some do not offer them at all. It is important to determine, before making a commitment, if the vendor has APIs already developed for the functions of other systems that are to be integrated to avoid the time, and cost, of having to develop them.
- Consider Physical Security Information Management (PSIM) systems as an integration ‘hub:’ When assessing the cost of custom-integrating subsystems with each other, PSIM can often save money, especially when integrating multiple subsystems. Because PSIM vendors offer large libraries of pre-built integrations to many popular security systems, it is often possible to achieve subsystem integration at lower cost, more quickly, with lower risk. There is also the added benefit of the advanced functionalities that PSIM offers, including a single user interface for multiple systems, correlating alarms with maps, ConOps management, etc.
- Be aware that some systems have unique integration restrictions: Many organizations attempt to integrate systems together, only to discover that a system’s vendor does not offer an API. Usually, the only way to do this with the vendor’s approval is to pay the vendor to develop the interface, which is usually costly. It is possible to bypass the application and integrate directly with the underlying database without the vendor’s approval, but this can void warranties. The consequences of attempting to integrate to a system with no available API sometimes make it more cost effective to replace the system with one that is more amenable to integration.
Cost Impacts
The factors affecting cost for an integrated system include:
- One-way or Two-way: whether the integration is unidirectional or bidirectional affects complexity;
- Functionality: To say two things are integrated is meaningless until one defines which features have been integrated, which affects complexity;
- System Size: Larger systems with more components are more complex to integrate than smaller ones, and the cost of maintenance is also much higher;
- PSIM licensing: PSIM licensing is broadly based on three factors. (i) The number of sensors under management (because it has to communicate with each and every one; (ii) the number of components (because the interfaces must be built, integrated and maintained throughout the life of the system); and (iii) the number of users.
Configuration Management / Migration Issues
Most airports have evolved their physical security infrastructure over time. This often results in a heterogeneous environment, with some older components, and some newer ones as well as a few that might be under development. For example, a video subsystem might include some older DVRs, some newer NVRs as well as some cutting edge high-resolution and megapixel IP cameras running on dedicated servers. That scenario represents three different sets of siloed components. The situation could be much worse in a geographically-dispersed multi-terminal facility.
The challenge with these silo components is that they provide a weaker situational awareness than if they were combined. In the scenario above, an operator who wants to replay a given camera needs to know which system it belongs to, pull that system up on his screen, adapt to the system’s user interface and remember how it handles rewind and replay. If the video needs to be exported, it is normal for each system to export tamper-detectable video clips using different or even proprietary formats, which are then incompatible with each other, so they cannot be combined into a forensic report.
Integrating these components via PSIM offers a single user interface, regardless of the physical implementation of the video components beneath. This is known as logical abstraction. (With PSIM, there are no differences between various vendors’ sub systems as to viewing/ manipulating PTZ cameras, replaying/ exporting video, viewing the last person who accessed a portal, locking down an area, or broadcasting a message to a terminal.
It is a common experience for airports to have to cope with moves, adds, and changes including upgrades to their security systems to cope with evolving threats, evolving regulations, and evolving technologies. An airport may feel locked in to the current system because of the magnitude of the existing investment which makes the cost of wholesale removal and replacement difficult to justify. If a PSIM solution is in place, it should be able to integrate both legacy and new subsystems, operating side by side, until such time as older components can be replaced.
