Lecture/CAP/2011/TheWatcher

From MCLab
Jump to: navigation, search

Contents

The Watcher Final Reports

머리말

  • 본 Wiki 페이지는 '정보통신종합설계2' 프로젝트를 통해 개발되는 The Watcher에 대해 기술한 것이다. The Watcher 시스템은 크게 Zigbee 노드와 Bio 센서 모듈, 스마트폰을 통한 어플리케이션 그리고 이 둘을 중계하는 The Watcher 서버로 구성된다. 본 문서는 이 구성요소들을 위하여 The Watcher 시스템의 개요, 개발 동향 및 사업 계획, 시스템 요구사항 분석 및 제한사항, The Watcher 설계 및 구현, 결론 및 향후 전망을 나누어 설명한다.

The Watcher 개요

  • 무선 센서 모듈 Zigbee의 Bio 센서 모듈을 무선 건강 관리 시스템에 이용하여 The Watcher를 사용하는 심장에 병이 있는 환자나 어르신의 심장의 상태를 실시간으로 체크하고, 이상 징후가 발견될 경우에 Push 기능을 사용하여 보호자에게 알림 메시지를 전달할 수 있는 시스템과 안드로이드 어플리케이션을 개발한다.


개발 동기 및 필요성

  • 심장질환은 누구도 예상하지 못하게 일어난다. 이러한 심장 질환은 갑작스런 돌연사로 이어진다. 가장 흔한 원인은 심장 자체에 산소와 영양분을 공급하는 관상동맥에 죽상반이라는 기름기가 끼고 혈전이 형성되어 발생하는 협심증 혹은 심근경색증이다. 특히 혈전으로 인하여 발생하는 심근경색증을 겪은 환자들은 평생 병원을 한 번도 가본 적이 없을 정도로 건강하였다가 하루 아침에 발병한다. 일단 심근경색증이 발병하게 되면 약 40%는 손 한 번 써 볼 틈없이 갑작스런 죽음에 이른다. 가장 큰 문제는 이런 협심증이나 혈전 같은 경우에 통증이 거의 없기 때문에 발견하기 힘들다.
  • 또한 심장질병이 발병했을 때는 빠른 응급처치만이 생명을 살릴 수 있는 유일한 방법이다. 따라서 The Watcher를 사용하는 대상은 심장에 관련된 수술을 받아 심장의 상태를 지속적으로 살펴봐야 하는 환자나 심장에 지병이 있어 심장이 좋지 않은 환자, 그리고 작은 활동으로도 많은 피로감을 느낄 수 있는 나이가 많은 어르신들이다.

목표

  • The Watcher를 통해 심장의 상태를 실시간으로 체크하고, 심장 박동이 급격히 변화를 보이게 되면 등록되어 있는 보호자에게 Push 알람 메시지를 전달하여 환자의 상태를 확인할 수 있게 하고, 만약 환자의 이상이 확인이 될 경우에 환자와 가장 가까운 병원의 위치를 보호자에게 제공하여 최대한 빨리 대처할 수 있게 한다.


Service11.jpg


  • 위의 그림은 The Watcher의 서비스 다이어그램을 표현한 것이다. The Watcher 시스템의 전체적인 구성은 Bio 모듈, The watcher server, Google Push Server ,smartphone, GPS 통신으로 이루어진다. 사용자의 심장을 체크할 수 있는 Bio 모듈은 사용자의 몸에 부착되어 있다. The watcher server는 사용자와 watcher의 ID, 전화번호, 심전도 데이터 값, Google Push Server 의 registration id 등을 관리하며 각각의 사용자와 watcher 에게 데이터를 전송하는 역할을 한다. Google Push Server user의 이상징후를 watcher에게 바로 알려줄 수 있는 역할을 한다. Smartphone은 사용자에게 측정된 심전도 수치를 알기 쉽게 가공하여 제공하며 이상증후 발생시 알림 메시지로 알려주는 역할을 한다. GPS는 사용자의 위치로 부터 가장 가까운 거리에 있는 응급시설의 위치를 알려주기 위해 사용된다.


Techdia.jpg


  • 위의 그림은 서비스 다이어그램을 기술적 블록 다이어그램으로 표현한 그림이다. 클라이언트와 서버 사이에는 HTTP 프로토콜을 이용한 3G 통신을 사용한다.

기대효과

  • The Watcher를 이용하여 위험한 환자의 보호자들이 환자들을 실시간으로 감시할 수 있다.
  • The Watcher의 사용자가 이상징후가 감지되었을 경우 보호자에게 알림 메시지를 전달하여 환자의 이상징후를 알 수 있도록 한다.
  • The Watcher의 사용자의 위치를 측정하여 지도에 표시해주고, 가장 가까운 대형병원을 같이 표시해준다.

USN 동향 분석 및 The Watcher 사업 계획

USN 기술 동향

BanNet.jpg


  • BAN 무선 센서 노드가 환자의 신체 표면 위나 가까이에 배치되거나 세포 안에 정적으로 임플랜트 되어 특정한 신체 데이터를 수집할 수 있게 해준다. 이러한 방식은 환자가 어디에 있든 관계없이 환자의 건강을 지속적으로 모니터링할 수 있도록 해준다. 감지되는 신호들은 EEG(뇌파전위 기록)나 EKG(심전도 기록), EMG(근전도 검사), 피부 온도, 피부 전도도 혹은 EOG(전기 안구도 기록)신호일 수 있다.
  • 시장분석 결과, BAN 디바이스에 대한 수요는 2011년 연간 1억 대에 달하게 될 것이며, 이러한 추세는 소비자의 건강 및 신체 단련용은 물론 환자 모니터링용의 웨어러블 디바이스 및 임플랜터블 디바이스에 의해 견인되었다고 예상한다.
  • BAN의 장점: 기존의 환자 모니터링 방법은 환자의 신체와 근처에 놓여 있는 전용 신호처리 장치 사이에 거추장스러운 와이어를 통해 연결되어 있는 생리학적 센서들로 구성되어 있다. 이 와이어들은 환자의 이동성과 편안함을 제약하며, 몇몇 연구에 따르면 병원내 감염의 원인도 될 수도 있다고 한다. 이와는 다르게 BAN은 무선 센서 노드를 이용하여 정보를 전달받게 되므로 환자의 편안함이 극대화되고 어느 장소에 있든 모니터링할 수 있게 된다.
  • BAN의 설계에 따르는 해결과제
  • 폼팩터: 무선 노드의 크기와 무게는 작고 가벼울수록 좋다. 그러나 이는 센서의 SNR, 잡음 면역성, 안테나 효율의 조건 등과 trade-off 관계가 형성되기 때문에 적절히 균형을 이루어 설계해야 한다.
  • 전력 및 전류 소모: 배터리 수명의 연장은 가장 큰 과제이다. 배터리를 빈번히 교체하거나 나중에 충전해야 한다면 바람직하지 못 한 노드의 설계가 될 것이다.
  • 신뢰성: 대부분의 데어터가 사람의 신체 정보이기 때문에 전송되는 정보의 신뢰성이 반드시 보장되어야 한다.
  • 보안성: 개인의 프라이버시인 신체의 민감한 데이터들을 전송해야 하기 때문에 보안 방법 또한 중요한 요소이다.
  • BAN 표준으로는 블루투스, 지그비, 와이파이 등의 여러 무선 표준들을 이용하지만 'The Watcher'는 ZigbeX-II 에서 지원하는 ZigBee 표준을 따른다. ZigBee 는 작은 데이터의 전송과 저전력 사용을 목적으로 사용된다.

현재의 심장 모니터 시스템

1. 건강 검진을 위한 심장 모니터 시스템 몸에 무선 센싱 노드를 부착하여 심장의 맥박 정보를 받아 건강 검진을 하는 시스템이다. 협심증이나 심근경색증을 검사하기 위해서는 몇 분의 검사가 아닌 몇 일동안 오래 검사를 해야하기 때문에 환자의 몸에 부착하여 오랜 시간동안 심장의 맥박 정보를 얻을 수 있게 하는 시스템이다. 단순히 건강 검진을 하기 위한 시스템이다.


Wireless.jpg


2. 안드로이드 병원 찾기 어플리케이션만 제공 자신의 안드로이드 모바일 기기의 위치를 GPS로 측정하여, 현재 위치에서 가장 가까운 곳의 병원 정보를 거리 순으로 표시해주는 어플리케이션이 많이 있다.


