미래 자동차 산업의 핵심 동력: SDV 달성을 위한 필수 요소들과 평가 방법

미래 자동차 산업의 핵심 동력 : SDV 달성을 위한 필수 요소들과 평가 방법

 

 

본 포스팅은 SDV를 주제로 하는 연재물입니다.

SDV에 대한 전체적인 내용을 알고 싶다면 다음을 클릭해 내용을 추가로 확인해주세요

 

저번 포스팅에서 SDV가 중요한 이유와 그 배경에 대해 알아보았습니다. 글을 요악하면, SDV는 Software Defined vehicle의 약자로 차량에서 소프트웨어의 중요성을 높이겠다는 의미로, 테슬라와 폭스바겐에 의해 최초로 등장한 개념이라 요약할 수 있었죠. 그리고 SDV란 자동차의 핵심이 되는 CASE의 기반 요소로서, 미래 자동차의 수익성을 증가시킬 수 있지만 BOM내 R&D 비중의 확대, 하드웨어와의 시너지 고려 등의 전제 조건이 필요한 것을 알 수 있었습니다.

 

지난 글에서 이런 배경적인 요소를 다뤘다면, 이번 포스팅에서는 이런 전제 조건에 대해 보다 자세히 다뤄보려 합니다. 이를 위해서 현재의 자동차 환경과 SDV 구현을 위한 자동차 환경을 AS-IS와 To-Be로 나눠 설명하는 방식으로 진행될 것이고요. 또한 아무래도 기존에 제가 블로그에서 미처 다루지 못했던 용어들이 등장할 것이기에, 이에 대한 간략한 설명 역시 함께 진행하려 합니다. 물론 SDV에 관심을 가진 분들이라면 충분히 산업에 대한 이해가 있으시겠지만, 그래도 혹여 이런 용어를 처음 접하는 분들을 위해 쉽게 글을 기고하고자 해요. 마지막으로 SDV의 평가 기준에 대해 다뤄보며, 기존 차량과의 차이점에 대해 알아보도록 하겠습니다.

 

 

반응형

 

 

 

 

1. SDV 도입을 위해 차량은 전체적으로 재구성되야 한다

 

 

SDV의 도입을 위해서는 기존 차량 구조에 많은 개선이 필요합니다. 현재 OTA 업데이트를 통해 다양한 차량의 ECU를 업데이트 할 수 있는데요. 모터제어유닛(MCU), 전자제어서스펜션(ECS), 스티어링휠(MDPS), 동력성능(VCU) 등을 개선하는 것이 이제는 우리에게 익숙한 일이기 때문이죠. 기업마다 이름은 다르지만 BMW의 RSU(Remote Software Update)와 같이 OTA를 통해 자사의 커넥티드 앱을 활용, 차량의 기능을 개선하는 작업을 대다수 기업이 지원하고 있습니다. 현재의 무선 업데이트가 편리함을 높여준 것은 맞지만, 이 과정이 전부 효율화되고 최적화되었느냐라는 질문에는 아니라는 답을 할 수 밖에 없을 것 같아요.

 

먼저, 이전에 차량을 설계할 당시 고려되지 않았던 제어기 등이 추가됨에 따라 복잡성이 높아지는 문제가 발생하고 있습니다. 예를 들어 현대자동차의 경우에도 차량 내 통합 제어를 위한 CCU(Central Communication Unit)을 추가하며 업데이트가 진행되는 등 신규 기능의 적용을 위해 새로운 제어기가 등장하는 경우가 많습니다. 특히 차량을 완전 새롭게 설계하는 것이 아닌 상품성 개선 등의 이유로 해당 부품을 적용하는 경우 이런 복잡성이 사전 고려되지 않았을 것이기 때문에 이런 부분에서 최적화가 어렵다는 문제점이 생기게 됩니다.

 

둘째, 자동차 내 통신 방식 때문이에요. 일반적으로 차량 내에서는 CAN(Controller Area Network) 방식이 주로 활용됩니다. 이는 CAN 통신이 상대적으로 느린 속도에도 불구하고 높은 신뢰성을 보이기 때문에, 응답성과 안전이 중요한 자동차에 주로 활용되는 것이죠. 물론 속도 및 메시지 길이에 있어 부족한 부분이 있기에 이를 개선한 CAN-FD, High-CAN, Low-CAN 등이 개발되고 있지만, 버스 토포롤지 구조로 인해 기능 업데이트 시 다수 ECU(Electronic  Controller Unit, 개별 제어기)의 업데이트가 함께 진행되야 하는 문제점이 있습니다. 개별 차량의 기능이 다수 제어기와 연관되어 있다는 점을 고려하면 이런 부분이 SDV의 업데이트 시간 지연 및 협업 시 기능 구현 불편에 영향을 끼친다고 하죠.

 

