Korean Institute of Information Technology
[ Article ]
The Journal of Korean Institute of Information Technology - Vol. 16, No. 9, pp.13-21
ISSN: 1598-8619 (Print) 2093-7571 (Online)
Print publication date 30 Sep 2018
Received 23 Jul 2018 Revised 03 Sep 2018 Accepted 06 Sep 2018
DOI: https://doi.org/10.14801/jkiit.2018.16.9.13

이기종 스마트워치의 라이프로그 수집을 위한 관계형 데이터베이스 모델

권승원* ; 이석훈**
*군산대학교 소프트웨어융합공학과
**군산대학교 소프트웨어융합공학과 교수
Relational Database Model for Collecting Lifelog from Heterogeneous Smart Watches
Seungwon Kwon* ; Sukhoon Lee**

Correspondence to: Sukhoon Lee Dept. of Software Convergence Engineering, Kunsan National University, Korea Tel: +82-63-469-8914, E-mail: leha82@kunsan.ac.kr

초록

최근 웨어러블 디바이스 시장이 커지며 스마트워치를 이용하여 라이프로그를 수집하는 연구들도 많이 진행되었다. 하지만 Fitbit, 애플, 삼성, 샤오미 등 다양한 스마트워치 제조사에서 각기 다른 플랫폼에서 서비스함에 따라 각각의 라이프로그를 수집하는 것이 어렵다. 따라서 이 논문은 이기종 스마트워치에서 생성되는 라이프로그를 수집하는 시스템과 라이프로그를 통합적으로 관리할 수 있는 데이터베이스 모델을 제안한다. 제안 모델은 관계형 데이터베이스에 기반하며 이기종 스마트워치를 위한 확장성에 초점을 맞춘다. 또한 이 논문은 각 스마트워치 플랫폼에서의 라이프로그 수집기를 구현하고 제안 데이터베이스 모델을 구축한다. 평가를 위하여 라이프로그를 저장할 수 있는 두 가지 유형의 데이터베이스 모델을 정의하고 확장성을 평가한다. 또한 각 스마트워치 별 라이프로그 수집기의 비교를 통하여 제안 데이터베이스 모델의 우수성을 보인다.

Abstract

Recently, the market for wearable devices has been growing, and many researches have been worked to collect lifelog using smart watches. However, it is difficult to collect lifelog on each device as various smart watch manufacturers such as Fitbit, Apple, Samsung, and Xiaomi serve on different platforms. Therefore, this paper proposes a system that collects lifelog generated from heterogeneous smart watches and a database model that can manage life logs integrally. The proposed model is based on a relational database and focuses on scalability for heterogeneous smart watches. This paper also builds a life log collector on each smart watch platform and builds a proposal database model. For evaluation, We define two types of database models which store lifelog and evaluate their extensibility. In addition, we show the superiority of the proposed database model by comparing each lifelog collector by smart watches.

Keywords:

lifelog, lifelog collector, database model, wearable device, heterogeneous smart watch

Ⅰ. 서론

최근 웨어러블 디바이스에 대한 대중들의 이목이 집중되며 웨어러블 디바이스 시장은 눈부시게 발전하고 있다. 그 중 접근성이 용이하고 대중들이 쉽게 접할 수 있는 스마트워치는 스마트폰의 보급률 증가와 함께 많은 발전을 이룬 웨어러블 디바이스중 하나이다[1]. Fitbit, 샤오미, 애플 등은 스마트워치의 대표적인 제품들을 출시했으며, 삼성, 엘지 등의 전자회사를 포함해 몽블랑, 태그호이어 등 전자제품을 주력사업으로 삼고 있지 않은 회사들도 구글과 협약을 통해 스마트워치 시장에 제품을 출시하고 있다.