HospitalApp.jpg


3. 안드로이드 프로요 버젼부터 제공된 푸쉬 기능 사용 미흡. 위에서 보이듯이 건강검진을 위한 시스템은 단순히 건강 검진만 할 수 있는 기능일 뿐 위험한 상황에서는 알람메시지를 알려주는 등의 기능은 없다. 또한 심장 질환은 아주 짧은 시간으로 환자의 생명이 위험할 수 있는 질병이기 때문에 가장 가까운 곳에 연락은 빠르게 할 수 있는 것이 중요하다.

사업 계획

대상

  • 심장 질환으로 인하여 수술을 받은 환자
  • 평소에 심장이 좋지 않거나 심장 질환을 앓고 있는 환자
  • 나이가 많아 심장의 기능에 의심이 되는 어르신


사업 모델

  • The Watcher 서버와 관련된 시스템을 모두 구축해 놓고, 심장에 연결할 수 있는 노드를 사용자에 판매한다. 또한 주기적인 노드의 관리와 3G 이용요금등의 서비스를 제공하기 위해서 월정액 요금을 정해두어 징수한다. 이는 핸드폰 단말기를 판매하고, 매월 월 정액 요금을 내는 것과 같은 이치이다.
  • 또한 스마트폰 이용이 가능한 환자나 보호자에게는 스마트폰 어플리케이션을 별도로 제공하여 The Watcher만의 단말기가 아닌 스마트폰으로도 언제 어디서나 쉽게 환자의 상태를 알 수 있도록 한다.

The Watcher 시스템 요구사항 분석 및 제한사항

개요

목적

  • 본 부분은 무선 센서와 안드로이드 푸쉬 기능을 이용한 심장 모니터 시스템 및 어플리케이션 개발 프로젝트의 요구사항을 정의한 부분이다. 무선 센서 노드의 Bio 센서 모듈이 부착된 무선 센서를 사용하여 The Watcher를 사용하는 사용자의 맥박 정보를 실시간으로 확인, 저장 및 분석할 수 있는 시스템 구축과 재가공된 맥박 정보를 안드로이드 스마트폰으로 제공하는 어플리케이션 제작을 목표로 한다. 본 문서는 고객들이 요구하는 다양한 요구사항을 수집하여 요구사항을 도출하였고, 이를 기반으로 개발자가 고객의 요구사항을 만족시키기 위해 적용할 수 있는 시스템 요구사항을 도출하였다.
  • 이와 같이 고객 요구사항과 시스템 요구사항을 본 문서에 기술함으로써 향후 고객에게는 요구 사항의 반영 여부를 확인시키고, 개발자에게는 고객 요구 사항의 파악 및 시스템 개발 방안을 결정하는 데 활용할 수 있도록 하는 것이 본 부분의 목적이다.
  • 본 부분은 이하 문서의 작성에서 기준 문서로 적용되며, 필요한 경우 이후의 다른 부분에서 인용 반복되어 기술될 것이다.


범위

  • 본 부분은 무선 센서 노드를 이용한 심장 모니터 시스템 개발 및 안드로이드 어플리케이션 개발 프로젝트에서 요구되는 일반 요구사항, 기능 요구사항, 성능 요구사항, 설계상 제약사항 및 시스템 속성에 대해 기술한다.
  • 본 부분은 기술 개발을 위한 구체적인 구현 방법에 대해서는 기술하지 않으나 고객 요구사항으로부터 시스템 또는 개발자 관점에서 기술적 용어를 사용하여 요구사항을 정의하며, 개발 과정의 기술적인 문제점을 고려하여 제한 조건, 가정 및 전제 조건을 반영하여 작성한다.
  • 본 부분은 구현 단계에서 구체적이고 현실적인 핵심 모듈 개발을 위하여 내용의 보완이 가능하며 수정 내용은 다른 부분에 반영되어야 한다.


개발 명칭

  • 본 부분은 무선 센서 노드의 Bio 센서 모듈을 이용한 심장 모니터 시스템과 안드로이드 어플리케이션을 이용하여 구축된 시스템과 어플리케이션의 명칭을 다음과 같이 명명한다.


  • The Watcher: <와쳐>라고 발음한다.
  • Zigbee: Zigbee는 Bluetooth의 고가격, 고전력 소비의 단점을 보완한 기술이다. Zigbee란 zig-zag로 날아 다니면서 다른 동료들에게 정보를 전달하는 Bee(벌)의 정보전달 체계를 착안하여 붙여진 명칭이며, 무선 리모콘, 무선 조명제어, 컴퓨터에서의 무선 키보드 및 무선 마우스, 홈오토메이션, 재고관리, 무선 센서네트워크 등에 주로 응용되는 기술이다.
  • Bio 센서: 심장 박동과 비부착식으로 체온을 측정할 수 있는 센서. 심장 박동은 좌심방과 우심방의 전압의 차이를 측정한다.


일반사항

연구개발 개요

  • Bio 센서 모듈을 부착한 무선 센서 노드와 안드로이드 어플리케이션을 이용한 심장 모니터 시스템 및 어플리케이션 개발은 센서 노드 및 센서 네트워크의 연결을 표준화된 환경에서 가능하게 하는 개방형 센서 네트워크 통신망 인프라에서 적용 될 수 있다. 또한 센서노드가 획득한 Bio 정보는 재가공되어 사용자의 심장 상태를 3G/4G 셀룰러 네트워크를 통해 안드로이드 모바일 기기로 전송해주기 때문에 심장의 이상 유무를 보호자가 쉽게 알 수 있으며, 사용자의 심장에 이상이 생길 경우에는 보호자에게 빠르게 연락을 취해 사전 예방 및 이상 상황에 대해 빠른 대처가 가능하다.


주요 기능

  • 각 사용자가 Bio 센서 모듈이 내장된 센서 노드를 신체에 부착하고 사용자의 안드로이드 모바일 기기에 Bio 정보를 수집, 재가공하여 표시해준다. 무선 센서 노드를 통해 수집한 정보는 사용자의 ID(노드의 식별번호), 심전도(ECG) 등이 포함된다. ECG 같은 정보는 매우 빠른 시간동안 민감하게 변하는 요소이므로 정보 수집 주기는 5초 이내로 설정하여 획득한다. 이는 시뮬레이션을 통해 조절하기로 한다. 수집된 Bio 정보를 재가공하여 사용자의 안드로이드 모바일에 표시해주고, 보호자의 모바일 기기에도 알려준다.
  • Bio 센서 모듈을 통해 측정한 정보를 바탕으로 각 개인의 신체 상태를 측정한다.
  • 사용자가 가지고 있는 안드로이드 모바일 기기에서 신체의 상태를 실시간으로 모니터링 한다.
  • 사용자의 심장이 이상이 있을 경우 안드로이드 모바일에서는 푸쉬 기능을 사용하여 보호자에 알람을 제공한다.
  • 보호자가 가지고 있는 안드로이드 모바일 기기에서 사용자의 건강 상태를 체크하고 사용자가 위험할 경우에 알람을 푸쉬받는다.


요구사항 구성설계

  • 무선 센서 노드와 안드로이드 어플리케이션을 이용한 심장 모니터 시스템 및 어플리케이션 개발 프로젝트는 크게 사용자 요구사항과 시스템 요구사항으로 구분된다. 사용자 요구사항은 서비스 시나리오부터 유추되는 일반 요구사항으로 작성되며, 시스템 요구사항은 센서 노드의 정확성 및 Bio 센서 모듈의 센싱 정보 재가공 및 안드로이드 어플리케이션 개발의 기능 관련 요구사항으로 작성된다.


  • 요구사항 번호 체계

Orgword1.jpg


서비스 시나리오

Case 1. 고객 1과 보호자 1이 The Watcher Application을 처음 사용하는 경우

  1. 고객 1이 몸에 BIO센서 노드를 부착한다.
  2. 고객 1 과 보호자 1이 The Watcher Application을 실행한다.
  3. 고객 1과 보호자 1은 The Watcher Application을 처음 사용하기 때문에 사용자 및 보호자 정보를 등록한다. 사용자 정보는 이름, 휴대폰 번호, 주소 등이다.
  4. 고객 1과 보호자 1의 사용자 정보의 등록이 완료되면 The Watcher Application이 실행된다.


