Wiznet makers

Overview

FUTUNER V1.1 is an ESP32-S3-based aftermarket ECU tuning dongle designed for Bosch MG1, MDG1, and MED17 ECU families. Its main role is to sit between a user’s browser, a vehicle ECU, and an SRM cloud backend, then provide controlled access to live gauges, VIN-bound calibration delivery, logging, and later-stage ECU flash workflows. The repository describes it as a mission-focused subset of FUTV1.0, organized around Phase 1 non-destructive features and Phase 2 full binary flash preparation.

This is not just a simple OBD display. It is closer to a staged ECU product platform: embedded firmware, browser UI, CAN/UDS transport, SBF calibration files, cloud licensing, test tools, and hardware-reference assets are all kept in the same repository. Naturally, because one repository apparently was not enough trouble for humanity.

System Architecture

The system is built around four main parts:

The README lists firmware, UI, cloud, SBF samples, tools, documentation, hardware references, and ignored secret files as the repository’s main layout. The firmware tree is described as ESP32-S3 code with CAN, ISO-TP, UDS, logger, ECU write, Wi-Fi, WebSocket, commands, and filesystem logic.

Technical Flow

The intended user flow is:

1. The dongle connects to the vehicle through the OBD-II diagnostic path.
2. The user connects to the dongle through a browser-based UI.
3. The dongle reads vehicle identity information such as VIN, boxcode, and software version.
4. The cloud backend binds the dongle behavior to a VIN or device entitlement.
5. The dongle can stream live ECU data to the browser through WebSocket.
6. Calibration files can be downloaded from the cloud and applied only through gated workflows.
7. Full binary flash is treated as a later, dangerous phase, not as the first customer-facing feature.

The mission specification describes the architecture as browser ↔ FUTUNER dongle ↔ ECU, with the dongle also talking to SRM Cloud for licensing, SBF delivery, and logs. It also states that Phase 1 is RAM-only and non-destructive, while Phase 2 is reserved for full binary flash.

Communication Model

The CAN/UDS layer is deliberately narrow. The protocol document identifies CAN 2.0B at 500 kbps, standard 11-bit identifiers, and ISO-TP over CAN for messages larger than a single CAN frame. The dongle uses physical CAN IDs 0x7E0 for requests and 0x7E8 for ECU responses, while broadcast 0x7DF is defined but not used in the current code path.

UDS service use is also conservative. The repository documents 0x3E Tester Present, 0x22 Read Data By Identifier, and negative-response handling as core services in the current protocol layer. Patch detection, live logger access, and RAM-write behavior are built around controlled subfunctions rather than open-ended probing.

Cloud and Licensing

The cloud backend is a FastAPI-based reference implementation using SQLite and Caddy/TLS. It is intended as a server-side replacement for a previous API service, with endpoints for device registration, firmware update checks, firmware download, and per-device calibration delivery.

The most important design point is VIN-bound SBF delivery. The cloud stores a base SBF calibration file, patches a per-device ethanol_random value into it during delivery, and sends the device-specific version to the dongle. This makes calibration delivery tied to a provisioned vehicle/device rather than a freely reusable file.

Current Readiness

The repository should be understood as an active engineering build, not a finished public product. The README says Phase 1 is the priority, with live gauges and WOT logging partially working, CAN transport working, DTC read/clear stubs present, Ethernet pending, and Phase 2 full binary flash research complete but still needing implementation.

The Phase 1 completion document is even more direct: customer-experience validation is the real exit gate, not just host tests. It lists live gauges as passing, data logging as partial, DTC clear as broken, Ethernet as deferred pending hardware, and Phase 2 remaining disabled until all Phase 1 close criteria are green.

W5500 / Ethernet Relevance

W5500 is not the active core of the current implementation. The current working transport is CAN. However, the mission specification explicitly describes a future transport abstraction where CAN and Ethernet share the same send_frame, receive_frame, and status interface, with Ethernet implemented by W5500 or equivalent hardware.

That means the W5500’s role would be a future wired transport interface, not the tuning logic itself. The meaningful design idea is transport separation: UDS/ISO-TP application logic should remain above the hardware layer so the system can move from CAN-only operation toward CAN/Ethernet variants without rewriting tuning workflows. 추론임: if this were positioned for WIZnet relevance, the honest angle would be “W5500 as a future deterministic Ethernet transport option for an ECU service dongle,” not “W5500 powers the existing product.”

Engineering Value

The valuable part of this repository is not one clever file. It is the system boundary discipline:

