승코딩당당당
[차량 통신] SDV 전환과 차량 통신 구조 정리 (CAN vs Ethernet) 본문
최근 자동차 산업은 단순한 기계 중심 구조에서 벗어나, 소프트웨어를 중심으로 기능이 정의되는 SDV(Software Defined Vehicle)로 빠르게 전환되고 있다. 기존 차량은 초기 설계 단계에서 모든 기능이 결정되고 이후 변경이 어려운 구조였지만, SDV는 OTA(Over-The-Air) 업데이트를 통해 지속적으로 기능을 개선하고 확장할 수 있다는 점에서 큰 차이를 가진다. 이러한 변화는 사용자에게 개인 맞춤형 경험을 제공하는 동시에, 자동차를 하나의 플랫폼으로 진화시키고 있다.
이러한 SDV를 구현하기 위해서는 단순히 소프트웨어만 중요한 것이 아니라, 이를 실제 하드웨어와 연결하는 구조에 대한 이해가 필수적이다. MCU 내부의 CPU, 메모리, 그리고 Peripheral(주변장치)와 레지스터를 통한 제어 방식은 소프트웨어가 어떻게 실제 물리적 동작으로 이어지는지를 보여주는 핵심 요소이다.
또한 차량 내부 통신 구조 역시 큰 변화를 겪고 있다. 기존에는 CAN 통신을 기반으로 ECU 간 데이터를 주고받았지만, CAN은 속도와 데이터 처리 측면에서 한계가 존재한다. 이에 따라 SDV 환경에서는 Ethernet 기반의 고속 통신과 SOME/IP와 같은 서비스 지향 통신 방식이 도입되고 있으며, 이는 차량을 보다 유연하고 확장 가능한 시스템으로 만든다.
본 글에서는 SDV의 개념을 시작으로, MCU 기반의 제어 구조와 레지스터 동작 원리, 그리고 CAN과 Ethernet 통신의 차이와 역할을 정리하며, 자동차가 어떻게 소프트웨어 중심 구조로 변화하고 있는지 전체적인 흐름을 살펴보고자 한다.
1. SDV (Software Defined Vehicle)
핵심 개념
SDV는 자동차를 하드웨어 중심에서 소프트웨어 중심으로 전환하는 개념이다.
차량의 기능, 성능, 사용자 경험이 소프트웨어에 의해 정의되고 변경될 수 있다.
특징
- 기능이 하드웨어가 아니라 소프트웨어로 정의됨
- 업데이트를 통해 기능 변경 및 개선 가능
- 개인 맞춤형 서비스 제공 가능
- 구독형 기능 추가 가능
기존 차량과의 차이
구분 기존 차량 SDV
| 구조 | 하드웨어 중심 | 소프트웨어 중심 |
| 개발 방식 | V-모델 (고정) | 지속적 업데이트 |
| 기능 추가 | 어려움 | OTA로 가능 |
왜 필요한가
기존 차량은 초기 요구사항에 맞춰 설계되고 이후 변경이 어렵다.
반면 사용자는 스마트폰처럼 기능이 계속 업데이트되고 개인화되기를 원한다.
이러한 요구를 충족하기 위해 SDV가 필요하다.
OTA (Over-The-Air)
무선으로 차량 소프트웨어를 업데이트하는 기술로, SDV의 핵심 요소이다.
2. 소프트웨어와 하드웨어 제어 구조
핵심 개념
소프트웨어는 직접 하드웨어를 제어하지 않고 레지스터를 통해 간접적으로 제어한다.
전체 흐름
[소프트웨어 코드]
↓
[컴파일 → 머신코드]
↓
[CPU 실행]
↓
[레지스터 값 변경]
↓
[하드웨어 동작]
↓
[핀 전압 변화]
↓
[LED ON]
구성 요소
- CPU: 메모리에 저장된 코드를 실행
- Flash 메모리: 프로그램 코드 저장
- RAM: 실행 중 데이터 저장
- Peripheral: MCU 내부 하드웨어 모듈 (GPIO, ADC, CAN 등)
- 레지스터: 소프트웨어와 하드웨어를 연결하는 인터페이스
정리
소프트웨어는 레지스터 값을 변경함으로써 하드웨어를 제어한다.
3. CAN 통신 구조

