CAN통신 CAN2.0 HS-CAN J1939 CAN FD 프로토콜 비교: 속도, 메시지 크기, 상용차·EV 적용 예

• “CAN2.0 HS-CAN J1939 CAN FD 프로토콜 비교: 속도, 메시지 크기, 상용차·EV 적용 예”

 

자동차 및 산업용 통신 네트워크에서는 ECU 간 데이터 주고받는 속도, 메시지 용량, 통신 안정성 등이 매우 중요합니다. 과거의 Classical CAN (CAN 2.0), HS-CAN을 넘어, J1939 프로토콜과 더 최신 버전인 CAN FD가 점점 더 많이 채택되고 있습니다. 이 글에서는 최신 기준으로 CAN2.0, HS-CAN, J1939, CAN FD의 기술적 차이, 실제 적용 사례, 장단점 등을 구체적으로 비교해서 정리해 봅니다.

---

CAN2.0과 HS-CAN: 기본 개념과 역할

• CAN 2.0은 Classical CAN이라고도 하며, 대표적으로 CAN 2.0A (표준식별자 11비트), CAN 2.0B (확장식별자 29비트) 버전이 존재합니다.
• **HS-CAN (High Speed CAN)**는 일반적으로 Classical CAN의 고속 버전으로, 승용차 및 상용차의 파워트레인, 브레이크, 트랜스미션 제어 등 실시간성이 요구되는 부분에서 주로 사용됩니다. 속도는 500 kbps ~ 1 Mbps가 보통입니다.
• CAN2.0의 한계로는 메시지 페이로드(payload)가 최대 8바이트, 프레임 속도가 높아질수록 케이블 길이, 노드 간 거리, 노이즈 등에 취약해지는 점 등이 있습니다.

---

J1939: 상용차·중장비의 표준 프로토콜

• SAE J1939은 상용차, 트럭, 버스, 농업·건설 장비 같은 분야에서 ECU 간 통신 및 진단 데이터 교환을 위해 개발된 고수준 프로토콜입니다. ISO 11898 CAN 물리계층을 사용하며, 확장 식별자(29비트)를 사용합니다.
• J1939에서는 메시지 그룹 (PGN: Parameter Group Number), 개별 파라미터 (SPN: Suspect Parameter Number), 주소 클레임(Address Claim) 등의 규칙이 정의되어 있어서 다수 ECU 간의 충돌 방지, 메시지 우선순위, 상호 운용성(interoperability)을 확보합니다.
• 예로 상용 트럭에서는 엔진 온도, RPM, 연료 소비율, 배출가스 성분, 냉각수 온도 등 다양한 센서 및 제어 데이터를 J1939 메시지로 주고받습니다. 제조사·장비 간 규격이 다를 때도 J1939 표준을 따르므로 비교적 진단 툴(tool) 또는 데이터 해석이 쉬운 편입니다.

---

CAN FD: 유연성·속도·확장성의 진화형

• **CAN FD (Flexible Data-Rate)**은 Classical CAN의 한계를 극복하기 위해 보쉬(Bosch) 등이 개발한 확장 규격입니다. 2012년 공식 발표된 이후 활용이 점차 늘고 있습니다.
• CAN FD의 주요 특징:
  1. 프레임당 데이터 바이트(payload)가 최대 64바이트 가능함. 기존 CAN (Classical)에서는 최대 8바이트.
  2. ID 필드 (식별자)는 11비트 또는 29비트 (표준/확장) 사용 가능함.
  3. 핵심: Arbitration, Start of Frame 등 제어 필드는 기존 Classical CAN과 유사하나, **데이터 전송구간(data phase)**에서 더 높은 전송 속도(bit rate switch)를 사용할 수 있음. 즉, 헤더/식별자 부분은 낮은 속도, 데이터 페이로드 부분은 높은 속도로 전환 가능하게 설계됨.
• 한국에서도 CAN-FD 제어기를 Verilog HDL로 설계하여 FPGA 상에서 상용 칩과의 연동 검증을 수행했다는 논문이 있음. 이 제어기는 Classical CAN 규격(CAN 2.0A, 2.0B)도 만족하고, 데이터 속도 및 프레임 크기 모두 확장 가능함을 보여줌.

---

최신 표준: J1939-FD / J1939-22 와의 접목

• J1939도 시간이 흐르면서 Classical CAN 기반의 J1939-21만으로는 데이터 양·속도 요구가 증가하는 트렌드를 따라가기가 힘들게 됨. 이에 J1939-FD (특히 J1939-22) 같은 규격이 제안됨.
• J1939-22는 CAN FD의 대역폭을 활용해서, 기존 J1939-21 (250 kbps 중심) 대비 4–6배 정도의 대역폭 증가를 목표로 함. 또한 최대 페이로드, 메시지 전송 속도, 효율성 측면에서 개선됨.
• 기존 PGN, SPN 체계 등을 가능한 한 유지하면서 새롭게 도입됨으로써, 기존 설비나 ECU와의 상호 운용성을 고려하는 설계가 중요함.

