V-Valet — Hệ thống điều phối bãi đỗ xe tầng hầm thông minh

1. Tổng quan

V-Valet là hệ thống hỗ trợ tài xế tìm và sử dụng chỗ đỗ phù hợp trong các bãi xe lớn hoặc có nhiều tầng. Đồng thời, hệ thống cung cấp cho ban quản lý công cụ để tạo kịch bản, quan sát tình trạng bãi, xử lý ngoại lệ và truy vết các quyết định đã xảy ra.

V-Valet không chỉ trả lời câu hỏi “còn bao nhiêu ô trống?”. Hệ thống tập trung giải quyết các câu hỏi nghiệp vụ quan trọng hơn:

• Xe này có đủ điều kiện sử dụng ô nào?
• Tài xế đang cần ô thông thường, ô sạc điện hay ô accessibility?
• Trong những ô hợp lệ, ô nào phù hợp nhất?
• Làm thế nào để hai xe không được giữ cùng một ô?
• Đường nào dẫn xe tới đúng vị trí đã được giữ?
• Nếu ô vừa được chọn không còn sử dụng được thì hệ thống xử lý thế nào?
• Vì sao hệ thống chọn ô A thay vì ô B?
• Ai đã thực hiện hoặc phê duyệt một hành động?
• Quyết định đó được đưa ra theo phiên bản quy định nào?

Mục tiêu của V-Valet là tạo ra một quy trình điều phối rõ ràng, có thể giải thích và có thể kiểm chứng.

---

2. Bài toán cần giải quyết

Trong một bãi xe lớn, tài xế thường phải tự chạy vòng quanh để tìm chỗ. Việc này làm tăng thời gian tìm kiếm, gây ùn tắc trong bãi và khiến tài xế khó lựa chọn được vị trí phù hợp với nhu cầu.

Một hệ thống chỉ hiển thị số ô trống vẫn chưa giải quyết được các vấn đề như:

• xe xăng được đưa vào ô sạc điện;
• xe lớn được đưa vào ô không phù hợp;
• tài xế không có quyền nhưng vẫn được cấp ô accessibility;
• booking theo khu vực nhưng hệ thống lại chọn ô ngoài khu đã đặt;
• hai tài xế cùng nhận một ô;
• trạng thái cảm biến đã cũ nhưng vẫn được dùng để ra quyết định;
• hệ thống không giải thích được tại sao chọn một vị trí;
• khi có lỗi, quy trình bị mất hoặc phải bắt đầu lại từ đầu.

V-Valet giải quyết các vấn đề này bằng một chuỗi xử lý có thứ tự:

Hiểu nhu cầu → kiểm tra điều kiện → xếp hạng ứng viên → giữ chỗ → dẫn đường → theo dõi → giải thích và lưu vết.

---

3. Các nhóm người dùng

V-Valet hiện mô phỏng chi tiết hai nhóm người dùng chính.

3.1. Tài xế

Tài xế sử dụng Driver App để:

• đăng nhập hoặc tạo phiên sử dụng;
• chọn bãi xe;
• khai báo thông tin xe;
• chọn preset hoặc nhập nhu cầu bằng tiếng Việt;
• xem các vị trí được đề xuất;
• xác nhận phương án;
• giữ chỗ;
• nhận chỉ dẫn trong bãi;
• theo dõi hành trình trên simulator Godot;
• xem trạng thái khi xe đã đỗ.

Mỗi tài xế có một môi trường Godot riêng. Xe, camera, barrier, tuyến đường và hành trình trong môi trường này thuộc về phiên của tài xế đó.

3.2. Ban quản lý bãi xe

Ban quản lý sử dụng Operations Console và Scenario Lab để:

• xem sức chứa và tình trạng vận hành;
• tạo nhiều nhu cầu xe giả lập;
• thử các kịch bản như giờ cao điểm hoặc nhu cầu sạc EV;
• kiểm tra kết quả chuẩn hóa nhu cầu;
• chạy pipeline phân bổ;
• quan sát kết quả trên sơ đồ GEN-3F;
• xem reason code, correlation ID và nhật ký hoạt động;
• kiểm tra các quyết định cần phê duyệt.

3.3. Ranh giới giữa Driver và BQL

Driver và BQL là hai môi trường mô phỏng độc lập.

• Driver mô phỏng trải nghiệm của tài xế trong một private Godot environment.
• BQL mô phỏng hoạt động điều hành trong Scenario Lab.
• BQL không trực tiếp quan sát camera hoặc xe trong môi trường riêng của Driver.
• Kịch bản PEAK_HOUR của BQL không tự động tạo xe NPC trong Godot của Driver.
• Bản đồ Scenario Lab là một bản chiếu của kịch bản vận hành, không phải physical live occupancy của các Driver environments.

