Raspberry Pi 두 대로 구성한 졸음 모니터의 sensor-to-alarm data path

두 Node로 나눈 이유

PPG 신호 취득과 camera 기반 EAR 계산은 입력 주기와 처리 부하가 다르다. 한 Raspberry Pi에서 모두 처리하면 camera frame 처리 지연이 PPG 읽기와 alarm timing에 영향을 줄 수 있다. 이 prototype은 sensing과 analysis를 두 node로 나누고 네트워크와 file IPC로 상태를 전달한다.

이 분리는 성능 향상을 자동으로 보장하지 않는다. 대신 각 node가 맡은 입력, 저장 파일, packet, output을 따로 추적할 수 있게 한다.

PPG Node와 Camera Node

PPG sensing node는 sensor sample을 읽고 heart-related 값과 상태를 만든다. Camera/EAR node는 frame에서 눈 영역을 처리하고 EAR 기반 상태를 계산한다. 공개 C/C++ source와 architecture 문서가 두 경로의 존재를 지원한다.

통합 판단은 PPG 값과 vision 상태가 전달된 뒤 alarm 조건을 조합하는 단계에서 이뤄진다. 사진만으로 알고리즘 threshold나 정확도를 복원할 수 없으므로 source에서 확인되는 모듈 경계와 prototype 배선 근거를 분리한다.

Packet·File·GPIO·I2C 경로

PPG sensor → sensing process → TCP/IP or shared file state
camera → frame processing → EAR state
PPG state + EAR state → decision path
decision → GPIO LED/buzzer + I2C LCD

TCP/IP 경계에는 sender/receiver address, message length, reconnect 정책이 필요하다. File IPC는 producer가 쓰는 중 consumer가 읽지 않도록 임시 파일과 atomic rename 또는 명시적 ready flag가 필요하다. GPIO는 LED·buzzer의 active level, I2C는 LCD address와 update 실패 처리까지 기록해야 재현할 수 있다.

소스의 통신 경로는 network·file IPC·GPIO·I²C다. 복구 동작 평가에는 packet schema·timeout·packet loss·stale file 처리 조건이 필요하다.

실제 Prototype에서 확인한 것

Raspberry Pi·LCD·센서 배선·조립 사진과 PPG server·image/EAR 처리 소스가 두 node의 데이터 경로를 보여준다. 화면 값의 자료 유형은 프로토타입 출력이다.

실패처리와 미측정 항목

분산된 두 node에서 필요한 실패처리는 camera frame 누락, TCP 연결 끊김, 오래된 file state, I2C write 실패, sensor read timeout이다. 현재 공개 자료만으로 각 실패가 어떤 retry와 fallback을 거치는지 모두 검증할 수 없다.

프로토타입 기록: 장비 사진·PPG server·image/EAR 처리 모듈·경고 경로. 후속 측정 지표: end-to-end latency·sensitivity·specificity·false-alarm rate·장시간 안정성.

다음 검증

다음 단계는 message schema와 monotonic timestamp를 고정하고, 각 node에서 동일 event ID를 log하는 것이다. 의도적으로 network를 끊거나 camera 입력을 중단해 alarm path가 안전한 상태로 이동하는지도 확인해야 한다. 그 전까지 prototype 존재와 성능 주장을 분리한다.