Case 2. 일반적으로 The Watcher Application을 사용하는 경우

  • 고객 1은 심장 질환이 있는 사람, 또는 심장 질환이 있는 사람, 또는 심장 질환으로 인하여 심장 수술을 받아 꾸준한 관리가 필요한 환자, 혹은 심장이 좋지 않은 나이가 많은 어르신으로 주기적인 확인이 필요하다고 가정한다. - 사용자 등록이후 고객 1이 사용하는 경우
  1. 고객 1이 The Watcher Application을 실행한다.
  2. 고객 1이 주기적으로 자신의 상태를 쉽게 알 수 있고, 보호자에게 알려주기 위해 알람 시간을 설정한다.
  3. 고객 1은 주기적(짧은 시간)으로 전송되는 자신의 맥박 정보를 확인한다.
  4. 고객 1은 무선 노드를 통해 들어오는 맥박 정보에 이상이 있을 경우에 푸시 메세지를 전달할 수 있도록 실시간 모니터링 기능을 활성화한다. 이 기능을 활성화해야만 맥박 정보에 이상이 있을 때 긴급 알람 메세지(Push 메세지)를 전송한다.
  5. 고객 1은 알람, 실시간 모니터링 기능 설정을 모두 마친 후, The Watcher Application을 종료한다. 종료된 The Watcher Application은 백그라운드로 서비스되어 맥박 정보를 주기적(수 분)으로 체크한다.


Case 3. 고객 1 이 실시간 모니터링 기능을 활성화한 이후에 맥박 정보가 이상이 생겼을 경우

  1. 고객 1 의 맥박 정보가 정상 범위를 벗어나는 수치가 지속적으로 측정된다.
  2. 일정 시간동안 (짧은 시간, 수 초) 맥박 정보가 정상 범위를 벗어날 경우 The Watcher Application은 보호자 1 에게 긴급 알람 메시지를 전송한다.
  3. 보호자 1 에게 Push를 보낸 후, 계속해서 맥박 정보가 정상 범위에서 벗어날 경우 The Watcher Application은 GPS 위치 정보를 기반으로 고객 1 과 가장 가까운 응급 처리 기관에 긴급 알람 메시지를 전송한다.
  4. 응급 처리 기관에 긴급 알람 메시지를 전송하면 고객 1 의 맥박 정보 변화는 설정한 알람 주기가 아닌 실시간으로 전송된다.
  5. 보호자 1 과 가까운 응급 처리 기관은 빠르게 대처하여 고객 1 에게 간다.


Case 4. 보호자 1 의 경우

  1. 보호자 1 은 The Watcher Application을 실행한다.
  2. 고객 1 의 The Watcher Application에 등록되어 고객 1 이 설정한 시간 주기로 고객 1의 맥박 정보를 수신한다.
  3. 보호자 1 은 The Watcher Application에 표시된 GPS 위치 정보로 고객 1 의 현재 위치를 파악한다.
  4. 보호자 1 은 The Watcher Application을 종료해도 백그라운드로 서비스되어 주기적으로 고객 1 의 맥박 정보를 수신 받는다.


The Watcher Data Flow Diagram

  • 위의 시나리오와 요구사항을 토대로 Data flow 다이어그램을 구성해보았다.


DataSequence.jpg

요구사항 및 제한사항

사용자 요구사항

  • 서비스 시나리오를 바탕으로 사용자 측면에서 요구사항을 도출한다. 도출된 사용자 요구사항을 통해 요소기술을 조사, 분석하여 시스템 개발에 필요한 기능 요소들을 추출할 수 있도록 한다.


Error creating thumbnail: Image type not supported

시스템 기능 요구사항

  • The Watcher 시스템은 사용자가 사용하는 사용자 노드, 사용자 및 보호자의 ID를 저장하여 관리하는 데이터베이스 서버, 안드로이드 모바일 어플리케이션 등의 서비스 객체 의 관리 기능과 서비스 처리 기능, Bio 센싱 정보 처리기능 및 성능을 고려하여 설계되어야 하며, 각 요구 사항은 센서 노드들을 구성하여 시스템을 통한 기능 및 성능이 테스트되어야 한다.


Error creating thumbnail: Image type not supported


시스템 구현의 제한사항

  • Zigbee Bio 센서 모듈과 서버간의 통신을 위해서 Zigbee에 셀룰러 통신 모듈이 탑재되어 The Watcher 서버와 통신을 해야한다. 하지만 우리가 가지고 있는 Zigbee 하드웨어는 Zigbee 통신만을 위하여 만들어진 제품이다. 따라서 몸에 부착한 Zigbee 노드와 Bio 센서 모듈은 셀룰러 통신이 가능하다고 가정한다.


  • 무선 센서 노드로부터 센싱되는 체온와 ECG(맥박) 값을 다음의 값이 정상 범위라고 제한한다.
  • 체온: 36.1 ~ 37.2 도
  • 맥박: 안정 상태에서 60 ~100 회, 극심한 운동을 할 경우 150 회.
  • 부정맥의 발견: 부정맥은 맥박이 불규칙하게 뛸 때 발생한다. 모든 사람들은 규칙적으로 심장박동이 뛴다. 개인별로 차이가 있지만 약 0.8초 ~ 1초 사이의 간격을 두고 일정하게 맥박이 뛴다. 하지만 부정맥이 의심이 되는 환자들은 불규칙한 맥박을 보이게 된다. 이는 ECG 그래프를 보고 판단할 수 있다. 부정맥을 측정하기 위해서 EWMA 방법을 사용한다.

The Watcher 설계 및 구현

ECG 분석

  • ECG 신호(HRV 신호라고도 한다.)는 사람에 따라 정상적이더라도 박동의 주기가 사람별로 다르다. 하지만 각 개인별로 일정한 주기를 가지고 심장박동이 뛴다. The Watcher에서는 이를 이용하여 ECG를 분석하고, 이상 징후(부정맥)에 대해서 판단할 수 있게 설계했다.
  • ECG 신호는 다음과 같이 해석할 수 있다.


ECGMethod.jpg


ECG의 시간 영역 분석

  • ECG 신호의 시간영역은 다음과 같은 요소로 분석할 수 있다.
  • Mean HRV(Mean HRT) : 평균 분당심박동수, 50이하 서맥 / 정상 60~90 / 90이상 빈맥
  • SDNN(CLU or SDRR) : RR간격의 표준편차
  • RMS-SD: RR간격의 차이를 제곱한 값의 평균의 제곱근, 10이하 심장질환의 발병위험


Times.png


  • 위의 요소로 ECG를 시간 영역에서 분석하면 다음과 같은 징후를 판정할 수 있다.
  • 빈맥(Tachycardia): 스트레스, 불안, 초조한 상태 / 갑상선 기능항진, 탈수 → 자율신경계 불균형, 심기능 문제 / 알코올, 수면부족, 급격한 운동, 카페인, 니코틴 등이 원인 / 동성 빈맥(100~140회), 심방 조동(150회), 심실상성 빈맥(160회 이상)
  • 서맥(Bradycardia): 운동선수 / 피로, 만성스트레스,갑상선 기능 저하 / 저 체온증, 급성 심근경색, 두통, 현기증, 실신
  • SDNN감소: 자율신경계 항상성 저하, Stress에 대한 저항력 저하
  • SDNN 현저히 감소: 심근경색, 협심증, 심실성 부정맥, 급성 심정지

ECG의 주파수 영역 분석

  • ECG 신호의 주파수 영역을 분석하면 3부분의 주파수로 나누어 확인할 수 있다.
  • VLF(Very Low Frequency): 0.0033~0.04Hz의 주파수 대역 / 체온조절, 혈관운동 / 5 분 측정에선 임상적 가치 적음
  • LF(Low Frequency): 0.04~0.15Hz의 주파수 대역
  • HF(High Frequency): 0.15~0.4Hz의 주파수 대역 / 부교감신경계의 활동에 대한 지표 / 호흡활동과 관련


Freqs.png


  • 위의 3 부분의 주파수를 분석하면 다음과 같은 이상 징후를 분석할 수 있다.
  • VLF 증가: 수면무호흡증(OSAS) 환자의 경우 호흡곤란, 저 산소혈증의 현상의 증가 / 산소교환이 결여 / 부정맥 사와 관련
  • LF 저하: 생체 에너지 소실 → 편두통, 두통환자에게서 높게 나타남 / 급격한 저하: 심폐기능 노화, 만성 스트레스
  • LF 증가: 호흡이 느리거나 깊은 경우(복식호흡 등)

