3.6 KiB
문제를 어떻게 좁혔나
1. 센서 이름이 있다고 실제 센서값은 아니다
공용 automotive framework의 수많은 getter 중에는 현재 차종에서 한 번도 갱신되지 않는 초기값과 다른 variant의 값이 있습니다. 전조등·미등의 0을 곧바로 꺼짐으로, 후측방의 -1,-1을 경고 없음으로 발행하면 그럴듯하지만 틀린 화면이 됩니다.
원천 callback·유효성·단위를 확인하고, 미확인은 미확인으로 남기는 것이 목표입니다. 특히 연료 게이지가 변해도 같은 숫자를 반환하는 getter는 잔량 측정값으로 채택하지 않았습니다. RPM 수신을 성공했다고 연료까지 찾았다고 기록하지 않습니다.
공개한 HscanRpmDecoder는 정해진 envelope·길이·XOR·메시지 구조·패딩을 검증한 뒤 RPM을 읽습니다. 이미 받은 바이트를 해석할 뿐, ECU 요청·socket 접속·CAN 송신 기능은 없습니다.
2. 교통 packet 도착과 도로별 정보 갱신은 다르다
TPEG packet이 몇 초마다 들어온다는 사실은 모든 도로의 최신 값이 그 간격으로 도착한다는 뜻이 아닙니다. RF lock, PCBER/FIC 확정, 서비스 연결, 내비 callback, 개별 도로의 관측·만료는 따로 봐야 합니다.
운영 보정은 새 유효값으로 갱신하고 누락·무효값으로 유효한 이전 값을 즉시 지우지 않는 것입니다. 보존 TTL은 60분이며, 오래된 값이 실제 현재 교통이라는 뜻은 아닙니다. 미지원 도로·만료 구간은 회색으로 남을 수 있습니다.
후면 카메라도 decoder가 전달하지 않는 rear 속성을 class·개수·거리만으로 추정하지 않습니다. 현재 보존은 검증된 기준 DB와 일치하는 기존 항목에 한정됩니다.
3. 지도 파일과 엔진은 독립적으로 바꿔도 되는가
신지도와 구형 엔진의 조합은 부팅·화면 표시에 성공했지만 특정 목적지 계산에서 HAFP node parser crash를 냈습니다. 이후 지도와 맞는 엔진에 기존 변경을 다시 이식하고 같은 실패 요청으로 확인했습니다.
교훈은 부팅 성공 = 모든 경로 계산 호환이 아니라는 점입니다. 공개한 과거 V038 차속 생성기는 이 현재 엔진용 설치 파일이 아닙니다. 정확한 입력 해시가 아니면 거부하는 과거 예제로만 제공합니다.
4. 외부 경로 geometry와 순정 길안내는 다른 계약이다
Naver 좌표를 목적지·경유점으로 보내면 순정 내비가 자체 경로를 계산할 수는 있지만, 외부 경로를 그대로 안내하는 것은 아닙니다. 설치 지도 link·방향·parcel 경계·연결성·안내 모델이 맞아야 합니다.
과거 한 시험에서 geometry 408점을 241개 RealLink·5,735바이트 순정 응답으로 변환하고 parser 소비를 확인했습니다. 408은 고정 규격이 아니라 그 입력의 표본 수입니다. 이 성과를 임의 경로·실제 안내·주기/이탈 재탐색 완료로 확대하지 않습니다. 관련 실차 개발은 보류돼 있습니다.
5. 실패를 숨기는 성공 응답은 해결이 아니다
위치공유는 수신자별 성공·실패를 격리하고, 한 명의 실패로 다른 사람의 정상 링크를 폐기하지 않아야 합니다. 원격 명령은 최종 차량 응답 전까지 성공이 아닙니다. 새 메뉴가 보이는 것과 해당 ECU·경로 엔진이 기능을 지원하는 것도 다릅니다.
이 공개본은 그러한 원칙을 설명하고 일부 순수 로직을 제공합니다. 전체 운영 서버·차량 제어 기능을 배포하는 저장소는 아닙니다.