Welcome!
『SDV Letters』 뉴스레터에 초대합니다. 

『SDV Letters』는 에디터 및 현대엔지비 모빌리티 기술연구회 SDV (Software Defined Vehicle) 분과의 관심 분야 및 이슈를 정리하여 공유하는 뉴스레터 입니다. 구독자 모두가 모빌리티 기술연구회의 일원으로 독자 투고와 최신 레포트 등을 업데이트 하여 드리며, 무료 구독제로 운영 합니다.

★구독 신청★ ☞ jhkim0402@hyundai-ngv.com 기술정보팀 김준혁 매니저

 Issue 002.

 최근 자동차 산업 및 미래 자동차의 메가트렌드는 M.E.C.A (Mobility Service, Electrification, Connected, and Autonomous) 로 대표되는 네가지 단어로 표현할 수 있습니다. 이러한 MECA 트렌드의 Tech Enabler는 자율주행을 위한 Deep Learning, 친환경차를 위한 eP (Electrical Powertrain), 커넥티드카를 위한 고속/고신뢰 통신, 모빌리티 서비스를 위한 클라우드 플랫폼 등이 떠오릅니다. 여러 Tech Enabler 중에서 (당연하게도) SDV Letters에서는 M.E.C.A를 모두 아우를 수 있는 SDV에 대해 탐구하고자 합니다. 

 미래 자동차를 혹자는 "바퀴 달린 스마트폰" 이라고 표현하기도 합니다. 이 표현의 진위를 떠나 이런 표현이 등장하게 된 이유는 우리가 스마트폰 시대로 넘어오면서 Cell phone 기능의 정의가 더이상 하드웨어(HW)에 의존적인 것이 아닌, 소프트웨어(SW)가 기능과 성능을 정의하는 시대가 도래한 것 입니다. 미래 자동차도 비슷합니다. SDV 라는 Tech Enabler 가 차량의 새로운 기능과 서비스를 사용자 니즈에 맞추어 제공하고, SW로 eP의 성능을 정의 하며, 자율주행의 성능을 (원격으로) 지속 발전 시킬 것 입니다. 본 Letter 에서는 SDV의 정의, 필수 요소, OEM 동향 및 도전에 대해 다룹니다. 챕터 (1)에서 Service-Oriented Architecture 개념으로의 SDV 정의, 챕터 (2)에서 각 OEM의 SDV 구현 동향, 챕터 (3)에서 SDV를 구현하기 위한 필요 기술, 챕터 (4)에서는 SDV 시대의 서플라이 체인의 변화, 그리고 (5) 결론으로 Letter를 마무리 합니다.

 (1) SDV의 정의; SOA가 기반 

  SDV의 사전적 의미는 SW가 그 기능(feature, function)을 정의하는 차량이라 할 수 있습니다. SW, 많은 양의 프로그램(명령어의 집합)을 내재한 차량의 개념인 'SW-Centric vehicle'을 SDV라 하지는 않습니다(그림1 차량 개발에 사용되는 SW Line of Codes). SDV는 SW-Centric Vehicle에 Service-Orientation 개념이 더해집니다; 

SDV = "SW-Centric Vehicle" + "Service-Oriented Architecture".

