xcp - ecu 개발을 위한 표준 프로토콜 · 2018-10-05 · ethernet 표준을 통해...

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.1XCP명령어구조 22 1.2.2CMD 25 1.2.3RES 28 1.2.4ERR 28 1.2.5EV 29 1.2.6SERV 29 1.2.7슬레이브의캘리브레이션파라미터 29

1.3 DTO 교환 - 동기화 데이터 교환 32 1.3.1측정방법:폴링vsDAQ 33 1.3.2DAQ측정방법 34 1.3.3STIM캘리브레이션방법 41 1.3.4DAQ와STIM에대한XCP패킷주소지정 42 1.3.5바이패싱=DAQ+STIM 44

1.4 XCP 전송 레이어 45 1.4.1CAN 45 1.4.2CANFD 48 1.4.3FlexRay 50 1.4.4Ethernet 53 1.4.5SxI 55 1.4.6USB 55 1.4.7LIN 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.7XCP의보안메커니즘 63

2 ECU 기술 파일 - A2L 65

2.1 XCP 슬레이브를 위한 A2L 파일 설정하기 682.2 수동으로 A2L 파일 생성하기 692.3 A2L 컨텐츠 vs ECU 구현 70

3 캘리브레이션 개념 73

3.1 플래시 파라미터 743.2 RAM 파라미터 763.3 플래시 오버레이 783.4 플래시 오버레이의 동적 할당 793.5 각 AUTOSAR에 대한 RAM 포인터 기반의 캘리브레이션 개념 80 3.5.1단일포인터개념 80 3.5.2이중포인터개념 823.6 플래시 포인터 기반의 캘리브레이션 개념 83

4 XCP의 어플리케이션 영역 85

4.1 MIL: Model in the Loop 874.2 SIL: Software in the Loop 884.3 HIL: Hardware in the Loop 894.4 RCP: Rapid Control Prototyping 914.5 바이패싱 924.6 가상 ECU로 반복 사이클 단축 95

5 XCP 구현 사례 99

5.1 함수 설명 1025.2 드라이버에 대한 파라미터 생성 104

저자 106약어 표 108참고자료 109웹주소 109그림 목차 110Appendix - 벡터의 XCP 솔루션 112색인 114

7서론

서론

최적화된ECU의파라미터화(캘리브레이션)에서는시스템런타임도중파라미터값을캘리

브레이션하고동시에측정한신호를얻는다.개발툴과ECU사이의물리적접속은측정/

캘리브레이션프로토콜을통해이루어지며XCP가이러한표준으로자리잡았다.

먼저,XCP의기초와메커니즘에대해간단하게설명한다음,적용분야및캘리브레이션

추가값에대해논의해보기로한다.

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

>XCP는"UniversalMeasurementandCalibrationProtocol"을뜻한다.여기서"X"는가

변적이고교환가능한전송레이어를의미한다.

>ASAM(AssociationforStandardisationofAutomationandMeasuringSystem)에서XCP를

표준화했다.ASAM은자동차OEM업체,부품업체,툴공급업체들로구성되어있다.

>XCP는CCP(CANCalibrationProtocol)를승계하는프로토콜이다.

> CCP의컨셉은CAN을통해내부ECU데이터에액세스하여읽기/쓰기를허용하는것이었다.

XCP는CAN외에도다양한전송매체를통해이러한컨셉을구현하기위해개발되었다.

이러한XCP의예로는XCPonCAN,XCPonFlexRay,XCPonEthernet이있다.

> XCP의주요사용목적은내부ECU파라미터의측정/캘리브레이션이다.이프로토콜은

ECU에서의처리를위한"이벤트동기화(Eventsynchronous)"측정값을얻을수있도록

해준다.이에따라상호간에사용하는데이터의일관성이보장된다.

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

하나의블랙박스로간주해보기로하자.이블랙박스에서는ECU로들어가는입력값(예:

CAN메시지와센서값)과ECU에서나오는출력값(예:CAN메시지와액추에이터드라이

브)만얻을수있다.내부알고리즘의처리에대한구체적인내용은바로확인할수없으

며,입출력데이터분석을통해서만확인할수있다.

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

가정하자.언제든알고리즘이구동되는방식에대해상세한정보를얻을수있을것이다.

ECU는더이상블랙박스가아니라내부프로세스를환히들여다볼수있는화이트박스가

되었다.이게바로XCP가하는일이다.

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

에서특정기능을확인하려면해당코드를반복적으로실행해야한다.이런방법으로개발

자는해당알고리즘이어떻게작동하는지어떻게최적화시켜야하는지를확인한다.

여기서는컴파일한코드가특정하드웨어에서구동되든지,모델기반방식으로개발되어이

어플리케이션이해당모델에서만구동된다든지하는것은문제가되지않는다.

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

시뮬링크(SimuLink)와같은특정개발환경에서이알고리즘이하나의모델로구동되고,

개발자가이어플리케이션을통해중간결과를즉각적으로얻을수있다면,다른변경

사항에대한결과를얻는데에도도움이될것이다.최종분석에서는이방법이파라미터

에대한읽기액세스를제공하는정도로모델을가시화하고분석할수있게된다.그리고

이모든것이모델런타임이나시간을제한한테스트가완료된후소급해서이루어지게

된다.예를들어PID컨트롤러의비례컴포넌트(Proportionalcomponent)를변경하여제어

하는시스템의알고리즘거동에적응하도록하는경우처럼파라미터가변경될때에는쓰기

액세스도필요하게된다.어플리케이션을어디서실행하던지간에,중요한것은항상알고리즘

8 서론

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

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

로존재할수있다.각기다른시스템을런타임환경(시뮬링크또는PC,래피드프로토타이

핑플랫폼,ECU등의DLL)으로사용할수있다.프로세스흐름(Processflow)은데이터에

대한읽기액세스와시간에따른흐름정보를이용해분석한다.파라미터세트는알고리즘

을최적화시키기위해반복해서수정한다.일반화를단순화시키기위해데이터획득은PC

기반의툴을이용해표면화시킬수있지만,여기서한가지이해해야할것은런타임환경

자체에서도분석능력을제공할수있다는점이다.

그림 1:

런타임 환경을 이용한

기초 통신

Application

Operating System

Runtime Environment

CommunicationPC Tool

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

환경들이서로다른제작자에의해개발되었으며,솔루션에대해상이한접근법을택하고

있기때문이다.서로다른형태의프로토콜,구성,측정데이터포맷등은모든개발단계

에서파라미터세트와결과를교환하고자하는모든노력을수포로만들고있다.그러나

결국에는이러한솔루션모두가런타임에서읽기/쓰기액세스수준으로단순화될것이다.

그리고이미이에대한표준이나와있다.바로XCP이다.

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

템표준화협회(Association for Standardisation of Automation and Measuring System)"

의약자이다. ASAM워킹그룹은차량부품업체, OEM업체,툴공급업체를모두대변한다.

XCP 워킹그룹의 목적은 특정한 전송매체에서 독립적으로 사용할 수 있는 일반화된

측정/캘리브레이션프로토콜을정의하는것이다.CCP(CANCalibrationProtocol)개발에서

얻은경험도이러한개발에활용되고있다.

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

XCP슬레이브와기술파일(descriptionfile)에대한인터페이스와보다고차원의자동화시

스템에대한접속을보여주고있다.

9서론

Measurement andCalibration System

ASAM MCD 3MC

ASAM MCD 1MC

ASAM

MCD 2MC *.a2L

ECU Description File

Upper LevelAutomation System

ECU

XCP Driver

XCP Driver

그림 2:

ASAM의 인터페이스

모델

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

이인터페이스는물리적부분및각프로토콜별부분을설명한다.엄격하게말하자면,여

기인터페이스ASAP1a와ASAP1b사이를구분해야한다.그러나ASAP1b인터페이스는지

금까지널리채택된적도없었고실용화된적도없었기때문에오늘날에는거의사용되지

않는다.XCP프로토콜은융통성이많으므로실질적으로제조사별일반적인인터페이스의

역할을하고있다.예를들어,오늘날모든측정/캘리브레이션하드웨어제조사들은XCPon

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)가된다.슬레이브는한번에하나의

마스터와만통신할수있는있지만마스터는동시에여러개의슬레이브와통신할수있다.

그림 3:

XCP 마스터는 여러

개의 슬레이브와 동시에

통신을 할 수 있다.

Bus

Master

SlaveSlave Slave Slave

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

XCP가사용돼야한다.이로써구매하고운용및유지해야하는툴의수를줄일수있다.

또한,한툴에서다른툴로설정값을수동으로복사할필요도없어지는데사실이프로세

스에서오류가발생하기쉽다.XCP는반복루프를단순화시켜뒷단계의작업과정에서얻은

결과를앞단계로전송할수도있다.

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

다!XCP솔루션은이미다양한작업환경에서사용되고있다.이책은측정/캘리브레이션

프로토콜의주요특성을설명하고다양한런타임환경에서어떻게사용할수있는지를

소개한다. 이 책에서 찾을 수 없는 내용은 다음과 같다. 구체적인 XCP 전체 규격은

나와있지않다.또한,특정런타임환경에서XCP드라이버를어떻게통합시키는지에대한

설명도없다.이책에서는개별적인프로토콜이나구체적인구현방법을소개하지는않는다.

Appendix에있는인터넷링크는공개적으로구할수있는XCP드라이버소스코드와샘

플에관한것이다.이를이용하여어떻게이프로토콜을구현할수있을지이해할수있

을것이다.

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

A2L파일을어떻게생성하는지와같은다른프로세스흐름도CANape를이용해서설명하고

있다.벡터웹사이트의다운로드센터에서CANape데모버전을무료로다운로드할수있다.

(www.vector.com/canape_demo)

11서론

131 XCP 프로토콜의 기초


14 1 XCP 프로토콜의 기초

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

송수신에대해설명하고있다.특정물리적전송레이어로부터독립성을유지하기위해

XCP는프로토콜레이어와전송레이어를구분하고있다.

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

CAN Ethernet FlexRay SxI USB ...

또한,전송레이어에따라XCPonCAN,XCPonEthernet등으로구분할수있다.새로

운전송레이어로확장할수있는능력은이미2005년XCPonFlexRay를선보일때증

명된바있다.XCP프로토콜의현행버전은버전1.1로2008년에승인받았다.

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

>ECU내에서최소자원사용

>효율적인통신

>심플한슬레이브구현

>소수의파라미터만으로플러그앤플레이구성

>확장성


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

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

독립적인시간거동을하는시스템으로그파라미터는특정시간간격에서만변경할수

있다.즉,프로세서가값을계산해서RAM에업데이트하는시간을뜻한다.XCP의최대

강점중하나는ECU내에서프로세스흐름이나이벤트와동시적으로변화하는RAM에서

측정값을구할수있다는점이다.사용자는이기능을통해ECU에서시간의존적인프로

세스흐름과변화하는값의직접적인관계를평가할수있다.이를이벤트-동기화측정

(event-synchronousmeasurement)이라고부른다.관련메커니즘은후에상세하게설명

하도록하겠다.

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

다.이러한액세스는주소를기반으로한다.즉,마스터와슬레이브간에통신할때메모리

에있는주소를참고로한다.그러므로파라미터의측정은기본적으로마스터가슬레이브

에다음과같이요청함으로써구현된다."메모리위치0x1234의값을보내주시오."특정

파라미터의캘리브레이션,즉슬레이브에대한쓰기액세스란"주소0x9876에있는값을

5로설정하시오."라고하는것을말한다.

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

환경,또는JTAG나NEXUS,DAP와같은인터페이스를디버깅해ECU메모리에액세스

하는데사용하는하드웨어인터페이스등과같은다른환경에서구현할수도있다.

그림 5:

XCP 슬레이브는

다양한 런타임

환경에서 사용할

수 있다.

Slave

Slave

Slave

Slave

Slave

PC

XCP Measurement/Calibration Hardware*

* Debug Interfaces, Memory Emulator, ...

HIL/SIL Systems

EXE/DLL

Prototype orECU Hardware

Simulink

Master


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

장점이있을까?ECU내의런타임에서개별적인파라미터를수정할수있으려면먼저이에

액세스해야한다.그러나모든유형의메모리가이러한프로세스를허용하지는않는다.이

기능은단지RAM에있는(여기서는의도적으로EEPROM은제외함)메모리주소에읽기/

쓰기액세스를하는것뿐이다.다음은각메모리기술의차이점을간단하게요약한것이다.

이에대한지식은본책자의나머지내용을이해하는데매우중요하다.

메모리 기초

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

터를전원공급없이도장기적으로저장하기위한목적으로사용하고있다.플래시메모리

의특성은개별바이트에대한읽기/쓰기액세스가언제든지가능하지만,새로운내용을

