Lecture/CAP/2011/Team 1

From MCLab
Jump to: navigation, search

Contents

Project Description

< 본 문서는 The Watcher 프로젝트에서 새로운 내용이 추가되거나 필요없는 내용은 삭제되는 등 내용이 계속 변경될 수 있습니다.>

Project Name

< The Watcher >

머리말

  • 본 Wiki 페이지는 '정보통신종합설계2' 프로젝트를 통해 개발되는 The Watcher에 대해 상세 설계 사항을 기술한 것이다. The Watcher는 크게 Zigbee 노드와 Bio 센서 모듈, 스마트폰을 통한 어플리케이션 그리고 이 둘을 중계하는 The Watcher 서버로 구성된다. 본 문서는 이 구성요소들을 위하여 기능 설명, 기능 동작, 자체 시험 방안으로 나누어 설명한다.


프로젝트 개요

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

개발 동기 및 필요성

  • 심장 질환, 특히 심장마비는 언제 어디서나 건강한 사람들에게도 갑자기 발생할 수 있는 질병이다. 또한 심장질병이 발병했을 때는 빠른 응급처치만이 생명을 살릴 수 있는 유일한 방법이다. 따라서 <와처>를 사용하는 대상은 심장에 관련된 수술을 받아 심장의 상태를 지속적으로 살펴봐야 하는 환자나 심장에 지병이 있어 심장이 좋지 않은 환자, 그리고 작은 활동으로도 많은 피로감을 느낄 수 있는 나이가 많은 어르신들이다.

목표

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

The Watcher 서비스 Diagram

Service11.jpg
  • <와처> 시스템 전체적인 구성은 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는 사용자의 위치로 부터 가장 가까운 거리에 있는 응급시설의 위치를 알려주기 위해 사용된다.


The Watcher 기술적 Block Diagram

Techdia.jpg

기대효과

  • <와처>를 이용하여 위험한 환자의 보호자들이 환자들을 실시간으로 감시할 수 있다.
  • <와처>의 사용자가 위험이 생길 경우 보호자에게 알림 메시지를 전달하여 환자의 이상징후를 판단할 수 있도록 한다.

사업 계획

동향 분석

갑자기 일어날 수 있는 심장 질환
  • 심장질환은 누구도 예상하지 못하게 일어난다. 이러한 심장 질환은 갑작스런 돌연사로 이어진다. 가장 흔한 원인은 심장 자체에 산소와 영양분을 공급하는 관상동맥에 죽상반이라는 기름기가 끼고 혈전이 형성되어 발생하는 협심증 혹은 심근경색증이다. 특히 혈전으로 인하여 발생하는 심근경색증을 겪은 환자들은 평생 병원을 한 번도 가본 적이 없을 정도로 건강하였다가 하루 아침에 발병한다. 일단 심근경색증이 발병하게 되면 약 40%는 손 한 번 써 볼 틈없이 갑작스런 죽음에 이른다. 가장 큰 문제는 이런 협심증이나 혈전 같은 경우에 통증이 거의 없기 때문에 발견하기 힘들다.
현재의 심장 모니터 시스템

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

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

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

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

사업 전략

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


시스템 요구 사항서

개요

목적
  • 본 부분은 무선 센서와 안드로이드 푸쉬 기능을 이용한 심장 모니터 시스템 및 어플리케이션 개발 프로젝트의 요구사항을 정의한 부분이다. 무선 센서 노드의 BIO 센서 모듈이 부착된 무선 센서를 사용하여 The Watcher를 사용하는 사용자의 맥박 정보를 실시간으로 확인, 저장 및 분석할 수 있는 시스템 구축과 재가공된 맥박 정보를 안드로이드 스마트폰으로 제공하는 어플리케이션 제작을 목표로 한다. 본 문서는 고객들이 요구하는 다양한 요구사항을 수집하여 요구사항을 도출하였고, 이를 기반으로 개발자가 고객의 요구사항을 만족시키기 위해 적용할 수 있는 시스템 요구사항을 도출하였다.
  • 이와 같이 고객 요구사항과 시스템 요구사항을 본 문서에 기술함으로써 향후 고객에게는 요구 사항의 반영 여부를 확인시키고, 개발자에게는 고객 요구 사항의 파악 및 시스템 개발 방안을 결정하는 데 활용할 수 있도록 하는 것이 본 부분의 목적이다.
  • 본 부분은 이하 문서의 작성에서 기준 문서로 적용되며, 필요한 경우 이후의 다른 부분에서 인용 반복되어 기술될 것이다.
