표준 OBD 너머로 — SAM·EIS·ESP를 읽기 위한 준비

표준 OBD 너머로 — SAM·EIS·ESP를 읽기 위한 준비

3 min read

BESTNET TECH BLOG

표준 OBD 너머로 — SAM·EIS·ESP를 읽기 위한 준비

어댑터의 통신 기능과 차종별 진단 정의를 나누고, 제조사 진단 프로그램을 실차 미검증 준비 단계로 정비한다

저자: Hideyuki Chinda / BESTNET LLC2026-10-13연재 “AI를 활용한 OBD 진단” 제3회

표준 OBD로 차량과 통신할 수 있어도 그것만으로 고장 진단이 완료되는 것은 아닙니다. 이번 2009년식 W204 C63에서는 표준 OBD로 얻은 정보에 더해 SAM, EIS, ESP의 정보를 확인하고 싶었습니다. 그래서 보유한 OBDLink EX를 사용한 제조사 고유 진단 준비를 진행했습니다.

현재 완성된 것은 읽기 프로그램과 오프라인 검증입니다. 이 차량에서 SAM, EIS, ESP를 읽은 실적은 아직 없습니다.

SAM은 신호 취득 및 출력 제어 유닛, EIS는 전자식 이그니션 스위치, ESP는 차량 자세 제어 장치를 가리킵니다. 이번 표준 OBD에서는 조사하지 않은 이들 시스템의 상태를 확인하는 것이 목적입니다.

준비의 도달점 #

항목상태
읽기 프로그램작성 완료
오프라인 검증(모의 응답)51건 성공
EIS·ESP 통신 경로타 차량 유래 후보 이 차량에서는 미검증
SAM 통신 경로미확정 식별부터 확인
이 차량에서의 실제 읽기다음 회

어댑터의 사양과 차종별 진단 정의 #

먼저 정리한 것은 어댑터의 통신 능력과 차종별 진단 정의의 차이입니다. CAN에 연결할 수 있는 하드웨어가 있어도, 어느 목적지로, 어떤 프로토콜로, 무엇을 요청하면 되는지는 따로 필요합니다. 돌아온 데이터의 형식과 의미도 알아야 합니다. "기기가 CAN을 지원한다"는 정보만으로는 특정 연식의 SAM을 진단할 수 있다고 판단할 수 없습니다.

OBDLink 공식 자료에서는 CAN 위에서 분할 메시지를 전달하는 ISO-TP, 수신 필터, 흐름 제어 설정을 확인할 수 있습니다. 이것들은 읽기 처리를 조립하기 위한 기반입니다. 한편 차종별 ECU 주소표나 고장 코드 설명은 그 자료에서 얻을 수 있는 것이 아닙니다. 이번에도 하드웨어 사양 확인과 차량 통신 정의 조사를 나누어 진행했습니다. (OBDLink 공식 사양)

다른 차량의 자료로 후보를 마련하다 #

EIS와 ESP 후보에는 원 개발자가 공개한 2011년식 C207의 통신 기록을 사용했습니다. 구체적인 송수신 경로, 진단 세션, 고장 코드 요청에 대한 응답이 남아 있습니다. 다만 대상은 이번 2009년식 W204 C63과 다릅니다. 자료에 실측값이 있다는 것과 그 설정이 눈앞의 차에 맞는다는 것은 별개의 확인 사항입니다. 구현에도 "후보"라는 라벨을 남기고 기본적으로는 실행하지 않도록 했습니다. (MBLINK 공개 정의, C207 응답 기록)

공개 기록의 형식에도 한계가 있었습니다. 기록된 것은 정리된 진단 메시지이며, CAN 원본 프레임 그 자체가 아닙니다. 분할 통신의 제어 정보나 확장 주소 사용 여부를 그 기록만으로 단정할 수는 없습니다. 다음에는 실제 응답을 저장하고 목적지뿐 아니라 프레임 형식도 대조해야 합니다.

SAM에 대해서는 앞뒤 모두 이 차량에서 쓸 수 있는 확정 경로를 찾지 못했습니다. 다른 차종의 주소를 그대로 할당하지 않고, 먼저 식별 정보를 취득하는 단계를 마련했습니다. 공개 자료에 있는 후보 경로의 규칙을 사용해 소수씩 확인하는 설계입니다. 보통은 한 번에 6슬롯을 대상으로 하며, 47개 경로를 자동으로 전수 시도하는 동작으로는 만들지 않았습니다. 후보의 수는 실측된 모듈 수를 의미하지 않습니다.