Hai môi trường chỉ dùng chung:

• cấu trúc dữ liệu;
• topology của bãi;
• policy;
• thuật toán eligibility và allocation;
• reason code;
• quy tắc audit.

Chúng không nên dùng chung trạng thái xe, camera, session hoặc simulator runtime.

---

4. Kiến trúc hệ thống

V-Valet sử dụng kiến trúc modular monolith.

Điều này có nghĩa là hệ thống được chia thành nhiều module có trách nhiệm riêng, nhưng phần backend chính vẫn được triển khai như một ứng dụng thống nhất.

Cách tổ chức này giúp:

• mỗi module có phạm vi và trách nhiệm rõ ràng;
• tránh phải vận hành quá nhiều microservice khi sản phẩm chưa cần;
• dễ kiểm tra luồng từ đầu đến cuối;
• giữ business rule trong một nguồn thống nhất;
• vẫn có thể tách thành các dịch vụ riêng trong tương lai nếu có nhu cầu vận hành thực tế.

Các nhóm chức năng chính gồm:

• quản lý topology và thông tin bãi xe;
• quản lý trạng thái ô;
• kiểm tra điều kiện sử dụng ô;
• chấm điểm ứng viên;
• giữ chỗ;
• tìm đường;
• phân tích nhu cầu;
• điều phối workflow;
• API và realtime;
• audit;
• simulator;
• Driver App;
• BQL Operations Console;
• Facility Knowledge và M21.

---

5. Luồng điều phối cốt lõi

Một yêu cầu tìm chỗ đi qua các bước sau:

1. Nhận thông tin xe và nhu cầu của tài xế.
2. Chuyển preset hoặc tiếng Việt tự nhiên thành dữ liệu có cấu trúc.
3. Đọc trạng thái hiện tại của các ô.
4. Loại các ô vi phạm điều kiện bắt buộc.
5. Chấm điểm những ô còn hợp lệ.
6. Trả về tối đa ba ứng viên tốt nhất.
7. Yêu cầu con người xác nhận khi có điều kiện mơ hồ hoặc cần phê duyệt.
8. Giữ nguyên tử ứng viên được chọn hoặc ứng viên khả dụng đầu tiên.
9. Tính đường đi tới ô đã giữ.
10. Trả kết quả cùng reason code và score breakdown.
11. Ghi lại allocation decision và audit entry.
12. Đồng bộ hành trình đã xác nhận sang simulator.

Trong đó, “giữ nguyên tử” có nghĩa là việc kiểm tra và giữ ô được thực hiện như một thao tác không thể bị chen ngang. Nếu hai xe cùng yêu cầu một ô, chỉ một xe được giữ thành công.

---

6. Vai trò của LangGraph

LangGraph được sử dụng như một máy điều phối trạng thái:

intent
  → eligibility
  → allocation
  → approval
  → reservation
  → routing

LangGraph không tự chọn ô và không tự quyết định business rule.

Mỗi bước được giao cho module chuyên trách:

Bước	Thành phần quyết định
Hiểu nhu cầu	M09 Intent Parser
Kiểm tra điều kiện	M05 Eligibility Engine
Xếp hạng	M06 Allocation Engine
Kiểm tra phê duyệt	Approval Policy và M14
Giữ chỗ	M07 Reservation Engine
Tìm đường	M08 Routing Engine

Workflow có thể dừng ở trạng thái chờ phê duyệt. Hệ thống không giữ ô nhạy cảm trước khi yêu cầu được xác nhận theo policy.

---

7. AI có kiểm soát

7.1. AI được sử dụng để làm gì?

AI được sử dụng ở lớp giao tiếp để:

• hiểu nhu cầu tiếng Việt;
• phân loại ý định;
• trích xuất yêu cầu sạc điện;
• trích xuất mức pin;
• nhận biết yêu cầu cần làm rõ;
• phân loại câu hỏi về bãi xe;
• diễn đạt kết quả theo cách tự nhiên hơn.

7.2. AI không được làm gì?

AI không được:

• tự chọn ô đỗ;
• tự tạo mã ô;
• tự thay đổi trạng thái ô;
• tự giữ hoặc nhả chỗ;
• tự xác minh quyền sử dụng ô ưu tiên;
• tự tạo giá, giờ mở cửa hoặc chính sách;
• tự thực hiện lệnh vận hành khi người dùng chưa xác nhận.

