흔한 실수와 트러블슈팅

1. 종단 저항 미설치

항목내용
증상통신 불안정, 에러 프레임 다발, Bus Off 빈번 발생
원인CAN 버스 양 끝단에 120Ω 종단 저항이 없으면 신호 반사가 발생하여 비트 레벨이 왜곡된다.
해결버스 양 끝단(백본의 물리적 시작과 끝)에 각각 120Ω 저항을 설치한다. 멀티미터로 버스 전원 차단 상태에서 CAN_H-CAN_L 간 저항을 측정하면 약 60Ω(두 저항 병렬)이 되어야 한다.

2. 비트레이트(보드레이트) 불일치

항목내용
증상통신 완전 불가, 버스에서 에러 프레임만 관측됨
원인노드마다 비트레이트 설정이 달라 비트 타이밍이 맞지 않는다. ISOBUS 표준 비트레이트는 250 kbps이나, 잘못된 초기화 코드로 500 kbps 등으로 설정되는 경우가 있다.
해결모든 노드의 비트레이트를 250 kbps로 통일한다. 오실로스코프나 CAN 분석기로 실제 버스 신호의 비트폭을 측정하여 확인한다.

3. 주소 충돌 (Cannot Claim Address)

항목내용
증상노드가 주소를 획득하지 못하고 버스에서 동작하지 않음. 로그에 "Cannot Claim Address" 메시지
원인두 노드의 NAME이 동일하거나, 주소 협상(Address Claiming) 과정에서 다른 노드가 동일 SA를 더 낮은 NAME 값으로 선점했다.
해결NAME의 Identity Number(21비트)를 노드마다 고유하게 설정한다. 제조사 코드(Manufacturer Code)도 올바르게 등록해야 한다. 협상에 실패한 노드는 SA를 254(Null Address)로 유지하고 재시도한다.

4. VT 오브젝트 풀 전송 실패

항목내용
증상VT에 UI가 표시되지 않음, "Object Pool Upload Failed" 또는 타임아웃 발생
원인 1VT의 가용 메모리가 부족하다. 오브젝트 풀 크기가 VT 사양을 초과한다.
원인 2TP 전송 타임아웃: 패킷 간 간격이 250ms를 초과했다.
원인 3오브젝트 풀 내부 참조 오류(존재하지 않는 오브젝트 ID 참조).
해결VT의 지원 메모리를 확인하고 오브젝트 풀을 최적화한다. 전송 속도를 높이고, ISO 11783-6 준수 여부를 검증 도구로 확인한다.

5. TP 타임아웃

항목내용
증상멀티패킷 전송이 중간에 끊기고 Abort 메시지 수신
원인J1939 TP 규격상 패킷(TP.DT) 간 전송 간격이 250ms를 초과하면 수신 측이 연결을 중단한다. 또는 CTS 응답 대기 시간(T3 = 1250ms)이 초과된다.
해결TP.DT 패킷 간 간격을 250ms 이내로 유지한다. 버스 부하가 높은 경우 전송 스케줄을 조정하거나, ETP(Extended Transport Protocol)로 전환한다.

6. DLC 불일치

항목내용
증상수신 노드에서 메시지를 무시하거나 파싱 오류 발생
원인전송 측에서 설정한 DLC(Data Length Code)가 PGN 규격상 기대되는 바이트 수와 다르다. 예를 들어 EEC1(PGN 61444)은 8바이트여야 하나 6바이트로 보내는 경우.
해결PGN별 표준 DLC를 확인하고 코드를 수정한다. 수신 측 파서는 DLC 검증 로직을 포함해야 한다.

7. 스텁(Stub) 길이 초과

항목내용
증상특정 노드 연결 후 통신 에러 증가, 신호 품질 저하
원인ISO 11783에서 백본에서 분기하는 스텁의 최대 길이는 1m이다. 이를 초과하면 임피던스 불연속으로 신호 반사가 발생한다.
해결스텁 길이를 1m 이내로 단축한다. 불가피한 경우 해당 노드를 백본 라인 위에 직접 배치(인라인 연결)하는 구조를 검토한다.