쓸때에는상당히큰블록단위로만가능하다는점이다.

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

따라최대수는100만번까지될수도있다).이는쓰기사이클의최대수로해도마찬가

지인데,왜냐하면메모리에서는다시쓰기전에먼저블록위로소거해야하기때문이다.

그이유는메모리구조이다.전자는터널다이오드를통해"펌핑"된다.비트하나는메모리

위치에다음과같이저장된다.전자가전기적으로절연된레이어를거쳐메모리위치로

전송된다.일단전자가절연레이어뒤에놓이게되면,전하로인해전기장이발생하는데,

이것을메모리위치에서는1로읽히게된다.레이어뒤에전자가없는경우에는셀정보

가0으로해석된다.사실1은이런방법으로설정되지만,0은다르다.0을결정하는것(=1

을소거하는것)은별도의소거루틴을이용하는데,이때절연레이어뒤에있던전자가

방전된다.그러나구조적인이유로이러한소거루틴은한바이트에대해서는작동하지

않고그룹이나블록단위로작동한다.아키텍처에따라보통128바이트의블록이나256

바이트의블록이사용된다.이런블록내에서한바이트만오버라이트하고자하는경우

에는블록전체를먼저소거해야한다.그다음에블록의내용전체가다시쓰이는것이다.

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

가파손될수있다.이말은전자가서서히새어나가시간이지남에따라들어있는정보

중일부가1에서0으로바뀔수있다는뜻이다.그러므로ECU에서는허용가능한플래시

사이클의수가극히제한되어있다.ECU를양산할때보통한자릿수로지정하기도한다.

이러한제약은플래시부트로더(FlashBootLoader)가감시하는데,이루틴은지금까지

수행한플래싱작업의수를기록해둔다.지정된수를넘어가게되면,플래시부트로더는

더이상의플래싱요청을거부한다.

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

에는내용이사라진다.플래시메모리는어플리케이션을장기적으로저장하는목적으로

사용되지만,RAM은계산한데이터나기타임시적인정보를잠시저장하는데사용된다.

전원공급을끌경우,RAM의내용이사라진다.플래시메모리와는반대로,RAM에읽거나

쓰기는쉽다.


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

싣도록해야한다는것이다.이를이해하는것은매우중요하다.다음예제를통해ECU에

서어플리케이션을어떻게실행하는지알아보기로하자.

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

//Pseudo-coderepresentation

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가플래시메모리

의어디에놓이는지는컴파일러/링커를구동해서설정한다.이위치는객체에고유주소

(uniqueaddress)가할당되는곳이다.객체명과데이터유형,주소사이의관계는링커-

맵(Linker-map)파일에기록되어있다.링커-맵파일은링커를구동해서생성하며,다른

포맷으로도존재할수있다.그러나모든포맷에공통된사항은최소한객체명과주소는

포함하고있어야한다는것이다.

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

당차량의특정조건에따라개별적으로조정하도록해야한다.즉,알고리즘은그대로지

만파라미터값은차량에따라바뀔수있다는뜻이다.

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

에대한쓰기액세스는허용되지않는다.이말은플래시영역에위치한파라미터값은런

타임에서수정할수없다는뜻이다.런타임중파라미터값을수정할수있다면,이수정

된파라미터는플래시메모리가아니라RAM에위치해야한다.이제이파라미터와그초

깃값을어떻게RAM으로옮길수있을까?RAM에동시에저장할수있는파라미터수보

다많은수의파라미터를수정해야하는문제를어떻게풀수있을까?이문제를다루려

면캘리브레이션의개념을알아야한다(제3장참조)


XCP 기초 요약

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

다.이런액세스는주소를기반으로이루어진다.읽기액세스는RAM에서파라미터를측

정할수있도록하며,쓰기액세스는RAM의파라미터를캘리브레이션할수있도록한다.

XCP는ECU에서측정을이벤트에동기화시켜실행할수있도록한다.이에따라측정값

들은서로연관성을갖게된다.측정을재시작할때마다측정할신호를임의로선택할

수있다.쓰기액세스에서캘리브레이션할파라미터는RAM에저장해야한다.이때문에

캘리브레이션개념이필요하다.

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

>XCP프로토콜사용자가RAM에서측정/캘리브레이션파라미터의정확한주소를알수

있을까?

>캘리브레이션개념이란무엇일까?

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

개념에대해서는제3장에서다루고있다.

191.1 XCP 프로토콜 레이어


XCP데이터는마스터와슬레이브사이에메시지방식으로교환된다."XCP메시지프레임"

전체는 전송 레이어의 프레임에 포함된다(XCP on Ethernet의 경우에는 UDP 패킷

내의UDP).이프레임은XCP헤더와XCP패킷,XCP테일의세부분으로구성되어있다.

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

보내는데사용된다.XCP헤더와XCP테일은전송프로토콜에의존한다.

그림 6: XCP 패킷

XCP Header

XCP Message (Frame)

XCP Packet

PID

IdentificationField

TimestampField

Data Field

FILL DAQ TIMESTAMP DATA

XCP Tail

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

Field)"와"타임스탬프필드",그리고현재데이터필드인"데이터필드"등세개의컴포

넌트로이루어진다.식별필드는패킷식별자(PID)로시작하는데,PID는패킷을식별하는

데사용한다.

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

0xFF

CMD

PID for frames from Master to Slave

PID for frames from Slave to Master

absolute or relative ODT number for STIM

0xC0

0xBF

0x00

....

....

absolute or relative ODT number for STIM

0xFF

0xFE

0xFD

0xFC

RES

ERR

EV

SERV

0xFB

0x00

....

그림 7: XCP 패킷 식별자(PID) 개요


XCP패킷을통한통신은명령어(CTO)를위한영역하나와동기화데이터(DTO)발송을

위한영역하나로구분된다.

XCP Master

XCP Slave

CMD SERVRES ERR EVCTO

STIMDTO

Command / Response / Error / Event /Service Request Processor

DAQProcessor

STIMProcessor

DAQ STIMPGM CAL

BypassXCP Handler

Resources

DAQ

XCP Driver

그림 8:

CTO/DTO를 이용한

XCP 통신 모델

여기서사용한약어는다음과같다:

CMD CommandPacket 명령어전송

RES CommandResponsePacket 긍정적응답

ERR Error 부정적응답

EV EventPacket 비동기이벤트

SERV ServiceRequestPacket 서비스요청

DAQ DataAcQuisition 주기적인측정값전송

STIM Stimulation 슬레이브의주기적인신호인가

명령어는 CTO(Command Transfer Object)를 통해교환된다. 예를들어, 마스터는이

방법으로접촉을시작한다.슬레이브는CMD에대해항상RES나ERR로응답해야한다.

다른 CTO 메시지는 비동기적으로 전송된다. DTO(Data Transfer Object)는 측정/신호

인가데이터를동기적으로교환하는데사용된다.


1.1.1 식별 필드

그림 9:

메시지 식별

XCP Packet

PID

Identification Field


메시지를교환할때마스터와슬레이브는모두상대방이어떤메시지를보냈는지확인

할수있어야한다.이는식별필드를이용해확인할수있다.이때문에각각메시지는

패킷식별자(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 타임스탬프

그림 10:

타임스탬프

XCP Packet

TIMESTAMPPID FILL DAQ DATA

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

슬레이브는측정값에시간정보를담기위해타임스탬프를사용한다.즉,마스터는측정값

만을갖는것이아니라측정값을획득한시점도가진다.측정값이마스터에도달하는데

걸린시간은더이상중요하지않은데,왜냐하면측정값과시점의관계가슬레이브에서

직접오기때문이다.

슬레이브에서타임스탬프를전송하는것은선택사항이다.이주제에대해서는ASAMXCP

파트2프로토콜레이어규격에서더자세히다루고있다.


1.1.3 데이터 필드

그림 11:

XCP 패킷의

데이터 필드

XCP Packet

DATA

Data Field

PID FILL DAQ TIMESTAMP

마지막으로, XCP 패킷에는데이터필드에저장된데이터도들어있다. CTO 패킷의

경우,데이터필드에는상이한명령어에대한특정파라미터가들어있다.DTO패킷에는

슬레이브에서보낸측정값과마스터에서이값을보낸시점이들어있다.

1.2 CTO 교환

CTO는마스터에서슬레이브로명령을보내거나슬레이브에서마스터로응답을보낼때

사용한다.

1.2.1 XCP 명령어 구조

슬레이브는마스터에서명령을수신하고그에따라긍정적또는부정적응답을보내야

한다.여기서는통신구조가항상같다.

명령어(CMD):

위치 종류 설명

0 BYTE CommandPacketCodeCMD

1..MAX_CTO-1 BYTE CommandspecificParameters

각명령어에는고유번호가할당된다.또한,명령어와함께다른특정파라미터를보낼수

도있다.파라미터의최대수는여기서MAX_CTO-1로정의된다.MAX_CTO는CTO패킷의

최대길이를바이트로나타낸것이다.

긍정적응답:


0 BYTE CommandPositiveResponsePacketCode=RES0xFF


231.2 CTO 교환

부정적응답:


0 BYTE ErrorPacketCode=0xFE

1 BYTE Errorcode


특정파라미터를긍정적응답뿐아니라부정적응답과함께보조정보로전송할수도

있다.한예로마스터와슬레이브간의접속을들수있다.마스터와슬레이브사이에

통신을시작할때마스터는슬레이브로접속요청을보내며,슬레이브는이때지속적인

점대점(Point-to-point)접속을만들기위해긍정적으로응답해야한다.

마스터à슬레이브:접속

슬레이브à마스터:긍정적응답

접속명령어:


0 BYTE CommandCode=0xFF

1 BYTE Mode

00=Normal

01=userdefined

모드00은마스터가슬레이브와XCP통신을원한다는뜻이다.마스터가접속을할때

0xFF0x01을사용하면,마스터는슬레이브에게XCP통신을요청하고있는것이다.동시

에,마스터는슬레이브에게특정한사용자정의모드로전환할것을통지한다

슬레이브의긍정적응답:


0 BYTE PacketID:0xFF

1 BYTE RESOURCE

2 BYTE COMM_MODE_BASIC

3 BYTE MAX_CTO,MaximumCTOsize[BYTE]

4 WORD MAX_DTO,MaximumDTOsize[BYTE]

6 BYTE XCPProtocolLayerVersionNumber(가장중요한바이트만)

7 BYTE XCPTransportLayerVersionNumber(가장중요한바이트만)

슬레이브의긍정적응답에서는좀더광범위한형태를가정하고있다.슬레이브는접속을

할때이미마스터로통신에특정한정보를보냈다.예를들어RESOURCE는슬레이브가

페이지스위칭과같은기능을지원하는지,XCP를통해플래싱이가능한지등의정보를제

공하는것이다.슬레이브는MAX_DTO를사용해서측정값전송시지원이가능한최대패

킷길이등을마스터에게보낸다.이파라미터에대한보다자세한내용은ASAMXCP파

트2프로토콜레이어규격에서찾을수있다.


XCP는마스터와슬레이브사이에명령어와반응을교환하는데사용하는세가지모드

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

그림 12: XCP 프로토콜의 세 가지 모드: 표준 모드, 블록 모드, 인터리브 모드

Time

Master Slave

Time

Master Slave

Time

Master Slave

Standard Mode Block Mode Interleaved Mode

Request k+1

Response k

Response k+1

Request k

Response k

Request k+1

Response k+1

Request kPart1

Part3

Part2

Part1

Part2

Part3

Request k

Request k+1

Response k

Response k+1

MIN_ST

MAX_BS

표준통신모델에서는슬레이브로보내는각각의요청에대해하나의응답이전달된다.

XCPonCAN의경우를제외하면,마스터에서보낸하나의명령어에대해여러개의슬레

이브가반응하는것을허용하지않는다.그러므로각XCP메시지는항상특정한슬레이브

로추적해갈수있다.이모드는통신에서표준으로사용된다.

블록전송모드는선택사항이며,대규모데이터전송시(예:업로드나다운로드)시간을

절약할수있다. 그러나이모드에서는슬레이브방향의성능문제를고려해야한다.

그러므로두개의명령어사이의최소시간(MIN_ST)을유지해야하며,총명령어수의

상한선은MAX_BS를넘지않도록해야한다.선택사항으로마스터는GET_COMM_MODE_

INFO를이용해슬레이브에서통신설정값을읽을수있다.블록전송모드에서마스터

방향으로전송할때는앞에서언급한한계를따를필요가없는데,PC의성능이거의항상

마이크로컨트롤러에서데이터를수신하기에충분하기때문이다.

인터리브모드는또한성능상의이유로제공된다.그러나이방법은선택사항으로블록

전송모드와달리실제로적용하기에는적합하지않다.

251.2 CTO 교환

1.2.2 CMD

그림 13: CTO 패킷 구조의 개요

XCP CTO Packet

PID DATA

Data FieldIdentification Field

Timestamp Fieldempty for CTO

마스터는CMD를통해슬레이브에일반적인요청사항을보낸다.PID(패킷식별자)필드에는

명령어의식별번호가실려있다.데이터필드로는추가적인특정파라미터가전송된다.

그다음에마스터는슬레이브가응답이나오류메시지를보내기를기다린다.

또한, XCP는구현하는데확장성이높아서모든명령어를구현할필요가없다. A2L

파일에는 XCP IF_DATA라는 CMD들이열거되어있다. A2L 파일의정의와슬레이브에

서구현된내용에차이가있는경우,마스터는슬레이브의반응에따라슬레이브가해당

명령어를지원하는지를확인할수있다.마스터가슬레이브에서구현하지않은명령어

를보낸경우에는슬레이브가ERR_CMD_UNKNOWN을보내확인하고더이상의조치를

하지않는다.이에따라마스터는해당슬레이브에서선택사항인명령어가구현되지않았

음을신속하게알수있다.

명령어에는다른파라미터도포함되어있다.프로토콜레이어의규격에대한상세한내용은

ASAMXCP파트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

271.2 CTO 교환

주기적데이터교환-기본구성:


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 PacketIdentifier=RES0xFF

1..MAX_CTO-1 BYTE Commandresponsedata

이파라미터에대한보다상세한내용은ASAMXCP파트2프로토콜레이어규격에서

찾을수있다.

1.2.4 ERR

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

보낸다.


0 BYTE PacketIdentifier=ERR0xFE

1 BYTE Errorcode

2..MAX_CTO-1 BYTE Optionalerrorinformationdata

발생가능한오류코드의리스트는ASAMXCP파트2프로토콜레이어규격에서확인할

수있다.

291.2 CTO 교환

1.2.5 EV

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

이항목의구현은선택사항이다.


0 BYTE PacketIdentifier=EV0xFD

1 BYTE Eventcode

2..MAX_CTO-1 BYTE Optionaleventinformationdata

이파라미터에대한보다상세한정보는ASAMXCP파트2프로토콜레이어규격에서

확인할수있다.

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

발송을시작하는XCP슬레이브의거동과는관계가없다.이는오히려특정기능의실패

등과같은문제점을보고하는슬레이브와관련이있다.

1.2.6 SERV

슬레이브는이메커니즘을이용해마스터에게특정서비스를실행하도록요청할수있다.


0 BYTE PacketIdentifier=SERV0xFC

1 BYTE Servicerequestcode

2..MAX_CTO-1 BYTE Optionalservicerequestdata

서비스요청코드표는ASAMXCP파트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장"캘리브레이션개념"참조).그러면변경된파라미터세트를