미식별 경로로 보내는 것은 고정된 식별 요청뿐입니다. 응답이 있어도 거기서 고장 코드 읽기나 세션 변경으로 자동으로 넓히지 않습니다. 돌아온 식별 문자열과 추가 근거를 확인한 뒤에 차량용 정의에 반영합니다. 회신이 없으면 목적지, 프로토콜, 전원 상태 등의 확인이 남습니다. 무응답만으로 SAM 고장을 단정할 수는 없습니다.

응답 상태를 구분하다 #

수신할 수 있었던 경우에도 결과 분류가 중요합니다. 고장 코드가 정상적으로 0건으로 돌아오는 경우와 취득하지 못한 경우를 나누었습니다. NO DATA, 부정 응답, 응답 대기, 중간 끊김은 각각 그 상태 그대로 기록합니다.

UDS(Unified Diagnostic Services)는 ECU와 진단기가 정보를 주고받기 위한 진단 서비스입니다. 그 고장 코드 응답에서는 코드와 상태 정보가 쌍을 이루는지 길이로 검증합니다. 코드처럼 보이는 값이 보여도 마지막 상태 정보가 빠져 있으면 완료된 결과로 채택하지 않습니다.

이 구분은 AI가 생성한 처리를 리뷰할 때도 도움이 되었습니다. 정상적인 빈 목록에 CAN 오류가 섞인 모의 응답을 사용해 0건으로 판정하지 않는다는 것을 검증했습니다. 통신 오류를 먼저 판정하고, 원본 데이터를 남긴 채 취득을 중단하는 구성입니다. 읽기 쉬운 요약을 만들기 전에 응답이 유효한지 확인하는 순서가 필요했습니다. 의미를 확인할 수 없는 제조사 고유 코드에는 추측에 의한 설명을 붙이지 않았습니다.

실행 조건과 오프라인 검증 #

참고로 "읽기 전용"이라도 차량에 요청 송신은 이루어집니다. 표준 OBD도 정보를 요청하고 응답을 받는 통신입니다. 분할 응답을 수신할 때는 필요한 흐름 제어 메시지도 송신됩니다. 이번 설계에서는 읽기 요청을 고정하고, DTC 삭제, ECU 리셋, 보안 액세스, 쓰기, 작동 테스트 등을 허용 목록에 포함하지 않았습니다. 진단 세션 변경에는 별도의 명시적 지정이 필요하며, 자료가 있는 EIS와 ESP 후보 경로로 한정합니다.

다음 실차 모드에는 키 ON·엔진 정지, 안정된 전원, 후보 실행 지정이 필요합니다. 연결 기기와 대상 차량을 대조하고, 도중에도 전압을 확인합니다. 기본 전압 하한 12.0 V와 추가 요청의 시간 상한 30초는 이 프로그램에서 정한 정지 조건이며, 제조사 정비 규정값으로 인용할 수 있는 것이 아닙니다. 조건을 충족하지 못하는 경우에도 도중까지의 증거를 남기도록 설계했습니다.

지금까지 성공한 51건의 테스트는 메모리상의 모의 기기와 응답을 사용한 오프라인 검증입니다. 이번 제조사 진단 준비에서 실차로 보낸 요청은 0건입니다. 분할 응답, 대상 불일치, 전압 저하, 금지 요청, 중간 끊김 등에 대한 처리를 확인했지만, Windows 실제 포트 입출력과 W204 제조사 진단 성공을 증명하는 시험은 아닙니다.

AI를 활용해 진행할 수 있었던 것은 자료 정리, 후보 구현, 이상 응답을 포함한 검증입니다. 다음에 확인할 것은 실차에서 후보 경로가 성립하는지, 어느 ECU가 회신하는지, 응답을 올바르게 조립할 수 있는지입니다. 그 결과가 갖춰진 항목만 차량용 설정에 채택하고, 미확정 항목은 계속 미확정으로 다룹니다.

Updated on 2026년 10월 19일

What are your feelings

  • Happy
  • Normal
  • Sad

©2020 BESTNET.LLC . All Rights Reserved.