태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.



 OBD(On-Board Diagnostics)에 대한 이야기는 조금 현실에서 동떨어지게 느껴질지도 모르겠다. 하지만 국내에서 한글로 된 자료가 거의 없고 자료가 있다고 해도 거의 겉핧기 식인지라...이쪽에 대해서 탐구하고 싶어 하는 분들에게는 알아가기란 굉장히 어려운 부분이 많다. 어차피 시작 자체가 미국에서 시작이 되었다 보니 어쩔 수 없다 싶기도 한데, 그리고 이쪽에 관한 이야기는 대학에서 공부하는 하나의 전공으로는 이해하기가 어려운 부분이 많다. 


 일단 기본적으로 자동차에 대한 배경 지식이 있어야 하며, 기계장치 제어 계열의 기계공학의 지식도 있어야 한다. 그리고 기본적으로 통신을 이해 할 수 있는 통신공학적인 지식이 베이스에 깔려 있어야 하고, 더 나아가서는 프로그램이 가능하면 이 "자동차 진단기"라는 것을 만들 수 있다. 사실 하드웨어 적인 문제는 ELM등의 아주 좋은 하드웨어들이 깔리고 깔려있는지라...정말 극 초반부터 만들길 원한다면 ATMEL등의 제어칩과 통신 모듈을 이용해 만들 수 있다. 일반적인 경우 Serial 통신으로 이루어 지기 때문에 Serial 통신 칩만 있으면 구현이 가능하고, CAN이나, PWM의 경우도 해당 제어 모듈이 모두 구할 수 있게 되어 있다. 


 이야기가 잠시 다른 곳으로 샛는데, 처음 시작은 당연히 개론적인 이해에서 시작이 되어야 하기에 이 OBD에 대해서 일단 개념을 잡아 보도록 해보자. 


 일단 "OBD란 무엇인가?" 부터 시작을 해보자면 On-Board Diagnostics의 약자로 간단하게 차량 진단을 위해 만들어진 무언가 이다. 이것은 연결을 할 수 있는 커넥터도 포함이 되며, 통신시 사용 되는 프로토콜과, 해당 프로토콜이 사용하는 Service ID까지 모두 포함이 된다. 


 사실 일반적으로 알고있는 OBD는 자동차의 엔진을 진단하기 위한 상용 프로토콜을 의미하는 경우가 많은데, 맞는 말이기도 하고 틀린 말이기도 한다. 사실은 그것을 포함한 더 많은 것을 뜻하기 때문이다. 


 OBD는 미국에서 시작이 되었고 처음 만들어지게 된 사유는 환경오염 때문이였다. 환경오염을 줄이기 위해 각종 센서들을 달고 그것을 모니터링 할 도구가 필요했는데, 그 필요에 따라 전자제어장치가 발달을 하게 되었고 현재는 진단기가 없이는 차량수리가 거의 불가능할 정도로 복잡해져 버렸다. 

 

 사실 처음에 나타나게된 고장코드(DTC - Diagnostic trouble code)는 산소센서 관련 항목이 많았다. 당연히 환경오염을 줄이기 위해서는 엔진에서 나오는 배기가스의 규제를 만들어야 했고, 엔진에서 잘못된 배기가스가 나오게 되면 엔진이 고장이 났다고 알리고 이를 수리하게 하려는 목적에서였다. 처음의 의도는 차량의 고장을 진단하려는 목적이 아니라 환경규제에 맞지 않는 엔진을 검출하려는데 있었던 것이다. 물론 현재는 그 뿐아니라 엄청나게 확장이 되어서 차량자체의 고장을 진단하고 원인을 보여주게 되었지만 뭐 시작은 그렇다는 말이다. 


 OBD에는 종류가 있는데, 크게 잡으면 OBD-I, OBD-II가 있고, 이를 지역별로 OBD, EOBD(유럽), JOBD(일본), KOBD(한국)으로 나누어 지며 각각의 지역에 맞는 조건에 따라 조절이 된 형식이다. 예를 들면 OBD에서 표출이 되어야 하는 센서의 종류나 그 센서 값의 폭이 각 지역별로 다르다는 말이다. 간단하게 예를 들면 OBD에서는 O2센서에 대한 값만 표출이 되어도 된다면, EOBD에는 O2외에 NOx의 값도 같이 표출이 되어야 한다. 뭐 이런식이다. 사실 어느지역의 OBD이든 O2와 NOx는 나오는게 맞을 것이다. 다만, 예는 예일 뿐이니 개념만 이해하고 넘어가도록 하자. 


 OBD는 미국에서 제일 먼저 시행이 되었고 유럽에서는 2000년, 일본에서는 2002년, 한국에서는 2007년에 시작이 되었다. 시작이 되었다고 하는 기준은 이 연식 이후의 차량들은 해당 조건을 반드시 충족을 해야 해당 지역에서 판매가 가능하다는 이야기다. 


 이제 OBD-I과 OBD-II에 대한 이야기를 해보자면, OBD가 시행이 되었다고 해서 모든 메이커가 같은 것을 만들고 있는 것은 아니다. 그렇다면 얼마나 좋겠느냐 만은...각 메이커 별로 특징과 사용하는 프로토콜이 다르다. 지금은 어느정도 비슷해 졌지만, 이 구형 OBD-I에 대해서는 거의 모든 메이커가 독자적인 노선을 만들었는데, 오죽하면 통신 연결을 위한 커넥터 까지 모두 다르다. 사용하는 프로토콜은 각 메이커에서 정의하는 경우가 대부분이고 일반적인 프로토콜이 아니며 상용화된 프로토콜도 아니다. 이에 대한 이야기는 꽤 많은 분량이기 때문에 나중에 다시 하는 편이 좋을 것 같다. 


 그럼 현재 돌아다니는 OBD-II에 대한 이야기를 해보자. 이 역시 앞서 설명한 OBD/EOBD/JOBD/KOBD에 해당하는 몇 종류의 상용 프로토콜이 존재하며, OBD-I처럼 각 메이커 별로 지원하는 일반 프로토콜이 존재한다. 기본적으로 해당 연식 이후의 차량은 상용프로토콜로는 "반드시" 진단이 된다. 단 지원하는 모드들이 있는데, SAE J1979에서 각 프로토콜 별로 정의하고 있다. 그리고 가장 큰 변화는 OBD-II부터는 커넥터의 규격이 동일하게 적용이 되어 한가지 커넥터로 모두 연결이 가능하다. SAE J1962 에서 정의하고 있는 이 커넥터는 16P을 가지고 있으며, 일단 16P는 VCC, 그리고 4,5PIN은 GRD로 이루어져 있다. 나머지 핀들은 각 메이커 별로 상이하며, 일반적으로 쓰이는 것은 J1850을 위한 2,10 PIN, ISO 9141-2와 KWP2000을 위해 쓰이는 7PIN, 그리고 CAN을 위해 쓰이는 6,14PIN 이 통상적이며 나머지 PIN들의 용도는 제조사에 따라 다르다.


 프로토콜은 크게 J1850, ISO 9141-2, KWP2000, CAN의 네가지 종류로 나누어 지는데, 각 프로토콜 별로 지원하는 Service ID는 조금씩 다르다. 일단 문서에 정의가 되어 있는 형식은 다음과 같다. 



 이렇게 봐서는 전혀 와닿지가 않는다. 각 모드가 뭐고 어떻게 쓰는지...각 프로토콜 별로 정해진 메세지 형식이 있으며, 그 형식에 맞춰 사용 하는 것이 저 Mode라는 부분이다. 제대로 된 Mode로 요청값을 보내게 되면, ECU에서 해당 Mode에 맞는 응답값이 오는 형식으로 프로토콜이 이루어져 있는데, 이는 프로토콜 별로 1:1 형식이 될 수도 있고 1:X 형식이 될 수도 있다. 일단 이 상용 Mode에 대해서는 기본적으로 OBD-II를 지원하는 차량들은 지원을 하게 되어 있으나 물론 모든 Mode를 지원해야 하는 것은 아니다. 위에서 정해진 지역별 차이에 따라서 반드시 지원을 해야하는 부분이 있고, 지원을 하지 않아도 되는 부분이 있다. 


 이 Mode중에서 중요한 부분은 바로 $02, $03, $04이 세가지 모드다. 물론 각 센서의 모니터링도 중요하지만, 이 세가지의 모드는 자동차의 고장코드에 관련된 Mode들이다. $02번인 FFD(Freeze frame data)의 경우는 DTC가 발생했을 당시의 센서 값들을 보여주는 기능이며, $03은 차량의 DTC를 보여주는 기능이다. 그리고 $04번은 이 DTC를 소거해주는 기능인데, 이 기능은 DTC의 형태에 따라 쓰이게 된다. 차량측에서 DTC의 Status를 지원하는 경우, 그러니까 과거 고장코드인지, 현재 고장코드인지, 간헐적 고장코드인지를 알 경우는 수리가 마무리 된 후에 한번만 해줘도 되며, 고장코드가 많은데 이게 어떤게 현재 고장코드인지 모를 경우 소거를 한뒤에 시험주행 후 다시 고장코드가 발생하게 만들어 확인을 하는 방법이다. 사실 이 $03, $04 만 지원하는 싸구려 코드리더들이 많은데, 해당 상용프로토콜만 이해를 하고 있다면, 아주 간단하게 만들 수 있다.


 사실 이 글만 봐서는 이게 뭔지 통 감이 오질 않을 것이다. 이 내용은 아주 기본적인 큰 그림인데, 이 그림을 이해하려면 세부적인 프로토콜들을 이해를 해야 완전한 이해가 가능하다.



저작자 표시
신고
Posted by 케이군입니다