전기 및 전자 자동차 아키텍처 트렌드

[정민섭]

아래 글은 https://ubuntu.com/blog/electrical-and-electronic-vehicle-architecture-trends-an-exploration의 글을 번역한 내용임

전기 및 전자 자동차 아키텍처 트렌드: 탐색
베르트랑 보이시우
2022년 8월 8일

차량 복잡성 증가

차량은 매일 복잡해지고 있다. 고객은 안전하고, 자율적이며, 연결되고, 전기화되고, 공유된 차량을 기대하며, 이러한 기능은 소프트웨어를 통해 달성된다. 하드웨어에서 소프트웨어로 초점을 맞춘 변화는 분명하지만, 소프트웨어 정의 차량의 등장은 최적화된 전기/전자(E/E) 차량 아키텍처에 크게 의존할 것이다.
이러한 변화하는 패러다임에 맞춰 큰 하드웨어 변화가 일어나야 합니다. 이 포스트에서는 E/E 아키텍처의 동향과 진화를 연구하고 소프트웨어 정의 접근법에 가장 적합한 아키텍처를 식별할 것입니다.

기본적이고 별개의 것에서부터 복잡하고 통합된 것까지

1세대 E/E 아키텍처는 취급할 수 있는 전자 제어 장치(ECU)가 많지 않았다. 쉽게 말해, ECU는 임베디드 컴퓨팅 시스템이다. 실제로 당시 차량은 ICE(Internal Combustion Engine)로 구동되었다. 라디오 카세트 시스템(행운의 경우 CD 판독 기능이 있음), 파워트레인, 섀시 관련 ECU가 있었으며, ECU의 수는 제한되어 있었고 모두 서로 격리되어 있었다. 각 ECU는 하나의 특정 기능을 가지고 있었으며, 그 기능은 간단하고 기본적이었다.

새로운 기능과 새로운 안전 제약 조건이 도입되면서 차량에는 ABS(Anti-lock Braking System), ESP(Electronic Stability Control), ACC(Adaptive Cruise Control) 등의 ECU가 많이 추가되었습니다. 등 차량 전반에 전자시스템이 보급되면서 특정 ECU 간 인터페이스의 필요성이 대두되기 시작했고, 동시에 인포테인먼트 요구사항도 강력하게 증가하기 시작했으며, GNSS(Global Navigation Satellite System) 데이터를 받아야 했다. ADAS(Advanced Driver-Assistance Systems) 기능 등을 표시한다. 이는 시스템 간 통신 및 제어를 갖는다는 것을 의미한다.

ECU가 서로 통신하기 시작하면서 차량 내부에 특정 네트워크가 생성되어 특정 ECU 세트가 효율적으로 통신할 수 있게 되었다. 이는 훗날 "차량 도메인"으로 불리게 될 기반이 된다. 예를 들어 인포테인먼트, 파워트레인, 섀시, 바디, ADAS 등이 있다.

현재 아키텍처 및 중앙 게이트웨이 사용

Central Gateway Architecture illustration

오늘날, 차량은 차량 전체의 통신을 보호하기 위해 여러 ECU로부터 데이터를 수신하는 중앙 게이트웨이를 사용한다. 그러면 다른 ECU에서 데이터를 가로채거나 액세스할 수 있어 상호 기능적인 작동이 가능하다. 이 접근법은 상세한 사양에 의존한다: 하나의 ECU는 다른 ECU로부터 올바른 정보를 "가져오기"해야 한다.

이 방식의 결함 중 하나는 차량이 여전히 여러 개의 ECU를 처리하는 여러 개의 네트워크를 지원해야 한다는 것이다. 그렇게 들리지 않을 수도 있지만 배선만 생각해도 된다. 현대의 차량에는 최소 50kg의 전선이 필요하다. 모든 전선을 일렬로 놓으면, 최대 4km까지 늘어난다! 이는 차량의 비용과 총 차량 중량에 모두 큰 피해를 준다. 또한 EV는 경량화를 목표로 하고 있기 때문에, 차량에 와이어, 하네스, 커넥터가 적을수록 더 좋다. 비용 절감뿐만 아니라, 더 적은 재료가 필요할 수 있으며, 이는 환경에 더 좋습니다.

OEM이 서로 다른 기능에 유사한 하드웨어를 사용할 수 있도록 하는 보다 모듈화된 접근법은 설계 프로세스를 단순화할 것이다. 또한 필요한 유지보수를 줄이고 BOM(Bill Of Materials)을 낮출 수 있다. 이 접근법은 어떻게 보일까? 이어지는 섹션에서, OEM이 보다 최적화된 E/E 아키텍처를 개발하는 데 도움이 될 수 있는 솔루션을 모색한다.

