Astemo는 ECU 및 차량용 네트워크 개발, 테스트, 분석 툴인 CANoe의 헤드리스 버전인 CANoe4SW Server Edition을 통해 vVIRTUALtarget으로 생성한 가상 ECU를 대상으로 하는 CT 환경을 구축했다. 테스트에 따라 효율을 약 30% 높일 수 있다. 또, 벡터의 SIL Kit를 사용해 서드파티 ECU 가상화 시뮬레이션 도구를 CANoe와 연계한 환경도 평가할 수 있다.

글 | Vector 





2018년부터 단계적 CI/CT 도입 

소프트웨어 개발 방식은 시대와 함께 변화해 왔다. 2010년대 중반부터 웹 애플리케이션 개발을 중심으로 확산한 CI/CD(Continuous Integration/Continuous Delivery 또는 Deployment)는 소스코드 변경, 통합(빌드), 테스트, 배포/배치로 이뤄진 사이클을 자동으로 빈번하게 순환해 품질과 개발 효율을 높이는 기술로, 통합과 테스트를 자동화한 CI/CT(Continuous Integration/Continuous Testing)와 더불어 자동차 산업에서도 갈수록 널리 활용되고 있다. 일본을 대표적인 공급업체 중 하나인 Astemo는 CI/CT를 단계적으로 도입해왔다.
 Astemo의 파워트레인 ECU의 경우 다음과 같은 단계를 거쳤다.

(1)    2018년~: 벡터의 vVIRTUALtarget을 도입해 AUTOSAR Classic과 호환되는 MICROSAR Classic(BSW 레이어)을 가상화하고, CANoe(Desktop Edition)를 결합해 실제 ECU를 사용하지 않고도 자동으로 빠르게 테스트를 실행할 수 있는 환경 구축(테스트 자동화를 위한 가상화)
(2)    2020년~: 소스코드를 관리하는 GitLab과 데이터저장소를 관리하는 Artifactory를 도입해 구성, 코드 생성, 빌드 등을 일괄적으로 처리할 수 있는 환경 구축(CI 시행)
(3)    2022년~: 커맨드로 제어할 수 있는 벡터의 CANoe4SW Server Edition과 자동화 도구인 Jenkins를 도입해 통합부터 테스트 실행까지 과정을 자동화하고 적용 범위를 확대(CI/CT 실현)

이중 (1)과 (2)는 2021년 11월에 공개한 도입 사례 ‘vVIRTUALtarget을 통한 엔진 ECU 가상화로 BSW 테스트 효율화 실현’에 정리돼 있으니 참조하면 된다[1]. 이번에는 (3)을 중심으로 다뤄본다. 



개발 과제 해결 위한 CI/CT 체계 확립    

Astemo의 SDV 플랫폼 총괄본부 SDV 플랫폼 개발본부는 사내 개발 및 검증 환경 표준화, 자동화 등을 공통으로 담당하고 있다. 해당 본부에서 확립한 기술이나 선택한 도구는 사내 제품 소프트웨어 개발 부문에 적용된다.
SDV 플랫폼 개발본부 소프트웨어 플랫폼 개발부의 스즈키 가이키는 CI/CT 표준화를 추진하는 목적을 다음과 같이 설명했다. 

“소프트웨어 개발은 빌드나 테스트 등 다양한 프로세스로 구성돼 있습니다. CI/CT의 장점은 이런 과정을 사람의 손을 거치지 않고 한 번에 처리할 수 있다는 것입니다. 또한 문제가 발생했을 때 신속하게 되돌릴 수 있어 효율도 높습니다. CI/CT 과정 구축은 이런 취지에서 진행됐습니다.”

선임 관리자인 사토 요시하루는 외부 업체와 공동으로 소프트웨어를 개발할 때 발생하는 문제도 CI/CT를 통해 해결할 수 있다고 말했다. 
“외부 업체가 개발한 소프트웨어와 Astemo가 개발한 소프트웨어를 최종적으로 통합할 때, 서로의 개발 환경이 다르면 통합이 원활히 진행되지 않는 문제가 있었습니다. CI/CT 환경을 구축해 Astemo와 외부 업체가 공통으로 사용할 수 있게 하면 이런 문제를 해결할 수 있을 뿐만 아니라 품질도 높아질 것으로 생각했습니다. 이런 문제는 OEM과 공동으로 소프트웨어를 개발할 때도 발생할 수 있습니다.”

해당 본부가 구축한 CI/CT 환경의 개요는 그림 1과 같다. 구성요소는 다음과 같다.