다양한 종류의 스마트워치가 시중에 출시되는 만큼, 다양한 기능을 가진 스마트워치들이 존재한다. 기본적으로 인간의 건강에 대한 데이터는 물론 운동기록 등 다양한 데이터들이 스마트워치를 통해 생성된다. 이러한 데이터들은 라이프로그로써 아주 가치 있는 정보들을 가지고 있다[2][3]. 라이프로그는 사용자가 생활하며 발생시키는 로그 데이터들을 의미하며, 스마트워치는 자체적으로 지니는 센서로부터 사용자의 심박수, 활동량, 위치정보 등 다양한 라이프로그를 발생시킨다. 많은 연구자들이 이러한 스마트워치를 활용한 다양한 연구를 진행하고 있으며[4][5], 각 스마트워치 제조사가 제공하는 플랫폼들도 다양한 방법으로 발전하고 있다[6].

사용자에게 데이터를 얻을 수 있게 하는 플랫폼을 제공하는 제조사는 대표적으로 애플, Fitbit, 구글, 삼성 정도가 있다. 제조사별로 각기 다른 플랫폼과 다양한 종류의 데이터를 수집할 수 있도록 제공하고 있으나 이로 인해 발생하는 문제점도 존재한다. 그것은 각 플랫폼마다 각기 데이터를 제공하는 방식이 다르고 데이터 모델의 유형이 다르기 때문에 다양한 플랫폼에서 얻는 데이터를 통합하여 활용하는 것은 쉽지 않다는 것이다. 통합된 데이터의 수집은 수집 방식, 종류, 품질 등의 차이로 인해 데이터의 일관성을 해치며 종합적인 분석을 어렵게한다. 예를 들어, Fitbit의 경우 자체 제공되는 플랫폼을 통하여 RESTful API를 이용해 서버에 저장되어 있는 데이터를 수집할 수 있으며, 삼성의 경우는 SDK를 이용해 직접 데이터 수집 앱을 개발하여 데이터를 수집 할 수 있다. 만약 Fitbit에서 수집된 심박수의 경우 플랫폼에서 1분당 데이터만을 제공한다면, 삼성의 경우 스마트워치 앱을 직접 개발하여 원하는 1초 단위의 데이터 수집도 가능하게 한다.

따라서 다양한 기기에서 생겨나는 데이터들을 활용하기 위해 생성되는 데이터들을 수집하는 시스템과 수집된 데이터들을 한 곳에 모으고 여러 분야에서 활용할 수 있도록 하는 통합 데이터베이스가 필요하다.

이 논문에서는 이기종 스마트워치에서 생성되는 라이프로그를 수집하는 시스템과 라이프로그를 통합적으로 관리할 수 있는 데이터베이스 모델을 제안한다. 이를 위하여 Fitbit, Fit.Life, 삼성의 스마트워치들로부터 라이프로그를 수집할 수 있는 수집기를 만들고 각종 데이터의 유형을 분석한다. 제안하는 데이터베이스 모델은 시스템 구축의 편의성 및 데이터 모델의 구조적 편의성을 위하여 관계형 데이터베이스를 이용한다. 이후 구현 및 평가를 통하여 제안하는 데이터베이스 모델의 장점을 보인다.

한편, 많은 연구들이 빅데이터 기술에 기반한 데이터베이스를 활용하여 센서 및 다양한 데이터를 저장하고자 연구되었다[7][8]. 하지만 이 연구에서 목표로 하는 라이프로그는 스마트워치로부터 발생하는 데이터로 주로 숫자 위주의 정형 데이터들이 대상이다. 또한 다양한 형태의 특징들만을 모아 라이프로그 데이터 셋을 구축하여 분석에 활용하는 것을 목표로 한다. 따라서 빠른 데이터 수집과 실시간성이 강조된 NoSQL 유형의 분산형 데이터베이스들 보다는 다양한 형태의 데이터셋 구축이 유용한 관계형 데이터베이스가 이 연구에는 더 적합하다. 따라서 이 논문에서 라이프로그 모델링 및 스키마 구축은 관계형 데이터베이스에 초점을 둔다.

