(구) CGM – 천안 순천향 병원 협력

  • 2018-08-19
  • 2018-08-16
    • 요구 기능
      • 1. 가상 ID 환자 번호 리스트 드롭다운
        • 어차피 환자 몇 명 없으니, 그 환자에 해당하는 모든 정보를 빠르게 검색할 수 있는 기능이 필요
      • 2. 출력해야 하는 페이지
        • -로그인 페이지
          • 학교용 계정: id는 cslab, pw는 cslabm606
          • 병원용 계정: id는 chhospital, pw는 chdiabetes
        • -검색 페이지
          • quickSearch를 맨 위로 올릴 것
        • -새로운 페이지
          • Sensor Glucose 수치만 라인 그래프로 출력
            • 수치가 180초과일 땐 hyperglucaemia(고혈당) 표시를 차트 내부에 할 것
            • 수치가 70미만일 땐 hypoglycaemia(저혈당) 표시를 차트 내부에 할 것
            • 눈에 가장 잘 띄는 색으로 표시
            • 데이터 레이블 축을 눈에 잘 띄도록 올릴것
          • 환자의 실제 정보를 테이블로 같이 출력
            • 실제 환자 정보를 유추할 수 있는 patientID부분을 제거하고, 가상 ID로 치환하고 그 외에 모든 정보 테이블로 출력
          • 이 페이지내에서 어떠한 버튼을 눌렀을 시 기존의 페이지로 이동
        • -기존의 페이지
          • 모든 센서 데이터 수치 라인 그래프로 출력
            • 기존과 동일
          • 모든 센서 데이터 수치 테이블로 출력
            • 기존과 동일
      • 3. Elasticsearch
        • 환자 개인 정보
          • index: patient_id
          • type: doc
          • id: <가상 환자 ID> (예: 100, 101…)
          • 필드 및 예시정보: patient_id/doc/100
        • 환자 센서 정보
          • index: patient-<가상 환자 ID> (예: 100, 101…)
          • type: doc
          • id: 무작위 생성
          • 필드 및 예시정보: patient-100/doc/n0CgHWUByu8EQ-Qm6xHc

