A hybrid platform for localisation sensor fusion to
control large-scale infrastructures: LocON
Maarten Weyn#1, Glenn Ergeerts#2, Martin Klepal*3, Alain Chambron-4, Sylvie Couronné+5, Marc Fassbinder+6
#Department of Applied Engineering, Artesis University College of Antwerp
Paardenmarkt 92, 2000 Antwerp, Belgium
*Department of Applied Engineering, Cork Institute of Technology
-Fraunhofer Institute for Integrated Circuits IIS
Abstract— Localisation systems will become more and more an
important tool for controlling large-scale infrastructures.
Although singular localisation systems limit their use to a limited
number of environments and scenarios, the diverse applicability
of localisation systems and environments requires a hybrid
combination of different technologies. In this paper we combine
GPS, LPR, Wi-Fi, UWB and RFID systems in a test bed and we
describe the necessity of a standardised data protocol. We
evaluate the architecture of the fusion of different indoor and
outdoor systems. The study showed that the systems can improve
and complement each other while overcoming gaps and
shortcomings in applicability of individual systems.
We currently experience a growing demand for location-
aware services in a broad range of industrial applications. The
industries demand has driven the development of various
localisation and tracking systems that are designed to suite an
individual application. While this approach has led to the fast
proliferation of some location-aware industrial services, it also
results in systems which are dominantly based on a single
However, the rapid growth of location-aware services and
their spread into new complex industrial applications poses
extra demands on localisation and tracking systems, which are
now required to operate in heterogeneous types of
environments meeting operation requirements of multiple
location-aware control applications. Therefore, the new
localisation and tracking systems have to become extensively
multi-modal based on different complementing technologies
to cope with the increasing demands.
Different researchers already demonstrated the benefits of
combining different localisation technologies [1,2], but little
research was carried out focusing on the diversity of context-
aware applications which should be driven by the localisation
LocON‟s objective is thus to streamline the combination of
single-mode localisation and tracking systems into a multi-
modal hybrid system, which is operational across
heterogeneous environments and various control location-
aware services. The concept of LocON is based on one
platform for the „plug and play”-like integration of
localisation systems in order to control large scale
Typical location-aware control services at an airport are e.g.
continuous localisation of vehicles on an apron for safety and
security, localisation of workers, sub-contractors, visitors for
safety and security, location aware tasks allocation and
scheduling, and equipment and cars continuous
commissioning and collision avoidance at the apron.
The LocON test setup combines a Wi-Fi/GSM based
system, using signal strength measurements in buildings,
an UWB system in small, but critical areas (to distinguish
security area limits), an active RFID based system using
signal runtime measurement with geometrical methods, a
distributed system using the distance information between
nodes and a GPS-EGNOS system. This configuration enables
the LocON platform to cover a widespread set of
In order to provide the integration and the cooperation of
heterogeneous radio based localisation systems a common
protocol layer described later in this abstract was studied and
The LocON platform also fuses the location data of
different localisation systems. Being built to support control
services in large environment involving a high number of
devices the fusion is designed to be scalable for managing all
incoming data in a very limited timeframe. The scalable
aspect of the fusion architecture will be detailed in the final
The remainder of this paper describes first the diversity of
the localisation systems used in LocON. Then the LocON
protocol and data stream, which makes the combination of
different systems possible, is introduced. Afterwards the
scalable fusion architecture is described. Then one of the test
runs in Faro airport are explained in experiments
II. THE LOCON SYSTEM
A. The localisation systems
The location-aware control services for airports require
location information basically about every moving car and
staff, everywhere and at any time.
Therefore, the technologies shown in Table 1 are integrated
into one LocON hybrid localisation and tracking system.
TOA or TDOA
Table 1: Overview of systems used in LocON
B. The LocON protocol and data stream
The LocON protocol drives the “hybrid-ability” of the
concept: it allows a “standardised” communication of the
heterogeneous localisation systems with the LocON platform.
Mainly, it facilitates the communication of the position data
from various tagged objects to the fusion engine and
monitoring and control services.
In order to satisfy the requirements of the different
localisation technologies on the one hand, and the need for a
consistent protocol on the other hand, a distinction was made
between common parameters and system specific parameters
in the definition of the protocol messages. Thus, the LocON
protocol defines messages that can be categorised as follows:
Systems Position Messages are split into Standard Position
Messages and Extended Data Messages. The first one is for
simple position information, i.e. they consist of the used
coordinate system, the xyz-coordinates and a quality of
location (QoL) value. The Extended Data Messages contain
more complex, system dependent information (e.g. sensor
data) to be conveyed to the platform. They can handle any
non-recurrent, position independent information like, e.g. that
a device is overheating or malfunctioning. All these protocol
messages are directed from the localisation systems to the
Additionally, the LocON platform can send configuration
messages to the localisation systems (e.g. requesting an
adjustment of the update rate) and provides firmware update
commands to the nodes in the field.
Typical applications require confidence in the obtained
positions, a safe and secure transmission and a secure
authentication of the localisation systems. In order to achieve
this authentication, a handshaking process is defined in which,
based on OpenSSL, a private and public signing key is
exchanged. The data integrity is then assured by signing every
transmitted message or data packet with a unique signature
identifying the message source. This enables to detect packet
losses and data manipulation.
Figure 1: LocON protocol principles
Figure 1 shows the basic principle of the LocON protocol.
The packet frame consists of different message types i.e
Position Messages or extended Data Messages and a header to
identify the sender source. Additionally in the LocON
protocol there is the possibility to sign each frame for source
identification. The Message Area comprised all messages
regardless of which message type. In this example the
highlighted single message is a Position Message Type for
local Cartesian coordinates with the x, y, z coordinates and the
Quality of Location Indicator in millimeters. Representing the
Positions in ECEF or LLA coordinate system is also possible.
C. The middleware architecture
This section gives a high level overview of the middleware
architecture of the LocON platform, as displayed in Figure 2.
More detailed information about the platform architecture is
available in .
The input data received by the middleware is coming from
the different localisation subsystems who send position data
(and possibly other data) according to the LocON protocol
described in Section B.
The entry point into the platform is the Localisation System
Interface which main responsibilities are managing the
communication with the subsystems, including aspects like
authentication. The Dispatcher component will parse the
received messages and decides based on static configuration if
this message should be processed by the Localisation Engine
or if it should just be logged using the System Data Logger.
The actual processing of the location related data is done in
the Localisation Engine component which is managed by the
Localisation Engine Manager. These core components and the
scalability properties thereof are described in more detail in
the next section. The output of the platform is controlled by
the Eventbroker component. The business applications
express their interest into certain types of events by
subscribing to a (parameterized) query. The Eventbroker
manages the subscriptions and is responsible for sending the
correct data to the subscribers. Closely related to this is the
Context Data Mining component whose main task is to match
the query subscriptions predicates on top off all data streams
Subsystem Subsystem Subsystem
System Data Logger Dispatcher
Localisation EngineFusion State Logger
EventbrokerContext Data Mining
Figure 2: LocON architecture overview
D. The scalable fusion architecture
The fusion engine receives the raw location data coming
from the different localisation systems, and estimates the most
likely position of the object. The engine is based on a
switching system which can switch between a Kalman Filter
, passthrough filter, particle filter , or adjustment filter
and uses environment, measurement and motion models.
The fusion components are the most CPU demanding
components of the platform. The platform scalability mainly
depends on the level of fusion engine scalability, while
making sure that the end-to-end latency remains on a
satisfactory level. Therefore, several instances of the fusion
engine running in parallel to keep up with the stream of
position updates are required to prevent queuing and thus
The main challenge lies in the management of the fusion
engine instances so that they scale virtually unlimitedly and
ideally linearly, while keeping the latency under control. A
fully stateless model where each engine instance is initiated
with all the data it needs makes it possible to distribute
instances, but this will increase the data flow. Since some
environment data is statically defined and does not change
often at run-time, the platform can safely cache this locally in
every engine instance.
An engine instance also needs the fusion state for the
specific object, which mainly consists of the particle
distribution. This data is very dynamic so a possibility is
making use of a shared data storage system which would
allow every instance to fetch the required data when needed.
Since this data is specific for a certain object instance and
different position updates of one object are not processed at
the same time, each object can be assigned to at most one
In the current implementation we make use of pool of
operating system threads which each run one engine instance.
A manager assigns a thread for every incoming object id and
makes sure that subsequent position updates for those objects
are handled by the correct thread. The fusion state is kept in
local memory and managed by each instance.
The manager keeps a queue per object in which the position
updates are stored. Every engine instance will pick a work
item from one of the queues it is responsible for on a round-
The engine components are loosely coupled from the rest of
the platform, which makes it possible to scale out to multiple
nodes and use processes on different computers instead of
threads. The cost of doing this will be increased network
This implementation also allows executing different fusion
algorithms in parallel for every object or dependent on the
applications needs. For fast straight forward fusion only a
Kalman Filter can be used, while in parallel for example a
Particle Filter can be executed.
A special care has been taken regarding the security aspects
of the platform. All potential threats have been analysed, and
recommendations are made to enable the highest level of
The first level of security measure is on the infrastructure
level. The platform relies on the hosting environment level of
security. This means having the server running in a secure
data center with access control, and gateways to different
localization technologies in secured cabinets.
The second level of security deals with all the software
interfaces to the LocON system (from subsystems to platform,
platform to control services and control services to clients).
The interface between control services and clients is using
WCF configured as HTTPS, and authentication of clients
against the control services is planned. The interface between
the platform and the Control Services is based on AMQP that
provides both authentication of the parties and secure
communications. The interface between the subsystems and
the platform is the most critical as subsystems can be remote
and connected through WAN (GPS systems for example). On
top of a solution based on TLS, we have developed a light
weight secure layer that wraps the LocON protocol, providing
authentication, privacy and anti-replay.
The LocON platform was installed together with the
different individual localization systems in the Faro Airport.
In this section we will discuss one user scenario, which was
demonstrated during the project. The four different engine
types where used for this test.
Figure 3 shows a screenshot of the GUI which was used
during the testing and development of the system. The GUI
shows a small part of the Faro Airport, with in blue a part of
the passenger terminal. The black circles visualize fused
objects. The colored circles are raw, unfused, data coming
from the different individual systems. Currently 2 staff
members and 4 follow-me cars are tracked.
Figure 3: Screenshot of development GUI
Figure 4 shows the path of the security person, wearing 1
WiFi tag, 1 UWB  tag and 2 Wismit tags, in a red line.
The person started at the right side, and walked towards the
left side. This area is covered only by the WiFi system.
Nevertheless the UWB and Wismit systems still pick up the
tags signal which results in poor estimations. This should be
filtered by the LocON system. When the person reached the
left sides, he started walking outside. The area between the
two gates inside is also covered by the UWB system. From the
moment the person walked outside only one of the Wismit
systems can take over, since UWB and WiFi does not cover
the outside in this set-up.
Figure 4: Test track of Security Person
The persons kept walking straight out where a handover
between the two Wismit systems has to happen, as shown in
Figure 5. Than he walked back inside and back to his original
Figure 5: Overview of the Quality of Location reported by the
different systems during the handover of the two Wismit systems.
Figure 8 till 12 show the 4 individual filter types with the data
of the security person trajectory. The black lines show the
ground truth, the red lines indicate the error between the
estimated and real positions.
The pass through filter, just forwards the location estimates
of the different systems. The systems using a pass through
filter do not compare any of the incoming measurements to
remove outliers. This is exactly what can be seen in Figure 8.
Systems which do not cover a specific area, but do receive a
signal from the tag, will estimated a position and send this to
the server. Without processing these wrong estimates are
The Kalman filter is shown in Figure 9 and can remove
these outliers. But this filter type will still have problems
when different systems are sending conflicting positions with
an acceptable Quality of Location parameter.
The results of the particle filter are shown in Figure 10. The
particle filter can handle multimodal distributions, but needs
to estimate at the end one position which is send to the Event
Broker. So it will also suffer from conflicting incoming data.
Additional algorithms which can be incorporated in the
particle filters motion model cannot be fully exploited in this
environment. Map filtering is the process of removes
impossible particle trajectories because of walls and obstacles.
This algorithm shows to be very useful in small environments
with a lot of walls, but in large environments like an airport
the small improvement does not compensate the additional
The adjustment filter is shown in Figure 11 and postulates a
linear movement which helps removing conflicting positions
coming from individual subsystems. The drawback is that the
estimation will overshoot on sudden changes in the speed or
direction of the target.
The results are combined in Figure 6. Here the 3D error of
the full trajectory is shown. The adjustment filter behaves
best, closely followed by the particle filter. The high errors of
the PassThrough Filter originate from moments when a
system which is not covering a specific area does pick up a
signal of the device in a non-covered area and uses this
information to estimate -a wrong- estimate. All errors are
higher than expected since the 3D error is shown and some
systems report a height of 0 when the device is on the floor of
Figure 6: Overall error of the different engine types with the security
person test track.
The same results are also shown in Figure 9 in a cumulative
distribution function of the 3D root mean square errors. This
graph shows a mean error of the adjustment filter of 5.09 m,
for the particle filter 5.3 m, the Kalman filter 6.67 m and the
pass through filter 9.82 m.
Figure 7: Cumulative Distribution Function of the 3D RMS
Error of the different engine types
In this paper, we explained the need for a standardized data
format in order to enable the fusion of different heterogeneous
systems. We have shown the aspects that need to be taken into
account when designing high performance system. LocON
needs to be able to adapt to the best state and configuration
according to its actual environment and context. A modular
switch system between engines is introduced and an
experiment in a real airport environment in explained. The
adjustment filter copes best when contradicting information is
coming from different subsystems.
 LaMarca, A., Chawethe, Y., Consolve, S., Hightower, J., Smith, I., J.,