이 논문의 구성은 다음과 같다. 2장에서는 관련 연구를 소개한다. 3장에서는 스마트워치로부터 라이프로그를 수집하기 위한 수집 시스템의 구조를 기술하고, 수집된 라이프로그를 저장하기 위한 데이터베이스 모델을 제안한다. 4장은 라이프로그 수집을 위해 구현한 결과와 제안한 데이터베이스 모델의 확장성을 평가하고 수집 시스템 간의 비교 결과를 기술하며, 마지막으로 5장은 결론을 기술한다.


Ⅱ. 관련 연구

2.1 스마트워치 플랫폼

최근 센서가 생성하는 방대한 양의 데이터를 수집하고 수집된 데이터들을 저장하는 구조에 대한 연구가 활발히 이루어지고 있다. [9]는 아두이노 센서와 스마트워치에서 생성되는 건강데이터를 수집하고, 수집한 데이터를 저장소에 저장하고 사용자에게 RESTful API를 이용해 헬스케어 데이터를 제공하는 플랫폼을 만드는 시스템을 제안하였다. [6]에서는 스마트워치를 이용해 수면품질 데이터를 수집하여 여러 가지 분야에서 사용할 수 있으나, 스마트워치들의 플랫폼이 통합되지 않아 연구에서 스마트워치의 데이터를 사용하는 데에 어려움이 존재한다고 기술하였다.

2.2 라이프로그 데이터베이스

사용자가 착용하는 웨어러블 디바이스로부터 다양한 센서에서 생기는 라이프로그를 분석, 저장하고 활용하는 것에 대한 연구가 활발히 이뤄지고 있다.

[10]은 라이프로그를 안드로이드 플랫폼을 이용해 데이터베이스에 저장하고 저장된 데이터를 실시간으로 관측할 수 있는 시스템을 만드는 연구로 환경정보에 관한 여러 가지 센서 데이터를 저장하고 관측하는 시스템을 제안하였다.

[11]은 공장 설비에서 사용되는 센서들에서 생성되는 데이터들을 모아 사용하기 어려운 문제점을 해결하기 위해 데이터들을 통합으로 관리할 수 있는 데이터큐브 구조를 차용한다. 또한, 스마트큐브라는 이름을 가진 플랜트 통합 데이터베이스를 제안하였다.

[12]는 방대한 센서에서 생성되는 라이프로그를 효율적으로 저장하기 위해 데이터들을 분류할 수 있는 알고리즘을 제안하였으며, 데이터들의 중복을 최소화하고 데이터베이스 저장 공간의 효율을 높일 수 있는 모델을 제안하였다.

[13]은 센서 데이터에서 생성되는 라이프로그를 대용량의 데이터베이스로 빠르게 저장하고 인덱싱을 통해 데이터를 효율적이며 상용 데이터베이스에 비해 간편한 쿼리문을 사용할 수 있는 데이터베이스 모델을 제안하였다.


Ⅲ. 라이프로그 수집기 및 데이터베이스 모델

3.1 라이프로그 수집기

이 절에서는 선행 연구[14]에서 언급한 이기종 스마트워치를 이용한 라이프로그 수집 시스템을 좀 더 자세히 기술한다. 이 논문은 통합 데이터베이스 제안을 위해 각종 플랫폼으로부터 데이터를 수집하는 수집기를 구축한다. 이를 위하여 Fitbit의 Blaze, 삼성의 Gear S3, Fit.Life의 Fitmeter를 이용한다.

Fitbit의 경우 자체 제공 플랫폼을 통하여 데이터 수집기를 만들었으며, Fitbit 서버에 저장되어있는 사용자의 데이터를 RESTful API를 통해 받아오는 방법을 이프로그를 파싱하여 제안하는 데이터베이스로 저장하는 방식이다.

