19.6.1.1. 단일 Topic 내 인스턴스 식별자(Instance ID)의 역할

우리가 이전 단원까지 아무 생각 없이 썼던 단순 무식한 orb_subscribe(ORB_ID(topic)) API 명령어를 커널 스케줄러의 메모리 관점에서 아주 냉정하게 해부해 보면, 사실 그 내부에는 **“아무 말 안 했으니 무조건 0번 인스턴스 파이프라인의 키만 내놓아라”**라는 암묵적이고 거만한 디폴트(Default) 규칙이 숨어 있었다.
지금까지 우리가 만든 예제 코드가 터지지 않고 잘 굴러갔던 유일한 이유는 시스템에 sensor_test_data를 발행하는 퍼블리셔 데몬이 세상에 단 1명밖에 없었기 때문에, 당연히 그가 쓴 파이프가 0번 방이었고 우리가 구독한 방도 0번 방이라 운 좋게 주소가 아귀가 맞았을 뿐이다.

하지만 다중 인스턴스의 핏빛 전장에서는 이 평화로운 규칙이 산산조각 난다. 마더보드에 3개의 가속도계 센서가 달리고 데몬 3개가 동시에 기동 되면, 그들은 각자 VFS 커널을 향해 아우성치며 “집을 지어달라“고 orb_advertise_multi()를 때려 댈 것이다. 커널은 이들의 선착순 요청에 따라 냉혹하게 0번, 1번, 2번이라는 정수형 번호표, 즉 **인스턴스 식별자(Instance ID)**를 발급하여 그들의 목에 강제로 걸어버린다.

1. 인스턴스 식별자(Instance ID): 런타임 메모리 주소록의 유일한 마스터 키

이 Instance ID는 단순한 구분이 아니라, 동일한 ORB_ID 껍데기 이름표 밑에 물리적으로 쪼개진 수많은 서브 링 버퍼(Sub-Ring Buffer)들 중 정확히 어느 파이프라인의 꼬리에 꽂고 통신할 것인가를 결정하는 절대적인 시스템 DNS 주소 마스터 키이다.

1. 퍼블리셔 관점의 ID: 퍼블리셔 시스템 데몬이 커널을 향해 “나도 vehicle_acceleration 클럽에 합류하겠다“라고 최초로 광고(Advertise)를 칠 때, 커널은 int instance_id 값을 포인터 반환 값으로 뱉어준다. “너는 지금 시스템에서 두 번째로 등록했으니, 네 ID는 평생 ’1’번이다.” 만약 이 퍼블리셔가 자신의 이 ’1’번 ID 메모리를 잃어버리고 나중에 무지성으로 업데이트를 때리면, 자기가 쓴 데이터가 0번 방으로 들어갔는지 1번 방으로 새서 섞였는지 자신조차 통제할 수 없게 되어 커널 패닉을 유발한다.
2. 구독자 관점의 ID: 이 멀티 버퍼들을 실시간으로 빼먹어야 하는 구독자 데몬에게 이 ID는 더욱 처절하다. 단순히 “가속도계 줘“라고 말하면 커널은 에러를 뱉는다. 반드시 “가속도계 1번 방(Instance 1)의 마스터 읽기 키를 개통해 달라“고 명시적으로 orb_subscribe_multi(ORB_ID(vehicle_acceleration), 1) 인터페이스를 타격해야만, 오직 उस I2C 센서가 생산해 낸 순수한 데이터 흐름망에만 정확히 빨대를 꽂을 수 있다.

2. 동적 할당의 맹점과 토폴로지 ID 역추적(Tracking)의 의무

여기서 다중 인스턴스 코딩을 처음 접하는 개발자들이 가장 많이 범하는 치명적인 아키텍처 실수가 하나 있다. 바로 “내 최고의 SPI 가속도계 센서 데몬은 무스펙 최고 성능이니까 항상 부팅할 때마다 무조건 0번 인스턴스를 차지할 것이다“라고 오만하게 하드코딩(Hard-coding)을 해버리는 것이다.

PX4 NuttX RTOS 시스템은 부팅 스크립트(rc.board, rc.sensors)에 의해 철저한 멀티스레드 병렬 논블로킹(Non-blocking) 비동기 실행을 지원한다. 즉, 어떤 날은 SPI 센서 데몬이 운 좋게 먼저 켜져서 커널로부터 0번 ID를 따내겠지만, 다음 날 겨울철 영하의 온도에서 SPI 칩셋의 초기화가 10ms 지연되면, 쓸데없이 일찍 켜진 I2C 쓰레기 예비 센서 데몬이 커널에 먼저 도착해 0번 ID 알박기를 훔쳐 가 버리는 끔찍한 순서 역전 현상(Race Condition)이 무조건 발생한다.
구독자가 어제처럼 “무조건 0번 먹어야지” 하고 핀셋 구독을 해버리면, 기체는 최고의 센서 데이터를 버려두고 가장 쓰레기 노이즈가 심한 센서의 데이터로만 연산을 수행하다 발산 추락하게 된다.

따라서 PX4 다중 인스턴스의 스케줄링 설계 철학에서 인스턴스 번호표(ID)는 절대 불변의 정적 숫자가 아니라, 비행할 때마다 엿장수 마음대로 순서가 뒤섞이는 극도로 불안정한 동적(Dynamic) 일회용 티켓으로 취급하고 철저히 예방 설계해야만 한다. 구독자 아키텍트는 19.6.3 단원 이후에서 배울 orb_group_count()를 통해 시스템에 존재하는 총인스턴스의 개수를 세고, N개의 모든 방을 다 열어보고 각 방표면의 타임스탬프 속도나 센서 에러 메타데이터를 직접 확인하여 **“도대체 이번 부팅에서는 어떤 번호의 방(Instance ID)이 가장 신뢰할 만한 메인 센서 방인가?”**를 스스로 투표 점수화(Voting)하여 동적으로 락온(Lock-on)하는 고도화된 선별(Selection) 아키텍처를 강제로 탑재해야만 한다.