자동차의 ECU 그리고 BMW 의 코딩

자동차에는 ECU 라는 장치가 있습니다.

ECU 는 Electric Control Unit 의 약자로 자동차의 다양한 부분들을 전자적으로 제어하는 역할을 담당합니다.

ECU 는 하나의 차량안에 여러개가 있으며 각각 담당하는 부분들이 다릅니다.

차량 제조사마다 칭하는 이름은 다르지만 BMW 의 경우 BDC(Body Domain Controller), DKMOBI4 등이 있습니다.

BDC 는 차량의 전체적인 부분에 대해 담당을 하며 도어제어, 라이트제어 등 여러가지 부분들을 담당하고, DKMOBI4 의 경우 흔히 말하는 계기판(Instrument Cluster)이며 계기판의 역할만 담당합니다.

이렇게 보면 흔히 백엔드 프로그래머들이 말하는 MSA(Micro Service Architecture) 와 유사합니다. MSA 가 생겨난 이유중 하나는 한쪽에 문제가 생겨도 다른쪽에는 문제가 생기지 않도록 한다는 점이 있는데 자동차에서 이런 구성을 도입한 이유도 동일합니다.

예를들면 BDC가 문제가 생겨도 엔진을 컨트롤하는 ECU는 분리되어 있어 주행중 시동이 꺼지는 참사는 피할수 있습니다. 주행중에 문이 열리지 않거나 라이트가 제어되지 않아도 엑셀과 브레이크 그리고 핸들만 동작하면 사고날 확률은 적을 것입니다.

이런 여러 ECU 들은 서로 통신을 하게 되는데 CAN 이라는 bus 를 통해서 통신을 하게 됩니다. CAN 은 차량에서 많이 사용되는 내부 통신 방법으로 멀티캐스트와 비슷하게 방송을 하듯이 커뮤니케이션 하게 됩니다.

다른 ECU가 듣던 말던 내가 할말을 방송한다는 뜻입니다. 그래서 CAN 버스에 연결하고 통신 내용을 감청(sniff)하게 되면 짧은 시간안에 엄청나게 많은 메세지가 오고갑니다. 특정 ECU가 다른 ECU에 요청을 할 경우 본인의 요청 메세지를 broadcast 한 뒤 상대편 ECU가 응답하는 broadcast 메세지를 골라서 수신하는 방식으로 통신합니다.

그리고 broadcasting 의 장점으로 한번 방송하면 여러 ECU에서 수신할수 있습니다. 예를들면 계기판과 HUD가 속도계산 담당 ECU에서 현재 속도값을 가져와 표시하고 싶다면 속도계산을 담당하는 ECU에서 지속적으로 broadcasting 하고 있는 현재 속도값을 읽어서 표시하기만 하면 된다는 편리함이 있습니다.

하지만 얼핏보면 되게 비효율적이고 높은 처리량이 필요할것 같아 보이지만 의외로 신뢰성이 높고 안정적으로 운용되는 통신 시스템입니다.

그리고 CAN 통신은 차량의 실질적인 제어에 대한 부분을 담당하기 때문에 CAN 통신 값을 조작하게 되면 엑셀을 밟게 한다거나 핸들을 돌린다거나 시동을 끄는 동작들이 가능합니다. 이런 기능들을 응용하면 자율주행차를 만들수 있는 기본 인터페이스를 구축할수 있겠지요. 물론 엑스박스 패드나 PS4 컨트롤러로 차량 운전하기와 같은 것도 가능하겠지만 실제로 실행하기에는 무서울듯 합니다.

 

BMW 의 경우는 이러한 차량이 통신하는 네트워크에 LAN 으로 접속할수 있는 인터페이스를 만들어 두었습니다.

기존에 차량의 고장코드나 각종 점검을 위해 사용하는 OBD 단자가 있는데 BMW 는 이 단자의 일부 pin 을 LAN 에 할당하여 LAN 으로 통신할수 있도록 구현해놓았습니다.

원래는 서비스센터나 각종 딜러사에서 전용 프로그램을 통해 차량의 상태를 쉽게 확인하고 변경할수 있도록 하기 위해서 만들어진 인터페이스지만 누군가에 의해 이러한 프로그램과 인터페이스 구조가 유출되어 현재는 많은 사람들이 사용하고 있습니다.

이러한 인터페이스를 일반 사용자들이 어디에 사용할까 하는 궁금증이 들 수 있을텐데요. 차량의 ECU에는 본인의 차량에 맞는 변수값들과 설정값들을 가지고 있습니다. 하지만 이 변수값을 수정하면 없던 기능이 생겨난다면 어떨까요?

차량 제조사가 국가와 차량마다 기능을 제한하기 위해서 이렇게 ECU 내부 변수들로 기능을 비활성화 한 채 출시하는 방법을 사용하고 있습니다. 이 방법이 실제로 부품이나 기능 데이터를 빼고 출시하는것 보다 간편하고 비용이 절약되기 때문입니다.

