Automotive Software Validation with Shift-Left and AI-driven Approach
2025년 05월호 지면기사
/ 글 │ 아눕 세이블(Anup Sable) CTO, KPIT Technologies
소프트웨어 정의 자동차의 복잡한 소프트웨어 및 아키텍처 요구사항은 소프트웨어 검증 프로세스에 영향을 미치고 있다. 이 글은 기존 V-사이클이 직면한 도전과제와 이를 해결하기 위한 가상화, AI 기반 테스트 등 최신 접근법과 해법을 소개한다.
글 │ 아눕 세이블(Anup Sable) CTO, KPIT Technologies
in english
소프트웨어 정의 자동차(SDV)의 복잡한 소프트웨어 및 아키텍처 요구사항은 자동차 소프트웨어 검증 프로세스에 영향을 미치고 있다. 기존의 자동차 소프트웨어 개발 프로세스는 가상화와 같은 shift-left 방법론으로 보완돼야 하며, AI 및 생성형 AI 기반 테스트를 통해 강화돼야 한다. 이 글의 초점은 전통적인 V-사이클이 직면한 도전과제를 설명하고, 이어 이런 과제를 해결하기 위한 최신 해법을 소개하는 데 있다. 이를 통해 OEM은 소프트웨어 검증과 관련된 지연을 방지함으로써 SOP 목표를 차질 없이 달성할 수 있다.
그렇다면, SDV 개발 및 검증 프로세스의 복잡성이 증가하는 요인은 무엇인가?
소프트웨어 검증을 어렵게 만드는 요인은 소프트웨어 애플리케이션의 증가와 복잡하고 동적인 배포이다. 향후 소프트웨어 업데이트에 대한 검증은 부담을 더욱 가중시킬 뿐이다. 이런 복잡성을 증가시키는 요인은 무엇인가?
첫째, 차량 내에 다수의 이기종(heterogeneous) 소프트웨어 및 하드웨어 구성 요소가 존재함에 따라 전체 테스트 시나리오가 3배 이상 증가하게 된다. 소프트웨어 복잡성이 높은 자율주행(AD/ADAS), 인포테인먼트, 커넥티드 솔루션과 같은 여러 도메인이 단일 고성능 칩셋(HPC)에 통합되며, 이 칩셋은 다양한 미들웨어, 운영체제(OS), 네트워크 구성 요소를 포함한다. 이런 각각의 구성요소는 아키텍처 제약 조건, 호환성, 통합성을 고려해 독립적인 검증이 필요하다.
둘째, 다양한 구성 요소 간의 상호 작용과 통합 지점이 늘어나면서 문제 분석 및 원인 규명(isolation)이 더욱 어렵고 시간도 더 오래 걸린다. HPC와 여러 zonal ECU 사이의 N2S(North to South) 및 S2S(South to South) 통신은 전례 없는 구조적/네트워크 제약과 시나리오를 동반한다.
셋째, 기존 테스트 전략은 실물 ECU를 기반으로 수립된다. 하지만 SDV 환경에서는 아키텍처가 거의 확정될 때쯤에야 테스트 환경을 구축할 수 있게 되는데, 이는 수많은 서로 다른 구성 요소 간 상호작용이 많이 증가한 점을 고려하면 너무 늦다. 또, 전통적인 아키텍처의 소프트웨어 개발 방식과 달리, OEM은 하드웨어 공급계약을 체결하는 과정에서 상당한 불확실성에 직면하고 있다.
전통적인 검증 방식은 OEM의 새로운 소프트웨어 중심 프로그램에 어떤 영향을 미치나?
OEM은 V-사이클에서 소프트웨어 오류를 늦게 식별해 SOP 일정이 2년 이상 지연되는 등의 여러 가지 문제에 직면하고 있다.
1. Feature/function 호환성 및 통합 문제는 SOP를 불과 몇 개월 앞두고 드러나는 경우가 많다. 이상적으로는 이런 문제들이 개발 단계의 시작부터 식별되고 SOP 일정 이전에 인지돼야 한다.
2. 개발 과정이 실물 ECU에 의존하는 정도를 줄이고, 이 과정을 공급업체 및 실물 ECU로부터 독립시킬 필요가 있다.
3. 시스템 V-모델 개발 주기를 완료하고 개발팀에 문제점을 다시 보고하는 데 4~6주 이상 소요된다. 이 과정은 며칠 내에 마무리돼야 한다.
4. 문제(결함)의 원인을 규명하고 특정하는 데 한 달 이상 걸린다.
5. 기존 방식에서 SDV 방식으로 전환되는 과정에서, 특이 케이스(corner cases)를 포함한 테스트 커버리지(test coverage)가 충분하지 않다.
기존 검증 프로세스를 shift-left 접근 방식과 AI 기반 솔루션으로 어떻게 보완할 수 있나?
OEM은 가상화, 레퍼런스 하드웨어에서 실물 ECU에 이르기까지 모든 가용한 기술 옵션을 아우르는 종합적인 테스트 전략을 구축해야 한다. 이런 전략을 구축하기 위해서 고려해야 할 구성 요소 목록은 다음과 같다:
1.
가상 검증(Virtual validation): 기존 테스트 전략은 실물 ECU와 밀접하게 연관돼 있으며, 문제가 양산 단계로 넘어가지 않도록 하는 데 중점을 두고 있다. 이것은 여전히 중요한 사항으로 유지돼야 하지만, 앞서 언급한 SDV 관련 이유로 인해 SDV의 SOP 일정에 대한 압박은 몇 배로 증가했다. 증가된 테스트 커버리지의 양과 복잡성을 감당하기 위해서는 전통적인 물리적 검증 환경을 넘어서는 사고가 필요하다. 따라서, 재사용가능한 가상 플랫폼을 마련하고 이를 여러 프로그램의 테스트 커버리지에 적극적으로 활용해야 한다. 이는 V-사이클 전반에 걸쳐 검증을 보완하고 shift-left 하기 위해 클라우드 네이티브(cloud-native) 환경과 가상 플랫폼의 활용이 필요하다. 현재 자동차 OEM은 개발 및 검증을 위한 가상 플랫폼 구축에 수백만 달러를 투자하고 있다. 하지만, 조직 내부의 근본적인 변화(transformational change) 없이 단순히 투자만 하면 실패로 이어질 수 있다. 이 새로운 프로세스를 기존 V-사이클 리듬 내에서 주도하고 운영할 전담팀 구성이 필요하다.
2.
조기 아키텍처 및 플랫폼 검증(Early Architecture & Platform Validation): 아키텍처 정의 초기 단계에서 아키텍처 정의 자체와 플랫폼 및 (각) 도메인의 하드웨어 제약 조건을 검증하는 것은 매우 중요하다. 애자일(agile) 방식을 적용하더라도 아키텍처 설계 개념은 처음부터 명확해야 한다. 통합 과정과 그 범위는 크게 과소평가되는 경우가 많다. 개념을 입증하려면, 실물 하드웨어가 준비되기를 기다릴 것이 아니라 적절한 협력체계(에코시스템)를 갖추어 가능한 한 빨리 통합을 시작해야 한다. 더욱이 차량 내 통신 시스템/네트워크는 매우 복잡하며(예: 이더넷과 CAN 간의) 모든 트래픽이 동일하지 않기 때문에 차별화해 접근해야 한다. 또한, 안전성(Safety)과 보안(Security) 요소 역시 초기부터 반드시 고려해야 한다. SDV 아키텍처 기반의 레퍼런스 하드웨어 환경이나 프로토타입을 활용할 수 있다면, 개념증명(POC) 단계에서 네트워크 사양, 아키텍처 관련 결정 사항, 설정된 가정 등을 검증하는 데 도움이 된다. 이를 통해 OEM은 아키텍처 POC 단계에서 하드웨어 프로토타입을 개발해 위험을 줄이고, 양산 준비(pre-SOP)부터 SOP까지의 개발 기간을 1 ~ 2년 앞당길 수 있다.
3.
통합 멀티 도메인 HIL(Hardware in Loop) 시스템(Integrated multi-domain HIL systems): SDV 환경에서 다양한 도메인 기능 간의 상호 의존성을 테스트하기 위해서는 네트워크 검증, 아키텍처 검증, 통합 검증 등 다양한 형태로 구현되는 통합 멀티 도메인 HIL 시스템이 필수적이다. 개별 도메인 HIL만으로는 서로 다른 도메인 기능들의 상호 의존적인 동작을 테스트하기에 충분하지 않다. 통합 HIL은 모든 구성 요소를 통합된 환경에서 테스트함으로써 실제 환경 시나리오를 재현하고, 실제 네트워크 조건 하에서의 원활한 상호 운용성을 보장한다. 또한, 중앙 집중식 시스템에서 병렬 테스트가 가능해 개발 속도를 높이는 데 도움이 된다. 이런 통합 HIL은 새로운 기능 출시를 원활하게 수용하고 테스트해 시스템 검증이 항상 최신 상태로 유지되도록 보장한다. 더 나아가, 이런 HIL 시스템은 고급 분석 기능을 접목해 시스템의 동작과 잠재적인 연쇄 고장까지 예측할 수 있도록 그 기능이 더욱 향상되고 있다.
4.
AI 기반 테스트(AI-driven testing): 최근 AI와 생성형 AI의 등장으로, 이런 기술을 생산성 향상을 위해 활용하는 것이 필수가 되고 있다. 자동화와 AI가 생성하는 테스트 케이스를 통해 막대한 엔지니어링 공수(effort)를 최소화할 수 있다. AI 솔루션은 기존 도구와 프레임워크에 유연하게 통합될 수 있으며, 이를 통해 비용을 크게 절감할 수 있다.
5.
특이 케이스(corner cases)를 포함한 테스트 커버리지 확대: 소프트웨어가 폭발적으로 증가함에 따라 기존에 고려되지 않았던 부분까지 아우르는 종합적인 테스트 시나리오를 새롭게 구성해야 한다. 이를 위해서는 새로운 아키텍처를 기반으로, 그리고 다양한 SDV 프로그램 경험에서 얻은 교훈을 통해 예측되는 완전히 새로운 테스트 시나리오를 만들어야 한다.
SDV 검증 과제와 KPIT의 역할
KPIT는 E/E 아키텍처, 차량 네트워크, 플랫폼, 여러 도메인 및 차량 전체에 걸친 통합 테스트 커버리지를 구축함으로써 OEM이 검증 전략을 SDV에 맞게 준비할 수 있도록 지원한다. KPIT는 가상 엔지니어링, AI 및 생성형 AI, 멀티 도메인 시스템 검증, 레퍼런스 SDV 아키텍처 및 양산준비(pre-SOP) 단계에서의 네트워크 테스트 등 앞서 언급한 요소들을 포함해, SDV 검증 프로세스에 필요한 모든 범위의 플랫폼과 액셀러레이터(accelerators)를 제공한다. 또한, OEM이 툴(도구)과 인프라(물리적 및 가상)의 원활한 조율(오케스트레이션), CI/CD부터 가상 검증 및 물리적 검증에 이르는 통합 전략 수립, 그리고 프로그램 수준의 실행을 위한 조기 로드맵 구축에 집중할 수 있도록 지원한다. 이를 통해 소프트웨어 검증 관련 지연을 방지해 OEM이 SOP 목표를 달성하도록 돕는다.
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>