EVthon 2026 — Problem Statement 

Smart EV Powertrain Diagnostics & Telematics Dongle — Full technical problem definition, scope, constraints, verification tests, and grading-ready acceptance criteria. (Derived from the EVthon Rulebook and Technical Blueprint).

1 — Context & Motivation (Why this problem matters)

Workshop-level diagnostic tools for EVs in India are expensive, fragmented, or OEM-locked. Affordable, open, and interoperable dongles that can read vehicle network data, perform early fault detection, provide cloud telemetry and geofencing, and respect EV safety practices will materially improve uptime for fleets, reduce service costs and create an accessible tooling ecosystem for small EV service centres. This challenge focuses on a compact, deployable hardware + firmware + cloud system that demonstrates those capabilities.

2 — High-level Goal (What teams must deliver)

Design, build and demonstrate a low-voltage (<60V DC) CAN-enabled Diagnostics & Telematics Dongle that:

1. Interfaces to a CAN bus (real or simulated)
   
2. Reads a defined set of EV telemetry PIDs (see Section 6)
   
3. Displays live values locally (OLED) and issues local visual alarms
   
4. Streams telemetry to a cloud dashboard (MQTT/HTTP)
   
5. Implements edge predictive logic to raise maintenance alerts
   
6. Supports location-based geofencing alerts
   
7. Complies with EVthon safety protocols and uses only allowed components.
    
   

3 — Scope (what is in / out)

In scope

• Hardware: ESP32 (or similar) + MCP2515 CAN transceiver + current/voltage/temperature sensors + OLED + GPS (or network geolocation). Use components in the standard kit or equivalents.
   
  
• Firmware: CAN reader, parser, sensor drivers, telemetry uploader, local UI, predictive algorithms running on the microcontroller.
  
• Cloud: Simple dashboard showing live telemetry, history, and alerts (can use Blynk, Firebase, AWS IoT, or a simple REST + chart frontend).
  
• Demonstration: Device connected to a testbench vehicle (12–48V simulated EV pack or 12V motor + simulated CAN frames) during the Mini Build Sprint and Grand Finale.
  
• Safety: All circuits and batteries must follow the EVthon safety “Red Book”. Max allowed system voltage < 60 V; battery charging in designated stations only.
   
  

Out of scope

• High-voltage (>60V) hardware work or direct HV battery pack modification.
  
• Using commercial closed telematics modules as your submission (you may study them but your submission must be built/assembled and coded by the team).
   
  

4 — Minimum Functional Requirements (MUST deliver these)

Teams must implement the following baseline features to be eligible for judging:

Hardware & Interfaces

1. ESP32-based controller (or equivalent; must have Wi-Fi).
   
2. MCP2515 (or equivalent) CAN transceiver.
   
3. Voltage sensing for pack voltage (via safe voltage divider + isolation if needed) OR simulated pack voltage input (for bench).
   
4. Current sensing (ACS712 or INA219) capable of ±30–100 A measurement depending on motor used.
   
5. One temperature sensor (NTC thermistor or digital sensor like DS18B20) placed to emulate cell or controller temperature.
   
6. 0.96″ OLED or similar local display.
   
7. LED for fault indicator.
   
8. GPS module or the ability to use SSID-based/network geolocation for geofencing (GPS preferred).
   

Firmware & Communication

1. CAN listener that can subscribe to and log CAN frames at configurable baud (125k/250k/500k/1M).
   
2. A PID map (see Section 6) — ability to parse named PIDs from CAN frames and present human-readable values.
   
3. Local UI to scroll values and show last fault and timestamp.
   
4. Cloud telemetry: Publish every N seconds (configurable; default N = 5s) via MQTT or HTTPS POST to the provided dashboard endpoint.
   
5. Over-the-air (OTA) update capability is optional (bonus).
   

Analytics & Alerts (Edge)

1. Voltage sag detection: detect sustained drop > X% below nominal for Y seconds → flag.
   
2. Overtemperature trend: detect rise rate > R °C/min or absolute temp > T_high → flag.
   
3. Current spike detection: peak current > I_limit for > Z ms → flag.
   
4. Simple SOH proxy: use internal resistance estimation (deltaV/deltaI on short pulses) or capacity drift heuristic to indicate SOH drop threshold.
   
5. Geofence: ability to configure polygonal area; alert if device crosses boundary (via GPS).
   

Default example thresholds (teams may tune):

• Voltage sag: drop > 5% of nominal for > 3s
  
• Overtemp: rise rate > 2 °C/min or T > 55 °C
  
