2016 IEEE 30th International Conference on Advanced Information Networking and Applications

An Architecture for Monitoring and Improving

Public Transportation Systems
Pedro H. S. Duarte∗ , Luis F. Faina∗ , Lásaro J. Camargos∗ ,
Luciano B. de Paula† and Rafael Pasquini∗
∗ Faculty of Computing (FACOM/UFU), Uberlândia – MG – Brazil

Email: pedrohsd@mestrado.ufu.br, {luisfaina, lasaro, rafael.pasquini}@ufu.br

† Federal Institute of Education, Science and Technology of São Paulo (IFSP), Bragança Paulista – SP – Brazil

Email: lbernardes@ifsp.edu.br

Abstract—Brazilian public transportation systems are facing
a significant demand reduction, mainly due to the poor quality
of the offered services, lack of information regarding lines and
timetables, high cost and lack of investment from the government.
Even though it is not trivial to improve financial aspects related
to the public transportation system, this work claims that the
overall system quality can be improved through ubiquitous
data collection according to a proposed ontology, which is the
basis for knowledge extraction to support the required quality
of experience improvements. The proposed architecture relies
on standard technologies available nowadays, providing a low
cost solution for the required data collection and analysis.
This paper presents the proposed inter-networking architecture
and ontology, then evaluates the system performance using a
prototype developed with standard solutions.
Index Terms—Internet of Things (IoT), Machine-to-Machine
(M2M), Ontologies, Public Transportation Systems, Smart
World, Ubiquitous Computing.
I. I NTRODUCTION
In the last few years the demand over the public transporta-
tion systems in Brazil has been significantly reduced, while
the average amount spent by Brazilian families with private,
mostly individual, transportation has increased [1], reaching
five times the average amount spent with public transportation
[2]. The competitiveness loss observed in the Brazilian public
transportation system was caused by many factors, including
the poor quality of the service offered, its high cost, lack
of information regarding lines and timetables and also lack
governmental investment [3].
At the same time, a globally observed phenomenon indicates
that from 2007 more than 50% of the world population is liv-
ing in cities, moving from rural areas to metropolitan regions
[4]. Consequently, the infrastructure of cities needs to adapt
in order to support this population growth. However, such
adaptations are not straightforward in most of the Brazilian
cities, since the migration usually occurs before the required
infrastructure expansions.
Moreover, the raise of Brazilian population income observed
in recent years, combined with government incentives for some
industrial sectors, including the entire automotive industry, sig-
nificantly reducing tax on such industrial sectors, contributed
to part of the population opting for the private transportation.
Such increase in the number of vehicles and the difficulties for
adapting the required infrastructure in the cities, exacerbated
common problems in large urban centers, such as traffic jams,
pollution, number of accidents and urban inequality [3].
Specifically to the public transportation system, data col-
lection is extremely important in order to design and improve
the service. In Brazil, the existence of inspectors in charge of
observing the public transportation system is common, gener-
ating all the (non-ubiquitous) data that companies responsible
for the transportation systems have in order to design the
entire transport network. So, in most of the Brazilian cities,
an economically interesting (standard-technologies-based) so-
lution for automated and ubiquitous data gathering from
the transportation system is extremely desirable, which can
significantly improve the quality of the information collected,
and also improve the overall transport network design.
This work leverages the M2M (Machine-to-Machine) and
IoT (Internet of Things) scenarios to propose an inter-
networking architecture aimed at improving the data gathering
process in Public Transportation Systems. At this moment, our
focus is the Brazilian Public Transportation Systems based on
buses, and the main objective is to automate the collection
of the maximum as possible statistics from the transportation
system and to store such information in a cloud-based Public
Transport Data Service solution, according to a proposed
ontology, in order to allow running analytic processes on it
for achieving knowledge-based improvements required in the
overall transportation system.
This paper details the proposed inter-networking architec-
ture and the proposed ontology. Ontologies are explored in
various areas and studies, due to its ability to promote the
sharing of knowledge bases and inter-operability between
systems. Applying an ontology, we firstly expect to extract
the required knowledge in order to improve the public trans-
portation system quality, providing better quality of experience
to the users.
Afterwards, as another outcome of this proposal (inter-
networking architecture and ontology), we consider that many
auxiliary tools can be created. For instance, drivers could be
aided by buses’ embedded systems that provide the timetable
to follow. Passengers at bus stops could receive buses ETA
(Estimated Time of Arrival), total number of seats and current
load. The entire transport network could be automatically

