XCP ReferenceBook V2.0 KO

XCP - ECU 개발을 위한
표준 프로토콜
프로토콜 기초와 응용분야
Andreas Patzer | Rainer Zaiser

Andreas Patzer | Rainer Zaiser
XCP - ECU 개발을 위한 표준 프로토콜
2014년 9월 Vector Informatik GmbH | 허가 없이 무단 전재 및 복제를 금함.
©본 책자는 개인용으로만 사용할 수 있으며, 상업적, 기술적 용도로 사용할 수 없다. 또한, 특정 계약을 위해
사용해서도 안 된다. 본 책자에 실린 모든 정보는 최대한 사실에 근거하여 편찬하였으나, 여기 실린 정보의 정확성에
대해 벡터에서 보장하지는 않는다. 즉, 악의적인 의도나 전반적인 부주의에 의한 오류를 제외하고는
이에 따른 법적 책임을 지지 않는다.
본 책자에 실린 정보는 저작권이나 특허권에 의해 보호되었을 수 있다. 본 책자에서 사용한 소프트웨어나 하드웨어,
기타 제품의 이름은 등록 브랜드로 확인되지 않은 경우에도 등록된 브랜드이거나 기타 브랜드 관련 법에 의해
보호되었을 수 있다.
XCP -
ECU 개발을 위한
표준 프로토콜
기초 및 응용 분야
Andreas Patzer, Rainer Zaiser

Vector Informatik GmbH
목차
서론 7
1 XCP 프로토콜의 기초 13
1.1 XCP 프로토콜 레이어 19

1.1.1 식별 필드 21
1.1.2 타임스탬프 21
1.1.3 데이터 필드 22
1.2 CTO 교환 22
1.2.1 XCP 명령어 구조 22
1.2.2 CMD 25
1.2.3 RES 28
1.2.4 ERR 28
1.2.5 EV 29
1.2.6 SERV 29
1.2.7 슬레이브의 캘리브레이션 파라미터 29
1.3 DTO 교환 - 동기화 데이터 교환 32

1.3.1 측정 방법: 폴링 vs DAQ 33
1.3.2 DAQ 측정 방법 34
1.3.3 STIM 캘리브레이션 방법 41
1.3.4 DAQ와 STIM에 대한 XCP 패킷 주소 지정 42
1.3.5 바이패싱 = DAQ + STIM 44
1.4 XCP 전송 레이어 45

1.4.1 CAN 45
1.4.2 CAN FD 48
1.4.3 FlexRay 50
1.4.4 Ethernet 53
1.4.5 SxI 55
1.4.6 USB 55
1.4.7 LIN 55
1.5 XCP 서비스 56

1.5.1 메모리 페이지 스와핑 56
1.5.2 메모리 페이지 저장 - 데이터 페이지 프리징 58
1.5.3 플래시 프로그래밍 58
1.5.4 슬레이브 자동 탐지 60
1.5.5 업로드/다운로드/플래싱을 위한 블록 전송 모드 61
1.5.6 콜드 스타트 측정 (파워 온 도중 측정 시작) 62
1.5.7 XCP의 보안 메커니즘 63
2 ECU 기술 파일 - A2L 65
2.1 XCP 슬레이브를 위한 A2L 파일 설정하기 68

2.2 수동으로 A2L 파일 생성하기 69
2.3 A2L 컨텐츠 vs ECU 구현 70
3 캘리브레이션 개념 73
3.1 플래시 파라미터 74

3.2 RAM 파라미터 76
3.3 플래시 오버레이 78
3.4 플래시 오버레이의 동적 할당 79
3.5 각 AUTOSAR에 대한 RAM 포인터 기반의 캘리브레이션 개념 80
3.5.1 단일 포인터 개념 80
3.5.2 이중 포인터 개념 82
3.6 플래시 포인터 기반의 캘리브레이션 개념 83
4 XCP의 어플리케이션 영역 85
4.1 MIL: Model in the Loop 87

4.2 SIL: Software in the Loop 88
4.3 HIL: Hardware in the Loop 89
4.4 RCP: Rapid Control Prototyping 91
4.5 바이패싱 92
4.6 가상 ECU로 반복 사이클 단축 95
5 XCP 구현 사례 99
5.1 함수 설명 102
5.2 드라이버에 대한 파라미터 생성 104
저자 106
약어 표 108
참고자료 109
웹주소 109
그림 목차 110
Appendix - 벡터의 XCP 솔루션 112
색인 114
서론 7
서론
최적화된 ECU의 파라미터화(캘리브레이션)에서는 시스템 런타임 도중 파라미터값을 캘리
브레이션하고 동시에 측정한 신호를 얻는다. 개발 툴과 ECU 사이의 물리적 접속은 측정/
캘리브레이션 프로토콜을 통해 이루어지며 XCP가 이러한 표준으로 자리 잡았다.
먼저, XCP의 기초와 메커니즘에 대해 간단하게 설명한 다음, 적용 분야 및 캘리브레이션
추가 값에 대해 논의해 보기로 한다.
먼저, XCP에 대한 기본개념은 다음과 같다.

> XCP는 "Universal Measurement and Calibration Protocol"을 뜻한다. 여기서 "X"는 가
변적이고 교환 가능한 전송 레이어를 의미한다.
> ASAM(Association for Standardisation of Automation and Measuring System)에서 XCP를
표준화했다. ASAM은 자동차 OEM 업체, 부품 업체, 툴 공급업체들로 구성되어 있다.
> XCP는 CCP(CAN Calibration Protocol)를 승계하는 프로토콜이다.
> CCP의 컨셉은 CAN을 통해 내부 ECU 데이터에 액세스하여 읽기/쓰기를 허용하는 것이었다.
XCP는 CAN 외에도 다양한 전송매체를 통해 이러한 컨셉을 구현하기 위해 개발되었다.
이러한 XCP의 예로는 XCP on CAN, XCP on FlexRay, XCP on Ethernet이 있다.
> XCP의 주요 사용 목적은 내부 ECU 파라미터의 측정/캘리브레이션이다. 이 프로토콜은
ECU에서의 처리를 위한 "이벤트 동기화(Event synchronous)" 측정값을 얻을 수 있도록
해 준다. 이에 따라 상호 간에 사용하는 데이터의 일관성이 보장된다.
이에 대한 기본 개념을 가시화하기 위해, 먼저 ECU와 그 안에서 구동되는 소프트웨어를

하나의 블랙박스로 간주해 보기로 하자. 이 블랙박스에서는 ECU로 들어가는 입력값(예:
CAN 메시지와 센서 값)과 ECU에서 나오는 출력값(예: CAN 메시지와 액추에이터 드라이
브)만 얻을 수 있다. 내부 알고리즘의 처리에 대한 구체적인 내용은 바로 확인할 수 없으
며, 입출력 데이터 분석을 통해서만 확인할 수 있다.
이제 ECU가 모든 연산 사이클(Computation cycle)에 대해 어떤 거동을 하는지 볼 수 있다고

가정하자. 언제든 알고리즘이 구동되는 방식에 대해 상세한 정보를 얻을 수 있을 것이다.
ECU는 더 이상 블랙박스가 아니라 내부 프로세스를 환히 들여다볼 수 있는 화이트 박스가
되었다. 이게 바로 XCP가 하는 일이다.
XCP는 전반적인 개발 프로세스에서 어떤 기여를 하고 있을까? 개발자는 특정 개발 단계

에서 특정 기능을 확인하려면 해당 코드를 반복적으로 실행해야 한다. 이런 방법으로 개발
자는 해당 알고리즘이 어떻게 작동하는지 어떻게 최적화시켜야 하는지를 확인한다.
여기서는 컴파일한 코드가 특정 하드웨어에서 구동되든지, 모델기반 방식으로 개발되어 이
어플리케이션이 해당 모델에서만 구동된다든지 하는 것은 문제가 되지 않는다.
중점이 되는 것은 알고리즘 프로세스의 평가에 있다. 예를 들어, 매스웍스(MathWorks)의

시뮬링크(SimuLink)와 같은 특정 개발 환경에서 이 알고리즘이 하나의 모델로 구동되고,
개발자가 이 어플리케이션을 통해 중간 결과를 즉각적으로 얻을 수 있다면, 다른 변경
사항에 대한 결과를 얻는 데에도 도움이 될 것이다. 최종 분석에서는 이 방법이 파라미터
에 대한 읽기 액세스를 제공하는 정도로 모델을 가시화하고 분석할 수 있게 된다. 그리고
이 모든 것이 모델 런타임이나 시간을 제한한 테스트가 완료된 후 소급해서 이루어지게
된다. 예를 들어 PID 컨트롤러의 비례 컴포넌트(Proportional component)를 변경하여 제어
하는 시스템의 알고리즘 거동에 적응하도록 하는 경우처럼 파라미터가 변경될 때에는 쓰기
액세스도 필요하게 된다. 어플리케이션을 어디서 실행하던지 간에, 중요한 것은 항상 알고리즘
8 서론
프로세스의 상세 분석과 파라미터 변경을 통한 최적화이다.
다음과 같은 일반화가 성립될 수 있다. 알고리즘은 실행 가능한 형태(코드 또는 모델 기술)

로 존재할 수 있다. 각기 다른 시스템을 런타임 환경(시뮬링크 또는 PC, 래피드 프로토타이
핑 플랫폼, ECU 등의 DLL)으로 사용할 수 있다. 프로세스 흐름(Process flow)은 데이터에
대한 읽기 액세스와 시간에 따른 흐름 정보를 이용해 분석한다. 파라미터 세트는 알고리즘
을 최적화시키기 위해 반복해서 수정한다. 일반화를 단순화시키기 위해 데이터 획득은 PC
기반의 툴을 이용해 표면화시킬 수 있지만, 여기서 한가지 이해해야 할 것은 런타임 환경
자체에서도 분석 능력을 제공할 수 있다는 점이다.
Runtime Environment
Application
Communication
PC Tool 그림 1:
Operating System 런타임 환경을 이용한
기초 통신
일반적으로 런타임 환경의 종류와 통신형태는 서로 상당히 다르다. 그 이유는 이런 런타임

환경들이 서로 다른 제작자에 의해 개발되었으며, 솔루션에 대해 상이한 접근법을 택하고
있기 때문이다. 서로 다른 형태의 프로토콜, 구성, 측정 데이터 포맷 등은 모든 개발단계
에서 파라미터 세트와 결과를 교환하고자 하는 모든 노력을 수포로 만들고 있다. 그러나
결국에는 이러한 솔루션 모두가 런타임에서 읽기/쓰기 액세스 수준으로 단순화될 것이다.
그리고 이미 이에 대한 표준이 나와 있다. 바로 XCP이다.
XCP는 ASAM 표준으로 2003년 버전 1.0이 출시되었다. ASAM은 "자동화 및 측정 시스

템 표준화 협회(Association for Standardisation of Automation and Measuring System)"
의 약자이다. ASAM 워킹그룹은 차량 부품업체, OEM업체, 툴 공급업체를 모두 대변한다.
XCP 워킹그룹의 목적은 특정한 전송매체에서 독립적으로 사용할 수 있는 일반화된
측정/캘리브레이션 프로토콜을 정의하는 것이다. CCP(CAN Calibration Protocol) 개발에서
얻은 경험도 이러한 개발에 활용되고 있다.
XCP는 ASAM 인터페이스 모델에 기반하여 정의된다. 다음 그림은 측정/캘리브레이션 툴의

XCP 슬레이브와 기술 파일(description file)에 대한 인터페이스와 보다 고차원의 자동화 시
스템에 대한 접속을 보여주고 있다.
서론 9
Upper Level
Automation System
ASAM MCD 3MC
Measurement and ASAM

Calibration System MCD 2MC *.a2L
XCP Driver
ECU Description File
ASAM MCD 1MC
XCP Driver
ECU 그림 2:
ASAM의 인터페이스
모델
인터페이스 1: ECU와 측정/캘리브레이션 시스템 간의 "ASAM MCD-1 MC"

이 인터페이스는 물리적 부분 및 각 프로토콜별 부분을 설명한다. 엄격하게 말하자면, 여
기 인터페이스 ASAP1a와 ASAP1b 사이를 구분해야 한다. 그러나 ASAP1b 인터페이스는 지
금까지 널리 채택된 적도 없었고 실용화된 적도 없었기 때문에 오늘날에는 거의 사용되지
않는다. XCP 프로토콜은 융통성이 많으므로 실질적으로 제조사별 일반적인 인터페이스의
역할을 하고 있다. 예를 들어, 오늘날 모든 측정/캘리브레이션 하드웨어 제조사들은 XCP on
Ethernet 표준을 통해 접속할 수 있는 시스템(xETK, VX1000 등)을 제공하고 있다. ASAP1b
인터페이스는 아직 CCP에서 설명하고 있기는 하지만 더 이상 필요하지 않다.
인터페이스 2: "ASAM MCD-2 MC" A2L ECU 기술 파일(Description file)

이미 언급한 대로 XCP는 주소 지향적으로 작동한다. 객체에 대해 읽기/쓰기 액세스를
하기 위해서는 항상 주소를 입력해야만 한다. 그러나 이러한 방법은 사용자로 하여금 주소를
이용해 마스터 내에서 ECU 객체를 검색해야 한다는 것을 뜻한다. 이는 매우 불편한 방식
이다. 예를 들어 사용자가 심볼을 이용한 객체명을 사용할 수 있도록 하려면 객체명과
객체주소 사이의 관계를 기술한 파일이 필요할 것이다. 다음 장에서는 A2L 기술 파일에 대해
알아보도록 한다.
인터페이스 3: "ASAM MCD-3 MC" 자동화 인터페이스

이 인터페이스는 테스트벤치 자동화와 같이 측정/캘리브레이션 툴에 다른 시스템을 연결
하는 데 사용한다. XCP를 이해하는 데는 상관이 없으므로 본 문서에서 이 인터페이스에
대한 더 이상의 설명은 생략한다.
10 서론
XCP는 마스터-슬레이브(Master-Slave) 원칙에 기반을 두고 있다. 여기서 ECU는 슬레이브

(Slave)이고, 측정/캘리브레이션 툴은 마스터(Master)가 된다. 슬레이브는 한 번에 하나의
마스터와만 통신할 수 있는 있지만 마스터는 동시에 여러 개의 슬레이브와 통신할 수 있다.
Master
Bus
그림 3:
XCP 마스터는 여러
Slave Slave Slave Slave 개의 슬레이브와 동시에
통신을 할 수 있다.
전체 개발 프로세스에서 데이터와 설정 값에 액세스하기 위해서는 모든 런타임 환경에서

XCP가 사용돼야 한다. 이로써 구매하고 운용 및 유지해야 하는 툴의 수를 줄일 수 있다.
또한, 한 툴에서 다른 툴로 설정 값을 수동으로 복사할 필요도 없어지는데 사실 이 프로세
스에서 오류가 발생하기 쉽다. XCP는 반복 루프를 단순화시켜 뒷단계의 작업과정에서 얻은
결과를 앞단계로 전송할 수도 있다.
앞에서 설명한 이론적인 것들을 오늘날 어디까지 구현할 수 있을까? 모든 것이 가능하

다! XCP 솔루션은 이미 다양한 작업 환경에서 사용되고 있다. 이 책은 측정/캘리브레이션
프로토콜의 주요 특성을 설명하고 다양한 런타임 환경에서 어떻게 사용할 수 있는지를
소개한다. 이 책에서 찾을 수 없는 내용은 다음과 같다. 구체적인 XCP 전체 규격은
나와 있지 않다. 또한, 특정 런타임 환경에서 XCP 드라이버를 어떻게 통합시키는지에 대한
설명도 없다. 이 책에서는 개별적인 프로토콜이나 구체적인 구현방법을 소개하지는 않는다.
Appendix에 있는 인터넷 링크는 공개적으로 구할 수 있는 XCP 드라이버 소스코드와 샘
플에 관한 것이다. 이를 이용하여 어떻게 이 프로토콜을 구현할 수 있을지 이해할 수 있
을 것이다.
이 책에 사용된 스크린샷 이미지는 벡터사의 CANape 측정/캘리브레이션 툴에서 캡처하였다.

A2L 파일을 어떻게 생성하는지와 같은 다른 프로세스 흐름도 CANape를 이용해서 설명하고
있다. 벡터 웹사이트의 다운로드 센터에서 CANape 데모 버전을 무료로 다운로드할 수 있다.
(www.vector.com/canape_demo)
서론 11
12
1 XCP 프로토콜의 기초
14 1 XCP 프로토콜의 기초
ASAM 인터페이스 모델의 인터페이스 1에서는 슬레이브와 마스터 간에 명령어 및 데이터

송수신에 대해 설명하고 있다. 특정 물리적 전송 레이어로부터 독립성을 유지하기 위해
XCP는 프로토콜 레이어와 전송 레이어를 구분하고 있다.
CAN Ethernet FlexRay SxI USB ...
그림 4: XCP 프로토콜의 프로토콜 레이어와 전송 레이어 구분
또한, 전송 레이어에 따라 XCP on CAN, XCP on Ethernet 등으로 구분할 수 있다. 새로

운 전송 레이어로 확장할 수 있는 능력은 이미 2005년 XCP on FlexRay를 선보일 때 증
명된 바 있다. XCP 프로토콜의 현행 버전은 버전 1.1로 2008년에 승인받았다.
이 프로토콜을 설계하는 데 있어서 최우선의 원칙은 다음과 같다.

> ECU 내에서 최소 자원 사용
> 효율적인 통신
> 심플한 슬레이브 구현
> 소수의 파라미터만으로 플러그 앤 플레이 구성
> 확장성
XCP의 핵심 기능은 슬레이브의 메모리에 읽기/쓰기 액세스가 가능하다는 점이다.
사용자는 읽기 액세스를 통해 ECU 내부 파라미터의 응답시간을 측정할 수 있다. ECU는

독립적인 시간 거동을 하는 시스템으로 그 파라미터는 특정 시간 간격에서만 변경할 수
있다. 즉, 프로세서가 값을 계산해서 RAM에 업데이트하는 시간을 뜻한다. XCP의 최대
강점 중 하나는 ECU 내에서 프로세스 흐름이나 이벤트와 동시적으로 변화하는 RAM에서
측정값을 구할 수 있다는 점이다. 사용자는 이 기능을 통해 ECU에서 시간 의존적인 프로
세스 흐름과 변화하는 값의 직접적인 관계를 평가할 수 있다. 이를 이벤트-동기화 측정
(event-synchronous measurement)이라고 부른다. 관련 메커니즘은 후에 상세하게 설명
하도록 하겠다.
사용자는 쓰기 액세스를 이용해 슬레이브에서 알고리즘의 파라미터를 최적화시킬 수 있

다. 이러한 액세스는 주소를 기반으로 한다. 즉, 마스터와 슬레이브 간에 통신할 때 메모리
에 있는 주소를 참고로 한다. 그러므로 파라미터의 측정은 기본적으로 마스터가 슬레이브
에 다음과 같이 요청함으로써 구현된다. "메모리 위치 0x1234의 값을 보내 주시오." 특정
파라미터의 캘리브레이션, 즉 슬레이브에 대한 쓰기 액세스란 "주소 0x9876에 있는 값을
5로 설정하시오."라고 하는 것을 말한다.
ECU에서XCP 슬레이브를 반드시 사용할 필요는 없다. 모델 기반의 개발 환경이나 HIL/SIL

환경, 또는 JTAG나 NEXUS, DAP와 같은 인터페이스를 디버깅해 ECU 메모리에 액세스
하는데 사용하는 하드웨어 인터페이스 등과 같은 다른 환경에서 구현할 수도 있다.
Simulink
Slave
Prototype or
ECU Hardware
Slave
Measurement/
XCP Calibration
Master Slave Hardware*
PC
EXE/DLL
Slave
그림 5:
HIL/SIL Systems
XCP 슬레이브는
Slave 다양한 런타임
환경에서 사용할
* Debug Interfaces, Memory Emulator, ...
수 있다.
ECU에 대한 읽기/쓰기 액세스를 이용해 어떻게 알고리즘을 최적화시키고 또 여기에 어떤

장점이 있을까? ECU 내의 런타임에서 개별적인 파라미터를 수정할 수 있으려면 먼저 이에
액세스해야 한다. 그러나 모든 유형의 메모리가 이러한 프로세스를 허용하지는 않는다. 이
기능은 단지 RAM에 있는 (여기서는 의도적으로 EEPROM은 제외함) 메모리 주소에 읽기/
쓰기 액세스를 하는 것뿐이다. 다음은 각 메모리 기술의 차이점을 간단하게 요약한 것이다.
이에 대한 지식은 본 책자의 나머지 내용을 이해하는 데 매우 중요하다.
메모리 기초
오늘날, 플래시 메모리는 보통 ECU용 마이크로컨트롤러 칩에 통합시키거나 코드 및 데이

터를 전원공급 없이도 장기적으로 저장하기 위한 목적으로 사용하고 있다. 플래시 메모리
의 특성은 개별 바이트에 대한 읽기/쓰기 액세스가 언제든지 가능하지만, 새로운 내용을
쓸 때에는 상당히 큰 블록 단위로만 가능하다는 점이다.
플래시 메모리의 수명은 제한되어 있는데, 보통 소거 사이클의 최대 수로 표시한다(기술에

따라 최대 수는 100만 번까지 될 수도 있다). 이는 쓰기 사이클의 최대 수로 해도 마찬가
지인데, 왜냐하면 메모리에서는 다시 쓰기 전에 먼저 블록 위로 소거해야 하기 때문이다.
그 이유는 메모리 구조이다. 전자는 터널 다이오드를 통해 "펌핑" 된다. 비트 하나는 메모리
위치에 다음과 같이 저장된다. 전자가 전기적으로 절연된 레이어를 거쳐 메모리 위치로
전송된다. 일단 전자가 절연 레이어 뒤에 놓이게 되면, 전하로 인해 전기장이 발생하는데,
이것을 메모리 위치에서는 1로 읽히게 된다. 레이어 뒤에 전자가 없는 경우에는 셀 정보
가 0으로 해석된다. 사실 1은 이런 방법으로 설정되지만, 0은 다르다. 0을 결정하는 것(=1
을 소거하는 것)은 별도의 소거 루틴을 이용하는데, 이때 절연 레이어 뒤에 있던 전자가
방전된다. 그러나 구조적인 이유로 이러한 소거 루틴은 한 바이트에 대해서는 작동하지
않고 그룹이나 블록 단위로 작동한다. 아키텍처에 따라 보통 128바이트의 블록이나 256
바이트의 블록이 사용된다. 이런 블록 내에서 한 바이트만 오버라이트 하고자 하는 경우
에는 블록 전체를 먼저 소거해야 한다. 그다음에 블록의 내용 전체가 다시 쓰이는 것이다.
이러한 소거 루틴이 여러 차례 반복되면, 절연 레이어(터널 산화막: Tunnel Oxide Film)

가 파손될 수 있다. 이 말은 전자가 서서히 새어나가 시간이 지남에 따라 들어 있는 정보
중 일부가 1에서 0으로 바뀔 수 있다는 뜻이다. 그러므로 ECU에서는 허용 가능한 플래시
사이클의 수가 극히 제한되어 있다. ECU를 양산할 때 보통 한 자릿수로 지정하기도 한다.
이러한 제약은 플래시 부트로더(Flash Boot Loader)가 감시하는데, 이 루틴은 지금까지
수행한 플래싱 작업의 수를 기록해 둔다. 지정된 수를 넘어가게 되면, 플래시 부트로더는
더 이상의 플래싱 요청을 거부한다.
RAM(Random Access Memory)은 영구적인 전원공급을 해야 하며, 전원이 끊길 경우

에는 내용이 사라진다. 플래시 메모리는 어플리케이션을 장기적으로 저장하는 목적으로
사용되지만, RAM은 계산한 데이터나 기타 임시적인 정보를 잠시 저장하는 데 사용된다.
전원공급을 끌 경우, RAM의 내용이 사라진다. 플래시 메모리와는 반대로, RAM에 읽거나
쓰기는 쉽다.
한 가지 확실한 것은 런타임에서 파라미터를 수정할 필요가 있다면, 이 파라미터를 RAM에

싣도록 해야 한다는 것이다. 이를 이해하는 것은 매우 중요하다. 다음 예제를 통해 ECU에
서 어플리케이션을 어떻게 실행하는지 알아보기로 하자.
어플리케이션에서 y 파라미터는 센서값 x를 통해 계산했다.
// Pseudo-code representation
a = 5;
b = 2;
y = a * x + b;
이 어플리케이션이 ECU에서 플래싱 되면, 컨트롤러는 부팅 후에 이 코드를 다음과 같이

처리한다. x 파라미터의 값은 센서값에 해당한다. 그러므로 어떤 시점에서 어플리케이션
은 센서값을 폴링해야 하며, 이 값은 x 파라미터에 할당된 메모리 위치에 저장된다. 이
값은 항상 런타임에서 다시 쓸 필요가 있으므로 메모리 위치는 RAM이 될 수 밖에 없다.
파라미터 y를 계산한다. 값 a와 b는 각각 인수(factor)와 오프셋(offset) 값인데, 플래시 메

모리에 정보로서 실려 있다. 이 값들은 여기서 상수(constant)로 저장된다. y 값도 RAM
에 저장해야만 하는데, 왜냐하면 RAM이 쓰기 액세스가 가능한 유일한 장소이기 때문이
다. RAM에서 정확하게 어디에 파라미터 x와 y가 위치하는지, 또 a와 b가 플래시 메모리
의 어디에 놓이는지는 컴파일러/링커를 구동해서 설정한다. 이 위치는 객체에 고유 주소
(unique address)가 할당되는 곳이다. 객체명과 데이터 유형, 주소 사이의 관계는 링커-
맵(Linker-map) 파일에 기록되어 있다. 링커-맵 파일은 링커를 구동해서 생성하며, 다른
포맷으로도 존재할 수 있다. 그러나 모든 포맷에 공통된 사항은 최소한 객체명과 주소는
포함하고 있어야 한다는 것이다.
예제에서 오프셋값 b와 인수 a가 특정 차량에 종속되는 경우, a 값과 b 값은 반드시 해

당 차량의 특정 조건에 따라 개별적으로 조정하도록 해야 한다. 즉, 알고리즘은 그대로지
만 파라미터값은 차량에 따라 바뀔 수 있다는 뜻이다.
ECU의 정상적인 동작 모드에서는 어플리케이션이 플래시 메모리에서 구동한다. 객체 각각