ECG 분석을 통해 판단할 수 있는 대표적 이상징후

  • The Watcher 시스템에서는 주파수 영역에서 판단하는 어려운 알고리즘으로 분석하지 않고, 시간 영역에서 간단한 알고리즘을 사용하여 환자의 이상상태를 쉽게 알아낸다. 왜냐하면 주파수 영역에서 판단하기 위해서는 FFT 알고리즘을 사용하여 시간 영역으로 전달되는 환자의 ECG 값을 주파수 영역으로 변환해야 한다. 하지만 이것을 하기 위해서는 1분 정도의 짧은 데이터가 아닌 최소 1시간에서 길게는 3일 정도의 누적된 ECG 데이터가 필요하다. 또한 이런 긴 데이터를 FFT 알고리즘을 적용하기 위해서는 굉장히 오랜 시간이 걸린다. 아무리 FFT 알고리즘이 신호처리 영역에서 가장 빠른 알고리즘이라고 하지만 몇 백만개 이상의 데이터를 처리하는데 있어서 모바일에서 처리하기는 쉽지 않을 것이라고 예상한다. 따라서 The Watcher에서 판단할 수 있는 대표적인 이상징후는 다음과 같다.
  • 빈맥과 서맥: 빈맥과 서맥은 심장박동수가 짧은 시간내에 급격하게 빠르게 뛰거나 느리게 뛸 때 이상징후를 검출해 낸다. The Watcher 시스템을 이용할 것이라고 예상하는 환자들은 심장에 평소에 이상이 있거나 나이가 많은 어르신들이기 때문에 심장 박동수에는 특별한 경우에는 급격한 변화를 예상할 수 없다. 급격한 변화가 있을 경우에는 환자에게 이상이 생겼을 것이라고 판단한다. 빈맥과 서맥은 이후에 소개될 심박수 계산 알고리즘을 이용하여 검출해내는 알고리즘을 구현했다.


Fasl.jpg


  • 부정맥: 아래 그림과 같이 부정맥은 심박이 일정한 규칙으로 뛰지 않고, 느리게 뛰다가 빠르게 뛰는 등 일정한 간격을 보이지 않는다. 한 두번 정도는 일반적인 사람에게 일어날 수도 있지만 이런 현상이 계속해서 반복되면 부정맥을 의심해봐야한다. 부정맥은 급사하는 경우도 간혹 있지만, 그 이전에 심장에 통증이 있거나 갑자기 쓰러진다는 등의 초기 증상이 있는 경우가 많기 때문에 부정맥이 의심이 되는 상황을 검출해내는 것이 중요하다. 이런 특징을 이용하여 부정맥 검출을 위한 알고리즘을 이후에 소개하겠다.


IrrBu.jpg


  • 동방결절: QRS파의 곡선이 서서히 상승하게 되고, 탈분극이 서서히 진행하여 정점이 둥글게 나타난다. 이는 실시간으로 검증할 수는 없고 심전도 검사를 마친 후에 표시된 그래프를 가지고 판단할 수 있다.
  • 방실결절: 동방결절의 곡선과 비슷하지만 탈분극이 더 빠르게 일어난다. 이는 동방결절과 마찬가지로 실시간으로 검사할 수는 없고 심전도 검사 이후에 심전도 그래프를 확인한 후 방실결절을 진단할 수 있다.


Doban.jpg


  • 심근경색: 비정삭적 T파, 비정상 ST파의 분절, 비정상적인 Q파가 심전도 그래프에서 나타난다.


Simgeun.jpg


  • 각종 폐질환: 우심방의 비대 및 확장으로 P파가 뾰족하게 나타나는 경우가 발생한다.

ECG 분석을 위한 The Watcher의 알고리즘

심박수 계산을 위한 알고리즘

  • 심박수를 계산하기 위한 알고리즘은 12개의 서큘러 큐를 사용하여 구현하였다.


Algorithm.jpg
Pickcount.jpg
  • 인간의 맥박은 분당 60 ~ 90회 정도 뛰는 것이 일반적으로 편안하고 정상적인 상태이다. 따라서 심박수를 계산하기 위해서는 1분을 간격으로 심박수를 계산한다. 5초를 간격으로 들어오는 Bio 센서 모듈에서 들어오는 ECG 값을 읽어서 The Watcher에서 설정한 Threshold값을 넘어갈 경우 심박수를 1번 더한다. 5초가 지난 이후에는 큐를 한 칸 이동한 후 반복하여 심박수 값을 계산한다. 모두 12번 계산을 하게 되면 1분의 계산이 완료가 되고, 13번째에는 다시 첫 번째 배열로 돌아가 심박수를 계산하게 된다. 이 때 계산되는 심박수는 초기화가 되는 것이 아니라 기존의 첫 번째 있던 심박수를 제외하고 다시 첫 번째 배열에 저장된다.

이상징후를 검출하기 위한 알고리즘

빈맥과 서맥 검출 알고리즘
  • 빈맥과 서맥을 판단하는 방법은 간단하다. Peak Count 알고리즘을 통해 계산된 BeatCount 값을 통해 빈맥과 서맥을 판단할 수 있다.


FSState.jpg


  • BeatCount를 계산하기 시작하여 60이상이 되었을 때 state를 1로 바꾼다. state 1은 이상징후가 발견되지 않는 정상적인 상태이다. 정상상태에서 beatCount가 150회 이상이 되면 빈맥으로 판단하여 환자의 상태를 확인하도록 push 메시지를 watcher에게 전송한다. 30회 이하가 될 경우에는 서맥으로 판단하여 빈맥과 마찬가지로 push 메시지를 watcher에게 전달한다.
부정맥 검출 알고리즘
  • 부정맥의 경우는 조금 복잡한 알고리즘이 적용된다.


Irregu.jpg


  • EWMA 방식을 사용하여 심장 박동의 주기를 계산하고, 계산된 심장박동 주기에서 많이 벗어나는 경우 Push 알람 기능을 통해 보호자에게 알람 메시지를 전달한다.


EWMA1.bmp


  • EWMA 계산 사용: 위의 식을 통해 EWMA 값을 얻을 수 있다. 위의 식을 적용하기 위해 두가지 사항을 결정해야 한다. 첫번쨰는 사람의 심장박동 주기의 초기값이고 두번째는 a값을 얼마로 지정할 것인가 이다. 첫 번째 사항은 일반적인 사람의 심장박동은 0.8초에서 1.0초 사이에 이루어진다는 것을 조사를 통해 파악했기 때문에 그 중간 값인 0.9 초로 설정했다. The Watcher에서는 150ms 주기로 10개의 데이터를 전송하기 때문에 60을 초기 값으로 설정하였다. 두번째 사항은 a값을 얼마로 지정한것인가 이다. a 값은 현재의 값을 얼마나 반영할것인가에 대한 척도 이며, Exponential Weighted이기 때문에 2의 자승으로 값을 설정해야한다. a 값이 크면 클수록 일반적인 심장 박동수가 아닌 개인적인 심장박동 주기를 반영하기 때문에 a 값을 7/8로 결정했다.

The Watcher Server 구성

  • The Watcher 서버는 크게 Zigbee 모듈 부분과 The Watcher Web Server + database Server 로 구성된다.


TheWatcherServer1.jpg


  • The Watcher Server의 개략적인 구성도는 위의 그림과 같다.


The Watcher Zigbee 통신

  • The Watcher에서 사용하는 Zigee 통신에는 크게 두 부분으로 나뉜다. 유저가 사용하는 Bio 센서 모듈 부분과 서버와 연결되어 있는 Base Station 부분으로 나뉜다.


Bio 센서 모듈

  • Zigbee의 Bio 센서 모듈은 ECG(심전도) 센서와 비접촉식 체온 센서를 탑재하고 있다. ECG 센서는 세 개의 도선을 통해 사람의 맥박을 측정하고, 환자의 심박 수 변화를 측정할 수 있다. 또한 체온 센서는 사용자의 체온을 비접촉 방식으로 측정하는 역할을 한다.


