11월, MathWorks가 개최한 ‘Automotive Conference 2024’에서 현대위아 TMS 제어팀의 허승준 책임연구원을 만나 ▶ATCU의 모델 기반 설계(MBD) ASW와 AUTOSAR Classic 플랫폼 모빌진(Mobilgene) 통합 ▶지속 통합(CI) ▶지속 배포(CD) 및 지속 테스팅(CT) 전략에 대해 들었다. 이것은 미래 자동차의 핵심 영역 중 하나인 전기차 공조, 열관리 분야에 도전장을 낸 현대위아가 현대기아자동차와 잠재 고객의 미래 자동차 요구사항에 적시 대응하고 다음 단계로 나아가는 이야기다. 

글 | 한상민 기자_han@autoelectronics.co.kr








“2022년 말 시작된 현대위아의 공조제어기(Auto Temperature Control Unit, ATCU) 개발 프로젝트 목표는 모델 기반으로 공조 제어 애플리케이션 소프트웨어 전체를 설계하고 이를AUTOSAR Classic 플랫폼인 모빌진(Mobilgene, 현대오토에버 개발)에 탑재하는 것이었습니다. 이런 개발 과정에서 소프트웨어의 지속적인 변경점에 대한 효율적인 통합과 검증에 대한 일련의 개발 프로세스를 구축하는 것이 큰 도전 과제였습니다. AUTOSAR 플랫폼 자체가 새로운 표준이거나 신기술로 분류하기는 어렵겠지만 공조 제어 영역에서는 현대위아가 최초로 모델 기반 설계와 모빌진 플랫폼을 결합해 개발에 도전하는 측면에서 개발과정에서 나름의 어려움이 있었습니다.” 

현대위아 TMS제어팀의 허승준 책임연구원이 감회를 말했다. 

11월, MathWorks가 개최한 ‘Automotive Conference 2024’에서 현대위아 TMS 제어팀의 허승준 책임연구원을 만나 ▶ATCU의 모델 기반 개발(MBD) ASW와 AUTOSAR Classic 플랫폼 모빌진(Mobilgene) 통합 ▶지속 통합(CI) ▶지속 배포(CD) 및 지속 테스팅(CT) 전략에 대해 들었다.

자동차 OEM은 오래전부터 ECU 간 상호운용성 및 소프트웨어 통합 용이성, 소프트웨어 모듈의 향상된 재사용과 교환 가능성을 통한 비용 절감 및 개발 효율성 향상, E/E 아키텍처 복잡성 관리를 개선하고자 AUTOSAR 적용을 요구해왔고, 이제 그 요구 영역은 SDV(Software Defined Vehicle) 트렌드에 따라 보안성, 기능안전성 확보와 같은 중요 요소와 함께 더욱 확대되고 있다. 
그러니까 이와 같은 상황 속에 미래 자동차의 핵심 영역 중 하나인 열관리, 공조 분야에 새롭게 도전장을 낸 현대위아, 범위를 좁히면 TMS 사업부 TMS제어팀이 현대기아자동차와 잠재 고객의 미래 자동차 요구사항에 적시 대응하고 다음 단계로 나아가고 있었다. 





새로운 사업 공조 

얼마 전인 10월, 현대위아는 독일 볼프스부르크(폭스바겐의 본거지)에서 개최된 한 전시회에서 그들의 전기차 공조 시스템 포트폴리오인 HVAC(Heating, Ventilation, Air Conditioning) 모듈, 열 교환기, e컴프레서 등과 함께 야심 차게 전기차 통합 열관리 시스템(Integrated Thermal Management System, ITMS)을 처음 공개했다. 2024년 개발을 완료한 ITMS는 모터와 배터리, 파워일렉트로닉스의 열관리부터 실내 공조까지 아우르는 통합 공조 시스템으로, 핵심인 냉각과 냉매 모듈을 하나로 합쳤다. 