어떻게해야영구적으로저장할수있을까?

311.2 CTO 교환

기본적으로두가지가능한방법이있다.

A) 파라미터를 ECU에 저장

RAM에있는변경된데이터는예를들어ECU의EEPROM에저장할수있다.이작업은

ECU를램프다운(rampingdown)할때자동으로또는사용자에의해수동으로저장할수

있다.여기서전제조건은데이터를슬레이브의비휘발성메모리에저장할수있어야한다.

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

이벤트동기화에대해설명하기전에,슬레이브에서상호연관데이터(Correlateddata)

를측정한다.여기서는폴링(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는데이터획득(DataAcquisition)을

뜻하며,슬레이브에서마스터로DTO를보내구현할수있다.

1.3.2 DAQ 측정 방법

DAQ방법은폴링의두가지문제를다음과같이해결한다.

>측정값의대비는ECU의이벤트에대한측정값획득과연결하여달성할수있다.모든

계산이완료되었음이확인될때까지측정값을획득하지않는다.

>버스의부하를줄이기위해측정프로세스를2단계로나눈다.구성단계에서는마스터

가슬레이브에게관심있는값이무엇인지문의하고두번째단계에서는슬레이브의측

정값을마스터로바로전송한다.


ECU에서는측정값의획득을프로세스와어떻게연결할까?그림19는ECU내의계산사

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

Calculationcycle n

Calculationcycle n+1

Calculationcycle n+2 time

10 8 6 4 2 0

10 8 6 4 2 0

E1 E1E1

X

Y

Calculate Y = XRead sensor X그림 19:

ECU 내의 이벤트

이제ECU에서일어나는일의순서에대해알아보기로하자.이벤트E1(=계산사이클의

끝)이발생하면,모든파라미터를획득하고계산이행해진다.이는이시점에서모든값이

서로대응하고대비가되어야한다는것을의미한다.또한,지금이벤트-동기화측정방

법이사용되고있다는것을나타내기도한다.이것이바로DAQ메커니즘의도움으로구

현된것이다.슬레이브내의알고리즘이"계산사이클완료"이벤트에도달하면,XCP슬

레이브는측정파라미터값을수집하고수집한값을버퍼에저장한다음마스터로보낸다.

여기서는슬레이브가특정이벤트에대해어떤파라미터를측정해야하는지알고있는것

으로가정했다.

특정이벤트가반드시순환적이고등시적(time-equidistant)인이벤트일필요는없다.예

를들어,엔진컨트롤러의경우에는각동기화(angle-synchronous)가될수도있다.이는

두개의이벤트사이의시간간격을엔진의RPM에의존하도록한다.드라이버에의한스

위치의활성화와같은이벤트는등시적이될수없는이벤트이다.

사용자는신호를선택한다.실제측정객체이외에사용자는측정파라미터에대한하부

이벤트를선택해야한다.이이벤트는물론측정객체를해당이벤트에할당한정보는A2L

파일에저장해야한다.

그림 20:

A2L의 이벤트 정의


정상적인경우에는하나의측정값을여러개의이벤트에동시에할당하는것이아무의미

가없다.일반적으로,하나의파라미터는단지단일사이클내에서만(예:10ms간격에서만)

수정할수있고,여러개의사이클에서는(예:10ms와100ms간격에서)할수없다.

그림 21:

A2L내의 가능한

이벤트에 "Triangle" 할당

그림21은"Triangle"파라미터를원칙적으로1ms,10ms,100ms의이벤트에서측정할

수있다는것을보여주고있다.기본설정값은10ms이다.

측정파라미터는사용자가측정을구성하면서ECU의이벤트에할당한다.

그림 22: 각 측정

파라미터에 대한 이벤트

(측정 모드) 선택

측정한신호를구성한후에사용자는측정을시작한다.XCP마스터는원하는측정파라미

터를DAQ리스트로알려진리스트에열거한다.이리스트에는측정한신호가선택된이벤

트에각각할당되어있다.이구성정보는측정을실제로시작하기전에슬레이브로보낸

다.그러면해당슬레이브는어떤이벤트가발생했을때어떤주소에서데이터를읽어전

송해야하는지알게된다.측정작업을이와같이구성단계와측정단계로배분하는것

은이장을시작할때이미언급한바있다.

이방법은폴링시발생하는두가지문제를모두해결한다.즉,측정도중마스터가각각

의값을폴링할필요가없으므로대역폭을최적화하여사용하고,측정값은상호간에대

비가된다는것이다.


그림 23: DAQ 측정 시 CANape Trace Window의 예

그림23은마스터와슬레이브사이에명령어-응답통신의예를(색으로강조하여)보여주고

있다(전체적으로이작업은상당히광범위하며,여기에는공간상의이유로일부만실었다).

여기에는DAQ구성을슬레이브로보내는것도포함된다.이후에측정시작이촉발되고

슬레이브는요청받은값을보내며,마스터는그냥수신만한다.

지금까지신호의선택은신호명과측정이벤트에대한할당여부로기술했다.정확하게

어떤방식으로구성을XCP슬레이브로전송할수있을까?

이제ECU의메모리구조의관점에서이문제를보기로하자.사용자는신호를선택하

고이를측정하고자한다.그래서신호값을보내는것은메시지전체를사용할필요가

없으므로슬레이브에서나온신호는메시지패킷으로결합한다.슬레이브는이결합의

정의를독립적으로생성하지않는데,그렇지않을경우마스터는메시지를수신할때데이터를

해석할수없을것이다.그러므로슬레이브는이값을메시지에어떻게배분해야하는지에

대한지시를마스터로부터받는다.

슬레이브가해당바이트를메시지에결합하는순서는객체기술테이블(ODT)에정의된

다.주소와객체길이는측정할객체를식별하는데중요하다.ODT는버스를거쳐온

메시지를조립하기위해슬레이브에서RAM의내용을할당한다.이통신모델을따르면,

이메시지는DAQDTO(데이터전송객체)로전송된다.


RAM Cells

ODTaddress, lengthaddress, lengthaddress, lengthaddress, length

...

...

0123

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가

포함되며,이는하나의이벤트에배정된다.

address, length

address, length

address, length

address, length

...

0

1

2

3

address, length

address, length

address, length

address, length

...

0

1

2

3

ODT #0 address, length

address, length

address, length

address, length

...

0

1

2

3

PID=0 0 1 2 3 ...

PID=1 0 1 2 3 ...

PID=2 0 1 2 3 ...

ODT #1

ODT #2

그림 25:

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에나와있다.

DAQ0

DAQ1MIN_DAQ + DAQ_COUNT

ODT_ENTERIES_COUNT

ALLO

C_OD

T

GRANULARITY_ODT_ENTRY_SIZE_DAQ

ODT_COUNT

ALLOC_ODT_ENTRY

ALLOC_DAQ

그림 27:

동적인 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

PID TS


PID

PID

PID

DAQ

DAQ TS

Identification Field Timestamp Field Data Field

그림 29:

DTO 전송을 위한

XCP 패킷의 구조

전송 유형: "절대 ODT값"

절대(absolute)라는의미는해당ODT수가통신전반에걸쳐,즉모든DAQ리스트에서고

유하다는뜻이다.또한,이는절대ODT값을사용한다는것은DAQ리스트에대한소위

"FIRST_PID"를이용하는전환단계를가정한다는뜻이기도하다.

만약어떤DAQ리스트가PIDj로시작한다면,첫패킷의PID는값j를갖고,두번째패킷

의PID값은j+1이되며,세번째패킷의PID값은j+2가되는식이다.슬레이브는자연

적으로FIRST_PID+상대ODT값의합이다음DAQ리스트의PID보다낮도록해야한다.

DAQ리스트:0≤PID≤kDAQ리스트:k+1≤PID≤mDAQ리스트:m+1≤PID≤n등.


이경우,식별필드는매우간단하다:


absolute ODT number

PID그림 30:

절대 ODT값을 가진

식별 필드

전송 유형: "상대 ODT값과 절대 DAQ 리스트 수"

이경우,DAQ리스트수와ODT수는식별필드로전송할수있다.그러나해당정보에

사용할수있는바이트수가남아있다.


PID DAQ

absolute DAQ List number

relative ODT number

그림 31:

상대 ODT 수와

절대 DAQ 수를 갖는

ID 필드(1바이트)

그림에서1바이트는DAQ수로사용할수있으며,1바이트는ODT수로사용할수있다

DAQ리스트의최대수는2바이트를사용해서전송할수있다.


PID DAQ

absolute DAQ list number

relative ODT number

그림 32:

상대 ODT 수와

절대 DAQ 수를 갖는

ID 필드(2바이트)


3바이트를 보내는 것이 불가능하다면, 필 바이트(fill byte) 1개를 추가해서 4바이트로

작업할수있다.


PID FILL DAQ

absolute DAQ list number

for alignement

relative ODT number

그림 33:

상대 ODT 수와 절대

DAQ 수, 그리고 필

바이트를 갖는 ID 필드

(총 4바이트)

이제XCP마스터가슬레이브를어떤방법으로사용하는지어떻게알수있을까?먼저

A2L파일에입력하거나두번째로는어떤통신버전을구현하고있는지슬레이브에요청

하는것이다.

GET_DAQ_PROCESSOR_INFO요청에대한응답은또한슬레이브가어떤전송유형을사

용하고있는지마스터에게통지하는데사용하는DAQ_KEY_BYTE도설정한다.DAQ만사

용하는것이아니라STIM도사용되는경우,마스터는슬레이브가DAQ를위해사용하는

것과같은방법을STIM에사용해야한다.

1.3.5 바이패싱 = DAQ + STIM

바이패싱은DAQ와STIM을함께사용하여구현할수있으며(그림8참조),이는래피드프

로토타이핑솔루션의특수한형태를나타낸다.그러나좀더깊이이해하기위해서는더

욱구체적인내용이필요하므로이방법은제4.5장"바이패싱"을다룰때까지는남겨두도

록하겠다.

451.4 XCP 전송 레이어


프로토콜을설계할때주요한요구사항중하나는다른전송레이어들을지원해야한다는것

이다.이문서를작성할무렵에XCPonCAN과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바이트가어떻게사용되었는가?등과같이기술파일에정의되어

있다.다음그림은이프로세스를보여주고있다.

DataFrame

ID=0x12 Sender Receiver

ID=0x34

ID=0x52 Receiver

Receiver

ReceiverSender

Receiver

Receiver

Sender

Sender Receiver

Sender

Sender

Receiver

Receiver

Receiver

ReceiverID=0x67

ID=0xB4

ID=0x3A5

CANNode A

CANNode B

CANNode C

CANNode D

그림 34:

어떤 버스 노드가

어떤 메시지를

보냈는지에 대한 정의

ID가0x12인메시지가CAN노드A에서발송되었으며,버스상에있는다른모든노드는

이메시지를수신한다.인수시험의프레임워크에서CAN노드C와노드D는이메시지가

필요없다고결론내리고수신을거절했다.반면에CAN노드B는상위레이어에서이

메시지가필요하리라판단하고Rx버퍼를통해보냈다.CAN노드는다음과같이상호

연결된다.


Host

TxBuffer

RxBuffer

CAN Interface

CAN Node A

CAN

Host

Receive

CAN Interface

CAN Node C

Host

Receive

AcceptanceTest

RxBuffer

Send

TxBuffer

CAN Interface

CAN Node D

Host

TxBuffer

RxBuffer

CAN Interface

CAN Node B

AcceptanceTest

Send

RxBuffer

TxBuffer

ReceiveReceive

AcceptanceTest

SendSend

AcceptanceTest

그림 35:

CAN 네트워크의 예

이XCP메시지는통신매트릭스에서기술하고있지않았다!만약이측정값이슬레이브에서

동적인DAQ리스트를통해예를들어XCP의도움을받아발신된것이라면,이메시지는

사용자가선택한신호에따라조립된다.신호선택이변경되는경우에는메시지내용도

마찬가지로 변경된다. 그러나 통신 매트릭스와 XCP 사이에는 관계가 있다. 즉, CAN

식별자는XCP메시지를CAN을통해전송해야할필요가있다.사용한CAN식별자의수를

최소화하기위해,XCP통신은단2개의CAN식별자만사용하도록제한되며,이식별자는

"정상적인"통신을위해DBC에서사용할수없다.마스터에서슬레이브로정보를전송하는

데에는하나의식별자가필요하다. 다른 하나는슬레이브가마스터로응답을보낼때

사용한다.

CANapeTraceWindow에서발췌한내용에서는"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바이트를사용할수있다는뜻이다.

그림 37: XCP on CAN 메시지의 예

XCP Packet XCP Tail

Fill

XCP on CAN Message (Frame)

Control Fieldfor CAN

Control Field empty for CAN

XCP Headerempty for CAN PID FILL DAQ TIMESTAMP DATA

CANape에서는XCPonCAN데모프로그램과가상ECUXCPsim을이용해볼수있다.

이표준에대한상세한내용은ASAMXCPonCAN파트3전송레이어규격에서찾을

수있다.


1.4.2 CAN FD

CANFD(가변데이터전송속도를지원하는CAN)는RobertBosch사에서개발한CAN프

로토콜의확장기능이다.이확장기능은유효데이터의크기를8바이트에서64바이트로

늘렸다는점에서CAN과차이가난다.CANFD는도한유효데이터를보다빠른전송속

도로보낼수있는옵션을제공한다.중재단계가끝난후에는,데이터를중재단계때보

다빠른속도로전송할수있다.이때문에CAN개발에서취득한귀중한경험을그대로

살리면서도자동차네트워크에보다넓은대역폭을제공할수있다.

XCP-on-CAN-FD규격은XCP표준버전1.2.0(2013년6월)의XCP-on-CAN기술서에

정의되어있다.

그림 38: CAN FD 프레임의 예

운영모드는상당히비슷하지만이프로토콜은하드웨어와소프트웨어를수정하고확장

기능을추가해야한다.특히CANFD는제어필드에다음과같은세개의비트형식을

새로도입했다.

>ExtendedDataLength(EDL)>BitRateSwitch(BRS)>ErrorStateIndicator(ESI)


열성인 EDL 비트(고수준)는 우성인 EDL 비트(저수준)가 식별할 수 있기 때문에 확장

CAN-FD포맷의프레임을표준CAN포맷의프레임과구분하게된다.마찬가지로열성인

BRS비트는데이터필드전송시더높은비트전송속도로전송이되게한다.

ESI비트는CANFD노드의오류상태를확인한다.다른네개의비트가DataLength

Code(DLC)라는것을구성하는데,이것은확장된유효데이터길이를12,16,20,24,32,

48,64바이트로한다.

XCPonCANFD를사용할때에는A2L파일에서이차전송속도를유효데이터로정의한

경우를가정한것이다.이런작업은사용자에게는완전히투명하며,사용자는A2L을완전히

파라미터화시키게된다.

XCP마스터의측정방식을설정할때에는패킷의최대길이를고려해야하며,사용자는다른

설정값은건드릴필요가없다.

CANFD는CANape버전12.0이상에서지원한다.Vector사의CAN하드웨어중"VN"으로

시작하는제품은모두CANFD전송프로토콜을지원한다.


1.4.3 FlexRay

FlexRay개발의기본아이디어는결정론적시간거동을하는이중화(redundant)시스템을

구현하는것이었다.접속의이중화는채널2개(채널A와채널B)를사용해서달성했다.다수의

FlexRay노드(=ECU)가중복적으로상호접속하는경우,한개의지선에문제가발생한

경우,해당노드이중화된접속을이용해서다른채널로전환할수있다.

그림 39: 노드 K와 노드 L은 중복적으로 상호접속됨

CH A

CH B

Node K Node L Node M Node N Node O

결정론적거동은지정된타임슬롯내에서데이터를전송함으로써달성된다.여기서정의되는

것중하나는어떤노드가어떤내용을어떤타임슬롯으로보내느냐하는것이다.이타임

슬롯은하나의사이클을형성하도록결합한다.여기서이사이클은버스가활성화된동안

반복된다. 타임 슬롯과 그 전송 내용(누가 무엇을 언제)을 조합하는 것을 스케줄링

(Scheduling)이라고부른다.

Frame: a Frame: b Frame: x Frame: a Frame: b Frame: x

t1Slot 1 Slot 2 Slot 3 Slot 1 Slot 2 ... Real-time

t2 t3 t4 t5 t6

Communication Cycle Next Communication Cycle

x

Slot13

TxRx

aDirection FrameSlot

13

TxRx

ab

Direction Frame

Node K Node L Node M

Slot13

TxRx x

Direction Framea

그림 40: 슬롯 정의에 의한 통신


최초의통신사이클에서노드K는프레임a를슬롯1로보낸다.이스케줄링은노드L과

노드M의소프트웨어에도저장된다.그러므로프레임a의내용은차상위의통신계위로

보내진다.

스케줄링은기술파일에통합되어있다.이파일은CAN의경우처럼DBC파일은아니고

FIBEX파일이다.FIBEX는"필드버스교환포맷(FieldBusExchangeFormat)"을말하며,

다른버스시스템용으로도사용할수있다.그러나현재이포맷의사용은실질적으로

FlexRay버스기술에국한되어있다.FIBEX는XML포맷이며,XCPonFlexRay규격은

FIBEX버전1.1.5와FlexRay규격버전2.1에연관되어있다.

ECU60 1 2 3 4 5 63

7

Slot

Stat

ic S

egm

ent 1 Node K

A b [rep : 1 ]

B

Node MA c [rep : 4 ]

B

3 Node LA a [rep : 1 ]

B d [rep : 1 ]

Dyna

mic

Seg

men

t

4A n [rep : 1 ]

B m [rep : 1 ]

5

Node M

A r [rep : 1 ]

B

6

Node L

A

B o [rep : 1 ]

A

u [rep : 4 ]

B

Node O

Node N

Node L A

B

Node O

A

B

Node L

b [rep : 1 ]

b [rep : 1 ]

x [rep : 2 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

t [rep : 2 ]

w [rep : 4 ]

y [rep : 4 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

p [rep : 4 ]

v [rep : 8 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

t [rep : 2 ]

c

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

t [rep : 2 ]

w [rep : 4 ]

b [rep : 1 ]

b [rep : 1 ]

x [rep : 2 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

CyclesChannel

b [rep : 1 ]

y [rep : 4 ]

a [rep : 1 ]

d [rep : 1 ]

n [rep : 1 ]

m [rep : 1 ]

r [rep : 1 ]

o [rep : 1 ]

p [rep : 4 ]

c [rep : 4 ]

b [rep : 1 ]

b [rep : 1 ] b [rep : 1 ]

b [rep : 1 ]b [rep : 1 ]

b [rep : 1 ] b [rep : 1 ]

b [rep : 1 ]b [rep : 1 ]

u [rep : 4 ]

x [rep : 2 ]

t [rep : 2 ]

...b [rep : 1 ]

x [rep : 2 ]

Node K

2

그림 41: FlexRay 통신 매트릭스의 예

버스통신을설명하는또하나의포맷은AUTOSAR솔루션개발의결과로정의되었는데,

이는AUTOSAR기술파일로XML포맷으로사용할수있다.XCPonFlexRay의정의는

AUTOSAR4.0규격을고려했다.그러나이책을발간할당시에는이규격이아직공식적으로

승인받지못했기때문에더는언급하지않도록하겠다.

FlexRay버스의다른특성때문에슬롯번호를내용에대한참조로사용하기에는충분하지

않다.한가지이유는다중화를지원한다는것이다.한사이클이반복될때마다,전송된내용이

반드시동일할필요는없다.다중화(multiplexing)에서는두번째패스마다특정정보를

슬롯에보내도록지정할수도있다.


순수한슬롯번호를지시하는대신,"FlexRay데이터링크레이어프로토콜데이터유닛

식별자(FLX_LPDU_ID)"가사용되는데,이것은일반화된슬롯 ID의한유형으로이해하면

된다.LPDU를기술하는데4가지정보가필요하다.

> FlexRay슬롯식별자(FLX_SLOT_ID)

>사이클카운터오프셋(OFFSET)

>사이클카운터반복(CYCLE_REPETITION)

>FlexRay채널(FLX_CHANNEL)

......

......

......

......

......

......

......

...

...

...

...

...

...

. . .

......

......

......

......

......

......

......

...

...

...

...

...

.... . .

LPDU_ID

Slot ID

Channel AChannel B

Cycl

e ID

그림 42:

FlexRay LPDU의 예

스케줄링은또한XCPonFlexRay사용에도영향을미치는데,왜냐하면이기능은정확하게

무엇을보내야하는지를정의하기때문이다.XCP에서는측정런타임에서사용자가신호를

조합해서어떤측정값을보내야하는지정의하기전까지는이런것을쉽게정의할수없다.

이말은XCP통신의어떤측면은어떤LPDU에서만,즉마스터에서슬레이브로보내는

CTO나DTO,또는슬레이브에서마스터로보내는CTOorDTO에서만사용할것인지선택

하는것만가능하다는뜻이다.

다음예에서이프로세스를보여주고있다.XCP마스터에서슬롯n으로명령어(CMD)를

보내면,슬레이브A는슬롯n+2로응답(RES)을보낸다.XCPonFlexRay의메시지는

항상LPDU를사용해서정의한다.

ECU내부의파라미터에액세스하기위해서는A2L기술파일이필요하다.ECU내에서주소를

가진객체는이파일에서정의된다.또한,FIBEX파일도필요한데,그래야XCP마스터가

어떤LPDU를보내야하는지또XCP슬레이브가응답하면서어떤LPDU를보내는지알

수있다.XCP마스터와XCP슬레이브사이의통신은두개의파일을결합하는경우,즉

A2L파일이FIBEX파일을참조하도록하는경우에만기능한다.


XCPonFlexRay파라미터설정값을갖는A2L파일의발췌본은다음과같다.

...

/beginXCP_ON_FLX

...

"XCPsim.xml"

"Cluster_1"

...

이예에서"XCPsim.xml"은A2L파일에서FIBEX파일로참조하도록하는참조파일이다.

......

......

......

......

......

......

......

...

...

...

...

...

...

. . ....

......

......

......

......

......

......

...

...

...

...

...

. . .

XCP-dedicated LPDU_IDs

Channel AChannel B

......

Cycl

e ID

Slot ID

그림 43:

XCP 통신을

LPDU로 할당

CANape의온라인도움말에서XCP on FlexRay에관한상세한내용을찾을수있다.

FIBEX뷰어도CANape와함께제공되는데,이툴을이용해스케줄링을편리하게볼수

있다.CANape에서XCPonFlexRay기기에대한드라이버설정값을만들어XCP메시지

를LPDU에할당하기는쉽다.

이프로토콜은ASAMXCPonFlexRay파트3전송레이어규격에서상세하게설명하고

있다.CANape에서는XCPonCAN데모프로그램과가상ECUXCPsim을이용해볼수

있다.이데모프로그램을구동하려면벡터사의FlexRay하드웨어가필요하다.

1.4.4 Ethernet

XCP on Ethernet은 TCP/IP나 UDP/IP와 함께 사용할 수 있다. TCP는 Ethernet에서

사용하는보호된전송프로토콜로그핸드세이크방식은패킷손실을탐지하는데사용

된다.패킷손실이탐지된경우,TCP는패킷을반복적으로전송한다.UDP는이러한보호

메커니즘을제공하지않는다.패킷손실이발생한경우,UDP는프로토콜차원에서손실된

패킷을반복적으로보내는메커니즘을제공하지않는다.

XCPonEthernet은실제ECU에서사용할수있을뿐아니라가상ECU의측정/캘리브레

이션용으로도사용할수있다.여기서가상ECU란ECU에서구동되는코드를PC상의실행

프로그램(예를들어DLL)으로실행할수있도록한것이다.이경우에는ECU와비교할때


전혀다른자원을사용하게된다(CPU,메모리등).

그러나먼저실제프로토콜에대해논의해보기로하자.하나의IP패킷은항상발신자와

수신자주소를포함한다. IP패킷을가시화해볼수있는가장간단한방법은수신자와

발신자의주소가함께쓰여있는편지라고생각해보는것이다.개별노드의주소는항상

고유해야한다.고유주소는IP주소와포트번호로구성된다.

그림 44: TCP/IP 또는 UDP/IP에서의 XCP 패킷

XCP Header XCP Packet

LEN CTR

XCP on Ethernet (TCP/IP and UDP/IP) Message (Frame)

Length (LEN)Control Fieldfor Ethernet

(TCP/ IP and UDP/IP)

Control Fieldempty for Ethernet

(TCP&IP and UDP&IP)

XCP Tailempty for Ethernet

(TCP/IP and UDP/IP)PID FILL DAQ TIMESTAMP DATA

헤더는인텔(Intel)포맷(=4바이트)의2단어로된제어(Control)필드로구성된다.이단어들은

길이(LEN)와카운터(CTR)를담고있다.LEN은XCP패킷내의바이트수를나타낸다.CTR은

패킷손실을탐지하는데사용된다.UDP/IP는보호된프로토콜이아니다.패킷이하나

손실된경우에도프로토콜레이어에서는인식하지못한다.패킷손실은카운터정보를

이용해감시한다.마스터가슬레이브로최초메시지를보낼때,마스터는프레임한개를추가로

전송할 때마다 카운터 수를 늘린다. 슬레이브도 같은 패턴으로 응답한다. 슬레이브가

보내는각각의프레임에대해자체카운터수를늘린다.슬레이브와마스터에있는카운터는

각각독립적으로작동한다.UDP/IP는측정값을전송하는데적합하다.패킷이하나손실되는

경우,그패킷을포함한측정값이손실되어측정에차이가생기게된다.이러한손실이가끔

발생하는경우에는무시할수 있다. 그러나측정데이터를고속제어용으로사용하는

경우에는TCP/IP를사용할것을권고한다.

Ethernet패킷하나는여러개의 XCP패킷을전송할수있지만,하나의 XCP패킷은

UDP/IP패킷의한계를넘지못한다. XCP on Ethernet의경우에는 "테일(Tail)",즉빈

제어필드가없다.

이프로토콜에대한보다상세한정보는ASAMXCPonEthernet파트3전송레이어

규격에서찾을수있다.CANape에서는시뮬링크모델과시뮬링크코더로구현된DLL

형태의가상ECUXCPsim이나가상ECU이포함된XCPonEthernet의데모를이용할

수있다.


1.4.5 SxI

SxI는SPI나SCI에대한집합명사이다.SPI나SCI는버스가아니고점대점(point-to-point)

접속에만적합한컨트롤러인터페이스이기때문에이러한전송방식에서는주소를지정하지

않는다.노드2개사이의통신은동기적으로나비동기적으로이루어질수있다.

그림 45: XCP-on-SxI 패킷

XCP Header XCP Packet

LEN CTR FILL CS

XCP Tail

XCP on Sxl Message (Frame)

Length (LEN)

Checksum (CS)

Control Fieldfor SxI

Control Fieldfor SxI

PID FILL DAQ TIMESTAMP DATA

XCP헤더는길이(LEN)와카운터(CTR)의두가지정보를제공하는제어필드로구성된다.

이파라미터의길이는바이트나단어로표시된다(인텔포맷).LEN은XCP패킷의바이트

수를나타낸다.CTR은패킷손실을탐지하는데사용된다.이방식은XCPonEthernet과

마찬가지로카운터정보를가지고감시한다.특정한상황에서는패킷에필바이트(fillbyte)를

추가해야할수도있다.예를들자면,SPI를WORD나DWORD모드로사용하거나최소

패킷길이보다짧은메시지를피해야하는경우이다.이러한필바이트는제어필드에

추가된다.

이프로토콜에대한보다상세한정보는ASAMXCP-on-SxI파트3전송레이어규격에서

찾을수있다.

1.4.6 USB

현재,XCPonUSB는실용적인중요성을지니지못하고있다.그러므로,이에대해서는별

도의언급을더는하지않을것이다.이에대해서는ASAMXCPonUSB파트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명령어를좀더이해하기위해,여기서섹터와세그먼트,페이지의

개념을다시한번설명하겠다.

Segment 0Page 0

Sect

or 2

Sect

or 1

Sect

or 0

Segm

emt 0

Segment 1Page 0

Segment 1Page 1

Segment 1Page 2

Segm

emt 1

ECU access

address

XCP access

그림 46:

메모리 예

571.5 XCP 서비스

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페이지의데이터를비휘발성

메모리에있는페이지에저장하는것도포함된다.이때비휘발성메모리가플래시메모리라면,

세그먼트시작주소와세그먼트크기가반드시플래시섹터에일치할필요는없다는점을

고려해야하며,이는플래시메모리의소거및다시쓰기에문제가있다는것을나타낸다

(ASAMXCP파트2프로토콜레이어규격참조).

1.5.3 플래시 프로그래밍

플래싱이란데이터를플래시메모리영역에쓰는것을말한다.여기에는메모리의레이아웃에

대한정확한지식이필요하다.플래시메모리는여러개의섹터(물리적구분)로나뉘며,이러한

섹터는시작주소와길이로기술한다.이러한섹터들을서로구분하기위해이들은각각

일련의식별번호를가진다.이렇게번호를할당하는데1바이트를쓸수있기때문에최대

255개의섹터를지원할수있다.

SECTOR_NUMBER[0,1,2...255]

플래시섹터에관한정보도A2L데이터세트의일부이다.

그림 47:

플래시 영역의

드라이버 설정 예

591.5 XCP 서비스

플래싱은"플래시커널"이라고부르는것을이용해구현한다.플래시커널은플래싱을실제로

실행하기전에슬레이브의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에대해이벤트를사용할수있는지,이벤트가주기적으로발생하

는지,그렇다면사이클주기는얼마인지등에관한것이다.

611.5 XCP 서비스

1.5.5 업로드/다운로드/플래싱을 위한 블록 전송 모드

"정상"통신모드에서는마스터에서보낸각명령어에대해슬레이브가응답을보내확인

한다.그러나어떤경우에는성능때문에블록전송모드를사용하는것이더바람직할

수도있다.

Time

Master Slave

Response k

Request k+1

Request kPart1

Part3

Part2MIN_ST

MAX_BS

그림 48:

블록 전송 모드 예

이런방법을사용하면대량의데이터를전송할때전송절차를가속화시킬수있다(UPLOAD,

SHORT_UPLOAD,DOWNLOAD,SHORT_DOWNLOAD,PROGRAM등).마스터는슬레이브가

이방식을지원하는지GET_COMM_MODE_INFO요청을보내확인할수있다.이에대한

보다자세한내용은ASAMXCP파트2프로토콜레이어규격에서찾을수있다.


1.5.6 콜드 스타트 측정 (파워 온 도중 측정 시작)

지금까지설명한XCP의능력을갖추고도ECU의시작단계초기에실행할수있는이벤트

수동식측정을이행하기는불가능하다.그이유는실제측정을하기전에이러한측정에

대해구성을해야하기때문이다.만약이러한구성을하려시도한다면최초측정값이

전송되는시점에는이미ECU의시작단계가종료된후일것이다.이문제를극복하기위해

사용하는방법은간단한아이디어에바탕을두고있다.

이방법은구성과적시측정을분리하는것이다.구성단계가완료된후에도측정을바로

시작하지는못하는데,그이유는ECU를종료해야하기때문이다.리부팅을한후XCP

슬레이브는기존의구성에직접액세스하는즉시최초의메시지를발송하기시작한다.이와

관련하여무엇이곤란한지는명백하다.즉,DAQ리스트의구성데이터는RAM에저장되기

때문에리부팅을한후에는더는해당정보가존재하지않는것이다.

콜드스타트측정을활성화하기위해RESUME모드라고알려진것을활성화하려면,XCP

슬레이브에전원공급이되지않더라도데이터를보존할수있는비휘발성메모리가필요

하다.여기에EEPROM이사용된다.이런상황에서는실제EEPROM이든플래시메모리를

이용해에뮬레이션한것이든따지는것은적당하지않다.

더욱구체적인내용은제1.4.2.2장"고급기능"의ASAMXCP파트1규격개요에서찾을

수있다.

631.5 XCP 서비스

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규격과는독립적이다.

652 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내에원천값으로존재하며,그형태로전송된다.측정/캘리브레이션툴은저장된

공식을사용해서물리값으로가시화한다.

스칼라파라미터이외에도특성곡선과맵은자주사용된다.홀센서(Hallsensor)와같은

근접센서를사용할수도있는데,이센서는거리를자계강도의함수로결정하기때문에이

거리값을알고리즘에사용할수도있다.자계와거리값은상호간에선형으로작용하지

않는다.이러한값의비선형성은알고리즘을불필요하게복잡하게만들게된다.특성곡선을

이용하면해당입력변수로값을알고리즘에입력하기전에먼저선형화시킬수있다.

특성맵의또다른어플리케이션영역은복잡한계산을대체하는데사용하는것이다.예를

들어,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"라는명칭의측정파라미터를예로들면다음과같다.

/beginMEASUREMENTShifter_B3"Singlebitsignal(bitfromabyteshifting)"

UBYTEHighLow0001

READ_WRITE

BIT_MASK0x8

BYTE_ORDERMSB_LAST

ECU_ADDRESS0x124C02

ECU_ADDRESS_EXTENSION0x0

FORMAT"%.3"

/beginIF_DATACANAPE_EXT

100

LINK_MAP"byteShift"0x124C020x000x010x870x0

DISPLAY0020

/endIF_DATA

/endMEASUREMENT

KF1이라는명칭의파라미터맵을예로들면다음과같다

/beginCHARACTERISTICKF1"8*8bytenoaxis"

MAP0xE0338__UBYTE_Z0Factor10002.55

ECU_ADDRESS_EXTENSION0x0

EXTENDED_LIMITS02.55

BYTE_ORDERMSB_LAST

BIT_MASK0xFF

/beginAXIS_DESCR

FIX_AXISNO_INPUT_QUANTITYBitSlice.CONVERSION807

EXTENDED_LIMITS07

READ_ONLY

BYTE_ORDERMSB_LAST

FORMAT"%.0"

FIX_AXIS_PAR_DIST018

/endAXIS_DESCR

692.2 수동으로 A2L 파일 생성하기

/beginAXIS_DESCR

FIX_AXISNO_INPUT_QUANTITYBitSlice.CONVERSION807

EXTENDED_LIMITS07

READ_ONLY

BYTE_ORDERMSB_LAST

FORMAT"%.0"

FIX_AXIS_PAR_DIST018

/endAXIS_DESCR

/beginIF_DATACANAPE_EXT

100

LINK_MAP"map3_8_8_uc"0xE03380x000x010x870x0

DISPLAY00255

/endIF_DATA

FORMAT"%.3"

/endCHARACTERISTIC

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에서새기기를생성한다음

인터페이스로XCPonCAN를선택한다.그다음에는기타통신방식별정보를보완할수

있다(예를들어,CAN식별자).파일을저장한후에는A2L의통신내용전체를담고있는

A2L파일을갖게된다.아직부족한것은실제측정/캘리브레이션파라미터의정의이다.


(CANape의일부이며,별도의툴로구매가능한)A2L에디터에서는링커-맵파일이A2L과

결부되어있다.사용자는선택대화상자에서맵파일을이용해스칼라측정/캘리브레이션

파라미터,특성곡선/맵등A2L에필요한파라미터를선택할수있다.사용자는원하는

파라미터를A2L에단계적으로추가하거나그룹화할수있다.기타객체별정보도에디터를

사용해추가할수있다.

여러분의코드를수정하거나다시컴파일하거나링크할때무엇을해야하는가?객체주소가

바뀔가능성은매우높다.근본적으로A2L파일을새로만들필요는없다.코드에방금

추가한객체를A2L파일에서도사용하고싶다면물론이객체를A2L파일에추가해야

한다.A2L파일에서는항상주소를업데이트할필요가있다.이런업데이트도에디터로할

수있다.에디터는A2L의객체명에따라링커-맵파일에서적절한입력값을찾아주소를

읽은다음그내용을A2L에업데이트한다.

여러분의어플리케이션이객체명이바뀌고,데이터유형을새로채택하고파라미터를지우거나

추가하는등매우동적으로변경된다면,수작업은실용적이아닐수도있다.A2L을C코드로

생성하기위해서는자동처리를위해다른툴들을사용할수도있다.

벡터사의홈페이지에서"ASAP2Tool-Set"에대한정보를얻을수있는데,이툴세트를

가지고소스코드에서A2L을배치프로세스로생성할수있다.

2.3 A2L 컨텐츠 vs ECU 구현

XCP마스터툴이ECU에완전히일치하지않는A2L파일을읽는경우,통신방식에대한

오해가발생A2L컨텐츠할수있다.예를들어,A2L파일에있는타임스탬프해상도관련

값이ECU에구현된값과차이가날수있다.이런경우,문제를탐지해서해결해야한다.

사용자는마스터에게서지원을받을수있는데,마스터는슬레이브에서실제로구현된것

으로확인된프로토콜을이용해슬레이브에폴링을할수있다.

XCP는슬레이브의자동탐지를위한여러가지기능을제공한다.물론이는슬레이브에자동

탐지가구현되어있다는가정을한경우에해당된다.마스터가슬레이브에폴링을했을

때,슬레이브의응답이A2L기술파일에들어있는파라미터세트와합치하지않는다면,

마스터는어떤설정값을사용해야하는지결정해야한다.CANape에서는A2L에서얻은

정보보다슬레이브에서읽은정보에더높은우선순위를부여한다.

712.3 A2L 컨텐츠 vs ECU 구현

다음은슬레이브의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리스트로존재...

733 캘리브레이션 개념

3 캘리브레이션 개념

74 3 캘리브레이션 개념

ECU파라미터는ECU나ECU베리언트(variant)의개발중에채택하고최적화하는일정한

파라미터이다.이는반복적인프로세스로특정파라미터의최적값은반복적인측정과

변경을통해구할수있다.

캘리브레이션개념은ECU의개발및캘리브레이션단계에서ECU에들어있는파라미터를

어떻게수정할수있는지에대한답변이다.현존하는캘리브레이션개념은하나가아니라

여러개이다.어떤개념을사용할것인지는사용하는마이크로컨트롤러의능력과자원에

달려있다.

보통,파라미터는양산된ECU의플래시메모리에저장된다.하부의프로그램변수들은

소프트웨어의상수로정의된다.ECU개발중런타임에서파라미터를수정할수있도록

하려면RAM메모리가추가로필요하다.

캘리브레이션개념은다음과같은질문과관련이있다.파라미터가초기에플래시메모리

에서RAM으로찾아갈수있을까?마이크로컨트롤러가RAM에액세스하는경로를다시

설정할수있을까?RAM에동시에저장할수있는양보다많은파라미터가있을경우에는

어떻게 해결해야 하는가? 파라미터를 플래시 메모리에 다시 복사하려면 어떻게 해야

하는가?파라미터에가한변경은지속적인가?다시말해ECU를끌경우에는보존되는가?

투명한캘리브레이션개념과불투명한캘리브레이션개념에대해구분해보자.투명하다는

것은특정캘리브레이션툴이위의질문들에대해관여할필요가없다는것으로,왜냐하면

모든필요한메커니즘이ECU에구현되어있기때문이다.

다음에몇가지방법에대해간략하게소개해보겠다.

3.1 플래시 파라미터

소프트웨어개발자는특정파라미터가변수인지상수인지,다시말해이파라미터를플래시에

저장할것인지,아니면RAM메모리에저장할것인지를정의한다.

C코드예제:

constfloatfactor=0.5;

"인수(factor)" 파라미터는 값이 0.5인 상수를 나타낸다. 코드를 컴파일하고 링크할 때

메모리공간은해당"인수"객체용플래시메모리에제공된다.이객체에는플래시메모리의

데이터영역에위치한주소를할당한다.0.5란값은헥스파일의해당주소에서찾을수

있으며,이주소는링커-맵파일에있다.

가장간단하게이해할수있는캘리브레이션개념은C코드에서값을수정하거나새로운

헥스파일을생성해서플래싱하는것이다.그러나이방법은매우노력이많이들어가는

데,왜냐하면모든값의변경을코드에서해야하며그에따라컴파일러/링커작업을한

후플래싱을해야하기때문이다.다른방법은헥스파일에서값만수정한다음,이파일을

다시플래싱하는것이다.모든캘리브레이션툴에서이방법을사용할수있다.이방법은

헥스파일의"오프라인캘리브레이션"이라고부르는데,보편적으로사용되는방법이다.

753.1 플래시 파라미터

특정컴파일러를사용하는어떤상황에서는예를들어파라미터가플래시메모리에저장되고

코드에통합되지않는지,그래서링커-맵파일에반영되지않는지를확실하게확인할

필요가있다.통상적으로플래시메모리내에서상수가어느곳에생성되는지를우연에

맡기는사람은없을것이다.이를위해사용하는수단은거의항상컴파일러별프라그마

지시어(pragmainstruction)이다.컴파일러가파라미터를코드내에내장시키는것을방지

하려면상수파라미터를위한"휘발성(volatile)"속성을사용하는것으로충분하다.다음

예에서는플래시상수에대한전형적인정의를보여주고있다.

C코드예제:

#pragmasection"FLASH_Parameter"

volatileconstfloatfactor=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코드예제:

#pragmasection"RAM_Parameter"

volatilefloatfactor=0.5;

여기서는 "인수"파라미터를초기값이0.5인RAM변수로정의했다.코드를컴파일하고

링크하는도중에는메모리공간을RAM에"인수"객체용으로유보하고관련RAM주소는

링커-맵파일에나타난다.초기값0.5는플래시메모리와헥스파일의해당위치에저장

된다.플래시메모리에든초기값의주소는링커의파라미터생성과정에의해정의하지만,

이값은링커-맵파일에나타나지는않는다.

ECU부팅도중모든RAM변수는일단플래시메모리에있는초기값으로초기화된다.이

작업은보통컴파일러생산자의시동코드에서실행되며,어플리케이션프로그래머는이에

관해관심을둘필요가없다.어플리케이션은RAM에있는파라미터값을사용하며,이값은

XCP메모리에정상적으로액세스해서수정할수있다.

ECU소프트웨어의관점에서보면,캘리브레이션용RAM의파라미터는항상수정할수없는

상태이다.즉,어플리케이션자체적으로는이를변경할수없다.많은컴파일러가코드

분석을통해이사실을발견하고단순히필요한RAM메모리공간을최적화시켜버린다.

그러므로컴파일러들이"휘발성"속성을이용해최적화시키는것을방지할필요가있다.

캘리브레이션툴의관점에서보면,파라미터가위치한RAM영역은캘리브레이션용RAM

(캘리브레이션이가능한메모리)으로불린다.

FLASH RAM

Parameters

Calibration RAM

그림 51:

RAM의 초기

파라미터 설정

캘리브레이션용RAM은완전히인접한RAM영역으로구성할필요가없다.캘리브레이션용

RAM은여러개의영역에분산시키거나원하는방법으로분산시킬수도있다.그러나이

방법은불과몇개의인접하는RAM영역에서파라미터를구성하고상태변수나중간결과

등과같은기타RAM파라미터로부터해당파라미터를격리하는데큰장점이있다.이는캘

리브레이션용RAM을오프라인에서헥스파일로캘리브레이션하도록한경우에특히중요

하다.사용자의요청에따라오프라인캘리브레이션에서온라인캘리브레이션으로전환

하는동안,캘리브레이션툴은오프라인에서수정한파라미터를탑재할수있어야한다.

773.2 RAM 파라미터

이러한경우는매우자주발생한다.예를들어,캘리브레이션담당자가다음날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_PAGEXCPtoRAM

체크섬계산 CALC_CHECKSUM

RAM영역에대한체크섬계산에서차이가발견되는경우,먼저사용자에게보통어떻게

처리할것인가를묻게된다.ECURAM의내용을마스터로보내야하는가아니면마스터

페이지에있는파일의내용을ECU의RAM으로보내야하는가?만약사용자가오프라인에

서ECU에가한변경내용을쓰기로한경우,그다음절차는다음과같다.

ECU는플래시페이지의데이터세트를사용해야한다.SET_CAL_PAGEECUtoFLASH

마스터에서RAM페이지로파일복사 DOWNLOAD...

ECU는RAM페이지의데이터세트를사용해야한다. SET_CAL_PAGEECUtoRAM

나중에이메모리페이지는언제나RAM으로전환할수있기때문에파라미터를수정할

수있다.그러나사용자는또한ECU에서어떤메모리페이지를활성화할것인지명확하게

지시해야한다.예를들어,RAM파라미터세트의거동을플래시파라미터세트의거동과

비교할수있으며,또는긴급시에는플래시메모리에들어있는확인된파라미터세트로

신속히복구시킬수도있다.

793.4 플래시 오버레이의 동적 할당

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 RAMPointertable

Parameters 그림 52:

부팅 후 처음 상황

사용자가부팅후처음으로A2L파일에서파라미터를하나선택하고그에대한쓰기액세스를

얻고자한다면,이는먼저ECU내에서복사작업을촉발한다.XCP슬레이브는액세스할

주소가플래시영역에있는지확인하고이파라미터값을캘리브레이션용RAM에복사한다.

해당어플리케이션이파라미터값을플래시메모리가아니라RAM영역에서가져오게하도록

포인터테이블에변경을가한다.

813.5 각 AUTOSAR에 대한 RAM 포인터 기반의 캘리브레이션 개념

FLASH RAMPointertable

Parameters

그림 53:

포인터 변경과

RAM에 복사하기

어플리케이션은포인터테이블을통해계속파라미터값을가져온다.그러나포인터는

RAM주소를지시하기때문에,그곳에서값을가져온다.그결과,사용자는XCP를통해

파라미터값을변경할수있고,측정을통해변경효과를관찰할수있다.이방법의단점은

포인터테이블에입력한값이각각의파라미터에서모두사용가능해야한다는점으로그에

따라포인터테이블용으로상당량의추가RAM메모리가필요하게된다는점이다.

다음그림은이문제를보여주고있다.PID컨트롤러의세가지파라미터(P,I,D)는ECU의

플래시 영역에 실려 있다. RAM 주소와 RAM 내에 있는 파라미터값은 이미 포인터

테이블에서변경되었다.

그림 54: 각 파라미터용 포인터 테이블

Flash

0x11

0x22

0x33

0x0000100A

0x000012BC

0x00007234

Parameter

P

I

D

Pointertable

0x000A100A

0x000A100B

0x000A100C

RAM

0x44

0x55

0x66

0x000A100A

0x000A100B

0x000A100C

Addr. Addr. Addr.Content Content

캘리브레이션개념은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세팅으로돌아가보자.

833.6 플래시 포인터 기반의 캘리브레이션 개념

그림 55는 포인터 테이블을 보여주고 있다. 포인터 테이블은 RAM에 위치한다. 이미

언급했던것처럼이테이블은플래시메모리에서RAM으로복사해야한다.그결과,이

테이블은플래시메모리에놓이게된다.RAM이나플래시에있는포인터테이블을지시하는

다른포인터가사용되는경우(테이블포인터),이중포인터솔루션에다다르게된다.

FLASH RAMRAM

Pointertable

Tablepointer

FLASHPointertable

그림 55:

이중 포인터 개념

파라미터값은처음에테이블포인터를통해서액세스한다.테이블포인터가RAM에있는포

인터테이블을지시하는경우,어플리케이션은기본적으로RAM포인터테이블의내용을통

해실제파라미터에액세스한다.이솔루션의단점은낮은액세스속도와더많은프로그램

코드를생성한다는점이다.

3.6 플래시 포인터 기반의 캘리브레이션 개념

이방법은수년전에"InCircuit2"라는이름으로ZF프리드리히샤펜(ZFFriedrichshafen)사

에서특허를냈으며,AUTOSAR의포인터기반개념과상당히유사하다.여기서도ECU에

있는어플리케이션은포인터테이블을이용하여파라미터데이터에액세스한다.그러나이

포인터테이블은RAM에있는것이아니라플래시메모리에들어있다.포인터테이블을

변경하기위해서는플래시프로그래밍을해야한다.툴에투명한구현방식은가능하지

않다.이방식의장점은RAM에포인터테이블이들어있지않기때문에RAM의메모리를

저장할수있다는데있다.

854 XCP의 어플리케이션 영역

4 XCP의 어플리케이션 영역

86 4 XCP의 어플리케이션 영역

ECU캘리브레이션담당자가XCP를사용하고자할때보통이프로토콜을ECU에고착

시킨다.

Slave

Slave

Slave

Slave

Slave

PC

XCP Measurement/Calibration Hardware*

* Debug Interfaces, Memory Emulator, ...

HIL/SIL Systems

EXE/DLL

Prototype orECU Hardware

Simulink

Master

그림 56:

어플리케이션 영역과

어플리케이션 사례

개발프로세스를조사하는과정에서전자기기나소프트웨어개발에대한수많은솔루션을

접할수있다.여기서키워드는HIL과SIL,래피드프로토타이핑등인데,이런것들은서로

다른시나리오를이용하고있다.이들이공통으로사용하는것은 "플랜트"와 "컨트롤러"

이다.

그림 57: 플랜트와 컨트롤러

OffsetManipulated

VariableDisturbance

Variable

Controlled Variable(Actual Value)

Reference Variable(Set Value)

Controller Plant

자동차를개발하는상황에서컨트롤러란ECU를말하고플랜트는전송장치,엔진,사이드

미러등과같이제어가가능한물리적시스템을말한다.

컨트롤러나플랜트를실제로또는시뮬레이션을통해구동하는가에따라개발방식을대략

구분한다.일부조합은좀더상세하게설명할것이다.

874.1 MIL: Model in the Loop

4.1 MIL: Model in the Loop

Plant ModelController Model

Simulink

그림 58:

시뮬링크의 MIL

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

예에서는시뮬링크를런타임환경으로하여이두모델을구동한다.행태를분석하는데

있어시뮬링크런타임환경의능력을사용할수있다.

초기개발단계에서CANape와같은측정/캘리브레이션툴의편의성을구현하기위해XCP

슬레이브는컨트롤러모델에통합시킬수있다.저작단계에서슬레이브는이모델에대응

하는A2L을생성하며,사용자는이미그래픽윈도를이용한프로세스흐름의가시화,특성

곡선에대한접근,맵등등모든편리한운영에필요한기능을갖게된다.


Simulink

SimulinkXCP Server

CANape

A2L

그림 59:

시뮬링크 모델의 측정/

캘리브레이션 툴로서의

CANape

코드생성단계나모델의계측화는여기에필요하지않다.타임스탬프도XCP를통한전송

시포함된다.CANape는여기서시뮬링크런타임환경의시간거동에완전히적응했다.

이모델이실시간보다빠르게혹은느리게구동되는지는중요하지않다.예를들어,기능

개발자가이모델을통해시뮬링크디버거를사용한다면,CANape는XCP를통해전송된

시간을참조시간으로사용한다.


4.2 SIL: Software in the Loop


Controller ModelWindows DLL

Simulink

Code generation

그림 60:

시뮬링크 환경의

SIL

이개발단계에서,코드는컨트롤러모델에서생성되며,이코드는 PC기반의런타임

환경에서사용한다.자연적으로,컨트롤러는어떠한모델기반의접근방법도사용하지않고

개발할수있다.플랜트는계속시뮬레이션된다.XCP는컨트롤러를측정하고캘리브레이션

하는데사용할수있다.컨트롤러가시뮬링크모델에서생성된경우라면,DLL및그에

연관된 A2L을위한 C코드를생성하기위해코드생성단계(CANape를타겟으로한

시뮬링크코더)를사용한다.만약수작업으로작성한코드를기반으로컨트롤러를개발하는

경우에는CANape와함께제공되는C++프로젝트에내장시킨다.

컴파일과링크후,이DLL은CANape환경에서사용된다.XCP접속을지원하기때문에

이 DLL의 알고리즘은 어플리케이션이 ECU에 이미 통합된 것과 마찬가지로 정확하게

측정및캘리브레이션할수있다.


Controller ModelWindows DLL

Simulink

Code generation

CANapeA2L

그림 61:

SIL 개발 플랫폼으로서의

CANape

894.3 HIL: Hardware in the Loop

4.3 HIL: Hardware in the Loop

다양한HIL시스템이출시되어있다.매우간단하고가성비좋은시스템에서고가의초대형

시스템에이르기까지다양하다.다음그림이대략적인개념을보여주고있다.

Plant Model

HIL Platform

ECU

I/O

Controller Model

그림 62:

HIL 솔루션

컨트롤러 알고리즘은 마이크로컨트롤러 플랫폼에서 (예를 들어 ECU) 구동되는 반면

플랜트는계속해서시뮬레이션을사용하고있다.파라미터와플랜트의복잡성,필요한I/O

등에따라HIL플랫폼에대한요구사항과관련비용은가파르게상승할수있다.ECU는

실시간으로구동되기때문에플랜트모델의시뮬레이션도실시간으로진행해야한다.

XCP의 최적화는또 하나의 ECU만 추가하면되니까사소한것으로보인다. 전체적인

시스템은다음과같다:

CANape

A2L

Plant Model

HIL Platform

ECU

I/O

Controller Model

그림 63:

HIL 측정/캘리브레이션

툴로서의 CANape

CANape에서는사용자가XCP를통해ECU의알고리즘에액세스할수있다.


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

경우,HIL시스템과같이보인다.

CANoe RT User PC

EthernetCANoe RT Server

Digital I/O Analog I/O

CAN

LIN

MOST

FlexRay

CANape

A2L

ECU

XCP

Plant Model

그림 64:

HIL 시스템으로서의

CANoe

시험하기위해CANoe에서직접XCP데이터에액세스할수있는기능은다음과같이

사용할수도있다.

CANoe RT User PC

EthernetCANoe RT Server

Digital I/O Analog I/O

CAN

LIN

MOST

FlexRay

A2L

ECU

XCPPlant Model

그림 65:

CANoe를 HIL 시스템

으로 사용 시, ECU에

XCP로 액세스

여기서플랜트모델은CANoe의실시간서버에서구동된다.동시에ECU에XCP로액세스

하는것도CANoe에서할수있다.이러한능력은사용자에게플랜트와컨트롤러에동시에

액세스할수있는툴을마련해주는것이다.

914.4 RCP: Rapid Control Prototyping

이그림을자세히설명하기위해서는또다른HIL솔루션에대해서도언급을해야한다.

플랜트는CANape에서하나의DLL로구동할수있다.이를이용해사용자는XCP를통해

플랜트와컨트롤러에완전하게액세스할수있다.

그림 66: HIL 솔루션으로서의 CANape

A2L

ECU

ECU

PlantXCP

Plant ModelWindows DLL

CANape

A2L

XCP

4.4 RCP: Rapid Control Prototyping

이개발단계에서제어알고리즘은 ECU대신실시간 HIL에서구동된다.이런상황은

필요한ECU하드웨어를사용할수없을경우흔히발생한다.몇몇플랫폼은단순한평가

위원회에서자동차차원의하드웨어솔루션에이르기까지추가적인요구사항을충족시킬

수있는하드웨어로서적합한지의문이제기되고있다.여기서도XCP와통합을하는경우

OEM에독립적인툴체인을설정하는데도움이된다.

그림 67: RCP 솔루션

A2LXCP I/O

EVA BoardCANape

Controller Model

Plant

"신속한(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은

이알고리즘의새로운변형으로실제플랜트에서시운전해보아야한다.

그림 68: 바이패싱의 기본 원칙

I/O

XCP

ECU

Bypassing Hardware

BypassingHardware

CANape

Controller Model

A2LECU

A2L

Plant

XCP

934.5 바이패싱

바이패싱하드웨어(그림에나온 VN8900 기기)와 ECU는 XCP를 이용해상호접속된다.

여기서한가지목표는DAQ를이용해ECU에서알고리즘A1에필요한데이터를가져오는

것이다.또다른목표는A1의결과를신호인가해ECU로돌려보내는것이다.다음그림은

이러한흐름을도식적으로보여주고있다.

2.

3.

Bypassing Hardware

ECU

Algorithm A1

Algorithm A

1. XCP 4.

BypassingCoordinator

그림 69:

바이패싱 흐름

ECU에있는것은알고리즘A가구동하는푸른색의기능블록이다.현재A1을사용할수

있는지확인하기위해데이터는알고리즘A에입력변수로입력되고,이는DAQ가ECU

에서측정한다. 1단계에서는바이패싱코디네이터가데이터를받아들이고,2단계에서는

데이터를알고리즘A1으로보낸다.A1은바이패싱하드웨어가계산하고,3단계에서는결과

값이바이패싱코디네이터로다시돌려보낸다.4단계에서는이값이STIM에의해ECU로

전달된다.이데이터는슬레이브에서그다음기능블록이입력변수를찾게될"위치"에

쓰여지게된다.이로써A가아니라알고리즘A1가계산한값을 ECU의전반적인제어

프로세스에서사용할수있게된다.이방법은I/O장치와ECU의베이직소프트웨어를

포함하는바이패싱하드웨어에서알고리즘을신속하게교체할수있도록한다.


물론,XCPonCAN드라이버의성능상한계도바이패싱에영향을미친다.짧은바이패싱

시간이필요한경우에는DAQ와STIM으로ECU에액세스하는것도컨트롤러의디버깅이나

추적인터페이스를통해수행할수있다.벡터의VX1000측정/캘리브레이션하드웨어는

데이터를컨트롤러인터페이스에서XCPonEthernet의데이터스트림으로전환시킨다.

이프로세스에서는최대1메가바이트의데이터를ECU로전송할수있다.

Plant

XCP

ECU

Bypassing HardwareBypassingHardware

CANape

Controller Model

A2L

I/O

XCP

Debugging and Trace Interface

Measurement & CalibrationHardware VX1000

그림 70: 실시간 바이패싱 하드웨어로 바이패싱 및 ECU 고속 액세스

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


이용하는다른솔루션도있는데,이알고리즘은ECU내에서구동되는것이아니라PC에서

실행코드의형태로또는시뮬링크모델을이용한"가상ECU"의형태로구동된다.이런가상

ECU는실시간으로구동할필요가없는데,왜냐하면이런경우에는실제시스템에대해

접속하지않기때문이다.이경우에는PC의계산성능에따라훨씬빠른속도로구동할

수있다.

이알고리즘은이전에로그했던측정파일에의해신호인가가되는데,이파일에는알고

리즘의입력신호로필요한모든신호가실려있다.CANape로접속하는것은XCP를통해

설정한다.사용자는파라미터를만들고,측정을구성할수있다.이후에는실행이시작된다.

여기서시운전에서얻은데이터를신호인가로알고리즘에입력하고어플리케이션에서

원하는측정파라미터를동시에측정한후측정파일로저장한다.

NewMDF

Application

Para-meter

MDFtest drive

CANape

1. Set parameters

2. Start

3. Send test drive data

4. Measurement data

5. Analyze

Slave

Simulink/DLL

그림 71:

가상 ECU로

캘리브레이션

사이클 단축


계산이완료된후,사용자는ECU의거동을분석하기위한새로운측정파일을이용할수

있다.새로운측정파일의시간길이는입력측정파일의길이와정확하게정합한다.시운전

시간이 1시간인경우,이알고리즘은 PC에서불과몇분만에시운전전체를계산할

수있다.그러면 1시간동안의시험에해당하는측정결과가존재한다.데이터분석을

기초로사용자는파라미터생성에대한결정을내리고,이반복사이클(iterationcycle)은

되풀이된다.

Parameterizationvia XCP

Start

Send measurementdata

New software version

CANape Application as EXE or DLL on PC

Set values inworkspace

Start

Calculate model

End model calculation

Send measurement values from the model

Receive newmeasurement data

Analyze thenew data

그림 72:

가상 ECU를 이용한

프로세스 흐름

반복사이클을단축하기위해이알고리즘은항상동일한데이터에의해신호인가된다.

이에따라다른파라미터를사용해얻은결과들도비교할수있게되는데,그이유는이

러한결과가다른파라미터들에의해서만영향을받기때문이다.

이프로세스는물론자동화시킬수있다.CANape의통합스크립트언어는측정결과의

분석을수행하며,또한이측정결과에서파라미터캘리브레이션에대해설정을하고자

동으로실행하게된다.또한CANape자동화인터페이스를이용해매트랩과같은외부의

최적화툴로프로세스를제어하는것도가능하다.

995 XCP 구현 사례

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.handxcp_cfg.h)로구현할수있다.이러한예로는

Ethernet과RS232등다양한전송레이어의구현을들수있다.CAN의경우,전송레이어는

보통매우단순하며,다양한XCP메시지종류를CAN메시지에직접매핑할수있으며,

그다음에는Tx방향과Rx방향의고정식별자를별개로부여하게된다.

전송레이어와프로토콜레이어사이의소프트웨어인터페이스는매우단순하며,불과몇개의

기능만을가지고있다.

>슬레이브가버스를통해XCP메시지를수신하면,메시지는먼저통신드라이버에도착

하고,드라이버는이메시지를XCP전송레이어로전달한다.전송레이어는프로토콜

레이어에XcpCommand()함수를호출하여이메시지에대해통보한다.

>XCP프로토콜레이어가메시지를발신하고자하는경우에는(예를들어마스터에게서

받은 XCP명령어나DAQ메시지에대한응답),이메시지가ApplXcpSend()함수를

호출하여전송레이어로보낸다.

>전송레이어는XcpSendCallBack()함수를호출하여프로토콜레이어에메시지가성공

적으로발신되었음을통보한다.

1015 XCP 구현 사례

Application

XCP Protocol Layer

XCP Transport Layer

Physical Layer

Bus

XcpE

vent

XcpI

nit

XcpB

ackg

roun

d

Appl

XcpG

etPo

inte

r

XcpC

omm

and

Appl

XcpS

end

XcpS

endC

allb

ack

Appl

icat

ion

- XCP

Tra

nspo

rtLa

yer I

nter

face

그림 73:

ECU 코드에

XCP 슬레이브 결합

어플리케이션과프로토콜레이어사이의인터페이스는4가지함수를가지고구현할수있다.

>어플리케이션은XcpInit()를이용해서XCP드라이버를활성화한다.이기능은시작프로세스

도중한번호출한다.

>어플리케이션은XcpEvent()를이용해서XCP드라이버에게특정이벤트가발생했음을

알린다.(예:"계산사이클끝에도달했습니다"등)

>XcpBackground()를호출하여XCP드라이버가백그라운드에서특정활동을실행하도록

한다.(예:체크섬계산하기등)

>A2L파일의주소는항상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은현재체크섬계산이진행중임을나타낸다.

1035.1 함수 설명

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

을이용해한다.가장단순한경우는다음과같다.

/*Defineprotocolparameters*/

#definekXcpMaxCTO8/*MaximumCTOMessageLength*/

#definekXcpMaxDTO8/*MaximumDTOMessageLength*/

#defineC_CPUTYPE_BIGENDIAN/*byteorderMotorola*/

/*Enablememorychecksum*/

#defineXCP_ENABLE_CHECKSUM

#definekXcpChecksumMethodXCP_CHECKSUM_TYPE_ADD14

/*Enablecalibration*/

#defineXCP_ENABLE_CALIBRATION

#defineXCP_ENABLE_SHORT_UPLOAD

/*Enabledataacquisition*/

#defineXCP_ENABLE_DAQ

#definekXcpDaqMemSize(512)/*MemoryspacereservedforDAQ*/

#defineXCP_ENABLE_SEND_QUEUE

CAN전송레이어에대해서는8바이트의적절한CTO/DTO파라미터를설정한다.드라

이버는구동하는플랫폼이모토로라(Motorola)나인텔의바이트순서를따르는지,이경우

에는모토로라의CPU(빅엔디언:BigEndian)를따르는지알고있어야한다.나머지파라

미터들은측정이나캘리브레이션,체크섬계산등의기능을활성화한다.체크섬계산용알

고리즘을구성하고(여기서는모든바이트를DWORD로합산),사용가능한메모리의파라

미터는측정용으로표시한다(여기서는512바이트).메모리는주로DAQ리스트를저장하

고측정도중에데이터를버퍼링하는데사용한다.그러므로이파라미터는측정신호의

가능한최대수를결정한다.필요한파라미터를추정하는데대한보다상세한정보는드

라이버문서에서찾을수있다.

1055.2 드라이버의 파라미터화

106 저자

저자

Andreas Patzer

카를스루에기술대학교에서전기공학을전공한그는측정및제어공학과정보

및산업공학에대해특히전문화된지식을가지고있다.

그는2003년슈투트가르트에소재한벡터에입사하였으며,XCP가ASAM에서

표준화된이래로아주초기부터XCP프로젝트를지원해왔다.그년현재측정/

캘리브레이션제품라인에서고객관리및서비스팀장을맡고있다.

107저자

Rainer Zaiser

슈투트가르트대학교에서전기공학을전공한그는졸업후(1988년가을),바로

벡터에입사했다.그는자동차업계표준인DBC,MDF,CCP, A2L및XCP

확립에크게기여했다.또한,측정및캘리브레이션,네트워크인터페이스제품

라인을이끌고있다.

108 약어 표

약어 표

A2L FileextensionforanASAM2MClanguagefile

AML ASAM2MetaLanguage

ASAM AssociationforStandardisationofAutomationandMeasuringSystems

BYP Bypassing

CAL Calibration

CAN ControllerAreaNetwork

CCP CANCalibrationProtocol

CMD Command

CS Checksum

CTO CommandTransferObject

CTR Counter

DAQ DataAcquisition,DataAcquisitionPacket

DTO DataTransferObject

ECU ElectronicControlUnit

ERR ErrorPacket

EV EventPacket

FIBEX FieldBusExchangeFormat

LEN Length

MCD MeasurementCalibrationandDiagnostics

MTA MemoryTransferAddress

ODT ObjectDescriptorTable

PAG Paging

PGM Programming

PID PacketIdentifier

RES CommandResponsePacket

SERV ServiceRequestPacket

SPI SerialPeripheralInterface

STD Standard

STIM DataStimulationPacket

TCP/IP TransferControlProtocol/InternetProtocol

TS TimeStamp

UDP/IP UnifiedDataProtocol/InternetProtocol

USB UniversalSerialBus

XCP UniversalMeasurementandCalibrationProtocol

Download SendingofdatafromMastertoSlave

Upload SendingofdatafromSlavetoMaster

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:HexWindow 32

그림17:A2L파일에서구한"Triangle"파라미터의주소정보 33

그림18:CANape의Tracewindow내의폴링통신 34

그림19:ECU내의이벤트 35

그림20:A2L의이벤트정의 35

그림21:A2L내의가능한이벤트에"Triangle"할당 36

그림22:각측정파라미터에대한이벤트(측정모드)선택 36

그림23:DAQ측정시CANapeTracewindow의예 37

그림24:ODT:DAQDTO로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:XCPonCAN통신의예 47

그림37:XCPonCAN메시지의예 47

그림38:CANFD프레임의예 48

그림39:노드K와노드L은중복적으로상호접속됨 50

그림40:슬롯정의에의한통신 50

그림41:FlexRay통신매트릭스의예 51

그림42:FlexRayLPDU의예 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를종합적으로지원하는데사용되고있다.

툴

>CANape의주요사용영역은ECU를최적의상태로캘리브레이션하는것이다.이시스템의

런타임중에파라미터값을캘리브레이션하고동시에측정한신호값을획득할수있다.

CANape와ECU의물리적인터페이스는(표준화된모든전송프로토콜에대해)XCP나

CCP를통해이루어진다.

>필요한A2L기술파일을생성하고관리하기위한완전한툴체인(ASAP2 Editor를

포함한ASAP2 Tool-Set와CANape.ASAP2Editor는별도로판매하기도한다.)

>테스트및분석작업을위해ECU내부값에액세스할때CANoe.XCP를사용

ECU 인터페이스

VX1000측정및캘리브레이션하드웨어는ECU에XCP-on-Ethernet인터페이스를갖출

수있는혜택을제공한다.이는POD(Plug onDevice)DAP, JTAG,Nexus등을통해

ECU가컨트롤러에직접적인액세스와연관되어있다. POD는데이터를베이스모듈로

전송하는데,이때베이스모듈은XCP슬레이브로서XCPonEthernet을통해PC의XCP

마스터에데이터를제공한다.이를통해ECU내에는XCP슬레이브가별도로필요로하지

않게된다.사용자는최대30Mbyte/sec의고속데이터처리량과15µs미만의짧은측정

인터벌의혜택을누릴수있다.

임베디드 소프트웨어

CAN과FlexRay,Ethernet용으로별도의전송레이어를갖는통신모듈:

>XCP Basic-www.vector.com/xcp-driver에서무료로다운로드할수있으며,XCP의

기본기능만갖추고있다.XCP프로토콜의구성과전송레이어의수정은소스코드에서

수작업으로한다. XCP 베이직을사용할때에는코드를프로젝트에직접통합시켜야

한다.

>XCP Professional-ASAM규격에따른유용한확장툴들을갖추고있으며,툴을이용한

구성도지원한다.벡터의CANbedded베이직소프트웨어용으로판매된다.

>MICROSAR XCP-XCP프로의기본기능을갖추고있으며,AUTOSAR규격을기반으로

하고있다.벡터의MICROSAR소프트웨어용으로판매된다.

서비스

>프로젝트에서XCP사용에대한컨설팅

>XCP와ECU의통합(Integration)

교육 (독일 본사 교육)

>"XCP Fundamentals Seminar"에서는이프로토콜의기본메커니즘과모델에대해학습할

수있음.

>"CANape with XCP on FlexRay Workshop"에서는FlexRay의기초와XCPonFlexRay의

특수성,특히대역폭의동적관리에대해학습할수있음.

113Appendix-벡터의XCP솔루션

CANape를 이용한 XCP 특별 지원

CANape는XCP1.0규격을지원하는최초의MCD툴이었으며,또한시장에서XCPonFlexRay

마스터기능을최초로제공했다.

XCPonFlexRay의특수기능중하나는동적인대역폭관리(bandwidthmanagement)

기능이다. 여기서 CANape는 FlexRay 클러스터에서 XCP 용으로 제공하는 대역폭을

식별하고,이대역폭을일시적인어플리케이션데이터트래픽에동적으로그리고매우

효율적으로할당한다.그래서사용가능한대역폭은XCP통신에최적화시켜사용하게된다.

더욱이,CANape는DLL인터페이스를가진다.이인터페이스는원하는(사용자가정의한)

전송레이어에서XCP를지원할수있다.이를이용해원하는시험기기나고유프로토콜을

CANape에통합시킬수있다.코드발생기는이런드라이버용으로XCP용코드를생성할

수있도록지원한다.

114 색인

색인

AA2L 9,10,25,33,35,39,40,41,52,

53,57,58,63,65,66,67,68,69,

70,88,102,103,108

Addressextension 29,33,38,101,103

AML 25,68,108

ASAM 7,8,9,55,108

ASAP2Tool-Set 70

BBandwithoptimization 34

Busload 34

BYP 108

Bypassing 44,92,93,94

CCAN 7,8,14,24,29,33,38,45,46,47,

51,69,94,108

CANFD 48

CANape 95

CANoe 95

CANoe.XCP 95

CCP 7,8,39,45,108

CMD 20,25,52,108

Compiling 95

CTO 20,21,22,25,108

CTR 54,55,108

CYCLE_REPETITION 52

DDAQ 22,32,33,34,35,36,37,38,

39,40,41,42,43,44,60,62,71,

93,94,100,102,108

DBC 45

DOWNLOAD 30,31,61

DTO 20,21,22,33,37,38,42,108

EECU 9,68,90,92,93,108

EEPROM 16,31,62

ERR 20,25,28,108

EV 29,108

Event 35,39,41,60,62,71,102

FFIBEX 51,52,53

Flashmemory 16,17,56,57,58,59,62

FLX_CHANNEL 52

FLX_LPDU_ID 52

FLX_SLOT_ID 52

Fullpassing 92

GGET_CAL_PAGE 25,57

GET_DAQ_PROCESSOR_INFO 44,60,71

HHIL 86,89,90,91

LLinking 74,88

LPDU 52

MMIL 87

MTA 30,108

OODT 37,38,39,40,42,43,44,60,

71,108

OFFSET 52

PPAG 108

Page 95

PGM 108

PID 8,19,21,25,42,108

Polling 33,34,36

RRAM 16,17,18,30,31,37,38,39,

58,62,74,76,79,80,82

Reboot 32

RES 20,21,28,52,108

115색인

SSegment 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

TTask 102

TCP/IP 53,54,108

UUDP/IP 53,54,108

USB 55,108

VVN8900 95

VX 94

VX1000 95

Get more Information!

웹사이트에 더욱 상세한 정보가 있습니다.

> 뉴스

> 제품 정보

> 데모 소프트웨어

> 교육 일정

> 문의처

V 2.

0 9/

2014

www.vector.com

xcp - ecu 개발을 위한 표준 프로토콜 · 2018-10-05 · ethernet 표준을 통해...

Documents