BioSensorModule.jpg


  • Bio 모듈을 이용하여 측정하는 방법은 위의 그림에 보이는 것처럼 3극을 이용하여 ECG 값을 측정한다. 자세히 말하면, R-ARM에 전극을 연결하여 심장의 좌측 상단에, L-ARM에 전극을 연결하여 심장의 우측 하단에, 그리고 R-LEG에 전극을 연결하여 복부 쪽에 부착을 한다. 몸에 전극을 모두 연결하면 R-ARM 과 L-ARM의 전위차이를 측정한 값이 Bio 센서 모듈로 측정된다. 15ms 마다 한 번씩 R-ARM과 L-ARM의 전위차이를 측정한다.


Error creating thumbnail: Image type not supported


  • Bio 센서 모듈이 작동하는 블록 다이어그램은 위의 그림과 같다. 기존 한백전자에서 판매되는 Kit인 USN Kit의 옵션 모듈이기 때문에 50pin Connector로 Zigbex 노드에 연결하여 Bio 센서 모듈을 통해 15ms마다 측정된 양 극의 전위 차 값이 Zigbex 노드의 Zigbee 통신을 이용하여 BaseStation으로 전송된다. Bio 센서 모듈을 얹은 Zigbee 노드로부터 BaseStation 노드까지 사용되는 메시지 프로토콜은 다음과 같다.


Bio 센서 모듈 메시지 프로토콜

  • Bio 센서 모듈을 사용하는 노드로부터 BaseStation 노드까지 전송되는 한백전자에서 정의한 Zigbex-II Serial 메시지 전송 프로토콜을 따른다. Zigbex-II에서 사용하는 프로토콜 중 data 부분을 Bio 센서 모듈에 정의된 패킷 형식으로 채워서 Zigbee 통신을 이용하여 BaseStation으로 전송한다. Bio 센서 모듈은 15ms마다 한 번씩 전위 차이를 측정하지만, 단 하나의 integer 값을 전달하기 위해서 아래 보이는 것과 같은 큰 헤더를 사용하는 것은 낭비이므로, 15ms 마다 한 번씩 측정되는 전위 차이 값을 10번 모아서 전송한다. 즉, 150ms마다 한 번씩 Bio 센서 모듈과 BaseStation 사이에 전송이 이루어진다.


MessageProtocol.jpg


  • 이 프로토콜은 Oscilloscope.h에 정의되어 있다.


Zigbex-II Serial Transfer Packet
  • 한백 전자에서 정의한 Zigbee 통신을 위한 패킷 프로토콜이다. Zigbex-II 하드웨어를 사용하여 Zigbee 통신을 할 경우에는 이 프로토콜로 데이터가 전송된다.
  • Head: 0x7E(Preamble)
  • Destination Address: 0xFFFF(Radio Frequency로 Braodcast)
  • Source Address: 전송하는 노드의 주소(0xXXXX 로 표현)
  • Length: 패킷의 총 길이
  • Group: 0x7D(Default)
  • Type(0x42: ACK가 필요 없는 사용자 패킷)
  • Data: OscopeMsg 구조체 형태로 저장되어 전송
  • CRC: CRC16 코드 사용.
  • Tail: 0x7E(Preamble)


Bio 센서 모듈 Data Packet
  • Zigbex-II 메시지 프로토콜의 Data 부분에 해당한다. Bio 센서 모듈에서 생성하고 Zigbex-II 프로토콜에 Envelop되어 BaseStation으로 전송된다.
  • Version: Node 소스의 버전, 소스가 업데이트될 때마다 Version이 하나씩 증가한다.
  • Interval: 15ms(Default)
  • Id: 현재 노드의 Id, 0 ~ 255까지 비어있는 Id에 자동으로 할당된다.
  • Count: Zigbex-II 프로토콜을 이용하여 BaseStation으로 전달된 패킷의 수
  • Reading: 15ms마다 측정된 전위 차이의 값, 총 10개를 모아서 한 번에 전송한다.


Bio 센서 모듈 Software

  • Bio 센서 모듈에 들어가는 Software(엄밀히 말하면 Firmware)는 아래의 그림과 같이 3개의 부분으로 나뉘어 진다.


BioModuleFirmware.jpg


  • 3개의 부분은 모두 OscilloscopeAppC.nc에서 정의되고 Wiring, Initailize되어 사용된다. OscilloscopeAppC.nc에서 초기화하고 OscilloscopeC.nc에서 실제로 프로그램을 실행하는 함수들이 구현되어 있다.


OscAppC.jpg


  • Radio Transfer 부분
  • AM 전송 방식을 사용하여 Radio Transfer를 한다. Sender와 Receiver, 그리고 메시지를 생성하는 .nc 코드로 구성되어 있다.
  • Node Process 부분
  • Bio 센서 모듈과 연결되어 있는 Zigbex-II 노드를 제어하는 부분이다. Timer를 작동하고, Led를 조작하는 .nc 코드로 구성되어 있다.
  • Heart Beat Sensor 부분
  • 양 극을 통해 전위 차이를 측정할 수 있는 부분을 초기화하고 제어하는 부분이다. BeatDeviceP.nc를 통해 방치를 초기화 하고, BeatC.nc와 AdcReadClientC.nc를 통해 전위차이를 계산하고 저장한다.


The Watcher BaseStation 노드

  • The Watcher 서버에 연결되어 있어서 Bio 센서 모듈과 통신하는 BaseStation 노드는 SerialForwarder.java 프로그램을 통해 Bio 센서 모듈로 부터 전송되는 Serial 패킷을 전송 받는다. 그리고 Oscilloscope.java 프로그램을 통해 The Watcher 서버에서도 환자의 현재 심전도 전위 차이의 값을 모니터할 수 있다.
  • 아래의 소스 코드는 Bio 센서 모듈로 부터 BaseStation에서 필요한 데이터를 Parsing하는 부분이다. BaseStation에서 필요한 데이터는 Zigbex-II 메시지 패킷 중에서 Data 부분만 필요로 하기 때문이다. 이 부분은 Bio 센서 모듈에서 매 150ms 마다 메시지 패킷이 전송되기 때문에 150ms 마다 불려지게 된다.


Osc java.jpg


BaseStation 데이터베이스 저장 알고리즘
  • Oscilloscope.java 소스 코드에서 수신되어지는 ECG 데이터를 분석, 재가공하여 이상 징후의 여부를 판단하여 The Watcher 데이터베이스 서버에 전송하게 된다. The Watcher 데이터베이스 서버로는 전송하는 것이 두 가지 방법이 있다.
  • 첫 번째로는 데이터베이스 서버에 5초 주기로 state 값을 전송한다. state 값은 비교적 빠른 시간안에 전송이 되어야만 하기 때문이다. 그리고 심박수를 계산하기 위한 알고리즘을 5초 주기로 계산을 수행하기 때문에 5초를 주기로 설정했다. 왜냐하면 state는 BeatCount의 변화에 영향이 있기 때문이다.


OSC 5sec.jpg


  • 두 번째로는 데이터베이스 서버 ECG 데이터를 1분 주기로 전송한다. 이 때 1분 동안 받아온 ECG 데이터는 약 4000개의 integer 값으로 이루어진다. 이는 Java String형으로 파싱되어 데이터베이스 서버에 저장되는데 String 객체 하나에는 최대 4KB의 데이터만 저장할 수 있는 구조이다. 따라서 Bio 센서 모듈로부터 오는 모든 ECG 데이터를 데이터베이스 서버에 전송하지 않고, 2번에 한 번 꼴로 데이터를 전송(총 2000여개), 데이터베이스 서버에 저장한다.


OSC 1min.jpg
The Watcher BaseStation Monitor
Osc program.jpg


  • Oscilloscope.java 프로그램을 실행할 경우 위의 그림과 같은 그래프를 그려주는 프로그램이 실행된다. 이 그래프는 Bio 센서 모듈로 부터 전송되는 Data 값들을 모두 그래프로 표시해주는 그래프이다. 그림에서 보이는 것처럼 QRS 파는 확실하게 측정이 되는 것을 볼 수 있지만, 다른 P파나 T파는 관측하기 힘들다. 이는 3극을 이용하여 ECG를 측정하기 때문인데 자세한 이유는 ECG 분석 부분에 있다.


The Watcher Database Server