당뇨병 환자를 위한 딥러닝 기반 CGM IoT 플랫폼

  • 2018-10-04
    • (가제) CGM IoT platform based on deep learning for diabetes patients
    • 논문 뼈대 대략적인 구성
    • 1. 서론
    • 2.이론적 배경
      • 2.1 뉴럴네트워크
      • 2.2 딥러닝
      • 2.3 Tensorflow
      • 2.4 MQTT
    • 3.  CGM IoT 플랫폼
      • 3.1 시스템 구성
      • 3.2 시퀀스 다이어그램
    • 4. 구현 및 테스트
      • 4.1 구현
        • LSTM 모델 생성
          • 사용한 JCHR 데이터 설명
          • LSTM 소스코드 첨부하며 파라미터들 설명
          • 모델 정확도 테스트(실제-예측 그래프 첨부)
        • IoT 각 부분(시뮬레이터, 구성도에서 연결부분)
      • 4.2 테스트
        • 시뮬레이터(CGM Device + IoT Device)
          • MQTT 프로토콜로 IoT Platform의 MQTT 브로커로 전송(소스코드)
        • 웹서버, 스마트폰앱(고/저혈당 알림화면) 캡처하며 설명
    • 5. 결론 및 향후 계획
    • 시스템 구성도
      • 여러개의 CGM 기계에 IoT Device(라즈베리파이나 비글본 등)를 연결하고, MQTT를 이용해 IoT Platform에 있는 MQTT Broker로 혈당 데이터 전송
      • IoT Platform에 있는 머신 러닝 예측 모델(ML Prediction Model)이 MQTT 브로커로부터 혈당 데이터를 받아 예측한 결과를 보고 고/저혈당일 시 Push Server로 전송
      • Push Server는 의사의 스마트폰으로 푸쉬 알림을 전송
      • Push 서버는 구글의 Firebase (FCM)을 이용. 별도 구성할 필요 없이 이용만 하면 OK
      • 모니터링 서버는 CGM Info DB(엘라스틱서치)와 통신해 의사의 스마트폰으로 실제 환자의 측정된 혈당 데이터를 차트로 모니터링 가능
    • 시퀀스 다이어그램
    • 구현 상황
      • (구현됨) 1. CGM Device -> IoT Device 는 파이썬 시뮬레이터로 대체. 5분에 한 번씩 slave6에 있는 MQTT 브로커로 혈당 정보를 전송함
      • (구현됨)2. slave6에 Node.js 구동중. 이는 MQTT Broker와 연결되어 시뮬레이터가 보낸 혈당을 받음
      • (구현됨)3. 받은 혈당을 Elasticsearch에 저장 (나중에 환자 혈당 정보 조회를 위함)
      • (미구현)4. Node.js가 머신 러닝 모델을 돌리고 결과를 받음. (텐서플로 모델 저장 부분에서 문제 발생)
      • (구현됨)5. Node.js가 Push Server(FCM)로 더미 데이터 전송함. (3이 아직 미구현이기 때문에 더미 데이터 전송)
      • (구현됨)6. Push Server(FCM)가 안드로이드 앱으로 고/저혈당 위험 사항 결과 전송받음
      • (구현됨)7. 모니터링 서버를 만들어 과거의 환자 혈당 데이터를 차트로 시각화 (이전에 병원전달용 CGM 서버 조금 변경함)
        • http://220.69.209.17:4071

 

  • 2018-09-11
    • 병원에 전달할 2차 CGM FFNN 결과 파일
    • 병원 + git 데이터 VS 병원 데이터 FFNN 비교 실험
    • LSTM 실험 결과
      • 학습데이터: git에서 구한 139_train.csv 1개
      • 실험데이터: git에서 구한 139_test.csv 1개
      • 반복횟수 500, AdamOptimizer(0.1) 적용
      • RNN 셀 갯수 25개 (git 코드와 동일)
      • 활성함수 ReLU 적용
      • PH +5 예측 (5분 뒤) : RMSE 약 16.39
  • 2018-09-06
    • 교수님 지도 사항
    • 실험
      • 데이터 분리 용어 정리
        • 환자 1명당 데이터 분리
          • 기존의 방식
          • 환자 1명당 그 환자 전체 데이터의 80%는 학습용, 20%는 시험용으로 분리한 것
          • 그렇기 때문에 총 16명 환자에 대한 시험 결과가 나옴
        • 환자 전체 데이터 분리
          • 새로운 방식
          • 16명 환자 데이터의 전체 80%를 학습용, 20%는 시험용으로 분리한 것
          • 12명의 환자 데이터를 학습용(80%)으로 사용
            • patientID: 85655,209019,365303,485709,553778,573060,579883,822250,839654,885633,895646,920087
          • 4명의 환자 데이터를 시험용(20%)으로 사용
            • patientID: 1007000,1185429,1393413,3008387
          • 그렇기 때문에 총 4명의 환자에 대한 시험 결과가 나옴
      • Question 1. 환자 1명당 데이터 분리시, PH+5와 PH+15별 RMSE는?
      • Answer 1.
        • PH+5 (5분뒤 예측, 즉 바로 다음 혈당 예측)와 PH+15 (15분뒤 예측, 즉 다다다음 혈당 예측)를 비교시 RMSE는 PH+15가 높음
          • 당연히, 더 먼 미래를 예측하는 것의 정확도가 낮을 수 밖에 없음

      • Question 2. 환자 1명당 데이터 분리시, PH+5와 PH+15별 RMSE의 표준 편차(SD)는?
      • Answer 2. 

      • Question 3. 환자 전체 데이터 분리시 PH+5와 PH+15별 RMSE는?
      • Answer 3.

      • Question 4. 환자 전체 데이터 분리시 PH+5와 PH+15별 RMSE의 표준 편차(SD)는?
      • Answer 4.

      • Question 5. 환자 데이터 분리 방식에 따른 RMSE (PH+5)
      • Answer 5.
        • PH+5의 경우만 나타냈지만 PH+15도 위와 비슷한 양상을 보임
        • 환자 전체 데이터 분리 방식이 환자 1명당 데이터 분리보다 훨씬 RMSE가 낮은걸 확인할 수 있음

      • Question 6. 환자 전체 데이터 분리시, 특정 환자의 PH+5와 PH+15별 실제-예측 그래프의 모양은?
      • Answer 6.
        • patientID가 1007000인 환자의 PH+5 테스트(RMES 약 3.56)
        • patientID가 1007000인 환자의 PH+15 테스트(RMES 약 8.33)
      • 실험 결과 자료
  • 2018-08-31
    • 텐서플로우 자체 세미나 (김수아)
  • 2018-08-30
    • 교수님 지도사항
      • 환자별로 테스트셋과 트레인셋을 분리할 것
        • ex) 환자 10명 데이터 전체는 트레인, 6명은 테스트 이런 식으로 분리
      • NN-CGM 논문 읽어보기
        • (실제값-예측값) 의 표준편차계산보다 논문에서 RMSE의 표준편차를 더 많이 씀
        • (예측값-실제값)^2 의 표준편차를 구해볼 것
      • PH가 5가 아닌 PH가 15도 계산해볼 것
        • 각각의 경우에 한해서 RMSE의 표준편차를 계산해볼 것
    • 전체 16명의 환자의 데이터에 대한 학습 (FFNN, 은닉계층 2개, 15뉴런, 선형활성함수)
      • 각 환자당 데이터의 80%는 학습용, 20%는 시험용 데이터로 분리후 실험
      • 미측정 데이터에 대한 보간(interpolate) 작업은 이루어지지 않고, 미측정된 구간은 0의 값으로 설정
        • ex) 아래와 같은 환자 데이터는 중간에 측정되지 않은 구간이 있음. 이런 구간은 모두 혈당치 0으로 설정하고 학습
      • (실제값-예측값)의 표준편차 계산
        • patientID (실제값-예측값)의 표준편차
          85655 12.42315225941561
          209019  25.508759152314173 (최대값)
          365303 14.302928964751395
          485709 9.18793178769357 (최소값)
          553778 12.245915979461149
          573060 15.69203688538201
          579883 15.656021348611832
          822250 17.243704343318765
          839654 22.487324538739117
          885633 15.194183148782226
          895646 21.543522156082716
          920087 16.136867882610808
          1007000 11.481246694308432
          1185429 19.911880364257804
          1393413 22.487324538739117
          3008387 9.22691648568163
      • 각 환자별 예측-실제 혈당 그래프
        • 위의 표준편차 표의 patientID와 같은 순서로 그래프가 나열됨
  • 2018-08-28 세미나 교수님 코멘트
    • 1 데이터 interpolation – 코드 참고
      2 정확도 측정을 위해 고혈당/저혈당 …
      – 하지만 지금 가진 데이터는 고/저혈당 환자가 적습니다
      – 찾으면 있을것이다
      3. 오차평균값, 표준편차값. 이해 후 내부 내용 이해
      – 텐서플로 첫걸음 책 2,3장 다같이 세미나
      – 2장 regression 및 gradiant descent 3장 tensor에 대한 구조 이해, shape
      – 세미나 ppt cs2에 업로드하기병원에서 피드백 올 때까지,,,현재 한 것 : 같은 모델에 같은 데이터
      해야 할 것 : 같은 모델에 테스트 데이터
  •  2018-08-14
    • UCI 데이터셋 분석 …
    • 스마트폰 기반 행동인식 기술 동향 참고문헌 16번 (CNN을 사용한 방법이 95%의 정확도로 가장 높은 성능을 나타내고 있다)

