18.3.1 uORB::Manager 싱글톤(Singleton) 아키텍처 및 초기화
PX4-Autopilot의 수많은 모듈(센서 드라이버, 자세 제어기, 위치 추정기 등)은 서로 피를 나누는 자율 신경계처럼 긴밀하게 얽혀 데이터를 주고받는다. 만약 여러 개의 브로커(Broker)가 난립하여 서로 다른 메모리 풀(Memory Pool)을 관리한다면, 데이터의 일관성은 무너지고 메모리 참조 에러로 인해 기체는 회복 불능 상태에 빠질 것이다.
이러한 파국을 막기 위해 PX4 설계자들은 미들웨어 통신의 전권을 쥐고 흔드는 단 하나의 중앙 통제 타워를 구축했다. 그것이 바로 uORB::Manager 클래스이며, 객체 지향 프로그래밍 디자인 패턴 중 가장 극단적인 통제 형태인 싱글톤(Singleton) 패턴으로 구현되어 있다.
1. 싱글톤(Singleton) 패턴의 적용 이유
싱글톤 패턴의 핵심 철학은 “전체 시스템 메모리(RAM) 상에 이 객체의 인스턴스(Instance)는 오직 단 하나만 존재해야 하며, 전역적인 접근점(Global Access Point)을 제공해야 한다” 는 것이다. uORB::Manager 에 이 패턴이 강제된 이유는 명확하다.
- 동시성 제어(Concurrency Control): 수백 개의 태스크가 동시다발적으로 토픽을 발행(Publish)하고 구독(Subscribe)할 때, 경로를 배정하고 버퍼를 할당하는 작업은 반드시 원자적(Atomic) 으로 이루어져야 한다. 단일 매니저가 전역 뮤텍스(Global Mutex)나 세마포어(Semaphore)를 쥐고 교통정리를 해야만 교착 상태(Deadlock)와 데이터 레이스(Data Race)를 원천 차단할 수 있다.
- 메모리 파편화(Fragmentation) 방지: 항공기 제어 시스템에서 동적 메모리 할당(
malloc/new)은 힙(Heap) 파편화를 유발하여 치명적인 타이밍 에러를 낳는다. 단방향 싱글톤 매니저가 시스템 부팅 시점에 필요한 메모리 풀(Memory Pool)을 한 번에 확보하여 평생 관리하는 구조가 안전하다. - VFS 마운트(Mount) 포인트의 유일성: 뒤이어 설명할 가상 파일 시스템(VFS)의
/obj디렉토리는 단일 진입점을 통해서만 안전하게 생성되고 파괴되어야 한다.
2. uORB::Manager의 구조적 특징
uORB::Manager의 C++ 원시 코드를 살펴보면 전형적인 싱글톤의 기법들이 엄격하게 적용되어 있다.
Manager클래스의 생성자(Constructor)와 소멸자(Destructor)는private영역에 감춰져 있어, 외부 모듈이 임의로new uORB::Manager()를 호출하여 복제본을 만드는 행위를 컴파일 타임에 철저히 금지한다.- 대신 외부 모듈들은 오직
uORB::Manager::get_instance()라는 정적(Static) 메서드를 통해서만 사전에 생성된 유일한 객체의 포인터를 얻어올 수 있다.
3. 초기화(Initialization)의 세 가지 핵심 임무
이 거대한 단일 통제 타워는 PX4가 부팅될 때 생명력을 얻어 구동을 시작하며, 주로 세 가지 거대한 막후 작업을 수행하여 비행 제어기 통신망의 기초 공사를 다진다.
- VFS 베이스 디렉토리 생성: NuttX의 가상 파일 시스템 루트(Root)에 토픽들이 장치 노드로 등록될 전용 폴더인
/obj디렉토리를 생성한다. uORBDeviceMaster인스턴스화: 실제로 토픽들의 명부(Ledger)를 기록하고 노드의 생명주기를 관리하는 핵심 부관격 클래스인DeviceMaster를 메모리에 띄운다.- 통신 프로토콜 노드 초기화: 외부 이기종(라즈베리 파이, ROS2 등)과의 패킷 브릿징을 담당하는 통신 채널(uXRCE-DDS 등)과의 파이프를 구축할 준비를 마친다.
이 싱글톤 매니저가 정확히 시스템의 어느 시점에 깨어나며(18.3.1.1절), 핵심 부관인 uORBDeviceMaster가 실질적으로 어떻게 전역 메모리를 할당하고 관리하는지(18.3.1.2절)에 대한 구체적인 메커니즘은 이어지는 하위 절들에서 소스 코드 레벨로 낱낱이 파헤칠 것이다.