3단계 명세(PHASE-3-PROTOCOL, v1.0.0)는 청소 로봇의 네트워크 프로토콜, 보안 요구 사항, 기기 탐색, 펌웨어 업데이트 방식을 정의한다. 제5장의 API가 "무엇을 주고받는가"를 정했다면, 3단계는 "어떤 통로로, 얼마나 안전하게 주고받는가"를 정한다.
로컬 네트워크에서 명세가 지원하는 프로토콜은 다음 네 가지다.
| 프로토콜 | 용도 |
|---|---|
| HTTP/HTTPS | REST API(제5장) |
| WebSocket/WSS | 실시간 상태 업데이트 |
| MQTT | 발행/구독(pub/sub) 메시징 |
| mDNS/Bonjour | 기기 탐색 |
이 밖의 프로토콜(예: CoAP, gRPC)은 표준에 포함되지 않는다. 필요하다면 명세 9.2절이 허용하는 프로토콜 변환 미들웨어(HTTP-MQTT 브리지, WebSocket-gRPC 변환, 기존 프로토콜 어댑터)나 x_ 접두사를 붙인 제조사 확장으로 제공해야 하며, 이는 비표준 확장임을 분명히 밝혀야 한다.
MQTT 토픽은 다음 구조를 따른다.
wia/rob/{robot_id}/{category}/{subcategory}
명세가 정의하는 표준 토픽은 다음과 같다.
wia/rob/{robot_id}/status
wia/rob/{robot_id}/battery
wia/rob/{robot_id}/position
wia/rob/{robot_id}/sensors/lidar
wia/rob/{robot_id}/sensors/camera
wia/rob/{robot_id}/map/update
wia/rob/{robot_id}/command
wia/rob/{robot_id}/event
토픽에 실리는 메시지 본문은 제4장의 1단계 형식을 따른다. 예를 들어 command 토픽에는 RobotCommand, event 토픽에는 RobotEvent 문서를 발행한다. MQTT 와일드카드를 쓰면 한 로봇의 센서 전체(wia/rob/{robot_id}/sensors/#)나 여러 로봇의 상태(wia/rob/+/status)를 한 번에 구독할 수 있다.
| 메시지 종류 | QoS | 의미 |
|---|---|---|
| 상태 업데이트 | 0 | 최대 한 번 전달(fire and forget) |
| 명령 | 1 | 최소 한 번 전달 |
| 중요 경보 | 2 | 정확히 한 번 전달 |
명령이 QoS 1로 전달되면 같은 명령이 두 번 도착할 수 있다. 따라서 로봇은 RobotCommand의 commandId를 기억해 중복 명령을 한 번만 실행하도록 구현하는 것이 좋다.
TLS 1.2 이하로의 연결은 허용되지 않는다. 전송 구간에서는 모든 네트워크 통신에 TLS 1.3을 쓰고, 클라우드 동기화에는 종단간 암호화를 적용한다. MQTT와 WebSocket도 각각 TLS 위에서(MQTTS, WSS) 동작해야 한다.
지도와 카메라 이미지는 집이나 시설의 구조, 사람의 모습을 담고 있으므로 특히 이 요구 사항을 엄격히 지켜야 한다.
로봇은 mDNS로 자신을 네트워크에 알린다. 서비스 타입과 TXT 레코드는 다음과 같다.
Service Type: _wia-rob._tcp Port: 8080 TXT Records: - version=1.0.0 - manufacturer=CompanyName - model=ModelName - serial=SerialNumber - capabilities=slam,camera,mopping
탐색 절차는 다섯 단계다.
1. 업데이트 확인 GET /firmware/check
Response: { "available": true, "version": "1.2.0", "size": 25600000,
"checksum": "sha256hash", "url": "https://..." }
2. 펌웨어 내려받기 GET /firmware/download (진행률과 함께 바이너리 스트림)
3. 체크섬 검증 클라이언트 측 SHA-256 검증
4. 설치 POST /firmware/install
Response: { "status": "installing", "estimatedTime": 300 }
5. 재부팅 설치 후 자동
6. 버전 확인 GET /robot/status 의 firmwareVersion 필드 확인
POST /firmware/rollback| 동기화 데이터 | 주기 |
|---|---|
| 상태 | 실시간(WebSocket) |
| 지도(암호화) | 갱신될 때마다 |
| 청소 이력 | 하루 한 번 일괄 |
| 설정 | 변경될 때 |
명세는 클라우드 API의 예시로 https://cloud.wiastandards.com/api/v1 아래의 POST /robots/register, GET /robots/{robot_id}/status, PUT /robots/{robot_id}/config, GET /robots/{robot_id}/history, POST /firmware/update를 제시한다. 로봇이 직접 제공하는 로컬 API(/api/v1/robot/..., 제5장)와는 경로 체계가 다르다는 점에 유의한다.
3단계는 주요 스마트 홈 규격에 청소 로봇을 어떻게 대응시키는지도 정한다. 연동의 실제 구성은 제7장에서 다룬다.
| 플랫폼 | 명세의 매핑 |
|---|---|
| Matter/Thread | 기기 유형 Robotic Vacuum Cleaner(0x0074), 필수 클러스터 On/Off, Fan Control, Robot Vacuum Mode, Battery Status(명세의 비공식 명칭) |
| Apple HomeKit | 서비스 유형 Fan, 특성 On(필수), Rotation Speed(흡입력), Current/Target Fan State |
| Amazon Alexa | 청소 시작, 특정 방 청소, 배터리 확인 음성 명령 |
| Google Home | 트레잇 OnOff, FanSpeed, EnergyStorage |
정오 표기: 3단계 명세 문서는 Matter 기기 유형 번호를 0x0073으로 적고 있으나 이는 오기이다. Matter 기기 라이브러리에서 0x0073은 세탁기(Laundry Washer)이며, 로봇 청소기(Robotic Vacuum Cleaner)는 0x0074이다. 또한 위 표의 클러스터 이름은 명세가 붙인 비공식 명칭일 뿐 Matter의 실제 클러스터 이름이 아니다. 실제 구현에서는 RVC Run Mode, RVC Clean Mode, RVC Operational State, Power Source 클러스터를 기준으로 삼아야 한다.
GET /health
Response:
{
"status": "healthy|degraded|unhealthy",
"checks": { "battery": "ok", "sensors": "ok", "navigation": "ok", "network": "ok" },
"uptime": 86400
}
GET /diagnostics/logs?level=error&limit=100
진단 로그는 시각, 수준(error·warning·info·debug), 구성 요소, 메시지로 이루어진다.
명세 9.3절은 성능 최적화 방법으로 지속 연결 유지, TLS 세션 재사용, 핸드셰이크 최소화, 텍스트 데이터의 gzip 압축, 센서 스트림의 바이너리 프로토콜, 대역폭에 따른 적응형 압축을 든다.
연결이 끊기면 주 서버 → 보조 서버 → 로컬 모드 순으로 전환한다. 복구 절차는 다음과 같다.
명세 10절은 인증을 위한 필수 시험으로 TLS 핸드셰이크 검증, 인증 흐름 시험, 데이터 형식 유효성 검증, 오류 처리 검증, 성능 벤치마크를 요구하며, 인증 제품은 매년 보안 감사를 받아야 한다. 이 내용은 제8장의 체크리스트에 반영되어 있다.
wia/rob/{robot_id}/{category}/{subcategory} 구조를 따른다_wia-rob._tcp를 사용한다R-17인 로봇의 LiDAR 데이터 토픽을 적어라.