openHAB2를 사용한 MQTT 기반 Edge Computing

2018.10.02 (세미나 이후)

  • 한범
    • 관련연구 내용 줄이고, 세부항목 합치기
    • 본론 → IoT 시스템 구성도
    • 엣지컴퓨팅 시나리오 및 구성도 작성 ( 농장 )
    • Node-RED 다이어그램 그림 필요?
    • 강조내용 : IoT 주요 프로토콜 중 하나인 MQTT를 기반으로 해서 IoT 환경에서 엣지 컴퓨팅 구현.
      엣지 컴퓨팅의 서비스 구성은 사용자가 자유롭게, Node-RED를 통해서 구성 가능함을 작성할 것.
    • 수정 사항 :
      1) 서론 / 관련연구 내용 요약
      2) 시나리오 이미지 추가
      3) 구성도 이미지 수정. (IoT Platform 부분 세분화 필요)

2018.10.02

  • 한범

 

2018.09.21 (면담 전)

  • 상현
    • openHAB rule 작성 공부
      • 각 서비스는 openHAB2 에서 사용되는 Xtend (rule 스크립트) 언어로 작성
    • 가용 서비스
      • 센서 값 모니터링 -> 게이지, 차트 등
      • 액추에이터 상태 모니터링 -> 액추에이터도 센서와 마찬가지로 지속적으로 상태 전송 예) open/closed
    • IoT 플랫폼
      • Node-red 상에서 openHAB2 스크립트 작성파일 전송
  • 한범
    • 논문 작성
      • 서론 : IoT 서비스에서 사용되는 클라우드 컴퓨팅의 동향과 일부 문제점 서술. 그에 따른 에지 컴퓨팅의 소개와 에지컴퓨팅을 통해 구현한 IoT 서비스 제안
      • 이론적 배경 : openHAB2, MQTT의 내용설명
      • 시스템 구성 및 구현 설계 : 위의 두 프로그램을 어떤식으로 사용하였으며, IoT 서비스의 구성내용 설명
        • Node-Red를 통해서 openHAB2 스크립트 작성 파일 다운로드 기능 구현
        • 웹 인터페이스를 통해 보여줄 수 있어야 함.
        • 등록, 모니터링 / 제어, 서비스 설치, 서비스 실행 등에 관련된 플로우 차트 작성?
    • 구성도
      • Non-ip 디바이스 상에서 MQTT Client를 동작시키는 방법 모색
      • MQTT-SN 조사

