2015 5th International Conference on the Internet of Things (IoT)

Conversations with Connected Vehicles

Simon Mayer Josh Siegel

Department of Computer Science Field Intelligence Laboratory
ETH Zurich, Switzerland Massachusetts Institute of Technology, USA
Email: [email protected] Email: j [email protected]

Abstract—We present a system that allows drivers and fleet

managers to interact with their connected vehicles both by means The basic infrastructure that we build upon in this paper to
of direct control and indirect goal-setting. The ability to move make cars accessible over the Web is supplied by CloudThink,
data from vehicles to a remote server is established by the flexible a platform developed to make vehicle data and actuation
and secure open vehicle telematics platform “CloudThink.” Based capabilities usable for clients in near real time via an intuitive
on this platform, we present several prototypes of how people can REST API. The use of CloudThink integrating cars into the
be enabled to conveniently interact with connected vehicles: First, Web of Things opens up many interaction methods for smart
we demonstrate a system that allows users to select and interact things to the automotive domain: we can recognize cars and
with vehicles using object recognition methods and automatically interact with them directly via user interface devices such as
generated user interfaces on smartphones or personal wearable
devices. Second, we show how functional semantic metadata can smartphones or smartglasses, can visualize their interactions
be used to smooth the boundaries for interacting with vehicles with other smart things and remote applications, and can
in the physical and virtual worlds. Finally, we present a method semantically describe the data and services they provide to
for monitoring interactions between vehicles and remote services enable the automatic collaboration of vehicles with smart
which increases safety and security by enhancing driver oversight devices and remote Web services.
and control over the data that leaves and enters their vehicle.
In this paper, following a brief introduction of the Cloud-
A car whose telemetry data is projected into the “Cloud” Think platform, we discuss several applications that have
and made accessible for third parties via standard Web been developed on top of the platform to make it easier for
technologies represents an interesting example of a Web- users and third-party applications to interact with connected
enabled smart thing. With vehicles being among people’s most vehicles. Specifically, we present a combination of a visual
frequently interacted with objects and representing the location object recognition system with embedded model-based user
where they spend the most time outside home and the office, interface descriptions that enables drivers to directly interact
Web-enabling vehicles affords designers and developers a with their cars. We furthermore demonstrate the applicability
unique opportunity to improve quality of life. Usable vehicle of functional semantic service descriptions to automobiles –
data has the potential to conserve valuable natural resources, this system integrates cars with other smart devices and Web
reduce aggravation, and improve safety. Integrating and services, thus creating physical mashups that make use of data
connecting automobiles to the broader Web ecosystem paves and functionality provided by the connected vehicles. Finally,
the way to reducing transit cost and time through efficiency we show a system that we created to help users stay in control
and reliability improvements, while also unlocking richer of what data leaves their automobiles – and which commands
information and actuator access than is presently available. It enter them – by using an augmented-reality interface that
thus provides a unique lever to improve user experience, a visualizes interactions of clients with cars.
primary differentiator in today’s vehicle market: from failure
prognostics to comfort and convenience improvements, a well- I. THE CLOUDTHINK PLATFORM
connected car has the ability to change how people see and
interact with transportation systems at large. Improved In the context of a collaboration between ETH Zurich,
connectivity not only makes the vehicle user experience better, Massachusetts Institute of Technology (MIT), the Singapore
it also facilitates seamless integration of automobiles with University of Technology and Design (SUTD), the University
other transit systems. By lowering barriers to vehicular of North Texas, and the Masdar Institute of Science and
application development, a whole new ecosystem of Technology in the United Arab Emirates, we have developed a
automotive applications may be developed, and OEMs, vehicle-to-cloud communication platform called CloudThink
consumers, and infrastructure all stand to benefit from reduced [1]. The core of this system consists of a low-cost hardware
cost and heightened quality and reliability. The key to making platform (the CARduino) that connects to the on-board
vehicular connectivity a widespread success lies in simplifying diagnostics port of a car using the OBD-II interface 1 and a
data acquisition and manipulation, and creating a platform that secure back-end server that stores data uploaded from vehicles
is brand-agnostic. In essence, the challenge is creating a and makes it accessible to other applications via a REST API.
system capable of supporting the many modes of data
The main goal of CloudThink is to enable drivers to share
acquisition and actuation required by the various application
data from their vehicles for processing by a wide variety of
builders while balancing the need for high safety and security
third-party applications while emphasizing an open, secure,
for critical systems integrated in user’s vehicles. Such a system
then needs to be integrated with a means of enabling car 1
This is a standard interface that every car manufactured in the E.U. and
owners as well as fleet managers to conveniently interact with U.S. after the year 1996 must support. The CARduino supports only the
their vehicles, irrespective of the make or model. Controller Area Network variant of the OBD-II specification.