그림 1은 Fitbit의 데이터 수집을 위한 시스템인 Fitbit Lifelog Collector와 데이터를 저장하기 위한 구조를 보인다. Fitbit Lifelog Collector는 Fitbit서버에 데이터를 요청하고 저장하는 Data Requester 모듈과 저장된 데이터를 읽고 Repository에 저장하는 Data Manager 모듈로 이루어진다.

Fig. 1.

Architecture of Fitbit lifelog collector

그림 2는 삼성 Gear S3와 Fit.Life Fitmeter의 시스템 구성을 보인다. Gear S3의 경우 삼성에서 제공하는 Tizen SDK를 이용하여 직접 수집하는 앱을 만들었으며, Fitmeter의 경우 제조사에서 제공하는 응용프로그램인 Fitmeter Manager을 이용하여 사용자가 수동적으로 데이터파일들을 수집한다. 수집된 파일들은 라이프로그로서 csv나 txt 파일로 모을 수 있다. Data Manger는 수집된 파일들을 파싱하여 제안하는 데이터베이스인 Repository에 저장하는 구조를 지닌다.

Fig. 2.

Architecture of Gear S3 and Fitmeter lifelog collector

3.2 라이프로그 데이터베이스

이 절에서는 제안하는 라이프로그 저장소의 데이터베이스 구조를 기술한다. 라이프로그 저장소는 접근성, 구축의 용이성, 분석의 활용도 등을 고려하여 관계형 데이터베이스를 기반으로 한다. 기존의 라이프로그는 단일 기종의 스마트워치 등으로부터 수집되어 정해진 데이터 유형, 단위, 수집 주기 등으로 인해 동일한 timestamp에서의 수집된 데이터들을 나열하는 정도의 포맷을 지닌다.

하지만 이기종 스마트워치에서의 라이프로그 수집은 각 기기마다의 수집할 수 있는 데이터의 종류, 단위, 수집 주기 등 모두 다를 수 있으므로 이러한 사항들을 고려하여 데이터베이스를 구축해야한다.

표 1은 제안하는 라이프로그 데이터베이스 모델의 스키마와 그 설명을 보인다. 스키마의 데이터타입은 기기에서 수집되는 다양한 유형의 데이터를 수집하기 위해 정의한 컬럼으로 다양한 기기에서 수집되는 데이터들을 효율적으로 저장할 수 있게 구성되어있다. 또한 uom 컬럼은 데이터가 측정되는 단위를 분류하기 위한 컬럼으로 플랫폼 별로 상이하게 다른 측정단위를 분류한다.

Proposed database model schema


Ⅳ. 구현 및 평가

4.1 구현

이 절에서는 3장에서 기술한 라이프로그 수집기를 실제 구현하고 수집된 파일들을 기반으로 제안하는 데이터베이스 모델에 저장된 결과를 보인다. 그림 3에서 수집 시스템들은 각 기기들의 데이터를 파일형식으로 폴더에 저장하게 된다.

Fig. 3.

Implementation devices and data types

이후 저장된 파일들은 데이터들을 통합해서 관리하기 위해 제안한 데이터베이스 모델인 라이프로그 데이터베이스에 저장한다.

구현 환경은 표 2와 같다. 이기종 스마트워치로는 각각 Fitbit Blaze, Fit.Life Fitmeter, 삼성 Gear S3를 채택하였다. 사용 언어는 자바, 파이썬을 사용하였고 데이터베이스는 MS-SQL을 이용하였다.

Implementation environments

그림 4는 제안하는 데이터베이스 모델로 Blaze의 라이프로그를 수집한 결과를 보인다. GPS 위치, 활동량인 STEPS, 심박수인 HR등의 데이터 수집이 가능하나 GPS의 경우 사용자가 운동하는 상황이라고 판단될 경우에만 수집하기 때문에 모든 경우에 데이터가 존재하지는 않는다.

Fig. 4.