• CAN ID discipline is strict.
• Feature execution is gated.
• Phase 1 is separated from destructive Phase 2 flash.
• Variant data is treated as a safety boundary.
• Cloud delivery is tied to VIN/device identity.
• Host tools support repeatable build, flash, cloud push, and provisioning loops.

The repository’s own rules prohibit broadcast probing, raw CAN probing, and unsafe ECU address scans because the target vehicle gateway can lock out diagnostic access if the wrong addresses are scanned.

Practical Limits

The project has several unresolved or high-risk areas:

The mission specification describes full 8 MB binary reflash as dangerous because an interrupted or failed flash can leave an ECU unbootable, requiring verified challenge-response, sector erase/write, verification, and recovery behavior.

FUTUNER V1.1: ESP32-S3 기반 차량 ECU 튜닝 동글과 VIN 연동 캘리브레이션 전달 구조

1. 이 프로젝트는 무엇인가

FUTUNER V1.1은 차량 ECU에 연결되는 ESP32-S3 기반 튜닝 동글 프로젝트다. 대상은 Bosch MG1, MDG1, MED17 계열 ECU이며, 주요 목적은 실시간 게이지 표시, WOT 로그 수집, VIN 기반 라이선스, SBF 캘리브레이션 전달, 그리고 향후 전체 ECU 바이너리 플래시까지 포함하는 단계형 튜닝 시스템을 구축하는 것이다.

다만 현재 상태를 “완성품”으로 보면 안 된다. 저장소 문서상 Phase 1은 RAM-only, 즉 ECU 플래시를 건드리지 않는 비파괴 기능을 우선 검증하는 단계이고, Phase 2의 전체 바이너리 플래시는 위험도가 큰 별도 단계로 분리되어 있다. 이 구분이 이 프로젝트의 핵심이다. 아무거나 먼저 태워보는 식의 개발이 아니라는 점은 칭찬할 만하다. 드문 일이다.

2. 전체 구조

사용자 브라우저
   │
   │ Wi-Fi / WebSocket
   ▼
FUTUNER ESP32-S3 동글
   │
   ├─ CAN / ISO-TP / UDS
   │      ▼
   │   차량 ECU
   │
   └─ HTTPS / API
          ▼
       SRM Cloud

이 구조에서 브라우저는 표시와 명령 입력을 담당하고, 실제 ECU 통신과 판단은 동글이 수행한다. 클라우드는 VIN 등록, 라이선스, 펌웨어 빌드 배포, SBF 캘리브레이션 전달, 로그 업로드를 담당한다. 저장소의 README도 firmware, ui, cloud, sbf, tools, docs, hw_reference를 주요 구성 요소로 나눈다.

핵심은 “브라우저 UI가 ECU에 직접 접근하지 않는다”는 점이다. 브라우저는 동글과 WebSocket으로 통신하고, 동글이 CAN/UDS 계층을 통해 ECU와 대화한다. 이 구조는 사용자 경험과 ECU 접근 제어를 분리하기 위해 필요하다. 추론임: ECU 튜닝 장비에서 UI가 단순 표시 계층으로 남고 실제 제어권을 펌웨어가 갖는 것은 안전 게이트를 한 곳에 모으기 위한 설계로 볼 수 있다.

3. 주요 구성 요소

도구 쪽도 단순 보조 수준이 아니다. bundle_ui.py는 UI 파일을 동글이 제공할 단일 HTML 파일로 묶고, sbf_to_json.py는 SBF 파일을 JSON으로 디코딩하며, bench_push.py는 빌드, 플래시, 클라우드 업로드, 동글 프로비저닝까지 묶는 벤치 작업 파이프라인 역할을 한다.

4. ECU 통신 방식

이 프로젝트의 ECU 통신은 CAN 2.0B, ISO-TP, UDS 조합이다. 문서 기준으로 물리 계층은 500 kbps CAN, 표준 11-bit ID를 사용하며, CAN 단일 프레임보다 큰 UDS 메시지는 ISO-TP로 분할된다.

프로토콜 규칙은 꽤 엄격하다. ECU 요청은 0x7E0, ECU 응답은 0x7E8을 사용하며, 브로드캐스트 0x7DF는 정의되어 있지만 현재 코드에서는 사용하지 않는다고 되어 있다. 이건 중요하다. 차량 네트워크에서 괜히 브로드캐스트를 쏘는 순간, 개발자는 디버깅을 하는 게 아니라 차량 게이트웨이에게 시비를 거는 것이다.

UDS 서비스는 0x3E Tester Present, 0x22 Read Data By Identifier, 그리고 negative response 처리가 중심이다. 패치 감지, live logger, ECU RAM write도 이 통제된 흐름 위에 얹혀 있다.