도메인 컨트롤러(DC)를 이용한 중간 진화

한 가지 솔루션은 이전에 상세한 중앙 게이트웨이를 유지하되 도메인의 네트워크 처리, 계산 및 특정 ECU에 대한 지침 적응과 같은 특정 기능으로부터 중앙 게이트웨이를 완화하기 위해 전용 도메인 컨트롤러를 추가하는 것으로 구성된다.

이는 도메인별 ECU와 중앙 게이트웨이 사이에 추상화 계층을 추가하기 때문에 아키텍처를 단순화하는 첫 번째 단계이다. 이러한 도메인 기능의 통합은 공용화된 소프트웨어와 이 새로운 추상화 계층을 활용하여 비용을 절감할 수 있다.

이 중간 진화는 올해 도입된 새로운 차량 모델에서 나타나고 있다. 이 단계는 올바른 방향으로 필요한 전환이지만 소프트웨어 정의 차량을 지원하기에는 충분하지 않다.

Domain Controller Architecture illustration

위 그래프에서 보듯이 센서와 게이트웨이 사이에는 여전히 너무 많은 하드웨어 계층이 존재한다. 하드웨어 계층이 많을수록 다중 시스템 통합은 더 어려워질 것이다. 하드웨어 통합 외에도 다른 방식으로 공급업체에서 제공되는 소프트웨어가 다르다. 기술, 개념(등)은 서로 대화를 해야 합니다. 목표는 이러한 계층을 최대로 줄이고 특정 영역으로 끝내야 합니다. 따라서 구역 아키텍처입니다.

목표 설정: 구역 아키텍처

대상이 최소 계층 수를 갖는다면 리소스가 공유된다는 것을 의미합니다. 일부 리소스는 차량 전체에서 액세스할 수 있고, 다른 리소스는 오버헤드가 가장 적은 구역별로 액세스할 수 있습니다. 이는 소프트웨어가 확장 가능하고 동적이어야 한다는 것을 의미합니다. 복잡한 것처럼 들리지만, 클라우드 네이티브 아키텍처는 그럭저럭 해냈습니다.

실제로 클라우드 네이티브 애플리케이션은 리소스를 동적으로 할당하고, 완전히 컨테이너화(의존성 관리 및 보안을 단순화)하고, 완전히 자동화할 수 있다. 이는 애플리케이션이 자동으로 이전에 안정된 상태로 돌아갈 수 있기 때문에 복원력을 높일 수 있다. 빌딩에서 생산으로 코드를 효율적으로 이동하는 효율적이고 지속적인 통합 및 연속 전달(CI/CD) 프로세스가 가능하다.

구역 접근 방식이 어디서 오는지 파악하기 위해서는 클라우드 네이티브 접근법을 이해하는 것이 중요하다.

지난 몇 년 동안 컨테이너와 마이크로서비스는 기업이 서비스를 개발하고 배치하는 방식을 완전히 바꾸어 놓았다. 컨테이너 서비스는 격리된 애플리케이션을 보장하고 환경에 관계없이 불가지론적 서비스를 안정적으로 운영할 수 있도록 한다. 종속성이 포함됩니다. 가상 시스템(VM)에 비해 컨테이너는 리소스가 적게 필요하고 오케스트레이터를 사용하여 더 쉽게 배포됩니다.

안전과 보안이 필수 요구사항인 자동차 환경에서 격리된 서비스를 쉽게 구현할 수 있도록 완벽하게 적합합니다. 아래 그래프는 클라우드 네이티브 아키텍처가 어떻게 생겼는지를 간략하게 보여 줍니다. 단순화를 위해, 하이퍼바이저와 오케스트레이터를 설명하지 않았습니다.

Simplified Basic Cloud Native Architecture illustration

분산 접근 방식

복잡한 컴퓨팅 기능과 컨테이너화된 서비스를 염두에 두고, 다음 E/E 아키텍처 진화는 중앙 서버와 호환되어야 한다. 차량 내 서버는 종종 자동차 업계에서 “HPC” (고성능 컴퓨팅) 서버로 언급되지만, 클라우드 기반의 HPC보다 성능이 떨어지고 기술적 관점에서도 매우 다르다. 독자들에게 혼동을 주지 않기 위해 "차량용 서버"라고 칭할 것이다.