Việc chọn ô, giữ chỗ, dẫn đường và cập nhật trạng thái vẫn do backend và các engine tất định thực hiện.

7.3. Kiểm soát dữ liệu AI trả về

Kết quả từ model được giới hạn bằng:

• JSON Schema;
• enum đóng;
• danh sách trường được phép;
• version của contract;
• reason code;
• grounding guard.

Grounding guard kiểm tra:

• mã ô, mã khu và mã tầng;
• các con số trong câu trả lời;
• một số phát biểu boolean được hỗ trợ, ví dụ:
  • chỗ giữ còn hay hết hiệu lực;
  • tài xế đã hay chưa được cấp ô;
  • dữ liệu còn mới hay đã stale.

Nếu model thêm mã hoặc số liệu không có nguồn, hoặc diễn đạt trái với fact đã nhận, toàn bộ bản diễn đạt của model bị loại. Hệ thống quay lại câu trả lời template tất định.

Khi không có fact đã được phê duyệt, hệ thống phải trả trạng thái không đủ dữ liệu thay vì tự suy đoán.

7.4. Khi AI không hoạt động

Khi LLM bị tắt, timeout hoặc không có kết nối Internet:

• preset vẫn hoạt động;
• bộ luật tiếng Việt vẫn phân tích các nhu cầu được hỗ trợ;
• regex và keyword matching vẫn hoạt động;
• eligibility vẫn lọc ô;
• allocation vẫn xếp hạng;
• reservation vẫn giữ chỗ;
• routing vẫn tạo đường đi.

Nhờ đó, AI không nằm trên đường găng của luồng điều phối.

---

8. Kiểm tra điều kiện của ô đỗ

Trước khi chấm điểm, hệ thống loại những ô không đáp ứng điều kiện bắt buộc.

Các điều kiện hiện có gồm:

• ô không ở trạng thái được phép cấp;
• trạng thái cảm biến đã stale;
• xe không thuộc loại có khả năng cắm sạc nhưng được xét vào ô EV;
• xe không thuộc nhóm kích thước được phép của loại ô;
• tài xế thiếu quyền sử dụng ô accessibility;
• ô nằm ngoài khu vực booking;
• booking EV đã ghim một ô khác;
• tài xế khai báo bắt buộc sạc nhưng ô không có trụ sạc.

Mỗi vi phạm đều có reason code. Nếu một ô vi phạm nhiều điều kiện, hệ thống có thể ghi nhận đầy đủ nhiều lý do thay vì chỉ giữ lý do đầu tiên.

Giới hạn hiện tại: rule kích thước mới được triển khai rõ nhất cho ô xe máy và xe cỡ S; hệ thống chưa có mô hình hình học đầy đủ cho mọi loại xe lớn.

---

9. Xếp hạng ứng viên

Các ô vượt qua eligibility được chấm điểm theo công thức:

total_score = Σ(weight_i × normalized_score_i)

Các điểm thành phần nằm trong khoảng từ 0 đến 1.

9.1. Các chiều điểm

Chiều điểm	Ý nghĩa
distance	Ưu tiên thời gian di chuyển tới ô; nếu không có thời gian thì dùng khoảng cách lái xe
congestion	Ưu tiên khu vực hoặc làn ít ùn tắc
preference	Mức phù hợp với loại xe, pin, loại sạc, urgency và độ tin cậy trạng thái
fairness	Tín hiệu hỗ trợ phân bổ công bằng
poi	Khoảng cách thẳng tới loại điểm tiện ích được policy chọn
corner	Mức độ gần biên hoặc góc của khu vực
isolation	Mức độ tách khỏi các luồng giao thông chính

9.2. Trọng số hiện tại

Baseline Sprint 1 sử dụng:

distance   = 0.40
congestion = 0.30
preference = 0.20
fairness   = 0.10
poi        = 0.00
corner     = 0.00
isolation  = 0.00

Policy spatial hiện hành sử dụng:

distance   = 0.384
congestion = 0.288
preference = 0.192
fairness   = 0.096
poi        = 0.000
corner     = 0.020
isolation  = 0.020

Congestion và fairness hiện chủ yếu dùng giá trị trung lập do chưa có dữ liệu vận hành thật đầy đủ nối vào ranking.

9.3. Top-3 và tính ổn định

Hệ thống trả tối đa ba ứng viên tốt nhất.

Nếu hai ô có cùng tổng điểm, mã ô tăng dần được dùng làm tiêu chí phụ. Vì vậy, cùng một dữ liệu đầu vào và cùng một policy sẽ cho cùng một thứ tự kết quả.

9.4. Giới hạn của preference vị trí

Topology đã có dữ liệu về:

