1 of 11

Từ nhu cầu sạc đến

phương án đã xác minh

Team T-036

Phó Viết Tiến Anh - 2A202601341
Ong Xuân Sơn - 2A202601327
Nguyễn Duy Dũng - 2A202601505
Lâm Việt Hoàng - 2A202601067

SmartCharging

2 of 11

1

Problems

Tìm thấy trạm chưa có nghĩa là

tìm được phương án sạc

ETA đường bộ không chỉ là khoảng cách trên bản đồ

Trạng thái trạm & cổng có thể đã bị chiếm bởi phiên đang chạy

Đầu nối & công suất phải tương thích và đủ để đạt SoC mục tiêu

Deadline & cam kết lịch đã xác nhận không được phá vỡ

Gần nhưng bận

Xa hơn nhưng

hoàn tất sớm

Không tương thích

Chi phí thấp

3 of 11

2

Solution

STEP 1

Capture

Ít tìm kiếm hơn → phương án đã xác minh → tài xế quyết định → kiểm tra lại trước khi cam kết

Nhận xe, SoC, target, deadline và location qua form hoặc hội thoại.

STEP 2

Evaluate

Kết hợp Mapbox road evidence với trạng thái trạm, lịch, phiên và giá → Top-K offer.

STEP 3

Verify

Solver + verifier chỉ công bố phương án đủ bằng chứng; có thể nêu sạc một phần.

STEP 4

Adapt

Revalidate khi Driver chọn; fault được ghi nhận, chỉ reroute khi có fresh verified offer.

Tài xế vẫn là người quyết định cuối cùng. SmartCharging tìm, kiểm chứng và giải thích các lựa chọn — offer là non-binding cho đến khi được revalidate và commit.

Để giải bài toán đó, SmartCharging xây dựng một quy trình gồm bốn bước.

Đầu tiên, Capture — hệ thống nhận những thông tin thực sự cần cho quyết định, như xe, mức pin hiện tại, mức pin mục tiêu, deadline và vị trí.

Tiếp theo là Evaluate — kết hợp ETA đường bộ với trạng thái thực tế của trạm, lịch sạc, phiên đang chạy và giá.

Sau đó là Verify — solver và verifier kiểm tra liệu phương án đó có thực sự khả thi hay không.

Và cuối cùng là Adapt.

Đây là điểm rất quan trọng: một recommendation đúng ở thời điểm hiện tại có thể không còn đúng vài phút sau. Vì vậy, khi tài xế thực sự chọn phương án, SmartCharging sẽ kiểm tra lại trên trạng thái mới nhất trước khi tạo lịch.

Nói ngắn gọn: SmartCharging không chỉ recommend. SmartCharging verify trước khi commit.

4 of 11

3

Product Demo

1 · Create request

2 · Review offers

3 · Accept

4 · Check-in

Input rõ ràng — durable request

ETA · completion · cost · evidence

Lock → fresh snapshot → re-solve

Cross-role, cùng một session

Driver Request

Verified Recommendations

Compare & Select

Fresh Revalidation

Schedule / Hold

Check-in & Charging

Main demo flow

Driver + Operator Monitoring

5 of 11

4

Achitecture

6 of 11

5

AI/Agent aproach

Intent

LLM Planner

Tool Policy

Snapshot + Solver

Verifier

Verified Offers

Driver decides

Đây cũng là một trong những quyết định thiết kế quan trọng nhất của SmartCharging.

Chúng em không để LLM quyết định một phương án sạc có khả thi hay không.

LLM Planner làm những việc mà LLM làm tốt: hiểu intent, duy trì context nhiều lượt, hỏi lại khi thiếu thông tin, lựa chọn capability phù hợp và diễn giải kết quả cho người dùng.

Nhưng trước khi capability được thực thi, nó phải đi qua một deterministic tool policy.

Và khi cần đưa ra phương án sạc, hệ thống luôn quay về state thật, tạo snapshot, chạy solver và cuối cùng là verifier.

Với những hành động nhạy cảm như giảm công suất, pause, stop hay reschedule, chúng em còn bổ sung Human-in-the-loop trước khi thực thi.

Vì vậy, ranh giới ở đây rất rõ:

LLM hiểu và đề xuất hành động.�Deterministic system quyết định điều gì được phép.�Solver và verifier quyết định điều gì thực sự khả thi.�Và con người quyết định có cam kết hay không.

Đó là cách chúng em tận dụng AI mà không biến LLM thành source of truth.

7 of 11

6

Technical Highlights

Từ kiến trúc đó, chúng em tập trung vào ba đặc tính kỹ thuật.

Thứ nhất là fresh revalidation: recommendation có thể stale, nên trước commitment, hệ thống phải đọc lại state và giải lại bài toán.

Thứ hai là bounded Agent: LLM không có đường tắt để trực tiếp thay đổi dữ liệu hay bỏ qua validation.

Và thứ ba là fail safely: khi không có đủ road evidence hoặc không thể xác minh một phương án, hệ thống không cố tạo ra một câu trả lời có vẻ hợp lý.

Ở validation flow trên staging, từ 5 candidate stations, hệ thống tạo ra 3 verified offers.

Điểm chúng em muốn chứng minh ở đây không phải rằng AI “thông minh” đến đâu, mà là:

mỗi quyết định quan trọng đều có boundary, evidence và cơ chế kiểm tra lại.

8 of 11

7

Demo Video

9 of 11

8

Chalenges & Learnings

10 of 11

Driver monitoring / staging evidence

Staging-validated MVP

1

1. OCPP + live telemetry

Thay mô phỏng bằng dữ liệu vận hành trực tiếp

2

2. queue/worker/observability production

Đưa xử lý nền và khả năng quan sát vào production

3

3. rolling-horizon multi-request optimization và pilot measurement

Mở rộng điều phối và đo lường trong pilot

9

Next Steps

NOW

NEXT STEPS

CURRENT LIMITATIONS

simulated charger/telemetry, demo station dataset, in-process worker, chưa có OCPP/message broker và chưa có full-stack production evidence.

Thank You — Q&A

NEXT STEPS

1

1. OCPP + live telemetry

Thay mô phỏng bằng dữ liệu vận hành trực tiếp

2

2. queue/worker/observability production

Đưa xử lý nền và khả năng quan sát vào production

3

3. rolling-horizon multi-request optimization và pilot measurement

Mở rộng điều phối và đo lường trong pilot

Ở thời điểm hiện tại, SmartCharging đã chứng minh được một luồng MVP

xuyên suốt: từ request, verified offers, revalidation, schedule cho đến

simulated charging và cross-role monitoring.

Tuy nhiên, chúng em cũng xác định rất rõ đây **chưa phải một production

system hoàn chỉnh**.

Ba bước tiếp theo là tích hợp OCPP và telemetry từ charger thật; đưa

worker, queue và observability lên kiến trúc production; sau đó mở rộng

sang bài toán tối ưu nhiều yêu cầu đồng thời và đo lường trên pilot thực

tế.

Từ một câu hỏi tưởng như rất đơn giản --- **"Tôi nên sạc ở đâu?"** ---

SmartCharging hướng tới một câu trả lời tốt hơn:

**Không chỉ là trạm nào gần nhất, mà là phương án nào thực sự khả thi,

có thể kiểm chứng và còn đúng tại thời điểm chúng ta quyết định.**

Chúng em là team T-036.

Cảm ơn thầy cô và mọi người đã lắng nghe. Chúng em xin sẵn sàng cho phần

Q&A.

11 of 11

CẢM ƠN MỌI NGƯỜI ĐÃ LẮNG NGHE