공하는 CANdelaStudio 툴은 진단 사양을 정의하기 위한 목적으

로 전세계적으로 도입되었다. 특히 이 툴은 국제 Open Diagnos-

tic data eXchange 표준(ODX, ISO22901) [3]을 지원한다. 이 표

준은 2008년에 발표되었으며 현재 전세계 대부분의 차량 제조업

체들이 사용하고 있다.

따라서 진단 프로토콜의 자동 생성을 위한 기술적 전제조건은 이

미 오래 전에 충족되었다. 그러므로 벡터의 CANoe.DiVa 툴과 같

은 자동 진단 테스트 생성을 위한 솔루션이 이미 마련되어10년

넘게 실행되고 있음은 분명하다.

CANdela 또는 ODX 포맷의 진단 정보 및 진단 프로토콜(예: UDS,

KWP2000, OBD, WWH-OBD, …)을 바탕으로 하여 매우 포괄적인

테스트가 자동으로 생성된다. 이러한 테스트는 ECU 내 오류 처

리를 테스트에 포함시키는 유효한 요청 및 유효하지 않은 요청을

모두 다룬다. 이 테스트는 CANoe에 로드되어 자동으로 실행된

다. 이 테스트의 결과는 상세한 보고서로 작성된다 [그림 1]. 더

큰 규모의 ECU의 경우, 중복되는 테스트 없이 빠르게 10,000개

이상의 테스트 케이스가 생성된다.

지난 2006년의 Unified Diagnostic Services(UDS) 표준

(ISO14229) [1]의 배포는 진단 테스트 자동화를 위한 중요한 한

걸음이었다: 이 표준이 진단 서비스의 규격을 통일함에 따라, 사

상 처음으로 심도 깊은 수준으로 여러 제조업체를 대상으로 하는

(cross-manufacturer) 진단 프로토콜 테스트를 실행할 수 있게 되

었다. 이전의 프로토콜인 KWP2000(ISO14230) [2]은 여전히 광범

위한 자유도를 허용하였으며, 이에 따라 각 OEM 고유의 방식을

통해 좀더 구체적으로 만들어야만 한다. 그리고 이것은 보편적으

로 유효한 테스트를 구현하는 것을 더욱 어렵게 만든다. UDS의

개정된 버전은 2013년도에 발표되었으며, 이 개정 표준 덕분에

훨씬 더 상세한 프로토콜 테스트를 만드는 것이 가능하다.

프로토콜 정의 외에도, 형식에 맞춰 기술된 진단 데이터는 테스

트 생성(test generation)을 위한 두 번째로 중요한 전제조건에

해당된다. 차량의 파워 윈도우의 기능적 범위는 엔진 ECU의 기

능적인 범위와는 본질적인 차이가 있으며, 이에 따라 실행되는

진단 기능 또한 서로 다르다. 테스트를 자동으로 생성하기 위해

서는 ECU에서 실행되는 진단 서비스를 알아야 한다. 벡터가 제

진단 검증(diagnostic validation)에 대한 기술 기사는 대개 다음과 같은 문장으로 시작된다: 차량의 ECU의 복잡성이 점점 증가됨

에 따라 진단의 범위 또한 넓어지고 있으며, 진단 검증에 필요한 시간과 노력 또한 증가하고 있다. 하지만 다행히도 오늘날의 테스

트 툴 덕분에 검증에 필요한 시간과 노력은 더 이상 선형적으로 증가하는 추세는 아니다. 특히 근 수년 동안 완전히 자동화된 진단

프로토콜 테스트를 만들고 실행할 수 있게 되었다. 기능이 더욱 증가함에도 불구하고 테스트 생성과 실행에 필요한 시간과 노력은

거의 일정한 수준으로 유지되고 있다. 진단 통신 서비스 UDS와 진단 데이터 포맷 ODX에 대한 표준이 수립됨에 따라, 비교적 높은