Stored Fitbit lifelog

그림 5는 Fitmeter의 라이프로그 수집 결과를 보인다. Fitmeter의 경우 1/32초 단위로 데이터를 저장하는 것을 지원한다. Fitmeter는 3축 가속도 데이터만을 수집할 수 있으므로 x, y, z에 대한 데이터만을 저장한다.

Fig. 5.

Stored Fitmeter lifelog

그림 6은 저장된 Gear S3의 라이프로그 수집 결과를 보이며, Gear S3의 라이프로그 수집을 위해서 제조사에서 제공하는 SDK를 이용하여 스마트워치 앱을 개발하였다. 이러한 앱을 통하여 심박수, GPS, 3축 가속도를 5초 간격으로 수집한다.

Fig. 6.

Stored Gear S3 lifelog

4.2 데이터 확장성 평가

이 절에서는 수집 시스템을 이용하여 새로운 웨어러블 디바이스 추가나 센서의 유형 추가에 대한제안 모델의 확장성을 평가한다.

평가를 위하여 센서 데이터를 저장할 수 있는 다양한 유형의 데이터베이스 모델을 비교 대상으로 선정하고 이 논문에서 제안하는 시스템에 유사하도록 모델링한다. 그림 7은 비교를 위한 유형별 데이터베이스 스키마를 보인다. 유형 1 모델은 수집하고자 하는 데이터 타입들을 각각의 테이블로 구축한다. 유형 2 모델은 수집하고자 하는 모든 데이터를 하나의 테이블로 구축한다. 이 논문에서는 3축 가속도계, 심박계, GPS 센서를 이용하여 데이터를 수집하는 환경을 고려한다.

Fig. 7.

Types of database schema

확장성 평가를 위하여 이 논문은 각 모델에 대한 새로운 웨어러블 디바이스를 추가하여 확장하는 경우와 기존의 스마트워치에서 새로운 센서 데이터를 추가로 수집하는 경우 얼마나 그 비용이 들어갈지에 대하여 추가되어야 하는 기능들을 나열하였다.

표 3은 새로운 웨어러블 디바이스를 추가하는 경우 각 유형별로 요구되는 작업의 예시를 보인다. Fitbit의 Alta 제품의 경우 심박수나 GPS가 포함되지 않는다. 유형 1 모델, 유형 2 모델, 제안 모델은 모두 devicetype 컬럼에서 Alta라는 메타데이터를 새로 정의해야 한다. 하지만 유형 2의 경우 Alta는 심박수(hr)와 GPS(lat, lon, alt) 센서가 없기 때문에 수집할 수 없는 상황이므로 기존의 type2_tb 테이블에 저장하는 것은 비효율적이다. 따라서 새로운 스마트워치에 대한 테이블을 생성해야 한다. 한 편, Alta는 Fitbit의 플랫폼을 이용하므로 동일한 수집기를 활용하면 되지만, 만약 LG G 워치와 같은 새로운 플랫폼을 이용할 경우 새로운 수집기를 개발해야 한다. 새로운 수집기의 개발은 높은 개발비용이 요구되지만 세 유형 모두 동일하게 적용되는 사항이다.

Extension example to add smartwatch by each type

표 4는 새로운 유형의 센서 데이터를 수집하고자 할 때 각 유형별로 요구되는 작업들을 보인다. 조도 센서의 경우 대부분의 스마트워치마다 지니고 있는 센서로써 분석 시 조도 정보가 요구될 때, 각종 테이블들은 조도 정보를 추가하기 위한 확장 작업이 이루어진다. 먼저 유형 1과 제안 모델은 조도 센서에 대한 공통적인 컬럼에서 메타데이터를 추가해야 한다. 조도 센서는 빛의 밝기 단위로서 lux를 이용하므로 uom에 “lx”와 같이 메타데이터를 정의한다.

Extension example to add illuminometer by each type

