null
vuild_
Nodes
Flows
Hubs
Login
MENU
GO
Notifications
Login
⌂
CAN 통신 실전 입문 — 이론부터 Vector 드라이버 설정까지
Structure
can-basics
•
CAN 통신이란 — 탄생 배경과 버스 구조
bit-timing
•
CAN Bit Timing — Prescaler·SJW·BS1·BS2 계산법
transceiver
•
CAN 트랜시버 — TLE9251V로 보는 핀, 모드, 설계 포인트
vector-driver-choice
•
Vector 드라이버 선택 — XL-Driver vs PassThru
xl-driver-setup
•
Vector XL-Driver 실전 설정 — 포트, 이더넷 모드, 주의사항
troubleshooting
•
Vector 드라이버 트러블슈팅 — 버전 미스매치와 Network 모드 불가
can-hw-filter
•
CAN 하드웨어 메시지 필터 — 원하는 ID만 골라받기
dbc-file
•
DBC 파일과 CANdb++ — CAN 메시지 데이터베이스 읽기
uds-on-can
•
UDS 진단 프로토콜 — CAN 위에서 ECU를 제어하는 방법
Flow Structure
CAN 하드웨어 메시지 필터 — 원하는 ID만 골라받기
8 / 9
UDS 진단 프로토콜 — CAN 위에서 ECU를 제어하는 방법
☆ Star
↗ Full
DBC 파일과 CANdb++ — CAN 메시지 데이터베이스 읽기
#can
#dbc
#candb
#신호
#메시지정의
@devpc
|
2026-05-06 05:25:46
|
GET /api/v1/flows/28/nodes/561?fv=1&nv=1
Context:
Flow v1
→
Node v1
0
Views
1
Calls
# DBC 파일과 CANdb++ — CAN 메시지 데이터베이스 읽기 ## DBC 파일이란 CAN 버스를 통해 ECU들이 주고받는 메시지는 0과 1의 조합일 뿐이다. 이 데이터를 "엔진 RPM이 몇 이다", "냉각수 온도가 몇 도다"라는 의미로 해석하려면 **신호 정의**가 필요하다. **DBC(CAN Database)** 파일은 이 신호 정의를 텍스트 포맷으로 담은 파일이다. Vector의 **CANdb++** 툴로 편집하며, CANoe, CANape 같은 Vector 툴과 긴밀하게 연동된다. DBC 파일이 없으면 수신한 CAN 프레임은 의미 없는 16진수 덩어리다. 있으면 바로 물리적 수치로 변환된다. ## DBC 파일 구조 (텍스트 포맷) DBC 파일은 일반 텍스트 파일이다. 구조를 알면 직접 파싱하거나 디버깅할 수 있다. ``` VERSION "" NS_ : BS_: BU_: ECU_Engine ECU_Body ECU_Gateway BO_ 513 EngineStatus: 8 ECU_Engine SG_ EngineRPM : 0|16@1+ (0.25,0) [0|16000] "rpm" ECU_Body,ECU_Gateway SG_ CoolantTemp : 16|8@1+ (1,-40) [−40|215] "degC" ECU_Body BO_ 514 WheelSpeed: 8 ECU_Body SG_ SpeedFL : 0|16@1+ (0.01,0) [0|300] "kph" ECU_Gateway SG_ SpeedFR : 16|16@1+ (0.01,0) [0|300] "kph" ECU_Gateway ``` ### 핵심 항목 설명 **`BO_` 라인 — 메시지 정의**: ``` BO_ <ID> <이름>: <DLC> <송신 노드> ``` - `513` = CAN ID (10진수, 0x201) - `8` = 데이터 길이 (DLC, 바이트 수) **`SG_` 라인 — 신호 정의**: ``` SG_ <신호명> : <시작비트>|<길이>@<바이트순서><부호> (<factor>,<offset>) [<최솟값>|<최댓값>] "<단위>" <수신 노드> ``` | 항목 | 설명 | |------|------| | `시작비트` | 신호의 시작 비트 위치 | | `길이` | 신호의 비트 수 | | `@1+` | `1` = Little Endian, `0` = Big Endian / `+` = Unsigned, `-` = Signed | | `factor` | 물리값 = raw × factor + offset | | `offset` | 물리값 계산 오프셋 | ## 물리값 변환 계산 DBC에서 factor/offset이 있는 이유는, CAN 데이터가 정수(raw)로 전송되기 때문이다. 물리적 의미는 변환 후에 얻는다. ``` 예: EngineRPM raw value = 0x1770 = 6000 factor = 0.25, offset = 0 물리값 = 6000 × 0.25 + 0 = 1500 rpm ``` ``` 예: CoolantTemp raw value = 0xB4 = 180 factor = 1, offset = -40 물리값 = 180 × 1 + (-40) = 140 degC ``` ## CANdb++ 툴 활용 Vector의 **CANdb++** Editor는 DBC 파일을 GUI로 편집하는 툴이다. CANoe 설치 시 함께 설치된다. 주요 기능: - 메시지/신호 추가·수정·삭제 - 신호 간 의존성(Multiplex Signal) 설정 - 속성(Attribute) 정의 — 신호에 메타정보 추가 - DBC ↔ ARXML 변환 (AUTOSAR 환경) CANoe에서 DBC를 로드하면 메시지 창에서 raw 바이트 대신 신호 이름과 물리값이 바로 보인다. 신호 그래프, 통계, 트리거 설정도 DBC 기반으로 동작한다. ## 코드에서 DBC 없이 직접 파싱 DBC를 로드하는 툴이 없는 환경에서 MCU 코드로 직접 신호를 추출할 때: ```c /* EngineStatus 메시지(ID: 0x201, DLC: 8)에서 RPM 추출 */ /* EngineRPM: 시작비트=0, 길이=16비트, Little Endian, Unsigned, factor=0.25 */ uint8_t data[8]; /* 수신된 CAN 데이터 */ /* Little Endian 16비트 추출 */ uint16_t raw_rpm = (uint16_t)data[0] | ((uint16_t)data[1] << 8); /* 물리값 변환 */ float rpm = raw_rpm * 0.25f; /* CoolantTemp: 시작비트=16, 길이=8비트 */ uint8_t raw_temp = data[2]; int16_t temp_c = (int16_t)raw_temp - 40; ``` 비트 추출 시 Little Endian(Intel byte order)과 Big Endian(Motorola byte order) 구분이 중요하다. 잘못 구분하면 값이 뒤집힌다. ## DBC 파일 관리 실무 - 차량 프로젝트에서는 **CAPL 스크립트 + DBC**가 한 세트다. DBC 없이는 CANoe 스크립트가 제대로 동작하지 않는다. - ECU가 많은 프로젝트에서는 네트워크별(CAN1, CAN2, LIN 등)로 DBC를 나눠 관리한다. - OEM(완성차 제조사)에서 DBC를 제공하는 경우, 신호 정의를 임의로 변경하면 다른 ECU와 통신이 깨질 수 있다. ## 다음 챕터에서는 CAN 버스 위에서 메시지를 주고받는 것 외에, **진단 통신**도 존재한다. UDS(Unified Diagnostic Services)는 CAN 위에서 ECU를 진단하고 제어하는 표준 프로토콜이다.
CAN 하드웨어 메시지 필터 — 원하는 ID만 골라받기
UDS 진단 프로토콜 — CAN 위에서 ECU를 제어하는 방법
// COMMENTS
Newest First
ON THIS PAGE
No content selected.