18.3.3.1 인스턴스 ID 부여 규칙 및 VFS 노드 네이밍 컨벤션

단일 기체에 여러 개의 동일한 센서나 액추에이터가 장착되는 하드웨어의 이중화(Redundancy) 배치는 현대 무인항공기 아키텍처에서 피할 수 없는 필수 요구사항이다. 예를 들어, 신뢰성을 극대화하기 위해 기체 내부에 3개의 가속도 센서(Accelerometer) 모듈을 장착했다고 가정해 보자.

이 3개의 센서는 모두 sensor_accel 이라는 완벽히 동일한 uORB 토픽(Topic) 타입 뼈대(.msg)를 사용하여 데이터를 뿜어낸다. 그렇다면 uORB 매니저와 가상 파일 시스템(VFS)은 이 구별할 수 없는 쌍둥이들을 어떻게 식별하고 격리된 파이프라인으로 운용하는가? 그 해답이 바로 인스턴스 ID (Instance ID) 부여 메커니즘과 노드 네이밍 컨벤션(Naming Convention) 이다.

1. 영차원 기반(Zero-based) 인스턴스 ID

어떤 센서 드라이버가 부팅 시퀀스(Boot Sequence) 도중 처음으로 orb_advertise() (또는 내부적으로 orb_advertise_multi()) C++ API를 호출하여 자신을 시스템에 등록하려고 시도하면, uORB 매니저는 이 드라이버에게 인스턴스 ID 0번을 최초로 할당한다.

만약 또 다른 제조사의 외부 가속도 센서를 연결하고 드라이버가 기동되어 두 번째로 같은 sensor_accel 토픽을 광고(Advertise)하면, 매니저는 기존에 등록된 0번이 있음을 확인한 후 이 새로운 센서에게 자동 증가(Auto-increment) 로직에 따라 인스턴스 ID 1번을 쥐여 준다.

• Primary (최초 인식 가속도계): Instance ID 0
• Secondary (두 번째 인식 가속도계): Instance ID 1
• Tertiary (세 번째 인식 가속도계): Instance ID 2

이러한 동적 런타임 ID 체계 덕분에 펌웨어 소스 코드를 하드 코딩(Hard Coding)으로 수정하지 않고도 동적 센서 확장이 수월하게 이루어진다.

2. VFS 노드 네이밍 컨벤션: 문자열 합성(String Concatenation)

인스턴스 ID의 진정한 가치는 이 번호가 NuttX 커널의 가상 파일 시스템(VFS)인 /obj 하위 경로(Path)로 맵핑(Mapping)되는 네이밍 컨벤션 규칙에서 발휘된다.

개발자는 소스 코드에서 특정 디바이스 노드의 문자열을 생성할 걱정을 할 필요가 없다. uORB 코어는 ORB_ID(topic_name)으로 넘어온 순수 토픽 문자열 이름에 문자열 서식(Formatting) 기법을 사용하여, 방금 발급된 인스턴스 ID 정수형 숫자를 꼬리표(Suffix)로 붙여(Concatenate) 최종 VFS 경로로 변환한다.

이 규칙은 예외 없이 다음과 같은 정규 표현식 패턴을 엄격히 따른다.
/obj/[토픽_이름][인스턴스_ID]

이 컨벤션에 따라, 앞서 예시로 든 3개의 가속도 센서는 VFS 상에서 다음과 같이 물리적으로 완전히 고립된 3개의 개별적인 문자 디바이스 캐릭터 노드(Character Device Node) 파일들로 분리되어 생성된다.

1. /obj/sensor_accel0
2. /obj/sensor_accel1
3. /obj/sensor_accel2

비행 제어 소프트웨어 내에서 Sensor Fusion(센서 융합)을 담당하는 EKF2 구독자(Subscriber) 모듈은 이제 파일 디스크립터(File Descriptor) 인터페이스(open())를 활용하여 /obj/sensor_accel1 경로를 단독으로 타겟팅해 파일을 여는 방식을 통해, 다른 가속도계 데이터와 섞이는 오염 현상 없이 1번(Secondary) 센서만의 고유한 자이로스코프 파이프라인에 안전하게 접근할 수 있는 것이다.