Proceedings of the 41st Annual IEEE International Carnahan Conference on

Security Technology; Ottawa, ON, Canada, October 9-11, 2007.

THE SECURE PERIMETER AWARENESS NETWORK (SPAN) AT JOHN F. KENNEDY

INTERNATIONAL AIRPORT

Ann S. Barry and David S. Mazel

Technology Service Corporation
962 Wayne Avenue, Suite 800
Silver Spring, Maryland 20910
{ann.barry,david.mazel}@tsc.com
ABSTRACT
The Secure Perimeter Awareness Network (SPAN) at JFK
is an integrated system of networked sensors for intrusion
detection, assessment, reporting, and video recording. The
system includes our Airport Security Display Processor
(ASDP) system, Pan-Tilt-Zoom (PTZ) cameras, an ASDP
Graphical User Interface (GUI), and a Common
Operational Picture (COP).
The ASDP system takes raw radar data from the ASDE-3
ground surveillance radar and monitors the airport
property and perimeter for any security breaches. The
system detects and tracks objects of interest beyond and at
the perimeter, and on the air operations area. If a tracked
object, such as a car, a boat (JFK borders Jamaica Bay), or
a person, breaches the user-defined perimeter, the ASDP
system issues an alarm, displays the intruder's position on
the GUI, and slews a camera to the location of the intruder
and tracks the intruder. The video is displayed on the
COP, an integrated geo-registered, situational awareness
display of all sensor data. The COP shows not only the
video, but also a layered display and interface for radar
data and other sensor inputs. Finally, SPAN records all
video for review and possible future prosecution.
Index terms: Airport security; airport security display
processor (ASDP); SPAN; tracking; common operational
picture; intrusion; detection
1. INTRODUCTION
Facility perimeter security is a key issue being addressed
worldwide by aviation, marine port, military, and
government agencies, as well as private companies. Many
of these agencies and companies are pursuing initiatives to
find an integrated system and method that will yield
realistic and cost-effective security. In response to the
need for integrated security systems that detect, assess,
identify, and disseminate information concerning possible
security threats, the Secure Perimeter Awareness Network
(SPAN) system has been developed and installed, and is
reported upon in this paper.
System Purpose
The basic security goals (detect, assess/ID, and
respond) are implemented by designing security systems
to meet the performance requirements: 360° coverage in
real-time; accurate detection, assessment, identification,
evaluation of events; and the resultant display of
situational awareness and secure notification of alarms to
first responders. SPAN provides accurate detection and
assessment of “targets of interest” through the use of
multiple sensors working in concert. Real-time, broad
range detection is achieved through the use of a fast-
updating radar system. The radar system provides
detections of human intruders, vehicles, and boats across
the facility and up to a several miles away, thus providing
time for assessment and reaction, sometimes called
"trading space for time." The radar system provides target
location to the video cueing system that will focus long-
range Pan-Tilt-Zoom (PTZ) cameras on the target for
visual assessment. Security personnel, using the
information provided by the Common Operational Picture
(COP) system, can see a target of interest while it is still
well outside the perimeter.
2. SYSTEM DESCRIPTION FOR CURRENT JFK
INSTALLATION
The full SPAN system is described in [7]. The installation
at JFK is a subset of the full system and while it contains
many of the subsystems of the full SPAN, it is not all that
there is to SPAN. In this paper, we present the system as it
is currently installed and working.
Figures 1 shows the system installation at the air traffic
control tower and Figure 2 shows the system architecture
at the Security Operations Control Center (SOCC) for
SPAN at JFK. We now examine the system and its
functions.
SPAN AT THE AIR TRAFFIC CONTROL TOWER
(ATCT)

