Virtual ECU란

자동차 SW 개발 단계에서 Virtual ECU란 크게 아래 두 가지 목적에 의해서 적용된다고 볼 수 있다. 

 

• 빠른 초도품 개발 및 HW 비의존적인 개발환경을 구축하여 조기에 로직 검증을 할 수 있다. 
• 플랜트 모델을 활용하여 SIL Test 환경을 구축, 사전에 T/C 검증 및 Calibration을 수행할 수 있다. 

 

위 두 가지 관점을 들여다보면, 첫번째 문장은 개발 관점의 이점이고 두번째 문장은 검증 관점의 이점이다.

 

구체적으로 그렇다면 Virtual ECU는 어떻게 구현하는 것일까

여기서부터 언급하는 내용은 인포테인먼트 시스템이 아닌 전력제어, 구동제어, 제동, 조향 제어와 같은 영역에 한정해서 이야기하도록 한다. 

일반적으로 근 10년간 트랜드를 살펴보면, 대부분은 차량 제어기는 AUTOSAR라고 불리는 표준에 따라 SW를 개발해 왔다. 

AUTOSAR Layer 중에서 HW와 민감하게 엮여있는 MCAL 영역과 CDD영역 그리고 OS 영역과 관련하여 PC 환경에서 동작할 수 있도록 보통은 X86 환경에 맞게 코드 및 빌드 환경을 수정하는 것을 vECU 개발의 1단계라고 볼 수 있다. 

 

이렇게 특정 영역을 Window나 Linux 환경에서 빌드 및 Run 할 수 있게 코드를 수정하게 되면, 우리는 HW나 디버거 툴 없이 곧바로 PC 상에 해당 SW를 띄워서 여러가지 기능 검증 테스트를 할 수 있는 가상 제어기를 가지게 되는 것이다. 

이를 지원하는 회사는 여러군데 있다. 

ETAS, Synopsys, DSPACE등 다양한 automotive tool 업체들이 이를 지원하고 있다.

vECU에도 단계가 여러가지가 있지만, 이 이야기는 다른 포스팅에서 하기로 하고 여기서는 전체적인 흐름만 이야기하도록하자.

 

이렇게 개발된 가상제어기는 어디에 활요하면 좋을까? 

물론 단순한 기능검증을 HW가 제작되기 전에 빠르게 PC 상에서 확인해보는 것 자체도 이점이 있을 수 있다. 

하지만 좀 더 확장해서 생각해본다면, 예를 들어 우리가 제어하는 제어 대상물에 대한 플랜트 모델이 Simulink나 DSPACE같은 모델링 툴로 가지고 있다면 이를 연결해볼 수도 있는 것이다. 

보통 이렇게 서로 다른 simulation tool을 연결할 때는 fmi(functional mock-up interface)라고 불리는 표준 인터페이스를 이용하여 연결한다. 

fmi는 bosch가 이러한 서로 다른 툴을 연결하여 테스트하기 위한 목적으로 만든 프로토콜이다. 

자동차 sw 툴의 대부분은 이러한 fmi 인터페이스를 지원하므로 플랜트모델과 vECU를 fmi를 통해 연결할 수 있다. 

게다가 보통 검증에 사용하는 검증 툴로는 Vector사의 vTEST studio와 같은 툴을 사용하는데 이 또한 fmi를 지원하므로 기존에 T / C를 가지고 있다면 이것 까지 연결해서 PC 상에서 검증 환경을 구성할 수도 있다. 

 

여기까지가 이상적으로 구현된다면 그 다음에는 CI/CD에 이 와 같은 검증 프로세스를 붙일 수도 있다. 

기본적으로 Synopsys의 vECU tool인 silver는 jenkins에 plugin을 지원한다. 

아주 아주 이상적으로 구현이 된다면, 개발자들이 commit을 하고 maintainer에 의해 merge되는 순간에 자동으로 vECU를 빌드하고 해당 vECU와 기존의 플랜트모델을 결합하고, 테스트 툴에 의해 T/C까지 수행해서 그 결과를 리포트로 받아볼 수도 있다. 

 

물론 위의 내용은 아주 이상적인 상황이고, 이를 구현하기 위해서는 많은 허들이 있다.

다만 이를 극복했을 때 이점을 살펴보면, 기존에 HW 제어기가 나와야만 개발 및 디버깅이 가능했던 시간을 획기적으로 단축할 수 있고, HILS 셋업 및 장비 비용과 테스트 수행 시간등을 SIL 자동화 구축을 통해 아주 극적으로 단축할 수도 있다.