범위
  • 본 부분은 무선 센서 노드를 이용한 심장 모니터 시스템 개발 및 안드로이드 어플리케이션 개발 프로젝트에서 요구되는 일반 요구사항, 기능 요구사항, 성능 요구사항, 설계상 제약사항 및 시스템 속성에 대해 기술한다.
  • 본 부분은 기술 개발을 위한 구체적인 구현 방법에 대해서는 기술하지 않으나 고객 요구사항으로부터 시스템 또는 개발자 관점에서 기술적 용어를 사용하여 요구사항을 정의하며, 개발 과정의 기술적인 문제점을 고려하여 제한 조건, 가정 및 전제 조건을 반영하여 작성한다.
  • 본 부분은 구현 단계에서 구체적이고 현실적인 핵심 모듈 개발을 위하여 내용의 보완이 가능하며 수정 내용은 다른 부분에 반영되어야 한다.
개발 명칭
  • 본 부분은 무선 센서 노드의 Bio 센서 모듈을 이용한 심장 모니터 시스템과 안드로이드 어플리케이션을 이용하여 구축된 시스템과 어플리케이션의 명칭을 다음과 같이 명명한다.
  • The Watcher: <와쳐>라고 발음한다.
  • Zigbee: Zigbee는 Bluetooth의 고가격, 고전력 소비의 단점을 보완한 기술이다. Zigbee란 zig-zag로 날아 다니면서 다른 동료들에게 정보를 전달하는 Bee(벌)의 정보전달 체계를 착안하여 붙여진 명칭이며, 무선 리모콘, 무선 조명제어, 컴퓨터에서의 무선 키보드 및 무선 마우스, 홈오토메이션, 재고관리, 무선 센서네트워크 등에 주로 응용되는 기술이다.
  • Bio 센서: 심장 박동과 비부착식으로 체온을 측정할 수 있는 센서. 심장 박동은 좌심방과 우심방의 전압의 차이를 측정한다.

일반사항

연구개발 개요
  • BIO 센서 모듈을 부착한 무선 센서 노드와 안드로이드 어플리케이션을 이용한 심장 모니터 시스템 및 어플리케이션 개발은 센서 노드 및 센서 네트워크의 연결을 표준화된 환경에서 가능하게 하는 개방형 센서 네트워크 통신망 인프라에서 적용 될 수 있다. 또한 센서노드가 획득한 Bio 정보는 재가공되어 사용자의 심장 상태를 안드로이드 모바일 기기로 전송해주기 때문에 심장의 이상 유무를 보호자가 쉽게 알 수 있으며, 사용자의 심장에 이상이 생길 경우에는 보호자에게 빠르게 연락을 취해 사전 예방 및 이상 상황에 대해 빠른 대처가 가능하다.
주요 기능
  • 각 사용자가 Bio 센서 모듈이 내장된 센서 노드를 신체에 부착하고 사용자의 안드로이드 모바일 기기에 Bio 정보를 수집, 재가공하여 표시해준다. 무선 센서 노드를 통해 수집한 정보는 사용자의 ID(노드의 식별번호), 심전도(ECG), 체온, 배터리 잔량여부 등이 포함된다. ECG, 체온과 같은 정보는 매우 빠른 시간동안 민감하게 변하는 요소이므로 정보 수집 주기는 10초 이내로 설정하여 획득한다. 이는 시뮬레이션을 통해 조절하기로 한다. 수집된 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 의 맥박 정보를 수신 받는다.

요구사항 및 제한사항

사용자 요구사항

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

시스템 기능 요구사항

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

시스템 구현의 제한사항

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

2. 무선 센서 노드로부터 센싱되는 체온와 ECG(맥박) 값을 다음의 값이 정상 범위라고 제한한다.

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

시스템 설계

Bio 모듈 및 The Watcher Server

  • Data Infomation Flow