978-1-4673-8058-4/15/$31.00 ©2015 IEEE 38

 2015 5th International Conference on the Internet of Things (IoT)

CloudThink Infrastructure

Gateway Server
Clients
Storage

Data Server

Cellular Operator
Fig. 2. A virtual dashboard that displays data from different sensors of a
Web-enabled car. The current location of the vehicle is shown on a map or
alternately in the form of a Google StreetView image.
CARduino

Fig. 1. Overview of the CloudThink platform. The CARduino hardware is are controllable only through specific, walled-garden
deployed on the car and communicates with the CloudThink back end via a companion applications. The access of vehicle data through
GSM link. In the back end, the data server parses, filters and synchronizes the OEM-provided interfaces like OnStar’s API or Ford’s
data and stores it in a database. The gateway server provides a REST API for
clients to conveniently access the data from a variety of devices.
OpenXC is limited in breadth, capable of accessing
standardized parameters and generic, but non-standardized
pieces of information. Output modulation is limited to simple
actuators, such as locks or other controls that act only when
and interoperable interface to these data. CloudThink thereby the vehicle is stationary,
aims to create an “App Store” for cars that hosts applications e.g. for car sharing applications. A system similar in nature
which can access and process car telemetry, and in cases, to CloudThink is required to facilitate the best application
control vehicle actuator function. The platform is distinguished development opportunities, by providing the richest possible
from similar projects in the automotive domain in that it vehicle data and actuation possibilities.
remains agnostic of the concrete type and make of vehicle
and therefore enables data sharing across the boundaries of car The main components of the CloudThink system are the
manufacturers, improving data generation by unsiloing data CARduino hardware, the data server that stores data uploaded
storage and allowing for rapid, crowdsourced data collection. from individual cars in a local database, and the gateway
Use cases for the CloudThink system stretch from enhancing server that enables third parties to access the stored data in a
vehicle security (for instance, a “virtual leash” for tracking of uniform way via a REST API (see Figure 1 on the previous
stolen vehicles) to reducing the environmental impact of cars page). Within the joint project, MIT is leading the hardware
by helping drivers to find out how they can better economize development (see Section I-A), while ETH’s main
fuel. Drivers could also use such a system to improve safety responsibility is the implementation and maintenance of the
by adapting their driving style [2], and the platform could back-end infrastructure (see Section I-B). On top of the
help set economic incentives to do so by enabling pay-as- system, the consortium has also created applications that
you-drive (PAYD) or usage based insurance schemes [3], [4]. provide better access to data stored on the platform in the form
Potentially, drivers could also use CloudThink to monetize of “virtual dashboards” (see Figure 2) that could be used, for
their driving data, for instance by sharing usage statistics and instance, by fleet managers, and has used telemetry data from
telemetry with the manufacturer of their car – or drivers could CloudThink to create an application that gives drivers more
provide the same data to non-profit organizations to achieve insight into their own driving behavior, especially with respect
better transparency of how specific vehicles fare in realistic to clues as to how they could improve their own fuel economy.
situations, for instance with respect to their fuel consumption,
maintenance effort, or to provide data leading up to a vehicle A. CARduino Hardware
recall. Another highly interesting application domain is using
real driving data for the improvement of vehicle Our CARduino hardware2 (see Figure 3) is responsible for
characteristics, for instance determining the optimal battery transmitting information from the vehicle to the CloudThink
size for electric cars [5]. On a larger scale, real-time feedback back-end infrastructure, where this data is stored in a SQL-
from vehicles could help improve road quality – and safety – based database. All information is sent via GSM connections
by enabling road operators to quickly react to problems that and encoded in a custom message format that is tuned to
range from potholes to developing traffic jams [6], [7], without minimize the volume of the transmitted data, thereby helping
the need for direct user reporting. to keep communication cost low. Each message that is sent
to the back end consists of the recording timestamp, the type
The CloudThink platform differs from contemporary of the transmitted data, the data itself, and a checksum to
OEM- backed application development systems. Interfaces ensure accurate data capture. Messages are received by the
proposed by auto manufacturers are limited in scope, with CloudThink data server that parses and checks each message
focus on intra- vehicle applications of data, such as within before persisting the contained data.
infotainment systems running locally on a car’s head unit. In 2
The CARduino hardware is open-source. It is manufactured by CarKnow
cases where direct, remote control of vehicle functions is LLC., a company that has been incorporated by one of our partners in the
allowed, these functions CloudThink project.