여기서 Service-Oriented Architecture (SOA)는 SDV의 핵심 덕목 입니다. 간단히 설명을 하자면 '소비자' 관점과 '제조사'의 관점에서 정의할 수 있습니다. 소비자 관점은, 차량 기능이 SW로 구현되어 각 기능이 동적으로 추가/수정 가능하도록 하는 메카니즘 입니다. 제조사 관점은, 차량의 기능(Function, feature)이 폐쇄적이고 독립된 서브시스템이 아닌, 개방되고 상호조합 가능한 서비스로 구성된 컨셉이라 보시면 됩니다. 이는 Adaptive AUTOSAR의 핵심 철학(AUTOSAR 관련 별도 발행 예정) 입니다. 추가로 이러한 차량 기능을 원격으로 동적 추가/수정 하는 Over-the-Air(OTA) upgrade의 기반이라 할 수 있습니다. 

  SOA에 대해 조금 더 파고 들어가 봅시다. SOA는 엔터프라이즈 컴퓨팅 도메인에서 널리 알려진 개념으로 네트워크-통신 프로토콜을 통해 애플리케이션 구성 요소에 의해서 또 다른 구성요소에 서비스가 제공되는 SW 설계 스타일 입니다 (Wiki).  

 

 여기서 '서비스'는 고객 중심의 경영자의 입장과 IT/개발의 입장을 연결하기 위한 매개체라 할 수 있습니다. 기업의 업무를 표현하는 단위이며, 상호 조합 가능한 독립된 단위 SW, 표준 인터페이스를 통해 연결 되며, 플랫폼에 종속되지 않는 개념 입니다. 이와 같이 비즈니스를 '서비스'로 제시하고, SW 구현을 '서비스'에 기반 하는 것이 Service-Orientation의 의미 입니다. '서비스'를 1st-class entity로 두고 SW를 구성 하는 것이 SOA이며, 어플리케이션(또는 기능)을 여러개의 서비스로 나뉘어 통합한 것 (분산 된 서비스는 Remote procedure call을 통해 호출) 이라고도 할 수 있습니다. 

 아래 그림2의 예시로 설명하겠습니다. 과거에는 IT 부서에서 isolated 되어 대형 시스템을 개발, 통합 하는 역할을 하였는데 그런 방식이 sub-system 들이 모놀리식(Monolithic)한 한 덩어리 시스템이 되었고, 시스템 공유할 수 있는 요소들이 있음에도 불구하고 독립적으로, 중복적으로 구현 되는 문제점이 있었습니다. SOA에서는 비지니스 부서에서 도출한 서비스 단위로 개발 한 다음, 비지니스 부서가 서비스를 연결하여 비즈니스를 만들면, 서비스에 해당하는 SW 모듈을 똑같이 연결하여 IT/SW 인프라도 같이 만드는 것 입니다. 이런 식의 개발로 비즈니스 부서와 IT 부서간의 커뮤니케이션 또한 원활해 질 뿐만 아니라 SW 인프라와 구조 또한 효율화 될 수 있습니다. 이러한 이유로 Enterprise 도메인에서 SOA가 자주 활용 되었습니다.   

[그림2] SOA 적용 전 후의 어플리케이션 구현 구조 비교 (Source: medium.com)

 SOA가 중요한 이유는 그 이점으로 설명 가능 할 수 있습니다.

• SOA를 사용하여 재사용 가능한 코드 생성: 이는 개발 프로세스에 소요되는 시간 단축 뿐 아니라 새로운 서비스 또는 프로세스를 생성해야 할 때마다 개발을 반복 할 필요가 없게 됩니다. SOA는 또한 모든 것이 표준/중앙 인터페이스를 통해 실행되기 때문에 여러 개발 언어가 호환 될 수 있습니다.
  
