오늘날 자동차는 자율주행 관련 기술과 여러 편의 기능이 급속도로 발전함에 따라 단순 위치 이동 수단만이 아니라 여러 다양한 기능들을 제공하고 있습니다. 한편 그러한 변화 배후에서 차량 내부 컴퓨팅 시스템은 점점 더 복잡해지고 있으며, 그에 따라 차량 전자 제어 유닛 ECU(Electronic Control Unit) 개수도 급증하고 있습니다.
ECU의 동작과 테스트
차량이 제공하는 수많은 기능들은 기능마다 한 개씩의 ECU로 수행되지 않고 여러 ECU들이 연관되어 복합적으로 동작해 기능을 제공합니다. 이를테면 자동 온도 조절 기능을 위해 온도 센서와 에어컨, 창문, 히터 등을 조작하는 ECU들이 연동되어 동작하는 것처럼요. 이는 간단한 예시로, 보다 복잡한 기능이라면 한 가지 기능을 위해 수십 개의 ECU가 동원되기도 합니다.
따라서 차량에 어떤 기능을 추가할 때에는 해당 기능에 직간접적으로 관련된 ECU들에 대한 소프트웨어 테스트 및 검증이 필요합니다. 하드웨어 결함과는 달리 소프트웨어 결함은 제품 개발 단계에서는 검증하기가 어렵고 그 결과로 나타나는 현상 또한 예측 불가능한 경우가 많기 때문에 철저한 소프트웨어 테스트는 더더욱 중요한 일입니다.
하지만 장치 제어를 포함한 기능들을 실제 차량을 통해 직접 테스트하는 것은 위험한 일이므로, 검증하려는 기능과 관련된 ECU들을 조합해 실제 차량의 네트워크 환경과 비슷한 프로토타입 모형을 제작해 테스트하는 방식을 취해 왔습니다. 그런데 문제는 최근 ECU와 소프트웨어의 복잡도가 기하급수적으로 증가해버렸다는 사실입니다.
예를 들어 벤츠 S 클래스, BMW 7 시리즈, 현대 제네시스와 같은 고급 차종에는 ECU가 수백 개가 탑재되어 있기 때문에, 차량 기능 하나를 테스트하기 위해 각각 프로토타입 모의 차량을 구성하기에는 시간과 비용 문제가 심각해진 것입니다. 더군다나 ECU뿐 아니라 럭셔리 급 세단에는 대형 항공기보다 약 3배 더 많은 2,000만 줄의 소프트웨어 코드가 탑재되어 있기도 합니다.
따라서 기능 추가 때마다 ECU 몇 백 개를 임시로 구성해 테스트하기에는 많은 비용과 시간이 소모됩니다. 완성차 OEM 제조사와 ECU 부품사 입장에서 보자면 어떤 ECU의 단 하나 기능을 테스트하려고 해도 그 기능과 연관된 모든 ECU를 조합해 테스트 환경을, 그것도 차량 모델마다 다르게 구성해야 한다면 시간과 노동뿐 아니라 각 ECU 구입 비용도 꽤 문제가 될 것입니다.
HILS 테스트
그래서 'HILS(Hardware in the Loop Simulation)'라는 테스트 기법이 활용됩니다. HILS 테스트란 개발된 제품의 기능을 검증하는 테스트 방법으로, 제품을 구성하는 장치들을 소프트웨어적으로 모델링하여 제품이 실제 환경과 동일한 조건에서 제대로 기능하는지 시뮬레이션을 통하여 검증하는 일입니다.
차량 테스트에 있어 HILS는 여러 ECU 기능의 시뮬레이션 시스템으로, 차량의 성능과 결함을 실차에 테스트하기에 앞서 HILS를 통해 모의 테스트를 진행할 수 있습니다. HILS를 이용하여 개별 ECU에서부터 전체 네트워크에 대한 통합 테스트까지 차량 운행의 모든 시나리오를 테스트할 수 있습니다.
자동차 산업의 HILS는 각 기능마다 일일이 실차 환경을 구성하지 않고도 ECU의 소프트웨어적 품질과 신뢰성을 보증하는 검증 방법의 근본적인 효율화 필요에 따라 등장한 기술이라 볼 수 있습니다. 물론 프로토타입 실물 제작 필요를 완전히 배제할 수는 없지만 프로토타입 차량 제작과 그 실험의 수를 줄여 비용을 대폭 줄일 수 있습니다.
이어서 HILS 테스트 환경에 대해 알아보겠습니다.
HILS는 실제 ECU를 조합해 프로토타입을 제작하는 대신에 시뮬레이션을 통해 테스트를 진행합니다. 이를 위해 HILS 테스트 환경은 1)Test Input Generator, 2)Target ECU, 3)HILS로 구성이 됩니다. Test Input Generator는 테스트를 위한 입력값을 생성하여 입력하는 역할을 하고, 이에 Fuzzer 등의 입력기가 포함됩니다. Target ECU는 말뜻 그대로 기능을 실험하고자 하는 대상 ECU를 의미합니다. HILS는 실제 차량의 환경을 수학적으로 모델링하고 실제 제어기의 움직임을 모델링한 가상 제어기로, 필요에 따라 여타 실제 액츄에이터들을 연결하여 실험할 수도 있습니다.
위 그림은 아우토크립트의 HILS 테스트 환경 예시입니다. 그림을 보시면, HILS에 실험 대상 ECU를 연결한 채로 Fuzzer를 이용해 테스트 입력값을 주입하면, HILS를 통해 출력값을 받음으로써 해당 ECU를 테스트하는 과정을 볼 수 있습니다. 이로써 ECU 기능 테스트를 위해 해당 ECU의 기능과 관련된 모든 ECU를 실제로 구성하지 않아도 되는 것이죠. HILS 환경에 테스트할 ECU만 연결하면 됩니다.
HILS의 가장 중요한 목적은 ECU와 소프트웨어의 복잡도를 감축함으로써 개발 비용을 줄이는 데 있습니다. 대개의 경우 실제 제품을 만드는 것보다 모의 실험 쪽이 비용이 낮으므로, 많은 비용과 시간이 요구되는 프로토타입 차량의 수를 줄이고 테스트벤치에서 소모되는 시간을 현저히 줄일 수 있는 것이죠.
이는 자동차 시험 중에 단선, 센서 고장, 차량 충돌 등 위험한 시험을 진행할 때에도 큰 장점이 됩니다. 또한 제어 알고리즘의 개발시 제어 대상이 되는 실제 부품이 존재하지 않는 등의 경우에도 효과적이죠. 시간과 공간 제한 없이 필요할 때마다 언제든 테스트를 수행할 수 있다는 점도 큰 현실적 장점입니다.
HILS 테스트의 적용
오늘날 자동차 업계에서는 HILS 검증의 중요성을 절감하고 안정적인 HILS 환경을 구축하는 데 열중하고 있습니다. 자동차 기능 안전 표준 ISO 26262에서는 자동차 생산에서 폐기까지 준수해야 할 항목들을 정리하여 소프트웨어 검증 단계를 정의하였는데, HILS 단위 시험과 통합 시험 과정에서 HILS 검증을 언급하고 있으며, 각종 요구사항 검증 단계에서의 사용 또한 적극 권장하고 있습니다.
아래 그림을 보시면 현대자동차의 차량 소프트웨어 개발 프로세스 V-Cycle에서도 HILS가 5번째 단계로 강조되어 있습니다. 이렇듯 자동차 메이커들이 신차 개발 과정에 통합 HILS를 적용하는 건 차량의의 제어 소프트웨어가 점점 복잡해지고 있기 때문입니다.
자동차 제조사들이 통합 HILS를 적극 도입하는 것은 차량 소프트웨어가 복잡해짐에 따라 소프트웨어 불량도 늘어나 리콜과 무상 수리에 따른 손해가 증가하기 때문이기도 합니다. 국토교통부의 자동차리콜센터에 따르면, 2023년 1월부터 5월까지 발생한 리콜 및 무상 수리는 총 367건으로 그중에 172건이 소프트웨어 불량입니다. 소프트웨어 불량이 43.3%인 거죠. 5년 전인 2018년 1~5월에는 12.3%였던 것에 비교하면 그 심각성이 더 두드러져 보입니다.
자동차 소프트웨어가 무거워지고 복잡해짐에 따라 소프트웨어 불량 또한 늘게 마련이니, 사전에 다양한 소프트웨어 테스트를 진행하는 일은 필수입니다. HILS는 시간과 공간 제약 없이 원하는 대로 테스트를 수행할 수 있으므로 크게 도움이 됩니다. 그리고 HILS는 이미 발생한 소프트웨어 불량에 대한 빠른 조치를 취할 때도 유용합니다. 실물 테스트는 프로토타입 제작 때문에라도 빠른 대응이 힘드니까요. 이때 HILS를 활용하면 시뮬레이션을 통해 기능 결함을 빠르게 분석하고 대응하여 조치를 취할 수 있습니다.
- 아우토크립트 기술기획팀 송호승 연구원
