CAN DBC: 두 바이트를 속도로 읽기까지

프레임 ID와 신호값은 다른 숫자입니다

CAN 프레임의 ID와 데이터 바이트만으로 차량 속도를 단정할 수는 없습니다. DBC는 메시지와 신호별로 위치·길이·바이트 순서·부호·배율·오프셋을 기록합니다. 차량·네트워크·ECU 소프트웨어에 맞는 정의가 필요하며, DBC 자체가 센서 정확도나 송신자 신원을 보장하지는 않습니다.

아래는 실제 차량에서 받은 값이 아니라 직접 구성한 예시입니다. 표준 11-bit 프레임 ID는 0x100, 길이는 2바이트, 데이터는 E8 03입니다. DBC의 메시지 ID 256은 0x100의 십진수 표기입니다. 페이로드에서 추출할 0x03E8과는 역할이 다릅니다. 메시지·신호 표기

계산에 필요한 정의를 모두 적습니다

VERSION ""
NS_ :
BS_:
BU_: TxECU RxECU

BO_ 256 DemoSpeed: 2 TxECU
 SG_ VehicleSpeed : 0|16@1+ (0.1,0) [0|6553.5] "km/h" RxECU

예시 DBC 파일

Intel 시작 비트는 신호의 최하위 비트입니다. Motorola의 시작 비트 관례와 API의 비트 번호 방식을 혼합하지 않습니다. Kvaser의 Intel·Motorola 비트 위치 설명

E8 03에서 100 km/h를 계산합니다

같은 정의에서 바이트 순서만 03 E8로 바꾸면 raw 59395, 물리값 5939.5가 됩니다. 이것을 무조건 센서 고장이라고 판단하지 말고 원시 바이트와 정의를 함께 확인해야 합니다.

파서로 해독과 역변환을 대조합니다

다음 예시는 파일을 읽고 메모리에서만 인코드·디코드합니다. CAN 인터페이스를 열거나 버스로 전송하지 않습니다. cantools의 파일 로드·인코드·디코드 API

import cantools

db = cantools.database.load_file("can-dbc-demo.dbc", strict=True)
message = db.get_message_by_name("DemoSpeed")
payload = bytes.fromhex("E8 03")
assert message.frame_id == 0x100
assert not message.is_extended_frame
assert message.decode(payload, scaling=False)["VehicleSpeed"] == 1000
assert message.decode(payload)["VehicleSpeed"] == 100.0
assert message.encode({"VehicleSpeed": 100.0}, strict=True) == payload

cantools 45.1.0으로 메시지 형식과 신호 정의, raw·물리값·역변환, 양 끝값, 바이트를 바꾼 값, 미등록 ID, 짧거나 긴 데이터, 음수와 상한 초과 인코드를 검사했습니다. 총 13개 검사가 통과했습니다. 긴 데이터 검사는 allow_excess=False를 지정했습니다. 파서의 기본값이 모든 길이 오류를 거부한다고 가정하지 않습니다.

정의를 검증했다고 차량에서도 맞는 것은 아닙니다

실제 데이터에서는 표준·확장 프레임 구분, 메시지 유형, 길이, 시작 비트·길이·바이트 순서·부호, 배율·오프셋·단위, multiplex 조건과 해당 시스템의 무효값 규칙을 확인합니다. 확장 ID나 J1939의 매칭에 이 표준 ID 예시를 그대로 적용하지 않습니다. 알려진 정상 프레임과 비교해도 실차의 센서·ECU·버스 동작 전체를 인증한 것은 아닙니다.

주제의 계기가 된 Koteswara Rao Para의 DBC 글과 이 예시는 구분합니다. 이 글은 저자의 차량 프레임이나 장애 사례를 재현한 것이 아니며, 원그림을 복제하지 않았습니다. 위 DBC와 2바이트는 설명과 파서 검증을 위해 만든 독립 데이터입니다.

이어서 읽기

• SocketCAN 문서
• J1939 문서
• CAN 포트의 종단·보호