sensors
Article
Evaluation of Google Glass Technical Limitations on
Their Integration in Medical Systems
Antonio Martinez-Millana 1,2, *,† , Jose-Luis Bayo-Monton 1,† , Aroa Lizondo 1,† ,
Carlos Fernandez-Llatas 1,2,† and Vicente Traver 1,2,†
1
2
*
†
Instituto Universitario de Investigación de Aplicaciones de las Tecnologías de la Información y de
las Comunicaciones Avanzadas (ITACA), Universitat Politecnica de Valencia, Camino de Vera S/N,
Valencia 46022, Spain;-(J.-L.B.-M.);-(A.L.);-(C.F.-L.);-(V.T.)
Unidad Mixta de Reingeniería de Procesos Sociosanitarios (eRPSS), Instituto de Investigación Sanitaria del
Hospital Universitario y Politecnico La Fe, Bulevar Sur S/N, Valencia 46026, Spain
Correspondence:- Tel.: -
These authors contributed equally to this work.
Academic Editors: Octavian Adrian Postolache, Alex Casson and Subhas Chandra Mukhopadhyay
Received: 14 October 2016; Accepted: 13 December 2016; Published: 15 December 2016
Abstract: Google Glass is a wearable sensor presented to facilitate access to information and assist
while performing complex tasks. Despite the withdrawal of Google in supporting the product, today
there are multiple applications and much research analyzing the potential impact of this technology
in different fields of medicine. Google Glass satisfies the need of managing and having rapid access
to real-time information in different health care scenarios. Among the most common applications
are access to electronic medical records, display monitorizations, decision support and remote
consultation in specialties ranging from ophthalmology to surgery and teaching. The device enables
a user-friendly hands-free interaction with remote health information systems and broadcasting
medical interventions and consultations from a first-person point of view. However, scientific
evidence highlights important technical limitations in its use and integration, such as failure in
connectivity, poor reception of images and automatic restart of the device. This article presents
a technical study on the aforementioned limitations (specifically on the latency, reliability and
performance) on two standard communication schemes in order to categorize and identify the
sources of the problems. Results have allowed us to obtain a basis to define requirements for medical
applications to prevent network, computational and processing failures associated with the use of
Google Glass.
Keywords: Google Glass; throughput; integration; surgery; imaging; medical systems
1. Introduction
Nowadays, the population pyramid is inverted [1]. The population is increasingly aging and
health care systems are adapting their services to provide coverage for the wide range of needs
generated by this change [2]. One of the most important improvements is the use of information and
communications technology to support medical interventions and processes, a discipline named as
eHealth [3]. In this context, Google Glass (Google Inc., Mountain View, CA, USA) is a device that can
be very useful in medical applications, as it allows the presentation of information in a simple and
ergonomic way, in real-time to the user.
Google Glass was developed in Google X [4], a facility devoted to the development of
high-technology innovative products. First prototypes dated from 2011 and were very heavy,
but during the following years, size and weight were dramatically reduced. The device was released to
Sensors 2016, 16, 2142; doi:10.3390/s-
www.mdpi.com/journal/sensors
Sensors 2016, 16, 2142
2 of 12
the market in 2013 for beta-testers, and one year later in 2014, opened to general public [5]. Since then,
Google Glass began to receive criticism and even legal actions, mainly due to the concern of privacy
issues. Because of this controversy, Google Inc. announced, in January 2015, that it would stop its
production, but made a compromise to continue with product development to create an improved
version [6].
Despite the temporal product retirement, the concept driven by Google Glass has created a
significant impact. On the one hand, it has ignited the development of head-mounted displays such
as Microsoft Hololens and Oculus Rift, and other several solutions available in market and pre-market
stages. On the other hand, it has made several inroads on their application to general medicine
and specific domains [7], boosting the exploitation of wearable devices in the public health care
sector. A recent review [8] summarizes the key enabling technologies that will drive next generation
clinical applications. The review concludes that the field of wearable technology is one of the greatest
opportunities, whereas there are major concerns about the integration of several, heterogeneous types
of information and communication technologies.
Nevertheless, even in the product’s short life-time, the literature has gathered many experiences of
development, tests and assessment of medical solutions using Google Glass in many fields of medicine
and public health. Among the most widespread applications are surgery [9–11], ophthalmology [12,13],
cardiology [14], emergency [15] and bedside [16]. Most studies show promising results but list a
number of shortcomings when using Google Glass. Major limitations highlighted by authors are the
short battery life in stand-alone use, which is less than 60 min [17]. Likewise, studies of evaluation
and comparison with similar technologies (e.g., Go Pro R Hero) reveal limitations in the quality of the
images and the inability to indicate points of interest in the images with such a low resolution, a fact
that affects the image interpretation. Other concerns spotted in the studies are related to the security
and privacy of data (images, texts and sounds) that Google Glass records and stores [18].
Broadcasting medical interventions currently stands as the most important medical application
of Google Glass. In 2014, a colo-rectal consultant streamed a liver resection while he was addressing
questions live from an audience of more than 10,000 surgery students from more than 100 countries [19].
This shows the potential to improve patient care as relevant experts can be consulted in real-time
without geographical boundaries, but it is seriously affected by hardware and network limitations,
because, most of the cited studies afflict technical failures in the transmission of images, communication
errors (connection lost) and sudden restarts while using the device.
Such limitations are in the scope of several research fields [20,21] on the development of new
communication paradigms and computational architectures to optimize key performance indicators
such as the latency, the computational overload and data quality.
In the scope of our research, limitations on the medical use of Google Glass originate from
technical aspects, but the extent to which these technical aspects are preventable is still unknown.
In this study, we present an analysis of the technical limitations of Google Glass. A test bench
using two well-established communication schemes has been used to identify and detect the optimal
characteristics that allow a proper use of Google Glass in medical systems. A major finding reveals
that even though there are not significant differences in the type of protocol with respect to the device
latency, some of the exceptions that cause the automatic reset could be avoided by properly managing
images’ delivery according to their size.
The rest of the manuscript is organized in four main sections: Material and Methods, in which we
describe the device and the experiment’s set-up, the key metrics for the performance, and the statistical
methods of the analysis; Results, in which we present the major findings achieved for each key metric;
Discussion, in which we interpret the obtained results and contextualize them in the current trends of
medical systems development; and Conclusion, in which we highlight the main end-point of our work.
Sensors 2016, 16, 2142
3 of 12
2. Materials and Methods
Google Glass is a wearable device based on a particular Android operating system. Google Glass
display is equipped with a prism and a LED beamer which projects an image on the top right of the
right eye using polarizing filters and semi-reflective mirrors (Figure 1). This configuration provides the
user with the feeling that the image floats inside a transparent prism, without limiting the natural field
of vision. This piece is adjustable to the shape of the user’s face and the distance to the eye. The device
also includes a transducer which passes down vibrations to the skull near the ear to transmit sound,
instead of using the auditory channel. The device has incorporated a lateral touch-pad, near to the
reflection prism, to interact with the device. Moreover, it has a digital 2528 × 1856 pixels resolution
camera which takes pictures in jpg format and records 720 p video in mp4 format. It is equipped with
an ARMv7 Dual 1.2 Ghz Texas Instrument Processor and the available storage in the device is 12 GB.
Autonomy is managed with a small battery of 570 mAh lithium-polymer, with an operating capacity
of less than an hour under intensive use and three to five hours under normal use.
Figure 1. Physical schematic of Google Glass. Source: Google Glass Inc.
Google Glass features the “Jelly-Bean” Operating System which executes Android Glass Ware
applications which operate very similar to “Google Now” terminal services.
The main interface of Google Glass is shown in the manner of an horizontal or vertical menu
(depending on the triggered user control). The right-side external touch-pad allows one to navigate
across the items in the Operative System and applications home page. The device also provides a small
set of features, such as the “head wake” that allows one to wake up the device with a nod or “wink”,
which also allows one to take photos with a simple wink of the eye [22]. The last type of applications in
Google Glass are the “Immersions”, which are out of the time-line interface and provide background
control of the user experience. Immersions are more like traditional Android applications in their
use of activities, layouts and widgets. The Glass Development Kit (GDK) enables the integration of
all these features to maximize the use of hardware resources in the device, such as voice control or
views on a 640 × 360 pixels interface. Regarding connectivity, Google Glass has three interfaces: Wi-Fi,
Bluetooth and micro-USB. For the preparation of this study, the communication channel Wi-Fi will be
used, as it has been the used one in medicine according to the literature study.
To evaluate the technical performance of Google Glass, we have implemented and compared two
traditional communication schemes: one based on a TCP [23] bidirectional connection and another
consisting of a web service communication schema, based on REST connectors [24].
Retrofit [25], an Application Programming Interface (API), has been use to build the REST
communication scheme. This schema is based on an HTTP client for Android and java, in which the
POST method is used with the @BODY tag to mark the input parameters of the evaluated method.
REST packets are based on the JSON messaging system, and to preserve compatibility with Glass Ware
applications, we have used GSON , a Google library to manage JSON messages. For the other schema,
default TCP APIs from Java framework were used to implement the TCP communication schema.
In this last case, Google Glasses were provided with a private Internet Protocol (IP) direction in the
network configuration.
Sensors 2016, 16, 2142
4 of 12
REST is a protocol implemented on HTTP (OSI Layer 7) and TCP transport protocol (OSI Layer 4).
On the one hand, REST messages are built with a higher load and thus, TCP should provide better
throughput indicators, but on the other hand, as an application layer protocol, REST enables an optimal
deployment of applications in Google Glass.
Both schemes have been implemented using the Choreographer [26], a semantic engine capable
of connecting registered services and functions (Figure 2). Using this approach, two main services
for each communication schema have been defined. The Choreographer dispatches messages among
the modules using a specific eXtensible Markup Language (XML) message protocol called eXtensible
MeSsaGe (XMSG) [27]. XMSG is based on the Foundation for Intelligent Physical Agents (FIPA)
recommendations [28] and Simple Object Access Protocol (SOAP) [29] headers to route and characterize
messages. The XMSG protocol allows broad-/multi-cast as well as Peer to Peer (P2P) message calls
using custom symbols in the destination address. Minimum transfer unit or Data Transfer Object
(DTO) used was a simple object, consisting of descriptive variables and fields for message content.
Performance and throughput tests were performed with a .NET framework 4.5 server and a standard
802.11 g local wireless network (WLAN) conducted with a D-LINK GO-R-Tn150 router.
Figure 2. Communication schema used to perform the experiments by the implementation of TCP
scheme (bottom) please define and REST (top) protocols.
The proposed comparison is based on a 10-set of systematic bench-tests using the two
communication schemes with groups of 10, 100, and 1000 DTOs sent gradually, containing
alpha-numeric messages, randomly generated with different sizes (0 values, 1 value, 10 and 100 values)
to monitor the following Key Performance Indicators (KPI) :
•
•
•
Communication Delay (Latency —milliseconds)
Communication Success (Reliability —% success)
Computational Load in Google Glass as regards to Memory and Central Processing Unit (CPU)
use (Performance —% and Megabytes (MB)
Likewise, to assess the picture exchange and processing metrics, we have used the Early Lung
Cancer Action Program (ECLAP) medical images database from Cornell University, which provides
medical images in .jpg format of several sizes. Due to the skewed distribution of the latency parameters,
a Wilcoxon signed-rank test at 95% C.I. will be used to assess the independence of intra and inter
schema differences. Significance will be assumed for p < 0.05. Statistical and graphical analysis were
done using Matlab 2016R version using Academic License.
3. Results
Overall results of the tests are satisfactory, as we have detected saturation points and therefore
connection losses. Also, we have been able to quantify delay (latency) characteristics, reliability
Sensors 2016, 16, 2142
5 of 12
and performance of the device, which depends on the number of messages and the size of
exchanged images.
For each test-bench (defined as a 10-set exchange of messages), the Choreographer has been used
to send DTOs and track KPIs on REST and TCP schemes. For each iteration on the number of DTOs
and the size of messages’ content, a bi-dimensional matrix was recorded with an experiment identifier.
A Matlab script was implemented to automatically parse matrix and make statistical comparisons
and charts.
Convenience of the GSON library for converting data type without additional configurations is
confirmed. In the case of our experiments, we developed a custom serialize and deserialize method to
convert complex objects (images) in alphanumeric sequences for encapsulating them in JSON messages.
Furthermore, the efficiency of library Retrofit stands as a key factor to achieve a proper functioning
of Google Glass, even when network problems occur, because it allows one to configure alternative
addresses to make requests when others fail.
3.1. Communication Delay
Latency values for REST and TCP schemes are drawn in Figure 3. An increase in the number and
size of messages is correlated to an increase in the reception time, whereas an increase in the size of
the message content is correlated to a decrease. TCP schema is significantly faster than REST protocol
(p < 0.01), as well as the distribution of the results for each bench and size (p < 0.05).
10 4
REST
3
10 DTOs
100 DTOs
1000 DTOs
2.5
Latency (ms)
-
-0.5
EMPTY
1
10
100
Size of the messages content
10 4
TCP
3
10 DTOs
100 DTOs
1000 DTOs
2.5
Latency (ms)
-
-0.5
EMPTY
1
10
100
Size of the messages content
Figure 3. Latency in milliseconds for the REST and TCP scheme. Wilcoxon signed-rank test for
a C.I. = 95% confirms statistical significant difference for each intra (p < 0.05) and inter scheme
(p < 0.01) results.
Sensors 2016, 16, 2142
6 of 12
3.2. Communication Success
Regarding reliability, REST schema reaches 96.62% ± 2.35% , whereas TCP reaches
96.90% ± 1.71%. A p value > 0.05 (p = 0.882) prevents us from confirming which schema is the
most reliable (Table 1).
Table 1. Percentage of success on communications (Reliability) for the REST scheme experiments for
each bulck of Data Transfer Objects (DTOs).
REST
Message Size
TCP
10 DTOs
100 DTOs
1000 DTOs
10 DTOs
100 DTOs
1000 DTOs
-
-
-
-
-
-
-
3.3. Computational Load
Figure 4 shows a comparison of the computational load in the Google Glass for the two
communication schemes. There are significant differences for the CPU (p < 0.01) and Memory (p < 0.05)
use for each communication scheme. As expected, the TCP scheme needs less resources to process
DTOs, as messages are loaded with less data. Nevertheless, the exponential shape of the results, as the
amount of DTOs increases, confirms our hypothesis on the OutOfMemory Exception.
Comparative Performance of Google Glass
REST
15
10 DTOs
100 DTOs
1000 DTOs
14
TCP
14
10 DTOs
100 DTOs
1000 DTOs
13
13
12
Allocated Memory (MB)
Allocated Memory (MB)
12
11
10
9
11
10
9
8
8
7
7
6
6
0
10
20
30
40
CPU (%)
(a)
50
60
70
80
0
10
20
30
40
50
60
70
80
CPU (%)
(b)
Figure 4. Comparison on the performance of Google Glass (CPU and Memory) for the two
communication schemes. The exponential slope of the cross-points confirms our hypothesis in the
Memory management and OutOfMemory Exception, eventhough the (b) figure shows a better CPU
management than (a). (a) Results on the performance of REST messages management; (b) Results on
the performance of TCP messages management.
3.4. Image Processing
A total set of 14 medical images with sizes ranging from 100 KB to more than 2 MB were sent
using TCP communication schema. Performance metrics such as CPU and Memory usage were
Sensors 2016, 16, 2142
7 of 12
tracked, as well as the delay on processing the image upon arrival. From the 64 delivered images,
46 were shown properly and the remaining 20 collapsed the device memory causing an automatic
reset. To present the results, we have classified the image in three categories: Light (less than 1 MB
size), Medium (between 1 and 2 MB size) and Heavy (more than 2 MB size).
Figure 5 shows a scatter plot of the successful and unsuccessful delivered images and the needs of
CPU and Memory. Even though there is not a clear pattern on the resources consumption related to the
type of image, we can see that Light and Medium images can work in stressful conditions (40% CPU
and more than 50 MB of Memory). At the same time, we can see that the image size is not linked to the
device collapse; in the top-right corner we can see the images that caused the exception. When the
device CPU use is over a threshold value (around 39.78% ± 0.35% in our experiments), the Garbage
collector cannot manage the use of resources and the device performs an automatic reset.
With respect to the time that Google Glass needs to process the images (Delay), in Figure 6 we
have noted a linear relationship among the image size and the delay. According to our experiments,
as the image is serialized, prior to being sent in the TCP schema, the device performs a re-buffering
operation to parse and deserialize the object, and then transform it into an image object to be projected
in the prism. Approximating the distribution with a linear function in (1), (R2 = 95.1% ), in which the
image size is in MB and the time delay is in milliseconds.
delay = 3786 × size + 2975
Performance of Google Glass for processing Images
80
70
(1)
Light
Medium
Heavy
60
Allocated Memory (MB)
OutOfMemory Exception
50
40
30
20
10
0
20
30
40
50
60
70
80
90
100
CPU (%)
Figure 5. Performance (CPU and Memory use) of Google Glass for processing images of different sizes.
The area of the circle is in proportion to the image size.
Sensors 2016, 16, 2142
8 of 12
104 Time delay of Google Glass for processing Images
3
Light
Medium
Heavy
LR
Processing Time (ms)
2.5
2
1.5
1
0.5
0
0
0.5
1
1.5
2
2.5
3
Image size (MB)
Figure 6. Relationship between image size and processing time of Google Glasses to show the image
in the prism. Failed tests are marked with a 0 delay (overlapped with x axis). Linear regression (LR)
goodness to fit has a R2 = 95.1%.
4. Discussion
In this manuscript, we analyze and quantify the most widespread technical limitations of Google
Glass in public health applications, as regards to previous published studies. The study has evaluated
objective metrics such as latency, reliability and computational burden in sending several different
data packets and different sizes of images.
We confirm that connection loss is a major issue, and results enable us to assume that the actual
failure experienced in the literature happens to be an OutOfMemory error, since the device memory
is very limited and the application closes automatically, preventing alert messages to the user before
returning to the main menu. Moreover, the analysis on communication prevents us from confirming
which is the suitable scheme to grant an acceptable level of success, nonetheless, results indicate that
big size messages with multiple DTOs are more likely to experiment unsuccessful transmissions, as
they are exposed to network fluctuations.
APIs and libraries used for communicating with Google Glass, GSON and Retrofit, have proven
to be really simple and versatile when it comes to making an application to communicate with Google
Glass. GSON has allowed us to customize the serialization and deserialization of data objects. Results
show that Google Glass connection to the server is possible through two communication schemes:
TCP and REST technology.
As for the overheads, REST messages present a higher data load than TCP, and thus, the study
on the communication delay shows a significant lower latency for TCP. Nonetheless, REST messages
are application-driven packets that allow less dedication on the hardware and software resources in
Google Glass, to display the results to users (Figure 4). In critical applications outside the medical field,
such as a remote drone controller [30], researchers have found technical limitations on the image speed
Sensors 2016, 16, 2142
9 of 12
processing that could be improved by optimizing network configuration. Our findings would suggest
optimizing the information transfer protocol, by using REST messages to avoid critical data loss.
Nowadays, in the era of Internet of Things, REST protocols appear to be the golden choice to
develop communication systems. It is clear that any technology has its advantages and disadvantages,
but, according to our findings, we think that the type of application and restriction parameters
should define which communication scheme accomplishes the quality requirements of service and
failure tolerance.
Google Glass has been demonstrated to optimize its performance for large messages. In Figure 3,
the test for 100 DTOs with the biggest size presents significantly less latency than the rest of tests.
In our opinion, due to the size of the message, the device activates the garbage collector methods to
re-allocate memory as the computational load in the CPU decreases.
The TCP scheme offers a better performance in terms of CPU (p < 0.01) and Memory (p < 0.05)
use, but the results show an exponential slope in the use of these resources as the number of DTOs
increases. Therefore, even though we would recommend a TCP scheme, it is mandatory to manage the
garbage collection in the device’s memory before sending packets.
In these tests, focusing on the Google Glass behavior to send/receive messages with multiple
sizes and multiple DTOs, we have shown the limitations in the processing capacity of Google Glass.
The principal limitation is the amount of memory that applications can use. In addition, we have also
measured the delay of the connection between server and device sending empty messages. We should
mention that all tests have been conducted in a Wireless Local Area Network specifically devoted to
our experiments, and thus results in the tests are not affected by external network load. However,
we can conclude that the size of the data sent to the device is a crucial factor that needs to be monitored
to help medical applications developers to overcome the technical limitations of Google Glass.
As expected, image processing is a major issue that does not depend on the image size, at least for
the CPU and Memory management. Literature shortcomings are linked to a weak management of
local memory resources, as we cannot confirm that the size of the image is linked to an OutOfMemory
exception. Nevertheless, the time needed to process images has a linear relationship with the image
size, and so, we have obtained an Equation (1) that may help researchers to identify the minimum time
gap in-between the image delivery to avoid crashes.
Google Glass is a versatile and innovative wearable that can be used to improve, enhance or
even create new services and tools for medical applications and systems. Positive user acceptance
of the device has been evaluated and confirmed in several studies involving specialists, trainees and
clinicians [18,31,32]. Acceptability of the image quality is an issue that may not be improved until
the next device version is released, as the compromise between image resolution and Field of View
(FoV) blocking has an unknown balance point. Some authors [33,34] in the field of image processing,
have pointed out the problems regarding the visualization of tiny signals or the identification of ’Points
of Interest’, however they accept the way in which the images are displayed, without distractions
or FoV blocking. Nonetheless, in ophthalmology applications for patients with an impaired FoV or
visual handicaps, the recording camera is a good feature to provide sound stimuli to enable them to
carry on with autonomy in short displacements. However, at last, the performance of these medical
applications depends on how they use the hardware, software and network features of the device,
and how their limitations may affect the life cycle of sessions or communications.
Mobile and wearable technologies are progressively penetrating into specific health care
applications [8]. One of the most promising fields for the use of Google Glass and other head-mounted
displays is medical training [35], in which the device is used to record residents during practical lessons
and on-field training, providing new perspectives for the analysis and evaluation of their interpersonal
communication and manual skills without the feeling of being observed. Another successful field
is its use as real-time decision support systems on patient consultations and documentation [36],
by integrating electronic health records and advanced information regarding drugs/interventions
into the daily communication workflow. Google Glass enables the automatic recording of sounds
Sensors 2016, 16, 2142
10 of 12
and images at the same time as the user interacts with the lateral touch-pad and voice commands,
so physicians can double check procedures, revise check-lists, access patient data in real-time and run
remote decision support systems. Last but not least, surgery and explorations stand as the flagship
field for exploiting Google Glass and similar wearable devices, as it allows high quality first-person
point of view image broadcasting whilst the user simultaneously accesses further information and
interacts in real-time with other doctors and surgeons without the need to modify the FoV (which can
be the patient him/her-self or the surgery area).
Nevertheless, as we have analyzed in this article, Google Glass has critical shortcomings that if not
prevented may lead to a loss of functions in health care systems. There are a number of concerns related
to the overall use of software and hardware resources, in particular to the processing performance
of images and delay in the communications. For the interpretation of real-time continuous signal
(i.e., ECG) or remote teleconferences, in which the delay, reliability and processing time are critical
factors, Google Glass has boundaries that are likely to be managed by a proper software design and
implementation, and moreover, that we hope will be overcome in future releases.
One major issue that we have not tackled, common to other mobile technologies, is the battery life,
which under non-stop use does not last more than one hour, and should be taken into consideration
when planning Google Glass use in health care applications.
Security and privacy are issues also identified in the literature [18]. Apart from the management
of unexpected or unauthorized image and sound recordings, the way in which the information is
hashed and transmitted will be a key factor for the development and certification of secure medical
applications. According to our analysis, TCP provides better outcomes than REST (using HTTP),
since TCP is a transport layer which does not provide information/application layer functionality;
nevertheless, from a security perspective, the implementation of HTTPS will be mandatory, and thus
so will be the implementation of the REST scheme.
Therefore, Google Glass is not suitable to carry out complex and heavy applications, such as
large data analysis, image processing or multi-threading. Following a recent publication in the mobile
technology field [37], we recommend using Google Glass as a wearable device to track and show
information, and instead using dedicated servers to host the execution of complex and heavy tasks.
Time is gold in health care and Google Glass can help health professionals to have rapid access
and new paths to information, but as with every medical technology, it has to be reliable.
5. Conclusions
Latency, reliability and performance of Google Glass depend on the technical characteristics of the
software in the device and the communication schema. It is essential to know the type of traffic that a
clinical application within a medical system will support, and moreover, to know what are the system
requirements to ensure an efficient and effective use of the Google Glass device. TCP permits lower
latency levels than REST, and thus the CPU and Memory rates remain better for TCP. The management
of data as well as medical images should be optimized to prevent the application from crashing due to
memory exceptions.
Acknowledgments: Authors would like to acknowledge the Laboratory for the Analysis for Human Behavior
(www.sabien.upv.es/lach) and the Operative Program FEDER 2007/2013, for providing the necessary materials
to undertake the presented research. The work done by A.L. was funded by the Ministry of Economy and
Competitiveness: Promoting Youth Employment Program and Implementation of the (PEJ-2014-A-06813) Youth
Guarantee 2014. The subsidized activity is part of the National System of Youth Guarantee and are co-financed
under the Operational Program for Youth Employment, with financial resources from the Initiative Youth
Employment (IYE) and the European Social Fund (ESF) for the period-.
Author Contributions: A.M.-M. performed the experiments, analyzed the data and wrote the paper; J.-L.B.-M.
and A.L. conceived and performed the experiments; C.F.-L. and V.T. contributed with analysis tools, conclusions
and wrote the paper. All authors have contributed substantially to the presented work.
Conflicts of Interest: The authors declare no conflict of interest.
Sensors 2016, 16, 2142
11 of 12
Abbreviations
The following abbreviations are used in this manuscript:
CPU
DTO
JSON
GSON
FoV
KPI
OSI
REST
TCP
Central Processing Unit
Data Transfer Object
JavaScript Object Notation
Google library for JSON
Field of View
Key Performance Indicators
Open Systems Interconnection
Representational State Transfer
Transmission Control Protocol
References
1.
2.
3.
4.
-.
-.
19.
20.
United Nations, Department of Economic and Social Affairs, Population Division. World Population Prospects:
The 2015 Revision, Key Findings and Advance Tables; Working Paper No ESA/P/WP.241; United Nations,
Department of Economic and Social Affairs, Population Division: New York, NY, USA, 2015.
Abrahams, E.; Ginsburg, G.S.; Silver, M. The Personalized Medicine Coalition. Am. J. Pharmacogenom. 2005,
5, 345–355.
Eysenbach, G. What is e-health? J. Med. Internet Res. 2001, 3, e20.
Gertner, J. The Truth about Google X: An Exclusive Look Behind the Secretive Lab’s Closed Doors.
Available online: https://www.fastcompany.com/-/united-states-of-innovation/the-google-x-factor
(accessed on 14 December 2016).
Glauser, W. Doctors among early adopters of Google Glass. Can. Med. Assoc. J. 2013, 185, 1385.
Google Glass Developer Site. Google Glass at Work, 2016. Available online: https://developers.google.
com/glass/ (accessed on 14 December 2016).
Emergency providers see big potential for Google Glass. ED Manag. 2014, 26, 55–58.
Patel, S.; Park, H.; Bonato, P.; Chan, L.; Rodgers, M. A review of wearable sensors and systems with
application in rehabilitation. J. Neuroeng. Rehabil. 2012, 9, 21–37.
Davis, C.R.; Rosenfield, L.K. Looking at Plastic Surgery through Google Glass: Part 1. Systematic Review of
Google Glass Evidence and the First Plastic Surgical Procedures. Plast. Reconstr. Surg. 2015, 135, 918–928.
Iversen, M.D.; Kiami, S.; Singh, K.; Masiello, I.; von Heideken, J. Prospective, randomised controlled trial to
evaluate the effect of smart glasses on vestibular examination skills. BMJ Innov. 2016, 2, 99–105.
Liebert, C.A.; Zayed, M.A.; Aalami, O.; Tran, J.; Lau, J.N. Novel Use of Google Glass for Procedural Wireless
Vital Sign Monitoring. Surg. Innov. 2016, 23, 366–373.
Longley, C.; Whitaker, D. Google Glass Glare: Disability glare produced by a head-mounted visual display.
Ophthalmic Physiol. Opt. 2015, 36, 167–173.
Trese, M.G.J.; Khan, N.W.; Branham, K.; Conroy, E.B.; Moroi, S.E. Expansion of Severely Constricted Visual
Field Using Google Glass. Ophthalmic Surg. Lasers Imaging Retin. 2016, 47, 486–489.
Jeroudi, O.M.; Christakopoulos, G.; Christopoulos, G.; Kotsia, A.; Kypreos, M.A.; Rangan, B.V.; Banerjee, S.;
Brilakis, E.S. Accuracy of remote electrocardiogram interpretation with the use of Google Glass technology.
Am. J. Cardiol. 2015, 115, 374–377.
Cicero, M.X.; Walsh, B.; Solad, Y.; Whitfill, T.; Paesano, G.; Kim, K.; Baum, C.R.; Cone, D.C. Do you see what I
see? Insights from using google glass for disaster telemedicine triage. Prehospital Disaster Med. 2015, 30, 4–8.
Wu, T.S.; Dameff, C.J.; Tully, J.L. Ultrasound-guided central venous access using Google Glass. J. Emerg. Med.
2014, 47, 668–675.
Lewis, T.L.; Vohra, R.S. Smartphones make smarter surgeons. Br. J. Surg. 2014, 101, 296–297.
Albrecht, U.V.; von Jan, U.; Kuebler, J.; Zoeller, C.; Lacher, M.; Muensterer, O.J.; Ettinger, M.; Klintschar, M.;
Hagemeier, L. Google Glass for documentation of medical findings: Evaluation in forensic medicine. J. Med.
Internet Res. 2014, 16, e53.
Waxman, B.P. Medicine in small doses. ANZ J. Surg. 2012, 82, 768.
Kortuem, G.; Bauer, M.; Segall, Z. NETMAN: The design of a collaborative wearable computer system.
Mob. Netw. Appl. 1999, 4, 49–58.
Sensors 2016, 16, 2142
21.
-.
26.
27.
28.
29.
30.
31.
32.
33.
-.
12 of 12
Roumen, T.; Perrault, S.T.; Zhao, S. NotiRing: A comparative Study of Notification Channels for Wearable
Intercative Rings. In Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing
Systems (CHI ’15), Seoul, Korea, 18–23 April 2015.
Lv, Z.; Feng, L.; Li, H.; Feng, S. Hand-free motion interaction on Google Glass. In Proceedings of the Asia
2014 Mobile Graphics and Interactive Applications, Shenzhen, China, 3–6 December 2014.
Stevens, W.R. TCP/IP Illustrated, Vol. 1: The Protocols, 1st ed.; Addison-Wesley: Boston, MA, USA, 1993.
Zou, G.; Gan, Y.; Chen, Y.; Zhang, B.; Huang, R.; Xu, Y.; Xiang, Y. Towards automated choreography of Web
services using planning in large scale service repositories. Appl. Intell. 2014, 41, 383–404.
Hasibuan, A.; Mustadi, M.; Syamsuddin, I.E.Y.; Rosidi, I.M.A. Design and implementation of modular home
automation based on wireless network, REST API, and WebSocket. In Proceedings of the 2015 International
Symposium on Intelligent Signal Processing and Communication Systems (ISPACS), Nusa Dua, Indonesia,
9–12 November 2015.
Martinez-Millana, A.; Fernandez-Llatas, C.; Sacchi, L.; Segagni, D.; Guillen, S.; Bellazzi, R.; Traver, V.
From data to the decision: A software architecture to integrate predictive modelling in clinical settings.
In Proceedings of the 37th Annual International Conference of the IEEE Engineering in Medicine and Biology
Society (EMBC), Milano, Italy, 25–29 August 2015.
Fernández-Llatas, C.; Mocholí, J.B.; Moyano, A.; Meneu, T. Semantic Process Choreography for Distributed
Sensor Management. In Proceedings of the International Workshop on Semantic Sensor Web (SSW), Valencia,
Spain, 27–28 October 2010; pp. 32–37.
OBrien, P.D.; Nicol, R.C. FIPA Towards a Standard for Software Agents. BT Technol. J. 1998, 16, 51–59.
Gudgin, M.; Hadley, M.; Mendelsohn, N.; Moreau, J.J.; Nielsen, H.F. SOAP Version 1.2 Part 1: Messaging
Framework; W3C: Cambridge, MA, USA, 2003; Volume 3.
Teixeira, J.M.; Ferreira, R.; Santos, M.; Teichrieb, V. Teleoperation Using Google Glass and AR, Drone for
Structural Inspection. In Proceedings of the 2014 XVI Symposium on Virtual and Augmented Reality,
Salvador, Brazil, 12–15 May 2014.
Muensterer, O.J.; Lacher, M.; Zoeller, C.; Bronstein, M.; Kübler, J. Google Glass in pediatric surgery:
An exploratory study. Int. J. Surg. 2014, 12, 281–289.
Brusie, T.; Fijal, T.; Keller, A.; Lauff, C.; Barker, K.; Schwinck, J.; Calland, J.F.; Guerlain, S. Usability Evaluation
of Two Smart Glass Systems; IEEE: Piscataway, NJ, USA, 2015; pp. 336–341.
McNaney, R.; Vines, J.; Roggen, D.; Balaam, M.; Zhang, P.; Poliakov, I.; Olivier, P. Exploring the acceptability
of google glass as an everyday assistive device for people with parkinsons. In Proceedings of the
32nd annual ACM conference on Human factors in computing systems (CHI ’14), Toronto, ON, Canada,
26 April–1 May 2014.
Hwang, A.D.; Peli, E. An Augmented-Reality Edge Enhancement Application for Google Glass. Optom. Vis. Sci.
2014, 91,-.
Tully, J.; Dameff, C.; Kaib, S.; Moffitt, M. Recording Medical Students’ Encounters With Standardized
Patients Using Google Glass. Acad. Med. 2015, 90, 314–316.
Fox, B.; Felkey, B. Potential Uses of Google Glass in the Pharmacy. Hosp. Pharm. 2013, 48, 783–784.
Nguyen, V.; Gruteser, M. First Experiences with GOOGLE GLASS in Mobile Research. GetMob. Mob. Comput.
Commun. Rev. 2015, 18, 44–47.
c 2016 by the authors; licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC-BY) license (http://creativecommons.org/licenses/by/4.0/).