에 대한 쓰기 액세스는 허용되지 않는다. 이 말은 플래시 영역에 위치한 파라미터값은 런
타임에서 수정할 수 없다는 뜻이다. 런타임 중 파라미터값을 수정할 수 있다면, 이 수정
된 파라미터는 플래시 메모리가 아니라 RAM에 위치해야 한다. 이제 이 파라미터와 그 초
깃값을 어떻게 RAM으로 옮길 수 있을까? RAM에 동시에 저장할 수 있는 파라미터 수보
다 많은 수의 파라미터를 수정해야 하는 문제를 어떻게 풀 수 있을까? 이 문제를 다루려
면 캘리브레이션의 개념을 알아야 한다 (제3장 참조)
XCP 기초 요약
메모리 내용에 대한 읽기/쓰기 액세스는 XCP 프로토콜의 메커니즘을 이용하면 가능하

다. 이런 액세스는 주소를 기반으로 이루어진다. 읽기 액세스는 RAM에서 파라미터를 측
정할 수 있도록 하며, 쓰기 액세스는 RAM의 파라미터를 캘리브레이션할 수 있도록 한다.
XCP는 ECU에서 측정을 이벤트에 동기화시켜 실행할 수 있도록 한다. 이에 따라 측정값
들은 서로 연관성을 갖게 된다. 측정을 재시작할 때마다 측정할 신호를 임의로 선택할
수 있다. 쓰기 액세스에서 캘리브레이션할 파라미터는 RAM에 저장해야 한다. 이 때문에
캘리브레이션 개념이 필요하다.
여기서 두 가지 중요한 질문이 제기된다.

>X CP 프로토콜 사용자가 RAM에서 측정/캘리브레이션 파라미터의 정확한 주소를 알 수
있을까?
> 캘리브레이션 개념이란 무엇일까?
첫 번째 질문에 대한 답은 제2장 "ECU 기술 파일 A2L"에서 다루고 있으며, 캘리브레이션

개념에 대해서는 제3장에서 다루고 있다.
1.1 XCP 프로토콜 레이어

XCP 데이터는 마스터와 슬레이브 사이에 메시지 방식으로 교환된다. "XCP 메시지 프레임"
전체는 전송 레이어의 프레임에 포함된다(XCP on Ethernet의 경우에는 UDP 패킷
내의 UDP). 이 프레임은 XCP 헤더와 XCP 패킷, XCP 테일의 세 부분으로 구성되어 있다.
다음 그림에서, 메시지 일부가 붉은색으로 표시되어 있다. 이는 현재의 XCP 프레임을

보내는 데 사용된다. XCP 헤더와 XCP 테일은 전송 프로토콜에 의존한다.
XCP Message (Frame)
XCP Header XCP Packet XCP Tail

PID FILL DAQ TIMESTAMP DATA
Identification Timestamp Data

Field Field Field
그림 6: XCP 패킷
XCP 패킷 자체는 사용한 전송 프로토콜과 독립적이며, 항상 "식별 필드(Identification

Field)"와 "타임스탬프 필드", 그리고 현재 데이터 필드인 "데이터 필드" 등 세 개의 컴포
넌트로 이루어진다. 식별 필드는 패킷 식별자(PID)로 시작하는데, PID는 패킷을 식별하는
데 사용한다.
다음 개요는 어떤 PID가 정의되었는지 보여 주고 있다.
PID for frames PID for frames

from Master to Slave from Slave to Master
0xFF 0xFF RES

0xFE ERR
CMD
....
0xFD EV
0xC0 0xFC SERV
0xBF 0xFB
absolute or absolute or
relative relative
....
....
ODT number ODT number

for STIM for STIM
0x00 0x00
그림 7: XCP 패킷 식별자(PID) 개요
XCP 패킷을 통한 통신은 명령어(CTO)를 위한 영역 하나와 동기화 데이터(DTO) 발송을

위한 영역 하나로 구분된다.
XCP Master
XCP Driver
CTO DTO
CMD RES ERR EV SERV DAQ STIM
Command / Response / Error / Event / DAQ STIM

Service Request Processor Processor Processor
XCP Handler Bypass
PGM CAL DAQ STIM

Resources 그림 8:
XCP Slave CTO/DTO를 이용한
XCP 통신 모델
여기서 사용한 약어는 다음과 같다:
CMD Command Packet 명령어 전송

RES Command Response Packet 긍정적 응답
ERR Error 부정적 응답
EV Event Packet 비동기 이벤트
SERV Service Request Packet 서비스 요청
DAQ Data AcQuisition 주기적인 측정값 전송
STIM Stimulation 슬레이브의 주기적인 신호 인가
명령어는 CTO(Command Transfer Object)를 통해 교환된다. 예를 들어, 마스터는 이

방법으로 접촉을 시작한다. 슬레이브는 CMD에 대해 항상 RES나 ERR로 응답해야 한다.
다른 CTO 메시지는 비동기적으로 전송된다. DTO(Data Transfer Object)는 측정/신호
인가 데이터를 동기적으로 교환하는 데 사용된다.
1.1.1 식별 필드
XCP Packet
Identification Field 그림 9:
메시지 식별
메시지를 교환할 때 마스터와 슬레이브는 모두 상대방이 어떤 메시지를 보냈는지 확인

할 수 있어야 한다. 이는 식별 필드를 이용해 확인할 수 있다. 이 때문에 각각 메시지는
패킷 식별자(PID)로 시작하는 것이다.
CTO를 전송할 때 PID 필드는 CMD나 RES 또는 다른 CTO 패킷을 식별하기에 충분하다.
그림 7은 마스터에서 슬레이브로 보내는 명령이 0xC0~0xFF의 PID를 이용하고 있는 것을
보여 준다. XCP 슬레이브는 마스터에게 0xFC~0xFF의 PID를 이용해 응답하거나 통지를
보낸다. 이에 따라 개별적으로 보낸 CTO에도 고유 PID를 할당할 수 있게 된다.
DTO를 전송할 때에는 식별 필드의 다른 요소들도 사용된다. (제1.3.4절 "DAQ와 STIM에
대한 XCP 패킷 주소 지정" 참조)
1.1.2 타임스탬프
XCP Packet

그림 10:
타임스탬프
DTO 패킷은 타임스탬프를 사용하는데, 이는 CTO 메시지를 전송할 때에는 불가능하다.

슬레이브는 측정값에 시간 정보를 담기 위해 타임스탬프를 사용한다. 즉, 마스터는 측정값
만을 갖는 것이 아니라 측정값을 획득한 시점도 가진다. 측정값이 마스터에 도달하는 데
걸린 시간은 더 이상 중요하지 않은데, 왜냐하면 측정값과 시점의 관계가 슬레이브에서
직접 오기 때문이다.
슬레이브에서 타임스탬프를 전송하는 것은 선택사항이다. 이 주제에 대해서는 ASAM XCP
파트 2 프로토콜 레이어 규격에서 더 자세히 다루고 있다.
1.1.3 데이터 필드
XCP Packet

그림 11:
Data Field XCP 패킷의
데이터 필드
마지막으로, XCP 패킷에는 데이터 필드에 저장된 데이터도 들어 있다. CTO 패킷의
경우, 데이터 필드에는 상이한 명령어에 대한 특정 파라미터가 들어 있다. DTO 패킷에는
슬레이브에서 보낸 측정값과 마스터에서 이 값을 보낸 시점이 들어 있다.
1.2 CTO 교환
CTO는 마스터에서 슬레이브로 명령을 보내거나 슬레이브에서 마스터로 응답을 보낼 때
사용한다.
1.2.1 XCP 명령어 구조
슬레이브는 마스터에서 명령을 수신하고 그에 따라 긍정적 또는 부정적 응답을 보내야

한다. 여기서는 통신 구조가 항상 같다.
명령어(CMD):
위치 종류 설명
0 BYTE Command Packet Code CMD
1..MAX_CTO-1 BYTE Command specific Parameters
각 명령어에는 고유 번호가 할당된다. 또한, 명령어와 함께 다른 특정 파라미터를 보낼 수

도 있다. 파라미터의 최대 수는 여기서 MAX_CTO-1로 정의된다. MAX_CTO는 CTO 패킷의
최대 길이를 바이트로 나타낸 것이다.
긍정적 응답:
0 BYTE Command Positive Response Packet Code = RES 0xFF
1.2 CTO 교환 23
부정적 응답:
0 BYTE Error Packet Code = 0xFE
1 BYTE Error code
특정 파라미터를 긍정적 응답뿐 아니라 부정적 응답과 함께 보조 정보로 전송할 수도

있다. 한 예로 마스터와 슬레이브 간의 접속을 들 수 있다. 마스터와 슬레이브 사이에
통신을 시작할 때 마스터는 슬레이브로 접속 요청을 보내며, 슬레이브는 이때 지속적인
점대점(Point-to-point) 접속을 만들기 위해 긍정적으로 응답해야 한다.
마스터 à 슬레이브: 접속
슬레이브 à 마스터: 긍정적 응답
접속 명령어:
0 BYTE Command Code = 0xFF
1 BYTE Mode
00 = Normal
01 = user defined
모드 00은 마스터가 슬레이브와 XCP 통신을 원한다는 뜻이다. 마스터가 접속을 할 때

0xFF 0x01을 사용하면, 마스터는 슬레이브에게 XCP 통신을 요청하고 있는 것이다. 동시
에, 마스터는 슬레이브에게 특정한 사용자 정의 모드로 전환할 것을 통지한다
슬레이브의 긍정적 응답:

0 BYTE Packet ID: 0xFF
1 BYTE RESOURCE
2 BYTE COMM_MODE_BASIC
3 BYTE MAX_CTO, Maximum CTO size [BYTE]
4 WORD MAX_DTO, Maximum DTO size [BYTE]
6 BYTE XCP Protocol Layer Version Number (가장 중요한 바이트만)
7 BYTE XCP Transport Layer Version Number (가장 중요한 바이트만)
슬레이브의 긍정적 응답에서는 좀 더 광범위한 형태를 가정하고 있다. 슬레이브는 접속을

할 때 이미 마스터로 통신에 특정한 정보를 보냈다. 예를 들어 RESOURCE는 슬레이브가
페이지 스위칭과 같은 기능을 지원하는지, XCP를 통해 플래싱이 가능한지 등의 정보를 제
공하는 것이다. 슬레이브는 MAX_DTO를 사용해서 측정값 전송 시 지원이 가능한 최대 패
킷 길이 등을 마스터에게 보낸다. 이 파라미터에 대한 보다 자세한 내용은 ASAM XCP 파
트 2 프로토콜 레이어 규격에서 찾을 수 있다.
XCP는 마스터와 슬레이브 사이에 명령어와 반응을 교환하는 데 사용하는 세 가지 모드

(표준 모드, 블록 모드, 인터리브 모드)를 가지고 있다.
Standard Mode Block Mode Interleaved Mode

Master Slave Master Slave Master Slave
Request k
Request k Part1 Request k
Part2
MIN_ST
Part3 Request k+1
Response k MAX_BS
Response k
Request k+1 Response k

Request k+1
Response k+1 Response k+1

Part1
Response k+1
Part2
Part3
Time Time Time
그림 12: XCP 프로토콜의 세 가지 모드: 표준 모드, 블록 모드, 인터리브 모드
표준 통신 모델에서는 슬레이브로 보내는 각각의 요청에 대해 하나의 응답이 전달된다.

XCP on CAN의 경우를 제외하면, 마스터에서 보낸 하나의 명령어에 대해 여러 개의 슬레
이브가 반응하는 것을 허용하지 않는다. 그러므로 각 XCP 메시지는 항상 특정한 슬레이브
로 추적해 갈 수 있다. 이 모드는 통신에서 표준으로 사용된다.
블록 전송 모드는 선택사항이며, 대규모 데이터 전송 시(예: 업로드나 다운로드) 시간을

절약할 수 있다. 그러나 이 모드에서는 슬레이브 방향의 성능 문제를 고려해야 한다.
그러므로 두 개의 명령어 사이의 최소 시간(MIN_ST)을 유지해야 하며, 총 명령어 수의
상한선은 MAX_BS를 넘지 않도록 해야 한다. 선택 사항으로 마스터는 GET_COMM_MODE_
INFO를 이용해 슬레이브에서 통신 설정 값을 읽을 수 있다. 블록 전송 모드에서 마스터
방향으로 전송할 때는 앞에서 언급한 한계를 따를 필요가 없는데, PC의 성능이 거의 항상
마이크로컨트롤러에서 데이터를 수신하기에 충분하기 때문이다.
인터리브 모드는 또한 성능상의 이유로 제공된다. 그러나 이 방법은 선택사항으로 블록

전송 모드와 달리 실제로 적용하기에는 적합하지 않다.
1.2 CTO 교환 25
1.2.2 CMD
XCP CTO Packet
PID DATA
Data Field
Identification Field
Timestamp Field
empty for CTO
그림 13: CTO 패킷 구조의 개요
마스터는 CMD를 통해 슬레이브에 일반적인 요청사항을 보낸다. PID(패킷 식별자) 필드에는

명령어의 식별번호가 실려 있다. 데이터 필드로는 추가적인 특정 파라미터가 전송된다.
그 다음에 마스터는 슬레이브가 응답이나 오류 메시지를 보내기를 기다린다.
또한, XCP 는 구현하는 데 확장성이 높아서 모든 명령어를 구현할 필요가 없다. A2L
파일에는 XCP IF_DATA라는 CMD들이 열거되어 있다. A2L 파일의 정의와 슬레이브에
서 구현된 내용에 차이가 있는 경우, 마스터는 슬레이브의 반응에 따라 슬레이브가 해당
명령어를 지원하는지를 확인할 수 있다. 마스터가 슬레이브에서 구현하지 않은 명령어
를 보낸 경우에는 슬레이브가 ERR_CMD_UNKNOWN을 보내 확인하고 더 이상의 조치를
하지 않는다. 이에 따라 마스터는 해당 슬레이브에서 선택사항인 명령어가 구현되지 않았
음을 신속하게 알 수 있다.
명령어에는 다른 파라미터도 포함되어 있다. 프로토콜 레이어의 규격에 대한 상세한 내용은
ASAM XCP 파트 2 프로토콜 레이어 규격에서 확인할 수 있다.
명령어는 표준 명령어나 캘리브레이션, 페이지, 프로그래밍, DAQ 측정 명령어 등 그룹으로

구성된다. 어떤 그룹이 전혀 필요하지 않을 경우, 그 명령어는 구현할 필요가 없다. 해당
그룹이 필요하다면 특정 명령어는 항상 슬레이브에서 사용 가능해야 하며, 해당 그룹의
다른 명령어들은 선택항목으로 사용할 수 있다.
다음 개요를 예로 들어 보자. 페이지 스위칭 그룹에 있는 SET_CAL_PAGE와 GET_CAL_

PAGE 명령어는 선택항목이 아니다. 이는 페이지 스위칭을 지원하는 XCP 슬레이브에게
있어서 적어도 이 두 개의 명령어는 구현되어야 한다는 것을 뜻한다. 슬레이브에게 페이
지 스위칭 지원 기능이 불필요한 경우에는 이 명령어를 구현할 필요가 없다. 이는 다른
명령어에도 똑같이 적용된다.
표준 명령어:
명령어 PID 옵션
CONNECT 0xFF No
DISCONNECT 0xFE No
GET_STATUS 0xFD No
SYNCH 0xFC No
GET_COMM_MODE_INFO 0xFB Yes
GET_ID 0xFA Yes
SET_REQUEST 0xF9 Yes
GET_SEED 0xF8 Yes
UNLOCK 0xF7 Yes
SET_MTA 0xF6 Yes
UPLOAD 0xF5 Yes
SHORT_UPLOAD 0xF4 Yes
BUILD_CHECKSUM 0xF3 Yes
TRANSPORT_LAYER_CMD 0xF2 Yes
USER_CMD 0xF1 Yes
캘리브레이션 명령어:
DOWNLOAD 0xF0 No
DOWNLOAD_NEXT 0xEF Yes
DOWNLOAD_MAX 0xEE Yes
SHORT_DOWNLOAD 0xED Yes
MODIFY_BITS 0xEC Yes
페이지 스와핑:
SET_CAL_PAGE 0xEB No
GET_CAL_PAGE 0xEA No
GET_PAG_PROCESSOR_INFO 0xE9 Yes
GET_SEGMENT_INFO 0xE8 Yes
GET_PAGE_INFO 0xE7 Yes
SET_SEGMENT_MODE 0xE6 Yes
GET_SEGMENT_MODE 0xE5 Yes
COPY_CAL_PAGE 0xE4 Yes
1.2 CTO 교환 27
주기적 데이터 교환 - 기본 구성:

SET_DAQ_PTR 0xE2 No
WRITE_DAQ 0xE1 No
SET_DAQ_LIST_MODE 0xE0 No
START_STOP_DAQ_LIST 0xDE No
START_STOP_SYNCH 0xDD No
WRITE_DAQ_MULTIPLE 0xC7 Yes
READ_DAQ 0xDB Yes
GET_DAQ_CLOCK 0xDC Yes
GET_DAQ_PROCESSOR_INFO 0xDA Yes
GET_DAQ_RESOLUTION_INFO 0xD9 Yes
GET_DAQ_LIST_INFO 0xD8 Yes
GET_DAQ_EVENT_INFO 0xD7 Yes
주기적 데이터 교환 - 정적 구성:

CLEAR_DAQ_LIST 0xE3 No
GET_DAQ_LIST_INFO 0xD8 Yes
주기적 데이터 교환 - 동적 구성:

FREE_DAQ 0xD6 Yes
ALLOC_DAQ 0xD5 Yes
ALLOC_ODT 0xD4 Yes
ALLOC_ODT_ENTRY 0xD3 Yes
플래시 프로그래밍:
PROGRAM_START 0xD2 No
PROGRAM_CLEAR 0xD1 No
PROGRAM 0xD0 No
PROGRAM_RESET 0xCF No
GET_PGM_PROCESSOR_INFO 0xCE Yes
GET_SECTOR_INFO 0xCD Yes
PROGRAM_PREPARE 0xCC Yes
PROGRAM_FORMAT 0xCB Yes
PROGRAM_NEXT 0xCA Yes
PROGRAM_MAX 0xC9 Yes
PROGRAM_VERIFY 0xC8 Yes
1.2.3 RES
슬레이브가 마스터의 요청에 응하면, 슬레이브는 RES에 긍정적인 확인 답변을 제공한다.
0 BYTE Packet Identifier = RES 0xFF
1..MAX_CTO-1 BYTE Command response data
이 파라미터에 대한 보다 상세한 내용은 ASAM XCP 파트 2 프로토콜 레이어 규격에서

찾을 수 있다.
1.2.4 ERR
마스터에서 보낸 요청을 수행할 수 없는 경우에는 오류 메시지 ERR과 오류 코드 하나를

보낸다.
0 BYTE Packet Identifier = ERR 0xFE
1 BYTE Error code
2..MAX_CTO-1 BYTE Optional error information data
발생 가능한 오류 코드의 리스트는 ASAM XCP 파트 2 프로토콜 레이어 규격에서 확인할

수 있다.
1.2 CTO 교환 29
1.2.5 EV
슬레이브가 마스터로 비동기 이벤트에 대한 정보를 보내려고 할 때, EV를 보낼 수 있다.

이 항목의 구현은 선택사항이다.
0 BYTE Packet Identifier = EV 0xFD
1 BYTE Event code
2..MAX_CTO-1 BYTE Optional event information data
이 파라미터에 대한 보다 상세한 정보는 ASAM XCP 파트 2 프로토콜 레이어 규격 에서

확인할 수 있다.
이벤트는 측정과 신호 인가에 관련하여 좀 더 상세하게 논의될 것이다. 이는 특정 이벤트

발송을 시작하는 XCP 슬레이브의 거동과는 관계가 없다. 이는 오히려 특정 기능의 실패
등과 같은 문제점을 보고하는 슬레이브와 관련이 있다.
1.2.6 SERV
슬레이브는 이 메커니즘을 이용해 마스터에게 특정 서비스를 실행하도록 요청할 수 있다.
0 BYTE Packet Identifier = SERV 0xFC
1 BYTE Service request code
2..MAX_CTO-1 BYTE Optional service request data
서비스 요청 코드표는 ASAM XCP 파트 2 프로토콜 레이어 규격에서 찾을 수 있다.
1.2.7 슬레이브의 캘리브레이션 파라미터
XCP 슬레이브의 파라미터를 변경하려면, XCP 마스터는 해당 파라미터의 위치와 해당

값을 슬레이브로 보내야 한다.
XCP는 항상 5바이트로 주소를 정의한다. 이 중 4바이트는 실제 주소용이고 1바이트는 주
소 확장용이다. CAN 전송방식에서는 XCP 메시지에 단지 7바이트만 사용할 수 있다. 예
를 들어, 캘리브레이션 담당자가 4바이트 값을 설정하고 두 개의 정보를 하나의 CAN 메
시지에 담아 보내려고 한다면, 이를 위한 공간이 부족할 것이다. 주소와 새로운 값을 보내
는데 총 9바이트가 필요하므로, 변경값을 CAN 메시지 하나(7바이트)에 담아 보낼 수 없
다. 그러므로 마스터에서 슬레이브로 보내는 캘리브레이션 요청은 두 개의 메시지로 구성
된다. 슬레이브는 반드시 이 두 개의 메시지를 받았는지를 알려야 하며, 그에 따라 총 4
개의 메시지가 교환된다.
다음 그림은 파라미터값을 설정하는 데 필요한 마스터와 슬레이브 간의 통신을 보여주

고 있다. 실제 메시지는 봉투 기호가 있는 행에 위치한다. 메시지 해석은 마우스로 봉투
기호를 클릭하면 나타난다.
그림 14: 캘리브레이션 프로세스 추적의 예
마스터의 첫 번째 메시지에서(그림 14에서 회색으로 강조), 마스터는 SET_MTA 명령어를

신규값을 사용해야 할 주소와 함께 슬레이브로 보낸다. 두 번째 메시지에 슬레이브는 그
명령어에 대해 Ok:SET_MTA로 긍정적인 확인신호를 보낸다.
세 번째 메시지를 다운로드하면 헥스 값과 유효 바이트 값을 보낸다. 이 예에서 유효 바이트

값은 부동 소수점 값이기 때문에 4가 된다. 슬레이브는 이 네 번째 메시지에도 긍정적인
확인 신호를 보낸다.
이로써 이 캘리브레이션 프로세스가 완료된다. 추적(Trace) 과정에서는 벡터(Vector)의

측정/캘리브레이션 툴인 CANape의 특별 명령어인 SHORT_UPLOAD가 사용되었다. 이
캘리브레이션 작업을 성공적으로 마무리하기 위해서는 프로세스가 완료된 후 이 값을 다시
읽어 디스플레이를 업데이트해야 한다. 이에 따라 사용자는 캘리브레이션 명령어가 실행되
었는지 직접 확인할 수 있게 된다. 이 명령어는 또한 긍정적인 확인 신호인 Ok:SHORT_
UPLOAD를 받게 된다.
ECU의 RAM에서 파라미터가 변경되는 경우, 해당 어플리케이션은 새로운 값을 처리한다.

그러나 ECU를 재부팅 하는 경우 RAM에 저장된 이 값은 소거되고 플래시에 저장된 초기
값이 오버라이트 된다(제3장 "캘리브레이션 개념" 참조). 그러면 변경된 파라미터 세트를
어떻게 해야 영구적으로 저장할 수 있을까?
1.2 CTO 교환 31
기본적으로 두 가지 가능한 방법이 있다.
A) 파라미터를 ECU에 저장
RAM에 있는 변경된 데이터는 예를 들어 ECU의 EEPROM에 저장할 수 있다. 이 작업은
ECU를 램프 다운(ramping down)할 때 자동으로 또는 사용자에 의해 수동으로 저장할 수
있다. 여기서 전제조건은 데이터를 슬레이브의 비휘발성 메모리에 저장할 수 있어야 한다.
ECU에는 이에 상응하는 것으로 EEPROM이나 플래시가 있다. 그러나 수천 개의 파라미터
를 가진 ECU에서는 사용하지 않는 EEPROM 메모리 공간을 제공하기 힘들어서 이 방법은
거의 사용되지 않는다.
또 다른 방법은 RAM에 있는 파라미터를 다시 ECU의 플래시 메모리에 쓰는 것이다. 이

방법은 상대적으로 복잡하다. 다시 쓰기 전에 플래시 메모리를 먼저 지워야 한다. 또한,
이 작업은 블록 단위로만 할 수 있다. 결과적으로 이 작업은 단순히 각각의 바이트를
다시 쓰는 문제가 아니다. 이에 대한 자세한 내용은 제3장 "캘리브레이션 개념"에서 확인할
수 있다.
B) 파라미터를 PC에 파일 형태로 저장

파라미터는 PC에 저장하는 것이 더 보편적이다. 모든 파라미터나 일부분의 파라미터는
파일의 형태로 저장된다. 이를 위해 다른 포맷을 사용할 수 있다. 가장 간단한 것은 ASCII
텍스트 파일을 사용하는 것으로 이 파일에는 객체명과 그 값만 실리게 된다. 다른 포맷에
서는 파라미터의 수정 이력이나 성숙도 레벨 등과 같은 다른 정보도 실을 수 있다.
시나리오: 한 캘리브레이션 담당자가 작업을 마친 후 저녁을 즐기기로 했다. 그래서 이

담당자는 ECU의 RAM에 있는 변경 내용을 PC에 파라미터 세트 파일의 형태로 저장했
다. 다음 날, 이 담당자는 ECU를 가동했다. 해당 파라미터는 부팅 시 RAM에서 초기화
되었다. 그런데 ECU는 플래시 메모리에 저장된 값을 사용해 시스템을 부팅했다. 즉, 그
전날 변경한 내용이 ECU에서 사라진 것이다. 그 전날 끝낸 지점에서 다시 작업을 시작
하려고 담당자는 XCP 다운로드 명령어를 사용하여 ECU의 RAM에 파라미터 세트 파일의
내용을 전송한다.
그림 15: 파라미터 세트 파일을 ECU의 RAM에 전송

