SDV가 Zone Controller 기반 아키텍처로 전환되면서, 차량 내부의 다양한 통신 프로토콜과 데이터 흐름을 “하나의 표준 데이터 공간”으로 통합하는 문제가 핵심 과제로 떠올랐다. 이 글은 10BASE-T1S의 결정론적 멀티드롭 이더넷과 Zenoh 미들웨어, 그리고 COVESA VSS 데이터 모델을 결합해 레거시 호환을 유지하면서도 End-to-End 통신을 단순화·확장하는 방법을 보여준다. 특히 VSS – Zenoh 결합이 상호운용성과 개발 효율을 높이고, 차량–클라우드까지 이어지는 SDV 데이터 흐름의 ‘공통 언어’를 만드는 데 어떤 실질적 가치를 갖는지 짚는다. 글 | 윤승현 이사, 아이비스(ivis inc)
전통적인 도메인 중심 아키텍처에서 Zone 기반 아키텍처로의 전환은 단순한 구조 변경이 아니라, 자동차 전자 시스템 설계 방식 자체가 바뀌는 흐름을 의미한다. 기능 단위로 ECU와 네트워크를 나누던 방식에서 벗어나, 차량의 물리적 위치를 기준으로 시스템을 구성하는 방향으로 이동하고 있다. 이런 전환은 SDV를 구현하기 위한 필수 조건으로 자리 잡고 있다.
Zone Controller의 핵심적인 변화는 센서와 액추에이터를 물리적 위치 기준으로 통합 관리한다는 점에 있다. 기존 도메인 아키텍처에서는 차량 전면 카메라는 ADAS 도메인에, 헤드라이트는 바디 도메인에, 범퍼 센서는 주차 도메인에 각각 연결돼, 서로 다른 도메인 간에 복잡한 통신이 필요했다. 반면 Zone 아키텍처에서는 Front Zone Controller 하나가 전면 영역의 모든 센서와 액추에이터를 직접 관리한다. 이와 같은 Zone 기반 구조는 중앙 컴퓨팅과 분산 제어를 결합하는 형태로 구성되며, SDV 환경에 적합한 아키텍처로 활용되고 있다.
Zone 환경에서 커지는 통신 복잡성
Zone Controller에 연결되는 End Point의 구성은 현재 차량 통신 환경이 얼마나 복잡해졌는지를 보여준다. 서로 다른 시기와 목적에 따라 개발된 다양한 통신 기술들이 하나의 시스템 안에서 동시에 사용되고 있으며, 이는 통합과 표준화의 필요성을 더욱 크게 만든다.
CAN, CAN-FD, LIN과 같은 전통적인 차량 통신 프로토콜은 여전히 차량 시스템의 중심으로 활용되고 있다. 기존 공급망과의 호환성과 비용 효율성 때문이다. CAN 버스는 1986년 Bosch에서 개발된 이후 약 40년간 차량 통신의 핵심 역할을 해왔고, 현재도 차 한 대당 평균 30~50개의 CAN 노드가 사용되고 있다. 저비용 센서와 단순 제어 기능에서는 CAN이 가장 경제적인 선택이며, LIN 버스 역시 윈도우 모터나 시트 제어와 같은 단순 기능에서 CAN 대비 약 10분의 1 수준의 비용으로 구현할 수 있어 계속 사용되고 있다.
안전과 직결되는 기능에서는 DIO, ADC, DAC, PWM과 같은 직접 I/O 방식이 여전히 필수적이다. 에어백 충격 센서나 ABS 휠 속도 센서처럼 마이크로초 단위의 응답이 필요한 경우에는, 네트워크 프로토콜을 거치면서 발생하는 지연을 허용할 수 없기 때문에 신호를 Zone Controller에 직접 연결해야 한다.
동시에 차량에는 10BASE-T1S, 100BASE-T1, 1000BASE-T1과 같은 차세대 차량용 이더넷도 도입되고 있다. 이러한 기술은 미래 확장성과 표준 기반 통합을 고려한 선택이다. 특히 10BASE-T1S는 기존 CAN 버스를 대체할 수 있는 경제적 고성능 솔루션으로, 멀티드롭 토폴로지를 유지하면서도 약 10배 이상의 성능 향상을 제공한다.
이처럼 목적과 특성에 따라 선택된 다양한 프로토콜이 공존하면서, Zone Controller 내부의 게이트웨이 기능은 매우 복잡해진다. 각 프로토콜은 서로 다른 데이터 포맷, 타이밍 요구사항, 오류 처리 방식을 가지고 있어, Zone Controller의 프로토콜 변환 소프트웨어는 복잡한 상태 머신과 버퍼 관리 로직을 필요로 한다. 특히 실시간 요구사항이 다른 프로토콜 간 데이터를 동기화하는 과정에서는 타이밍 지터와 데이터 일관성 문제가 발생할 수 있다.
개발 환경 역시 복잡하다. 하나의 기능을 구현하기 위해 CAN DBC 파일, LIN LDF 파일, 이더넷 소켓 프로그래밍, GPIO 레지스터 제어를 동시에 다뤄야 하며, 프로토콜별로 서로 다른 진단 도구와 디버깅 환경이 필요하다. 이러한 복잡성은 개발 효율을 떨어뜨리고 시스템 최적화를 어렵게 만든다. 결국 통합된 통신 구조 없이는 SDV 아키텍처의 확장성과 안정성을 확보하기 어렵다.
10BASE-T1S가 제공하는 새로운 네트워크 기반
10BASE-T1S는 IEEE 802.3cg 표준으로 정의된 Single Pair Ethernet 기술로, 기존 이더넷과 달리 멀티드롭 버스 아키텍처를 지원하는 최초의 이더넷 표준이다. 단일 케이블에 최소 8개의 노드를 연결할 수 있으며, 최대 25m까지 통신 거리를 지원한다. 이러한 구조는 CAN 버스와 유사한 배선 방식을 유지하면서도 이더넷 기반의 성능과 확장성을 제공한다.
이 기술의 핵심은 PLCA(Physical Layer Collision Avoidance) 프로토콜이다. 기존 이더넷이 사용하는 CSMA/CD 방식은 네트워크 충돌을 확률적으로 처리하지만, PLCA는 코디네이터 노드가 전송 순서를 제어해 각 노드에 정해진 순서로 전송 기회를 부여한다. 이로 인해 결정론적인 매체 접근이 가능해진다.
이러한 결정론적 특성은 자동차 환경에서 특히 중요하다. 실시간 제어와 예측 가능한 응답 시간이 안전과 직결되기 때문이다. PLCA 환경에서는 각 노드가 최대 2μs의 대기시간 후 전송 기회를 얻을 수 있고, 8개 노드 구성에서도 전체 사이클 시간이 16μs 이하로 유지된다. 이는 기존 CAN 버스의 평균 지연시간인 약 500μs와 비교할 때 20배 이상 빠른 수준이다.
비용 측면에서도 10BASE-T1S는 경쟁력이 있다. DME(Differential Manchester Encoding) 신호 방식을 사용해 PAM(Pulse Amplitude Modulation) 방식보다 구현이 단순하고, 각 노드에 단일 PHY만 필요하기 때문에 스위치 기반 스타 토폴로지보다 하드웨어 비용이 낮다. 또한 TCP/IP 스택으로의 확장을 지원하기 때문에, 상위 계층 애플리케이션을 이더넷 환경에서 직접 구현할 수 있다.
Zenoh 통신 미들웨어의 구조와 역할
차량 전자 시스템에서 통신 미들웨어는 단순한 데이터 전달 계층이 아니라 전체 아키텍처의 유연성과 확장성을 좌우하는 핵심 요소가 된다. 이러한 관점에서 Zenoh는 기존 차량용 미들웨어가 갖고 있던 구조적 한계를 해결하도록 설계된 통합형 통신 미들웨어다.
Zenoh의 가장 큰 특징은 Key-Value 기반의 동적 데이터 모델이다. 기존 DDS가 사전에 정의된 Topic과 데이터 타입을 중심으로 동작하는 것과 달리, Zenoh는 계층적인 Key Expression 구조를 사용한다. 이 구조는 Unix 파일 시스템과 유사한 형태로 차량 데이터의 위치와 의미를 표현한다. 예를 들어 /Vehicle/Engine/Temperature라는 키는 차량 내 엔진 온도 센서 데이터를 의미하며, 개발자가 시스템 구조를 직관적으로 이해하고 관리할 수 있게 한다.
Zenoh는 와일드카드 패턴 매칭을 지원한다. /Vehicle/*/Temperature와 같은 패턴을 사용하면 모든 도메인의 온도 센서를 동시에 구독할 수 있고, /Vehicle/Engine/** 형태로 엔진 관련 모든 하위 신호를 한 번에 수신할 수 있다. 이는 신호 수가 계속 늘어나는 SDV 환경에서 데이터 접근 구조를 단순하게 유지할 수 있게 한다.
Zenoh는 Pub/Sub, Query, Storage 기능을 하나의 프로토콜로 통합한다. 기존 차량 통신 스택에서는 실시간 데이터 스트리밍, 요청 기반 조회, 데이터 저장이 각각 다른 미들웨어나 인터페이스를 필요로 했다. Zenoh에서는 센서 데이터가 실시간으로 publish되는 동시에, 진단 시스템이 query로 현재 값을 요청하고, Storage 기능이 자동으로 데이터를 저장해 히스토리 조회를 지원할 수 있다. 하나의 API와 하나의 프로토콜로 이 모든 기능이 처리된다.
프로토콜 자체도 경량화되어 있다. Zenoh의 최소 헤더 크기는 5바이트로, DDS의 16바이트 이상, SOME/IP의 8바이트 이상과 비교해 매우 작다. RWTH Aachen University의 성능 평가 결과에서도 Zenoh는 FastDDS 대비 4.4배 빠른 발견 시간을 보였고, P2P 모드에서는 67Gbps 처리량을 기록해 Cyclone DDS의 26Gbps보다 2.6배 높은 성능을 나타냈다.
COVESA VSS와 Zenoh의 결합 구조
COVESA VSS는 2016년 도입된 이후 자동차 업계에서 가장 널리 채택된 차량 데이터의 사실상 표준으로 자리 잡았다. BMW Group의 VSS 기반 GraphQL 데이터 접근 구조, Amazon FleetWise의 차량 데이터 전송 서비스, BlackBerry IVY의 센서 데이터 정규화 플랫폼, Bosch의 Vehicle Edge 플랫폼 등 주요 업체들이 이 표준을 기반으로 시스템을 구축하고 있다.
VSS와 Zenoh는 데이터 모델 구조 측면에서 자연스럽게 결합된다. VSS는 차량 데이터를 계층적 트리 구조로 정의하며, 이는 Zenoh의 Key Expression 구조와 직접적으로 대응된다. 예를 들어 VSS에서 정의된 Vehicle.Body.Lights.Hazard.IsOn 신호는 Zenoh에서는 /Vehicle/Body/Lights/Hazard/IsOn 경로로 그대로 매핑된다. 이 과정에서 별도의 변환 계층이나 추가 프로토콜이 필요하지 않다.
VSS 기반 표준 인터페이스를 사용하면 코드 재사용성이 높아지고, 통합 테스트 시간이 줄어들며, 신규 기기나 기능을 시스템에 추가하는 데 필요한 시간도 감소한다. 또한 OEM 중심의 폐쇄적 개발 구조를 벗어나, 애프터마켓 솔루션 개발자와 서드파티 개발자, Tier 공급업체들이 동일한 데이터 인터페이스를 기반으로 참여할 수 있는 개방형 생태계를 형성할 수 있다.
Zone Controller를 중심으로 한 통합 통신 구조
이 아키텍처에서 Zone Controller는 단순한 I/O 집약기가 아니라, 차량 내부의 다양한 통신 방식을 하나의 데이터 구조로 통합하는 지능형 게이트웨이 역할을 한다. 기존 CCU(Central Communication Unit)의 개념을 확장해, 서로 다른 프로토콜 영역을 COVESA VSS 기반의 통합 데이터 모델로 변환하고, Zenoh 미들웨어를 통해 차량 전체와 클라우드까지 연결되는 데이터 흐름을 구성한다.
.jpg)
그림 | Zone Controller 아키텍쳐 구성도
이 구조의 중요한 특징은 레거시 시스템과의 하위 호환성을 유지하면서도 차세대 통신 기술을 동시에 수용할 수 있다는 점이다. CAN, LIN, FlexRay 기반 ECU는 하드웨어 변경 없이 Zone Controller에 연결되고, 그 신호는 내부에서 VSS 기반 데이터로 변환되어 이더넷과 Zenoh 네트워크로 전달된다. 이를 통해 단계적인 아키텍처 전환이 가능해진다.
10BASE-T1S로 연결된 End Point는 TCP/IP 스택을 직접 실행할 수 있기 때문에 Zenoh 미들웨어를 Zone Controller를 거치지 않고도 바로 사용할 수 있다. 이때 PLCA 기반 결정론적 통신 특성이 결합돼 예측가능한 실시간 성능을 유지한다. CAN과 LIN 기반 End Point는 Zone Controller가 능동적으로 프로토콜 변환을 수행한다. DBC 파일과 LDF 파일에 정의된 신호 구조를 VSS 매핑 테이블과 연동해 CAN·LIN 신호가 자동으로 표준화된 VSS 경로로 변환된다.
DIO, ADC, DAC, PWM으로 연결되는 센서 신호 역시 Zone Controller에서 디지털화와 표준화가 이루어진다. 고해상도 ADC로 수집된 아날로그 신호는 캘리브레이션 테이블을 적용해 물리값으로 변환되고, 해당 값은 대응되는 VSS 경로로 매핑된다.
10BASE-T1S 네트워크와 HPC(중앙 고성능 컴퓨터) 사이의 연결은 Layer 2 브리징 방식으로 구성된다. 이 구조에서는 10BASE-T1S End Point가 HPC에 직접 연결된 것처럼 IP 통신을 수행할 수 있다. Zone Controller는 MAC 주소를 학습하고 포워딩 테이블을 관리해, HPC에서 들어오는 트래픽을 목적지 End Point로 전달한다. 동시에 QoS 기반 트래픽 제어를 적용해 실시간 제어 신호, 센서 데이터, 진단 정보를 서로 다른 우선순위로 처리한다.
이 아키텍처에서는 End Point에서 시작된 Zenoh 세션이 Zone Controller와 HPC를 거쳐 클라우드의 Zenoh Router까지 단일 세션으로 유지된다. 네트워크 단절이나 라우터 장애가 발생하더라도 로컬 버퍼링을 통해 데이터 손실을 방지하고, 연결이 복구되면 자동으로 동기화가 이루어진다.
다수의 차량을 동시에 관리하는 환경에서는 VIN 기반의 계층적 네임스페이스 구조를 사용한다. /fleet/{VIN}/Vehicle/... 형태의 구조를 통해 클라우드에서 여러 차량을 체계적으로 관리할 수 있으며, /fleet/*/Vehicle/Engine/** 패턴으로 전체 차량의 엔진 상태를 모니터링하거나, /fleet/{특정 VIN}/** 형태로 특정 차량을 상세 추적할 수 있다.
성능 비교와 실제 구현 사례
Zenoh, FastDDS, vSomeIP에 대한 비교 결과는 이 통합 통신 구조가 실제 환경에서도 의미 있는 성능 차이를 만들어낸다는 점을 보여준다. RWTH Aachen University 연구진이 수행한 차량용 미들웨어 성능 비교 실험에 따르면, 발견 시간(Time-To-First-Message) 측면에서 Zenoh가 가장 빠른 성능을 보였고, FastDDS가 그 뒤를 따랐으며, vSomeIP는 상대적으로 느린 반응을 나타냈다.1) 통신 지연시간에서는 Zenoh와 FastDDS(best-effort)가 대부분의 조건에서 유사한 수준을 유지했지만, vSomeIP는 더 높은 지연시간을 보였다. 확장성 측면에서는 Zenoh와 vSomeIP가 비교적 안정적인 동작을 보인 반면, FastDDS는 일부 네트워크 토폴로지에서 전송 실패가 발생했다. 이러한 결과는 Zenoh가 SDV 환경과 같은 대규모 분산 통신 구조에서 보다 안정적인 특성을 갖는다는 점을 보여준다.
이러한 구조는 실제 시스템 구현 사례에서도 확인된다. Eclipse Foundation SDV 프로젝트의 Blueprint에서는 COVESA VSS와 Zenoh를 결합한 Fleet Management System이 구현되었다. 이 시스템에서는 KUKSA 브로커가 CAN, SOME/IP 등 다양한 차량 버스 기술로부터 신호를 수집해 VSS 형식으로 변환하고, 이를 Zenoh를 통해 백엔드 서비스와 필요한 애플리케이션으로 분산한다. 이 방식은 차량 내부의 이질적인 통신 환경과 클라우드 기반 서비스 환경을 하나의 데이터 흐름으로 연결하는 구조를 실제 시스템에서 검증한 사례다.2)
.jpg)
데이터 통신 미들웨어 성능 비교 (RWTH Aachen Univ.)
SDV를 위한 통합 통신 아키텍처의 의미
이 통합 통신 구조는 10BASE-T1S의 멀티드롭 이더넷, Zenoh 미들웨어, COVESA VSS 데이터 모델이 결합되면서 기존 차량 아키텍처로는 구현하기 어려웠던 성능과 효율을 동시에 제공한다. PLCA 기반의 결정론적 통신과 경제적인 하드웨어 구성, Zenoh의 5바이트 최소 헤더와 67Gbps 처리량, VSS 기반의 표준화된 데이터 모델이 함께 작동하면서, 차량 내부와 클라우드까지 이어지는 데이터 흐름이 단순화되고 성능이 향상된다.
이 구조의 핵심적인 가치는 표준 기반 상호운용성에 있다. 제조사나 통신 프로토콜에 관계없이 동일한 데이터 인터페이스를 사용할 수 있기 때문에, 애프터마켓 솔루션, 서드파티 개발자, Tier 공급업체가 동일한 플랫폼 위에서 기능을 개발하고 통합할 수 있다. BMW, Amazon FleetWise, BlackBerry IVY, Bosch 등 주요 업체들이 VSS 기반 시스템을 도입하고, Eclipse Foundation의 Zenoh 프로젝트가 활성화되고 있다는 점은 이러한 방향이 산업 전반으로 확산되고 있음을 보여준다.
향후 이 구조는 5G와 6G 통신과 결합해 V2X 환경으로 확장될 수 있고, AI·ML 기반의 지능형 라우팅과 트래픽 최적화 기술과도 연동될 수 있다. 이를 통해 차량 내부 통신과 클라우드 기반 데이터 처리 환경이 더욱 긴밀하게 연결될 수 있다.
결과적으로 이 통합 통신 아키텍처는 SDV 환경에서 요구되는 실시간성, 확장성, 표준화, 그리고 클라우드 연계를 동시에 만족시키는 실질적인 기술 기반을 제공한다. 이는 차세대 소프트웨어 정의 차량을 구현하는 과정에서 핵심적인 인프라로 기능하게 될 것이다.
AEM(오토모티브일렉트로닉스매거진)
<저작권자 © AEM. 무단전재 및 재배포 금지>