1550-445X/16 $31.00 © 2016 IEEE 871

DOI 10.1109/AINA.2016.39
adjusted based on knowledge extracted from the data collected.
In this way, we hope that public transport become more
attractive, by providing easily accessible information, and
more efficient, by avoiding delays of buses and identifying
possible improvements in the system routes.
Besides the proposed inter-networking architecture and the
proposed ontology, another contribution of this paper is the
developed prototype using standard solutions available in the
market. The prototype shows the feasibility of collecting
data using standard technologies, and allowed us to presents
results on the load generated by the messages collected in
the proposed scenario and the required to move the collected
information towards the cloud-based Public Transport Data
Service storage.
The remainder of this paper is organized as follows. Section
II presents some background literature relevant to this work,
introducing current projects in the M2M and IoT scenarios.
Section III details the proposed inter-networking architecture,
explaining its main components, and the proposed ontology.
Section IV presents the evaluations performed with our proto-
type, the information regarding the overall system performance
and overhead for data gathering, and based on random data
generation over the prototype, this section also briefly intro-
duces some analyses doable using the collected data. Section
V concludes this paper and describes the future work.
II. BACKGROUND
The world is going from a Machine-to-Machine model
(M2M) to a new paradigm called Internet of Things (IoT)
[5]. Both paradigms have risen from the new technological
solutions of the last decades, including the decreasing costs
of devices and the broad adoption of the Internet. The M2M
model is built around solutions for specific problems. Basi-
cally, an M2M solution is based on a device, which senses
some characteristic of an asset, and an application, which
consumes this data. The application is self contained and any
intent to integrate different applications and share data is not
simple.
An evolution of such environment is the IoT. The idea
is to integrate all the devices, systems, sensors to a broader
scenario. In an IoT, not just data generated and consumed by
people are available in Internet, but also data from real world
objects [5]. A scenario which IoT may be explored is the
one called Smart Cities, or more widely called Smart World.
Nowadays the major part of the people lives in urban areas,
creating a demand for smarter services. In [5] it is cited many
types of so called “smart services”, including:
• Smart transportation: e. g., solutions for parking, traffic
monitoring, public transport and municipal fleet manage-
ment;
• Smart health-care: which includes management of elec-
tronic records, hospital asset management, and remote
monitoring systems;
• Smart education: including e-Learning and connected
campuses;
872
• Security and public safety: such as video surveillance,
data analysis, and work-flows for emergency services;
• Smart buildings: which include smart meters, light, heat-
ing, internal security systems, and water and waste man-
agement.
The context of this paper lies in the smart transportation
scenario. There are several projects on this context as follows.
Libelium1 , an enterprise which produces an open source
sensor platform, has tested a system of sensor platforms that
will measure the availability of parked vehicles. As part of
the European Framework 7 Program, their monitoring system
includes magnetic sensors, signal conditioning electronics, 7-
10 year life battery and a radio. The measured information is
transmitted to an access point then to the cloud, where the
processed data is used by the parking department headquar-
ters to send to displays on the street as well as to mobile
phones/tablets/computers to direct vehicles to the appropriate
available parking spots. Besides that, there is a node system
on lamp posts that senses the air quality as well as light level
to control the ambient light.
Another similar parking system, called SF Park2 , was in-
stalled in San Francisco. The system determines the status of
parking spaces and informs individuals of their existence via
mobile phones/tablets. Additionally, it provides information to
traffic enforcement when a parking meter is expired as well
as enables parking availability based prices.
A Romanian tech firm called Onyx Beacon3 is teaming up
with the local authorities in Bucharest to install beacons on
buses to inform the people about the buses. The project aims to
the visually impaired people that, using a smartphone, receives
audio information when a bus is near the stop. This smart
system frees visually impaired users from having to rely on
another person to tell them when their bus has turned up. A
smartphone app is used, which receives signal informing the
app which bus is arriving so the passengers can check if that
is the one they are waiting.
In some European cities, instead of displays, “smart tags”
are being embedded in bus station walls, tourist landmarks,
and airport arrivals lounges, allowing citizens to access in-
formation using their smartphones. In Strasbourg, users can
see if a bus is going to be late, and whether there is a bike-
share service nearby. The system shows how many bikes are
available and the distance from there4 .
In the City of Cologne, Germany, an IBM pilot project was
used to predict and manage traffic flow and road congestion.
The pilot demonstrated how the city of Cologne can anticipate,
better manage, and in many cases, avoid traffic jams and
trouble spots across the city using analytic technologies. The
city’s traffic engineers and IBM were able to predict traffic
volume and flow with over 90 percent accuracy up to 30
minutes in advance. As a result, travelers would be able to
1 Libelim - www.libelium.com (accessed on Sept. 12, 2015)
2 SFPark - www.sfpark.org (accessed on Sept. 12, 2015)
3 Onyx Beacon - http://www.onyxbeacon.com/ (accessed on 13 Sept., 2015)
4 Fast Coexist - http://www.fastcoexist.com/1681809/smart-displays-beam-
city-information-directly-to-your-phone (accessed on Sept. 13, 2015)
better plan ahead and determine whether they should leave
at a different time, plan an alternate route or use a different
mode of transportation. The traffic command center collects
real-time data from more than 150 monitoring stations and 20
traffic cameras on the roads, highways and at intersections that
are known to be traffic hot spots5 .
The work presented in this paper lies in the context of
those others presented in this section (and many others that
may be found in the literature), and as such, it is designed
to be an IoT solution, in which the proposed ontology is
expected to provide the basis for knowledge exchange among
different solutions, a step further from a simpler M2M scenario
with a single aim of improving only the bus-based public
transportation system. In the next section, the design of the
solution proposed in this work is defined.
III. P ROPOSAL
In this section firstly the proposed inter-networking architec-
ture responsible for the ubiquitous data collection is detailed.
This architecture collects data from the public transportation
system and pushes it towards the data repository at a Public
Transport Data Service. Afterwards, in this section, the ontol-
ogy responsible for data context characterization is presented,
which is essential for the knowledge extraction in order to
improve the overall system.
 
