AUTOSAR를 공부할 때 많은 개발자가 가장 먼저 혼란을 느끼는 부분은 통신 모듈 구조이다.
COM, PduR, CanIf, CanTp, CanNm, Can Driver 등 여러 모듈 이름은 자주 보이지만,
각각이 어떤 역할을 하고 서로 어떻게 연결되는지 한 번에 이해하기는 쉽지 않다.
특히 설정 툴에서 모듈이 각각 분리되어 보이기 때문에 개별 설정은 따라 할 수 있어도,
전체 데이터 흐름과 구조를 이해하지 못하면 Generate 오류나 통신 문제를 분석하기 어려워진다.
이번 글에서는 첨부한 구조도를 기준으로 AUTOSAR CAN 통신 스택이 어떤 계층으로 나뉘어 있으며, 각 모듈이 어떤 역할을 담당하는지 설명한다.
1. AUTOSAR 통신 구조는 계층 구조이다.
위 그림은 AUTOSAR 전체 구조 중 CAN 통신 중심으로 보여주는 그림이며, 아래 그림은 CAN 통신 중심 구조도이다.
즉, CAN 메시지 송수신에 필요한 모듈들을 계층별로 나누어 표현한 그림이다.
이 구조는 아래에서 위로 보면 이해하기 쉽다.
Hardware→ Driver→ Hardware Abstraction→ Communication Services
맨 아래는 실제 하드웨어이고, 위로 올라갈수록 하드웨어와 독립적인 소프트웨어 계층이 된다.
즉, 물리적인 CAN 통신은 아래 계층에서 수행되고, 데이터 관리와 통신 정책은 위 계층에서 처리된다.
2. Hardware Layer
가장 아래 계층은 실제 MCU와 통신 주변장치 영역이다.
여기에는 다음 요소가 포함된다.
- Microcontroller
- CAN Controller
- SPI Interface
- External CAN Controller
이 계층은 실제 전기 신호를 송수신하는 물리적 장치이며, AUTOSAR 상위 모듈은 이 하드웨어를 직접 다루지 않는다.
3. Communication Drivers Layer
이 계층은 하드웨어를 직접 제어하는 드라이버 영역이다.
대표적으로 다음 모듈이 포함된다.
- CAN Driver
- SPI Handler Driver
- DIO Driver
CAN Driver는 실제 CAN Controller를 제어하는 핵심 드라이버이며 주요 역할은 아래와 같다.
- CAN 송신 요청 수행
- 수신 데이터 읽기
- Mailbox 제어
- Baudrate 설정
- Interrupt 처리
- Controller 상태 제어
즉, 실제 CAN 프레임을 버스로 내보내거나 수신하는 마지막 소프트웨어 계층이다.
SPI Driver / DIO Driver는 외부 CAN Controller, Transceiver, ASIC 등을 제어할 때 사용된다.
프로젝트 하드웨어 구성에 따라 필요 여부가 달라진다.
4. Communication Hardware Abstraction Layer
이 계층은 CAN, LIN 등 다양한 통신 버스의 하드웨어 차이를 상위 계층에서 보이지 않도록 추상화하는 역할을 한다.
즉, 상위에서는 물리적인 CAN 컨트롤러나 LIN 드라이버를 직접 다루지 않고, 동일한 인터페이스로 통신 기능을 사용할 수 있게 만든다.
이 계층 덕분에 상위 COM/PDU/RTE 계층은 버스 종류와 무관하게 동일한 방식으로 메시지를 송수신할 수 있다.
대표 모듈은 CAN 통신의 경우 CanIf (CAN Interface) 이며,
이 모듈이 CAN Driver와 COM 계층 사이에서 데이터 전달을 중계하는 역할을 수행한다.
5. CanIf (CAN Interface)
CanIf는 AUTOSAR CAN 통신 구조에서 가장 중요한 중간 계층 중 하나이다.
상위 모듈은 CAN Driver를 직접 호출하지 않고 CanIf를 통해 통신 기능을 사용한다.
즉, 상위 계층과 하드웨어 사이의 표준 인터페이스 역할을 수행한다.
주요 기능은 다음과 같다.
- 송신 요청 전달
- 수신 데이터 상위 전달
- PDU 식별 및 매핑
- Controller Mode 관리
- Upper Layer 연결
CanIf가 존재하기 때문에 MCU나 Driver 구현이 달라져도 상위 모듈은 동일한 방식으로 CAN 통신을 사용할 수 있다.
6. Communication Services Layer
이 계층은 실제 AUTOSAR 통신 기능을 담당하는 상위 서비스 계층이다.
프로젝트 설정의 대부분이 이 영역에서 이루어진다.
첨부 그림에 표시된 주요 모듈은 다음과 같다.
- COM
- PduR (PDU Router)
- CanTp (CAN Transport Protocol)
- CanSM (CAN State Manager)
- CanNm (CAN Network Manager)
- ComM (Communications Manager)
- Generic NM Interface
7. COM
COM은 Application 데이터와 CAN 메시지를 연결하는 핵심 모듈이다.
상위 기능 로직에서 전달된 값을 Signal 단위로 관리하고, 이를 CAN Payload 형식으로 구성한다.
주요 역할은 다음과 같다.
- Signal 관리
- Bit 위치 계산
- Packing / Unpacking
- Endian 처리
- Timeout 관리
- Update Bit 처리
- 송신 Trigger 처리
즉, COM은 데이터를 통신 가능한 형태로 변환하는 계층이다.
8. PduR (PDU Router)
PduR은 이름 그대로 데이터 라우터이다.
각 모듈에서 생성된 PDU를 목적지 모듈로 전달한다.
예를 들어 COM에서 생성된 데이터는 PduR을 통해 CanIf로 전달되고, 진단 데이터는 CanTp로 전달될 수 있다.
PduR의 핵심 목적은 모듈 간 직접 연결을 줄이고 구조를 단순화하는 것이다.
9. CanTp (CAN Transport Protocol)
CAN 기본 프레임은 길이에 제한이 있기 때문에 긴 데이터를 전송하려면 분할 전송이 필요하다.
CanTp는 이러한 다중 프레임 전송을 담당한다.
즉, 긴 데이터를 여러 프레임으로 나누어 보내고, 수신 측에서 다시 조립하는 역할을 한다.
주로 진단 통신에서 사용된다.
10. CanSM (CAN State Manager)
CAN 네트워크의 동작 상태를 관리하는 모듈이다.
예를 들어 CAN Controller의 시작, 정지, Sleep, Wakeup과 같은 상태 전환을 제어한다.
통신이 가능한 상태인지, 네트워크를 종료해야 하는지 등을 판단하는 관리 계층이라 볼 수 있다.
11. CanNm (CAN Network Management)
차량 네트워크에서 여러 ECU가 함께 동작하기 위해서는 네트워크 상태를 관리해야 한다.
CanNm은 ECU 간 네트워크 활성 상태를 유지하고, Sleep 전환 여부를 판단하는 역할을 한다.
즉, 단순 메시지 송수신이 아니라 전체 네트워크 생명주기를 관리하는 기능이다.
12. ComM (Communication Manager)
ComM은 상위 관점에서 통신 모드를 관리한다.
대표적으로 다음 상태를 제어한다.
- Full Communication
- Silent Communication
- No Communication
네트워크를 활성화할지, 절전 상태로 전환할지 결정하는 정책 관리자 역할을 한다.
13. 실제 데이터 흐름은 어떻게 움직이는가?
AUTOSAR CAN 통신 구조에서 데이터는 아래 순서로 이동한다.
송신 흐름
COM→ PduR→ CanIf→ CAN Driver→ Hardware
수신 흐름
Hardware→ CAN Driver→ CanIf→ PduR→ COM
즉, 상위 계층은 데이터를 만들고, 하위 계층은 실제 전송을 수행한다.
14. 이 구조를 이해해야 하는 이유
AUTOSAR 통신 문제는 대부분 특정 계층에서 발생한다.
예를 들어:
데이터 값 이상 → COM 설정 확인
경로 누락 → PduR 확인
송신 실패 → CanIf 확인
버스 출력 없음 → Driver 확인
따라서 모듈 이름을 외우는 것보다 어느 계층이 어떤 책임을 가지는지 이해하는 것이 중요하다.
정리
AUTOSAR CAN 통신 스택을 계층별로 정리한 구조도이다.
각 계층은 다음과 같은 역할을 가진다.
- Hardware: 실제 CAN 장치
- Driver: 하드웨어 직접 제어
- CanIf: 표준 인터페이스
- COM: 데이터 처리
- PduR: 경로 전달
- CanTp: 긴 데이터 전송
- ComM / CanNm / CanSM: 네트워크 상태 관리
AUTOSAR 통신 구조를 이해한다는 것은 단순히 모듈 이름을 아는 것이 아니라,
데이터가 어떤 계층을 지나 실제 CAN 버스로 이동하는지 이해하는 것이다.
'AUTOSAR' 카테고리의 다른 글
| [UDS] DiagnosticSessionControl (0x10) — 세션 변경이 실제로 의미하는 것 (ISO 14229) (0) | 2026.05.07 |
|---|---|
| AUTOSAR DCM - Diagnostic Request 처리 흐름 완전 이해 (DSL → DSD → DSP + 전체 흐름) (0) | 2026.04.28 |
| AUTOSAR 통신 제어 구조 완전 정리: ComM, CanSM, CanNm, BswM 역할 이해 (0) | 2026.04.27 |
| AUTOSAR Runnable과 Event 관계 완전 이해 (0) | 2026.04.23 |
| AUTOSAR 초보자를 위한 E2E Protection (통신 보호) 완벽 정리 (0) | 2026.04.22 |