유형 1은 새로운 유형의 센서 데이터를 수집하기 위해서는 새로운 테이블을 생성해야 한다. 이 때, 수집기에서는 새로 수집되는 조도에 대한 값을 새 테이블에 저장할 수 있도록 새로운 INSERT 질의문을 개발하고 수집 시 추출된 조도에 대해 개발한INSERT 질의문을 수행할 수 있도록 소스코드를 수정해야 한다.

유형 2는 테이블의 컬럼 확장을 통해 조도 센서를 추가할 수 있다. type2_tb 테이블에서 조도 센서 값을 저장하기 위한 illumination 컬럼을 추가한다. 또한, 수집기에서는 기존 type2_tb 테이블로 삽입하기 위한 INSERT 질의문에 illumination 컬럼을 추가하는 형태의 질의문 수정만이 요구된다.

제안 모델은 단순히 datatype의 메타데이터 정의만으로 확장 가능하다. 예를 들어, 수집기에서 수집되는 조도 정보는 “illumination”이라는 메타데이터로 수집되며, 이 것을 그대로 제안 모델의 datatype 컬럼으로 넣게 된다면, 소스코드의 수정 없이 새로운 유형의 센서 정보를 추가하는 것이 가능하다.

마지막으로 표 5는 앞서 예시로 설명한 디바이스 및 데이터 유형 확장의 결과로서 유형별 확장 비용 평가에 대한 결과를 보인다.

Evaluation of extension cost by each type

4.3 수집 시스템 비교

표 6은 데이터 수집에 이용된 Fitbit, Gear S3, Fitmeter의 수집기의 특징 및 장단점을 비교한다. Fitbit의 경우 RESTful API를 이용하여 데이터를 얻을 수 있으며 URL형식으로 데이터를 요청하기 때문에 사용자가 어떤 데이터를 얻을 수 있는지 쉽게 알 수 있다. 하지만 Fitbit의 경우 기기와 블루투스로 연결되어 있는 스마트폰을 통해 Fitbit 서버에 약 15분 간격으로 데이터 전송 및 동기화 하므로 사용자가 실시간 데이터 수집보다는 최장 15분 전의 데이터를 얻게 된다. 또한 스마트워치 하나당 데이터를 얻을 수 있는 접속 코드를 얻어야 데이터를 수집할 수 있기 때문에 데이터 수집에 어려움이 생길가능성이 존재한다.

Comparison by collection systems

반면 Gear S3의 경우 Tizen SDK를 이용해 데이터를 얻을 수 있는 앱을 만들 수 있다. 이 경우 Gear S3의 경우 실시간으로 기기에서 직접 데이터를 얻을 수 있으며, 사용자의 편의에 맞춰 수집기를 만들 수 있다는 장점을 지닌다. 그러나 Gear S3의 경우 기기의 운영체제 특성상 Fitbit에 비해 수집기를 구현하기가 어렵다.

마지막으로 Fitmeter의 경우 제조사에서 제공해주는 데이터 추출 프로그램인 Fitmeter Manger을 이용하고, 앞의 두 플랫폼보다 더 세세한 단위인 1/32초로 샘플링된 3축 가속도의 측정이 가능하다. Fitmeter의 경우는 수집 프로그램을 제공해주기 때문에 사용자가 별도의 수집기를 제작할 필요는 없고, 최대 2일간의 데이터를 기기 안에 저장해 둘 수 있다. 하지만 데이터 수집을 위해선 2일마다 한번씩 수동적으로 사용자의 컴퓨터에 스마트워치를 연결시켜 데이터를 얻어내야 한다. 또한 앞서 설명한 Gear S3와 Fitbit보다 수집할 수 있는 데이터의 종류가 활동량과 3축가속도 2개밖에 없음으로 다양한 데이터를 수집할 수 없다는 단점이 존재한다.


Ⅴ. 결론

