13.4.3.1 입력-출력 포트(Port) 이름표 정의 및 멀티 스레드 타게팅 매핑 기법

13.4.3.1 입력-출력 포트(Port) 이름표 정의 및 멀티 스레드 타게팅 매핑 기법

복잡한 딥러닝 센서 융합(Sensor Fusion) 기능을 담당하는 Zenoh-Flow 오퍼레이터(Operator) 노드는 더 이상 1개의 데이터만 받고 1개의 결과만 뱉어내는 1차원적인 단순 파이프에 머무르지 않는다.
자율주행의 핵심 코어 노드는 “전방 카메라”, “후방 레이더”, “라이다 포인트“라는 3개의 거대한 스트림을 동시에 입력받아, 이를 융합 연산한 뒤 “스티어링 방향“과 “브레이크 답력“이라는 2개의 결과를 갈라치며 동시 출력하는 메두사와 같은 다중 포트(Multi-Port) 구조체로 진화한다.

본 절에서는 입력 구멍 3개와 출력 구멍 2개를 지닌 거대 비동기 노드 덩어리를 파이프라인망에 꽂아 넣기 위해, 포트(Port)에 명확한 식별표(ID)를 각인하고 데이터 직조(Weaving)의 오작동을 원천 봉쇄하는 매핑(Mapping) 아키텍처를 전개한다.

1. 멀티 포트(Multi-Port)의 스레드 붕괴와 식별표(Tag)의 당위성

로보틱스 초보 개발자들은 함수 인자로 데이터를 받을 때 그 배열의 도착 순서로 데이터를 구분하려 든다.
배열 inputs[0] 에는 카메라가, inputs[1] 에는 라이더 데이터가 들어온다고 맹신하고 하드코딩을 강행한다. 이는 비동기 분산 스트림 처리망에서 완벽하고 끔찍한 파국을 초래한다.

네트워크 지연으로 인해 라이더의 가벼운 패킷이 더 먼저 당도해버려 [0] 인덱스로 꽂히는 순간, 딥러닝 모델의 VRAM 텐서행렬에 카메라 이미지 대신 라이더 점군(Point Cloud)들이 들이부어지며 코어 덤프(Segmentation Fault)를 내뿜고 시스템이 즉각 동결사(Freeze) 당한다.
이 타임 어긋남(Timing skew)을 타파하기 위해선, 오퍼레이터 노드에 뚫려 있는 구멍(Port)들인 입력 배관과 출력 배관에 순서와 관계없이 절대 변하지 않는 논리적 현판, 즉 명시적 문자열 ID (Port Identifier) 를 단단히 각인해 매달아야만 한다.

2. 노드 내부 입출력 포트 명세화 런북

오퍼레이터를 컴파일할 때, 해당 노드가 어떠한 식별표를 가진 입/출력 배관을 소유하고 있는지 파이프라인 프레임워크 런타임에 소리쳐 보고(Declare)해야 한다.

# [Python 기반 융합 오퍼레이터의 멀티포트 인스턴스 구축 구조]

class SensorFusionOperator:
    def __init__(self):
        # 런타임에 이 노드의 스레드가 열리기 전, 구멍(Port)들의 명찰을 판다
        self.inputs = ["cam_in", "radar_in", "lidar_in"]
        self.outputs = ["steering_out", "brake_out"]

    # Zenoh-Flow 데몬이 데이터를 밀어 넣어줄 때 반드시 '포트 이름(Port_ID)' 꼬리표를 달고 찔러 넣는다.
    def on_data_received(self, port_id, data_capsule):
        
        # 순서나 도착 지연에 관계없이, 철저히 명판(Tag) 라벨 기반으로 분기(Routing)한다.
        if port_id == "cam_in":
            process_camera_thread_pool(data_capsule)
        elif port_id == "radar_in":
            process_radar_thread_pool(data_capsule)
            
        # ... 융합 내부 연산(Fusion)이 완료되었다면 ...
        
        # 방출할 때도, 어느 파이프 구멍으로 쏠지 명판을 지목하고 던져 넣는다
        send_data("steering_out", steering_payload)
        send_data("brake_out", emergency_brake_payload)

이 배관 명판화 설계로 인해, C++ 나 파이썬 안에서 도는 각각의 수신 스레드들은 자신의 배관(cam_in)으로만 데이터가 들어올 때까지 코루틴 블로킹(Couroutine Blocking)을 걸고 안전하게 잠들 수 있다. 도착 순서의 혼란과 경합(Race Condition) 지뢰밭이 포트 중심의 분리 아키텍처 아래서 완벽히 소거된다.

3. 매니페스트(YAML) 외부 용접망 타게팅

내부 로직에서 "cam_in" 과 "steering_out" 을 뚫어 두었다면, 시스템 SRE는 전체 뼈대를 지배하는 pipeline.yaml 디스크립터 상에서 이 명판(Tag)들을 찾아내어 철사로 무자비하게 용접(Link) 해버린다.

# [파이프라인 외부 타게팅 매핑(Link) 설계도]
links:
  # 외부 카메라 Source에서 생산된 데이터를, 융합 노드의 'cam_in' 이라는 특정 구멍에만 직격 타격한다
  - from: 
      node: "stereo_camera_source"
      output: "RGB_OUT"
    to:
      node: "sensor_fusion_operator"
      input: "cam_in"  # 절대적 타게팅 매핑!

  # 융합 노드의 'steering_out' 구멍에서 분출된 조향 결괏값을 훔쳐 액추에이터 싱크단으로 내동댕이친다
  - from:
      node: "sensor_fusion_operator"
      output: "steering_out"
    to:
      node: "can_bus_actuator_sink"
      input: "CMD_VEL_IN"

“어느 노드(Node)에 데이터를 넣을까?” 수준의 물류 설계는 학부생 수준의 1차원 배관공이다.
하드 리얼타임 데이터-플로우 네트워크의 아키텍트는 “어느 노드(Node)의, 식별된 어떤 포트 밸브(Port_ID)에 데이터를 타격해 넣고, 백그라운드 멀티 스레드 워커 프로토콜로 이관시킬 것인가?“를 철저히 장악하는 초거대 다차원 그래프(Multi-dimensional Graph) 제어의 지배자로 군림해야 한다.