테마
06. DBC, CANoe, E2E 프로토콜
학습 목표
- CAN DB와 DBC 파일의 관계를 구분할 수 있다.
- CANdb++ 같은 도구가 어떤 정보를 작성하는지 이해할 수 있다.
- CANoe가 메시지 로깅과 ECU 시뮬레이션에서 어떤 역할을 하는지 설명할 수 있다.
- E2E 프로토콜이 CAN 자체 에러 검출과 무엇이 다른지 이해할 수 있다.
- CRC, Counter, Data ID가 E2E 검증에서 어떤 역할을 하는지 설명할 수 있다.
전체 구조
1. CAN DB와 DBC는 같은 말이 아니다
CAN DB는 CAN 네트워크의 메시지와 Signal 약속 전체를 뜻하는 일반 개념이다.
이 정보를 Excel, PDF, 자체 포맷, 데이터베이스, DBC 파일 등 어떤 형식으로든 표현할 수 있다.
DBC는 Vector 계열 도구에서 널리 쓰이는 CAN DB 파일 형식이다.
현장에서 DBC가 워낙 자주 쓰이기 때문에 사람들이 CAN DB와 DBC를 거의 같은 의미로 말하는 경우도 많다.
하지만 정확히는 다음처럼 구분하는 편이 좋다.
| 용어 | 의미 |
|---|---|
| CAN DB | 네트워크 메시지와 Signal 정의라는 개념 |
| Communication Matrix | CAN DB를 행렬/표 형태로 표현한 문서 |
| DBC | CAN DB 정보를 담는 파일 형식 중 하나 |
| CANdb++ | DBC 파일을 작성하고 편집하는 Vector 도구 |
실무에서는 "DBC를 받았다"는 말이 "프로젝트의 CAN 메시지와 Signal 정의를 도구가 읽을 수 있는 형태로 받았다"는 의미인 경우가 많다.
2. DBC에는 네트워크 약속이 들어간다
DBC 파일에는 보통 다음 정보가 들어간다.
| 범주 | 정보 예시 |
|---|---|
| Network | 프로토콜 종류, Baud Rate 관련 정보 |
| Node | 네트워크에 참여하는 ECU 목록 |
| Message | ID, 이름, DLC, 송신 노드, 주기 |
| Signal | 이름, Start Bit, Length, Byte Order, Factor, Offset, Unit |
| Receiver | 어떤 ECU가 어떤 Signal을 읽는지 |
| Attribute | 메시지 주기, 송신 타입, 기타 프로젝트 속성 |
개발자는 DBC를 보고 코드를 직접 작성할 수도 있고, 코드 생성 도구로 메시지 구조체나 Signal 접근 코드를 생성할 수도 있다.
검증자는 DBC를 도구에 import해서 raw byte 대신 Signal 이름과 물리값으로 로그를 볼 수 있다.
3. CANoe는 버스 위의 메시지를 해석한다
CANoe는 Vector에서 제공하는 차량 네트워크 개발 및 검증 도구다.
CAN 통신 관련 채용 공고에서 CANoe, Vector, CAPL 같은 단어가 자주 나오는 이유는 실제 현장에서 많이 쓰이기 때문이다.
CANoe를 사용하면 다음 일을 할 수 있다.
- 현재 CAN 버스에 흐르는 메시지를 로깅한다
- DBC를 import해 메시지 ID를 이름으로 해석한다
- 데이터 영역을 Signal 물리값으로 표시한다
- Bus Load를 측정한다
- 가상 ECU를 만들어 특정 메시지를 송신한다
- CAPL 같은 스크립트로 테스트 동작을 자동화한다
DBC 없이도 CANoe는 raw CAN ID와 data byte를 보여줄 수 있다.
하지만 DBC가 있으면 0x123 7C 00 ... 같은 값을 BatteryVoltage = 12.4V처럼 읽을 수 있다.
4. CANoe는 가상 ECU 역할도 할 수 있다
개발 중에는 차량의 모든 ECU가 실험실에 다 있는 것이 아니다.
내가 개발하는 ECU 하나만 있고, 나머지 ECU는 아직 없거나 다른 팀이 개발 중일 수 있다.
그런데 내 ECU는 다른 ECU가 보내는 메시지를 받아야 정상 동작한다.
이때 CANoe가 가상 ECU 역할을 해서 필요한 메시지를 대신 보내줄 수 있다.
이 기능은 개발 초기에 매우 중요하다.
- 다른 ECU가 없어도 내 ECU의 수신 로직을 테스트할 수 있다
- 특정 Signal 값을 바꿔가며 동작을 확인할 수 있다
- 에러 상황이나 경계값을 반복해서 재현할 수 있다
- 테스트 케이스를 자동화할 수 있다
5. CAN 자체 CRC만으로 충분하지 않은 경우가 있다
CAN 프레임에는 자체 CRC가 있다.
이 CRC는 메시지가 버스 위에서 전송되는 동안 비트가 깨졌는지 감지하는 데 쓰인다.
하지만 실무에서는 CAN 자체 CRC만으로는 잡기 어려운 문제가 있다.
예를 들면 다음과 같다.
- 같은 메시지가 의도치 않게 반복 전송된다
- 이전에 보낸 오래된 메시지가 다시 들어온다
- 원래 A ECU가 보내야 할 메시지를 B ECU가 잘못 보낸다
- 애플리케이션 데이터 영역이 논리적으로 잘못 조립된다
- 수신 측이 메시지 순서 누락을 구분해야 한다
CAN Controller의 CRC는 프레임 전송 중 비트 오류를 잡는 데 초점이 있다.
E2E(End-to-End) 프로토콜은 애플리케이션 데이터가 송신 애플리케이션에서 수신 애플리케이션까지 의도한 흐름으로 도착했는지를 추가로 검증한다.
6. E2E의 핵심은 CRC와 Counter다
E2E 프로토콜은 보통 데이터 영역 안에 검증용 Signal을 추가한다.
| 요소 | 역할 |
|---|---|
| Counter | 메시지가 순서대로 갱신되는지 확인 |
| CRC | 데이터가 변경되지 않았는지 확인 |
| Data ID | 메시지의 정체성을 CRC 계산에 포함해 오수신을 줄임 |
예를 들어 송신 측은 메시지를 보낼 때마다 Counter를 1씩 증가시킨다.
수신 측은 Counter가 예상대로 증가하는지 확인한다.
이렇게 하면 다음 상황을 감지할 수 있다.
- 같은 메시지가 반복됨
- 중간 메시지가 누락됨
- 순서가 꼬임
7. CRC는 데이터 변경을 감지한다
CRC(Cyclic Redundancy Check)는 원본 데이터를 특정 다항식과 초기값, XOR 값 등을 이용해 계산한 검증값이다.
송신 측은 원본 데이터와 함께 CRC 값을 보낸다. 수신 측은 받은 데이터로 CRC를 다시 계산해 비교한다.
CRC가 맞지 않으면 수신 측은 메시지 전송 또는 데이터 조립 과정에서 문제가 있다고 판단할 수 있다.
중요한 점은 E2E CRC와 CAN 프레임 CRC가 다르다는 것이다.
| 항목 | CAN 프레임 CRC | E2E CRC |
|---|---|---|
| 처리 주체 | CAN Controller | 애플리케이션 소프트웨어 또는 라이브러리 |
| 보호 범위 | CAN 프레임 전송 오류 | 애플리케이션 데이터의 End-to-End 무결성 |
| 위치 | CAN 프레임의 CRC 영역 | 데이터 영역 안의 Signal로 배치 |
| 설정 | CAN 프로토콜에 의해 정의 | E2E Profile과 프로젝트 사양에 의해 정의 |
8. E2E Profile마다 세부 규칙이 다르다
AUTOSAR E2E에는 여러 Profile이 있고, Profile마다 Counter 크기, CRC 크기, Data ID 사용 방식, 계산 순서가 다를 수 있다.
예를 들어 어떤 Profile은 4bit Counter를 쓰고, 어떤 Profile은 8bit Counter를 쓸 수 있다.
CRC도 CRC8, CRC16, CRC32처럼 크기와 다항식이 다를 수 있다.
예를 들어 AUTOSAR E2E Profile 1은 4bit Counter와 CRC-8-SAE J1850 다항식을 사용하지만, Counter 범위와 CRC start/XOR 값 같은 세부 규칙이 Profile에 묶여 있다. Profile 이름만 비슷해도 release와 variant가 다르면 배치와 계산 순서가 달라질 수 있다.
| 항목 | Profile마다 달라질 수 있는 것 |
|---|---|
| Counter 크기 | 4bit, 8bit 등 |
| CRC 크기 | 8bit, 16bit, 32bit 등 |
| Data ID 크기 | 2byte 등 |
| CRC 입력 순서 | Data ID low byte 먼저 등 |
| Initial Value | CRC 계산 시작값 |
| XOR Value | 최종 보정값 |
따라서 "E2E를 적용한다"는 말만으로는 구현할 수 없다.
반드시 어떤 Profile을 쓰는지, 어떤 메시지에 적용하는지, Data ID와 CRC 배치가 어떻게 되는지 확인해야 한다.
9. E2E 적용 여부는 보통 OEM이 정한다
E2E는 모든 메시지에 무조건 적용되는 것이 아니다.
안전이나 신뢰성이 중요한 메시지에 선택적으로 적용하는 경우가 많다.
실무에서는 보통 OEM 또는 네트워크 설계자가 다음을 정한다.
- 어떤 메시지에 E2E를 적용할지
- 어떤 E2E Profile을 사용할지
- CRC와 Counter를 데이터 영역 어디에 배치할지
- Data ID 값을 무엇으로 할지
- DBC에 E2E 정보를 넣을지, 별도 문서로 제공할지
개발자는 이 정보를 기준으로 송신 로직과 수신 검증 로직을 구현한다.
핵심 정리
- CAN DB는 메시지와 Signal 정의라는 개념이고, DBC는 그 정보를 담는 파일 형식 중 하나다.
- CANoe는 DBC를 import해 raw CAN 메시지를 Signal 단위로 해석하고, 가상 ECU로 메시지를 시뮬레이션할 수 있다.
- CAN 자체 CRC는 프레임 전송 오류를 잡지만, E2E는 애플리케이션 데이터의 End-to-End 무결성을 추가로 본다.
- E2E의 핵심 요소는 CRC, Counter, Data ID다.
- E2E Profile마다 계산 방식과 데이터 배치가 다르므로 프로젝트 사양을 반드시 확인해야 한다.
확인 질문
- CAN DB와 DBC는 어떤 관계인가?
- DBC를 CANoe에 import하면 어떤 점이 편리해지는가?
- CAN 프레임 CRC와 E2E CRC는 보호 범위가 어떻게 다른가?
- Counter만으로 감지할 수 있는 오류와 CRC가 필요한 오류를 구분해 보라.