• thang máy;
• cầu thang;
• lối vào;
• lối ra.

M21 cũng có thể đọc dữ liệu này để trả lời câu hỏi về các vị trí gần tiện ích.

Tuy nhiên, trong Driver allocation hiện tại:

• near_elevator chưa tác động trực tiếp vào ranking;
• near_exit chưa tác động trực tiếp vào ranking;
• trọng số poi vẫn bằng 0.

Driver App phải hiển thị giới hạn này trung thực, không được tuyên bố rằng hệ thống đã chọn ô gần thang máy nếu preference đó chưa tác động tới kết quả.

---

10. Topology và dẫn đường

10.1. Dijkstra

Dijkstra được dùng để tìm đường theo chi phí thời gian traversal_seconds.

Nếu một cạnh không khai báo thời gian riêng, hệ thống suy ra thời gian từ:

• chiều dài cạnh;
• tốc độ mặc định của làn.

Điều này giúp dốc hoặc đoạn di chuyển chậm có chi phí cao hơn một đoạn đường phẳng cùng chiều dài.

Khoảng cách hiển thị cho tài xế vẫn là mét thật, không bị tăng giả để biểu diễn độ khó.

10.2. A* cho đường ra

Đối với đường ra, hệ thống có thể dùng A* với heuristic free-flow đã tính trước.

Heuristic được tạo bằng reverse multi-source Dijkstra từ các cổng ra. Vì chi phí ùn tắc chỉ làm đường đắt hơn, heuristic free-flow không vượt quá chi phí thật và vẫn bảo toàn tính tối ưu.

10.3. Hình học và tín hiệu không gian

Hệ thống sử dụng:

• Delaunay triangulation và alpha shape để xác định biên lõm của khu vực;
• betweenness centrality để xác định các node nằm trên nhiều luồng chính;
• KD-tree và k-nearest neighbors để đo khoảng cách tới các ô lân cận;
• khoảng cách tới vật cản để điều chỉnh corner score;
• cross product, dot product và atan2 để phân loại đi thẳng, rẽ trái hoặc rẽ phải;
• thay đổi floor_id để phân biệt lên dốc và xuống dốc.

Các phép tính hình học này chủ yếu được thực hiện khi nạp topology và xây dựng slot hints, không phải chạy lại toàn bộ trong mỗi request allocation.

10.4. Giới hạn topology hiện tại

Các topology hiện tại chủ yếu có một đường duy nhất từ cổng tới từng ô.

Vì vậy:

• Dijkstra và A* vẫn tính đúng chi phí;
• hướng dẫn vẫn được tạo đúng;
• hệ thống chưa chứng minh đầy đủ khả năng lựa chọn giữa nhiều tuyến thay thế trong cùng một bãi.

Để đánh giá khả năng tránh ùn tắc hoặc chọn đường khác, topology tương lai cần có vòng giao thông hoặc nhiều đường hợp lệ dẫn tới cùng một khu vực.

---

11. Các cơ chế an toàn đã có

V-Valet hiện đã có các nền tảng sau:

11.1. Chống cấp trùng

Việc giữ ô được thực hiện nguyên tử. Hai request đồng thời không thể cùng giữ thành công một ô.

11.2. Chống tạo dữ liệu trùng

Mỗi hành động quan trọng có thể mang idempotency key. Khi cùng một request được gửi lại, hệ thống trả lại kết quả đã có thay vì tạo thêm một quyết định hoặc một chỗ giữ mới.

11.3. Khôi phục workflow

Workflow lưu trạng thái sau các bước quan trọng để có thể:

• tiếp tục sau lỗi;
• thử lại có giới hạn;
• nhận biết quy trình đang chờ phê duyệt;
• không lặp vô hạn;
• lưu lại lý do recovery.

11.4. Nhật ký không thể sửa ngược

Audit là append-only: sự kiện mới được ghi thêm, không âm thầm sửa lịch sử cũ.

Audit lưu các thông tin như:

• người thực hiện;
• hành động;
• thời gian;
• reason code;
• policy version;
• correlation ID;
• đối tượng bị tác động.

11.5. Quản lý phiên bản quy định

Mỗi quyết định gắn với một policy version cụ thể. Khi quy định mới được phát hành, quyết định cũ vẫn có thể được giải thích theo đúng phiên bản đã sử dụng lúc đó.

11.6. Phân quyền và quyền sở hữu phiên

Hệ thống đã có:

• phân quyền theo vai trò;
• access token và refresh token;
• giới hạn hành động theo Driver, Operator, Admin hoặc System;
• owner guard;
• che giấu session của người khác bằng phản hồi an toàn;
• đảm bảo tài xế chỉ đọc hoặc thay đổi phiên của chính mình.

