CAN과 CAN-FD를 혼합 사용하면 ...?

시작하기 전에

CAN이 탄생한 시기에 CAN의 (최대 1Mbps가 가능하지만 통상 사용되는) 500kbps 라는 통신 속도는 느린 편이 아니었다. CAN 출현 후 거의 40년이 지난 오늘날 우리에게 익숙한 통신 속도의 단위는 Mbps나 Gbps이다. 이에 비하면 500kbps는 (실제 느린가는 별도 논의의 좋은 주제라고 생각하지만) 느린 느낌이다.

CAN을 발명한 Bosch는 누구보다 이걸 잘 안다. 그래서 CAN의 속도를 개선하였다. 임시로 이 개선된 CAN을 2세대 CAN이라고 부르겠다.

CAN이 가장 많이 사용되는 산업 분야인 자동차 산업은 제품의 수명 주기가 길다. 자동차사들은 원가를 낮추기 위해서 '규모의 경제'를 최대한 활용한다. 차종간에 부품을 공유할 수 있도록 설계하고, 부품을 구매할 때 한 차종이 아니라 여러 차종의 부품을 한꺼번에 계약한다. 그 결과, 부품의 평균 수명 주기는 자동차의 평균 수명 주기보다 길다.

그래서 2 세대 CAN은 속도가 빠른 것도 중요하지만 1세대 CAN과 호환이 되는 것도 중요하다. 어떤 부품들은 아직 수명이 많이 남아있고, 이들을 2세대 CAN을 적용하여 개발한 새 제품으로 교체하면 개발비 등 매몰되는 비용이 크기 때문이다.

똑똑한 보쉬 사람들은 다음의 아이디어를 냈다.

• CAN 통신 전송을 조율하는 헤더 부분은 기존 CAN 속도로 전송하고 (CAN은 헤더의 메시지 아이디로 우선 순위가 결정된다.)
• 데이터 부분은 고속으로 전송하도록

하는 것이다.

전송 속도 (Data rate)를 유연하게(Flexible) 운용하는 것이다. 그들은 2세대 CAN을 CAN-FD라고 불렀다. (그들은 3세대라고 할 수 있는 CAN-XL을 내놓았다.)

한 CAN 버스에 CAN과 CAN-FD를 정말 혼용해서 사용할 수 있는가? 그런 경우 어떤 제약이 있을까? 

  

 

개요

• 아래 표의 결과를 예상한다. 아래 표의 결과가 맞는지 실험해 본다. 

	수신 제어기
송신 제어기	CAN	CAN-FD
CAN	ok	ok
CAN-FD	nok	ok

• nok는 곧 에러가 발생한다는 의미이다. 수신 제어기에 어떤 에러가 어떤 식으로 발생하는지 확인한다.

 

실험 환경

• CAN 채널이 2개 있는 TC1013 2개를 이용한다.
• TC1013에 Y-케이블을 연결하여 2개 채널을 모두 사용할 수 있도록 한다. 각 채널은 하나의 제어기를 대신한다.
• 4 채널을 점퍼 케이블로 연결하여 동일한 CAN 버스에 연결한 상태를 구성한다.

총 4개 채널들 중에서 2개는 CAN으로 2개는 CAN-FD로 설정하였다. 4 채널을 점퍼 케이블로 연결하였다.

 

• 2 채널에만 CAN 종단 저항을 적용한다.
• 1번과 2번 채널은 CAN으로, 3번과 4번 채널은 CAN-FD로 설정한다.
• CAN의 통신 속도와 CAN-FD의 헤더 부분 통신 속도를 모두 500kbps로 설정한다. CAN-FD의 데이터 부분 통신 속도를 2Mbps (2,000kbps)로 설정한다.

각 채널을 위 그림처럼 CAN/ CAN-FD, 종단 저항, 전송 속도를 설정하였다.

