Intro

우선, 이름을 이렇게 지은 것에 너무나도 유감을 보낸다.
하지만, 임베디드 개발에 들어오면 용어가 이따구인 경우가 너무나 많기에 모든 개발자 분들에게 응원의 메시지를 보낸다.(나는 책에서 본 이 말이 너무나 위로가 됐다..)

어찌 됐건 저찌 됐건
오늘의 주제는 CAN(Controller Area Network)다.
뭐 한 동안 이 주제를 다룰 것이고 나 역시 계속해서 이에 대해서 알아야 한다.

처음에 CAN을 들었을 때 CAR blah blah 인가 했는데 아니었고...
TCP/IP 밖에 모르던 내가... 새로운 통신 규약을 배운다?

너무나도 재밌었다.(개발자의 재미는 힘들고 고생했다는 뜻?)

CAN에 관해 어떻게 설명하고 찾아 봤던 자료들을 정리해서 올리는 게 좋을지가 많이 고민이 되는 부분이다. CAN은 프로그래밍에 괂난 내용이 나오지 않고,
개념적인 것이기 때문이다. 즉 이걸 안다고 프로그래밍을 잘 할 수 있는 건 아니다.
하지만 이걸 모르면 CAN을 활용한 그 어떠한 것도 할 수가 없다...

자료나 강의들을 보면 CAN 만을 설명하는게 아니라 다양한 통신들도 소개하며,
CAN이 가지는 특징과 구간에 대해 상세히 써 두었다. 정말 감사한 일이다.

하지만 특정 회사의 CAN 통신을 보조해 주는 Tool을 사용하는 것이 아니면 꽤나 그 내요오가 의미를 이해하기가 어려울 수 있다.

그래서 해당 부분을 최대한 함께 기재할 수 있도록 하겠다. :)

CAN은 이름이 정말 왜 이렇게 음료수 캔과 같게 만든 건지...검색으로 쉽게 찾기도 어렵고,
무슨 CAN에 관련된 기관도 CiA라고 지어나서... 미중앙정보국이랑 이름을 같게 지어서...

검색이 안 되게 만든 기적의 ... 작명 센스를 가지고 있는 곳인 만큼 한국 자료가 늘고 도움이 많이 되면 좋곘다.

CAN bus

can을 검색할 때의 tip 중에 하나는 can bus라고 검색하는 것이다. 이렇게 검색하면 stackoverflow나 관련한 내용이 나오기 시작한다.

can은 Controller 한국어로는 제어기, 조금 더 이해하기 쉽게 이야기하면 하나의 디바이스(기계장치 ex 휴대폰이라고 가정하자.)에 해당한다. 이러한 제어기를 Network연결해서 통신을 하게 만드는 방식 중에 대표적으로 사용되는 방식이 CAN bus다.

두 개 이상의 제어기가 서로 신호를 주고 받으며 원하는 결과를 받기 때문에 can은 단독으로 존재하는 것만으로는 의미를 가지기 어렵다. 마치 사람이 뇌 하나만 있다고 또는 팔 하나만 있다고 해서 움직일 수 없는 거라고 보면 될까 싶다.(이 비유가 맞을지는 모르겠다. 하지만 핵심은 신호의 수신자, 신호의 송신자 모두가 있어야 유의미하며 서로 접촉함에 따라서 반응을 하고 동작을 하는 것에서 크게 다르지 않은 것 같다.)

bus는 우리가 집에서 나와 버스 정류장까지 가면 bus를 타고 일정한 노선을 이동하며 사람을 태우고 내리게 할 수 있는 것을 말하는데 이 개념이 그대로 적용된다.

가령, 우리가 명절 연휴 같은 경우에, 대중 교통을 이용해서 교통 혼잡을 줄이자 라는 이야기를 하면 모두 쉽게 납득을 할 수 있을 것이다.

이처럼 우리가 can을 이용해 통신을 할 때 대중교통에 해당하는 bus를 이용한다면 교통혼잡을 줄일 수 있다. 하지만 각각의 자차를 이용한다면 교통 혼잡으로 의도하지 않은 사고와 불편을 겪게 되는 것이다.