DataSequence.jpg


  • 심장 질환 환자나 평소 주기적인 진단이 필요한 노인들을 대상으로 미연에 심장을 관리하는 <와처> 시스템의 내부 구조도는 다음과 같다. 먼저, 사용자인 User와 <와처> 서버가 구글 푸쉬 서버에 등록을 한다. 보호자인 Watcher가 <와처> 시스템을 설치하면 사용자의 등록으로 자동 로그인이 가능하다. 이후 유저의 심장 데이터는 <와처> 서버에 저장되고 이를 실시간으로 구글 푸쉬 서버를 통해 실시간으로 검진이 가능하다. 만약 심장의 이상징후가 포착 될 시 이상징후에 대한 알림 메시지와 가장 가까운 응급시설의 위치를 제공 받을 수 있다.



Bio 센서 모듈
  • ZigbeX의 바이오센서 모듈은 ECG(심전도) 센서와 비접촉식 체온 센서를 탑재하고 있다. ECG 센서는 세 개의 도선을 통해 사람의 맥박을 측정하고, 환자의 심박 수 변화를 감지하여 현재 몸에 어떠한 변화가 일어나는지 예측할 수 있다. 또한 체온 센서는 센서의 이름에서 알 수 있듯이 환자의 사용자의 체온을 센싱하는 역할을 한다.
Module.png
Error creating thumbnail: Image type not supported
  • The Watcher에서 사용하는 Bio 모듈은 3극을 이용하여 ECG 값을 측정한다. 심장의 왼쪽에 Right Arm, 심장의 왼쪽에 Left Arm, 그리고 심장과 먼쪽에 Right Leg를 몸에 부착한다. Right Leg는 Ground 역할을 하여 ECG 값의 기준이 되고, Right Arm과 Left Arm의 전위차이를 15ms마다 측정한다.


  • Bio 모듈 블록도와 Bio 모듈 Program
BioModuleProgram.jpg
  • 위의 그림은 Bio 모듈 펌웨어들을 정의하는 헤더파일과 nseC의 구조를 나타낸 그림이다. The Watcher에서 사용하는 Bio 모듈은 크게 3부분으로 나뉘어 진다.
  • 통신 부분
  • 노드 processing 부분
  • Bio Sensing 부분


  • ECG와 체온은 Oscilloscope를 통해 Analog Output으로 출력이 나오게 된다. 15ms 마다 주기적을 값을 읽는다. 15ms 마다 주기적으로 읽은 값을 10번 누적하여 하나의 패킷에 저장하여 전송한다. 즉, 150ms마다 한번씩 Bio 모듈에서 서버로 전송이 이루어 진다. BIO 모듈의 구조와 전송되어지는 패킷의 형태는 다음과 같다.
Zigbee 및 Bio 모듈 메세지 프로토콜
  • ZigbeX 센서 노드를 통해 Bio 센싱되는 값인 ECG와 체온 센싱 값을 센서 네트워크를 사용하여 전송하기 위한 메시지 프로토콜을 정의하였다. TinyOS에 기본적으로 제공하는 Oscilloscope를 이용하여 아날로그로 전송되는 값을 디지털로 변환한다.

TinyOs의 시리얼 통신 메시지 형식

Mess.jpg
  1. SYNC_BYTE: 항상 0x7E (메시지의 시작바이트)
  2. PACKET TYPE
  • 0x42: ack가 필요 없는 사용자 패킷
  • 0x41: ack가 필요한 사용자 패킷
  • 0x40: 0x41에 대한 응답 패킷 (ack)
  • 0xFF: 형식이 없는 패킷
3. PAYLOAD DATA: TinyOS의 PAYLOAD DATA인 메시지(TOS_Msg) 형태를 기본적인 포맷으로 제공한다.
1. Address
  • 직렬포트: 0x007E
  • RF인 경우: 0xFFFF
2. TYPE
  • AMTYPE_XUART: 0x00
  • AMTYPE_MHOP_DEBUG: 0x03
  • AMTYPE_SURGE_MSG = 0x11
  • AMTYPE_XSENSOR = 0x32
  • AMTYPE_XMULTIHOP = 0x33
  • AMTYPE MHOP MSG = 0xFA