39
 2015 5th International Conference on the Internet of Things (IoT)

(a)
Fig. 4. Example responses of the CloudThink API’s HTML interface to a
request for a minute of car telemetry (GPS coordinates, coolant temperature,
speed, and revolutions per minute).

responsible for calculating several metrics that are derived

from the raw data – such as the instantaneous fuel
consumption, and distance driven – and persisting these values
together with the other synchronized data points.
It is the responsibility of the CloudThink gateway server
to give client applications (which can be mobile applications,
third-party servers, or Web browsers) access to the stored,
synchronized data via a secure REST interface (SSL/TLS and
(b)
HTTP Basic authentication). All data is provided in the JSON
format for machine clients, and can be browsed and visualized
Fig. 3. (a) The CARduino hardware (ca. 9.3cm x 4.4cm x 1.5cm). One using the HTML interface of the gateway server (see Figure 4).
can recognize the SIM card and the SD card that is used for data buffering. The server provides a layer of abstraction on top of the OBD
The GPS and GSM antennas are attached to the bottom of the module. The PIDs that are used internally by our system and enables clients
“CarKnow” silkscreen refers to the name of the start-up hardware designer
and distributor. (b) The CARduino hardware shown in a prototype 3D-printed to request data about attributes such as “RPM,”
casing and with an OBD-II connector cable. New variants plug directly into “consumption,” and “speed” – information about which types
the diagnostic port. of data a specific user is allowed to access on a specific car can
also easily be loaded from the interface. Additionally, the
gateway server enables clients to send actuation commands to
The CARduino carries an on-board accelerometer and a vehicles.
GPS receiver, and can be configured to listen on a car’s
OBD-II interface for OBD messages that are tagged with Another responsibility of the gateway server is to enforce
specified OBD-II Parameter Identifiers (PIDs). This allows that only authorized users may access data stored in the
us to capture information about many internal processes CloudThink back end. To do this, it stores, for each registered
of a vehicle, for instance basic driving data (e.g., speed, user and application, the data fields that this user may access
runtime, etc.) and information related to motor management (e.g., GPS location, acceleration, etc.) as well as, for each
(e.g., motor revolutions per minute, mass airflow, coolant vehicle, the users that are allowed to access data from this
temperature, etc.). In particular, we are able to gather all data vehicle and whether they also hold actuation rights. The
required for calculating an approximation of the instantaneous gateway server also keeps track of which user accesses which
fuel consumption of a car, which can be computed from the stored data item for billing purposes and to be able to inform
current vehicle speed and the mass airflow rate [8]. When the each driver about who requests what kind of information about
CARduino is unable to reach our back end, for instance due their cars. Finally, the gateway server features a public
to poor network connectivity, it uses an on-board memory unit interface that enables developers of client applications to test
for buffering and transmits the contents of that buffer at the their ideas and software prior to registering their
end of the trip. Finally, our hardware can also write to the car’s applications as data users on the CloudThink platform. The
OBD interface, thereby enabling it to actuate vehicle functions capabilities of the gateway server are detailed in its online
– we have successfully used it to lock and unlock cars, and to REST API description, along with example queries.
control wipers and power windows.
II. TALKING TO CONNECTED VEHICLES
B. Back-end Infrastructure Essentially, CloudThink aims to provide convenient access
to vehicle data for third-party applications – how exactly these
After being stored in the CloudThink database by the data process the provided data to create advanced services for
server, the vehicle information is processed by a drivers and third parties is left to the application developers.
synchronization script that aligns all received data points to We have developed several applications that make use of the
common 5-second time windows using linear interpolation data made available via the CloudThink platform, including a
and, as part of this process, copies it to a different database. virtual dashboard and a fuel economy assistant. The primary
This script is also topic of this paper, however, is how CloudThink can be used
40
 2015 5th International Conference on the Internet of Things (IoT)

