살아 있다는 신호와 유효한 행동은 다르다
watchdog은 정한 사건/신호가 필요한 시간 안에 갱신되는지 관찰하고, 조건을 벗어나면 정해 둔 대응을 시작하는 감독 수단이다. heartbeat는 구성요소가 주기적으로 보내는 생존/진행 신호다. 신호가 새로 왔다고 센서 관측/정책 결과·물리 상태가 모두 정상이라는 뜻은 아니다. heartbeat 생성 경로가 실제 작업 진행과 어떻게 연결되는지도 정해야 한다.
정책 추론은 멈췄는데 별도 timer가 heartbeat만 계속 낼 수 있다. 반대로 관측은 도착하지만 명령/구동 피드백이 끊길 수 있다. 그러므로 heartbeat 나이, 근거 관측의 나이, 명령의 발행/적용·유효기간과 작업 진행을 다른 열로 검사한다. 메시지에 신선한 봉투를 씌웠다는 사실로 오래된 관측이 새로워지지 않는다. M27의 ID/clock·task/모델 버전과 출력 제한을 함께 사용한다.
감독의 입력은 유효해야 한다. 같은 clock에서 나이를 차분하고 음수/역전·재시작/단절은 별도 오류/미상으로 처리한다. 실제 경과 timeout을 정지할 수 있는 simulation clock에 그대로 맡기면 시뮬레이션 정지 중에도 경과 조건이 변하지 않을 수 있다. ROS 시간 설계를 연결해 관측의 ROS stamp와 내부 경과 감독의 시계/정합을 구분한다.
세 나이를 각각 계산한다
합성 감독 표의 시각은 모두 같은 단조 시계의 초 단위다. 마지막 heartbeat=1.000 s, 허용 나이는 0.150 s 이하로 정한다. 현재 1.120 s이면 나이는 0.120 s/여유 0.030 s다. 현재 1.180 s이면 나이는 0.180 s로 0.030 s 초과한다. 경계 0.150 s는 통과하도록 과제 규칙을 정했으며 실제 시스템 임계값을 권고한 것이 아니다.
그림 M30.04-1. 각 칸은 서로 다른 역할/근거다. 나란히 비교할 항목이며 위아래가 시간 순서를 뜻하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
현재 1.180 s에 새 heartbeat 1.170 s를 받았다고 하자. heartbeat 나이는 0.010 s로 통과하지만 근거 관측이 0.950 s면 관측 나이는 0.230 s다. 최대 관측 나이 0.100 s 조건은 0.130 s 초과다. 명령 발행이 1.150 s/입구 TTL이 0.050 s라면 명령 나이 0.030 s는 통과한다. 이때 heartbeat/명령 입구는 통과하나 관측 조건은 실패다.
TTL(time to live)은 이번 표에서 명령을 새로 받아들일 수 있는 발행 뒤 기간이다. 실행 시작 뒤 그 시간이 지나면 자동으로 실제 축이 정지한다는 뜻은 아니다. 동작 중 lease/갱신·실행 deadline과 장애 시 대응이 필요하면 별도 계약으로 정한다. 과제는 관측 실패이면 새 동작을 보류하고 실행 중인 동작의 상태를 확인/중단 정책으로 넘기는 것으로 정한다. 새 동작 보류와 이미 실행 중인 명령의 실제 정지는 다른 사건이다.
실행 전에 증거의 단계를 나눈다
오프라인 replay는 저장한 입력을 정책/검사 경로로 재생해 계산/거부 결과를 확인하는 단계다. 출력이 구동 경로로 전달되지 않는지 명시하고 실제 상황의 피드백이 새 행동 때문에 바뀌지 않는다는 한계를 남긴다. 고정 기록 재생만으로 실제 폐루프 성공을 측정할 수 없다. 데이터를 읽는 장치가 실제 로봇 옆에 있더라도 출력 연결이 없다면 실물 운전과 구분한다.
shadow는 이 단위에서 현재 관측으로 후보를 계산/비교하되 제어 명령으로 전달하지 않는 구성으로 정의한다. 계산/시간·계약/한계 위반을 관찰할 수 있지만 실제 행동의 결과를 입증하지 않는다. 기존 제어기가 따로 장비를 움직이는 shadow라면 그 동작의 명령 주체도 분리한다. 'shadow 성공'이라는 말 대신 어떤 관문을 통과했는지 기록한다.
제한 실행은 별도 권한/장비 절차가 갖춰진 경우 정의된 속도/공간·과업/시간 범위로 실제 동작을 허용하는 단계다. 이 교재의 기본 과제는 제한 실행을 하지 않고 필요한 입력/판정만 설계한다. 시뮬레이션·replay/shadow의 통과를 실제 실행 허가로 자동 승격하지 않는다. 승격에는 담당 주체·현재 상태/관측, 버전/인터페이스와 출력 제한·중단 경로/복구 절차, 조건별 시험 근거가 필요하다.
교육용 감독 상태는 ROS lifecycle 상태와 구분한다
이 과제의 상태를 준비, 비실행 검증, shadow, 제한 실행, 중단 처리, 상태 미상, 복구 검토로 정한다. 이는 설명을 위한 응용 상태이며 ROS lifecycle에 새 primary state를 추가한 API가 아니다. ROS managed nodes 설계의 Unconfigured/Inactive/Active 같은 상태는 구성/활성화 관리의 기반이고, 여기의 과업/운영 상태는 그 위에서 따로 관리한다.
ros2_control Jazzy 하드웨어 lifecycle 문서도 하드웨어 상태/인터페이스 처리를 설명하며 구현/현재 제약을 확인해야 한다. 따라서 lifecycle deactivate 요청/응답이나 소프트웨어의 중단 flag 하나를 장치 전원 차단·브레이크/물리 정지의 증거로 쓰지 않는다. 실제 driver/장비의 명령/상태와 해당 절차를 확인해야 한다.
합성 로그가 '제한 실행 중→heartbeat 초과→중단 요청→요청 수락'까지만 있고 최종 결과/현재 속도·물체 상태가 없다면 중단 요청/수락은 확인되었고 실제 결과는 미상이다. 상태표에서 바로 준비/성공으로 돌리지 않는다. 이미 전달한 명령의 큐/driver 행동과 결과·복구 전제를 추적한다. watchdog 사건이 있었다는 기록과 실제 대응 완료의 시각/근거도 나누어 남긴다.
감독기가 실패할 때의 경로와 재개를 설계한다
감독이 감시 대상과 같은 thread/프로세스·전원/통신 경로에 의존하면 그 공통 실패 때 함께 멈출 수 있다. 독립적인 관찰/차단 경로를 고려하더라도 모든 고장을 막는다고 단정하지 않고, 무엇을 관찰하고 어떤 경로로 대응하며 그 결과를 어떻게 확인하는지 적는다. 소프트웨어 watchdog은 인증된 안전 기능/물리 비상 정지나 장비 위험 평가를 대신하지 않는다.
재개에는 새 heartbeat 한 번보다 많은 조건이 필요하다. 실제 장치/goal·파지/장면/관측의 현재 상태, 원인 조치/버전·권한, 큐/필터/ensemble의 초기화·재검증과 중단 수단을 확인한다. 정의된 복구 절차에서 이전 단계로 돌아가며 다음 tick에 무조건 재실행하지 않는다. 기존 6.4 안전 배포 감독기의 교육 모형을 이 상태표와 비교하자. 아래 과제는 실제 정지/승격을 수행하지 않는다.