CAN 통신 실전 입문 — 이론부터 Vector 드라이버 설정까지

# 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를 진단하고 제어하는 표준 프로토콜이다.

DBC 파일과 CANdb++ — CAN 메시지 데이터베이스 읽기

// COMMENTS

ON THIS PAGE