하지만 BMW 의 경우 자체 프로그램이 너무 잘 만들어져 있어 이를 통해 비교적 쉽게 이러한 값들을 수정하고 차량에 등록하는 과정을 진행할수 있었기 때문에 좀 더 널리 알려진 면이 있습니다.

예를들면 오토하이빔, 반자율주행과 같은 기능들이 차량 판매시에는 비활성화 되어 있지만 관련 부품은 차량에 장착되어 있다면 이러한 변수값 코딩 과정을 통해 활성화 하여 사용할수 있습니다.

 

하지만 시간이 지나서 BMW도 이것을 어떻게 막을까 고민을 하게 되면서 새로운 방지책이 추가되었습니다. 기능 추가는 코딩 과정을 통해 가능하지만 실제 활성화는 활성화 코드가 담긴 인증서와 값이 있어야만 활성화가 되도록 해놓은 것이지요. 그래서 이러한 부분이 적용된 기능들은 코딩 과정을 통해 메뉴를 활성화하여 활성화 체크를 하더라도 실제 기능은 동작하지 않습니다. 하지만 활성화 과정이 비교적 복잡하기 때문에 중요하거나 돈이 될만한 부분들(네비게이션 지도 업데이트, 없던 부품을 추가하는 부분 등)에만 적용이 되어 있습니다.

그리고 이제 시간이 더 지나면서 아예 막아버리기 위한 방지책을 준비하고 있는듯 한데 기존에는 코딩 과정에 필요한 기반 데이터들(코딩 변수 메모리 위치값, 설명 등)을 다운로드 받아 사용하게 해서 유출이 쉬웠는데, 앞으로는 온라인에 연결하여 그때 그때 일부분만 받아와서 사용하게끔 하는 방식을 준비하고 있는듯 합니다. 이렇게 할 경우 온라인 인증을 넣게 되면 일반 사용자가 사용하는것은 매우 힘들어 질 것입니다.

안타깝긴 합니다만 제조사 입장에서는 당연한 조치이지 않나 싶습니다. 사실 BMW 전용 코딩 프로그램의 경우도 원래는 인증을 받아야 사용이 가능하지만 언제나 그렇듯이 여러 사람이 모이면 인증을 우회하는 프로그램도 생기고 그러는 법이라 우회 프로그램을 통해 사용되고 있습니다.

 

하지만 여기서 흥미로운 점들은 이러한 과정들이 일반인도 쉽게 가능하게 프로그램이 잘 제작되어 있다는 점과 인터페이스나 기반구조가 잡혀 있다는 점입니다.

 

물론 사용하다가 실수할 경우엔 ECU 가 멈추게 되면서 차량 운행이 불가능해질수도 있지만 보수적이라고 생각될만한 자동차에 대해 이만한 자유도를 가지고 차량을 제어하고 수정할수 있다는 점이 흥미롭습니다.

양평 벗고개에서 별 구경하기

지난주에 양평 벗고개에 별을 보러 다녀왔습니다.

양평 벗고개는 전부터 한번 가봐야겠다는 생각을 하고 있었는데 월요일 저녁에 갑자기 생각이 나서 동생이랑 같이 다녀왔습니다.

가기전에 기상청 홈페이지에 들어가서 구름 레이더 영상을 찾아봤었는데 정말 하늘에 구름 한점도 없이 깨끗해서 정말인가 하늘을 봤는데 정말 구름 한점도 없이 맑은 밤이었습니다.

집에서 1시간 30분 정도 거리이고 1시간 정도는 고속도로를 타고 나머지 30분 정도는 국도만 타고 갔던것 같습니다. 고속도로에서 내려 여러 시골길들을 지나 굽이굽은 어두운 산길로 들어서니 점점 차 안에서도 별이 한두개씩 보이기 시작했습니다.

너무 늦은 저녁이기도 하고 평일 저녁이라 사람이 없어서 무섭지 않을까 걱정했었는데 벗고개에 거의 다 도착했을때 갓길에 세워진 수많은 차들을 보고 살짝 안도의 한숨을 내쉬었습니다.

저도 갓길에 세워진 차들 뒤에 차를 주차하고 어두운 도로를 걸어 올라가는데 하늘을 올려다 보니 정말 하늘에 별이 한가득 있다는 표현이 맞을 정도로 별이 많았습니다. 이전에 오키나와에 갔었을때 이후로 이렇게 많은 별을 보는건 처음이었고 한국에도 이렇게 별이 많이 보이는 곳이 있는것에 놀랐습니다.

은하수도 눈으로 보여서 하루종일 별만 보고 있을수 있을것 같았습니다.

하지만 가져온것은 카메라와 삼각대 밖에 없어서 별을 보려면 고개를 위로 들고 있어야 했기 때문에 목이 많이 아팠는데 주변을 둘러보니 많은 분들이 돗자리에 누워서 별을 보고 계셔서 다음번에는 꼭 돗자리를 가져 가야겠습니다.

 

아래는 벗고개에서 찍은 별 사진입니다.

 

아래는 인스타그램 필터 입혀서 올렸던 사진입니다.

개인적으로는 이 사진이 젤 맘에드는듯 하네요. 담엔 아예 이런 색감으로 편집해봐야겠습니다.