2018.09.14 (면담 전)

  • 상현
    • GateWay  웹 인터페이스 구상
      • 로그인 및 회원 가입(Elastic Search에 회원 정보 등록)
      • 가용한(다운로드) 서비스  목록(드롭 다운 또는 라디오 버튼 등)
        -차트(일별 온도 현황/시간 별 평균 온도 값 확인)
        -디바이스 등록(Elastic Search에 디바이스 등록)
      • 알아 볼 것
        -Node-Red 대시보드 사용 시  Elastic Search 노드 내 도큐먼트, 또는 타입 생성
        -Node.js 웹 페이지 사용 시 동일 과정 학습
  • 한범
    • 임시 시나리오 작성
      • 과수원 시나리오 : 과수원 관리를 위해 사용하는 각종 디바이스를 효율적으로 관리할 수 있는 IoT 서비스 설계
        • 사용자 : 일반 사용자 / 관리자
          – 일반 사용자 : 디바이스 등록, 디바이스 모니터링 · 제어, 서비스 등록
          – 관리자 : Gateway, Device 단에서 모니터링 · 제어, 고장상태 확인
      • 필요한 것
        • 디바이스 등록과정, 센서 데이터 전송 / 액츄에이터 제어 과정
        • 서비스 등록과정
    • 서비스 구성 (임시)
      • 상황인지 – ex : 현재 습도량에 따라 스프링 쿨러 동작
      • 고장 감지 – ex : 센서값이 비정상적으로 증가하거나 감소, 혹은 변동이 없는 경우
      • 센서 데이터 특정 시간별 평균 산출 – ex : 시간별 평균 온도값 계산
      • 이벤트 (긴급상황) – ex : 화재가 발생하였을 경우, 스프링쿨러에 있는 디바이스에서 상황을 인식하고 작동
    • 클래스 다이어그램


 

