32.6 Liveliness 폴리시 매개변수를 활용한 유효성 노드 네트워크 생존성 자동 입증 알고리즘

데이터 분배 서비스(Data Distribution Service, DDS) 기반의 ROS2 통신 환경에서 노드의 생존성(Liveliness)은 분산 시스템의 강건성과 신뢰성을 유지하기 위한 핵심 요소이다. 대규모 로봇 네트워크 또는 다중 자율 에이전트 환경 시스템에서는 네트워크 단절, 프로세스 충돌, 혹은 예기치 못한 교착 상태(Deadlock)로 인해 특정 노드가 정상적인 통신 능력을 상실할 수 있다. 이러한 노드의 기능 상실을 적시에 감지하고 대처하기 위해, QoS(Quality of Service) 프로필의 Liveliness 폴리시는 네트워크 참여자 간의 생존 상태를 자동적이고 정량적으로 입증하는 메커니즘을 제공한다. 본 절에서는 Liveliness 폴리시의 매개변수를 구체적으로 분석하고, 이를 활용하여 유효성 노드의 네트워크 생존성을 자동 입증하는 알고리즘 구동 원리를 서술한다.

1. Liveliness 폴리시의 핵심 개념 및 QoS 분류 모델

Liveliness 폴리시는 퍼블리셔(Publisher)가 서브스크라이버(Subscriber) 측에 자신이 여전히 활성화되어 데이터 스트리밍 또는 서비스 처리를 수행할 수 있는 “살아있는(Alive)” 상태임을 입증(Assert)하는 방식을 제어한다. ROS2 미들웨어인 DDS는 이러한 Liveliness 상태를 판단하기 위해 두 가지 주요 매개변수인 활성 종류(Kind)와 임대 기간(Lease Duration)을 정의한다.

1.1 활성 종류(Liveliness Kind)별 입증 메커니즘

Liveliness 종류는 노드의 상태를 시스템이 어떻게 감지하고 평가할 것인지를 결정하며, 다음과 같은 세 가지 모드로 구분된다.

AUTOMATIC 모드: 퍼블리셔가 속한 특정 노드 또는 프로세스가 네트워크의 미들웨어를 통해 여전히 응답 가능한 상태라면, DDS 미들웨어가 자체적으로 퍼블리셔의 생존 상태를 입증하는 방식이다. 퍼블리셔 애플리케이션 수준의 직접적인 동작(데이터 전송 행위 등)이 없어도, 하부 미들웨어 데몬이 런타임 동안 주기적으로 생존 신호를 교환하므로 시스템 자원 소모가 가장 적고 관리가 용이하다.
MANUAL_BY_PARTICIPANT 모드: 퍼블리셔 측 애플리케이션이 동일한 DomainParticipant에 속한 어떠한 활성 상태를 나타내면, 해당 참여자에 소속된 모든 퍼블리셔의 생존이 함께 입증되는 방식이다. 이 모드에서는 개발자가 직접 미들웨어 API를 호출하여 애플리케이션이 정상 작동하고 있음을 증명해야 하므로, 단순한 네트워크 연결 유무를 넘어 프로세스 내부의 로직 실행 유효성을 검증할 수 있다.
MANUAL_BY_TOPIC 모드: 퍼블리셔가 자신이 발행하는 각각의 토픽에 대해 개별적이고 명시적으로 생존을 입증해야 하는 방식이다. 데이터가 발행되거나 명시적인 assert_liveliness() API가 호출될 때만 해당 토픽의 퍼블리셔가 생존한 것으로 간주된다. 가장 세밀한 제어가 가능하며, 특정 데이터 계통의 데드락(Deadlock)이나 스레드 멈춤 현상(Starvation)을 정밀하게 감지해 내는 데 최적화되어 있다.

1.2 임대 기간(Lease Duration) 매개변수의 역할

임대 기간은 퍼블리셔가 다음 생존 입증까지 서브스크라이버 측에 허용한 최대 대기 시간 간격을 의미한다. 만약 퍼블리셔가 임대 기간으로 설정한 시간 $\tau_{lease}$ 내에 상태 증명(Assertion)을 갱신하지 못한다면, 서브스크라이버의 DDS 미들웨어 데몬은 해당 퍼블리셔를 “비활성화(Not Alive)” 상태로 간주한다. 수학적으로 퍼블리셔 $P_i$ 의 $k$ -번째 생존 입증 시점을 $t_k$ 라고 할 때, $t_{k+1} - t_k \leq \tau_{lease}$ 조건을 지속적으로 충족해야 유효성 노드로서 생존성을 인정받는다.

