SDV 검증을 위한 Virtual ECU 병렬 빌드 및 SILS 자동화 구축 방안

2.1 V-Model 기반 검증 체계

임베디드 시스템, 특히 자동차 전자제어장치(ECU)와 같은 고신뢰성 시스템의 SW 개발에는 체계적이고 구조화된 개발 방법론의 적용이 필수적이다. 이 중 V-Model은 요구사항 분석에서부터 설계, 구현 및 통합에 이르기까지 각 개발 단계와 그에 대응하는 검증 활동을 명확히 연결하는 계층적 개발 프로세스로서, 현재까지 널리 활용되고 있다.⁷⁾

V-Model은 Fig. 1 좌측의 개발 단계(요구사항 분석, 시스템 설계, 소프트웨어 설계, 구현 등)와 우측의 검증 단계(단위 테스트, 통합 테스트, 시스템 테스트 등)가 V자 형태로 대응되도록 구성되어 있다. 이러한 구조는 각 단계별 산출물에 대해 정형화된 검증이 가능하도록 하며, 품질 확보와 결함의 조기 식별에 유리한 구조를 제공한다.

Fig. 1

V-Model development process

2.2 Virtual ECU 기반 검증 연구

AUTOSAR(Automotive Open System Architecture) 기반 개발 환경에서는 Virtual MCAL을 포함하는 Level 3 수준의 Virtual ECU를 구성하여 기능 검증에 활용한 사례가 보고되었으며, 차량 시스템 수준에서도 통신 구조와 기능을 사전에 검토하는 수단으로 활용 가능성이 논의되어 왔다.^9,10) 하지만 Virtual ECU는 Real ECU와 실행 환경이나 MCAL 구조가 다르기 때문에, 하드웨어 인터럽트나 레지스터 레벨의 동작까지 동일하게 재현하는 데에는 한계가 있다. 이러한 이유로 Virtual ECU를 Real ECU의 완벽한 대체재로 보기보다는, SW 변경 사항을 빠르게 확인하기 위한 별도의 검증 수단으로 보는 것이 적절하다.

저자들의 선행 연구에서도 Level 3 Virtual ECU를 구축해 CAN 통신 기반의 Task 주기 동작 확인과 로직 검증을 수행하여, Virtual ECU를 기능 검증 도구로서의 가능성을 확인한 바 있다.¹¹⁾ 다만, 이 연구는 Virtual ECU 개발과 신뢰성 확인에 목표를 두었기 때문에, 실제 개발 프로세스에서 반복적으로 발생하는 SW 변경을 자동화하고 SILS 실행까지 연계하는 운영 구조는 후속 과제로 남아 있었다.

현업에서는 SW가 수정될 때마다 Real ECU와 Virtual ECU의 프로젝트 형상을 각각 관리해야 하다 보니, 이 과정에서 업무 부담이 커지고, 변경 사항이 누락되거나 검증이 지연되는 일이 자주 발생한다. 기존 연구들 역시 가상 검증 환경의 구성 방법이나 활용 사례에 주로 초점을 맞췄을 뿐, 코드 변경을 자동으로 반영하고 빌드부터 SILS 실행까지 하나의 CI 파이프라인으로 연결하는 구조에 대해서는 구체적인 방법이 제시되지 않았다. 본 연구는 이러한 점에 착안하여, 선행 연구에서 확보한 Virtual ECU 자산을 바탕으로 Context 기반 자동 패치 기법과 Jenkins 병렬 빌드 구조를 결합하여 실무 운영 효율을 높이고자 한다.

2.3 기존 Jenkins 기반 Real ECU 빌드 구조

기존 ECU 개발 환경에서는 Jenkins를 활용한 CI(Continuous Integration) 빌드 파이프라인이 구성되며, ASW 및 AUTOSAR 설정 코드 변경 이후 ECU용 바이너리 파일을 생성하는 것을 목적으로 한다.^12,13) 해당 파이프라인은 Fig. 2에 나타낸 바와 같이 4단계로 구성되며, ECU 단일 타겟에 대한 자동화된 빌드를 수행하는 전통적인 Jenkins 기반 구조이다.