---

비교: CAN2.0 / HS-CAN / J1939 / CAN FD – 실제 차이는 무엇인가

아래는 실제 현장 및 제품 개발 시 체감되는 비교 요소들입니다.
항목 Classical CAN / HS-CAN J1939 (Classical CAN 기반) CAN FD J1939-22 / J1939-FD

메시지 용량 (바이트)	최대 8바이트	같은 8바이트 기본, 필요시 여러 프레임(chained) 사용하는 경우 있음	최대 64바이트 가능	J1939-22에서는 더 긴 메시지, 데이터 효율성 증대됨
속도(비트레이트)	보통 500 kbps ~ 1 Mbps	표준적으로 250 kbps 또는 500 kbps (시스템, 지역, 요구 사항 따라 다름)	데이터 페이로드 전송 시 5 ~ 8 Mbps 가능 (환경 및 트랜시버에 따라 다름)	J1939-22는 Classical 대비 속도/효율 대폭 개선됨
식별자(ID) 길이	11비트 또는 29비트 (표준/확장)	항상 확장 식별자 (29비트) 사용됨이 일반적	동일하게 선택 가능 (11비트 또는 29비트)	J1939-22에서도 확장 ID 체계 유지됨
상호 운용성 / 진단	단순 제어 중심, 메시지 종류 적음	여러 제조사, 상용차/중장비 표준, 진단툴 많음	Classical CAN 호환 가능성 있음, 하지만 혼합 네트워크 시주의 필요함	이전 J1939 및 CAN FD 간 호환성 확보하는 방향으로 설계됨
케이블 길이/노드 수/노이즈 민감도	노드 많거나 케이블 길면 신호 약해짐 / 노이즈 영향 큼	동일한 문제 + 여러 ECU가 많은 환경에서는 더욱 조심해야 함	더 높은 속도 사용 시 케이블, 트랜시버 품질, 노이즈 완화(차폐, 임피던스 일치) 중요성 대폭 증가	J1939-FD에서도 마찬가지, 특히 산업 환경에서는 노이즈/환경 영향 고려 필수

---

구체적 사례: 어디에 어떤 프로토콜이 채택되고 있는가

1. 전기자동차 및 배터리 관리 시스템 (BMS)
   • BMS는 전압, 전류, 셀 온도 등 실시간 데이터가 많고, 상태 변화가 빠름. Classical CAN으로는 여러 개의 메시지를 작게 나눠 보내야 해서 오버헤드가 크고 지연(latency)가 커질 수 있음.
   • 일부 EV 업체들은 BMS 내부 또는 셀 밸런싱 부분에 CAN FD 도입을 검토 또는 일부 양산 적용 중임. 예: 배터리 셀 간 밸런스 조정, 셀 내 온도 예측, 충방전 제어 등에서 주문형 데이터 패킷이 커지면서 효율성이 중요해짐. (한국 및 해외 EV 관련 기술 자료들에서 이런 자주 언급됨)
2. 상용차 / 농업/건설 기계
   • 트럭/버스의 엔진, 배출가스 제어, 변속기, 냉각 시스템, 연료 시스템 간 데이터 교류는 J1939이 오랫동안 표준이었고 아직도 많이 사용됨.
   • 최근 일부 업체에서는 상용차의 진단 시스템 확장, OTA (Over-the-Air) 업데이트, 원격 모니터링(텔레메틱스) 등을 위해 J1939-FD 또는 J1939-22를 통한 더 높은 대역폭 확보 필요성이 제기됨. 예: 배출가스 데이터, 엔진 운전 패턴 통계, 필터 상태, GPS/위치 정보 병합 등 데이터 양이 많아짐.
3. 산업 자동화 및 로봇, 건물 제어 시스템
   • 자동차 외부 환경에서도 CAN FD가 도입되는 사례가 증가 중임. 예: 공장 자동화에서 여러 센서 데이터, 제어기(Actuators) 상태, 오류 진단 데이터 등을 하나의 네트워크에서 통합하고자 할 때 Classical CAN보다 효율적임.
   • 또한, 일부 연구 기관에서는 CAN-FD 제어기를 직접 구현하여 FPGA 등으로 검증함으로써 향후 산업용 모듈, IoT 디바이스, 스마트 빌딩 제어 등에 적용 가능성 확인됨.