그동안 파워트레인, 드라이브트레인 등을 주력으로 해온 현대위아는 2022년 전격적으로 전기차 열관리 시스템 개발본부 TMS를 출범시켰다. 열관리, 전기차 공조를 미래 자동차의 핵심 영역으로 판단했기 때문이다.
내연기관에서 공조는 히터, 에어컨 등의 단순 기능에 국한됐지만, 전기차에서는 배터리, 모터, 그리고 인버터 등의 파워일렉트로닉스 부품의 성능과 연계되면서 이것이 단순한 실내 쾌적성 뿐 아니라 차량의 주행거리, 성능과 품질 등에 막대한 영향을 미친다. 이 같은 배경으로 차량 열관리 시장도 점차 확대되어 2021년 10억 달러 규모에서 27년 약 21억 5,000만 달러에 이를 전망이다. 

허 책임은 “저희가 하고 있는 것은 공조 시스템의 최상단에 있는 ATCU를 포함한 ITMS 개발입니다. ATCU의 경우 온도, 습도 제어 등 실내 공기질 최적화를 위한 제어 등을 수행하는 역할을 담당하는데, 이 역시도 여러 컴포넌트와의 연계 제어 요소가 많고 복잡합니다. 이런 연계 제어의 효율성은 전기차 전비에 막대한 영향을 미치기 때문에 매우 중요합니다”라고 소개했다.

예를 들어, ATCU에는 일사량, AMB, 인카, ADS, Duct 등 여러 센서 데이터를 비롯해 Blower 유닛, PTC, HVAC 모듈 등 냉매 사이클을 만드는데 필요한 많은 관련 컴포넌트들이 연관된다. 내연기관이나 하이브리드카가 엔진이란 강력한 열원이 있어 상대적으로 단순했지만, 열원이 부족한 전기차에서는 이를 극복하기 위한 냉각수/냉매 모듈 기반의 히트펌프 시스템이 구성되고, 전동식 컴프레서와 부족한 열원을 보완하기 위한 PTC 히터가 별도로 구성된다. 


모빌진 통합(AUTOSAR)의 요구

일반적으로 제어 시스템의 개발은 많은 부분에서의 기반 기술이 필요한 영역이다. 새롭게 시작한 현대위아의 공조 부문에 대한 제어 개발은 시작부터 순탄하지 않았다. 모빌진 기반의 AUTOSAR 플랫폼을 신규로 적용하는 과정에 있어서 모델 기반 애플리케이션 소프트웨어와의 통합에 있어 여러 문제에 직면했다. 대표적으로, AUTOSAR의 경우 신호를 처리하는 상호간의 인터페이스 속성이 맞아야만 소프트웨어 통합을 위한 조각들이 맞춰지는데, 그 인터페이스 속성을 맞추는 특성, 형태, 방법적인 부분에 대한 많은 문제를 극복해야 했다. 

허 책임은 “현대위아가 공조에 발들인 지가 얼마 안 됐습니다. 하지만 다른 영역에서의 모델 기반 제어 개발 경험을 비롯해 MathWorks와 협업해 온 경험과 역량, 노하우를 통해 문제를 극복하고 개발 속도를 높여 현재의 개발 결과를 향후 다른 프로젝트로 수평 전개 가능할 정도의 수준에 도달했습니다. AUTOSAR는 결국 표준 플랫폼이라는 점에서 출발해 표준 문서를 적극 참조하고, MathWorks 팀과의 협업을 통해 난관을 극복할 수 있었습니다”라고 말했다. 

MBD의 리더로 잘 알려진 MathWorks는 현대위아의 주요 파트너이자 소프트웨어 개발 메인 툴 체인이다. MathWorks는 단순 제어 알고리즘을 구성하는 서비스만 제공하는 것이 아니라, 모빌진과 같은 AUTOSAR 플랫폼 통합 과정에 효율적이고 빠른 접근을 지원한다. 특히 MathWorks의 MBD를 활용하면 소프트웨어의 구조화가 쉽고 다양한 기법을 통해 조기 검증이 가능해 검증 절차를 간소화하고 개발 속도를 높일 수 있다. 

