front page placeholder see ”front page.doc”

Nicolai Sonne May 31, 2013

FRONT PAGE PLACEHOLDERSEE ”Front Page.doc”

1 of 112


Preface

This report acts as documentation of the design and implementation of an asset-managementsystem. The system was developed, during the spring of 2013.It was done as an IT engineering bachelor project at the Technical University of Denmark(DTU Diplom) with the cooperation of Pernexus Systems.

I, Nicolai Sonne, had my internship at Pernexus Systems during the autumn of 2012 andthe bachelor project was made as an extension of this internship.

I would like to thanks the following people for their involvement of this project:

• Christian Almskou (Pernexus Supervisor)• Ole Rydahl (DTU Diplom Supervisor)• My colleagues of Pernexus Systems• Peter Greenfort (Veriloc Automation)• John C.W. Olsen (HOFOR)• Michael Sepstrup Nielsen (HOFOR)

2 of 112


Contents

1 Introduction 6

2 Choice of Software Development Process 72.1 Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Problem Definition 8

4 Problem Analysis and Design 94.1 Tagging Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2 RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.3 Barcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.4 Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Interim Conclusion: Tagging Technology . . . . . . . . . . . . . . . . . . . . . . 134.3 Stationary Gate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4 Hardware set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.5 Direction detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.6 Ill-placed components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.7 Passing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.8 New position of leaving components . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.8.1 Mounted truck tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.8.2 Mobile truck tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.8.3 Pre-register components . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.8.4 On-site component registration . . . . . . . . . . . . . . . . . . . . . . . 224.8.5 Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8.6 Backup system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.9 Interim Conclusion: Hardware set-up . . . . . . . . . . . . . . . . . . . . . . . . 244.9.1 Summary and decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.10 Bundling of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.10.1 Splitting trucks apart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.11 Server communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.11.1 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.11.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.12 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.13 Update system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.13.1 Push method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.13.2 Pull Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.13.3 Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.14 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.15 Website interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.15.1 Method 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.15.2 Method 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.16 Android Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.16.1 Functionality and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.16.2 Android server communication . . . . . . . . . . . . . . . . . . . . . . . . 36

3 of 112


5 Complications 37

6 Implementation 386.1 Choice of programming language . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.1.2 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.1.3 Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Stationary Gate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2.2 Future real world set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Grape Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.3.1 Tag Collecting Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3.2 Tag-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3.3 Tag Bundling Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3.4 Bundle Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3.5 Server Communication Thread . . . . . . . . . . . . . . . . . . . . . . . . 486.3.6 Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3.7 Update System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.8 Configuration and modularity . . . . . . . . . . . . . . . . . . . . . . . . 536.3.9 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.4 Android Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4.1 Functionality and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4.2 Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.4.3 Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Test 627.1 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.1.1 Stationary gate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.1.3 Android Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.2 Integration & Acceptance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.2.1 Test hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.2.2 Use-case 6/10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.3 Use-case 9/13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.4 Use-case 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.5 Use-case 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.6 Test Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8 Conclusion 698.1 Product assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.2 Process assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

9 Appendices 709.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

9.1.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.1.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . 70

9.2 Uses-case specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719.3 Use-case realizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809.4 Use-case test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4 of 112


9.4.1 Use-case 6/10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819.4.2 Use-case 9/13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869.4.3 Use-case 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.4.4 Use-case 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

9.5 Milestone plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999.6 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009.7 Mobile and vehicle mounted reader solution . . . . . . . . . . . . . . . . . . . . 1029.8 Handheld Reader Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5 of 112


1 Introduction

This project centers around the design and implementation of an asset-management system forthe management of roadway bridges for HOFOR (”Hovedstadens Forsyning” earlier ”Copen-hagen Energy”)

HOFOR owns a great deal of the infrastructure of Copenhagen. This regards utilities suchas waste/clean water, central district heating and gas. HOFOR also manages the developmentand maintenance of these utilities.

The project will be done in cooperation with Pernexus Systems and their subsidiary, VerilocAutomation. The main product of Pernexus Systems is www.entrepriseportalen.dk.Entrepriseportalen is a SAAS (Software as a Service) system, which utility companies use forcontract and project management.Their subsidiary, Veriloc, is a company, which is specialized in sales and consulting of RFIDequipment.

No software or hardware requirements exists, but RFID technology is preferred due to theexpertise and availability from Veriloc.

For more informaiton on the project, look to the project description in section 9.6 page 100.

6 of 112


2 Choice of Software Development Process

Previously I have worked with two different development processes.During my education I have mainly worked with UP (Unified Process) and gained a lot of

experience using this method.During my internship at Pernexus Systems I have been using SCRUM, which is a quite

different development process.I will briefly discuss how both methods and make my choice in the sections below. It should

be noted that I haven’t had any detailed education in either of these methods and my analysisis solely based on experience.

2.1 Unified Process

Unified Process is the method of which I have the most experience and feel most confidentusing.

Generally it is a method, which require a lot of planning, research and documentation. Thisresults is a very well thought, but long process. If you are able to plan and research properlythe end-result should be excellent.

2.2 SCRUM

SCRUM is an Agile development process. It is basically based on the statement: ”A projectcan’t be properly planned, so don’t do it”. Instead of intense planning the method relieson customer/user communication. The process involves the customers/users more and thedevelopment doesn’t have precise planning a very long time ahead.

Since your solutions aren’t always as well planned (compared to UP) and all requirementsaren’t planned from the start, your product might change dramatically over the time of theproject.

2.3 Decision

I have chosen to use Unified Process mainly because it is the one, which I have most experiencein using. I have only worked with SCRUM during my time at Pernexus Systems and I havenever had any proper introduction to it. I like SCRUM, since it require a lot ”doing”, butthe solutions aren’t always as well thought and big product changes are likely to happen mid-development.

7 of 112


3 Problem Definition

In order to set milestones and have a good understanding of the project, the problem definitiontries to state the problems facing the project development and do so in an orderly fashion.

The project, construction and inventory managers of HOFOR (earlier Copenhagen Energy)have some problems with their inventory.

HOFOR is the company, which handles a lot of the infrastructure of Copenhagen (includingcentral heating and water supply).

One of their largest inventory-problems concerns their roadway bridges.

Steel roadway bridges.

When HOFOR have to put new pipes (or renovate old) in the ground, they use theircontractors (NCC, Kamco etc.).

The roadway bridges are extra robust steel constructions, which help the traffic keep moving,when the contractors digs holes in roads.

HOFOR owns about three hundred of these roadway bridges and their contractors borrowthem for the projects, which they perform for HOFOR. The problems occur when there’s noproper registration of who has borrowed which roadway bridges.

Currently HOFOR is using a standard Excel spreadsheet, which is mailed between partiesand has the tendency to get out of date and unsynchronized.

Due to this, roadway bridges sometimes get lost. They are not cheap (about 50.000 DKKeach) and buying new ones makes quite a dent in their budgets.

To resolve this, a proper overview of the locations of the roadway bridges are required. Thisshould help get an optimal use of the roadway bridges and if some get lost, HOFOR will knowwhere to send the bill.

This project should end up in an asset management system. Since the project is done forPernexus Systems (not directly HOFOR), the system should be able to be implemented inother cases than that of the roadway bridges.

Some of the targeted users are computer/technology beginners and because of that, thefinal product should have minimal human interaction. The limited human interaction shouldbe simple and logic, due to the same reason. It would be preferred if the interaction is donethrough the Entrepriseportalen ecosystem (project management system of Pernexus, whichincludes a website and an Android application).

Project description is located in the appendices (section 9.6 page 100).For full requirements of the systems look to section 9.1 page 70.

8 of 112


4 Problem Analysis and Design

This project have two different aspects:• To get and store tracking information of components.• Presentation of tracking information.

I will start by analysing the first aspect.Since the basic idea of this project is to track components, the first thing to figure out is howto tag the components. I will start by discussing the tagging technology, since it will be thefoundation of the rest of the system.

After the tracking technology have been decided I will analyse and design the rest of thesystem. See section 4.2 page 13 for this continuous analysis and design.

For the analysis and design of the second aspect (presentation of tracking information) referto section 4.14 page 29.

9 of 112


4.1 Tagging Technology

Tagging components, and especially the big metal rich steel roadway bridges, presents quite afew problems.

I have chosen to investigate the following three technologies for my analysis:• GPS• RFID• Barcodes

I will discuss these technologies and finally make my decision in section 4.1.4 page 13.

4.1.1 GPS

Putting a GPS on each of the roadway bridges would be a great solution, since it would allowlive or periodical tracking. Yet quite a few downsides exists.

The first problem would be the need for a battery, which means the roadway bridges wouldneed to be replaced or charged once in a while. Also since the roadway bridges are made ofsteel, they would reflect and block most of the GPS signal.

There exists two kinds of GPS modules. The cellular kind which used the cellular networkfor tracking and the satellite kind, which obviously uses satellites.

The satellite kind requires a stronger signal and might even have problems inside a building.The cellular kind catches a strong signal easier since the cellular transmitters are positioned

on earth opposed to the satellites in space. Construction won’t always be located inside a cityand the cellular signal might be weak.

Last, but almost most important, is the cost.GPS tagging is by far the most expensive of the three suggested technologies.Overall cost and maintenance is a big disadvantage for the GPS-solution.

Pros• Possibility of live trackingCons• Battery dependent• Signal diminished by metal rich environments• Might require cellular network• Expensive

10 of 112


4.1.2 RFID

RFID has a lot strengths, but also quite a few weaknesses. The biggest weakness is that trackingwon’t be live and requires scanning.

From some research done during my internship, it has been determined that the technologyof mobile UHF RFID readers are not yet capable of being used in environment where a lot ofmetal is present (which is the case with the steel roadway bridges).

Please look at appendix section 9.8 page 107 for a small report on this experiment.

Three types of RFID tags exists:• Low Frequency (LF)

Frequency: 100-150 KHzRange: <0.5m

• High Frequency (HF)Frequency: 13,56 MHzRange: <1m

• Ultra High Frequency (UHF)Frequency: 850-950 MHzRange: +100m

The distances of LF and HF RFID are way too low. These technologies are normally usedfor identification with credit card sized plastic cards or small RFID bricks.

The obvious choice would be UHF.

UHF has three sub-categories as well:• Passive (Class 1/2)

Passive tags have no internal power source, but uses the readers signal to power the circuitand transmission. This means no maintenance, but a relatively low read range. The readrange for the top of the line passive tags with a stationary reader is roughly 30 meters.

• Semi-passive (Class 3)Semi-passive tags are in between the passive and active tags. It relies on a batteryfor powering the circuit, while the transmission is powered by the signal of the reader.Compared to active tags, this results in a better battery life, but suffers a bit in readranges. Semi-passive tags are able to be read from a distance of up to 120 meters.

