차량에서 데이터를 꺼내는 방법

운행 기록, 고장 진단, 사고 탐지. 전부 차량에서 데이터를 꺼내는 것에서 시작합니다. 그 꺼내는 방법은 다양하고, 어떤 방식이냐에 따라 모든 게 바뀝니다.

들어가며

저희는 달리는 차에서 신호를 받아 무언가를 판단하는 일을 합니다. 지금 어디를 달리고 있는지, 어떻게 몰고 있는지, 고장 조짐이 있는지 같은 것들입니다.

그런데 이 모든 일은 한 가지 질문에서 시작합니다. 차에서 그 신호를 어떻게 꺼내느냐입니다.

밖에서 보면 별게 아닐 것 같습니다. 요즘 차는 컴퓨터 덩어리니 그냥 값을 가져오면 될 것 같습니다.

실제로는 꺼내는 방법이 크게 세 가지고, 세 방법이 주는 정보가 서로 전혀 다릅니다. 얼마나 자주 주는지, 어떤 항목을 주는지, 심지어 설치하는 데 몇 시간 걸리는지까지 다릅니다.

시작할 때 어느 걸 고르느냐가 그 뒤의 모든 걸 정합니다. 나중에 바꾸려면 수집해둔 데이터를 버려야 하는 경우도 생깁니다.

이 글은 그 세 가지를 정리합니다. 저희가 세 가지를 다 써보면서 알게 된 것들도 같이 적겠습니다.

방법 1. 진단 포트에 꼽고 물어보기

운전석 무릎 아래쪽을 더듬으면 사다리꼴 커넥터가 만져집니다. OBD-II 진단 포트입니다.

이건 원래 데이터를 가져가라고 만든 구멍이 아닙니다. 배기가스 규제 때문에 법으로 달게 한 것입니다. 정비소에서 고장 코드를 읽으려고 만든 진단용 창구입니다.

동작 방식도 그러합니다. 물어봐야 대답합니다. "지금 속도가 몇이야?"라고 보내면 그제서야 값이 옵니다. 이걸 PID라고 부르는 번호로 하나씩 지정해서 묻습니다.

장점은 분명합니다.

• 어느 차에나 꼽으면 됩니다. 포트 모양과 기본 항목이 표준이라 제조사를 가리지 않습니다.
• 공구가 필요 없습니다. 동글 하나 꼽으면 끝입니다. 차량 수십 대에 하루 만에 깔 수 있습니다.
• 전원이 같이 나옵니다. 별도 배선이 필요 없습니다.

대신 한계가 있습니다.

첫째, 표준 항목이 생각보다 적습니다. 속도, 엔진 회전수, 냉각수 온도 같은 배기가스와 관련된 것들이 중심입니다. 조향각, 방향지시등, 각 바퀴의 속도 같은 건 표준에 없습니다.

둘째, 물어보는 방식이라 느립니다. 한 번에 한 항목씩 주고받으니 항목을 늘리면 그만큼 주기가 길어집니다. 충돌 같은 순간적인 사건을 보기엔 부족합니다.

셋째, 제조사가 추가로 열어둔 항목은 문서가 없습니다. 표준 밖에도 많은 값이 있지만 공개된 규격서가 없어서, 값을 받아도 그게 뭐지 알아내는 건 별도의 일입니다.

그래서 진단 포트는 범위를 넣기엔 좋고, 깊이를 넣기엔 부족합니다.

방법 2. CAN 버스를 직접 들여듣기

차 안의 부품들은 서로 끊임없이 대화합니다. 엔진 제어기, 브레이크, 계기판, 전방 카메라가 공통 선 하나에 매달려 있고, 그 선을 CAN 버스라고 부릅니다.

진단 포트와 결정적으로 다른 점이 있습니다. 여긴 물어볼 필요가 없습니다. 부품들이 알아서 계속 떠들고 있고, 우리는 옆에서 그걸 듣기만 하면 됩니다.

그래서 양이 비교가 안 됩니다. 저희가 준중형 세단 한 대를 물어놓고 재봤는데, 75종의 메시지가 초당 2,128개 프레임씩 흘러다니고 있었습니다. 세 번 주행해서 쌀은 게 3,545만 프레임입니다.

주기도 빠릅니다. 같은 "속도"라도 어느 부품이 보내느냐에 따라 다릅니다.

문제는 둘입니다.

첫째, 진단 포트에선 이걸 볼 수 없습니다. 요즘 차는 게이트웨이가 포트 쪽으로 브로드캐스트를 막아둡니다. 동글을 꼽아도 진단 응답만 오고, 부품끼리 떠드는 소리는 안 들립니다.

그래서 실제 트래픽이 흐르는 곳에 직접 물려야 합니다. 저희는 전방 카메라로 가는 배선 중간에 하네스를 끼워 넣었습니다. 여기엔 차로 유지 보조, 앞차 거리 같은 신호가 지나다닙니다.