3. Group ID: 0x7D (Default)
4. length
5. Data: ECG와 체온의 센싱 값은 아날로그 형태로 전송이 되고, 이 아날로그 데이터는 OscopeMsg 구조체에 저장되어 전송된다. OscopeMsg는 TinyOS에서 기본적으로 제공하는 oscilloscope [net.tinyos.oscope.oscilloscope] 어플리케이션을 통해 디지털 값으로 변환되어 text 파일로 저장할 수 있다.
6. CRC16
4. SYNC_BYTE: 항상 0x7E (메시지의 끝 바이트)


Bio 모듈 Data Packet 메세지 형

  1. version: 모트의 버젼
  2. defalut interval: 15 ms
  3. id: Node Id [0 ~ 255]
  4. count: 보낸 패킷의 수
  5. reading: 인터벌이 발생했을 때 주고 받은 데이터


패킷을 받는 The Watcher Server 구조

Ocs.jpg


  • 서버에서는 이 패킷을 Ocsiloscope.java를 통해 서버에서 전송받게 된다. 오실로스코프는 서버측에서도 ECG 그래프를 찍어주기 때문에 watcher가 환자를 감시할 수 있는 것 뿐만 아니라 The Watcher 측에서도 환자를 감시할 수 있다. The Watcher 서버에서는 Bio 모듈을 통해 전송받은 ECG 데이터를 가공하여 각 스마트폰 단말기에 전송해주고, 이상징후를 간단히 분석하여 이상징후가 발생했을 경우 push 알람 서비스를 제공한다.


The Watcher ECG Monitor

TestingBioModule.jpg
  • 위의 그림은 The Watcher 서버에서 제공하는 ECG 모니터이다. 이와 비슷한 그림을 안드로이드 유저에게 제공하기 위하여 안드로이드 디바이스에서는 GraphView 라는 프로그램을 사용하였다.
Graphview.jpg

서버 데이터베이스 스키마

Error creating thumbnail: Image type not supported
  • The Watcher의 데이터베이스는 위의 그림과 같이 구성되어 있다. 사용자와 보호자의 전화번호를 비롯한 개인정보를 하나의 개별적인 테이블로 묶어서 저장, 관리하고, 사용자의 심박수 데이터 또한 하나의 테이블로 묶어 저장, 관리한다. 이 때 각 사용자, 각 사용자의 심박수 정보, 각 보호자들은 하나의 ID를 통해 관계를 맺어 서로 연관이 있게 만들었다.
  • 응급시설에 대한 테이블도 독립적으로 저장, 관리하여 응급시설의 경도와 위도 값을 저장한다. 이 경도 위도값을 이용하여 사용자와 가장 가까운 위치에 있는 병원의 정보를 추출해낸다.


Bio 모듈에서 Database 서버로 값 전달 방법

  • ECG 데이터는 데이터베이스에 TEXT 형태로 저장이 되고, 안드로이드 디바이스에서도 전송받아 String 형태로 처리한다. 이 때 안드로이드 디바이스에서 지원하는 String 자료형은 4KB 이상의 데이터를 수신할 수 없다. 왜냐하면 파일 시스템의 논리적인 구조가 4KB 단위로 나뉘어져 있기 때문이다. 물론 String의 배열 형태로 데이터를 전송받는다면 더 많은 데이터를 받을 수 있겠지만 The Watcher 시스템은 다른 방법을 사용하여 데이터를 전송 받는다.
S2db.jpg
  • Bio 모듈에서 센싱한 값은 150ms 마다 10개의 데이터를 전송한다. 이럴경우 5초동안 약 330개의 데이터가 생기고 1분동안은 약 4천여개의 데이터가 발생한다. 1개의 데이터가 약 1.5 Byte씩 4천여개의 데이터가 전송될 경우 4KB가 넘개 된다. 따라서 모든 데이터를 전송하지 않고, 10개의 데이터 중 5개, 즉 30ms 마다 전송되어 지는 값들만을 서버에 전송한다.


The Watcher Server

  • The Watcher 서버의 기능은 아주 단순하게 설계되어 있다. Database Server의 state의 변화를 보고 변화가 생길 경우에 그 변화에 맞추어서 환자와 보호자의 안드로이드 단말기에 구글 Push 메시지를 전달한다. 각 안드로이드 스마트폰의 C2DM Registration ID는 스마트폰에서 어플리케이션을 실행할 때 데이터베이스 서버에 등록이 되어 있으므로 Push 메시지를 전달하기 전에 데이터베이스에서 Registration ID를 가지고 온다. 서버에서는 5초를 주기로 Database의 state 값을 확인한다. 왜냐하면 Bio 모듈에서 전달된 값을 데이터베이스로 5초를 주기로 업데이트를 하기 때문이다. 다음 소스 부분인 5초 주기로 state를 검사하는 부분이다.
