Project 45: Intelligent Airport Security Systems

sandpaperleadΛογισμικό & κατασκευή λογ/κού

31 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

78 εμφανίσεις

Project 45:Intelligent Airport Security Systems
Qifan Wang
Department of Electrical and Computer Engineering
University of Auckland
Auckland,New Zealand
Email:qwan082@aucklanduni.ac.nz
Abstract
—Baggage handling systems are familiar to
everyone who travels.But people rarely know what are
controlling them.In fact,people even more rarely know
that most of the baggage handling control systems were
not designed to be changing.We know that the security re-
quirements change so rapidly nowadays but if the baggage
handling systems cannot keep up with them,how can they
be safe any more?The answer is now at hand,design and
deploy new,lightweight and yet effective control systems
using function blocks.Function blocks are suitable,if not
best,candidates for building distributed systems such as
the control system for baggage handling.Their potential
plug and play ability makes systemupgrade and expansion
a much easier job than conventional systems.Coupled with
a 3D user-friendly control interface,this paper shows you
how the new system was designed,implemented,tested
and how it can be improved in the future.
Index Terms
—function blocks;3D interface;security
requirements;baggage handling systems;
I.
I
NTRODUCTION
Although the title suggests that the project focuses on
airport security systems,it is not feasible to explore all
aspects of securing an airport given the scale and time
constraints.Instead,the focus has been on the security
of the baggage handling systems.More specifically,this
project simulates the change in security requirements and
how well the BHS developed can adapt to it.
Building on top of an existing one,this project demon-
strates a simulated baggage handling system(BHS) that
can be modified,upgraded or redeployed much easier
than traditional ones.
During the project,functionalities with regard to se-
curity devices and further developing the user interface
were considered,designed and implemented.
A.
Motivation
The BHS system in majority of the airports are still
using the traditional distributed control systems.Because
of the nature of these systems,it is almost impossible
for them to adapt and expand[3].But nowadays these
systems are much behind on keeping up with the rapid
changes in security requirements.The IEC 61499 has
provided new directions and opportunities on designing
and implementing a much more agile kind of system.
And function blocks are the most suitable candidate for
building these new systems.listed below are some of the
characteristics of the traditional and the new intelligent
systems.
1) Traditional systems:

Slow to implement

High maintenance cost

Slow to change
2) Intelligent systems:

Modular

Re-usable

Distributed
B.
Related Work
Although the concept of function blocks is not new
any more,research on how the industry is adapting to
using them were carried out but only found a minority
of factories are currently using this technology to build
control systems.Even less companies are using them to
build the control systems of baggage handling.
However,Because this project is based on an existing
one,some of the functionalities were already imple-
mented and it provided a good starting ground for the
remaining functionalities to be designed,implemented
and tested.
C.
Project Aim
The project aims to demonstrate that a baggage han-
dling system implemented using function blocks does
not only require less resource and time to implement,but
also provides advantages over traditional control systems
in the fast changing world as today.
The overall aim of the project is to:

Implement full control and update in the 3D user
interface