• 확장성을 위해 SOA를 사용: 클라이언트의 요구사항을 충족하도록 비즈니스를 확장할 수 있는 것이 중요하지만 특정 종속성이 확장성을 방해할 수 있습니다. SOA를 사용하면 클라이언트-서비스 상호 종속이 줄어들어 확장성이 향상 됩니다.
• 비용의 절감: SOA를 사용하면 원하는 수준의 결과물을 유지하며 비용 절감이 가능합니다. SOA를 사용하면 기업이 맞춤형 솔루션을 개발할 때 필요한 투자를 줄일 수 있습니다.

 SOA와 비슷한 개념으로 학술적으로 파고들면 Software-as-a-Service (SaaS)나 microservice Architecture 등이 있습니다. SOA 등 이러한 개념들이 사실 엔터프라이즈 컴퓨팅 영역에서 개발 된 개념이기 때문에 자동차 산업에 적용하기 위해 맞지 않는 부분도 있고 해서 친숙하지만은 않은 것 같습니다 ^^;

 다시 SDV로 돌아오겠습니다. SDV의 기대 효과로 SDV가 구현된 자동차는 차량 판매 이후, 제품 라이프사이클 전반에 걸쳐 지속적인 기능과 부가가치를 창출할 수 있게 됩니다 (OTA와 결합하여 더욱 강력한 솔루션이 됨). 이는 운전자의 신규 UX 욕구 및 급변하는 환경과 서비스 니즈에 대응 가능하게 됨으로서 “차량의 기능(Function / Features)을 SW로 정의" 하고자 하는 SDV의 목적을 설명할 수 있습니다. 

 (2) OEM의 SDV 구현 동향 리뷰

 SW로 각종 기능을 구현하는 SDV에 관한 구상은 Tesla가 SDV를 선구적으로 도입해 일정한 성공을 거두면서 순식간에 자동차 업계 전체에 퍼졌습니다.

 (3) SDV를 구현하기 위해서는 ... (예고편)

 앞선 챕터에서는 SDV를 위한 OEM들의 저마다의 움직임을 살펴 보았습니다. 다양한 파트너십과 내부 전략이 있는 가운데, 이들의 공통적인 기술적 필요조건을 살펴보고자 합니다. 여기에 나열 된 기술들이 향후 SDV Letters의 주요 주제가 되지 않을까 싶습니다. 개별 아이템을 상세히 다루긴 힘드니, 처음 접하시는 분들을 위해 몇 줄 씩만 코멘트 하고 넘어 가도록 하겠습니다. 

1. 중앙 집중형 E/E Architecture 로의 진화 (a.k.a. Zonal Architecture) [Link]
  - 현재 Flat E/E 아키텍처에서 Domain 기반 E/E 아키텍처로 진화 (그림3),
    ☞ 많은 ECU (or DCU)에 서로 다른 운영체제(OS)가 장착 된 이질적인 구조,
    ☞ 도메인 별로 차량 전역에 대한 와이어링이 적용 되어 있음 → 물리적 제약,
    ☞ 기능 및 SW의 중복, 펌웨어의 다양성, Failure 분석의 난이도,
    ☞ 전통적 서플라이 체인이 초래한 "피치 못할 결과물",
  - E/E 아키텍처를 근접성으로 분할하여 재구성,
    ☞ 기능 도메인은 가상화,
    ☞ 핵심 요소: 중앙 차량 컴퓨터(기존 DCU 기능 통합하며 제어 기능을 중앙화/SW 化), Zonal Gateway(I/O, 배전/배선, J/B 역할), 차량용 이더넷(백본 망) 등 → 다양한 구현 토폴로지와 아이디어.

[그림3] E/E 아키텍쳐의 진화 과정 (Figure Source: Siemens)  

2. 통합 OS [Link]
  - 개별 장비 별로 존재하던 Control Plane을 별도로 분리하여 SW 형태의 컨트롤러에서 구현함으로써 장비 각각 별도 제어가 아닌 컨트롤러를 통한 집중화된 관제 및 제어가 가능,
    ☞ 자동차 에서는 신뢰성에 대한 요구가 상당히 높음,
  - SW 부품의 통합과 검증을 위한 핵심 플랫폼 역할로 OEM의 이점,
    ☞ SW 개발/수정/배포의 주도권 및 Time to market 단축,
    ☞ HW와 SW의 병행 개발로 개발 주기 단축 가능,
    ☞ SW Failure 분석 용이,
    ☞ 플랫폼 개방화로 다양한 개발사 참여 가능 (HW 및 SW의 스텍 표준화),
  - 참고기사 (Redhat),
  - SDV를 염두해 두고 일부 OEM들은 통합 차량 OS를 in-house로 개발 중 (그림4).

