- freely available
Sensors 2016, 16(9), 1538; doi:10.3390/s16091538
2. Fragmentation Problems
2.2. OSs and Software Platforms
- Apple Health . The Apple Health platform enables the collection of data from devices and apps of Apple, but it also supports some other companies, such as Nike, Fitbit and RunKeeper. It allows the user to view data and information related to physical activities and health. Two different kinds of profiles are recognized by Apple Health: general purpose and medical research. For medical research purposes, Apple Health provides more data analysis capabilities than the general purpose profile .
- Google Fit + Android Wear . Google Fit platform supports the collection of data from devices and apps under the Android Wear, Android and associated partners. Indeed, Google Fit supports more partners than any other platform , such as: Nike, Adidas, Xiaomi, HTC, Motorola, LG. Final users can view the information collected in the Google Fit web or in the app dashboard.
- S-Heath . This is the Samsung platform supporting all the wearables under its Tizen OS. It also works with devices delivered with the Android Wear, and devices and apps of some partners, such as Nike and Sleep as Android. Originally, it was proposed as a unifying platform for Samsung devices, but now it is open to other platforms. In any case, this platform has the smaller number of associated partners and market share, mainly located in the Asia area.
3. Data Collection
3.1. Involved Systems
- Data collection. Data is captured by the sensors available in wearable devices and smartphones.
- Data transfer. Data collected in wearables can be transferred to a computer or to a smartphone as an intermediate step towards its eventual transfer to a permanent data storage. This transfer can be produced through proprietary solutions or using third-party apps and programs. In theory, wearable data could be directly transferred from the wearable to the permanent data storage, without the need of any intermediate system, but nowadays, this is not possible.
- Permanent data storage. This function is related to the permanent storage of the data. Usually, this permanent storage is performed in proprietary servers, where third parties and final users can gain access to the data.
- Data analysis. This is related to the analytic processing of data to provide results of interest. Typically, this processing is performed in servers, both proprietary and third-party.
- Apple Health. Apple Health is made up of a warehouse and cloud services, an app, and a SDK (Health Kit). The Apple Health warehouse and cloud services maintain all the data collected from users and provide some analytic services. Nevertheless, Apple Health does not provide any REST API for third-party systems. The app is used in the iPhone or iPad to synchronize all the available data with the Apple Health server and to show such data to the user. The Health Kit SDK enables the development of apps for iWatch, iPhone and iPad providing access to data available in the Apple Health warehouse.
- Google Fit. It is the most complete solution, including a warehouse and cloud services and an app for Android systems. It provides a SDK for app developers, a SDK to gain access to Google Fit warehouse and a warehouse REST API for third-party systems. The Android app is needed to transfer the data from the wearable to the smartphone and then to the proprietary warehouse. This app involves some intelligence because it selects the best sensors available to collect data depending on the circumstances, whether they are in the wearable or in the smartphone. For example, if we are walking, it will use the pedometer to count the number of steps. Nevertheless, if we go by bike, as movement in the wrist will be limited, this app will measure the distance based on data from the smartphone GPS sensor. Eventually, measures of distance, steps, type and time of physical activity are calculated using the best data available.
- S-Health. Similarly, a smartphone app is included to synchronize the data with the Samsung server. It also provides a SDK to support the development of apps by third-party developers, gaining access to collected data in the proprietary warehouse (SDK-Warehouse). Nevertheless, this SDK does not enable the access to wearable data sensors directly. The S-Health platform does not include any REST API.
- Fitbit. It only provides a warehouse REST API for third-party systems. This platform synchronizes data from Fitbit quantification bands and enables third-party developers to get such data through the REST API. For some data, such as minute by minute heart rate, third-party developers need to own a specific permission.
- Microsoft Health. It provides a SDK for app developers and a REST API for third-party systems. Using these two facilities it is possible to gain access to data available in the Microsoft cloud that has been collected from Microsoft Band devices.
- Jawbone. It provides a SDK to support the development of apps by third-party developers gaining access to collected data in the proprietary warehouse (SDK-Warehouse) and a warehouse REST API for third-party systems. Similar to the previous cases, it also stores and provides data from the connected Jawbone devices.
3.2. Data Transfer
- Wearable data transfer. Taking the data directly from the wearable sensors.
- Warehouse data transfer. Taking the data from the proprietary warehouse.
- Direct access. If the third-party collects the data directly from the source in which it is available, whether wearable or warehouse.
- Indirect access. If some kind of intermediary system, such as a smartphone or a PC, is needed as a gateway to the third-party server.
3.2.1. Wearable Data Transfer—Indirect Access
- Link 1. An app in a smartphone can collect data from a wearable. To do so, a native app running in the smartphone subscribes as a listener to events in wearable sensors. The wearable periodically notifies new data and the smartphone collects it. In all cases where we have studied this transfer, it is performed using Bluetooth.
- Link 2. An app in a smartphone sends data to a server. Periodically, a native app running in the smartphone checks the availability of an Internet connection. When the connection is available, the app sends the data collected to the server. The smartphone app stores the data collected from the wearables while the Internet connection is not available.
3.2.2. Warehouse Data Transfer—Direct Access
- Link 3. The wearable sends data to its proprietary warehouse. This is performed through the proprietary transfer solution. This solution is based on an app running in an intermediate smartphone or PC, which acts as a gateway towards the server. In the cases we studied, the wearable sends the data to the intermediate app using Bluetooth. This transfer is performed periodically because of the energy demands of the Bluetooth connection. Depending on the wearable, if this transfer cannot be performed for a long time, the data can be summarized or even lost.
- Link 4. The data is transferred from the intermediate smartphone or PC to the wearable warehouse.
- Link 5. The wearable warehouse receives requests from third-party systems through the REST API. Then, the warehouse delivers the requested data.
3.2.3. Warehouse Data Transfer—Indirect Access
3.2.4. Wearable Data Transfer—Direct Access
3.2.5. Data Transfer Options by Platform
4. Data Integration
4.1. Differences in Data Models
- Microsoft manages each sleep period as a different object, named as a sleep segment. When the user moves from light sleep to deep sleep, for example, a new sleep segment object is produced. Each sleep segment includes its own start and finish date object and type of sleep (cf. Listing 1).
- Google Fit. It uses a structure based on segments similar to the Microsoft Band. Each segment includes the start and finish time and it is tagged with the sleep state.
- Apple Health. Its model is also based on segments, but in this case segments can be overlapped . It is possible to find segments in which the user is in bed but not sleeping and other segments in which the user is in bed and sleeping. Situating the segments along a temporal axis, it is possible to know the different sleep states of the user, the total sleeping time, the awake time, etc.
- Fitbit. The sleep record is represented minute by minute (cf. Listing 2). Each minute is tagged with the sleep state of the user.
- In Jawbone, there are segments indicating a new sleep period, but there is no information about the end of the period (cf. Listing 3).
4.2. Differences in Data Names
- Sleep types managed by Microsoft are: Doze, Snooze, Awake, Sleep, and three subtypes: Unknown (for awake segment), RestlessSleep and RestfulSleep (for sleep segment).
- Google Fit distinguishes among four sleep levels: sleep light, deep, REM (Rapid Eye Movement) and awake. These are the exact number of states and names given by the sleep physiognomy theory.
- Fitbit distinguishes among three possible states (cf. Listing 2): sleeping, awake or really awake. The difference between awake and really awake is determined by the violence and duration of the movements. Basically, it tries to distinguish between a light-brief movement (awake) and a strong-long movement (really awake).
- Jawbone distinguishes sleep states as: awake, light and deep (cf. Listing 3).
|segmentType: “Doze”, “Snooze”, “Awake”, “Sleep”|
sleepType: “Unknown”, “RestlessSleep “, RestfulSleep
|1 (“asleep”), 2 (“awake”), or 3 (“really awake”)|
|1 (awake), 2 (light) or 3 (deep)|
4.3. Temporal Discrepancies
- Microsoft identifies different sleep periods using a single identifier for each day. Therefore, if a user sleeps from day 6 to day 7, that sleep period is assigned to day 6. If the user sleeps after midnight, the sleep period is assigned to the next day. As a result, the data can show weird things: some days the user does not sleep at all, while other days he/she sleeps almost all the day.
- Fitbit identifies each sleep period using a different identifier. For each day, one of the periods is marked as the main one and the other periods, if available, as naps. If a user sleeps from day 6 to day 7, the sleep period is assigned to day 7.
- Jawbone follows an approach similar to Microsoft. Nevertheless, if a user sleeps from day 6 to day 7, the sleep period is assigned to day 7.
4.4. Differences in Counters
5. Use Cases
- Personalized work plan. Taking into account the chronotype, the time periods with more sleepiness and stress level, a working plan will be generated suggesting studying, physical activity and relaxing hours. Learning and training activities will be assigned to the periods at which the user is more active.
- Student working groups. Students are grouped taking into account their chronotype. Students with a similar chronotype and somnolence periods will be grouped together.
- Recommendations. The introduced indicators made up a learner profile. This will enable us to apply clustering algorithms to identify similar learners and provide recommendations based on neighbourhood. For example, to perform similar activities or adopt the study routine of successful learners.
- Alerts. These can be generated when anomalies are detected in relation to the sleep and stress patterns captured in the indicators.
- Self-quantification. The values and indicators will be shown to the student (and teacher) on a specific dashboard. Daily, weekly and monthly summaries together with comparisons with other students will be provided. This can be used as a tool to promote self-reflection and self-regulation, similar to what is already done in sport activities. It will enable the user to be more aware of his own features and patterns.
- More information will be provided to the teachers about the student activities related to their subjects. Particularly, classroom measures of the stress or sleepiness levels during different academic activities can be provided. This will enable teachers to plan their teaching, taking advantage of the periods at which the students are more activated. Similarly, activation and relaxing activities could be introduced to reduce the sleepiness and stress at certain situations.
5.1. Selected Devices
- Developer’s market share. It is important to use common devices in the market because we are mainly interested in their availability for our experiments.
- The availability of sensors. We are working on the development of algorithms that do not require many sensors, but some of them are key in order to calculate the indicators. Therefore, a minimum set of sensors should be available: accelerometer and HR in most cases are necessary.
- The options to collect data from the device. We pay attention to the availability of some API or method that enables us to collect data from the device.
- Price and availability. Every student needs to obtain his/her own wearable. Therefore, from a sustainability point of view, we tried to work with devices that were easy to acquire and affordable.
- Fitbit Surge. Fitbit had the largest smartband market share in recent years. In addition, it provides a REST API that facilitates data collection.
- LG Watch R. This was selected as a kind of Android Wear device. This device enables access to the sensor data through native apps, but it also supports the Android app and the Web Service provided by Google Fit.
- Microsoft Band. This was selected taking into account the relevance of the company supporting it. In addition, it includes a good set of sensors and provides easy access to data through its API.
- Jawbone. This device provides sleep information based on a unique sensor: an accelerometer. It was selected because it is a very affordable device and the developer is well-known in the wearable market.
5.1.1. Fitbit Surge
5.1.2. LG Watch R
5.1.3. Microsoft Band
5.1.4. Jawbone UP Move
5.2. Data Transfer
5.2.1. Fitbit Surge
5.2.2. LG Watch R
- Wearable data transfer—indirect access. If we use the Google Fit SDK, we can gain access to the wearable sensors to obtain HR and steps, but we cannot obtain accelerometer or gyroscope raw data. To retrieve such data, we would need to develop and install native apps both in the wearable and in the smartphone. Using this mode, the following data elements can be collected: HR, accelerometer, xyz position, atmospheric pressure, steps, calories and distance. In this case the data can be collected in real time.
- Warehouse data transfer—direct/indirect access. The wearable sensors’ data is transferred through the smartphone to the Google Fit warehouse. Then, warehouse data is requested by our server on a daily basis. The data collected in this mode is limited: distance walking/by bike/running, calories consumed, number of steps, time spent in each type of exercise, and if the user has manually taken his/her HR, this value is also included.
5.2.3. Microsoft Band
- Wearable data transfer—indirect access. The Microsoft Health app needs to be installed in the wearable and a native app has to be installed on the smartphone. Microsoft provides a library set (SDK) compatible with Android, iOS and Windows that can be used to implement the smartphone app. Using this mode, the sensors’ data can be collected in real time. Nevertheless, not all the data from the available sensors can be collected. For example: light sensor, GPS and galvanic sensor. In addition, it is important to note that in case the connection is broken, the data about HR and skin temperature is lost. Another issue to have in mind is that some data, such as the number of steps and calories consumed, is provided as a number since the beginning of time. This means that the number of steps in a certain day has to be computed as the difference between the value at the end and at the beginning of the day.
- Warehouse data transfer—direct access. The sensors’ data stored in the Microsoft warehouse is summarized and processed in accordance to the Microsoft models. As a result, the data available for third-parties is: distance, calories consumed, number of steps, time devoted to different exercises, HR according to the activity type, sleep analysis, etc. In the case of sleep analysis, it provides both the sleep stages and the HR in time intervals (cf. Figure 10).
5.2.4. Jawbone UP Move
- What happens if the (Bluetooth) connection to the intermediate system (e.g., smartphone) used to transfer the data to the proprietary warehouse or to the third-party server is broken? In the Microsoft Band case, when the connection between the wearable and the smartphone is broken, the sampling rate of sensors’ data is reduced to save memory. When the connection is recovered the saved data is sent to the intermediate system as soon as possible.
- What happens if the connection between the intermediate system and the warehouse/server is broken? In this case, the data is stored in the intermediate system because it has a much larger memory capacity than the wearable. The situation in which this memory is completed is not considered.
- What happens if the wearable is not able to transfer the data and is running out of memory? Usually, as for Fitbit, if the wearable is running out of memory it summarizes the data collected and in the worst cases, it removes the older summaries.
- How is the permission to obtain users’ private data from the proprietary warehouse granted? To receive permission to access data stored in warehouses, such as Fitbit or Google Fit, methods available in the REST API or SDKs need to be invoked on an individual basis. Using a specific web page, the user will check the permission requests and will confirm them to the third-party. Once a permission is granted a “token” is provided that can be used to collect the private user data from the warehouse.
- How long is the duration of the token? The token has a limited valid time because of security concerns. Once the user has been granted permission to gain access to his/her data, a “refresh token” is also provided, in addition to the “token”. When the lifetime of the “token” expires, the “refresh token” can be used to generate a new “token”. Currently, there are great differences in the duration of the tokens for different vendors, while in some cases they are in the order of hours, in other cases they are in the order of years.
5.3. Integrating Data
- All the wearables that enable the transfer of data in real time to our server follow the same data model. This model is shown in Listing 4.
- All the data objects include a unique id, the learner id, the date as a String and as a Long integer, the learner id in the proprietary warehouse and the device id. This data is shown in Listing 5.
- The sleep data analysed every day is collected from the source and prepared in accordance to the model shown in Listing 6.
|private String device;|
private Long date;
private int wear;
private int resistence;
private String uvValue, typeWalk;
private double tempValue, speedValue, disValue, accelValue;
private long stepsValue, caloriesValue, hrValue;
private String typeStudy;
|protected String _id;|
protected String student_id;
protected Long date;
protected String student_id_api;
protected String device;
“hr”: [64, 64,…],
- Apache Commons-math3. Library with statistical functions such as: standard deviation, linear regressions, matrix operations, etc.
- Weka . This library is used to solve machine learning developments. The classifiers allow us to provide real time predictions for the indicators: stress, sleepiness, etc.
- Input data flow. This is related to the collection of data from wearables, data homogenization and storage in the database. It can be produced in two different ways:
- OnDemand. This is related to the “indirect access” mode. The intermediate device needs to include the software that collects data in the wearable or in the warehouse and send it to the server through POST requests. Next, calculations included in the classes StatisticsCalcs, WekaCalcs and IndicatorsCalcs are applied to get the indicators.
- Scheduled. Every morning at the same time (12:30 p.m.) the server performs the update of tokens and initiates the collection of data from the registered users. GET or POST requests are used in accordance to the different options.
- Proprietary systems collections. We store data collected from proprietary systems in sleep_fitbit, sleep_microsoft, sleep_jawbone, etc. We also maintain the tokens needed to carry out the scheduled daily data collections in fitbit_token, microsoft_token, jawbone_token, etc.
- sleep_analytics. This collection stores the homogenized sleep data per user, device and date. It maintains no-real time indicators in accordance to the data model shown in Listing 6: sleep quality and chronotype.
- band_sensors. This collection stores the sensors homogenized data. Each entry corresponds to a specific user, device and date. The data is arranged in accordance to the model shown in Listing 4.
- sleep_quiz. This collection stores the answers of the users to the sleep questionnaire. Each entry is related to a specific user and date.
5.3.2. Differences in Data Models/Names
- Fitbit has a main problem because there is not a one to one mapping between Fitbit (“asleep”, “awake” and “really awake”) and Microsoft (“awake”, “light” and “deep”) sleep types. In Fitbit, the “awake” state is assigned to very short periods produced when the user is moving while sleeping. Therefore, we decided to assign “really awake” and “awake” the value “awake”. As a result, we just used “asleep” and “awake” types.
- In the Jawbone case, we need to use two records to create a sleep segment. We use the start time of both of them to indicate the start and finish period.
5.3.3. Temporal Discrepancies
5.3.4. Differences on Counters
5.3.5. Sensors Standardization
5.3.6. Analytics Location
- All the analytic processing is performed in the smartphone. In this case, the smartphone transfers to the server just the results obtained from the analytics, not the raw sensors’ data. This can be a valuable advantage from privacy and data protection points of view, because the data shared is not so sensitive. For example, accelerometer and HR data can be used to get many different results, more than if just the sleep features are available. In addition, the data transfer load is highly reduced. On the contrary, the performance of analytics in the smartphone is very low and drains the battery. This option is not feasible if wearable data transfer from the wearable to the smartphone is not feasible.
- All the analytics processing is performed in the server. The advantage of this solution is that algorithms can be changed easily and for all the devices involved at the same time. There would be just one implementation for each algorithm, and not several versions such in the smartphone case where multiple implementations would be required for different developers. In addition, the performance of servers is much better than the performance of smartphones. In the smartphone case, the analytics should be performed in the background.
- In a hybrid approach, processing in the smartphone and in the server, the algorithms are split between both systems trying to get the better performance and to ensure data privacy issues. Particularly, the homogenization operations can be performed in the smartphone.
6. Standardization Context
6.1. Key Concepts
- The ISO/IEC JTC1 established the Special Working Group (SWG) 5 on the IoT in 2012 to identify gaps and market requirements related to the IoT. In November 2014 JTC1 decided to establish a new Working Group WG 10 on the IoT to create standards, coordinating the standardization work and cooperation with other organizations. Currently, this group is working in the ISO/IEC 30141—the IoT Reference Architecture but it is just at a preparatory stage.
- The “oneM2M—Standards for M2M and the Internet of Things” is a partnership of main standardization bodies, such as the European Telecommunications Standards Institute (ETSI), the US Alliance for Telecommunications Industry Solutions (ATIS) and Telecommunications Industry Association (TIA) and similar bodies in Japan, China, India and South Korea. It is also made up of 232 members from main electronic, computer and communication vendors. It is focused on the standardization of end-to-end M2M communications . The OneM2M Technical Specification published in January 2015 specifies the functional architecture for the Services Platform, but it is still under development .
- The IEEE Standards Association has launched the project P2413—Standard for an Architectural Framework for the IoT to promote cross-domain interaction, aid system interoperability and functional compatibility in for the IoT . More related to the contents of this paper, the IEEE has also launched the P360—Standard for Wearable Consumer Electronic Devices—Overview and Architecture. Its main goal is to provide a testing solution and a homogeneous way to describe the features for wearable consumer electronic devices. Currently, both proposals are under development.
Conflicts of Interest
- Rawassizadeh, R.; Price, B.A.; Petre, M. Wearables: Has the Age of Smartwatches Finally Arrived? Commun. ACM 2014, 58, 45–47. [Google Scholar] [CrossRef]
- Swan, M. Sensor Mania! The Internet of Things, Wearable Computing, Objective Metrics, and the Quantified Self 2. J. Sens. Actuator Netw. 2012, 1, 217–253. [Google Scholar] [CrossRef]
- Richter, F. The Predicted Wearables Boom is All about the Wrist. Available online: https://www.statista.com/chart/3370/wearable-device-forecast/ (accessed on 24 May 2016).
- Sazonov, E.; Neuman, M. Wearable Sensors: Fundamentals, Implementation and Applications; Academic Press: Waltham, MA, USA, 2014. [Google Scholar]
- Buechley, L.; Eisenberg, M.; Catchen, J.; Crockett, A. The LilyPad Arduino; Using Computational Textiles to Investigate Engagement, Aesthetics, and Diversity in Computer Science Education. In Proceedings of the Twenty-Sixth Annual CHI Conference on Human Factors in Computing Systems—CHI ’08, Florence, Italy, 5–10 April 2008; ACM Press: New York, NY, USA, 2008; p. 423. [Google Scholar]
- Buechley, L.; Eisenberg, M. The LilyPad Arduino: Toward Wearable Engineering for Everyone. IEEE Pervasive Comput. 2008, 7, 12–15. [Google Scholar] [CrossRef]
- Miwa, H.; Sasahara, S.; Matsui, T. Roll-over Detection and Sleep Quality Measurement Using a Wearable Sensor. In Proceedings of the 2007 29th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Lyon, France, 23–26 August 2007.
- Sano, A.; Picard, R.W. Stress Recognition Using Wearable Sensors and Mobile Phones. In Proceedings of the 2013 Humaine Association Conference on Affective Computing and Intelligent Interaction, Geneva, Switzerland, 2–5 September 2013.
- Shoaib, M.; Bosch, S.; Scholten, H.; Havinga, P.J.M.; Incel, O.D. Towards detection of bad habits by fusing smartphone and smartwatch sensors. In Proceedings of the 2015 IEEE International Conference on Pervasive Computing and Communication Workshops (PerCom Workshops), St. Louis, MO, USA, 23–27 March 2015.
- Xu, C.; Pathak, P.H.; Mohapatra, P. Finger-writing with Smartwatch: A case for finger and hand gesture recognition using smartwatch. In Proceedings of the 16th International Workshop on Mobile Computing Systems and Applications—HotMobile ’15, Santa Fe, NM, USA, 12–13 February 2015; ACM Press: New York, NY, USA, 2015; pp. 9–14. [Google Scholar]
- Garcia-Mancilla, J.; Gonzalez, V.M. Stress Quantification Using a Wearable Device for Daily Feedback to Improve Stress Management; Springer International Publishing: Cham, Switzerland, 2016; pp. 204–209. [Google Scholar]
- Haescher, M.; Matthies, D.J.C.; Urban, B. Anomaly Detection with Smartwatches as an Opportunity for Implicit Interaction. In Proceedings of the 17th International Conference on Human-Computer Interaction with Mobile Devices and Services Adjunct—MobileHCI ’15, Copenhagen, Denmark, 24–27 August 2015; ACM Press: New York, NY, USA; pp. 955–958.
- De Arriba Perez, F.; Caeiro Rodriguez, M.; Santos Gago, J.M. Extracción de conocimiento a partir de datos de uso de dispositivos móviles con fines educativos Knowledge extraction from usage data of mobile devices with educational purposes. In 2015 10th Iberian Conference on Proceedings of the Information Systems and Technologies (CISTI), Aveiro, Portugal, 17–20 June 2015; pp. 1–4.
- De Arriba Perez, F.; Santos Gago, J.M.; Caeiro Rodriguez, M. Calculation of Sleep Indicators in Students Using Smartphones and Wearables. New Adv. Inf. Syst. Technol. 2016, 445, 169–178. [Google Scholar]
- De Arriba Perez, F.; Santos Gago, J.M.; Caeiro Rodriguez, M. Analytics of biometric data from wearable devices to support teaching and learning activities. J. Inf. Syst. Eng. Manag. 2016, 1, 41–54. [Google Scholar]
- Ben-Zeev, D.; Campbell, A.; Chen, F.; Chen, Z.; Li, T.; Wang, R.; Zhou, X.; Harari, G.; Tignor, S.; Wang, R.; et al. Student Life Study. Available online: http://studentlife.cs.dartmouth.edu/ (accessed on 29 July 2016).
- Wang, R.; Harari, G.; Hao, P.; Zhou, X.; Campbell, A.T. SmartGPA: How smartphones can assess and predict academic performance of college student. In Proceedings of the 2015 ACM International Joint Conference on Pervasive and Ubiquitous Computing—UbiComp ’15, Osaka, Japan, 7–11 September 2015; ACM Press: New York, NY, USA, 2015; pp. 295–306. [Google Scholar]
- Haim, S.; Wang, R.; Lord, S.E.; Loeb, L.; Zhou, X.; Campbell, A.T. The mobile photographic stress meter (MPSM): A new way to measure stress using images. In Proceedings of the 2015 ACM International Joint Conference on Pervasive and Ubiquitous Computing and Proceedings of the 2015 ACM International Symposium on Wearable Computers—UbiComp ’15, Osaka, Japan, 7–11 September 2015; ACM Press: New York, NY, USA, 2015; pp. 733–742. [Google Scholar]
- Mattern, F.; Floerkemeier, C. From the Internet of Computers to the Internet of Things. In From Active Data Management to Event-Based Systems and More; Springer: Berlin, Germany; Heidelberg, Germany, 2010. [Google Scholar]
- Watson, D.; Piette, M.; Sezgen, O. Machine to machine (M2M) technology in demand responsive commercial buildings. In Proceedings of the 2004 ACEEE Summer Study on Energy Efficiency in Buildings, Pacific Grove, CA, USA, 23–27 August 2004.
- Blackstock, M.; Lea, R. IoT interoperability: A hub-based approach. In Proceedings of the 2014 International Conference on the Internet of Things (IOT), Rome, Italy, 28 October 2014; pp. 79–84.
- Desai, P.; Sheth, A.; Anantharam, P. Semantic Gateway as a Service Architecture for IoT Interoperability. In Proceedings of the 2015 IEEE International Conference on Mobile Services, New York, NY, USA, 27 June–2 July 2015; pp. 313–319.
- Elmangoush, A.; Coskun, H.; Wahle, S.; Magedanz, T. Design aspects for a reference M2M communication platform for Smart Cities. In Proceedings of the 9th International Conference on Innovations in Information Technology, Al Ain, UAE, 7–19 March 2013.
- IEEE-SA P2413. Standard for an Architectural Framework for the Internet of Things (IoT). Available online: https://standards.ieee.org/develop/project/2413.html (accessed on 24 May 2016).
- oneM2M. Standards for M2M and the Internet of Things. Available online: http://www.onem2m.org/about-onem2m/why-onem2m (accessed on 24 May 2016).
- onemM2M. Functional Architecture. Available online: http://onem2m.org/images/files/deliverables/TS-0001-Functional_Architecture-V1_6_1.pdf (accessed on 24 May 2016).
- Liarokapis, F.; Petridis, P.; Lister, P.F.; White, M. Multimedia augmented reality interface for e-learning (MARIE). World Trans. Eng. Technol. Educ. 2002, 1, 173–176. [Google Scholar]
- Kafai, Y.; Fields, D.; Searle, K. Electronic Textiles as Disruptive Designs: Supporting and Challenging Maker Activities in Schools. Harv. Educ. Rev. 2014, 84, 532–556. [Google Scholar] [CrossRef]
- Han, D.; Zhang, C.; Fan, X. Understanding android fragmentation with topic analysis of vendor-specific bugs. In Proceedings of the 2012 19th Working Conference on Reverse Engineering, Kingston, ON, Canada, 15–18 October 2012.
- IDC The Worldwide Wearables in 2015, According to IDC. Available online: http://www.idc.com/getdoc.jsp?containerId=prUS41037416 (accessed on 11 May 2016).
- IDC Worldwide Wearables Market Q1 2016. Available online: http://www.idc.com/getdoc.jsp?containerId=prUS41284516 (accessed on 24 May 2016).
- IDC IDC Forecasts Worldwide Shipments of Wearables to Surpass 200 Million in 2019, Driven by Strong Smartwatch Growth and the Emergence of Smarter Watches. Available online: https://www.idc.com/getdoc.jsp?containerId=prUS41100116 (accessed on 24 May 2016).
- Apple Health—Apple. Available online: http://www.apple.com/ios/health/ (accessed on 24 May 2016).
- Apple ResearchKit and CareKit—Apple. Available online: https://www.apple.com/researchkit/ (accessed on 24 May 2016).
- Google Google Fit. Available online: https://developers.google.com/fit/ (accessed on 20 April 2016).
- Samsung S Health. Available online: https://shealth.samsung.com/ (accessed on 24 May 2016).
- Vandrico Inc. Available online: http://vandrico.com/wearables/ (accessed on 20 April 2016).
- Ur Rehman, M.H.; Liew, C.S.; Wah, T.Y.; Shuja, J.; Daghighi, B. Mining personal data using smartphones and wearable devices: A survey. Sensors 2015, 15, 4430–4469. [Google Scholar] [CrossRef] [PubMed]
- SAMSUNG. Available online: http://www.samsung.com/es/consumer/mobile-devices/wearables/filter/ (accessed on 20 April 2016).
- Jawbone. Available online: https://jawbone.com/up/trackers (accessed on 20 April 2016).
- Apple Watch. Available online: http://www.apple.com/es/shop/buy-watch/apple-watch-sport (accessed on 20 April 2016).
- Fitbit. Available online: https://www.fitbit.com/ (accessed on 20 April 2016).
- Garmin. Available online: http://www.garmin.com/ (accessed on 20 April 2016).
- LG G Watch R. Available online: http://www.lg.com/es/wearables/lg-LGW110-g-watch-r (accessed on 20 April 2016).
- Mi Band. Available online: http://www.mi.com/en/miband/#01 (accessed on 20 April 2016).
- Microsoft Band. Available online: https://www.microsoft.com/microsoft-band/en-us/features (accessed on 20 April 2016).
- Natale, V.; Drejak, M.; Erbacci, A. Monitoring sleep with a smartphone accelerometer. Sleep Biol. Rhythms 2012, 10, 287–292. [Google Scholar] [CrossRef]
- Guo, F.; Li, Y.; Kankanhalli, M.; Brown, M. An evaluation of wearable activity monitoring devices. In Proceedings of the 1st ACM International Workshop on Personal Data Meets Distributed Multimedia, Barcelona, Spain, 22 October 2013.
- Richmond, S. The Real World Wrist-Based Heart Rate Monitor Test: Are They Accurate Enough? Available online: http://www.wareable.com/fitness-trackers/heart-rate-monitor-accurate-comparison-wrist (accessed on 25 May 2016).
- Valenti, G.; Westerterp, K. Optical heart rate monitoring module validation study. Consum. Electron. 2013. [Google Scholar] [CrossRef]
- Kern, N.; Schiele, B.; Schmidt, A. Multi-sensor Activity Context Detection for Wearable Computing; Springer: Berlin, Germany; Heidelberg, Germany, 2003; pp. 220–232. [Google Scholar]
- Hezarjaribi, N.; Fallahzadeh, R.; Ghasemzadeh, H. A machine learning approach for medication adherence monitoring using body-worn sensors. In Proceedings of the Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, Germany, 14–18 March 2016.
- Jersey 2.22.1 User Guide. Available online: https://jersey.java.net/ (accessed on 20 April 2016).
- Mark, H.; Ian, W.; Eibe, F. Data Mining: Practical Machine Learning Tools and Techniques; Morgan Kaufmann Publishers: Burlington, MA, USA, 2011. [Google Scholar]
- Buysse, D.J.; Reynolds, C.F.; Monk, T.H.; Berman, S.R.; Kupfer, D.J. The Pittsburgh Sleep Quality Index: A new instrument for psychiatric practice and research. Psychiatry Res. 1989, 28, 193–213. [Google Scholar] [CrossRef]
- Horne, J.A.; Ostberg, O. A self-assessment questionnaire to determine morningness-eveningness in human circadian rhythms. Int. J. Chronobiol. 1975, 4, 97–110. [Google Scholar]
- Madrid, J.A. Versión castellana del cuestionario de matutinidad-vespertinidad de horne Y östberg (revisado). Available online: http://www.cet.org/wp-content/uploads/2014/11/MEQ-SA-ESP.pdf (accessed on 24 May 2016).
- Healey, J.A. Wearable and Automotive Systems for Affect Recognition from Physiology. Ph.D. Thesis, Massachusetts Institute of Technology, Cambridge, MA, USA, 2000. [Google Scholar]
- Zhai, J.; Barreto, A. Stress Detection in Computer Users Based on Digital Signal Processing of Noninvasive Physiological Variables. In Proceedings of the 2006 International Conference of the IEEE Engineering in Medicine and Biology Society, New York, NY, USA, 31 August–3 September 2006.
- Kurniawan, H.; Maslov, A.V.; Pechenizkiy, M. Stress detection from speech and Galvanic Skin Response signals. In Proceedings of the 26th IEEE International Symposium on Computer-Based Medical Systems, Porto, Portugal, 20–22 June 2013.
- Alberto de, S.S. Design, Implementation and Evaluation of an Unconstrained and Contactless Biometric System Based on Hand Geometry and Stress Detection. Ph.D. Thesis, Universidad Politécnica de Madrid, Madrid, Spain, 2012. [Google Scholar]
- Zimmerman, B.; Schunk, D. Self-Regulated Learning and Academic Achievement: Theory, Research, and Practice; Springer Science & Business Media: New York, NY, USA, 2012. [Google Scholar]
- McNiff, J. Action Research: Principles and Practice; Routledge Abingdon-on-Thames: New York, NY, USA, 2013. [Google Scholar]
- Google Android APIs—Google Fit. Available online: https://developers.google.com/fit/android/ (accessed on 20 April 2016).
- Hamida, S.; Hamida, E.; Ahmed, B. A new mHealth communication framework for use in wearable WBANs and mobile technologies. Sensors 2015, 15, 3379–3408. [Google Scholar] [CrossRef] [PubMed]
- Cisco. The Internet of Things Reference Model. Available online: http://cdn.iotwf.com/resources/71/IoT_Reference_Model_White_Paper_June_4_2014.pdf (accessed on 24 May 2016).
- Holler, J.; Tsiatsis, V.; Mulligan, C. From Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence; Academic Press: Cambridge, MA, USA, 2014. [Google Scholar]
- Kuzlu, M.; Pipattanasomporn, M.; Rahman, S. Communication network requirements for major smart grid applications in HAN, NAN and WAN. Comput. Netw. 2014, 67, 74–88. [Google Scholar] [CrossRef]
- Piwek, L.; Ellis, D.A.; Andrews, S.; Joinson, A. The rise of consumer health wearables: Promises and barriers. PLoS Med. 2016, 13, e1001953. [Google Scholar] [CrossRef] [PubMed]
|Platforms||Wearable Data—Indirect Access||Warehouse Data—Direct Access||Warehouse Data—Indirect Access|
|Values||Start Bed Time||Values||End Bed Time|
|Sensors||LG G Watch R||Fitbit Surge||Microsoft Band||Jawbone UP Move|
|Ultraviolet Light Sensor||-||-||X||-|
|Type||LG G Watch R||Fitbit Surge||Microsoft Band||Jawbone UP Move|
|Warehouse data transfer||X||X||X||X|
|Token duration||(Unknown)||1 month||1 h||1 year|
|Wearable data transfer||X||-||X||-|
|Battery duration with warehouse data transfer||1 day||4 days||3 days||6 months|
|Battery duration with wearable data transfer||10 h||-||10 h||-|
© 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/).