• Current spike: > 1.5× continuous rated current for > 300 ms
  
• SOH proxy: internal resistance increase > 15% vs baseline
  

(Teams must document chosen thresholds and reasoning.)

Documentation & Demo

1. Wiring schematic and BOM (all components)
   
2. Firmware source code repository (GitHub/GitLab link) with README to build & flash
   
3. Cloud dashboard URL and instructions
   
4. 8–12 minute demonstration video showing end-to-end workflow (local display, CAN readout, cloud telemetry, alert triggering) — required for virtual round.
    
   

5 — Extended/Optional (for extra credit)

• Integrate secure CAN (simple MAC) or message authentication for data integrity (bonus).
  
• Implement ML inference for SOH/SOC on the microcontroller (tinyML / TensorFlow Lite) instead of heuristic.
  
• Add BLE for local mobile pairing and diagnostics UI.
  
• Implement OTA firmware updates via Wi-Fi.
  
• Provide DBC file and a tool to import CAN frames into the dashboard.
  

6 — Required Parameter List (Suggested PID set)

Teams must read or simulate at least 8 real/virtual PIDs. Example mapping (use this naming in report):

1. PACK_VOLTAGE — pack voltage (V)
   
2. PACK_CURRENT — pack current (A) (positive = discharge)
   
3. CELL_TEMP_1 — cell/pack temp (°C)
   
4. MOTOR_RPM — motor speed (rpm)
   
5. CONTROLLER_TEMP — inverter/controller temp (°C)
   
6. SOC_EST — estimated State of Charge (%) (microcontroller computed or provided on CAN)
   
7. BMS_FAULT_FLAGS — bitmask of fault states
   
8. ODOMETER — trip odometer / total km
   

CAN frame examples (teams must include real frames in report; these are example formats):

• Frame ID 0x180 + source: PACK_VOLTAGE (2 bytes, unsigned, 0.1 V LSB)
  
• Frame ID 0x180 + source: PACK_CURRENT (2 bytes, signed, 0.1 A LSB)
  
• Frame ID 0x200: TEMPERATURES (byte0 = cell1 temp offset by 40)
  
• Frame ID 0x300: MOTOR_RPM (2 bytes, rpm)
  

If working with simulation, submit generation script that emits frames in the above format. Teams that work with genuine vehicle CANs must map their vendor IDs but provide translation table.

7 — Safety Requirements (Mandatory)

All teams must follow EVthon safety mandates (the “Red Book”):

1. Max system voltage < 60V DC. Any team using higher voltage is immediately disqualified.
    
   
2. Battery chemistry: only 18650/21700 cylindrical Li-ion or LiFePO4 in hard shell. Soft pouch banned unless in a hard enclosure.
    
   
3. Charging: Batteries may only be charged at supervised charging station on venue. No desk charging.
    
   
4. Containment: Teams must provide non-conductive container for battery packs; tape exposed terminals.
    
   
5. Thermal: Any cell > 50 °C must be quarantined and reported to safety officer.
    
   
6. Mains connection: Any use of mains AC must pass through venue-provided isolation transformer/certified supply.
    
   

Safety violations attract a 20-point penalty or disqualification depending on severity. Judges enforce strictly.

8 — Test & Verification Protocols (How judges will test your device)

During Mini Build Sprint and Final demo, teams will be required to execute the following standard tests:

A. CAN Read & Log Test (Functional)

• Connect dongle to a configured CAN bus (or simulator) at chosen baud.
  
• Demonstrate live reading of the 8 PIDs with correct conversion factors.
  
• Judges will inject known frames and expect correct display & cloud values within ±5% accuracy (for voltage/current) and correct alarms.
  

B. Telemetry Latency Test

• Measure time between frame emission and cloud display. Acceptable default: ≤ 5 s for standard telemetry. (Teams can explain network limitations.)
  

C. Predictive Alert Test

• Judges will simulate a fault (e.g., injected overtemp or current spike). Device must raise local LED + cloud alert and log event with timestamp.
  

D. Geofence Test

• Judges will simulate location outside configured polygon; device must report geofence breach.
  

E. Robustness & Safety Check

• Verify wiring neatness, fusing, battery insulation, correct polarity protection, presence of pre-charge resistor for capacitive loads if applicable. Loose wiring or missing fuses will deduct points.
  

F. Documentation Review

• Evaluate wiring schematic, BOM, firmware repository, CAN DBC or frame map, and dashboard. Missing documentation reduces feasibility score.
  

9 — Scoring / Evaluation (Rubric mapped to EVthon rules)

Total 100 points (rubric directly aligned to EVthon scoring):