Shon, T., Howard, J. Hughes, J., Potter, F., et al.: Place lab: Device
positioning using radio beacons in the wild. In: Gelersen, H.-W. Want,
R. Schmidt, A. (eds.) PERVASIVE 2005. LNCS, vol 3468, pp. 116-
133. Springer, Heidelberg (2005)
 Klepal, M., Weyn, M., Najib, W., Bylemans, I., Wibowo, S.,
Widyawan, Hantano, B.: OLS – Opportunistic Localization System for
Smart Phones Devices. In Proceedings of the 1st ACM workshop on
Networking, systems, and applications for mobile handhelds,
 Talom, F.T., Denis, B., Keignart, J., Daniele, N. and Bouix, D.:
UWB Positioning Experiment in a typical Snowy Environment In:
Proceedings of 4th Workshop on Positioning, Navigation and
Communication, 2007. WPNC '07.
 Denis T., Ergeerts, G., Weyn M.: Schematic overview of the LocON
framework and guidelines for environmental requirements. In: LocON
Project Deliverable 3.1 (2009)
 Blom, H., Bar-Shalom, Y.: The interacting multiple model algorithm
for systems with Markovian switching coefficients. In: Automatic
Control, IEEE Transactions on, vol 33, no. 8, pp. 780-789 (2002)
 Weyn. M and Klepal M: OLS – Opportunistic Localization System for
smart phones devices. In: Mobile Phones: Technology, Networks and
User Issues, Nova (2011)
 Niels Hadaschik: Coexistence Analysis of the Subsystems at Radio
Signal Level. In: : LocON Project Deliverable 5.4 (2010)
 Millner, H., Gulden, P., Weyn, M., Fassbinder, M., Casaca, A.:
Description of the LocON protocols. In: LocON Project Deliverable
Figure 8: Error overview of pass through filter
Figure 9: Error overview of Kalman filter
Figure 10: Error overview of particle filter
Figure 11: Error overview of adjustment filter