oneM2M 기반 노인 건강 관리 플랫폼 구현

2-1 Bluetooth

블루투스는 1994년에 에릭슨이 최초로 개발한 디지털 통신 기기를 위한 개인 근거리 무선통신 산업 표준으로[3], 수 미터에서 수십 미터 정도의 거리를 둔 디바이스 사이에서 간단한 정보를 교환하는 데 사용한다. 이때 사용되는 무선은 신호는 ISM(industrial, scientific and medical) 대역인 2.45GHz이다. 버전 1.1과 1.2의 속도는 723.1Kbps이고, 버전 2.0에서는 EDR(enhanced data rate)에 의해 2.1Mbps의 속도를 낼 수 있다. 최근 버전 3.0, 4.0의 속도는 24Mbps 정도로 약 12 배정도 빨라졌다. 블루투스는 RS-232나 유선 USB 등의 유선 연결이 곤란하거나 번거로운 상황에서 편리하고 효율적인 통신 수단이 된다.

2-2 oneM2M

M2M(Machine to Machine) [4]은 이름 그대로 사람이 직접 관여하지 않는 상태에서 지능화된 기기들이 사람을 대신해 통신의 양쪽 모두를 맡고 있는 기술을 의미한다. 즉, 센서 등을 통해 수집된 데이터를 다른 디바이스나 기기 등에 전달하기 위한 통신을 의미하며 일반적으로 사람이 접근하기 힘든 지역의 원격제어나 위험 품목의 상시 검시 등의 영역에 적용된다.

다양한 센서에서 수집되는 데이터를 M2M 방식으로 단일 서버에서 수집하기 위해서는 IoT 디바이스 관리에 대한 표준화가 필요한데, 이를 위해 설립된 기구 중 하나가 oneM2M [5]이다. oneM2M은 폐쇄적으로 운영되는 플랫폼의 구조를 벗어나 응용 서비스 인프라 환경을 통합하여 공유하고, IoT 공동서비스 플랫폼 개발을 위해 발족한 사실상의 표준화 단체이다.

oneM2M은 IoT 디바이스 혹은 게이트웨이와 네트워킹을 형성하여 장치 관리, 서비스 관리 등의 기능을 제공한다. 또한, 다양한 기존 M2M 서비스들이 표준 REST(Representational State Transfer) API를 통해 통합될 수 있다. 표 1은 여러 가지 oneM2M 구현체들의 장·단점과 특징에 대한 비교이고, 이들의 기본 구조는 그림 1과 같다.

Table 1.

Comparison of oneM2M Implementations

Fig. 1.

Structure of oneM2M [6]

2-3 OAuth 2.0

OAuth 2.0 [7]은 다양한 플랫폼 환경에서 권한을 부여하는 산업 표준프로토콜로서, Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials 등 4개의 인증 방법을 지원한다. OAuth 2.0은 보안을 철저하게 보장하지만, 그 절차가 복잡하다. 또한, 암호화가 필요 없고 HTTPS를 사용하며 HMAC(hash based message authentication code)를 사용하지 않는다.

2-4 건강관리 시스템

건강관리 시스템의 시작은 스마트폰 활용 중심으로 이루어졌는데, 스마트폰 자체에 탑재된 가속도 센서에 의한 운동량 측정이나 식사량 등 수동 입력 데이터를 데이터베이스 기반 단순 서버에 전송하고, 이를 의사나 간호사가 웹으로 접근할 수 있는 시스템 수준이다[8]. 이런 유형에서는 IoMT 디바이스 관리에 관심이 크지 않다. [9]에서는 개인별 팔목 센서로 혈압, 심박, 체온을 측정하여 스마트폰을 거쳐 단순 서버에 저장한 후, 이로부터 환자 상태를 예측하는 시스템 모델을 제안하는데, 이 역시 다양한 생체 신호 센서 디바이스를 지원하는 대규모 공공 건강관리 플랫폼과는 거리가 있다.

노인 건강관리를 위한 일차적 요소는 현실적으로 착용과 휴대가 가능하면서도 정확도가 높은 웨어러블 센서의 개발에 있는데[10], 웨어러블 심전도, 산소 포화도, 심박, 혈압 센서 등의 가능성을 단순 데이터베이스 기반 서버를 이용하여 검증하는 연구들이 있다[11-13]. 이와 같은 연구들의 목적과는 달리, 본 논문과의 관련성이 높은 대규모 건강 데이터 수집 및 관리 플랫폼 구현에 목적을 둔 연구는 의외로 많지 않다. [14]에서 다양한 IoT 디바이스들의 통신 및 관리를 표준화하는 oneM2M을 적용하여 디바이스에 대한 CRUDN(create, retrieve, update, delete, notify)을 실현하는 성과를 보이는데, 사용자 인증 등의 보안이나 대규모 데이터베이스 측면은 다루지 않는다. 본 연구에서는 이를 바탕으로 보안과 데이터베이스, 그리고 웹 서비스를 망라하는 통합 건강 모니터링 플랫폼을 구현한다.