둘째, 받은 값이 무슨 뜻인지는 안 알려줍니다. 프레임은 그냥 숫자 뚝어리입니다. 어느 번호의 몇 번째 자리가 조향각인지 알려면 해독표가 필요하고, 그 표는 제조사가 공개하지 않습니다. 직접 알아내야 합니다.

이건 따로 한 편을 써야 할 주제라 다음에 다루겠습니다.

방법 3. 제어기에 직접 질문하기

세 번째는 앞의 둘 사이 어딘가에 있습니다.

버스에 아예 흘러다니지 않는 값들이 있습니다. 대표적으로 전기차 배터리의 셀 단위 전압과 수명 상태가 그렇습니다.

이건 배터리 관리 제어기만 알고 있고, 다른 부품에게 굳이 알려줄 이유가 없으니 방송하지 않습니다. 하네스에 물려도 여긴 안 나옵니다.

그러면 방법은 하나뿐입니다. 그 제어기에게 직접 물어보는 것입니다.

방식은 진단 통신 표준을 그대로 씁니다. 특정 주소로 "이 번호의 데이터를 달라"는 요청을 보내면 응답이 옵니다. 답이 길면 여러 프레임으로 쪼개져 오고, 중간에 "계속 보내라"는 신호를 우리가 껴야 합니다.

이 방식의 성격은 진단 포트와 비슷합니다. 물어봐야 나오고, 그만큼 느립니다. 대신 다른 어느 방법으로도 못 얻는 값을 얻습니다.

제조사가 공식 제공하는 커넥티드카 API도 같은 칸에 넣을 수 있습니다. 가장 편하고 가장 제한적입니다. 붙이는 수고가 없는 대신 항목과 주기를 제조사가 정하고, 보통 몇 분에 한 번 수준입니다.

세 방법을 나란히 놓으면

정리하면 이렇습니다.

차량 수백 대의 운행 기록을 모으는 게 목적이면 진단 포트가 맞습니다. 설치가 쉬워야 하고, 초당 몇 번씩이면 충분합니다.

충돌이나 급조작처럼 순간적인 사건을 봐야 한다면 버스를 직접 들어야 합니다. 1초에 한 번으로는 안 보입니다.

배터리 상태처럼 특정 제어기만 아는 값이 필요하면 폴링이 유일한 길입니다.

실제로는 섞어 씁니다. 저희도 한 차량에서 하네스로 주행 신호를 받으면서 배터리는 따로 폴링하고 있습니다.

한 가지 더 — "되는지"는 차마다 다릅니다

여기까지가 교과서라면, 실제로는 한 층이 더 있습니다.

실패하는 차량들을 보면서 저희가 정한 게 있습니다. 안 되는 이유를 두 종류로 구분해서 적자는 것입니다.

• 차의 성질 — 그 차가 그 값을 애초에 방송하지 않음. 장비를 바꿔도 안 됨.
• 장비의 성질 — 차는 보내고 있는데 우리 장비가 못 받음. 장비를 바꿔서 해볼 가치가 있음.

통신은 분명히 하고 있는데 저렴한 BLE 동글로는 한 프레임도 못 잡는 경우가 있었습니다. 이걸 "이 차는 데이터가 없다"고 적어두었다면, 나중에 제대로 된 장비를 가졌을 때도 그 차량을 빼놓고 시작했을 겁니다.

그래서 항목마다 등급을 붙입니다. 실차에서 응답 바이트를 받아 확인한 것, 벤치에서만 돌려본 것, 커뮤니티 자료만 보고 추정한 것, 아예 시도 안 한 것, 시도했다가 실패한 것을 다르게 표시합니다.

문서가 좀 지저분해지지만, 몇 달 뒤에 "이거 확인한 거였나"를 다시 묻지 않아도 됩니다.

마치며

처음 시작하는 분이라면 이 순서로 정하시기를 권합니다.

먼저 무엇을 판단할 건지 정합니다. "차량 데이터를 모으자"로 시작하면 무엇을 수집해야 하는지 정해지지 않습니다. 사고를 보려는 건지, 운행 기록을 보려는 건지에 따라 필요한 주기가 열 배 차이 납니다.

그다음 주기를 정합니다. 초당 몇 번이 필요한가. 이 하나로 진단 포트로 될지 버스를 따야 할지가 갈립니다.

마지막으로 대상 차량을 확인합니다. 한 대에서 됐다고 다 되지 않습니다. 가장 오래된 차와 가장 최신 차를 먼저 꼽아보세요.

저희는 이 순서를 거꾸로 밟아서, 장비를 먼저 고르고 나중에 주기가 부족하다는 걸 알았습니다. 그때 버린 수집 기간이 아깝습니다.

다음 편에서는 진단 포트로 얻을 수 있는 것과 없는 것을 더 구체적으로 다루겠습니다.

감사합니다.