차량 서버는 도메인 컨트롤러 기반 E/E 아키텍처로 정의된 추상화 계층의 이점을 누리며 이를 대체하는 경향이 있다. 소프트웨어 기능을 실행하기 때문에 이러한 전환은 특정 기간 동안 점진적으로 발생할 것이다. 적어도 2-3세대 이상.

차량 서버가 도메인 컨트롤러와 공존하는 단계를 흔히 분산 영역 아키텍처라고 하는데, 도메인 컨트롤러 기능이 서버로 이동함에 따라 도메인 컨트롤러의 하드웨어가 사라져 배선과 같은 자재에서 비용 절감 효과가 발생한다.

Distributed Vehicle Server Architecture illustration

통합 접근 방식

다음 단계와 마지막 단계를 통합 영역 아키텍처 접근법이라고 합니다. 이 기능이 완료되면 차량 서버에서 완전히 처리되므로 물리적 도메인 컨트롤러가 필요하지 않습니다.

이 방식의 주요 장점 중 하나는 소프트웨어 기능을 대부분 서버가 담당한다는 것이다. 이는 OEM이 하드웨어 구성 수를 줄일 수 있다는 것을 의미한다. 게다가, 모든 차량 모델이 유사한 기능에 대해 동일한 소프트웨어 패키지에 의존할 수 있기 때문에 OEM의 제품 범위에 걸쳐 동일한 소프트웨어를 사용할 수 있다.

이를 염두에 두고 엔지니어링 팀은 최적화된 소프트웨어 개발 주기에 집중할 수 있다. 시리얼 라이프의 소프트웨어는 최신 보안 업데이트 및 기능의 이점을 누릴 수 있다. 이전 차량 모델의 소프트웨어를 유지하기 위해 전용 개발 팀을 유지할 필요가 없다. 이는 개발 투자의 관점에서 이익을 얻을 뿐만 아니라, 소프트웨어 자체의 품질이 개선되어야 한다.

Consolidated Vehicle Server Architecture illustration

최종 하드웨어 최적화: 모든 것을 지배하는 하나의 고리

우리는 이 작품에서 배선을 많이 언급했지만, 어떻게 이 중앙 컴퓨터가 다른 ECU에 물리적으로 연결될 수 있을까? 많은 해결책이 존재하지만, 그것이 메시든, 별이든, 트리 접근이든, 그것들은 모두 많은 전선을 필요로 한다. 어떻게 우리가 이것을 더 최적화할 수 있을까?

ECU, 센서 및 엣지 장치는 모두 구역별로 차량 전체에 물리적으로 분산되어 있으며, 서버가 구역별 게이트웨이에 최소한의 배선으로 연결할 수 있도록 하고자 한다.

메쉬 접근 방식(대부분의 구역이 상호 연결되어 있음)은 이중화를 허용하고 물리적 연결을 보장하지만 높은 배선 비용을 초래한다. 스펙트럼의 다른 측면에서는 링 접근이 상호 연결을 가능한 최소한으로 제한한다. 배선 비용이 가장 저렴하다. 또한 링 방식을 사용하면 차량 서버가 모든 구역과 직접 물리적 연결이 없어도 통신할 수 있다.

스위트 스팟은 아마도 링 기반일 것이지만 안전 중요 구역에 대한 매우 구체적인 추가 연결을 통해 중복성을 더할 것이다. 또한 모든 데이터에 대해 충분한 대역폭을 보장하기 위해 전체 네트워크가 이더넷 기반이 될 것으로 기대한다.

Ring-shaped Consolidated Vehicle Server Architecture illustration

결론

차량 E/E 아키텍처는 확장되지 않고 기능 및 업데이트가 지속적으로 추가되는 레거시 방식으로 인해 너무 복잡해졌다. E/E 아키텍처는 소프트웨어 측면에서 추상화 계층을 처리할 수 있도록 진화해야 한다.

이러한 닭과 달걀 유형의 문제에서 가장 좋은 방법은 하드웨어와 소프트웨어 모두에서 전환을 적용하는 것이다. OEM과 Tier-1이 직면하게 될 첫 번째 문제는 시스템 간 호환성이다. 대부분의 기업이 자체 개발한 소프트웨어를 사용하기 때문에 이 문제를 해결하는 가장 좋은 해결책은 오픈 소스 소프트웨어입니다. 투명성, 협업 및 동료평가를 통해 올바른 소프트웨어를 유지, 업데이트할 수 있습니다. 이 접근법은 해당 소프트웨어를 개발, 지원 및 구축하는 기업들에게 상당한 가치를 창출할 수 있다. 초과 근무는 산업 표준이 될 가능성이 있다.