(1)    GitLab과 같은 구성 관리 도구(개발 프로젝트에 따라 다름)
(2)    ‘CI Runner’, 즉 CI 작업 실행 환경(물리 서버)
(3)    테스트 작업을 자동으로 실행하는 Jenkins
(4)    ‘Test Runner’, 즉 테스트 실행 환경(물리 서버)

CI/CT의 흐름은 다음과 같다.

(a)    개발자가 변경한 소스코드나 작성한 테스트 시나리오를 구성 관리 도구(GitLab 등)의 저장소에 등록
(b)    저장소에 파일을 등록하거나 미리 정한 일정에 맞춰 CI 작업이 실행되면 CI Runner에서 빌드 및 테스트에 필요한 정보를 수집하고 가공
(c)    테스트 케이스와 테스트 대상 소프트웨어를 Test Runner로 전송 후 Jenkins를 통해 CT 작업이 실행되면 Test Runner에서 테스트가 처리
(d)    빌드 및 테스트 결과를 개발자에게 보고

Astemo 담당자와 외부업체 등이 사용할 구성 관리 도구(리포지터리)는 개발 프로젝트별로 준비했다(실제 운영은 각 개발 프로젝트에서 담당).
스즈키는 “CI Runner와 Test Runner 사이에 Jenkins를 끼워 넣은 이유는 구성 관리 도구의 차이에 유연하게 대응하기 위해서입니다. Jenkins를 호출하는 부분까지를 구성 관리 도구별로 작성해 Test Runner 사용 직전에 이런 차이를 흡수하도록 했습니다”라고 말했다.
그림 1에는 CI Runner가 3대, Test Runner가 1대로 나와 있지만 반드시 실제로 그래야 하는 것은 아니다. 프로젝트에 따라서는 파일 전송의 오버헤드를 줄이기 위해 CI Runner와 Test Runner를 동일한 물리 서버에 구축할 수도 있다.



그림 1 | Astemo의 CI/CT 구성, Astemo 



CANoe4SW Server Edition 도입해 CT 환경 구축   

Astemo는 Test Runner 환경에 벡터의 CANoe4SW Server Edition을 도입했다. ECU 및 차량용 네트워크 개발, 테스트, 분석도구로서 다양한 프로젝트에 사용하는 CANoe에는 4가지 버전이 있다. 그중 CANoe4SW Server Edition은 SIL(Software- In-the-Loop)과 CT를 대상으로 해 그래픽 사용자 인터페이스가 없는 솔루션이다(그림 2, 그림 3). 





그림 2 | CANoe 제품 에디션과 CT에 적합한 CANoe4SW Server Edition의 포지셔닝(오른쪽 아래), Vector Japan Inc.


그림 3 | CANoe4SW Server Edition에서 CI/CT의 대략적인 흐름, Vector Japan Inc.



“테스트 자동화와 CI/CT에 대해 Vector Japan Inc.에 문의하던 중 CANoe4SW Server Edition을 소개받아 도입하게 되었습니다.”
사토가 말했다.

일단 일반 버전의 CANoe를 사용해 통신 및 테스트 환경을 구축하고, 이를 대략 완성한 단계에서 사내 내부 서버에 설치한 CANoe4SW Server Edition으로 마이그레이션 작업을 진행하는 방식이다. 

스즈키는 “환경 설정용 YAML 파일 작성 방법이나 테스트에 사용하는 CAPL 파일 기술 변경은 Vector Japan Inc.의 지원을 받아 진행했다”고 말했다. 

또, 테스트 시나리오 작성 시에는 CAN 버스의 신호 사양이 OEM마다 다르므로 OEM에서 제공하는 사양 파일을 사내 도구로 변환해 테스트 시퀀스 작성 도구인 벡터의 vTESTstudio에 파라미터(vparam)를 입력함으로써 사양에 따른 차이에 대응했다.

Astemo는 파워트레인 ECU의 CI/CT에서 벡터의 vVIRTUALtarget을 사용해 MICROSAR classic 환경을 가상화하고, CANoe4SW Server Edition을 CAN 통신의 대향으로 사용해 테스트 자동화를 구현했다. 주요 테스트 대상은 MICROSAR Classic을 구성하는 COM(COMmunication) 모듈, DEM/FIM(Diagnostic Event Manager/Function Inhibition Manager) 모듈, 그리고 DCM(Diagnostic Communication Manager) 모듈이다.
테스트 내용에 따라 다르지만, CI/CT 한 사이클당 시간을 약 30분에서 1시간 정도 단축할 수 있다(그림 4).