Implement functionalities in function blocks that
simulate security devices
The project aims on achieving short and medium goals
in order to accomplish as much as possible.Therefore
an iterative implementation process had been adopted.
D.
Paper Structure
This report is organised as follows:Section II explains
the implementation of the system including all the as-
pects and components.Section III states the challenges
faced while the system was being developed.The end
product is shown in section IV.Section V suggests some
of the possible future additions that can be done.And
Section VI concludes.
II.
IMPLEMENTATION
A.
Design and Architecture
From careful study of the given system,the system
architecture design was determined to be a 3 - Tier
architecture with slight variances.It consists 3 modules
that work together in order for the whole system to
function.This kind of arrangement is preferable as it
is highly flexible.
Fig.1.The 3 - Tier Architecture
As shown in Fig.1,each layer of the system has
a specific responsibility,they then communicate using
pre-defined protocols which will be discussed in a later
section.In a 3 -Tier architecture,the top most and bottom
most layers cannot talk to each other directly.All the
communications have to go through the business layer
which controls the system and updates the user with the
system state.
When commands are entered in the presentation layer
by users,they get passed down to the business layer.
The control within the layer then determines what the
system needs in order to response correctly to the com-
mands,then passes commands that the hardware would
understand to make the change of state happen.Then
the hardware passes the feedback regarding the actual
event that happened (can be either job accomplished or
error) to the business layer.It will then be the job of the
business layer again to inform the presentation layer so
the users know if the commands were executed properly.
This design provides great flexibility.In the future,
only the specific layer needs to be changed if it is needed
where other layers can still function as is.
B.
System Components
One of the characteristics that made this project a
complex one is that each layer had to be developed using
different tools.
1) Presentation Layer:
The presentation layer of the
project consists of a 3D user interface that was developed
in Unity 3D game engine.It has the commands that the
users need to control the system.This interface does not
contain any information about the state of the system
or the positions of the bags on the belts.It only sends
and receives update information that is needed by the
business layer.
The set-up of the convenor belts were defined in an
XML file.When the systemstarts up,the file is parsed so
that Unity can render the set-up to initialise the system.
Shown in Fig 2 is a part of the XML file that defined the
final set-up of the project.For each section of the belts,
not only it defines its name,angle etc but also what is
connected before and after it.
Fig.2.A part of the XML file which define the set-up of the
conveyor belts
At this point of the project,it has been achieved that
one only needs to modify the XML file to change the
whole layout in the presentation layer.This defines the
advantages of having a 3 - Tier architecture.In the
future,if the interface is in need of a change e.g.when
new sections of convenor belts need to be installed,
simple changes made to the XML file will be sufficient
to implement the addition.However,because the XML
file only defines the set-up of the belts,the other core
functionalities such as communication and command
passing will remain unchanged.This again shows how
adaptable the system is.
2) Business Layer:
This layer can also be referred
to as the ”logic layer”.It contains the ”brain” of the
system,the function blocks.Every part that is shown
in the presentation layer is controlled by at least one
function block in the business layer.When commands
are received regarding a specific task,every part that is
needed to complete the action would be employed.And
the function blocks communicate constantly between
them to maintain the system state.
Since every piece of information has be processed by
this layer,there has to be corresponding function blocks
for every task.And as the types of tasks increase,the
number of different function block types will increase
too.
3) Persistence Layer:
This layer is usually the
database which the software system needs to access in
order to serve the information the user had requested.
However,for this project,this layer has been replaced by
the actual hardware such as the conveyor belts and photo
eyes etc.These hardware is where the function blocks
should have been deployed on and they will carry out
tasks that the function block has ordered them to.But
given the scale of this project,it was not feasible for
the hardware to be provided.Therefore it will not be
discussed further.
C.
User Interface
1) Design:
Initially,there were two user interfaces for
the system,one of them was a 2D interface(shown in
Fig 3) created by NXTControl where all the commands
were,and the other 3D interface was created by Unity
where only the system state was shown.This was due
to the fact that communication from the 3D interface to
the function blocks was not implemented.So in order to
control and view at the same time,both of them had to
be running.This was a major draw back of the system
and the project aimed to merge the commands in the 2D
interface into the 3D interface so the user can control and
view from the same window.Ideas of how the buttons
Fig.3.User interface in NXTControl
should be integrated into the 3D user interface had been
suggested and tested.One of the original plans were
using 3D texts as the buttons and dynamic menus pop-
up when they are clicked on.But since it is a 3D user
interface,the user might want to change the angle he/she
looks at it and the 3D texts would rotate with it.That
means the orientation of the menus would not have been
user-friendly,therefore it was then discarded.
Instead,a plan to have a static menu bar on the top
left corner was designed and chosen since it is more
user-friendly and efficient.
Fig.4.The menu bar in the interface
Shown in Fig 4 is the menu bar that has now replaced
the original one in the 2D interface.
Another requirement of the project is to add security
devices into the system as required.Therefore some
models of the devices had to be shown in the interface.
since Unity cannot develop models by itself,other tools
had to be considered to create the model.The tool chosen
for model building was Google Sketchup.It is free to
use,the functionalities are sufficient and easy to learn.
Fig.5.The X-Ray machine model developed in Google Sketchup
Shown in Fig 5 is an X-Ray model that was created
in Google sketchup and imported into Unity.The model
does does not have any
2) Implementation:
The menu bar was implemented
by writing a script in C sharp and attaching it to the main
camera of the 3D view.Because the camera represents
where the user’s eyes are looking from,the menu bar
will always stay at the top left corner of the screen even
when the view is rotated.However the script has to be
attached to the camera while it is being initialised,so
it had to be done by coding the attachment in the main
setup.cs file rather than in the development interface in
Unity.
After the X-Ray model was built in Google sketchup,
it was exported into a file.Then the file had to be
imported by Unity in order to be rendered.A ”prefab”
was created in Unity to take in the mesh data of the
model so that it can be instantiated in the setup.cs file.
At the moment,it is specified that the device is to be
added on the section where the name is ”T2.03”.So
when ”T2.03” is detected,its start and end positions are
used to calculate where the X-Ray should be and then the
angle of the belt is obtained to calculate the orientation
of the X-ray.Therefore the device will always be added
correctly onto ”T2.03” where ever ”T2.03” might be.
3) Testing:
Since the development was carried out in
a GUI interface,there was no special testing done other
than initialising the system and examining if the position
of the X-Ray is right and if the menu bar stay where it
should be.The function ”print()” was also used to print
out the x and y coordinates of the X-Ray model and to
print a test message when a button in the menu bar was
pressed.
D.
Control
When new components are added to the interface,they
will not have any function at all before the corresponding
controls are implemented in the business layer (ie.having
function blocks developed for them).
1) Design:
A Model-View-Controller architecture
was used for function blocks within the business layer.
The model module manages the behaviour of the real
hardware(e.g.conveyor belts),the controller module
receives the user command and manipulates the model
based on the command.However,the view module’s job
changed slightly since now it is freed from the job of
rendering the system state to updating the information
needed by the 3D user interface only.Therefore the
design of new basic and composite function blocks will
have to comply with this architecture.
Shown in Fig 6 is the function block built to con-
trol the X-Ray machine mentioned earlier.It was then
included in a composite block type that contained the
original hardware (e.g.belt and photoeyes).Once this
was done,a new type of conveyor belts section was cre-
ated,this was to ensure the rest of the sections(without
the X-Ray) that depend on the old type can still function
properly.In other words,a library entry was created
so in the future,when another section is to be fitted
with X-Ray,simply changing the type of function block
that controls it to the new type created will change its
behaviour.
Fig.6.X-Ray function block developed
2) Implementation:
The X-Ray function block’s exe-
cution control chart (ECC) is shown in Fig 7.
Fig.7.The ECC developed for a security device
This determines what the reaction of the function
block is at a specific stage.The ECC now specifies that
when a bag comes onto this section of the belt,the belt
will pause to wait for an external timer(set to 1 second at
the moment) to finish counting down,then it will execute
the algorithm called ”BagScreen”.When ”BagScreen”
has determined if a particular bag is dangerous,it then
starts and transfers the bag to the next section.The
colour of any unsafe bags is then changed to red on
the 3D interface to notify the user that his/her attention
is needed.
The algorithm shown in Fig 8 was written in
Struc-
tured Text
,the programming language for function
blocks in NXTControl.It randomly chooses a bag to
be unsafe and give it a new,large BagOutID so it can be
IF MOD(msSinceMidnight,3) = 0
AND BagInID >=2 THEN
BagOutID:= BagInID + 1000;
ELSE
BagOutID:= BagInID;
END_IF
Fig.8.X-Ray algorithm
detected by the interface.the randomness can be changed
if the number in the MOD function is changed.This is
only to test the functionality of the X-Ray machine block
because specific X-Ray machines might have different
algorithms embedded.
3) Testing:
The development environment of function
blocks is NXTControl.It has built-in testing/debugging
facilities to test the functionalities of the function blocks.
Firstly,when a basic function block such as the X-Ray
control is developed,it can be ran by itself only with the
tester providing the event input and the variables it needs
to execute the algorithm.
If the output of the basic block is correct and it is
now included in a system,a ”watch” can be added to
any composite blocks or CATs.The ”watch” shows the
variables it is receiving from other components of the
systemin real time so if the number or boolean is wrong,
it can be detected by the tester.
The X-Ray block was subjected to both of these tests
while being developed and passed both.
E.
Integration and Communication
As function blocks and the interface developed in
Unity are completely different,the integration and com-
munication between them were carefully planned.
Aclient-server-client architecture was chosen for com-
munication.The protocol that was chosen for com-
munication is User Datagram Protocol(UDP).Although
Transmission Control Protocol(TCP) was suggested and
considered,UDP was determined to be more efficient for
this project as TCP requires a link between the clients
constantly while the system is running.This requires
more resource and the performance increase was not
significant enough to implement the change.Therefore
the idea did not get included in the project.
When the original system was provided,function
blocks had the ability to update the user interface about
the position of bags etc but not vice versa.So two new
blocks were imported into to the business layer.One is to
act as the server,the other one acts as a client.Another
client of the system is in the 3D interface,when a button
is pressed,the client sends UDP packets to the server in
business layer,then the server sends the command to the
client within the business layer in order to make changes
to the model.
After this architecture was implemented,one of the
project’s aims:3D user interface with full control,was
finally achieved.Now the user is able to manipulate and
view the changes from a single window and the system
has the new function of X-Ray machines added.
III.
C
HALLENGES
When deciding what new functions could be added
to the system,the design had been changing when
they were experimented as a number of challenges
arose.some of the functions were not added due to
the limitation of the resources but the majority of the
problems were solved.Some of the problems that arose
and ultimately affected the design of the system are:
A.
Control
Function blocks had trouble parsing the UDP packets
sent to thembecause their programming language,Struc-
tured text,is a low level language.This created problem
while controls in from the 3D interface were being im-
plemented.Originally,the packets also contained some
strings which function blocks simply could not parse.
At the end,the server and clients were modified in such
a way that:commands sent from user interface only
contains boolean and they are passed to the event input
of the blocks.As soon as the function block receives a
packet,it sets the boolean field bound to it to be true
or false.The design ensured there is no information the
server needs to parse and it solved the problem of the
original design.
B.
User Interface
Most of the problems occurred when the models built
in Google Sketchup were being imported into Unity,
some of them are:

