07. XCP 서비스

XCP를 통해 실현할 수 있는 서비스의 리스트와 그에 대한 설명을 포함한다.

 

XCP 규격은 사실 서비스마다 고유하게 지정된다.

동시에 이런 서비스를 항상 구현할 필요가 있는지, 선택사항인지도 표시되어 있다.

예를 들면, 어떤 XCP 슬레이브는 마스터가 접속에 대해 설정할 수 있도록 "접속"을 지원해야 한다.

반면, XCP를 통한 플래싱은 반드시 필요한 것이 아니고, XCP 슬레이브가 반드시 지원할 필요가 없다.

→ S/W 요구사항에 달린 문제. (아래 소개하는 내용은 모두 선택사항)

 

메모리 페이지 스와핑

캘리브레이션 개념에서 설명 했듯, 파라미터는 보통 플래시 메모리 내에 위치하며, 필요시 RAM으로 복사된다.

어떤 캘리브레이션 개념에서는 RAM과 플래시메모리에 스와핑 메모리 세그먼트 페이지에 대한 선택항목을 제공하기도 한다.

XCP는 일반적인 접근방식을 기술한다.

메모리 세그먼트 하나에는 여러 개의 스와핑이 가능한 페이지가 들어갈 수 있다.

보통 여기에 구성되는 것은 RAM 페이지 하나와 플래시 페이지 하나이다. ; 여러개의 RAM 페이지가 존재하는 경우나, 플래시 페이지가 없는 경우도 생각해 볼 수 있다.

XCP의 관점에서 슬레이브의 메모리는 40Bit(5Byte – Address를 나타내는 크기일 듯.) 폭을 가진 연속 메모리로 구성된다.

메모리의 물리적 레이아웃은 섹터를 바탕으로 한다.

플래시 섹터에 대한 지식은 플래싱을 할 때 꼭 필요한데, 플래시 메모리에서는 한 번에 한 블록만 소거가 가능하기 때문이다.

 

메모리의 논리적 구조는 세그먼트에 바탕을 둔다.

캘리브레이션 데이터가 메모리의 어느 부분에 저장되는지를 기술한다. 한 세그먼트의 시작주소와 파라미터는 물리적 섹터의 시작주소와 파라미터와 동일할 필요가 없다.

각 세그먼트는 여러개의 페이지로 구성된다.

한 세그먼트의 페이지들은 동일한 주소에서, 같은 파라미터를 기술한다.

페이지 내에서 파라미터 값과 읽기 쓰기 권한은 페이지 별로로 제어할 수 있다.

 

세그먼트 내의 특정 페이지에 할당되는 알고리즘은 항상 고유해야 한다.

어떤 특정 시간에 한 세그먼트 내에는 하나의 페이지만 활성화 될 수 있다.

(프로세스와 메모리구조, 메모리 Paging과 유사하다.)

 

이 페이지는 세그먼트 내의 ECU에 대해 활성화 된 페이지라고 불린다.

ECU와 XCP 드라이버가 활발하게 엑세스하는 특정 페이지는 개별적으로 개폐할 수 있다. 이런 설정 사이에는 상호 의존성이 존재하지 않는다.

XCP 액세스를 위해 활성화 된 페이지는 세그먼트 내의 XCP 액세스를 위해 활성화 된 페이지 라고 부른다.

 

세그먼트들은 A2L 파일에 실려야 하며, 각 세그먼트는 고유한 번호를 갖는다.

XCP 슬레이브 내에서 SEGMENT_NUMBER는 항상 0에서 시작하며, Sequential 하게 증가한다.

각 세그먼트는 적어도 하나 이상의 페이지를 갖는다. 이 페이지 또한 숫자로 표현이 가능하다.

최초의 페이지는 0번부터 시작하며, 페이지 번호는 1Byte를 사용하므로, 세그먼트 당 최대 페이지 수는 255개 이다.

 

슬레이브는 모든 세그먼트에서 모든  페이지를 초기화 해야 한다.

마스터는 GET_CAL_PAGE 명령을 통해 슬레이브에게 어떤 페이지가 ECU용으로 활성화 되었고, 또 어떤 페이지가 XCP 액세스 용인지 질의 한다.

이런 경우, 페이지 Access에 대해 상호 블로킹이 필요할 수 있다.

어떤 페이지가 ECU에서 활성화 되어있는 경우, XCP 슬레이브는 ECU에서 활성화 된 페이지에 액세스할수 없을 수 있다. – 의존성이 있을 수 있으나, 반드시 그런 것은 아니다. – 슬레이브 구현에 따라 접근가능할 수 있다.

 

만약 슬레이브가 선택사항인 GET_CAL_PAGE, SET_CAL_PAGE를 지원한다면, 페이지 스와핑이라는 기능도 지원한다.

이 두 명령은 마스터로 하여금, 현재 사용하는 페이지가 어떤 것인지 Polling 하도록 하며 필요시 ECU와 XCP 액세스를 위해 페이지를 스와핑 할 수 있다.

 

XCP 마스터는 페이지 스와핑을 완전히 제어할 수 있다.

XCP 슬레이브는 자체적으로 스와핑을 할 수 없다.

 

스와핑의 이점

• 파라미터 세트 전체를 매우 신속하게 바꿀 수 있다.
• 캘리브레이션 담당자가 ECU의 다른 페이지에서 파라미터 변경을 실시하는 동안 플랜트는 안정된 상태로 남아있다. (Plant ; ECU 에 연결된 다른 기기들... 조향, 서스펜션 등등)

 

메모리 페이지 저장 - 데이터 페이지 프리징

캘리브레이션 담당자가 특정 페이지에 있는 파라미터를 캘리브레이션 할 때, XCP는 데이터를 ECU에 직접 저장할 수 있는 능력이 있다.

