01

대부분의 경우 ECU의 입출력을 살펴보는 것만으로 컴포넌트를

기능적으로 테스트하기에 충분하다(그림 1). 그러나 상태 머신을

ECU에서 사용하면 이 문제가 어려워진다. 이들의 현재 상태는

ECU 출력에서의 효과를 통해서만 간접적으로 도출될 수 있다. 그

값이 네트워크 시스템을 통해 전송되지 않는 센서의 경우 테스트

엔지니어가 소프트웨어 인터페이스 오류를 찾아내는 것 또한 쉽

지 않다. ECU 외부에서는 센서 값이 잘못 처리된 위치를 정확히

찾아낼 수 없다.

ECU 개발 단계에 따라 내부 ECU 데이터에 대한 액세스를 제공

하는 다양한 방법이 사용된다. 가령, 초기 단계에서는 내부 ECU

값이 소위 “예약된 개발 메시지”로 출력되는 경우가 많다(그림

1). 공급업체의 기능 개발자에게 있어서는 특정 목표를 정확하게

타겟팅하는 효과적이고 빠른 방법일 수 있다. 그러나 후속 개발

단계, 특히 시스템 통합 및 생산의 경우 이러한 추가 메시지를 제

거해야 한다. 추가 버스 부하를 유도할 뿐만 아니라 최악의 경우

다른 시스템 컴포넌트의 메시지와 충돌할 수도 있기 때문이다.

내부 값에 액세스하는 또 다른 방법은 진단을 활용하는 것이다(

그림 1). 일부 정보(예: 진단으로 결함 메모리에 액세스)는 진단을

통해 직접 이용할 수 있다.

메모리에서 필요한 값을 읽을 수 있는 특수 진단 서비스 역시 제

공된다. 이 시스템의 장점은 바로 표준화된 액세스 방법을 사용

한다는 점이다. 유일한 전제 조건은 진단 드라이버를 완전히 통

합하는 것이며 오늘날의 ECU에서는 일반적으로 제공되는 부분

이다.

블랙박스 테스트는 일반적으로 ECU 개발 프레임워크 또는 결함 있는 ECU 동작을 분석하기 위해 활용된다. 여기에는 신호 인가 및

계측을 위해 ECU의 입출력을 테스트 시스템에 연결하는 작업이 포함된다. 이 방법을 통해 테스트 엔지니어가 광범위한 분석을 수행

할 수 있지만, 특정 테스트에서는 ECU를 직접 확인해야 한다. 이것이 유의미한 테스트 결과를 얻거나 테스트에 필요한 리소스를 절

감할 수 있는 유일한 방법이다.

숨겨진 이면

XCP 지원을 통한 ECU 테스트

그림 1: 진단 기능이나 개발자가 생성한 특수 메시지를 통해 ECU 내부 값에 대한 접근이 제한적인 기존의 ECU 테스팅을 위한 테스트 시스템

02

기술기사 / 숨겨진 이면

필요한 신호 인가는 CANoe Rest-of-Bus 시뮬레이션에서 형성되

며 ECU의 반응은 네트워크뿐만 아니라 XCP를 통해 ECU에서 직

접 계측할 수도 있다.

센서가 필요한 테스트 케이스와 같이 테스트 케이스를 실행하는

데 필요한 노력도 크게 줄어든다. 테스트 시스템은 XCP를 통해

ECU의 메모리 셀에 센서 값을 직접 기록한다. 그 덕분에 ECU 입

력에서 기존 센서를 연결하고 제어하는 까다로운 작업을 수행할

필요가 없다. ECU에 센서 및 관련 하드웨어 드라이버가 값을 올

바르게 계측했음을 알리며 다른 방향으로도 동일한 접근 방식을

사용할 수 있다. 출력 단계와 액추에이터를 테스트하고 승인했다

고 가정해보자. 그렇게 하면 테스트 시스템은 XCP를 통해 어플리

케이션이 운전자에게 제공하는 값을 계측한다.

대용량 데이터로의 액세스

테스트 케이스에서 테스트 시스템과 ECU 간에 대량의 데이터를

교환해야 하거나 속도가 빠른 프로세스를 모니터링해야 하는 경

우 CAN 네트워크를 통한 XCP 연결이 더는 효과적이지 않다. 이

러한 경우 ECU의 디버그 인터페이스에 직접 액세스하는 것이 좋

다. 예를 들면 NEXUS 또는 JTAG 인터페이스를 통해 구현할 수

있을 것이다. 이러한 프로토콜은 마이크로 컨트롤러에 대한 부하

없이 ECU 메모리에 직접 액세스하며 네트워크와 ECU에 부하를

주지 않고도 시스템에서 다량의 데이터를 빠르게 읽을 수 있다.

Vector VX 하드웨어의 경우 ECU의 NEXUS 또는 JTAG 인터페이