• Active (Class 4)Active tags uses an internal power source to power the circuit and transmitter of the tags.This means long read ranges, but limited battery life. Very few products have been puton the market (especially with the European certification ETSI), which means I don’thave any precise numbers on read ranges and battery life.

Due to the battery and a more complex circuitry, active tags are the most expensive andpassive tags are the least. Semi-passive tags are placed somewhere in between.

Active tags are out of the question due to the relatively low battery life, availability andhigh cost. Semi-passive tags are worth mentioning, since battery life of these are often ratedat 4+ years.

11 of 112


Passive tags are often the most durable, cheapest and they have no maintenance, due tohaving no battery. The Problem with these are the read ranges fails dramatically, when youintroduce a lot of metal.

Based on this, semi-passive tags could very well be the most interesting type, since theroadway bridges will go in for service once in a while anyway.

Semi-passive readers often have the advantage of being backward compatible with passivetags, which means you could use passive tags for metal poor components without changingreaders.

Stationary readers would be a good solution for tracking components at storage plots. It’shard to track them once they’re used at different project locations.

For tracking components outside storage plots, you could use mobile readers for metal poorcomponents and vehicle equipped stationary readers for metal rich components.

Overall a very good (but complex) solution with relative low cost (compared to GPS track-ing, which has a lot of problems.)

Pros• Low cost• Long or no battery life• Few places to maximize signal strength (readers only)• Much knowledge already known and available from Veriloc• Durable• Easy to upgrade mobile reader once the technology improvesCons• Mobile readers too weak• Scanning required

4.1.3 Barcode

Barcodes are great for clean environments.They have a great many advantages like no maintenance/battery-life, cheap tagging and

cheap scanners.The problem is that they aren’t very durable. A tear can easily make them unusable. New