TMS 제어팀은 BSW와 관련해 OTA, 사이버 보안 등에 대응하기 위해 관련 모듈을 모빌진 플랫폼에 통합하고 공조제어에 필요한 특화 모듈들에 대한 설정을 한 후 코드를 생성했다. 일부 모듈로 지원하지 않는 특수 부분은 ‘CDD(Complex Device Driver)’로 분류해 직접 개발을 수행했다. MathWorks의 Simulink 기반 MBD 기법을 전체 ASW 영역에 적용했다. 

“현대위아는 단순히 부품 단위로 공급하는 업체가 아니라 차량 전체의 열관리 시스템을 공급하는 전략으로 사업을 추진했기 때문에 OEM에서 받은 차량 레벨의 요구사항을 현대위아 시스템에 맞춰 분석하고 시스템 요구사항을 도출했습니다. 이를 통해 소프트웨어 요구사항을 작성하고 소프트웨어 아키텍처를 구성했습니다.”






TMS 제어팀은 BSW와 ASW의 구성을 병행하면서 모빌진 기반 AUTOSAR 플랫폼에 대한 통합 전략을 수립했다. 처음 시도한 통합 방식은 Bottom-Up 방식이었다. AUTOSAR 적용 기반인 모빌진 플랫폼에서 Simulink로 출력한 다음 다시 산출물을 모빌진으로 가져와 통합하는 형태가 Top-Down 방식이라면, Bottom-Up 방식은 Simulink에서 모빌진으로 직접 출력한 결과를 통합하는 형태다. 

초기에 팀은 ASW의 개발 자유도와 다소의 변경 예상으로 Simulink 중심의 Bottom-Up 방식을 적용하면서 System Composer를 활용해 컴포지션 단위에 통합되는 애플리케이션을 모빌진에 이식하는 전략을 취했다. 
물론, Bottom-Up 방식 통합 시도 이전에 ASW 대한 구조를 더 구체화시키기도 했다. 인풋과 아웃풋을 처리하는 별도의 컴포넌트를 구성하고, A-SPICE에서 권장하는 입력부터 출력까지 단방향 흐름으로 제어될 수 있도록 아키텍처를 구체화했다. 이 아키텍처를 기반으로 System Composer를 통해 아키텍처 모델링을 수행을 하고 각 소프트웨어 개발자들이 내부 알고리즘을 채웠다. 

“System Composer를 통해 통합된 ASW를 구성하는 데에도 상당한 어려움과 트러블 슈팅이 있었지만, 이전의 Simulink 경험과 MathWorks의 지원으로 1차적 통합 구성을 완료할 수 있었습니다.” 허 책임이 말했다. 





시행 착오

하지만, Bottom-Up 방식의 첫 소프트웨어 통합에는 많은 문제가 있었다. 
애플리케이션 소프트웨어는 MBD로 개발되고, 개발된 모델은 ARXML을 포함한 C코드와 헤더파일은 AUTOSAR 코드 제너레이션 기반으로 자동 생성된다. AUTOSAR 표준에 의해 정의되는 모든 인터페이스는 생성되는 ARXML 내에 정보가 정의된다. 그런데 Simulink와 모빌진이 연결되는, 다시 말해 애플리케이션 기준으로 양 끝단 컴포넌트의 생성된 ARXML이 모빌진과 바로 통합되지 못하는 문제가 발생했다. 