Fig. 2

Jenkins-based real ECU build process

빌드 흐름은 Developer가 ASW 및 AUTOSAR 설정 코드를 수정하여 PTC Repository에 Check-in 하는 시점부터 시작된다. 이후 빌드 요청이 발생하면 Jenkins Build Node에서 파이프라인이 실행되며, 사전에 정의된 단계에 따라 빌드 절차가 순차적으로 수행된다. Fig. 2의 1) Checkout 단계에서는 ECU 프로젝트 코드와 관련 파일을 Jenkins 작업 공간으로 가져온다. 이어서 2) Code Generation 단계에서는 EB tresos를 이용해 ARXML 기반의 MCAL 및 BSW 코드를 생성하며, 생성된 결과물은 이후 ECU 빌드를 위한 입력으로 사용된다. 다음으로 3) Build 단계에서는 Tasking Compiler를 이용해 Real ECU 빌드를 수행하고, ECU용 Hex 파일을 생성한다. 마지막으로 4) Artifact 단계에서는 생성된 바이너리 파일(Hex)과 빌드 로그를 Jenkins 산출물로 보관하여 이후 조회 및 다운로드가 가능하도록 저장한다.

3.1 리소스 동기화 (Resource Synchronization)

리소스 동기화 단계는 Real ECU 프로젝트에서 생성된 최신 헤더(Include) 및 소스(Source) 파일을 Virtual ECU 타겟 디렉터리로 복사하여, 두 환경 간의 기반 코드 형상을 동일하게 유지하는 과정이다. Fig. 3은 코드 동기화를 위한 리소스 복사 절차를 보여준다. 이 단계에서는 디렉터리 내의 파일을 재귀적으로 순회하며, Real ECU 산출물을 기준으로 Virtual ECU가 동일한 기반 코드(Base code)를 공유할 수 있으며, 이후 자동 패치 적용의 일관성을 보장하고 Virtual ECU 환경에서 최신 ASW 구성을 확보하기 위한 기반을 제공한다.

Fig. 3

Pseudo-code of resource synchronization

3.2 코드 정제 (Artifact Pruning)

코드 정제 단계는 Fig. 4와 같은 구조로 Virtual ECU 시뮬레이션 환경에서 불필요하거나 하드웨어 종속적인 파일들을 자동으로 제거하는 과정이다. 삭제 대상은 별도의 설정 파일로 관리되며, 주석 및 공백 라인은 무시하고, 디렉터리 경로나 범위를 벗어나는 경로는 자동으로 필터링되도록 구현하였다. 이를 통해 삭제 대상을 유연하게 변경할 수 있으며, SILS 환경에 필요한 최소 구성 요소만을 포함함으로써 실행 환경의 경량화와 안정성을 동시에 달성할 수 있다.

Fig. 4

Pseudo-code of artifact pruning

3.3 문맥 기반 패치 (Context-aware Patching)

문맥 기반 패치(Context-aware patching) 단계는 본 Patch tool의 핵심 기능으로, ASW 변경 사항을 기술한 JSON 데이터를 입력으로 받아 지정된 코드 파일에 대해 자동 수정 작업을 수행한다. 각 JSON 규칙 파일은 Context, Delete line, Add line의 세 항목으로 구성되며, 코드 내 특정 문맥의 문자열을 기준으로 삽입 또는 삭제 위치를 식별하는 방식으로 동작한다. 구체적으로는 대상 파일에서 Context 문자열을 탐색한 후, 해당 위치를 기준으로 Delete line과 일치하는 코드가 존재할 경우 이를 제거하고, Add line을 삽입한다. 이 과정은 라인 번호에 의존하지 않고 문맥 기반 탐색을 통해 수행되기 때문에, 코드 생성 과정에서 라인 수나 위치가 변경되더라도 패치 규칙의 적용 가능성을 유지할 수 있다. 모든 수정은 변경이 실제로 발생한 경우에만 반영되며, 이를 통해 Virtual ECU 프로젝트가 최신 ASW 구성에 맞춰 자동으로 재구성된다.