3-1 IOT 플랫폼 MEDBIZ

이 연구에서는 표 1의 oneM2M 구현체 중 Mobius[15]를 기반으로 의료데이터 연동 부분을 보강하여 전체적인 데이터 흐름이 그림 2와 같은 IoT 플랫폼을 구현하고 이를 MEDBIZ라 명명한다.

Fig. 2.

Data Flow Diagram of the MEDBIZ-based Platform

MEDBIZ는 IoMT로부터 데이터를 수집하고 수집된 데이터를 자체 데이터베이스에 저장한 다음, 최종 데이터베이스 구축 및 데이터의 영속성을 위해 메시지 큐 Kafka로 전달한다. Kafka는 전달 받은 데이터를 구현 모듈 Collector에 전송하고, Collector는 데이터베이스 MongoDB에 저장한다. MongoDB에 저장된 데이터는 MEDBIZ를 거쳐 웹 서비스 등 다양한 모니터링 어플리케이션에게 오픈 API를 제공한다.

1) 하드웨어

MEDBIZ를 포함한 플랫폼 전체를 구동하는 하드웨어는 표 2의 호스트 시스템으로부터 생성한 표 3의 가상 기계와 같다.

Table 2.

Hardware Specifications of the Host System

Table 3.

Hardware Specifications of the Virtual Machine for MEDBIZ

3-2 디바이스 연동 및 데이터 표준화

이 연구의 구현 플랫폼 MEDBIZ는 노인의 생체 신호 모니터링을 위해 다양한 IoMT 디바이스를 사용하여 운동량, 심박수, 혈압, 혈당, 체온 등의 데이터를 oenM2M API를 통해 수집한다.

2) 모바일 게이트웨이를 통한 간접 수집

Bluetooth 통신을 지원하는 디바이스는 그림 3과 같이 스마트폰 기반으로 구현된 모바일 게이트웨이로 전송하도록 한다. 그림 4의 모바일 게이트웨이는 수신한 데이터를 oneM2M 표준프로토콜을 사용하여 MEDBIZ로 전송하고, oneM2M 표준으로의 변환, 사용자의 서비스 신청을 위한 인증, 측정 결괏값 확인 등의 다양한 부가 기능을 제공한다.

Fig. 3.

Data Collection Flow using Bluetooth

Fig. 4.

Mobile Gateway App

3) 브로커 애플리케이션을 통한 간접 수집

Fitbit사의 걸음마 측정 스마트밴드와 같이 데이터를 전송하는 서버가 자체적으로 고정된 경우에는 그림 5와 같이 해당 서버의 전용 API를 사용하여 데이터를 내려받은 후 이를 oneM2M API를 호출하여 MEDBIZ로 전송하는 브로커 애플리케이션을 구현하여 수집한다.

Fig. 5.

Data Collection Flow using Fitbit API

4) 데이터 표준화

Mobius로 수집된 데이터는 Collector 모듈의 ETL(Extract, Transform, Load) 과정에서 개인건강기기(PHD: personmal health device) 표준인 표 4의 IEEE 11073 표준 의료데이터 형태에 따라 변환되어 MongoDB에 저장된다.

Table 4.

IEEE Personal Health Device Standards

3-3 사용자 인증

MEDBIZ 플랫폼에서 사용자 인증을 OAuth 2.0 기반으로 일원화하기 위해 OAuth 2.0 인증 방식을 사용한다. 그중 하나인 Implicit 방식은 인증 페이지 요청(Redirect URL 및 OAuth Client ID 전달), 플랫폼 로그인을 위한 ID/Password 입력, Authorization Code 확인 및 AccessToken 요청(Redirect URL 및 OAuth Client ID AccessToken 발급 완료) 등의 기능을 수행한다. Kafka와 마찬가지로 OAuth도 도커에 의해 자동 설치되도록 도커 컴포즈를 설정하고, OAuth 2.0을 위한 설정했다.

3-4 모니터링 웹 서비스

