목차
개요
차를 다 완성해도 사실 우리는 우리가 만든 차에 대해 잘 알지 못한다. 데이터로깅의 필요성은 굳이 언급하지 않아도 차가 굴러가기 시작하면 모두가 느낄 수 있을 것이다.
대부분의 차량용 장비는 CAN으로 자신의 정보를 출력한다. 우리 팀의 Orion BMS 2와 PM100DX 컨트롤러도 마찬가지다. 차량에서 정보를 수집하고 싶다면 CAN 통신을 읽을 수 있어야 한다.
그러나 CAN 통신을 잘못 이해하고 사용하는 경우를 많이 보았다. 통신을 하려면 일단 그 통신이 어떤 것인지 대충은 알아야 한다. 적어도 종단 저항과 차동 신호에 대해서는 이해하는 것이 좋다. 그러니 일단 CAN에 대해 조금 알아보자.
Controller Area Network, CAN
CAN은 1986년에 Bosch가 공개한 통신 프로토콜(약속)이다. 여러분이 쓰는 드릴 만드는 그 보쉬 맞다. 1991년부터 완성차에 탑재되기 시작했다. 현재 CAN 2.0이 자동차 외에도 여러 산업에서 널리 쓰이고 있다. OBD-II에도 사용된다.
CAN 통신은 차동 신호 버스를 이용하는 1:N 통신이다. 모든 노드(통신 장비)는 CAN-H와 CAN-L로 이루어진 두 가닥의 통신 버스에 자기 다리를 내려 연결된다.
이런 식이다. CAN 버스는 가로로 긴 CAN-H, CAN-L 전선을 말한다.
CAN 통신 속도는 250kbps, 500kbps, 1Mbps가 많이 사용된다. 통신 속도가 느려질수록 버스의 길이 제한이 늘어난다. 500kbps에서 CAN 버스는 100m까지도 길어질 수 있다.
한편, 각 유닛이 이 버스에 내리는 다리는 stub라고 부른다. 이 거리는 상대적으로 짧아서 50cm 이상 길어지면 통신에 문제가 생길 수 있다.
종단 저항
그림에서처럼 버스의 양 끝단 CAN-H, CAN-L는 120Ω 저항으로 연결되어 있다. 이를 종단 저항이라고 부르며, 임피던스 매칭을 위해 사용된다고 하는데 이런건 몰라도 된다. 다만 종단 저항은 꼭 있어야 한다.
정상적으로 구성된 CAN 버스는 양 끝에 120Ω 저항이 병렬로 달려 있기 때문에 멀티미터로 CAN-H, CAN-L 사이의 저항을 재면 60Ω이 측정된다.
대부분 장비는 종단 저항을 설정할 수 있다. 우리 BMS는 CAN 버스가 2개라서 종단 저항이 내장된 버스와 없는 버스가 하나씩 존재한다. 컨트롤러는 EEPROM으로 종단 저항을 사용할지 여부를 설정할 수 있다.
이러한 장비들과 데이터로깅에 사용할 CAN 트랜시버의 종단 저항을 확인해서 종단 저항이 있는 2개의 장비가 CAN 버스의 양 끝에 오도록 연결해야 한다. 꼭 멀티미터로 직접 측정해 보자.
차동 신호
RS232나 여러분이 아두이노에서 한번쯤 써 보았을 UART 시리얼 통신은 모두 GND를 기준으로 신호를 주고받는다. 신호선이 GND를 기준으로 0V면 LOW, 5V면 HIGH 이런 식이다.
반면 CAN 통신에는 GND가 없다. 대신 CAN-H와 CAN-L 사이의 전압차가 신호를 만든다.
두 선 사이에 전압차가 없으면 HIGH, 있으면 LOW이다. 이렇게 하면 노이즈 저항성이 높아진다. 사실 그러려면 CAN 버스의 두 선을 꼬아 주어야 효과가 극대화되지만, 그런 것까지 신경쓸 필요는 없다.
통신 규칙
CAN에는 통신을 통제하는 마스터 노드가 없다. 누구든 떠들고 싶으면 버스에 대고 조잘거리면 된다. 물론 두 노드가 동시에 떠들면 충돌이 일어나지만 이런 상황은 장비들이 알아서 잘 프로토콜에 정해진 대로 대처한다. CAN 트랜시버를 만들 게 아니라면 몰라도 된다.
CAN 통신은 메시지 단위로 이루어진다. CAN 메시지는 이렇게 생겼다.
다른 거 다 몰라도 된다. 메시지마다 11bit짜리 ID가 있고 데이터는 최대 64bit(8Byte)까지 담을 수 있다는 것만 알면 된다. 데이터가 몇 바이트 길이인지에 대한 정보도 control 섹션에 담겨 있어서 알 수 있다.
CAN 2.0B는 ID를 29bit까지 쓸 수 있는데, 이런 부가적인 것은 필요하면 그 때 찾아보면 된다.
대부분의 장비는 CAN ID별로 내보내는 정보를 정해 놓고, 같은 메시지를 주기적으로 버스에 브로드캐스팅한다.
이런 식이다. ID가 0x0A0인 메시지의 2, 3번 바이트는 B상 IGBT 모듈의 온도 정보를 담고 있다는 뜻이다.
이런걸 한가득 미리 정해서 매뉴얼에 적어 놓고, 이 메시지를 일정한 주기(100ms 등)로 실시간 정보를 담아 CAN 버스에 방송한다.
CAN 통신 읽기
이러한 CAN 메시지 중에서도 우리가 진짜 궁금한 것들은 주행 도중에 나오는 정보들이다. 하지만 주행 데이터를 보겠다고 차에다 노트북을 달아 놓고 달릴 수는 없는 노릇 아닌가? 우리에게는 노트북 대신 CAN 버스에 어떤 데이터들이 날라다녔는지 보여줄 작은 컴퓨터가 필요하다.
하지만 아두이노나 STM32 같은 대부분의 MCU는 CAN의 차동 신호를 처리할 수 있는 기능 자체가 없다. 이러한 MCU가 CAN 통신을 하려면 트랜시버를 사용해야 한다.
CAN 트랜시버는 차동 신호를 MCU가 알아먹을 수 있는 디지털 신호로 바꿔준다. 제일 흔하게 사용하는 것은 MCP2515이다. 이 칩이 들어간 CAN 트랜시버 모듈을 통해 MCU를 CAN 버스에 연결해야만 MCU가 CAN 신호를 이해할 수 있다.
이렇듯 CAN은 아예 다른 통신 방식이다. 대회를 준비하면서 CAN 버스를 아두이노의 시리얼 통신 핀인 TX, RX에 연결했는데 데이터가 불안정하다거나, 컨트롤러에서 나오는 CAN 버스를 MCU와 연결했더니 IMD가 FAULT를 띄웠다는 등의 이야기를 들었다. 아마 다 트랜시버를 잘못 사용해서 발생하는 문제가 아닐까 싶다. CAN 버스가 HV랑 그라운드를 공유할 리는 없으니 말이다.
CAN 트랜시버를 사용해서 CAN 메시지를 읽는 예제 코드같은 것은 이 글에서 설명하지 않는다. 아두이노로 CAN 통신하는 예제야 인터넷에 충분히 많고, STM32 다룰 정도면 아마 HAL 헤더 보고 충분히 직접 짤 수 있을 것이다.
데이터로거
그런데 사실 데이터로거를 사용할만한 수준으로 직접 만드려면 손이 많이 간다. MCU가 CAN 버스 모니터링도 해야 하고, 수집한 데이터를 차량 전원이 꺼져도 들고 있어야 하니 플래시나 SD카드에 적어놓기까지 해야 한다. 거기에 데이터 분석 도구까지 만드려면 한세월이다.
차 만들기도 바쁜데 아마 대부분이 기계과일 테니 별로 안 친한 코딩과 놀 시간이 없을 것이다. 그래서 우리 팀이 이번에 사용하고 기술아이디어 금상을 받은 데이터로거를 아무 팀이나 자유롭게 쓸 수 있도록 하드웨어와 소스코드 전체를 GitHub에 공개해 두었다.
현재는 데이터로거가 우리 팀이 사용하는 컨트롤러와 BMS에 맞춰 프로그램이 되어 있고, PCB가 차단 회로와 함께 합쳐져 있어서 바로 사용할 수는 없는 상태이다.
아무 팀이나 가져다 만들어 쓸 수 있도록 PCB 설계도와 부품 목록, 소스코드, 업로드 툴, 사용 매뉴얼을 공개할 예정이다. 현재 기판을 설계하고 코드를 고치고 있으니 작업이 완료되어 공개하면 많은 관심을 부탁드린다.