As soon as bus B1 approaches the stop point SP1 and
becomes covered by the wireless signal of the access point
AP1 available at SP1 , the time-window ΔT{B1 ,SP1 } available
for the communication process is open. The time-window is
available until the instant whenever B1 departs from SP1 and
the connection to AP1 is lost due to being uncovered by the
wireless signal. The ideal departing time is the instant defined
in the timetable, but fluctuations can occur due to, for example,
elevated number of embark and disembark of passengers.
In general, every time a given bus Bx arrives at a given
stop point SPi , the two main actions that can occur is the
embark and the disembark of passengers. Obviously, all the
combinations of such two actions are possible, including no
embark and no disembark of passengers. As higher the number
of passengers for each action at the stop point, the higher the
amount of time expected for bus Bx being stopped at stop
point SPi . So, the time-window ΔT{Bx ,SPi } is in function of
the wireless coverage area of the access point APi available at
SPi , the number of passengers embarking at SPi , the number
of passengers disembarking at SPi , and some extra time due
to unexpected occurrences i . Figure 2 depicts the sequence
of messages exchange during the time-window ΔT{Bx ,SPi } in
which bus Bx is located at stop point SPi .








A. Inter-networking Architecture

 
 !"#$%
In Figure 1 the inter-networking architecture is depicted. All
$% ) 
 !
data collection in the architecture occurs in the communication 
  !"#

between the Buses and the Stop Points composing the public  
 
#$ !     % $ 
transportation system. The proposed architecture is developed !
&$ 
 
considering that each stop point is equipped with a wireless  
  '

access point, in order to perform data exchange with the buses.     
  
 
 
  ($  !
 
 
 !    !
   "      '
 "

 
 !"#&%




)   
&%

  !"#
 

 


  

 
Fig. 2. Sequence diagram for the exchange of messages between a given bus
Bx and a given stop point SPi , during the time-window ΔT{Bx ,SPi } .
 
!
"
   

As seen in Figure 2, the entire process that occurs in
the time-window ΔT{Bx ,SPi } requires the establishment of a
 wireless communication channel between a given bus Bx and
 a given stop point SPi . Regarding wireless communication

 
      security, this work relies on standard 802.11 technologies, such

as WPA, WPA2 and the use of RADIUS for authentication. As
 