to interact

41
 2015 5th International Conference on the Internet of Things (IoT)

with Web-connected cars: to this end, we propose the

automatic generation of user interfaces for vehicles and to
combine this technology with an object recognition system for
allowing users to select which car to interact with (see Section
II-A), the semantic annotation of services that are provided by
connected vehicles to enable the integration of their
functionality within physical mashups (see Section II-B), and
the visualization of interactions with Web-enabled cars using
an augmented-reality interface (see Section II-C).

(a)

A. Direct User Interaction with a Vehicle

First, we focus on the direct interaction of a user with

a connected car, meaning that we want to enable people to
monitor telemetry data produced by a vehicle and to control
actuators of a car using a user interface device, such as a
smartphone, tablet, smartwatch, or smartglasses. Accomplishing
this requires both: a means of selecting a vehicle to interact
with, and rendering a suitable user interface to interact with
it. We propose a system where a car is selected by means of (b)
a visual object recognition algorithm, i.e., making use of its
distinctive visual features, and where the interaction takes
place via automatically generated user interfaces.

To select a vehicle to interact with, we make use of current

visual object recognition methods that can be deployed on
hand- held or wearable devices such as smartphones,
smartwatches, or smartglasses (see Figure 5(a)). Our approach
combines a Bag of visual Words (BoW) with linear SVMs and
FAST/ORB feature detection/description and thus allows to
recognize objects without relying on fiducial markers, meaning
that our classification algorithm can be trained using only (c)
snapshots of the cars to interact with (see [9] and [10] for more
information about the object recognition subsystem).

For automatically generating an interface that allows users

to control the actuators of a vehicle, and monitor sensor values,
we incorporate a model-based user interface generation system
that relies on descriptions of the high-level semantics of
interactions with Web-enabled devices (see [11] for more
information). This system can be applied in the context of
generating user interfaces for the sensors and actuators of
Web-enabled cars without requiring any changes to the
CloudThink system other than the embedding of hyperlinks to
the relevant interaction descriptions.
(d)
Together, the described technologies yield a system that
permits users to directly interact with vehicles that are Fig. 5. (a) Our smart things interaction software recognizes a car using
its visual features. (b) Using the CloudThink API, a smartphone application
connected to the CloudThink platform and whose features are can display values from sensors of a recognized vehicle and (c) provide user
distinctive enough to enable them to be recognized as unique interfaces to control its actuators. (d) For cars, our visual object recognition
by our object recognition algorithm. As an example, Figure software falls back to the few distinctive features of a vehicle, for instance
5(b) demonstrates the interaction with the mileage “sensor” of the characteristics of its rims, stickers, and the number plate. Unfortunately,
many of the other features are located “inside” the car, and not useful for
a connected vehicle, while Figure 5(c) enables users to control differentiation in the most common use modalities.
a car’s door locks: the embedded user interface descriptions
allow rendering interfaces for multiple interaction modalities,
including haptic, speech, and graphical. Especially the application of our object recognition system

42
 2015 5th International Conference on the Internet of Things (IoT)