핵심 개념
CAN은 차량 내 ECU 간 데이터를 주고받기 위한 통신 방식이다.
구성 요소
- CAN Controller
- 메시지 생성
- 중재(arbitration)
- 오류 검출
- 논리 계층 역할
- Transceiver
- 디지털 신호 ↔ 전기 신호 변환
- 물리 계층 역할
구조
MCU → CAN Controller → Transceiver → CAN Bus
특징
- 브로드캐스트 방식
- ID 기반 통신
- 버스 공유 구조 (동시에 한 노드만 송신 가능)
신뢰성 확보
- CAN_H / CAN_L 두 선 사용
- 꼬인 선(Twisted Pair) 적용
- 차동 신호로 노이즈 상쇄
4. Ethernet이 필요한 이유 (SDV 관점)

핵심 개념
SDV를 구현하기 위해서는 기존 CAN만으로는 한계가 있어 Ethernet이 필요하다.
CAN의 한계
- 낮은 전송 속도
- 작은 데이터 크기
- 정적인 구조
- 서비스 기반 통신 어려움
Ethernet의 장점
- 고속 통신 (수십~수백 Mbps 이상)
- 대용량 데이터 처리 가능
- 스위치 기반 구조 (병렬 통신 가능)
- 서비스 기반 통신 지원
구조 비교
CAN (버스 구조)
모든 노드가 하나의 통신선 공유 → 순차 통신
Ethernet (스위치 구조)
각 노드가 스위치에 연결 → 동시에 통신 가능
관련 기술
- SOME/IP: 서비스 기반 통신 프로토콜
5. CAN vs Ethernet 비교
항목 CAN Ethernet
| 구조 | 버스 | 스위치 |
| 통신 방식 | 순차 | 병렬 |
| 속도 | 낮음 | 높음 |
| 데이터 크기 | 작음 | 큼 |
| 특성 | 정적 | 동적 |
6. 네트워크 기본: ARP
핵심 개념
IP 주소를 이용해 통신하기 위해, 해당 IP에 대응하는 MAC 주소를 알아내는 과정이다.
동작 과정
목적지 IP 필요
↓
ARP Request (브로드캐스트)
↓
ARP Reply (MAC 주소 응답)
↓
MAC 기반 통신 수행
포인트
- 브로드캐스트 주소: FF:FF:FF:FF:FF:FF
- 스위치는 요청을 전달만 하고 응답하지 않음
전체 흐름 정리
SDV (소프트웨어 중심 차량)
↓
Ethernet + SOME/IP (동적 통신 구조)
↓
MCU (CPU + 메모리 + Peripheral)
↓
레지스터 기반 제어
↓
CAN / Ethernet 통신
최종 정리
SDV는 차량 기능을 소프트웨어로 정의하고 OTA를 통해 지속적으로 업데이트하는 구조이다. 이를 위해 기존의 CAN 기반 정적 통신만으로는 한계가 있으며, Ethernet 기반의 고속 및 서비스 지향 통신이 필요하다. 또한 MCU는 레지스터를 통해 하드웨어를 제어하며, 차량 내 ECU 간 통신은 CAN 또는 Ethernet을 통해 이루어진다.
'개발 > 임베디드' 카테고리의 다른 글
| [RTOS] OSEK/Trampoline RTOS Task 스케줄링 실습 (0) | 2026.04.24 |
|---|---|
| [RTOS] RTOS Scheduling과 OSEK 개념 정리 (0) | 2026.04.23 |
| [차량 통신] 차량 네트워크 구조 정리 (CAN, Ethernet, TCP/IP) (0) | 2026.04.16 |
| [차량 통신] CAN, FlexRay, LIN, SOME/IP (0) | 2026.04.14 |
| [AUTOSAR] Communication 구조와 BSW 통신 스택 정리 (0) | 2026.03.24 |