soon as the wireless secure channel is established, the buses
can access the application running at infrastructure available at
Fig. 1. Proposed inter-networking architecture.
stop points, in order to execute the proposed communication
5 IBM - http://www-03.ibm.com/press/us/en/pressrelease/40140.wss (ac- protocol depicted in Figure 2.
cessed on Sept. 13, 2015) So, in order to have stop points compliant with the proposed

873
inter-networking architecture, the main requirement is related
to their connectivity to the Public Transport Data Service
available in a cloud-based infrastructure. The amount of traffic
expected to be exchanged in between the stop points and the
Public Transport Data Service is proportional to the number
of lines and their respective frequency along the day. Conse-
quently, a single stop point located in a street, serving a small
number of lines, should require a simpler inter-networking
infrastructure, when compared to bigger terminals (central
stations), where several lines are offered.
Defining the sensing capabilities available at buses is out of
the scope of this work. But, in general, this work assumes that
a given bus Bx can easily provide timestamps, such as, the
moment when Bx arrives and departs from a given stop point
SPi . Based on such timestamps (heart beats), the inference of
the required time slot in between two stops [SPi−1 , SPi ], for a
certain line L is possible, as the inference of the average speed
in such section [SPi−1 , SPi ] is possible. As seen in Figure 2,
after established the wireless communication between bus and
stop point, the first NOTIFICATION message, with a flag set
to 0, is used to define the instant when the bus arrived at
the stop. Conversely, before departing, the bus sends another
NOTIFICATION message, with a flag set to 1, to define the
instant when the bus departs from the stop point, followed
by the wireless disconnection. By consistence and security
reasons, both moments are acknowledged by the stop point,
and the timestamps considered in both moments are provided
by the stop points.
It is important to mention that such infrastructure is capable
of providing bi-directional communication, allowing not only
the push of sensed information from the buses towards the
central repository, but also allowing the pull of information of
interest from the central repository to the buses. Based on the
time-window ΔT{Bx ,SPi } , whenever bus Bx arrives at stop
point SPi , the architecture specifies that bus Bx first requests
information from the central repository, such as, information
regarding the next stop point SPi+1 . As seen in Figure 2,
such request/response process uses two messages, ONBOARD
INFORMATION REQUEST and ONBOARD INFORMATION
RESPONSE. Such process can proactively operate, relying
on information already available at the stop point SPi , or
in a reactive basis, in which the ONBOARD INFORMATION
REQUEST message triggers a query at the Public Transport
Data Service.
Note that during the process described so far, passengers are
embarking and disembarking at stop point SPi . There are dif-
ferent technological solutions for such passengers accounting,
including image recognition mechanisms [6], or simpler solu-
tions, such as turnstiles at the doors, or bus weight checking
to provide estimations regarding the numbers of passengers in
the buses. Whenever such embark and disembark is finished,
i.e., the doors are closed, the module at the bus Bx gen-
erates the message ONSITE COLLECTED INFORMATION
and delivers it to the stop point SPi , which replies with
the respective ONSITE COLLECTED INFORMATION ACK
message. Such acknowledgment indicates that SPi received
874
the information collected at bus Bx , and en-queued it for
delivery to the central repository. SPi is responsible for
assuring that such information are correctly delivered at the
central repository at the cloud-based Public Transport Data
Service.
Besides information related to the buses and the passengers,
the architecture can also collect information regarding the
current conditions of the buses, such as, available fuel level
and engine conditions. Consequently, the size of the message
ONSITE COLLECTED INFORMATION sent from a given
bus Bx at a given stop point SPi is not fixed, varying
according to the amount of information available from the
sensors installed at the bus. The standard technology adopted
for such data transfer is REST/JSON6 [7], in which objects
according to the ontology (Section III-B) can be pushed
from the buses towards the data repository located in the
cloud-based Public Transport Data Service, relying in the
communication infrastructure available at stop points.
As seen in Figure 1, the proposed Public Transport Data
Service is based on the cloud infrastructure paradigm, which
inherently brings flexibility and scalability to the service,
based on the concepts of elasticity and agility offered by such
paradigm [8]. Basically, such concepts support the service ad-
justment according to the variable load that can be experienced
along the days or different seasons along the year.
There is no restriction regarding the model adopted for the
Public Transport Data Service, i.e., being possible to develop
such service in private cloud infrastructures, public cloud
infrastructures or any other cloud-based solution available, that
can offer the needed resources to support the components of
the architecture, which mainly are:
• Elastic Web Application: the front-end interface to pro-
vide the interactions with the stop points and buses. The
elastic requirements of such web application are in order
to adjust the service according to the current demand.
This feature offers the pay-as-you-go paradigm, which
significantly contributes to the overall costs control to
deploy such system;
• Ontology Database: the central repository that stores
the objects transported using REST/JSON containing the
sensed data pushed from the buses. The storage of such
objects is according to the ontology, and such database
is key for semantic queries in order to extract knowledge
from the collected data;
• Inferring/Mining Engine: composed of a (also elastic and
agile) set of servers running inferring/mining applica-
tions. Such engine generates the data pushed back to
the buses and stop points, in order to keep the public
transportation system running. Such engine is also re-
sponsible for providing data to the public transportation
system designers, detailing to them the overall system
behavior, and also assisting them defining the required
improvements to the system. In the IoT context, such
6 JSON-LD also may be used, which also express the semantic meaning of
data - http://www.w3.org/TR/json-ld (accessed on October 29, 2015)
 servers are also responsible for the data sharing among