“이 문제를 해결하기 위해 여러 접근을 했습니다. Simulink 내부 설정을 바꿔보고 AUTOSAR Dictionary에 있는 다양한 옵션을 적용하면서 ARXML을 생성해봤는데, 결론적으로는 현재 설정 가능한 영역 내에서는 인터페이스 일체화가 어렵다는 판단을 했습니다. 특히 AUTOSAR Dictionary에서 정의하는 인터페이스 패키지 속성에서 이 부분을 일치시켜야만 모빌진 인터페이스와 명확하게 통합된다는 사실을 확인해, 속성의 일체화를 위해 컴포넌트 입, 출력 인터페이스를 각각 양 끝단과 중간 단으로 분리하는 작업을 했습니다.”

System Composer와 Simulink 레벨에서 이 과정이 자동으로 해결되면 좋겠지만, 아쉽게도 팀은 AUTOSAR 코드 제너레이션 이전, 이후에 별도의 프리-프로세싱 혹은 포스트-프로세싱이 필요하다는 결론을 내렸다. ASW에 대한 개발 변경이 잦고 일정도 충분치 않아 임시 통합 방식 전략을 가져갈 수밖에 없었다.






결국 팀은 Bottom-Up과 Top-Down 방식의 믹스를 시도했다. 서드파티 툴과 호환해 산출물을 교환하는 통합 형태를 Round-Trip 방식이라고 말하는데, 애플리케이션을 기준으로 입력과 출력을 담당하는 컴포넌트는 Top-Down 방식으로, 다른 중간 애플리케이션은 Bottom-Up 방식을 유지했다. 

Top-Dwon 방식을 취하는 컴포지션 중에서 입력 처리를 담당하는 컴포넌트는 입력 부분이 모빌진과 맞닿는다. 출력 처리를 담당하는 컴포넌트는 출력 부분이 맞닿아 있다. 팀은 입력부 컴포넌트의 입력 부분을 모빌진 인터페이스로 고정시켜 놓고 뒤쪽을 분리하는 작업을 실시했다. 반대로 출력부 컴포넌트는 출력 부분을 모빌진 인터페이스로 고정시키고 입력 부분을 Simulink 인터페이스로 분리하는 작업을 했다. 이렇게 입력과 출력에 대한 매칭성을 확보하고, 나머지 애플리케이션 소프트웨어에 대해 내부 인터페이스로 인터페이스 매칭을 수행했다.

허 책임은 “제어기 개발의 특성상 통상적으로 입력과 출력의 경우 개발 초기부터 정의되고 이후로 갈수록 변경이 적어지는 점이 있기 때문에 다른 기능 대비 상대적으로 변경이 적다는 장점을 활용했습니다. 또 Round-Trip 방식을 통해 나머지 ASW에 개발 자유도를 어느 정도 확보할 수 있었습니다”라고 말했다. 

Simulink 모델 구성에 필요한 인터페이스를 모빌진으로부터 ARXML로 export하고 이를 다시 Simulink에 import하면 스켈레톤 모델(Skeleton Model)을 만들 수 있다. Round-Trip 방식으로 생성된 산출물은 제어팀의 전략대로 인터페이스에 있어 모빌진과 매칭성을 확보했다. 그리고 최종적으로 모빌진에 통합해 컴파일을 수행할 수가 있었다. 

통합된 인터페이스는 크게 통신, 센서 입출력과 같은 아날로그 및 디지털 I/O, 메모리 진단 영역으로 나뉜다. 각각의 기능에 따라서 통합 시에 적합만 AUTOSAR 모듈과 연결 작업을 수행하고 AUTOSAR 모듈에서 지원하지 않는 기능의 경우 CDD 영역으로 분류해 별도 개발했다.

“직관적으로 봐도 Round-Trip 방식은 상당히 복잡합니다. 과정이 복잡해지면 애플리케이션 개발 효율이 떨어지고 휴먼 에러도 발생할 수 있습니다. 무엇보다 저희가 MBD를 하면서 한계를 느꼈던 것은 애플리케이션을 분리해 관리해야 한다는 점이었습니다. 이렇게 하면 부분적으로만 통합을 진행할 수 있고, 분리 문제로 소프트웨어 통합 담당자와 애플리케이션 개발자가 항상 패러럴하게 존재해야 하는 문제도 있었습니다.” 허 책임이 말했다. 






