Virtual ECU (가상 ECU)

https://yocto.tistory.com/309 에서 "SDV 개발에서 HW/SW Decoupling" 주제로 간단히 글을 써봤다. 핵심은 소프트웨어를 하드웨어와 분리해서 개발을 하는 환경을 구현해서 빠르게 개발을 하면서 테스팅 하는 것이다.

배경

점점 차량용 소프트웨어의 복잡도와 크기가 커져가면서 통합과 테스트가 점점 더 어려워지고 있다. 더불어 많은 ECU가 작은 개수의 고성능 ECU 통합되면서 하드웨어의 Cost가 비싸져서 많은 하드웨어를 가지고 개발하기도 큰 부담이 있다. 초기 보드 Bringup의 시간도 많이 들어 빠른 릴리스와 개발을 요구하는 요즘과 같은 경쟁 시대에 그동안 기능 개발을 놓기도 어려운 상황이다.

 

그렇기 때문에 Virtual ECU (vECU)가 점점 각광을 받고 있고 대부분 제대로된 vECU환경을 갖추기 위해 노력하고 있다. Virtual ECU(가상 ECU)는 실제 차량의 전자 제어 장치(ECU)를 소프트웨어 환경에서 시뮬레이션하는 기술이다. 이는 물리적인 하드웨어 없이도 ECU의 기능을 테스트하고 검증할 수 있게 해준다. 가상 ECU는 다음과 같은 장점을 제공한다.

장점

• 비용 절감: 물리적인 하드웨어 없이도 테스트가 가능하므로 비용을 절감할 수 있다.
• 시간 절약: 개발 초기 단계에서부터 ECU의 기능을 검증할 수 있어 개발 시간을 단축할 수 있다.
• 유연성: 다양한 시나리오와 조건에서 ECU를 테스트할 수 있어 더 다양한 상황을 시뮬레이션할 수 있다.
• 안전성: 실제 차량을 사용하지 않으므로 테스트 중 발생할 수 있는 위험을 줄일 수 있다.

물론, Virtual ECU(가상 ECU)에도 단점과 구현하기 어려운 점이 있다. 주요 단점과 어려운 점은 다음과 같다.

단점

• 정확성 문제: 가상 환경에서의 시뮬레이션은 실제 하드웨어와 완전히 동일하지 않을 수 있다. 이는 테스트 결과의 정확성에 영향을 미칠 수 있다.
• 복잡성 증가: 가상 ECU를 구현하고 유지하는 데 필요한 소프트웨어와 인프라가 복잡할 수 있다.
• 제한된 하드웨어 상호작용: 실제 하드웨어와의 상호작용을 완전히 재현하기 어려울 수 있다. 이는 특정 테스트 시나리오에서 문제가 될 수 있다.
• 성능 제한: 가상 환경에서의 시뮬레이션은 실제 하드웨어보다 느릴 수 있으며, 이는 실시간 테스트에 영향을 미칠 수 있다.

구현하기 어려운 점

• 정밀한 모델링: ECU의 모든 기능과 상호작용을 정확하게 모델링하는 것은 매우 어렵고 시간이 많이 소요될 수 있다.
• 복잡한 소프트웨어 통합: 다양한 소프트웨어 툴과의 통합이 필요하며, 이는 복잡한 작업이 될 수 있다.
• 데이터 관리: 대규모 시뮬레이션 데이터를 관리하고 분석하는 것은 도전적인 과제이다.
• 실시간 성능: 가상 ECU가 실제 ECU와 동일한 실시간 성능을 제공하도록 하는 것은 어려운 일이다.
• 테스트 환경 구축: 다양한 테스트 시나리오를 지원하는 가상 테스트 환경을 구축하는 데 많은 노력과 자원이 필요하다.

이러한 단점과 어려운 점에도 불구하고, 가상 ECU는 자동차 산업에서 중요한 도구로 자리 잡고 있으며, 지속적인 기술 발전을 통해 이러한 문제들을 극복하고 있다.

가상 ECU 레벨

출처: https://semiengineering.com/going-virtual-in-automotive-electronics-development/

 

가상 ECU는 다음과 같은 레벨을 가지고 있고 크게 Host 컴파일러 환경에서 구현 가능한 레벨 1,2,3과 Target 컴파일러와 동일한 환경에서 구현하는 레벨 4가 있다. 레벨 4를 추가하지만 기술적 난이도와 그만큼 개발/관리 비용이 요구되며 각 제품/회사의 전략에 맞춰 테스트 상황에 맞게 적절히 조합해서 사용하는 것이 좋다.