또한 Patch tool은 Fig. 5의 의사 코드와 같이 각 JSON 규칙에 대해 대상 파일 존재 여부, Context 탐색 성공 여부, Delete line 매칭 여부, Add line 삽입 여부를 로그로 기록한다. Jenkins 기반 CI 파이프라인에서는 로그를 바탕으로 Patch summary를 생성하며, 이를 통해 패치 적용 결과를 단계별로 확인할 수 있다. 필수 규칙이 적용되지 않은 경우에는 후속 Virtual ECU 빌드 또는 SILS 실행 단계에서 이를 확인할 수 있도록 구성하였다. 이를 통해 개발자는 패치 수행 여부뿐만 아니라, 필요한 변경사항이 실제로 반영되었는지를 검토할 수 있다. 다만 본 방식은 라인 번호 변화에는 비교적 강건하지만, 코드 변경으로 인해 Context 문자열 자체가 크게 달라지는 경우에는 적용 한계가 있을 수 있다.

Fig. 5

Pseudo-code of context-aware patching

4.1 EPC 기반 Virtual MCAL 및 Virtual ECU 생성

본 절에서는 dSPACE 사의 SystemDesk 도구를 활용하여, 양산 ECU 프로젝트에서 생성된 AUTOSAR EPC(ECU Parameter Configuration) 파일을 기반으로 Virtual MCAL을 생성하고, Level 3 수준의 Virtual ECU를 구축하는 절차를 설명한다.

Virtual ECU 생성은 Real ECU 프로젝트의 EPC 파일을 SystemDesk에 불러오는 것으로 시작되며, 해당 정보를 기반으로 Virtual MCAL이 생성된다. 이후 ASW 및 BSW에 해당하는 소스 코드와 헤더 파일을 SystemDesk 프로젝트에 통합함으로써, Virtual ECU가 실제 양산 SW와 동일한 로직을 수행할 수 있도록 한다. 이후 PC 시뮬레이션 타겟 (예: Windows/Linux)에 맞춰 OS (Operating System) 및 TASK 스케줄링을 조정하고, 최종적으로 가상 환경에서 실행 가능한 FMU (Functional Mock-up Unit) 형태의 Virtual ECU를 생성한다. 생성된 Virtual ECU는 SILS 환경 내에서 통신 메시지 송수신, 내부 변수 모니터링 등이 가능한 독립적 시뮬레이션 단위로 활용된다. 단, 본 연구는 Virtual MCAL의 내부 생성 로직 구현보다는, 상용 도구에서 제공하는 기능을 활용해 ASW 변경 자동 반영 및 검증 자동화에 중점을 두었다.

4.2 Real ECU - Virtual ECU 병렬 빌드 파이프라인

해당 연구에서는 기존 Jenkins 기반 ECU 단일 빌드 구조를 확장하여, Real ECU와 Virtual ECU를 하나의 파이프라인 내에서 병렬 처리하는 구조를 구현하였다. 제안 구조의 핵심은 동일한 코드 형상 기반에서 ECU 빌드 흐름을 유지하되, Virtual ECU 생성을 위한 별도 빌드 경로를 추가하여 두 타겟을 동시에 처리하는 데 있다. 개발자가 ASW 및 AUTOSAR 설정 코드를 PTC Repository에 Check-in 하면 Jenkins Build Node에서 파이프라인이 실행되며, Real ECU와 Virtual ECU 빌드가 분기되어 병렬로 수행된다. ECU는 기존 방식과 동일하게 ARXML 기반 MCAL·BSW·ASW를 결합하여 Hex 파일을 생성하고, Virtual ECU는 Virtual MCAL을 적용하여 SystemDesk를 통해 FMU 파일로 빌드 된다. 이처럼 하나의 빌드 파이프라인에서 Hex와 FMU 파일을 동시에 생성함으로써, 동일 변경 시점을 기준으로 Real ECU와 Virtual ECU를 병렬 처리하고 SILS 실행까지 연계하는 자동화된 검증 환경을 구성하였다. 이러한 흐름은 산업 현장에서 요구되는 빠른 변경 대응과 Virtual ECU 기반 검증 적용을 보다 효율적으로 지원할 수 있다.