1
The front end of SPAN ties in to the air traffic control
radar. The signals from the radar are analog and
consequently, we derive these signals and process them as
close to the equipment as possible to limit any attenuation
of the analog signals through the coaxial cable
connections. Thus, part of our system necessarily resides
near the radar and is, at JFK, in the air traffic control
tower.
Radar System
ASDE-3 (Airport Surface Detection Equipment) is the
FAA primary radar system for air traffic ground control of
airplanes and vehicles within the terminal area of an
airport. The radar operates in the Ku-band (15.7-17.7
GHz) and operates in all weather conditions. It can detect
aircraft from 500-feet to 24,000-feet in range and up to
200-feet in altitude. The system wavelength, pulse width
(40-ns), and rotational rate (1-Hz) are designed to resolve
aircraft at a minimum cross section of 3-m2. It has an
angular resolution of 0.25-degree and a range cell
resolution of approximately 18-feet [1]. See [2] for a
picture.
control
IP controller/
Camera Interface
1 video
Camera
Control
Tracks
Video Encoder
IP Network
Camera
Control
video
IP controller/
Interface
Camera
2
Figure 1: System architecture for installation at the air traffic
control tower. The video recorder is located in a separate part of
the airport.
The ASDP (Airport Security Display Processor) system
interfaces to the FAA's ASDE-3 ground surveillance radar
system to derive potential perimeter intrusion information.
It uses raw analog video signals of radar returns and
processes them to reduce clutter, detect intruders, and
display tracks. The ASDP decouples the air traffic control
functions of the radar from any security functions [3].
The ASDP performs constant detection and tracking. It
works in all-weather and is an organic sensor—it takes
data from the air traffic control radar already in place at
the airport. This radar has a 1-Hz update rate—it scans
once per second—so that the radar sweeps the entire
airport every second. Consequently, the ASDP system is
able to detect and track targets quickly and reliably over
the entire airport property.
In more detail, the ASDP system accesses radar video and
timing signals from the ASDE-3 receiver. The ASDP
Radar Signal Processor (RSP, not shown in Figure 1)
digitizes this radar video, performs detection processing,
and range and angular measurement of detected targets.
These radar reports are sent to an internal tracker. The
RSP and tracker are referred to as the Security Radar
Interface Unit (SRIU) and are housed within the same
physical unit. The tracker processes the radar reports into
consistent tracks that are sent over an IP-network to the
ASDP Display (see Figure 2) for operator viewing and
interaction.
Video cameras
In our SPAN system at JFK there are two Pan-Tilt-Zoom
(PTZ) video cameras mounted on the air traffic control
tower. Each camera has a video encoder that digitizes the
video output and sends the encoded video over the IP-
network to the SOCC for display. Each camera is IP-
addressable and controllable from the SOCC. Details are
below.
Network Video Recorder
ASDP ASDE-3 The digitized video is also sent via the IP-network to
Transceiver
SRIU digital video recorders. The video is recorded in a
rolling buffer for 30-days. The resolution is 4-CIF (640
Network by 480 pixels) in NTSC interlaced format. This video
Video Video can be searched based on date-time stamps, written to a
Recorder
DVD for long-term storage, and is of suitable quality for
Security use in legal proceedings.
Operations
Center
SPAN AT THE SECURITY OPERATIONS
CONTROL CENTER (SOCC)
The system diagram for the Security Operations Control
Center (SOCC) is shown in Figure 2. The SOCC is
manned constantly and is the command center for security
operations at JFK airport. There are three fundamental
subsystems here: The ASDP GUI workstation, the
Common Operational Picture (COP) and the camera
control system (not shown in the figure).
2
 Figure 3 is a screen capture of the COP display annotated