1
2
@prefix
@prefix
:<ex#>.
ex:<http://example.org/#>.
to obtain the GPS latitude of the current location of a vehicle
3 @prefix http:<http://www.w3.org/2011/http#>. given its VIN: using Notation3, a superset of RDF, it specifies
4 @prefix dbpedia:<http://dbpedia.org/resource/>. that, given a specific VIN (line 7 in Listing 1), the car’s GPS
5
6 {
latitude can be obtained (line 15) by sending an HTTP GET
7 ?car a dbpedia:Car; ex:hasVin ?vin. request to the specified URL (lines 11-13) – more specifically,
8 } that this latitude value is conveyed in plain text within the
=>
9
10 {
body of the HTTP response. Note that the correct car’s URI is
11 _:request http:methodName "GET"; selected at runtime by substituting the ?vin parameter with
12 http:requestURI ("https://api.cloud-think.com/things the supplied VIN (line 12).
/" ?vin "/?parameters=latitude");
http:resp [ http:body ?gpslat ].
13
14
The CloudThink API contains a similar description for
15 ?gpslat a dbpedia:Latitude; ex:derivedFrom ?car. each parameter that can be accessed about its connected cars
16 }. (e.g., their velocity, coolant temperature, and engine
Listing 1. Part of the RESTdesc description of the CloudThink API that revolutions per minute). These descriptions can be used by
describes how the current GPS latitude of a car can be obtained given its VIN,
using an HTTP request to the CloudThink server. The server provides similar
semantic reasoners to integrate functionality across
descriptions for other information about the cars it has data about. heterogeneous Web-enabled devices and Web services – to
demonstrate that our system is capable of creating composite
services on top of data produced by vehicles and published via
CloudThink, we used its semantic descriptions together with
within the context of recognizing vehicles gives rise to several those of a service able to display arbitrary images on a display,
challenges, predominantly due to the visual similarity of and semantically annotated two mapping applications (Google
distinct vehicles: being based on visual object recognition Maps and OpenStreetMaps). Given this setup, users can
technologies, our systems cannot differentiate between formulate a semantic goal that expresses their desire to obtain
different cars that look alike, with the exception of cases where an image object that is also a map and is derived from the
unique features of the car are visible in the camera frame (and VIN of a specific car, and that a screen that is situated at
related training images). While our approach is thus able to the current location of the user should be displaying this
find and match visual features of vehicles, these are often image – this leads a semantic reasoner to propose that it
located on the rims or the number plate of a vehicle, on could display the current location of a car on a nearby screen,
custom stickers, inside the car, or on its reflective surfaces by mashing up the CloudThink back end with either Google
(see Figure 5(d)), which makes the robustness of our system Maps or OpenStreetMaps and the screen API (see Figure 7).
heavily dependent on the current lighting conditions. Our reasoning infrastructure, which is described in greater
Furthermore, especially in the case of “plain vanilla” cars detail in [12], then sends the appropriate HTTP requests to the
without any distinct features, our software is not able to client which can execute them and thereby achieve the desired
differentiate between cars of the same make, type, and color. user goal. Because this service mashup is not hard-coded but
Similar to humans, who often arbitrate between different cars rather derived on demand from the currently available semantic
that look alike by remembering their vehicle’s parking descriptions, the mashup seamlessly switches to using
location, we propose to partially overcome this challenge by alternatives when services become unavailable, e.g. due to
using the GPS location of a car (which may be obtained from network outages – in this specific case, when we blocked
the CloudThink API) in conjunction with the location of the access to one of the two mapping services, the mashup
user interface device as an additional context parameter to seamlessly switched to using the other, thus demonstrating the
uniquely identify a vehicle. However, while this technique can flexibility of our approach of using functional semantic
indeed help to achieve stable selection results, it introduces metadata for dynamic service composition.
another challenge: the (remote or local) application that helps
the user interface device arbitrate between different cars
requires access to the locations of cars that are registered to the C. Monitoring Car Interactions
CloudThink platform or, as a minimum, an interface to send We believe that keeping users informed about what their
geographically bounded queries for a car (i.e., “Is car C connected smart things are doing in an increasingly connected
currently located within 100 meters of the GPS coordinates Web of Things world – and why they are – will become
(Lat,Lon)”). Other types of context information might be increasingly important as many of our once isolated devices
used as well for this purpose, for instance ambient beacons start interacting with each other and with remote services [13],
(e.g., Google PhysicalWeb3), to ensure the minimum viable especially if distributed services are flexibly or even automati-
amount of data are shared with unlinked parties. cally combined. Indeed, Web-enabled cars and platforms such
as CloudThink represent an interesting domain where drivers
B. Functional Semantic Metadata for Smart Vehicles would want to monitor which services access their vehicles:
Apart from the direct interaction with connected automo- the ability to supervise and control interactions is relevant to
biles, we have used functional semantic metadata in the form protect drivers from attacks on their privacy such as location
described in [12] to capture the functionality of the profiling, undesired actuator control, or the misuse of private
CloudThink API with respect to providing access to vehicle data by authorities [14].
telemetry data of individual cars, where each car is uniquely To support users to stay in control of their connected cars,
identified using its Vehicle Identification Number (VIN). As we integrated a piece of software that logs HTTP requests
an example, Listing 1 shows the semantic description of the and responses with the CloudThink back end and makes
API that enables clients
the collected data accessible to users in real time, using an
43
 2015 5th International Conference on the Internet of Things (IoT)

3
https://google.github.io/physical-web/ augmented reality interface on their handheld devices [13].

44
 2015 5th International Conference on the Internet of Things (IoT)

(a) (b)

Fig. 6. Our application visualizes interactions with a Web-enabled automobile that are brokered by the CloudThink platform using a visual object recognition
algorithm and an augmented reality overlay on a handheld device. (a) Interactions of a client with a vehicle (and other endpoints). (b) Interaction of a handheld
device with a vehicle.

III. SUMMARY
The CloudThink platform, a joint effort of ETH, MIT, and
several additional international partner institutions, has been
created to make automobiles “first-class citizens” of the Web
GET and enable third-party applications to easily access and
GET process vehicle data while providing advanced services to
drivers, fleet managers, and other players in the transportation
PUT industry. We and others have implemented several such
applications on top of this platform, in particular in an effort to
support users and applications when interacting with
connected vehicles: using our systems, it is possible for users
to directly interact with sensors and actuators of connected
automobiles, monitor the communication of vehicles and
Fig. 7. By publishing semantic metadata that describes its interfaces,
functionality of the CloudThink API (i.e., access to sensor values and actuators clients in real time, and to seamlessly use functionality that is
of connected vehicles) can be flexibly integrated with other local and remote provided by cars within physical mashups.
Web services. In this example, a user instructs an interface device (in this case,
a smartphone) to display the location of his car on a map that is shown an a The future developments for the CloudThink project
nearby computer screen. A reasoner then finds the necessary HTTP requests include expanding the API to return interaction monitoring
to reach that goal and executes them. data for all available vehicles. Additionally, we plan to
implement the ability for third-party application builders to
run their own scripts and modify firmware behavior on the
CARduino within safe and controlled boundaries, using an
Using Java Agents which can modify the bytecode of Java embedded virtual machine of sorts to limit the risk of
classes and class transformers that can infuse any Web server malicious code execution and to protect sensitive vehicle
based on the Grizzly NIO framework4 with an HTTP request networks.
logger, the integration of the logging functionality with the
CloudThink gateway server proved straightforward, and
merely required a restart of the server with attached Acknowledgements. This work was supported by the
transformers. The combined system allows users to monitor Swiss National Science Foundation under grant number
interactions of clients with their vehicles using the Web 341627 and the SUTD-MIT International Design Center. The
interface of our visualization tool as well as displaying these authors thank Yassin N. Hassan and Ga´bor So¨ro¨s for their
interactions as a live overlay on handheld, or ultimately help with the object recognition and interactions visualization
wearable, devices (see Figure 6). For the live overlay view, we software.
again use our object recognition software to identify the
vehicle whose information should be displayed: the arcs REFERENCES
between endpoints represent HTTP connections and the dots [1] E. Wilhelm, J. Siegel, S. Mayer, L. Sadamori, S. Dsouza, C.-K. Chau,
traveling on these arcs represent actual pseudo-real time HTTP and S. Sarma, “CloudThink: A Scalable Secure Platform for Mirroring
requests (for the visualization, we increase the request Transportation Systems in the Cloud,” Transport, vol. 30, no. 3, 2015
(in press).
latencies to one second per request, however).
[2] T. Lotan and T. Toledo, “An In-Vehicle Data Recorder for Evaluation
of Driving Behavior and Safety,” Transportation Research Record, vol.
1953, pp. 112–119, 2006.
[3] J. Paefgen, T. Staake, and F. Thiesse, “Resolving the Misalignment
4 between Consumer Privacy Concerns and Ubiquitous IS Design: The
https://grizzly.java.net/ Case of Usage-based Insurance,” in Proceedings of the 33rd

45
 2015 5th International Conference on the Internet of Things (IoT)

International Conference on Information Systems (ICIS), 2012.

46
 2015 5th International Conference on the Internet of Things (IoT)

[4] J. Zantema, D. H. van Amelsfort, M. C. J. Bliemer, and P. H. L. Bovy,

“Pay-as-You-Drive Strategies: Case Study of Safety and Accessibility 239–242.
Effects,” Transportation Research Record, vol. 2078, pp. 8–16, 2008. [10] S. Mayer and G. So¨ro¨s, “User Interface Beaming – Seamless
[5] R. C. Smith, S. Shahidinejad, D. Blair, and E. L. Bibeau, “Characteri- Interaction with Smart Things using Wearables,” in Proceedings of the
zation of urban commuter driving profiles to optimize battery size in Glass and Eyewear Computers Workshop, 2014.
light-duty plug-in electric vehicles,” Transportation Research Part D: [11] S. Mayer, A. Tschofen, A. K. Dey, and F. Mattern, “User Interfaces
Transport and Environment, vol. 16, no. 3, pp. 218–224, 2011. for Smart Things – A Generative Approach with Semantic Interaction
[6] S. Rogers, P. Langley, and C. Wilson, “Mining GPS Data to Augment Descriptions,” ACM Transactions on Computer-Human Interaction,
Road Models,” in Proceedings of the 5th ACM SIGKDD International vol. 21, no. 2, 2014.
Conference on Knowledge Discovery and Data Mining (KDD), ACM, [12] S. Mayer, N. Inhelder, R. Verborgh, R. V. de Walle, and F. Mattern,
1999, pp. 104–113. “Configuration of Smart Environments Made Simple – Combining
[7] W. Shi and Y. E. Liu, “Real-time urban traffic monitoring with global Visual Modeling with Semantic Metadata and Reasoning,” in
positioning system-equipped vehicles,” Intelligent Transport Systems, Proceedings of the 4th International Conference on the Internet of
vol. 4, no. 2, p. 113, 2010. Things (IoT), 2014.
[8] Rick Walter, “Fuel Economy Data,” 2014. [Online]. Available: [13] S. Mayer, Y. N. Hassan, and G. So¨ ro¨ s, “A Magic Lens for Revealing
http://www.cert.ucr.edu/events/pems2014/liveagenda/24walter.pdf Device Interactions in Smart Environments,” in Proceedings of the
SIGGRAPH Asia 2014 Symposium on Mobile Graphics and Interactive
[9] S. Mayer, M. Schalch, M. George, and G. So¨ro¨s, “Device Recognition Applications (MGIA), 2014.
for Intuitive Interaction with the Web of Things (Poster Abstract),” in
Adjunct Proceedings of the 2013 ACM International Joint Conference [14] F. Do¨tzer, “Privacy Issues in Vehicular Ad Hoc Networks,” in Privacy
on Pervasive and Ubiquitous Computing (UbiComp), ACM, 2013, pp. Enhancing Technologies, ser. Lecture Notes in Computer Science,
G. Danezis and D. Martin, Eds., Springer, 2006, vol. 3856, pp. 197–209.

47