헥스(Hex) 파일에 파라미터 세트 파일 저장 및 플래싱
ECU를 플래싱하는 것도 플래시의 파라미터를 변경하는 한 가지 방법이다. ECU가 부팅할

때 파라미터들은 RAM에 새로운 파라미터로 기록된다. 파라미터 세트 파일은 C나 H 파일로
전송하여 다른 컴파일러/링커 작업 시 새로운 플래시 파일로 만들 수 있다. 그러나 코드의
파라미터에 따라 플래싱할 수 있는 헥스 파일을 생성하는 프로세스는 상당한 시간이 걸릴
수 있다. 또한, 캘리브레이션 담당자는 작업 프로세스에 따라 다른 ECU 소스코드를 보유
하지 않을 수도 있다. 이런 경우, 캘리브레이션 담당자는 이 방법을 사용할 수 없다.
한 가지 대안으로 캘리브레이션 담당자는 파라미터 세트 파일을 기존 플래시 파일에

복사할 수 있다.
그림 16: Hex Window
플래시 파일에는 주소와 값이 들어있는 헥스 파일이 있다. 이제 파라미터 파일을 헥스

파일에 복사하자. 이를 위해 CANape는 파라미터 세트 파일에서 해당 주소와 값을 추출하고
헥스 파일의 해당 위치에 이 파라미터값을 업데이트한다. 이와 같이 해서 변경된 파라미
터값을 갖는 새로운 헥스 파일이 생성된다. 그러나 이 헥스 파일이 플래싱이 가능한 파일
을 획득하기 위해서는 추가적인 프로세스 단계를 거쳐야 한다. 여기서 늘 나타나는 문제는
체크섬인데, ECU는 데이터를 정확하게 받았는지 확인하기 위해 체크섬을 확인한다. 만약
플래싱이 가능한 파일이 존재하는 경우, 이 파일은 ECU에 플래싱되며 ECU가 재부팅한
후에도 사용할 수 있는 새로운 파라미터값이 된다.
1.3 DTO 교환 - 동기화 데이터 교환

그림 8에 나와 있는 것처럼 DTO(Data Transfer Object)는 동기화 측정/캘리브레이션
데이터를 교환하는 데 사용할 수 있다. 슬레이브에서 보낸 데이터는 DAQ를 통해 마스터로
전송되는데, 이때 데이터는 내부 이벤트에 동기화된다. 이렇게 통신이 이루어지는 단계를
둘로 나눌 수 있다. 초기화 단계에서 마스터는 슬레이브와 통신하여 데이터를 보내는데,
이때 슬레이브는 다른 이벤트를 위해 데이터를 보낸다. 이 단계가 지난 후 마스터는 슬
레이브에서 측정을 시작하며 실제 측정 단계가 시작된다. 이 시점에서 슬레이브는 원하는
데이터를 마스터로 보내는데, 이때 마스터는 슬레이브에 "측정 중지" 명령을 보낼 때까지
수신만 한다. 측정 데이터 획득 및 전송의 촉발은 ECU의 이벤트에 의해 제어된다.
마스터는 STIM을 통해 데이터를 슬레이브로 보낸다. 이렇게 통신이 이루어지는 단계도 둘로

나눌 수 있다. 초기화 단계에서는 마스터가 슬레이브와 통신을 하여 데이터를 슬레이브로
보낸다. 이 단계가 지난 다음에는 마스터가 슬레이브로 데이터를 보내고, STIM 프로세서는
데이터를 저장한다. 관련 STIM 이벤트가 슬레이브에서 촉발되는 즉시, 데이터는 어플리케
이션 메모리로 전송된다.
1.3.1 측정 방법: 폴링(Polling) vs DAQ
이벤트 동기화에 대해 설명하기 전에, 슬레이브에서 상호 연관 데이터(Correlated data)

를 측정한다. 여기서는 폴링(Polling)으로 알려진 측정 방법에 대해 간단하게 설명하겠다.
폴링은 DTO에 기반을 둔 것이 아니라 CTO에 기반을 두고 있다. 사실 이 주제는 별도의
장에서 설명해야 하지만 폴링에 대한 설명을 통해 DTO 기반의 측정이 왜 필요한지를
매끄럽게 설명할 수 있기 때문에 폴링에 대해 가볍게 짚고 가도록 하겠다.
마스터는 슬레이브에서 측정 파라미터값을 요청할 때 SHORT_UPLOAD 명령어를 사용할 수

있다. 이것을 폴링이라고 부른다. 이 방법은 가장 간단한 측정방법이다. SHORT_UPLOAD
명령어를 수신하고 실행하는 시점에 측정 파라미터의 측정값을 보내는 것이다.
다음 예에서는 측정 파라미터 "Triangle"을 슬레이브에서 측정했다.
그림 17:
A2L 파일에서 구한
"Triangle" 파라미터의
주소 정보
주소 0x60483는 CAN 프레임에서 5바이트 주소로 표시된다. 여기서 1바이트는 주소 확장

자용으로 4바이트는 실제 주소용으로 사용된다.
그림 18: CANape의 Trace window 내의 폴링 통신
XCP 규격에서는 폴링에 대한 요건을 정하고 있다. 즉, 각 측정 파라미터값은 개별적으로

폴링을 해야 한다는 것이다. 폴링을 통해 측정한 각각의 값에 대해 마스터가 슬레이브에
요청한 값과 마스터로 슬레이브가 보낸 응답, 이 2개의 메시지가 버스를 통해 전달된다.
버스에 부하가 추가로 걸리는 것 말고도 폴링 방법에는 약점이 하나 더 있다. 여러 개의

데이터 값을 폴링할 때 사용자는 보통 데이터를 서로 대비하고자 한다. 그러나 폴링으로
연속해서 측정한 여러 개의 값은 상호 간에 반드시 대비할 수 있는 상태가 아니다. 즉, 이
값들은 같은 ECU의 계산 사이클에서 나온 것이 아니다.
이는 측정에 폴링을 사용하기 어렵게 만드는데, 왜냐하면 이 경우 불필요하게 많은 데이터
트래픽을 초래하고, 이때 얻은 측정값들은 ECU 내의 프로세스 흐름과 관련하여 평가할
수 없기 때문이다.
그러므로 최적화된 측정은 다음 두 가지 과제를 해결해야 한다.

> 측정 중 대역폭 최적화
> 데이터 대비의 보장
이 과제는 이미 언급한 DAQ 방법으로 처리한다. DAQ는 데이터 획득(Data Acquisition)을

뜻하며, 슬레이브에서 마스터로 DTO를 보내 구현할 수 있다.
1.3.2 DAQ 측정 방법
DAQ 방법은 폴링의 두 가지 문제를 다음과 같이 해결한다.

>측 정값의 대비는 ECU의 이벤트에 대한 측정값 획득과 연결하여 달성할 수 있다. 모든
계산이 완료되었음이 확인될 때까지 측정값을 획득하지 않는다.
> 버스의 부하를 줄이기 위해 측정 프로세스를 2단계로 나눈다. 구성 단계에서는 마스터
가 슬레이브에게 관심 있는 값이 무엇인지 문의하고 두 번째 단계에서는 슬레이브의 측
정값을 마스터로 바로 전송한다.
ECU에서는 측정값의 획득을 프로세스와 어떻게 연결할까? 그림 19는 ECU 내의 계산 사

이클과 파라미터 X와 Y 사이의 관계를 보여주고 있다.
Calculation Calculation Calculation

cycle n cycle n+1 cycle n+2 time
10
8
6
X 4
2
0
10
8
6
Y 4
2
0
E1 E1 E1
그림 19:
Read sensor X Calculate Y = X
ECU 내의 이벤트
이제 ECU에서 일어나는 일의 순서에 대해 알아보기로 하자. 이벤트 E1 (= 계산 사이클의

끝)이 발생하면, 모든 파라미터를 획득하고 계산이 행해진다. 이는 이 시점에서 모든 값이
서로 대응하고 대비가 되어야 한다는 것을 의미한다. 또한, 지금 이벤트-동기화 측정 방
법이 사용되고 있다는 것을 나타내기도 한다. 이것이 바로 DAQ 메커니즘의 도움으로 구
현된 것이다. 슬레이브 내의 알고리즘이 "계산 사이클 완료" 이벤트에 도달하면, XCP 슬
레이브는 측정 파라미터값을 수집하고 수집한 값을 버퍼에 저장한 다음 마스터로 보낸다.
여기서는 슬레이브가 특정 이벤트에 대해 어떤 파라미터를 측정해야 하는지 알고 있는 것
으로 가정했다.
특정 이벤트가 반드시 순환적이고 등시적(time-equidistant)인 이벤트일 필요는 없다. 예

를 들어, 엔진 컨트롤러의 경우에는 각 동기화(angle-synchronous)가 될 수도 있다. 이는
두 개의 이벤트 사이의 시간 간격을 엔진의 RPM에 의존하도록 한다. 드라이버에 의한 스
위치의 활성화와 같은 이벤트는 등시적이 될 수 없는 이벤트이다.
사용자는 신호를 선택한다. 실제 측정 객체 이외에 사용자는 측정 파라미터에 대한 하부

이벤트를 선택해야 한다. 이 이벤트는 물론 측정 객체를 해당 이벤트에 할당한 정보는 A2L
파일에 저장해야 한다.
그림 20:
A2L의 이벤트 정의
정상적인 경우에는 하나의 측정값을 여러 개의 이벤트에 동시에 할당하는 것이 아무 의미

가 없다. 일반적으로, 하나의 파라미터는 단지 단일 사이클 내에서만(예: 10ms 간격에서만)
수정할 수 있고, 여러 개의 사이클에서는(예: 10ms와 100ms 간격에서) 할 수 없다.
그림 21:
A2L내의 가능한
이벤트에 "Triangle" 할당
그림 21은 "Triangle" 파라미터를 원칙적으로 1 ms, 10 ms, 100 ms의 이벤트에서 측정할
수 있다는 것을 보여주고 있다. 기본 설정 값은 10 ms이다.
측정 파라미터는 사용자가 측정을 구성하면서 ECU의 이벤트에 할당한다.
그림 22: 각 측정
파라미터에 대한 이벤트
(측정 모드) 선택
측정한 신호를 구성한 후에 사용자는 측정을 시작한다. XCP 마스터는 원하는 측정 파라미
터를 DAQ 리스트로 알려진 리스트에 열거한다. 이 리스트에는 측정한 신호가 선택된 이벤
트에 각각 할당되어 있다. 이 구성 정보는 측정을 실제로 시작하기 전에 슬레이브로 보낸
다. 그러면 해당 슬레이브는 어떤 이벤트가 발생했을 때 어떤 주소에서 데이터를 읽어 전
송해야 하는지 알게 된다. 측정 작업을 이와 같이 구성 단계와 측정 단계로 배분하는 것
은 이 장을 시작할 때 이미 언급한 바 있다.
이 방법은 폴링 시 발생하는 두 가지 문제를 모두 해결한다. 즉, 측정 도중 마스터가 각각

의 값을 폴링할 필요가 없으므로 대역폭을 최적화하여 사용하고, 측정값은 상호 간에 대
비가 된다는 것이다.
그림 23: DAQ 측정 시 CANape Trace Window의 예
그림 23은 마스터와 슬레이브 사이에 명령어-응답 통신의 예를 (색으로 강조하여) 보여주고

있다(전체적으로 이 작업은 상당히 광범위하며, 여기에는 공간상의 이유로 일부만 실었다).
여기에는 DAQ 구성을 슬레이브로 보내는 것도 포함된다. 이후에 측정 시작이 촉발되고
슬레이브는 요청받은 값을 보내며, 마스터는 그냥 수신만 한다.
지금까지 신호의 선택은 신호명과 측정 이벤트에 대한 할당 여부로 기술했다. 정확하게

어떤 방식으로 구성을 XCP 슬레이브로 전송할 수 있을까?
이제 ECU의 메모리 구조의 관점에서 이 문제를 보기로 하자. 사용자는 신호를 선택하
고 이를 측정하고자 한다. 그래서 신호 값을 보내는 것은 메시지 전체를 사용할 필요가
없으므로 슬레이브에서 나온 신호는 메시지 패킷으로 결합한다. 슬레이브는 이 결합의
정의를 독립적으로 생성하지 않는데, 그렇지 않을 경우 마스터는 메시지를 수신할 때 데이터를
해석할 수 없을 것이다. 그러므로 슬레이브는 이 값을 메시지에 어떻게 배분해야 하는지에
대한 지시를 마스터로부터 받는다.
슬레이브가 해당 바이트를 메시지에 결합하는 순서는 객체 기술 테이블(ODT)에 정의된

다. 주소와 객체 길이는 측정할 객체를 식별하는 데 중요하다. ODT는 버스를 거쳐 온
메시지를 조립하기 위해 슬레이브에서 RAM의 내용을 할당한다. 이 통신 모델을 따르면,
이 메시지는 DAQ DTO(데이터 전송객체)로 전송된다.
RAM Cells
ODT
0 address, length
1 address, length
2 address, length
3 address, length
...
PID 0 1 2 3 ...
그림 24:
ODT: DAQ DTO로
RAM 주소 할당
더 정확하게 말하자면, ODT 리스트에 입력한 값은 주소와 객체길이를 이용해 RAM의

메모리 영역을 참조한다.
측정 시작 명령을 수신한 후 어떤 시점에서 측정과 연관된 이벤트가 발생한다. XCP 슬레

이브는 데이터를 획득하기 시작한다. 슬레이브는 각각의 객체를 패킷으로 결합하고, 패킷을
버스를 통해 보낸다. 마스터는 버스 메시지를 읽고 각각의 데이터를 해석할 수 있는데,
그 이유는 각각의 객체를 패킷 자체에 할당하도록 정의해서 그 사이의 관계를 알고 있기
때문이다.
그러나 각 패킷은 최대 바이트를 가지고 있는데, 이 값은 사용하는 전송에 따라 다르다.

CAN의 경우에는 7바이트가 된다. 측정하는데 더 많은 데이터가 필요하다면, ODT 하나로
는 더 이상 충분하지 않다. 측정값을 전송하는데 2개 이상의 ODT가 필요하다면, 슬레이브
는 데이터를 정확한 ODT에 복사하고 마스터는 수신한 ODT를 고유하게 식별할 수 있어야
한다. ECU의 측정 간격이 여러 개일 경우에는 ODT와 측정 간격의 관계도 역시 고유하게
식별할 수 있어야 한다.
ODT는 XCP 프로토콜의 DAQ 리스트에 결합한다. 각 DAQ 리스트에는 다수의 ODT가
포함되며, 이는 하나의 이벤트에 배정된다.
ODT #2 0 address, length

1 address, length
2 address, length
1 address, length
3 address,
2 address, lengthlength
1 address, length
... PID=2 0 1 2 3 ...
3 address, length
2 address, length
... PID=1 0 1 2 3 ...
3 address, length 그림 25:
... PID=0 0 1 2 3 ... 3개의 ODT를 가진
DAQ 리스트
예를 들어, 사용자가 두 개의 측정 간격을 사용한다면(= ECU에서 2개의 다른 이벤트),

DAQ 리스트도 두 개가 사용되어야 한다. 사용한 이벤트마다 하나의 DAQ 리스트가 필요
하다. 각 DAQ 리스트에는 ODT에 관련된 입력값이 실려 있으며, 각각의 ODT에는 RAM
셀에 들어있는 값에 대한 참조 값이 들어 있다.
DAQ 리스트는 정적(static), 사전정의(predefined) 및 동적(dynamic)의 유형별로 구분된다.
정적인 DAQ 리스트:

만약 DAQ 리스트와 ODT 테이블이 CCP에서처럼 ECU에 영구적으로 정의되어 있다면, 이
를 정적인 DAQ 리스트라고 부른다. 여기에는 어떤 측정 파라미터가 ODT 리스트에 들어있
는지에 대한 정의는 없고, 다만 채울 수 있는 프레임워크(framework)만 있다(이에 대해서
사전 정의된 DAQ 리스트 참조).
정적인 DAQ 리스트에서는 이 정의가 ECU 코드에 설정되어 있으며, A2L에 기술되어 있다.
그림 26은 정적인 DAQ 리스트가 정의되어 있는 A2L 파일의 발췌본을 보여주고 있다.
그림 26:
정적인 DAQ 리스트
위의 예에서 보면 숫자 0이 있는 DAQ 리스트가 있는데, 0은 10ms 이벤트에 할당되었으며,

최대 2개의 ODT를 반송할 수 있다. 숫자 1이 있는 DAQ 리스트는 4개의 ODT를 가지고
있으며, 100ms 이벤트에 연결되어 있다.
A2L 파일은 ECU의 내용에 정합한다. 정적인 DAQ 리스트의 경우, DAQ 리스트의 수와 이들
각각이 싣고 있는 ODT 리스트는 ECU에 어플리케이션을 다운로드하여 정의한다. 만약
사용자가 한 이벤트에서 할당된 DAQ 리스트에 실린 것보다 많은 수의 신호를 측정하려고
시도한다면, ECU의 슬레이브는 이 요구사항을 충족시킬 수 없으며, 이를 구성하려는 시도는
오류를 일으키게 될 것이다. 다른 DAQ 리스트가 아직 사용 가능해 실제로 전송 능력이
있는지는 상관이 없다.
사전정의된 DAQ 리스트:

완전히 사전에 정의한 DAQ 리스트도 ECU 내에서 설정할 수 있다. 그러나 이 방식은
사용자들에게 융통성이 부족하다는 이유로 실질적으로 ECU에 사용된 적이 없다. 이 방식은
XCP로 데이터를 전송하는 아날로그 측정 시스템과도 다르다. 이 경우에는 측정 시스템의
물리적 구조가 그 수명주기 동안 동일하게 유지되기 때문에 융통성이란 불필요하다.
동적인 DAQ 리스트:

XCP 프로토콜의 한 가지 특별한 점은 동적인 DAQ 리스트이다. 이는 ECU 코드에 영구적
으로 정의되어 있는 DAQ의 절대 파라미터와 ODT 리스트가 아니라 DAQ 리스트가 사용할
수 있는 메모리 영역의 파라미터에 불과하다. 이 리스트의 장점은 측정 툴이 DAQ
리스트를 만들 때 좀 더 많은 자유(latitude)를 가지고 있으며 DAQ 리스트의 구조를 동적
으로 관리할 수 있다는 점이다.
마스터가 슬레이브 내의 DAQ 리스트의 구조를 정의하는 데 사용할 수 있는 함수 ALLOC_

ODT와 같이 이 동적 관리를 위해 설계한 다양한 함수가 XCP에 나와 있다.
MIN_DAQ + DAQ_COUNT
DAQ1
DAQ0
AQ
_D
OC
ALL
ALLOC_OD
T_ENTRY
ODT_ENTERIES_COUNT
ALLOC_ODT
GRANULARITY_ODT_ENTRY_SIZE_DAQ
그림 27:
ODT_COUNT
동적인 DAQ 리스트
마스터는 DAQ 리스트를 만들 때 사용하는 DAQ 리스트가 동적인지 또는 정적인지, DAQ

리스트의 파라미터와 구조가 어떤 모양인지 등을 구별할 수 있어야 한다.
1.3.3 STIM 캘리브레이션 방법
XCP 캘리브레이션 방법에 대해서는 이미 CTO 교환에 대한 장에서 소개한 바 있다. 이러한
캘리브레이션 유형은 모든 XCP 드라이버에 존재하고 있으며, ECU의 캘리브레이션 객체에
대한 근간을 이루고 있다. 그러나 캘리브레이션 명령어를 보내는 일과 ECU내의 이벤트
사이에는 동기화가 이루어지지 않는다.
이와 반대로 STIM을 사용하는 것은 CTO 교환을 바탕으로 하지 않으며, 오히려 슬레이브 내의

이벤트에 동기화하는 통신에서 DTO를 사용하는데 바탕을 두고 있다. 그러므로 마스터는
슬레이브 내에 있는 어떤 이벤트를 동기화시킬 수 있는지 알고 있어야 한다. 이런 정보는
A2L 파일에 실려 있어야 한다.
그림 28: DAQ와 STIM을 위한 이벤트
마스터가 STIM으로 슬레이브에 데이터를 보낼 때, XCP 슬레이브는 반드시 패킷 내에

서 캘리브레이션 파라미터를 찾을 수 있는 위치를 보내야 한다. 동일한 메커니즘이 DAQ
리스트에서도 사용되고 있다.
1.3.4 DAQ와 STIM에 대한 XCP 패킷 주소 지정
XCP 패킷에 대한 주소 지정 문제는 이 장의 첫머리에서 이미 논의했다. 이제 DAQ와 ODT,

STIM의 개념을 소개했으므로, XCP 패킷 주소 지정에 대해 좀 더 자세히 알아 보자.
CTO를 전송하는 중에는 패킷을 식별하는 데 PID를 사용하는 것으로도 충분하다. 그러나
이 방식은 측정값을 전송하는 데에는 충분하지 않다. 다음 그림은 DTO 전송 시의 주소 지
정 방식에 대한 개요를 보여주고 있다.
XCP DTO Packet

Identification Field Timestamp Field Data Field
PID
PID DAQ TS
PID DAQ TS
그림 29:
DTO 전송을 위한
XCP 패킷의 구조
전송 유형: "절대 ODT값"
절대(absolute)라는 의미는 해당 ODT수가 통신 전반에 걸쳐, 즉 모든 DAQ 리스트에서 고

유하다는 뜻이다. 또한, 이는 절대 ODT값을 사용한다는 것은 DAQ 리스트에 대한 소위
"FIRST_PID"를 이용하는 전환단계를 가정한다는 뜻이기도 하다.
만약 어떤 DAQ 리스트가 PID j로 시작한다면, 첫 패킷의 PID는 값 j를 갖고, 두 번째 패킷

의 PID 값은 j + 1이 되며, 세 번째 패킷의 PID 값은 j + 2가 되는 식이다. 슬레이브는 자연
적으로 FIRST_PID + 상대 ODT값의 합이 다음 DAQ 리스트의 PID보다 낮도록 해야 한다.
DAQ 리스트: 0 ≤ PID ≤ k

DAQ 리스트: k + 1 ≤ PID ≤ m
DAQ 리스트: m + 1 ≤ PID ≤ n
등.
이 경우, 식별 필드는 매우 간단하다:
PID
그림 30:
절대 ODT값을 가진
absolute ODT number
식별 필드
전송 유형: "상대 ODT값과 절대 DAQ 리스트 수"
이 경우, DAQ 리스트 수와 ODT 수는 식별 필드로 전송할 수 있다. 그러나 해당 정보에

사용할 수 있는 바이트 수가 남아 있다.
PID DAQ
그림 31:
absolute DAQ List number 상대 ODT 수와
절대 DAQ 수를 갖는
relative ODT number
ID 필드(1바이트)
그림에서 1바이트는 DAQ수로 사용할 수 있으며, 1바이트는 ODT 수로 사용할 수 있다
DAQ 리스트의 최대 수는 2바이트를 사용해서 전송할 수 있다.
PID DAQ
그림 32:
absolute DAQ list number 상대 ODT 수와
relative ODT number 절대 DAQ 수를 갖는
ID 필드(2바이트)
3바이트를 보내는 것이 불가능하다면, 필 바이트(fill byte) 1개를 추가해서 4바이트로

작업할 수 있다.
PID FILL DAQ

그림 33:
상대 ODT 수와 절대
absolute DAQ list number
DAQ 수, 그리고 필
for alignement
바이트를 갖는 ID 필드
relative ODT number (총 4바이트)
이제 XCP 마스터가 슬레이브를 어떤 방법으로 사용하는지 어떻게 알 수 있을까? 먼저

A2L 파일에 입력하거나 두 번째로는 어떤 통신 버전을 구현하고 있는지 슬레이브에 요청
하는 것이다.
GET_DAQ_PROCESSOR_INFO 요청에 대한 응답은 또한 슬레이브가 어떤 전송 유형을 사

용하고 있는지 마스터에게 통지하는 데 사용하는 DAQ_KEY_BYTE도 설정한다. DAQ만 사
용하는 것이 아니라 STIM도 사용되는 경우, 마스터는 슬레이브가 DAQ를 위해 사용하는
것과 같은 방법을 STIM에 사용해야 한다.
1.3.5 바이패싱 = DAQ + STIM
바이패싱은 DAQ와 STIM을 함께 사용하여 구현할 수 있으며(그림 8 참조), 이는 래피드 프

로토타이핑 솔루션의 특수한 형태를 나타낸다. 그러나 좀 더 깊이 이해하기 위해서는 더
욱 구체적인 내용이 필요하므로 이 방법은 제4.5장 "바이패싱"을 다룰 때까지는 남겨두도
록 하겠다.
1.4 XCP 전송 레이어

프로토콜을 설계할 때 주요한 요구사항 중 하나는 다른 전송 레이어들을 지원해야 한다는 것
이다. 이 문서를 작성할 무렵에 XCP on CAN과 FlexRay, Ethernet, SxI, USB 등의 레이어가
정의되었다. CAN이나 LIN, FlexRay 등의 버스 시스템에 대해서는 벡터 사의 이러닝
플랫폼에서 설명하고 있다. 웹사이트 www.vector-elearning.com을 참조하도록 하라.
1.4.1 CAN
XCP는 CAN 캘리브레이션 프로토콜(CCP)의 후계 프로토콜로 개발되었으며, CAN 버스의

요구사항을 완전히 충족시키고 있다. CAN 버스를 통한 통신은 관련 기술 파일에서 정의
하고 있다. 보통은 DBC 포맷이 사용되지만, 어떤 경우에는 AUTOSAR 포맷인 ARXML이
사용되기도 한다.
CAN 메시지는 고유한 CAN 식별자로 식별한다. 통신 매트릭스는 누가 어떤 메시지를 보

냈으며, CAN 버스에서 8바이트가 어떻게 사용되었는가? 등과 같이 기술 파일에 정의되어
있다. 다음 그림은 이 프로세스를 보여주고 있다.
Data CAN CAN CAN CAN

Frame Node A Node B Node C Node D
ID=0x12 Sender Receiver
ID=0x34 Sender Receiver Receiver
ID=0x52 Receiver Sender
ID=0x67 Receiver Receiver Sender Receiver
그림 34:
ID=0xB4 Receiver Sender
어떤 버스 노드가
ID=0x3A5 Sender Receiver Receiver Receiver 어떤 메시지를
보냈는지에 대한 정의
ID가 0x12인 메시지가 CAN 노드 A에서 발송되었으며, 버스 상에 있는 다른 모든 노드는

이 메시지를 수신한다. 인수 시험의 프레임워크에서 CAN 노드 C와 노드 D는 이 메시지가
필요 없다고 결론 내리고 수신을 거절했다. 반면에 CAN 노드 B는 상위 레이어에서 이
메시지가 필요하리라 판단하고 Rx 버퍼를 통해 보냈다. CAN 노드는 다음과 같이 상호
연결된다.
CAN Node A CAN Node B
Host Host
CAN Interface CAN Interface
Tx Rx Tx Rx
Buffer Buffer Buffer Buffer
Acceptance Acceptance
Test Test
Send Receive Send Receive
CAN
Receive Send Receive Send
Acceptance Acceptance
Test Test
Rx Tx Rx Tx
Buffer Buffer Buffer Buffer
CAN Interface CAN Interface
Host Host
그림 35:
CAN Node C CAN Node D
CAN 네트워크의 예
이 XCP 메시지는 통신 매트릭스에서 기술하고 있지 않았다! 만약 이 측정값이 슬레이브에서

동적인 DAQ 리스트를 통해 예를 들어 XCP의 도움을 받아 발신된 것이라면, 이 메시지는
사용자가 선택한 신호에 따라 조립된다. 신호 선택이 변경되는 경우에는 메시지 내용도
마찬가지로 변경된다. 그러나 통신 매트릭스와 XCP 사이에는 관계가 있다. 즉, CAN
식별자는 XCP 메시지를 CAN을 통해 전송해야 할 필요가 있다. 사용한 CAN 식별자의 수를
최소화하기 위해, XCP 통신은 단 2개의 CAN 식별자만 사용하도록 제한되며, 이 식별자는
"정상적인" 통신을 위해 DBC에서 사용할 수 없다. 마스터에서 슬레이브로 정보를 전송하는
데에는 하나의 식별자가 필요하다. 다른 하나는 슬레이브가 마스터로 응답을 보낼 때
사용한다.
CANape Trace Window에서 발췌한 내용에서는 "ID"열에 사용한 CAN 식별자를 보여주고
있다. 이 예에서는 단지 2개의 다른 식별자가 사용되었다. 마스터에서 슬레이브로 보내는
(Tx 방향) 메시지의 ID로 554를 사용하고, 슬레이브에서 마스터로 보내는 (Rx방향) 메시지의
ID로 555를 사용했다.
그림 36: XCP on CAN 통신의 예
이 예에서는 XCP 통신 전체를 2개의 CAN 식별자(554와 555)로 처리했다. 이 두 개의 ID는

이 네트워크에서 다른 목적으로 할당할 수 없을 것이다.
CAN 버스는 메시지당 최대 8바이트를 전송한다. 그러나 XCP의 경우에는 사용한 명령어나
발송한 응답에 대한 정보가 필요하다. 이 정보의 CAN 데이터의 첫 번째 바이트에 실리게
된다. 이 말은 데이터를 전송할 때 CAN 메시지당 7바이트를 사용할 수 있다는 뜻이다.
XCP on CAN Message (Frame)

XCP Packet XCP Tail
XCP Header
empty for CAN PID FILL DAQ TIMESTAMP DATA Fill
Control Field Control Field

empty for CAN for CAN
그림 37: XCP on CAN 메시지의 예
CANape에서는 XCP on CAN 데모 프로그램과 가상 ECU XCPsim을 이용해 볼 수 있다.

이 표준에 대한 상세한 내용은 ASAM XCP on CAN 파트 3 전송 레이어 규격에서 찾을
수 있다.
1.4.2 CAN FD
CAN FD(가변 데이터 전송속도를 지원하는 CAN)는 Robert Bosch사에서 개발한 CAN 프
로토콜의 확장 기능이다. 이 확장 기능은 유효 데이터의 크기를 8바이트에서 64바이트로
늘렸다는 점에서 CAN과 차이가 난다. CAN FD는 도한 유효 데이터를 보다 빠른 전송속
도로 보낼 수 있는 옵션을 제공한다. 중재 단계가 끝난 후에는, 데이터를 중재 단계 때보
다 빠른 속도로 전송할 수 있다. 이 때문에 CAN 개발에서 취득한 귀중한 경험을 그대로
살리면서도 자동차 네트워크에 보다 넓은 대역폭을 제공할 수 있다.
XCP-on-CAN-FD 규격은 XCP 표준 버전 1.2.0(2013년 6월)의 XCP-on-CAN 기술서에
정의되어 있다.
그림 38: CAN FD 프레임의 예
운영 모드는 상당히 비슷하지만 이 프로토콜은 하드웨어와 소프트웨어를 수정하고 확장

기능을 추가해야 한다. 특히 CAN FD는 제어 필드에 다음과 같은 세 개의 비트 형식을
새로 도입했다.
> Extended Data Length (EDL)
> Bit Rate Switch (BRS)
> Error State Indicator (ESI)
열성인 EDL 비트(고수준)는 우성인 EDL 비트(저수준)가 식별할 수 있기 때문에 확장

CAN-FD 포맷의 프레임을 표준 CAN 포맷의 프레임과 구분하게 된다. 마찬가지로 열성인
BRS 비트는 데이터 필드 전송 시 더 높은 비트 전송속도로 전송이 되게 한다.
ESI 비트는 CAN FD 노드의 오류 상태를 확인한다. 다른 네 개의 비트가 Data Length
Code(DLC)라는 것을 구성하는데, 이것은 확장된 유효 데이터 길이를 12, 16, 20, 24, 32,
48, 64 바이트로 한다.
XCP on CAN FD를 사용할 때에는 A2L 파일에서 이차 전송속도를 유효 데이터로 정의한
경우를 가정한 것이다. 이런 작업은 사용자에게는 완전히 투명하며, 사용자는 A2L을 완전히
파라미터화 시키게 된다.
XCP 마스터의 측정방식을 설정할 때에는 패킷의 최대 길이를 고려해야 하며, 사용자는 다른
설정값은 건드릴 필요가 없다.
CAN FD는 CANape 버전 12.0 이상에서 지원한다. Vector 사의 CAN 하드웨어 중 "VN"으로
시작하는 제품은 모두 CAN FD 전송 프로토콜을 지원한다.
1.4.3 FlexRay
FlexRay 개발의 기본 아이디어는 결정론적 시간 거동을 하는 이중화(redundant) 시스템을

구현하는 것이었다. 접속의 이중화는 채널2개(채널 A와 채널 B)를 사용해서 달성했다. 다수의
FlexRay 노드(= ECU)가 중복적으로 상호접속하는 경우, 한 개의 지선에 문제가 발생한
경우, 해당 노드 이중화된 접속을 이용해서 다른 채널로 전환할 수 있다.
Node K Node L Node M Node N Node O
CH A
CH B
그림 39: 노드 K와 노드 L은 중복적으로 상호접속됨
결정론적 거동은 지정된 타임 슬롯 내에서 데이터를 전송함으로써 달성된다. 여기서 정의되는

것 중 하나는 어떤 노드가 어떤 내용을 어떤 타임 슬롯으로 보내느냐 하는 것이다. 이 타임
슬롯은 하나의 사이클을 형성하도록 결합한다. 여기서 이 사이클은 버스가 활성화된 동안
반복된다. 타임 슬롯과 그 전송 내용(누가 무엇을 언제)을 조합하는 것을 스케줄링
(Scheduling)이라고 부른다.
Node K Node L Node M
Slot Direction Frame Slot Direction Frame Slot Direction Frame

1 Tx a 1 Tx a 1 Tx a
3 Rx x 3 Rx b 3 Rx x
Frame: a Frame: b Frame: x Frame: a Frame: b Frame: x
Slot 1 Slot 2 Slot 3 Slot 1 Slot 2 ... Real-time

t1 t2 t3 t4 t5 t6
Communication Cycle Next Communication Cycle
그림 40: 슬롯 정의에 의한 통신
최초의 통신 사이클에서 노드 K는 프레임 a를 슬롯 1로 보낸다. 이 스케줄링은 노드 L과

노드 M의 소프트웨어에도 저장된다. 그러므로 프레임 a의 내용은 차상위의 통신 계위로
보내진다.
스케줄링은 기술 파일에 통합되어 있다. 이 파일은 CAN의 경우처럼 DBC 파일은 아니고
FIBEX 파일이다. FIBEX는 "필드 버스 교환 포맷(Field Bus Exchange Format)"을 말하며,
다른 버스 시스템용으로도 사용할 수 있다. 그러나 현재 이 포맷의 사용은 실질적으로
FlexRay 버스 기술에 국한되어 있다. FIBEX는 XML 포맷이며, XCP on FlexRay 규격은
FIBEX 버전 1.1.5와 FlexRay 규격 버전 2.1에 연관되어 있다.
Cycles
Slot ECU Channel
0 1 2 3 4 5 6 ... 63
A b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ]
1 Node K
Static Segment
B b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ] b [rep : 1 ]

A c [rep : 4 ] x [rep : 2 ] y [rep : 4 ] x [rep : 2 ] c [repc : 4 ] x [rep : 2 ] y [rep : 4 ] x [rep : 2 ]
2 Node M
B
A a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ] a [rep : 1 ]
3 Node L
B d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ] d [rep : 1 ]
Node L A n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ] n [rep : 1 ]
4
Node O B m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ] m [rep : 1 ]
Node N A r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ] r [rep : 1 ]
5
B
Dynamic Segment
A
6
Node K B o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ] o [rep : 1 ]
Node M A t [rep : 2 ] p [rep : 4 ] t [rep : 2 ] t [rep : 2 ] p [rep : 4 ] t [rep : 2 ]
B
Node L A u [rep : 4 ] u [rep : 4 ]
7
Node L B v [rep : 8 ]
A
Node O B w [rep : 4 ] w [rep : 4 ]
그림 41: FlexRay 통신 매트릭스의 예
버스 통신을 설명하는 또 하나의 포맷은 AUTOSAR 솔루션 개발의 결과로 정의되었는데,

이는 AUTOSAR 기술 파일로 XML 포맷으로 사용할 수 있다. XCP on FlexRay의 정의는
AUTOSAR 4.0 규격을 고려했다. 그러나 이 책을 발간할 당시에는 이 규격이 아직 공식적으로
승인받지 못했기 때문에 더는 언급하지 않도록 하겠다.
FlexRay 버스의 다른 특성 때문에 슬롯 번호를 내용에 대한 참조로 사용하기에는 충분하지

않다. 한가지 이유는 다중화를 지원한다는 것이다. 한 사이클이 반복될 때마다, 전송된 내용이
반드시 동일할 필요는 없다. 다중화(multiplexing)에서는 두 번째 패스마다 특정 정보를
슬롯에 보내도록 지정할 수도 있다.
순수한 슬롯 번호를 지시하는 대신, "FlexRay 데이터 링크 레이어 프로토콜 데이터 유닛

식별자(FLX_LPDU_ID)"가 사용되는데, 이것은 일반화된 슬롯 ID의 한 유형으로 이해하면
된다. LPDU를 기술하는데 4가지 정보가 필요하다.
> FlexRay 슬롯 식별자 (FLX_SLOT_ID)
> 사이클 카운터 오프셋 (OFFSET)
> 사이클 카운터 반복 (CYCLE_REPETITION)
> FlexRay 채널 (FLX_CHANNEL)
LPDU_ID
... Channel A
Cycle ID
... ... Channel B

.. .. .. .. .. .. .. .. .. .. ..... .. .. .. ..
. . . . . . . . . . . . . . .
..
.
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . .... . . . . .
..
.
... ...
... ...
...
그림 42:
Slot ID
FlexRay LPDU의 예
스케줄링은 또한 XCP on FlexRay 사용에도 영향을 미치는데, 왜냐하면 이 기능은 정확하게

무엇을 보내야 하는지를 정의하기 때문이다. XCP에서는 측정 런타임에서 사용자가 신호를
조합해서 어떤 측정값을 보내야 하는지 정의하기 전까지는 이런 것을 쉽게 정의할 수 없다.
이 말은 XCP 통신의 어떤 측면은 어떤 LPDU에서만, 즉 마스터에서 슬레이브로 보내는
CTO나 DTO, 또는 슬레이브에서 마스터로 보내는 CTO or DTO에서만 사용할 것인지 선택
하는 것만 가능하다는 뜻이다.
다음 예에서 이 프로세스를 보여주고 있다. XCP 마스터에서 슬롯 n으로 명령어 (CMD)를

보내면, 슬레이브 A는 슬롯 n + 2로 응답(RES)을 보낸다. XCP on FlexRay의 메시지는
항상 LPDU를 사용해서 정의한다.
ECU 내부의 파라미터에 액세스하기 위해서는 A2L 기술 파일이 필요하다. ECU 내에서 주소를
가진 객체는 이 파일에서 정의된다. 또한, FIBEX 파일도 필요한데, 그래야 XCP 마스터가
어떤 LPDU를 보내야 하는지 또 XCP 슬레이브가 응답하면서 어떤 LPDU를 보내는지 알
수 있다. XCP 마스터와 XCP 슬레이브 사이의 통신은 두 개의 파일을 결합하는 경우, 즉
A2L 파일이 FIBEX 파일을 참조하도록 하는 경우에만 기능한다.
XCP on FlexRay 파라미터 설정 값을 갖는 A2L 파일의 발췌본은 다음과 같다.
...
/begin XCP_ON_FLX
...
"XCPsim.xml"
"Cluster_1"
...
이 예에서 "XCPsim.xml"은 A2L 파일에서 FIBEX 파일로 참조하도록 하는 참조파일이다.
XCP-dedicated LPDU_IDs
... Channel A
Cycle ID
... ... Channel B

.. .. .. .. .. .. .. .. .. .. ..... .. .. .. ..
. . . . . . . . . . . . . . .
..
.
.. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . .... . . . . .
..
.
... ...
... ...
... 그림 43:
XCP 통신을
Slot ID
LPDU로 할당
CANape의 온라인 도움말에서 XCP on FlexRay에 관한 상세한 내용을 찾을 수 있다.

FIBEX 뷰어도 CANape와 함께 제공되는데, 이 툴을 이용해 스케줄링을 편리하게 볼 수
있다. CANape에서 XCP on FlexRay 기기에 대한 드라이버 설정값을 만들어 XCP 메시지
를 LPDU에 할당하기는 쉽다.
이 프로토콜은 ASAM XCP on FlexRay 파트 3 전송 레이어 규격에서 상세하게 설명하고

있다. CANape에서는 XCP on CAN 데모 프로그램과 가상 ECU XCPsim을 이용해 볼 수
있다. 이 데모 프로그램을 구동하려면 벡터 사의 FlexRay 하드웨어가 필요하다.
1.4.4 Ethernet
XCP on Ethernet은 TCP/IP나 UDP/IP와 함께 사용할 수 있다. TCP는 Ethernet에서

사용하는 보호된 전송 프로토콜로 그 핸드세이크 방식은 패킷 손실을 탐지하는 데 사용
된다. 패킷 손실이 탐지된 경우, TCP는 패킷을 반복적으로 전송한다. UDP는 이러한 보호
메커니즘을 제공하지 않는다. 패킷 손실이 발생한 경우, UDP는 프로토콜 차원에서 손실된
패킷을 반복적으로 보내는 메커니즘을 제공하지 않는다.
XCP on Ethernet은 실제 ECU에서 사용할 수 있을 뿐 아니라 가상 ECU의 측정/캘리브레

이션용으로도 사용할 수 있다. 여기서 가상 ECU란 ECU에서 구동되는 코드를 PC상의 실행
프로그램(예를 들어 DLL)으로 실행할 수 있도록 한 것이다. 이 경우에는 ECU와 비교할 때
전혀 다른 자원을 사용하게 된다 (CPU, 메모리 등).
그러나 먼저 실제 프로토콜에 대해 논의해 보기로 하자. 하나의 IP 패킷은 항상 발신자와

수신자 주소를 포함한다. IP 패킷을 가시화해 볼 수 있는 가장 간단한 방법은 수신자와
발신자의 주소가 함께 쓰여 있는 편지라고 생각해보는 것이다. 개별 노드의 주소는 항상
고유해야 한다. 고유 주소는 IP 주소와 포트 번호로 구성된다.
XCP on Ethernet (TCP/IP and UDP/IP) Message (Frame)

empty for Ethernet
LEN CTR PID FILL DAQ TIMESTAMP DATA (TCP/IP and UDP/IP)
Control Field Length (LEN) Control Field

for Ethernet empty for Ethernet
(TCP/ IP and UDP/IP) (TCP&IP and UDP&IP)
그림 44: TCP/IP 또는 UDP/IP에서의 XCP 패킷
헤더는 인텔(Intel) 포맷(= 4바이트)의 2단어로 된 제어(Control) 필드로 구성된다. 이 단어들은

길이(LEN)와 카운터(CTR)를 담고 있다. LEN은 XCP 패킷 내의 바이트 수를 나타낸다. CTR은
패킷 손실을 탐지하는 데 사용된다. UDP/IP는 보호된 프로토콜이 아니다. 패킷이 하나
손실된 경우에도 프로토콜 레이어에서는 인식하지 못한다. 패킷 손실은 카운터 정보를
이용해 감시한다. 마스터가 슬레이브로 최초 메시지를 보낼 때, 마스터는 프레임 한 개를 추가로
전송할 때마다 카운터 수를 늘린다. 슬레이브도 같은 패턴으로 응답한다. 슬레이브가
보내는 각각의 프레임에 대해 자체 카운터 수를 늘린다. 슬레이브와 마스터에 있는 카운터는
각각 독립적으로 작동한다. UDP/IP는 측정값을 전송하는데 적합하다. 패킷이 하나 손실되는
경우, 그 패킷을 포함한 측정값이 손실되어 측정에 차이가 생기게 된다. 이러한 손실이 가끔
발생하는 경우에는 무시할 수 있다. 그러나 측정 데이터를 고속 제어용으로 사용하는
경우에는 TCP/IP를 사용할 것을 권고한다.
Ethernet 패킷 하나는 여러 개의 XCP 패킷을 전송할 수 있지만, 하나의 XCP 패킷은

UDP/IP 패킷의 한계를 넘지 못한다. XCP on Ethernet의 경우에는 "테일(Tail)", 즉 빈
제어필드가 없다.
이 프로토콜에 대한 보다 상세한 정보는 ASAM XCP on Ethernet 파트 3 전송 레이어

규격에서 찾을 수 있다. CANape에서는 시뮬링크 모델과 시뮬링크 코더로 구현된 DLL
형태의 가상 ECU XCPsim이나 가상 ECU이 포함된 XCP on Ethernet의 데모를 이용할
수 있다.
1.4.5 SxI
SxI는 SPI나 SCI에 대한 집합명사이다. SPI나 SCI는 버스가 아니고 점대점(point-to-point)

접속에만 적합한 컨트롤러 인터페이스이기 때문에 이러한 전송 방식에서는 주소를 지정하지
않는다. 노드 2개 사이의 통신은 동기적으로나 비동기적으로 이루어질 수 있다.
XCP on Sxl Message (Frame)

LEN CTR PID FILL DAQ TIMESTAMP DATA FILL CS
Control Field Length (LEN) Control Field

for SxI for SxI
Checksum (CS)
그림 45: XCP-on-SxI 패킷
XCP 헤더는 길이(LEN)와 카운터(CTR)의 두 가지 정보를 제공하는 제어 필드로 구성된다.

이 파라미터의 길이는 바이트나 단어로 표시된다(인텔 포맷). LEN은 XCP 패킷의 바이트
수를 나타낸다. CTR은 패킷 손실을 탐지하는 데 사용된다. 이 방식은 XCP on Ethernet과
마찬가지로 카운터 정보를 가지고 감시한다. 특정한 상황에서는 패킷에 필 바이트(fill byte)를
추가해야 할 수도 있다. 예를 들자면, SPI를 WORD나 DWORD 모드로 사용하거나 최소
패킷 길이보다 짧은 메시지를 피해야 하는 경우이다. 이러한 필 바이트는 제어 필드에
추가된다.
이 프로토콜에 대한 보다 상세한 정보는 ASAM XCP-on-SxI 파트 3 전송 레이어 규격에서

찾을 수 있다.
1.4.6 USB
현재, XCP on USB는 실용적인 중요성을 지니지 못하고 있다. 그러므로, 이에 대해서는 별
도의 언급을 더는 하지 않을 것이다. 이에 대해서는 ASAM XCP onUSB 파트 3 전송 레이어
규격을 참고하도록 하라.
1.4.7 LIN
현재 ASAM은 XCP-on-LIN 표준을 더 이상 정의하고 있지 않다. 그러나 벡터 사에서

출시한 솔루션이 하나 있으며(XCP-on-LIN 드라이버와 XCP-on-LIN 마스터로 사용하는
CANape), 이 솔루션은 LIN이나 XCP 규격에 위배되지 않고 이미 일부 고객들의 프로젝트
에서 사용 중이다. 더 상세한 정보를 원한다면 벡터에 연락할 것.
1.5 XCP 서비스

이 장에는 XCP를 통해 실현할 수 있는 서비스의 리스트와 그에 대한 설명이 들어 있다. 이
것들은 모두 CTO와 DTO를 이용한 통신 메커니즘에서 이미 설명했다. 일부 XCP 서비스에
대해서도 이미 설명했는데, 예를 들자면 동기화 데이터의 획득/신호 인가와 기기의
메모리에 읽기/쓰기 액세스하는 방법 등이다.
XCP 규격은 사실 서비스마다 고유하게 지정된다. 동시에 이런 서비스를 항상 구현할 필요가

있는지, 또는 선택사항인지도 표시되어 있다. 예를 들어, 어떤 XCP 슬레이브는 마스터가
접속에 대해 설정을 하도록 "접속"을 지원해야만 한다. 반면에, XCP를 통한 플래싱은
반드시 필요한 것은 아니며, XCP 슬레이브가 이를 반드시 지원할 필요는 없다. 이는 단순히
프로젝트와 소프트웨어의 요구사항에 달린 문제이다. 이 장에서 설명한 모든 서비스는
선택사항이다.
1.5.1 메모리 페이지 스와핑
캘리브레이션 개념에서 이미 설명했듯이, 파라미터는 보통 플래시 메모리 내에 위치하며,

필요할 때 RAM으로 복사된다. 어떤 캘리브레이션 개념에서는 RAM과 플래시 메모리에
스와핑 메모리 세그먼트 페이지에 대한 선택항목을 제공하기도 한다. XCP는 약간 일반적인
접근방식을 기술하고 있는데, 여기서 메모리 세그먼트 하나에는 여러 개의 스와핑이 가능한
페이지가 들어갈 수 있다. 보통 여기에 구성되는 것은 RAM 페이지 하나와 플래시 페이지
하나이다. 그러나 여러 개의 RAM 페이지가 존재하는 경우나 플래시 페이지가 없는 경우도
생각해 볼 수 있다.
페이지 스와핑에 대한 XCP 명령어를 좀 더 이해하기 위해, 여기서 섹터와 세그먼트, 페이지의
개념을 다시 한 번 설명하겠다.
XCP access
Segmemt 1
Segment 1 Segment 1 Segment 1

Page 0 Page 1 Page 2
Sector 2
ECU access
Segmemt 0
Segment 0
Page 0
Sector 1
Sector 0
address
그림 46:
메모리 예
XCP의 관점에서 슬레이브의 메모리는 40비트의 폭을 가진 연속 메모리로 구성된다. 이

메모리의 물리적 레이아웃은 섹터를 바탕으로 한다. 플래시 섹터에 대한 지식은 플래싱을
할 때 꼭 필요한데, 그 이유는 플래시 메모리에서는 한 번에 한 블록씩만 소거할 수 있기
때문이다.
이 논리적 구조는 세그먼트라는 것에 바탕을 두고 있는데, 이는 캘리브레이션 데이터가

메모리의 어느 부분에 저장되는지 기술한다. 한 세그먼트의 시작 주소와 파라미터는
물리적 섹터의 시작 주소와 파라미터에 정렬할 필요가 없다. 각 세그먼트는 여러 개의
페이지로 다시 나눌 수 있다. 한 세그먼트의 페이지들은 동일한 주소에서는 같은 파라미터를
기술한다. 이 파라미터값과 읽기/쓰기 권한은 페이지마다 개별적으로 제어할 수 있다.
한 세그먼트 내의 특정 페이지에 할당하는 알고리즘은 항상 고유해야 한다. 어떤 특정한

시간에 한 세그먼트 내에서는 단지 하나의 페이지만 활성화될 수 있다. 이 페이지는 "이
세그먼트 내의 ECU에 대해 활성화된 페이지"라고 부른다. ECU와 XCP 드라이버가 활발
하게 액세스하는 특정 페이지는 개별적으로 개폐할 수 있다. 이러한 설정 사이에는 상호
의존성이 존재하지 않는다. ECU에서 사용하는 명명 규정과 비슷하게 XCP 액세스를 위해
활성화된 페이지는 "이 세그먼트 내의 XCP 액세스를 위해 활성화된 페이지"라고 부른다.
차례대로 이는 각각의 세그먼트에 적용된다. 세그먼트들은 A2L 파일에 실려야 하며, 각

세그먼트는 고유한 번호를 갖는다. XCP 슬레이브 내에서 SEGMENT_NUMBER는 항상 0에
서 시작하며, 그다음부터는 연속번호로 증가한다.
각 세그먼트는 적어도 하나의 페이지를 갖는다. 이 페이지는 또한 숫자로 언급할 수도 있다.
최초의 페이지는 0페이지이다. 이 숫자에 1바이트를 사용할 수 있으므로, 세그먼트 당
최대 255페이지까지 정의할 수 있다.
슬레이브는 모든 세그먼트에서 모든 페이지를 초기화해야 한다. 마스터는 GET_CAL_PAGE

명령을 사용해 슬레이브에게 어떤 페이지가 ECU용으로 활성화되었고 또 어떤 페이지가
XCP 액세스용인지 질의한다. 이런 경우에는 확실히 액세스에 대해 상호 블로킹이 필요할
수 있다. 예를 들어, 어떤 페이지가 현재 ECU에서 활성화되어 있는 경우, XCP 슬레이브
는 이 페이지에 액세스할 수 없을 수도 있다. 언급한 대로, 의존성이 있을 수는 있으나 꼭
그런 것은 아니다. 이는 슬레이브를 어떻게 구현하는가에 대한 문제이다.
만약 이 슬레이브가 선택사항인 GET_CAL_PAGE와 SET_CAL_PAGE를 지원한다면, 페이지

스와핑이라는 기능도 지원한다. 이 두 개의 명령어는 마스터로 하여금 현재 사용하는
페이지가 어떤 것인지 폴링하도록 하며, 필요시에는 ECU와 XCP 액세스를 위해 페이지를
스와핑할 수 있다. XCP 마스터는 페이지 스와핑을 완전히 제어할 수 있다. XCP 슬레이브
는 자체적으로는 스와핑 시작할 수 없다. 그러나 자연히 마스터는 슬레이브 구현에 따른
모든 제약사항을 준수해야 한다.
스와핑의 이점은 무엇인가?

먼저, 스와핑은 파라미터 세트 전체를 매우 신속하게 바꿀 수 있도록 한다. 진짜 전후 비교의
문제이다. 두 번째로 캘리브레이션 담당자가 ECU의 다른 페이지에서 파라미터 변경을
실시하는 동안 플랜트는 안정된 상태로 남아 있는다. 이는 예를 들어 파라미터 설정 중
불완전한 데이터 세트 때문에 플랜트가 중대한 또는 불안정한 상태로 넘어가는 것을
방지한다.
1.5.2 메모리 페이지 저장 - 데이터 페이지 프리징
캘리브레이션 담당자가 특정 페이지에 있는 파라미터를 캘리브레이션할 때 XCP는 데이터를

ECU에 직접 저장할 수 있는 능력이 있다. 여기에는 RAM 페이지의 데이터를 비휘발성
메모리에 있는 페이지에 저장하는 것도 포함된다. 이때 비휘발성 메모리가 플래시 메모리라면,
세그먼트 시작 주소와 세그먼트 크기가 반드시 플래시 섹터에 일치할 필요는 없다는 점을
고려해야 하며, 이는 플래시 메모리의 소거 및 다시 쓰기에 문제가 있다는 것을 나타낸다
(ASAM XCP 파트 2 프로토콜 레이어 규격 참조).
1.5.3 플래시 프로그래밍
플래싱이란 데이터를 플래시 메모리 영역에 쓰는 것을 말한다. 여기에는 메모리의 레이아웃에

대한 정확한 지식이 필요하다. 플래시 메모리는 여러 개의 섹터(물리적 구분)로 나뉘며, 이러한
섹터는 시작 주소와 길이로 기술한다. 이러한 섹터들을 서로 구분하기 위해 이들은 각각
일련의 식별번호를 가진다. 이렇게 번호를 할당하는데 1바이트를 쓸 수 있기 때문에 최대
255개의 섹터를 지원할 수 있다.
SECTOR_NUMBER [0, 1, 2 ... 255]
플래시 섹터에 관한 정보도 A2L 데이터 세트의 일부이다.
그림 47:
플래시 영역의
드라이버 설정 예
플래싱은 "플래시 커널"이라고 부르는 것을 이용해 구현한다. 플래시 커널은 플래싱을 실제로
실행하기 전에 슬레이브의 RAM 영역에 보내는 실행 코드이다. 이 커널은 XCP 마스터와의
통신도 처리한다. 여기에는 플래시 메모리를 소거하는 알고리즘도 포함될 수 있다. 보안과
공간 상의 이유로 이 코드는 ECU의 플래시 메모리에 영구적으로 저장되지 않는 경우가
많다. 어떤 경우에는 예를 들어 체크섬 계산이나 기타 비슷한 계산을 해야 할 필요가
있을 때, 컨버터를 사용하기도 한다.
XCP로 플래싱할 때 플래시 프로세스 전체를 대략 세 개의 영역으로 구분한다.

>준 비 (예: 버전 관리용, 그러므로 새로운 내용을 플래싱할 수 있는지 점검)
> 실행 (새로운 내용을 ECU로 전송)
> 후처리 (예: 체크섬 점검 등)
XCP 표준에서는 플래싱의 실행에 주로 초점을 맞추었다. 진단 프로토콜을 이용해 이

작업을 해 본 사람은 누구나 메타데이터를 이용한 일련번호 처리 등과 같은 프로세스별
요소들이 XCP에서는 좀 절제된 방식으로 지원하고 있다는 것을 알 수 있을 것이다. 확실히
이 정의를 만드는데 있어서는 라인 종단(end-of-line)할 때의 플래싱에 필요한 복잡한
프로세스 단계 대신 개발 단계에서의 플래싱이 주요 초점사항이었다.
그러므로, 준비 단계에서 중요한 것은 새로운 내용이 ECU에 적합한지를 결정하는 것이다.

버전관리를 위한 특별한 명령어는 없다. 이 작업은 프로젝트에 특정한 명령어를 지원하기
위한 것이다.
다음과 같은 XCP 명령어를 사용할 수 있다.
PROGRAM_START: 플래시 절차 시작
이 명령어는 플래시 프로세스의 시작을 나타낸다. ECU가 플래싱을 허용할 수 없는 상
태에 있다면(예: 차량 속도 > 0), XCP 슬레이브는 오류를 표시해야 한다. 실제 플래시
프로세스는 슬레이브가 PROGRAM_START의 성공 여부를 확인할 때까지 시작하지 않는다.
PROGRAM_CLEAR: 현재 플래시 메모리 소거 루틴 호출

플래시 메모리에 새로운 내용을 오버라이트하기 전에 먼저 메모리를 소거해야 한다. 이
명령어를 이용한 소거 루틴의 호출은 ECU에서 구현하거나 플래시 커널의 도움으로
ECU에서 사용할 수 있어야 한다.
PROGRAM_FORMAT: 플래시 데이터용 데이터 포맷 선택

XCP 마스터는 슬레이브에 전송할 데이터의 포맷을 정의할 때(예: 압축이나 암호화 등),
이 명령어를 사용한다.
PROGRAM: XCP 슬레이브로 데이터 전송

진단 루틴을 이용해 플래싱하는데 익숙한 사용자에게 있어 이 명령어는 진단 루틴의
TRANSFERDATA에 상응한다. 이 명령어를 사용하여 데이터를 XCP 슬레이브로 전송하면,
슬레이브는 이 데이터를 플래시 메모리에 저장한다.
PROGRAM_VERIFY: 새로운 플래시 내용 점검 요청

마스터는 슬레이브에게 새로운 내용이 OK인지 확인하기 위해 내부 점검을 실시하도록
요청할 수 있다.
PROGRAM_RESET: 슬레이브에 리셋(Reset) 요청

마스터가 슬레이브로 보낸 리셋 실행 요청. 이후, 슬레이브 접속은 항상 종료되며 새로운
접속 명령을 보내야 한다.
1.5.4 슬레이브 자동 탐지
XCP 프로토콜은 마스터가 프로토콜의 특정 특성에 대해 슬레이브에게 폴링을 할 수 있도록

해 준다. 이를 위해 많은 명령어를 사용할 수 있다.
GET_COMM_MODE_INFO
이 명령어에 대한 응답에서는 마스터에게 슬레이브의 다양한 통신 옵션에 대한 정보를
제공한다. 예를 들어, 슬레이브가 블록 전송이나 인터리브 모드를 지원하는지, 또는 마스터가
이러한 모드에서 요청을 할 때 최소 시간 간격이 어떻게 되는지 등의 정보를 제공한다.
GET_STATUS
이 요청에 대한 응답에서는 슬레이브의 현황 정보를 모두 제공한다. 어떤 자원을 지원하는가
(캘리브레이션, 플래싱, 측정 등)? 현재 진행 중인 메모리 활동은 무슨 유형인가(DAQ
리스트 구성 등)? DTO(DAQ, STIM)를 바로 교환할 수 있는가?
GET_DAQ_PROCESSOR_INFO
마스터는 슬레이브의 한계를 알 수 있는 사전정의된 DAQ 리스트의 수, 가용한 DAQ 리스트
및 이벤트 등 일반적인 정보를 얻게 된다.
GET_DAQ_RESOLUTION_INFO
이 명령어로 DAQ와 STIM에 대한 ODT의 최대 파라미터 수, ODT 입력 단위, 타임스탬프
전송시의 바이트 수 등, 슬레이브의 DAQ 능력에 대한 기타 정보를 교환한다.
GET_DAQ_EVENT_INFO
이 명령어를 사용할 때 ECU 이벤트당 1번씩 호출이 이루어진다. 여기서 전송되는 정보는
DAQ나 STIM, DAQ/STIM에 대해 이벤트를 사용할 수 있는지, 이벤트가 주기적으로 발생하
는지, 그렇다면 사이클 주기는 얼마인지 등에 관한 것이다.
1.5.5 업로드/다운로드/플래싱을 위한 블록 전송 모드
"정상" 통신 모드에서는 마스터에서 보낸 각 명령어에 대해 슬레이브가 응답을 보내 확인

한다. 그러나 어떤 경우에는 성능 때문에 블록 전송 모드를 사용하는 것이 더 바람직할
수도 있다.
Master Slave
Request k
Part1
Part2
MIN_ST
Part3
MAX_BS
Response k
Request k+1
그림 48:
Time
블록 전송 모드 예
이런 방법을 사용하면 대량의 데이터를 전송할 때 전송절차를 가속화시킬 수 있다 (UPLOAD,

SHORT_UPLOAD, DOWNLOAD, SHORT_DOWNLOAD, PROGRAM 등). 마스터는 슬레이브가
이 방식을 지원하는지 GET_COMM_MODE_INFO 요청을 보내 확인할 수 있다. 이에 대한
보다 자세한 내용은 ASAM XCP 파트 2 프로토콜 레이어 규격에서 찾을 수 있다.
1.5.6 콜드 스타트 측정 (파워 온 도중 측정 시작)
지금까지 설명한 XCP의 능력을 갖추고도 ECU의 시작 단계 초기에 실행할 수 있는 이벤트

수동식 측정을 이행하기는 불가능하다. 그 이유는 실제 측정을 하기 전에 이러한 측정에
대해 구성을 해야 하기 때문이다. 만약 이러한 구성을 하려 시도한다면 최초 측정값이
전송되는 시점에는 이미 ECU의 시작 단계가 종료된 후일 것이다. 이 문제를 극복하기 위해
사용하는 방법은 간단한 아이디어에 바탕을 두고 있다.
이 방법은 구성과 적시 측정을 분리하는 것이다. 구성 단계가 완료된 후에도 측정을 바로

시작하지는 못하는데, 그 이유는 ECU를 종료해야 하기 때문이다. 리부팅을 한 후 XCP
슬레이브는 기존의 구성에 직접 액세스하는 즉시 최초의 메시지를 발송하기 시작한다. 이와
관련하여 무엇이 곤란한지는 명백하다. 즉, DAQ 리스트의 구성 데이터는 RAM에 저장되기
때문에 리부팅을 한 후에는 더는 해당 정보가 존재하지 않는 것이다.
콜드 스타트 측정을 활성화하기 위해 RESUME 모드라고 알려진 것을 활성화하려면, XCP

슬레이브에 전원 공급이 되지 않더라도 데이터를 보존할 수 있는 비휘발성 메모리가 필요
하다. 여기에 EEPROM이 사용된다. 이런 상황에서는 실제 EEPROM이든 플래시 메모리를
이용해 에뮬레이션한 것이든 따지는 것은 적당하지 않다.
더욱 구체적인 내용은 제1.4.2.2장 "고급 기능"의 ASAM XCP 파트 1 규격 개요에서 찾을

수 있다.
1.5.7 XCP의 보안 메커니즘
가능한 한 비인가 사용자가 ECU에 접속할 수 있도록 하는 것을 방지해야 한다. 어떤 접속

시도가 인가를 받았는지를 확인하는데 "Seed & key"라는 방법을 사용할 수 있다. Seed
& key를 사용하면, 측정/신호 인가 및 캘리브레이션, 플래싱 등 세 가지 액세스 유형에서
보호를 받을 수 있다.
"Seed & key" 방법은 다음과 같이 작동한다. 마스터로부터 접속 요청을 받은 슬레이브는

난수(= Seed)를 마스터로 보낸다. 이제 마스터는 응답(= Key)을 생성하기 위해 반드시
특정 알고리즘을 사용해야 한다. 이 키를 슬레이브로 보낸다. 슬레이브도 예상 응답을
계산하고, 그 결과를 마스터가 보낸 키와 비교한다. 만약 두 결과가 합치하면 마스터와
슬레이브는 같은 알고리즘을 사용하고 있다. 그러면 슬레이브는 마스터의 접속을 승인한다.
두 결과가 합치하지 않는 경우 슬레이브는 마스터와의 통신을 거절한다.
보통, 이 알고리즘은 마스터에서 DLL로 이용할 수 있다. 그러므로 만약 어떤 사용자가

"Seed & key" DLL과 A2L 파일을 가지고 있다면 이 사용자가 ECU의 메모리에 액세스하
는 것을 막을 방도가 없다. ECU가 양산단계에 도달하면, 보통 XCP 드라이버를 비활성화
시킨다. ECU에 XCP 액세스를 복구시키는 데는 각 진단 명령어의 특별한 시퀀스가 사용된
다. 이를 이용하면 양산 차량에서도 XCP 드라이버를 사용할 수 있지만, 보통은 비인가자가
ECU를 조작하지 못하도록 비활성화시켜 놓는다 (ASAM XCP 파트 2 프로토콜 레이어
규격 참조).
한 프로젝트에서 Seed & key 또는 XCP 드라이버의 비활성화를 사용할지의 여부는 프로

젝트별로 다르며, XCP 규격과는 독립적이다.
64
2 ECU 기술 파일 - A2L
66 2 ECU 기술 파일 - A2L
A2L 파일이 왜 필요한지는 이미 설명했다. 즉, 주소에 기호명칭을 부여하기 위한 것이다.

예를 들어, 어떤 소프트웨어 개발자가 PID 컨트롤러를 구축하면서 어플리케이션의 비례적,
통합적, 차등적 컴포넌트에 각각 P1, I1, D1이라는 명칭을 부여했다면, 캘리브레이션 담당자는
해당 기호명칭을 사용하여 이 파라미터들에 액세스할 수 있어야 한다. 다음 그림을 예로
들기로 하자.
그림 49:
캘리브레이션 창
내의 파라미터
사용자는 기호명칭을 이용하여 편리하게 값을 변경할 수 있다. 또 다른 예는 ECU에서

측정한 신호 변수를 보는 것이다.
그림 50: 시간에 따른 신호 응답
범례에서 사용자는 신호의 논리적 명칭을 읽을 수 있다. 오프라인에서 해당 값을 분석할 때

ECU 내에서 해당 파라미터가 위치한 주소는 이차적인 중요성만 가진다. 자연히 ECU 내에서
특정 값을 요청하기 위해서는 정확한 주소가 필요하지만, 주소 자체의 수치는 사용자에게
아무 의미가 없다. 사용자는 선택하고 가시화를 할 목적으로 논리적 명칭을 사용한다.
즉, 사용자는 객체명을 이용해 해당 객체를 선택하고, XCP 마스터는 A2L 파일에서 연관
된 주소와 데이터 유형을 찾는다.
파라미터의 또 다른 속성은 최소값이나 최대값을 정하는 일일 것이다. 해당 객체의 값은 이

범위 내에 놓이게 된다. 여러분이 소프트웨어 개발자로 전기 출력에 직접적인 영향을 미치는
파라미터를 정의하고 있다고 하자. 이제 여러분은 사용자가 이유가 무엇이든 전기 출력
부분에 치명적 피해를 줄 수 있게끔 설정을 변경하는 일을 막아야 한다고 하자. 여러분은
이 일을 A2L 파일에서 최소값과 최대값을 정의해 허용값을 제한함으로써 완수할 수 있다.
A2L에는 물리 값과 원천값(raw value)을 전환하는 규칙도 정의된다. 8비트 값을 갖는

센서에 이런 전환규칙을 실린 간단한 예를 생각해 볼 수도 있다. 센서에서 출력하는 수치
값은 0에서 255 사이에 놓이게 되지만, 이 값을 퍼센트로 전환할 수도 있다. 센서 출력
값[0 ... 255]을 퍼센트 값[0 ... 100 %]으로 매핑하는 일은 전환 규칙에 따라 수행할 수
있으며, 이렇게 전환된 값은 A2L에 저장된다. 객체 하나를 측정하는 경우, 그 측정값
은 ECU 내에 원천값으로 존재하며, 그 형태로 전송된다. 측정/캘리브레이션 툴은 저장된
공식을 사용해서 물리 값으로 가시화한다.
스칼라 파라미터 이외에도 특성 곡선과 맵은 자주 사용된다. 홀센서(Hall sensor)와 같은

근접센서를 사용할 수도 있는데, 이 센서는 거리를 자계강도의 함수로 결정하기 때문에 이
거리 값을 알고리즘에 사용할 수도 있다. 자계와 거리 값은 상호 간에 선형으로 작용하지
않는다. 이러한 값의 비선형성은 알고리즘을 불필요하게 복잡하게 만들게 된다. 특성 곡선을
이용하면 해당 입력변수로 값을 알고리즘에 입력하기 전에 먼저 선형화시킬 수 있다.
특성맵의 또 다른 어플리케이션 영역은 복잡한 계산을 대체하는 데 사용하는 것이다. 예를

들어, y = f(x)라는 함수가 있고 이 함수 f가 계산을 위한 많은 노력과 연관되어 있다면 먼저
x의 잠재적 범위 내에서 간단하게 값을 계산하고 그 결과를 표의 형태로(= 특성 곡선)
저장하는 것이 훨씬 단순할 수 있다. 값 x가 지금 ECU 내에 있다면, 값 y는 컨트롤러의
런타임에서 계산할 필요가 없으며, 차라리 맵을 이용해 입력변수 x에 대한 결과값 y를
제공하는 것이 낫다. 두 개의 값 사이를 보간할 필요가 있을 수도 있으마 이는 계산의
범위에 포함되는 것이다.
이러한 특성 곡선은 메모리에 어떻게 저장되는가? 모든 x 값을 먼저 입력한 다음 모든 y

값을 입력해야 하는가? 아니면 저장 시 x1, y1; x2, y2; x3, y3 ...?와 같은 패턴을 따라야
하는가? 다양한 선택이 가능하므로 메모리 저장 유형은 A2L 파일 내의 저장 방식에
정의된다.
파라미터를 기호명칭으로 사용할 수 있도록 하고, 물리 값을 직접 볼 수 있도록 하며, 복

잡한 저장방식에 구애되지 않고 특성 맵과 같은 복잡한 요소에 접근할 수 있게 하는 등의
사용자 편의를 위한 기능이 제공되고 있다.
또 다른 장점은 통신 파라미터의 사용에 있다. 통신 파라미터도 A2L 파일에 저장된다.

측정/캘리브레이션 툴과 ECU 간에 통신을 할 때, A2L 파일에 저장된 파라미터 세트를
사용한다. A2L 파일에는 측정/캘리브레이션 툴이 ECU와 통신하는 데 필요한 모든 것이
들어 있다.
2.1 XCP 슬레이브를 위한 A2L 파일 설정하기

A2L 파일은 ASCII파일로 키워드를 이용해 다음 사항을 기술한다.
> 측정/캘리브레이션 툴과 A2L 파일간의 인터페이스별 파라미터 (이 내용은 A2L 파일
앞쪽에 있으며, AML 트리라고 하는 곳에 위치한다)
> ECU와의 통신
> 특성 곡선/맵 저장방식 (키워드 RECORD_LAYOUT)
> 원천값을 물리 값으로 전환하는 전환규칙 (키워드 COMPU_METHOD)
> 측정 파라미터 (키워드 MEASUREMENT)
> 캘리브레이션 파라미터 (키워드 CHARACTERISTIC)
> 측정을 촉발할 수 있는 이벤트 (키워드 EVENT)
파라미터와 측정 파라미터의 요약본은 그룹을 이용해 작성한다(키워드 GROUP).
"Shifter_B3"라는 명칭의 측정 파라미터를 예로 들면 다음과 같다.
/begin MEASUREMENT Shifter_B3 "Single bit signal (bit from a byte shifting)"
UBYTE HighLow 0 0 0 1
READ_WRITE
BIT_MASK 0x8
BYTE_ORDER MSB_LAST
ECU_ADDRESS 0x124C02
ECU_ADDRESS_EXTENSION 0x0
FORMAT "%.3"
/begin IF_DATA CANAPE_EXT
100
LINK_MAP "byteShift" 0x124C02 0x0 0 0x0 1 0x87 0x0
DISPLAY 0 0 20
/end IF_DATA
/end MEASUREMENT
KF1이라는 명칭의 파라미터 맵을 예로 들면 다음과 같다
/begin CHARACTERISTIC KF1 "8*8 byte no axis"

MAP 0xE0338 __UBYTE_Z 0 Factor100 0 2.55
ECU_ADDRESS_EXTENSION 0x0
EXTENDED_LIMITS 0 2.55
BYTE_ORDER MSB_LAST
BIT_MASK 0xFF
/begin AXIS_DESCR
FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7
EXTENDED_LIMITS 0 7
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT "%.0"
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
2.2 수동으로 A2L 파일 생성하기 69
/begin AXIS_DESCR
FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7
EXTENDED_LIMITS 0 7
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT "%.0"
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
/begin IF_DATA CANAPE_EXT
100
LINK_MAP "map3_8_8_uc" 0xE0338 0x0 0 0x0 1 0x87 0x0
DISPLAY 0 0 255
/end IF_DATA
FORMAT "%.3"
/end CHARACTERISTIC
ASCII 텍스트는 이해하기 쉽지 않다. ASCII 텍스트의 구조에 대한 설명은 제2장의 ASAM
XCP 파트 2 프로토콜 레이어 규격에서 찾을 수 있다.
다음에는 A2L 파일을 어떻게 생성하는지 설명하도록 하겠다. A2L의 실제 내용과 의미에
초점을 맞추도록 하며, A2L 기술언어의 세부 내용은 에디터에 맡기도록 하겠다. A2L 에디터는
여기서 사용하는 CANape와 함께 제공된다.
2.2 수동으로 A2L 파일 생성하기

A2L는 주로 XCP 슬레이브 메모리에 있는 내용을 기술하는 데 사용된다. 이 내용은 슬레이
브에 들어있는 어플리케이션에 따라 달라지며, 이런 어플리케이션들은 C 코드로 개발된다.
컴파일러/링커로 어플리케이션 코드를 처리한 후, A2L 파일의 중요한 요소인 객체명,
데이터 유형, 메모리 주소 등은 링커-맵 파일에 들어 있으나 XCP 마스터와 슬레이브
사이의 통신을 위한 파라미터는 빠져 있다. 이 밖에도 파라미터의 최소값과 최대값, 전환
규칙, 특성 맵 저장방식 등의 기타 정보도 필요하다.
먼저 빈 A2L 파일과 통신 파라미터를 생성해 보기로 하자. 예를 들어, XCP on CAN

인터페이스로 ECU를 기술하는 A2L 파일을 만든다면, CANape에서 새 기기를 생성한 다음
인터페이스로 XCP on CAN를 선택한다. 그 다음에는 기타 통신방식 별 정보를 보완할 수
있다(예를 들어, CAN 식별자). 파일을 저장한 후에는 A2L의 통신 내용 전체를 담고 있는
A2L 파일을 갖게 된다. 아직 부족한 것은 실제 측정/캘리브레이션 파라미터의 정의이다.
(CANape의 일부이며, 별도의 툴로 구매 가능한) A2L 에디터에서는 링커-맵 파일이 A2L과

결부되어 있다. 사용자는 선택 대화상자에서 맵 파일을 이용해 스칼라 측정/캘리브레이션
파라미터, 특성 곡선/맵 등 A2L에 필요한 파라미터를 선택할 수 있다. 사용자는 원하는
파라미터를 A2L에 단계적으로 추가하거나 그룹화할 수 있다. 기타 객체 별 정보도 에디터를
사용해 추가할 수 있다.
여러분의 코드를 수정하거나 다시 컴파일하거나 링크할 때 무엇을 해야 하는가? 객체 주소가

바뀔 가능성은 매우 높다. 근본적으로 A2L 파일을 새로 만들 필요는 없다. 코드에 방금
추가한 객체를 A2L 파일에서도 사용하고 싶다면 물론 이 객체를 A2L 파일에 추가해야
한다. A2L 파일에서는 항상 주소를 업데이트할 필요가 있다. 이런 업데이트도 에디터로 할
수 있다. 에디터는 A2L의 객체명에 따라 링커-맵 파일에서 적절한 입력값을 찾아 주소를
읽은 다음 그 내용을A2L에 업데이트한다.
여러분의 어플리케이션이 객체명이 바뀌고, 데이터 유형을 새로 채택하고 파라미터를 지우거나

추가하는 등 매우 동적으로 변경된다면, 수작업은 실용적이 아닐 수도 있다. A2L을 C 코드로
생성하기 위해서는 자동 처리를 위해 다른 툴들을 사용할 수도 있다.
벡터 사의 홈페이지에서 "ASAP2 Tool-Set"에 대한 정보를 얻을 수 있는데, 이 툴 세트를

가지고 소스코드에서 A2L을 배치 프로세스로 생성할 수 있다.
2.3 A2L 컨텐츠 vs ECU 구현

XCP 마스터 툴이 ECU에 완전히 일치하지 않는 A2L 파일을 읽는 경우, 통신방식에 대한
오해가 발생A2L 컨텐츠할 수 있다. 예를 들어, A2L 파일에 있는 타임스탬프 해상도 관련
값이 ECU에 구현된 값과 차이가 날 수 있다. 이런 경우, 문제를 탐지해서 해결해야 한다.
사용자는 마스터에게서 지원을 받을 수 있는데, 마스터는 슬레이브에서 실제로 구현된 것
으로 확인된 프로토콜을 이용해 슬레이브에 폴링을 할 수 있다.
XCP는 슬레이브의 자동 탐지를 위한 여러 가지 기능을 제공한다. 물론 이는 슬레이브에 자동