From
to give an indication of it functionality. The display shows
Control
Tower IP Network a photographic overview of the airport that the operator
Radar tracks,
may zoom-in to see particular areas of the airport in
Video control
ASDP GUI—COP data transfers CISCO Track data greater detail. The larger display shows warning zones
switch
(orange) and keep-out zones (red). Blue icons represent
Video
from
object, tracked by SPAN that have never entered a keep-
cameras
out zone. The SPAN system will issue an alert (warning)
ASDP Video Video
GUI Decoder Decoder
GUI,
or alarm (requires action) if a tracked object breaches into
Common radar tracks
Workstation Operational videos one of the user-defined alert or alarm keep-out zones. If
Picture (COP)
Joystick
Controller
Workstation this occurs, the SPAN system will issue an audible
KVM
switch (a)
alert/alarm, and will change the color and shape of the
tracked object icon on the COP display. An orange icon
Keyboard Mouse
Large Screen Display
mounted
represents an alert while a red icon is an alarm. Once a
on back rack tracked object has been declared an alarm, its icon will
remain red as long as the system continues to track that
target.
Figure 2: System architecture for SPAN at the Security
Operations Control Center. The COP supports selection by operator and display of
ASDP GUI Workstation various graphical layers. These layers include a control
layer, a track display layer, a CAD map display layer and
The ASDP GUI workstation was described at a basic level a photographic image layer. The control layer supports
in [5]. In essence, the GUI displays the radar tracks of operator selected track-hooking of the radar track with a
ground targets. In addition, the GUI system runs the selected camera to provide slaved video. The symbology
camera control program and allows the operator to of tracks is based on MIL STD 2525B [6]. Under this
manually control each camera. It shares, for the sake of standard unknown tracks are shown as squares, friendly
desk space, its keyboard and mouse with the COP display tracks are shown as circles, and threat tracks are shown as
(see the keyboard-video-mouse (KVM) switch in Figure diamonds. Thus, red tracks are, by definition, diamonds.
2).
The COP controls include pull down menu across the top
Common Operational Picture (COP) workstation and as well as duplicate context sensitive menus available
display within the screen display. Example controls include:

The COP is a system hosted on a Windows PC with a • Various display modes to show only threat
large screen display that integrates all sensors to a unified tracks, all tracks, or a hybrid mode where threat
display for situational awareness and command and tracks are bold while other tracks are shadows
control operations. In normal operations, the COP • Display of exclusion zones
displays a layered map of the airport with threat zones • Display of video windows or hiding video
overlaid. Typically, only threat tracks as well as the video windows
from each camera are constantly displayed. The COP may • Video footprints may be turned on or off
display all tracks, threat and non-threat, as desired. It may • Screen controls to drag the map and
interact with the GUI but it can also work independently corresponding tracks, or zoom in or out of the
of the GUI. display;
• Layer controls to show the security grid; range
With the COP, the operator may employ various control rings; CAD map underlay; photographic underlay
functions such as hooking tracks for data (threat level,
velocity of the track, location within the airport grid); The list of features and capabilities is varied and
hiding tracks; showing specific tracks from the GUI on the operator adjustable. Figure 4 is another screen capture
COP; adding sticky notes; and changing display showing additional features and functionality.
parameters among others. The camera footprints are
displayed on the COP to give an intuitive indicator to the
operator of camera location and the width of these
footprints changes automatically to indicate the zoom
setting of each camera.

3

