앞으로 진단 기능 관련하여 고객들이 경험할 수 있는 새로운 사용 사례가 생겨날 것이며, 아마도 진단 기능의 사용 빈도는 더 잦아지고 사용 범위는 더 넓어지게 될 것이다. 따라서 진단 실행에 대한 품질 요구조건도 더욱 증가하고 까다로워질 것으로 예상된다.


 크리스토프 라에츠*, 진단 제품 라인 담당 부장(좌) 
 사이먼 뮐러**, 진단 제품 라인의 CANoe.DiVA 제품 매니저
 Vertor Informatik GmbH

진단 검증(Diagnostic validation)에 대한 기술기사는 대개 다음과 같은 문장으로 시작한다: 차량 ECU의 복잡성이 점점 증가함에 따라 진단의 범위 또한 넓어지고 있으며, 진단 검증에 필요한 시간과 노력 또한 증가하고 있다. 하지만 다행히도 오늘날의 테스트 툴 덕분에 검증에 필요한 시간과 노력은 더 이상 선형적으로 증가하는 추세는 아니다.

특히 수년 동안 완전히 자동화된 진단 프로토콜 테스트를 만들고 실행할 수 있게 됐다. 기능이 더욱 증가함에도 불구하고 테스트 생성과 실행에 필요한 시간과 노력은 거의 일정한 수준으로 유지되고 있다.

진단 통신 서비스 UDS와 진단 데이터 포맷 ODX에 대한 표준이 수립됨에 따라, 비교적 높은 수준의 테스트 자동화를 달성할 수 있으며, 그 결과 높은 진단 품질을 제공할 수 있다. 그뿐만 아니라 진단 애플리케이션과 업데이트 소프트웨어의 테스트 역시 자동화될 수 있다. 오늘날 테스트 자동화에서 이처럼 높은 잠재력을 지닌 자동차 전자 개발 분야는 매우 적다.


지난 2006년 Unified Diagnostic Services(UDS) 표준(ISO14229)^[1] 배포는 진단 테스트 자동화를 위한 중요한 한 걸음이었다: 이 표준이 진단 서비스의 규격을 통일함에 따라 사상 처음으로 심도 깊은 수준으로 여러 제조업체를 대상으로 하는(cross-manufacturer) 진단 프로토콜 테스트를 실행할 수 있게 됐다.

이전의 프로토콜인 KWP2000(ISO14230)^[2]은 여전히 광범위한 자유도를 허용했으며, 이에 따라 각 OEM 고유의 방식을 통해 좀 더 구체적으로 만들어야만 한다. 그리고 이것은 보편적으로 유효한 테스트를 구현하는 것을 더욱 어렵게 만든다. UDS의 개정된 버전은 2013년도에 발표됐으며, 이 개정 표준 덕분에 훨씬 더 상세한 프로토콜 테스트를 만들 수 있게 됐다.

프로토콜 정의 외에도, 형식에 맞춰 기술된 진단 데이터는 테스트 생성(test generation)을 위한 두 번째로 중요한 전제 조건에 해당된다. 차량의 파워 윈도의 기능적 범위는 엔진 ECU의 기능적인 범위와는 본질적인 차이가 있으며, 이에 따라 실행되는 진단 기능 또한 서로 다르다. 테스트를 자동으로 생성하기 위해서는 ECU에서 실행되는 진단 서비스를 알아야 한다.

벡터가 제공하는 CANdelaStudio 툴은 진단 사양을 정의하기 위한 목적으로 전 세계적으로 도입됐다. 특히, 이 툴은 국제 Open Diagnostic data eXchange 표준(ODX, ISO22901)^[3]을 지원한다. 이 표준은 2008년 발표됐으며 현재 전 세계 대부분의 차량 제조업체들이 사용하고 있다.

따라서 진단 프로토콜의 자동생성을 위한 기술적 전제 조건은 이미 오래 전에 충족됐다. 그러므로 벡터의 CANoe.DiVa 툴과 같은 자동 진단 테스트 생성을 위한 솔루션이 이미 마련돼 10년 넘게 실행되고 있음은 분명하다.

CANdela 또는 ODX 포맷의 진단 정보 및 진단 프로토콜(예: UDS, KWP2000, OBD, WWH-OBD, …)을 바탕으로 매우 포괄적인 테스트가 자동으로 생성된다. 이러한 테스트는 ECU 내 오류처리를 테스트에 포함시키는 유효한 요청 및 유효하지 않은 요청을 모두 다룬다. 이 테스트는 CANoe에 로드되어 자동으로 실행된다. 이 테스트 결과는 상세한 보고서로 작성된다(그림 1). 더 큰 규모의 ECU 경우, 중복되는 테스트 없이 빠르게 10,000개 이상의 테스트 케이스가 생성된다.


