10. XCP - 캘리브레이션

XCP - 캘리브레이션 개념

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

특정 파라미터의 최적값은 반복적인 측정과 변경을 통해 구한다.

 

캘리브레이션의 개념은 ECU 개발 및 캘리브레이션 단계에서 ECU에 들어있는 파라미터를 어떻게 수정할 수 있는지에 대한 답변이다.

보통 파라미터는 양산된 ECU의 플래시 메모리에 저장된다.

ECU 개발중 런타임에서 파라미터를 수정할 수 있도록 하려면 RAM 메모리가 추가로 필요하다.

 

캘리브레이션 - 플래시 파라미터

S/W 개발자는 특정 파라미터가 변수인지 상수인지, 다시 말해 플래시메모리에 저장할 것인지 RAM 에 저장할 것인지를 정의한다.

const float factor = 0.5;

"factor" 파라미터는 값이 0.5인 상수를 나타낸다.

코드를 컴파일하고 링크할 때, 메모리 공간은 해당 "factor" 객체용 플래시 메모리에 제공된다.

"factor" 객체에는 플래시 메모리의 데이터영역에 위치한 주소를 할당한다.

0.5란 값은 Hex 파일의 해당 주소에서 찾을 수 있으며, 이 주소는 링커-맵 파일에 있다.

 

캘리브레이션 개념을 쉽게 이해하면, C 코드에서 값을 수정하거나 새로운 Hex 파일을 생성해서 플래싱하는 것이다.→ 유지 관리 및 개발이 힘들다.

모든 값의 변경을 코드에서 해야하며, 그에 따라 컴파일러/링커 작업을 한 뒤 플래싱을 해야 한다.

 

Hex 파일에서 값만 수정한 다음 해당 파일을 플래싱 하는 방법이다. (Hex 파일의 오프라인 캘리브레이션) 

※ 보편적으로 사용

 

파라미터에 대한 플래시 영역 저장 또는 RAM 영역 저장에 대한 확실성을 코드에서 표기할 수 있다.

#pragma section "FLASH_Parameter"
volatile const float factor = 0.5;

→ 컴파일러 별 프라그마 지시어(pragma instruction)를 사용한다.

파라미터를 코드 내에 내장시키는 것을 방지 하려면 상수 파라미터에 "volatile(휘발성)" 속성을 사용하는 것으로 충분하다.

volatile 지시어는 컴파일러의 최적화에서 제외하여, 항상 메모리에 접근하게 한다.

 

캘리브레이션 - RAM 파라미터

런타임에서 파라미터를 변경(온라인 캘리브레이션)에 가장 흔히 사용된느 방법은 사용 가능한 RAM 영역에 해당 파라미터를 생성하는 것이다.

#pragma section "RAM_Parameter"
volatile float factor = 0.5;

컴파일링 & 링킹 과정에서 RAM 영역에 float 형의 factor 객체에 대한 공간을 생성한다. 해당 RAM 주소, Data type, 객체명은 Linker map에 나타낸다.

초기 값인 0.5는 상수 → 플래시 메모리와 Hex 파일의 해당 위치에 저장된다. → 링커의 파라미터 생성과정에 의해 정의하지만, linker map 파일에 나타나지는 않는다.

 

ECU 부팅과정 중 모든 RAM 변수는 flash memory의 초기값으로 초기화된다.

Application은 RAM에 있는 파라미터 값을 사용하게 되며, 이 값은 XCP를 통해 메모리에 정상적으로 액세스 해서 수정 할 수 있다.

 

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

많은 컴파일러들이 최적화를 통해 상수화 시키고, RAM 공간을 최적화 해 버린다. → volatile 속성을 통해 컴파일러 최적화를 피해야 한다.

 

캘리브레이션 툴의 관점에서 바라보면, 파라미터가 위치한 RAM 영역은 캘리브레이션용 RAM(캘리브레이션이 가능한 메모리)으로 불린다.

캘리브레이션 RAM은 완전히 인접한 RAM 영역으로 구성할 필요는 없다.(분산 시키는 것도 가능)

인접한 영역으로 구성하는 경우, Hex 파일을 통한 오프라인 캘리브레이션을 진행할 때, 캘리브레이션 RAM 영역과 기타 파라미터를 위한 영역의 격리는 장점을 갖는다.

 

메모리 세그먼트를 명확하게 정의할 경우(캘리브레이션 RAM영역) 다른 장점은 플래시 메모리에 있는 초기값 저장용 메모리 영역을 오프라인 캘리브레이션에 사용할 수 있다는 점이다.

초기값을 포함하는 Flash 영역을 명확하게 아는 경우, Hex 파일을 통해 그 값을 수정 → 수정한 Hex 파일을 해당 Flash 영역에 플래싱 함으로 서, 초기값을 변경 반영 할 수 있다.

캘리브레이션 툴은 RAM에 있는 파라미터의 위치와 플래시메모리에 있는 초기값도 알아야 한다.

전제조건

• RAM의 메모리 세그먼트를 동일한 구성을 가진 플래시 메모리 세그먼트에서 복사함으로써 초기화 시켜야한다는 것.

RAM에 있는 파라미터의 주소가 A2L 파일에 포함된 경우,

캘리브레이션 용 RAM의 시작주소를 Offset 시킬 값을 적용하면, 해당 플래시 영역의 시작주소에 이 값을 더하게 된다.

이 offset 값을 A2L 파일에 들어있는 각각이 파라미터에 적용한다.

 

그 다음 캘리브레이션 툴은 이 영역에 대해 플래싱 할 수 있는 Hex 파일을 생성하거나 해당 값을 링커의 원래 Hex 파일에 직접 추가하여 파라미터의 초기값을 수정한다.

 

캘리브레이션 - 플래시 오버레이 (Flash Overlay)

많은 마이크로 컨트롤러는 내부나 외부의 RAM을 이용해 플래시 메모리 영역을 오버레이 시키는 옵션을 제공한다.

플래시 에뮬레이션 또는 플래시 오버레이라 불린다.

플래시 오버레이를 사용하기 위해서는 MMU(Memory Management Unit)의 사용에서 부터 전용 메커니즘을 사용하는데 까지 다양한 옵션이 가능하다.

• 플래시 주소와 RAM 주소 사이에 구분이 없다.
  • 플래시 주소는 항상 A2L파일, Hex 파일과 링커-맵(Linker-map) 파일에 존재한다.
  • RAM과 플래시 메모리의 상호관계가 명확해져 Hex 파일은 직접 플래싱 할 수 있고, A2L 파일도 가능하다.
• 오버레이는 전반적으로 활성화하거나 비활성화 할 수 있다.
• 플래시 메모리에 있는 값과 RAM에 있는 값을 스와핑 할 수 있다
  • 메모리 세그먼트의 해당 영역들은 RAM 페이지, 플래시 페이지라 부른다. 
  • XCP에서는 특별 명령어를 통해 두 페이지간의 스와핑을 제어를 지원한다.
• 메모리 페이지는 개별적으로 스와핑 할 수 있다.
• RAM에 오버레이 할 때에는 완전하게 할 필요가 없으며, 이는 어플리케이션에도 적용할 수 있다.
  • 플래시 메모리보다 적은 RAM으로 작업하는 것도 가능하다.

오프라인 캘리브레이션 값을 다운로드 하여 캘리브레이션 툴과 ECU를 연결하는 절차.

1. ECU에 접속 - CONNECT
2. XCP 마스터를 RAM 페이지에 접속 - SET_CAL_PAGE XCP to RAM
3. 체크섬 계산 - CALC_CHECKSUM

메모리 영역에 대한 체크섬 계산에서 차이가 발생하는 경우, 사용자에게 어떻게 처리할 것인지를 묻는다.

ECU RAM의 내용을 마스터로 보내야 하는가?

마스터 페이지에 있는 파일의 내용을 ECU RAM으로 보내야 하는가?

오프라인에서 ECU에 가한 변경내용을 쓰기로 한 경우의 절차.

1. ECU는 플래시 페이지의 데이터 세트를 사용해야 한다. - SET_CAL_PAGE ECU to FLASH
2. 마스터에서 RAM 페이지로 파일 복사 - DOWNLOAD
3. ECU는 RAM 페이지의 데이터 세트를 사용해야 한다. - SET_CAL_PAGE ECU to RAM

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

사용자는 ECU에서 어떤 메모리 페이지를 활성화 할 것인지 명확하게 지시해야 한다.

RAM 파라미터 세트를 플래시 파라미터 와 비교할 수 있으며, 긴급시 플래시 메모리에 들어있는 확인된 파라미터 세트로 복구할 수 있다.

 

캘리브레이션 - 플래시 오버레이의 동적 할당

캘리브레이션 용 RAM의 개념에서는 모든 파라미터에 대해 RAM의 size가 충분하다면 문제가 없다.

파라미터 전체가 사용가능한 RAM 영역에 들어가지 않는 경우는 어떻게 하는가? → 페이지들을 여러개 두고, 활성화 시키는 형태로 진행. – 동적 오버레이

RAM으로 플래시 메모리를 동적으로 오버레이하고, 특정 파라미터에 대해 실제로 쓰기 위해 액세스 할 때까지 관련 플래시 메모리를 RAM으로 오버레이 하는 것이 바람직하다.

XCP 드라이버가 ECU의 플래시메모리에 변경을 가할수 있는 쓰기 액세스를 탐지한 경우, 캘리브레이션용 RAM 영역의 일부를 이용해 플래시메모리의 해당 부분을 복사하고, 이부분에 오버레이 메커니즘을 활성화 한다.

캘리브레이션용 RAM의 자원은 유한하다.

캘리브레이션 프로세스 중에는 이미 할당된 RAM 영역을 해제 할 수 없으며, 사용가능한 캘리브레이션용 RAM은 요청이 있을 때마다 줄어들게 된다.

RAM 자원이 소진되어 새로 할당할 필요가 생기면, 사용자에게 통보한다.

이때 사용자는 플래싱을 하거나, 그 시점까지 만든 모든 변경내용을 저장할 것을 선택한다.

 

이런 조치를 통해, 사용자는 RAM 영역을 확보할 수 있고, 다시 캘리브레이션 작업을 진행할 수 있다.

어떤 경우, RAM 자원이 부족하여 오프라인에서 생성한 파라미터 세트를 다운로드하지 못할 수 있다. → 유일한 대안으로 플래싱이 있다.

사용자는 툴에서 변경내용을 언제든지 취소할 수 있으며, 이때 할당된 RAM 블록은 해제된다.

 

RAM 페이지와 플래시 페이지 사이의 페이지 스와핑도 무제한으로 사용가능하다.

파라미터는 그 기능에 따라 플래시 메모리 내에 조직화 해야하며, 이에 따라 사용가능한 RAM 블록은 가능한 효율적으로 사용할 수 있게 된다.

소프트웨어 개발자는 연관성에 따라 파라미터를 인접한 메모리 영역에 놓이도록 지정한다.

파라미터들은 RAM에 복사한 후 특정 기능을 위해 조율된 파라미터들은 사용할 준비가 된다.

 

캘리브레이션 - RAM 포인터 기반의 캘리브레이션 개념

이 개념은, AUTOSAR 운영체제의 사용을 요구하지 않으며, 아무런 운영체제가 없는 다른 환경에서도 사용 가능하다.

RAM을 플래시 메모리로 대치하는 것이 하드웨어 메커니즘으로 구현되는 것이 아니라, 소프트웨어 매커니즘으로 구현된다.

 

캘리브레이션 파라미터는 ECU 소프트웨어에서 포인터에 의해 항상 참조되고 있다.

플래시 메모리나 RAM에 든 내용은 이 포인터를 변경하여 액세스 할 수 있다.

 

수정할 플래시 파라미터는 사용가능한 RAM을 가지고 지정된 블록에 복사된다.

단일 포인터 개념

포인터 테이블은 RAM에 위치한다.

ECU를 부팅할 때 모든 포인터는 플래시 메모리에 있는 파라미터 값을 나타낸다.

캘리브레이션용 RAM의 위치와 파라미터는 알려졌지만, 부팅후에는 파라미터값이 아직 올라오지 않았다.

처음에는 어플리케이션이 전적으로 플래시메모리에서만 작업한다.

사용자가 부팅 후 처음으로 A2L 파일에서 파라미터를 하나 선택하고 그에 대한 쓰기 Access를 한다면, ECU내에서 복사 작업을 촉발한다.

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

해당 어플리케이션이 파라미터 값을 플래시 메모리가 아니라 RAM 영역에서 가져오게 하도록 포인터 테이블에 변경을 가한다.

 

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

단일 포인터 방식의 단점은 포인터 테이블에 입력한 값이 각각의 파라미터에서 모두 사용가능해야 한다는 점으로, 그에 따른 포인터 테이블용으로 상당량의 추가 RAM이 필요하게 된다.

 

각각의 파라미터에 대한 포인터를 하나씩 만드는 것을 피하기 위해 structure(구조체)를 사용할 수 있다.

각 구조체 마다 포인터가 하나씩 필요.

 

장점 - 파라미터를 선택할 수 있는 포인터의 수가 감소된다. – 메모리의 포인터 테이블 크기를 줄일 수 있다.
단점 - 파라미터 하나를 선택하면, 그 파라미터 뿐 아니라 동일 structure 내에 존재하는 파라미터들이 함께 넘어온다.

       - RAM영역에 좀 더 큰 구조가 복사되므로, RAM의 가용공간(캘리브레이션 용)이 빠르게 한계에 다다를 수 있다.

 

이중 포인터 개념

단일 포인터 개념의 단점은 메모리 페이지 스와핑을 구현하기 쉽지 않다는 것이다.

캘리브레이션 툴은 포인터 테이블을 완전히 페이지 스와핑용으로 기술할 수 있으나, 단기적으로는 일시적인 불일치와 부작용을 초래한다.

포인터 테이블을 선택할 수 있는 테이블 포인터를 사용한다.

파라미터 값은 테이블 포인터를 통해, 어느 포인터 테이블을 사용할지 판단. 해당 포인터 테이블에서 원하는 값을 참조하는 형태로 진행한다.

단점은 낮은 액세스 속도와 더 많은 프로그램 코드를 생성해야 하는 점이다.

 

Reference

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