본문 바로가기
카테고리 없음

자동차 산업 트랜드 : SDV 플랫폼

by studyml 2025. 5. 15.
반응형

 SDV 플랫폼은 소프트웨어 정의 차량을 개발, 배포, 관리하기 위한 통합 소프트웨어 및 하드웨어 인프라를 의미합니다. 본 글에서는 기존 자동차 산업의 트랜드와의 차이점에 대해서 개인적인 이해를 바탕으로 작성해 보겠습니다. 

 

SDV 플랫폼이란?

 SDV 플랫폼이 갖아야 하는 특징은 기존의 차량 구조와 달리, 전자 제어 유닛(ECU)마다 독립적인 기능으로 구동이 가능해야 합니다. 기존 시스템을 예로 들자면 제동 장치의 모터를 구동하기 위해서는 제동 ECU에서 생성된 신호로 제어가 됩니다. 즉 로컬 ECU가 상황을 판단하고 제어를 합니다. 반면 SDV에서는 최종 타켓을 중앙 CCU에서 생성을 하게 되고, 해당 모듈은 단지 actuator처럼 동작을 한다고 봐야 합니다. 쉽게 이야기 하면 예전에는 각자 팔다리가 알아서 판단을 했다면, 현재는 사람 처럼 머리가 하나가되어 "내가 명령을 내릴테니 너희는 잘 동작해" 와 같습니다. 즉 좀 좋은 말로 정리하면, 통합된 중앙 집중형 아키텍처에서 소프트웨어 중심으로 차량의 기능이 구현됩니다.

 

SDV와 기존 자동차 산업
SDV와 기존 자동차 산업

 

 

SDV와 기존 차량의 구조적 차이

 

 그렇다면 기존 차량 개발 방식과 SDV의 가장 큰 기능 차이는 어디에 있을까요? 앞서 이야기 한 내용을 표로 정리해 봤습니다. 

 

항목 기존 차량 (ECU 기반) SDV (소프트웨어 정의 차량)
기능 구현 방식 기능별로 각 각의 ECU에 코딩 됨 기능이 모듈화되어 소프트웨어 서비스 단위로 구혀
ECU 개수 수십~100개 이상 통합 플랫폼 또는 고성능 CCU로 통합 가능
업데이트 방식 정비소 방문 또는 수동 업데이트 OTA를 통한 원격 업데이트
기능 배포 고정된 기능 중심 구매 후에도 새로운 기능을 추가 가능
개발 방식 하드웨어 중심 소프트웨어/서비스 중심, DevOps 적용
보안 업데이트 수동 반영, 느림 자동 배포, 빠른 대응 가능

 

 

반응형

SDV 플랫폼의 주요 구성 요소

 위의 기능을 나타 내기 위해서는 기존 시스템과는 다르게 SDV가 갖어야 할 구성 요소가 있습니다. 개인 적인 생각에는 모든 내용의 기반이 되는 내용은 OTA와 보안이지 않을 까 싶습니다. 사실 SDV라고 좋은 말을 갖다 넣기는 했지만, 기존 시스템에서 OTA만 된SDV와 유사한 컨셉의 개발도 가능합니다. 생각해보면 HW는 차량에 장착 된 이후, 고정 되더라도 SW는 지속적으로 개발이 될 수 있습니다. 하지만, 기존 시스템에서는 개선된 SW를 넣으려면 캠페인을 하던지, 자발적 리콜을 해야 하던지 매우 복잡한 일들이 있을 수 있습니다. OTA가 있다면? 이야기가 달라 집니다. 로컬 ECU의 개선된 소프트웨어를 바로 바로 고치고 수정 하고, 최신 SW 업데이트가 가능합니다. 

 여기서 SDV 돌풍을 일으킨 테슬라가 한 건을 합니다. 일단 출시 하고, "사사로운 문제는 OTA로 처리 할 수 있어" 가 컨셉입니다. 자동차 산업에서 대부분의 사람들은 완전 무결을 강조합니다. 반대로 IT 산업군의 사람들은 빠른 제품화를 선호합니다. 왜냐, 자동차 산업은 사람의 생명과 직결 되기 때문에 검증이라는 이름 아래에 매우  보수 적인 판단을 하는 곳이기 때문입니다. 반대로 IT는 제품 주기가 상대적으로 자동차 산업대비 빠릅니다. 산업 사이클로 봤을 때 차량을 한 번 구매하면 10년은 타지만, IT 제품이나 IT 서비스의 경우 1~2년만 업데이트를 하지 않으면 도태 될 수 있기 때문입니다. 제품의 라이프 사이클에 따라 개발 방식이 달라졌다고 생각 했으나, 테슬라가 바로 이러한 틀을 깨고 게임 첼린져가 되었습니다. 치명적인 문제가 아니라면 우선 출시하고, OTA로 빠르게 고치며 진행 했습니다. 놀라운 변화이고, 다른 산업 군에서 넘오 온 사람들이 있었기 때문에 가능한 일이지 않았나 싶습니다. 

  

구성 요소 설명
중앙 컴퓨팅 유닛 (CCU) 여러 ECU의 기능을 통합한 중앙 제어 유닛
운영체제 (OS) 차량용 실시간 OS 또는 리눅스 기반 OS (: QNX, AGL, AUTOSAR Adaptive )
서비스 아키텍처 마이크로서비스나 서비스 지향 아키텍처(SOA)를 통해 기능 모듈화
OTA 기능 Over-The-Air 업데이트를 통해 기능 및 보안 패치 배포 가능
클라우드 연동 클라우드와의 연계를 통한 데이터 분석, 원격 진단, 기능 업데이트
디지털 트윈 및 시뮬레이션 가상 차량 환경에서 테스트 및 검증 가능
DevOps / CI-CD 파이프라인 지속적인 개발 및 배포 환경을 갖춘 개발 체계

 

OTA가 SDV의 핵심인가?

필수 조건이지 핵심은 아닙니다. 제품을 바로보는 관점을 바꾸는데 SDV의 핵심이 있습니다. 즉, SDV = 차량 기능의 정의, 실행, 업그레이드를 모두 소프트웨어로 수행할 수 있는 구조를 말합니다. 

  • 고객 인도 후에도 기능 추가/변경/제한이 가능 해야함
  • 하드웨어가 변하지 않아도 해당 모듈의 소프트웨어를 개선할 수 있어야 함
  • 중앙 집중형 소프트웨어 아키텍처로 전환, 각 모듈이 판단하는 형태가 아니라, 중앙에서 신호처리 가능해야 함
  • 빠른 개선과 배포를 위해,  SW를 DevOps, CI/CD 기반으로 개발

각 OEM 별 SDV 사례

  • Tesla: 차량 기능이 소프트웨어로 정의되어 있으며, OTA를 통해 실시간 기능 업데이트 가능
  • BMW iDrive : 운영체제 기반으로 다양한 차량 기능을 소프트웨어로 제어
  • Hyundai ccOS / SDV 플랫폼 : 소프트웨어 중심 구조 전환을 선언하고, XM 기준으로 개발 중

 

마무리

SDV의 핵심은 "아키텍처 변화, 서비스화된 기능 구조, 그리고 중앙 통제형 소프트웨어 플랫폼" 입니다. 개인적으로 기존 시스템에 OTA만 달리고 중앙 ECU에서 로컬 ECU에 대한 업데이트만 가능하다라도 제한적인 SDV가 가능 할 것으로 생각합니다. 그러나, 대부분의 사람들이 각 단계는 넘어 최종 목표로만 가는 듯 싶습니다. 가끔은 중간 다리까지가고 가는 것도 방법이지 않을까 싶습니다.