Rotecting national infrastructure such as airports, historical

ond, they allow for file input of relevant informa-
tion for checkpoints or canines, such as traffic/pas-
senger volume by time of day, which can greatly
affect the security measures taken and the values
of certain actions. At this point we will discuss in
detail what each component consists of and how
they interact with each other. 
Interface 
The ARMOR interface, seen in figure 7, consists of
a file menu, options for local constraints, options
to alter the ac tion space, a monthly calendar and a
main spreadsheet to view any day(s) from the cal-
endar. Together these compo nents create a work-
ing interface that meets all the key re quirements
set forth by LAWA officers for checkpoint and
canine deployment at LAX. 
The base of the interface is designed around six
possi ble adjustable options; three of them alter the
action space and three impose local constraints.
The three options to al ter the action space are the
number of check points allowed during a particular
time slot; the time inter val of each time slot; and
the number of days to schedule over. For each giv-
en time slot, the system constructs a new game.
As discussed previously, the total num ber of
inbound roads and the number of checkpoints al -
lowed during that time slot determines the avail-
able actions for the LAWA police, whereas the
action space of the adver sary is determined by the
number of inbound roads. Thus, the system can set
up the foun dation for the Bayesian Stackelberg
game by providing all the actions possible in the
game. Once the action space has been generated, it
can be sent to the back end to be set up as a
Bayesian Stackelberg game, solved, and returned as
a suggested schedule, which is displayed to the
user by means of a spreadsheet. 
There are three options that serve to restrict cer-
tain ac tions in the generated schedule: forced
checkpoint; forbidden checkpoint; at least one
checkpoint. These constraints are intended to be
used sparingly to accommo date situations where a
user, faced with exceptional circum stances and
extra knowledge, wishes to modify the output of
the game. The user may impose these restrictions
by forcing specific actions in the schedule. In par-
ticular, the forced checkpoint option schedules a
checkpoint at a specific time on a specific day. The
forbidden checkpoint option des ignates a specific
time on a specific day when a checkpoint should
not be scheduled. Finally, the at least one check-
Articles
50 AI MAGAZINE
Figure 7. ARMOR Interface.

point option designates a set of time slots and
ensures that a checkpoint is scheduled in at least
one of the slots. 
The spreadsheet in the interface serves as the
main mech anism for viewing, altering, and con-
straining schedules. The columns correspond to
the possible checkpoints, and the rows correspond
to the time frames in which to schedule them. Up
to a full week can be viewed at a single time as seen
in figure 7. Once a particular day is in view, the
user can assign to that day any desired constraints.
Each constraint is represented by a specific color
within the spreadsheet, namely green, red, and yel-
low for the forced, for bidden, and at least con-
straints, respectively.
Matrix Generation and DOBSS 
Given the submitted user information, the system
must cre ate a meaningful Bayesian Stackelberg
game matrix. Pre viously we illustrated the genera-
tion of the action space in this game. Based on the
prespecified rewards as discussed earlier, we can
provide the rewards for the LAWA police and the
adversaries to generate a game matrix for each
adversary type. After the final game matrices are
constructed for each adversary type, they are sent
to the DOBSS implementation, which calculates
the optimal mixed strategy over the current action
space. 
To demonstrate the process, assume there are
three pos sible checkpoint locations (A, B, C), one
possible time slot to schedule over, and two check-
points available for schedul ing. Given this sce-
nario, the unique combinations possible include
scheduling checkpoints A and B, A and C, and B
and C, over the given time frame. We will assume
that check points A and B are highly valuable while
C, although not completely devoid of value, has a
very low value. Based on this information, a likely
mixed strategy generated by DOBSS would be to
assign a high probability to choosing action A and
B, say 70 percent, and a low probability to both the
other actions, say 15 percent each. Whatever the
mixed strategy actually comes out to be, it is the
optimal strategy a user could take to maximize
security based on the given information. This
mixed strategy is then stored and used for the actu-
al schedule generation. 
Mixed Strategy and Schedule Generation 
Once an optimal mixed strategy has been chosen
by DOBSS and stored within the system, a particu-
lar combination of ac tions must be chosen to be
displayed to the user. Consider our example from
the previous section involving three pos sibilities
(checkpoints A and B, A and C, B and C) and their
probabilities of 70 percent, 15 percent, and 15 per-
cent. Knowing this prob ability distribution, the
system can formulate a method to randomly select
between the combinations with the given proba-
bilities. Each time a selection is made, that combi-
na tion is sent to the user interface to be reviewed
by the user as necessary. So if, for instance, combi-
nation one was chosen, the user would see check-
point A and B as scheduled for the given time slot. 
In rare cases, as mentioned previously, a user
may have forbidden a checkpoint or required a
checkpoint. ARMOR accommodates such user
directives when creating its sched ule; for example,
if checkpoint C is forbidden, then all the probabil -
ity in our example shifts to the combination A and
B. Un fortunately, by constraining the schedule fre-
quently, a user can completely alter the mixed
strategy produced as the out put of DOBSS, defeat-
ing DOBSS’s guarantee of optimality. To avoid such
a possibility, ARMOR incorporates certain alerts
(warnings) to encourage noninterference in its
sched ule generation. For example, if a combina-
tion has zero or very low probability of being cho-
sen and the user has forced that checkpoint com-
bination to occur, ARMOR will alert the user.
Similarly, if a combination has a very high likeli-
hood and the user has forbidden that event,
ARMOR will again alert the user. However, ARMOR
only alerts the user; it does not autonomously
remove the user’s constraints. Re solving more sub-
tle interactions between the user’s imposed con-
straints and DOBSS’s output strategy remains an
issue for future work. 
When a schedule is presented to the user with
alerts, the user may alter the schedule by altering
the forbidden or required checkpoints, or possibly
by directly altering the schedule. Both possibilities
are accommodated in ARMOR. If the user simply
adds or removes constraints, ARMOR can create a
new schedule. Once the schedule is finalized, it can
be saved for actual use, thus completing the system
cycle. This full process was designed specifically to
meet the re quirements at LAX for checkpoint and
canine allocation. 
Design Challenges 
Designing and deploying the ARMOR software on
a trial ba sis at LAX posed numerous challenges and
problems to our research group. Some key lessons
learned during the design and deployment of
ARMOR include the importance of tools for ran-
domization, the importance of manual schedule
overrides, and the importance of providing police
officers with operational flexibility.
Importance of Tools for Randomization
There is a crit ical need for randomization in secu-
rity operations. Se curity officials are aware that
requiring humans to gen erate randomized sched-
ules is unsatisfactory because, as psychological
studies have often shown (Wagenaar 1972),

tải về 0.64 Mb.

Chia sẻ với bạn bè của bạn: