396.38 소프트웨어 아키텍처 내 임무 관리자의 위치

1. 개요

자율 로봇 시스템의 소프트웨어 아키텍처는 다양한 기능 모듈이 유기적으로 결합되어 작동하는 복잡한 구조물이다. 이 구조 내에서 임무 관리자(Mission Manager)는 시스템의 고수준 의사 결정과 저수준 행동 실행 사이를 연결하는 핵심적인 중개 역할을 수행한다. 임무 관리자의 아키텍처적 위치를 정확히 이해하는 것은 시스템의 전반적인 설계 효율성과 확장성을 결정짓는 중요한 과제이다.

2. 로봇 소프트웨어 아키텍처의 일반 구조

2.1 기능 계층 분할

로봇 소프트웨어 아키텍처는 일반적으로 기능적 역할에 따라 복수의 계층으로 분할된다. 가장 널리 알려진 분류 방식은 다음의 세 계층 구분이다.

의사 결정 계층(Deliberative Layer): 시스템의 최상위 계층으로, 임무 목표의 해석, 계획 수립, 자원 할당 등 추상적이고 인지적인 기능을 담당한다. 이 계층은 완전한 세계 모델(World Model)을 활용하여 최적의 행동 방침을 결정하며, 계산 비용이 크고 실행 주기가 상대적으로 길다.

실행 계층(Executive Layer): 의사 결정 계층에서 산출된 계획을 구체적인 행동 시퀀스로 변환하는 중간 계층이다. 실행 계층은 계획의 분해, 자원 관리, 오류 복구, 행동 시퀀싱 등의 기능을 수행하며, 의사 결정 계층과 반응 계층 사이의 시간적·의미적 간극을 메운다.

반응 계층(Reactive Layer): 센서 데이터를 직접 처리하고 액추에이터를 제어하는 최하위 계층이다. 이 계층은 빠른 응답 시간이 요구되며, 장애물 회피, 경로 추종, 자세 안정화 등과 같은 실시간 제어 루프를 포함한다.

2.2 계층 간 정보 흐름

각 계층 사이에서는 명령(Command)과 상태(Status) 정보가 수직적으로 흐른다. 상위 계층에서 하위 계층으로는 목표와 명령이 전달되고, 하위 계층에서 상위 계층으로는 실행 상태, 센서 데이터, 오류 보고 등이 피드백된다.

$\text{Deliberative} \xrightarrow{\text{goals, plans}} \text{Executive} \xrightarrow{\text{commands}} \text{Reactive}$

$\text{Deliberative} \xleftarrow{\text{status, events}} \text{Executive} \xleftarrow{\text{sensor data}} \text{Reactive}$

이 양방향 정보 흐름은 시스템의 폐루프(Closed-Loop) 작동을 보장하며, 각 계층이 환경 변화에 적응적으로 대응할 수 있는 기반을 제공한다.

3. 임무 관리자의 아키텍처적 위치

3.1 의사 결정 계층과 실행 계층의 경계

임무 관리자는 의사 결정 계층과 실행 계층의 경계 영역에 위치한다. 구체적으로, 임무 관리자는 다음과 같은 이중적 역할을 수행한다.

상향적 역할: 임무 계획기(Mission Planner)로부터 생성된 고수준 계획을 수신하고, 이를 실행 가능한 과업(Task) 단위로 분해한다. 이 과정에서 임무 관리자는 계획의 실현 가능성을 평가하고, 필요 시 계획 수정을 요청한다.

하향적 역할: 분해된 과업을 행동 실행기(Behavior Executive)에 전달하고, 실행 상태를 모니터링하며, 실행 중 발생하는 예외 상황에 대응한다. 이 역할은 과업의 시작, 중단, 재개, 종료 등 생명 주기 전반을 관리하는 것을 포함한다.

3.2 아키텍처 배치 유형

임무 관리자의 아키텍처 내 배치는 시스템 설계 철학에 따라 크게 세 가지 유형으로 분류된다.

유형 1: 독립 모듈형(Standalone Module)

임무 관리자가 다른 모듈과 독립적으로 존재하면서, 정의된 인터페이스를 통해 상하위 계층과 통신한다. 이 유형은 모듈 간 결합도(Coupling)를 최소화하여 유지보수성과 재사용성을 높인다.

$M_{\text{standalone}} : \mathcal{P} \times \mathcal{S} \rightarrow \mathcal{C}$

여기서 $\mathcal{P}$ 는 계획 공간, $\mathcal{S}$ 는 시스템 상태 공간, $\mathcal{C}$ 는 명령 공간을 나타낸다.

유형 2: 내장 통합형(Embedded Integration)

임무 관리자가 실행 계층의 내부에 통합되어, 행동 제어와 임무 관리가 단일 프로세스 내에서 이루어진다. 이 유형은 통신 지연을 줄일 수 있으나, 모듈 간 경계가 모호해져 확장성에 한계가 있다.

유형 3: 분산형(Distributed)

임무 관리 기능이 복수의 노드에 분산되어 실행된다. 다중 로봇 시스템에서 주로 채택되며, 각 로봇의 로컬 임무 관리자와 중앙의 글로벌 임무 관리자가 협력적으로 동작한다.

$M_{\text{distributed}} = \{M_{\text{global}}\} \cup \{M_{\text{local},i} \mid i = 1, 2, \ldots, N\}$

4. 대표적 소프트웨어 아키텍처에서의 임무 관리자 배치

4.1 LAAS 아키텍처

LAAS(Laboratory for Analysis and Architecture of Systems) 아키텍처는 Alami 등(1998)이 제안한 3계층 아키텍처의 대표적 사례이다. 이 아키텍처에서 임무 관리자는 의사 결정 계층에 위치하며, 절차적 실행기(Procedural Executive)와 기능 계층(Functional Layer) 위에서 동작한다.

┌─────────────────────────────┐
│      Decision Layer         │  ← 임무 관리자 + 임무 계획기
├─────────────────────────────┤
│    Executive Layer          │  ← 절차적 실행기 (e.g., PRS)
├─────────────────────────────┤
│    Functional Layer         │  ← 센서/액추에이터 모듈
└─────────────────────────────┘

LAAS 아키텍처에서 임무 관리자는 시간적 제약 조건과 자원 할당 문제를 해결하는 역할을 담당하며, IxTeT(Indexed Time Table) 플래너와 연동하여 시간적 계획을 수립한다(Lemai & Ingrand, 2004).

4.2 CLARAty 아키텍처

CLARAty(Coupled Layer Architecture for Robotic Autonomy)는 NASA JPL에서 개발한 로봇 소프트웨어 아키텍처이다(Volpe et al., 2001). CLARAty는 전통적인 3계층 구조를 2계층으로 축소하여, 기능 계층(Functional Layer)과 의사 결정 계층(Decision Layer)으로 구성된다.

이 아키텍처에서 임무 관리자는 의사 결정 계층의 일부로서 CASPER(Continuous Activity Scheduling, Planning, Execution, and Replanning) 플래너와 결합되어 있다. 임무 관리자는 지속적인 재계획(Replanning) 기능을 통해 변화하는 환경에 적응한다.

4.3 T-REX 아키텍처

T-REX(Teleo-Reactive Executive)는 McGann 등(2008)이 제안한 아키텍처로, 계획과 실행을 통합한 목표 지향적 실행 체계를 제공한다. T-REX에서 임무 관리자의 기능은 복수의 에이전트(Agent)로 분산된다. 각 에이전트는 자신의 타임라인(Timeline)을 관리하며, 에이전트 간의 상호작용을 통해 전체 임무가 조율된다.

$\text{T-REX}: \mathcal{A} = \{a_1, a_2, \ldots, a_k\}, \quad a_i = (\mathcal{T}_i, \mathcal{R}_i)$

여기서 $a_i$ 는 에이전트, $\mathcal{T}_i$ 는 해당 에이전트가 관리하는 타임라인 집합, $\mathcal{R}_i$ 는 에이전트 간 관계를 정의하는 리액터(Reactor)이다.

4.4 ROS/ROS2 기반 아키텍처

ROS(Robot Operating System) 및 ROS2 기반 시스템에서 임무 관리자는 일반적으로 하나의 독립 노드(Node)로 구현된다. Nav2(Navigation2) 스택의 경우, bt_navigator 노드가 행동 트리(Behavior Tree) 기반의 임무 실행을 담당하며, 이는 임무 관리자의 기능적 역할을 수행한다(Macenski et al., 2020).

ROS2 아키텍처에서 임무 관리자의 위치적 특성은 다음과 같다.

토픽(Topic), 서비스(Service), 액션(Action)을 통해 다른 노드와 비동기적으로 통신한다.
Lifecycle 노드 관리를 통해 시스템 생명 주기와 통합된다.
QoS(Quality of Service) 정책을 통해 통신 신뢰성을 보장한다.
DDS(Data Distribution Service) 기반의 분산 통신 미들웨어에 의존한다.

5. 임무 관리자와 인접 모듈의 상호작용

5.1 임무 계획기와의 관계

임무 계획기(Mission Planner)는 목표로부터 행동 계획을 생성하는 모듈이다. 임무 관리자는 임무 계획기의 출력을 수신하여 실행 관리를 담당하므로, 두 모듈 사이에는 명확한 인터페이스가 존재하여야 한다.

$\text{Planner} \xrightarrow{\pi = \langle a_1, a_2, \ldots, a_n \rangle} \text{Mission Manager}$

여기서 $\pi$ 는 계획(Plan)이며, $a_i$ 는 계획 내 개별 행동(Action)을 나타낸다.

임무 관리자는 계획의 실행 가능성을 검증하고, 실행 중 계획 이탈이 발생하면 임무 계획기에 재계획을 요청한다. 이 상호작용은 비동기적이거나 이벤트 기반으로 구현되는 것이 일반적이다.

5.2 세계 모델과의 관계

세계 모델(World Model)은 로봇이 인식한 환경 정보를 저장하고 갱신하는 모듈이다. 임무 관리자는 세계 모델로부터 현재 환경 상태를 질의(Query)하여 의사 결정에 활용한다.

$s_t = \text{WorldModel.query}(t)$

$d_t = M(s_t, \pi_t)$

여기서 $s_t$ 는 시각 $t$ 에서의 상태, $\pi_t$ 는 현재 계획, $d_t$ 는 임무 관리자의 의사 결정 출력이다.

5.3 상태 추정기와의 관계

상태 추정기(State Estimator)는 센서 융합을 통해 로봇의 내부 상태(위치, 속도, 자세 등)를 추정한다. 임무 관리자는 상태 추정 결과를 참조하여 과업 완료 조건의 충족 여부를 판단하고, 임무 진행 상태를 평가한다.

5.4 자원 관리자와의 관계

자원 관리자(Resource Manager)는 배터리 잔량, 통신 대역폭, 계산 자원 등의 시스템 자원을 모니터링한다. 임무 관리자는 자원 관리자로부터 자원 가용성 정보를 수신하여 임무 실행의 타당성을 판단한다.

$\text{feasible}(\pi) = \begin{cases} \text{true} & \text{if } \forall r \in \mathcal{R}: r_{\text{available}} \geq r_{\text{required}}(\pi) \\ \text{false} & \text{otherwise} \end{cases}$

6. 아키텍처 설계 시 고려 사항

6.1 모듈 간 결합도와 응집도

임무 관리자의 아키텍처 배치에서는 모듈 간 결합도(Coupling)를 최소화하고 응집도(Cohesion)를 최대화하는 소프트웨어 공학적 원칙이 적용되어야 한다. 결합도가 높은 설계는 한 모듈의 변경이 다른 모듈에 파급 효과를 일으켜 유지보수 비용을 증가시킨다.

6.2 확장성과 재구성 가능성

임무 관리자가 아키텍처 내에서 독립적인 위치를 점유할 경우, 시스템의 확장성(Scalability)과 재구성 가능성(Reconfigurability)이 향상된다. 새로운 임무 유형이나 로봇 플랫폼을 추가할 때 임무 관리자의 인터페이스만 수정하면 되기 때문이다.

6.3 실시간 제약 조건

임무 관리자가 실행 계층에 가까이 배치될수록 실시간 반응성이 향상되지만, 의사 결정의 복잡도 증가로 인해 실시간 보장이 어려워질 수 있다. 따라서 임무 관리자의 기능을 시간 임계(Time-Critical) 부분과 비시간 임계(Non-Time-Critical) 부분으로 분리하는 설계 전략이 제시된다.

$M = M_{\text{critical}} \cup M_{\text{non-critical}}$

여기서 $M_{\text{critical}}$ 은 비상 대응, 행동 전환 등 즉각적 반응이 요구되는 기능이고, $M_{\text{non-critical}}$ 은 장기 계획 수정, 성과 분석 등 지연 허용이 가능한 기능이다.

6.4 통신 패턴과 미들웨어 의존성

임무 관리자의 위치는 시스템이 사용하는 통신 미들웨어의 특성에 의해 영향을 받는다. 발행-구독(Publish-Subscribe) 패턴을 사용하는 DDS 기반 시스템에서 임무 관리자는 느슨하게 결합된 노드로 구현될 수 있으나, 요청-응답(Request-Response) 패턴이 주로 사용되는 시스템에서는 임무 관리자와 다른 모듈 간의 동기적 결합이 강화된다.

7. 임무 관리자 배치의 형식적 분석

7.1 아키텍처 기술 언어(ADL)를 활용한 명세

임무 관리자의 아키텍처적 위치는 AADL(Architecture Analysis and Design Language)이나 SysML(Systems Modeling Language) 등의 아키텍처 기술 언어를 통해 형식적으로 명세될 수 있다. AADL에서는 임무 관리자를 프로세서(Processor) 바인딩을 포함하는 프로세스(Process) 컴포넌트로 모델링한다(Feiler & Gluch, 2012).

7.2 컴포넌트 커넥터 모델

소프트웨어 아키텍처에서 컴포넌트-커넥터(Component-Connector) 패러다임은 임무 관리자의 위치를 분석하는 데 유용한 도구이다. 이 모델에서 임무 관리자는 하나의 컴포넌트로, 인접 모듈과의 연결은 커넥터로 표현된다.

$\text{Architecture} = (\mathcal{C}, \mathcal{K}, \mathcal{A})$

여기서 $\mathcal{C}$ 는 컴포넌트의 집합, $\mathcal{K}$ 는 커넥터의 집합, $\mathcal{A}$ 는 부착(Attachment) 관계의 집합이다. 임무 관리자 $c_{\text{MM}} \in \mathcal{C}$ 의 아키텍처적 중요도는 인접 커넥터의 수와 전달되는 정보의 의미적 중요도에 비례한다.

8. 요약

임무 관리자는 자율 로봇 소프트웨어 아키텍처에서 의사 결정 계층과 실행 계층의 경계에 위치하여, 고수준 계획을 저수준 행동으로 변환하는 중추적 역할을 담당한다. 그 배치 방식은 독립 모듈형, 내장 통합형, 분산형으로 분류되며, LAAS, CLARAty, T-REX, ROS2 등 대표적 아키텍처에서 서로 다른 설계 철학에 따라 배치된다. 아키텍처 설계 시에는 결합도, 확장성, 실시간성, 통신 패턴 등의 요소를 종합적으로 고려하여 임무 관리자의 최적 위치를 결정하여야 한다.

9. 참고 문헌

Alami, R., Chatila, R., Fleury, S., Ghallab, M., & Ingrand, F. (1998). “An Architecture for Autonomy.” The International Journal of Robotics Research, 17(4), 315–337.
Volpe, R., Nesnas, I., Estlin, T., Mutz, D., Petras, R., & Das, H. (2001). “The CLARAty Architecture for Robotic Autonomy.” Proceedings of IEEE Aerospace Conference, Vol. 1, pp. 121–132.
Lemai, S., & Ingrand, F. (2004). “Interleaving Temporal Planning and Execution in Robotics Domains.” Proceedings of the 19th National Conference on Artificial Intelligence (AAAI-04), pp. 617–622.
McGann, C., Py, F., Rajan, K., Thomas, H., Henthorn, R., & McEwen, R. (2008). “T-REX: A Deliberative System for AUV Control.” Proceedings of the 3rd Workshop on Planning and Plan Execution for Real-World Systems (ICAPS).
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.
Feiler, P. H., & Gluch, D. P. (2012). Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis & Design Language. Addison-Wesley Professional.

v0.1