---

12. Phiên bản demo hiện chứng minh được gì?

Phiên bản demo hiện nhằm chứng minh:

• Driver App và simulator Godot có thể phối hợp trong một journey;
• nhu cầu tiếng Việt có thể được chuẩn hóa;
• backend lọc và xếp hạng ứng viên;
• hệ thống giữ chỗ mà không cấp trùng;
• barrier và chuyển động xe có thể được điều khiển qua bridge;
• trạng thái xe có thể đi từ chờ, dẫn đường đến PARKED;
• BQL có thể tạo và kiểm tra nhiều kịch bản trong Scenario Lab;
• reason code, policy version và audit có thể được truy vết;
• luồng chính vẫn chạy khi AI không khả dụng.

Demo chưa phải bằng chứng rằng hệ thống đã sẵn sàng triển khai trong một bãi xe thực tế.

---

13. Những phần còn thiếu trước khi vận hành thực tế

13.1. Danh tính và tài khoản

Cần hoàn thiện:

• lưu danh tính ổn định trên nhiều server;
• lưu bền vững quan hệ phiên thuộc về ai;
• hỗ trợ nhiều thiết bị;
• khôi phục tài khoản;
• xử lý mất thiết bị;
• xử lý liên kết hoặc hợp nhất tài khoản;
• khắc phục các race condition còn lại trong refresh token.

13.2. Thiết bị và cảm biến thật

Cần kết nối:

• camera nhận diện biển số;
• barrier thật;
• cảm biến trạng thái ô;
• thiết bị đo lưu lượng;
• heartbeat và health của thiết bị;
• cơ chế xử lý dữ liệu sai hoặc mất tín hiệu.

13.3. Lưu trữ bền vững

Một số dữ liệu đã có adapter PostgreSQL hoặc Redis, nhưng chưa phải toàn bộ critical state đều có khả năng:

• sống qua restart;
• dùng chung giữa nhiều worker;
• khôi phục sau lỗi;
• backup và restore;
• migrate an toàn giữa các phiên bản.

13.4. Bảo mật MQTT

MQTT production cần:

• mã hóa TLS;
• xác thực thiết bị;
• ACL theo topic;
• chứng chỉ riêng cho từng nhóm thiết bị;
• thu hồi thiết bị bị lộ thông tin;
• không mở broker trực tiếp ra Internet.

13.5. Quản lý bí mật

API key, mật khẩu và chứng chỉ cần được:

• lưu trong secret manager;
• không ghi trực tiếp vào code hoặc Docker Compose;
• thay định kỳ;
• thu hồi khi nghi ngờ bị lộ;
• giới hạn quyền theo từng dịch vụ.

13.6. Bảo vệ dịch vụ

Cần bổ sung:

• giới hạn số lượng request;
• chống spam;
• chống brute force;
• timeout;
• circuit breaker;
• quota cho các API gọi AI;
• kiểm soát chi phí model.

13.7. Theo dõi vận hành

Cần có:

• dashboard sức khỏe hệ thống;
• metrics cho API, database, MQTT và sensor;
• mục tiêu vận hành SLO;
• cảnh báo khi hệ thống chậm hoặc lỗi;
• theo dõi dung lượng;
• theo dõi độ trễ;
• cảnh báo dữ liệu stale;
• cảnh báo lượng lỗi tăng bất thường.

13.8. Sao lưu và khôi phục

Cần chứng minh:

• dữ liệu được backup;
• bản backup có thể restore;
• phiên bản mới có thể rollback;
• rollback không làm mất hoặc sai dữ liệu;
• đội vận hành đã diễn tập quy trình phục hồi.

---

14. Kết luận

V-Valet hiện đã chứng minh được kiến trúc và luồng điều phối cốt lõi của một hệ thống bãi đỗ xe thông minh.

Điểm mạnh chính của hệ thống là:

• lõi quyết định tất định;
• AI được giới hạn ở đúng vai trò;
• giữ chỗ chống cấp trùng;
• kết quả có thể giải thích;
• quyết định có reason code và policy version;
• hành động có audit;
• luồng chính vẫn hoạt động khi AI không khả dụng;
• Driver và BQL có hai môi trường mô phỏng phù hợp với từng actor.

Những công việc còn lại không chỉ là bổ sung giao diện. Chúng tập trung vào việc biến một hệ thống đã chạy được trong môi trường demo thành một sản phẩm có thể vận hành ổn định, an toàn và lâu dài trong bãi xe thực tế.