5. 동작 흐름

5.1 초기 연결

동글은 차량 OBD-II 포트에 연결되고, ECU와 CAN/UDS 통신을 시작한다. 이후 VIN, boxcode, software version 같은 식별 정보를 읽는다. 이 정보는 차량과 ECU variant를 구분하고, 클라우드에서 어떤 캘리브레이션과 권한을 줄지 판단하는 기준이 된다.

5.2 브라우저 UI 연결

사용자는 스마트폰이나 노트북 브라우저로 동글 UI에 접속한다. 동글은 WebSocket 서버 역할을 하며, 브라우저는 실시간 게이지나 상태 표시를 받는다. 문서상 live gauge는 boost, lambda, ignition timing, coolant/intake temperature, RPM, throttle, load 등 UDS로 읽을 수 있는 ECU 파라미터를 대상으로 한다.

5.3 클라우드 연동

SRM Cloud는 장치 등록, 펌웨어 업데이트 확인, 펌웨어 다운로드, SBF 캘리브레이션 전달을 처리한다. 특히 SBF 전달 시 base SBF에 장치별 ethanol_random 값을 패치해서 전달한다. 이 구조는 캘리브레이션 파일을 단순 복사해서 다른 차량에 재사용하기 어렵게 만드는 장치다.

5.4 Phase 1 기능

Phase 1은 비파괴 기능 중심이다. VIN pairing, live gauges, WOT logging, DTC read/clear, CAN transport 검증이 포함된다. 문서상 현재 live gauges는 통과로 표시되어 있지만, data logging은 부분 상태, DTC clear는 broken 상태, Ethernet은 하드웨어 대기 상태다.

5.5 Phase 2 기능

Phase 2는 전체 ECU 바이너리 플래시다. 문서상 8 MB ECU binary reflash, AES-128 challenge-response, sector erase/write, verification, fault recovery를 포함한다. 실패 시 ECU가 부팅 불능이 될 수 있으므로 Phase 1 검증 후 마지막에 테스트하는 위험 영역으로 분리되어 있다.

5.6 Phase 3 기능

Phase 3은 live tuning 생태계다. SBF live calibration switching, SBF/STF/FBF builder, ethanol constraint engine, rev limiter safety, 9-slot map switch UI, pre-apply safety gate 등이 이 단계로 분리되어 있다. 기본 설정은 FUTUNER_PHASE3_ENABLED=0이며, Phase 1 완료 전 고객 차량에 활성화하지 않는다는 게 문서상 원칙이다.

6. 설계 선택의 의미

6.1 Phase 분리

이 프로젝트에서 가장 중요한 설계 선택은 위험도에 따라 기능을 Phase 1, 2, 3으로 분리한 점이다.

이 구조는 현실적이다. ECU flash를 먼저 구현하고 나머지는 나중에 맞추는 방식은 개발자의 용기라기보다 보험회사에 보내는 러브레터다. Phase 1을 게이트로 둔 것은 좋은 판단이다.

6.2 VIN / ECU variant 중심 구조

FUTUNER는 ECU variant를 boxcode, software number, ECU family, endianness, memory map signature 등으로 구분한다. Scale Architecture 문서는 variant별 RAM 주소가 다를 수 있고, 잘못된 주소 write는 fleet-wide brick risk가 된다고 설명한다.

따라서 이 프로젝트는 “튜닝 파일 하나를 여기저기 적용”하는 구조가 아니라, VIN, ECU variant, manifest, writable region, license를 묶어서 동작시키려는 구조다. 추론임: 이 점이 상용화 가능성의 핵심이다. ECU 튜닝에서 위험한 것은 알고리즘보다 “어떤 차에 어떤 주소를 썼는지 모르는 상태”이기 때문이다.

6.3 Feature manager / ON-OFF 규칙

프로젝트 규칙은 모든 사용자 노출 기능이 기본 비활성 상태여야 하고, 명시적 UI 또는 serial command로만 시작되어야 하며, feature manager에 등록되어야 한다고 정한다. 동시에 하나의 active feature만 허용하는 중앙 상태 관리도 요구한다.

이건 꽤 좋은 임베디드 설계 습관이다. 특히 ECU write, logging, flash, BLE ethanol, live tune 같은 기능이 동시에 얽히면 타이밍 문제가 사고로 이어질 수 있다. “한 번에 하나만 실행”은 투박하지만 강력하다. 인간도 동시에 여러 일을 하면 망치는데, ECU write 중에는 더더욱 그렇다.