2018.09.06 (면담 후)

  • 한범
    • 키워드 : 스마트 디바이스, IoT 게이트웨이, 클라우드, Node-RED IoT 서비스 구성, 스크립트 다운로드
    • Edge Computing 시나리오
      • 게이트웨이 상에서의 Edge Computing
      • 스마트 디바이스 상에서의 Edge Computing
    • 아이디어
      • 다현이의 논문과 다르게, 이미 전부 디바이스 정보가 등록이 되어있다고 가정하고 진행되는 시나리오
      • openHAB2를 이용하여 Edge Computing을 구현
        • openHAB2에 대한 인터페이스 구성을 위한 스크립트를 클라우드로부터 다운로드 받음 ( 클라우드에서 서비스를 구성한 결과에 따라 스크립트 변환 )
        • Edge Computing 근거 및 활용 이유 기술과 Edge Computing을 위해 openHAB2를 활용하였음을 기술

 

2018.09.06

  • 상현
    레퍼런스 논문(청와대 논문) 내 디바이스 관리자 서비스는 관리자 에이전트를 도와
    디바이스를 관리하며 각 IoT 응용을 자바 웹 응용으로 구현

    Node-Red DashBoard로 구현한  Web Interface 는 자바 웹 응용보다  GPIO 컨트롤을 통한 IoT 응용 배치가 손쉽게 가능하다.
    관련 영상 링크 : https://www.youtube.com/watch?v=RA06ee3jahM라즈베리 파이 내 설치된 Node-Red DashBoard를 통해 웹 인터페이스를 구현하여
    연구실 내 브레드 보드 , LED로 조작, 및 현재 상태를 MQTT Broker를 통해 클라우드까지 전달되는지 시험해보고자 함
  • 다현
    • MQTT 기반 스마트 디바이스
    • 논문 시나리오 작성(디바이스를 중심으로), IoT Platform 포함 가능
    • 논문 개요 작성
    • 스마트 디바이스 서비스 : 초기화, 데이터 발행 및 구독, 센서 및 액추에이터 관리
  • 한범
    • openHAB2를 활용한 MQTT 기반 Edge Computing
    • 메시지 다이어그램 작성 필요
    • 메시지 다이어그램 작성 후, 클래스 다이어그램 작성
      • 현재 서비스 구상 : 상황인지 / 고장감지 / 평균 값 산출 / 차트
      • 클래스 다이어그램 수정 필요
    • Device Discovery 용어 변경 필요 ( 역할 : 디바이스 등록 시, IoT Platform으로 부터 Mac에 따른 Device Id 값으로 변환하고, 변환된 값으로 토픽을 구성하여 디바이스에 전송)
    • 논문 시나리오 작성(게이트웨이를 중심으로)

2018.08.30 (면담 전)

  • 한범

    • 구조도 작성 (최종)
    • 메시지 플로우 차트 작성
    • 실제 구현한 프로그램의 클래스 다이어그램 / 모듈 다이어그램 작성
    • Device agent 중, 작성한 프로그램 수정
      • 메타데이터 캐싱 프로그램
      • 스크립트 작성 프로그램
  • 다현
    • 제조사 등록 및 농민 등록은 웹 상에서 이루어지는 동작이지만 농민 등록은 데이터 플로우 작성 가능
    • 디바이스 데이터 플로우 작성 및 코딩 전 클래스 다이어그램 작성
    • 5개 지역 등록 및 서비스 시나리오 상현오빠랑 얘기할 것
    • 추계 논문 작성
  • 상현Smart Device 기반 IoT 서비스 구성IoT 서비스 구성단계
    Use Case 작성할 것(농민의 요구에 따라 서비스를 구성하는 설치 기사 관점)


    온도 데이터에 대해 사용자에게 보여질 서비스 예)

    온도 데이터는 Node-Red DashBoard의 노드, gauge를 통해 표현, 제어 메시지는
    Button 노드와 연결된 MQTT 노드와의 연동을 통해 제어 토픽을 구독하고 있는 디바이스에 전송 가능
    이처럼 elastic search 내 타입별 센서 데이터에 대하여 Node-Red dashboard의 기능을 통한 서비스가 생성 가능
    , 더 나아가 템플릿 노드를 통해 html 페이지도 보여줄 수 있어 JavaScript 라이브러리를 통한 다양한 구현도 가능