실제로 지금은 거의 모든 ECU에 대해 CANdela와 ODX 포맷으로 형식을 갖춘 진단 사양 기술이 가능하다. 그러므로 이는 진단 사양부터 종합적이고 자동화된 프로토콜 테스트까지 나아가기 위한 작은 발걸음이다. 초기에 작은 노력만 기울인다면 간단하게 프로토콜 오류를 검출할 수 있다.

AUTOSAR, 진단 프로토콜 품질 향상

진단용 AUTOSAR 소프트웨어 컴포넌트가 사용되는 경우, 테스터가 유발하는 일련의 프로토콜 위반(예, 포맷 위반)은 응용 소프트웨어 레이어가 아닌 기본 소프트웨어 레이어에서 처리한다. 일반적으로 ECU의 기본 소프트웨어는 가용 진단 데이터를 직접 파라미터로 사용하기 때문에, 대개 ECU가 테스터로 보내는 진단 응답 또한 프로토콜을 준수한다.

따라서 AUTOSAR 소프트웨어 컴포넌트가 사용되는 경우, 단순한 프로토콜 오류의 비율은 눈에 띄게 감소한다. 그 결과 테스트 평가와 문제해결에 필요한 시간과 노력도 크게 줄어든다. 그럼에도 불구하고 특히 다음과 같은 이유로 인하여 프로토콜 테스트는 여전히 중요하다:

- AUTOSAR 컴포넌트, 컴포넌트 통합 그리고 애플리케이션 개발을 구성하는 도중에 오류가 발생할 수 있다.
- ECU의 진단 데이터가 진단 테스터가 사용하는 진단 데이터와 일치하지 않는 경우, “올바른” 실행에도 불구하고 ECU 내의 올바른 진단이 가능하지 않을 수도 있다.
- 애플리케이션에서 에러 처리하는 방식이 맞지 않는 경우 악성 코드를 설치하더라도 찾아내지 못할 수 있다.

DoIP와 OTA(over the air) 시에는 진단 테스터와 ECU가 직접 연결이 필요하지 않기 때문에, 프로토콜 오류는 전체 차량군에서 이러한 서비스에 부정적인 영향을 끼칠 수도 있다. 예를 들면 원격 진단 시 사용할 수 있는 진단 항목의 제한으로 완전한 차량 진단이 안 될 수 있다. 필요한 진단 기능이 원하는 대로 작동되지 않기 때문에, 결국 정비소에서 정비하는데 많은 시간이 소모된다. 최악의 경우에 프로토콜 에러는 안전에 치명적인 차량에 대한 공격을 허용할 수도 있다.

차량은 끊임없이 사용되기 때문에, 앞으로 진단 기능에 관련하여 고객들이 경험할 수 있는 새로운 사용 사례가 생겨날 것이며, 아마도 진단 기능의 사용 빈도는 더 잦아지고 사용 범위는 더 넓어지게 될 것으로 예상된다. 따라서 진단 실행에 대한 품질 요구조건도 더욱 증가하고 까다로워질 것으로 예상할 수 있다.

소프트웨어 업데이트 검증

여러 가지 진단 표준화 조치에도 불구하고, ECU 소프트웨어의 업데이트를 위한 과정은 여전히 OEM마다 서로 다르다. 사용되는 서비스가 표준화돼 있음에도 불구하고, 부분 자동 업데이트(incremental update)나 전송 데이터(식별 데이터, 체크섬, 시그니처 등)를 보호하기 위한 메커니즘과 같은 기능들은 실제로 상당히 다른 플래시(flash) 절차로 이어진다. 또한 각 제조업체별 프로세스 요구사항을 충족시키기 위해 서로 다른 플래시 컨테이너(flash container) 포맷이 사용된다.

실제로 이것은 거의 모든 OEM을 위한 개별적인 소프트웨어 업데이트 툴들이 존재한다는 것을 의미한다. 그러므로 공급업체는 이처럼 다양한 툴을 사용해 작업해야 할 뿐만 아니라, 때로는 각각의 OEM을 위한 개별적인 테스트 환경을 개발하고 이를 유지해야 한다. 잘 동작하는 플래시 절차는 항상 생산 및 정비 시의 필수적인 요소이다. 장래에 있을 소프트웨어 업데이트인 “over the air”(SOTA)를 고려하면 신뢰할 수 있는 차량 소프트웨어 업데이트 기능은 그 어느 때보다도 중요하다.