oneM2M 서버로 전송되어 데이터베이스에 저장된 데이터에 대하여 언제 어디서나 접근할 수 있도록 하는 웹 서비스를 구현한다. 노인 건강 모니터링 웹 서비스는 보편적으로 적용되는 메뉴 구조 제시를 통해 학습성의 강화와 콘텐츠에 대한 정확한 인지가 가능한 UI 설계에 중점을 두었다. 즉, 건강관리 메뉴 및 내비게이션을 단순화하여 명확하게 보이도록 하고, 핵심 콘텐츠, 부가 콘텐츠, 생체 신호 정보제공 콘텐츠, 그리고 서비스 제공 콘텐츠 등의 적절한 배치를 고려하였다. 모니터링 웹 서비스의 일부 모습을 그림 6에 보였다.

Fig. 6.

Monitoring Web Service

3-5 데이터 변환

모바일 게이트웨이는 생체신호측정 디바이스에서 그림 7 형태의 측정 데이터를 전달받아 이를 MEDBIZ 플랫폼에서 수신할 수 있도록 그림 8의 oneM2M 표준 포맷으로 변환하여 전송한다. oneM2M으로 변환된 데이터는 Collector 모듈에서 개인 건강데이터로 변환된다. 그림9는 그림 8의 systolic 항목이 개인 건강데이터 포맷으로 변환된 부분의 모습이다. 위와 같이 생체신호측정 디바이스에서 수집된 데이터는 모바일 게이트웨이에서 MongoDB까지 총 2회의 변환을 거쳐 저장되고, 저장된 데이터는 개인 건강관리를 위한 모니터링 웹서비스에 활용된다.

Fig. 7.

Data Type of Biosignal Devices

Fig. 8.

Data Converted to oneM2M Standard Format

Fig. 9.

Data Converted to Personal Health Data Format

4-1 데이터 무결성

건강관리 플랫폼 MEDBIZ의 디바이스 연동 과정에서의 무결성 검증을 위해 혈압, 혈당, 체온, 운동량 등 4가지 데이터를 표 5의 실제 생체 신호 측정 디바이스로부터 수집하고, 디바이스의 표시 내용과 모바일 게이트웨이에서 수신받은 데이터를 비교한다. 그림 10은 체온계와 혈압계의 실제 측정된 데이터와 수신된 데이터를 비교하는 모습인데 데이터가 불일치하는 경우는 발견되지 않았다. 모바일 게이트웨이와 최종 MongoDB 사이의 데이터 무결성은 JMeter를 이용하여 수집 API를 5000, 10000, 15000번씩 각각 동시 호출하도록 한 후, 입력했던 가상 혈압 데이터와 MongDB의 내용을 비교한다. 그 결과, 세 가지 경우 데이터의 불일치 사례가 발견되지 않았다.

Table 5.

Biosignal Devices for Data Integrity Test

Fig. 10.

Process of Data Integrity Test

4-2 데이터 처리 성능

데이터 처리 성능은 다수의 디바이스를 사용하는 다수의 사용자 데이터를 동시에 처리하는 데 중요한 요소이다. 현재 서비스되는 건강관리 플랫폼은 대부분 기업의 의료기기 한 종류를 지원하는 서비스 형태 또는 기업 전용 프로토콜을 지원하는 형태의 건강관리 서비스이다. 따라서 기존에 동시에 한 종류의 의료기기에서 수집되는 성능을 테스트하기보다는 구현된 플랫폼 MEDBIZ의 성능 측정을 위해 다수의 클라이언트에서 발생하는 데이터를 동시에 수집하는 성능을 테스트한다. 무결성 테스트에서와 마찬가지로 JMeter를 활용하여 데이터 수집 API에 대하여 각각 5000, 10000, 15000번의 동시 호출 테스트를 실시한다. 건강관리 플랫폼의 데이터 수집 API를 처리하는 서버의 하드웨어는 표 2 및 표 3에서 언급한 바와 같다.

테스트 결과는 표 6 및 그림 11과 같다. 이 표와 그림으로부터 5000회 동시 호출까지는 데이터 손실이 없고, 이후 동시 호출 횟수가 증가할수록 손실률이 증가함을 볼 수 있다. 전체 인구 중 고령 인구의 비율은 지역별로 다르며, 전국 평균은 16.7%이다[16]. 생체 신호 측정이 동시에 5,000회가 발생할 확률은 희박하다는걸 고려하여 사용자 중 10%만 동시에 사용한다고 가정할 경우 약 20만 명 규모의 중소 도시의 약 3만 명에 해당하는 고령 인구를 충분히 감당할 수 있는 수준이다.

Table 6.

Results of Data Processing Performance Test

Fig. 11.

Trend of Data Loss Rate