수준의 테스트 자동화를 달성할 수 있으며, 그 결과 높은 진단 품질을 제공할 수 있다. 그뿐만 아니라 진단 어플리케이션과 업데이

트 소프트웨어의 테스트 역시 자동화될 수 있다. 오늘날 테스트 자동화에서 이처럼 높은 잠재력을 지닌 자동차 전자 개발 분야는

매우 적다.

단지 실행 가능한 기존 방안들을 활용하여 결론을 맺는 것이다.

자동 진단 검증은 로켓 과학이 아니다.

Insert figure

그림1: CANoe.DiVa 자동 테스트 환경의 기능 블록

실제로 지금은 거의 모든 ECU에 대해 CANdela와 ODX 포맷으로

형식을 갖춘 진단 사양 기술이 가능하다. 그러므로 이는 진단 사

양부터 종합적이고 자동화된 프로토콜 테스트까지 나아가기 위

한 작은 발걸음이다. 초기에 작은 노력만 기울인다면 간단하게

프로토콜 오류를 검출할 수 있다.

AUTOSAR, 진단 프로토콜의 품질을 향상시키다

진단용 AUTOSAR 소프트웨어 컴포넌트가 사용되는 경우, 테스터

가 유발하는 일련의 프로토콜 위반(예, 포맷 위반)은 응용 소프트

웨어 레리어가 아닌 기본 소프트웨어 레이어에서 처리한다. 일반

적으로 ECU의 기본 소프트웨어는 가용 진단 데이터를 직접 파라

미터로 사용하기 때문에, 대개 ECU가 테스터로 보내는 진단 응

답 또한 프로토콜을 준수한다. 따라서 AUTOSAR 소프트웨어 컴

포넌트가 사용되는 경우, 단순한 프로토콜 오류의 비율은 눈에

띄게 감소한다. 그 결과 테스트 평가와 문제해결에 필요한 시간

과 노력도 크게 줄어든다. 그럼에도 불구하고 특히 다음과 같은

이유로 인하여 프로토콜 테스트는 여전히 중요하다:

> AUTOSAR 컴포넌트, 컴포넌트 통합 그리고 어플리케이션

개발을 구성하는 도중에 오류가 발생할 수 있다. > ECU의 진단 데이터가 진단 테스터가 사용하는 진단 데이터와

일치하지 않는 경우, “올바른” 실행에도 불구하고 ECU 내의

올바른 진단이 가능하지 않을 수도 있다. > 어플리케이션에서 에러 처리하는 방식이 맞지 않는 경우

악성 코드를 설치하더라도 찾아내지 못할 수 있다.

DoIP와 OTA(over the air) 시에는 진단 테스터와 ECU가 직접 연

결이 필요하지 않기 때문에, 프로토콜 오류는 전체 차량군에서

이러한 서비스에 부정적인 영향을 끼칠 수도 있다. 예를 들면 원

격 진단시 사용할 수 있는 진단 항목의 제한으로 완전한 차량 진

단이 안될 수 있다. 필요한 진단 기능이 원하는 대로 작동되지 않

기 때문에, 결국 정비소에서 정비하는데 많은 시간이 소모된다.

최악의 경우에 프로토콜 에러는 안전에 치명적인 차량에 대한 공

격을 허용할 수도 있다. 차량은 끊임없이 사용되기 때문에, 앞으

로 진단 기능에 관련하여 고객들이 경험할 수 있는 새로운 사용

사례가 생겨날 것이며, 아마도 진단 기능의 사용 빈도는 더 잦아

지고 사용 범위는 더 넓어지게 될 것으로 예상된다. 따라서 진단

실행에 대한 품질 요구조건도 앞으로 더욱 증가하고 까다로워 질

것으로 예상할 수 있다.

소프트웨어 업데이트 검증

여러 가지 진단 표준화 조치에도 불구하고, ECU 소프트웨어의 업