RAM 페이지의 데이터를 비 휘발성 메모리에 있는 페이지에 저장하는 것도 포함한다.

 

이때, 비 휘발성 메모리가 플래시 메모리라면, 세그먼트 시작주소와 세그먼트 크기가 반드시 플래시 섹터에 일치할 필요는 없다는 점을 고려해야 하며, 플래시 메모리 소거 및 다시쓰기 문제가 있다는 것을 나타낸다.

 

플래시 프로그래밍

플래싱 : 데이터를 플래시 메모리영역에 쓰는 것을 의미한다.

플래시 메모리는 여러개의 섹터(물리적 구분)로 나뉘며 섹터는 시작주소와 길이로 나타낸다.

섹터를 구분하기위해 식별번호를 가진다.(1Byte → 255개 까지 지원)

 

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

 

플래싱은 플래시 커널을 이용해 구현한다.

플래스 커널은 플래싱을 실제로 실행하기 전에 슬레이브의 RAM 영역에 보내는 실행 코드이다. 이 커널은 XCP 마스터와의 통신도 처리한다.

플래시 메모리를 소거하는 알고리즘도 포함 될 수 있다.

보안과 공간상의 이유로 코드는 ECU 플래시 메모리에 영구적으로 저장되지 않는 경우가 많다. – checksum 계산이나 비슷한 계산이 필요한 경우 컨버터를 사용하기도 한다.

 

XCP로 플래싱할 때 플래시 프로세스는 3개의 영역으로 구분한다.

• 준비 (새로운 내용을 플래싱 할 수 있는지를 점검)
• 실행 (새로운 내용을 ECU로 전송)
• 후처리 (checksum 점검 등)

 

XCP 표준에서는 플래싱의 실행에 초점을 맞춘다.

준비 단계에서 중요한 것 : 새로운 내용이 ECU에 적합한지를 결정하는 것.

 

Command	Operation	Description
PROGRAM_START	플래시 절차 시작	플래시 프로세스의 시작을 나타낸다. ECU가 플래싱을 허용할 수 없는 상태(e.g., 차량속도 > 0)에 있다면, XCP 슬레이브는 오류를 표시해야 한다.
PROGRAM_CLEAR	현재 플래시 메모리 소거 루틴 호출	플래시 메모리에 새로운 내용을 overwrite하기 전에 메모리 소거를 진행한다. 이 명령어를 이용한 소거 루틴의 호출은 ECU에서 구현하거나 플래시 커널의 도움으로 ECU에서 사용가능해야 한다.
PROGRAM_FORMAT	플래시 데이터용 데이터 포맷 선택	XCP 마스터는 슬레이브에 전송할 데이터 포맷을 정의할 때(압축이나 암호화 등) 이 명령어를 사용한다.
PROGRAM	XCP 슬레이브로 데이터 전송	이 명령어를 사용하여 데이터를 XCP 슬레이브로 전송하면 슬레이브는 이 데이터를 플래시 메모리에 저장한다.
PROGRAM_VERIFY	새로운 플래시 내용 점검 요청	마스터는 슬레이브에게 새로운 내용이 OK 인지 확인하기 위해 내부 점검을 실시하도록 한다.
PROGRAM_RESET	슬레이브에 reset 요청	마스터가 슬레이브로 보낸 리셋실행 요청. 슬레이브 접속은 항상 종료되며 새로운 접속명령을 보내야 한다.

슬레이브 자동 탐지.

XCP 프로토콜은 마스터가 프로토콜 특정 특성에 대해 슬레이브에게 폴링을 할 수 있도록 해 준다.

 

 

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

 

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

블록 전송모드 : 대량의 데이터를 전송할 때, 전송절차를 가속화 시킬 수 있다.

UPLOAD, SHORT_UPLOAD, DOWNLOAD, SHORT_DOWNLOAD, PROGRAM 등

마스터는 슬레이브가 이 방식을 지원하는지 GET_COMM_MODE_INFO 요청을 통해 확인할 수 있다.

콜드 스타트 측정 ( Power ON 도중 측정 시작 )

시작 단계 초기에 실행할 수 있는 이벤트의 수동식 측정을 하기는 어렵다.

구성 단계 완료후(initialize) → ECU가 reboot 되어야 한다. → RAM의 데이터가 날아가고, Flash Memory의 초기 데이터로 덮어써 진다.

-- DAQ 리스트의 경우 RAM에 저장되기 때문에 reboot 후에는 남아있지 않는다.

 

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

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

여기에 EEPROM이 사용된다.

XCP의 보안 매커니즘

가능한 비인가 사용자에게 ECU에 접속하지 못하도록 해야한다.

어떤 접속시도가 인가되었는지 확인하는데 "Seed & Key"라는 방법을 사용할 수 있다.

장점

• 측정/ 신호인가 및 캘리브레이션, 플래싱 등 세가지 액세스 유형에서 보호받을 수 있다.

 

작동 순서

1. 마스터로 부터 접속 요청을 받은 슬레이브는 Seed(난수)를 마스터로 보낸다.
2. 마스터는 Key(응답)을 생성하기 위해 특정 알고리즘을 사용한다. 생성된 Key를 슬레이브로 보낸다.
3. 슬레이브는 예상 Key를 계산하고, 마스터로부터 전달된 Key와 비교한다.
4. 결과가 같은 경우 인가된 접속으로 판단하여 접속을 승인한다. - 결과가 다른경우, 접속 거절

보통 이 알고리즘은 마스터에서 DLL로 이용한다.

만약 어떤 사용자가, Seed & Key DLL과 A2L을 가지고 있다면 ECU 메모리에 액세스 할 수 있다.

때문에 ECU가 양산단계에 도달하면 XCP 드라이버를 비활성화 시킨다.

 

Reference

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