2D barcodes (QR-codes) have some error correction, which enables up to 30 percent of the datato be restored (Source: http://en.wikipedia.org/wiki/QR_code#Error_correction).

Another disadvantage is the need for a clear line of visibility. If the barcode gets dirty itcan quickly become unreadable.

Overall not a great solution for the rough conditions of the utility companies’ workingenvironment.

Pros• Very low cost• No battery lifeCons• Fragile• Clear line of visibility required

12 of 112

http://en.wikipedia.org/wiki/QR_code#Error_correction


4.1.4 Decision

The best solution would be a small, powerful, nuclear powered GPS device with a price below100 DKK. Sadly this technology is not (yet) available.

Barcodes are immediately discarded due to the need for a clear line of visibility and theirdurability.

If each roadway bridge got a GPS device mounted, I highly doubt it would be able to handlea stable signal with all the metal surroundings of a stack of roadway bridges. Even if it could,the battery-life would require too much maintenance and the cost is too high.

This leaves RFID as the last solution. The main disadvantage of RFID is that powerfulreaders are stationary. This means a gate solution would be one of the most stable solution.

Some companies has started to make powerful RFID readers, which can be equipped onvehicles. This makes it possible to scan the roadway bridges out in the field. Overall RFID isa rather good solution with its stability and relatively low cost.

Now that RFID has been chosen as the tagging technology, the type of RFID is to be chosen.Passive tags are too weak to give stable results in a metal rich environment.Active tags on the other hand are too expensive and the battery-life is too short. The

maintenance is too high for these tags. Besides that, the EU regulations are very strict on thistype of RFID, which means very few companies makes them.

Semi-passive RFID is a newer technology, which takes the low prices and maintenance ofpassive tags and the reading ranges of active tags and put together. As mentioned earlier,semi-passive RFID readers are often compatible with passive tags, which creates the possibilityof tagging metal poor components with the cheap and maintenance-free passive tags withoutinvesting in a new reader.Semi-passive tags also suffers from the strict EU regulations, but a few companies has developedtags and readers, which seems to have been approved.

Semi-passive RFID is the technology to go with.

4.2 Interim Conclusion: Tagging Technology

Now that semi-passive RFID has been decided as the tagging technology, the next step is toconsider the hardware set-up and the complications of it.

As mentioned in the RFID section of the tagging technology discussing (see section 4.1.2page 11) three systems should be made to cover all requirements.

• Stationary gate-system (SGS) for storage plots.• Mobile reader for in-field metal-poor components.• Vehicle mounted reader for in-field metal-rich components.

During my internship, I have developed a solution for the mobile reader and vehicle mountedreader implementations.For more information on this, please refer to section 9.7 page 102.

Because of this, I will focus on the development of the SGS system and the problems of it.

13 of 112


4.3 Stationary Gate System

Normally a gate mounted RFID system will be set up similarly to the following picture.

R=Receiver, T=TransmitterGrey circles indicates where the readers are able to read tags.

This is one of several set-ups and to find the correct one would be the first problem to solve.The next problem would be to detect the direction of components passing through the gate.

Are they leaving or arriving?How would the system handle components which are detected but doesn’t pass through the

gate?If a component is placed in the readfield by accident? How should this be handled?When components are leaving, where will they be registered?How are the components bundled together?How would the system communicate with the server?Several could potentially be installed. Should these be configured for each situation? How

will they be maintained?All these problems spring to mind and I will now analyse and design a solution for each of

these.

The problems have been summarized in the following list:• Hardware set-up• Direction detection• Ill-placed components• Passing components• New position of leaving components• Bundling of components• Server communication• System customization• System up-to-date

I will discuss these topics in the following sections.

14 of 112


4.4 Hardware set-up

Before discussing the hardware set-up, some terms need to be specified.

Term Description

Read Point [RP] The read-field of a single antenna pair.

Read Zone [RZ] The read-field of a collection of read points.

Antennas of powerful RFID readers are often bistatic, which means that they come in pairsof a transmitter and a receiver. I have based my drawings and analysis on this.

The general hardware layout of a gate system is quiet simple.The gate will have one or more antennas on each side. These antenna will be connected to

a reader, which is controlled by a controller-unit.I have found two different suggestions, which is described below.

Hardware suggestion one: One readzone

The first option only contains one read zone.This is the cheap option, which only require one reader.

15 of 112


Hardware suggestion 2: Two readzones

The second option contains two read zones.This is a more expensive option, but has quite a few advantages.

Two read zones are defined:• Readzone 1: Consisting of RP1 and RP2• Readzone 2: Consisting of RP3 and RP4

These two options enables different solutions to the remaining of the problems.Because of this I will delay my hardware decision and discuss these problems.My final hardware decision will be discussed in section 4.9 page 24.

16 of 112


4.5 Direction detection

With a stationary gate system, it is important to know which way the components are moving.In ”Current Trends and Challenges in RFID” chapter 22, Cornel Turcu discuss the most

used methods for detection direction using RFID. The first method is simple, but a bit costly.This method I have called ”Antenna based” and is described below. Other more complex andvelocity-based methods are also described, but are discarded due to the complicity and the tagswill not be moving in a constant pace and might stand still in the read-field. These optionsare more suited for assembly lines and other situations where tags are moving at a constantvelocity.

I will discuss solutions for both hardware suggestions (see hardware suggestions in section4.4 page 15).

Hardware suggestion one

Hardware suggestion one only have a single readzone, which means that it is hard to detectthe direction by hardware. The ”antenna based” solution is not possible.

Another software based solution (which I will call ”Database based”) relies on the databaseto detect the direction. When components are detected in the readzone, the RFID UID (UniqueIdentifier) are sent to the server. If the database already has the component registered at thestorage plot, the component will be marked as leaving (For the new location refer to section 4.8page 22). If the component is registered outside the storage plot it will be detected as arrivingand registered to the location of the storage plot.

This solution has the potential of being very error-prone and unreliable.

17 of 112


Hardware suggestion twoHardware suggestion two have two readzones, which open up for more direction detection

possibilities compared to hardware suggestion one.By having two simple states for each discovered tag, a direction can be determined by in

which order they enter the two readzones. This is the solution mentioned as ”Antenna based”.Let’s have a look at the hardware suggestion again.

If the component is first discovered in readzone 1 (Composed of RP1 and RP2) and afterwardin readzone 2 (Composed of RP3 and RP4), the component is leaving the storage plot. If thecomponent is first discovered in readzone 2, the component would be registered to the locationof the storage plot.

This could be combined with the ”Database based” solution. If the ”Antenna based”direction guess doesn’t match the database, the person, who is responsible for the components,would be notified and he would have to manually (by memory or receipts) decide whether thecomponent would be leaving or arriving.

Hardware suggestion two, with the combined antenna and database based design, is muchbetter than hardware suggestion one. It has a potential of being much more reliable.

18 of 112


4.6 Ill-placed components

If components are left in the readfield and remain static, they are to be quarantined.

Example:Two central heating pipes have been tagged and placed right next to the gate.These pipes will stay in the readfield even when other components pass the gate.

Two problems might occur:• The statemachine of the reader will lock and wait for the the two pipes to pass the gate.

This will cause the system to never send any information to the server and bundle allpassing components together.• Every time components passes the gate, the two pipes will be bundles with the tags and

their registered position will change and become invalid.

To solve this problem I have found two variations of the same solution.

Option One:If the two pipes have been located in the readfield for X amount of time, they will be marked”quarantined” and the server will be notified.After this, the server will contact the storage plot manager by email and tell him the two pipesare located too close to the gate. He will then have the pipes moved and manually unmark thepipes as quarantined.

Option Two:This option is exactly the same as option one, except instead of the storage plot managerhaving to manually unmark the pipes, the system will automatically remove the pipes from itscomponent-list, if they haven’t been read in X time.

Option one is less error prone, but option two is simpler and automated.In this project, I try to make the system as simple as possible and because of this I will

choose option two. If option two become too error-prone, an update containing a change tooption one could be deployed at a later time.

Both options will work just as well with both hardware suggestions.

19 of 112


4.7 Passing components

If a truck with components passes the gate, but doesn’t come through it, the system will needto ignore these components.

I will consider this problem from both hardware suggestions.

Hardware suggestion oneSee section 4.4 page 15 for an explanation of hardware suggestion one.With only one readzone it is really hard to ignore the passing components.Because of the single readzone the components won’t be able to have a state (see hardwaresuggestion two for more on this).Even by registering the distance between components and antennas, it is hard to detect ifcomponents are passing or going through the gate.

See the following diagrams for an example.

Passing the gate.

The above graph illustrates the distance between each transmitter/receiver reader pair and thetruck as the truck passes by. The vertical axis indicates distance between truck and readpoint,

while the horizontal axis indicates time.

20 of 112


Going through the gate.

The above graph illustrates the distance between each transmitter/receiver reader pair and thetruck as the truck passes by. The vertical axis indicates distance between truck and readpoint,

while the horizontal axis indicates time.

As you can see these graphs are very similar. With the variable speeds of the components,the graphs could very well sync up.Let’s have a look at hardware option two.

Hardware suggestion twoWith two readzones the components have the ability to have states. The components will beable to have the following states:• State one: Discovered in one readzone• State two: Discovered in both readzones

If a component passes the gate, it will only be discovered in one readzone and stay in stateone. If the component isn’t discovered in X time and doesn’t go to state two, it will time outand be removed from the component-list.This way passing components will naturally be ignored and removed from the taglist.

To sum up, hardware suggestion two is the only suggestion of which I have found a propersolution.If hardware suggestion one is chosen, some big problems might occur due to passing components.This is a big advantage of hardware suggestion two.

21 of 112


4.8 New position of leaving components

When components arrive at storage plot, they will naturally get their position moved to thestorage plot, but how do I know where to register them when they are leaving?

I have found four solutions for this problem. These solutions are not dependant on the hard-ware set-up and because of this the hardware suggestions won’t be involved in the discussion.It should be noted that these solutions doesn’t involve any of the mobile systems and will onlyconcern the stationary gate system.

4.8.1 Mounted truck tagging

To be allowed to pick up components, each truck will have to get an RFID tag mounted.Every time someone orders some components, they will have to link a truck to the componentsand their destination.This is a lot of work and will not work in the real world. Truck are often from a third partyand often the specific truck are specified late in the process and not long before the pick-up.This also means that each truck will only be able to pick up components for a single project ata time, since we won’t be able to separate the components.

4.8.2 Mobile truck tagging

This second solution is very similar to the first, but instead of a mounted RFID tag, the truckdriver will get a cheap RFID sticker each time he picks up some components. This sticker islinked to the address of the project of where the components are going. This sticker is ”onetime use only” and will be ignored after it has passed the gate once. This isn’t a problem sincethe stickers costs less than 1 DKK each.This way truck won’t have to be identified before they arrive for the pick-up.We still have the problem that the truck is only able to pick up components for one project ata time.

4.8.3 Pre-register components

When ordering a delivery, your order will be linked to some specific components and their UID.This way the specific components will be linked to the delivery address of the order.The problem here is that you have to find the specific components. If the ordered componentsare at bottom of a stack, you need to remove the top of the stack to get your components.you could spend a lot of time looking for these unique components. This can end up to be avery time consuming task. The advantage of this solution is that the truck is able to pick-upcomponents for many different projects.

4.8.4 On-site component registration

This solution is very similar to solution three, but instead of pre-registering the components toa delivery address of an order, the workers of the storage plot will use a mobile reader to linkeach component to an address when they load the truck. This way they won’t have to pick upspecific components.It has the disadvantage of moving the registering from the computer friendly office personal tothe storage plot workers, who often doesn’t have much knowledge of technology.This might also become a very time consuming task for the workers.

22 of 112


4.8.5 Decision

Option one has too many disadvantages with different trucks to come up on top.Option two removes these disadvantages. The only disadvantage left is that the truck is onlyable to carry components of one delivery address.Option three has too many disadvantages with having to find specific components.Option four is good, but put too much technology jobs on the workers.

From these considerations, I choose option two. Option four will become the backup-planif option two causes to many problems.

4.8.6 Backup system

If any of these solutions fails, we need a backup system.

• Option one: If an untagged truck picks up components.• Option two: The truck driver forgets the RFID sticker.• Option three/four: The components haven’t been registered to an address.

The storage plot should mount security cameras at their gate.If any of these problems occurs, the storage plot manager is notified by the the server with alist of components which doesn’t have a destination address.Now he can manually enter the destination address either from memory, the camera or receipts.

23 of 112


4.9 Interim Conclusion: Hardware set-up

From the previous sections I have build up a set of advantages and disadvantages for bothhardware suggestions. I will now sum up these.

Hardware suggestion one

Advantages:• Cheapest

Disadvantages:• Bad direction detection options• No proper way to detect passing components

24 of 112


Hardware suggestion two

Advantages:• Great direction detection options• Statefull components let it detect Passing components

Disadvantages:• Expensive

4.9.1 Summary and decision

Hardware suggestion two is way ahead of suggestion one. The only disadvantage is the cost.The greatest disadvantage of suggestion one is that I have found no stable solution for ignoringpassing components. This is a deal-breaker since it can potentially cause a lot of false readings.The other disadvantage is its weak abilities for detecting direction.A proper solution of these two problems is well worth the cost.

The solutions for solving the problems of ”ill-placed components” and ”position of leavingcomponents” work equally well for both hardware suggestions and has been taken out of theequation.

Hardware suggestion two is the clear winner.

In the following sections I will analyse the remaining problems:• Bundling of components• Server communication• Configuration• Update System

25 of 112


4.10 Bundling of components

Now that the hardware set-up has been decided, as well as how to collect the data, I need todecide how to process the data before the sending it to the server.

Since components need to be linked to a project/address, as decided in section 4.8 page 22,they need to be bundled with a project/address-tag.

Please note that quarantined tags/components are ignored in all discussions below (as ex-plained in section 4.6 page 19.

The most obvious solution would be to bundle components together as long as there’s tagsin the readfield. As soon the readfield is empty the tags would be bundled together and sent.

With this solution a problem arises.

Example:

As shown in the images above, in cases of long trucks it would be possible for the bundleto be split in two and the second bundle would not have a project/address tag attached.

To solve this problem we would need to implement a ”calm”-timer. The bundle would not bewrapped up and sent to the server before the readfield haven’t registered any tags/componentsfor X time.

26 of 112


4.10.1 Splitting trucks apart

With the ”calm”-timer (and possibly before) a new problem arises.How do we split up two truck, which drives right after each other?This is one of the problems of RFID technology: splitting tags which doesn’t belong together.

To not overcomplicate things I would like a simple low-tech solution.Two light are installed: A green and a red light. When no tags are in the readfield, the greenlight are lit and trucks are allowed to pass through the gate. As soon as a tag/component isdetected, the red light will light up and the second truck will have to wait till the light turnsgreen.

4.11 Server communication

There’s two aspects of the server implementation. Technology and protocol. I will discuss bothbelow.

4.11.1 Technology

Now that all data are collected and bundled together we need to send it to the server.Several options are available and I chosen to discuss two highly viable methods.

TCP/IPSocket programming using TCP/IP is very fast and highly customizable.The disadvantage is that we’re working on the Transport layer (OSI-model) and we have tobuild the Application Layer from scratch.If speed and customizability is an important factor, this is the way to go.

REST Web ServicesRESTful Web Services are a software architecture, which is build on top of the HTTP protocol.Due to the wide variety libraries, implementation is very easy. Lemon (server of Entreprisepor-talen.dk) already have REST implemented and with a client library, it would be very easy toimplement.

Since REST is already very integrated into the systems of Pernexus, it is the obvious choice.This system won’t need to send huge amount of data quickly and there’s no need to customizethe application layer.

To make things even easier, JSON has been chosen as the encoding format. It is lightweightcompared to other encoding like XML and is widely supported (especially with Java Libraries).

With a proper REST/JSON libraries, implementation will be easy.

4.11.2 Protocol

From the decisions of the previous sections I found two use-cases for communication betweenthe Stationary Gate System and Lemon.

• Send bundle of components• Quarantine component

For use-case explanations refer to section 9.2 page 71.The implementation is explained in section 6.3.6 page 48.

27 of 112


4.12 Configuration

Since the system might be deployed at several different locations, each of these need to becustomized to the specific situation.

I have found the following variables which should be configurable on each location:• identifier of each specific system (installation).• default destination installation, which component should be transferred to if the address

tag doesn’t specify one.• Location• How long should the components stay in the tag-list before they are removed? (see section

4.7 page 20 for details)• How long should the components stay in the readfield before they are quarantined? (see

section 4.6 page 19 for details)• What are the limit of the ”calm-timer”? (see section 4.10 page 26 for details)• Server setting. Only used for debugging.• Server authentication

All these options should simply be loaded from a file during start-up of the system.

4.13 Update system

Since the requirements (section 9.1 page 70) demands the system to be automated (N2), easy-to-use (N1) and update automatically (F7) an update system need to be developed.

I have found two different approaches to solve this system: push and pull.

4.13.1 Push method

The updating responsibility is held by the server.When an update is available the server will push it out to all the stationary gate systems.The advantages is that you have a lot more control of when the updates should be deployed.

The disadvantage is that you have to keep a list of all deployed stationary gate systems. IPsmight not be static, which means you have to keep the list up to date at all times.

4.13.2 Pull Method

The updating responsibility is held by each stationary gate system.The system will check for an update once per night. If an update is available it will pull it

from the server and install it.The advantages is that you don’t have to keep a list of all systems. The disadvantage is

that you have limited control of when a system will be updated.

4.13.3 Decision

I have chosen the pull method, since it eliminate the need for keeping a list of all deployedsystems and the implementation is much simpler.

Pernexus Systems updates their system once every four weeks. It is done during the evening.The system will normally only been in service betweens something like 5:00 to 16:00. If anupdate is made available at 20:00 and the systems then checks for updates at 24:00, the systemshould perform just fine and no downtime is present.

28 of 112


4.14 User interface

Now that I have settled how to get the data into the system, the users will need a way ofreading it.

Currently Entrepriseportalen.dk already has a system for showing data on components (seethe next chapter for details). Since this system works fine and the JBoss Application Server isnot my area of expertise, I have chosen to let this system stay as it is.

Pernexus Systems also have an Android application (EP Mobile) of which I have designedand coded a great deal of.I have chosen to focus my presentation of data in EP Mobile.

I will start by showing and explaining the already existing website interface.After that I will analyse and develop the design of component tracking in EP Mobile (Lime).

Jump to section 4.16 page 32 for more info on the EP Mobile design.

4.15 Website interface

The website interface was made a while ago (before I joined Pernexus Systems) and I havedecided to let it stay as it is. It should be noted that this was NOT made by me.

Two different ways of accessing your components exists:• Method 1: Getting a list of all accessible installations• Method 2: Getting a list of all accessible components.

I will start by explaining the first method and on page 31 I will explain the second method.

4.15.1 Method 1

If you choose to search by installations you will get a list of installations accessible to you (seeimage below).Above the list, the installations location data will be shown on a Google Map implementation(if the data is available).Select an installation to continue.

29 of 112


After selecting an installation you will be presented with information of this installationsand a list of components which belongs to it (see below).

From the interface above you can select a components and will be presented with theinterface below. The interface below will contain all information of the component, includingits tracking data.

Sadly no tracking data was available on this component

This was the first method on how to access you components by the web interface.

30 of 112


4.15.2 Method 2

The second method will show you a list of all components of which you have access (see examplein image below).A map of their locations are shown above the list.

By selecting a component in this list you will be brought to the interface containing com-ponent details.The component detail interface was presented on the previous page.

The second method is more direct, but less organized.

31 of 112


4.16 Android Application

As mentioned earlier I have chosen to focus my user interaction through EP Mobile (AndroidApplication of Pernexus Systems.

From an use-case analysis with the Michael Søndergaard (Managing Director of PernexusSystems), we have found three interesting use-cases for Lime.

Lime has the advantages of being mobile and having access to GPS data, which has influ-enced the use-cases.

We came to the following use-cases:• Find Components near you (with a filter on component-type)• Search components by installation• Search components by component-type

See section 9.2 page 71 for a use-case diagrams and descriptions.I have chosen to prioritize the use-cases and only implement one of them. The two remaining

will be extra features and will only be implemented if the time is present.

1. Search components by component-typeI have chosen to prioritize this use-case highest. It has the highest versatility and all componentare accessible through it.

2. Search components by installationComponents are not necessarily linked to an installation, but the use-case is very relevant ifyou want to find the components linked to a specific project/installation.

3. Components near youThis use-case is the least versatile since it will only allow you to find components near you.Because of this I have to chosen to prioritize this use-case the lowest.

Now that ”search components by component-type” has been chosen and have been explainedin the appendices (see section 9.2 page 71), I will start to discuss the design of this use case.

I will start by discussing the layout and functionality followed by how to communicate withthe server.

32 of 112


4.16.1 Functionality and layout

Since computer experts are not the targeted users of this application, the design will have tobe simple and intuitive.

The design will have the following requirements:

User Interaction:• UI1: Input search query• UI2: Search button• UI3: Pick from component-type result-list• UI5: Access to more component information

Data representation:• DR1: Component-type result-list• DR2: Component result-list (Map)• DR3: Component result-list (List)• DR4: Detailed component information

To limit the complexity of each activity I have chosen to split this information into twoactivities and two dialog boxes.

Activity 1: Search Activity

Map image from Google Maps

This will be the search activity which will be where the user starts.Most of the requirements are fulfilled in this activity. The only requirements, which isn’t

represented is DR1, DR4 and UI3.At the top you will have the query input and search button (UI1 & UI2).

33 of 112


After a search query has been entered and the search button has been pressed, four thingscan happen.• If no component-types are found the user will be notified.• If more than one result is found, the results will be shown in ”Dialog 1”.• If one result is found, the components of that type will be shown in tab 1 and tab 2.• If one result is found and no components of the component-type exists, the user will be

notified.

Below the query input/search button two tabs will be located.In tab 1 (Map), the component results will be shown on a map (DR2).In tab 2 (List), the component results will be shown in a list with limited component informationand the distance from you (DR3).If a map-marker or a list-item is pressed it will direct the user to ”Dialog 2” (UI4).

Dialog 1: Component-type result-list


This dialog is shown if more than one result of the search is found.It will list the first 50 result of the query (DR1).If more than 50 results are found, the user will be notified and told to be more specific.By clicking a list-item, the user will be sent back to ”Activity 1” and a specific search is done(UI3).

34 of 112


Dialog 2: Detailed component information

This layout is shown if the user clicks a list-item or map-item of ”Activity 1”.This will show most of information of a component (DR4).The only missing information will be the tracking data. This information is shown in ”Activity4” and accessed by clicking the ”Track Component” button of this dialog.

Activity 2: Tracking data of component


This activity is simple and contains a map of all position data linked to the component(DR4). It is accessible from ”Dialog 2”.

35 of 112


4.16.2 Android server communication

I will start by discussing the technology to use, followed by how the protocol should be build.

TechnologyFor the choice of technology I would like refer to section 4.11 page 27.Once again, and for the same reasons, REST web services is chosen as the method of commu-nication.

ProtocolFrom my previous functionality analysis (see section 4.16 page 32) I have determined the needfor the following server communications functionalities:• Search components by component-type.• Get component details.

”Search components by component-type” will be required to handle three different use-cases:• Search query returns no component-type• Search query returns one component-type• Search query returns many component-types• Search by selection of the above results

The implementation is explained in section 6.4.2 page 58.

36 of 112


5 Complications

During the project I ran into a few problems.The communication between HOFOR and myself was lacking and meetings took quite a whileto plan and execute. This meant that at some point I had to limit the real world implementationof the project and at the end, it ended up as a proof-of-concept instead.

In addition to this I ran into some hardware problems.I have been in contact with an American company called Intelliflex. They produce semi-passive(class 3) RFID equipment. From a first look at their website and product datasheets, theirEuropeans support seems to be okay.To make sure everything was alright I ”recruited” a colleague in Veriloc Automation (PeterGreenfort) who knows more about European certification. He discovered that they didn’t haveany real documentation on the European standard (ETSI Standards) and during his searchthey actually closed down their European office. After that they haven’t been very responsive.

Because of these two complications I have decided to scale down the project, due to shortageof time.Instead of a fully tested system on roadway bridges, the project have been ”reduced” to astandard asset management system. The system will be the same, the difference lies mainly inthe testing.Also since I can’t get an ETSI Standard certified class 3 reader, I have chosen to use an olderpassive reader. The functionality will be the same, the difference lies with the read ranges.

Because of the change of reader, another requirement has been added (see section 9.1 page70 for requirements).The system will need to be modular, which makes an easy integration of a class 3 reader, oncea suitable have been found in the future.

More on this modularity and the change of hardware can be found in the implementationsection 6 page 38

37 of 112


6 Implementation

All projects of Pernexus Systems have codenames which are related to citrus-fruits.I have chosen to continue this practice and named my stationary gate system ”Grape”. Allsystems will be referred to by their codename in the implementation section.

Below is a table of all projects of Pernexus Systems and their codes:

Codename Description

Lemon JBoss Application Server of Entrepriseportalen.dk

Lime EP Mobile (Android Application)

Pomelo Integration server

Grape Stationary Gate System

I would like to start by deciding on the programming language.After the programming language has been decided I will start describing the implementation

of the Grape (section 6.2 page 40).

After this I will explain the implementation of Lime (section 6.4 page 55).

38 of 112


6.1 Choice of programming language

I have chosen to decide on the programming language after the analysis and design, because Idon’t want the language to dictate the design. My opinion is that you can create more or lessanything in any programming language. It is only a matter of difficulty and speed.

I have several programming/scripting languages under my belt. These include, but are notlimited to, Java, C, C++, VHDL, Assembler, PHP and Javascript.

My current favourites are Java and C, and I have chosen to discuss these two.

6.1.1 Java

Java is an easy and great language for systems which are not performance-dependant.Implementation is easy and libraries are plentiful.

One of the main strength of Java is its versatility. Since it’s running in a virtual machine itcan run on almost all system with the same compilation.

Another big plus for Java is the fact that Pernexus Systems is a Java-oriented company. Alldevelopers of Pernexus Systems are very capable with Java and their entire project managementsystem is based on the JBoss Application Server.

This factor rates high, since another developer might have to take up the updates, when Ileave the company at some point.

6.1.2 C

C is the language of speed. It’s old and has proven its capabilities.It is a functional programming language, where Java is object oriented. The downsides of Cis mainly the system specific compilations. This means that it is very dependant on processorarchitectures and operating systems.

6.1.3 Decision

I would’ve liked to do some of the this project in C, but mainly due to the maintenance of thesystem I have chosen to do the entire thing in Java.

This is the faster choice and I won’t have problems working on ARM/x86 Linux/Windowsmachines.

39 of 112


6.2 Stationary Gate System

I have decided to split the implementation of the stationary gate system into two part. First Iwill explain the final hardware set-up and after that I will go through the software implemen-tation (data collection and server communication).

6.2.1 Hardware

As mentioned in the ”Complications” section (see section 5 page 37) I’ve had to change theproject to a proof-of-concept, which means my hardware set-up will be quite less impressive.

Because of this I have chosen to split my hardware section in two:• My test set-up• Future real world set-up (page 43).

Test set-up

My test set-up is quite simple.

40 of 112


AntennasAs shown on the diagram above I will have 4 antennas, which has been set to be mono-static

(each antenna transmit and receive), which reduces the performance, but saves me the need toacquire another reader.

The antennas are set up with two readzones as decided in section 4.9 page 24.

Reader Set-upThe reader is an Alien Technology ALR-8800, which have the four antennas attached, power

and ethernet.

41 of 112


The reader needs to be configured before it can be used for this system.Since the reader by default is set to have DHCP enabled it’s not easy to get the IP addresswithout router access or network scanning. To simplify the configuration, it is done by usingan USB-to-Serial adapter and the terminal program ”putty”.

The following commands should be executed in the shown order to set up the reader prop-erly:

Command Value Description

factorysettings Reset reader to factory settings.

dhcp off Disable DHCP.

ipaddress 192.168.1.147 Set IP-address.

netmask 255.255.255.0 Set netmask.

gateway 192.168.1.1 Set default gateway.

dns 8.8.8.8 Set DNS (Google DNS).

persisttime -1 Reset internal tag-list each time tag-list ispulled.

autostarttrigger 0,0 Disable autotrigger from GPIO.

autostoptimer 0 Disable autotrigger from GPIO.

autotruepause 0 Disable autotrigger from GPIO.

autofalsepause 0 Disable autotrigger from GPIO.

taglistformat custom Custom format of tag-list.

taglistcustomformat TAG;%k;%a Tag-list formatTAG;”Tag UID”;”Antenna Number”Example:TAG;1234567890ABCDEF12345678;1

taglistantennacombine off Tag UID gets an entry for each antennathey have been discovered in.

ant 0 1 2 3 Reader from all antennas

save Save settings to flash

The format is quite simple. commands without values are simply submitted follow by acarriage return, new line. Commands with value are in the command=value format follow bya carriage return, new line.

Now that the reader has been set up the communication is done using Telnet.The only command used after this (besides Telnet authentication) is the ”get Taglist”-

command which initializes a scan of the antennas and returns the tag-list.

ControllerThe controller is currently a laptop running Ubuntu, but will be changed to an Raspberry

Pi running Debian in the future.

ServerThe server is running from another Windows 7 laptop.

This is basically the test set-up.

42 of 112


6.2.2 Future real world set-up

My optimal future hardware set-up is a bit different from the test set-up.

Opposed to my test set-up, the antennas would be set up bi-static, which means eachantenna gets the role of receiver or transmitter. This would require twice as many antennasand because reader only have four antenna-inputs I would have to require another reader.

Instead of the Alien ALR8800 (Class1 Gen2), I would use a semi-passive (Class 3) reader likethe Intelleflex FMR-6000. The FMR-6000 readers are powered by PoE (Power over Ethernet),which would erase the need of power cables.

The readers would be mounted in a waterproof protective case next to the gate. The cat5eEthernet cables would be lead to a PoE router in an office building. Another advantage of PoEis that it would be really easy to insert Ethernet extenders in case the distance between theoffice building and the gate exceeds the 100 meters a cat5e cable is capable of.

In the same office building a small (probably ARM-based) Linux device would be connectedto the router and used as the controller.

43 of 112


The router would handle the connection to the internet where the controller would be ableto contact the server of Entrepriseportalen (Lemon).

Users would be able to access the data through either their browsers or Android devices.This is basically the concept of a future real life hardware implementation.

6.3 Grape Software

Grape is basically a three layer consumer/producer program.We need an producer, which detects tags and puts the data into a shared resource (tag-list).The consumer of the tag-list is another thread, which bundles the tags. When it has

produced a complete bundle, it will send this to another shared resource (bundle-resource).The last consumer is the server communication thread. When a bundle is ready it will be

removed from the bundle-resource and the data is sent to the server (Lemon).

The data will travel the following route:

In the following chapters I will describe the implementation of each of these three threadsas well as the two shared resources.

44 of 112


6.3.1 Tag Collecting Thread

The ”Tag Collecting Thread” is responsible for getting data from the RFID reader and insertit into the taglist. It will constantly ask the reader for which tags are currently in its readfield.

Depending on the antenna and the readzone-configuration (see section 6.3.8 page 53 fordetails) it will decide the read zone of a discovered tag and insert it into the taglist.

If the tag has already been discovered it will update the timestamp of when the tag waslast seen and make sure the readzone is marked in the tags data.

6.3.2 Tag-list

The tag-list is basically a list of UIDs of tags. Each of these tags will have the followingproperties.

Property Type Description

ID String UID of tag

Status Byte See below for explanation

Discovery time Long System time of when the tag was first seen

Last seen time Long System time of when the tag was last seen

Quarantined Boolean Indicated if the tag has been quarantined

First time the tag is discovered the ”Discovery time” and the ”Last seen time” timestampwill be set. Addition discoveries (as long as the tag id already in the tag-list) will only updatethe ”Last seen time” timestamp. The quarantined boolean will be initialized as ”false” andcan only be set by the ”Tag Bundling Thread”. The status field is a bit special.

I will use four bits for indicating the status of the tag.

Bit Description

0 Discovered in RZ1

1 Discovered in RZ2

2 First discovered in RZ1

3 First discovered in RZ2

When a tag is first discovered by the ”Tag Collecting Thread” either bit 2 or 3 will be setdepending on the readzone the tag was discovered in. The corresponding bit 0 or 1 is also set.

Addition discoveries after the tag first have been discovered will only update bit 0 or 1.Since multiple threads are accessing the tag-list simultaneously, all data will be protected

against race-conditions by mutexes.

45 of 112


6.3.3 Tag Bundling Thread

This is the most complex thread.

In this thread we have to handle all the following problems:• Ill-placed Components (explained in section 4.6 page 19)• Passing Components (explained in section 4.7 page 20)

This is done by using the following state-diagram:

The thread functions by monitoring the tag-list.It starts in the ”Idle” state. When a non-quarantined tag is discovered it moves to ”Col-

lecting Tags” state.In the ”Collecting Tags” state it handles the above mentioned problems.

Ill-placed ComponentsThe thread will quarantine a tag if the different between the ”Discovery Time” property of atag and the current time is too large. The size of the difference is configurable (See section 4.12page 28 for details on this).

When this condition is met, the ”Tag Bundling Thread” will simple change the ”quaran-tined” property of a tag to ”true” and spawn a new thread, which contacts the server.

For details concerning the process of contacting the server, please refer to section 6.3.6 page48.

46 of 112


Passing ComponentsPassing components should only be discovered in one of the readzones. The ”Tag BundlingThread” will constantly check the different between ”Last Seen Time” and the current time.This is not done if the tag has passed both readzones. If this difference become too large itmeans the tag have not been in the readfield for a certain amount of time and has not passedboth readzones. The size of the difference is configurable (See section 4.12 page 28 for detailson this).

If this is the case the tag will simply be removed from the tag-list.This is also how quarantined tags are removed and ”unquarantined”.

If the tag-list is empty or only contains quarantined tags, due to the two above mentionedfunctions, the thread will return to the ”Idle” state.

If all tags have been discovered in both readzones and no tags have been discovered inthe readzone for a certain amount of time (see section 4.10 page 26 for explaination on the”calm-timer”), the tags will be bundled together, removed the tag-list and sent to the ”Bundle-Resource”.

6.3.4 Bundle Resource

The Bundle-Resource holds finished bundles until the are consumed by the ”Server Communi-cation Thread”.

Since this is vital data. If a crash or error occurs, the positions of the components could beinvalidated. Because of this the data needs to be persistent.

For this I have chosen to use a MySQL database with two tables. One table containingbundles and another table containing tag UIDs.

The tables have been configured as shown below:

table bundlesName Type Note

id Integer Primary Key

createdtime Timestamp

table components

Name Type Note

id Integer Primary Key

uid Varchar(24)

bundleid Integer References table bundles.id

status Integer

All database-transaction are made threadsafe by mutexes.Alternatively I could use the build-in functions of the database, but since databases are not mystrong suit and the system doesn’t require high performance, I have chosen the simple solutionof mutexes.

47 of 112


6.3.5 Server Communication Thread

The ”Server Communication Thread” works by monitoring the Bundle-Resource. Each time anew bundle is found it convert it to a Java class, which mirrors the database.

The new bundle class will contain its id, createdtime and a list of components, which eachhave an uid and their status (explained on page 45).

For details concerning the process of sending bundles, please refer to the next section.

6.3.6 Server Communication

The server communication is done using the Restlet API for communication with the server(server codename: Lemon). The communication is done using the JSON format. To encodeand decode JSON, Grape uses Google’s GSON library.

The stationary gate system (Codename: Grape) will only contact the server in two cases:• A new bundle of tag UIDs is ready to be processed• A tag has been quarantined

I will now explain these two cases using sequence diagrams in the following pages.

48 of 112


Send BundleI have chosen three relevant examples to explain the ”Send Bundle” communication.• Direction guess matches the database and everything else checks out.• Direction guess doesn’t match the database.• The server is down.

Before going through the examples, I would like to explain what happens when Grape triesto send a new tag bundle to the server.

The following data is required to use this function:

Name Type Description

installationId Integer The id of the storage plot in the projectmanagement system.(Entrepriseportalen)

destinationInstallation Integer The id of the default destinationinstallation.

createdDate Date Date of bundling.Used in case of the server is down.

tags Map<String, Integer> Map of tags containing their UID andstatus (explained in section 6.3.2).

latitude Double Position of the stationary gate system.

longitude Double Position of the stationary gate system.

The first thing that is done is calculating the average of the status of the tags.The result determines the direction guess:

Average Result

<8 Leaving

8-10 Inform responsible

>10 Arriving

On the next page I have created a flow diagram to explain how the server handles a lot ofcomplications (no/many address tags, unknown tags etc.).

During the process of traversing the flow diagram the following data will be handled.

Name Type Description

UIDs List<String> List of tag UIDs.

uuList List<String> List of tag UIDs which doesn’t a component/address.

mmcList List<Component> List of component where direction guess and databasedoesn’t match.

vcList List<Component> List of component, which have been validated.

AdrList List<String> List of addresses.

After the flow diagram I will start explaining the three examples using sequence diagrams.

49 of 112

Nicolai

Son

ne

May

31,2013

50of

112


Example 1:

The ”Server Communication Thread” will bundle the tags as shown in section 6.3.5 page48 and send them to the server. Before updating the components, the server will check if thecomponents new positions makes sense.• Does the components have different directions?• If the components are leaving, but an project/address tag is not present?• Is the components direction arriving, but they are already marked as being located in at

the storage plot?• Does tag UIDs with nothing linked to them appear?In this case none of these problems occur. The components passes the tests and their

position are updated. The ”Server Communication Thread” gets a ”success” returned anddeletes the bundle from its database.

51 of 112


Example 2:

In this second case one or more of the previously mentioned tests fails and the componentowner are notified about the specific problem. The ”Server Communication Thread” will stillreceive an success, since the components have been processed and the responsibility have beentransfered to the server.The notification feature has not been implemented, since this is a proof-of-concept (reasons areexplained in the ”complications” section). Instead of the owner receiving a notification, theproblems are printed in the server-log.

Example 3:

In this last case Grape can not get in contact with the server. This could be caused by theinternet being down or the server being updated/restarted. In this case Grape won’t delete thebundle and try again later.

52 of 112


Quarantine Tag

A tag has been detected to be located too close to the readfield and haven’t been movedfor a while (see section 4.6 page 19 for more on this problem). Grape has already marked thetag as being quarantined and will notify the server by sending the tag UID.Lemon will notify the user and return a ”success” message.The notification feature has not been implemented, since this is a proof-of-concept (reasons areexplained in the ”complications” section). Instead of the owner receiving a notification, theinformation are printed in the server-log.

6.3.7 Update System

Due to time limitation, I have chosen not to implement the Update System and focus on myreport instead.

The Update System have greatly lost its prioritization after the transition from an imple-mentation project to a proof-of-concept project (Explained in section 5 page 37).

Instead I will quickly explain how the system should be implemented.The stationary update system (Grape) will run Linux and the Update System will be set

up as a cron-job.Once every night at 2:00 the update system will contact the server (Lemon). If an update

is available it will download it, shut down Grape, deploy the update and start up Grape again.

That is basically how the Update System should be implemented.

6.3.8 Configuration and modularity

As explained in section 4.12 page 28 the system will need to be configurable. And as mentionedin section 5 page 37 the system will need to modular.

Both these problems are solved by using a configuration file which is loading during start-upof the system.

53 of 112


The file have the following properties:

No. Name Type Description

1 readerOneType String Determines protocol ofreader one.

2 readerOneIP String IP of reader one.

3 readerOnePort Short Port of reader one. (default: 23)

4 readerOneUsername String Username of reader one.

5 readerOnePassword String Password of reader one.

6 readerOneAntennaMap Map<Int, Int> Maps antennas to readzones.

7 readerTwoType String Determines protocol ofreader two.

8 readerTwoIP String IP of reader two.

9 readerTwoPort Short Port of reader two. (default: 23)

10 readerTwoUsername String Username of reader one.

11 readerTwoPassword String Password of reader one.

12 readerTwoAntennaMap Map<Int, Int> Maps antennas to readzones.

13 installationId Integer Entrepriseportalen-ID of thestorage plot

14 destinationInstallationId Integer Entrepriseportalen-ID of thedefault installation location

15 latitude String Latitude of the system.

16 longitude String Longitude of the system.

17 tagTimeout Long Milliseconds before tags times out

18 tagQuarantineTime Long Milliseconds before tags are quar-antined

19 taglistCalmTime Long Calm timer limit

20 serverIP String IP of server. Used for debugging.

21 serverPort String Port of server.Used for debugging.

20 serverUsername String Server authentication.

20 serverPassword String Server authentication.

Property 1 to 12 are used to configure two RFID reader.The remaining are explained in section 4.12 page 28,

6.3.9 Source code

All Grape concerned source code is located on the attached CD in /Sourcecode/Grape/.

54 of 112


6.4 Android Application

As mentioned in section 4.16 page 32 I have chosen to only implement one of the three use-cases(see use-case 10,11,12 page 78 to 79) of the android application.

The selected use-case was ”Search components by component-type” and it is designed inthe analysis section 4.16 page 32.

The application is implemented exactly as explained in the analysis section.I will start by explaining the functionality and design followed by the server communication

(see section 6.4.2 page 58).

6.4.1 Functionality and layout

As mentioned above the functionality and layout is implemented exactly as described in theanalysis and design section (page 32) with a few differences/improvements.

I will go through the application as the user would experience it.

The user is introduced to a screen with two tabs. One which shows the found componentson a map and another which shows the same components in a list. At start up no componentsare shown in either.

At the top of the screen, a input field and a search button are located. These are used tosearch for specific component-types.

55 of 112


If the search query doesn’t find any components, the user will get notified by a field in thetop of the list/map.

If a search query finds multiple component-type, the user gets a list of these returned. Theuser is now required to pick a component-type and all components of this type is returned andshown in the map/list.

56 of 112


If the search query is more specific and only find one component-type, the list of componentsare immediately returned and shown in the map/list.

If a component is selected in either the map or the list, a dialog with detailed componentinformation is shown. The information of the component are split in two catagories: generaland specific. The general information relates to the component-type and are the same for allcomponents of the same type. The specific information is information unique to the chosencomponent (ex. tag UID).A button a the bottom of this dialog allows the user to see the tracking history of the component.

This is the overall layout and functionality of the android application.In the next section I will explain the communication between the android application and

the server.

57 of 112


6.4.2 Server Communication

Basically we only need two different communication functions to achieve the functionality ex-plained in the section above.

These two functions are the following:

Description Parameters Return Values

Search componentsby component-type

- Search query- Component-type ID

- List component-types- List of components

Get component details - Component ID - All component information

I will now describe each of these and in the end explain how they work together.

Search components by component-typeThis function can work in three different ways.• 1. Search by query ⇒ multiple component-types, no components returned• 2. Search by query ⇒ one component-types, components returned• 3. Search by component-type ID ⇒ one component-type, components returned

Option one and two is used when the user searches by the search field. Option three is onlyused when the user selects a component-type from the result of option one. ”Component-typeID” is required because the names of the component-types are not necessarily unique.

This results in different flows (see use-case 10 main/alternative flow page 78).I will describe these flows in the following pages using sequence diagrams.

58 of 112


Flow one: multiple component-types

• The user enters a search query and sends the request to the server.• The server finds more than one component-types from the search query.• A list of component-types are returned (maximum 50 results due to performance).• User selects selects a component-type and sends a request with a component-type ID.• The server finds one component-type from the component-type ID.• The component-type is returned along with a list of components of the given type.

59 of 112


Flow two: one component-type

• The user enters a search query and sends the request to the server.• The server finds one component-type from the search query.• The component-type is returned along with a list of components of the given type.

60 of 112


Search components by component-typeThe last communication function is used when the user click a component from the list/map

of the main screen.It is described below by the use of a sequence diagram.

• The user selects a component from the list/map of the main screen.• The android application sends request (with the component ID) to the server.• Server find the component in the database and bundles all information together.• The component information is returned to the android application.• The android application present the information to the user.

6.4.3 Source code

All Lime concerned source code is located on the attached CD in /Sourcecode/Lime/.

61 of 112


7 Test

For testing I have chosen to do unit tests, integration test and acceptance test.

I like to use an example about building a motor to explain these tests:• Unit tests: Test the cylinders, crankshaft, spark plugs etc. are working.• Integration test: Test if all the parts work together and the motor runs.• Acceptance test: Test if the motor performs as promised.

I have chosen to join the integration and acceptance test.For more info about this refer to section 7.2 page 64.

7.1 Unit Test

7.1.1 Stationary gate system

Most of the logic of the stationary gate system have been build into the data structures andthe unit test have been done on these.

For details about the unit tests please refer to the source code in /Sourcecode/Grape/test/on the attached CD.A picture of the results are shown below:

62 of 112


7.1.2 Server

On the server I have chosen to make unit tests for the REST methods.To properly test REST methods, the server needs to be started and run locally. The unit

test program can now call the rest methods using HTTP Post. Since the methods rarely returndetailed information (often the method will return ”success” or failure”). The unit test willgrab the before and after data of the database and check if the correct changes have been made.

For details about the unit tests please refer to the source code in /Sourcecode/Lemon/test/on the attached CD.A picture of the results are shown below:

Since the ”quarantine tags” REST methods only notifies the user and doesn’t return any-thing or change the database it has not been possible to test it.

7.1.3 Android Application

I have chosen not to run unit tests for the android application.Android require some special test SDKs for creating and running unit tests. Due to time

pressure I have prioritized the learning of these SDKs down.Beside these points, The android application is mainly presentation of data and no really

complex logic is processed. For testing the interface and functionality, the integration test ismuch better suited.

63 of 112


7.2 Integration & Acceptance Test

I have chosen to do the integration and acceptance test by doing a use-case test.By testing all use-cases I can confirm all parts of the system are working together, which is

the essence of an integration test. By doing a use-case realization I can confirm that by beingable to perform the use-cases the system adheres to the requirements. Please see section 9.3page 80 for the complete use-cases realizations.

As mentioned in the Android application analysis (see section 4.16 page 32) I have chosenonly to implement ”search components by component-type” of the three use-cases. Because ofthis the previously mentioned use-case realization have become invalid.

I have made an updated version below:

UC1 UC2 UC3 UC4 UC5 UC6 UC9 UC10 UC11

F1 x

F2 x x x

F3 x x x x

F4 x x

F5 x x x

F6 x x x

F7 x x x

N1 x x x x x x x

N2 x x

N3 x x x x x x

N4 x x x x x

N5 x

As shown above, even when use-case 7,8,12 and 13 have been removed, all requirements arestill fulfilled.

Before I start to explain the tests, I would like to mark up my hardware set-up (see nextpage).

I have tested the main flow and alternative flows of each use-case in the appendices. Pleaserefer to these (section 9.4 page 81) for details.

In the sections following the hardware explanation I will introduce and sum up the use-casetests (see page 66).

I will start by testing the use-cases related to the Android application, since it will be usedfor reading the results of some of the following tests.

64 of 112


7.2.1 Test hardware

Before starting to explain my tests I would like to give a quick explanation of my test set-up.The grape system test set-up is quite simple. It was explained in details in the hardwareimplementation section (section 6.2.1 page 40).

Below is a simple diagram of the set-up:

As for the Android device, I have been using my Samsung Galaxy Nexus running Android4.2.2.

65 of 112


7.2.2 Use-case 6/10

I have chosen to combine use-case 6 and 10 since they are basically an extension of each other.

No. Environment Actor Description

6 Lemon Lime Search components by component-type

10 Lime User Search components by component-type

Use-case 10 defines how the user uses the Android application to search for component bycomponent-type. Use-case 6 defines how the Android application asks the server the same.

I have tested the following cases with the before mentioned use-cases:• Search query returns no results (see page 81 for details).• Search query returns one result (see page 82 for details).• Search query returns more than one result (see page 83 for details).

All tests have been executed successfully and the system was able to fully adhere to theuse-cases.

7.2.3 Use-case 9/13



9 Lemon Lime Get component details

13 Lime User Get component details

Use-case 13 defines how the user selects an component and is presented with its details inthe Android application. Use-case 9 defines how the Android application asks the server forthe information.

Only a single test was done concerning use-case 9 and 10.I was a simple test where information on a component was pulled and displayed.(see page 86 for details)

The test was executed successfully and the system fully adhere to the use-cases.

66 of 112


7.2.4 Use-case 1/3



1 Grape RFID Reader Tag Information

3 Lemon Grape Send bundle of tag UIDs with direction guess

Use-case 1 defines how Grape collects and sorts tags from the RFID reader. Use-case 3defines how Grape sends the bundles of tag UIDs to the server (Lemon).

I have tested the following cases with the before mentioned use-cases:• Tracking test (see page 87 for details).

– Components start at the storage plot. They are then driven to location 1, back tothe storage plot and then to location 2. Data confirmation is done using the androidapplication.

• No address tag (see page 92 for details).• More than one address tag (see page 93 for details).• Unclear direction guess (see page 94 for details).• Components passes the gate (see page 95 for details).• Direction guess doesn’t match the database (see page 96 for details).• Unknown tags (see page 97 for details).

All tests have been executed successfully and the system was able to fully adhere to theuse-cases.

7.2.5 Use-case 1/4



1 Grape RFID Reader Tag Information

4 Lemon Grape Quarantine tag

Use-case 1 defines how Grape quarantine tags from the RFID reader. Use-case 4 defineshow Grape notifies the server (Lemon) of the quarantine.

Only a single test was done concerning use-case 1 and 4.A component was placed in the readfield and was quarantined. Afterwards a batch of componentpassed the gate and was not blocked by the quarantined component.(see page 98 for details)

The test was executed successfully and the system fully adhere to the use-cases.

67 of 112


7.2.6 Test Conclusion

I would like to start by showing the use-case realization.

UC1 UC2 UC3 UC4 UC5 UC6 UC9 UC10 UC11

F1 x

F2 x x x

F3 x x x x

F4 x x

F5 x x x

F6 x x x

F7 x x x

N1 x x x x x x x

N2 x x

N3 x x x x x x

N4 x x x x x

N5 x

As mentioned earlier and explained in section 6.3.7 (page 53), I did not implement theUpdate System hence I have not been able to test use-case 2 and 5.

These use-cases have been marked as red in the above table. Because of this I have notbeen able to fulfil requirement F7 (System should update automatically.

Because of the transition from an implementation project to an proof-of-concept project,this requirement have been moved to the bottom of the requirement-list and will only be relevantonce the system is to be implemented.

Most of the remaining requirements have been fulfilled. Requirement N2 (System shouldbe automated) have been weakened due to the system not updating automatically. Yet theremaining of Grape is automated.

Overall I think the result fulfil the requirements nicely from a proof-of-concept point-of-view.

68 of 112


8 Conclusion

8.1 Product assessment

Overall I am very happy about the final product. Sadly the project was transformed from animplementation project to a proof-of-concept project, which limited the real world implemen-tation quite a bit.

Most requirements was fulfilled. The only requirement that wasn’t implemented was the”Update automatically” requirement, which lost a lot of its priority after the project went to aproof-of-concept state. A solution was designed and the implementation was figured out, butnever went ”live”.

The system is very capable of handling all the problems, which was presented in the analysis.The integration into the eco system of Entrepriseportalen was a success. The only part missingon that front is the error handling. Currently the server will simply log the error instead ofnotifying the owners.

I am very happy how the Android application turned out. Searching and finding componentsare really helpful and done in a simple and orderly manner.

Sadly I was never able to get hold on a proper semi-passive RFID reader. I would like tosee how the system will perform once they become more available.

Overall I am very happy about the final product, but there’s definitely some future devel-opment.

8.2 Process assessment

This is the first time that I tried working alone on project this size. During all previoussemesters I have been involved in a team of two or more. This mean that during this projectI ended up doing some stuff, which other members of the group normally did and it ended upas a good learning experience.

The work at Pernexus Systems have been great. People have been nice and helpful.Sadly the communication with HOFOR haven’t been as easy as I had hoped. The fault

is shared between HOFOR and myself. I haven’t been the fastest to plan meetings and theyhaven’t been the fastest to respond.

Before my internship I had never worked in an IT company before and the internship andbachelor project have been really educational. I have had my chance to experience the realworld.

During this project I figured out that I work better in teams. I had the colleagues atPernexus Systems, but it is different from working together with someone on the same project.

Overall it has been a very eye opening experience.

69 of 112


9 Appendices

9.1 Requirements

Functional requirements define what a system is supposed to do,whereas non-functional requirements define how a system is supposed to be.

9.1.1 Functional requirements

# Description

F1 System should track components

F2 System should do so with minimal position errors

F3 System should present tracking data

F4 System should not loose vital data in case of crashes

F5 System should communicate over the internet

F6 System should store data on a central server

F7 System should update automatically

9.1.2 Non-functional requirements

# Description

N1 System should be easy to use

N2 System should be automated

N3 System should be available 24/7

N4 System should be interfaced with the ”Entrepriseportalen”-ecosystem

F5 System should be modular (RFID-Readers)

70 of 112


9.2 Uses-case specifications

UC1: Tag Information

Brief description:Each time the RFID reader detects a tag, the tag-ID and some other information is sentto the stationary gate system. The system will clean out duplicates, remove invalid tagsand package a collection of tag-IDs to a persistent datasource.

Preconditions:Minimum one RFID tag enters the read-field.

Main flow:1. A RFID tag is detected and information is read2. Tag-IDs are bundled together3. When all RFID tags has exited the system, the bundle is sent to the persistent data-source

Postconditions:No RFID-tags in the read-field.Tags are sent to the server (see use-case 3 page 74).Next batch of RFID tags can drive through the gate.

71 of 112


UC2: Update System

Brief description:Update available. The system will be stopped, updated and started.

Preconditions:New update available (see use-case 5 page 75).

Main flow:1. User inputs a search query2. List of relevant components returned and shown.

Postconditions:User has the correct results.

Alternative flow:1. User inputs an empty search query2. List of all components returned and shown.

72 of 112


73 of 112


UC3: Send bundle of tag UIDs with direction guess

Brief description:After a bundle of tag UIDs have been bundled together it will be sent to the server.

Preconditions:Bundle of tag UIDs available (see use-case 1 page 71).Direction makes sense.

Main flow:1. The stationary gate system will constantly check for new bundles of tag UIDs2. A bundle is found and sent to the server with a direction guess.3. The server will insert the new location for each component

Postconditions:User is able to see the changes on the Android app / browser-interface.

Alternative flow:Direction doesn’t make sense1. Server receives tag UID bundle from the stationary gate system2. Direction doesn’t make sense with data in database3. Database is updated, but marked suspended.4. Warning mail is sent to the person responsible of inventory5. This person checks the security camera and decides the correct direction.6. Data suspension removed.

UC4: Qurantine Tag

Brief description:The stationary gate system has quarantined a component and notifies the server.

Preconditions:A component has been quarantined by the stationary gate system.

Main flow:1. The stationary gate system has quarantined a component.2. The stationary gate system notifies the server.3. The server notifies the person responsible of the component

Postconditions:The person responsible of the component moves the component from the readfield.

74 of 112


UC5: Check for software update

Brief description:The stationary gate system will check for update in a to-be-decided interval. If an updateis available, the system will download it and update the software.

Preconditions:Software-update available.

Main flow:1. The stationary gate system will check for updates at a specific interval (probably everynight)2. Update is found and downloaded.3. The system will be updated (see use-case 2 page 72)

Postconditions:System starts up normally.

Alternative flow:No update available1. The on-site system will check for updates at a specific interval (probably every night)2. No update found.

UC6: Search components by component-type

Brief description:The android application sends a search-query for a component-type to the server. Theserver will either return a list of component-types or a list of found components.

Preconditions:Use-case 10 have been executed (see page 78).

Main flow:Multiple search results: 1. Android application sends a search query to the server2. List of component-types are returned to the android application.Alternative flow:One search result:1. Android application sends a search query to the server2. Only one component-type found.3. List of components (of the found type) are returned to the android application.

75 of 112


UC7: Search components by installation

Brief description:The android application sends a search-query for an installation to the server. The serverwill either return a list of installations or a list of found components.


Main flow:Multiple search results: 1. Android application sends a search query to the server2. List of installations are returned to the android application.Postconditions:The user is able to get detailed information on each component.

Alternative flow:Only on installation found:1. Android application sends a search query to the server2. Only one component-type found.3. List of components linked to the installation are returned to the android application.

UC8: Search components near me

Brief description:The android application send request for components near its position. Based on positionand max distance, a list of components are returned.


Main flow:1. The application sends a request with its position and max allowed distance2. The server find the components which are within the allowed vicinity.3. The server returns the list of components to the android application.

UC9: Get component details

Brief description:The android application request information on a specified component.

Preconditions:Android application knows the ID of the component.

Main flow:1. The android application sends a request for component information and attaches theID of the component2. The server gets the information from the database and returns it to the androidapplication.

76 of 112


77 of 112


UC10: Search components by component-type

Brief description:The user inputs an search-query for a component-type into the android app. The appwill either return a list of component-types or a list of found components.

Preconditions:Search query matches one or more component-types.

Main flow:1. User inputs a search query2. List of component-types returned and shown to the user.3. user selects a component-type4. List of components returned and shown to the user.

Postconditions:The user is able to get detailed information on each component.

Alternative flow:Only on component-type found:1. User inputs a search query2. Only one component-type found.4. List of components of the selected component-type returned and shown to the user.

UC11: Search components by installation

Brief description:The user inputs an search-query for an installation into the android app. The app willeither return a list of installations or a list of found components.

Preconditions:Search query matches on or more installations.

Main flow:1. User inputs a search query2. List of installations returned and shown to the user.3. user selects an installation4. List of components returned and shown to the user.

Postconditions:The user is able to get detailed information on each component.

Alternative flow:Only on installation found:1. User inputs a search query2. Only one installation found.4. List of components linked to the installation returned and shown to the user.

78 of 112


UC12: Search components near me

Brief description:The user is presented to a list of components near his location. He is able to filter theresults.

Preconditions:Components are present in the defined vicinity.

Main flow:1. User opens the activity2. List of close components are returned and shown to the user.3. User filters the results by component-type.

Postconditions:The user is able to get detailed information on each component (see use-case 13 page 79.

UC13: Get component details

Brief description:User selects a component (see use-case 10,11,12 on page 78 to 79) and get its detailedinformation.

Preconditions:User has searched for and selected a component.

Main flow:1. User selects component2. Android app get all the information of the chosen component.3. Component information is presented in the android application.

79 of 112

Nicolai

Son

ne

May

31,2013

9.3 Use-case realizations

UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC9 UC10 UC11 UC12 UC13

F1 x

F2 x x x

F3 x x x x x x x x

F4 x x

F5 x x x x x

F6 x x x x x

F7 x x x

N1 x x x x x x x x x x x

N2 x x

N3 x x x x x x x x x x

N4 x x x x x x x x x

N5 x

80of

112


9.4 Use-case test

9.4.1 Use-case 6/10

Search query returns no resultsPreconditions:

Query doesn’t match any component-types.

Expected Flow:

1. User insert query and press search.

2. Android application sends the query to the server.

3. Server finds no component-types containing the query.

4. Server returns an empty list of component-types.

5. User is notified that no components have been found.

Actual Flow:

1. User inserts the query ”asdfghj” which doesn’t result in any component-types.


3. The server outputs the following:

As shown above no component-types have been found.

4. An empty empty list of component-types was returned to the Android application.

5. The android application shows a message that no component-types have been found.

81 of 112


Search query returns one resultPreconditions:

Query only matches one component-type.

Expected Flow:



3. Server finds one component-type containing the query.

4. Server finds one or more components of the found type.

5. Server returns a list only containing the found component-type and a list containingall the found components.

6. Android application shows a list of all returned components.

Actual Flow:

1. User inserts the query ”Roadway Bridge Type 1”.



One component-type have been found (number 64619 called ”Roadway Bridge Type 1”and 2 components of this type have been found.



82 of 112


Search query returns more than one resultPreconditions:

Query only matches more than one component-type.

Expected Flow:



3. Server finds more than one component-type containing the query.

4. Server returns a list of the found component-types.

5. Android application present the found component-types in a list

6. User selects a component-type from the list 7. Android application sends a requestwith the ID of the chosen componen-type to the server.

8. Server finds the component-type with the given ID.

9. Server finds one or more components of the found type.



Actual Flow:

1. User inserts the query ”type”.


83 of 112



Five component-types have been found.

4. Server returns a list of the five found component-types.

5. Android application present the found component-types in a list

6. User selects ”Pipe Type 2” from the list.

7. Android application sends a request with the ID of the chosen component-type to theserver.


One component-type have been found (number 64617 called ”Pipe Type 2” and 2components of this type have been found.

10. Server returns a list only containing the found component-type and a list containingthe two found components.

84 of 112



85 of 112


9.4.2 Use-case 9/13

Get component detailsPreconditions:

User has searched for and found a component.

Expected Flow:

1. User Selects a component from either the map or the list.

2. Android application request information on the chosen component from the server.

3. Server finds the requested component.

4. Server returns all information on the requested component.

5. Android application shows the returned information in a dialog.

Actual Flow:

1. User inserts the component with the ID 49.

2. Android application request information on component 49 from the server.


Component with the ID 49 has been found and its data has been returned.

4. Server returns all information on component 49.

5. Android application shows the returned information in a dialog. Tracking informationis available through and bottom.

86 of 112


9.4.3 Use-case 1/3

Leaving to first destinationPreconditions:

Components are located at the storage plot.

Address tag present.

No additional problems occur.

Expected Flow:

1. Components passes the gate from the storage to the ”outside”.

2. Gate storage system bundles tags and sends them to the server.

3. Server does all necessary checks and finds no problems.

4. Server updates the location of the tags.

5. Components passes the gate from ”outside” to the storage plot.








Actual Flow:

- Components are located at Forlandet 29.

1. Components passes the gate from the storage plot to the ”outside”.

87 of 112



All tags are first detected in readzone 1, which means they are coming from inside thestorage plot. Tag 000000000000000000000018 is an address tag, which is linked to

Herlufsholmvej 37


4. Server updates the location of the tags to Herlufsholmvej 37.

88 of 112


Left: component is now located at Herlufsholmvej 37.Middle: Tracking historyRight: Position Details

5. Components passes the gate from ”outside” to the storage plot.


All tags are first detected in readzone 2, which means they are coming from outside tothe storage plot. No address taq present.


89 of 112


8. Server updates the location of the tags to the storage plot (Forlandet 29).

Component is now located at Forlandet 29.



All tags are first detected in readzone 1, which means they are coming from inside thestorage plot. Tag 000000000000000000000019 is an address tag, which is linked to

Persillehaven 40

90 of 112



12. Server updates the location of the tags to Persillehaven 40.

Component is now located at Persillehaven 40.

91 of 112


No Address TagPreconditions:

Components are leaving the storage plot.

No address tag present

Expected Flow:



3. Server does all necessary checks and finds no address tag.

4. Server doesn’t updates the location of the tags and prints and an error.

Actual Flow:



Grape output:

3. Server does all necessary checks and finds no address tag.


Server output:

92 of 112


More than one address tagPreconditions:

Components are leaving the storage plot.

More than one address tag present

Expected Flow:



3. Server does all necessary checks and finds more than one address tag.


Actual Flow:



Grape output:

Tag 000000000000000000000018 and 000000000000000000000019 are address tags.

3. Server does all necessary checks and finds two address tags.


Server output:

93 of 112


Unclear direction guessPreconditions:

The components are detected first in different readzones.

Expected Flow:



3. The direction guess doesn’t make sense.

4. Server prints an error.

Actual Flow:



Grape output:

Tags was discovered first in mixed readzones.

3. The direction guess doesn’t make sense.


Server output:

94 of 112


Components passes the gatePreconditions:

The components are only detected in one readzone.

Expected Flow:

1. Components passes the gate.

2. Tags are only discovered in one readzone.

3. Tags times out.

Actual Flow:

1. Components passes the gate.

2. Tags are only discovered in readzone 1.

3. Tag times out.

Grape output:

Tags was only discovered in readzone 1.All tags times out. Server in never contacted.

95 of 112


Direction guess doesn’t match the databasePreconditions:

Components are already registered where the direction guess points.

Expected Flow:

1. Components passes the gate from the ”outside” to the storage plot.


3. The components are already registered at the storage plot.


Actual Flow:

1. Components passes the gate from the ”outside” to the storage plot.


Grape output:

3. The components are already registered at the storage plot.


Server output:

96 of 112


Unknown TagsPreconditions:

Tags are not registered in the database.

Expected Flow:

1. Tags passes the gate from the storage plot to the ”outside”.

2. Grape bundles tags and sends them to the server.

3. The tag UIDs are not linked to addresses or components.


Actual Flow:

1. Tags passes the gate from the storage plot to the ”outside”.

2. Grape bundles tags and sends them to the server.

Grape output:

3. The tag UIDs are not linked to addresses or components.


Server output:

97 of 112


9.4.4 Use-case 4

Quarantine TagPreconditions:

User has searched for and found a component.

Expected Flow:

1. A component is placed in the readfield.

2. The component is quarantined.

3. A batch of components passes the readfield and is successfully repositioned.

Actual Flow:

1. Tag ”300833B2DDD901400000000” is placed in the readfield.

2. Tag ”300833B2DDD901400000000” is quarantined.

3. A batch of components passes the readfield and is successfully repositioned.

Grape output:

Server output:

98 of 112

Nicolai

Son

ne

May

31,2013

9.5 Milestone plan

99of

112


9.6 Project Description

Automated Asset-Managementwith web integration to www.entrepriseportalen.dk

(Initial focus on steel roadway bridges)

Bachelor ProjectNicolai Sonne

Student-id: 100050In cooperation with Pernexus Systems ApS

Description

Abbreviations

Abbreviation Description

HOFOR ”Hovedstadens Forsygning” earlier ”Københavns Energi”

EP Entrepriseportalen (The project management software of Pernexus Sys-tems)

Problem Description

One of the biggest customers of Pernexus Systems is HOFOR and they are the ones with theproblem.

When HOFOR is digging up roads for renovations of pipes/power lines, to make sure thetraffic can keep moving, they place roadway bridges on top of the grave for cars to drive on.

Currently they have roughly three hundred roadway bridges. These are not normal metalplates, but thick steel constructions, which can handle the high weights of trucks and machinery.

Image of the roadway bridges

HOFOR are the owners of these roadway bridges and their entrepreneurs loans these forthe work they perform for HOFOR.

100 of 112


The problem is the management of these roadway bridges.Currently the roadway bridges are managed using an Excel spreadsheet.Different copies of this spreadsheet become out of sync and the spreadsheet are not always

being used.The entrepreneurs of HOFOR of course have other employers and with this ineffective asset

management, the roadway bridges sometimes ”disappear” between jobs.Each of these roadway bridges costs roughly 50.000 DKK and just recently six of them

disappeared.As explained HOFOR currently doesn’t have a way to correctly place the responsibility of

the roadway bridges and due to that the bill lands on their own desks.

Assignment Description

The bottom line of this project is to find an easy and effective way to track and handle theresponsibility of the roadway bridges.

Besides the responsibility, the system should keep track of each project gets the correctnumber of roadway bridges. If an entrepreneur by accident has taken more roadway bridges,than he has signed off on, an alert should be sent to a relevant person.

The product should have as little human interaction as possible to remove the human errorfactor and limit the time consuming job of manually registering the roadway bridges (In otherwords it should be automated).

The preferred tracking technology should be RFID, since it’s very capable of the job andVeriloc (a sister company of Pernexus) deals with sales and consulting of RFID equipment.Other technologies should be discussed.

Previous experiments has shown that portable RFID readers are not viable to be used withroadway bridges, due to the steel reflecting too much of the signal. Due to this a stationarysolution with a higher signal-power output is preferred.

As mentioned HOFOR uses EP for project management and integration into this system isobvious. Few of the end users of the project are very IT-capable, which means that the use ofa software (EP) they know are very much preferred.

Besides handling responsibility of roadway bridges, the product should be ready to beexpanded to handling all kinds of deliveries. In the future this will help stopping wrong deliveries(which happens more often than you would guess) before they are unloaded from the truck.

Suggested Extra Features

• Asset Tracking on EP Mobile– Pernexus has an Android application, which I have written a very large part during

my internship. Adding the ability to track components seems obvious.

101 of 112


9.7 Mobile and vehicle mounted reader solution

The solution for the mobile and vehicle mounted readers (VMR) are very similar. The onlydifference lies in the hardware. It is all handled by an android application, which I helpeddevelop during my internship.

Since the connection between the readers and an android smartphone/tablet should bewireless, bluetooth was the obvious choice. More or less all android smartphones/tablets areequipped with bluetooth.

Mobile readers handles bluetooth natively, while the VMR does not. The most commonconnections of the VMR are Serial and Ethernet.Since the reader is mounted in a vehicle, ethernet is not ideal. Luckily serial-to-bluetoothadapters exists.

The basic hardware set-up for both cases will look the following:

Vehicle Mounted Reader

102 of 112


Mobile Reader

With these hardware configurations, the android device will be able to connect to bothreaders by bluetooth.

I will now go through the functionality of the android application.

When opening up the application the user is first asked to turn on GPS and bluetooth,since it is required for the functionality.

103 of 112


After bluetooth has been enabled, the user asked to connect to the reader. A list of detectedbluetooth devices are shown.

After the reader has been selected we need to specify the type reader to make sure theapplication use the correct protocol.

104 of 112


A pull-up menu allow the user to look up information on bluetooth and GPS status.

We are now ready to scan RFID tags.When tags have been scanned, the application will check to see if the tag UID exists in thedatabase of the server.If the tag UID exists, limited information of the linked component will be shown in a list. Ifthe tag UID doesn’t exist in the database, it will be put in the ”unknown component” list.

105 of 112


If a known tag has been selected, it will shown the information of the linked componentand give the option to update the position of the component. Alternatively the user is able toview the tracking history of the component.

If an unknown tag is selected, it will give you the option to create a component linked tothe tag UID.This is simply done by selecting one of your catalogues and then a component-type from it.

This functionality should forfill the need for creating, updating and getting informationfrom components.

106 of 112


9.8 Handheld Reader Test

This document will show the result of the testing of the IP30 UHF Handheld RFID Reader.

For specification of the IP30 reader, refer to:http://www.intermec.co.uk/products/ip30a/specs.aspx

Test Specification

The relevant case was that of Copenhagen Energy’s need for tracking steel bridges.The steel bridges are shown below.

107 of 112

http://www.intermec.co.uk/products/ip30a/specs.aspx


The test will be done in different distances and with and without concrete blocking the tagand the reader. Two tests were identified.

Horizontal test

In this case the reader will be parallel with the steel bridge.

Standing test

In this test the user will be standing in up position and pointing at the tag.The degree of entrance will naturally be smaller as the user gets farther away.

108 of 112


Choice of tags

For the test two tags were chosen.

These were chosen by prioritizing durability and reading range.For specification concerning the tags, refer to:http://www.omni-id.com/products/RFID_tags-max-hd.php

http://www.omni-id.com/products/RFID_tags-ultra.php

109 of 112

http://www.omni-id.com/products/RFID_tags-max-hd.php

http://www.omni-id.com/products/RFID_tags-ultra.php


Set-up

When setting up the test, a problem concerning the Omni-ID Ultra became apparent immedi-ately. The tag was too wide to be inserted into the steel bridge.

The tags are to be incased in a rubber/plastic material and this made it impossible to fitthe Omni-ID Ultra. The Omni-ID Ultra was discarded, which left us with the Omni-ID MaxHD.

This tag fit much better, but has a lower reading range.

110 of 112


After testing with an open view to the tag, the tag was blocked by concrete.

Results

Below is the results shown in tables. The Omni-ID Ultra was not tested due to size and is tobe ignored.

Horizontal Test

111 of 112


Standing test

Error-Factors

The following error factors are to be considered:• Since the steel bridges were stacked, much more metal was present compared to when the

steel bridges are placed in the ground.– This may have a big impact on reading ranges.– The steel bridges are also to be scanned while stacked, but the reading range are not

as important in this case.• The concrete blocking wasn’t solid.

– We were not able to get a big solid piece of concrete.– This may have a impact on reading ranges.

Conclusion

The reading ranges are not satisfying.For this case the minimum reading range are 1.5 - 2 meters, but preferable farther.The reader did show great result in optimal conditions (6-8 meters reading range against theOmni-ID Ultra), but the real-life results were much less impressive.

112 of 112

front page placeholder see ”front page.doc”

Documents