396.41 임무 관리자와 행동 실행기의 인터페이스

1. 개요

자율 로봇 시스템에서 임무 관리자(Mission Manager)와 행동 실행기(Behavior Executive)의 인터페이스는 고수준 임무 명령을 저수준 행동으로 변환하고, 행동의 실행 상태를 상위 시스템에 환류하는 핵심적 통신 경로이다. 이 인터페이스의 설계는 시스템의 반응성, 확장성, 내결함성(Fault Tolerance)에 직접적인 영향을 미친다.

2. 행동 실행기의 정의와 역할

2.1 행동 실행기의 개념

행동 실행기(Behavior Executive)는 임무 관리자로부터 수신한 과업(Task)을 구체적인 행동(Behavior) 단위로 분해하고, 각 행동의 활성화, 비활성화, 전환, 합성 등을 제어하는 모듈이다. 행동 실행기는 상태 머신(Finite State Machine), 행동 트리(Behavior Tree), 절차적 추론 시스템(Procedural Reasoning System) 등의 실행 모델에 기반하여 구현된다.

행동 실행기의 기능을 형식적으로 표현하면 다음과 같다.

\text{BehaviorExecutive} : \mathcal{T} \times \mathcal{S} \rightarrow \mathcal{B}^*

여기서 \mathcal{T}는 과업 공간, \mathcal{S}는 시스템 상태 공간, \mathcal{B}^*는 행동 시퀀스 공간이다.

2.2 행동의 실행 인터페이스

개별 행동 b \in \mathcal{B}는 다음의 표준 인터페이스를 통해 제어된다.

b.\text{configure}(\text{params}) \rightarrow \text{Status}
b.\text{activate}() \rightarrow \text{Status}
b.\text{execute}() \rightarrow \text{Result} \in \{\text{RUNNING}, \text{SUCCESS}, \text{FAILURE}\}
b.\text{deactivate}() \rightarrow \text{Status}
b.\text{cleanup}() \rightarrow \text{Status}

이 생명 주기 인터페이스는 ROS2의 Lifecycle 노드 모델(Managed Node)에서 영감을 받은 것으로, 행동의 구성, 활성화, 실행, 비활성화, 정리의 5단계를 명확히 분리한다(Open Robotics, 2017).

3. 임무 관리자에서 행동 실행기로의 하향 인터페이스

3.1 과업 전달(Task Dispatch)

임무 관리자는 분해된 과업을 행동 실행기에 전달한다. 과업 전달 메시지는 다음과 같은 구조를 갖는다.

\text{TaskDispatch} = (\text{task\_id}, \text{task\_type}, \text{params}, \text{constraints}, \text{priority})

• \text{task\_id}: 과업의 고유 식별자
• \text{task\_type}: 과업의 유형 (예: NAVIGATE, INSPECT, PICK, PLACE)
• \text{params}: 과업 수행에 필요한 매개변수
• \text{constraints}: 시간, 자원, 안전 등의 제약 조건
• \text{priority}: 과업의 우선순위 수준

3.2 과업 제어 명령(Task Control Commands)

임무 관리자는 실행 중인 과업에 대해 다음의 제어 명령을 발행할 수 있다.

과업 선점(Preemption) 명령은 다음과 같이 형식화된다.

\text{Preempt}(T_{\text{current}}, T_{\text{new}}) : \text{pri}(T_{\text{new}}) > \text{pri}(T_{\text{current}})

선점이 발생할 때 행동 실행기는 현재 실행 중인 행동을 안전하게 중단하고, 새로운 과업에 대응하는 행동 체인을 활성화한다. 이 과정에서 행동의 중단 안전성(Abort Safety)이 보장되어야 한다.

3.3 행동 매개변수화(Behavior Parameterization)

임무 관리자로부터 전달된 과업은 행동 실행기에서 구체적인 행동 인스턴스로 변환된다. 이 변환 과정에서 과업의 추상적 매개변수가 행동의 구체적 매개변수로 매핑된다.

\text{BehaviorParams} = \text{Resolve}(\text{TaskParams}, \text{Context})

예를 들어, “물체 A를 위치 B로 운반하라“는 과업은 다음과 같은 행동 시퀀스로 분해된다.

T_{\text{transport}}(A, B) \rightarrow \langle b_{\text{navigate}}(A.\text{pos}), b_{\text{pick}}(A), b_{\text{navigate}}(B), b_{\text{place}}(A, B) \rangle

4. 행동 실행기에서 임무 관리자로의 상향 인터페이스

4.1 실행 상태 보고(Execution Status Reporting)

행동 실행기는 과업의 실행 상태를 주기적으로 또는 이벤트 발생 시 임무 관리자에 보고한다.

\text{StatusReport} = (\text{task\_id}, \text{status}, \text{progress}, \text{details}, t)

여기서 \text{status} \in \{\text{PENDING}, \text{RUNNING}, \text{PAUSED}, \text{SUCCEEDED}, \text{FAILED}, \text{CANCELED}\}이고, \text{progress} \in [0, 1]은 과업 완료율, t는 타임스탬프이다.

4.2 오류 보고(Error Reporting)

행동 실행 중 발생하는 오류는 구조화된 형식으로 임무 관리자에 보고된다.

\text{ErrorReport} = (\text{task\_id}, \text{error\_code}, \text{error\_type}, \text{severity}, \text{recoverable}, \text{context})

오류 유형은 다음과 같이 분류된다.

\text{recoverable} 필드는 행동 실행기 수준에서의 자체 복구 가능 여부를 나타내며, 복구 불가능한 오류는 임무 관리자에 에스컬레이션된다.

4.3 이벤트 통지(Event Notification)

행동 실행기는 사전 정의된 이벤트가 발생할 때 임무 관리자에 통지한다.

\text{Event} = (\text{event\_type}, \text{source\_behavior}, \text{data}, t)

주요 이벤트 유형은 다음과 같다.

• \text{TASK\_COMPLETED}: 과업 정상 완료
• \text{TASK\_FAILED}: 과업 실패
• \text{PRECONDITION\_MET}: 다음 과업의 선행 조건 충족
• \text{ANOMALY\_DETECTED}: 이상 상황 감지
• \text{RESOURCE\_CRITICAL}: 자원 임계 수준 도달

5. 통신 패턴과 구현 전략

5.1 동기 호출과 비동기 호출

임무 관리자와 행동 실행기 사이의 통신은 동기(Synchronous) 또는 비동기(Asynchronous) 방식으로 구현된다.

동기 호출: 임무 관리자가 과업을 전달하고 결과가 반환될 때까지 대기한다. 구현이 단순하지만, 장시간 행동 실행 시 임무 관리자의 응답성이 저하된다.

\text{result} = \text{BehaviorExecutive.execute\_sync}(T)

비동기 호출: 임무 관리자가 과업을 전달한 후 즉시 반환받고, 결과는 콜백(Callback)이나 별도의 채널을 통해 수신한다.

\text{future} = \text{BehaviorExecutive.execute\_async}(T)

\text{future.on\_complete}(\lambda \text{result} : \text{MM.handle\_result}(\text{result}))

자율 로봇 시스템에서는 대부분의 행동 실행이 비동기적으로 이루어지므로, 비동기 패턴이 표준적인 구현 방식이다.

5.2 ROS2 기반 구현

ROS2 환경에서 임무 관리자와 행동 실행기의 인터페이스는 다음의 통신 메커니즘을 활용하여 구현된다.

액션(Action): 장기 실행 행동에 대한 비동기 요청-피드백-결과 인터페이스. 과업의 시작, 진행 모니터링, 취소를 지원한다.

서비스(Service): 단발성 요청-응답 인터페이스. 행동 매개변수 설정, 상태 조회 등에 사용된다.

토픽(Topic): 발행-구독 기반의 단방향 메시지 스트림. 주기적 상태 보고, 이벤트 통지 등에 사용된다.

임무 관리자                              행동 실행기
    │                                          │
    ├──→ Action Goal: ExecuteTask ─────────→  │
    │                                          │
    │  ←── Action Feedback: progress ──────── │
    │  ←── Topic: /behavior_events ────────── │
    │                                          │
    │  ←── Action Result: success/fail ─────── │
    │                                          │
    ├──→ Service: ConfigureBehavior ────────→  │
    │  ←── Service Response: ok ────────────── │

5.3 블랙보드(Blackboard) 패턴

행동 트리 기반의 행동 실행기에서는 블랙보드(Blackboard) 패턴이 널리 사용된다(Colledanchise & Ögren, 2018). 블랙보드는 공유 메모리 공간으로, 임무 관리자와 행동 실행기 사이의 간접적 데이터 교환을 가능하게 한다.

\text{Blackboard} = \{(\text{key}_i, \text{value}_i) \mid i = 1, 2, \ldots, n\}

임무 관리자는 블랙보드에 과업 매개변수와 목표 상태를 기록하고, 행동 실행기는 블랙보드로부터 필요한 정보를 읽어 행동을 수행한다. 행동의 실행 결과도 블랙보드에 기록되어 임무 관리자가 참조할 수 있다.

\text{MM} \xrightarrow{\text{write}(\text{goal\_pose}, p)} \text{Blackboard} \xleftarrow{\text{read}(\text{goal\_pose})} \text{BehaviorExecutive}

6. 행동 합성과 실행 흐름 제어

6.1 순차적 합성(Sequential Composition)

과업이 순차적으로 실행되어야 하는 경우, 임무 관리자는 행동 시퀀스를 행동 실행기에 전달한다.

\text{Sequence}(b_1, b_2, \ldots, b_n) : b_i \text{가 SUCCESS를 반환하면 } b_{i+1} \text{을 실행}

6.2 병렬 합성(Parallel Composition)

복수의 행동이 동시에 실행되어야 하는 경우, 병렬 합성이 사용된다.

\text{Parallel}(b_1, b_2, \ldots, b_n, M) : M \text{개 이상 SUCCESS이면 SUCCESS 반환}

여기서 M은 성공 임계값(Success Threshold)이다.

6.3 조건부 실행(Conditional Execution)

환경 조건이나 시스템 상태에 따라 행동의 실행 여부가 결정되는 경우, 조건부 실행 패턴이 적용된다.

\text{ConditionalExecute}(c, b_{\text{true}}, b_{\text{false}}) = \begin{cases} b_{\text{true}} & \text{if } c(\mathcal{S}) = \text{true} \\ b_{\text{false}} & \text{otherwise} \end{cases}

7. 인터페이스 추상화와 플러그인 아키텍처

7.1 행동 플러그인 인터페이스

임무 관리자와 행동 실행기의 인터페이스를 표준화하기 위해, 행동을 플러그인(Plugin) 형태로 구현하는 아키텍처가 널리 채택된다. Nav2의 행동 트리 노드 플러그인이 이 접근법의 대표적 사례이다(Macenski et al., 2020).

플러그인 인터페이스의 기본 구조는 다음과 같다.

\text{BehaviorPlugin} = (\text{name}, \text{type}, \text{configure}(), \text{activate}(), \text{execute}(), \text{deactivate}())

이 아키텍처는 임무 관리자의 수정 없이도 새로운 행동을 시스템에 추가할 수 있는 확장성을 제공한다. 임무 관리자는 행동의 구체적 구현에 의존하지 않고, 표준 인터페이스를 통해서만 행동 실행기와 상호작용한다.

7.2 추상 행동 인터페이스

행동 실행기가 지원하는 모든 행동은 공통의 추상 인터페이스를 구현한다.

\text{AbstractBehavior} = \{\text{initialize}(), \text{on\_tick}(), \text{on\_halt}(), \text{get\_status}()\}

• \text{on\_tick}(): 매 실행 주기마다 호출되어 행동의 현재 상태를 반환한다.
• \text{on\_halt}(): 행동이 중단될 때 안전한 정지를 수행한다.
• \text{get\_status}(): 행동의 현재 실행 상태를 반환한다.

8. 내결함성과 안정성 설계

8.1 워치독(Watchdog) 메커니즘

임무 관리자는 행동 실행기의 응답성을 감시하는 워치독 타이머를 유지한다. 지정된 시간 내에 상태 보고가 수신되지 않으면, 행동 실행기의 비정상 상태로 판단하고 복구 절차를 개시한다.

\text{Watchdog}(T_{\text{timeout}}) : \begin{cases} \text{normal} & \text{if } t_{\text{last\_report}} - t_{\text{now}} < T_{\text{timeout}} \\ \text{alert} & \text{otherwise} \end{cases}

8.2 행동 격리(Behavior Isolation)

개별 행동의 실패가 전체 시스템에 파급되는 것을 방지하기 위해, 행동을 격리된 실행 환경에서 수행하는 전략이 적용된다. 이는 프로세스 격리, 예외 처리, 자원 제한 등의 메커니즘을 통해 구현된다.

9. 요약

임무 관리자와 행동 실행기의 인터페이스는 하향 방향의 과업 전달·제어 명령과 상향 방향의 상태 보고·이벤트 통지로 구성된다. 비동기 통신 패턴이 표준적으로 채택되며, 블랙보드 패턴을 통한 간접적 데이터 교환이 행동 트리 기반 시스템에서 널리 활용된다. 행동의 플러그인 아키텍처는 시스템의 확장성을 보장하고, 워치독 메커니즘과 행동 격리는 인터페이스의 내결함성을 강화한다.

10. 참고 문헌

• Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.
• Macenski, S., Martín, F., White, R., & Clavero, J. G. (2020). “The Marathon 2: A Navigation System.” Proceedings of IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 2718–2725.
• Open Robotics. (2017). “ROS 2 Managed Nodes Design Document.” ROS 2 Design Documentation.
• Ingrand, F. F., Georgeff, M. P., & Rao, A. S. (1992). “An Architecture for Real-Time Reasoning and System Control.” IEEE Expert, 7(6), 34–44.
• Firby, R. J. (1989). Adaptive Execution in Complex Dynamic Worlds. Ph.D. Dissertation, Yale University.
• Arkin, R. C. (1998). Behavior-Based Robotics. MIT Press.

v0.1