8. Working Set 연결 안됨

항목내용
증상VT에서 작업기 UI가 나타나지 않음, Working Set Master가 VT를 찾지 못함
원인NAME의 Function 필드 설정 오류. Virtual Terminal 기능 코드(0x26)가 올바르게 설정되지 않아 VT를 인식하지 못한다. 또는 Working Set Maintenance 메시지 전송 누락.
해결Working Set Master의 NAME Function 필드를 올바르게 설정한다. 주소 획득 후 매 2초마다 Working Set Maintenance 메시지(PGN 0xE8FF)를 전송하는지 확인한다.

9. TC가 DDOP를 거부

항목내용
증상TC가 DDOP 업로드를 거부하거나 에러 응답을 반환
원인 1DDOP 오브젝트 구조 오류: Device Object가 없거나 필수 DDI가 누락되었다.
원인 2오브젝트 ID 중복: DDOP 내에서 동일한 Object ID가 여러 번 사용되었다.
원인 3TC 버전 불일치: TC가 지원하지 않는 DDOP 구조나 DDI를 사용했다.
해결ISO 11783-10을 기반으로 DDOP 구조(Device → DeviceElement → DPD/DPT)가 올바른지 검증한다. AEF의 ISOBUS 준수 테스트 도구로 DDOP를 사전 검증한다.

10. Bus Off 반복

항목내용
증상노드가 Bus Off 상태에 반복적으로 진입, 통신 완전 불가
원인TEC(Transmit Error Counter)가 지속적으로 증가하는 근본 원인이 있다. 주로 커넥터 접촉 불량, 배선 단선/단락, 또는 EMI(전자기 간섭) 문제다.
해결모든 커넥터(특히 Deutsch DT04 계열)의 핀 상태와 잠금을 점검한다. CAN_H-GND, CAN_L-GND 간 단락 여부를 측정한다. 배선 경로의 고압 장비(모터, 인버터)와의 간격을 확인하고 차폐 케이블 사용을 검토한다.

11. 섹션 컨트롤이 동작하지 않음

항목내용
증상GPS 위치 기반 자동 섹션 ON/OFF가 작동 안 함
원인DDOP에서 섹션에 해당하는 DeviceElement의 DDI(Setpoint/Actual Section Control State) 설정 누락. 또는 TC와 TECU 간 작업 상태(Task Active) 동기화 문제.
해결DDOP의 각 섹션 DeviceElement에 DDI 160(Section Control State)을 올바르게 등록한다. TC가 Task Active 상태임을 확인하고, 작업 중 TC로부터 섹션 설정값이 수신되는지 로그를 확인한다.

12. 메시지 수신은 되나 데이터 값이 이상함

항목내용
증상메시지는 수신되지만 파싱된 값이 예상과 크게 다름
원인SPN의 바이트 오프셋, 비트 오프셋, 해상도(Resolution), 오프셋(Offset)을 잘못 적용했다. 엔디안(Little-endian) 처리 오류도 자주 발생한다.
해결J1939 SPN 정의서에서 바이트 위치(1-based), 비트 시작 위치, 길이, 해상도, 오프셋을 다시 확인한다. CAN 분석기의 원시 데이터와 직접 비교하며 파싱 로직을 검증한다.

진단 팁

  • CAN 분석기 사용: PCAN-View, SavvyCAN 등으로 버스 트래픽을 캡처하여 에러 프레임 비율과 메시지 타이밍을 확인한다.
  • 에러 카운터 모니터링: CAN 컨트롤러의 TEC/REC 값을 주기적으로 읽어 에러 누적 추세를 파악한다.
  • 전압 측정: 정상 버스는 CAN_H 약 3.5V, CAN_L 약 1.5V (Dominant), 각각 2.5V (Recessive)여야 한다.
  • 로그 수준 분리: 에러 프레임, 주소 협상, TP 세션을 별도 채널로 로깅하면 원인 파악이 빠르다.