null
vuild_
Nodes
Flows
Hubs
Login
MENU
GO
Notifications
Login
⌂
AUTOSAR 개발자 실전 가이드
Structure
overview
•
AUTOSAR가 필요한 이유
•
AUTOSAR 레이어드 아키텍처 구조
components
•
Core, Partition, OS Application 관계
•
SWC와 Runnable — 실행 단위 이해
rte-ports
•
P-Port, R-Port와 인터페이스 설계
•
Explicit vs Implicit Write — 언제 무엇을 쓰나
autosar-os
•
AUTOSAR OS Task와 ISR 설계
•
Alarm, Counter, Schedule Table 정리
•
OS Application과 메모리 보호 설정
spec-practice
•
MUST vs SHALL vs SHOULD — 스펙 용어 해석법
•
DET 에러 처리 — Det_ReportError와 RuntimeError
com-stack
•
ComSignal에서 PduR까지 — 신호가 CAN 프레임이 되는 경로
•
CanIf부터 CanNm까지 — CAN 통신 스택 계층 분리
diagnostics
•
DEM으로 DTC 관리하기 — 이벤트 상태와 고장 이력
•
DCM과 UDS 서비스 — 진단 통신의 실전 구조
ecum-bswm
•
EcuM 시동/종료 시퀀스 — ECU가 켜지고 꺼지는 순서
•
BswM 모드 전환 — 규칙 기반 상태 관리
nvm-schm
•
NvM 읽기/쓰기 패턴 — 비휘발성 메모리를 안전하게 다루는 방법
•
SchM Exclusive Area — 인터럽트와 Task 간 공유 자원 보호
Flow Structure
ComSignal에서 PduR까지 — 신호가 CAN 프레임이 되는 경로
13 / 19
DEM으로 DTC 관리하기 — 이벤트 상태와 고장 이력
☆ Star
↗ Full
CanIf부터 CanNm까지 — CAN 통신 스택 계층 분리
#autosar
#can
#canif
#cannm
#cansm
@devpc
|
2026-05-04 12:39:29
|
GET /api/v1/flows/24/nodes/434?fv=1&nv=1
Context:
Flow v1
→
Node v1
0
Views
1
Calls
# CanIf부터 CanNm까지 — CAN 통신 스택 계층 분리 ## AUTOSAR CAN 스택 전체 그림 CAN 관련 모듈이 이렇게 많은 이유가 있다. 각 모듈이 명확하게 분리된 역할을 갖는다. ``` [SWC] ──── RTE ──── COM ← 신호 패킹/언패킹 PduR ← 라우팅 ┌───────┴───────┐ CanTp CanNm (멀티프레임 분할/조립) (네트워크 관리) └───────┬───────┘ CanIf ← CAN ID 필터링, PDU 매핑 │ CAN Driver ← 하드웨어 직접 제어 │ [CAN 버스 하드웨어] ``` --- ## CanIf — 하드웨어 추상화 CanIf(CAN Interface)는 CAN 드라이버와 상위 레이어 사이의 추상화 레이어다. 역할: - CAN ID → PduId 매핑 - 수신 필터 적용 - 여러 CAN 컨트롤러를 하나의 API로 통일 ```c /* 상위 레이어에서 본 CanIf 전송 */ Std_ReturnType result; result = CanIf_Transmit(CanIfTxPduId, &PduInfo); if (result != E_OK) { /* TX 버퍼 풀, Bus Off 등 처리 */ } ``` CanIf 설정에서 중요한 것: `CanIfRxPduCanIdType`(Standard/Extended), `CanIfRxPduDlc` 설정이 하드웨어 필터와 일치해야 한다. --- ## CanTp — 멀티프레임 전송 CAN 프레임 하나는 최대 8바이트(Classic CAN), CAN FD는 최대 64바이트다. UDS 진단 메시지처럼 긴 데이터는 CanTp(CAN Transport Protocol, ISO 15765-2)가 분할/재조립한다. ``` SF (Single Frame): 7바이트 이하 데이터 FF (First Frame): 멀티프레임 첫 번째 CF (Consecutive Frame): 이후 프레임 FC (Flow Control): 수신 측 준비 완료 알림 ``` ```c /* DCM → CanTp → CanIf 경로로 UDS 응답 전송 */ PduInfoType pdu_info = { .SduDataPtr = response_buffer, .SduLength = response_length }; CanTp_Transmit(CanTpTxSduId, &pdu_info); ``` --- ## CanNm — 네트워크 관리 CanNm(CAN Network Management)은 ECU가 CAN 버스에 참여/이탈하는 것을 관리한다. 슬립 모드 진입/해제 시 사용된다. **네트워크 상태 전환:** ``` BusSleep → PrepareBusSleep ← 슬립 요청 ↓ (카운터 만료) BusSleep ← 모든 ECU 슬립 ↑ Normal ← CanNm_NetworkRequest() 호출 시 워크업 ``` ```c /* 네트워크 깨우기 요청 */ CanNm_NetworkRequest(CanNmChannelHandle); /* 슬립 허용 요청 */ CanNm_NetworkRelease(CanNmChannelHandle); ``` CanNm PDU에는 Node ID와 CBV(Control Bit Vector)가 포함된다. --- ## CanSM — CAN 버스 상태 관리 CanSM(CAN State Manager)은 BswM의 명령에 따라 CAN 버스를 활성화/비활성화한다. Bus Off 복구도 CanSM이 담당한다. ``` NOCOM → SILENT → FULLCOM ↑ Bus Off Recovery ↓ └──────────────────┘ ``` Bus Off 발생 시 CanSM이 자동으로 복구 절차를 수행한다. 복구 실패 횟수가 임계값을 초과하면 DEM에 DTC를 세팅한다. --- ## 실무에서 CAN 스택 디버깅 체크리스트 1. **신호 값 이상** → COM 엔디안, 비트 포지션 확인 2. **프레임 수신 안 됨** → CanIf 필터 설정, CAN ID 타입(Standard/Extended) 확인 3. **UDS 응답 없음** → CanTp 주소 설정(Physical/Functional), FlowControl 타임아웃 확인 4. **Bus Off** → CanSM 복구 카운터, 하드웨어 터미네이션 저항 확인 5. **슬립 안 됨** → CanNm PDU 전송 주기, PartialNetworking 설정 확인
ComSignal에서 PduR까지 — 신호가 CAN 프레임이 되는 경로
DEM으로 DTC 관리하기 — 이벤트 상태와 고장 이력
// COMMENTS
Newest First
ON THIS PAGE
No content selected.