차량에 이상이 감지된 경우, 엔진체크등 (MIL : Malfuction Indicator Lamp)이 점등 됩니다.

이때 진단단자 (OBD2 Connector)에 스캐너를 연결하여 오류코드 (DTC : Diagonostic Trouble Code)를 읽으면

차량의 어느 부분에 이상이 발생했는지 대략 알 수 있습니다.

차량에 이상이 발생했다면, 그 원인을 찾아서 수리를 하는 것이 올바른 방법이겠지만,

수리를 해도 엔진체크등을 지울 수 없는 경우도 있습니다.

특히 배기관련 튜닝을 한 경우에 흔하게 발생하는 문제 입니다.

많은 운전자들이 이런 문제 때문에, 스캐너로 주기적으로 DTC를 삭제하며 운행을 하는데, 무척 번거로운 일입니다.

그래서, 시중에서 쉽게 구할 수 있는 OBD2 블루투스 동글을 개조하여

자주 발생하는 DTC코드를 기억하였다가,  오류가 발생하면 자동으로 지워주는 장치를 만들어 보았습니다.

-------------------------------------------------------------------------------

얼마전... 

평소에 일은 잘 안하고, 자동차 경주에 나갈 기회만 호시탐탐 노리고 있는 것으로 보이는 

인피동 노땅 회원분으로부터 카톡이 왔습니다.