When the models were rendered,some of the edges
were transparent.

The objects were not able to be clicked on so the
dynamic menu attached shows up.
After careful researching[1],experimenting and debug-
ging,it was determined that,the dynamic menu scripts
and the models’ colliding boxes with the mouse pointer
were working properly.So the attention was directed to
the models themselves.It was then discovered that *.3DS
files do not act well imported into ”prefab”s in Unity.
After research and trials,another file type,*.fbx was
observed to perform better than *.3DS so the subsequent
models were all exported as *.fbx files.
There were also scaling and coordinates problems
while importing models into Unity but they were elimi-
nated after careful adjustments.
IV.
E
ND PRODUCT
Shown in Fig 9 is what the 3D user interface looks
like.The menu bar is on the top left corner of the screen
as designed and the X-Ray machine is on top of ”T2.03”
as designed too.The business layer is not shown due to
space constrains.
Fig.9.Final Interface
V.
F
UTURE
W
ORKS
The project at this moment is still open-ended,there
still exists a lot of possibilities for it to grow.Some
suggestions are:
A.
Fully Automated System Generation
At this stage,when new functionalities are needed,the
business layer still has to be modified manually.This is
time consuming and error prone,because when a new
function block type is created and included in a project,
all the connections have to be re-established and one
specific type might require quite a lot connections in
order to function properly.This will become even worse
when the systemreaches proper ”real-world” complexity.
It will not be efficient or even feasible if this is the case.
Therefore It is preferable that in the future,when
a new system is developed,only the XML file needs
to be modified and the parser can generate not only
the use interface but also the corresponding function
block controls in the background.Doing so will further
enhance and perfect the design and purpose of using
distributed systems such as function blocks.
B.
”Mini-Map”
When the system do get more and more complex,
using the zoom function might be a hassle as the user
might lose track of which part of the system he/she is
looking at.A smaller”map” of the whole system could
be displayed at the bottom right corner of the window.
It should have a red square showing where the user
has zoomed in to.This technology has been widely
employed by a number of different applications such as
Google Map.
[2]
Fig.10.Diverter
C.
Diverter
A diverter is usually needed for a baggage handling
system,it can be added so bags can be pushed onto
different loops or to different destinations.More im-
portantly for this project,the diverter will become an
extra security function.At this point,when the X-Ray
machine determines if a particular bag is unsafe,it can
not do much more than changing its colour.In the future,
it is desirable that if a bag is unsafe,the X-Ray can
order it to go through another loop so that it undergoes
another security machine.This requires the presence of a
diverter(shown in Fig 10) so the bag can be re-directed.
VI.
C
ONCLUSION
At the end,this project has achieved its initial re-
quirements.The fully functioning model can clearly
demonstrate that it is superior over the traditional system
in a number of characteristics that it was intended to
show.
A
CKNOWLEDGEMENT
I would like to take this opportunity to acknowledge
Dr.Valeriy Vyatkin for allowing us to undertake this
project.The lectures in SOFTENG701 he has given us
regarding function blocks have been very helpful and
provided the starting ground of this project.
I would also want to thank Jeffrey Yan for guiding
us through the original project and provide technical
support on the course of developing this one.
Finally,I would like to acknowledge my project part-
ner,Daniel Dawson,without his help,this project would
not have been successful.
R
EFERENCES
[1] (2011,September).[Online].Available:
http://forum.unity3d.com/forums/12-Scripting
[2] (2011,September).[Online].Available:
http://www.glidepathgroup.com/baggage-handling-systems-
gb
[3] K.T.C.Tranoris,“From requirements to function block dia-
grams:A new approach for the design of industrial control ap-
plications,” in
Proceedings of the 10th Mediterranean Conference
on Control and Automation
,2002.
[4] L.Ferrarini and C.Veber,“Implementation approaches for the
execution model of iec 61499 applications,” in
Industrial Infor-
matics,2004.INDIN’04.2004 2nd IEEE International Confer-
ence on
.IEEE,2004,pp.612–617.