Figure 3: The Common Operational Picture display shows a
high resolution map with camera videos that form a single
integrated security picture. Camera footprints are color-coded to
match the associated video windows and keep-out zones are
delineated by level of alert (yellow is warning, red is alarm).
Information for a hooked track is shown in the call-out bubble.
Figure 4: System display showing video tracks; exclusion,
warning, and keep-out zones; and track identifications.
3. CAMERA CONTROL SYSTEM
Overview
As noted above, there are two PTZ cameras mounted on
the air traffic control tower that are IP-addressable and
need to be controlled either automatically by the system or
manually by the operator. To control the cameras, we
developed a camera control system that:
1. Implements airport security policy for
investigation and tracking of intruders
2. Allows each camera to be automatically
controlled by the system
3. Allows each camera to be manually controlled by
the operator
4. Is extendable to multiple cameras
5. Is fault tolerant, that is, a “bad” camera does not
adversely effect control of any other camera
Part of the airport policy we implemented, for example, is
that when an intruder crosses a keep-out zone, say a boat
comes too close to the shore, the system will
automatically select the best available camera, slew that
camera to the intrusion, and follow the intruder.
Camera control system: Detail
The camera control system is built upon representing each
camera as a state machine. When a camera is needed, say
there is an intrusion, the camera control system issues a
request to view that intrusion. The system will rank the
available cameras from best to worst (see below) to
service that request. From this ranking each camera can be
queried as to its present state. If the camera is idle, for
example, then it is available to service the request and will
be directed to steer to the intrusion. However, if the
camera is under manual control then the camera will
report busy (airport policy is that operator control has
highest precedence) and the controlling software will look
to another camera for service.
The best (and worst) camera
Ranking a camera for assignment is not arbitrary, clearly.
For example, a camera close to a target is better than one
far away, given that both cameras are otherwise
comparable. Likewise, a target that is well within the
field of view of a camera (so the camera can follow it
without the target moving outside the camera plus panning
field of view) is better served by that camera than a
camera for which the target is at the edge of the field of
view and the edge of its pan region. In addition, when
ranking cameras for selection, we need not find an
absolute ranking because we only need a relative ranking.
That is, we seek the relative best camera from the ones we
have at the site and therefore, are not ranking them in an
absolute sense. Thus we come to the following scheme.
Each camera has a specific field of view and motion (pan)
from its mount to the perimeter (and beyond) of the
airport. Figure 5 illustrates this idea.
4
 While we have used an exponential decay, the behavior
Camera Coordinates could be any monotonically decreasing function. If a
Camera
(origin) camera has particularly good range behavior (it could
zoom far in) and another camera has a fixed zoom setting,
this can be well-modeled by using different functions for
Slant each camera.
range

Azimuth rank: From the mounted location, the camera

can pan a maximum and minimum amount. The limits on
East, 90-degrees panning may be camera-based, say the camera can only
North, 0-degrees pan through 90-degrees, or location-based, say the camera
target
is blocked by a nearby building so additional panning
while possible in movement only shows a wall. In either
Pan Max
∆Pan case, there is a minimum and maximum pan angle
Pan Min
associated with each camera. We model this panning
Pan
Neutral Pan_total = Pan_Max – Pan_Min behavior as a symmetric function with decaying value as
Position the position moves to either side of this neutral position.
Pan (azimuth) is measured in the ground plane
Figure 7 illustrates this idea.

Pan Appropriateness Function

Figure 5: Coordinate system for a camera. 1

The pan angle is denoted by the minimum and maximum

angle the camera can move to and see within the ground 0.98

plane. The distance to a target (or track) is the slant range

from the camera to that target. To determine the rank of a
Appropriateness Value

0.96

camera based on a given target, we decompose the

problem into two pieces, that is, we rank (or score) each 0.94

camera based on range and based on target azimuth. The

final rank is the product of these two individual ranks. 0.92

Range rank: We postulate when ranking a camera that 0.9

the closer to a target in slant range the camera is, the

better. Hence, we assign a range rank of unity to a target 0.88
0 10 20 30 40 50 60 70 80 90
at zero distance and then exponentially decay the ranking Pan Angle (degrees)

function with increasing distance. Figure 6 illustrates this

term. Figure 7: Azimuth rank of a camera. At the neutral position
(here, 45-degrees) the rank is unity and it falls as the target
Range appropriateness function requires the camera to pan from its neutral position to the target
1
location.
0.9

0.8
We have flexibility in choosing this function with the
0.7
overall motivation that targets within the center of
Appropriateness value

0.6
panning region have high (near unity) rank and targets
0.5 toward the end of the panning region have low rank. A
0.4 target outside of the panning region for a camera has zero
0.3 azimuth rank. Interestingly, if the camera has 360-degree
0.2 panning ability the azimuth rank is unity for any target,
0.1
thus, this function is a constant of unity value for all target
azimuths.
0
0 0.5 1 1.5 2 2.5 3 3.5
Slant range from camera to target (km)
Final camera rank: The final rank for a camera is the
product of the range rank and azimuth rank. We show an
Figure 6: Range rank of a camera. At zero distance the rank is
unity and this rank falls as a function of slant range between the example of this function in Figure 8.
camera and target.