지속 통합(CI)을 위한 MasterDB

“CI(Continuous Integration)는 말 그대로 지속 통합에 대한 것인데, 단순히 통합을 지속적으로 한다는 것이 아니라, 어떤 소프트웨어의 변경이 발생했을 때, 이에 대해 자동으로 변경 내역을 적용하고 통합을 할 수 있는 체계를 마련하는 것을 말합니다. 이에 따라 당연히 작업 효율성, 개발 속도가 올라가고 자동화를 통해 휴먼 에러도 줄어듭니다. 결론적으로, 저희 팀은 이런 통합 방식으로는 CI 환경 구현이 불가능하기 때문에 다시 Bottom-Up 방식의 통합 방식으로 회귀하는 고민을 이어갔습니다.”

팀은 Round-Trip 방식을 통해 얻은 결과들과 분석 결과를 토대로 다시 Bottom-Up 방식 통합을 적용하는 새로운 개념을 도입했다. 이것이 바로 MasterDB 개념이다.







“MasterDB는 마이크로소프트 엑셀 기반 데이터입니다. 베이직 소프트웨어 개발자들은 모빌진에서 애플리케이션에 필요한 입출력을 개발하고, 애플리케이션 개발자들은 Simulink에서 실제 공조제어에 필요한 로직을 개발합니다. 결국 이 산출물들이 하나로 통합된다는 관점에서 도입된 것으로, MasterDB를 기준으로 각 개발자가 필요한 모든 인터페이스에 대한 정보를 하나로 묶어두고 중앙 관리하는 형태입니다.”

모빌진에서 생성되는 인터페이스는 필요 기능에 따라 관련된 ARXML을 파싱한다. 애플리케이션에서 필요한 인터페이스의 경우 개발자가 직접 등록하거나 삭제하는 작업을 통해 MasterDB를 구성한다. 이 과정에서 MasterDB는 통합에 필요한 애플리케이션 및 BSW의 모든 인터페이스 속성 정보를 포함하게 된다. 속성 정보에는 데이터 타입과 인터페이스, 컴포지션 구성에 필요한 여러 argument 등이 포함된다. 

“우리는 MasterDB를 통해 Simulink 모델과 아키텍처의 구성, 파싱에 있어 MathWorks와 협업을 했습니다. 모빌진에 구성된 모든 인터페이스와 애플리케이션 개발자들이 지정한 인터페이스가 MasterDB에 등록되면 이를 통해 스켈레톤 모델부터 아키텍처 모델 생성을 자동으로 할 수 있게 만들었습니다. 등록된 인터페이스를 기준으로 필요한 AUTOSAR Blockset같은 경우도 자동으로 생성합니다.”

이렇게 되면 애플리케이션 개발자들은 그저 생성된 스켈레톤 모델에 알고리즘을 채워놓는 형태로 개발을 종료할 수 있게 된다. 빌드를 통해 생성된 산출물이 MasterDB에서 갖고 있던 모든 인터페이스를 포함해 생성되기 때문에 초기에 수용했던 Bottom-Up 방식의 산출물 대비 MasterDB를 적용한 후의 Bottom-Up 방식은 모빌진 인터페이스를 모두 포함할 수 있게 된다. 또, 인터페이스 매칭에 있어 이전 방식에서는 매칭되지 않던 부분들이 MasterDB 방식을 통해 매칭성이 확보됐다. 



CI의 남은 부분

MasterDB와 Bottom-Up 방식을 활용해도 모빌진의 특유 속성 정보를 모두 만족시키지는 못한다. 때문에 팀은 일부 영역에서 후처리 및 자동화 구현을 위한 추가 작업을 했다.