other services in a widely-integrated-scenario.
The adoption of such cloud-based infrastructure is essential
for moving from the M2M scenario to the IoT scenario,
where the information collected from the public transportation
system can be available to users through the Internet, as
considered in the architecture through the Consume API,
from which, for example, Online Users (probably passengers)
can obtain information of interest from the Public Transport
Data Repository. Moreover, such information can be shared
among other services in order to deliver integrated solutions,
as proposed in the context of IoT and Smart World.
B. Ontology
As aforementioned, the main idea is to create data that
may be shared by anything (bus stops, users, buses, etc). The
approach used here is to model all data using an ontology. On-
tologies are used to define a context and establish a common
vocabulary and definition between all parts of a system/group.
The ontology defined here, presented in Figure 3 is still a
working in progress and it is based on the work of [9]. The
classes presented in the ontology are:

the reverse is Part of. A Line is exploited by a Bus and the
reverse is used by. A Bus Journey is Composed of classes Bus
and Line and the reverse is part of.
The intention is to share all data between any entity pre-
sented in Figure 1 using the Semantic Web standards, which
allows inferences and queries that relate to data that are not
explicitly linked. Queries about the data may be answered such
as “what is the average time to go from stop point SPi to
SPj ?”, “what are the best periods (considering the amount
of time spent) to go for the following bus journey?”, “is
there alternative routes to go from where the user is to some
other point in the city?”, and so on. As the data shared has
meaning based on an ontology, the vocabulary and definitions
are previously defined, which allows that new apps could be
developed and the data could be used freely by users.
The stop point itself is part of the ontology, and can benefit
from collecting information regarding the lines that stop on it,
for example, in order to display to passengers at this stop point
information regarding the buses that will arrive in the next
minutes. Such information can be enriched with the number of
passengers inside the buses, providing a hint to the passengers
whether they will be able to embark or not, based on the
historical average number of disembarking passengers.
The information provided to the passengers can indicate
whether the bus is delayed or not and, for example, also



indicating to passengers that a given bus is broken. In such
later case, the system could indicate to passengers to which

 


 

specific stop point they should redirect themselves or if it is


 
 

 
worth to wait at the same stop point for a next bus. As seen,
 
 
the demands over the system can be more complex, and the
 

proposed ontology is designed to support generating answers

to demands like these.
  




IV. E XPERIMENTAL R ESULTS / I MPLEMENTATION


 


 

We turn our attention now to an experimental evaluation of
 
  
 

this proposal. The experiments were run using a prototype

 