탐지가 구현되어 있다는 가정을 한 경우에 해당된다. 마스터가 슬레이브에 폴링을 했을
때, 슬레이브의 응답이 A2L 기술 파일에 들어 있는 파라미터 세트와 합치하지 않는다면,
마스터는 어떤 설정 값을 사용해야 하는지 결정해야 한다. CANape에서는 A2L에서 얻은
정보보다 슬레이브에서 읽은 정보에 더 높은 우선순위를 부여한다.
2.3 A2L 컨텐츠 vs ECU 구현 71
다음은 슬레이브의 XCP 구현 여부를 확인할 때 사용할 수 있는 명령어들의 예를 몇 개

들어 보았다.
GET_DAQ_PROCESSOR_INFO
DAQ 리스트에 대한 일반 정보 확인: MAX_DAQ, MAX_EVENT_CHANNEL, MIN_DAQ
GET_DAQ_RESOLUTION_INFO
DAQ/STIM, 시간 간격 정보 등 ODT 입력값의 최대 파라미터
GET_DAQ_EVENT_INFO (EVENT_CHANNEL_NUMBER)
특정 시간 간격에 대한 정보 제공: 시간 간격의 명칭 및 해상도, 이 시간 간격에 배정될
수 있는 DAQ 리스트의 수 ....
GET_DAQ_LIST_INFO (DAQ_LIST_NUMBER)
선택한 DAQ 리스트에 대한 정보 제공: MAX_ODT, MAX_ODT_ENTRIES는 사전 정의된
DAQ 리스트로 존재 ...
72
3 캘리브레이션 개념 73
3 캘리브레이션 개념
74 3 캘리브레이션 개념
ECU 파라미터는 ECU나 ECU 베리언트(variant)의 개발 중에 채택하고 최적화하는 일정한

파라미터이다. 이는 반복적인 프로세스로 특정 파라미터의 최적 값은 반복적인 측정과
변경을 통해 구할 수 있다.
캘리브레이션 개념은 ECU의 개발 및 캘리브레이션 단계에서 ECU에 들어 있는 파라미터를

어떻게 수정할 수 있는지에 대한 답변이다. 현존하는 캘리브레이션 개념은 하나가 아니라
여러 개이다. 어떤 개념을 사용할 것인지는 사용하는 마이크로컨트롤러의 능력과 자원에
달려 있다.
보통, 파라미터는 양산된 ECU의 플래시 메모리에 저장된다. 하부의 프로그램 변수들은
소프트웨어의 상수로 정의된다. ECU 개발 중 런타임에서 파라미터를 수정할 수 있도록
하려면 RAM 메모리가 추가로 필요하다.
캘리브레이션 개념은 다음과 같은 질문과 관련이 있다. 파라미터가 초기에 플래시 메모리
에서 RAM으로 찾아갈 수 있을까? 마이크로컨트롤러가 RAM에 액세스하는 경로를 다시
설정할 수 있을까? RAM에 동시에 저장할 수 있는 양보다 많은 파라미터가 있을 경우에는
어떻게 해결해야 하는가? 파라미터를 플래시 메모리에 다시 복사하려면 어떻게 해야
하는가? 파라미터에 가한 변경은 지속적인가? 다시 말해 ECU를 끌 경우에는 보존되는가?
투명한 캘리브레이션 개념과 불투명한 캘리브레이션 개념에 대해 구분해 보자. 투명하다는
것은 특정 캘리브레이션 툴이 위의 질문들에 대해 관여할 필요가 없다는 것으로, 왜냐하면
모든 필요한 메커니즘이 ECU에 구현되어 있기 때문이다.
다음에 몇 가지 방법에 대해 간략하게 소개해 보겠다.
3.1 플래시 파라미터

소프트웨어 개발자는 특정 파라미터가 변수인지 상수인지, 다시 말해 이 파라미터를 플래시에
저장할 것인지, 아니면 RAM 메모리에 저장할 것인지를 정의한다.
C 코드 예제:
const float factor = 0.5;
"인수(factor)" 파라미터는 값이 0.5인 상수를 나타낸다. 코드를 컴파일하고 링크할 때

메모리 공간은 해당 "인수" 객체용 플래시 메모리에 제공된다. 이 객체에는 플래시 메모리의
데이터 영역에 위치한 주소를 할당한다. 0.5란 값은 헥스 파일의 해당 주소에서 찾을 수
있으며, 이 주소는 링커-맵 파일에 있다.
가장 간단하게 이해할 수 있는 캘리브레이션 개념은 C 코드에서 값을 수정하거나 새로운

헥스 파일을 생성해서 플래싱하는 것이다. 그러나 이 방법은 매우 노력이 많이 들어가는
데, 왜냐하면 모든 값의 변경을 코드에서 해야 하며 그에 따라 컴파일러/링커 작업을 한
후 플래싱을 해야 하기 때문이다. 다른 방법은 헥스 파일에서 값만 수정한 다음, 이 파일을
다시 플래싱하는 것이다. 모든 캘리브레이션 툴에서 이 방법을 사용할 수 있다. 이 방법은
헥스 파일의 "오프라인 캘리브레이션"이라고 부르는데, 보편적으로 사용되는 방법이다.
3.1 플래시 파라미터 75
특정 컴파일러를 사용하는 어떤 상황에서는 예를 들어 파라미터가 플래시 메모리에 저장되고

코드에 통합되지 않는지, 그래서 링커-맵 파일에 반영 되지 않는지를 확실하게 확인할
필요가 있다. 통상적으로 플래시 메모리 내에서 상수가 어느 곳에 생성되는지를 우연에
맡기는 사람은 없을 것이다. 이를 위해 사용하는 수단은 거의 항상 컴파일러별 프라그마
지시어(pragma instruction)이다. 컴파일러가 파라미터를 코드 내에 내장시키는 것을 방지
하려면 상수 파라미터를 위한 "휘발성(volatile)" 속성을 사용하는 것으로 충분하다. 다음
예에서는 플래시 상수에 대한 전형적인 정의를 보여주고 있다.
C 코드 예제:
#pragma section "FLASH_Parameter"

volatile const float factor = 0.5;
플래시 메모리 내에 있는 파라미터를 온라인으로 캘리브레이션하는 것은 보통 가능하지

않다. 사실 대부분 마이크로컨트롤러는 자체 플래시 메모리를 자체적으로 프로그래밍할
수 있는데, 이러한 작업은 필드에서 프로그래밍을 다시 하는 데 필요하다. 그러나 플래시
메모리는 항상 더 큰 블록(섹터)으로 조직되는 특성이 있고, 이러한 섹터는 전체적으로만
삭제할 수 있다. 각각의 파라미터를 개별적으로 플래싱하는 것은 실질적으로 불가능한데,
왜냐하면 ECU는 보통 나머지 섹터의 내용을 버퍼에 넣고 프로그램을 다시 할만한 자원을
가지고 있지 않기 때문이다. 또한, 이 프로세스는 시간이 너무 많이 걸릴 우려도 있다.
어떤 ECU는 EEPROM 메모리라는 곳에 데이터를 저장할 수 있는 능력이 있다. 플래시

메모리와는 반대로 EEPROM 메모리는 각각의 메모리 셀을 독립적으로 소거하거나 프로
그래밍할 수 있다. 사용할 수 있는 EEPROM 메모리의 양은 항상 사용할 수 있는 플래시
메모리보다 적으며, 보통 수 킬로바이트에 불과하다. EEPROM 메모리는 보통 정비소에서
프로그램 가능한 파라미터를 저장하거나 ECU에 주행 기록계와 같은 지속(persistence)
메커니즘을 구현하는 데 흔히 사용된다. 여기서 온라인 캘리브레이션도 생각해 볼 수는
있으나, 거의 사용되지 않고 있는데, 그 이유는 EEPROM 셀에 액세스하는 것이 비교적
느리고, 또 부팅 프로세스 중에 EEPROM 파라미터는 보통 RAM 메모리에 복사되기 때문에
여기서 직접 액세스 하는 것이 가능하기 때문이다. EEPROM 메모리가 없는 ECU는 보통
EEPROM 에뮬레이션(emulation)이라는 방법을 사용해 구현한다. 이 방법에서는 여러 개의
작은 플래시 메모리 섹터를 사용해 파라미터 변화를 기록하기 때문에 마지막 유효 값은 항상
확인할 수 있다. 이 방법을 사용하면 온라인 캘리브레이션도 고려해 볼 수 있다.
이 두 경우 모두 해당 메모리에 액세스 하는 것은 XCP 드라이버의 소프트웨어 컴포넌트가
가로채어 EEPROM의 소프트웨어 루틴이나 EEPROM 에뮬레이션을 구현한다. 벡터 사의
XCP 전문 드라이버는 이에 필요한 소프트웨어 훅(hook)을 제공하고 있다.
3.2 RAM 파라미터

런타임에서 파라미터를 변경하는데 ("온라인 캘리브레이션") 가장 흔히 사용되는 방법은 사용
가능한 RAM 메모리에 해당 파라미터를 생성하는 것이다.
C 코드 예제:
#pragma section "RAM_Parameter"

volatile float factor = 0.5;
여기서는 "인수" 파라미터를 초기값이 0.5인 RAM 변수로 정의했다. 코드를 컴파일하고
링크하는 도중에는 메모리 공간을 RAM에 "인수" 객체용으로 유보하고 관련 RAM 주소는
링커-맵 파일에 나타난다. 초기값 0.5는 플래시 메모리와 헥스 파일의 해당 위치에 저장
된다. 플래시 메모리에 든 초기값의 주소는 링커의 파라미터 생성과정에 의해 정의하지만,
이 값은 링커-맵 파일에 나타나지는 않는다.
ECU 부팅 도중 모든 RAM 변수는 일단 플래시 메모리에 있는 초기값으로 초기화된다. 이

작업은 보통 컴파일러 생산자의 시동 코드에서 실행되며, 어플리케이션 프로그래머는 이에
관해 관심을 둘 필요가 없다. 어플리케이션은 RAM에 있는 파라미터값을 사용하며, 이 값은
XCP 메모리에 정상적으로 액세스해서 수정할 수 있다.
ECU 소프트웨어의 관점에서 보면, 캘리브레이션용 RAM의 파라미터는 항상 수정할 수 없는

상태이다. 즉, 어플리케이션 자체적으로는 이를 변경할 수 없다. 많은 컴파일러가 코드
분석을 통해 이 사실을 발견하고 단순히 필요한 RAM 메모리 공간을 최적화시켜 버린다.
그러므로 컴파일러들이 "휘발성" 속성을 이용해 최적화시키는 것을 방지할 필요가 있다.
캘리브레이션 툴의 관점에서 보면, 파라미터가 위치한 RAM 영역은 캘리브레이션용 RAM

(캘리브레이션이 가능한 메모리)으로 불린다.
FLASH RAM
Calibration RAM
그림 51:
RAM의 초기
Parameters
파라미터 설정
캘리브레이션용 RAM은 완전히 인접한 RAM 영역으로 구성할 필요가 없다. 캘리브레이션용
RAM은 여러 개의 영역에 분산시키거나 원하는 방법으로 분산시킬 수도 있다. 그러나 이
방법은 불과 몇 개의 인접하는 RAM 영역에서 파라미터를 구성하고 상태 변수나 중간 결과
등과 같은 기타 RAM 파라미터로부터 해당 파라미터를 격리하는데 큰 장점이 있다. 이는 캘
리브레이션용 RAM을 오프라인에서 헥스 파일로 캘리브레이션하도록 한 경우에 특히 중요
하다. 사용자의 요청에 따라 오프라인 캘리브레이션에서 온라인 캘리브레이션으로 전환
하는 동안, 캘리브레이션 툴은 오프라인에서 수정한 파라미터를 탑재할 수 있어야 한다.
3.2 RAM 파라미터 77
이러한 경우는 매우 자주 발생한다. 예를 들어, 캘리브레이션 담당자가 다음 날 ECU에 재

접속한 경우 그 전날 중단했던 지점에서 작업을 다시 시작하고자 할 것이다. 그러나 ECU
를 부팅하게 되면 초기값으로 플래시 메모리에 있는 내용이 RAM에 복사된다. 사용자가 그
전날 하던 작업을 재개하게 하려면 그 전날 저녁에 저장한 파라미터 세트 파일을 ECU의
RAM에 탑재해야 한다. 이러한 탑재 프로세스에 걸리는 시간은 필요한 전송 파일의 수를
최소로 줄임으로써 최적화시킬 수 있다. 만약 해당 툴이 좀 더 넓은 인접 영역에 체크섬을
기록하는 식으로 신속하고 믿을만한 방법으로 차이점을 찾을 수 있다면 이 경우에 매우
유리할 것이다. ECU에 있는 캘리브레이션용 RAM의 내용이 이 툴을 사용해 수정한 파일과
차이가 없다면 이 영역에 대해서는 전송을 할 필요가 없다. 캘리브레이션 파라미터가 있는
메모리 영역이 명확하게 정의되지 않은 경우나 ECU 소프트웨어가 수정한 파라미터가
포함된 경우에는 체크섬 계산을 통해 차이점을 찾아내고 또 ECU에서 XCP 마스터로 파라미터
값을 전송해야 하는지, 아니면 그 반대방향으로 해야 하는지를 알아낼 수 있다. 전송 속도와
데이터양에 따라 이렇게 전송하는 데 몇 분이 걸릴 수도 있다.
메모리 세그먼트를 명확하게 정의할 경우의 다른 장점은 플래시 메모리에 있는 초기값

저장용 메모리 영역을 오프라인 캘리브레이션에 사용할 수 있다는 점이다. 플래시 메모리의
내용은 플래싱이 가능한 헥스 파일을 이용해서 정의한다. 만약 캘리브레이션 툴이 헥스 파일
내의 어느 위치에 파라미터가 있는지 안다면, 그 값을 수정할 수 있고, 또 수정한 헥스 파일을
플래싱해서 ECU에 새로운 초기값을 구현할 수 있다.
캘리브레이션 툴은 RAM에 있는 파라미터의 위치를 알 필요가 있을 뿐 아니라, 플래시
메모리에 있는 초기값도 알아야 한다. 여기서 전제조건은 RAM의 메모리 세그먼트를
동일한 구성을 가진 플래시의 메모리 세그먼트에서 복사함으로써 초기화시켜야 한다는
것이다. 이는 대부분 컴파일러나 링커에서 사용하는 관행이다. RAM에 있는 파라미터의
주소가 A2L 파일에 실려 있는 경우에는 툴에 캘리브레이션용 RAM의 시작 주소를 오프셋
시킬 값을 알려주면, 툴은 해당 플래시 영역의 시작 주소에 이 값을 더하게 된다. 그다음
에는 이 오프셋 값을 A2L 파일에 들어있는 각각의 파라미터에 적용한다.
그다음, 캘리브레이션 툴은 이 영역에 대해 플래싱할 수 있는 헥스 파일을 생성하거나 해당

값을 링커의 원래 헥스 파일에 직접 추가하여 해당 헥스 파일의 파라미터 초기값을 수정
한다.
3.3 플래시 오버레이(Flash Overlay)

많은 마이크로컨트롤러는 내부나 외부의 RAM을 이용해 플래시 메모리 영역을 오버레이
시키는 옵션을 제공하고 있다. 이 프로세스를 플래시 에뮬레이션 또는 플래시 오버레이라고
부른다. 이를 위해서는 메모리관리 장치(MMU)의 사용에서부터 전용 메커니즘을 사용하는데
이르기까지 다양한 옵션이 가능하다. 이 경우, 캘리브레이션 개념 1에서 언급한 것처럼 이
파라미터는 플래시의 파라미터로 생성된다. 이 방법은 앞에서 설명한 캘리브레이션 개념 2
"RAM의 파라미터"와 비교할 때 많은 장점을 제공한다.
> 플래시 주소와 RAM 주소 사이에 구분이 없다. 플래시 주소는 항상 A2L 파일, 헥스 파일과
링커-맵 파일에 위치한다. 이에 따라 상호 간의 관계가 명확해져 헥스 파일은 직접 플래싱할
수 있고, A2L 파일을 그와 똑같게 만들 수 있다.
> 오버레이는 전반적으로 활성화하거나 비활성화시킬 수 있으며, 이에 따라 플래시 메모리에
있는 값과 RAM에 들어있는 값을 순식간에 스와핑할 수 있다. 이들을 메모리 세그먼트의
RAM 페이지와 플래시 페이지라고 부른다. XCP는 특별 명령어를 이용해 메모리 페이지의
스와핑 제어를 지원한다.
> 메모리 페이지는 개별적으로 스와핑할 수 있다. 예를 들어, XCP와 ECU에 액세스하는
경우, 즉, ECU 소프트웨어가 한 페이지에 대해 작업하고 있는 동안 XCP는 다른 페이지에
액세스할 수 있다. 이를 이용해 ECU가 플래시 데이터를 처리하는 동안 오프라인의
캘리브레이션 데이터를 RAM에 다운로드하는 등의 작업을 할 수 있다. 이러한 기능은
ECU를 구동할 때 봉착할 수 있는 잠재적인 모순들을 피할 수 있도록 한다.
> RAM에 오버레이할 때에는 완전하게 할 필요가 없으며, 이는 어플리케이션에도 적용할
수 있다. 플래시 메모리보다 적은 RAM으로 작업하는 것도 가능하다. 이에 대한 상세한
내용은 나중에 다루도록 하겠다.
오프라인에서 캘리브레이션한 값을 나중에 다운로드해서 캘리브레이션 툴과 ECU를 연결하는

전형적인 절차는 다음과 같다.
ECU에 접속 CONNECT
XCP 마스터를 RAM 페이지에 접속 SET_CAL_PAGE XCP to RAM
체크섬 계산 CALC_CHECKSUM
RAM 영역에 대한 체크섬 계산에서 차이가 발견되는 경우, 먼저 사용자에게 보통 어떻게

처리할 것인가를 묻게 된다. ECU RAM의 내용을 마스터로 보내야 하는가 아니면 마스터
페이지에 있는 파일의 내용을 ECU의 RAM으로 보내야 하는가? 만약 사용자가 오프라인에
서 ECU에 가한 변경내용을 쓰기로 한 경우, 그다음 절차는 다음과 같다.
ECU는 플래시 페이지의 데이터세트를 사용해야 한다. SET_CAL_PAGE ECU to FLASH

마스터에서 RAM 페이지로 파일 복사 DOWNLOAD ...
ECU는 RAM 페이지의 데이터세트를 사용해야 한다. SET_CAL_PAGE ECU to RAM
나중에 이 메모리 페이지는 언제나 RAM으로 전환할 수 있기 때문에 파라미터를 수정할

수 있다. 그러나 사용자는 또한 ECU에서 어떤 메모리 페이지를 활성화할 것인지 명확하게
지시해야 한다. 예를 들어, RAM 파라미터 세트의 거동을 플래시 파라미터 세트의 거동과
비교할 수 있으며, 또는 긴급 시에는 플래시 메모리에 들어 있는 확인된 파라미터 세트로
신속히 복구시킬 수도 있다.
3.4 플래시 오버레이의 동적 할당 79
3.4 플래시 오버레이의 동적 할당

지금까지 설명한 캘리브레이션용 RAM의 개념에서는 모든 파라미터에 대해 RAM이 충분하기만
하다면 아무런 문제가 없다. 그러나 파라미터 전체가 사용 가능한 RAM 영역에 들어가지
않는 경우에는 어떻게 하는가?
여기서는 RAM으로 플래시 메모리를 동적으로 오버레이하고, 특정 파라미터에 대해 실제로

쓰기 위해 액세스할 때까지 관련 플래시 메모리를 RAM으로 오버레이하는 것이 바람직하다.
이 절차는 구현 방식에 따라 특정 단위로 진행할 수 있으며, XCP의 관점에서 보면 캘리
브레이션 툴에 대해 투명하다고 할 수 있다. XCP 드라이버가 ECU의 플래시 메모리에
변경을 가할 수 있는 쓰기 액세스를 탐지한 경우, 캘리브레이션용 RAM의 일부를 이용해
플래시 메모리의 해당 부분을 복사하고 이 부분에 대해 오버레이 메커니즘을 활성화한다.
여기에는 고정 레이아웃에서의 RAM 할당도 포함되며, 이러한 RAM은 이용 중인 것으로
식별된다. 그러나 캘리브레이션용 RAM 자원은 유한하다. 캘리브레이션 프로세스 중에는
이미 할당된 RAM 영역을 해제할 수 없으며, 그래서 사용 가능한 캘리브레이션용 RAM은
요청이 있을 때마다 줄어들게 된다. RAM 자원이 소진되어 새로 할당할 필요가 생기면,
사용자에게 RAM 자원 소진에 대한 통보가 보내진다. 이때 사용자에게는 플래싱을 하거나
그 시점까지 만든 모든 변경내용을 저장할 것을 선택해야 한다. 이러한 조치로 할당된
RAM 영역을 되찾게 되면 사용자는 다시 캘리브레이션작업을 착수할 수 있다. ECU가
자동으로 이전에 변경된 파라미터를 플래싱하는 옵션은 배제했는데, 이 내용은 이미 캘리
브레이션 개념 중 "플래시의 파라미터"에서 언급했기 때문이다.
어떤 경우에는, RAM 자원이 부족해 오프라인에서 생성한 파라미터 세트를 다운로드하지

못할 수도 있다. 이때 유일한 대안은 플래싱을 하는 것이다. 사용자는 툴에서 변경내용을
언제든지 취소할 수 있으며, 이때 할당된 RAM 블록은 다시 해제된다.
이 개념에서는 RAM 페이지와 플래시 페이지 사이의 페이지 스와핑도 무제한적으로 가능하다.
파라미터는 그 기능에 따라 플래시 메모리 내에 조직화시켜야 하며, 이에 따라 사용 가능한
RAM 블록은 가능한 한 효율적으로 사용할 수 있게 된다. 소프트웨어 개발자는 같은 주제를
갖는 파라미터가 인접한 메모리 영역에 놓이도록 지정한다. 파라미터들을 RAM에 복사한
후, 특정 기능을 위해 조율된 이 파라미터들은 사용 준비가 된다.
3.5 각 AUTOSAR에 대한 RAM 포인터 기반의 캘리브레이션 개념

이 개념은 AUTOSAR 운영 체제의 사용을 요구하지 않으며, 아무런 운영 체제가 없는 전혀
다른 환경에서도 사용 가능하다. 이 개념은 이전 개념과 중요한 면에서 유사성을 보인다.
주요한 차이점은 RAM을 플래시 메모리로 대치하는 것이 하드웨어 메커니즘으로
구현된 것이 아니라 소프트웨어 메커니즘으로 구현되었다는 점이다. 캘리브레이션
파라미터는 ECU 소프트웨어에서 포인터에 의해 항상 참조되고 있다. 플래시 메모리나
RAM에 든 내용은 이 포인터를 변경하여 액세스할 수 있다. 수정할 플래시 파라미터는
사용 가능한 RAM을 가지고 지정된 블록에 복사된다. 이 방법은 이전 방법과
마찬가지로 XCP 관점에서 완전히 투명하게 구현될 수 있다. 한 가지 대안으로 캘리
브레이션 툴 사용자는 원하는 파라미터를 미리 선택하여 수정할 파라미터를 확실하게
선택할 수 있다. 이 방법의 장점은 사용자가 자원의 이용과 탑재 상황을 볼 수 있다는
점으로, 사용자는 작업 도중 메모리 부족으로 놀랄 일이 없을 것이다.
3.5.1 단일 포인터 개념
포인터 테이블은 RAM에 위치한다. ECU를 부팅할 때 모든 포인터는 플래시 메모리에

있는 파라미터값을 나타낸다. 캘리브레이션용 RAM의 위치와 파라미터는 알려졌지만 부팅
후에는 파라미터값이 아직 올라와 있지 않다. 처음에는 어플리케이션이 전적으로 플래시
메모리에서만 작업한다.
FLASH Pointertable RAM
Parameters 그림 52:
부팅 후 처음 상황
사용자가 부팅 후 처음으로 A2L 파일에서 파라미터를 하나 선택하고 그에 대한 쓰기 액세스를

얻고자 한다면, 이는 먼저 ECU 내에서 복사 작업을 촉발한다. XCP 슬레이브는 액세스할
주소가 플래시 영역에 있는지 확인하고 이 파라미터값을 캘리브레이션용 RAM에 복사한다.
해당 어플리케이션이 파라미터값을 플래시 메모리가 아니라 RAM 영역에서 가져오게 하도록
포인터 테이블에 변경을 가한다.
3.5 각 AUTOSAR에 대한 RAM 포인터 기반의 캘리브레이션 개념 81
FLASH Pointertable RAM
그림 53:
Parameters 포인터 변경과
RAM에 복사하기
어플리케이션은 포인터 테이블을 통해 계속 파라미터값을 가져 온다. 그러나 포인터는

RAM 주소를 지시하기 때문에, 그곳에서 값을 가져온다. 그 결과, 사용자는 XCP를 통해
파라미터값을 변경할 수 있고, 측정을 통해 변경 효과를 관찰할 수 있다. 이 방법의 단점은
포인터 테이블에 입력한 값이 각각의 파라미터에서 모두 사용 가능해야 한다는 점으로 그에
따라 포인터 테이블용으로 상당량의 추가 RAM 메모리가 필요하게 된다는 점이다.
다음 그림은 이 문제를 보여주고 있다. PID 컨트롤러의 세 가지 파라미터(P, I, D)는 ECU의

플래시 영역에 실려 있다. RAM 주소와 RAM 내에 있는 파라미터값은 이미 포인터
테이블에서 변경되었다.
Parameter Flash Pointertable RAM

Addr. Content Addr. Addr. Content
P 0x0000100A 0x11 0x000A100A 0x000A100A 0x44
I 0x000012BC 0x22 0x000A100B 0x000A100B 0x55
D 0x00007234 0x33 0x000A100C 0x000A100C 0x66
그림 54: 각 파라미터용 포인터 테이블
캘리브레이션 개념은 RAM 자원이 부족하므로 매우 중요하다. 대형 RAM 포인터 테이블은

이 개념을 무용지물로 만들 수 있다.
각각의 파라미터에 대해 포인터를 하나씩 만드는 일을 피하고 또 그와 같은 방법을 사용하는