7. W5500 / WIZnet 관점

이 저장소에서 W5500은 현재 완성된 핵심 기능이 아니다. 현재 통신의 실사용 중심은 CAN이다. 다만 Mission Spec은 transport abstraction을 설계 요구사항으로 두고, CAN driver와 Ethernet driver가 같은 인터페이스를 구현하도록 하며, Ethernet 하드웨어 예시로 W5500 또는 동급 장치를 언급한다.

정확히 말하면 W5500의 역할은 다음과 같이 정리할 수 있다.

추론임: WIZnet 관점에서 이 프로젝트를 다룬다면 “W5500이 ECU 튜닝을 한다”가 아니라, **“W5500이 향후 ECU 서비스 동글의 Ethernet transport 계층을 맡을 수 있는 구조”**라고 설명하는 것이 정확하다. 이 차이를 빼먹으면 또 발표자료가 광고문처럼 썩어버린다.

8. 강점

8.1 시스템 경계가 명확하다

펌웨어, UI, 클라우드, SBF, 도구, 문서가 구분되어 있고, 각 계층의 역할이 비교적 명확하다. README는 firmware, UI, cloud, docs, tools, hw_reference를 구조적으로 나누고 있으며, cloud README도 동글-facing API와 admin surface를 분리한다.

8.2 ECU 안전 규칙을 문서화했다

0x7E0만 사용하고, 0x7DF 브로드캐스트와 raw probing을 금지하는 규칙이 명시되어 있다. 이건 차량 네트워크 프로젝트에서 매우 중요하다. “일단 스캔해보자”는 PC 네트워크에서는 호기심이지만, 차량 ECU에서는 정비소 예약 버튼이다.

8.3 Variant scaling 문제를 제대로 인식하고 있다

Scale Architecture Proposal은 100개 이상의 ECU software version을 지원하려면 단순 처리량보다 schema complexity, manifest, validation, per-variant test가 중요하다고 본다. SQLite에서 PostgreSQL로 넘어가는 이유도 성능이 아니라 관계형 복잡도 때문이라고 설명한다.

8.4 개발/벤치 도구가 있다

bench_push.py는 빌드, 플래시, 클라우드 업로드, 프로비저닝을 묶는 도구이고, dirty git tree에서 플래시를 막는 안전 장치도 갖고 있다. 이는 실제 하드웨어 반복 테스트에서 추적성을 유지하려는 설계다.

9. 한계와 위험

특히 공개 저장소에 민감한 ECU key, VIN, 복구 문서, 고객 관련 정보가 섞이면 제품 신뢰성뿐 아니라 법적·운영상 문제로 이어질 수 있다. 이 저장소도 secrets 디렉터리를 gitignore 대상으로 두고, key류를 commit하지 말라는 구조를 갖고 있다.

10. 적용 조건

이 프로젝트는 다음 조건에서 의미가 있다.

추론임: 개인 취미 저장소라기보다는 소규모 튜닝 업체의 내부 제품화 작업에 가깝다. “오픈소스 예제”로 보기에는 ECU key, VIN-bound delivery, commercial licensing, staged flash workflow가 너무 강하게 드러난다.

11. 최종 판단

FUTUNER V1.1은 단순한 ESP32 OBD 프로젝트가 아니다. 구조상으로는 차량 ECU 튜닝 제품의 전체 골격에 가깝다. 펌웨어, 클라우드, UI, SBF 캘리브레이션, variant manifest, 벤치 도구, Phase별 안전 게이트가 모두 들어 있다.

다만 현재 상태는 “즉시 고객 차량에 적용 가능한 완제품”이 아니라, Phase 1 고객 경험 검증을 닫고 Phase 2/3 위험 기능을 순차적으로 열어야 하는 개발 중 시스템이다. 이 저장소의 가치는 완성도보다 구조 설계와 위험 분리 방식에 있다. 특히 CAN ID discipline, VIN-bound SBF delivery, feature gating, variant manifest 중심 설계는 기술적으로 볼 가치가 있다.

W5500 관점에서는 현재 핵심 구현이 아니라 향후 Ethernet transport 후보로 보는 것이 맞다. 이 부분을 과장하지 않고 “CAN 중심 ECU 동글이 Ethernet transport abstraction으로 확장될 수 있는 구조”라고 설명해야 정확하다. 제품을 멋있게 보이게 하려고 사실을 부풀리는 순간, 기술 큐레이션이 아니라 자동차 액세서리 쇼핑몰 문구가 된다.

12. 저자 / 조직 정보