예전에 만들었던 학습형 DTC 자동 소거기 (참조: http://cafe.daum.net/playwithcar/7MdY/23 )

여분이 있냐는 내용이 었는데, 사실대로(^^;) 없다고 하려다가...

뭔가 느낌이 이상해서 어디다 쓰려고 하냐고 물어봤더니, 아는 분 차량에 자꾸 오류가 떠서 그렇다고 하시더군요.

그런데 그 차량이 바로....,...

요런 계기판을 가진 좀 특별한 차량이더군요...

좀 넓게 볼까요? 뭔가 좀... 아니 마구 복잡하네요

엔진룸도 심상치 않게 생겼군요... 무슨 차일까요?

저... 저요?

네 무려... 무르시엘라고 LP640 입니다.

아벤타도르에게 자리를 물려주기 전까지, 람보르기니의 기함이었던 멋진 녀석이죠...

람보를 한번 뜯어봐야겠다는 호기심에 그만 일을 벌이고 말았습니다.

또 수십만원을 날릴 기회가 생긴거죠 ㅠㅠ

:

:

:

몇 일 뒤... 땅바닥에 찰싹 달라붙어 있는 무르시를 만났고, 일단 어떤 오류가 있는지 스캔해 봤습니다.

현재는 2개의 오류 코드가 떠 있지만, 배기/Miss fire 관련 오류 몇가지가 계속 발생한다고 합니다.

배기 튜닝이 된 상태이기 때문에, 일반적인 수리 방법으로는 해결이 되지 않는다는군요.

그래서 급히 DTC 소거기를 만들어서 연결해 봤는데...

OTL... 이 차량은 (2008년식 무르시엘라고) OBD단자에 CAN이 없었습니다.

DTC 소거기는 CAN 방식만을 지원하기 때문에 이 차에는 아무런 쓸모가 없더군요.

어쩔 수 없이 기념사진만 찍고ㅠㅠ 무르시와는 일단 이별을 하게 되었습니다.

CAN을 지원하지 않는 구형 차량도 대부분 K-Line은 지원하기 때문에,

K-Line 방식으로 DTC 소거기를 다시 만들면 되지만, 그러려면 시간도 많이 걸리고,

비용도 많이 들어가기 때문에 포기 할까하다가.... 좋은 생각이 떠 올랐습니다.

자동차의 진단단자(OBD2I 단자)에 꽂고 스마트폰이나 노트북등과 블루투스로 연결하여

차량의 상태 (속도, RPM, 냉각수온, 유온등)를 실시간으로 확인할 수 있는 "OBD2 블루투스 동글" 이라는 장치가 있습니다.

1~3만원대의 저렴한 가격으로 구입할 수 있고, 대부분의 차량에 사용가능하죠. 이렇게 생겼습니다.

요즘 많은 분들이 차량에 설치하여 "Torque" ( https://play.google.com/store/apps/details?id=org.prowl.torque )와

같은 스마트폰용 어플을 사용하여 보조 게이지로 사용하고 계시죠.

OBD2 동글은 ELM-327이라는 자체 프로토콜을 지원하며, ELM-327은 차량의 종류/연식등에 따라

다른 여러가지 통신방식을 간단한 AT 커맨드 방식으로 변환해 주는 일종의 번역장치 입니다.

ELM-327에 대하여 자세히 알고 싶으신 분은 http://elmelectronics.com/ 를 참조하시기 바랍니다.

이 제품을 사용하면, CAN, K-LIne을 포함하여, 전 세계의 구형~신형 차량 대부분을 지원할 수 있는

다양한 통신 프로토콜을 비교적 쉽게 사용할 수 있습니다.

DTC 소거기는 CAN 밖에 지원하지 않아서 구형 차량에는 사용할 수 없지만,

차량에서 사용되는 다양한 OBD 관련 프로토콜을 모두 지원하는 ELM-327이

들어 있는 블루투스 동글을 약간 개조하면 비교적 쉽게 문제를 해결 할 수 있을 것입니다..

가지고 있던 OBD2 블루투스 동글을 분해해 보았습니다. 제품 상단에 붙어 있는 작은 PCB가 블루투스 모듈입니다.

블루투스 모듈은 ELM-327 chip과 시리얼통신(UART)으로 연결되어 있습니다.

블루투스 모듈을 제거하고, ELM-327에서 나온 시리얼통신 라인을 제가 제작한 CPU 보드와 연결합니다.

CPU보드는 다른용도로 만들었던 것을 개조한것이라서 살짝 지저분합니다.^^

그리고, ELM-327을 통하여 기존의 학습형 DTC 자동 소거기와 같은 기능을 할 수 있도록 프로그램을 작성하였습니다.

드디어 완성 되었는데....그런데, 이렇게 만들어 놓고보니, 조금 더 욕심이 생겼습니다.

"제어 회로(CPU보드)를 OBD2 동글 안에 넣을 수 있지 않을까?"

블루투스 모듈을 떼어 낸 자리에 넣을 수 있도록 아주 작은 회로를 만들었습니다.

회로설계와 아트웍 작업 후, 주문한 PCB가 도착했습니다. 주문한 량보다 훨~~~씬 많이 보내주셨네요^^

크기는 아래 사진과 같습니다. 100원짜리 동전과 비교해 보시죠~

이제 OBD2 동글을 몇 대 더 구입했는데... 어? 외형은 같은데... 내부의 블루투스 모듈이 다른 종류네요ㅠㅠ

그런데 다행히, 시리얼통신 및 전원핀은 동일하여 그대로 사용할 수 있었습니다. 휴우....

살짝 팁을 한가지 알려드리자면... 국내 오픈마켓에서 2~3만원에 판내되는 OBD2 블루투스 동글은

AliExpress나 EBay등을 통하여 직접 구매할 경우 $10 이하로 구매할 수 있습니다.

저는 $7도 안되는 가격에 구입했죠... (좀 오래 걸리긴 하지만, 무료배송^^)

이제 조심스럽게 블루투스 모듈을 제거 합니다.

아래 사진처럼, 블루투스 모듈을 떼어낸 자리에 새로 제작한 제어회로를 부착합니다.

이제, 프로그램 작성을 위해 개발용 장비/PC와 연결합니다.

PC를 통하여 AT 커맨드로 오류를 읽어봤습니다.

지난번에 스캐너로 읽은것과 동일한 오류코드가 읽히는군요.

새로운 회로에 맞도록 수정한 펌웨어를 기록한 후

케이스에 스위치용 구멍을 하나 뚫고... 조립합니다.

완성~ 아주 심플하죠?

이제 OBD2 진단단자가 달려 있는 거의 모든 차량에서 사용할 수 있는 학습형 DTC 자동 소거기가 만들어졌습니다^^

이 제품의 상단에는 작은 버튼 하나와, 적색/녹색 LED가 달려 있습니다.

차량의 전원이 켜져 있는 동안, 주기적으로 오류를 검사하여 차량에 이상이 없을 경우는 녹색 LED가 깜박이고,

DTC 오류가 있을 경우에는 적색 LED가 깜박입니다. 이 때 버튼을 짧게 누르면 DTC 오류가 삭제됩니다.

오류가 발생했을때, 버튼을 3초간 누르고 있으면 적색 LED가 빠르게 깜박이고,

현재 발생한 DTC오류를 기억합니다. 오류는 64개 까지 기억가능하며,

(64개보다 더 많은 오류가 발생하는 차량은... 폐차장으로)

기존에 기억된 오류가 있다면 추가하여 기억하게 되고,

추후 기억한 오류가 발생할 경우 자동으로 지워줍니다.

기억하지 않은 오류가 발생할 경우는 정말로 차에 이상이 발생한 경우이므로,

DTC를 삭제 하지 않고 적색 LED가 깜박입니다.

버튼을 5초 이상 누르고 있으면 녹색 LED가 빠르게 깜박이면서 기억한 내용을 모두 지우게 됩니다.

설치는... 진단 단자에 꽂기만 하면 끝입니다.

이제 무르시의 깊은 곳(?)에 있는 진단단자에 꽂고 오류를 기억시켰습니다.

잠시 후.... 경고등이 꺼진 깨끗한 계기판을 볼 수 있었습니다.^^

참, 무르시엘라고는 ECU가 2개라고 하는군요. 그래서 경고등도 Left, Right 2개가 있습니다. 참 희안하죠?

글쓴이는 현재 유럽 OEM 관련 SOME/IP Project를 진행 중이며 진행 하면서 배운 것들을 정리 할 겸 글을 써 보았다.

(AUTOSAR 1.5.1 SOME/IP 규격 기반)

https://www.autosar.org/standards/foundation/

1. SOME/IP(Scalable service-Oriented MiddlewarE over IP) Overview

BMW 주도하에 Automotive 영역에서 Device(ECU)간 Ethernet 기반 Data 통신을 지원하기 위해 만들어진 Protocol이다.

SOME/IP 는 SOA(Service Oriented Architecture)기반으로 설계 된 Protocol이다.

각 기능이 Service별로 구별 되어 있으며,

각 Service는 Service를 제공하는 Provider(Server), Service를 이용하는 Consumer(Client)로 구분 되어 있다.

2. SOME/IP 

Device 끼리 SOME/IP Protocol을 통해 Data를 주고 받는 것이 주 목적이다.

SOME/IP 관련 Header 가 존재하며 data 가 Serializatoin 된 Payload가 존재 한다.

Header 와 Payload는 Byte형태이다.

- SOME/IP Header

- Payload Serialization

  규격 참고

보통 Protocol의 Header 및 Serilization 부분은 규격을 자세히 읽어 보는 것이 좋은것 같다.

그리고 직접 PCAP과 비교해보면서 보면 훨씬 이해가 빠를 것이다.

- Transport Protocol

SOME/IP 는 UDP 또는 TCP 기반으로 통신을 하게 된다. 

보통 Packet 크기 MTU 사이즈 이상 되게 되면 TCP를 사용하게 되며

현재는 Runtime 시점에 동적으로UDP <->TCP 전환 내용은 요구사항에 없다.

규격에서 제안 하는 Transprot Protocol 선택 가이드라인 

TCP 사용 시 중요한 것은 Nagle's Algorithm이 off 되야 된다는 것이다.

SOME/IP 중요성 중에 하나가 실시간 성이기 때문이다.

Consumer 와 Provider 간은 하나의 Connection을 기반으로 통신해야 한다.(TCP는 Heavy 한 Protocol 이며 TCP Connection은 최소화 해야 한다.)

UDP 기반으로 MTU 이상 Packet을 전송 하기 위해서는 SOME/IP-TP라는 것을 이용해 보내게 된다.

결국 Data를 Segment하며 Header에 offset 정보를 담아서 보내게 되는 형식이다.

- Communication 

규격에서 제안 하는 SOME/IP 통신 방법은 Request/Response(Method), Fire&Forget, Events, Field 총 4가지 이다.

아래 그림으로 충분히 설명이 가능 할 것이다.

- Error Handling

Error 발생 시 규격에서 제안 하는 방법은 총 2가지 존재한다.

• Return codes in the Response Messages of methods.
• Explicit Error Messgaes

Response Message의 Returen code에 Error code를 Returne 해주는 방법 과 Paload에 Error mesage(Message Type 0x81)을 담아서 보내는 방법이 있다.

후자는 Consumer Provider 간의 Error message 약속이 존재해야 한다.

글쓴이가 느끼기엔 Error Handling 관련 부분이 타 Protocol Spec(RFC, 3GPP) 대비 많이 부족한 부분인것 같다.

앞으로 많은 부분이 Update 될 것 같다.

3. SOME/IP Service Discovery(SOME/IP-SD)

각 Provider 와 Consumer는 시작 전 서로의 정보(Version, IP address, Port ...)들을 알고 있지 않는다.

SOME/IP Service Discovery라는 Step을 통해서 Provider 와 Consumer간 서로의 정보를 교환하게 된다.

경험상 SOME/IP-SD flow 다음과 같이 2가지가 존재 할 수 있다.

1) TTL 안에 OfferService가 오는 경우

2) TTL expired 된 후 FindService가 전송 되는 경우