아마도 앞으로는 새로운 가능을 가진 새로운 소프트웨어가 더욱 자주 탑재될 것이다. 이러한 빈도는 아마도 우리가 현재 모바일 기기에서 경험하고 있는 수준(예를 들면 보안 취약성 해결을 위한 업데이트의 빈도)이 될 수 있다. 물론 업데이트 실패 끝에 ECU가 더 이상 기능하지 않게 되는 상황은 반드시 피해야 한다. 하지만 유명 스마트폰 제조업체들의 경우를 보면 정교한 보호 수단을 마련하고 있음에도 불구하고 소프트웨어 업데이트가 항상 원활하게 이루어지지는 않는다.

이미 벡터의 리프로그래밍 툴인 vFlash를 사용해 수년 전부터 여러 제조업체에 공통적으로 적용되는(Cross-manufacturer) 소프트웨어 업데이트가 수행돼 왔으며, 현재 모든 관련 차량 제조업체의 90개 이상의 서로 다른 사양의 부트로더에 대하여 이러한 업데이트가 수행되고 있다.

테스트 자동화 툴인 CANoe.DiVa는 vFlash 자동 인터페이스를 사용하고 있으며, 이에 따라 vFlash가 지원하는 모든 부트로더에 대한 자동 소프트웨어 업데이트가 추가적으로 제공된다. 유효한 플래시 절차의 변수(타이밍, 포맷 등) 외에도 플래시 절차의 다양한 지점에서의 중단이나 부족 전압과 같은 기존의 오류 시뮬레이션도 자동으로 테스트된다. 이를 통해 ECU 소프트웨어의 강건성(robustness)을 쉽고 종합적으로 테스트할 수 있다.

설명된 테스트는 본질적으로는 블랙박스 테스트이다. 이러한 테스트 외의 테스트는(예를 들면 식별 데이터나 시그니처와 같은 프로세스 관련 데이터에 대한 타당성_plausibility 검증) 제조업체마다 다른 상세한 사양을 요구한다. 이미 이러한 유형의 테스트를 위해 유명 제조업체를 위한 별도의 확장(extension)이 존재한다. 소프트웨어 업데이트 시험은 신뢰할 수 있는 데이터 전송 및 오류 발생 시의 안정적인 작동과 같은 필수적인 업데이트 특성들을 보장한다. 이러한 사항에 대한 자동화가 제공하는 편리함은 진단 프로토콜 테스트에 대한 자동화가 주는 편리함과 유사하다.

진단 애플리케이션의 검증

ECU 진단 기능은 형식적인 측면들을 만족시킬 뿐만 아니라, 그 내용 또한 올바른 것이어야 한다. 이것은 합리적인 차량 진단을 보장하는 유일한 방법이다. 현재의 진단 포맷(예: ODX)은 특히 프로토콜의 정의에 집중하고 있다. 그렇지만 자동 테스트 생성을 위하여 이것들로부터 애플리케이션 관련 정보를 추출할 수 있다:

예를 들어 전송된 값의 타당성에 대한 자동 테스트는 이미 정의된 지정된 값의 범위로부터 얻을 수 있다. 구체적인 오류의 원인은 경험적 방법(heuristic method) 또는 제조업체별 지식을 사용해 에러 코드 또는 진단 파라미터로부터 얻을 수 있다. 특정한 자동 시험에서 얻은 통찰력을 실천에 옮기기 위하여(테스트) 환경에 대한 접근을 위한 옵션과 ECU의 시뮬레이션을 위한 옵션이 무엇인지 알아야 한다. 하지만 대부분의 경우 이러한 정보는 ECU 개발 동안 얻을 수 있다:

- 네트워크 아키텍처는 AUTOSAR(.arxml) 또는 CANdb(.dbc) 안에 기술된다. 신호는 버스에서 쉽게 읽을 수 있으며 잔여 버스 시뮬레이션을 통해 조정된다.
- ECU의 메모리 레이아웃은 a2l 파일 내에 기술된다. 파라미터는 XCP를 통해 쉽게 읽고 조정할 수 있다.
- 전기적 입출력과 테스트 구성은 대개 기계적으로 읽을 수 있는 포맷으로 기술된다. 이것은 HiL(Hardware-in-the-Loop) 테스트와 벡터 VT 시스템의 조합(그림 2)를 통해 측정되고 시작될 수 있다.



