DTO (Data Transfer Object) 는 동기화 측정/캘리브레이션 데이터를 교환하는데 사용할 수 있다.
슬레이브에서 보낸 데이터는 DAQ 를 통해 마스터로 전송되는데, 이 때 데이터는 내부 이벤트에 동기화 된다.
DTO 통신이 이루어지는 2단계는 다음과 같다.
- 초기화 단계 : 마스터는 슬레이브와 통신하여 데이터를 전송한다. 슬레이브는 다른 이벤트를 위해 데이터를 전송한다.
- 실제 측정단계 : 마스터는 슬레이브에 측정을 시작하라는 명령을 보낸다. 슬레이브는 실제 측정을 시작하며, 정해진 시점마다 마스터에게 측정된 데이터를 보낸다. (마스터에서 측정 중지 명령 이전까지, 마스터는 이 동안만 수신한다.)
측정 데이터의 획득 및 전송의 시작은 ECU 이벤트에 의해 제어된다.
마스터는 STIM 을 통해 데이터를 슬레이브로 보낸다.
마스터가 슬레이브와 통신하여, 데이터를 슬레이브로 보낸다. 이 단계 이후, 마스터가 슬레이브로 데이터를 보내고 STIM Processor 는 데이터를 저장한다. 관련한 STIM 이벤트가 슬레이브에서 시작되면 데이터는 Application Memory 로 전송된다.
측정 방법 : Polling vs DAQ
폴링 (Polling) 은 DTO 에 기반을 둔 것이 아니라 CTO 에 기반을 둔다.
마스터는 슬레이브에서 측정 파라미터 값을 요청할 때, SHORT_UPLOAD 명령어를 사용할 수 있다. (폴링)
슬레이브는 SHORT_UPLOAD 명령어를 수신하고 실행하는 시점의 파라미터 측정값을 Response 로 보내는 것이다.
XCP 표준에는 폴링에 대한 요건을 정하고 있다. (각 측정 파라미터의 값은 개별적으로 폴링)
폴링 방식의 단점
- 불필요하게 많은 데이터 트래픽을 초래
- 폴리을 통해 측정한 각각의 값에 대해 마스터가 슬레이브에 요청한 값과 마스터로 보낸 응답, 2개의 메시지가 버스를 통해 전달되어 버스에 부하가 추가로 걸림 - ECU 내의 프로세스의 흐름과 관련하여 평가 불가능.
- 데이터 값을 폴링할 때, 사용자는 보통 측정 데이터를 동일한 주기로 지속적으로 수신하여 값을 비교하고자 하는데, 폴링 방식으로 데이터를 측정할 경우, 마스터가 전송한 CTO Message 의 수신에 따른 측정이 진행 되므로, 측정 데이터가 ECU 의 계산 사이클에서 나온 것이 아님으로 사용자가 원하는 데이터가 아닐 수 있다.
따라서, 최적화된 측정은 앞의 폴링 방식의 2가지 단점을 해결해야 한다.
- 측정 중 대역폭 최적화
- 데이터 대비의 보장 (Synchronize)
DAQ 측정 방법
DQA 방법은 폴링의 두 가지 문제를 다음과 같이 해결한다.
- 측정값의 대비는 ECU의 이벤트에 대한 측정값 획득과 연결하여 해결한다. 모든 계산이 완료되었음이 확인 될 때 까지 측정값을 획득하지 않는다.
- 버스의 부하를 줄이기 위해 측정 프로세스를 2 단계로 나눈다.
- 구성 단계 : 마스터가 슬레이브에게 관심있는 값이 무엇인지 문의
- 전송 단계 : 슬레이브의 측정값을 마스터에 전송
E1 : 계산 사이클의 완료 이벤트
슬레이브 내의 알고리즘이 "계산 사이클 완료" 에 도달하면 (이벤트 E1 발생), XCP 슬레이브는 측정 파라미터 값을 수집 (x, y 파라미터 값)하고, 수집한 값을 버퍼에 저장 후 마스터로 보낸다.
※ 슬레이브가 특정 이벤트에 어떤 파라미터를 측정해야 하는지 알고 있다고 가정
※ 이벤트는 반드시 순환적이거나 동시적일 필요는 없음
A2L에서의 이벤트정의
사용자는 신호를 선택한다. - 실제 측정 객체 이외에 사용자는 측정 파라미터에 대한 하부 이벤트를 선택해야 한다.(파라미터와 이벤트 매핑)
정상적인 경우, 하나의 측정값을 여러개의 이벤트에 동시에 할당하는 것이 아무런 의미가 없다.
하나의 파라미터는 단일 사이클(예, 10ms 간격에서만)내에서만 수정할 수 있고, 여러 사이클(10ms와 100ms 사이)에서는 할 수 없다.
측정 파라미터는 사용자가 측정을 구성하면서 ECU의 이벤트에 할당한다.
측정한 신호를 구성한 후, 사용자는 측정을 시작한다.
XCP 마스터는 원하는 측정 파라미터를 DAQ 리스트로 알려진 리스트에 열거한다.
DAQ 리스트에는 측정한 신호가 선택된 이벤트에 각각 할당되어 있다.
해당 구성정보는 측정을 실제로 시작하기 전에 슬레이브로 보낸다. → 슬레이브가 어떤 이벤트가 발생하였을때, 어떤 주소에서 데이터를 읽어 전송해야 하는지 알게 된다.
이 방법은 Polling에서 발생하는 두가지 문제를 모두 해결한다.
> 측정 도중 마스터가 각각의 값을 폴링할 필요가 없으므로, 대역폭을 최적화 하여 사용한다.
> 측정 값은 상호간에 대비가 된다. – 센서 값에 대한 처리 (예, x : 센서값, y = 2x+1, y가 계산 되기 전에 폴링하는 경우의 문제점.)
사용자는 신호를 선택하고 이 값을 측정하고자 한다.
신호 값을 보내는 것은 메시지 전체를 사용할 필요가 없다. – 슬레이브에서 나온 신호는 메시지 패킷으로 결합한다.
슬레이브는 독자적으로 메시지 패킷에 대한 결합을 정의할 수 없다. (마스터가 해석 불가능)
슬레이브는 측정값들을 메시지에 결합하는 순서를 ODT(객체 기술 테이블; Object Description Table)에 정의된 것으로 사용한다.
주소와 객체의 길이는 측정할 객체를 식별하는데 중요하다.
ODT는 버스를 거쳐 온 메시지를 조립하기 위해 슬레이브에서 RAM의 내용을 할당한다. >> DAQ DTO(데이터 전송객체)로 전송된다.
Measurement Start Command → Event Occur → Collect Data(Object) → Assemble to Packet(with. ODT) → Send to Master → Extract to Object(with ODT)
ODT는 XCP 프로토콜의 DAQ List에 포함된다.
각 DAQ List는 하나이상의 ODT가 포함되며, 이는 하나의 이벤트에 배정된다.
이벤트 : DAQ List → 1:1
DAQ List : ODT → 1:N
사용자가 두 개의 측정간격(e.g., 10ms, 100ms)을 사용한다면(ECU에서 2개의 다른 이벤트), DQA 리스트도 2 개가 사용되어야 한다.
사용한 이벤트마다 하나의 DAQ리스트가 필요하다.
각 DAQ 리스트에는 ODT에 관련된 입력값이 실려있으며, 각 ODT에는 RAM Cell에 들어있는 값에 대한 참조 값(address)이 들어있다.
DAQ 리스트의 유형 : 정적(static), 사전정의(predefined), 동적(dynamic).
정적인 DAQ 리스트
DAQ 리스트와 ODT 테이블이 CCP(CAN Calibration Protocol)처럼 ECU에 영구적으로 정의되어 있다면, 이를 정적인 DAQ 리스트라고 한다.
어떤 측정파라미터가 ODT 리스트에 들어있는지에 대한 정의는 없고, 채울 수 있는 Framework만 존재한다.
정적인 DAQ 리스트에는 이 정의가 ECU 코드에 설정되어 있으며, A2L에 기술되어 있다.
정적 DAQ List의 예
0번 DAQ List는 10ms 이벤트에 할당 되었으며, 최대 2개의 ODT를 return 할 수 있다.
1번 DAQ List는 100ms 이벤트에 할당 되었으며, 최대 4개의 ODT를 return 할 수 있다.
A2L 파일은 ECU의 내용에 정합한다.
정적인 DAQ 리스트의 경우 DAQ 리스트의 수와 이들이 각각 담고있는 ODT 리스트는 ECU에 어플리케이션을 다운로드하여 정의한다. (코드에 박혀있는 듯 하다.)
만약 사용자가 한 이벤트에서 할당된 DAQ 리스트에 실린 것 보다 많은 수의 신호를 측정하려고 시도한다면, ECU 슬레이브는 이 요구사항을 충족할 수 없으며 오류가 발생한다.
다른 DAQ 리스트가 아직 사용 가능한지, 실제로 전송능력이 있는지는 상관없다.
사전정의된 DAQ 리스트
완전히 사전에 정의한 DAQ 리스트도 ECU 내에서 설정할 수 있다.
>> 이 방식은 사용자들에게 융통성이 부족하다는 이유로 실질적으로 ECU에 사용된 적이 없다.
동적인 DAQ 리스트
XCP 프로토콜의 한 가지 특별한 점은 동적인 DAQ 리스트이다.
ECU 코드에 영구적으로 정의되어있는 DAQ의 절대 파라미터와, ODT 리스트가 아니라 DAQ 리스트가 사용할 수 있는 메모리영역의 파라미터에 불과하다. → 메모리에 특정 space를 동적 ODT를 위한 공간으로 확보해 두고, address로 접근할 것 같다.(Heap 영역과 유사)
동적 리스트의 장점은 측정 툴이 DAQ 리스트를 만들 때 좀 더 많은 자유(latitude)를 가지고 있으며, DAQ 리스트의 구조를 동적으로 관리할 수 있다는 점이다.
마스터가 슬레이브내의 DAQ 리스트의 구조를 정의하는데 사용할 수 있는 함수는 ALLOC_ODT 와 같이 동적 관리를 위해 설계한 다양한 함수가 XCP에 나와있다.
마스터는 DAQ리스트를 만들 때 사용하는 DAQ 리스트가 동적인지, 정적인지, DAQ 리스트의 파라미터와 구조가 어떤 모양인지 등을 구별할 수 있어야 한다.
STIM 캘리브레이션 방법
캘리브레이션 유형은 모든 XCP 드라이버에 존재하고 있으며, ECU의 캘리브레이션 객체에 대한 근간을 이루고 있다.
캘리브레이션 명령어를 보내는일과 ECU 내의 이벤트 사이에는 동기화가 이루어지지 않는다. ( CTO 를 통한 캘리브레이션 방식 )
STIM을 사용하는것은 CTO 교환을 바탕으로 하지 않으며, 슬래이브 내의 이벤트 동기화 하는 통신에서 DTO를 사용하는데 바탕을 두고 있다.
마스터는 슬레이브 내에 어떤 이벤트를 동기화 시킬 수 있는지 알고 있어야 한다. → a2L 파일에 기술되어있어야 한다.
마스터가 STIM으로 슬레이브에 데이터를 보낼 때, XCP 슬레이브는 반드시 패킷 내에서 캘리브레이션 파라미터를 찾을 수 있는 위치(address)를 보내야 한다. :: DAQ 리스트와 동일한 메커니즘.
DAQ와 STIM에 대한 XCP 패킷 지정
CTO를 전송하는데에는 PID 만으로 패킷 식별이 가능하다.
DTO 전송시에는 PID만으로는 부족하다.
DAQ 리스트의 ODT들의 PID를 관리하는 방법.
전송 유형 :: 절대 ODT 값.
절대(absolute)라는 의미는 해당 ODT 수가 통신 전반에 걸쳐, 모든 DAQ 리스트에서 고유하다는 뜻이다.
절대 ODT 값을 사용한다는 것은 DAQ 리스트에 대한 FIRST_PID를 이용하는 전환단계를 가정한다는 뜻이다.
FIRST_PID = x 라 하면, 첫 패킷의 PID는 x, 두 번째 패킷의 PID는 x+1, 세 번째 패킷의 PID는 x+2가 되는 식이다.
슬레이브는 FIRST_PID + 상대 ODT값의 합이 다음 DAQ 리스트의 PID 보다 낮도록 해야 한다.
DAQ 리스트 : 0 <= PID <= K
DAQ 리스트 : K+1 <= PID <= M
DAQ 리스트 : M+1 <= PID <= N 등.
Identification Field가 간단하다.
전송 유형 :: 상대 ODT 값과 절대 DAQ 리스트 수
DAQ 리스트 수와 ODT 수는 식별 필드로 전송할 수 있다. – 해당 정보에 사용할 수 있는 바이트 수가 남아있다.
PID : 1번 DAQ List에서 몇번째인지 Index를 나타낸다.
DAQ : DAQ List 들 중에서 몇번째인지를 나타낸다.(절대값. – Unique)
1 바이트는 DAQ 수로 나타낼 수 있으며, 1 바이트는 ODT 수로 나타낼 수 있다. – DAQ LIst의 최대 수는 2 바이트를 사용해서 전송할 수 있다.
3바이트를 보내는 것이 불가능 하다면, FILL 바이트 1개를 추가하여 4바이트로 작업할 수 있다. – FILL BYTE는 Alignment에 사용한다.
XCP 마스터가 슬레이브를 어떤 방법으로 사용하는지 아는 방법
- a2L 파일에 입력
- 어떤 통신 버전을 구현하고 있는지 슬레이브에 요청.
GET_DAO_PROCESSOR_INFO 요청에 대한 응답은 슬레이브가 어떤 전송유형을 사용하고 있는지 마스터에게 통지한다.
DAQ 수의 BYTE 수도 정한다. (최대 2.)
DAQ만 사용하는 것이 아니라, STIM에도 사용하는 경우, 마스터는 슬레이브가 DAQ를 위해 사용하는 것과 같은 방법을 STIM에 사용해야 한다.
바이패싱 = DAQ + STIM
바이패싱은 DAQ와 STIM을 함꼐 사용하여 구현할 수 있다.
래피드 프로토타이핑 솔루션의 특수한 형태를 나타낸다.
Reference
Andreas Patzer, Rainer Zaiser, XCP-ECU 개발을 위한 표준 프로토콜 - 프로토콜 기초와 응용분야 (Vector, 2014)
'기타 > XCP (파라미터 측정 및 캘리브레이션)' 카테고리의 다른 글
07. XCP 서비스 (0) | 2022.01.04 |
---|---|
06. XCP 전송 레이어 (0) | 2022.01.04 |
04. CTO 교환 (0) | 2022.01.03 |
03. XCP 프로토콜 레이어 (1) | 2022.01.02 |
02. XCP 프로토콜의 기초 (1) | 2022.01.02 |