결국 이를 위해 차량은 소프트웨어 변경 구조가 용이한 형태로 다시 설계되어야 한다는 것이 SDV의 요지입니다. 전문적인 용어로는 이를 SOA(Service Oriented Architecture)이라 명명하는데요. SOA를 위해서는 기존 출시된 차량의 구조 및 기능을 재구성해야 하는 과정이 필요합니다. 예를 들어 차량의 전방충돌방지에 전방카메라, 브레이크, 레이더 센서 등과 레이더센서 제어 ECU 등이 활용될텐데, 이런 부분을 개별 제어하는 것이 아닌 통합으로 묶어서 업데이트 해야 한다는 것이죠. 해당 구조를 활용하면 향후 소프트웨어의 변경/추가/삭제 과정에 있어 유연성을 확보할 수 있는만큼 많은 비용과 시간이 들더라도 SDV로 나아가기 위해서는 이런 고된 작업이 선행되어야할 필요성이 있습니다.

 

 

반응형

 

 

 

 

2. SDV 구성을 위한 기초 인프라 요소들

 

 

SDV를 위해서는 기초 인프라가 선행되어야 합니다. 차량의 내/외부를 가리지 않고 말이죠. 위 주제에서는 SDV로 나아가기 위해서는 차량을 기능별로 다시 분해하고 재설계할 필요가 있다 말했습니다. 이런 접근법은 현재 자동차에서 조날 아키텍처(Zonal Architecture)라 불리는데요. 자동차 반도체로 유명한 기업인 NXP는 공식 홈페이지에서 SDV로 나아가기 위해 필요한 인프라 요소를 다음과 같이 정리하고 있었습니다.

 

먼저 차량 내 컴퓨터와 네트워크 구조입니다. 자동차의 안전평가 기준인 ASIL-D를 만족하면서도 실시간으로 네트워크 통신을 만족시킬 수 있는 컴퓨터의 필요성을 언급했어요. 이를 조금 더 풀어 설명하면, 자율주행과 연관지을 수 있을 것 같은데요. 미래 SDV는 자율주행과 같이 실시간성이 필요한 상황에 더욱 자주 접할 것이기에, 정보를 빠르게 연산하면서도 오류에 강인함을 가진 PC가 필요하다는 의미로 받아들이시면 될 것 같습니다. 그리고 이 과정에서 차량 내/외부 통신에 활용되는 CAN, LIN, FlexRay, Ethernet과 같은 다양한 방식의 강건화 역시 함께 진행되어야 한다는 것이죠.

 

실제 차량 내 제어와 기록을 위한 장치 역시 필요하다고 합니다. 영역 컨트롤러(Zonal Controller, 조날 컨트롤러)는 특정 기능으로 분류된 기능 내를 제어하는 영역으로 센서 및 구동부와 직접 상호작용하는 부분인데요. 이 역시 조금 쉽게 풀어 말하면 고성능컴퓨터가 모든 것을 제어하기는 벅차기 때문에 각 세부 영역에 적합한 통식 방식과 안전성을 갖춘 Sub PC를 구성한다고 이해해주시면 될 것 같습니다. 데이터 로거(Data Logger)는 고객의 맞춤형 상품 제공 및 안전성 확보를 위한 기초 자원인 데이터를 확보하기 위해서, 함께 구성되어야 한다고 NXP는 주장했습니다.

 

마지막으로 차량이 내-외부와 통신하기 위한 장치들을 말할 수 있어요. 커넥티비티 도메인 컨트롤러(Connectivity Domain Controller)는 외부의 편의 기능 및 핸드폰 등이 차량에 접속/제어할 수 있도록 이를 제어하는 역할을 수행한다는 것을 알 수 있었습니다. 그리고 OTA는 FOTA(Firmware Over-the-Air) 수준으로 구성되어 개별 펌웨어에 접근, ECU를 업데이트 해야 한다고 하죠. 마지막으로 차량 내/외부에 실시간 기능을 위한 주파수 제어 및 네트워크 관리 등을 위한 서비스 지향적 게이트웨이가 구성되어야 한다는 내용을 찾을 수 있었습니다. 즉 차량의 SDV 전환을 위해서는 내부 제어기 계층 형태의 변경 및 외부와의 통신 과정 방식, 그리고 전 과정에서의 안전 등이 전반적으로 고려되어야 한다고 요약할 수 있습니다.

 

 

반응형

 

 

 

 

3.  SDV의 단계는 어떻게 구분할까?

 

 