DBSchema.jpg


  • 위 그림은 The Watcher 데이터베이스 스키마를 나타낸 그림이다. The Watcher의 데이터베이스는 MySQL을 기반으로 작성되어 있고, APMSETUP 7 프로그램을 사용하여 구현하였다.
  • 데이터 베이스는 크게 3부분으로 나뉠 수 있다.
  • Userinfo: The Watcher를 사용하는 환자의 정보를 저장한다. 이름과 전화번호, 주소와 같은 개인 정보를 등록하고, 현재 위치의 경도와 위도를 합쳐서 하나의 텍스트로 저장한다. 예를들어 '37.4243 128.34123'으로 위치 정보를 저장한다. 이 정보는 매 1분마다 환자의 안드로이드 디바이스에서 업데이트가 될 것이다. 마지막으로 C2DM 푸시 서비스를 사용하기위해 C2DM Registration ID를 The Watcher 데이터베이스 서버에 저장한다. 이는 The Wathcer 웹 서버에서 C2DM 푸시 메시지를 전송할 것이기 때문이다.
  • Watcherinfo: The Watcher의 환자를 관찰하는 보호자의 정보를 저장한다. 환자와 마찬가지로 이름, 전화번호, 주소와 같은 개인 정보를 등록하고, C2DM 푸시 메시지를 수신하기 위해 C2DM Registration ID를 저장한다.
  • beatinfo: The Watcher를 사용하는 환자의 심장 정보를 저장한다. beat_data 부분은 30ms마다의 ECG 전위 차이의 값을 String의 나열로 저장한다. 1분의 데이터를 저장하므로 총 2천여개의 ECG 데이터가 저장되게 된다. 이는 약 2KB 정도의 용량을 차지하는 것으로 실험을 통해 밝혀졌다. 그리고 beat_count는 매 5초마다 업데이트가 된다. 심박수를 계산하는 알고리즘을 통해 계산된 정보를 5초를 주기로 데이터베이스에 업데이트한다.


  • 이 3개의 테이블은 userinfo에 있는 id 속성에 모두 관계를 맺고 있다. 다시 말해서, 환자가 개인의 정보를 저장할 경우에는 이에 맞는 보호자의 개인 정보와 환자의 심장 정보가 정해진다.

The Watcher PHP Web Server

  • The Watcher 웹 서버는 굉장히 단순한 구조와 기능을 가진다. PHP로 구현되어 있으며, The Watcher 데이터베이스 서버에 접근하여 state 속성을 읽어 state 속성 값이 변화가 생길 경우에 C2DM 푸시 메시지를 환자와 보호자에게 전달하는 역할을 한다.


WebServer.jpg


  • 위의 그림과 같이 state는 매 5초마다 state의 속성을 읽는다. 이는 BaseStation에서 state 값을 데이터베이스 서버로 5초를 주기로 업데이트하기 때문이다. state가 1, 즉 정상 상태에서 벗어나 2, 3, 4의 상태가 될 경우에는 즉시 C2DM 푸시 메시지를 사용자에게 전달한다.


SenderWeb.jpg


  • 위의 그림과 같이 C2DM 메시지를 전송하기 위해서는 안드로이드 디바이스 뿐만 아니라 서버측에서도 C2DM Registration ID를 발급받아야 한다. 서버의 C2DM Registration ID는 안드로이드 모바일 디바이스와는 다르게 Sender로 등록하는 것이다.

안드로이드 구성

  • 안드로이드는 크게 안드로이드 푸쉬 시스템(C2DM)과 유져 인터페이스(UI)로 구성된다.


안드로이드 푸쉬 시스템(C2DM)

  • 안드로이드 푸쉬 Server 는 환자의 심장 이상 증후 발생시 즉시 보호자인 watcher에게 긴급 메세지를 알려주기 위해 사용된다. 푸쉬 시스템을 사용하기 위해서는 먼저, <와처> 시스템의 와처 서버와 각각의 단말 간에 registration ID 를 Google C2DM 서버로 부터 발급 받고 이를 저장해야 한다. 추후에 메세지를 받기 위해서 registration ID 는 단말의 고유번호가 되어 판별할 수 있도록 되어 있기 때문이다. 기본적인 C2DM 의 구조는 다음과 같다.
Error creating thumbnail: Image type not supported
  • C2DM Sequence Diagram
Error creating thumbnail: Image type not supported


  • 안드로이드 C2DM 서비스의 Life Cycle
  1. http://code.google.com/intl/ko-KR/android/c2dm/signup.html 에 가서 개발자 email, 어플 package이름을 등록한다.
  2. 어플을 setup하면 app, sender정보를 C2DM으로 전송하면 reg_id가 날아온다(기기의 고유id)
  3. 기기로 날아온 reg_id를 User_id(전화번호)와 함께 3rd party 서버로 전송하여 DB에 저장한다.
  4. 메일서버에 편지를 보낼 때 msg, user_id(전화번호)를 3rd party서버로 전송한다.
  5. 프로그램 승인값(auth_id)이 없으면 새로 발급받아 cookie에 저장해 두고 있으면 cookie에서 읽는다.
  6. msg, auth_id, reg_id(user_id로부터 읽어)를 C2DM으로 전송한다.
  7. 인증 검사후 msg를 해당 SmartPhone로 전송한다.
  8. Notification으로 폰에서 메시지를 읽는다.


The watcher 클래스 다이어그램 및 유져 인터페이스

  • 먼저 <와처> 시스템의 클래스 다이어그램 및 유져 인터페이스는 아래와 같다. 각각의 클래스들 간에 연관 관계를 가지고 상호 연결되어 있으며, 각 클래스의 특성이 아래의 표에 명시되어 있다.
ClassDiagram.jpg