4.3 Virtual ECU 기반 SILS 구성 및 실행 자동화

병렬 빌드 파이프라인을 통해 Virtual ECU FMU가 생성되면, 이를 기반으로 SILS 환경이 자동 실행된다. Fig. 6은 Real ECU와 Virtual ECU의 병렬 빌드 이후 SILS 환경이 연속적으로 구성 및 실행되는 흐름을 나타낸다. Fig. 6의 하단에 도시된 SILS Environment Set-Up & Test 절차에 따라, 먼저 1) Import Virtual ECU FMU 단계에서는 FMU 파일을 dSPACE VEOS 환경에 로드하여 Virtual ECU 인스턴스를 구성한다. 이어서 2) Import Virtual Plant Models 단계에서는 Simulink 기반의 플랜트, 센서, 액추에이터 모델을 함께 Import 한다. 이후 3) Configure Virtual CAN Bus & Connect 단계에서는 DBC(Database CAN) 파일을 기반으로 Virtual CAN(Controller Area Network) Bus를 구성하고, Virtual ECU와 각 모델 간 통신 및 Signal 연결을 설정한다. 이를 통해 SILS 환경 구성이 완료되면, 4) Execute Test & Logging 단계에서 정의된 테스트 시나리오에 따라 시뮬레이션이 자동 실행되며, 이때 발생하는 로그 및 출력 Signal은 서버 환경에 저장되어 이후 동작 검증 및 분석을 위한 데이터로 활용된다. 이와 같이 병렬 빌드와 SILS 실행이 하나의 연속 흐름으로 구성됨으로써, Real ECU 및 Virtual ECU 빌드 결과가 동일한 자동화 흐름 내에서 시뮬레이션 기반 실행 단계로 연결되도록 구현하였다.

Fig. 6

Overview of dual-build and SILS automation pipeline

5.1 Test Case

검증을 위한 테스트 케이스로 SW 개발 단계에서 빈번하게 발생하는 RTE (Run-Time Environment) Port 연결 변경과 CAN 메시지 수정 사례를 선정하였다. 테스트 대상이 되는 시스템은 Redundant 구조를 가지며, 2개의 ECU와 2개의 Battery로 구성된다. 각 ECU는 서로의 정보를 포함하여 Battery 전압 정보를 Inter-ECU CAN Bus를 통해 송수신한다. Fig. 7은 해당 시스템 내 Signal 흐름을 간략화한 구조도이다.

Fig. 7

System signal flow diagram

각 ECU는 자체 Battery 전압 정보를 SW ADC를 통해 측정하고, 이를 Diagnostic SWC (Software Component)에 Sender-Receiver Interface를 통해 전달한다. 본 테스트 케이스에서는 기존 RTE Port 연결을 제거하고, 상대 ECU의 Battery 전압 정보를 이용하여 고장 진단을 수행하도록 RTE Port 간 연결을 변경하였다. 또한, 고장 상태를 CAN 통신을 통해 송출하기 위해 새로운 CAN Signal인 ECUx_Fault를 정의하였으며, 이에 따라 DBC 파일과 ASW 코드도 변경하였다.

요약하면, 각 ECU는 자신의 Battery 전압이 아닌 상대 ECU의 Battery 전압 정보를 이용해 고장 여부를 판단하고, 그 결과를 CAN Bus를 통해 전송하도록 구성된다. 테스트 시나리오에 따른 단계별 시퀀스는 Table 1과 같다.

Table 1

Test scenario sequence

각 시퀀스에 대한 기대 동작 결과는 Table 2와 같다. 예를 들어, Sequence 2에서는 ECU2의 Battery 고장을 의도적으로 주입하고, ECU1은 ECU2의 전압 정보를 기반으로 고장을 판단하여 CAN Tx Signal로 고장 상태를 송신한다. 반면, ECU2는 ECU1의 전압 정보를 기반으로 고장을 판단하기에 정상 상태로 진단하고, CAN Tx Signal로 정상을 표출한다.