그림 4 | 빌드 및 테스트에 대한 수작업 공수(시간)와 CI/CT를 통한 공수 비교 이미지, Astemo 



“테스트 공정 사이에 사람이 해야 하는 작업이 없어져 조작 실수로 인한 휴먼 에러가 줄어드는 등 개발 프로젝트에서 숫자로는 나타낼 수 없는 정성적인 효과가 크다는 의견이 있었습니다.  체감 효율은 30%에서 40% 향상됐습니다.” 사토가 말했다. 
이에 더해 Astemo는 ECU 하드웨어의 동작을 확인하는 테스트(예를 들면 CAN 버스 단선 테스트)를 실제 ECU와 벡터의 VT System을 조합한 환경을 준비해 대응했다.


‘SIL Ki’으로 서드파티의 가상 ECU 도구 연계        

앞서 언급한 환경은 주로 BSW 레이어를 대상으로 시도했지만, Astemo는 애플리케이션 레이어(SW-C 부분)의 테스트 효율성을 높이는 데에도 벡터의 ‘SIL Kit[2]’를 활용했다. SIL Kit는 벡터가 오픈소스로 무상 제공하는 라이브러리를 통해 서드파티의 테스트 도구, 마이컴 에뮬레이터 및 시뮬레이터, 가상 ECU, 모델, 애플리케이션 소프트웨어를 연결하는 구조다(그림 5).



그림 5 | 서드파티의 도구 연계를 구현하는 벡터의 SIL Kit. ‘SIL 어댑터’(인터페이스)를 갖춘 도구에 대응, Vector Japan Inc.



Astemo는 서드파티의 가상 ECU 시뮬레이션 도구로 CAN 통신을 테스트하기 위해 해당 도구와 CANoe를 SIL Kit로 연계한 환경을 구축해 평가했다(그림 6). 이때 테스트 대상이 아닌 BSW 부분은 고정값으로 설정하는 등의 방법을 사용한다.
서드파티의 가상 ECU 시뮬레이션 도구를 SIL Kit를 통해 CANoe에 연결해 CAN 버스 테스트를 실시한다. BSW(그림의 abstract 부분)는 고정값으로 설정하거나 단순 처리로 치환한다.



그림 6 | Astemo의 애플리케이션 소프트웨어(ASW) 테스트용 환경, Astemo 



스즈키는 “도구 연계 시 설정 파일 작성에 다소 어려움이 있었지만, 가상 ECU 시뮬레이션 도구만으로는 수행할 수 없었던 CAN 통신 테스트가 가능해졌습니다. 또한, 익숙한 CANoe를 활용할 수 있어서 CAPL이나 자동 테스트 패턴 등 CANoe를 사용하며 축적한 경험을 활용할 수 있다는 것도 SIL Kit의 장점입니다”라고 설명했다.

Astemo는 향후 평가를 거쳐 파워트레인 ECU 이외의 분야에도 적용하는 등 본격적인 활용을 추진할 계획이다.


SDV 시대를 향하는 CI/CT 진화 노력         
 
사토는 “가상 ECU 환경에서 CI/CT를 구현함으로써 기본적인 기능 검증을 효율적으로 실행할 수 있게 됐습니다”라고 말했고, 스즈키는 벡터의 CANoe4SW Server Edition과 관련해 “COM(Component Object Model) 인터페이스 등 커맨드라인으로 제어할 수 있어 자동화에 대응하기 쉬웠습니다”고 평가했다. 
현재 그들은 물리적인 PC 수를 줄이기 위해 CI Runner를 클라우드 인스턴스나 컨테이너에 구현하는 등의 시도를 진행 중이다.

사토는 향후 SDV 진화와 관련해 “차량 개발에서 소프트웨어의 중요성이 점점 더 커지고 있으며, 보다 고도화된 기능을 더욱 효율적으로 개발하는 것도 중요합니다. 따라서 가상화 및 CI/CT의 도입은 필수적이라고 생각합니다”라고 말했다.  

Astemo는 향후 Ethernet 등 CAN 통신 이외의 차량용 네트워크의 CI/CT화, 차량 내부의 폐쇄적인 in-car 영역 테스트뿐만 아니라 커넥티드와 같은 이른바 out-car 영역과 연계한 테스트에도 적용을 확대할 계획이다. 
벡터는 CT를 포함한 자동화를 지원하는 도구를 지속적으로 제공하는 한편, 일반 버전 CANoe에서 CANoe4SW Server Edition으로 원활하게 전환하는 등 사용 편의성 개선에 주력해 고객의 요구사항을 충족할 예정이다.