Concept OfferService와 FindService를 통해 서로의 IP addres, Port 등등을 주고 받는 것이며,

주고 받은 정보 기반으로 SOME/IP 통신을 하게 된다.

SOME/IP-SD는 Mulitcast를 이용하기 때문에 무조건 UDP 를 사용해야 한다.

이와 관련된 자세한 내용을 알기 위해서는 규격의 StateMachine Diagram을 이해 하는 것이 좋다.

여기서 주의 할 것은 Subscribe는 Mandatory가 아니다, Event 혹의 Field의 Notication이 필요 없을 경우는 Subscription 과정을 생략 해도 된다.

- Message format

SOME/IP의 Payload에 SOME/IP-SD Header와 Option이 위치하게 된다.

각 Header들은 규격을 읽어 보길 추천한다.

아래는 중요한 것들만 요약 하였다.

Type = SD Type

Index 1st options = option reference index

Service ID = Vehicle에서 Service Unique ID

Instance ID = Service 하위의 Instance ID 

TTL = OfferService lifetime,  Note : TTL Timer Expired 시 Client에서 FindService가 전송 됨

Type = option type, ( [0x06] = "IPv6 Endpoint Option”=>IPv6 사용)

IPv4/6 Address = SOME/IP 를 수신 받기 위한 Local IP

L4-Proto = Transport Layer Protocol, (0x06(TCP), 0x11(UDP))

Port Number = SOME/IP 를 수신 받기 위한 Port

- State Machine

가장 중요한 그림이다.

아래 그림만 이해 할 수 있으면 SOME/IP-SD 반은 이해 한다고 볼 수 있다.

머리속으로 상상해 가며 State Machine을 따라 가보 기를 권장한다.