|
Contributed by Hirsch Electronics www.WeSecureBuildings.com
A security robot lounges in the first-floor
lobby of a government research laboratory, its on-board computer
sleeping to preserve battery power. It's 4:00 a.m.
Suddenly, the building's access control system
detects a propped door. One of the laboratory's side doors has
remained open too long following an authorized card
presentation.
As usual, the access control software triggers
an alarm in the off-site security control center, advising the
officer on duty. Security personnel will monitor what happens next,
ready to respond if necessary. Chances are, however, that several
technological systems in the building will work out the problem on
their own.
XML Opens the Door
All night long, the access control system has
been broadcasting security system events to other systems that are
authorized to listen. The data format is XMLeXtensible Markup
Languagethe de facto standard for machine-to-machine
communication.
The XML data, written in short bursts of plain
English, is so simple that even the non-technical professional will
understand it right off the bat.
<SecuritySystemMessage>
<EventType>Alarm</EventType>
<EventSpecifics>DoorOpenTooLong</EventSpecifics>
<Location>LabSideDoor</Location>
</SecuritySystemMessage>
As much as 99.9% of the data bouncing around
among the different systems is ignored. Authorized users and
vehicles coming and going, for instance, raise no red flag. But
when the XML listener spots the phrase in the security system's XML
stream about the propped lab door, it triggers a series of actions
in other systems.
The building's lighting control system responds
by turning on the lights in the corridor adjacent to the propped
door. The CCTV system activates a preset program to pan, tilt and
zoom a nearby camera onto the propped door.
In the lobby, the robotic security guard hears
about the alarm condition over the wireless communications network
and matches the alarm location to the floor plan stored in its
memory. It moves unassisted from the lobby to the lab's side door,
where it finds two people: an authorized cardholder and someone who
followed him through the doora piggybackerjust inside a door that
has been propped open with a box. All of this happens within a few
moments of the alarm.
At the scene, a camera in the robot focuses on
the two people. From the remote security center, the security
officer talks to them, live, over the robot's two-way radio.
Turns out they are lab technicians who have come
to work early to check on an experiment. The security officer
suggests the piggybacker hold his photo ID up to the robot's camera
lens and present his access card to the proximity reader mounted on
the robot. The robot sends the card data to the access control
system, which verifies current employment status and area
authorization.
The alarm condition is cancelled.
Interoperability ensures the lab is secure and even negates the
need for a physical response.
While this scenario consolidates a number of
examples of interoperability, nothing about it is futuristic. Each
is currently being implemented in real-world applications.
CCTV from the Access Control
System
At the Orlando Sanford International Airport in
Florida, the Velocity access control system from Hirsch Electronics
will soon begin to interoperate with a CCTV solution from
Quebec-based SmartSight. We've tested the system, and it works,
said Andy Bowman, a security integrator with SiteSecure Inc. of
Sanford, FL.
Velocity's XML writer broadcasts data generated
by the access control system to other systems, and the XML listener
between Velocity and SmartSight will look for key triggers in the
stream of day-to-day transactional data.
If an XML communication arrives from Velocity
noting that input number one on panel number one indicates a forced
door alarm, then a specific mini-program called a macro will be
run. That macro executes particular commands or functions in the
video system.
Each potential alarm reported by Velocity will
have a predetermined macro executed by SmartSight. Say camera
number eight watches doors one, two, and three. When SmartSight
discovers an alarm on door number one, it will pan, tilt and zoom
camera number eight into its preset position for monitoring door
number one, and it will put the image from camera number eight up
on the alarm monitor in the security center.
While it is not new for one manufacturer's
access control system to communicate with another manufacturer's
video surveillance system, what is new is the ease and flexibility
of the implementation when using Velocity's XML output. It took
very little time to write both a relatively simple XML listenerto
identify and translate the security system trigger events into a
command for the target systemand the additional macros that perform
the desired video system controls.
In the old days, one could have achieved such
interoperability by hardwiring potentially thousands of access
control relays to video system inputs or under taking a massive
software integration development project to create a custom,
code-level integration of the products (which, by the way, would
need to be updated every time any of the vendors came out with new
product versions). Both alternatives are vastly more complex, time
consuming and costly than XML-based interoperability.
Other building systems can be made to
interoperate as well, said Bowman. For instance, if a facility were
concerned about the possibility of an attack on the air handling
system, intrusion alarms might be placed on secure doors protecting
the HVAC ducts. Should one of those alarms go off, the HVAC
controller, programmed to listen to access control data, would hear
an XML phrase about the forced door. In turn, the HVAC controller
would shut down the air handler to eliminate the possibility of an
airborne contaminant spreading through the facility.
If You Can't Fly, You Can't Work
Here
XML isn't necessarily the best tool for all
security interoperability assignments. Sometimes it is preferable
to use an application programming interface (API).
At the Palm Springs International Airport in
Palm Springs, CA, an API now handles the labor-intensive job of
checking government-issued no-fly watch lists against airport
employee rosters.
Federal laws designed to combat terrorism
require airport security to check all airport employees against the
watch lists, the same lists used to check out airline passengers
and crews. These lists contain thousands of names.
Every time we process a new employee, we have to
make sure he or she isn't on a watch list, said Shawn Flinn,
airport operations supervisor at Palm Springs International. And we
have to recheck all employees' names each time an updated watch
list arrives. In those cases, we have to compare the entire new
list to our entire employee database. It was very time consuming to
do it manually.
Looking for a way to automate the checks, Flinn
inquired if the airport's access control software, a Hirsch
Velocity system, could handle the job. After all, every airport
employee's name resides in the security system. Could Velocity
compare its database of employee names with the names in the watch
list database?
It was a perfect job for our API, said Mark
Allen, manager of Hirsch's Professional Services Group. Allen's
group wrote a database-matching program that sits between
Velocity's API and the watch list files, and installed it on an
airport workstation. Now, to check airport employees against the
watch lists, Flinn simply drags the watch list database into the
API's inbox folder. The program runs a comparison at a certain time
every day and whenever a new list comes in. It looks in the inbox,
pulls out each watch list name, and runs it against the names in
Velocity, Flinn said. Then it generates a report with any
matches.
It takes 30 seconds to run all the names on the
lists. Before we got the API, it took 30 seconds to check a single
name. It really speeds the process.
Tell the Technology to Handle
It
It's clear interoperability not only saves time
and money, it automates routines and solves problems that couldn't
be solved otherwise. A non-security system can listen to all the
security system events and transactions, identify a key event, and
then do literally hundreds of things with that information,
depending on the customer's needs. It can post information to a
website page, control cameras, change recording modes, fire relays,
turn on microphones, dial phones, send pages, play recorded
messages over the audio system, and run macros and other programs
that initiate even more actions.
While many implementations involve a
non-security system responding to a security system event,
interoperability works both ways. Authorized third-party systems
can also send commands to the security system. For instance, the
data on a newly hired employee can flow automatically from the
human resources system to not only the physical security system for
instant credentialing and door access, but also to the IT system
for instant assignment of network log-on rights and
permissions.
XML- and API-enabled security systems have
already begun to replace less advanced security systems that can't
talk or listen to other systems or that require the complex
code-level integration approach. It's not hard to see why both end
users and integrators are enthused: low project cost, quick and
easy implementation, measurable financial benefits, and intriguing
application possibilities quite an exciting combination.
|
What You're Saying