• Controller Mode는 Normal로 하였다. (나중에 ACK Off로 설정하여 실험한다. ACK의 영향은  timestamp, ACK와 ACK error :: hsl's tsmaster 사용기를 참조하십시오.)

 

실험용 CAN 메시지

• TSMaster의 CAN/ CAN-FD Transmit 창에서 전송할 메시지를 준비한다.
• 행 1: CAN 제어기에서 8 바이트 CAN 메시지 전송
• 행 2: CAN-FD 제어기에서 8 바이트 CAN 메시지 전송
• 행 3: CAN-FD 제어기에서 8 바이트 CAN-FD 메시지 전송. 헤더와 데이터에 동일 전송 속도 적용
• 행 4: CAN-FD 제어기에서 8 바이트 CAN-FD 메시지 전송. 헤더와 데이터에 다른 전송 속도 (x 4) 적용
• 행 5: CAN-FD 제어기에서 32 바이트 (데이터 전송 속도가 헤더 전송 속도의 4배라서, 데이터 길이를 4배 늘렸다.) CAN-FD 메시지를 전송. 헤더와 데이터에 동일 전송 속도 적용
• 행 6: CAN-FD 제어기에서 32 바이트 CAN-FD 메시지를 전송. 헤더와 데이터에 다른 전송 속도 (x4) 적용

 

 

CAN 제어기에서 8 바이트 CAN 메시지 전송

• (예상대로) OK . 송신 제어기나 수신 제어기에 문제가 발생하지 않는다. 

CAN 제어기에서 CAN 메시지를 전송하는 경우, CAN 제어기의 수신에 CAN-FD 제어기의 수신에 문제가 발생하지 않는다.

 

 

CAN-FD 제어기에서 8 바이트 CAN 메시지 전송

• (예상대로) OK
• 송신 제어기나 수신 제어기에 문제가 발생하지 않는다.

 

 

CAN-FD 제어기에서 8 바이트 CAN-FD 메시지 전송. 헤더와 데이터에 동일 전송 속도 적용

• (예상대로)  CAN 제어기는 NOK CAN-FD 제어기는 OK
• CAN 제어기들에서 메시지 수신 에러가 발생한다. CRC 에러다. 
• CAN 프레임과 CAN-FD 프레임의 헤더 구조 살짝 다르다. (내가 좋아하는 설명이 있는 페이지를 링크하는 것으로 나의 애정을 표시한다.  CAN FD Explained - A Simple Intro [2023] – CSS Electronics )

CAN 프레임과 CAN-FD의 구조 차이로 CRC 부분의 위치가 다르다.

• CAN 제어기가 500kbps의 속도로 메시지를 처리하면서 CRC 부분을 처리하는 순간, 실제 CAN-FD 프레임은 CRC 부분이 아니다. CAN 제어기는 CRC 에러를 검출한다. 헤더에 CAN-FD 프레임 여부를 표시하는 비트가 있는데, 이 비트를 보고 CAN-FD 프레임을 처리하지 않을 수도 있겠지만 이렇게 구현되어 있다.   
• 예상 밖으로, 수신한 CAN-FD 제어기에 stuff 에러가 발생한다. 송신한 CAN-FD 제어기에도 bit 에러가 발생한다. 아래 그림의 경우이다.
• TSMaster의 하드웨어 설정에서 헤더 부분과 데이터 부분의 속도를 다르게 했다. 그러면 BRS가 on이 되어야 한다. 그런데 Transmit 창에서 BRS( Bit Rate Switching)를 off로 했다. 아마 이 이유로 송신 제어기가 bit 에러를 검출한 것 같다. 수신 제어기는 비트가 잘못 채워져서(stuff) stuff 에러를 검출한 것 같다.
• 바로 이 실험 셋-업에서 바로 이 경우에, 모든 수신 제어기가 메시지를 수신하지 못했다. 그래서 어떤 수신 제어기도 ACK 신호를 전송하지 않는다. 송신 제어기는 ACK 신호를 받지 못했기 때문에 재송신을 "1회" 하였다. 재송신 메시지를 CAN-FD 제어기가 수신하고 ACK 신호를 보냈다. 송신 제어기가 재전송할 때는 알아서 BRS를 on 해서 전송한 것 같다. 그러니 수신 제어기가 ACK를 했을 것이다. 송신 제어기는 추가 재송신을 하지 않는다. timestamp, ACK와 ACK error :: hsl's tsmaster 사용기에서 실험한 것처럼 ACK가 계속 발생하지 않았다면 CAN 버스는 재전송 메시지로 홍수가 났을 것이다. 

• 예상했던 결과는 아래 그림과 같다. 실제로 동일한 메시지를 수동으로 다시 송신하니 아래 그림처럼 되었다. CAN 제어기들은 에러를 검출하고, CAN-FD 제어기는 정상적으로 수신한다.

• 실제 이렇게 사용하는 경우는 없을 것으로 생각한다. CAN-FD 적용으로 인한 속도 향상이 없기 때문이다.

 

CAN-FD 제어기에서 8 바이트 CAN-FD 메시지 전송. 헤더와 데이터에 다른 전송 속도 (x 4) 적용

• (예상 대로) CAN 제어기는 NOK CAN-FD 제어기는 OK
• CAN 제어기들에서 메시지 수신 에러가 발생한다. CAN-FD 제어기들은 송신 에러나 수신에러가 발생하지 않는다.

 

 

CAN-FD 제어기에서 32 바이트 (데이터 전송 속도가 헤더 전송 속도의 4배라서, 데이터 길이를 4배 늘렸다.) CAN-FD 메시지를 전송. 헤더와 데이터에 동일 전송 속도 적용

• (예상 대로)  CAN 제어기는 NOK CAN-FD 제어기는 OK
• CAN-FD 메지시의 전송이 CAN 제어기 입장에서 너무 빨리 종료되는 것이 문제라면, 그렇지 않게 하면 어떨까 하는 의문이 생겼다. 데이터 부분의 전송 속도를 4배로 늘렸으니 데이터양을 4배로 늘리면 될까?
• BRS를 off하고 전송하면 CRC 에러가 발생한다. CAN 제어기가 CRC를 기대하는 순간에 CRC가 아닌 메시지의 데이터가 들어온다. 우연히 데이터가 CRC와 같지 않다면 (아마 대부분 그럴 것이다.) CRC 에러 검출은 당연하다. CRC를 통과한다고 해도 다른 에러가 검출될 것이다.
• 위에서 언급한 것처럼 CAN과 CAN-FD의 헤더 부분은 완전히 동일하지 않다. 헤더에서 에러를 검출할 만도 한데 안 그렇다.

 

 

CAN-FD 제어기에서 32 바이트 CAN-FD 메시지를 전송. 헤더와 데이터에 다른 전송 속도 (x4) 적용

• CAN 제어기에서 CRC 에러가 아닌 stuff 에러가 발생한다. 

 

 

 

결론

• CAN과 CAN-FD를 섞어서 사용할 수 있다. 비록 CAN-FD 메시지를 수신한 CAN 제어기들쪽에 에러가 발생하지만, 에러가 timestamp, ACK와 ACK error :: hsl's tsmaster 사용기 에서 설명한 경우처럼 재전송 메시지로 CAN 버스를 점유하는 에러가 아닌 일회성 에러이다. 그래서 CAN과 CAN-FD의 혼용이 가능하다.
• CAN 아이디를 잘 정리하면, CAN Controller의 마스크를 이용하여 CAN 제어기들은 CAN-FD 메시지들을 CAN Controller 수준에서 무시하도록 수 있다. 예를들어, CAN-FD 메시지는 11 비트 길이의 아이디 중에 3번과 7번 비트가 세트되도록 정의했다면, CAN 제어기의 CAN Controller에 3번과 7번 비트가 세트된 메시지들은 무시하도록 설정할 수 있다. 그러면 에러 발생을 회피할 수 있을 것이다. (추측이다. 나중에 해볼까? 안 되는 것을 확인하는 것은 의미도 재미도 없기는 하다.) 
• 그런데 CAN 아이디를 정리하는 것은 복잡한 일이다. 관련된 제어기가 많으면 복잡도는 급격히 증가할 것이다. 어떻게 하면 위에서 말한 부품의 수명을 계획대로 유지하면서, 즉, 매몰 비용을 피하면서 CAN-FD를 도입할 수 있을까? 아마 전체를 CAN-FD로 전환하는 것이 속편하기는 할 것이다.
• CAN-FD 도입이 한참 진행되어 전체 제어기들에 CAN-FD로 전환된 경우, 헤더 부분의 속도도 데이터 부분의 속도만큼 올린다면 버스 로드에 여유가 생겨서 새 메시지드들을 추가할 수 있을 것이다. 필요하다면. 
• 이런 실험을 SiLS(Software in the Loop Simulation)으로 할 수 있을까? SiLS로 하려면 CAN Controller를 소프트웨어로 시뮬레이션 해야한다. 기술적 가능성과 상업적 유용성이 모두 있어야 한다. 기술적으로 가능하다면 그리고 내가 CAN Controller 회사의 결정권자라면 나는 시뮬레이션을 할 수 있는 코드를 만들어서 적절한 형태로 고객사에게 팔 것이다. 고객들이 SiLS을 하고 싶어할 테니까. 그걸 제공 할 수 없는 CAN Controller 회사와 차별화가 될 테니까. 적절한 형태란 우리 회사의 지적 재산권이 보호되는 형태다. 

 

목차 :: hsl's tsmaster 사용기