Web1.jpg


  • The Watcher Server는 PHP를 이용하여 Web 서버로 구축되었다. Web Server로 구축되어 있기 때문에 별도의 프로그램을 작동시키지 않아도 서버에서 Web을 실행시키기만 하면 Web Server가 작동한다.

ECG 분석

  • ECG 기초
ECG 신호는 사람에 따라 정상적이더라도 박동의 주기가 다르며 심한 고주파 잡음이 있다. 하지만 일정한 주기로 규칙성을 가지게 된다. 만약 비정상적인 신호는 특징점들이 비정상적으로 나타나고 규칙성이 결여되어 환자의 현재 건강 여부를 판단할 수 있다.
  • 보다 쉬운 특징점 검출을 위하여 Fourier Transform을 사용하고 Low Pass Filter를 이용하여 고주파의 잡음을 없앤다.
Ff.png
ECG의 시간영역 분석
  1. Mean HRV(Mean HRT) : 평균 분당심박동수, 50이하 서맥 / 정상 60~90 / 90이상 빈맥
  2. SDNN(CLU or SDRR) : RR간격의 표준편차
  3. RMS-SD: RR간격의 차이를 제곱한 값의 평균의 제곱근, 10이하 심장질환의 발병위험
  • 결과
  1. 빈맥(Tachycardia): 스트레스, 불안, 초조한 상태 / 갑상선 기능항진, 탈수 → 자율신경계 불균형, 심기능 문제 / 알코올, 수면부족, 급격한 운동, 카페인, 니코틴 등이 원인 / 동성 빈맥(100~140회), 심방 조동(150회), 심실상성 빈맥(160회 이상)
  2. 서맥(Bradycardia): 운동선수 / 피로, 만성스트레스,갑상선 기능 저하 / 저 체온증, 급성 심근경색, 두통, 현기증, 실신
  3. SDNN감소: 자율신경계 항상성 저하, Stress에 대한 저항력 저하
  4. SDNN 현저히 감소: 심근경색, 협심증, 심실성 부정맥, 급성 심정지
Times.png
주파수영역 분석
  • 각기 다른 대역의 주파수 신호가 합쳐져서 하나의 복잡한 신호로 표현된다.
  1. VLF(Very Low Frequency): 0.0033~0.04Hz의 주파수 대역 / 체온조절, 혈관운동 / 5 분 측정에선 임상적 가치 적음
  2. LF(Low Frequency): 0.04~0.15Hz의 주파수 대역
  3. HF(High Frequency): 0.15~0.4Hz의 주파수 대역 / 부교감신경계의 활동에 대한 지표 / 호흡활동과 관련
  • 결과
  1. VLF 증가: 수면무호흡증(OSAS) 환자의 경우 호흡곤란, 저 산소혈증의 현상의 증가 / 산소교환이 결여 / 부정맥 사와 관련
  2. LF 저하: 생체 에너지 소실 → 편두통, 두통환자에게서 높게 나타남 / 급격한 저하: 심폐기능 노화, 만성 스트레스
  3. LF 증가: 호흡이 느리거나 깊은 경우(복식호흡 등)


Freqs.png
ECG 분석을 통해 판단할 수 있는 대표적인 이상징후
Irr.jpg

위의 그림과 같이 부정맥이 발생할 경우에는 심박이 규칙적으로 뛰지 않는 것을 확인할 수 있다. 또한 심근경색이 의심되는 ECG의 그래프 형태는 일반적인 ECG 그패의 형태와는 다르게 심하게 뭉개지고, Edge가 명확하게 표현이 되지 않는다.

ECG 분석을 위한 알고리즘들