[그림4] In-house 통합 OS 개발의 장단점 및 사례 (Source: Frost & Sullivan)  

3. HW-SW Decoupling 
  - SDV의 주요 목적으로 SW는 기능 실현의 중심이며 HW는 추상화 (그림5),
    ☞ HW 중심의 UX를 SW 중심으로 대체시키는 역할,
  - 기존의 SW는 특정 HW에 종속된 프로그램을 의미했지만 ... 
    ☞ HW와 SW가 일체화 된 모듈이 아닌 각각 별도를 구매 또는 개발하게 될 것,
  - Adaptive AUTOSAR,
    ☞ SOME/IP 미들웨어 스택 도입으로 SOA를 위한 표준 플랫폼 제시,
  - 차량 SW를 공급하는 새로운 supply chain 필요.

[그림5] AUTOSAR로 인한 HW-SW Decoupling의 도식 (Figure Source: [Link])  

4. OTA Upgrades
  - SW 전담조직이 SDV 장비/인프라를 운용하면서 필요에 따라 기능을 추가/삭제/수정이 가능한 개발운영(DevOps)이 가능,
  - HW의 추가 또는 수정 없이 원격으로 새로운 기능 추가가 가능,
  - 차세대 E/E 아키텍처와 SOA의 결합으로 SW 생태계의 변화,
  - FoD와 같은 비즈니스 모델 확장 가능 (그림6),
    ☞ 자동차는 End Product가 아닌 새로운 비즈니스 모델 전개를 위한 플랫폼으로서의 가치 실현 가능 (일회성 제품의 판매 → 제품 + 전체 라이프사이클 서비스).

[그림6] OTA를 수익화한 사례 (Not Exhaustive, Source: [Link] ) 

1 RMB: 1 중국 위안화로 8월28일 1 RMB는 약 195 KRW. 

5. Cloud Platform
  - OEM은 보안 및 개인정보 보호와 같은 문제가 처리되는 E2E 솔루션이 가능한 클라우드 공급업체를 탐색 중,

  - 클라우드의 역할은 신규 UX의 관리 및 배포, AI 및 머신러닝의 강화, 데이터 관리 및 수익화, 데이터 프라이버시 및 보안, 차량 설계 등,
  - 자동차 제조업체는 다양한 기능에 대해 별도의 클라우드 아키텍처를 배포하여 멀티 클라우드 적용 하기도,
    ☞ 성공적 SDV 클라우드 구현 위해 목적에 맞게 구축된 모델에서 수평 및 조직 차원의 접근 방식이 고려 되야함 (그림7).

