1261.54 행동 제어를 위한 통신 인프라 설계 원칙
1. 설계 원칙의 필요성
로봇 행동 제어 시스템의 통신 인프라는 센서 데이터의 수집, 상태 추정, 행동 결정, 액추에이터 명령 전달의 전체 처리 체인을 연결하는 핵심 기반이다. 통신 인프라의 설계가 부적절하면 제어 루프의 지연 증가, 메시지 손실, 교착 상태, 비결정론적 동작 등의 결함이 발생하며, 이는 로봇의 안전성과 임무 수행 성능에 직접적인 영향을 미친다.
행동 제어를 위한 통신 인프라 설계는 기능적 정확성(functional correctness)뿐 아니라 시간적 정확성(temporal correctness), 신뢰성(reliability), 확장성(scalability), 유지보수성(maintainability)을 동시에 충족하여야 한다. 본 절에서는 이러한 요구를 체계적으로 달성하기 위한 설계 원칙을 제시한다.
2. 원칙 1: 데이터 흐름의 명시적 정의
행동 제어 시스템의 통신 인프라를 설계할 때, 모든 데이터 흐름(data flow)을 명시적으로 정의하고 문서화하여야 한다. 데이터 흐름의 정의에는 다음의 요소가 포함된다.
| 정의 요소 | 설명 |
|---|---|
| 발행 노드 | 데이터를 생성하고 발행하는 노드의 이름 |
| 수신 노드 | 데이터를 수신하고 처리하는 노드의 이름 |
| 토픽/서비스/액션 이름 | 통신 채널의 식별자 |
| 메시지 타입 | 교환되는 데이터의 구조적 정의 |
| 발행 주기 | 데이터 발행의 주기 또는 이벤트 발생 빈도 |
| QoS 프로파일 | 신뢰성, 내구성, 기한 등의 품질 정책 |
| 최대 허용 지연 | 발행에서 수신까지의 최대 허용 지연 |
이러한 데이터 흐름 정의는 노드 간 의존 관계(dependency)를 시각화하는 데이터 흐름 그래프(data flow graph)로 표현할 수 있으며, 시스템의 구조적 분석과 병목 지점 식별에 활용된다.
3. 원칙 2: 통신 패러다임의 적합한 선택
각 데이터 흐름에 대하여 가장 적합한 통신 패러다임(토픽, 서비스, 액션)을 선택하여야 한다. 선택 기준은 다음과 같다.
| 데이터 특성 | 적합한 패러다임 | 근거 |
|---|---|---|
| 연속적 센서 데이터 스트림 | 토픽(Topic) | 비동기적, 주기적 발행에 최적화 |
| 즉각적 요청-응답 | 서비스(Service) | 동기적 일회성 호출에 적합 |
| 장시간 실행 작업 | 액션(Action) | 피드백, 취소, 결과 수신 지원 |
| 일대다 브로드캐스트 | 토픽(Topic) | 복수 구독자에 동시 전달 |
| 상태 조회 | 서비스(Service) | 특정 시점의 상태 반환 |
| 네비게이션 목표 | 액션(Action) | 진행 상황 피드백과 취소 지원 필요 |
통신 패러다임의 혼합 사용이 권장되며, 단일 패러다임으로 전체 시스템을 구성하는 것은 비효율적이다.
4. 원칙 3: QoS 프로파일의 의도적 설계
모든 통신 채널에 대하여 QoS(Quality of Service) 프로파일을 명시적으로 설정하여야 한다. 시스템 기본값에 의존하면 DDS 구현체 간의 차이, 환경 변경에 따른 동작 변동 등 비결정론적 오류의 원인이 된다.
행동 제어 시스템에서 권장되는 QoS 설계 패턴은 다음과 같다.
| 데이터 유형 | Reliability | Durability | History | Deadline |
|---|---|---|---|---|
| 센서 원시 데이터 | BEST_EFFORT | VOLATILE | KEEP_LAST(1) | 미설정 |
| 상태 추정 결과 | BEST_EFFORT | VOLATILE | KEEP_LAST(1) | 설정 권장 |
| 제어 명령 | RELIABLE | VOLATILE | KEEP_LAST(1) | 설정 권장 |
| 비상 정지 신호 | RELIABLE | VOLATILE | KEEP_LAST(1) | 필수 설정 |
| 시스템 진단 정보 | RELIABLE | TRANSIENT_LOCAL | KEEP_LAST(10) | 미설정 |
| 정적 변환(TF) | RELIABLE | TRANSIENT_LOCAL | KEEP_LAST(1) | 미설정 |
5. 원칙 4: 지연 예산의 수립과 관리
행동 제어 시스템의 전체 처리 체인에 대하여 지연 예산(latency budget)을 수립하고, 각 구성 요소에 허용 가능한 지연을 할당하여야 한다. 지연 예산의 총합은 제어 주기 T를 초과하지 않아야 한다.
\sum_{i=1}^{n} L_i + M \leq T
여기서 L_i는 i번째 처리 단계의 할당 지연이며, M은 안전 여유(safety margin)이다. 안전 여유는 일반적으로 제어 주기의 20~30%를 확보하는 것이 권장된다.
지연 예산은 시스템 구현 후 실측 데이터를 기반으로 검증하여야 하며, ros2_tracing 등의 프로파일링 도구를 통해 각 단계의 실제 지연을 측정한다.
6. 원칙 5: 네임스페이스와 토픽 명명의 체계화
통신 채널의 이름(토픽, 서비스, 액션)은 계층적 네임스페이스(namespace)를 사용하여 체계적으로 명명하여야 한다. 명명 규칙의 일관성은 시스템의 가독성, 디버깅 효율, 다중 로봇 환경에서의 충돌 방지에 기여한다.
권장 명명 체계는 다음과 같다.
/{로봇_이름}/{서브시스템}/{기능}
예:
/robot1/sensor/lidar/scan # 라이다 스캔 데이터
/robot1/perception/obstacle_map # 장애물 지도
/robot1/control/cmd_vel # 속도 명령
/robot1/behavior/navigate_to_pose # 내비게이션 액션
/robot1/safety/emergency_stop # 비상 정지 서비스
다중 로봇 환경에서는 로봇별 네임스페이스를 통해 동일한 토픽 이름이 서로 다른 로봇 간에 충돌하지 않도록 분리한다.
7. 원칙 6: 통신 경로의 최소화
행동 제어 루프의 통신 경로(communication path)는 가능한 한 최소화하여야 한다. 불필요한 중간 노드를 거치는 데이터 경로는 종단 간 지연을 증가시키고 오류 발생 지점을 확대한다.
이를 위한 구체적 전략은 다음과 같다.
- 컴포넌트 합성(Composition): 밀접하게 결합된 노드들을 단일 프로세스 내에 합성하여 인트라 프로세스 통신(IPC)을 활용한다.
- 직접 구독: 데이터를 중계하는 릴레이(relay) 노드를 제거하고, 소비 노드가 생산 노드의 토픽을 직접 구독한다.
- 메시지 집약(Aggregation): 동일 목적의 데이터를 단일 메시지 타입으로 통합하여 토픽 수를 감소시킨다.
8. 원칙 7: 안전 관련 통신의 분리
비상 정지, 안전 감시, 고장 보고 등 안전 관련 통신은 일반 데이터 통신과 분리하여 설계하여야 한다. 분리의 방법은 다음과 같다.
- 별도 콜백 그룹: 안전 관련 콜백은 일반 콜백과 다른 콜백 그룹에 배치하여, 일반 콜백의 지연이 안전 콜백의 실행에 영향을 미치지 않도록 한다.
- 높은 QoS 보장: 안전 관련 메시지에는
RELIABLE신뢰성, 짧은Deadline,Liveliness정책을 적용한다. - 독립 통신 경로: 가능한 경우 안전 관련 데이터를 별도의 네트워크 인터페이스 또는 DDS 도메인을 통해 전송한다.
9. 원칙 8: 실패 모드의 설계와 대비
통신 인프라는 다양한 실패 모드(failure mode)에 대비하여 설계하여야 한다. 주요 실패 모드와 대응 전략은 다음과 같다.
| 실패 모드 | 증상 | 대응 전략 |
|---|---|---|
| 메시지 손실 | 구독자가 데이터를 수신하지 못함 | RELIABLE QoS, Deadline 모니터링 |
| 메시지 지연 | 수신 데이터가 현재 상태를 반영하지 않음 | Lifespan 설정, 타임스탬프 검증 |
| 노드 비정상 종료 | 발행이 중단됨 | Liveliness 정책, 감시 노드(watchdog) |
| QoS 비호환 | 매칭 실패로 통신 불능 | 명시적 QoS 설정, 사전 호환성 검증 |
| 네트워크 분할 | 노드 그룹 간 통신 단절 | 다중 경로, 타임아웃 기반 안전 동작 |
| 대역폭 포화 | 메시지 지연 증가 또는 손실 | 메시지 크기 최적화, 발행 주기 조절 |
10. 원칙 9: 테스트 가능성의 보장
통신 인프라는 단위 테스트(unit test), 통합 테스트(integration test), 시스템 테스트(system test)의 모든 수준에서 검증 가능하도록 설계하여야 한다.
- 인터페이스 분리: 통신 로직을 비즈니스 로직에서 분리하여, 모의 객체(mock object)를 통한 단위 테스트가 가능하도록 한다.
- 녹화/재생(Record/Replay):
ros2 bag도구를 활용하여 센서 데이터를 녹화하고 재생함으로써 재현 가능한 통합 테스트를 수행한다. - 시뮬레이션 호환: 실제 센서/액추에이터와 동일한 인터페이스를 시뮬레이터가 제공하도록 하여, 통신 인프라를 변경하지 않고 시뮬레이션 환경에서 테스트가 가능하도록 한다.
11. 원칙 10: 확장성과 진화 가능성
통신 인프라는 시스템의 성장과 변경에 유연하게 대응할 수 있도록 설계하여야 한다.
- 느슨한 결합(Loose Coupling): 발행-구독 패턴을 기본으로 하여 노드 간의 직접적 의존을 최소화한다.
- 인터페이스 버전 관리: 메시지 타입의 변경 시 하위 호환성(backward compatibility)을 고려한다.
- 동적 재구성: 런타임 중 노드의 추가, 제거, 재시작이 전체 시스템의 중단 없이 가능하도록 설계한다.
- 미들웨어 독립성: RMW 추상화 계층을 활용하여 특정 DDS 구현체나 전송 프로토콜에 종속되지 않도록 한다.
12. 참고 문헌
- S. Macenski, T. Foote, B. Gerkey, C. Lalancette, W. Woodall, “Robot Operating System 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, eabm6074, 2022.
- Open Robotics, “About Quality of Service Settings,” ROS 2 Documentation, https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Quality-of-Service-Settings.html.
- D. Casini, T. Blaß, I. Lütkebohle, B. B. Brandenburg, “Response-Time Analysis of ROS 2 Processing Chains Under Reservation-Based Scheduling,” in Proceedings of the 31st Euromicro Conference on Real-Time Systems (ECRTS), 2019.
- IEC 61508, “Functional safety of electrical/electronic/programmable electronic safety-related systems,” International Electrotechnical Commission, 2010.
- Open Robotics, “Composing Multiple Nodes in a Single Process,” ROS 2 Documentation, https://docs.ros.org/en/rolling/Tutorials/Intermediate/Composition.html.