첫째는 ARXML 후처리다. 이것은 특히 MATLAB API, AUTOSAR 딕셔너리나 GUI에 정의되지 않은 Simulink에서 직접 다룰 수 없는 부분으로, System Composer 과정에서 자동화가 불가능했다. 이에 ARXML을 하나의 텍스트로 인지시킨 다음, 이 부분에 대해 필요한 부분을 인터페이스 속성에 맞춰 변경할 수 있는 자동화 스크립트를 만들어 ARXML을 후 처리할 수 있도록 했다.
또, MasterDB를 사용하면서 외부 라이브러리나 신규 인터페이스가 추가될 때를 대비해 BUS 인포메이션을 머지하는 스크립트를 만들었다. 이런 자동화 스크립트를 통해 AUTOSAR 인터페이스 속성에 필요한 다양한 정보를 쉽게 병합할 수 있게 했다.
 
세 번째로, 과거에는 아키텍처로 모델을 구성한 이후 개발자가 직접 각각의 포트를 System Composer에 연결해야 했는데, 이 스크립트를 통해 자동으로 연결할 수 있게 구성해 단순 통합 업무뿐 아니라, 컴포지션 단위의 MILS 환경 구성에도 효율을 증대시켰다. 


현대위아 TMS 제어팀은 A2L 자동 생성 및 병합 기능도 연동시켰다. 현대기아의 공조제어 기능인 XCP 기능을 도입해 실차 캘리브레이션 모니터링 기능을 구현했고, 이를 통해 시스템의 성능 육성 속도와 효율을 높이고 있는 상황이다. XCP 구현에서 필수 산출물은 A2L이다. CI 환경 구축 시에 소프트웨어 컴포넌트에서 필요한 A2L 추출이 가능하고, 이를 병합하는 기능을 자동화해 통합된 A2L을 CI 환경에 생성할 수 있게 했다. 통합된 A2L은 Vector의 CANape나 ETAS의 INCA와 같은 범용 툴을 통해 실차 캘리브레이션 작업도 지원한다.

허 책임은 “MasterDB에 등록된 모든 정보를 기반으로 아키텍처 및 스켈레톤 모델이 자동 생성되고 ARXML에 대한 포스트 프로세싱까지 자동 수행하게 되면서 통합에 필요한 산출물을 연속적으로 생성하고 이를 기반으로 모빌진에서 컴파일을 수행하게 됩니다. Round-Tip 방식과 마스터 MasterDB Bottom-Up 방식을 비교하면, MasterDB와 스크립트를 통해 전체적인 통합 과정을 자동화해 복잡도를 최소화하고 개발 속도를 높였습니다. System Composer를 통해 전체 ASW에 대한 통합 관리가 가능해져, 인풋부터 아웃풋까지 전체 MILS 검증 접근이 가능해졌습니다. 또 별도 수작업 없이 모빌진에 직접 통합 가능한 애플리케이션 소프트웨어 산출물을 제공할 수 있게 되면서 공조제어 소프트웨어에 대한 CI 환경 구축 기반을 만들 수 있었습니다”라고 설명했다. 









CD/CT로의 전개

허 책임과 TMS 제어팀은 이렇게 다져진 CI 환경에서 다른 서드파티  툴을 연동해 미래의 개발 및 검증에 필요한 전체 프로세스 자동화를 추구하고 있다. CD, CT 환경 확보를 목표로 한다. 

“CI 환경을 완성했으니 다음은 CD 및 CT 환경 구축을 목표로 해 설계부터 배포 및 검증까지 일련의 과정을 체계화하는 것이 목표입니다. 물론 여기서 Codebeamer, Jira, GitLab, Jenkins 등은 물론 가상 제어기, HILS 등 서드파티 툴과 연계하기 위해 개발해야 할 요소들도 굉장히 많을 것입니다. 이런 개발 과정에서 MathWorks의 툴 체인은 다른 서드파티 툴과 연계되는 부분이 많아 큰 도움이 될 것입니다.”