4. 자동차의 ADAS / 자율주행 / 인포테인먼트
   • 카메라, 라이다, 레이더 등의 센서 데이터는 용량이 크고 빈도가 높음. 이 부분은 아직 대부분 Ethernet 계열 또는 차량 내부 이더넷(Vehicle Ethernet)과 같은 고속 네트워크가 쓰이는 경우가 많지만, 센서 간 내부 통신 일부, 제어 루프 일부에서는 CAN FD가 보조적으로 또는 일부 역할로 사용됨.
   • 일부 차량 모델에서는 인포테인먼트 디스플레이, 디지털 계기판, 미디어 제어 등에서 전송 속도 및 응답성이 중요해지면서 Classical CAN → CAN FD 전환 고려됨.

---

장단점 정리: 어떤 경우에 어떤 옵션이 유리한가

장점

• 높은 대역폭 / 큰 페이로드 (CAN FD, J1939-FD/J1939-22)
  데이터 전송 효율 증가, 프레임 오버헤드 감소, 지연(latency) 감소 가능
• 기존 표준과의 호환성 (J1939, Classical CAN 계열)
  많이 쓰여 온 하드웨어·소프트웨어가 많고, 진단 툴 및 정비 인프라가 갖춰져 있음
• 확장성 및 미래 투자 측면
  전기차, 자율주행, 텔레매틱스, 센서 데이터의 고밀도화 등으로 데이터 요구량 증가 중
• 표준화된 메시지 구조 (PGN, SPN 등)
  제조사 간 데이터 공유, 정비/진단 용이성, 시스템 통합 시 리스크 감소

단점 및 고려사항

• 하드웨어 비용 및 트랜시버 성능 요구 증가
  CAN FD 사용 시 더 높은 속도와 큰 페이로드를 처리할 수 있는 트랜시버가 필요하고, 노이즈, 선형 임피던스, 배선 차폐 등에 민감함
• 네트워크 설계 복잡성
  노드 간 거리, 케이블 길이, stub 길이, 차폐, 버스 탑폴로지(bustopology), 혼합 네트워크(Classical CAN + CAN FD) 시 호환성 문제 등이 발생 가능
• 진단 및 소프트웨어 수정 필요성
  PGN/SPN 데이터베이스 업데이트, 메시지 처리 로직 변경, 에러 검출/CRC 처리 강화 등 개발 및 검증 시간 요구됨
• 확장성에 따른 시스템 부하 및 우선순위 설계
  더 많은 메시지 → 버스 로드(bus load)가 높아질 수 있으며, 우선순위 ID 설계, 메시지 주기(period), 빈도 설계 등이 중요함

---

실제로 프로토콜 선택 시 체크리스트

프로젝트 또는 제품 단위로 아래 항목들을 미리 체크하면 후에 시행착오 줄일 수 있어요.

1. 필요한 데이터 전송량
   • 전달해야 할 메시지의 크기(bytes), 빈도(Hz), 동시 메시지 수
2. 요구되는 응답 속도(latency)
   • 실시간 제어, 긴급 제어, 안전 관련 제어 등이 포함되는가
3. 노드 수 및 배선 인프라
   • 노드가 많을수록 식별자(ID) 충돌 가능성, 케이블 길이/임피던스 문제, 노이즈 증가
4. 기존 시스템 호환성
   • 기존 Classical CAN 혹은 J1939 기반 시스템과의 통합 여부
   • 진단툴/소프트웨어 업데이트가 가능한지
5. 환경적 조건
   • 온도, 진동, 전자파 간섭(EMI), 케이블 차폐 요구 등
6. 표준 준수 및 인증 요구사항
   • SAE, ISO 규격, 업체별 또는 지역별 인증 요구
   • J1939-22 등 최신 규격 적용 여부
7. 비용 vs 이익 분석
   • 하드웨어 트랜시버, 케이블, 설계 및 검증 비용
   • 시스템 유지보수, 업그레이드, 미래 확장성 고려시의 비용 절감 가능성

---

상황별 추천

• 단순 제어, 메시지 양·속도 요구 낮은 환경이라면 Classical CAN / HS-CAN (CAN2.0 계열)도 충분히 좋은 선택임. 예: 단순 센서 모니터링, 미러 제어나 문 잠금 같은 기능.
• 상용차 / 중장비에서는 현재도 **J1939 (Classical CAN 기반)**이 매우 널리 쓰이고 있고, 대부분의 엔진 ECU, 배출가스 제어, 변속기 제어 등에 안정적으로 작동함.
• 데이터량이 많아지고 실시간성이 강조되는 경우와 미래 확장성 고려 시에는 CAN FD 또는 J1939-FD / J1939-22 쪽이 유리함.
• 또한, 혼합 네트워크(Classical + FD) 구성이나 업그레이드 마이그레이션(migration) 전략을 미리 설계하면 비용 및 리스크 절감 가능.