DBC·LDF가 어렵다면? CAN·LIN 로그를 읽고 바로 검증에 적용하는 실무 가이드
수정 2026-10-04: Frame ID와 PID를 구분하고, LIN 슬롯 시간과 프레임 반복주기의 차이를 가상 스케줄로 설명했습니다.
CAN·LIN 로그에 숫자는 보이는데 펌프가 몇 RPM인지 모르겠다면, 먼저 DBC와 LDF를 확인하세요. DBC는 CAN 데이터의 의미를 풀어주는 정의 파일이고, LDF는 LIN 신호·프레임·노드와 스케줄을 설명하는 파일입니다. 파일을 읽는 목적은 문법 암기가 아니라 원시 데이터와 제어 의미, 시간 조건을 연결하는 것입니다.
1. 네 가지 약어부터 구분합니다
| 용어 | 뜻과 역할 |
|---|---|
| DBC | CAN 데이터베이스 파일 형식(.dbc). 메시지 ID와 신호의 비트 위치·길이·단위·변환 규칙 등을 정의. |
| LDF | LIN Description File. LIN 노드, 신호, 프레임, 송수신 역할과 Schedule Table 등을 정의. |
| DLC | Data Length Code. CAN 데이터 길이 코드. CAN FD에서는 코드와 실제 바이트 수가 항상 같지 않음. |
| PID | Protected Identifier. LIN의 6비트 Frame ID에 패리티 2비트를 더한 8비트 식별자. |
예를 들어 CAN FD의 DLC 15는 데이터 64바이트를 뜻합니다. LIN Frame ID 0x22는 패리티를 결합하면 PID 0xE2가 됩니다. 둘은 같은 숫자를 다른 표기로 쓰는 관계가 아닙니다. 도구가 ID와 PID 중 무엇을 표시하는지 확인해야 합니다. 이 값은 프로토콜 설명 예이며 고객 메시지 사양이 아닙니다.
2. CAN은 ID와 길이부터 읽습니다
확인 순서는 ID·프레임 형식 → 데이터 길이 → Start Bit·Length·Endian → Factor·Offset → 단위·상태 → 시간 조건입니다. Standard/Extended ID, Classical CAN/CAN FD를 먼저 구분하세요. 메시지가 다르면 같은 바이트도 다른 의미입니다.
Start Bit과 Length는 신호가 차지하는 비트 위치와 길이입니다. Endian은 여러 바이트를 해석하는 순서이며 Intel·Motorola 정의를 함께 봐야 합니다. 특히 Motorola 신호는 숫자만 보고 바이트를 뒤집지 말고, 사용 도구의 비트 번호 규칙과 실제 해석값을 대조합니다.
3. 가상 CAN 데이터로 직접 계산합니다
다음 ID·신호·수치·바이트는 모두 교육용 가상 가정이며 실제 로그가 아닙니다. ID 0x180, 길이 8바이트인 PumpStatus에 다음 신호가 있다고 가정합니다. 모든 예제 신호는 unsigned이며 Intel 방식입니다.
| 신호 | Start Bit·Length | Factor·Offset | 의미 |
|---|---|---|---|
| PumpSpeed | 0·16비트 | 0.125·0 | RPM |
| InternalTemp | 16·8비트 | 1·−40 | °C |
| OperationState | 24·2비트 | 1·0 | 0:Off, 1:Run, 2:Derating, 3:Fault |
가상 Payload를 40 9C 4B 01 00 00 00 00으로 둡니다. 처음 두 바이트는 Intel 방식으로 0x9C40, 즉 Raw 40000입니다. 물리값 공식은 Raw × Factor + Offset이므로 속도는 40000×0.125=5000 RPM입니다. 온도 Raw 0x4B는 75이므로 75−40=35°C입니다. 네 번째 바이트의 하위 2비트는 1이므로 Run입니다.
계산이 맞아도 정상 동작 판정이 끝난 것은 아닙니다. Min/Max, 무효값, 초기값, 신호 유효시간, Counter·Checksum과 진단 조건은 따로 확인해야 합니다. DBC만으로 모든 고장 반응 요구사항을 알 수는 없습니다.
4. LIN은 Header와 Response를 나눕니다
LIN Master(또는 commander)는 스케줄에 따라 Break·Sync·PID가 포함된 Header를 보냅니다. 해당 프레임의 Publisher가 Data·Checksum인 Response를 보냅니다. Publisher는 프레임 정의에 따라 Master나 Slave(responder)가 될 수 있으므로 Slave만 항상 응답한다고 가정하지 않습니다.
응답이 없으면 우선 해당 Header가 나왔는지 확인하세요. Header가 없으면 현재 스케줄, 시작 상태, 스케줄 전환을 먼저 봅니다. Header는 있는데 Response가 없으면 Publisher, 배선, 전원, 통신속도와 프레임 정의를 분리해 확인합니다.
5. 슬롯 10ms가 프레임 주기 10ms는 아닙니다
아래는 세 unconditional 프레임이 순서대로 한 번씩 나오고, 정지·전환·추가 지연 없이 반복되는 가상의 스케줄입니다. 슬롯 시간은 Header·Response를 담을 충분한 시간을 확보했다고 가정합니다. 실제 전송시간과 허용오차는 통신속도·길이·사양으로 검토해야 합니다.
| 슬롯 | 프레임·Publisher | 슬롯 길이 | 첫 Header 시작 |
|---|---|---|---|
| A | PumpCommand·Master | 10ms | 0ms |
| B | PumpStatus·Pump | 20ms | 10ms |
| C | SensorStatus·Sensor | 30ms | 30ms |
한 바퀴 길이는 10+20+30=60ms입니다. 다음 PumpCommand Header는 60ms, PumpStatus는 70ms, SensorStatus는 90ms에 시작합니다. 각 프레임이 한 바퀴에 한 번 나오므로 각 반복주기는 60ms입니다. PumpStatus 슬롯이 20ms라고 해서 PumpStatus가 20ms마다 나온다는 뜻은 아닙니다.
실제 스케줄에는 같은 프레임이 여러 번 나오거나 진단·event-triggered·sporadic 프레임, 다른 테이블로의 전환이 들어갈 수 있습니다. 이 경우 한 바퀴 합만으로 개별 프레임 간격을 단정하지 말고 실제 배치와 실행 상태를 확인합니다. 타임아웃 기준도 슬롯 길이에서 임의로 만들지 않습니다.
6. ACK와 애플리케이션 동작을 혼동하지 않습니다
CAN 송신기가 ACK 슬롯에서 dominant를 관측하면 적어도 한 수신 노드가 프레임을 정상 수신했음을 알 수 있습니다. 어떤 ECU가 수신했는지, 그 ECU의 제어 로직이 명령을 사용했는지는 ACK만으로 알 수 없습니다. 상태 응답, 내부 변수 또는 실제 출력 변화로 별도 확인하세요.
7. CANoe 적용과 AI 검토 순서
- 승인된 DBC·LDF 버전을 대상 채널에 연결합니다.
- Trace에서 원시 프레임과 물리값을 같은 시각으로 비교합니다.
- CAN 송수신 역할, LIN Publisher와 현재 스케줄을 확인합니다.
- 필요한 경우 승인된 환경에서 무효값·미수신·스케줄 전환 시험을 수행합니다.
- 입력·기대값·실제 관측값·환경 버전·로그를 요구사항 ID에 연결합니다.
AI에는 익명화한 일부 정의에서 누락된 단위, 송수신 방향, 변환 규칙과 시간 조건의 검토 후보를 찾게 할 수 있습니다. 입력에 없는 값을 만들지 말고 확인 필요로 표시하도록 요청합니다. 실제 ID·신호명·네트워크 구조도 기밀일 수 있으므로 조직이 승인한 최소 정보만 사용하세요.
확인한 공식 자료와 관련 글
- Vector DBC Glossary: 이름·Scaling·Offset을 적용하는 DBC 역할.
- Vector CANoe 19.4 LIN Interactive Master – Scheduling: LIN 스케줄 제어.
- NI LIN Schedules: 프레임 종류 설명.
- AI CAPL 검증 체크포인트
- 요구사항–테스트 추적성
가상 예제는 파일 읽기 연습이며 시험 결과나 실제 사양이 아닙니다. 요구사항·승인된 데이터베이스·조직 검증 기준을 우선합니다.
DBC 읽는 순서 정리 진짜 유용하네요. LDF 프레임이 Trace에 안 보이면 스케줄부터 보라는 팁, 바로 써먹어야겠습니다.
답글삭제