• Technical Complexity (30 pts)
  
  • Depth of CAN parsing logic, edge analytics, telemetry architecture (15–30).
    
• Innovation (20 pts)
  
  • Novel alert logic, security, low-cost design, multi-network support.
    
• Feasibility / Demo (25 pts)
  
  • Successful live demo, stable telemetry, accurate readings, clean build.
    
• Impact & Relevance (15 pts)
  
  • Potential for deployment in workshops, cost effectiveness, scalability.
    
• Presentation & Documentation (10 pts)
  
  • Report quality, code readability, video clarity.
    

Penalties: Safety violation = −20 pts or DQ; use of prebuilt commercial telematics device = DQ.

Minimum qual. score for prototype round: 70/100 (as per EVthon benchmarks).

---

10 — Deliverables Checklist (exact files to upload)

1. TeamName_Dongle_BOM.xlsx — full BOM with vendor links and costs.
    
   
2. TeamName_Wiring_Schematic.pdf — clear wiring diagrams and safety notes.
   
3. TeamName_FirmwareRepo_URL.txt — public repo link with build instructions.
   
4. TeamName_CAN_DBC_or_FrameMap.csv — frame IDs, payload layout, scaling.
   
5. TeamName_Dashboard_URL.txt — cloud dashboard (or sample screenshots if not public).
   
6. TeamName_Report.pdf — 10–20 pages: architecture, algorithm, thresholds, test logs.
   
7. TeamName_Video.mp4 — 8–12 minute demo (screen + hardware).
   
8. Physical prototype presented at Mini Build Sprint (assembled and powered as per safety rules).
    
   

Upload format: single ZIP named EVthon_Dongle_TeamName.zip containing folders: BOM/Docs/Code/Video.

11 — Suggested Development Plan & Milestones (3 months suggested schedule)

Week 0–1 (Concept & Plan)

• Team roles assigned. Prepare 2-page concept note (Phase 1 requirement).
   
  

Week 2–3 (Core HW selection & CAD)

• Finalize BOM from allowed kit. Enclosure sketch. Start PCB/breadboard layout.
  

Week 4–6 (Firmware & CAN simulation)

• Implement CAN listener & frame parser. Build simulator to generate frames for testing.
  

Week 7–8 (Sensors & UI)

• Integrate current/voltage/temp sensors. Implement OLED UI.
  

Week 9–10 (Cloud & Dashboard)

• Implement telemetry uplink + history display.
  

Week 11 (Analytics)

• Implement edge heuristics for alerts. Test thresholds.
  

Week 12 (Integration & Hardening)

• End-to-end testing, robustness, prepare documentation and video.
  

Mini Build Sprint (On-Campus)

• 36 hour hands-on assembly & verification; milestone checks per EVthon process.
   
  

12 — Recommended Reference Resources (from EVthon blueprint)

• Use the EVthon standard kit as baseline (ESP32, MCP2515, ACS712/INA219, OLED).
   
  
• Review BMS fault modes and safety guidance (EVthon Rulebook sections on BMS & Safety).
   
  

13 — Common FAQs (preemptive)

Q: Can we simulate CAN frames instead of hooking to a real vehicle?
A: Yes — simulation is allowed for the virtual rounds. For on-campus rounds you must demonstrate live frames (simulator acceptable) and show wiring & device functionality.

Q: Can mentors solder or code during Mini Build Sprint?
A: No. Mentors may advise only. Hands-on work must be by registered team members.

Q: Can we use 3rd-party cloud dashboards?
A: Yes (Blynk/Firebase/AWS) — but you must provide full connectivity details and demonstrate data flow during demo.

14 — Acceptance Criteria (how judges will decide “pass”)

The submission passes if all of the following are true:

1. Prototype operates at <60V and adheres to battery handling guidelines.
    
   
2. Device reads required PIDs and displays them locally.
   
3. Device publishes telemetry to cloud with ≤5 s latency (document network test).
   
4. At least two predictive alerts trigger correctly during triggered test cases.
   
5. Documentation & firmware repo are complete and buildable.
   
6. No plagiarism or prebuilt telematics module used as primary device.
   

Failing any of the first two items results in immediate disqualification from prototype advancement.

15 — Closing notes & alignment to EVthon strategy

This problem statement directly implements EVthon’s mission to move beyond purely software ideation into hardware prototyping, closing the “deployment gap” for EV talent and creating solutions that OEMs and workshops can realistically adopt. The safety and IP rules, judging rubric and structure for progression to prototype and internship rounds are taken verbatim from the EVthon technical rulebook.