SDV 단계는 어떻게 구분할까요? 많은 평가 기준이 있지만, 자동차산업 전문 리서치 기업인 SDB automotive가 제시한 기준을 참고하고자 합니다. SDB에서는 SDV로 나아가는 길에 대해 Vehicle 1.0에서 Vehicle 4.0까지 나누면서 단계별 필요 요소를 위 그림과 같이 제시했습니다. 차량의 구조(E/E 아키택처), U.X, 업데이트 가능 여부, 커넥티비티 연동 범위 및 소프트웨어 아키택처 구조라는 5가지 기능과 그 수준에 대해 평가 기준을 제시하며, SDV로 나아가기 위해서 어떤 요소들이 확충되어야 하는가에 대해 언급한 것을 찾아볼 수 있었습니다. 해당 기준이 무료 레포트에도 포함되어 있으나, 세부 평가 항목은 결국 유료 레포트를 구매해야 하는만큼, 이에 대한 제 견해를 포함해 포스팅 작성하는 점 양해 부탁드립니다.

 

Vehicle 1.0은 Functional, 즉 기능 집중형 차량이에요. 달리고 멈추고 방향을 바꾸는 차량의 동작에 집중한다는 것이죠. 이 단계에서는 기존과 같이 다중 CAN 네트워크로 차량이 구성되며 인포테인먼트는 최초 설계 환경 그대로 고정됩니다. 당연히 차량의 업데이트는 꿈도 꿀 수 없는 일이고, 비상 시 연락(e-Call)이 제공된다면 감지덕지 한 그런 단계입니다. 소프트웨어는 강결합 구조 혹은 강결합 시스템으로 구성되어 여러 프로세스가 하나의 메모리를 함께 사용하는 방식으로 동작하는 것이 주요 특징입니다.

 

Vehicle 2.0은 디지털화가 적용되는 단계에요. 이전 단계 대비 기능 별 주파수가 제공된다는 특징이 있다고 언급되었는데요. 이는 차량에 활용되는 CAN뿐만 아니라 다른 대역인 Flexray, Ethernet 등의 다른 방식이 적용되었다는 의미로 해석하면 될 것 같습니다. 스마트폰 연결(Phone Protection)이 해당 단계에서 활용되는데 이는 우리에게 익숙한 안드로이드 오토 혹은 애플 카플레이가 활용 가능하다는 것을 의미합니다. 차량의 업데이트는 핸드폰 활용 업데이트라는 모호한 말이 언급되었는데, 이는 아무래도 핸드폰에 업데이트를 다운로드 한 이후 블루투스 혹은 유선 방식을 활용해 기능을 업데이트 하는 단계를 뜻하는 것이 아닐까라고 추측되네요. 해당 단계에서는 4G 방식을 지원하기 때문에 본격적으로 차량과 다른 요소가 상호작용할 수 있으며, 콕핏 내 일부 App이 지원되지만 여전히 강결합 시스템에 포함되는 형태로 구성됩니다.

 

Vehicle 3.0은 업데이트가 가능한 차량입니다. 이전 단계와 대비했을 때 차량을 기능별로 나눠 도메인 별로 이를 분화시켰다는 차이점이 있습니다. 또한 인포테인먼트에 개인화 요소를 다수 도입, 사용자의 기호에 맞춘 형태로 변경이 가능해지며 개별 ECU에 대한 업데이트로 성능 개선이 가능해지는 확장성을 얻을 수 있습니다. 그리고 커넥티드 앱, 카페이 등과 같은 다중 채널과 연동될 수 있는 방향으로 차량이 개선된다는 특징이 있습니다.

 

SDV에 해당하는 Vehicle 4.0은 소프트웨어가 핵심이 되는 차량입니다. 영역 기반으로 차량의 전자 아키택처가 완전히 분기되었고, 차량 자체의 소프트웨어 업데이트가 가능해진 단계입니다. 이 단계에서는 5G 통신이 적용되어 클라우드 연결과 같은 기능이 가능해지는 단계입니다. 이외에도 차량 자체가 소프트웨어 기반 아키택처로 구성되기 때문에 기능의 업데이트 및 변경이 용이해지는 유연성을 갖출 수 있다는 장점을 얻을 수 있습니다. 기준을 살펴볼 때 상대적으로 빠른 실현이 가능하도록 기능 수준을 적절히 분기한 것 같은데, 현재 자동차의 지원서비스를 고려해본다면 Vehicle 3.5 정도의 수준에 도달하지 않았나라는 개인적인 의견 역시 함께 전달드립니다.

 

 

반응형

 

 

 

 

이번 포스팅에서는 SDV의 도입 시 필요한 요소들과 인프라,

그리고 SDV로 전환 단계를 판별 가능한 기준들에 대해 알아보았습니다.

 

다음 포스팅에서는 SDV의 전환에 대한 차량의 변화점 중 핵심인

E&E 아키택처 구조에 대해 더 자세히 파악해보도록 하겠습니다.

 

긴 글 읽어주셔서 감사드립니다!