Câu hỏi thường gặp

Thường liên quan độ trễ đồng bộ trạng thái hoặc "lỗi mềm". OCPP 1.6 dựa StatusNotification báo trạng thái connector; mạng chập chờn hoặc heartbeat đứt thì nền tảng có thể còn hiển thị trạng thái cũ. OCPP 2.0.1 cải thiện nhờ TransactionEvent và giám sát mịn hơn, nhưng nếu trụ phát hiện lỗi (nhấn nút dừng khẩn, lỗi khóa súng) mà chưa kịp báo NotifyEvent, app vẫn có thể hiểu nhầm là khả dụng. Nên thêm gợi ý "thời gian cập nhật trạng thái cuối" ở trang chi tiết.

Độ trễ khởi động thường xảy ra trong chu trình Authorize và StartTransaction (1.6) hoặc TransactionEvent(Started) (2.0.1). Nếu WebSocket heartbeat giữa nền tảng và trụ không ổn định, hoặc tín hiệu trụ yếu, lệnh bị gửi lại. OCPP 1.6 phải đợi nền tảng trả transaction ID mới cấp điện, còn mô hình hướng sự kiện 2.0.1 nhanh hơn về lý thuyết — nhưng firmware xử lý TransactionEvent kém vẫn có thể trễ.

Đây là trường hợp trạng thái lệch nhau điển hình. Trong OCPP 1.6, nếu trụ dừng do quá nhiệt, bảo vệ rò điện hoặc súng bị rút (không gửi StopTransaction đúng cách), nền tảng có thể giữ trạng thái đang sạc vì chưa nhận StatusNotification(Faulted/Available). OCPP 2.0.1 dùng TransactionEvent(Ended) chặt chẽ hơn nhưng cần trụ thực hiện đúng. Nền tảng nên có logic "hết timeout heartbeat thì tự đóng đơn nội bộ" để xử lý.

Plug-and-charge (PnC/ISO 15118) là năng lực gốc của OCPP 2.0.1; OCPP 1.6 không hỗ trợ PnC chuẩn. Nếu nền tảng có trụ cả hai giao thức, app nên hiển thị nhãn năng lực theo phiên bản giao thức và cấu hình thực tế của từng trụ. Nếu trụ 2.0.1 cấu hình certificate chain sai, PnC cũng hỏng — app nên lùi về nhắc "vui lòng quét mã để bắt đầu".

Kiểm tra theo thứ tự Mạng → WebSocket → OCPP: ① trụ có truy cập được địa chỉ wss:// của nền tảng không (DNS, firewall, cổng 443); ② Charge Point Identity khớp URL path (ví dụ /ocpp/CP001 sai hoa thường hoặc hậu tố); ③ OCPP 1.6 xem Heartbeat có bình thường, OCPP 2.0.1 xem Heartbeat sau BootNotification và security event log. Nếu màn hình trụ bình thường nhưng OCPP offline, thường là module OCPP treo hoặc SIM hết lưu lượng.

Phải, nhưng có thể trừu tượng hóa. Thông điệp hai phiên bản không tương thích: 1.6 dùng StartTransaction/StopTransaction, 2.0.1 dùng TransactionEvent; 1.6 cấu hình bằng ChangeConfiguration key-value, 2.0.1 dùng device model SetVariables/GetVariables có cấu trúc. Nên xây mô hình "charging session" hợp nhất trên tầng giao thức, ánh xạ thông điệp hai giao thức vào một business object, tránh phát triển trùng lặp.

OCPP 1.6 RemoteStartTransaction yêu cầu trụ làm local auth (như Authorize) trước; nếu cache whitelist cục bộ hết hạn hoặc cấu hình AuthorizeRemoteTxRequests sai sẽ bị từ chối. OCPP 2.0.1 RequestStartTransaction nghiêm ngặt hơn, cần AvailabilityState của EVSE và Connector là Operative trước. Ngoài ra nếu WebSocket chết giả (TCP thông nhưng tầng ứng dụng không phản hồi), lệnh sẽ timeout — cần TriggerMessage hoặc phát hiện heartbeat timeout để reset kết nối.

OCPP 2.0.1 quản lý firmware an toàn, truy vết được hơn. UpdateFirmware của 1.6 thường là "gửi URL → trụ tải → trụ restart", nền tảng khó biết tiến độ và kết quả kiểm; 2.0.1 PublishFirmware + UpdateFirmware hỗ trợ tải phân khối, kiểm tra bảo mật và báo trạng thái — phù hợp vận hành quy mô lớn. Nếu nền tảng vẫn chủ yếu 1.6, nên thêm bước "xác minh phiên bản qua BootNotification sau nâng cấp".

"Hỗ trợ OCPP 1.6" không đồng nghĩa "plug-and-play". Điểm đứt hay gặp: định dạng WebSocket URL (dấu gạch cuối, hoa thường path, wss hay không), Charge Point Identity lệch, chưa thương lượng subprotocol (ocpp1.6), chứng chỉ TLS trụ không tin (firmware cũ không nhận CA mới). OCPP 2.0.1 còn đòi khớp security profile; nếu nền tảng ép TLS mà trụ chỉ có basic auth thì handshake thất bại ngay.

Không thể tự chuyển. Phiên bản OCPP chốt lúc WebSocket handshake qua subprotocol (như ocpp1.6, ocpp2.0.1); firmware thường chỉ cài một phiên bản. Nền tảng phải route tới protocol handler phù hợp dựa BootNotification hoặc path URL. Một trụ vật lý không thể chuyển từ 1.6 "lên" 2.0.1 khi đang chạy, trừ khi thay firmware và cấu hình lại.

Ở 1.6, nền tảng phải dò khả năng trụ bằng GetConfiguration với đầy ắp vendor key; 2.0.1 device model chuẩn hóa cây EVSE → Connector → Component → Variable, nền tảng đọc/ghi chính xác ví dụ ngưỡng nhiệt độ của từng đầu sạc, trạng thái từng relay. Bước nhảy vọt cho bảo trì mịn và chẩn đoán từ xa, nhưng backend phải tái cấu trúc mô-đun quản lý cấu hình, không giữ kho key-value phẳng kiểu 1.6.

1.6 hỗ trợ SetChargingProfile cơ bản (tĩnh hoặc curve theo thời gian đơn giản) nhưng thiếu phối hợp lưới điện và điều chỉnh động. 2.0.1 đầy đủ hơn: ChargingStationExternalConstraints, gửi trần công suất động, điều phối cụm nhiều trụ, và kết hợp ChargeParameterDiscovery của ISO 15118 được. Nếu trạm cần "orderly charging" hoặc "demand control", trụ 2.0.1 tốt hơn — nhưng engine lập kế hoạch sạc phía nền tảng phải nâng cấp tương ứng.

Chúng tôi có bốn mô hình: nhượng quyền, mua thiết bị, vận hành trạm và giải pháp doanh nghiệp — phủ đại lý, quản lý bất động sản và nhà vận hành fleet. Gửi yêu cầu hợp tácKể cho chúng tôi hiện trường và nhu cầu của bạn, đội kinh doanh sẽ liên hệ trong 24 giờ, kèm ước tính phương án và khảo sát hiện trường; bạn cũng có thể gửi email trực tiếp qua trang "Liên hệ".