또한 CANoe.DiVa는 Excel exchange 포맷을 통한 각 기업 고유의 파라미터들과 DTC를 연결시키는 기능을 제공한다. 벡터 CANoe와 같은 통합 테스트 환경에서는 이 모든 소스가 하나의 테스트에 조합되어 사용될 수 있다.

가상 ECU가 개발에 사용되는 경우(예: 벡터 vVIRTUALtarget), 하드웨어 I/O가 소프트웨어에서 쉽게 시뮬레이션 될 수 있기 때문에, 애플리케이션 시험을 위한 테스트 설정은 비교적 간단하다. 애플리케이션 테스트 동안 가능한 자동화의 정도는 분명 프로토콜 시험 동안의 자동화 수준에는 미치지 못한다. 하지만 반자동 테스트 생성 또는 완전 자동 테스트 생성을 위한 다양한 옵션이 마련되고 있으며 이러한 옵션을 활용하는 것은 많은 도움이 된다.

테스트 범위, 테스트 평가, 그리고 추가 프로세싱

적절한 툴을 통해서 달성한 진단 프로토콜 검증에 대한 고도의 자동화 덕분에, 꾸준한 시간과 노력을 기울여 더욱 자동화된 테스트 또는 사용자의 추가적인 자체 테스트를 통해 더욱 심도 깊은 검사를 실시할 수 있다: 점점 더 많은 OEM들이 진단 애플리케이션 케이스를 체계적으로 보호하기 위해 자동 옵션을 활용하고 있다(예: OEM에게 특히 중요한 생산 및 정비에 활용). 따라서 진단 기능은 이미 초기 개발 단계에서 공급업체가 확실하게 보호할 수 있다.

전 세계에서 가장 큰 규모의 여러 OEM들이 현재 CANoe.DiVa의 테스트 지원에 의존하고 있다. 이 과정에서 OEM은 시험 결과의 추가적인 프로세싱에 대한 종합적인 지원을 통해서도 이익을 얻으며, 이는 실제로 많은 시간을 절약할 수 있다(그림 3):



- 시험 결과의 선별적이고 필요에 기반한 검토를 위한 분류 및 필터링
- 동일한 원인의 연결 오류
- 오류와 그 원인을 분류하기 위해 각각의 시험 결과에 코멘트를 추가하기, 시정조치에 대한 메모 작성하기, 문제 해결방법 관리하기
- 하나의 테스트 런으로부터 다른 테스트 런으로 오류 분석 결과를 전송하기
- 기존의 프로세스에 통합하기 위해 테스트 솔루션을 기존의 테스트 데이터 관리 시스템 또는 요구사항 시스템에 연결하기

결론 및 전망

ECU의 진단 범위는 점점 넓어지고 품질 요구사항은 계속해서 증가하게 될 것이다. 하지만 진단 검증에 필요한 시간과 노력을 크게 감소시켜 주면서 한편으로 테스트의 범위를 크게 넓히고 더욱 심도 있게 만드는 자동화 솔루션은 이미 존재한다. 대부분의 경우 이를 위해 필요한 형식을 갖춘 진단 DB를 사용할 수 있다. 또한 테스트 목적을 위한 이 데이터의 재사용은 매우 간단하고 논리적이다.

차량의 경계를 넘어서는 네트워크가 점점 증가함에 따라, 자동차의 사이버 보안에 대한 문제도 더욱 빠르게 증가하고 있다. “Testing security”^[4]와 “Testing despite security”, 즉 “보안 검사”와 “보안과 무관한 검사”는 이제 다양한 개발 분야에서 중요한 주제가 되고 있다. 소위 “over the air”, 즉 무선을 통한 확장된 차량 액세스는 차량 진단을 위한 새로운 애플리케이션의 영역을 열고 있으며, 결국 이것은 충분한 보호가 이루어져야 한다.

다양한 혁신들이 소프트웨어와 주요 툴에서 처음부터 사용자 친화적인 방식으로 지원되어야만 이러한 혁신들이 양산체계(serial production)에 바로 적용될 수 있다. 이것은 복잡하고 어려운 기술이 아니라 소프트웨어 벤더들에 대한 흥미로운 도전일 뿐이다.

참고문헌
[1] - [3] International Organization for Standardization: ISO 14229 (UDS), ISO 14230 (KWP2000), ISO 22901 (ODX)
[4] Metzger E.; 2016: Presentation: The Vector Security Solution, Vector Cyber Security Symposium 2016
[5] Peti P., Timmerberg A., Pfeffer T., Muller S., Ratz C.; 2008: Automatic validation of diagnostic services, ATZ elektronik 06I2008