차량 내 ECU가 데이터를 주고받는 방식은 크게 시그널 지향(signal-oriented)과 서비스 지향(service-oriented)으로 나뉜다. 전자는 무엇을 언제 보낼지가 개발 단계에서 고정되는 반면, 후자는 런타임에 필요한 기능을 서비스로 찾아 연결한다.
| 구분 | 시그널 지향 | 서비스 지향 |
|---|---|---|
| 정의 시점 | 개발 단계에서 정적으로 확정 | 런타임에 동적으로 연결 |
| 데이터 단위 | 프레임 안 고정 위치의 시그널 | 발견 가능한 서비스(메서드·이벤트·필드) |
| 전송 방식 | 정해진 주기·이벤트마다 방송 | 요청한 소비자에게만 유니캐스트 |
| 새 기능 대응 | 매트릭스 자체를 다시 설계해야 함 | 서비스 등록·발견만으로 확장 |
| 대표 기술 | CAN DB, Fibex | SOME/IP |
시그널 지향 통신은 CAN DB·Fibex 같은 통신 매트릭스로 CAN 등 버스에서 오가는 메시지 ID별 시그널의 구조·타이밍·스케일을 정의한다. 이 매트릭스는 네트워크 설계 단계부터 ECU 소프트웨어 개발까지 전 과정에서 모든 ECU가 데이터를 일관되게 해석하도록 하는 단일 기준점 역할을 하며, 한 번 확정되면 통상 이후 개발 단계에서는 바꾸지 않는다[1]. 송신 노드는 수신 측이 그 값을 실제로 필요로 하는지와 무관하게 정해진 주기나 이벤트마다 시그널을 방송하고, 새 기능을 추가하려면 매트릭스 자체를 다시 설계해야 한다 — 이렇게 정적으로 사전 구성된 방식은 서비스 지향 통신에 비해 변화 대응이 느리다[2].
서비스 지향 통신은 기능을 서비스 단위로 나누고, 정해진 인터페이스와 정책을 통해 그 서비스에 접근하게 한다[3]. 자동차에서는 AUTOSAR·GENIVI·OSEK 등 서로 다른 운영체제 위에서 동작하는 ECU 사이의 원격 함수 호출(RPC)과 이벤트 통지를 지원하도록 표준화된 SOME/IP(Scalable service-Oriented MiddlewarE over IP)가 TCP/UDP 기반의 Ethernet 네트워크에서 대표적으로 쓰인다[4]. SOME/IP는 서비스 제공자가 offer 메시지로 서비스 가용성을 알리고 소비자가 find 메시지로 필요한 서비스를 찾는 서비스 디스커버리(SD)를 통해, 정적 매트릭스 없이도 런타임에 서비스를 동적으로 찾아 연결한다[2].
이 정적·동적 대비는 차량 집중형 아키텍처가 도메인과 무관하게 배치된 제어기의 기능을 유연하게 조합하려는 이유이자, Software Defined Vehicle이 새 기능을 개별 활성화·구독형으로 제공할 수 있는 바탕이다.