이 연구를 통해 이기종 스마트워치에서 생성되는 라이프로그를 수집하고 저장할 수 있는 데이터베이스 모델을 제안하였다. 특히 제안하는 데이터베이스 모델은 저장하는 파일의 형식이나 데이터 유형이 다른 문제를 통합해서 관리할 수 있는 방안을 제시한다. 이후 이기종 스마트워치로부터 수집된 각기 다른 종류의 라이프로그를 통합하여 저장할 수 있는 시스템을 구현하였으며, 평가를 통해 제안 모델이 비교 대상으로 정의된 모델들에 비해 높은 확장성을 보임을 확인하였다. 또한 스마트워치별 수집기들의 비교를 통해 각 플랫폼들의 사용 목적에 따른 장단점을 판별하였다. 제안 데이터베이스 모델은 헬스케어 뿐만 아니라 센서 데이터를 저장할 수 있는 다양한 사물인터넷 산업 분야에서 사용이 가능할 것으로 기대할 수 있다.

Acknowledgments

이 논문은 2018학년도 군산대학교 신임교수 연구비 지원에 의하여 연구되었음

References

  • S. Waltzer, "Global Smartwatch Revenue and ASP by Vendor by Price Tier : Q2 2017", Report, Strategy Analytics, Aug), (2017.
  • R. Rawassizadeh, M. Tomitsch, K. Wac, and A. M. Tjoa, "UbiqLog: A generic mobile phone-based lifelog framework", Personal and Ubiquitous Computing, 17(4), p621-637, Apr), (2012. [https://doi.org/10.1007/s00779-012-0511-8]
  • J. Ji, S. Kwon, M. G. Kim, and S. Lee, "Activity Classification Method for User Movement using Wearable Device", Proc. the KIIT Fall Conference 2017, p318-319, Dec), (2017.
  • M. Han, and S. Lee, "Smartphone based Moving Activity Recognition using Accelerometer and GPS", Proc. the KIISE Korea Computer Congress 2014, p356-359, Jun), (2014.
  • F. Attal, S. Mohammed, M. Dedabrishvili, F. Chamroukhi, L. Oukhellou, and Y. Amirat, "Physical Human Activity Recognition Using Wearable Sensors", Sensors, 15(12), p31314-31338, Dec), (2015. [https://doi.org/10.3390/s151229858]
  • F. de Arriba-Perez, M. Caeiro-Rodriguez, and J. M. Santos-Gago, "Collection and Processing of Data from Wrist Wearable Devices in Heterogeneous and Multiple-User Scenarios", Sensors, 16(9), p1-31, Sep), (2016. [https://doi.org/10.3390/s16091538]
  • J. Kim, H. Lee, and K. Kim, "Database Design for Efficient Processing of Large-Scale Sensor Data", Proc. the KIISE Winter Conf, p244-246, Dec), (2015.
  • D. Choi, B. Kim, I. Bae, Y. Kwak, and S. Song, "Spark based Distributed Processing Method for Sharing Big Traffic Data in Realtime", Journal of KIIT, 14(2), p107-114, Feb), (2016. [https://doi.org/10.14801/jkiit.2016.14.2.107]
  • D. Y. Kim, Y. W. Kim, J. H. Lee, S. J. Kim, and K. I. Kim, "Developing health data collection platform for Internet of Things and wearable device with Fast Healthcare Interoperability Resources", Proc. the KIISE Winter Conf. 2016, Pyeongchang, Korea, p1706-1708, Dec), (2016.
  • S. I. Hong, J. H. Lim, E. J. Jo, H. R. Cho, G. S. Son, C. H. Lin, and Y. W. Kim, "The Environment Information Database Storage Program Design based on Android Platform using Multi Sensor", Proc. IEIE Fall Conference 2013, p911-914, Nov), (2013.
  • J. H. Lee, and H. W. Suh, "Design of a Plant Life Cycle Data Management System for Plant Operation and Maintenance", Journal of the KIIE, 42(3), p241-248, Jun), (2016.
  • P. Maheshwari, "A Model-Based Sensor Database for Internet of Things", A Master’s Thesis, University of Maiami, Dec), (2016.
  • N. Tsiftes, and A. Dunkels, "A Database in Every Sensor", Proc. 9th ACM Conference on Embedded Networked Sensor Systems, Seattle, USA, p316-332, Nov), (2011.
  • K. Kim, S. Kim, and S. Lee, "Lifelog Collection System for Heterogeneous Smart Watch", Proc. the KIIT Summer Conference 2018, p249-251, Jun), (2018.
저자소개
권승원 (Seungwon Kwon)

2017년 : 군산대학교 소프트웨어융합공학과(학사)

관심분야 : 빅데이터, 데이터베이스 사물인터넷, 데이터마이닝, 응용시스템개발

이석훈 (Sukhoon Lee)

2009년 : 고려대학교 전자및정보공학부(학사)

2011년 : 고려대학교 컴퓨터·전파통신공학과(공학석사)

2016년 : 고려대학교 컴퓨터·전파통신공학과(공학박사)

2016년 3월 ~ 2017년 3월 : 아주대학교 의료정보학과 연구강사

2017년 4월 ~ 현재 : 군산대학교 소프트웨어융합공학과 조교수

관심분야 : 사물인터넷, 메타데이터, 센서 레지스트리, 시맨틱 웹, 경로 예측

Fig. 1.

Fig. 1.
Architecture of Fitbit lifelog collector

Fig. 2.

Fig. 2.
Architecture of Gear S3 and Fitmeter lifelog collector

Fig. 3.

Fig. 3.
Implementation devices and data types

Fig. 4.

Fig. 4.
Stored Fitbit lifelog

Fig. 5.

Fig. 5.
Stored Fitmeter lifelog

Fig. 6.

Fig. 6.
Stored Gear S3 lifelog

Fig. 7.

Fig. 7.
Types of database schema

Table 1.

Proposed database model schema

column description datatype
userid user identifier char
timestamp measured time of data datetime
uom unit of measure varchar
devicetype model name of device varchar
datatype datatype of the value varchar
value measured value float

Table 2.

Implementation environments

device feature spec
Server CPU
RAM
OS
database
Intel Xeon E5-2620
DDR4 128GB
Windows Server 2016
SQL Server 2017
Blaze language Python 3.6
Fitmeter collection program Fitmeter manager
Gear S3 language Tizen 3.0, Java 1.8

Table 3.

Extension example to add smartwatch by each type

(type) task description
(All types)
metadata definition
- devicetype : Alta
(Type 2)
table creation
CREATE TABLE newtype2_tb (
userid char,
timestamp datetime,
uom varchar,
devcietype varchar,
steps float,
x float,
y float,
z float );

Table 4.

Extension example to add illuminometer by each type

(type) task description
(Type 1, Proposed)
metadata definition
- uom : lx
(Type 1)
table creation
CREATE TABLE illum_tb (
userid char,
timestamp datetime,
uom varchar,
devcietype varchar,
value float
);
(Type 1)
sourcecode revision
- development of new INSERT query
(Type 2)
coulum addition
ALTER TABLE type2_tb ADD illumination float NULL;
(Type 2)
sourcecode extention
- revision of INSERT query
(Proposed)
metadata definition
datatype : illumination

Table 5.

Evaluation of extension cost by each type

type device extension feature extension
Type 1 model low high
Type 2 model high medium
Proposed model low low

Table 6.

Comparison by collection systems

device collection method type of sensors real-time collection duration
Fitbit RESTful API hr, steps, gps, sleep support (15min. delay) 1sec. or 1min.
Gear S3 SDK hr, steps, gps, 3dacc support unfixed
Fitmeter Fitmeter Manger 3dacc, activity not support 1/32sec. ∼ 60sec.