considering an emulated bus line at Uberlândia - Brazil,
composed by four stop points in a total segment of 8.5
Fig. 3. Proposed ontology. kilometers (≈5.3 miles) illustrated on Figure 4, where a single
emulated bus traveled in such line 200 times in each direction.
• Network: a class that express a network of buses lines; As the emulated line runs in both directions, we define Line
• Line: a class that is basically a set of stop points that a 1 as the direction from the central station in downtown to the
bus may follow; BR-050 road, and Line 2 as the opposite direction.
• Stop Point: a bus stop, where users can get into or out of Table I details the distance in kilometers from one stop point
the bus; to the other. It is important to mention that, even though the
• Bus: represents a bus; bus line runs in both directions (Line 1 and Line 2), whenever
• Driver: the person that is responsible for a Line; results are presented in this sections, the notation used to
• Bus Journey: the journey of a bus through a Line, which identify the stop points is statically defined, considering as
has information as hour, date, etc; stop point 1 – SP1 – the central station at city downtown (Av.
• Bus Journey Part: represents a segment betweem two Américo Salvador Tangari 11-13); stop point 2 – SP2 – at Av.
Stop Points for a Bus Journey. João Naves de Ávila 1352; stop point 3 – SP3 – at Av. João
The Bus Network class has the relationship Composed of Naves de Ávila 2675; and stop point 4 – SP4 – near BR-050,
the class Line, and the reverse relation is Part of. A Driver at Av. João Naves de Ávila 6970-7000.
has the relation is Reponsible for a Line, and the reverse is Figure 5 illustrates the implementation we produced in our
served by. A Line is Composed of the class Stop Point and prototype. The prototype has the following configuration:

875
Fig. 4. Emulated bus line composed of four stop points. Line 1 runs from Av. Américo Salvador Tangari 11-13 (central station) to Av. João Naves de Ávila
7000 (BR-050 road). Line 2 performs the opposite direction.

TABLE I running Linux Mint 17.1 Rebecca (64 bits) with ker-
D ISTANCE BETWEEN STOP POINTS IN THE EMULATED SCENARIO . nel 3.13.0-37. Its wireless interface chipset features a
Segment [SP1,SP2] [SP2,SP3] [SP3,SP4] RTL8188CE 802.11b/g/n WiFi Adapter.
Distance 2.3 km 1.4 km 4.8 km

Emulated
Bus

• Public Transport Data Service: It was implemented as

a cloud host at Amazon EC2, using an instance type
t2.micro, running Ubuntu 14.04.2 LTS with kernel 3.13.0-
48. The instance has a single Intel Xeon core up to
3.3GHz and 1 GB RAM memory. The central repository
was implemented using MySQL Server version 14.14
Distribution 5.5.44, for debian-linux-gnu x86 64 using SP3
SP1
readline 6.3;
M
ikr
• Stop Points: The four stop points were implemented on oti
kR
Public Transport

top of a single Mikrotik RouterBOARD 800, equipped SP2 ou SP4

Data Service

with four miniPCI slots where four R52N wireless in-
terface cards are installed, three Gigabit Ethernet ports,
two daughter-board connectors, a miniPCI-e slot and a
compact flash slot. Its CPU features a MPC8544 800MHz
core, 256MB DDR2 SDRAM on-board memory and data
storage on NAND memory chip. The RouterBOARD is
running MikroTik RouterOS v4 with Level6 license. The
stop points run as MetaRouters on top of RouterOS,
running OpenWrt ATTITUDE ADJUSTMENT (bleeding
edge, r31206), in which the modules for the Web Server
Apache 2.2.15-3, PHP5 and Mysql Client: 5.1.53-7 were
installed. So, the RouterBOARD runs four MetaRouter
instances for the emulated scenario, each MetaRouter
assigned to an individual R52N wireless interface;
• Bus: It was implemented using a notebook with Intel(R)
Core(TM) i3-2330M CPU @ 2.20GHz with 8GiB RAM,
ter
Internet
Amazon EC2
Fig. 5. Details about the prototype implementation.
Besides the prototype realization, which is part of the con-
tributions presented in this paper. The experiments that we run
allowed us to analyze the costs for the communication between
the emulated bus and stop points. The results presented in
this section are two fold. The first results elaborate about
the communication cost of the messages pushed from the
bus towards the Public Transport Data Service and, in the
sequence, the results present about the RTT (Round Trip Time)
required to pull information from the central repository to the