[그림7] OEM의 클라우드 플랫폼 파트너 (Not Exhaustive, Source: Frost & Sullivan)  

 위 나열한 기술적 이슈 외에도 기존 서플라이 체인의 재구성(생각보다 간단한 문제가 아닙니다.^^;) 및 SW 인력 확보 및 관리 등 다양한 필요 조건이 있겠지만, 차차 다루기로 하겠습니다. 

 (4) SDV의 공급망과 Tier 0.5의 등장 

 기존의 분산 E/E 아키텍처에서 컨트롤러의 HW와 제어 로직은 Tier-1 공급업체에서 제공되어 왔으며, OEM은 서로 다른 공급업체를 조정하므로 협업이 극도로 비효율적 이었습니다. 새로운 E/E 아키텍처, Zonal 아키텍처 에서는 SW 주도권을 가진 OEM이 우위를 점할 수 있습니다. 자체 SW 및 HW 플랫폼을 기반으로 공급업체에 (Tier-2 이더라도) 직접 수요를 전달하며, 그 와중에 Tier-1(Ex. Bosch, Continental 등과 같은 메가 Tier-1)의 영향력은 더 이상 지배적이지 않을 수 있으며, Tier-0.5 서플라이어는 SDV 및 AD를 위한 알고리즘/SW 까지 제공 할 수 있습니다. Tier-0.5는 기존 Tier-1의 역할 AND/OR Functional/Basic SW, 범용의 HW 아키텍처 제공 및 White-Label solutions의 제공 역할로 보시면 될 것 같습니다. 

 물론 SDV로 가는과정에서, OEM과 Tier-1 사이에 SW 주도권에 대한 이권 다툼이 계속 될 것이고, 이 것이 기존 OEM의 SDV 전환을 늦추게 되는 요인이 될 수 있습니다. 테슬라 처럼 in-house 로 통합 OS와 주요 SW를 직접 개발하고, 특정 Tier-1에 의존 하는 것이 아닌 HW 업체로 부터 White-label solution (OEM이 원하는 형태에 맞게 모듈식으로 자동차를 만들 수 있음)을 공급 받던가 말입니다. 당연하게도 기존 ICE의 주도권을 가지고 있던 글로벌 OEM들의 성공은 보장 되지 않습니다 (기존에 자리 잡은 de-facto를 쉽게 뿌리칠 수 없음).

 기존 OEM 및 공급업체가 역량이 부족한 SW에 의해 주도되는 기술 업체 및 디지털 플레이어로 자동차 산업에 진출하고자 하는 Apple과 같은 잠재적 위협에 주도권을 빼앗길 수도 있습니다. 또 다른 변화로 특정 틈새 분야의 전문 분야에서 활약할 신규 참가자 (Tier-2/3가 Tier-1 으로 승격 되기도 [CARIAD-Innoviz]), SW 개발 및 플랫폼 개발 능력을 갖춘 신규 플레이어(그림8)는 OEM을 위한 개발 파트너로서 탁월한 위치에 있음을 알게 될 것 입니다. 

 다양한 형태의 서플라이 체인 모델과 OEM, Tier-1 및 Tier-2/3 등 저마다의 활로를 찾기 위한 내부 혁신과 파트너십 등이 긴밀하게이루어질 것으로 기대 됩니다.  

[그림8] SDV 서플라이 체인 예시 (Frost & Sullivan)  

 (5) 맺음말 

 여기까지 SDV 에 대한 장황한 설명이었습니다. SDV란? 이란 물음에 "HW 보다 차량의 SW에 더 큰 가치를 두어 기능과 서비스를 커스터마이징 할 수 있는 가치를 가진 Vehicle" 이라 제 나름의 짧은 대답을 남겨 봅니다. 마지막으로, 필자의 SDV 구현을 위한 세가지 코멘트를 끝으로, 2번째 Issue "SDV란 무엇인가?"를 마치도록 하겠습니다. 

 

 SDV는 2022년 현재 자동차 산업에서 유행하는 용어 중 하나이지만 OEM마다 다른 의미와 컨셉을 갖기도 합니다. 각 OEM은 조직 전체에 적용되는 고유한 사고, 전략 및 목표를 수립해야 합니다. 이 전략과 목표에는 SW 전문 인력 확보 및 관리에 대한 것도 포함 됩니다. 

• 투자/파트너 찾기 (or M&A)

 "협력"을 기반으로 구축되는 자동차 산업의 미래 서플라이 체인. OEM은 화이트 라벨링 솔루션을 포함한 엔드 투 엔드 기능을 제공하는 새로운 Tier 0.5 공급업체의 공동 제작 파트너를 선택할 것입니다. HW 판매 후 소비자를 자사 디지털 공간에 가두는 전략은 스마트폰 등 IT 업계에서는 당연시 되는 전략 입니다. 그러나 순수 IT 단말과는 달리 차량의 경우 기대한 대로 구입자가 디지털 애프터 서비스를 이용할 지 여부가 불투명 하며, 충성도 및 로열티도 문제 입니다. 따라서, 향후 OEM은 해당 차량만이 제공할 수 있는 매력적인 기능이 요구 될 것으로 바라봅니다. 

끝.

 SDV관련 테크니컬 레포트/기사 소개