일을 피하고자, 파라미터들을 구조(structure)로 결합할 수 있다. 여기서는 구조마다 포인터가
하나씩 필요하다. 사용자가 파라미터를 하나 선택하면, 이 파라미터뿐 아니라 전체 관
련 구조가 RAM에 복사된다. 이 구조의 단위 크기(granularity)도 여기서 아주 중요하다.
몇 개의 포인터를 갖는 큰 구조가 필요하다. 이 말은 RAM 영역에 좀 더 큰 관련 구조가
복사되고 이에 따라 캘리브레이션용 RAM의 공간이 빠르게 한계에 다다르게 된다는
뜻이다.
예:
캘리브레이션용 RAM의 크기는 400바이트이다. 다음 파라미터로 소프트웨어에 4개의
구조를 정의한다.
A 구조: 250바이트
B 구조: 180바이트
C 구조: 120바이트
D 구조: 100바이트
사용자가 A 구조에서 파라미터를 하나 선택하면, 플래시 메모리에서 캘리브레이션용 RAM

으로 250 바이트가 복사되며, 사용자는 A 구조에 위치한 모든 파라미터에 XCP로 액세스
할 수 있다. 캘리브레이션 업무가 이 구조의 파라미터로 한정되는 경우, 캘리브레이션용
RAM만으로도 충분하다. 그러나 만약 사용자가 예를 들어, C 구조와 같이 다른 구조에 있
는 또 다른 파라미터를 선택하는 경우 이 120바이트도 캘리브레이션용 RAM에 복사되어야
한다. 캘리브레이션용 RAM은 400바이트를 처리할 수 있기 때문에, 사용자는 A 구조와 C
구조에 동시에 액세스할 수 있다.
선택한 다른 파라미터가 C 구조에 없고 B 구조에 있는 경우에는 A 구조의 250바이트 이

외에도 B 구조의 180바이트를 RAM에 복사해야 한다. 그러나 RAM에는 이를 위한 공간이
부족하므로 사용자는 A 구조의 파라미터에는 액세스할 수 있지만, ECU가 해당 명령어를
복사할 수 없으므로 B 구조의 데이터에는 액세스할 수 없다.
3.5.2 이중 포인터 개념
단일 포인터 개념의 단점은 메모리 페이지 스와핑을 구현하기가 쉽지 않다는 점이다. 캘

리브레이션 툴은 포인터 테이블을 완전히 페이지 스와핑용으로 기술할 수 있으나, 단기적
으로는 일시적인 불일치와 부작용을 초래하기 때문에 적절하지 않다. 툴에 투명하게 구현
하는 작업은 포인터 테이블용으로 필요한 메모리 공간을 두 배로 늘리는데, 그 이유는 메
모리 페이지를 플래시 메모리로 스와핑할 때, 이전 포인터 테이블의 복사본이 RAM 포인
터와 함께 생성되기 때문이다.
대형 포인터 테이블을 갖는 어플리케이션이나 투명한 구현 또는 완전히 일관성 있는 스와

핑 등에 대해서는 이 방법을 이중 포인터 개념으로 확장할 수 있는 선택사항이 있다. 그
방법을 설명하기 위해 초기 RAM 세팅으로 돌아가 보자.
3.6 플래시 포인터 기반의 캘리브레이션 개념 83
그림 55는 포인터 테이블을 보여주고 있다. 포인터 테이블은 RAM에 위치한다. 이미

언급했던 것처럼 이 테이블은 플래시 메모리에서 RAM으로 복사해야 한다. 그 결과, 이
테이블은 플래시 메모리에 놓이게 된다. RAM이나 플래시에 있는 포인터 테이블을 지시하는
다른 포인터가 사용되는 경우(테이블 포인터), 이중 포인터 솔루션에 다다르게 된다.
FLASH RAM
Pointertable FLASH Pointertable RAM
그림 55:
Tablepointer
이중 포인터 개념
파라미터값은 처음에 테이블 포인터를 통해서 액세스한다. 테이블 포인터가 RAM에 있는 포

인터 테이블을 지시하는 경우, 어플리케이션은 기본적으로 RAM 포인터 테이블의 내용을 통
해 실제 파라미터에 액세스한다. 이 솔루션의 단점은 낮은 액세스 속도와 더 많은 프로그램
코드를 생성한다는 점이다.
3.6 플래시 포인터 기반의 캘리브레이션 개념

이 방법은 수년 전에 "InCircuit2"라는 이름으로 ZF 프리드리히샤펜(ZF Friedrichshafen)사
에서 특허를 냈으며, AUTOSAR의 포인터 기반 개념과 상당히 유사하다. 여기서도 ECU에
있는 어플리케이션은 포인터 테이블을 이용하여 파라미터 데이터에 액세스한다. 그러나 이
포인터 테이블은 RAM에 있는 것이 아니라 플래시 메모리에 들어 있다. 포인터 테이블을
변경하기 위해서는 플래시 프로그래밍을 해야 한다. 툴에 투명한 구현 방식은 가능하지
않다. 이 방식의 장점은 RAM에 포인터 테이블이 들어있지 않기 때문에 RAM의 메모리를
저장할 수 있다는 데 있다.
84
4 XCP의 어플리케이션 영역 85
4 XCP의 어플리케이션 영역
86 4 XCP의 어플리케이션 영역
ECU 캘리브레이션 담당자가 XCP를 사용하고자 할 때 보통 이 프로토콜을 ECU에 고착

시킨다.
Simulink
Slave
Prototype or
ECU Hardware
Slave
Measurement/
XCP Calibration
Master Slave Hardware*
PC
EXE/DLL
Slave
HIL/SIL Systems
Slave 그림 56:
어플리케이션 영역과
* Debug Interfaces, Memory Emulator, ...
어플리케이션 사례
개발 프로세스를 조사하는 과정에서 전자기기나 소프트웨어 개발에 대한 수많은 솔루션을

접할 수 있다. 여기서 키워드는 HIL과 SIL, 래피드 프로토타이핑 등인데, 이런 것들은 서로
다른 시나리오를 이용하고 있다. 이들이 공통으로 사용하는 것은 "플랜트"와 "컨트롤러"
이다.
Manipulated Disturbance
Offset Variable Variable
Reference Variable Controlled Variable

Controller Plant
(Set Value) (Actual Value)
그림 57: 플랜트와 컨트롤러
자동차를 개발하는 상황에서 컨트롤러란 ECU를 말하고 플랜트는 전송장치, 엔진, 사이드
미러 등과 같이 제어가 가능한 물리적 시스템을 말한다.
컨트롤러나 플랜트를 실제로 또는 시뮬레이션을 통해 구동하는가에 따라 개발 방식을 대략

구분한다. 일부 조합은 좀 더 상세하게 설명할 것이다.
4.1 MIL: Model in the Loop 87
4.1 MIL: Model in the Loop
Simulink
Controller Model Plant Model

그림 58:
시뮬링크의 MIL
이 개발 환경에서 컨트롤러와 플랜트는 모두 하나의 모델로 시뮬레이션된다. 여기 있는

예에서는 시뮬링크를 런타임 환경으로 하여 이 두 모델을 구동한다. 행태를 분석하는 데
있어 시뮬링크 런타임 환경의 능력을 사용할 수 있다.
초기 개발 단계에서 CANape와 같은 측정/캘리브레이션 툴의 편의성을 구현하기 위해 XCP

슬레이브는 컨트롤러 모델에 통합시킬 수 있다. 저작 단계에서 슬레이브는 이 모델에 대응
하는 A2L을 생성하며, 사용자는 이미 그래픽 윈도를 이용한 프로세스 흐름의 가시화, 특성
곡선에 대한 접근, 맵 등등 모든 편리한 운영에 필요한 기능을 갖게 된다.
Simulink

CANape
그림 59:
Simulink 시뮬링크 모델의 측정/
XCP Server
A2L 캘리브레이션 툴로서의
CANape
코드 생성 단계나 모델의 계측화는 여기에 필요하지 않다. 타임스탬프도 XCP를 통한 전송

시 포함된다. CANape는 여기서 시뮬링크 런타임 환경의 시간 거동에 완전히 적응했다.
이 모델이 실시간 보다 빠르게 혹은 느리게 구동되는지는 중요하지 않다. 예를 들어, 기능
개발자가 이 모델을 통해 시뮬링크 디버거를 사용한다면, CANape는 XCP를 통해 전송된
시간을 참조 시간으로 사용한다.
4.2 SIL: Software in the Loop
Simulink
Code generation
Controller Model 그림 60:

Windows DLL 시뮬링크 환경의
SIL
이 개발 단계에서, 코드는 컨트롤러 모델에서 생성되며, 이 코드는 PC 기반의 런타임

환경에서 사용한다. 자연적으로, 컨트롤러는 어떠한 모델 기반의 접근방법도 사용하지 않고
개발할 수 있다. 플랜트는 계속 시뮬레이션 된다. XCP는 컨트롤러를 측정하고 캘리브레이션
하는데 사용할 수 있다. 컨트롤러가 시뮬링크 모델에서 생성된 경우라면, DLL 및 그에
연관된 A2L을 위한 C 코드를 생성하기 위해 코드 생성 단계(CANape를 타겟으로 한
시뮬링크 코더)를 사용한다. 만약 수작업으로 작성한 코드를 기반으로 컨트롤러를 개발하는
경우에는 CANape와 함께 제공되는 C++ 프로젝트에 내장시킨다.
컴파일과 링크 후, 이 DLL은 CANape 환경에서 사용된다. XCP 접속을 지원하기 때문에

이 DLL의 알고리즘은 어플리케이션이 ECU에 이미 통합된 것과 마찬가지로 정확하게
측정 및 캘리브레이션할 수 있다.
Simulink
Code generation
Controller Model
A2L CANape Windows DLL
그림 61:
SIL 개발 플랫폼으로서의
CANape
4.3 HIL: Hardware in the Loop 89
4.3 HIL: Hardware in the Loop

다양한 HIL 시스템이 출시되어 있다. 매우 간단하고 가성비 좋은 시스템에서 고가의 초대형
시스템에 이르기까지 다양하다. 다음 그림이 대략적인 개념을 보여주고 있다.
Controller Model
HIL Platform
I/O
Plant Model
그림 62:
ECU
HIL 솔루션
컨트롤러 알고리즘은 마이크로컨트롤러 플랫폼에서 (예를 들어 ECU) 구동되는 반면

플랜트는 계속해서 시뮬레이션을 사용하고 있다. 파라미터와 플랜트의 복잡성, 필요한 I/O
등에 따라 HIL 플랫폼에 대한 요구사항과 관련 비용은 가파르게 상승할 수 있다. ECU는
실시간으로 구동되기 때문에 플랜트 모델의 시뮬레이션도 실시간으로 진행해야 한다.
XCP의 최적화는 또 하나의 ECU만 추가하면 되니까 사소한 것으로 보인다. 전체적인
시스템은 다음과 같다:
Controller Model
A2L
HIL Platform
I/O
CANape
Plant Model
그림 63:
HIL 측정/캘리브레이션
ECU
툴로서의 CANape
CANape에서는 사용자가 XCP를 통해 ECU의 알고리즘에 액세스할 수 있다.

벡터 사의 툴인 CANoe도 많은 고객이 HIL 시스템으로 사용하고 있다. CANoe를 사용할

경우, HIL 시스템과 같이 보인다.
CANoe RT User PC
Ethernet
CANoe RT Server
CAN
LIN
Plant Model
MOST A2L
FlexRay
Digital I/O Analog I/O
XCP
CANape
그림 64:
HIL 시스템으로서의
ECU
CANoe
시험하기 위해 CANoe에서 직접 XCP 데이터에 액세스할 수 있는 기능은 다음과 같이

사용할 수도 있다.
CANoe RT User PC A2L
Ethernet
CANoe RT Server
CAN
LIN
Plant Model XCP
MOST
FlexRay
Digital I/O Analog I/O
그림 65:
CANoe를 HIL 시스템
으로 사용 시, ECU에
ECU
XCP로 액세스
여기서 플랜트 모델은 CANoe의 실시간 서버에서 구동된다. 동시에 ECU에 XCP로 액세스
하는 것도 CANoe에서 할 수 있다. 이러한 능력은 사용자에게 플랜트와 컨트롤러에 동시에
액세스할 수 있는 툴을 마련해 주는 것이다.
4.4 RCP: Rapid Control Prototyping 91
이 그림을 자세히 설명하기 위해서는 또 다른 HIL 솔루션에 대해서도 언급을 해야 한다.

플랜트는 CANape에서 하나의 DLL로 구동할 수 있다. 이를 이용해 사용자는 XCP를 통해
플랜트와 컨트롤러에 완전하게 액세스할 수 있다.
ECU CANape Plant Model

A2L Windows DLL
XCP
Plant A2L XCP ECU
그림 66: HIL 솔루션으로서의 CANape
4.4 RCP: Rapid Control Prototyping

이 개발 단계에서 제어 알고리즘은 ECU 대신 실시간 HIL에서 구동된다. 이런 상황은
필요한 ECU 하드웨어를 사용할 수 없을 경우 흔히 발생한다. 몇몇 플랫폼은 단순한 평가
위원회에서 자동차 차원의 하드웨어 솔루션에 이르기까지 추가적인 요구사항을 충족시킬
수 있는 하드웨어로서 적합한지 의문이 제기되고 있다. 여기서도 XCP와 통합을 하는 경우
OEM에 독립적인 툴 체인을 설정하는 데 도움이 된다.
Controller Model
A2L CANape EVA Board

XCP I/O
Plant
그림 67: RCP 솔루션
"신속한(Rapid)"과 "프로토타이핑(Prototyping)"의 개념은 이 과제를 잘 나타내고 있다. 여기서

목표는 기능하는 프로토타입을 가능한 한 빨리 개발하고 이를 런타임 환경에서 사용 및
시험하는 것이다. 여기에는 프로세스 전체에 걸친 단순한 작업 단계가 필요하다.
참고자료에서 RCP 접근방식은 흔히 풀패싱(fullpassing)과 바이패싱(Bypassing)이라는 두

개의 영역으로 나뉜다.
그림 66에 나온 대로 컨트롤러 전체는 별도의 실시간 HIL에서 구동된다. 이 방법은 컨

트롤러 전체가 컨트롤러 하드웨어 상에서 구동되기 때문에 풀패싱이라고 한다. 여기서는
플랜트와 인터페이스를 할 수 있도록 필요한 I/O 장치를 갖추어야 한다. I/O 장치의 기술
요건을 충족시키기 위해서는 강력한 전자장비가 필요한 경우가 자주 있다.
문제가 되는 것은 I/O 장치뿐만이 아니다. ECU 소프트웨어의 기능 요소들도 (예:

네트워크 관리) 더욱 복잡한 네트워크에서 기능을 활성화할 필요가 있다. 그러나 만약
일반적인 컨트롤러 플랫폼 대신 RCP용으로 완전한 ECU가 사용되는 경우에는 플래시
프로세스의 복잡성, 전체 소프트웨어의 크기 등 모든 것이 "신속한" 개발 요건에서 멀어지게
만들 것이다.
요약하자면, ECU 전체를 컨트롤러용 런타임 환경으로 사용하는 경우, 플랜트용 하드웨어와
소프트웨어 인프라가 존재한다는 점은 장점으로 작용하지만, 단점으로는 과도한 복잡성을
들 수 있다.
바이패싱 개념은 과도한 복잡성에 구애되지 않고 ECU 인프라의 장점을 최대한 활용하기
위해 개발되었다.
4.5 바이패싱
그림 68에서 ECU는 플랜트에 접속되어 있다. 필요한 I/O와 소프트웨어 컴포넌트는 ECU에
들어 있다. 바이패싱 하드웨어에서는 ECU의 버전 A에 있는 알고리즘 A1가 구동된다. A1은
이 알고리즘의 새로운 변형으로 실제 플랜트에서 시운전해 보아야 한다.
ECU A2L XCP Bypassing Hardware

CANape
Bypassing
Hardware A2L
XCP
I/O
Controller Model
ECU Plant
그림 68: 바이패싱의 기본 원칙
4.5 바이패싱 93
바이패싱 하드웨어(그림에 나온 VN8900 기기)와 ECU는 XCP를 이용해 상호접속된다.

여기서 한 가지 목표는 DAQ를 이용해 ECU에서 알고리즘 A1에 필요한 데이터를 가져오는
것이다. 또 다른 목표는 A1의 결과를 신호 인가해 ECU로 돌려보내는 것이다. 다음 그림은
이러한 흐름을 도식적으로 보여주고 있다.
Bypassing Hardware
Algorithm A1
2.
Bypassing
Coordinator
3.
1. XCP 4.
Algorithm A
ECU 그림 69:
바이패싱 흐름
ECU에 있는 것은 알고리즘 A가 구동하는 푸른 색의 기능 블록이다. 현재 A1을 사용할 수

있는지 확인하기 위해 데이터는 알고리즘 A에 입력 변수로 입력되고, 이는 DAQ가 ECU
에서 측정한다. 1 단계에서는 바이패싱 코디네이터가 데이터를 받아들이고, 2단계에서는
데이터를 알고리즘 A1으로 보낸다. A1은 바이패싱 하드웨어가 계산하고, 3단계에서는 결과
값이 바이패싱 코디네이터로 다시 돌려 보낸다. 4단계에서는 이 값이 STIM에 의해 ECU로
전달된다. 이 데이터는 슬레이브에서 그다음 기능 블록이 입력 변수를 찾게 될 "위치"에
쓰여지게 된다. 이로써 A가 아니라 알고리즘 A1가 계산한 값을 ECU의 전반적인 제어
프로세스에서 사용할 수 있게 된다. 이 방법은 I/O 장치와 ECU의 베이직 소프트웨어를
포함하는 바이패싱 하드웨어에서 알고리즘을 신속하게 교체할 수 있도록 한다.
물론, XCP on CAN 드라이버의 성능 상 한계도 바이패싱에 영향을 미친다. 짧은 바이패싱

시간이 필요한 경우에는 DAQ와 STIM으로 ECU에 액세스하는 것도 컨트롤러의 디버깅이나
추적 인터페이스를 통해 수행할 수 있다. 벡터의 VX1000 측정/캘리브레이션 하드웨어는
데이터를 컨트롤러 인터페이스에서 XCP on Ethernet의 데이터 스트림으로 전환시킨다.
이 프로세스에서는 최대 1메가바이트의 데이터를 ECU로 전송할 수 있다.
XCP Bypassing Hardware

Bypassing
Hardware A2L CANape
XCP
Measurement & Calibration

Hardware VX1000
Debugging and Trace Interface
I/O
Controller Model
ECU
Plant
그림 70: 실시간 바이패싱 하드웨어로 바이패싱 및 ECU 고속 액세스

4.6 가상 ECU로 반복 사이클 단축

이용하는 다른 솔루션도 있는데, 이 알고리즘은 ECU내에서 구동되는 것이 아니라 PC에서
실행코드의 형태로 또는 시뮬링크 모델을 이용한 "가상 ECU"의 형태로 구동된다. 이런 가상
ECU는 실시간으로 구동할 필요가 없는데, 왜냐하면 이런 경우에는 실제 시스템에 대해
접속하지 않기 때문이다. 이 경우에는 PC의 계산성능에 따라 훨씬 빠른 속도로 구동할
수 있다.
이 알고리즘은 이전에 로그했던 측정 파일에 의해 신호 인가가 되는데, 이 파일에는 알고

리즘의 입력신호로 필요한 모든 신호가 실려 있다. CANape로 접속하는 것은 XCP를 통해
설정한다. 사용자는 파라미터를 만들고, 측정을 구성할 수 있다. 이후에는 실행이 시작된다.
여기서 시운전에서 얻은 데이터를 신호 인가로 알고리즘에 입력하고 어플리케이션에서
원하는 측정 파라미터를 동시에 측정한 후 측정 파일로 저장한다.
Para- MDF
meter test drive
Application
5. Analyze 1. Set parameters
2. Start Simulink/
CANape 3. Send test drive data DLL
4. Measurement data
Slave
그림 71:
New 가상 ECU로
MDF 캘리브레이션
사이클 단축
계산이 완료된 후, 사용자는 ECU의 거동을 분석하기 위한 새로운 측정 파일을 이용할 수

있다. 새로운 측정 파일의 시간 길이는 입력 측정 파일의 길이와 정확하게 정합한다. 시운전
시간이 1시간인 경우, 이 알고리즘은 PC에서 불과 몇 분 만에 시운전 전체를 계산할
수 있다. 그러면 1시간 동안의 시험에 해당하는 측정 결과가 존재한다. 데이터 분석을
기초로 사용자는 파라미터 생성에 대한 결정을 내리고, 이 반복 사이클(iteration cycle)은
되풀이된다.
CANape Application as EXE or DLL on PC

Parameterization Set values in
via XCP workspace
Start Start
Send measurement Calculate model

data
Receive new Send measurement

measurement data values from the model
Analyze the End model calculation

new data
그림 72:
New software version 가상 ECU를 이용한
프로세스 흐름
반복 사이클을 단축하기 위해 이 알고리즘은 항상 동일한 데이터에 의해 신호 인가된다.

이에 따라 다른 파라미터를 사용해 얻은 결과들도 비교할 수 있게 되는데, 그 이유는 이
러한 결과가 다른 파라미터들에 의해서만 영향을 받기 때문이다.
이 프로세스는 물론 자동화시킬 수 있다. CANape의 통합 스크립트 언어는 측정 결과의

분석을 수행하며, 또한 이 측정 결과에서 파라미터 캘리브레이션에 대해 설정을 하고 자
동으로 실행하게 된다. 또한 CANape 자동화 인터페이스를 이용해 매트랩과 같은 외부의
최적화 툴로 프로세스를 제어하는 것도 가능하다.
98
5 XCP 구현 사례
100 5 XCP 구현 사례
ECU가 XCP를 통해 통신할 수 있도록 하기 위해서는 ECU의 어플리케이션에 XCP 드라이버를

통합시킬 필요가 있다. 다음에 설명하는 예제는 벡터 사 웹사이트의 다운로드 센터에서
(www.vector.com/xcp-driver) 무료로 다운로드할 수 있는 XCP 드라이버를 이용하고
있다. 이 패킷에는 또한 다양한 전송 레이어와 목표 플랫폼을 구현하기 위한 샘플도
들어 있다. 드라이버는 측정/캘리브레이션에 필요한 기본 기능이 있는 프로토콜과 레이어로
구성된다. 여기에는 콜드 스타트 측정이나 신호 인가, 플래싱과 같은 기능이 포함되어 있지
않다. 이 기능들이 모두 구현된 패키지를 구입하고 싶다면 벡터의 CANbedded나AUTO-
SAR 환경을 구입하면 된다.
XCP 프로토콜 레이어는 XCP 전송 레이어 위에 위치하는데, 이 전송 레이어는 실제 버스

통신을 기반으로 하고 있다. XCP 프로토콜 레이어는 C 파일 하나와 몇 개의 H 파일
(xcpBasix.c, xcpBasic.h, xcp_def.h and xcp_cfg.h)로 구현할 수 있다. 이러한 예로는
Ethernet과 RS232 등 다양한 전송 레이어의 구현을 들 수 있다. CAN의 경우, 전송 레이어는
보통 매우 단순하며, 다양한 XCP 메시지 종류를 CAN 메시지에 직접 매핑할 수 있으며,
그 다음에는 Tx방향과 Rx 방향의 고정 식별자를 별개로 부여하게 된다.
전송 레이어와 프로토콜 레이어 사이의 소프트웨어 인터페이스는 매우 단순하며, 불과 몇 개의

기능만을 가지고 있다.
>슬
레이브가 버스를 통해 XCP 메시지를 수신하면, 메시지는 먼저 통신 드라이버에 도착
하고, 드라이버는 이 메시지를 XCP 전송 레이어로 전달한다. 전송 레이어는 프로토콜
레이어에 XcpCommand()함수를 호출하여 이 메시지에 대해 통보한다.
>X
CP 프로토콜 레이어가 메시지를 발신하고자 하는 경우에는(예를 들어 마스터에게서
받은 XCP 명령어나 DAQ 메시지에 대한 응답), 이 메시지가 ApplXcpSend() 함수를
호출하여 전송 레이어로 보낸다.
>전
송 레이어는 XcpSendCallBack() 함수를 호출하여 프로토콜 레이어에 메시지가 성공
적으로 발신되었음을 통보한다.
Application
ApplXcpGetPointer
XcpBackground
XcpEvent
Application - XCP Transport

XcpInit
Layer Interface
XCP Protocol Layer
XcpSendCallback
XcpCommand
ApplXcpSend
XCP Transport Layer
Physical Layer
그림 73:
Bus ECU 코드에
XCP 슬레이브 결합
어플리케이션과 프로토콜 레이어 사이의 인터페이스는 4가지 함수를 가지고 구현할 수 있다.
>어
플리케이션은 XcpInit()를 이용해서 XCP 드라이버를 활성화한다. 이 기능은 시작 프로세스
도중 한 번 호출한다.
>어
플리케이션은 XcpEvent()를 이용해서 XCP 드라이버에게 특정 이벤트가 발생했음을
알린다. (예: "계산 사이클 끝에 도달했습니다" 등)
>X
cpBackground()를 호출하여 XCP 드라이버가 백그라운드에서 특정 활동을 실행하도록
한다. (예: 체크섬 계산하기 등)
>A
2L 파일의 주소는 항상 40비트 값으로 정의되므로(32 비트는 주소, 8비트는 주소 확장자),
XCP 드라이버는 A2L에 정합하는 주소에서 포인터를 얻기 위해 ApplXcpGetPointer()
함수를 사용한다.
이 인터페이스는 측정/캘리브레이션을 위한 기본 기능을 통합시키기에 충분하다. 다른

인터페이스는 페이지 스와핑이나 식별, Seed & key 등과 같은 확장 함수를 이용하고자 할
때에만 필요하다. 이에 대한 내용은 드라이버 설명문서에 자세히 설명되어 있다.
5.1 함수 설명
void XcpInit (void)
과제:
XCP 드라이버를 초기화한다.
설명:
어플리케이션은 XCP 드라이버를 XcpInit()로 활성화시킨다. 이 명령어는 다른 XCP 드라이버
함수를 호출하기 전에 딱 한 번 실행해야 한다.
void XcpEvent (BYTE event)
과제:
어플리케이션은 XCP 드라이버에게 어떤 이벤트가 발생했는지 통지한다. 여기서 각각의
이벤트에 대해 고유 이벤트 번호가 할당된다.
설명:
측정/캘리브레이션 툴의 측정 구성을 설정할 때 사용자는 어떤 측정값을 어떤 이벤트와
동기화시켜 획득할지를 선택한다. 측정값과 이벤트에 관한 정보는 A2L에서 가져온다. 원하는
측정 구성을 DAQ 리스트의 형태로 XCP 드라이버로 보낸다.
다음은 엔진 컨트롤러에서 이벤트를 정의하는 예제이다.
XcpEvent (1); // 이벤트 1은 10ms 과제를 나타낸다

