[OBD Acquisition & Kinematics] 차량 센서 데이터 수집 통신 파이프라인 구축 및 트러블슈팅

차량의 동역학 데이터(악셀, 브레이크, 차량 속도 등)를 수집하기 위해 PCAN to OBD 케이블을 활용하여 통신 파이프라인 구축을 진행했다. 초기에는 PEAK사의 공식 OBD Viewer와 PCAN-View를 통해 통신 상태를 점검했다. 그러나 기본 제공되는 OBD Viewer에서는 표준 PID만 조회가 가능했으며, 제어 계통에 해당하는 비표준 확장 PID 데이터는 확인할 수 없었다. 이에 따라 필요한 센서 데이터의 PID를 특정하기 위한 브루트포스 스캔(Brute-force scan) 환경 구축을 시도했다.

[통신 파이프라인] 확장 PID 브루트포스 스캔의 한계

특정 조작(예: 브레이크 페달 조작 전후)에 따른 데이터를 비교하여 목적 PID를 찾기 위해 스크립트 기반의 자동화가 필요했다. PEAK사에서 제공하는 PCAN-View는 수동 조작 기반의 툴이므로 브루트포스 스캔 및 수신 응답 로깅에 적합하지 않았다.

• python-can 패키지를 활용하여 유효한 확장 PID를 탐색하는 자동화 스크립트를 작성했다.
• 스크립트를 차량에 연결하여 테스트한 결과, 차량으로부터 수신되는 응답 데이터가 손상(깨짐)되는 현상이 지속적으로 발생했다.
• 문제 원인을 프로토콜 처리 상의 한계로 추정했다. 물리적 연결이 유지된 상태에서 공식 툴인 PCAN-View를 통해 진단 세션 시작 메시지를 전송했을 때는 정상적인 응답이 수신됨을 확인했다.
• python-can과 같은 범용 라이브러리 환경에서는 차량 진단 프로토콜의 복잡한 요구사항을 완벽하게 제어하기 어려워 통신 불안정이 발생한 것으로 판단했다.

[프로토콜] PCAN-OBDonUDS API 기반 통신 안정성 확보

범용 라이브러리를 활용한 자체 구현의 한계를 확인한 후, 신뢰성 있는 통신 계층 확보를 위해 PEAK사의 공식 API 환경으로 전환했다.

• PEAK사가 공식 제공하는 PCAN-OBDonUDS API를 도입하여 진단 프로토콜 통신을 처리하도록 구조를 변경했다.
• 해당 API는 Windows 전용으로 배포되어 기존 Linux 환경을 사용할 수 없다는 물리적 제약이 존재했다. 그러나 프로토콜 안정성 확보와 빠른 데이터 검증을 최우선순위로 두어 Windows 환경으로 개발 환경을 전환했다.
• 개발에 앞서 PCAN-ISO-TP, PCAN-OBD-2, PCAN-OBDonUDS, PCAN-UDS, PCAN-Basic 등 관련 API 매뉴얼을 종합적으로 분석하여 통신 규격을 확인했다.
• 이를 바탕으로 C++ 환경에서 안정적으로 확장 PID를 스캔하고, 차량의 응답을 유실 없이 기록할 수 있는 데이터 수집 프로그램의 초안을 완성했다.