순번 Watcher 화면 클래스명 설명
1
1.jpg
TheWatcherInitActivity.java The watcher 시스템에 처음 접속한 화면 구성으로써 Background 에서 동작중인 Thread 로 데이터베이스에 접근하여 데이터를 가져오는데 8초의 시간이 걸리므로 8초 동안 watcher 와 환자의 등록여부를 판단한다. 만약 데이터베이스에 개인정보가 등록되어 있지 않다면 Registinfo Activity 로 화면을 전환한다. 반대로 개인정보가 등록되어 있다면 The watcher 시스템의 주요 3가지 기능을 보여주는 TestbedActivity 화면으로 넘어가게 된다.
2
2.jpg
RegistInfo.java 초기화면에서 등록되지 않은 watcher 와 환자가 the watcher 시스템에 등록하기 위한 User Interface 이다. 각각의 항목에 대해 watcher 와 환자의 기본 정보를 입력하게 되면 데이터베이스에 접속되어 입력한 정보가 저장되게 된다.
3
3.jpg
WacherTabActivity.java 초기화면에서 watcher와 환자가 등록되어 있다면 이 Activity 로 화면이 전환된다. The watcher 시스템의 주 기능을 3가지 탭으로 표현한 Activity 이다. 각각의 탭은 환자정보, 환자상태, APP 정보로 구성되어 있으며 전환된 페이지는 가장 먼저 환자정보를 보여주도록 default 되어 있다.
4
4.jpg
MyInfo.java 개인정보가 The watcher 시스템에 저장되어 있다면 가장 먼저 보여지는 Activity 이다. 저장된 watcher와 환자의 기본 정보를 데이터베이스로부터 가져오고 이를 출력하여 사용자에게 확인시켜 준다. 이외에 Google GPS 로 부터 받아온 환자의 위치와 임의로 지정한 병원 간의 위치 간의 거리를 km 로 단위로 출력해 주며, 이를 구글 맵으로 확인할 수 있도록 하는 ‘지도’ 버튼으로 구성되어 있다.
5
5.jpg
GPSService.java 60초 단위로 GPS 값을 업데이트 하도록 설정 하였으며, 업데이트를 할 때 Google GPS 로 부터 환자의 위도와 경도 값을 받아와 업데이트 한다. 병원의 위도와 경도 값은 임의로 지정하였으며, 환자와 병원 사이의 거리를 계산하여 Myinfo Activity에 km 단위로 출력하도록 하였다. 환자의 위치에 따라 15초 간격으로 거리의 값이 변경된다.
6
6.jpg
WatcherMapActivity.java MyInfo 에서 받은 버튼 이벤트에 대해 지도상에 환자와 병원의 위치를 출력하는 Activity 이다. GPSService에서 받아온 환자의 위도와 경도의 값을 구글 맵 위에 하트 표시로 출력하며 병원 표시로 병원의 위치를 출력하여 준다.
7
7.jpg
MyState.java 만약 환자 혹은 watcher 가 MyState 탭을 선택한 경우 환자의 현재 맥박 수를 확인할 수 있으며 맥박 수는 실시간으로 60초 단위로 the watcher 서버로부터 맥박 수를 받아온다. 또한 그래프 이미지 버튼을 클릭하면 그래프 화면으로 화면을 전환해 준다. 만약 START 버튼을 클릭하기 전에 그래프 버튼을 클릭하면 ‘START 버튼을 누른 후 부터 그래프가 생성됨’을 알린다. 또한 초기 데이터를 받아 오는 동안 버튼을 클릭하게 되면 ‘잠시 후에 다시 누르세요’ 라는 알림 메시지를 출력한다. START 버튼을 클릭시 데이터 전송이 시작됨을 알리고 60초 간격으로 데이터가 전송된다. END 버튼을 클릭시 데이터 전송이 멈추는 것을 알려준다.
8
8.jpg
ReceiveService.java MyState 로 부터 들어온 event에 대한 데이터를 받기 위해 C2DM 서버에 Registration ID 을 등록한다. C2DM 에서 단말로 데이터를 전송하기 위해서는 단말 고유의 Registration ID 를 알아야 하기 때문이다. START 버튼에 대한 event를 처리하기 위해 조건에 따라 The watcher 서버의 데이터베이스에 접속을 하고 해당 단말기에 대한 정보를 받아온다. 받아온 정보에 따라 MyState 의 맥박수치를 변화시킨다. 수치는 60초 주기로 변화된다. 또한 END 버튼에 대한 event 를 처리하기 위해 stopTask 에 대한 조건에 따라 데이터베이스와의 연결을 종료한다.
9
9.jpg
GraphActivity.java 받아 온 데이터를 space 단위로 parsing 한다. parsing 한 string 형 데이터를 그래프에 찍기 위해 먼저 int 형의 데이터로 가공하고 그래프에 출력하기 위해 float 형으로 변환한다. 변환된 데이터의 Max 값을 찍어주고 그래프의 x축과 y축 등의 형식을 만들고 그린다.
10
10.jpg
Setting.java APP 정보 탭의 Activity 를 구성하는 클래스이다. The watcher 가 어떤 시스템인지에 대한 정의와 The watcher 시스템 개발자 정보를 출력한다.
11
11.jpg
C2dmBroadcastReceiver.java C2DM 서버로 부터 등록된 registration 정보를 받는다. 매번 어플리케이션을 실행 할 때 마다 C2DM registration 값이 바뀌기 때문에 등록 ID를 발급 받아야 하고 발급 받은 ID로 추후에 broadcast 하기 위해 DB에 저장한다. C2DM 으로 부터 받은 이상증후 state 상태에 따라 Activity 를 변환한다. C2DM 으로 부터 받은 state 값을 저장한다. 초기 state 는 숫자 1로 셋팅 되어 있으며, 2 는 빈맥, 3은 서맥, 4는 부정맥을 뜻한다.
12
12.jpg
VisitActivity.java C2dmBroadcastReceiver 클래스로부터 넘어온 state에 따라 각각의 state에 따른 빈맥, 서맥, 부정맥에 해당하는 긴급 메시지를 watcher 에게 전송하여 다이얼로그로 출력해 준다.

The Watcher 개발 및 시험 환경

하드웨어

  • HBE-Zigbex-II Kit
  • Processor : ATmega 128L
  • Memory: 128KB Program FLASH, 4KB RAM
  • RF Device : CC2420 (IEEE 802.15.4)
  • Security : DSSS
  • Data Rate: 250Kbps (Max)
  • Base Sensor: 온도/습도, 가시광도, 적외선, RTC
  • Power: 1.2V ,1.5V Battery
  • Size (W x D x H) : 60mm x 50mm x 30mm
  • Bio 옵션 모듈
  • 신체의 ECG(맥박)과 체온을 측정하여 아날로그 데이터로 전송한다.
  • 안드로이드 스마트폰 (LG-LU6200, 옵티머스 LTE)
  • 3G(Downlink: 14.7 Mbit/s), 4G(Downlink: 86.4Mbit/s) 셀룰러 통신
  • 1.5GHz AP.

소프트웨어

  • Eclipse Indigo
  • 안드로이드 어플리케이션 개발 툴 (JAVA version 1.7.0, 안드로이드 SDK 2.2 Froyo)


  • 서버 개발 소프트웨어
  • APMSETUP 7
  • Database: MySQL Server(5.1.41-community)
  • PHP Server 5.2.12
  • Apache Web Server
  • Aptana studio 3
  • PHP 및 Java Script와 같은 웹 언어를 개발하는데 사용하는 개발 툴


  • 센서 네트워크 관련 소프트웨어
  • TinyOS2.0
  • Cygwin
  • AVR studio 4

결론 및 향후 전망

결론

  • 우리나라 사망 원인중 심장 질환으로 인한 사망이 3위이며, 매년 심장질환으로 사망하는 비율으 점점 더 증가하는 추세이다. 심장 질환을 가진 사람이 응급 처치와 같은 즉각적인 대처를 갖는 다면 생존률을40% 이상 된다고 한다. <와처> 시스템은 이와 같은 대처방안으로 부터 고착된 시스템으로써, 환자의 심장 상태를 실시간으로 체크하고, 심장 박동이 급격히 변화를 보이게 되면 등록되어 있는 보호자에게 Push 알람 메시지를 전달하여 환자의 상태를 확인할 수 있게 하고, 만약 환자의 이상이 확인이 될 경우에 환자와 가장 가까운 병원의 위치를 보호자에게 제공하여 최대한 빨리 대처할 수 있게 한다.

향후 전망

  • 현재에는 데모 버젼의 프로그램이지만, 추후에 응급실, 구급대와 같은 응급시설과 연동 되어 더욱 발전 한다면 건강을 지키고 소중한 생명을 지킬 수 있을 것이다. 또한 응급시설과의 연동 서비스가 가능하다면 병원에서 의사들이 환자의 진단 차트로 활용할 수 있을 것이다. 서비스적인 측면에서 환자 혹은 보호자가 평소 숙지하고 있을 수 있도록 응급상황에 대한 대처 방안에 대해 정보 제공 서비스를 제공하게 되면 응급 상활 발생시 응급처치를 할 수 있도록 할 수 있을 것이다. 현재 <와처> 시스템에서 환자에게 제공되는 심전도 측정 그래프는 시간영역 면에서의 서비스를 제공하고 있다. 추후 주파수 영역에서의 분석 기능이 추가된다면 보다 정밀하고 세밀한 심장 정보를 환자에게 제공할 수 있을 것이다.

Project Outcomes

Proposal

교수님의 Feedback의 결과로 내용이 많이 부족하고, 구현 가능성이 어렵다고 판단하여 다른 아이디어를 생각하여 제안서를 다시 작성하는 것으로 결정 및 일정 계획.


너무 광범위한 아이디어의 내용을 조금 좁은 범위에서, 그리고 자기 팀만의 전문화된 기술적인 이슈를 추가하여 중간 발표를 하기 위한 일정 계획.


아이디어를 다른 방향으로 모색하고 최대한 범위를 줄인 최종 Proposal 작성



중간 발표

  • 10.31일 중간 결과 보고, Midterm
데이터베이스 스키마 설계, 바이오 모듈 테스트, Google Push Server 연동 등 10.31 까지 진행된 사항에 대한 중간 결과 발표자료



최종 발표

교수님의 Feedback의 결과로 , 전반적인 최종 결과보고 형식을 갖추지 못하였고, 설계와 구현 부분에서 차이가 있어 12월 5일 2차 발표를 가지기로 함.


  • 12월 5일 2차 최종발표
최종 보고는 Mediawiki에 있는 최종 내용을 가지고 발표.



회의록 및 계획

팀원별 역할

Dividerole.jpg


  • 기타 문서 작성 및 Wiki 작성, 프로그램 개발은 모든 팀원이 합심하여 같이 진행.

일정

마일스톤

Milestone.jpg

세부 계획