데이트를 위한 과정은 여전히 OEM마다 서로 다르다. 사용되는 서

비스가 표준화되어 있음에도 불구하고, 부분 자동 업데이트(incre-

mental update)나 전송 데이터(식별 데이터, 체크섬, 시그니처 등)

를 보호하기 위한 메커니즘과 같은 기능들은 실제로 상당히 다른

플래시(flash) 절차로 이어진다. 또한 각 제조업체별 프로세스 요구

사항을 충족시키기 위하여 서로 다른 플래시 컨테이너(flash con-

tainer) 포맷이 사용된다. 실제로 이것은 거의 모든 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]:

Insert figure

그림3: 수동 검증과 자동 검증에 소요되는 테스트 시간과 노력을

비교한 실제 사례 [5]

> 시험 결과의 선별적이고 필요에 기반한 검토를 위한 분류 및

필터링 > 동일한 원인의 연결 오류 > 오류와 그 원인을 분류하기 위하여 각각의 시험 결과에

코멘트를 추가하기, 시정조치에 대한 메모 작성하기, 문제

해결방법 관리하기 > 하나의 테스트 런으로부터 다른 테스트 런으로 오류 분석

결과를 전송하기 > 기존의 프로세스에 통합하기 위하여 테스트 솔루션을 기존의

테스트 데이터 관리 시스템 또는 요구사항 시스템에 연결하기

결론 및 전망

ECU의 진단 범위는 점점 넓어지고 품질 요구사항은 계속해서 증

가하게 될 것이다. 하지만 진단 검증에 필요한 시간과 노력을 크

게 감소시켜 주면서 한편으로는 테스트의 범위를 크게 넓히고 더

욱 심도 있게 만드는 자동화 솔루션은 지금도 이미 존재한다. 대

부분의 경우 이를 위하여 필요한 형식을 갖춘 진단 DB를 사용할

수 있다. 또한 테스트 목적을 위한 이 데이터의 재사용은 매우

간단하고 논리적이다. 차량의 경계를 넘어서는 네트워크가 점점

증가함에 따라, 자동차의 사이버 보안에 대한 문제도 더욱 빠르

게 증가하고 있다. “Testing security”[4]와 “Testing despite secu-

rity”, 즉 “보안 검사”와 “보안과 무관한 검사”는 이제 다양한 개발

Insert figure

그림2: CANoe.DiVa: Software 및 Hardware in-the-loop

Christph Rätz

Christoph Rätz는 Vertor Informatik GmbH에서 Diagnostic Product

Line Head이다.

Simon Müller

Simon Müller는 Vertor Informatik GmbH에서 Diagnostic Product Line

의 CANoe.DiVA Product Manager이다.

독일 Hanser Automotive 3-4/2017호의 기술기사입니다.

이미지 권리: Vector Informatik GmbH

참고문헌:

[1] - [3] International Organization for Standardization: ISO

14229 (UDS), ISO 14230 (KWP2000), ISO 22901 (ODX)

[4] Metzger E.; 2016: Presentation: The Vector Security Solu-

tion, Vector Cyber Security Symposium 2016

[5] Peti P., Timmerberg A., Pfeffer T., Müller S., Rätz C.; 2008:

Automatic validation of diagnostic services, ATZ elektronik

06I2008

분야에서 중요한 주제가 되고 있다. 소위 “over the air”, 즉 무선

을 통한 확장된 차량 액세스는 차량 진단을 위한 새로운 어플리

케이션의 영역을 열고 있으며, 결국 이것은 충분한 보호가 이루

어져야 한다. 다양한 혁신들이 소프트웨어와 주요 툴에서 처음부

터 사용자 친화적인 방식으로 지원되어야만 이러한 혁신들이 양

산 체계(serial production)에 바로 적용될 수 있다. 이것은 복잡

하고 어려운 기술이 아니라 소프트웨어 벤더들에 대한 흥미로운

도전일 뿐이다.