• 레벨 0: 알고리즘 모델의 설계에 중점을 두며, 일반적으로 C++ 코드로 작성되거나 MathWorks MATLAB 환경을 사용한다. 코드는 호스트에서 호스트 컴파일된 코드 또는 인터프리터를 통해 시뮬레이션된다.
• 레벨 1: 생산 애플리케이션 또는 그 모듈의 테스트에 중점을 둔다. 미들웨어 소프트웨어 계층은 기본 런타임 및 I/O 시뮬레이션 코드로 대체된다. 애플리케이션 또는 모듈은 호스트 실행 파일로 컴파일된다.
• 레벨 2: 전체 애플리케이션으로 범위를 확장하고 애플리케이션과 미들웨어 간의 인터페이스를 도입한다. 전체 애플리케이션의 생산 코드를 사용하지만, 미들웨어는 시뮬레이션 등가물로 대체된다.
• 레벨 3은 스택의 하단에 더 많은 생산 소프트웨어를 추가한다. 생산 미들웨어가 포함되며, 디바이스 드라이버는 시뮬레이션 등가물로 대체된다. 모든 하드웨어 독립 소프트웨어 계층을 검증할 수 있다.
• 레벨 4b: 애플리케이션, 미들웨어 및 OS의 모든 소프트웨어 계층에 대해 생산 코드를 사용한다. 시뮬레이션 대체가 필요하지 않다. 물리적 ECU에 사용된 것과 동일한 컴파일러가 동일한 바이너리 타겟 실행 파일을 생성한다.
• 레벨 4a: Synopsys에서 도입한 독특한 접근 방식이다. 이는 레벨 4b와 유사하지만, 전체 스택에서 선택된 소프트웨어 기능이 호스트에서 우회되어 실행된다. 이는 vECU 시뮬레이션 속도를 높이고 필요한 모델 수를 줄인다.
• 레벨 5: 물리적 ECU가 타겟 컴파일된 코드로 전체 생산 소프트웨어 스택을 실행하는 전통적인 벤치 접근 방식이다. 이는 실제 차량이 현장에서 작동하는 방식이기도 하다.

제품 / 솔루션

많은 공급자 (Supplier)들이 vECU를 개발하여 OEM등에 커스터마이즈를 하면서 판매하려고 노력하고 있다. 이전에 https://yocto.tistory.com/306 에서 이야기한 QNX Cabin도 그중에 하나이고, dSPACE의 VEOS, 퀄컴과 같은 SoC 벤더들의 솔루션, QEMU로 자체 구현 등이 있다. 안드로이드의 경우 Cuttlefish를 제공하여 쉽게 개발을 할 수 있는 환경도 만들어준다.

 

앞으로 소프트웨어는 단일 OS에서 돌아가지 않고 고성능 SoC를 가진 HPC (High Performance Computing)에서 하이퍼바이저 위에 여러개의 VM으로 OS가 돌아갈 확률이 굉장히 높다. 그렇기에 하이퍼바이저도 시뮬레이션을 해야하고 이로써 복잡도는 더 높아진다. 또한 서로 다른 ECU간의 통신도 해야하고, POSIX OS와 Autosar Classic이 올라간 MCU 등 이기종 간의 VM과도 통신을 해야한다.

 

각 ECU, VM, OS에서 Simulator/Emulator를 만드는 것도 중요하지만 궁극적으로 이를 통합하는 부분도 상당히 큰 어려움과 부분을 차지하게 될 것이다.

정리 / 인사이트

vECU의 장점은 개발자 Local PC, Cloud등 어느 환경에서나 다 동작하는 것이다. 단일 OS에서 개발하는 부분은 개발자의 Local PC에서 할 수 있고 작게 컴포넌트 테스트, 일부 통합 테스트까지도 할 수 있을 것으로 기대한다. 하지만 전체 통합 테스트 환경을 Local PC에 구축하는것은 복잡한 설정이 필요할 것으로 생각된다. 그래서 Cloud에 미리 설정해놓고 테스트 할 수 있는 환경을 제공하지 않을까 조심스럽게 생각한다.

 

그렇게 되면 Cloud의 사용량이 늘어나고 결국 Google Cloud, MS Azure, AWS 등의 Cloud 업체은 엄청난 수익을 내게 될 것이다. 당연히 CI/CD 환경도 그곳에서 구축할 확률이 놓다. 그래서 이런 클라우드 업체에서는 vECU 환경 설정을 하는데 적극 지원을 하고 있는 상황이다.

 

vECU는 여전히 초기 단계인것 같다. 하지만 정말 중요하고 이것이 앞으로의 개발 방향이라고 생각한다. 동시에 실제 개발 환경에 쓰이도록, 이슈가 실제 하드웨어에서 나오는 것과 비슷하게 나오도록 만드는 것은 여전히 어려운 일이다. 잘 만들어서 개발자와 통합하는 부서에 신뢰를 얻는게 중요하다.

SDV 개발에서 HW/SW Decoupling