Software defined vehicle

소프트웨어가 하드웨어 제어한다는 개념, SD-WAN이랑 같은ㄱ ㅐ념

스마트폰의 진화과정이랑 같을 것이라고 봄

Smart Car

Connectivity - 연결

Autonomous - 자율주행

Electrification

OTA

SMART CAR Data collection -> Center computer에서 처리 -> DB 로 데이터보냄 -> AI 필터링, 딥러닝 -> 자동차에 업데이트

OEM 업체들은, ECU 베이스로 만들어짐, Tier 1 회사들이, 자동차 회사에 하드웨어와 ECU를 같이 제공

즉 tier 1에서 개발한 각자 다른 OS의 ECU가 들어간다는것 > 복잡해짐

> 차에 소프트웨어를 업그레이드 하거나 이런게 어려워지는 이유

옛날에는 하드웨어 >> 소프트웨어, 였지만 지금은 반대로 소프트웨어가 하드웨어 (자동차)를 제어하는 그림으로 나오는 것

테슬라는 오류가 발생했을때 OTA 업데이트로 한다는 것

SDV구현으로 원가 절감 할 수 있음 > 소프트웨어로 컨트롤 하게 된다면, 서비스센터 비용이라던지 이런게 획기적으로 줄수 있다는 것

기존의 기능보다 더 좋은 기능으로 사용가능

안정성도 올라감

SDV 경쟁에서 뒤쳐질 경우, 피쳐폰의 길을 가게 될 것임

EE Architecture . 테슬라는 Zone 방식으로 가있음

도메인 방식 (현재 조금씩 적용하는거)

수십개의 ECU 를 기능별로 묶어주는거

Connectivity
Drive
Autonomy
Informatinment
Body

이렇게 통합 ECU 를 만들어 놓고 중앙에 Central gateway 놓고 네트워킹 및 통신 지원

Eventually zone 방식으로 감

지역별로 하드웨어 배치해놓고, Central compute (tesla hardware 3.0) 중앙 집중형 computer를 놓고,, 차를 컨트롤 해가는 방식

결국 Zone으로 가면 원하는 위치에 하드웨어를 배치해놓고, 훨씬 wiring harness 가 간소화 될 수 있음

무게 + 제조원가 절감

완성차 업체의 과제는,, 이 운영체제를 만드는 것 ** 소프트웨어 개발역량이 굉장히 중요함

하나의 OS(Windows/Linux) 로 자체로 컨트롤한다? 너무 위험함 -> Container orchestration 의 도입

차량은 각 기능별로 각각의 multi OS 체제로 사용 > Hypervisor (Docker)

OTA (Over the Air)

플랫폼 기업들은 Linux 를 쓰되, 자기들의 OS로 clustering 해서 distribution 해야함 (보안때문에)

ADAS나 Autonomous 같은 거는 RTOS 방식 (즉각적으로 반응할꺼) 으로 운영이 될꺼고 이 방식에는 QNX OS가 사용될 것

Tier 0.5 > 소프트웨어 개발 잘 되는 업체들, Big tech 는 여기 파고들수있음

클라우드를 통해 어떻게 SDV에 대해 최적화를 시키고.. 이런거 > Cloud 사업자들이 개발/서비스 가능

OTA (Over-the-Air) 작동 원리

OTA는 네트워크를 통해 원격으로 소프트웨어를 업데이트하는 메커니즘이다. 스마트폰뿐 아니라 자동차, IoT, 라우터, 서버 장비까지 동일한 구조를 가진다.

당신이 SDV(Software Defined Vehicle) 환경에 관심 있는 만큼, 자동차 OTA 기준으로 구조를 설명한다.

구성 요소는 다음 4계층이다:

① Cloud Backend

업데이트 파일 저장 (Firmware / App / Config)
버전 관리
대상 차량 그룹 관리
인증/서명 관리
배포 스케줄 제어

보통 AWS, Azure 같은 클라우드 기반.