09.26 ~ 09.30

  • 아이디어 제안서를 위한 아이디어 선택
  • 선택된 아이디어의 시나리오 작성, 팀원 모두 작성하여 3개의 시나리오를 작성하고 통합하여 1개의 시나리오로 작성
  • 작성된 시나리오를 기반으로 사용자, 기술 요구사항 등 설계 및 개발에 필요한 요소들을 작성


10.01 ~ 10.03

  • 작성된 시나리오와 요구 사항을 기반으로 제안서 작성
  • 09.26일 교수님께 FeedBack 받은 것을 기반으로 작성
    • 우리 팀이 정확히 무엇을 할 것인지
    • 사용한 기술들의 상세한 명세
    • 이 시스템, 서비스를 사용할 사용자의 요구명세
    • 우리가 시스템을 구현할 때 요구되는 제한사항
    • 시스템을 사용하여 얻을 수 있는 비지니스 모델, 전략 계획


10.04 ~ 10.10

  • 2차 제안서 작성을 위한 자료 준비 및 제안서 작성
  • Zigbee 센서 개발환경 구축 및 하드웨어 테스트
  • 10.10 제안서 2차 발표
    • 교수님 Feedback: 아이디어의 범위가 너무 광범위하여 구현의 어려움이 있을 것 같음.
    • 아이디어의 범위를 조금 더 좁은 범위에서 생각하고, 자기 팀만의 독창성을 내세울만한 것으로 집중 개발을 권장.
  • 교수님의 Feedback을 수용하여, 조금 더 좁은 범위에서 Bio모듈을 이용하여 건강 상태를 체크하지만
  • 우리만의 독창적이고 전문화된 기술적인 이슈를 생각하여 추가.


10.11 ~ 10.21

  • 학교 중간고사 시험 범위로 인하여 개발 일시 중단.
  • 21일 팀미팅 이후 제안서 재수정 계획 및 24일 중간 발표를 위한 안드로이드 기술적 이슈 체크.


10.24 ~ 11.10

  • ECG 분석에 대한 의학적 자료 조사와 이를 구현할 수 있는 시스템 구축
  • 서버에 관련하여 Web, Database 서버 기술적 이슈 체크.
  • 안드로이드 어플리케이션 프로그래밍 진행


11.11 ~ 11.29

  • 모든 개발 프로그래밍 및 서버 구축 완성할 것
  • 최종 발표 준비 및 자료 작성


11.30 ~ 12.05

  • 최종 보고서 작성
  • 어플리케이션 및 서버의 작은 버그들 수정

회의록

2011.09.12 회의록

  1. 시간 및 장소: 수업 직후 공학관 301호, 1시간 30분 진행
  2. 팀 형성 및 아이디어 회의
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 아이디어 제시
    1. 고동현: Bio 모듈과 Zigbee 센서 측위 기술을 활용한 범죄자 감시 및 범죄 예방
    2. 김진호: Zigbee 센서 측위 기술을 사용한 시각 장애인 안내 시스템
    3. 이정윤: Zigbee 센서 측위를 활용한 공원내 아이 안심 서비스
  5. 아이디어 선택 결과: 고동현 학우의 아이디어 선택
    1. Zigbee 측위 기술을 기반으로 하여 범죄자의 위치를 감시
    2. Bio 모듈을 이용한 신체 변화 감지, 범죄를 예방


2011.09.20 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간 및 장소: 수업 직후 공학관 논문실, 1시간 30분 진행
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 온라인 메신저를 이용하여 제안서 제작 회의
    1. 다음 오프라인 회의때까지 제안서의 각 파트를 나누어 작업 후 회의에서 발표 후 팀내 피드백 활동.


2011.09.24 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간 및 장소: 오후 3시, 교대역 카페, 1시간 30분 진행
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 제안서 제작 마무리 및 발표에 관한 회의 진행
    1. 발표 자료 구성
    2. 예상 질문 도출 및 답안 제시


2011.09.26 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간 및 장소: 수업 직후 공학관 301호, 약 1시간 동안 진행
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 기존의 아이디어의 한계와 기술적 문제점 발견
  5. 제안서의 부족한 내용으로 제안서 다시 작성
  6. 새로운 제안서를 위한 아이디어 회의.
  7. 제시된 아이디어
    1. 고동현: Bio 모듈과 자동차의 연동
    2. 김진호: 직원 건강 관리 시스템
    3. 이정윤: 병원에서 활동량이 많은 환자를 위한 무선 Bio 측정기
  8. 아이디어 선택 결과: 이정윤 학우의 아이디어 선택
    1. Google push server 를 이용한 알림 어플리케이션
    2. Bio 모듈을 이용한 신체 변화 감지 및 사전 발병 예방



2011.09.27 회의록

  1. 회의 방식 : 온라인 회의
  2. 시간 및 장소: 약 1시간 동안 진행
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 온라인 회의: 각자 제시된 아이디어를 평가 후 선택
    1. 아이디어 선택 결과: 김진호 학우의 아이디어인 원격 직원 건강 관리 시스템으로 아이디어 채택
  5. 선택된 아이디어에 따른 개인별 시나리오 작성 후 28일 오후에 Mclab Wiki를 통해 쉐어.


2011.09.30 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간 및 장소: 오후 4시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 각 시나리오에 따른 사용자 요구사항과 기술 요구사항 등 필요한 요소들을 도출, 평가


2011.10.05 회의록

  1. 회의 방식 : 온라인 회의
  2. 시간 및 장소: 오후 10시, 온라인 회의
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 제시된 시나리오를 보강, 제안서 기본 작업 시작.
  5. 시나리오에 기초하여 필요한 기술과 현재 기술 동향 등, 제안서를 만들 자료를 분담


2011.10.08 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 4시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 시나리오 흐름도, 데이터베이스 스키마, 바이오 모듈 블록도, 서비스 UI 구성, 동향분석, 마일스톤 추가
    1. 고동현 - 시나리오 흐름도, 서비스 UI 추가
    2. 김진호 - 바이오모듈 블록도, 데이터베이스 스키마 추가
    3. 이정윤 - 동향분석, 마일스톤 추가


2011.10.10 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오전 11시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 아이디어 기술적 측면과 문제점 보안에 대한 토론
    1. 광범위한 제안서의 기술적인 부분을 좀 더 작은 범위의 전문적이고 독창성인 것으로 특화 결정.
    2. Zigbee 무선 센서 네트워크 개발환경 구축: 공학관 409호, Zigbex-II 프로그램 포팅


2011.10.21 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 3시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 아이디어 기술적 측면에 대한 토론과 수정


2011.10.27 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 6시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 서비스 시나리오 수정 및 보완
  5. 서비스 시나리오를 기초로 데이터베이스 스키마 및 안드로이드 어플리케이션 기본 UI 추출.
  6. Zigbee로 부터 전송되는 메세지 프로토콜 분석 및 설정, 파싱.


2011.11.07 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 6시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. Zigbee로 부터 전송되는 메세지 프로토콜 분석 및 설정, 파싱.
  5. Database 수정 및 의학정보 조사
  6. Bio 모듈과 서버간 연동 및 서버와 스마트 폰 간에 연동 테스트


2011.11.12 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 3시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 안드로이드 UI 구성 및 Bio 모듈로 부터 수신한 데이터 가공
  5. 이상징후 관련 알림 기능 구현


2011.11.20 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오전 11시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
  4. 기존에 작성된 테스트 기반의 안드로이드 UI 구성을 추가 보안


2011.11.25 회의록

  1. 회의 방식 : 오프라인 회의
  2. 시간과 장소: 오후 4시, 공학관
  3. 팀원: 고동현(팀장), 김진호, 이정윤
    1. 고동현 - 전반적인 안드로이드 UI 구성 추가 보안 및 the watcher 시스템 점검
    2. 김진호 - Google map 연동 및 데이터 베이스 수정
    3. 이정윤 - the watcher 시스템 이미지 작성 및 보고서 작성

Reference

  • ZigbeX를 이용한 유비쿼터스 센서 네트워크 시스템, (주)한백전자 기술연구소, 2007
  • 데이터베이스 시스템, McGraw-Hill, 2010
  • 안드로이드 프로그래밍 정복, 한빛미디어, 2010
  • 인터넷 사이트


소스 첨부

The Watcher 안드로이드 소스

The_Watcher.zip

The Watcher Web 서버 소스

The_Watcher_Web_Server.zip

The Watcher Zigbee + Bio 센서 모듈 소스

The_Watcher_Sensor.zip