Algorithm of Peak Count
Algorithm.jpg
Pickcount.jpg


  • 인간의 맥박은 분당 60회가 뛰는 것이 가장 이상적이다. 따라서 본 프로젝트에서 제안하고자 하는 알고리즘은 5 초간격으로 들어오는 peak의 수를 세어 12개의 원형 큐에 각각 넣는다. 매번 5초가 지날 때 마다 새로운 peak count 값은 peak[0] 에 저장하여 1분간 맥박의 수를 확인한다.


이상 징후를 알아내기 위한 알고리즘

The Watcher에서 검출해낼 수 있는 이상징후는 빈맥과 서맥, 즉 맥박이 기준치보다 빠르게 뛰는 것과 기준치보다 느리게 뛰는 것을 위의 Peak Count 알고리즘을 통해 계산해낸 결과를 토대로 알아낼 수 있다. 그리고 맥박이 불규칙하게 뛰는 부정맥도 검출해낼 수 있다. 이번 부분에서는 빈맥과 서맥, 그리고 부정맥을 검출해낼 수 있는 알고리즘을 소개하려고 한다.

  • 빈맥과 서맥
FSState.jpg
  • 빈맥과 서맥을 판단하는 방법은 간단하다. Peak Count 알고리즘을 통해 계산된 BeatCount 값을 통해 빈맥과 서맥을 판단할 수 있다. BeatCount를 계산하기 시작하여 60이상이 되었을 때 state를 1로 바꾼다. state 1은 이상징후가 발견되지 않는 정상적인 상태이다. 정상상태에서 beatCount가 150회 이상이 되면 빈맥으로 판단하여 환자의 상태를 확인하도록 push 메시지를 watcher에게 전송한다. 30회 이하가 될 경우에는 서맥으로 판단하여 빈맥과 마찬가지로 push 메시지를 watcher에게 전달한다.


  • 부정맥
Irregu.jpg
  • 부정맥의 경우는 조금 복잡한 알고리즘이 적용된다. EWMA 방식을 사용하여 심장 박동의 주기를 계산하고, 계산된 심장박동 주기에서 많이 벗어나는 경우 Push 알람 기능을 통해 보호자에게 알람 메시지를 전달한다.
  • 부정맥 계산 알고리즘
EWMA1.bmp
  • 위의 식을 통해 EWMA 값을 얻을 수 있다. 위의 식을 적용하기 위해 두가지 사항을 결정해야 한다. 첫번쨰는 사람의 심장박동 주기의 초기값이고 두번째는 a값을 얼마로 지정할 것인가 이다. 첫 번째 사항은 일반적인 사람의 심장박동은 0.8초에서 1.0초 사이에 이루어진다는 것을 조사를 통해 파악했기 때문에 그 중간 값인 0.9 초로 설정했다. The Watcher에서는 150ms 주기로 10개의 데이터를 전송하기 때문에 60을 초기 값으로 설정하였다. 두번째 사항은 a값을 얼마로 지정한것인가 이다. a 값은 현재의 값을 얼마나 반영할것인가에 대한 척도 이며, Exponential Weighted이기 때문에 2의 자승으로 값을 설정해야한다. a 값이 크면 클수록 일반적인 심장 박동수가 아닌 개인적인 심장박동 주기를 반영하기 때문에 a 값을 7/8로 결정했다.

안드로이드 푸쉬 시스템(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으로 폰에서 메시지를 읽는다.

개발 및 시험 환경

  • 하드웨어
  • 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 5.2.12
  • Apache Web Server
  • Aptana studio 3
  • 센서 네트워크
  • TinyOS2.0
  • Cygwin
  • AVR studio 4

<와처> 화면 구성

  • <와처>의 화면구성은 다음과 같다.

Screen.jpg


  • 클래스 다이어그램
ClassDiagram.jpg


PushM.jpg

Project Outcomes

Proposal

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


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


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



중간발표

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



최종발표


회의록 및 계획

팀원별 역할

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일 중간 발표를 위한 안드로이드 기술적 이슈 체크.



회의록

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

  1. ZigbeX를 이용한 유비쿼터스 센서 네트워크 시스템, (주)한백전자 기술연구소, 2007
  2. 데이터베이스 시스템, McGraw-Hill, 2010
  3. 안드로이드 프로그래밍 정복, 한빛미디어, 2010
  • 인터넷 사이트
  1. 한백전자, http://www.hanback.co.kr/
  2. Android Developer, http://developer.android.com/