② TCU (Telematics{컴퓨터 통신이용} Control Unit)

차량 내 통신 게이트웨이
LTE/5G/WiFi 통해 클라우드 접속
OTA 패키지 다운로드 담당

③ Gateway ECU

차량 내부 네트워크 브릿지
CAN / Ethernet 통신으로 각 ECU에 전달

④ Target ECU

실제 업데이트 대상
예: ADAS ECU, Infotainment, Body Control Module

아래는 Example

OTA 업데이트 단계별 동작

Step 1 — Update Trigger

클라우드가 특정 차량 VIN에 업데이트 할당.

차량이 주기적으로 서버에 체크:

GET /update/check?vin=xxxx

Step 2 — Download

TCU가 TLS 기반 HTTPS로 패키지 다운로드
Delta update (변경된 부분만 다운로드) 사용 가능
파일은 암호화 + 서명됨

Step 3 — Verification

차량 내부에서:

디지털 서명 검증
해시 체크
무결성 확인

Secure Boot 기반.

Step 4 — Install (Flashing)

ECU가 새 firmware를 별도 partition에 설치.

여기서 중요한 개념:

A/B Partition 방식

A: 현재 실행 중
B: 업데이트 설치 공간
성공하면 B로 스위칭
실패하면 A로 롤백

→ Brick 방지

Step 5 — Activation

차량 재부팅
ECU 재시작
정상 동작 확인 후 완료 보고

보안 구조 (가장 중요)

자동차 OTA는 ISO 21434, UN R156 규정 적용.

핵심:

① End-to-End Encryption

TLS 1.2+

② Code Signing

OEM Private Key로 서명
차량에는 Public Key 내장

③ Secure Boot

부팅 시 firmware 서명 검증

④ Anti-Rollback

이전 취약 버전으로 다운그레이드 방지

4. 네트워크 관점 (당신 백그라운드 기준)

네트워크 엔지니어 관점에서 중요 포인트:

LTE APN 구성
VPN 터널 (IPSec/OpenVPN)
MQTT vs HTTPS 통신 방식
Firewall 정책
NTP 동기화
패킷 손실 대비 Resume download

실제 기업 사례

Tesla → Full vehicle OTA
Hyundai Motor Company → Infotainment + 일부 ECU OTA
Sonatus → SDV 플랫폼 기반 OTA/Vehicle orchestration

Sonatus 같은 회사는 차량 내부 네트워크 virtualization + OTA orchestration을 제공한다.

대부분 차량은 내장 SIM(eSIM) + 셀룰러 모뎀(LTE/5G) 기반으로 통신한다.
Wi-Fi는 보조 수단이다.

구성

TCU (Telematics Control Unit)
- LTE/5G 모뎀 포함
- eSIM 내장
- GPS 포함
외부 안테나
이동통신사 망 연결

2️⃣ SIM 종류

① Embedded SIM (eSIM) – 표준

차량 생산 시 내장
원격 프로파일 변경 가능 (GSMA eUICC)
물리적 교체 불필요
OEM이 통신사와 계약

② Physical SIM – 과거/일부 모델

교체 가능
유지보수 불편

현재는 대부분 eSIM 기반.

3️⃣ 통신 방식

차량 → 기지국 → 통신사 Core → Internet → OEM Cloud

프로토콜은 보통:

HTTPS (TLS)
MQTT over TLS
VPN (IPSec/OpenVPN)
APN 분리망 사용

4️⃣ 데이터 요금은 누가 내는가?

보통:

차량 가격에 3~5년 포함
이후 유료 구독 모델
OTA는 OEM이 부담

5️⃣ Wi-Fi OTA는? 대용량 업데이트(수 GB)는:

집 Wi-Fi 연결 시 다운로드
주차 상태에서 진행
배터리 전압 조건 확인

네트워크 엔지니어 관점 포인트

당신 기준으로 중요한 것들:

APN 구성
Private APN + VPN 터널
NAT traversal
Packet loss recovery
Resume download
QoS 제어
SIM lifecycle management

