Home

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

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

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

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

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

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

이 절에서는 선행 연구[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

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

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

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

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

Fig. 3. 
Implementation devices and data types

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

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

그림 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

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

평가를 위하여 센서 데이터를 저장할 수 있는 다양한 유형의 데이터베이스 모델을 비교 대상으로 선정하고 이 논문에서 제안하는 시스템에 유사하도록 모델링한다. 그림 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 워치와 같은 새로운 플랫폼을 이용할 경우 새로운 수집기를 개발해야 한다. 새로운 수집기의 개발은 높은 개발비용이 요구되지만 세 유형 모두 동일하게 적용되는 사항이다.

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

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

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

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

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

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

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

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