876
bus.
The first analysis presented in Figure 6 provides information
for the RTT required when a bus requests information from
the central repository using the ONBOARD INFORMATION
REQUEST message. Such analyses correspond to the process
depicted in Figure 2, when a certain bus Bx arrives at a
given stop point SPi and recovers, for example, information
regarding the situation at the next stop point SPi+1 to display
to passengers inside the bus. As seen in Figure 6, the average
RTT varies from ≈ [2.6, 2.8] seconds at the stop points SP3
and SP4, increasing to ≈ [3.2, 3.6] seconds at stop points SP1
and SP2.
Response delay (ms)
3600 Bus Line 1
Bus Line 2
3400
3200
3000
2800
2600
1 2 3 4
Stop Points
Fig. 6. Average RTT for performing queries from the emulated bus to the
Public Transport Data Service.
In the evaluations, we considered that none information
was proactively available at the stop point infrastructure. So,
the experiments consider the time from which the ONBOARD
INFORMATION REQUEST messages are issued at the emu-
lated bus (notebook), passes through the infrastructure avail-
able at the emulated stop points (MetaRouters running on
the Mikrotik RouterBOARD), arrives at the Public Transport
Data Service (machine at Amazon EC2) which generates the
ONBOARD INFORMATION RESPONSE messages and push
them back to the emulated bus.Such time can vary according to
several factors, including variable network traffic and variable
load on the servers located at the Public Transport Data
Service. We consider that the network traffic variation aspect
was covered in these experiments, since the communications
with the server machine at Amazon EC2 is through public
Internet. At the same time, variations on the servers’ load were
not considered in the experiments, but based on the elastic
characteristic of cloud-based infrastructures, we consider that
the service work-load can be adapted to better accommodate
such fluctuations. It is also possible to apply prediction models
in order to balance the load on the servers, for example,
considering the proposal in [10].
Therefore, we consider the obtained average RTT values
as representative to the proposed ONBOARD INFORMATION
REQUEST/RESPONSE communication process, and can fea-
sible occur in the time-window ΔT{Bx ,SPi } , expected to be
in the order of tens of seconds. It is also important to mention
that, according to the proposal, while at a stop point SPi ,
bus Bx is collecting information from its sensors (number
877
of embarking and disembarking passengers, fuel and engine
information, and others, all defined as attributes of the class
Bus of the ontology). Immediately before departing from SPi ,
a message ONSITE COLLECTED INFORMATION is gener-
ated, as described in Figure 2, containing all such information,
and it is delivered to the APi composing the communication
infrastructure at SPi , responsible for the correct delivery of
such message ONSITE COLLECTED INFORMATION to the
Public Transport Data Service. Consequently, the time to move
ONSITE COLLECTED INFORMATION from bus Bx to APi
under normal conditions (failure-free) is expected to be short,
being not evaluated in this paper.
The results presented in Figure 7 show the aver-
age size in bytes of the messages ONSITE COLLECTED
INFORMATION generated at the emulated bus in order to be
pushed to the Public Transport Data Service of our prototype.
The emulated sensors in our experiments include information
regarding the number of embarking and disembarking pas-
sengers and information according to the proposed ontology.
The obtained values in the experiments are very stable, ≈
132 bytes per message. Basically, there is a single emulated
bus, composed of the same amount of sensors in the entire
evaluation. In the real world, a different number of sensors is
expected to be present in the buses, leading to more variations
in the size of the messages.
HTTP Request Content Size (bytes)
135
Bus Line 1
134 Bus Line 2
133
132
131
130
1 2 3 4
Stop Points
Fig. 7. Average size of messages containing sensed data collected from the
emulated bus.
Even considering the same bus, and the same amount of
sensors, as seen in Figure 7, there are fluctuations in the
size of the messages. This occurs due to the REST/JSON
nature of objects serialization in the messages payload, when
factors such as variable number of characters in the objects
result in variations in the size of the messages. In essence,
the collected ONSITE COLLECTED INFORMATION mes-
sages include key information that can help improving the
overall quality of the public transportation system, and the
current average size of ≈ 132 bytes can significantly be
extended, considering an upper-bound around 1500 bytes, in
order to avoid the fragmentation of ONSITE COLLECTED
INFORMATION messages, what can raise the amount of time
required to push such information towards the Public Transport
Data Repository.
 V. C ONCLUSIONS AND F UTURE W ORK [4] U. N. D. of Economic and S. A. S. Division, International standard in-