Table 2

Expected result

추가로, Jenkins 파이프라인에서 자동화 Patch tool이 단계별로 의도한 코드 수정을 정확히 수행했는지 확인하기 위해, 실행된 패치 로그를 분석하였다.

5.2 Test 환경 및 구성

Real ECU SW 테스트 환경은 Photo 1과 같다. Photo 1의 ①은 테스트 대상인 ECU1 및 ECU2를 나타내며, ②와 ③은 각각의 ECU 전원 라인에 연결된 Power supply로, Battery 전압을 조절할 수 있도록 하였다. ④는 VN1640 장비로, 본 장비를 활용하여 CAN Bus 모니터링을 수행한다.

Photo. 1

Real ECU test setup

Virtual ECU SW 테스트 환경은 Fig. 8과 같이 Plant model을 통해 Virtual ECU에 Battery 값을 입력하고, Fault 발생시 Virtual ECU가 Fault Signal을 Virtual CAN Bus를 통해 출력하도록 구현하였다. 또한, 가상의 Inter-ECU CAN Bus를 통해 서로의 Battery 전압 정보를 주고 받도록 구성하였다.

Fig. 8

Virtual ECU simulation architecture

5.3 Test 결과 및 고찰

SW 변경 사항에 대해 동일 프로젝트 형상을 기반으로 Jenkins Job을 구성하고, 자동화 Patch tool 적용 후 Real ECU와 Virtual ECU를 병렬 빌드하였다.

자동화 Patch tool 적용 결과, 리소스 동기화 단계에서는 빌드 시 생성되는 코드 675건과 프로젝트 종속 코드 125건을 포함한 총 800건의 파일이 모두 정상 동기화되었다. 이어 코드 정제 단계에서는 기 설정한 45건의 제거 대상 파일이 모두 정제되었으며, 마지막 문맥 기반 패치 단계의 경우 설정된 11개 파일에 대해 모두 패치가 적용되어 100 % 적용률을 확인하였다(Table 3).

Table 3

Patch tool application results

이후, Real ECU SW를 실제 테스트 환경에서 검증하기 위해 Reprogram 하였고, Virtual ECU는 dSPACE VEOS 환경에 Import 하여 SILS 실행 환경을 구성하였다. 이후 사전에 정의한 테스트 케이스에 따라 실험을 수행하였다. 그 결과, Fig. 9와 같이 Real ECU와 Virtual ECU 모두 ECU2의 Battery 전압을 조절하였을 때 ECU1이 고장 상태로 판단하여 CAN Signal을 통해 고장을 표출하였다. 반면 ECU1의 Battery 전압은 정상 상태로 유지되었기 때문에, ECU2는 정상 상태로 판단하여 CAN Signal을 출력하지 않았다. 이는 Table 2 Expected result와 일치하는 결과이다.

Fig. 9

Comparison of fault detection results for real and virtual ECUs

추가로, 고장 진단 로직의 신뢰성 검증을 위해, Battery 전압이 22V 이상으로 500 ms 이상 유지되었을 때 고장으로 판단하는 요구 사항을 적용하였다. Fig. 9의 주요 부분을 확대한 Fig. 10을 참고하면 Real 및 Virtual ECU 모두 해당 조건에서 CAN Signal을 통해 고장이 표출되었음을 확인하였으며, 이를 통해 진단 로직이 정상적으로 동작함을 입증하였다.

Fig. 10

Fault diagnosis under battery voltage conditions

이상의 실험 결과를 통해, Real ECU SW에 적용된 CAN 메시지 수정 사항과 RTE Sender-Receiver Port 연결 변경 사항이 정상적으로 반영되었음을 확인하였다. 또한 자동화 Patch tool이 의도한 대로 동작하여 Virtual ECU에도 동일한 변경 사항이 정확히 적용되었음을 확인하였다. 이후 병렬 빌드까지 성공적으로 수행되었으며, 빌드 산출물을 활용한 테스트를 기반으로 Jenkins 파이프라인을 통해 생성된 Virtual ECU에 대한 동작 신뢰성과 유효성을 확인하였다.