정의

상위 계층 프로토콜(higher-layer protocol)은 버스 프로토콜이 규정하지 않는 기능을 그 위에 얹어 제공하는 프로토콜 계층이다. 표준화된 CAN 기반 상위 계층 프로토콜 스택은 대체로 응용 계층과 전송 계층을 구현하며, 표현·세션·네트워크 계층의 일부 기능도 함께 담는다.[1]

CAN이 규정하는 범위는 데이터 링크 계층과 물리 계층까지다(CAN 프로토콜 계층 구조) — 고전 CAN의 데이터 링크 계층은 ISO 11898-1[2]에 국제 표준으로 실려 있다.[3] 그 범위 안에서 한 프레임이 실어 나를 수 있는 데이터는 CAN에서 8바이트, CAN FD에서 64바이트로 묶여 있고[4], 한 서브네트워크에서 다른 서브네트워크로 데이터를 넘기는 절차도 정해져 있지 않다. 이 빈자리를 메우려고 응용과 CAN 사이에 끼워 넣는 것이 상위 계층 프로토콜이다.

확장 과제

OSI 기본 참조 모델은 계층마다 수행하는 기능을 목록으로 정리한다. 연결형 데이터 링크 계층에는 흐름 제어·순서 제어·오류 복구가, 네트워크 계층에는 라우팅과 중계·분할과 블로킹·흐름 제어가, 전송 계층에는 단대단 분할과 블로킹·단대단 흐름 제어·단대단 오류 복구가 들어간다.[5]

CAN이 규정하는 두 계층은 이 목록의 아래쪽 일부만 덮는다. 버스 네트워킹 과제가 정리하는 기본 과제 위에 흐름 제어, 분할(segmenting)과 재조립(reassembling), 서브네트워크 사이의 전달이라는 확장 과제가 남고, 그 각각을 상위 계층 프로토콜이 맡는다.

분할과 재조립

분할은 하나의 서비스 데이터 단위를 여러 프로토콜 데이터 단위로 나눠 싣는 것이다. 나눠 실으면 원래 단위의 경계와 순서를 잃으므로, 각 조각의 프로토콜 제어 정보(PCI)에 복원에 필요한 정보를 함께 넣어야 한다.[5]

CAN에서 이 일을 맡는 것이 전송 프로토콜이다. AUTOSAR의 CAN 전송 계층 모듈은 8바이트(CAN FD에서는 64바이트)를 넘는 데이터 단위를 분할하고 재조립하는 것을 그 주된 목적으로 삼으며, 단일 프레임(SF)·첫 프레임(FF)·연속 프레임(CF)·흐름 제어 프레임(FC) 네 종류의 프레임만 다룬다.[4] 수신 측은 연속 프레임의 순서 번호를 검사한 뒤에야 데이터를 상위 계층으로 올린다.

이 전송 프로토콜을 국제 표준으로 규정한 것이 ISO 15765-2다. 이 표준은 ISO 11898-1이 규정하는 CAN 위에서 동작하는 차량 네트워크의 요구에 맞춰 전송 계층·네트워크 계층 프로토콜과 그 서비스를 규정한다.[6]

분할의 단위와 확인 방식은 프로토콜마다 다르다. CANopen의 서비스 데이터 객체(SDO)는 일반 전송에서 한 세그먼트에 최대 7바이트를 싣고 나머지 1바이트를 프로토콜 정보로 쓰며, 블록 전송에서는 최대 127개 세그먼트를 하나의 블록으로 묶어 수신자가 블록 단위로만 확인하게 해 오버헤드를 줄인다.[7]

흐름 제어

OSI 모델은 흐름 제어를 두 갈래로 구분한다. 피어 흐름 제어는 같은 계층의 두 엔티티 사이에서 프로토콜 데이터 단위 크기를 기준으로 동작하므로 프로토콜에 규정이 있어야 하고, 서비스 경계 흐름 제어는 인접한 두 계층 사이에서 데이터가 건네지는 속도를 조절한다.[5]

계층마다 흐름 제어의 목적도 다르다. 데이터 링크 계층의 흐름 제어는 하나의 데이터 링크 연결 위에서, 즉 맞닿은 두 지점 사이에서 동작한다. 전송 계층의 흐름 제어는 개별 연결에 대한 단대단 흐름 제어여서, 중간 구간이 몇 개든 최종 송신자와 최종 수신자의 처리 속도를 맞추는 것이 목적이다.

CAN 전송 프로토콜에서 이 역할을 하는 것이 흐름 제어 프레임이다. 수신 측이 받아 둘 자리를 마련하지 못하면 오버플로 상태를 실은 흐름 제어 프레임을 보내 그 전송을 중단시킨다.[4]

게이트웨이 전달

CAN 프레임은 송신 노드나 수신 노드의 주소가 아니라 내용으로 구분된다(CAN 메시지 주소 지정).[8] 프레임 안에 경로를 가리키는 정보도 없다. 그래서 서브네트워크 사이의 전달은 프레임을 읽어 경로를 정하는 라우터가 아니라, 여러 버스에 동시에 붙어 있는 게이트웨이 노드의 소프트웨어가 맡는다.

