본 보고서는 PX4 자율비행 스택을 Xenomai 실시간 프레임워크에 이식하고, 이를 단일 보드 컴퓨터(SBC) 상에서 표준 리눅스와 함께 구동하여 비행 제어 컴퓨터(FCC)와 임무 컴퓨터(Mission Computer)의 기능을 통합하는 시스템 아키텍처에 대한 기술적 타당성, 구현 전략, 그리고 내재된 과제를 심층적으로 분석한다. 분석 결과, 이러한 통합 시스템은 기술적으로 구현 가능하며, 특히 안전이 중요한(safety-critical) 애플리케이션에서 비실시간 임무 소프트웨어로부터 실시간 비행 제어부를 보호하는 탁월한 아키텍처적 격리(isolation)를 제공함을 확인하였다. 그러나 이 아키텍처의 성공적인 구현은 Xenomai의 이중 커널(dual-kernel) 환경에 특화된 실시간 디바이스 드라이버(RTDM Driver) 개발에 상당한 공학적 투자를 요구하는 중대한 트레이드오프(trade-off)를 수반한다. 따라서 본 보고서는 제안된 아키텍처가 차세대 고성능 자율 드론 시스템을 위한 강력한 솔루션임을 인정하면서도, 그 구현은 실시간 시스템에 대한 깊은 전문성과 예방적 개발 및 검증 방법론에 대한 조직적 헌신을 전제로 해야 함을 결론으로 제시한다.
전통적인 고성능 드론 아키텍처는 명확하게 분리된 두 개의 컴퓨팅 유닛으로 구성되는 것이 일반적이었다. 첫째는 NuttX와 같은 실시간 운영체제(RTOS)를 실행하는 자원 제약적인 비행 제어기(FC)이며, Pixhawk 시리즈가 그 대표적인 예시다. 둘째는 고수준의 임무를 처리하기 위해 별도로 탑재되는 동반 컴퓨터(Companion Computer)로, 주로 Raspberry Pi나 NVIDIA Jetson 같은 보드에서 리눅스를 구동한다.1 이러한 물리적 분리 구조는 비행 제어의 안정성을 보장하는 강력한 격리 수단을 제공했지만, 동시에 두 시스템 간의 통신 지연(latency), 크기, 무게, 전력(SWaP; Size, Weight, and Power)의 비효율성, 그리고 데이터 처리량의 병목 현상이라는 명백한 한계를 내포했다.
그러나 자율 시스템 기술이 발전함에 따라, 이러한 분리형 모델은 한계에 부딪히기 시작했다. 컴퓨터 비전, 시각적 관성 주행 거리 측정(VIO; Visual Inertial Odometry), 실시간 경로 계획과 같은 고급 자율 기능은 센서 데이터의 수집, 처리, 그리고 액추에이터 구동 간에 기존 모델이 제공할 수 있는 것보다 훨씬 더 긴밀한 통합과 낮은 지연 시간을 요구한다.3 LiDAR나 고해상도 카메라와 같은 센서로부터 방대한 데이터 스트림을 기체 내에서 직접 처리하여 실시간으로 의사결정을 내리고, 지상국(Ground Station)에 대한 의존도를 줄이는 것이 현대 자율 드론의 핵심 과제로 부상했다.3
이러한 시대적 요구는 단일 고성능 단일 보드 컴퓨터(SBC)가 비행 제어 컴퓨터(FCC)와 임무 컴퓨터의 역할을 동시에 수행하는 통합 항공전자 시스템의 등장을 촉진했다. 이 개념은 비행 제어기, 임무 컴퓨터, 그리고 통신 모듈을 하나의 제품으로 통합한 Auterion의 Skynode X와 같은 상용 제품을 통해 현실화되고 있다.4 이 패러다임의 전환은 단순히 하드웨어의 통합을 넘어, 자율 시스템 소프트웨어 아키텍처의 근본적인 변화를 의미한다. 이는 개발자들이 안전 필수적인 제어 루프를 위해 리눅스와 같은 범용 운영체제(GPOS)가 가진 본질적인 한계에 직면하게 만들었으며, 과거에는 일부 특수 분야의 관심사였던 실시간 기술을 고급 드론 개발의 주류 요구사항으로 끌어올렸다.
통합 아키텍처의 핵심에는 결정성(determinism)과 처리량(throughput)이라는 상충하는 두 가지 요구사항이 존재한다. 임무 컴퓨터의 워크로드, 즉 리눅스 애플리케이션(예: ROS, 컴퓨터 비전 라이브러리)은 높은 데이터 처리량에 최적화되어 있지만, 스케줄링, 메모리 관리, 복잡한 소프트웨어 스택으로 인해 본질적으로 비결정적(non-deterministic)이며 예측 불가능한 지연 시간을 가진다.3
반면, FCC의 워크로드, 즉 PX4 비행 제어 스택은 하드 실시간(hard real-time) 성능을 요구한다. 이는 센서 입력과 제어 루프 실행에 대해 예측 가능하고, 경계가 정해져 있으며, 낮은 지연 시간을 갖는 응답을 의미한다.6 비행 제어 루프에서 단 한 번의 데드라인(deadline) 위반은 기체의 불안정성을 초래하고 치명적인 고장으로 이어질 수 있다.
이러한 아키텍처 통합의 흐름은 다음과 같은 논리적 귀결을 낳는다.
따라서 본 보고서가 다루는 중심 질문은 ‘단일 하드웨어 상에서 이처럼 상반된 요구사항을 동시에 만족시키는 소프트웨어 시스템을 어떻게 설계할 것인가?’이다.
Xenomai는 표준 리눅스 커널과 나란히 실행되는 보조 커널(co-kernel) 또는 동반 코어(companion core)를 제공하는 실시간 프레임워크이다.8 Xenomai의 핵심 원리는 리눅스 커널 전체를 실시간으로 만들려고 시도하는 대신, 작고 검증 가능한 별도의 실시간 코어(Cobalt)를 제공하고 여기에 리눅스보다 절대적인 우선순위를 부여하는 것이다.9 즉, 리눅스 커널은 Cobalt 코어가 처리할 실시간 작업이 없을 때만 실행될 기회를 얻는다.
이러한 구조는 명확한 관심사 분리(separation of concerns)를 만들어낸다. Cobalt는 시간에 민감한 작업을 전담하고, 리눅스는 그 외 모든 일반적인 작업을 처리한다.10 이는 아키텍처적으로 두 개의 커널이 거의 비동기적으로 작동하며 각자의 작업 집합을 서비스하는 것으로 묘사될 수 있다.10
이러한 이중 커널 아키텍처를 가능하게 하는 핵심 메커니즘은 Dovetail 인터럽트 파이프라인(구 버전에서는 I-pipe로 불림)이다.11 Dovetail은 리눅스 커널에 적용되는 패치로, 높은 우선순위의 실행 단계를 도입한다. 이 파이프라인은 모든 하드웨어 인터럽트를 리눅스 커널이 인지하기 전에 가로챈다.14
파이프라인은 가로챈 인터럽트를 먼저 Cobalt 코-커널로 라우팅한다. 만약 Cobalt가 해당 인터럽트에 대한 핸들러를 등록해 두었다면, 인터럽트는 결정론적인 지연 시간 내에 즉시 처리된다. 그렇지 않은 경우, 인터럽트는 파이프라인을 따라 표준 리눅스 커널로 전파된다.16 이 메커니즘이야말로 리눅스의 스케줄링 지연과 비선점(non-preemptible) 구간으로부터 실시간 도메인을 보호하는 ‘방화벽’ 역할을 수행한다.10
실시간 리눅스를 구현하는 또 다른 주요 접근 방식은 PREEMPT_RT 패치이다. 이 두 기술 간의 비교는 통합 항공전자 시스템의 아키텍처를 결정하는 데 있어 매우 중요하다.
이러한 차이점을 기반으로, Xenomai를 선택하는 것은 타협 불가능하고 검증 가능한 실시간 격리를 위해 개발 속도와 하드웨어 채택의 용이성을 희생하는 전략적 결정이라고 볼 수 있다. 악명 높은 “RTDM 드라이버 문제”는 결함이 아니라, 이러한 강력한 격리를 얻기 위해 지불해야 하는 대가인 것이다. PREEMPT_RT를 사용하는 개발자는 표준 리눅스 드라이버가 종종 별다른 수정 없이 작동하기 때문에 새로운 하드웨어에서 시스템을 신속하게 구동할 수 있다.24 반면, Xenomai 개발자는 모든 핵심 주변 장치에 대한 RTDM 드라이버의 존재 여부를 확인해야 하며, 만약 없다면 이를 직접 포팅해야 하는 주요 과제에 직면한다.17 그러나 PREEMPT_RT 시스템에서는 새로 설치된 비핵심 USB 장치의 버그 있는 드라이버가 이론적으로 시스템 전반의 지연 시간을 유발하여 비행 제어기가 데드라인을 놓치게 할 수 있다. Xenomai 시스템에서는 동일한 버그 있는 드라이버가 리눅스 도메인에만 영향을 미칠 뿐, Cobalt 코어와 통신하는 PX4의 RTDM 드라이버는 별도의 보호된 실행 컨텍스트에 존재하므로 전혀 영향을 받지 않는다.10 따라서 Xenomai를 사용하는 결정은 잠재적인 시스템 오류의 한 종류를 원천적으로 제거하기 위해 맞춤형 격리 드라이버 스택을 만드는 데 엔지니어링 자원을 선투자하는 명시적인 선택이며, 이는 전형적인 안전 공학의 트레이드오프다.
| 기능 | Xenomai/Cobalt | PREEMPT_RT | 통합 항공전자 시스템에 대한 함의 |
|---|---|---|---|
| 코어 아키텍처 | 이중 커널 (코-커널) | 단일, 완전 선점형 커널 | Xenomai는 실시간과 비실시간 워크로드를 하드웨어 수준에서 격리한다. |
| 실시간 보증 | 격리를 통한 하드 실시간 | 커널 전반의 선점을 통한 하드 실시간 | Xenomai의 보증은 리눅스 도메인의 부하 변동에 덜 민감하다. |
| 격리 수준 | RT와 비-RT 도메인 간의 강력한 격리 | 약한 격리 (리눅스 드라이버가 RT 성능에 영향 가능) | 임무 컴퓨터 소프트웨어의 오류가 비행 제어에 영향을 미치는 것을 방지하는 데 Xenomai가 월등히 우수하다. |
| 드라이버 모델 | 맞춤형 RTDM 드라이버 필요 | 표준 리눅스 드라이버 재사용 가능 | Xenomai는 개발 비용과 복잡성이 훨씬 높지만, 드라이버 수준에서 결정성을 보장한다. |
| 개발 복잡성 | 높음 (RTDM 드라이버 작성/포팅 필수) | 중간 (표준 POSIX 개발, 시스템 튜닝 필요) | PREEMPT_RT는 초기 개발 속도가 빠르지만, Xenomai는 아키텍처적으로 더 엄격한 실시간 제약을 강제한다. |
| 장기 유지보수 | 높음 (RTDM 드라이버가 메인라인에 뒤쳐질 위험 17) | 중간 (메인라인 리눅스와 더 가까워 업데이트 용이) | Xenomai의 드라이버 스택은 별도의 유지보수 노력을 요구한다. |
| 이상적인 사용 사례 | RT 실패가 용납되지 않는 혼합 임계 시스템 | RT와 비-RT 작업이 긴밀하게 통합되거나 개발 속도가 중요한 시스템 | 제안된 통합 FCC/임무 컴퓨터는 Xenomai의 이상적인 사용 사례에 해당한다. |
PX4의 핵심 설계 원칙은 다양한 운영체제에 걸친 이식성(portability)이다.26 이를 가능하게 하는 열쇠는 스레딩, 스케줄링, 파일 I/O 등 모든 OS 상호작용에 대해 표준 POSIX API에 의존한다는 점이다.28 PX4가 NuttX, 리눅스, macOS, QuRT 등에서 실행될 수 있는 이유는 이들 모두가 이 표준 인터페이스를 제공하기 때문이다.
이는 매우 중요한 설계 결정이다. 더 모놀리식(monolithic) 구조를 가진 Ardupilot과 달리, PX4는 POSIX에 의존함으로써 깊이 임베디드된 펌웨어라기보다는 표준 사용자 공간 애플리케이션의 집합과 유사한 형태를 띤다.28
PX4의 내부 통신 메커니즘은 uORB (Micro Object Request Broker)라는 발행-구독(publish-subscribe) 메시지 버스에 기반한다.29 모듈들은 서로를 직접 호출하지 않는다. 대신, vehicle_attitude와 같은 ‘토픽(topic)’에 데이터를 발행하고, sensor_combined와 같이 필요한 토픽을 구독한다. 이는 반응적(reactive)이고 비동기적이며 고도로 병렬화된 시스템을 만들어낸다.29
실행은 데이터 중심으로 이루어진다. 모듈은 일반적으로 구독 중인 토픽에 대한 업데이트를 기다렸다가, 계산을 수행하고, 그 결과를 발행한다.31 이 메커니즘은 공유 메모리를 기반으로 구현되어 매우 효율적이다.29
PX4의 OS 추상화 계층(OSAL)은 POSIX 호출을 기본 운영체제에 매핑하는 얇은 코드 계층이다. 실제 이식 작업은 이 계층에 집중된다. 모듈의 실행 컨텍스트는 크게 두 가지로 나뉜다:
SCHED_FIFO)를 가지고 실행된다.7PX4의 이러한 아키텍처는 단순히 ‘이식 가능’한 것을 넘어, Xenomai와 같은 이중 커널 환경에 거의 완벽하게 사전 적응되어 있다고 볼 수 있다. uORB 발행-구독 모델은 Xenomai/리눅스 분할을 그대로 반영하는 실시간/비실시간 경계를 가로지르는 모듈의 논리적, 물리적 분리를 가능하게 한다. 이식 작업은 전체를 한 번에 옮기는 거대한 작업이 아니라, PX4의 내재된 모듈성을 활용하여 각 모듈을 적절한 실행 도메인에 세밀하게 할당하는 과정으로 개념화될 수 있다. 예를 들어, 비행 안정성에 중요한 모듈들(ekf2_selector, mc_att_control 등)은 Xenomai 실시간 태스크로 컴파일되고, 비핵심적인 고수준 기능(복잡한 MAVLink 메시지 핸들러, 비필수 데이터 로거 등)은 표준 리눅스 프로세스로 실행될 수 있다. 이 두 모듈 집합 간의 uORB 통신은 섹션 5에서 논의될 도메인 간 IPC 메커니즘(예: 공유 메모리 기반 uORB 브리지)을 통해 구현된다. 이는 즉각적으로 드러나지 않을 수 있는 강력한 시너지 효과다.
이식의 첫 단계는 PX4 코드베이스가 Xenomai 라이브러리에 대해 컴파일되도록 만드는 것이다. 이는 PX4 빌드 시스템(CMake)을 수정하여, Xenomai를 타겟으로 하는 올바른 컴파일러 및 링커 플래그를 제공하는 xeno-config 유틸리티를 사용하도록 하는 것을 포함한다.32
스레딩 및 스케줄링: PX4의 태스크 생성 호출(px4_task_spawn_cmd 31)을 Xenomai의 POSIX 스킨이 제공하는
pthread_create에 매핑한다. PX4가 리눅스에서 사용하는 실시간 스케줄링 정책(SCHED_FIFO)과 우선순위가 7 Xenomai 스케줄러에 의해 올바르게 요청되고 존중되는지 확인해야 한다.
동기화: PX4가 사용하는 뮤텍스, 조건 변수와 같은 POSIX 동기화 기본 요소들이 실시간에 안전한 Xenomai POSIX 스킨 구현체에 직접 매핑되는지 검증한다.
| POSIX 기능 | PX4/표준 POSIX 호출 | Xenomai POSIX 스킨 동등물 | 구현 노트 및 주의사항 |
|---|---|---|---|
| 태스크 생성 | pthread_create |
pthread_create |
태스크가 Xenomai의 주 모드(primary mode)에서 생성되는지 확인해야 한다. |
| 태스크 스케줄링 | pthread_setschedparam |
pthread_setschedparam |
SCHED_FIFO 정책과 실시간 우선순위가 Cobalt 코어에 의해 관리되는지 확인한다. |
| 뮤텍스 | pthread_mutex_* |
pthread_mutex_* |
Xenomai의 실시간 안전 뮤텍스가 사용된다. 우선순위 상속(priority inheritance) 프로토콜 지원을 확인한다. |
| 세마포어 | sem_* |
sem_* |
실시간 컨텍스트에서 안전하게 사용 가능. 도메인 전환을 유발할 수 있는 블로킹 호출에 유의한다. |
| 조건 변수 | pthread_cond_* |
pthread_cond_* |
뮤텍스와 함께 사용 시, 대기 중인 태스크가 비실시간 태스크에 의해 지연되지 않도록 주의한다. |
| 타이머/지연 | timer_create, nanosleep |
timer_create, nanosleep |
Xenomai의 고정밀 타이머를 사용한다. 도메인 전환을 유발하지 않는 실시간 안전 버전인지 확인한다. |
이것은 이식 과정에서 가장 중요하고 노동 집약적인 부분이다. SPI, I2C, UART 등을 위한 표준 리눅스 드라이버는 블로킹 호출을 사용하고 Cobalt 코어에 의해 관리되지 않기 때문에 실시간 태스크에서 사용할 수 없다.17
실시간 드라이버 모델(RTDM)은 Xenomai가 결정적이고 커널 공간에서 실행되는 드라이버를 만들기 위해 제공하는 프레임워크이다.11
rtdm_dev_register를 사용하여 RTDM 코어에 자신을 등록한다._rt) 및 비실시간(_nrt) 컨텍스트를 위한 별도의 핸들러(예: open_rt, read_rt, ioctl_rt)를 구현한다.34 이를 통해 동일한 장치를 Xenomai와 리눅스 애플리케이션 양쪽에서 접근할 수 있다.xnintr_attach를 사용하여 Cobalt 코어에 인터럽트 서비스 루틴(ISR)을 등록한다.16 이 ISR은 높은 우선순위의 out-of-band 컨텍스트에서 실행되며, 매우 빠르고 비블로킹(non-blocking)이어야 한다. 일반적으로 데이터가 준비되었음을 대기 중인 실시간 태스크에 알리는 역할을 한다.rtdm_copy_to_user 및 rtdm_copy_from_user와 같은 실시간 안전 함수를 사용한다.38inv_mpu6050)에서 시작한다.rtdm_driver 구조체)을 생성한다.probe 함수를 구현한다.read_rt 및 write_rt 핸들러로 포팅하고, 표준 커널 I2C 전송 함수를 RTDM 호환 동등물이나 필요한 경우 직접적인 레지스터 조작으로 대체한다. (참고: RTDM은 CAN, Serial에 대한 프로파일을 제공하지만, I2C/SPI는 종종 spi-bcm283x-rtdm 39과 같은 기존 RTDM SPI 드라이버를 참조하여 더 직접적이고 맞춤화된 구현이 필요하다.)rtdm_read()를 호출한 PX4 센서 모듈 태스크를 깨우게 된다.단계별 워크플로우는 다음과 같다.
prepare-kernel.sh 스크립트를 실행하여 커널 소스에 Dovetail 패치를 적용한다.42make menuconfig를 통해 커널을 설정한다. Xenomai/Cobalt 옵션, RTDM 드라이버를 활성화하고, 지연 시간을 악화시키는 기능(예: CPU 주파수 스케일링, 깊은 CPU 유휴 상태)을 비활성화한다.33PX4가 실시간 도메인에서 실행되고, 컴퓨터 비전이나 고수준 임무 계획을 위한 ROS2 노드와 같은 다른 애플리케이션들이 비실시간 리눅스 도메인에서 실행됨에 따라, 두 도메인 사이에는 견고하고 낮은 지연 시간을 갖는 통신 브리지가 필수적이다.45 이 섹션에서는 이 브리지를 위한 솔루션을 설계한다.
VIO나 로깅을 위해 리눅스 프로세스에서 소비해야 하는 IMU 측정값이나 자세 추정치와 같은 고주파 데이터의 경우, 공유 메모리가 가장 효율적인 방법이다. Xenomai의 POSIX 스킨은 다음과 같은 공유 메모리 API를 제공한다:
shm_open(): 이름 있는 공유 메모리 객체를 생성하거나 연다.46ftruncate(): 메모리 객체의 크기를 설정한다.46mmap(): 객체를 실시간 태스크와 리눅스 프로세스 양쪽의 주소 공간에 매핑한다.46매핑이 완료되면, 양쪽 모두 동일한 물리적 메모리를 가리키는 포인터를 갖게 되어 복사 없는(zero-copy) 데이터 전송이 가능해진다. 접근을 관리하고 경쟁 상태(race condition)를 방지하기 위해서는 실시간 안전 뮤텍스나 세마포어와 같은 동기화 메커니즘이 공유 메모리 영역 자체에 위치해야 한다.46
리눅스 프로세스에서 PX4 모듈로 명령을 보내는 것과 같은 메시지 기반 통신을 위해, Xenomai는 소켓 기반 API인 RTIPC (Real-Time Inter-Process Communication)를 제공한다.49 주요 프로토콜은 다음과 같다:
이 API는 표준 버클리 소켓 API(socket(), bind(), sendto(), recvfrom())를 모방하여 네트워크 프로그래머에게 익숙하다.49 이는 이벤트 기반 통신을 위해 공유 메모리보다 더 구조화되고 견고한 대안을 제공한다.
잘 설계된 도메인 간 브리지는 단순한 데이터 파이프가 아니라 실시간 시스템을 위한 ‘충격 흡수 장치’ 역할을 한다. IPC 메커니즘을 신중하게 선택함으로써, 아키텍트는 실시간 도메인과 비실시간 도메인 간의 결합(coupling) 정도를 제어할 수 있다. 예를 들어, IMU 데이터를 소비하는 리눅스 기반 VIO 알고리즘을 생각해보자. 만약 이 알고리즘이 블로킹 recvfrom() 호출을 사용하고 VIO 프로세스가 멈춘다면, 데이터를 sendto() 하려는 실시간 PX4 태스크가 잠재적으로 블록될 수 있다. 그러나 공유 메모리 링 버퍼 접근 방식을 사용하면, 실시간 PX4 태스크는 링 버퍼에 IMU 데이터를 계속 덮어쓰기만 할 뿐, VIO 프로세스가 멈추더라도 전혀 영향을 받지 않고 블록되지 않는다. 실시간 도메인은 완전히 분리되고 결정적인 상태를 유지한다. 이는 IPC 메커니즘의 선택과 구현 자체가 시스템의 실시간 보증을 확보하는 데 있어 중요한 부분임을 보여준다.
| 메커니즘 | 지연 시간 | 처리량 | 오버헤드 | 동기화 | 대표 사용 사례 |
|---|---|---|---|---|---|
| POSIX 공유 메모리 | 극도로 낮음 (복사 없음) | 매우 높음 | 매우 낮음 | 수동 (사용자 구현 필요) | 스트리밍 센서 데이터, 비디오 프레임, 상태 벡터 |
| RTIPC (XDDP 소켓) | 낮음 (커널 버퍼링 포함) | 높음 | 낮음 | API에 의해 관리됨 | 이벤트 기반 명령, 임무 웨이포인트, 상태 업데이트 |
표준 디버깅 도구는 Xenomai의 실시간 컨텍스트에서 문제가 될 수 있다. out-of-band 컨텍스트(예: RTDM ISR)에서 printk()를 호출하면 출력이 지연되거나, 고주파 상황에서는 콘솔 드라이버를 압도하여 시스템 정지를 유발할 수 있다.51
raw_printk(): 임계 구역에서 저수준의, 직렬 콘솔로 직접 출력하는 디버깅에 사용한다.51CONFIG_DEBUG_IRQ_PIPELINE과 CONFIG_DEBUG_DOVETAIL을 활성화한다. 이들은 실시간 컨텍스트에서 비재진입(non-reentrant) 리눅스 서비스를 호출하는 것과 같은 불법적인 연산을 잡아내는 런타임 검사를 추가한다.52가장 위험한 버그는 시스템 충돌이 아니라 성능 저하이다. 실시간 태스크가 불법적인 시스템 호출(예: 표준 파일 I/O, malloc)을 하면 비실시간 리눅스 도메인으로 조용히 ‘강등’될 수 있다.54
탐지 및 예방:
코드 규율: 실시간 태스크에 필요한 모든 메모리는 임계 루프에 진입하기 전에 정적으로 할당한다. mlockall()을 사용하여 메모리 페이지를 잠가 스와핑(swapping)을 방지한다.54
모니터링: Xenomai의 /proc/xenomai/sched/threads 인터페이스를 사용하여 각 실시간 태스크의 “MSW”(Mode Switches) 카운트를 모니터링한다. 증가하는 MSW 카운트는 문제의 명백한 신호이다.48 또한 Xenomai는 전환이 발생할 때
SIGXCPU 신호를 보내도록 설정할 수 있으며, 이는 디버거로 잡을 수 있다.54
최종 단계는 시스템이 실시간 데드라인을 충족함을 증명하는 것이다. Xenomai 테스트 스위트의 latency 테스트를 사용하여 부하 상태에서 시스템의 인터럽트 및 스케줄링 지연 시간의 기준선을 측정한다.13 목표는 평균 지연 시간이 아니라
최악의 경우 지연 시간을 찾는 것이다. 이를 위해서는 리눅스 도메인에 커널 컴파일, 네트워크 트래픽, 디스크 I/O와 같은 무겁고 예측 불가능한 스트레스를 가하면서 장시간(수 시간 또는 수 일) 테스트를 실행하여 병적인 사례를 발견해야 한다.55
테스트 중에는 SMI(시스템 관리 인터럽트), CPU 주파수 스케일링, 깊은 유휴 상태와 같이 상당하고 예측 불가능한 지연 시간을 유발할 수 있는 비결정성의 원인들을 비활성화해야 한다.44
성공적인 Xenomai 프로젝트는 ‘실시간 우선’ 개발 문화를 요구한다. 디버깅과 검증은 나중의 일이 될 수 없으며, 개발 첫날부터 프로세스에 통합되어야 한다. 디버깅의 어려움은 코딩에 있어 더 엄격하고 예방적인 접근을 필요로 한다. 표준 리눅스 개발자는 GDB, Valgrind와 같은 풍부한 디버깅 도구에 익숙하지만, 이들 중 다수는 Xenomai의 주 실시간 도메인에서 사용할 수 없거나 신뢰할 수 없다.51 실시간 태스크의 버그는 충돌을 일으키기보다는 미묘한 지터 증가를 유발할 수 있어 사후 추적이 매우 어렵다. 따라서 개발 프로세스는 ‘작성 후 디버그’에서 ‘검증 가능성을 고려한 설계’로 전환되어야 한다. 이는 비실시간 안전 호출을 찾기 위한 엄격한 코드 검토, 모든 개발 빌드에서 커널 디버그 플래그의 의무적 사용, 스트레스 하에서 지연 시간 테스트를 포함하는 지속적인 통합을 의미한다. 팀은 실시간 컨텍스트 내에서 ‘금지된’ 연산(동적 메모리 할당, 블로킹 I/O 등) 목록을 내재화해야 한다. 이는 기술적인 변화일 뿐만 아니라 문화적, 프로세스 수준의 변화이다.
본 보고서는 제안된 통합 항공전자 아키텍처가 기술적으로 실현 가능할 뿐만 아니라, 차세대 고도의 자율 드론을 구축하기 위한 견고한 솔루션임을 결론 내린다. 핵심적인 트레이드오프는 탁월한 실시간 격리와 시스템 안전성을 확보하는 대가로 RTDM 드라이버 개발에 상당한 엔지니어링 투자가 필요하다는 점이다. 프로젝트의 성공은 실시간 시스템에 대한 팀의 전문성과 엄격하고 예방적인 개발 및 검증 방법론에 대한 헌신에 달려 있다.
마지막으로, Xenomai 프레임워크의 가장 큰 고충인 RTDM 드라이버 모델을 해결하기 위한 차세대 Xenomai의 방향을 조망할 필요가 있다.10 Xenomai 4의 EVL (Even Less) 코어는 동일한 Dovetail 파이프라인 위에 구축되었으며, 메인라인 커널과의 긴밀한 통합을 통해 완전히 분리된 포크(fork) 드라이버의 필요성을 줄이는 것을 장기적인 목표로 한다.10
현재 프로젝트를 Xenomai 3 기반으로 구축하는 것은 견고한 토대를 마련하는 것이며, 향후 Xenomai 4/EVL로의 마이그레이션 경로는 맞춤형 드라이버 스택의 장기적인 유지보수 부담을 크게 줄일 수 있는 전략적인 전망을 제공한다. 이는 기술 선택에 대한 전략적 통찰을 제공하며, 현재의 높은 개발 비용이 미래의 유지보수 효율성 향상으로 이어질 수 있음을 시사한다.
| PX4 System Architecture | PX4 Guide (main), accessed July 7, 2025, https://docs.px4.io/main/en/concept/px4_systems_architecture.html |
| Drone Apps & APIs | PX4 Guide (main), accessed July 7, 2025, https://docs.px4.io/main/en/robotics/ |
| Flight Controller Porting Guide | PX4 Guide (main) - PX4 docs, accessed July 7, 2025, https://docs.px4.io/main/en/hardware/porting_guide.html |
| PX4 Architectural Overview | PX4 Guide (main) - PX4 docs, accessed July 7, 2025, https://docs.px4.io/main/en/concept/architecture.html |