스에 직접 액세스할 수 있도록 한다(그림 2). 이 하드웨어는

XCP-On-Ethernet을 통해 테스트 시스템과 통신하기 때문에

CANoe에서의 통합이 CAN을 통한 XCP 액세스용 통합만큼이나

쉽다. CANoe 테스트 시스템과 VX 하드웨어를 결합하면 통신 매

체에 어떠한 부정적인 영향도 주지 않고 테스트 시스템 성능을

향상시킬 수 있다.

반면 이 방식의 단점은 불필요한 진단 프로토콜 정보가 실제 계

측된 값과 함께 전송되어 네트워크 시스템 인터페이스에 추가적

인 부하를 준다는 점이다. 특히 계측된 값에 타임스탬프 정보가

없어서 방대한 값에 대한 데이터 흐름 분석은 불가능하다.

테스트 접근을 위한 XCP

네트워크 인터페이스 부하를 낮게 유지해야 하는 경우 캘리브레

이션 프로토콜을 사용하는 것이 대안이 될 수 있다. 원래 이러한

프로토콜은 ECU 캘리브레이터용으로 개발되었으나, 알고리즘

최적화를 위해 캘리브레이터가 ECU의 파라미터 또는 특성맵를

수정할 수도 있다. XCP 프로토콜이 ASAM으로 표준화되면 사용

자는 필요에 따라 ECU에서 개별 값을 직접 확인할 수 있다. 프로

토콜은 또한 소위 데이터 수집(DAQ) 목록을 통해 ECU에서 정의

된 계측값 집합을 주기적으로 제공할 수 있다. XCP 프로토콜은

네트워크 매체들을 통해 데이터를 효율적으로 제공하기 위해 정

의되었다. 예를 들어 구성 후 DAQ 목록을 테스트 시스템의 단일

식별자에 대한 응답으로 전송할 수 있고 DAQ 목록의 계측 시간

을 내부 ECU 프로세스와 동기화할 수도 있다. 자동화된 테스트

시스템은 시스템에 유사한 요구 사항을 배치한다. XCP 프로토콜

을 사용해 ECU 또는 사용된 네트워크 시스템에 과도한 부하를

주지 않고도 테스트 시퀀스에 내부 값을 통합할 수 있다.

XCP와 같이 널리 사용되는 표준이 이상적인 또 다른 이유는 툴

체인에 구성하는 것이 매우 간단하기 때문이다. 이름 및 통신 파

라미터를 사용하여 내부 프로그램 메모리 위치와 같은 모든 필요

한 정보가 이미 A2L 파일에 포함되어 있다. 개발 환경에 따라

A2L 파일이 자동으로 생성되거나 링커맵 정보가 아닌 별도의 단

계에서 생성되어야 할 수 있다. 테스트 툴에서 사용자는 테스트

에 사용되는 각 ECU에 대해 이 파일을 한 번만 구성하면 된다. 두

번째 단계에서는 A2L 파일에서 테스트 시퀀스에 필요한 심볼을

선택한다.

CANoe Option .AMD/XCP

Option .AMD/XCP는 내부 ECU 값을 읽고 쓸 수 있는 편리한 기

능으로 벡터의 CANoe 테스트 툴을 보완한다. XCP 표준 지원뿐

만 아니라, 이전 프로토콜인 CCP 역시 지원한다. A2L 파일이 구

성되고 필요한 값이 선택되면 CANoe는 이를 자동으로 획득하여

시스템 변수로 매핑한다. 그러고 난 후, 사용자는 이렇게 매핑된

변수를 모든 테스트 작업에 사용할 수 있으며 ECU 입출력에 대

한 액세스 권한 제공뿐만 아니라 ECU의 메모리를 심층적으로 살

펴볼 수도 있다 (그림 2).

간단한 분석 작업만으로 사용자는 Trace 또는 Graphic 창에 데이

터를 표시하고 패널을 사용하여 결과를 평가할 수 있다. 보다 복

잡한 테스트 시퀀스의 경우 CANoe의 Test Feature Set으로 테스

트 케이스를 만들고 자동으로 평가하기 위해 다양한 옵션을 활용

할 수 있다. 이것의 일례로, 올바른 기능을 위해 네트워크 관리 상

태 머신을 확인할 수 있다는 것을 들 수 있다.

그림 2: Option .AMD/XCP로 ECU 내부 값에 직접 액세스 가능한 CANoe 테스트 시스템

03

기술기사 / 숨겨진 이면

Oliver Falkner독일 슈투트가르트 대학에서 전기 공학을 전공, 학업을 마친 후 1999년

슈투트가르트의 Vector에 입사하였다. 현재 네트워크 및 분산 시스템

제품군의 제품 관리 그룹 리더직을 맡고 있다.

이미지 권리: Vector Informatik GmbH