AUTOSAR는 이 기능을 두 수준으로 나눈다. PDU 수준의 게이트웨이는 PDU 라우터 모듈이, 시그널 수준의 게이트웨이는 COM 모듈에 속한 시그널 게이트웨이가 제공한다.[9]

PDU 라우터는 하나의 출발지 버스에서 하나 이상의 목적지 버스로 PDU를 전달한다. 목적지를 정하는 근거는 정적 설정 표에 등록된 PDU 식별자이고, 이 모듈은 PDU의 내용에 좌우되는 라우팅 판단을 하지 않으며 전달하는 PDU를 고치지도 않는다.[10] 경로가 프레임 안이 아니라 설정에 들어 있다는 점이 통신망의 라우팅과 갈리는 지점이다.

지점 간 통신

CAN의 주소 지정은 브로드캐스트다. 특정 노드 하나를 상대로 하는 통신이 필요하면 그 구분을 상위 계층이 따로 마련해야 한다. CAN 전송 프로토콜은 네트워크 목적지 주소에 유형을 붙여 이를 구분한다 — physical 유형은 1대1 통신에 쓰이고 모든 종류의 네트워크 계층 메시지를 지원하며, functional 유형은 1대다 통신에 쓰여 CAN에서는 단일 프레임에만 허용된다.[4] 진단 장비가 특정 ECU의 주소를 알 때는 전자를, 어느 ECU가 응답해야 할지 모르거나 기능이 여러 ECU에 나뉘어 구현돼 있을 때는 후자를 쓴다.

CAN 기반 프로토콜

CAN 위에서 쓰이는 표준화된 상위 계층 프로토콜은 적용 분야에 따라 갈린다.[1]

프로토콜규격주된 적용 분야
CANopen CCCiA 301범용 임베디드 실시간 제어
CANopen FDCiA 1301CAN FD·CAN XL 기반 실시간 제어
J1939 응용 프로파일SAE J1939 계열상용차 등 여러 분야
DeviceNetIEC 62026-3공장 자동화
UAVCAN/DroneCAN무인 항공기

J1939는 SAE International이 1990년대 초에 디젤 파워트레인을 겨냥해 만든 CAN 기반 응용 프로파일이며, 여기서 농림기계(ISO 11783 계열), 트럭·트레일러 통신(ISO 11992 계열), 선박 항법(IEC 61162-3, NMEA 2000), 타코그래프(ISO 16844 계열) 같은 파생 규격이 나왔다.[11]

진단 쪽은 계층이 나뉘어 있다. 전송·네트워크 계층은 ISO 15765-2의 DoCAN이 맡고, 그 위의 응용 계층은 ISO 14229-2(UDS)가 규정한 추상 서비스 프리미티브 인터페이스를 통해 얹힌다.[6] 배기 관련 온보드 진단(ISO 15031 계열)이나 세계 조화 온보드 진단(ISO 27145 계열)처럼 서로 다른 응용 계층이 같은 전송 계층 위에 올라갈 수 있는 것도 이 분리 덕이다.

[1]
CAN in Automation, “Standardized higher-layer protocols.” 2026. Accessed: Aug. 25, 2026. [Online]. Available: https://www.can-cia.org/can-knowledge/standardized-higher-layer-protocols
[2]
International Organization for Standardization, “ISO 11898-1:2024 Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical coding sublayer.” ISO catalogue entry, 2024. [Online]. Available: https://www.iso.org/standard/86384.html
[3]
CAN in Automation, “Controller Area Network classic (CAN CC).” 2026. Accessed: Aug. 25, 2026. [Online]. Available: https://www.can-cia.org/can-knowledge/can-cc
[4]
AUTOSAR, “Specification of CAN Transport Layer,” AUTOSAR, Software specification, 2021. Accessed: Aug. 25, 2026. [Online]. Available: https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_CANTransportLayer.pdf
[5]
International Telecommunication Union, “Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model.” ITU-T Recommendation X.200, Jul. 1994. [Online]. Available: https://www.itu.int/rec/T-REC-X.200-199407-I/en
[6]
International Organization for Standardization, “ISO 15765-2:2024 Road vehicles — Diagnostic communication over Controller area network (DoCAN) — Part 2: Transport protocol and network layer services.” ISO catalogue entry, 2024. [Online]. Available: https://www.iso.org/standard/84211.html
[7]
CAN in Automation, “SDO protocol.” 2026. Accessed: Aug. 25, 2026. [Online]. Available: https://www.can-cia.org/can-knowledge/sdo-protocol
[8]
CAN in Automation, “History of CAN technology.” 2026. Accessed: Aug. 25, 2026. [Online]. Available: https://www.can-cia.org/can-knowledge/history-of-can-technology
[9]
AUTOSAR, “Requirements on Gateway,” AUTOSAR, Requirements specification, 2022. Accessed: Aug. 25, 2026. [Online]. Available: https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SRS_Gateway.pdf
[10]
AUTOSAR, “Specification of PDU Router,” AUTOSAR, Software specification, 2021. Accessed: Aug. 25, 2026. [Online]. Available: https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_PDURouter.pdf
[11]
CAN in Automation, “J1939 profile family.” 2026. Accessed: Aug. 25, 2026. [Online]. Available: https://www.can-cia.org/can-knowledge/j1939-profile-family