RFID and surveillance of festivals - VBN

RFID and surveillance of
festivals
Authors:
Kimmo V. Andersen
Steffen Raahede
Rune Ettrup
Sune S. Nilausen
Eric V. Ruder
Bjarke M. Lauridsen
Mathias Andersen
December 2011
Preface
This report is created by a group of 7 computer science students on their
3. semester at Aalborg University, Denmark. The report was made in the
period between the 2nd of September and the 20th of December.
The purpose of this report was to gain experience in the development of
an application with focus on; Investigating a realistic setting which includes
the involvement of 2 informants or more, using object-oriented analysis and
design, through prototypes and systematic evaluation of usability.
The report is created with LaTeX.
The development report is part 1. The academic report is attached at the
end of the development report as part 2. The C# source code and the compiled version of the product is attached with the report on a CD along with
the code used in the database ind the audio files from the interviews.
We would like to thank Nibe festival representative Peter Møller Madsen
and Aalborg Karneval representatives Michael Børsting and Klaus Bystrup
for acting as our informants.
Det Teknisk - Naturvidenskabelige Fakultet
Datalogi
Strandvejen 12-14
Telefon 96 35 97 31
Fax 98 13 63 93
Title: Project of Dat303e11
Theme:
Developing applications – from
users to data, algorithms and
tests – and back again
Project period:
P3, the autumn semester 2011
Project group:
d303e11
Authors:
Kimmo V. Andersen
Steffen Raahede
Rune Ettrup
Sune S. Nilausen
Eric V. Ruder
Bjarke M. Lauridsen
Mathias M. Andersen
Councilor:
Benjamin Krogh
Total pages: 92
Pages: 80
Appendix pages: 1
Synopsis:
Modern technologies contains a powerful tool for surveillance and service. In
this report we present the work we have
made, about RFID surveillance of festival and carnival guests. An interview
with relevant informants is the basis for
a problem statement. An analysis of
the problem and user area, through the
object oriented paradigm, showed that
RFID wristbands for guests at festivals
can be a very useful tool for managing the crowds, including many other
aspects.
To focus the work for the project, a
scope was created so that only the
main requirements of the software design were actually implemented, including a user interface, a way to give
the guards at festivals an overview of
the guests’ location and a way to represent data from the guests’ activity using a database.
An conclusion is made on our work,
where a test shows that our application fits into some real life needs, but
further work must be done to widen the
functionality.
Finished 20th of December 2011
The content of this report is freely available, but publishing (with reference) must be
with the approval of the authors.
Contents
1 Introduction
6
2 Informants
2.1 Interview with Aalborg Karneval
2.1.1 Summary . . . . . . . . .
2.2 Interview with Nibe Festival . . .
2.2.1 Summary . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
11
11
14
3 Problem Statement
16
4 Analysis
4.1 Technology Analysis .
4.1.1 Technology . .
4.1.2 Knowledge . . .
4.1.3 Organization .
4.1.4 Product . . . .
4.1.5 Summary . . .
4.2 RFID technology . . .
4.3 Choice of technology .
4.4 Project goal . . . . . .
4.5 Class definition . . . .
4.6 Event definition . . . .
4.7 Behaviour patterns . .
4.8 User interaction . . . .
4.8.1 Users . . . . . .
4.8.2 User description
4.9 Functions . . . . . . .
4.10 Focus areas . . . . . .
4.11 Summary . . . . . . .
17
17
18
19
20
21
22
22
23
25
25
27
28
30
30
31
32
33
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Design
5.1 Quality goals . . . . . .
5.2 Detailed system overview
5.3 Component architecture
5.4 User interface . . . . . .
5.4.1 The menu . . . .
5.4.2 Areas . . . . . .
5.4.3 Gates . . . . . .
5.4.4 Search . . . . . .
5.4.5 Guest . . . . . .
5.4.6 Bank . . . . . . .
5.4.7 Setup . . . . . .
5.4.8 Export database
5.5 Design principles . . . .
5.6 Summary . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Implementation of the Administrative Program
6.1 Program Design . . . . . . . . . . . . . . . . . . . .
6.1.1 The Administrative Program is a Subsystem
6.1.2 Layered Architectural Pattern . . . . . . . .
6.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Handlers . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 SOAPHandler . . . . . . . . . . . . . . . . .
6.3.2 RfidElementHandler . . . . . . . . . . . . .
6.3.3 AreaHandler . . . . . . . . . . . . . . . . . .
6.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Main Window . . . . . . . . . . . . . . . . .
6.4.2 Area Overview Interface . . . . . . . . . . .
6.4.3 Gateway Control Interface . . . . . . . . . .
6.4.4 Search Interface . . . . . . . . . . . . . . . .
6.4.5 Customer Manager Interface . . . . . . . . .
6.4.6 Setup Interface . . . . . . . . . . . . . . . .
6.4.7 Area Control Interface . . . . . . . . . . . .
6.4.8 Customer Control Interface . . . . . . . . .
6.4.9 Equipment Control Interface . . . . . . . . .
6.4.10 Area Statistics . . . . . . . . . . . . . . . .
6.5 Server side implementation . . . . . . . . . . . . . .
6.5.1 Database . . . . . . . . . . . . . . . . . . .
6.5.2 Communication . . . . . . . . . . . . . . . .
6.5.3 SOAP API . . . . . . . . . . . . . . . . . .
6.6 Checkpoint . . . . . . . . . . . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
38
39
40
41
42
42
42
43
44
45
46
47
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
51
51
51
52
53
54
55
56
56
56
57
58
59
60
61
62
62
63
64
67
67
67
68
70
6.7
6.8
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.7.1 Use Case Tests . . . . . . . . . . . . . . . . . . . . . . 73
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7 Conclusion
76
8 Future Works
78
5
Chapter 1
Introduction
Festivals, especially music festivals, attract a lot of people who wants to listen
to music and meet other music enthusiasts. A gathering like a festival rises
a problem regarding crowd control. First of all, entrances can be congested
by people and hour long queues can occur.
Festivals often celebrate a certain theme. A few examples would be art,
culture or music. In this project, the term ”festival” will be used only in
relation to a music festival. In Denmark there are more than 170 festivals,
twice as many as only 10 years ago [2], the largest, ”Roskilde Festival”, attracts around 100,000 people annually [3]. When attending a festival, the
participants usually have to buy a ticket to cover expenses such as administration, renting of the location, paying performers and more. Tickets are
often exchanged for a wristband which is less likely to be lost and is visible,
so security at entrances easily can see an attendant’s level of authorization.
Many attendants at music festivals gets free access by volunteering as assistants. Roskilde Festival, for instance, have 25,000 volunteers every year.
Music festivals have often multiple stages that participants can choose to
walk between, which can create moving crowds at each stage. Festivals, especially if it lasts for more than a day, often have camping sites, toilets, baths
and shops with food, alcohol and more, all of which generates crowd traffic.
To control these crowds, festivals usually use volunteers and other personnel
to overlook the crowds and admit participants into the festival areas. There
have been employed several different solutions to some of these crowd control problems such as RFID in wristbands to ease congestion at entrances [4],
however, many of these solutions remain partially or completely unsolved.
This report will investigate crowd control problems at festivals and carnivals.
The report will work with Radio Frequency Identification (RFID) technology
6
in order to see if this technology can solve or ease some of these problems and
develop a software product that uses this solution. As a part of developing
this software, an analysis will be produced which consists of contact with two
informants, in order to gain insight into the requirements they have as well
as the potential limitations they have. Second, an evaluation of the product
will be made in order to do quality assurance.
The interview with the two informants will be documented in chapter 2
along with the decisions made about why the informants were chosen, why
informants are a valuable asset in analysing a problem and what information
was gained through the interviews with the informants. The problem statement is located in chapter 3 where the main problem of this report will be
thoroughly formulated. In chapter 4, an analysis of the problem is described
with focus on product specification and technology choices. The chapter will
also contain designs of the software solution along with the project scope. In
chapter 5, the application is designed and a prototype of the user interface
is made. The documentation of the implementation of the administrative
program is located in chapter 6, where the development and design of the
application will be described. Finally in chapter 7, a conclusion is located,
defining how a solution was obtained, according to the problem statement.
In chapter 8, the project will be put into perspective and further work will
be considered.
The first informant is Aalborg Karneval in which around 30,000 people gather
and dress up according to a specific theme. They go through town in a parade, showing off their costumes and music wagons. Music wagons are home
made wagons, often with a speaker system attached to them. Some of the
music wagons are able to support several people dancing on top of them, others are smaller, made only for the sound system. This carnival is held once
a year in Aalborg, spanning over a weekend. After the parade ends, most
people move towards a park by the name of Kildeparken. Aalborg Karneval
sets up a closed party area with music stages, beverage and food stands in
this park. There is an entrance fee to enter this area, unlike the parade which
is free to attend.
The second informant is Nibe Festival which is a yearly festival which takes
place at the end of June or the beginning of July and spans over 4 days. It
is held at Skalskoven in the city of Nibe, northern part of Denmark. Nibe
festival have averagely 15,000 participants each day and 4,000 volunteers.
Nibe Festival is split into several areas which require different access rights
and the amount of participants in each area is limited by fire regulations
7
to averagely 3 persons per squaremeter. Some of the areas are dedicated to
stages and others are dedicated to camping areas and in each area there is
beverage and food stands which is manned by volunteers.
The learning goals [9] with this report are to:
• Analyse and model requirements in the object-oriented paradigm.
• Design, realize and test an application in the object-oriented paradigm,
understand and use the concepts and facilities in the paradigm and on
that basis construct an application of high internal and external quality.
• Perform systematic testing of the application and show that the application corresponds to the intentions and the users needs.
• Perform systematic evaluation of the user interface.
• Argue for choices in the activities of the development including explaining how requirements, architecture and the user’s needs are related.
• Develop a running application that solves the user’s problems.
• Describe and reflect on the applied development practice in the project.
8
Chapter 2
Informants
In order to get specific requirements regarding the project, there was arranged a meeting with two different informants where they were interviewed.
First is Aalborg Karneval and second is Nibe Festival.
The purpose of interviewing these informants is to find out how it is to
administer a festival and specifically what they require in relation to their
area. A vital question is knowing how many people are at the festival in total
and how many are at any given time.
The following questions need to be elaborated:
• How much security and how many guards are available as well as what
the safety procedures are.
• What kind of information is necessary about the attendees and how to
handle this information.
• How many checkpoints there are and how many areas needs to be
covered.
• The frequence of incidents with regard to troublemakers and people
who try to gain unauthorized access to areas they do not belong in.
For example people entering the backstage area without a backstage
pass.
• To know if the security personnel is moved around depending on how
many people are at any given area.
9
2.1
Interview with Aalborg Karneval
The first meeting was with Aalborg Karneval. They had attempted to integrate RFID technology before but were unable to do so because of costs
and technology insecurity. Aalborg Karneval were not quite sure the RFID
technology was stable enough or it would live up to their expectations and
needs. They were asked what they attempted to do with it and what their
main goal in implementing the technology was.
Their main interest was monitoring the participants general behaviour on
carnival day. They wanted to know when people joined the parade, where
the participants joined the parade and went afterwards. For example if they
entered the carnival area or they left for a pub. Aalborg Karneval wanted
to know the general flow of the parade and the flow at the entrance to the
carnival area to determine the average waiting time for getting in. Aalborg
Karneval had great focus on the overall experience, from the start of the day
to the end. They talked about the differences between a parade and a music
festival, where in a music festival you go to get a music experience. This
can then be used to analyse which artists are popular by seeing when there
are most people at the stage. That way, it is possible to improve the music
festival. That chain of thought is not applicable to the carnival - the participants go there to have a whole-day experience. What they are interested in,
is figuring out what people want to do during the day so Aalborg Karneval
can improve in those areas and improve the overall experience of the carnival.
Aalborg Karneval also described a problem regarding participants standing
in line to enter the carnival area after the parade is done. The entrance to
the carnival area is located at the end of the parade. Since a large part of
the participants at the parade is trying to enter the carnival area at the same
time, bottlenecks occur at the entrance. Aalborg Karneval described cases
where people had been waiting up to 4 hours to get through the entrance,
resulting in some people gave up and headed to a pub instead of the carnival
area. This ties into the idea that Aalborg Karneval wishes to improve the
whole-day experience, which will require to speed up the check-in procedure
at the entrance. One solution Aalborg Karneval attempted was to pre-sell
tickets. This did not solve the problem of people getting through because
even though some people had bought tickets in pre-sale, they were still required to stand in line with the people who needed to buy their tickets at the
entrance. Another problem which occurred at the entrance was that participants are not allowed to bring beverage through the entrance and into the
park. This causes a lot of people standing at the entrance to drink their own
10
beverage and therefore blocking the entrance for other participants. Aalborg
Karneval wants a solution to this problem as well.
Furthermore, Aalborg Karneval described the security procedures they had
in place. They told it was not their responsibility to have security personnel
at the scene because Aalborg Karneval had agreements with both the police
and the hospital in which they would have extra people on work that day. It
is the police’s responsibility to monitor the crowd in regard to fights, theft
and general criminal activity. The hospital look out for the general welfare
of the participants at the parade and at the carnival area. They also have a
group of volunteers known as ”Samaritans” who manage satellite positions
to help with smaller cases which the hospital does not need to be involved
in.
2.1.1
Summary
The following sums up the interview with Aalborg Karneval:
• Monitor the movement pattern of people attending the carnival
• Monitor the movement flow at the carnival
• Monitor the movement flow at the entrance to the party area
2.2
Interview with Nibe Festival
The second meeting was with the informant Nibe Festival. The first subject
discussed, was about monitoring the participants. Nibe Festival were interested in an automated system which is able to distribute guards to different
areas in the most efficient manner. They where also intrested in having the
computer system manage the number of people in a given area, making sure
it did not exceed the maximum number of people allowed in each area. Aalborg Beredskabscenter has estimated fire safety regulations and made the
first estimate on two people per m2 , which Nibe Festival found unrealistic
and could cause immediate shutdown of the festival. Nibe Festival made
some research and found out that Skanderborg Festival, a festival in Northern Jutland, got estimated 4 people per m2 in the front closest to the stage, 3
people per m2 in the middle and 2 people per m2 in the back, which Aalborg
Beredskabscenter approved for Nibe Festival as well.
The current wristband Nibe Festival uses is a fabric wristband without any
11
kind of technology. They have different kind of wristband types, One-day,
Part-out, VIP and a warning wristband. With the current fabric wristband it
is necessary that there are guards to check whether they are valid on the day
and whether they have access to the area. With 14,000 - 15,000 participants
it is usually difficult to achieve a constant flow and avoid bottlenecks. By
using RFID technology, the different kinds of tickets such as one-day, partout and VIP can be programmed into the RFID wristbands and hopefully
reduce traffic jam at every checkpoint. The RFID wristband location will be
logged so that the administration quickly can find the given participant or
festival volunteer in situations like finding trouble makers or a volunteer who
did not show up for work.
Nibe Festival does a great deal in keeping control with the trouble makers on the festival by giving the trouble makers a warning wristband that is a
supplementary wristband. That way, trouble makers are easily visible for the
festival guards. For the trouble makers to remain on the festival area, they
are forced to have a ”friendly” conversation with one of the security guards
once a day. The security guards want to keep the ”friendly” conversation
because they think it is a preventive method which has worked very well. If
the trouble makers do not show up for the ”friendly” conversation, the security guards have to throw the trouble makers out of the festival. Sometimes
though they have trouble finding a given trouble maker, which the RFID
wristband can improve by showing in which area the trouble maker are in.
Nibe Festival has gotten permission to make a trouble maker database but
only if the information can be accessed inside the organization. A trouble
maker database can have some benefits for future events.
The Security guards could also have a RFID wristband on them. That way
it would be easy to delegate them from the administration office by monitoring which areas could spare some security guards. Many of the security
guards are police officers in their daily life and some of the security guards at
the checkpoints today have a doorman certificate. The festival’s volunteers
could, like the security guards, wear a RFID wristband to show their location
and this way they could be delegated for needed assistance in a area. Nibe
Festival are experiencing that because the festival tickets are quickly sold
out, people sign up for festival volunteer jobs.
Nibe Festival has 4,000 festival volunteers and wish that their volunteers
have a good team spirit and work together as a team. Many applicants for
the volunteer jobs do not have the same purpose. Many people actually sign
up for volunteer jobs only to get a ticket to the festival and Nibe Festival
12
has a theory that some of the festival assistants are selling drugs, stealing
money or partaking in other criminal activity. Nibe Festival has had good
experience with the festival volunteers but bad as well. They have experienced the festival assistants being drunk or simply not appearing on their
shifts, which results in Nibe Festival taking their ticket for not doing their
job. Nibe Festival have trouble finding the unreliable volunteers in the volume of participants. An idea to locate the unreliable volunteers can be the
RFID wristband. They can see which festival area the volunteers are located
in, they can also deactivate their wristband so when the unreliable volunteer
is trying to go through a checkpoint, the ticket will not be accepted with a
green light but instead a red warning light.
Nibe Festival had a great interest in knowing how many are living in the
Lux-camp, which is for campers, and how many are living in Rolig-camp,
which is for people with tents, and in which time periods the camp areas are
most crowded.
Nibe Festival also discussed how it could be possible monitoring the general stage area in order to see how long a band would be able to keep the
audience. They wanted to know how many people were at a concert in the
beginning, how many people entered the area and how many people left
the area during the concert. By reviewing those statistics they could see
which bands were the most popular and which bands could not keep their
audience. In safety manner they also know in advance where to place their
security guards for future festivals. By knowing the amount of participant
in the festival areas, Nibe Festival could predict when there are participants
enough in a given area to put one of the popular bands on the stage.
Another subject Nibe Festival had interest in was advertising displays in the
bar area that should suggest the participants what they should buy, based
on the participants’ previous purchases. When their RFID chip is discovered
by a nearby bar, the advertisement will be displayed on the screen. The
advertising screens might increase beverage sales in the festival bars.
In the interview it was discussed how to make a non-cash environment. This
is because it is a hypothetical problem with thieves who steal from participants but also festival volunteers who steal from cash registers while they
work. One solution that Nibe Festival came up with was to make a money
account that the participants could insert money on while they buy their
ticket at home over the Internet. If they are running out of money on the
account they could go to a festival personnel stand who has the ability of
13
refilling the account by receiving payment through a credit card. Thereby
they could use their RFID wristband as a payment method in the beverage
bars and food stands. Dankort, Mastercard and other credit cards are also
non-cash but once their wallet is stolen the credit card is stolen. Thieves and
unreliable festival volunteers are not the only things that could be solved
with the RFID non-cash environment. Participants can put a limit on the
amount of money they use by only inserting the maximum amount of money
they want to use at the festival. This can be ideal for parents who have their
kids with them to the festival. That way the kids do not have to go around
with cash on them. This solution may also give a better crowd flow at the
beverage bars and food stands because the RFID chips only needs to run
over a scanner and no money needs to be exchanged.
Nibe Festival already have experience with non-cash solutions including money
cards which are distributed to the suppliers to use in the festival area. The
purpose with the money card is that the suppliers do not have to go around
with cash. The suppliers manage who has the card and when the festival
is over the supplier will receive an invoice with the used amount from Nibe
Festival. The money card has the same technology as liftcard with a portable
card terminal and is delivered by SKYdata.
Nibe Festival has a large amount of equipment such as cars, backhoe excavators and drilling machines that they want to monitor the position of.
The smaller tools like drilling machine and hammers can be lent by participant and therefore quickly disappear. Tools can be mounted with a RFID
tag and monitored just like participants. This way they can be located in a
specific area.
The last idea Nibe Festival had was to include smartphones in the system.
Most people today own a smartphone and they wanted to create groups
through a social network like Facebook which were based different interests.
The idea was an application that participants could make and join groups
from social networks like Facebook and give the participants a message when
a nearby event is starting etc. If a heavy metal group receives a message
when a heavy metal band is playing or when there is happy hour in a nearby
party-tent.
2.2.1
Summary
The following sums up the interview with Nibe Festival:
14
• Monitoring the participants in specific areas.
• How their current wristbands work.
• How they handle trouble makers.
• How RFID technology would be able to replace the current wristbands.
• Guard distribution system depending on how many people are at specific areas.
• How to monitor and control volunteers.
• Statistic of how the bands keep the audience.
• Making commercials on a nearby screen based on the participants recent purchase.
• A money system, so that cash would be removed from the festival.
• Monitoring the equipment in specific areas.
• A way of incorporating social networks like Facebook, possibly a group
system to know where other participants from a group are.
• Graphical overview of where everyone is located and where all their
equipment is.
• The ability to overview movement flow and to control movement by
closing specific gates or making them one-way only.
• Different types of tickets, mainly VIP, Normal and Troublemakers.
• A money system, so that cash would be removed from the festival.
• Making commercials on a nearby screen based on your recent purchase.
• A system to be able to tell people what is happening in the given area
they are located.
• A way of incorporating social networks like Facebook, possibly a group
system to know where other participants from a group are.
15
Chapter 3
Problem Statement
The two informants have large crowd of participants in common, which based
on their assessment is a source of congestion at any given checkpoint. In order
to address this problem it is necessary to develop a viable solution to ease the
congestion and obtain a smoother flow through the checkpoints. To prevent
the congestion, both the informants were wondering whether it was possible
to track the movement flow of the participants. Nibe Festival wanted this information in real time in order to act upon the information as fast as possible.
Nibe Festival suggested an expansion for the system which could be able
to track equipment, as well as the ability to issue different access rights to
the people at the festival location. Because the festival is offering different
ticket types which lasts from one day to all four days and some of these tickets give heightened access to the festival.
Nibe Festival also wanted a way of controlling movement flow by being able
to close specific entrances and exits or make them one-way only.
Another requirement they had was the ability to automatically distribute
guards among the festival areas, depending on crowd numbers in order to
have the necessary personnel available at any given time.
This leads to the following problem statement:
Is it possible to create a system, capable of monitoring a crowd using RFID
technology, with the ability to ease congestion at checkpoints by speeding up
the admittance process.
16
Chapter 4
Analysis
4.1
Technology Analysis
In this section the current system of both Nibe Festival and Aalborg Karneval
will be analyzed from a technological point of view. The analysis helps gain
insight into the procedures which are currently implemented with each informant in order to create an overview of how to improve these procedures.
The technology analysis is based on Jens Müllers article about technology
which contains four components; Technology, Knowledge, Organization
and Product. The four components in figure 4.1 are illustrated as pieces in
a puzzle to show they are tightly connected.
Figure 4.1: Technology concepts four components [7]
17
4.1.1
Technology
Technology covers the physical tools which the technology is a part of. This
includes work resources, work objects and physical labor. The technological
process is dependent on human interaction, otherwise it would not have a
purpose and therefore not be a part of solving any problems.
Nibe Festival
In order to attend Nibe Festival, participants need a ticket in order to get in.
Most of the tickets, if not all, are sold through a webshop before the actual
festival begins. Once a ticket is bought, the participant receives a digital
ticket which they then print out and bring to the festival. Because of this
the festival usually gets sold out before it even starts and therefor limits the
amount of tickets that can be sold at the entrance.
When the participant arrives at the festival with the printed ticket, it gets
scanned by a volunteer at ticket sale and each participant get a wristband
put on. This wristband functions as an identification representing the ticket
the participant has bought and gives admittance to the areas of which the
ticket apply.
When the participants crosses a checkpoint they are required to show the
wristband in order to be admitted through the checkpoint.
The way security personnel is distributed is through radio communication.
This communication is handled by the local security office at the festival.
When there is urgent need of extra security personnel at a given location,
the security office will be contacted and they will dispatch the required security personnel.
Aalborg Karneval
Participants at Aalborg Karneval have the ability to buy a tickets online
which is a new addition to the ticket sale. Typically tickets are usually only
sold at the entrance to Kildeparken. The participants receive a wristband
by mail which then acts as a proof that they have bought a ticket. The
participants put the wristband on at the carnival day and they are required
to show it when entering Kildeparken.
Security is outsourced to the local police which will patrol the park as well as
18
the parade and if trouble occurs Aalborg Karneval contacts the acting police
chief on site, who then dispatches officers to handle the issue.
4.1.2
Knowledge
Knowledge consists of the experience people have with the work resources
and work objects.
Nibe Festival
Nibe Festival is held once a year which creates problems regarding knowledge. The volunteers who use the work resources and work objects can not
be expected to maintain the knowledge about the daily operation of the festival. Therefore the volunteers must renew their knowledge which requires
resources, both in relation to time and mental energy.
Another subject in regards to knowledge is the trouble makers with minor
infractions. They are not registered between festivals and the security personnel are not able to point out trouble makers in advance.
At each festival the amount of allowed people in the festival area are based
on estimates which is subjective and no concrete data is available.
Aalborg Karneval
Aalborg Karneval is held once a year but in several ways it is not required
from the volunteers to have much knowledge of the daily operation. Most
of the management, which requires interaction beyond selling beverage and
food, is managed by a team which functions as the daily management. Aalborg Karneval has a limited use of technology at the carnival day. All purchases are done with cash and credit card and the participants receive their
wristband by mail if they have pre-ordered it through the webshop.
Aalborg Karneval do experience trouble makers but they are handled by
the police, which removes the responsibility from Aalborg Karneval and the
trouble maker loses their wristband and they are not welcome again.
The area of Kildeparken is designed to handle large crowds. This is an
advantage for Aalborg Karneval because there are escape routes in several
places and accessibility for emergency vehicles is good. This way they can
quickly get in and out of the park area.
19
4.1.3
Organization
Organization is the unification of the technology which consists of leadership
and coordination of labor division.
Nibe Festival
The organization of Nibe Festival is built on the principle of dividing responsibilities to a group of volunteers who have another group of volunteers who
serve under them. This is illustrated in the figure 4.2.
Figure 4.2: Organization of Nibe Festival
The elements Security, Area, Assistant, Stock & stands, Backstage
and Production are the main areas of work in the festival. These elements
each have one or more Team Leaders who are responsible for the given area.
Below the Team Leaders are a group of Chairmen. At Nibe Festival there
are over 300 chairmen who handle specific areas within the main area of
work. This works by the Team Leaders being responsible for all bars at the
festival and at each bar is assigned one or more Chairmen who handle the
daily operations.
The main reason for this division is that Nibe Festival has 4,000 volunteers
during the festival and several bars, stands and other areas which requires
an overview of the entire festival, which is not possible for a few people to
handle.
20
Figure 4.3: Organization of Aalborg Karneval
Aalborg Karneval
Aalborg Karneval is a small organization which has a department called
Daily management. They handle the operations of Aalborg Karneval at
the carnival day as well as the planning of the carnival. They also handle
the parade and the carnival area. On the carnival day the responsibilities
are distributed to Check-in responsible, Stock & stands responsible,
Area responsible and Stage responsible. They handle each of their areas of work and coordinate with the volunteers under each of these areas.
4.1.4
Product
The product is a result of the combination of Technology, Knowledge and
Organization which can be a physical product or a service.
Nibe Festival
To check-in a person, it requires personnel at each checkpoint to validate
that each participant has a valid wristband on to access the given area at
the given time. In order for the participant to be able to receive a wristband
there has to be a ticket sale who handles the attachment of wristbands to
the participants.
Aalborg Karneval
Aalborg Karneval focuses on people buying their ticket at the entrance to
Kildeparken. This requires personnel at the entrances, both to admit the
participants and to sell the tickets. Aalborg Karneval is trying to implement
a solution which enables the participant to buy their ticket in presale in order
to skip the line at the ticket-sale and enter directly to Kildeparken.
21
4.1.5
Summary
In both the cases of Nibe Festival and Aalborg Karneval, the way of buying
tickets is very similar. The participants are able to buy tickets online and
get the ticket exchanged for a wristband. They differ in the way security is
handled though. Nibe Festival handles security with their own security team
and Aalborg Karneval have outsourced the security to the local police and
only handle the checkpoints with their own team of volunteers.
Nibe Festival has several systems which are managed by volunteers at the
festival. This causes problems when the volunteers are forced to learn how
to use each systems every year. Aalborg Karneval is more limited from a
technical point of view because they are using physical validation of each of
the tickets the participants bring.
Nibe Festival has a more extensive organization than Aalborg Karneval.
Nibe Festival distributes the management into several smaller responsibilities with the title of ”Team coordinator” which is divided into even smaller
responsibilities with the title of ”Chairman”. Aalborg Karneval is limited to
a single person for each responsibility.
4.2
RFID technology
Radio Frequency Identification (RFID) is a technology that uses radio waves
to identify a RFID tag. The advantage of this technology is that it does not
require line-of-sight communication between the RFID reader and the RFID
tag which is a drawback of other technologies for example infrared communication.
This technology features two main components, a reader and a tag. The
reader works by scanning for a certain radio frequency in the electromagnetic spectrum. This is possible by having an antenna and a transceiver,
which represents the reader. Different antennas provide different reading
ranges to read the RFID tags, while the transceiver works as the main control unit [1]. This tranceiver exchanges data between the RFID tag in halfduplex mode [13] which means that it can only use one connection type at
a time, send or receive [11]. The way it works is the transceiver sends out a
requesting signal through the antenna. All the tags in the immediate vicinity
receives this signal and uses the power from this transmission to reflect its
own identification number back to the reader through the same frequency. It
should be noted that the system requires the reader and the tag to work on
the same frequency. Since the transceiver is swapping between sending and
22
receiving, it will after the signal is transmitted swap to a receiving mode in
order to receive nearby device’s data. The transceiver converts the reflected
data to digital data and then outputs this data to a connected device.
This reflection technique is based on using passive RFID tags. This is however only one type of RFID tag. The two main types of RFID tags are the
passive tag and the active tag [1]. The passive tag is normally smaller than
the active tag and does not require any power supply beyond the signal from
the transceiver. Because of this, the passive tag can generally only be read
and not written to and its readable range is not dependant on the tag but
instead on the range of the reader [12]. The active tag however features a
power source usually in form of a built-in battery. This enables the tag to be
read at longer distances since it is able to send out its own signal without the
tag itself being in range of the reader. The active tags also have the functionality of both read and write, so in some cases it is possible to customize
the data on the tag, whereas the passive is created with a unique ID from
the factory [10].
4.3
Choice of technology
To find a technology which could be used for monitoring participants, two
technologies where evaluated, Bluetooth and RFID technology. To find which
one of the technologies to choose, the pros and cons for each of the technologies where noted.
Bluetooth
Pros:
• Range of which communication is possible.
• Most mobile phones have Bluetooth.
• Has a unique Mac address.
Cons:
• Need internal power to work.
• If using a mobile phone solution it would drain the battery for power
fast.
• Would require everyone to enable bluetooth in their mobile phone.
23
RFID
Pros:
• Cheaper then Bluetooth enabled devices.
• Passive chip, does not need external powersource.
• Easy to work with.
• Has a unique ID number.
Cons:
• Not yet common in most mobile devices.
If the Bluetooth in mobile phones should be used to track people it must
be taken into account that not everyone has got a mobile phone with Bluetooth. A good thing about the Bluetooth technology is the range which
make monitoring people more precise based on the possibility to triangulate every participants location. Bluetooth is expensive if it is required to
track every participant and if the system would rely on the built-in Bluetooth capabilities in the mobile phones of the participants, it would only be
able to give a representative sample and not an overview of every participant.
The RFID technology is chosen because the chips are cheap and therefore
gives the opportunity to monitor a large amount of people at a low price.
The software languages chosen for this project is respectively C#, C and
php. These languages are chosen based on they were assessed to be the most
fitting languages for the system’s needs. C# is chosen because it, through
Visual Studio, gives an easy way of implementing a graphical user interface
in an easy manner and it natively supports the use of the SOAP protocol.
The programming language C is chosen to be used on the scanners at each
checkpoint because it is a fast language in terms of execution time and it
is easier to develop so it uses less resources than other languages through
memory management. The idea behind the checkpoints is they must run on
small embedded computers which puts limits in term of processing power
and memory. One drawback which is expected, is it does not have as many
supplied libraries as C# and php which requires more development time and
effort.
The language, php, is used because the system was designed to be based
24
on as much open source as possible which fell on the choice of using a Linux
server with and Apache installation to handle communication between the
checkpoints and client applications.
4.4
Project goal
The main goal of this project is to create a system that gives festival administrators the possibility to monitor festival participants and possibly equipment
in an easy fashion. This system will be used by people with varying degrees
of technological expertise. The users of the system is security personnel,
administrative committee of the festival and personnel at ticket sale. The
system will be designed to make sure all safety precautions are upheld regarding the amount of participants in a given area and the administrative
committee will use it to create statistics over their festival to see what people
are interested in and be able to see where crowd complications occur. Also
the system will be designed to validate whether the participants have the
necessary ticket to enter a given area.
This system will be created, by using a combination of personal computers in
order to administrate the system, which is capable of displaying information
visually and statistically. Smaller embedded computer devices will handle
the validation of participants and upload of information to a database server
for later use in statistics generation combined with RFID reading technology.
4.5
Class definition
The system is built around a few classes which handle the information regarding among other, participants, staff members and equipment, see Figure-4.4.
One of the primary classes is named ”surveillance objects”, which have two
subclasses classed ”person” and ”equipment”. The class ”Surveillance Objects” contains the most basic information to uniquely identify an object,
which is the ID number from the RFID tag. The subclass ”person” contains
information which is necessary to identify a person, and consists of name and
Social Security Number (CPR) . The choice of using CPR is based on the fact
that CPR is the most unique identifier about a single person even though in
rare cases, CPR can be subject to change. Everyone at the festival also has
a ticket type, which is stored as an attribute under the person class. Nibe
25
Festival stated the requirement that it should be possible to state whether a
person is a trouble maker or not, which is added as an attribute under the
person class. The subclass ”equipment” contains information necessary to
identify equipment, which consists of an equipment description.
The function of the system is to log whenever a RFID tag is passing by
a checkpoint and save this data along with information about which areas
the participant or equipment is moving from and to. This provides the system with access to a list of timestamps for each object, which then can be
used to show data of objects visually to the administrative user.
A specialization of the participant class, called the Worker class, only have
one unique attribute which is where the worker is supposed to be at the given
moment.
There is also an Area class. Each area can have zero or more surveillance
elements located inside of them at any given time. Each area can have one
or more checkpoints associated with them as well.
The Cross class is used to show whenever a person goes through the checkpoint. It has two areas associated with itself, the one the Surveillance Element is coming from and where it is headed. It also has a timestamp.
The Checkpoint class is a part of the Area class. This class has two RFID
Reader classes associated with itself.
Another class is the RFID Reader class. This class only has one attribute,
open or closed.
There is also an Administration class. It is the owner of the Area class.
It has the ability to change specific attributes of each area, decide whether
the area is open or closed, decide attributes of specific checkpoints as well as
closing, opening or making them one way only.
Finally there is the Account class which is the account of the participant
which is used to store money that the participant can use to buy food, beverages, items and more.
26
Figure 4.4: The abstract class structure in UML
4.6
Event definition
The system will need to be designed to handle a number of different events.
An overview is listed in Figure 4.5. One of these events is the Registration
which is the registration of a surveillance element to a person or equipment,
so they are connected. Similarly unregistration unregisters a person to a
surveillance element.
There is also the event Authentication which occurs when a surveillance
element approaches a gate and requests authentication to go through a gate.
This should happen automatically depending on the rules dictated by administration.
Another event is the physical opening and closing of gates, which, for instance, occurs when the festival starts or whenever administration feels the
need to open or close a gate. This event has been truncated to Open/close
gates.
Also there is the event Distribute guards which involves distributing guards
to an area, a checkpoint or something else.
27
There is also modification and removal of ID on a surveillance element. These
events have been truncated to Modify/remove ID.
Another event is the transactions involved with an account. A person can
deposit money to an account which is used to buy beverages, merchandise,
food, etc. at the festival. When a transaction occurs, the buying of a beer
for instance, money is withdrawn from the account. Alternatively a person
can withdraw the money to himself or transfer money to one of his accounts
or check the balance of his account. This is part of administration and the
event has been truncated to Account transactions.
Lastly there is the event Checkpoint which occurs when a person crosses
from one area to another via a checkpoint.
Events:
Registration
Unregistration
Checkpoint
Authentication
Open/close gates
Distribute guards
Modify/remove ID
Account transactions
Classes:
Persons
x
x
x
Equipment
x
x
x
x
x
x
Administration
x
x
Area
x
x
x
x
x
x
Figure 4.5: Events associated with this system
4.7
Behaviour patterns
The dynamic of the problem area is mainly connected to the behaviour of
the objects ”Surveillance Element”, ”Person”, ”Administration” and ”Checkpoint”.
The state diagram in Figure 4.6 describes the behavior pattern of the Surveillance
Element class. An element is born into the system when it is registered and
its state is of course ”active”. Whenever it goes through a checkpoint then a
crossing happens which updates its area and logs the crossing with a timestamp.
28
Figure 4.6: The Surveillance Element state diagram in UML
Figure 4.7: The Person state diagram in UML
The behaviour pattern of the Person class is described by the state diagram
in Figure 4.7. The class is born by registration and becomes a ”Participant”
which can check balance on his accounts, and make transactions. If a trouble
event happens the state changes to ”Troublemaker”.
In Figure 4.8 you see the state diagram describing the behavior pattern of the
Administration class. The class is involved with events such as ”Distribute
guards”, ”Registration”, ”Unregistration”, ”Modify ID”, ”Remove ID” and
”Check area”.
The Figure 4.9 shows the state diagram describing the behavior pattern of
29
Figure 4.8: The Administration state diagram in UML
Figure 4.9: The Checkpoint state diagram in UML
the Checkpoint class. This class is responsible for registering the approach
of a surveillance element and then checking whether it is allowed to gain
entrance, which decides the response.
4.8
4.8.1
User interaction
Users
There are several different people who will be using the software. These
people all have different roles in regards to the festival. E.g. a bartender
should not be able to close a gate at a checkpoint. To give a better overview
of these people and what functions they should be able to access in the system
30
see Figure 4.10.
Figure 4.10: Table of roles and their functions
4.8.2
User description
In order to clarify the differences between the individual roles at the festival
the following section describes the these roles and their responsibility.
The guards are responsible for the security at the festival. Their primary
function is to validate participants are wearing the correct wristband in order to be at the festival. Festival guards also have to stop any sort of trouble
which could arise.
The guard office is the central point of communication between different
departments of the festival guards. The guard office are also responsible for
contact with ambulances, police and other rescue personnel.
The safety officer is the head of the guards and the guard office. The safety
officer’s main purpose is to monitor the daily operations at the festival and
be the one to make the final decision in non trivial matters where the guard
office is unable to make a decision.
The secretariat is responsible for the daily operations at the entire festival regarding where to distribute commodities and in some cases handle the
contact between different departments.
The bartenders main responsibility is to service drinks and receive money
from the participants.
The financial manager is responsible for the economics at the festival. This
implies amounts of which commodities are distributed and to where, with
31
focus on the economical aspect.
The ticket sale is selling tickets to participants and putting wristbands on
the participants, whether they are buying a ticket at the festival and on participants who have bought a ticket before the festival.
The festival bank is responsible for the management of the participants
money. They are managing money deposits and withdrawals for the participants.
4.9
Functions
Our solution must be able to perform several different functions. Complex
functions will be described in detail, while straight forward functions will be
described more abstract to give the programmer a larger degree of flexibility
in regards to programming the actual function.
It must be able to...
• Fetch a list of users/equipments in a given area.
• Fetch a list of locations for a specific user/equipment.
• Assign different tickets to different users.
• Assign a warning to participants.
• Remotely control individual gates.
• Add money to a wristband.
• Modify the access rights of a given user.
• Allow participants to pay for items with the wristband.
For an overview of how the system works, see Figure 4.11.
The general idea behind the project is that there will be several different
checkpoints placed all around the festival area. At each of these checkpoints,
there will be a RFID scanner and a small computer connected to the RFID
scanner which is responsible for communicating with the rest of the system.
Each time a RFID tag gets picked up by the scanner, it tells the system
where he passed by and when, so that the system can log that information.
32
Figure 4.11: How the system works
Depending on the checkpoint, it will then await an answer from the main
system, in regards to if the user is allowed to go through or not. The user
client will be able to communicate with the database and get the requested
information it needs from there. The user client will also be able to edit some
parts of the database.
4.10
Focus areas
We must put our focus in the main functionality of the system, which keeps
track of where people are located. This is also a crucial building block in
the system, since all other parts are built upon this. Implementing tracking
functionality of equipment can be easily implemented once we have built the
base for the system, tracking people. Being able to display this information
is also a crucial part of the final system. If the data is not displayed to the
user, this would ruin the purpose of collecting the data in the first place. So
a great part of our focus will also be in displaying this data in the best way
possible.
A big part of this system is to make it able to distinguish between different types of tickets, and inform the checkpoints whether or not the given
33
person have the right to enter the given area.
Once we are able to inform the checkpoints of access rights, it would be
possible to implement a way to completely deny all access through a specific
checkpoint, making it easier to control the movement flow.
The requirement of automatic guard distribution will not have a very high
focus when we develop the system. This is due to the fact that it only serves
as an additional feature, since it is already possible to directly monitor the
assets. So this will be a functionality we might incorporate if we have time,
but there are other functions that have a higher priority.
Another implementation is the money system. This is also something we
would like to implement, but does not have the highest priority either. The
reason for this is that when we start managing persons money, there is a
lot of different issues we will have to consider. The security aspects of the
system become paramount for the system. Also, there might be some legal
aspects we need to consider in order to legally implement this.
Since the requirement of having commercials showing after a purchase, relies
on having a money system in place, this also does not have a very high priority in our system.
Having a backup power supply source for the system is also extremely crucial
if it were to be implemented in a real-life scenario. This however, is more
of a hardware solution rather than a software solution. This means that we
will make our system able to cope with a power outage, so that it can restore
its previous state once the power is back. But ensuring that the system is
always powered is something that has to be solved on the hardware side.
Due to our current equipment it should be possible to add this in some way,
since it is currently just powered by a USB connection.
We were also asked to implement some kind of location based event-viewer.
This was to be used mainly by the user after entering an area by having
some kind of connection between his RFID chip’s location and his phone.
This would open up for the possibility of sending information about the
events happening in the area the user is currently located in. Such an implementation would have to be implemented for a smartphone. Since this
does not supplement the main functionality of our system, this has a very
low priority for us.
34
However, if we were to implement a connection between the tag and the
phone, it would also be possible to incorporate it into Facebook in some way.
This would enable the user to find the location of his friends in a Facebook
group etc. But due to the previous implementation, this also has a very low
priority.
4.11
Summary
Through a technology analysis, it was possible to decide what kind of technology should be used for the system. Also, by creating a class defenition
as well as a detailed class structure graph it was possible to get a good understanding of the problem-area. With the help of an event table and state
diagram charts, it was possible to understand how the system should behave
and in which states it should find itself in. Based on the focus areas it was
possible to create a priority list and structure the work process from most
important elements to least important elements.
35
Chapter 5
Design
The purpose of this project is to create a system that is capable of tracking
the position of certain assets using RFID technology. Due to the fact that
there is a time limit for developing this system, a prioritisation must be
made in order to complete the most important parts of the system first.
That means we must prioritize the list of requirements from the informants
so that we develop the most relevant and most crucial parts of the system
first since some of these parts are a building block for other system parts.
5.1
Quality goals
This section covers some criteria for the application. A list of criteria is
given, described and finally summarised in a table to give an overview. The
overall idea with these goals is to be able to guide the design process of the
application.
User friendliness is considered important since the analysis showed that parts
of the workforce is not educated in their specific tasks and different people
will be using the application from one year to another. The application
should therefore be very intuitive for new users. It can be difficult to conclude on user friendliness but by following known methods and laws for good
user interface it is possible to create a good user interface.
Secureness is also valued as important because the database potentially will
contain some personal information about guests and the workforce. To enforce the importance of this aspect the system should be built in such a way
that any user only has access to information to that specific user, while illegal
or unwanted intrusion of the database must be handled in some way in the
36
program.
Efficiency is considered to become trivially fulfilled. This must not be understood as the system’s efficiency, but the application’s. The application will
be running on a platform where efficiency problems most likely can be solved
through hardware choices. The goal for this criterion is simply to make an
application that can run without hassle on a modern computer.
Correctness is important as the software is mainly developed for a rather
specific market. The development should not sacrifice the correctness of the
functionality, compared to what interest the informants have delivered to
the project. To reasonably take care of this criterion, the main functionality
interests from the informants must be clearly presented in the application
whereas other interests may be implemented in a lesser degree.
Testability is valued very important because the system itself seems to only
be used in short timespans every year. This means that the system and the
application have to be put together and tested as a routine event. For this to
work properly, the development of the application must include that every
part of the application can be tested.
Flexibility of the code is valued less important. The code for the application should always be flexible for object oriented programming but it is
not considered to be important compared to other aspects for this application.
Understandability of the application code is likewise a flexibility, also not
marked as important. Like the flexibility aspect, good object orientated
programming should be readable and meaningful but other aspects of the
application are again valued higher.
Criteria
User friendliness
Secureness
Efficiency
Correctness
Testability
Flexibility
Understandability
Very
imp.
Important
Less Irrelevant
imp.
Trivially
fulfilled
x
x
x
x
x
x
x
37
5.2
Detailed system overview
The system is to be composed of several different smaller components as
seen in Figure 4.11. Each component will be described in detail along with
its responsibilities, capability and use. It will also be described how these
components are associated and how they interact with each other.
The database is responsible for handling all the data about the festivalparticipants and all the different checkpoints. It basically stores all information that the system will be using. It delivers information to each checkpoint regarding the access rights of each festival-participant. The database
also contains information of each checkpoint, specifying whether or not each
checkpoint is open. It is also responsible for administrating whether or not
each user has the rights to view or modify data in the database.
The checkpoint manages the entrance to an area and scans all festivalparticipants RFID tag before they enter that area. Based on the information
it gets from the database about that specific festival-participant it will either
deny or allow access to the area. The checkpoint also constantly checks the
database to know whether or not that specific checkpoint is open or closed.
Each RFID wristband has the sole purpose of storing a unique ID that
can be read by the checkpoints. The ID is used to uniquely identify each
festival-participant so that the checkpoint it able to determine the access
rights of the correct festival-participant.
The user interface provides the users with a way to manipulate data from
the database through a graphical interface. It is able to add and remove
festival-participants from the database, along with modifying existing ones.
The modification include changing ticket types and modifying trouble maker
status. Managing money for each individual is one of its responsibilities as
well. The user interface also needs to fetch data from the database and display it intuitively to the user. This data includes information about each
festival-participant’s location, ticket type and trouble maker status. It must
also display an overview of where each worker is supposed to be and wheter
or not that is violated. Through the user interface it is also possible to open
or close a specific checkpoints.
38
5.3
Component architecture
The component architecture describes the system’s components and also
gives a rough overview of the system. A system can be designed based on
different patterns. Our system is based on the client-server pattern which
consists of a server component and a number of clients – connected to the
server.
Figure 5.1: The component architecture
The server component contains a model and a function component. The
model component’s responsibility is to maintain a technical representation
of the problem area and it is connected to the function component. The
model also contains a representation of the database. The function component is responsible for making the model accessible for actors in the scope.
The client components in the system are the RFID gateways and the administration. The RFID gateway scanners user interface is very simple and
include LEDs and registration of the RFID chip. The administration component’s user interface is a program running on a computer. The administration
client is linked to the server and it has both a user interface and a function
component. The client has a graphical interface the user can interact with.
The user’s interaction with the program calls functions, which then communicates with functions in the server component.
39
Figure 5.2: The model component
Timestamp has an association to both user and equipment. This association is a many-to-one, which means it is possible to have many timestamps
to user and equipment respectively. Timestamp is also associated to gateway with a many-to-one relation and gateway is associated to area with a
one-to-many relation. This gives a possibility to see where a user has been
at a given time. One user can have one ticket and therefore user has an
association to ticket with a one-to-one relation.
5.4
User interface
This section contains sketches for a user interface with the needed functions,
presented in a simple and effective way, combined with argumentation for
the most important aspects of the design.
40
Figure 5.3: Areas window
5.4.1
The menu
The main menu of the application will always be visible which makes navigation easy to master, safe to use and effective, as the user always have a
static reference point to go from. In the top half of the menu the general user
windows is located in a group of buttons in the top-left. They communicate
a starting point of the main functions in the application. In the bottom
of the menu two buttons are located together, the buttons text are cursive.
These two changes in the design translates to more specific and ”non-general
user” parts of the application. The buttons in the menu are located after
the individual window’s relative relationship to each other, for instance the
area overview is placed right next to the port-control window. The menu
is adaptive to the user. A bartender would probably never need to export
data or find a guest, so these buttons should in this case be removed to not
confuse the user and prevent misuse of the functions.
41
5.4.2
Areas
The main function of the application is located in this window: an overview
of all the areas, with the actual amount of people in the area including a
max amount of people allowed in the area and how much of the work force
is distributed in the area. As seen on Figure 5.3, a progress bar is added
to the individual areas. This is done to make the observation of the actual
amount of people in the area compared to the max amount of people quick
to visualize and easy to understand. The numbers for this progress is shown
since a misreading could occur if the user reads a progress bar of one area
but thinks of it as from another. The last number for every area is based on
the amount of employees in the area. This number would also be difficult to
relate to a progress bar, which again requires actual number to represent the
areas.
The individual area objects in the window is auto fitted in size so that an
unlimited amount of areas can be added, without any area objects leaving
the window and thereby optimizing the quality of the overview. This choice
could become a problem if for instance 50 areas are added to the application
but it is considered very unlikely that a such large amount of areas is needed.
If a very large amount of areas is needed in a given system, a bigger screen
with a higher resolution would make the problem less profound.
5.4.3
Gates
The port management, see Figure 5.4, is basically a subwindow of ”areas”.
The only difference is the content of every area object, which is changed to
a list of gate-connected areas. Next to all the listed areas is the open/closed
checkbox. This checkbox is built so that no confusion can exist from the chosen box. The two rows of boxes is placed underneath ”open” and ”closed”,
which constantly updates what setting has been chosen, and what has not.
5.4.4
Search
This window, see Figure 5.5, is based on a search function with filters. The
search bar will search on anything inside the database, unless restricted
through the filters. The reason for the time span filter is that the user have
interest in the activity of a given item or person inside a time span. But this
function would be complex to master if it based on a text-code inside the
search bar itself. The same goes for area and type choice. The user might
42
Figure 5.4: Gate window
not know exactly which word to use in the search bar alone, but with a presentation the user can easily browse for the correct words. The person/item
filter is useful for wider searches, for instance if all activity of all items in a
area have interest.
The search bar contains a greyed out text that gives the user some additional
ideas for search terms.
The search result window adapt to the search items found to minimize the
clutter of the window. The phone number row will for instance not appear if
only items has been returned. Every result list can be sorted by given rows
to optimize the usefulness of the list.
Every person returned in the search can be double clicked or right-clicked to
take the person’s ID to the ”guest” window.
5.4.5
Guest
This window, see Figure 5.6, is based on scanned IDs from wristbands or
the ”search” window. The function of this window is to add, remove or edit
the information bound to an ID, change the ID, ticket type, add warnings
or make the wristband inactive. The Information section will adapt to the
43
Figure 5.5: Search window
existing information bound to the ID. If the user want to add information, the
button ”add/edit” will present a simple pop-up windows with a form to add,
remove or edit information. The ”comment” section is a text field, where the
user can add any comment they want. The buttons ”give warning”, ”new
wristband” and ”turn off wristband” will add a line of information in the
comment field, as a log over the actions done to the ID. This gives a simple
and effective way to keep a relationship to the person’s actions.
The ”new wristband” button will also prompt a pop-up that requests a new
ID from a scanned wristband, in order to avoid faulty use of the system.
5.4.6
Bank
This window, see Figure 5.7, contains a very basic function. When an ID is
scanned from a wristband the ID and the balance of money related to the ID
is shown. From this point the user can add and/or subtract an amount of
money from the ID. The chosen action is either terminated with the ”cancel”
button or performed with the ”transact” button. The two functions add
and subtract is separated graphically to avoid misunderstandings with the
layout of the text fields. The ”transact” and ”cancel” buttons is located in
44
Figure 5.6: Guest window
the middle in a top down format, to communicate that the actions of both
buttons is performed on both functions. Right above the button ”transact”
is the final outcome of either functions. This is simply done to help the
administrators communicate the costumers resulting money-balance.
5.4.7
Setup
This window and contains two sub-menus, ”area”, see Figure 5.8, and ”RFID”,
see Figure 5.9. Both menus contains setup functions for the problem area.
The procedure of ”areas” follows an intuitive thinking, where you have to
create two or more areas to make a gateway between them. All other options
are referred to through the name of the area. A list is chosen to contain
all the different areas to make the overview easier. To delete or edit the
attributes of an area, the user clicks on an area from the list and the options
is shown in the form above.
The RFID-setup menu contains relevant options that can be changed and
modified as the user might want to. All RFIDs are split in two groups: persons and items. A person is defined through its type, so that an employee
and a partout guest is a ”person” and will therefore both contain information
45
Figure 5.7: Bank window
and access rights. On items, the ”access to” option will be forced to ”all” so
that no items can be denied through gates. To link IDs to the type, the user
can either type in one ID, an ID range or scan a package of RFID. Again a
list in the bottom of the window shows all the added types, where a click
on an item will show that item’s options and information right above in the
form.
The ”delete RFID” button deletes the type. The button is located in the top
so the user will relate the button to the information in the form and not the
list itself. The ”save” button on the other hand, is located right above the
list which gives a more combined effect of the information in the form and
the list. The location of the button is like the area-setup window, to enforce
uniformity and overview.
5.4.8
Export database
This button have no effect inside the application, as it simply exports all the
data from the database into an open file container where statistics can easily
46
Figure 5.8: Area setup window
be built from.
5.5
Design principles
In the design we have chosen to make use of several design principles in order
to improve usability. One of such is consistency, where it is important to be
consistent in the use of design features. For instance if you look at Figure 5.4
and Figure 5.3 the layout is quite consistent.
Another principle is to give users feedback on their actions. To enhance
the users feeling of control, it is important that the interface will let the
users know the response to their actions. For instance if you press a menu
button, it gets highlighted to let the user know that they successfully clicked
it.
Visibility of what is possible is also quite important. For instance if you
47
Figure 5.9: RFID setup window
look at the search field in Figure 5.5 you can see it is possible to search for
several different things. This ensures that people are able to recognize what
they are able to search for.
The search field also accommodates flexibility. People have different interests
and experience and will be searching for different things in many different
ways, especially depending on which piece of informationt they have and
which they are looking for.
5.6
Summary
In this chapter we made some goals for the application to help focus design
and implementation in the wanted direction. The application is designed and
defined through several diagrams to help the overview and understanding of
48
the functions. Lastly a prototype of the user interface is created and design
considerations is presented.
49
Chapter 6
Implementation of the
Administrative Program
Figure 6.1: Program goal
The picture on Figure 6.1 is what the program should look like once
the development process is completed. It should be a really simple, yet
50
informative user interface and must be extremely simple to navigate. The
goal is based on the information that was acquired during the analysis phase
for the graphical user interface. This chapter is dedicated to describing how
this goal is achieved through a detailed description of the design process
along with an explanation of each implementation.
6.1
Program Design
As mentioned earlier, the whole system is based on a client-server architectural pattern. The administrative program is a client component in the
system. It connects to the database, which is the server-component in the
system. The system is built around the idea that no clients have connections
to each other. This means that if there is a need to edit information about
specific customers, areas or gateways it must go through the database to
achieve this.
6.1.1
The Administrative Program is a Subsystem
The administrative program is by nature a subsystem of the main system,
because it is a component that communicates with another component: the
database. This allows the program to have its own architectural pattern as
long as it achieves the desired functionality. By doing so, the development
process is eased significantly which enables the possibility of dismantling the
main task of this program into even smaller tasks.
6.1.2
Layered Architectural Pattern
It was decided that the program would use a layered architectural pattern to
ease implementation and separate functionality. As can be seen on Figure 6.2
the program is divided into three component layers. All the components will
be described in detail later in this chapter.
The interface layer consists of all the interface components used in the
program. These components are the components responsible for displaying
all relevant information through a graphical user interface. In accordance to
the layered architectural pattern this layer is not allowed to access the model
layer directly - it must go through the functions layer.
The functions layer is composed of different components which each manages
different aspects of the problem domain. This layer provides functionality to
51
Figure 6.2: The Layered Architectural Pattern
the interface layer. It then communicates with the model layer according to
the request from the interface layer.
The model layer is actually an interface to the rest of the system because it
is the only connection to the database. But because all information to and
from the database goes through this component, it can also be seen as the
model component in this architecture. This also eases implementation because whenever information is needed about specific objects in the problem
domain, this layer is accessed. Only the functions layer can access this layer.
6.2
Classes
Implementation of the classes was based on the class definition in section 4.5.
The main classes SurveillanceObject, Person, Participant, Worker and
52
Equipment are all basically unchanged compared to the original class definition, with some minor modifications. A few extra attributes were added
such as a string called ”Comment” and a date called ”DateRegistered” these were added to the SurveillanceObject class since these attributes
can exist in any of the other subclasses. A ”PhoneNumber” attribute was
also added to the Person class, in case this was needed.
There was another change that was made was to the Checkpoint class. Originally the idea was to have a checkpoint class contain two gateways: from and
to specific areas. Instead, a Gateway class was created to contain every individual gateway, describing a one-way connection from one area to another.
This ruled out the need for the checkpoint class, since it would be possible to
run through all gateways to find the exact gateways associated with an area.
Several attributes was added to the Gateway class including the following
attributes: Open, AreaFrom, AreaTo, Description and a unique GatewayID.
The Area class is also changed considerably from the original class definition. This class have a number of new attributes: MaxNumberOfPeople,
NumberOfEmployees, AreaID, Description and NumberOfPeople. The class
also has a few List attributes including ConnectedGateways, ConnectedAreas
and GatewaysOut. These three lists were created since there were difficulties
navigating through each area object. By adding these attributes it became
much easier to develop the program. All these attributes are needed to be
able to represent an area and easily navigate through each class.
An overview of the updated class diagram is shown in Figure 6.3.
6.3
Handlers
Different handlers were created in order to distribute the different functionalities required by the program. Each handler is responsible for handling
these functionalities for a certain class. These handlers include SOAPHandler,
RfidElementHandler and AreaHandler. Both RfidElementHandler and
AreaHandler have some methods in common: Add, Delete and Modify.
Each method takes an object of the given class as a parameter, e.g. the
Add method in RfidElementHandler takes either a Person or an Equipment
object as a parameter and creates the relevant object. This makes it easy
to create, delete and modify content since the entire, and already created,
object is passed.
53
Figure 6.3: The detailed class diagram with attributes
6.3.1
SOAPHandler
The SOAPHandler is the ”model” of the previously described layered architectural pattern on Figure 6.2. This handler’s purpose is to create a communication from the program to the database. Having this handler provides a
way to easily retrieve data from the database without having to know how
to directly communicate with it. A good example of this is the GetGateways
method, which takes an area ID as parameter. This method returns a list
of all gateways associated with the given area ID by running through the
information from the database.
Most of the methods contained in the SOAPHandler basically converts the
data from the database into objects usable in the program. In other words
the SOAPHandler is responsible for interpreting data received from the SOAP
client to something the rest of the program can understand. The SOAPHandler
is merely an encapsulation of the SOAP client, which keeps it isolated from
the rest of the program.
54
AuthHandler
As an extension to the SOAPHandler the AuthHandler was created. This
handler’s purpose is to handle login information to the system and pass this
to the SOAPHandler. Having this as a separate class provides an easy way to
change login methods to the database if this is needed. The handler consists
of two main methods: SetUsername and SetPassword. These methods refer
to private properties in the class which prevents access to the username and
password outside this scope.
6.3.2
RfidElementHandler
The handlers for the surveillance elements is mostly divided into two methods. This is necessary since the class Person and Equipment do not have the
same attributes and therefore need to be handled differently. This is done by
having overloaded each duplicate method to take a different parameter, e.g.
when adding a person the Add method has a Person object as parameter,
while the Add method for adding an equipment has an Equipment object as
parameter.
Handling these objects requires some additional methods including SearchPerson,
SearchEquipment, GetTimeStamps, GetRequiredLocations and SearchInAreas.
The SearchPerson method is used to search a person by entering any of
the information originally provided by the user as a search criteria. This
method returns a list of all Person objects that match this search criteria.
SearchEquipment does the same except it returns a list of Equipment objects. GetTimeStamps returns a list of time stamps for a given element, each
time stamp representing a movement from one area to another along with the
time of this event. It was necessary to implement GetRequiredLocations
into this handler since Worker inherits from Participant and therefore also
uses this handler. This method returns a list of time stamps defining when
and where the worker is supposed to be. SearchInAreas is used to retrieve
every person who is currently located in the given area(s).
The idea behind the RfidElementHandler was to add more functionality
than is currently implemented. The thought behind it was to have methods
such as AssignWarning, Deposit and Withdraw money, so that the logic
would be handled by the handler instead of having to call a modify method.
E.g. if AssignWarning was called, the handler would know the logic behind
that method. It would know that it would have to assign the TroubleMaker
property to true and assign the given comment to the ”Comment” property.
55
At the moment this is handled through the Modify method. While most
of the currently implemented methods work as intended, implementing such
smaller methods would simplify the process. These methods are currently
not implemented due to time constraints, as described earlier. Deposit and
Withdraw money was not a high priority and was therefore not implemented.
6.3.3
AreaHandler
The AreaHandler is responsible for managing the areas in the festival. As
mentioned before, this class also has the Add, Delete and Modify methods. But these methods differ from the other handlers in the way that a
lot of logic is actually implemented in them. While the class does have
the same methods for adding, deleting and modifying gateways, adding and
deleting are only used by the handler itself while adding, deleting and managing areas. This simplifies area creation and deletion since the handler is
responsible for creating and deleting all relevant gateways. There are two
other methods in this handler: the GetAreas and the GetAreaDescription.
The GetAreaDescription method returns a string with the description of
the requested area. GetAreas simply returns a list of all the areas in the
database.
6.4
Interfaces
The interfaces are all responsible for drawing the information gathered from
the database in a nice and organized fashion. Whatever is shown on screen
is a result of a call to one of the different interface components. These include: MainWindow, AreaOverviewInterface, GatewayControlInterface,
SearchInterface, CustomerControlInterface, AreaControlInterface and
the CustomerManagerInterface. They are each responsible for a certain
area of the interface.
6.4.1
Main Window
This is the main window that loads up when the program starts. The main
window was designed based on the user interface analysis in section 5.4. All
user controls are placed on this window. Each of the remaining interface
components simply gets a shared panel to fill and that panel is located to
the right of the buttons in the main window. The main window is in charge
of loading up the relevant interfaces depending on which button is clicked,
thereby calling the interface that is responsible for managing that specific
56
aspect of the program. The main window is a menu for all different aspects
of the program. It is here the user chooses what to do with the program.
6.4.2
Area Overview Interface
Figure 6.4: The Area Overview Interface
The AreaOverviewInterface Figure 6.4 is responsible for drawing the
panel with all the information about a zone, including area name, people
count, max number of people and number of employees. It also shows a
progress bar depending on how how many people are in the given area. It has
a panel for each of the areas in the database. This panel is not interactive.
This is only here to simplify surveillance. A problem here was that the
information generated on the screen only represented a certain moment. It
would be more benificial if this information was constantly updated. This
problem was solved by adding a timer into the constructor of the panel that
updates itself every 30 seconds, so that the information is as new as possible
without abusing the server.
57
6.4.3
Gateway Control Interface
Figure 6.5: The Gateway Control Interface
The GatewayControlInterface Figure 6.5 is responsible for managing
all the gateways in the database. This displays a panel for every area in the
database and shows each and every gateway in each area. From this interface
you can then decide which gateways are opened or closed. Note that each
panel displays what gates lead away from it. That means it is possible to
configure a couple of gateways in such a way that you are allowed to leave
the area but not enter it again. This gives a huge amount of flexibility for
the user. This is accomplished by calling the GetAreas method from the
AreaHandler. It then iterates through all the areas in the list while iterating
through all the gateways that lead out of each area.
A problem here was that there was no simple way to relate each button
to its respective gateway. There were two solutions: one was to create a
class that derives from the radio button that implements an Attribute called
Gateway. Then, everytime a button was added, its respective gateway would
58
then be added to the control and that class would be added to a list of
controls. Once the saved button was clicked that list would iterate saving
the value of the open radio button to each respective gateway and calling
the ModifyGateway method from the AreaHandler. The other solution was
to simply create another class called GatesAndRadio with two properties, a
Gateway and a RadioButton. All radio buttons are added to a list and then
the same thought process as before is applied. That was the solution that
was implemented because of its simplicity.
6.4.4
Search Interface
Figure 6.6: The Search Interface
The SearchInterface Figure 6.6 is responsible for displaying search results on screen. It is possible to choose between the different types of surveillance objects to search for, as well as searching for a multitude of different
attributes such as RFID ID, CPR number and someone’s first or last name.
Once it receives the list of elements from the RfidElementHandler, it creates the columns depending on what type of object the person searched
59
for. The program then iterates through the list, adding all elements found
to the table. It is then possible to edit each element of the table and
then submit for change. Every time one of the rows is edited, it is added
to a list of changed rows, which is the list that iterates and submits for
changes through the RfidElementHandler. It is also possible to right click
on any of the elements and then choose to manage them, which opens up
the CustomerManagerInterface with that specific persons information displayed.
Later on in the development process it was noticed that the strategy pattern could have been used when implementing how the Data Grid Table
behaved depending on what kind of results it needed to display. Here, the
different classes should have overloaded a few methods called GetColumns,
CreateRow and ManageElement. This way the program would just have to
call searchResult.GetColumns to create the right columns to represent the
necessary data. This could be followed by a searchResult.GetRow in a foreach loop that runs through all of the elements found and uses them as a result
of the search. Also, overloading the ManageElement method would make that
method responsible for loading the relevant Customer/Equipment Manager
Interface. Unfortunately this was discovered too late in the development
process and there was no time to have that implemented.
6.4.5
Customer Manager Interface
Once someone is found through the search interface, it is possible to right
click them and open up this interface and manage them, as seen in subsection 6.4.5. It is also possible to access this control by clicking the ”Manage”
button on the left of the screen and then scanning an RFID tag. This will
automatically find the associated user and show him on the screen.
All of the participants’ information is shown at the top in an organized
fashion. Through this interface it is possible to withdraw and deposit money
from someones account. It is also possible to hand out warnings and add
comments to that specific participant. The bank functionality was not fully
implemented because of time constraints and as mentioned in section 4.10
this was not a as high priority as the other functions. Every time an input
is given to either one of the two textboxes, there is a check to ensure that a
digit is typed in. Each time a new digit is entered, the resulting balance label
is updated with the respective value. The interface will not allow a negative
balance. There is also a rich text box containing comments about the participant. This is not fully implemented as well since this was not something
60
Figure 6.7: The Customer Manager Interface
that was required by either informants - this was just a nice feature that
could be useful at some point.
6.4.6
Setup Interface
The setup interface is where everything is setup according to how the festival
works. This is the place where the user adds, deletes or edits the different
areas in the festival. This is also the place where customers and equipment
get added. The panel differs from the others since it has a tab control on
the top of it which the user can use in order to change what he wants to
edit. The first panel is the Area Control, the second is Customer Control
and the third is Equipment Control. This interface has no real appearance
besides the tabs in the top of the page.
61
Figure 6.8: The Area Control Interface
6.4.7
Area Control Interface
As mentioned before, this is where all areas are managed. subsection 6.4.7
shows this interface. It is possible to add, delete or modify each area according to your need. It is possible to choose the maximum amount of people that
each area should be able to manage and also which gateways are connected
to it. If the user decides to add or edit an area, the AreaHandler is called
with the information along with a list of gateways. It then handles gateway
creation so that the user doesn’t have to worry about it.
6.4.8
Customer Control Interface
As can be seen in subsection 6.4.8, this is the place where all customers get
added. Every time the user presses add, the new customer gets added to the
list. Once the user is satisfied and wants to save the list to the database, he
just needs to press ”Save All”. This was done so that the user can have a
62
Figure 6.9: The Customer Control Interface
good overview when creating groups of customers. E.g. if a group of people
buys tickets to the festival, the user can then check if everything is okay
before pressing save all. Also, if the user needs to hire a group of workers, he
adds all of them to the list and is easily able to check if everything regarding
that group is okay.
This interface works with the RFID reader so that if you scan an RFID
tag, the RFID ID field gets automatically filled with the information in the
RFID tag. Also, if the RFID ID cell is selected for any participant and you
scan an RFID tag, that field is updated with the RFID tag’s information.
6.4.9
Equipment Control Interface
This interface works exactly like the Customer Control Interface. As
shown in subsection 6.4.9, it also looks alot like the Customer Control
Interface. It has the same RFID functionality as well as the same list
63
Figure 6.10: The Equipment Control Interface
functionality. It only has a few minor differences in regards to which kind of
information it needs.
6.4.10
Area Statistics
One of the the main requests from Aalborg Carnival was the possibility to
get an overview of the participants movement patterns. A statistics function
was created to achieve this. Because of how this function is built, it can
be used in a variety of situations, meaning that both Aalborg Carnival and
Nibe Festival might find good use for this function. The statistics window can
be seen on subsection 6.4.10, displaying a set of randomized data of 10,000
participants for 3 areas over a 24-hour period.
Figure 6.11: A graph example of randomly generated participant data
64
The graph is a point-based 2-dimensional graph with a time interval of
one hour. This time interval represents the x-axis of the graph while the
y-axis is the amount of people. Each area is then represented by a graph
element/curve. The idea behind this is to give the user an easy overview
of unique participant activity in each area. By using a point-based graph,
it makes it possible to easily spot a progress or downfall in area activity.
An external graph library called ZedGraph was used in order to create this
graph. [5]
Making this graph work with the rest of our system required a special algorithm to analyse each participant. This algorithm was built using randomly
generated participant information to make sure that every aspect of the algorithm worked as intended. Several tests were performed later with actual
use-case data to ensure the algorithm’s functionality. It should be noted that
the algorithm and the statistics function is currently based on static information such as static time intervals. This is being used as a proof of concept
due to time limitations. The final implementation of this would be to make
the user able to select the time intervals of the graph, as well as which areas
to display.
Detailed algorithm description
The algorithm used to extract graphical data from participants is called
GetPoints. This algorithm is called for each area. In this case the algorithm
would have to be called three times with each unique area ID. GetPoints
takes 4 parameters: an area ID, a list of participants to examine, an interval
for the x-axis and a period of the entire graph. For an easier understanding
of the algorithm take a look at the pseudocode below.
1 GetPoints ( int areaID , L i s t <P a r t i c i p a n t > p a r t i c i p a n t s , int
i n t e r v a l , int p e r i o d ) {
2
3
L i s t <Point> l i s t O f P o i n t s = new L i s t <Point >() ;
4
L i s t <int> a r e a s V i s i t e d = new L i s t <int >() ;
5
TimeSpan c u r r e n t S p a n = 0 ;
6
TimeSpan nextSpan = i n t e r v a l ;
7
int x ; // p a r t i c i p a n t s i n i n t e r v a l
8
9
while ( nextSpan <= p e r i o d ) {
10
x = 0;
11
12
foreach ( P a r t i c i p a n t s in p a r t i c i p a n t s ) {
13
a r e a s V i s i t e d . Clear () ;
14
int t s = s . t s ; // t s − s h o r t f o r timeStamp , i s t h e i n d e x
65
o f timeStamps
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
}
34 }
i f ( s . V i s i t e d [ t s ] . Time < nextSpan ) {
f o r ( t s = s . t s ; s . V i s i t e d [ t s ] . Time < nextSpan ; t s ++) {
i f ( ! a r e a s V i s i t e d . C o n t a i n s ( s . V i s i t e d [ t s ] . AreaTo ) && s .
V i s i t e d [ t s ] . AreaTo == areaID ) {
x++;
a r e a s V i s i t e d . Add( s . V i s i t e d [ t s ] . AreaTo ) ;
}
s . ts = ts + 1;
}
}
e l s e i f ( s . V i s i t e d [ t s ] . AreaFrom == areaID ) {
x++;
}
}
l i s t O f P o i n t s . Add( currentSpan , x ) ;
c u r r e n t S p a n += i n t e r v a l ;
nextSpan += i n t e r v a l ;
The algorithm consists of two loops: the first loop running through every
interval within the specified period, and the second running through every
participant in the current interval. The first loop waits for x to be computed
by the second loop. When x is computed, a new point is added to the list
of points for the current area. The loop then increases the current searching
time span with the interval specified.
Since every interval is now being correctly run through by the first loop,
the second loop with the responsibility of computing x will be explained. It
starts by running through all participants in the specified list which is necessary for each interval. The variable ts is set to s.ts to use the last examined
time stamp of the participant. It would also be possible to reset ts every
time, but this would make the algorithm run through already examined time
stamps which would increase the running time and would clearly be unnecessary.
It is then necessary to check whether the time of the current time stamp
of the current participant is lower than the current interval. If this statement is not true it must check if the current time stamp still came from the
specified area ID, in which case the participant is still located in the same
area as the last time stamp. However, when this statement is true the algorithm must run through every time stamp which is registered before the
66
current interval. If the entered area of this time stamp is not already visited
in the current interval and it matches the specified area ID, x is increased
and the area ID is added to the list of visited areas. Having this list ensures
that there are no duplicates of participants in each interval for each area.
6.5
Server side implementation
In order to implement the system model and the functionality, two different
decisions needs to be made. They consist of which database to use, and
which methods are necessary to use in order to handle the communications
efficiency and correctness between clients and servers.
6.5.1
Database
During the project, a couple of databases where considered and analyzed
based on a few requirements. The ability to implement an object-oriented
model structure, effectiveness and easy to implement. The following databases
where considered because they are free, open-source and easy to obtain as
well as they all have extensive communities to provide support:
• MySQL
• PostgreSQL
MySQL and PostgreSQL are some of the more common databases when
it comes to open-source databases. They are both relational databases which
makes it possible to implement an object-oriented database structure. Because they are both able to solve the main problem of an object-oriented
structure, they are compared with each other based on their performance
and efficiency. Based on the results from the page [8], it is safe to conclude
PostgreSQL is the fastest in many cases. This leaves PostgreSQL as the obvious candidate. The last requirement is being easy to implement. MySQL
have for many years been a part of the php library and therefore is, in many
cases, the preferred database system when it comes to web development.
This leads to easier available support since this database is more widely used
and therefore have a higher amount of support. Because of this, MySQL is
chosen as the database for this system.
6.5.2
Communication
When communicating between a server and a client, it is necessary to be able
to transfer information and retain datatypes between server and client. In
67
order to do this, the SOAP protocol was chosen because it is by default a part
of both C#, which is the client side language, and php which is the server
side language. SOAP has the advantage that it has strong datatyping and
therefore guarantees the given return datatype is correct. Most other API
protocols, e.g. REST is not as strict as SOAP when it comes to datatypes
and therefore requires both the client and server to typecast the data received
which leaves the possibility for error.
6.5.3
SOAP API
The implementation of the SOAP API is structured in a Service.php file
which handles the inclusion of the relevant classes. This contains the functions of the server as well as handles session persistence, which enables the
program to have active persistent connections. The purpose of this is, speeding up execution as well as enabling a single-login-system if needed, instead
of sending the login information every time a connection is made.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
i n c l u d e ( ” i n i t i a l i z e . php” ) ;
function
autoload ( $class name )
{
r e q u i r e o n c e ( ” ” . $ c l a s s n a m e . ” . php” ) ;
}
// S e t INI
i n i s e t ( ” soap . w s d l c a c h e e n a b l e d ” , ” 0 ” ) ;
i n i s e t ( ” s e s s i o n . a u t o s t a r t ” , 0) ;
// For p e r s i s t e n t S e s s i o n
session start () ;
// S e r v i c e
$ s e r v e r = new S o a p S e r v e r ( ” S e r v i c e . wsdl ” ) ;
$ s e r v e r −>s e t C l a s s ( ” F e s t i v a l S o a p ” ) ;
$ s e r v e r −>s e t P e r s i s t e n c e (SOAP PERSISTENCE SESSION) ;
$ s e r v e r −>h a n d l e ( ) ;
?>
\ c a p t i o n { S e r v i c e . php f i l e − Handling i n c l u s i o n o f c l a s s e s }
One of the important functions in the class FestivalSoap which contains
all the functions implemented on the server side is GetTimestamps which is
shown below:
1 class FestivalSoap
2 {
3
f u n c t i o n GetTimestamps ( $ i n p u t )
68
{
4
5
6
7
g l o b a l $mysql ;
$timestamps = $mysql−>GetTimestamps ( $input −>
user id ) ;
8
9
10
11
12
13
14
15
16
$return array = array (
GetTimestamps=>a r r a y (
)
);
foreach ( $timestamps as $ t s k e y => $ t s )
{
$tmp arr = a r r a y ( ’ timestamp ’=>” ” . $ t s [ ’
timestamp ’ ] . ” ” , ’ gw id ’=>” ” . $ t s [ ’
gw id ’ ] . ” ” , ’ AreaIn ID ’=>” ” . $ t s [ ’
a r e a i d i n ’ ] . ”” , ’ AreaIn Description
’=>”N/A” , ’ AreaOut ID ’=>” ” . $ t s [ ’
a r e a i d o u t ’ ] . ”” , ’
A r e a O u t D e s c r i p t i o n ’=>”N/A” ) ;
$ r e t u r n a r r a y [ ’ GetTimestamps ’ ] [ ] =
$tmp arr ;
}
17
18
19
20
21
22
23 }
return $ r e t u r n a r r a y ;
}
The purpose of this function is to receive the input from the client, which
in this case consists of an object with a user id, which sends this as a
parameter to a function inside a mysql class. The purpose of the mysql
class is to handle the communication between php and the mysql server,
as well as handling the queries that are implemented inside the class. The
next function which is called GetTimestamps as well, under the Mysql class.
The interesting part about this function is that it executes a query to the
mysql server which demonstrates the object-oriented way the database is
implemented and used. The function is shown below:
1 c l a s s f e s t i v a l m y s q l e x t e n d s mysql
2 {
3
f u n c t i o n GetTimestamps ( $ u s e r i d )
4
{
5
return $ t h i s −>q u e r y a s a r r a y ( ”SELECT
6
user id ,
7
timestamps . gw id ,
8
timestamp ,
9
area id in ,
69
10
11
12
13
14
15
16
17
18
19
20
21
22 }
area id out
FROM
timestamps
LEFT JOIN
gateways
ON
( timestamps . gw id=gateways . gw id )
WHERE
u s e r i d =’” . $ u s e r i d . ” ’
ORDER BY
timestamp ASC” ) ;
}
The way it demonstrates the object-oriented way is through the LEFT
JOIN command which joins two tables together based on two id numbers.
The two affected tables are timestamps and gateways where gateways are
the main class and timestamps are the subclass.
6.6
Checkpoint
The checkpoint is implemented using the programming language C. The implementation is based on a prebuilt example code available from the manufacturers webpage with a simple webclient implemented as part of this report.
The webclient is demonstrated below:
1 int c l i e n t ( char ∗ host , int port , char ∗ f i l e n a m e , char ∗
parameters )
2 {
3 int r , s ;
4 struct s o c k a d d r i n s i n ;
5 char buf [ 1 0 2 4 ] ;
6
7 /∗ Setup t h e s o c k e t ∗/
8 s = s o c k e t (AF INET , SOCK STREAM, 0 ) ;
9
10 /∗ Make t h e c o n n e c t i o n ∗/
11 b z e r o (& s i n , s i z e o f ( s i n ) ) ;
12 s i n . s i n f a m i l y = AF INET ;
13 s i n . s i n p o r t = h t o n s ( p o r t ) ;
14 i n e t a t o n ( host , &s i n . s i n a d d r ) ;
15
16 i f ( c o n n e c t ( s , ( struct s o c k a d d r ∗ ) &s i n , s i z e o f ( s i n ) ) < 0 )
17 {
18
e r r o r ( ” Unable t o c o n n e c t ” ) ;
19 }
20
70
/∗ C o n s t r u c t t h e GET r e q u e s t ∗/
char r e q u e s t b u f f e r [ 1 0 2 4 ] ;
int s i z e ;
s i z e = s p r i n t f ( r e q u e s t b u f f e r , ”GET %s?%s HTTP/ 1 . 1 \ r \ nHost : %s \
r \n\ r \n” , f i l e n a m e , parameters , h o s t ) ;
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
write ( s , request buffer , s i z e ) ;
w r i t e ( s , ”\n” , 1 ) ;
/∗ Send t h e b y t e s t h a t come back t o s t d o u t ∗/
r = r e a d ( s , buf , s i z e o f ( buf ) ) ;
w r i t e ( 1 , buf , r ) ;
w r i t e ( 1 , ” \n” , 1 ) ;
/∗ F i n i s h out ∗/
close ( s ) ;
return 0 ;
}
void e r r o r ( const char ∗msg )
{
p e r r o r ( msg ) ;
exit (0) ;
}
The web clients work by creating a socket connection to a given host and
port, given as parameters. After the socket connection is established it sends
a HTTP header which is constructed on line 24 and sent on line 26. The
header requests a given path and filename on the web directory with a few
given parameters which is readable by the server. The function client is
executed every time the RFID reader loses connection to an RFID tag.
In order to receive the data on the server side the following php script is
implemented called GatewayAPI:
1
2
3
4
5
6
7
8
9
<?php
i n c l u d e ( ” i n i t i a l i z e . php” ) ;
$ g a t e w a y i d = $ REQUEST [ ’ g a t e w a y i d ’ ] ;
$ r f i d = $ REQUEST [ ’ r f i d ’ ] ;
$ f i l e = ” log check . txt ” ;
$ f h = f o p e n ( $ f i l e , ’ a + ’) o r d i e ( ” can ’ t open f i l e ” ) ;
f w r i t e ( $fh , ” Gatewayid : ” . $ g a t e w a y i d . ” checked i n ” . $ r f i d . ”\n” )
;
10 f c l o s e ( $ f h ) ;
11
12 // echo $ r f i d ;
13 echo $mysql−>CheckIn ( $ g a t e w a y i d , $ r f i d ) ;
71
14 ?>
At line 4 and 5 the information sent from the gateway is received and
loaded into two variables, namely gateway id and rfid. At line 7 to 10
there is a simple log implementation which creates a log file on the file system
in case the database is unavailable and is unable to insert the information
regarding check-in of a given participant. At line 13 the sql query is executed
which is shown below:
1 c l a s s f e s t i v a l m y s q l e x t e n d s mysql
2 {
3
f u n c t i o n CheckIn ( $ g a t e w a y i d , $ r f i d )
4
{
5
$ u s e r d a t a = $ t h i s −>q u e r y a s s i n g l e a r r a y ( ”
SELECT u s e r i d FROM u s e r s WHERE r f i d =’” . $ r f i d
. ” ’”) ;
6
$ e q u i p m e n t d a t a = $ t h i s −>q u e r y a s s i n g l e a r r a y ( ”
SELECT e q u i p m e n t i d FROM equipment WHERE r f i d
=’” . $ r f i d . ” ’ ” ) ;
7
8
i f ( $user data )
9
{
10
$ t h i s −>query ( ”INSERT INTO timestamps (
gw id , timestamp ) VALUES ( ’ ” .
$ g a t e w a y i d . ” ’ , UNIX TIMESTAMP( ) ) ” ) ;
11
$ t s i d = $ t h i s −>i n s e r t i d ;
12
$ t h i s −>query ( ”INSERT INTO
rel user timestamp ( ts id , user id )
VALUES ( ’ ” . $ t s i d . ” ’ , ’ ” . $ u s e r d a t a [ ’
user id ’ ] . ” ’) ”) ;
13
return ” 0 ” ;
14
} e l s e i f ( $equipment data ) {
15
$ t h i s −>query ( ”INSERT INTO timestamps (
gw id , timestamp ) VALUES ( ’ ” .
$ g a t e w a y i d . ” ’ , UNIX TIMESTAMP( ) ) ” ) ;
16
$ t s i d = $ t h i s −>i n s e r t i d ;
17
$ t h i s −>query ( ”INSERT INTO
rel equipment timestamp ( ts id ,
e q u i p m e n t i d ) VALUES ( ’ ” . $ t s i d . ” ’ , ’
” . $equipment data [ ’ equipment id ’ ] . ” ’ )
”) ;
18
return ” 1 ” ;
19
} else {
20
return ” 2 ” ;
21
}
22
}
23 }
72
This function handles the insertion of data into the database. First it
checks whether the given RFID is a participant or a piece of equipment.
In both cases it inserts the information at their respective locations in the
database with a UNIX TIMESTAMP attached in order to make a timestamp of
the event. The function ends by returning either 0, in case of participant
check-in, 1, in case of equipment checkin or 2 in case of error.
6.7
Testing
The program needs to work as intended. There needs to be an insurance
that the program actually does what it says it does. It was decided that it
was necessary to create a few use cases and thoroughly test them to ensure
that whatever input was given to the program was valid and that all output
was relevant and correct. This program is entirely based on the information
it sends and receives from the database, so what was done was that every
time the program communicated with the SOAP Client there were artificial
breaks added at those spots. This ensured that the data was sent correctly
and that the data was received and managed correctly once the program
received it. It was also checked whether or not the program displayed correct
information on the screen.
6.7.1
Use Case Tests
There were 7 different use cases that were created which needed to be able
to function as intended in order for the program to be seen as a success. The
server had been filled with data so that it was possible to conduct searches
and get relevant data back from it. It was also a priority that all functionality
was quick and easy to use as well as intuitive. The use cases can be described
as follows:
• Check the location of a user/an equipment
• Manage a user
• Check the status of an area
• Add/Delete/Modify an area
• Add/Delete/Modify a user/an equipment
• Control the different areas by opening and closing gates.
73
The first use case was to check the location of a user/an equipment. The
search interface was accessed and then a few names were searched. The RFID
Reader was also used in conjunction with an RFID tag which also worked
perfectly and displayed correct and relevant information on the screen.
The next step was to manage a user. That meant being able to edit his
information, add or remove money and to be able to add comments to the
user and give him warnings. While comments and warnings were not something that was implemented, there was still a desire to make sure everything
worked as intended so that it would be impossible to break the program by
entering wrong input. That way it would be quite simple to finally add those
features in once needed. This interface was accessed in two ways: by the normal search function as well as scanning the RFID tag after clicking on the
”Manage” Button. Regardless of which way was used to access this function,
no errors were found. This was also tested extensively because scanning an
RFID tag and having relevant information pop up on the screen is awesome.
The manage interface was thoroughly tested as well by attempting to enter
as much invalid information as possible. Nothing broke the program though.
If other information needed to be edited such as name, CPR number, etc the
search interface was used. No problems were found here either.
Another important function was the ability to monitor different areas. This
was easily tested by simply accessing the Area Overview Interface. This
was tested together with the Add/Delete/Modify area functionality so that
it was possible to see whether or not information was delivered correctly and
received correctly as well. Everything was a success, all information was sent
correctly to the server and all information was received and handled properly
as well. Multiple areas were created, deleted and modified in the process as
well as checking the area overview tab to see if everything was working as
intended.
Right after Area Control was tested, the user and equipment control was
tested as well. Again, everything worked as it should. All information sent
to the server was sent correctly. The only place where it was possible to add
invalid information was the RFID ID. This was circumvented by encouraging the use of the RFID scanner to input the correct RFID tag. Otherwise
everything else worked as it should.
The next functionality that needed to be tested was the ability to control the
different gateways. This worked exactly as it should as well. Information was
74
sent correctly to the server and was also managed and displayed correctly on
the screen.
6.8
Summary
After all testing was complete, the program functioned exactly as intended.
There were no flaws in the program - it was capable of communicating with
the database successfully. All the functionality was easy to access as well
as intuitive. The same goes for the design of the program - since all the
information is handled by different classes and handlers and not in the user
interface itself, it is very easy to apply a new design.
The main part of the program, the tracking functionality, was implemented
very well and functions perfectly. It is very easy to find any customer in
your festival with very few clicks of a button. The architecture of the classes
in the program was also built up in an intuitive and easily manageable way.
This makes future development easy if the need ever arises.
75
Chapter 7
Conclusion
We have succeeded in solving our main problem statement through scoping
and solving its subproblems. We gave these subproblems different priorities
in section 4.10.
Our main focus in this project was to make a system that is able to keep
track of where people are located. We have managed to create a software
solution that is able to track the location of people and equipment. In this
software solution we have also managed to create a user interface in which to
access and display the information. We have implemented display functionality that makes it posssible for the users to easily find the information they
need by methods of searching, viewing statistics, and models of the problem
area.
We have also managed to achieve userfriendliness in our solution by using
the gestalt laws of perception, a generally effective menu system and a good
compromise between size, location and importancy of the content.
One aspect that was of a high priority was to have different types of tickets,
like 1 days passes, several day passes, etc. This feature was unfortunately not
implemented since there was not enough time. Within our time span there
were a lot of functionality that needed to be implemented, and unfortunantly
this implementation got pushed back since we felt that the other parts of the
system were more important to complete first. Another aspect we did not
achieve was the automatic distribution of guards, which did not get implemented due to the fact that we did not have time enough to implement this.
However, some areas was deemed less important and have not been completed. One of such areas is the money system. We have added the basic
76
functionalities, however we have not implemented functionality regarding real
money transfer or other interaction with banks. Reasons for this not having
been implemented is because of technical complexity compared to our time
restraints and legal complexity. Another less important area was the ability
to have intelligent commercials which adapts to the information available
about the user, such as location, interests, and your previous purchase. This
was not implemented because we saw this as an extra feature and not an
essential part of the program, again due to time constraints. Another area
is location based events: being able to know what is going on in the area
you are located, as well as integration with social media such as facebook or
twitter. This also did not get implemented because of time constraints.
Having the system restore its current state after a power outage was also
something we managed to do. Although we did not find a solution to prevent our system from going down during a power outage, we feel that this is
something that could be achieved by having some sort of battery or backup
power supply connected to the gateways. This would ensure that the gatways
had connection to the network regardless of power outages, as long as the
database is located offsite or separate from the rest of the festival’s power
system. These are only a few solutions and we would need more time to
investigate if it would even work or which other solutions would.
Even though we have not achieved all our goals, we feel that we managed
to achieve the most important one: To create a system that is capable of
monitoring a crowd. We can easily and effectively add, delete and modify
areas in the program and create connections in between them. We can just as
easily add, delete and modify people in the festival as well as search them by
either name, cpr number or rfid tag. Managing crowd movement is a breeze
as well, through our gateway control system.
However, there are still some things that need to be addressed in order for
this program to be implemented in a real life situation. We need to be able
to assign different tickets to different people. The need for stability in case
of a power outage is also something that needs to be considered. Imagine if
all of a sudden, no guests were able to move in between areas because the
power was out. This is something that needs to be addressed before we can
implement this in a real life situation. Through testing of usecases we have
verified the quality of our solution to make sure it is fit its purpose.
77
Chapter 8
Future Works
Even though the main requirements were met, there are still things that
could be implemented in the program. There were quite a few features that
were cut out because of time constraints as well as new features that could be
implemented fairly easy with the current solution. There are actually quite a
few things that could be added in different ways due to the structure the system uses. It is possible to create a multitude of applications that can connect
and communicate with the server. This is possible due to the structure that
was used: the server makes a few functions available to outside applications
which then decide which functions it wants to use as well as how to interpret
the data it receives from the server.
A promising possibility would be the schedule application for smartphones.
This could for example have been accomplished by adding a schedule of events
onto the database and creating a function on the server which returned this
list. The smartphone would then take this information and create a visual
representation of that list for the user. All the user needs to do is download the application which has a built-in connection to the server. All that
is needed is then a smartphone with online capabilities. Another solution
would be to provide a huge wireless network at the festival itself. These
solutions would of course need to be analyzed in order to find an optimal
solution for the given problem.
The gateway system is also another area that could be improved. At the
moment, all it does is light up an LED light depending on whether or not
the user has access to that area. This could be expanded by implementing it
into a ticket gate which would also rule out the need for staff at the entrance.
An example of such a ticket gate can be seen on Figure 8.1. It would also be
necessary to find a proper connection method between the gateways and the
78
database.
Figure 8.1: A ticket gate
Another thing that could be done was to fully implement the money system. This could be achieved by finishing how money is handled in the program and adding some security around it. Furthermore, it would be possible
to have terminals located around the festival which are able to read a user’s
RFID wristband and lookup the balance of that user from the database. It
would also have the possibility to withdraw or deposit money from your balance.
In order to fulfill the requirements of a real life implementation, it is necessary to ensure a certain standard on reliability. This could be achieved by
implementing a separate power source to each gateway. This way, should
there be a power outage, customers would still be able to move around unaffected by that outage.
It would also be nice to further implement even more data representation
in form of statistics into the program. Currently, there is only a graph that
shows the amount of people in any given area at any given time. That could
be expanded to show the influx of people represented as people per minute
or maybe a graph that shows the average time spent in each area per user.
79
It would be nice to be able to have these sets of statistics shown visually
in the program as well as having the possibility to export them to a file.
While at the moment it is possible to save a picture of the graph, another
possibility would be to save all information to some kind of data file so that
other programs could analyse and interpret that data.
Another functionality that could be added would be the possibility to change
between languages. This is because there is a big variation in our user base:
Everyone from festival administrators to ticket sellers could be using the program, and not all of them have the same level of expertise with the English
language. This will also make further development of the program available
internationally.
80
Bibliography
[1] Vangie Beal. All about rfid. http://www.webopedia.com/DidYouKnow/
Computer_Science/2005/rfid.asp - Visited 20/09/2011. 22, 23
[2] DR. Danske festivaler fordoblet på 10 år. http://www.dr.dk/Nyheder/
Kultur/2010/07/07/07101728.htm6 - Visited 24/10/2011. 6
[3] Roskilde Festival. Hvor mange deltagere har der været på roskilde festival gennem årene? http://roskilde-festival.dk/presse/nice_to_
know/6 - Visited 24/10/2011. 6
[4] http://www.festivalinsights.com.
Rfid wristbands starts to
take
off.
http://www.festivalinsights.com/2011/04/
rfid-wristbands-start-to-take-offvince-power-aims-to-create-100m-empire-council
- Visited 27/10/2011. 6
[5] rjosulli jchampion, kooseefoo. Zedgraph. http://sourceforge.net/
projects/zedgraph/ - Visited 13/12/2011, 2008. 65
[6] Peter Axel Nielsen Jan Stage Lars Mathiassen, Andreas Munk-Madsen.
Objektorienteret Analyse og Design. Marko, 3. edition edition, 2001. 1,
2, 4
[7] Jens Müller. Hvad er teknologi. http://www.tnb.aau.dk/fg_2010/sw_
dat/pv/PV%204/Hvad%20er%20teknologi.pdf - Visited 14/12/2011. 17
[8] Randombugs.com. Mysql vs postgresql benchmarks. http://www.
randombugs.com/linux/mysql-postgresql-benchmarks.html - visited 18/12/2011. 67
[9] Aalborg
Universitet.
3.
semester
dat3,
s.17-18.
http://www.sict.aau.dk/digitalAssets/27/27026_
forel--big-datalogi-bachelor-3-6.pdf - Visited 02/11/2011.
8
81
[10] www.webopedia.com. active tag. http://www.webopedia.com/TERM/
A/active_tag.html - Visited 20/09/2011. 23
[11] www.webopedia.com. half-duplex. http://www.webopedia.com/TERM/
H/half_duplex.html - Visited 20/09/2011. 22
[12] www.webopedia.com. passive tag. http://www.webopedia.com/TERM/
P/passive_tag.html - Visited 20/09/2011. 23
[13] www.webopedia.com. tranceiver. http://www.webopedia.com/TERM/
T/transceiver.html - Visited 20/09/2011. 22
82
Appendix
CD
Source code of the C# application and SQL database
Compliced C# application
Audio files of interviews
83
Academic report
The report
The report is generally structured around the waterfall method phases. We
begin by analysing the requirements for a software solution in the desired
problem area followed by a software design, an implementation and then
testing and evaluation hereby. The requirement of informants was a new
aspect for all of the members in the group which evolved into a bigger discussion about its most fitting place in the report. We however chose to place
the context of the interviews as the very initial part of the requirements
analysis as we chose to look them as the driving force behind the programs
required functionality.
This project
Work model: We initially chose the waterfall model as we believed the construction of the program would fit the project itself better. We however ran
into a wall of discussions about the design and implementation of the program. We finally chose to do some changes to the design in response to the
implementation phase and thus adapting the evolutionary implementation
model to our initial work and report. We believe the waterfall model has
shown itself inadequate for our way of working.
Methodology
To give a better understanding of the methods used in the analysis, this
chapter will describe these methods.
”Problem area: The part of the environment, which is being administered, monitored or controlled by using a system.”
[6, p. 43]
The analysis of the problem area includes development of an event table,
a class diagram and related state diagrams. To give an overview of the most
important events and their connection to classes, an event table is made. The
event table will show events to the left and classes at the top, a connection is
shown with an X. A class diagram is constructed in order to give an overview
of classes and objects in the problem area and the connection between them.
State diagrams show the state an object can be in during its lifecycle. The
object can change into different states while events can affect the object and
make it change its current state.
1
”The scope of the problem: An organization, which administers,
monitors and controls the problem area.”
[6, p. 113]
As a part of analyzing the scope of the problem, a table of roles will be
developed. This table gives an overview of the actions and their connection
to people in the scope of the problem.
”Criterion: A wanted property about an architecture.”
[6, p. 173]
To show the priority of the criteria, a table is developed to show which
priority a given criterion has. The priority can vary from very important to
irrelevant. The criteria used are from a checklist [6] with the most classical
criteria.
”Component architecture: A structuring of a system in mutually
connected components.”
[6, p. 185]
The component architecture describes the system’s components and also
gives a rough overview of the system. A system can be designed based on
different patterns. A client-server pattern consists of a server component and
a number of clients connected to the server. Another pattern is the layered
component architecture. In this pattern, components are layered and more
components can be added on a layer. As an example, an interface component
can contain a user interface component and a system interface component.
In order to gather data for the analysis, two informants have been interviewed using semi-structured interview. A semi-structured interview gives
the interviewer the possibility to prepare questions and also reflect on the
interviewee’s answers and ask clarifying questions. [6, p. 152]
The administrative program needs a graphical user interface. As a part
of designing the user interface, there are some principles which can help the
process of designing. The Gestalt laws have a psychological impact on the
human brain. They are used to create a user interface, which is easy to get
an overview of. The Gestalt laws are:
• Proximity: elements that are grouped together are viewed as a whole.
2
• Similarity: elements that look alike are viewed as being a group.
• Closure: if elements are grouped within a closed space, then these
elements are viewed as a whole, even though they are different.
• Continuity: elements that are linked or continue visually belong together.
• Part-whole: in an area, the smallest element is the element that is
noticed. If the element and the background are equally big, it may be
difficult to distinguish between foreground and background.
Development process
The waterfall model is a structured way of developing software. It is divided
into five different phases. Phase 1 is the analysis, in which the requirements
are described. Phase 2 deals with design and software design specifications.
Phase 3 is the implementation of the actual software product and results in a
program. In phase 4 this program is tested in order to eliminate errors and a
test report is written. Phase 5 is maintenance of the finished program. Some
faults may occur after the program is tested or released and these faults often
need to be corrected.
This model is logical and easy to understand but in reality using this
model can result in problems throughout the development and can also be
very costly when the software is finalized. The cost of correcting errors and
faults in the end rather than throughout the development process can be
very high.
Other models used in software development are evolutionary. They iterate the above described phases a number of times. Using this evolutionary
method can ease the process of developing software, because developers are
allowed to go back and correct, for example, the analysis in the early stages
of the process.
3
Figure 8.2: The traditional top-down approach [6, p. 16]
Figure 8.3: Iterative approach [6, p. 17]
4
Work, planing and structure
In this project there has been many faults when it comes to structured and
time-effective work as very little energy was spent on planing and overviewing the project. This resulted in a significant gap of time where nothing was
neither produced or discussed in the group. A milestone time table was created to support the overview of our given time but the lack of structure and
planning caused the group to stall for a longer period of time. The lack of
structure is likely a supporting reason to our failed constructive implementation.
Future projects
To improve the work structure and planning in future projects, the group
members should consider some degree of work structure that at least contains
structured meetings for planning, work and project overview. As a semester
is about 4-5 months, these planning and overview meetings should happen
maybe weekly to avoid bigger holes of time where work stalls. Notation of
agreements and planning should always be done to help all group members
remember exactly where the group is in the project and what tasks is to
be done until next meeting. These meetings will lessen the communication
problem in a considerable degree, as all members have a more formal and
structured way of meeting and thereby communicating. The communication
outside the group room could also be optimised and regularly performed
through the use of a more adapted communication technology such as Skype,
Facebook or other.
A higher degree of respect towards formality and objectivity should also
be given to future projects. Lack of file and folder management is for instance
a detail that will always evolve into a mess that is impossible to handle and
use effectively by anyone. Small and maybe initially harmless trends as this
should be noticed and commented on to avoid escalation. These things could
for instance be a permanent subject for the project overview and/or planing
meetings.
Technologies used
These were the tools we used to be able to create our solution.
5
File sharing
Dropbox - a cloud based file sharing software was chosen to distribute all
relevant files to all the members in the group. This services was chosen as
all members in the group already used it and were familiar with it. Despite
some problems with folder and file management from the group, this turned
out to be a very nice feature for the collaborate work.
Latex editor
ScribTex - a web-based editor that has very low complexity in setup and
management. The editor contains version control and merge functions for
multiple users in one document out of the box which made it a good candidate
for this group project. There has however been small issues with the editor
in form of some technical problems where compiled documents were different
depending on where the compiling was done in the document. Some folders
and files could become locked in place and some references in the document
itself had problems finding their reference point at times. This did result in
some annoyance that could be avoided with another Latex editor.
Subversion
A few days before the report was handed in, problems with ScribTex occured
which resulted in the need to change both editor and file sharing method. A
subversion server was setup and the entire report were moved to the subversion server and all members installed a latex editor on each of the machines.
6