dustrial classification of all economic activities (ISIC), rev. 4 (Statistical
This paper detailed the proposed inter-networking architec- papers). UN; Rev. ed. edition, 2009.
ture and the work-in-progress related to the proposed ontology, [5] J. Höller, V. Tsiatsis, C. Mulligan, S. Karnouskos, S. Avesand, and
D. Boyle, From Machine-to-Machine to the Internet of Things: Intro-
designed to perform ubiquitous data collection from pub- duction to a New Age of Intelligence. Elsevier, Apr. 2014.
lic transportation systems and answering semantic questions. [6] N. Bernini, L. Bombini, M. Buzzoni, P. Cerri, and P. Grisleri, “An
Specifically in this paper, the focus of data modeling is on embedded system for counting passengers in public transportation vehi-
cles,” in Mechatronic and Embedded Systems and Applications (MESA),
bus-based transportation systems. 2014 IEEE/ASME 10th International Conference on. IEEE, 2014, pp.
The results presented in this paper, regarding the RTT 1–6.
and costs for pushing sensed information towards the Public [7] M. Kazuaki, “Performance evaluation of object serialization libraries in
xml, json and binary formats. 2nd int,” in Conf. on Digital Informa-
Transportation Data Service demonstrate the feasibility of tion and Communication Technology and its Applications (DICTAP),
performing the proposed ubiquitous data collection, which we Bangkok, 2012, pp. 177–182.
consider essential for applying the required improvements in [8] C. Esteve, R. Pasquini, F. Verdi, and M. Magalhaes, “Novas arquiteturas
de data center para cloud computing,” in Book Chapter published as a
the overall public transportation network. Mini Course of the 28th Brazilian Symposium on Computer Networks
The proposed architecture can work starting with a period of and Distributed Systems (SBRC 2010), Organized by: CA Kamienski;
data sensing after the deployment of this solution in a city, for LP Gaspary; MP Barcellos. ISBN: 9772177497006. Idiom: Portuguese.
Gramado, RS, Brazil, 2010.
example, in Uberlândia. Based on such initial data sensing, [9] M. Houda, M. Khemaja, K. Oliveira, and M. Abed, “A public trans-
major details from the public transportation system can be portation ontology to support user travel planning.” in RCIS. IEEE,
captured, conducting the first adjustments in the timetables and 2010, pp. 127–136.
[10] M. KOHANA and S. OKAMOTO, “A server selection method for
definition about the required number of buses (frequency) of web-based multiserver systems,” in Advanced Information Networking
the lines. From such moment, the new data collected will help and Applications (AINA), 2015 IEEE 29th International Conference on.
in the stabilization of the system and enrich the information IEEE, 2015, pp. 112–117.
[11] M. Doering, T. Pögel, W.-B. Pöttner, and L. Wolf, “A new mobility trace
provided to the users inside the buses, stop points and from for realistic large-scale simulation of bus-based dtns,” in Proceedings of
the Internet. the 5th ACM workshop on Challenged networks. ACM, 2010, pp.
The prototype also shows that the development of this 71–74.
proposal on top of standard technologies, available on different
low-cost hardware is possible. Thus, the information gathering,
based on the proposed ontology, can significantly help to
improve the overall quality of experience of users of public
transportation systems with reduced technological costs.
As future work, the ontology will be extended and formal-
ized for a wider context. We are also working in large scale
experiments, in which entire transportation networks can be
evaluated with the help of simulation tools [11]. If possible,
we would like to implement our prototype in a certain number
of real bus lines, in order to improve the prototype.
Also, as the amount of data collected rises, and the type of
data as well, new correlations and information about them may
be defined, which will open to new and diverse information
services offered to the population.
ACKNOWLEDGEMENTS
The authors would like to thank CAPES, CNPq and
FAPEMIG for supporting this work.
R EFERENCES
[1] C. Carvalho, “Elasticidade-renda dos gastos das famı́lias metropolitanas
brasileiras com transporte urbano e aquisição de veı́culos privados,”
Instituto de Pesquisa Econômica Aplicada - IPEA, Discussion Papers
1947, 2014. [Online]. Available: http://EconPapers.repec.org/RePEc:ipe:
ipetds:1947
[2] C. Carvalho and R. Pereira, “Gastos das famı́lias brasileiras com
transporte urbano público e privado no brasil: Uma análise da
pof 2003 e 2009,” Instituto de Pesquisa Econômica Aplicada -
IPEA, Discussion Papers 1803, 2012. [Online]. Available: http:
//EconPapers.repec.org/RePEc:ipe:ipetds:1803
[3] IPEA, “A mobilidade urbana no brasil, infraestrutura social e urbana no
brasil subsı́dios para uma agenda de pesquisa e formulação de polı́ticas
públicas,” Instituto de Pesquisa Econômica Aplicada - IPEA, Bulletin 94,
2011.

878