XcpEvent (2); // 이벤트 2는 100ms 과제를 나타낸다
XcpEvent (5); // 이벤트 5는 1ms 과제를 나타낸다
XcpEvent (8); // 이벤트 8은 점화 각도의 동기화 측정에 사용된다
BYTE XcpBackground (void)
과제:
XCP 드라이버의 백그라운드 작업을 실행한다.
설명:
이 함수는 백그라운드 작업이나 유휴 작업으로 주기적으로 호출된다. 이 함수는 예를 들어
체크섬을 계산할 때 XCP 드라이버를 사용하는데, 왜냐하면 XcpCommand()의 긴 체크섬을
계산하는 데에는 엄청나게 오랜 시간이 소요되기 때문이다. XcpBackground()을 호출
할 때마다 256바이트씩 체크섬이 부분적으로 계산된다. 그러므로 체크섬 계산 시간은
XcpBackground()의 호출 빈도에 따라 결정된다. 호출 빈도나 주기에 대한 다른 요구사항은
없다. 반환 값 1은 현재 체크섬 계산이 진행 중임을 나타낸다.
5.1 함수 설명 103
void XcpCommand (DWORD* pCommand)
과제:
XCP 명령어를 해석한다.
설명:
이 함수는 전송 레이어가 XCP 프레임을 수신할 때마다 호출해야 한다. 파라미터는 프레임에
대한 포인터이다.
void ApplXcpSend (BYTE len, BYTE *msg)
과제:
전송 레이어에 보낼 프레임을 전송한다.
설명:
이 호출로 프로토콜 레이어는 마스터로 전송하기 위해 메시지를 전송 레이어로 보낸다.
XcpSendCallBack의 호출은 프로토콜과 전송 레이어 사이에 핸드세이크 방식으로 구현
된다.
BYTE XcpSendCallBack (void)
과제:
프로토콜 레이어는 이 콜백(callback)을 사용해서 전송 레이어에 ApplXcpSend()로 전송한
마지막 메시지가 성공적으로 전달되었다고 통지한다.
설명:
이 프로토콜 레이어는 XcpSendCallBack()에서 이전 메시지가 성공적으로 전달되었다고
표시할 때까지 ApplXcpSend() 명령어를 호출하지 않는다. XcpSendCallBack()는 XCP
드라이버가 유휴 모드일 때는 0 값(FALSE)을 보낸다. 보낼 프레임이 더 있는 경우에는
XcpSendCallBack()에서 ApplXcpSend()를 직접 호출한다.
BYTE *ApplXcpGetPointer (BYTE addr_ext, DWORD addr)
과제:
A2L에 정합하는 주소를 포인터로 전환한다.
설명:
이 기능은 XCP 마스터가 보낸 A2L에 정합하는 40비트 주소(32비트 주소 + 8비트 주소
확장자)를 유효한 포인터에 매핑한다. 주소 확장자는 예를 들어 다른 주소 영역이나 메모리
유형을 구분하는 데 사용할 수 있다.
5.2 드라이버에 대한 파라미터 생성

많은 점에서 XCP 드라이버는 다양한 함수와 전송 프로토콜, 목표 플랫폼을 처리할 수 있
도록 확장할 수 있고 파라미터 생성이 가능하다. 모든 설정은 파라미터 파일인 xcp_cfg.h
을 이용해 한다. 가장 단순한 경우는 다음과 같다.
/* Define protocol parameters */

#define kXcpMaxCTO 8 /* Maximum CTO Message Length */
#define kXcpMaxDTO 8 /* Maximum DTO Message Length */
#define C_CPUTYPE_BIGENDIAN /* byte order Motorola */
/* Enable memory checksum */

#define XCP_ENABLE_CHECKSUM
#define kXcpChecksumMethod XCP_CHECKSUM_TYPE_ADD14
/* Enable calibration */
#define XCP_ENABLE_CALIBRATION
#define XCP_ENABLE_SHORT_UPLOAD
/* Enable data acquisition */

#define XCP_ENABLE_DAQ
#define kXcpDaqMemSize (512) /* Memory space reserved for DAQ */
#define XCP_ENABLE_SEND_QUEUE
CAN 전송 레이어에 대해서는 8 바이트의 적절한 CTO /DTO 파라미터를 설정한다. 드라

이버는 구동하는 플랫폼이 모토로라(Motorola)나 인텔의 바이트 순서를 따르는지, 이 경우
에는 모토로라의 CPU(빅 엔디언: Big Endian)를 따르는지 알고 있어야 한다. 나머지 파라
미터들은 측정이나 캘리브레이션, 체크섬 계산 등의 기능을 활성화한다. 체크섬 계산용 알
고리즘을 구성하고 (여기서는 모든 바이트를 DWORD로 합산), 사용 가능한 메모리의 파라
미터는 측정용으로 표시한다(여기서는 512 바이트). 메모리는 주로 DAQ 리스트를 저장하
고 측정 도중에 데이터를 버퍼링하는 데 사용한다. 그러므로 이 파라미터는 측정 신호의
가능한 최대수를 결정한다. 필요한 파라미터를 추정하는 데 대한 보다 상세한 정보는 드
라이버 문서에서 찾을 수 있다.
5.2 드라이버의 파라미터화 105
106 저자
저자
Andreas Patzer
카를스루에 기술대학교에서 전기공학을 전공한 그는 측정 및 제어 공학과 정보

및 산업 공학에 대해 특히 전문화된 지식을 가지고 있다.
그는 2003년 슈투트가르트에 소재한 벡터에 입사하였으며, XCP가 ASAM에서
표준화된 이래로 아주 초기부터 XCP 프로젝트를 지원해 왔다. 그년 현재 측정/
캘리브레이션 제품 라인에서 고객관리 및 서비스 팀장을 맡고 있다.
저자 107
Rainer Zaiser
슈투트가르트 대학교에서 전기공학을 전공한 그는 졸업 후(1988년 가을), 바로

벡터에 입사했다. 그는 자동차 업계 표준인 DBC, MDF, CCP, A2L 및 XCP
확립에 크게 기여했다. 또한, 측정 및 캘리브레이션, 네트워크 인터페이스 제품
라인을 이끌고 있다.
108 약어 표
약어 표
A2L File extension for an ASAM 2MC language file

AML ASAM 2 Meta Language
ASAM Association for Standardisation of Automation and Measuring Systems
BYP Bypassing
CAL Calibration
CAN Controller Area Network
CCP CAN Calibration Protocol
CMD Command
CS Checksum
CTO Command Transfer Object
CTR Counter
DAQ Data Acquisition, Data Acquisition Packet
DTO Data Transfer Object
ECU Electronic Control Unit
ERR Error Packet
EV Event Packet
FIBEX Field Bus Exchange Format
LEN Length
MCD Measurement Calibration and Diagnostics
MTA Memory Transfer Address
ODT Object Descriptor Table
PAG Paging
PGM Programming
PID Packet Identifier
RES Command Response Packet
SERV Service Request Packet
SPI Serial Peripheral Interface
STD Standard
STIM Data Stimulation Packet
TCP/IP Transfer Control Protocol / Internet Protocol
TS Time Stamp
UDP/IP Unified Data Protocol / Internet Protocol
USB Universal Serial Bus
XCP Universal Measurement and Calibration Protocol
Download Sending of data from Master to Slave

Upload Sending of data from Slave to Master
참고자료 & 웹주소 109
참고자료
XCP는 ASAM에서 규정했다.
이 프로토콜과 ASAM에 대한 자료는 www.asam.net에서 찾을 수 있다.
웹주소
표준화 위원회:
> ASAM, XCP 프로토콜 별 문서와 A2L 규격은 www.asam.net에서 찾을 수 있다.
개발 소프트웨어 공급업체:
> 매스웍스, 매트랩이나 시뮬링크 및 시뮬링크 코더에 대한 정보는
www. mathworks.com에서 찾을 수 있다.
> 벡터, CANape의 시험판, XCP 드라이버(기본버전)의 무료 다운로드, ECU
캘리브레이션에 관한 종합 정보, 시험 및 시뮬레이션에 대한 정보는
www.vector.com에서 찾을 수 있다.
110 그림 목차
그림 목차
그림 1: 런타임 환경을 이용한 기초 통신 8
그림 2: ASAM의 인터페이스 모델 9
그림 3: XCP 마스터는 여러 개의 슬레이브와 동시에 통신을 할 수 있다. 10
그림 4: XCP 프로토콜의 프로토콜 레이어와 전송 레이어 구분 14
그림 5: XCP 슬레이브는 다양한 런타임 환경에서 사용할 수 있다 15
그림 6: XCP 패킷 19
그림 7: XCP 패킷 식별자(PID) 개요 19
그림 8: CTO/DTO를 이용한 XCP 통신 모델 20
그림 9: 메시지 식별 21
그림 10: 타임스탬프 21
그림 11: XCP 패킷의 데이터 필드 22
그림 12: XCP 프로토콜의 세 가지 모드: 표준 모드, 블록 모드, 인터리브 모드 24
그림 13: CTO 패킷 구조의 개요 25
그림 14: 캘리브레이션 프로세스 추적의 예 30
그림 15: 파라미터 세트 파일을 ECU의 RAM에 전송 31
그림 16: Hex Window 32
그림 17: A2L 파일에서 구한 "Triangle" 파라미터의 주소 정보 33
그림 18: CANape의 Trace window 내의 폴링 통신 34
그림 19: ECU내의 이벤트 35
그림 20: A2L의 이벤트 정의 35
그림 21: A2L내의 가능한 이벤트에 "Triangle" 할당 36
그림 22: 각 측정 파라미터에 대한 이벤트 (측정 모드) 선택 36
그림 23: DAQ 측정 시 CANape Trace window의 예 37
그림 24: ODT: DAQ DTO로 RAM 주소 할당 38
그림 25: 3개의 ODT를 가진 DAQ 리스트 39
그림 26: 정적인 DAQ 리스트 39
그림 27: 동적인 DAQ 리스트 40
그림 28: DAQ와 STIM을 위한 이벤트 41
그림 29: DTO 전송을 위한 XCP 패킷의 구조 42
그림 30: 절대 ODT값을 가진 식별 필드 43
그림 31: 상대 ODT수와 절대 DAQ 수를 갖는 ID 필드 (1바이트) 43
그림 32: 상대ODT수와 절대DAQ수를 갖는 ID 필드 (2바이트) 43
그림 33: 상대ODT수와 절대DAQ수, 그리고 필 바이트를 갖는 ID 필드 (총 4바이트) 44
그림 34: 어떤 버스 노드가 어떤 메시지를 보냈는지에 대한 정의 45
그림 35: CAN 네트워크의 예 46
그림 36: XCP on CAN 통신의 예 47
그림 37: XCP on CAN 메시지의 예 47
그림 38: CAN FD 프레임의 예 48
그림 39: 노드 K와 노드 L은 중복적으로 상호접속됨 50
그림 40: 슬롯 정의에 의한 통신 50
그림 41: FlexRay 통신 매트릭스의 예 51
그림 42: FlexRay LPDU의 예 52
그림 43: XCP 통신을 LPDU로 할당 53
그림 44: TCP/IP 또는 UDP/IP에서의 XCP 패킷 54
그림 45: XCP-on-SxI 패킷 55
그림 목차 111
그림 46: 메모리 예 56
그림 47: 플래시 영역의 드라이버 설정의 예 58
그림 48: 블록 전송 모드 예 61
그림 49: 캘리브레이션 윈도 내의 파라미터 66
그림 50: 시간에 따른 신호 응답 66
그림 51: RAM의 초기 파라미터 설정 76
그림 52: 부팅 후 처음 상황 80
그림 53: 포인터 변경과 RAM에 복사하기 81
그림 54: 각 파라미터용 포인터 테이블 81
그림 55: 이중 포인터 개념 83
그림 56: 어플리케이션 영역과 어플리케이션 사례 86
그림 57: 플랜트와 컨트롤러 86
그림 58: 시뮬링크의 MIL 87
그림 59: 시뮬링크 모델의 측정/캘리브레이션 툴로서의 CANape 87
그림 60: 시뮬링크 환경의 SIL 88
그림 61: SIL 개발 플랫폼으로서의 CANape 88
그림 62: HIL 솔루션 89
그림 63: HIL 측정/캘리브레이션 툴로서의 CANape 89
그림 64: HIL 시스템으로서의 CANoe 90
그림 65: CANoe를 HIL 시스템으로 사용 시, ECU에 XCP로 액세스 90
그림 66: HIL 솔루션으로서의 CANape 91
그림 67: RCP 솔루션 91
그림 68: 바이패싱의 기본 원칙 92
그림 69: 바이패싱 흐름 93
그림 70: 실시간 바이패싱 하드웨어로 바이패싱 및 ECU 고속 액세스 94
그림 71: 가상 ECU로 캘리브레이션 사이클 단축 95
그림 72: 가상 ECU를 이용한 프로세스 흐름 96
그림 73: ECU 코드에 XCP 슬레이브 결합 101
112 Appendix - 벡터의 XCP 솔루션
Appendix - 벡터의 XCP 솔루션

벡터는 XCP 표준을 만드는데 상당한 노력을 기울였다. 벡터의 방대한 노하우와 경험은
XCP를 종합적으로 지원하는 데 사용되고 있다.
툴
>C ANape의 주요 사용영역은 ECU를 최적의 상태로 캘리브레이션하는 것이다. 이 시스템의
런타임 중에 파라미터값을 캘리브레이션하고 동시에 측정한 신호 값을 획득할 수 있다.
CANape와 ECU의 물리적 인터페이스는 (표준화된 모든 전송 프로토콜에 대해) XCP나
CCP를 통해 이루어진다.
> 필요한 A2L 기술 파일을 생성하고 관리하기 위한 완전한 툴 체인 (ASAP2 Editor를
포함한 ASAP2 Tool-Set와 CANape. ASAP2 Editor는 별도로 판매하기도 한다.)
> 테스트 및 분석 작업을 위해 ECU 내부값에 액세스할 때 CANoe.XCP를 사용
ECU 인터페이스
VX1000 측정 및 캘리브레이션 하드웨어는 ECU에 XCP-on-Ethernet 인터페이스를 갖출
수 있는 혜택을 제공한다. 이는 POD(Plug on Device) DAP, JTAG, Nexus 등을 통해
ECU가 컨트롤러에 직접적인 액세스와 연관되어 있다. POD는 데이터를 베이스 모듈로
전송하는데, 이때 베이스 모듈은 XCP 슬레이브로서 XCP on Ethernet을 통해 PC의 XCP
마스터에 데이터를 제공한다. 이를 통해 ECU 내에는 XCP 슬레이브가 별도로 필요로 하지
않게 된다. 사용자는 최대 30 Mbyte/sec의 고속 데이터 처리량과 15 µs 미만의 짧은 측정
인터벌의 혜택을 누릴 수 있다.
임베디드 소프트웨어
CAN과 FlexRay, Ethernet용으로 별도의 전송 레이어를 갖는 통신 모듈:
>X
CP Basic - www.vector.com/xcp-driver에서 무료로 다운로드할 수 있으며, XCP의
기본 기능만 갖추고 있다. XCP 프로토콜의 구성과 전송 레이어의 수정은 소스코드에서
수작업으로 한다. XCP 베이직을 사용할 때에는 코드를 프로젝트에 직접 통합시켜야
한다.
>X
CP Professional - ASAM 규격에 따른 유용한 확장툴들을 갖추고 있으며, 툴을 이용한
구성도 지원한다. 벡터의 CANbedded 베이직 소프트웨어용으로 판매된다.
>M
ICROSAR XCP - XCP 프로의 기본 기능을 갖추고 있으며, AUTOSAR 규격을 기반으로
하고 있다. 벡터의 MICROSAR 소프트웨어용으로 판매된다.
서비스
> 프로젝트에서 XCP 사용에 대한 컨설팅
> XCP와 ECU의 통합(Integration)
교육 (독일 본사 교육)
> "XCP Fundamentals Seminar"에서는 이 프로토콜의 기본 메커니즘과 모델에 대해 학습할
수 있음.
> "CANape with XCP on FlexRay Workshop"에서는 FlexRay의 기초와 XCP on FlexRay의
특수성, 특히 대역폭의 동적 관리에 대해 학습할 수 있음.
Appendix - 벡터의 XCP 솔루션 113
CANape를 이용한 XCP 특별 지원

CANape는 XCP 1.0 규격을 지원하는 최초의 MCD 툴이었으며, 또한 시장에서 XCP on FlexRay
마스터 기능을 최초로 제공했다.
XCP on FlexRay의 특수 기능 중 하나는 동적인 대역폭 관리(bandwidth management)

기능이다. 여기서 CANape는 FlexRay 클러스터에서 XCP 용으로 제공하는 대역폭을
식별하고, 이 대역폭을 일시적인 어플리케이션 데이터 트래픽에 동적으로 그리고 매우
효율적으로 할당한다. 그래서 사용 가능한 대역폭은 XCP 통신에 최적화시켜 사용하게 된다.
더욱이, CANape는 DLL 인터페이스를 가진다. 이 인터페이스는 원하는 (사용자가 정의한)

전송 레이어에서 XCP를 지원할 수 있다. 이를 이용해 원하는 시험기기나 고유 프로토콜을
CANape에 통합시킬 수 있다. 코드 발생기는 이런 드라이버용으로 XCP용 코드를 생성할
수 있도록 지원한다.
114 색인
색인
A F
A2L 9, 10, 25, 33, 35, 39, 40, 41, 52, FIBEX 51, 52, 53
53, 57, 58, 63, 65, 66, 67, 68, 69, Flash memory 16, 17, 56, 57, 58, 59, 62
70, 88, 102, 103, 108 FLX_CHANNEL 52
Address extension 29, 33, 38, 101, 103 FLX_LPDU_ID 52
AML 25, 68, 108 FLX_SLOT_ID 52
ASAM 7, 8, 9, 55, 108 Fullpassing 92
ASAP2 Tool-Set 70
G
B GET_CAL_PAGE 25, 57
Bandwith optimization 34 GET_DAQ_PROCESSOR_INFO 44, 60, 71
Bus load 34
BYP 108 H
Bypassing 44, 92, 93, 94 HIL 86, 89, 90, 91
C L
CAN 7, 8, 14, 24, 29, 33, 38, 45, 46, 47, Linking 74, 88
51, 69, 94, 108 LPDU 52
CAN FD 48
CANape 95 M
CANoe 95 MIL 87
CANoe.XCP 95 MTA 30, 108
CCP 7, 8, 39, 45, 108
CMD 20, 25, 52, 108 O
Compiling 95 ODT 37, 38, 39, 40, 42, 43, 44, 60,
CTO 20, 21, 22, 25, 108 71, 108
CTR 54, 55, 108 OFFSET 52
CYCLE_REPETITION 52
P
D PAG 108
DAQ 22, 32, 33, 34, 35, 36, 37, 38, Page 95
39, 40, 41, 42, 43, 44, 60, 62, 71, PGM 108
93, 94, 100, 102, 108 PID 8, 19, 21, 25, 42, 108
DBC 45 Polling 33, 34, 36
DOWNLOAD 30, 31, 61
DTO 20, 21, 22, 33, 37, 38, 42, 108 R
RAM 16, 17, 18, 30, 31, 37, 38, 39,
E 58, 62, 74, 76, 79, 80, 82
ECU 9, 68, 90, 92, 93, 108 Reboot 32
EEPROM 16, 31, 62 RES 20, 21, 28, 52, 108
ERR 20, 25, 28, 108
EV 29, 108
Event 35, 39, 41, 60, 62, 71, 102
색인 115
S
Segment 57, 58
SEGMENT_NUMBER 57
SERV 29, 108
SET_CAL_PAGE 25, 57
SHORT_UPLOAD 30, 33, 61
SIL 86, 88
STIM 33, 41, 42, 44, 60, 71, 93,
94, 95, 108
Stimulation 29, 63, 95
T
Task 102
TCP/IP 53, 54, 108
U
UDP/IP 53, 54, 108
USB 55, 108
V
VN8900 95
VX 94
VX1000 95
Get more Information!
웹사이트에 더욱 상세한 정보가 있습니다.
> 뉴스
> 제품 정보
> 데모 소프트웨어
> 교육 일정
> 문의처
www.vector.com
V 2.0 9/2014

XCP ReferenceBook V2.0 KO

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XCP ReferenceBook V2.0 KO

Uploaded by

Copyright:

Available Formats

XCP - ECU 개발을 위한

프로토콜 기초와 응용분야

Andreas Patzer | Rainer Zaiser

Andreas Patzer, Rainer Zaiser

1.1 XCP 프로토콜 레이어 19

1.3 DTO 교환 - 동기화 데이터 교환 32

1.4 XCP 전송 레이어 45

1.5 XCP 서비스 56

2.1 XCP 슬레이브를 위한 A2L 파일 설정하기 68

3.1 플래시 파라미터 74

4.1 MIL: Model in the Loop 87

먼저, XCP에 대한 기본개념은 다음과 같다.

이에 대한 기본 개념을 가시화하기 위해, 먼저 ECU와 그 안에서 구동되는 소프트웨어를

이제 ECU가 모든 연산 사이클(Computation cycle)에 대해 어떤 거동을 하는지 볼 수 있다고

XCP는 전반적인 개발 프로세스에서 어떤 기여를 하고 있을까? 개발자는 특정 개발 단계

중점이 되는 것은 알고리즘 프로세스의 평가에 있다. 예를 들어, 매스웍스(MathWorks)의

프로세스의 상세 분석과 파라미터 변경을 통한 최적화이다.

다음과 같은 일반화가 성립될 수 있다. 알고리즘은 실행 가능한 형태(코드 또는 모델 기술)

일반적으로 런타임 환경의 종류와 통신형태는 서로 상당히 다르다. 그 이유는 이런 런타임

XCP는 ASAM 표준으로 2003년 버전 1.0이 출시되었다. ASAM은 "자동화 및 측정 시스

XCP는 ASAM 인터페이스 모델에 기반하여 정의된다. 다음 그림은 측정/캘리브레이션 툴의

ASAM MCD 3MC

Measurement and ASAM

인터페이스 1: ECU와 측정/캘리브레이션 시스템 간의 "ASAM MCD-1 MC"

인터페이스 2: "ASAM MCD-2 MC" A2L ECU 기술 파일(Description file)

인터페이스 3: "ASAM MCD-3 MC" 자동화 인터페이스

XCP는 마스터-슬레이브(Master-Slave) 원칙에 기반을 두고 있다. 여기서 ECU는 슬레이브

전체 개발 프로세스에서 데이터와 설정 값에 액세스하기 위해서는 모든 런타임 환경에서

앞에서 설명한 이론적인 것들을 오늘날 어디까지 구현할 수 있을까? 모든 것이 가능하

이 책에 사용된 스크린샷 이미지는 벡터사의 CANape 측정/캘리브레이션 툴에서 캡처하였다.

ASAM 인터페이스 모델의 인터페이스 1에서는 슬레이브와 마스터 간에 명령어 및 데이터

CAN Ethernet FlexRay SxI USB ...

그림 4: XCP 프로토콜의 프로토콜 레이어와 전송 레이어 구분

또한, 전송 레이어에 따라 XCP on CAN, XCP on Ethernet 등으로 구분할 수 있다. 새로

이 프로토콜을 설계하는 데 있어서 최우선의 원칙은 다음과 같다.

XCP의 핵심 기능은 슬레이브의 메모리에 읽기/쓰기 액세스가 가능하다는 점이다.

사용자는 읽기 액세스를 통해 ECU 내부 파라미터의 응답시간을 측정할 수 있다. ECU는

사용자는 쓰기 액세스를 이용해 슬레이브에서 알고리즘의 파라미터를 최적화시킬 수 있

ECU에서XCP 슬레이브를 반드시 사용할 필요는 없다. 모델 기반의 개발 환경이나 HIL/SIL

ECU에 대한 읽기/쓰기 액세스를 이용해 어떻게 알고리즘을 최적화시키고 또 여기에 어떤

오늘날, 플래시 메모리는 보통 ECU용 마이크로컨트롤러 칩에 통합시키거나 코드 및 데이

플래시 메모리의 수명은 제한되어 있는데, 보통 소거 사이클의 최대 수로 표시한다(기술에

이러한 소거 루틴이 여러 차례 반복되면, 절연 레이어(터널 산화막: Tunnel Oxide Film)

RAM(Random Access Memory)은 영구적인 전원공급을 해야 하며, 전원이 끊길 경우

한 가지 확실한 것은 런타임에서 파라미터를 수정할 필요가 있다면, 이 파라미터를 RAM에

어플리케이션에서 y 파라미터는 센서값 x를 통해 계산했다.

이 어플리케이션이 ECU에서 플래싱 되면, 컨트롤러는 부팅 후에 이 코드를 다음과 같이

파라미터 y를 계산한다. 값 a와 b는 각각 인수(factor)와 오프셋(offset) 값인데, 플래시 메

예제에서 오프셋값 b와 인수 a가 특정 차량에 종속되는 경우, a 값과 b 값은 반드시 해

ECU의 정상적인 동작 모드에서는 어플리케이션이 플래시 메모리에서 구동한다. 객체 각각

메모리 내용에 대한 읽기/쓰기 액세스는 XCP 프로토콜의 메커니즘을 이용하면 가능하

여기서 두 가지 중요한 질문이 제기된다.

첫 번째 질문에 대한 답은 제2장 "ECU 기술 파일 A2L"에서 다루고 있으며, 캘리브레이션

1.1 XCP 프로토콜 레이어

다음 그림에서, 메시지 일부가 붉은색으로 표시되어 있다. 이는 현재의 XCP 프레임을

XCP Message (Frame)

XCP Header XCP Packet XCP Tail

Identification Timestamp Data

XCP 패킷 자체는 사용한 전송 프로토콜과 독립적이며, 항상 "식별 필드(Identification

다음 개요는 어떤 PID가 정의되었는지 보여 주고 있다.

PID for frames PID for frames

0xFF 0xFF RES

ODT number ODT number