5

Figure 8: Combined ranking function (appropriateness) for a
camera.
Comments: Our scheme for camera selection is scalable
from one to any number of cameras. What’s more, SPAN
is able to control cameras and assign targets to cameras at
least as fast as once per second. Hence the system can
handle fast changing situations. Lastly, our scheme is
expandable to support hand-offs between cameras and
targets so that we could have a continual video record of a
target as long as that target is within the field of view of at
least one camera.
4. ISSUES AND COMMENTS
Video tracking: In [4,5] we incorporated a video system
that analyzed a scene, detected moving objects, and then
generated its own tracks of these objects. Mobile Ravin
had a track fusion system to merge these video tracks to
the radar tracks. Here, we did not use video tracking.
Instead, we continually cue each camera based on radar
information and tracks. Thus, the video cameras are
driven from the radar system and the video system does
not detect objects nor track them. There is no need for a
fusion system to merge different sensor tracks. At the
conference we will show a video of how SPAN tracks a
car even as the car moves behind large, visually blocking
objects. Because the radar can see the car over the
objects, the video camera can follow the car as the image
of the car is blocked and then show the car as it emerges
from behind the blockage.
System expansion: SPAN is built as a modular system so
that additional cameras can be easily added to it without
changing the architecture and with simple changes to
configuration files. Other sensors, such as fence alarms or
trip-wires can be added simply and easily.
Multiple COPs: SPAN can accommodate multiple COPs
so that personnel in disparate locations can benefit from
the situational awareness provided by the SPAN COP. As
a follow-on to multiple COPs, SPAN can accommodate
multiple camera controller operators. For example, an
operator at the Security Operations Center now directs all
the cameras. If another COP were installed at another
location, we could allow users there to control cameras
along with other operators. Each user is assigned a
priority, based on facility policy, and the camera control
system would permit camera control based on which user
seeks to direct a camera.
5. CONCLUSIONS
The SPAN system at JFK airport is installed, working, and
used daily by operators who monitor the airport perimeter
for intrusions. This paper described the workings of SPAN
and detailed the Common Operational Picture as well as
the camera control system. Further details may be
obtained by contacting the first author.
6. ACKNOWLEDGEMENTS
The authors gratefully acknowledge the Technical Support
Working Group for support in the original development of
the Airport Security Display Processor system at the John
F. Kennedy International Airport, New York, and for
support and funding of SPAN at JFK. We also gratefully
acknowledge the Port Authority of New York and New
Jersey for their continued support and hosting of this
system and, in particular, Mr. Al Graser and Ms. Jeanne
Olivier. We gratefully acknowledge Mr. Mark Torbeck of
the TSA for his guidance and vision in the development of
this system. Finally, the authors wish to pay special thanks
to Mr. John Cimba of Axsys Technologies, Inc. who
worked closely with us during this development and to
Messrs. James Barron and Michael Murray of HBE, Inc.,
who worked closely with us to install this system and
make it a success.
7. REFERENCES
[1] Barry, et al., “ASDE-3 Radar Siting and Analysis Security
Study,” Final Report, TSC-W111-079, Oct. 2000.
[2] ASDE-3 antenna photograph available at:
http://www.tsc.com/images/contentimgs/ASDP2.gif
last accessed August 3, 2007.
[3] Mark Bond, Airport Security Display Processor: Software
Requirements Specification, TSC-W234-020, March 2005.
[4] David S. Mazel and Ann Barry, “Mobile Ravin: Intrusion
detection and tracking with organic airport radar and video
systems,” IEEE International Carnahan Conference on
Security Technology, Lexington, Kentucky, October 2006.
[5] Mobile RAVIN Design Document, TSC-W282-010,
October 2005.
[6] MILSTD 2525B is available at:
http://herbb.hanscom.af.mil/tbbs/R472/ms2525b.pdf
[7] Ann S. Barry and David S. Mazel, Secure Perimeter
Awareness Network (SPAN) System Requirements
Specification, Technology Service Corporation, April 6,
2007.