시간값 앞에 어떤 시계인지 적는다
초 단위 숫자가 둘 있다고 바로 뺄 수 있는 것은 아니다. System Time은 운영체제의 시계와 연결된다. 날짜를 표현하거나 외부 기록을 대조할 때 유용하지만 시간 보정으로 값이 바뀔 수 있다. Steady Time은 경과 시간 측정에 사용하는 단조 시계다. 같은 기기의 같은 시간원에서 두 사건 사이를 재는 데 적합하며 날짜나 다른 기기의 단조 시계 원점과 자동 대응하지 않는다. 단조라는 말은 계산이나 콜백이 정해진 기한에 실행된다는 보장이 아니다.
ROS Time은 ROS 시스템의 시간 추상화다. 별도 ROS 시간원이 활성화되지 않았을 때는 시스템 시간을 따른다. 노드의 use_sim_time=true로 시간원이 활성화되면 /clock으로 받은 시뮬레이션/재생 시간값을 따른다. 노드별 설정이므로 한 노드만 바꿨다고 모든 소비자가 같은 시계를 쓰는 것은 아니다. 첫 clock 표본을 받기 전의 0은 미초기화 상태로 취급해야 하며, 이를 정상 경과 시간으로 계산하지 않는다. 시뮬레이션 시작이나 reset의 0과도 맥락을 함께 기록한다.
시뮬레이션이나 재생은 시간을 멈추거나 빠르게 진행하고 뒤로 돌릴 수 있다. /clock이 5.0 s에서 멈춘 동안 벽시계 2 s가 흘러도 ROS 시간의 차이는 0일 수 있다. ROS 시간으로만 수신 중단을 재면 멈춘 시뮬레이션에서 경과가 늘지 않는다. 반대로 외부 장치의 통신 경과 시간이나 실물 watchdog에는 같은 기기의 steady 시계가 적합할 수 있다. 실제 설계에서는 상태와 시간원의 의도를 명시해야 하며, 이 단위는 실물 watchdog을 실행하지 않는다.
센서 획득 stamp가 ROS 시간 4.90 s이고 판단 시각도 같은 ROS 시간 5.00 s라면 관측 나이는 0.10 s=100 ms다. 판단 시각이 Unix 시스템 시간의 큰 숫자라면 그대로 빼서는 안 된다. 서로 다른 컴퓨터의 시스템 시계도 동기화 오차를 확인해야 한다. 시간 비교에는 시계 종류·동일한 기준·단위·동기화의 확인 범위를 붙인다. 기존 1.5의 시간 경계를 이 관점으로 읽는다.
주기·처리 시간·관측 나이를 따로 계산한다
목표 주기 T는 반복 작업의 목표 시작 간격이다. 여기서 T=20 ms면 목표 빈도는 1/0.020 s=50 Hz다. 합성 시작 시각이 steady 기준 0, 20, 43, 60 ms라면 실제 시작 간격은 20, 23, 17 ms다. 이 단위의 jitter는 각 간격에서 목표 주기를 뺀 편차로 정의하므로 0, +3, −3 ms다. 최대 절댓값은 3 ms다. 다른 자료가 jitter를 표준편차나 최대-최소로 정의할 수 있으므로 계산 규약을 먼저 적는다.
같은 작업의 처리 시간이 각각 5, 6, 8, 4 ms라면 완료 시각은 5, 26, 51, 64 ms다. 예정 시작 시각 0, 20, 40, 60 ms에서 다음 예정 시작까지인 20, 40, 60, 80 ms를 각 작업의 완료 기한으로 정하면 모두 기한 안이다. 세 번째 작업은 예정 40 ms보다 3 ms 늦게 시작했지만 51 ms에 끝나 완료 기한 60 ms는 지켰다. 시작 지연과 완료 기한 위반은 다른 판정이다.
처리 시간 8 ms가 주기 20 ms보다 작다는 이유만으로 전체 지연이 8 ms인 것도 아니다. 입력의 생성·전송·대기·콜백 시작·처리·출력 전달이 따로 있다. 반대로 로그의 시작 간격이 흔들렸다는 사실만으로 네트워크가 원인이라고 확정하지 않는다. Executor의 긴 콜백, 운영체제 스케줄, 잠금, 기록 부하도 구분해야 한다. 목표 빈도를 설정하는 API와 실제 실행 기한 보장은 다른 증거다.
수신 중단과 오래된 자료는 다르게 찾는다
현재 ROS 시간이 10.0 s이고 최근 받은 메시지 stamp가 같은 ROS 시간 9.7 s라면 자료 나이는 300 ms다. 그 메시지를 같은 호스트의 steady 시각 100.00 s에 받았고 현재 steady 시각이 100.04 s라면 마지막 수신 뒤 경과는 40 ms다. 네트워크로 최근에 도착했어도 내용은 이미 오래될 수 있다. ‘최근에 받았으니 새 관측’이라는 추론은 성립하지 않는다. 이 예의 응용 규칙을 자료 나이>100 ms는 오래됨, 수신 경과>80 ms는 수신 중단 의심으로 정하면 첫 조건만 만족한다. 이 임계값은 교육용 가정이며 실제 장치 기준이 아니다.
통신 장애에도 발견 실패·패킷 손실·재전송 지연·수신 대기·응용 처리 정체가 있다. 노드 목록에서 보인다고 계속 건강한 연결임을 보장하지 않으며, deadline이나 liveliness 사건도 특정 물리 원인을 자동 진단하지 않는다. 송신 순번과 생성/수신/처리 시각, 양쪽의 실행·QoS·발견 상태를 모아 어느 단계가 멈췄는지 조사한다. 같은 네트워크에 있다는 이유로 임의 방화벽 해제나 전체 설정 초기화를 해결 절차로 삼지 않는다.
재연결 뒤에는 오래된 보관 자료나 이전 실행의 순번을 새 명령으로 오해할 수 있다. 실행 세대 식별자와 순번, stamp, 유효 기간을 함께 확인한다. 시뮬레이션 시간이 10 s에서 2 s로 되돌아가면 이전 stamp 9.7 s를 단순히 빼서 음수 나이가 나온다. 이를 ‘아주 신선함’으로 통과시키지 않고 시간 점프와 캐시/목표 상태의 재초기화 정책을 적용해야 한다. 미분·적분에 쓰는 시간 간격도 0이나 음수면 정상 업데이트로 넣지 않는다. 구체적인 재초기화 범위는 응용 계약이며 모든 노드가 같은 처리를 자동으로 해주는 것은 아니다.
복구는 메시지 하나가 다시 왔다는 사건보다 넓다. 같은 실행 세대의 올바른 타입/프레임·시간 기준과 유효한 자료, 준비 상태가 회복됐는지 확인한다. 기록 재생의 시간원과 실물 경과 시간의 요구가 섞이지 않도록 구분하고, 필요하면 안전한 보류 상태에서 수동 검토를 거친다는 설계를 기록한다. 이는 종이 설계 판정이며 실제 장비의 정지나 재개를 지시하는 활동이 아니다.