2. 노드 네트워크 생존성 자동 입증 알고리즘 체계

Liveliness 매개변수를 기반으로 한 네트워크 생존성 자동 입증 알고리즘은 노드의 발견(Discovery), 계약(Contract), 모니터링(Monitoring) 및 예외 처리(Exception Handling)의 네 단계 상태 머신(State Machine)으로 구축된다.

2.1 단계 1: 토픽 생성 및 QoS 계약 협상 모델링

퍼블리셔 $P_i$ 와 서브스크라이버 $S_j$ 는 통신 초기 단계에서 각자의 QoS 프로파일을 비교하여 계약의 호환성을 검증한다. 서브스크라이버의 요구 수준이 퍼블리셔가 제공할 수 있는 보장 수준보다 높을 경우, DDS는 통신 경로를 확립하지 않는다. Liveliness 폴리시의 호환성 조건은 다음과 같다.

Liveliness Kind 보장성: $Kind(P_i) \geq Kind(S_j)$ 를 만족해야 한다. (순서: AUTOMATIC < MANUAL_BY_PARTICIPANT < MANUAL_BY_TOPIC)
Lease Duration 제약성: $Duration(P_i) \leq Duration(S_j)$ 를 만족해야 한다. 퍼블리셔가 생존을 입증하겠다고 약속한 주기가, 서브스크라이버가 대기할 수 있는 최대 주기보다 짧거나 같아야 적법한 계약이 성립한다.

2.2 단계 2: 생존 신호(Heartbeat) 발생 및 갱신 아키텍처

Liveliness 종류에 따라 미들웨어는 각기 다른 방식으로 타이머 스레드를 할당하여 생존 신호를 자동 생성 및 갱신한다. AUTOMATIC 환경에서는 하위 네트워크 프로토콜 계층인 RTPS(Real-Time Publish Subscribe)가 독립적으로 제어 루프를 실행하며 서브스크라이버에게 생존 메시지를 멀티캐스트 혹은 유니캐스트 서브넷 모델로 브로드캐스팅한다. 반면 MANUAL_BY_TOPIC 모드에서는 사용자의 퍼블리싱 스레드와 동일한 컨텍스트에서 오퍼레이션이 발생하여, 애플리케이션의 멈춤 현상이 발생할 경우 신호 발생도 정확히 동기화되어 중단된다.

2.3 단계 3: 시간 제반 손실 검출 메커니즘

서브스크라이버 노드 $S_j$ 에는 매칭된 퍼블리셔 $P_i$ 마다 독립적인 감시 타이머(Watchdog Timer)가 할당된다. 이 타이머는 $P_i$ 의 상태 증명 메시지가 도착할 때마다 초기화된다. 만약 $\tau_{lease}$ 가 경과하도록 타이머 리셋 루틴이 호출되지 않으면, 시스템은 대기시간 초과 인터럽트를 발생시키고 검출 알고리즘의 예외 핸들러를 호출한다.

2.4 단계 4: Liveliness Changed Status 콜백 및 자율형 후속 조치

퍼블리셔의 상태 증명 기한이 초과된 사실이 검출되면, DDS 미들웨어 계층은 비동기 이벤트 큐에 LivelinessChangedStatus 변화를 알린다. 개발자는 ROS2 노드의 생명주기(Lifecycle) 및 이벤트 콜백 리스너(Listener)를 매핑하여 이 상태 변화를 즉시 수신하도록 설계할 수 있다. 상태 이벤트 콜백 내부에서는 다음과 같은 변수들을 통해 유효성을 상실한 노드를 식별한다.

alive_count: 현재 정상적인 Alive 상태를 유지하고 있는 퍼블리셔의 총개수
not_alive_count: 임대 기간 내 증명 실패로 인해 Not Alive로 전환된 퍼블리셔의 총개수
alive_count_change / not_alive_count_change: 마지막 이벤트 발생 이후 카운트의 델타(Delta) 증감량

자율 에이전트 소프트웨어 아키텍처는 위 통계치를 활용해, 특정 센서 노드의 고장을 진단하고 대체 구동 시스템을 강제 실행시키거나 페일 세이프(Fail-Safe) 착륙 시퀀스로의 모드 전환을 결정하는 등의 고도화된 자율 생존망을 즉각적으로 구성한다. 이러한 프로그래매틱 추월 방식을 통해 분산 컴포넌트 간 단절이 중앙 집중적인 서버의 지시 없이 하부 통신망의 자가 점검(Self-Diagnostics) 루틴만으로 완결된다.