ISO 15765-2
ISO 15765-2 | 이 글은 검증을 위해 인용구가 추가로 필요하다.– · · 책· · (1919년 6월)(이 메시지 |
ISO 15765-2 [1]또는 ISO-TP(Transport Layer)는 CAN-Bus를 통해 데이터 패킷을 전송하기 위한 국제 표준이다. 이 프로토콜은 CAN 프레임의 최대 페이로드 8바이트를 초과하는 메시지의 전송을 허용한다. ISO-TP는 긴 메시지를 여러 프레임으로 분할하여 개별 프레임을 해석하고 수신인에 의한 완전한 메시지 패킷으로 재조립할 수 있는 메타데이터를 추가한다. 메시지 패킷당 최대 4095바이트의 페이로드를 운반할 수 있다.
OSI 모델에서 ISO-TP는 계층 3(네트워크 계층)과 4(트랜스포트 계층)를 커버한다.
ISO-TP의 가장 일반적인 애플리케이션은 KWP2000과 UDS를 이용하여 OBD-2가 장착된 차량과의 진단 메시지 전송이지만, 다른 애플리케이션별 CAN 구현에서 광범위하게 사용된다.
ISO-TP는 자체 주소 지정(Extended Addressing) 또는 주소 없이 CAN ID(Cannormal Addressing)만 사용하여 작동할 수 있다. 확장 어드레싱은 각 프레임의 첫 번째 데이터 바이트를 주소의 추가 요소로 사용하여 애플리케이션 페이로드(payload)를 1바이트로 줄인다. 명확하게 하기 위해 아래의 프로토콜 설명은 8바이트 CAN 프레임의 정상 주소 지정에 기초한다. 총 6가지 유형의 어드레싱은 ISO 15765-2 프로토콜에 의해 허용된다.
ISO-TP는 8바이트 CAN 프레임에서 하나 이상의 메타데이터 바이트를 페이로드 데이터에 미리 입력하여 페이로드 수를 프레임당 7바이트 이하로 줄인다. 메타데이터를 프로토콜 제어 정보, 즉 PCI라고 한다. PCI는 1바이트, 2바이트 또는 3바이트 입니다. 초기 필드는 프레임 유형을 나타내고 PCI 길이를 암시적으로 설명하는 4비트다.
ISO 15765-2는 ISO 15765(헤드라인 도로 차량 - DoCAN(Controller Area Network)을 통한 진단 통신)의 일부로서 다음과 같은 부분이 있다.
- ISO 15765-1 제1부: 일반 정보 및 사용 사례 정의
- ISO 15765-2 제2부: 전송 프로토콜 및 네트워크 계층 서비스
- ISO 15765-3 제3부: CAN 상의 UDS(통합 진단 서비스) 구현 - ISO 14229-3 도로 차량으로 대체 - 통합 진단 서비스
- ISO 15765-4 제4부: 배출 관련 시스템 요구 사항
프로토콜 제어 정보 필드 유형 목록
ISO-TP는 네 가지 프레임 유형을 정의한다.
| 유형 | 코드 | 설명 |
|---|---|---|
| 단일 프레임(SF) | 0 | 전송된 단일 프레임에 최대 7바이트(일반 주소 지정) 또는 6바이트(확장 주소 지정)의 전체 페이로드 포함 |
| 첫 번째 프레임(FF) | 1 | 6/7바이트 이상의 데이터 분할 시 사용되는 더 긴 다중 프레임 메시지 패킷의 첫 번째 프레임. 첫 번째 프레임은 초기 데이터와 함께 전체 패킷의 길이를 포함한다. |
| 연속 프레임(CF) | 2 | 다중 프레임 패킷에 대한 후속 데이터가 포함된 프레임 |
| 흐름 제어 프레임(FC) | 3 | 퍼스트프레임 세그먼트를 승인하는 수신기의 응답 연속된 프레임의 전송을 위한 파라미터를 설정한다. |
| 4..15 | 예약됨 |
| 비트 오프셋 | 7 .. 4 (바이트 0) | 3 .. 0 (바이트 0) | 15 .. 8 (바이트 1) | 23..16 (바이트 2) | .... |
|---|---|---|---|---|---|
| 싱글 | 0 | 크기(0..7) | 데이터 A | 데이터 B | 데이터 C |
| 먼저 | 1 | 사이즈 (8..4095) | 데이터 A | 데이터 B | |
| 연속 | 2 | 색인(0..15) | 데이터 A | 데이터 B | 데이터 C |
| 흐름 | 3 | FC 플래그(0,1,2) | 블록 크기 | 세인트 | |
초기 바이트에는 유형(0)과 페이로드 길이(1-7바이트)가 포함된 7바이트 이하의 메시지가 단일 프레임으로 전송된다. 형식 필드에서 0을 사용하는 경우 이는 길이 데이터 형식의 보다 단순한 프로토콜로도 통과될 수 있으며, 종종 그렇게 잘못 해석된다.
7바이트보다 긴 메시지는 메시지 패킷을 여러 프레임에 걸쳐 분할해야 한다. 분할된 전송은 첫 번째 프레임으로 시작한다. 이 경우 PCI는 2바이트로, 처음 4비트 필드는 유형(유형 1)과 다음 12비트 메시지 길이(유형 및 길이 바이트 제외)이다. 수취인은 흐름 제어 프레임으로 이전을 확인한다. 플로우 제어 프레임에는 후속 프레임 사이의 간격과 연속적인 프레임 전송 가능 수(블록 크기)를 지정하는 3개의 PCI 바이트가 있다.
| 비트 오프셋 | 7 .. 4 (바이트 0) | 3 .. 0 (바이트 0) | 15 .. 8 (바이트 1) | 23..16 (바이트 2) |
|---|---|---|---|---|
| 설명 | 타자를 치다 | 양도가 허락되면. | 블록 크기 | 분리 시간(ST), 프레임 간 최소 지연 시간(한 프레임의 끝과 다른 프레임의 시작) |
| 싱글 | 유형 = 3 | (0 = 계속 전송, 1 = 대기, 2 = 오버플로/어브) | 0 = 흐름 제어 또는 지연 없이 전송될 나머지 "기존" | <= 127, 분리 시간(밀리초). |
| 싱글 | 유형 = 3 | (0 = 계속 전송, 1 = 대기, 2 = 오버플로/어브) | > 다음 흐름 제어 프레임을 기다리기 전에 0의 "수신" 번호를 전송 | 0xF1 ~ 0xF9 UF, 100 ~ 900마이크로초. |
초기 바이트에는 처음 4비트의 유형(유형 = 3)과 전송이 허용되는지 여부를 나타내는 다음 4비트의 플래그가 포함되어 있다(0 = 전송하기 위해 지우기, 1 = 대기, 2 = 오버플로/어보트). 다음 바이트는 블록 크기, 즉 다음 흐름 제어 프레임을 대기하기 전에 보낼 수 있는 프레임 수입니다. 값이 0이면 나머지 프레임을 흐름 제어나 지연 없이 보낼 수 있다. 세 번째 바이트는 프레임 사이의 최소 지연 시간인 분리 시간(ST)이다. 최대 127 (0x7F)의 ST 값은 프레임 간에 지연할 최소 밀리초 수를 지정하는 반면, 241 (0xF1) ~ 249 (0xF9) 범위의 값은 100 ~ 900 마이크로초로 증가하는 지연을 지정한다. 분리 시간은 한 프레임의 끝에서 다음 프레임의 시작 사이의 최소 시간으로 정의된다는 점에 유의하십시오. 이를 프레임 반복률(즉, 프레임 시작부터 프레임 시작까지)으로 오해하는 송신자의 프레임을 수용하기 위한 강력한 구현이 준비되어야 한다. 신중한 구현도 물리적 계층에서 비트 스터핑의 사소한 영향을 설명하지 못할 수 있다.
발신인은 연속 프레임을 사용하여 메시지의 나머지 부분을 전송한다. 각 연속 프레임에는 1바이트 PCI가 있으며, 4비트 유형(유형 = 2)에 이어 4비트 시퀀스 번호가 있다. 시퀀스 번호는 1에서 시작하여 전송되는 각 프레임(1, 2,..., 15, 0, 1,...)에 따라 증가하며, 이 경우 손실되거나 버려진 프레임을 감지할 수 있다. 각 연속 프레임은 0에서 시작되며, 첫 번째 프레임의 첫 번째 데이터 집합에 대해 처음에는 0번째 데이터로 간주된다. 그래서 첫 번째 세트의 CF는 "1"에서 시작한다. 이후 "15"가 되면 "0"부터 시작할 것이다. 12비트 길이 필드(FF)는 분할된 메시지에서 최대 4095바이트의 사용자 데이터를 허용하지만, 실제로는 수신 버퍼 또는 하드웨어 제한 때문에 일반적인 애플리케이션별 제한이 상당히 낮다.
타이밍 파라미터
P1 및 P2 타이머와 같은 타이밍 파라미터가 언급되어야 한다.
표준
ISO 15765-2:2016 도로 차량 - DoCAN(Controller Area Network)을 통한 진단 통신 - 제2부: 전송 프로토콜 및 네트워크 계층 서비스
참조
- ^ 14:00-17:00. "ISO 15765-2:2016". ISO. Retrieved 2019-04-05.
{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