7️⃣ 정리

항목사용 여부

SIM Card	✅ 대부분 사용
eSIM	✅ 현재 표준
LTE	✅ 기본
5G	점점 확대
Wi-Fi	보조
위성통신	거의 없음 (일반 승용차 기준)

이제 **현대차 CCOS 구조 + OTA + 통신(eSIM)**을 같이 묶어서 설명한다.

1️⃣ CCOS가 뭔가

CCOS = Connected Car Operating System

현대차그룹이 SDV 전환하면서 만든 통합 SW 플랫폼.

두 가지 축이 있다:

ccOS.a → Automotive (차량 내부 영역)
ccOS.i → Infrastructure (클라우드 영역)

3️⃣ ccOS.a (차량 내부)

차량 안에 있는 소프트웨어 스택.

구성:

IVI (Infotainment)
Domain Controller
Gateway ECU
Application Layer
Middleware
Hypervisor / Linux / Android 기반 OS

OTA와의 관계

ccOS.a는:

OTA agent 포함
Update Manager 존재
ECU version 관리
Flashing orchestration 수행

즉, 차량 쪽 OTA 실행 주체가 ccOS.a

4️⃣ ccOS.i (클라우드 영역)

클라우드 기반 인프라 플랫폼.

구성:

OTA Server
Device Management
Fleet Management
Data Lake
Telemetry
Security Key Management

OTA에서 역할

업데이트 패키지 저장
차량별 버전 매칭
VIN 기반 배포 제어
롤아웃 단계별 배포
성공/실패 리포트 수집

즉, 배포 컨트롤 타워가 ccOS.i

5️⃣ 통신은 어디서 어떻게 연결되는가

핵심:

ccOS.a 안에 있는 TCU가 eSIM을 통해 ccOS.i와 통신

흐름

차량 시동 ON
TCU → LTE attach
APN 접속
VPN 터널 생성 (OEM Private APN)
HTTPS/mTLS 세션 생성
OTA check

6️⃣ 네트워크 레벨로 보면

당신 네트워크 엔지니어 관점에서 보면:

차량 측

eSIM profile
LTE modem
Private APN
IPSec tunnel
NAT traversal

클라우드 측

Load Balancer
API Gateway
OTA microservice
Object Storage (firmware)

7️⃣ OTA 동작을 ccOS 기준으로 다시 설명

Step 1

ccOS.a → ccOS.i
/checkUpdate

Step 2

ccOS.i → Update available response

Step 3

ccOS.a → Download (TLS encrypted)

Step 4

ccOS.a 내부 Update Manager가
각 ECU에 UDS/DoIP로 flashing 지시

Step 5

결과 리포트 → ccOS.i

8️⃣ 왜 ccOS가 중요한가

과거:

ECU 각각 독립 → OTA 어려움

현재 SDV 구조:

Domain Controller 중심 구조
ccOS.a가 모든 ECU orchestration

→ 대규모 OTA 가능

9️⃣ ccOS와 Sonatus 같은 회사 연관성

Hyundai Motor Company
Sonatus

Sonatus는:

차량 내부 네트워크 virtualization
Data orchestration
OTA orchestration

즉, ccOS.a 내부에 들어가는 일부 플랫폼 기술과 유사 영역.

🔟 요약 (한 줄 정리)

ccOS.a = 차량 내부 실행 플랫폼
ccOS.i = 클라우드 인프라 플랫폼
OTA = ccOS.i가 배포하고 ccOS.a가 실행
통신은 eSIM 기반 LTE/5G + Private APN + TLS/VPN

'ETC' 카테고리의 다른 글

Jira & Confluence (0)	2026.03.12
Palantir (0)	2025.04.17
SAP MM / Module (0)	2025.04.17
Built to Last by Jim Colins 책 요약 (0)	2022.10.19
네전따 2 세미나 (0)	2021.11.27

SDV (Software Defined Vehicle) 정리