하지만 우리는 실생활을 통해 잘 알고 있다. 대중 교통이 무조건적으로 편리한 게 아니라는 걸, 때로는 시간을 넘겨서 놓친다던지, 유튜브를 보다가 내려야 하는 곳을 놓친다 던지, 버스가 만석이어서 버스를 이용할 수 없다던지...

이런 현실의 모든 상황들이 실제 CAN에서도 발생한다.

그리고 이러한 문제를 해결하는 것이 CAN 통신을 다루는 Software Engineer의 핵심 역량이 된다.

앞서 이야기 했던 대중 교통과 연휴 시즌의 내용을 통해 CAN에 대해 다시 이야기 해 보자.

우선 CAN bus가 어디서 효율적으로 사용되는지를 생각해 볼 수 있다.

많은 제어기들이 서로 연결 되어 있어야 하고, 이러한 제어기들이 개별적으로 있을 때 불편한 경우가 발생하는 환경이 바로 CAN bus가 높은 효율을 보이는 영역일 것이다.

그리고 자동차는 이러한 환경에 해당한다. 현재 자동차에는 무수히 많은 제어기가 제한된 '공간(Area)' 안에 들어가고 제한된 공간에 각각의 모든 제어기가 각각 연결이 되어 통신을 한다면 굉장히 많은 선의 연결이 발생해 복잡하고 무게가 늘어날 것이다.

컴퓨터 조립에서 선 정리 하는 것에서도 사람들이 스트레스를 받는데 자도아 동작을 위해 사용하는 제어기 조작을 위해 쓰이는 선이 모두 각각 연결 되어 있다면?
얼마나 복잡해 질지 간단하게 5가지 정도만 생각해 보자.

우선, 엑셀을 밟을 때 속도가 올라가는 것과 브레이크를 밟는 것, 그리고 변속기를 변경하는 것, 왼쪽 오른쪽 깜박이를 넣는 것, 와이퍼 조작 등 몇 개 안 되는 것 처럼 보이지만 연료의 사용량이라던지, 즉각적으로 발생하거나 우선 순위 지연시간 등 생명과 직접 연관된 기능도 많이 있다.

가령, 엑셀을 밟았는데 속도가 갑자기 200이 된다거나, 변속기를 d로 했는데 후진을 한다던지 브레이크가 동작하지 않는다던지 정말 많은 상황들이 있을 수 있다.

이 모든 것이 오직 전기로만 동작하지 않도록 설계하는 이유가 있겠지만, 전기적 신호를 통해 보조하고 정밀하게 조작할 수 있도록 하는 것 역시 굉장히 중요한 이유다.

또한 앞으로 더 많은 것들이 전기 신호로 대체되고 무인 자동차 시대에는 모든 속도의 증감 방향 전환의 신호(물론, 모든 자동차가 무인 자동차가 되면 깜빡이 무선으로 상호 자동차간의 통신을 통해 변경이 이루어지겠지만...여기까지 가는 과도기도 있고 법규적인 문제들도 많이 있기 때문에 향후 20년 이상은 깜빡이 같은 것이 존재하지 않을까 생각해 봅니다...)

현재의 보조 수단이 나아가 기본적인 제어 장치가 된다고 했을 때 중요한 것은 속도인데, 이건 조금 다른 이야기가 되기 때문에
(CAN은 최대 1Mbps 밖에 속도가 나지 않는다. 하지만 이도 500Kbps로 제한해서 사용하는게 현재 자동차 시스템이기 때문에 이제부터 CAN의 특징에 대해서 알아 보자!!)
이와 관련된 내용은 CAN에 관한 이야기가 끝난 다음에 이야기하는 게 좋을 것 같다!

자, 그렇다면 현재의 보조 수단으로 쓰이는 과도기의 CAN 그리고 이 과도기의 CAN이 나아가 발전해 가는 CAN-FD 그리고 왜 이렇게 발전했으며 이 발전을 통해 알 수 있는 자동차 임베디드의 주요한 핵심 가치에 대해서는 다음에 알아 보도록 하자 :)