데이터 분산 서비스(DDS)는 단순히 메시지를 전달하는 프로토콜이 아니라, 데이터 중심(data-centric) 분산 시스템을 구축하기 위한 OMG(Object Management Group) 표준 미들웨어입니다.1 DDS의 핵심 추상화 개념은 ‘글로벌 데이터 공간(Global Data Space, GDS)’으로, 이는 애플리케이션이 상호작용하는 가상적이고 분산된 데이터 저장소입니다.2 이 접근 방식은 DDS가 통신 세부 사항을 애플리케이션으로부터 추상화하여 개발자가 데이터의 상태와 로직에 집중할 수 있도록 한다는 점에서 메시지 중심 미들웨어와 근본적인 차이를 보입니다.2
DDS의 통신 모델은 발행-구독(publish-subscribe) 패턴을 기반으로 합니다.3 발행자(Publisher)와 구독자(Subscriber)는 특정 데이터 스트림을 위한 강력한 타입의 채널인 토픽(Topic)을 통해 익명으로 통신하며, 이로 인해 서로 분리(decoupled)됩니다.3 이러한 분리 구조는 모듈화되고 확장 가능한 아키텍처를 구현하는 핵심적인 이점입니다.1
주요 아키텍처 구성 요소는 다음과 같습니다:
DDS의 가장 두드러진 특징은 서비스 품질(Quality of Service, QoS) 정책으로, 이는 DDS를 “강화된(on steroids)” 발행-구독 기술로 만들어 줍니다.4 실시간 및 미션 크리티컬 시스템에 필수적인 주요 QoS 정책들은 통신 행위를 세밀하게 제어합니다.
이러한 QoS 정책들은 신뢰성, 성능, 리소스 사용에 대한 정밀한 제어를 제공하며, 복잡한 시스템에서 DDS가 선택되는 핵심적인 이유가 됩니다.1 또한, DDS는 중앙 브로커나 별도의 구성 파일 없이 런타임에 새로운 참여자, 토픽, QoS 요구사항을 자동으로 발견하는 동적 발견(Dynamic Discovery) 기능을 제공하여 진정한 ‘플러그 앤 플레이’를 가능하게 합니다.2
DDS의 높은 수준의 추상화와 대조적으로, CAN은 차량과 같이 전기적으로 열악한 환경에서 마이크로컨트롤러(ECU) 간의 견고하고 저비용의 실시간 통신을 위해 설계된 저수준 메시지 기반 프로토콜(ISO 11898)입니다.9 CAN의 주된 개발 목적은 차량 내 배선의 복잡성과 무게를 줄이는 것이었습니다.12
CAN의 통신 모델은 다음과 같은 특징을 가집니다:
CAN 데이터 프레임은 우선순위를 결정하는 식별자, 데이터 길이 코드(DLC), 그리고 0-8 바이트의 데이터 페이로드로 구성됩니다.10 또한 데이터 요청을 위한 원격 프레임(RTR), 오류 프레임, 오버로드 프레임도 존재합니다.9 CAN은 CRC, 프레임 검사, 비트 모니터링 등 다층적인 오류 감지 메커니즘과, 결함이 있는 노드가 스스로 버스에서 연결을 끊는(Bus-Off 상태) 오류 제한 기능을 포함하고 있어 안전이 중요한 애플리케이션에 매우 높은 신뢰성을 제공합니다.11 최근에는 페이로드 크기를 64바이트로 늘리고 데이터 전송률을 크게 향상시킨 CAN FD(Flexible Data-Rate)가 등장하여 최신 애플리케이션에서도 CAN 프로토콜의 수명을 연장시키고 있습니다.9
DDS와 CAN을 연결하는 근본적인 과제는 단순히 비트와 바이트를 기술적으로 변환하는 것을 넘어, 서로 다른 두 통신 철학 사이의 개념적 변환을 수행해야 한다는 점에 있습니다. DDS는 미들웨어 계층에서 동작하며, 네트워크를 추상화하고 풍부한 타입과 QoS로 관리되는 ‘글로벌 데이터 공간’에 초점을 맞춥니다. 반면, CAN은 데이터 링크 및 물리 계층에서 동작하며, 타입이 없고 우선순위에 따라 구동되는 원시적인 메시지 전송을 제공합니다. 따라서 게이트웨이는 저수준의 익명 CAN 프레임 스트림을 받아 DDS가 요구하는 풍부한 컨텍스트, 즉 토픽 이름, 정의된 데이터 타입(IDL), 적절한 QoS 설정을 부여하는 ‘의미론적 다리(semantic bridge)’ 역할을 해야 합니다. 반대로, DDS 데이터 객체 업데이트에서 높은 수준의 컨텍스트를 제거하고, 이를 올바른 우선순위를 가진 단일 CAN 프레임으로 정제하여 적시에 방송해야 합니다. 이러한 개념적 임피던스 불일치(impedance mismatch)가 게이트웨이 설계의 모든 주요 과제의 근원입니다.
표 1: DDS와 CAN 버스 특성 비교 개요
| 특성 | DDS (Data Distribution Service) | CAN (Controller Area Network) |
|---|---|---|
| OSI 계층 | 미들웨어 (애플리케이션/표현 계층) | 데이터 링크/물리 계층 |
| 통신 패턴 | 발행-구독 (Publish-Subscribe) | 방송 (Broadcast), 다중 마스터 |
| 데이터 모델 | 데이터 중심 (Data-Centric), 강력한 타입 | 신호 중심 (Signal-Centric), 타입 없음 |
| 주요 추상화 | 글로벌 데이터 공간 (Global Data Space), 토픽 | 메시지 프레임, 식별자(ID) |
| 주소 지정 | 토픽 이름 및 키(Key) | 메시지 식별자 (ID) |
| 페이로드 크기 | 가변적 (수 MB까지 가능) | 0-8 바이트 (CAN), 0-64 바이트 (CAN FD) |
| 속도 | 고속 (Gbps 이상 가능, 네트워크에 의존) | 최대 1 Mbps (CAN), 8 Mbps 이상 (CAN FD) |
| QoS/우선순위 | 20개 이상의 풍부한 QoS 정책 | 메시지 ID 기반의 고정 우선순위 중재 |
| 발견 | 동적, 자동 발견 (플러그 앤 플레이) | 정적, 노드 구성에 의존 |
| 주요 사용 사례 | 자율주행, 로보틱스, 항공, 산업 IoT | 차량 내 네트워크, 산업 자동화, 의료기기 |
| 관리 표준 | OMG (Object Management Group) | ISO (International Organization for Standardization) |
차량의 전기/전자(E/E) 아키텍처는 중대한 패러다임 전환을 겪고 있습니다. 과거의 차량은 수십에서 수백 개의 전문화된 ECU가 다수의 CAN 및 LIN 버스로 연결된 분산 모델을 사용했습니다.12 반면, 현대적인 아키텍처는 ADAS, 인포테인먼트, 차량 제어와 같은 기능들을 강력한 구역 게이트웨이(Zonal Gateway)와 고성능 컴퓨터(HPC)로 통합하고 있습니다.16
이러한 새로운 아키텍처는 ‘연결성 격차(connectivity gap)’를 야기합니다. HPC는 복잡한 소프트웨어를 실행하기 위해 고대역폭, 확장성, 유연성을 갖춘 통신 백본을 필요로 합니다. DDS는 뛰어난 성능, 풍부한 QoS, 데이터 중심 모델 덕분에 이러한 ‘데이터 버스’에 이상적인 후보입니다.16 그러나 창문 모터, 휠 속도 센서, 기본적인 파워트레인 제어 등 필수적인 액추에이터와 센서들은 비용 효율성 때문에 예측 가능한 미래에도 계속해서 기존의 CAN 버스에 남아있을 것입니다.5
DDS-CAN 게이트웨이는 바로 이 격차를 해소하는 핵심적인 구성 요소입니다. 게이트웨이는 새로운 HPC 기반의 DDS 세계가 기존의 CAN 세계와 원활하게 통합하고 제어할 수 있도록 합니다. 이는 비용이 많이 들고 위험 부담이 큰 ‘전면 교체(rip-and-replace)’ 방식 대신, 소프트웨어 정의 차량으로 점진적이고 진화적인 전환 경로를 제공하는 전략적 조력자 역할을 합니다.5
DDS-CAN 게이트웨이의 필요성은 자동차 산업에만 국한되지 않습니다.
DDS-CAN 게이트웨이는 단순한 기술적 유틸리티를 넘어, 기술 부채를 관리하고 점진적 혁신을 가능하게 하는 핵심적인 비즈니스 및 아키텍처 전략입니다. 기업들은 신뢰성이 입증되고 비용 효율적인 기존 CAN 기반 하드웨어 및 소프트웨어에 막대한 투자를 해왔습니다.5 자율주행, 커넥티비티, 향상된 UI와 같은 새로운 기능에 대한 시장의 요구는 DDS와 같은 더 강력한 컴퓨팅 패러다임과 통신 미들웨어를 필요로 합니다.17 모든 기존 구성 요소를 전면적으로 교체하는 것은 엄청난 비용과 높은 위험을 수반합니다. 게이트웨이는 ‘최소 저항 경로’를 제공합니다. 즉, 기존 시스템에 대한 투자를 보존하면서 새로운 기술의 역량을 활용할 수 있게 해줍니다. 이를 통해 기업은 기존의 방대한 CAN 구성 요소 생태계를 활용하면서 차세대 DDS 기반 시스템을 구축할 수 있습니다. 이는 개발 위험을 줄이고 새로운 기능의 시장 출시 시간을 단축시켜, 복잡한 시스템의 진화를 관리하는 강력한 도구가 됩니다.
게이트웨이는 CAN 버스와 DDS 글로벌 데이터 공간 사이의 다리 역할을 하며, 그 내부 구조는 세 가지 논리적 계층으로 나눌 수 있습니다.
이것은 게이트웨이 설계에서 가장 중요한 작업입니다. 본질적으로 타입이 없는 CAN 메시지를 구조화되고 타입이 있는 표현으로 정의해야 합니다. 표준적인 접근 방식은 OMG의 인터페이스 정의 언어(IDL)를 사용하여 struct를 정의하는 것입니다.22
구체적인 IDL 구조를 제안하고 각 필드에 대한 근거를 설명하면 다음과 같습니다.
Code snippet
// 일반적인 CAN 프레임을 위한 예시 IDL
module Automotive {
struct CANFrame {
unsigned long long timestamp; // epoch 이후 나노초 단위 타임스탬프
@key unsigned long can_id; // 11비트 또는 29비트 CAN 식별자
boolean is_extended_id; // 표준 ID와 확장 ID 구분
octet dlc; // 데이터 길이 코드 (클래식: 0-8, FD: 최대 64)
sequence<octet, 64> payload; // 페이로드, CAN FD에 맞춰 크기 지정
};
};
이러한 데이터 모델링에는 다음과 같은 전략과 장단점이 존재합니다.
단순한 접근 방식 (1 CAN ID -> 1 토픽): 이해하기는 쉽지만 규모가 커지면 실패합니다. 토픽 수가 폭발적으로 증가하여 DDS 발견 메커니즘에 과부하를 주고 시스템을 관리 불가능하게 만듭니다.24
정교한 접근 방식 (논리적 그룹화): 권장되는 전략으로, 관련된 CAN 메시지들을 의미론적으로 연관된 단일 DDS 토픽으로 그룹화합니다. 예를 들어, ‘WheelEncoders’라는 토픽을 만들 수 있습니다.
구분을 위한 DDS 키 사용: 단일 토픽 내에서 IDL 구조체의 can_id 필드를 @key로 지정합니다.2 이를 통해 DDS는 각
can_id를 ‘WheelEncoders’ 토픽 내의 고유한 인스턴스로 취급할 수 있습니다. 구독자는 전체 토픽을 구독하거나 특정 인스턴스(특정 바퀴)만 구독할 수 있습니다. 이 접근 방식은 확장 가능하고 효율적이며, 깔끔한 데이터 중심 모델을 생성합니다.
CANFrame IDL 구조체를 채우고, DAL의 데이터 작성자는 이를 적절한 DDS 토픽에 발행합니다. 여기서 타임스탬프는 매우 중요하며, 게이트웨이는 타이밍 정보를 보존하기 위해 하드웨어에서 읽는 시점에 최대한 가깝게 고해상도 타임스탬프를 적용해야 합니다.CANFrame 데이터 샘플을 발행합니다. 게이트웨이의 데이터 판독기가 이를 수신합니다. PTDME는 can_id, dlc, payload를 추출하여 원시 CAN 프레임을 구성하고, 이를 CIL로 보내 전송합니다. 게이트웨이는 can_id에 인코딩된 우선순위를 존중해야 합니다.이는 암시적 동작을 명시적 정책으로 매핑하는 미묘한 과제입니다.
TRANSPORT_PRIORITY QoS 정책에 매핑될 수 있습니다. 이를 통해 DDS 인프라는 우선순위가 높은 CAN 메시지에서 비롯된 데이터에 우선적인 처리를 제공할 수 있습니다.RELIABILITY QoS(최선 노력 또는 신뢰성)를 제공합니다. 일반적인 전략은 안전에 중요한 CAN 데이터를 RELIABLE DDS 토픽에 매핑하여 IP 기반 네트워크에서의 전달을 보장하고, 중요하지 않은 데이터는 BEST_EFFORT를 사용하여 오버헤드를 줄이는 것입니다.표 2: CAN 프레임과 DDS IDL 구조체의 규범적 매핑
| IDL 필드 | C++ 타입 (생성된 코드) | 설명 및 근거 | CAN 프레임 소스 |
|---|---|---|---|
timestamp |
uint64_t |
타이밍 정보 보존을 위한 고해상도 타임스탬프. CAN 프레임 수신 시점에 게이트웨이가 생성. | 게이트웨이 |
can_id (@key) |
uint32_t |
11/29비트 CAN 식별자. 토픽 내 인스턴스를 구분하기 위해 @key로 지정. 확장 가능성 확보. |
CAN 프레임 헤더 |
is_extended_id |
bool |
표준(11비트) ID와 확장(29비트) ID를 구분. | CAN 프레임 헤더 |
is_fd_frame |
bool |
클래식 CAN과 CAN FD 프레임을 구분. 페이로드 크기 해석에 필요. | 게이트웨이/드라이버 |
dlc |
uint8_t |
데이터 길이 코드(0-8 또는 0-64). 페이로드의 유효 길이를 나타냄. | CAN 프레임 헤더 |
payload |
std::vector<uint8_t> |
최대 64바이트의 데이터 페이로드. sequence<octet, 64>는 가변 길이 데이터를 효율적으로 처리. |
CAN 프레임 데이터 필드 |
Connext Drive는 RTI가 자동차 시장을 겨냥하여 Connext DDS를 기반으로 개발한 주력 제품입니다.17 이 제품의 핵심 가치는 자율주행 및 소프트웨어 정의 차량을 위해 특별히 설계된 완전한 안전 인증 프레임워크라는 점입니다.16 특히 TÜV-SÜD로부터 ISO 26262 ASIL D 인증을 획득한 것은 큰 차별점이며, 이는 시스템 통합업체가 기능 안전 인증에 드는 노력을 크게 줄여줍니다.16
Connext Drive는 AUTOSAR Classic 및 AUTOSAR Adaptive 모두에 대한 전용 통합 툴킷을 제공합니다.16 이는 표준 자동차 소프트웨어 아키텍처와의 통합에 매우 중요합니다. 이 툴킷은 AUTOSAR의 ARXML 형식과 DDS의 IDL 형식 간에 데이터 타입을 자동으로 변환하고 코드를 생성하여, 두 생태계 간의 격차를 해소합니다.16 이는 AUTOSAR Classic으로 관리되는 기존 CAN 기반 ECU를 최신 DDS 데이터 버스에 직접 연결하는 것을 용이하게 합니다.
RTI 라우팅 서비스는 DDS 도메인 간, 그리고 더 중요하게는 DDS와 비-DDS 시스템 간에 데이터를 라우팅하고 변환하기 위한 강력한 독립형 애플리케이션입니다.27 이 서비스는 매우 유연한 플러그인 아키텍처를 기반으로 동작합니다.29
비-DDS 통합의 핵심은 어댑터 SDK(Adapter SDK)입니다.27 이를 통해 개발자는 라우팅 서비스가 CAN과 같은 새로운 프로토콜과 통신하는 방법을 가르치는 맞춤형 ‘어댑터’를 작성할 수 있습니다. 개발자는 CAN 프레임을 읽고 쓰는 로직을 구현하기만 하면, 라우팅 서비스 엔진이 모든 복잡한 DDS 상호작용, 데이터 라우팅, 변환을 처리합니다.28
또한 라우팅 서비스는 데이터를 즉석에서 변환하는 강력한 내장 기능을 갖추고 있습니다. 토픽 이름을 변경하고, 콘텐츠 기반으로 메시지를 필터링하며, 심지어 서로 다른 IDL 구조체 간에 데이터를 재매핑할 수도 있습니다.27 이는 기존 애플리케이션을 변경하지 않고도 약간 다른 데이터 모델을 가진 시스템을 통합할 때 매우 유용합니다.
rticonnextdds-gateway 프로젝트는 라우팅 서비스 SDK 위에 구축되어 프로토콜 통합 플러그인 개발을 위한 더 정제된 프레임워크와 예제를 제공함으로써 개발 과정을 단순화합니다.29
RTI의 전략은 다양한 수준의 통합 요구에 부응하는 다층적 솔루션을 제공하는 것입니다. 자동차 OEM은 턴키 솔루션으로 완벽하게 통합되고 안전 인증을 받은 Connext Drive 제품을 선택할 수 있고, 시스템 개발자는 더 일반적이지만 강력한 라우팅 서비스를 사용하여 고도로 맞춤화된 비자동차용 게이트웨이를 구축할 수 있습니다. 대규모 자동차 OEM의 주요 관심사는 안전 인증(ISO 26262), 표준 준수(AUTOSAR), 개발 위험 감소입니다.16 Connext Drive는 이러한 요구를 직접적으로 해결합니다. 반면, 로보틱스 회사나 산업 통합업체는 AUTOSAR 준수가 필요 없을 수 있지만, 독점적인 CAN 프로토콜을 DDS 백본에 견고하게 연결할 방법이 필요합니다.19 이들에게는 라우팅 서비스와 어댑터 SDK가 완벽한 도구입니다.27 이러한 계층화된 제품 제공은 시장에 대한 깊은 이해를 보여주며, ‘하나의 크기가 모든 것에 맞는다’는 접근 방식이 아님을 증명합니다.
Fast DDS는 ROS 2의 기본 미들웨어로 채택되어 널리 사용되는 오픈소스 C++ DDS 구현체입니다.31 고성능과 풍부한 기능을 자랑합니다. eProsima DDS 라우터는 주로 서로 다른 DDS 네트워크를 연결하기 위해 설계되었습니다. 예를 들어, 로컬 LAN을 WAN에 연결하거나 서로 다른 DDS 도메인을 브리징하는 데 사용됩니다.26 따라서 이 도구는 즉시 사용 가능한 CAN 게이트웨이는 아닙니다.
eProsima 도구를 사용하여 CAN 게이트웨이를 구축하려면, DDS 라우터를 브리지 자체로 사용하는 대신 맞춤형 C++ 애플리케이션을 설계해야 합니다. 이 애플리케이션은 DDS 측을 위해 Fast DDS 라이브러리 31와 CAN 측을 위해 CAN 라이브러리(예: socketcan)를 링크하여 게이트웨이 역할을 수행합니다. 필요한 경우, 이 맞춤형 애플리케이션은 더 넓은 네트워크에 연결하기 위해 DDS 라우터 인스턴스와 통신할 수 있습니다.26 eProsima의 고급 도구인 통합 서비스(Integration Service)는 서로 다른 프로토콜 간의 매개변수화된 통신 브리지를 생성하기 위한 라이브러리로, 처음부터 구축하는 것보다 더 적절한 출발점이 될 수 있습니다.37
OpenDDS는 Object Computing에서 개발한 또 다른 주요 오픈소스 C++ DDS 구현체입니다.38 이 역시 모든 기능을 갖추고 있으며 표준을 준수합니다. 구현 전략은 Fast DDS와 유사합니다. 개발자는 OpenDDS 라이브러리 39와 CAN 라이브러리를 링크하는 독립형 C++ 애플리케이션을 만들어야 합니다. 이 방식은 최대의 제어와 유연성을 제공하지만, 스레딩, 데이터 매핑, 오류 처리 등 전체 게이트웨이 로직을 처음부터 작성해야 하므로 가장 많은 개발 노력이 필요합니다.
OPC UA 41, MQTT 42, iceoryx 43와 같은 다른 게이트웨이 프로젝트를 살펴보면 공통적인 아키텍처 패턴을 발견할 수 있습니다. 이들은 종종 YAML이나 TOML 파일과 같은 구성을 통해 매핑 규칙을 정의하고, 플러그인 기반 아키텍처를 채택하며, 핵심 라우팅 로직과 프로토콜별 커넥터를 명확히 분리합니다. 이러한 패턴들은 맞춤형 DDS-CAN 게이트웨이 설계에 직접적으로 적용될 수 있습니다.
표 3: 상용 및 오픈소스 게이트웨이 솔루션 비교
| 기준 | RTI Connext Drive / 라우팅 서비스 | eProsima 기반 맞춤형 게이트웨이 | OpenDDS 기반 맞춤형 게이트웨이 |
|---|---|---|---|
| 안전 인증 (ISO 26262) | 제공 (ASIL D) | 개발자 책임 | 개발자 책임 |
| AUTOSAR 통합 | 제공 (툴킷 포함) | 없음 (수동 개발 필요) | 없음 (수동 개발 필요) |
| 라이선스 모델 | 상용 | Apache 2.0 | Apache 2.0 유사 |
| 즉시 사용 가능 기능 | 높음 (완제품/프레임워크) | 낮음 (라이브러리 수준) | 낮음 (라이브러리 수준) |
| 개발 노력 | 낮음 | 높음 | 높음 |
| 성능 | 고성능, 최적화됨 | 구현에 따라 다름 | 구현에 따라 다름 |
| 커뮤니티 및 상용 지원 | 강력한 상용 지원 | 활발한 커뮤니티, 상용 지원 옵션 | 활발한 커뮤니티, 상용 지원 옵션 |
오픈소스 경로는 자유와 라이선스 비용 절감을 제공하지만, 시스템 통합, 검증, 그리고 가장 중요하게는 안전 인증의 부담을 전적으로 개발자에게 전가합니다. Fast DDS나 OpenDDS를 사용하면 개발자는 강력하고 표준을 준수하는 DDS 라이브러리를 무료로 얻을 수 있습니다.32 그러나 이것들은 완전한 게이트웨이 솔루션이 아닌 라이브러리일 뿐입니다. 개발자는 복잡한 데이터 매핑, QoS 변환, 오류 처리 로직을 포함한 전체 게이트웨이 애플리케이션을 직접 설계, 구현, 테스트해야 합니다. 차량과 같은 안전이 중요한 시스템의 경우, 이렇게 맞춤 제작된 게이트웨이는 매우 시간과 비용이 많이 드는 ISO 26262 인증 과정을 거쳐야 합니다. 반면 RTI Connext Drive와 같은 상용 솔루션은 이미 이 작업을 완료하고 인증 산출물을 제공합니다.16 따라서 오픈소스의 ‘무료’는 라이선스에 한정됩니다. 인증된 양산 등급 시스템을 오픈소스 구성 요소로 구축하는 총 소유 비용(TCO)은 상용의 사전 인증된 솔루션의 라이선스 비용보다 잠재적으로 훨씬 더 높을 수 있습니다. 이는 단순한 기능 비교를 넘어서는 중요한 재무적, 전략적 판단을 요구합니다.
LIVELINESS QoS 상태를 NOT_ALIVE로 변경하거나 전용 GatewayStatus 토픽을 발행하여 수행할 수 있습니다.이 섹션은 DDS-CAN 브리지를 차세대 차량 네트워킹의 더 넓은 맥락에서 조명합니다. 주요 대안은 브리징이 아니라 CAN ECU를 오토모티브 이더넷으로 마이그레이션하고 SOME/IP와 같은 프로토콜을 사용하는 것입니다.44
이 둘 사이의 선택은 어느 것이 ‘더 낫다’의 문제가 아니라, 어떤 아키텍처 목표가 최우선인지에 따라 결정됩니다. 순수한 AUTOSAR 호환 차량 내 서비스 네트워크가 목표라면 SOME/IP가 자연스러운 선택입니다. 반면, 기존 시스템을 통합하고 잠재적으로 차량 외부의 비자동차 시스템(V2X, 클라우드)과 연결해야 하는 매우 유연한 데이터 중심 아키텍처가 목표라면 DDS와 게이트웨이 접근 방식이 더 우수합니다. DDS-CAN 게이트웨이는 기존 CAN 자산을 활용하여 새로운 기능을 신속하게 추가해야 하는 복잡한 프로젝트에 최적의 솔루션이며, 이는 프로젝트의 시간 및 복잡성 제약 조건 하에서 전략적 우위를 점합니다.
미래의 차량은 단일 통신 프로토콜을 사용하지 않을 것입니다. CAN/CAN FD, LIN, FlexRay, 오토모티브 이더넷, 무선 기술이 공존하는 이기종 네트워크의 네트워크가 될 것입니다.45 이러한 미래에는 지능형 다중 프로토콜 게이트웨이의 역할이 더욱 중요해집니다. 게이트웨이는 서로 다른 프로토콜 도메인 간에 데이터를 변환하고 라우팅하여 전체 차량이 단일의 응집력 있는 시스템으로 기능하도록 보장하는 중앙 신경계 역할을 할 것입니다.
솔루션을 선택하기 전에 아키텍트는 다음과 같은 핵심 질문에 답해야 합니다.
이 프레임워크는 표 3의 논리를 따라 정보에 입각한 선택을 하는 데 도움이 될 것입니다.
보고서에서 제시된 핵심 권장 사항을 실행 가능한 목록으로 요약하면 다음과 같습니다.
DDS-CAN 브리지는 단순한 연결 장치 그 이상입니다. 이는 차세대 소프트웨어 정의 차량 및 기타 복잡한 분산 시스템의 실용적이고 진화적인 개발을 가능하게 하는 정교하고 전략적인 구성 요소입니다. 검증된 기존 기술과 현대적인 데이터 중심 미들웨어의 강력한 기능을 융합시켜, 미래 혁신을 향한 실용적인 경로를 제공합니다.
| Bridging XMPP and DDS Messaging Frameworks | Object Computing, Inc., accessed July 5, 2025, https://objectcomputing.com/resources/publications/sett/april-2012-bridging-xmpp-and-dds-messaging-frameworks |
| What Is Can Bus (Controller Area Network) | Dewesoft, accessed July 5, 2025, https://dewesoft.com/blog/what-is-can-bus |
| A Guide to Controller Area Network (CAN) for Industrial Applications | Electromate Inc, accessed July 5, 2025, https://www.electromate.com/news/post/a-guide-to-controller-area-network-can-for-industrial-applications |
| RTI Connext Drive - Autonomous Vehicle Development | RTI, accessed July 5, 2025, https://www.rti.com/products/connext-drive |
| Bridge Remote DDS Networks With a DDS Router | Husarnet, accessed July 5, 2025, https://husarnet.com/blog/ros2-dds-router/ |
| Getting Started with the OpenDDS Project | Object Computing, Inc., accessed July 5, 2025, https://objectcomputing.com/how-we-serve/accelerators/opendds/resources/getting-started-with-opendds |