Hệ thống quản lý điểm sạc: Danh sách kiểm tra thử nghiệm thí điểm thực tế

Hệ thống quản lý điểm sạc có thể trông rất thuyết phục trong buổi trình diễn bán hàng nhưng vẫn có thể gây ra những vấn đề tốn kém sau khi triển khai. Bộ sạc được kết nối, bảng điều khiển chuyển sang màu xanh lá cây và phiên thử nghiệm kết thúc. Tuy nhiên, không có điều nào trong số đó cho bạn biết liệu nền tảng có thể khôi phục phiên sau khi mất kết nối, giải thích hóa đơn bị tranh chấp hay cung cấp dữ liệu hữu ích cho nhóm của bạn khi hợp đồng kết thúc hay không.

Hướng dẫn này biến việc đánh giá phần mềm thành một dự án thí điểm thực tế. Nó được viết dành cho các nhà điều hành điểm sạc, nhà sản xuất bộ sạc và các đội quản lý đội xe đang so sánh các nền tảng CPMS. Thay vì một danh sách tính năng khác, nó giải thích những gì cần kiểm tra, bằng chứng nào cần lưu giữ và cách đưa ra quyết định triển khai có cơ sở. Các kịch bản dưới đây là các bài kiểm tra chấp nhận được khuyến nghị, không phải là kết quả từ việc triển khai của khách hàng TrendPower.

Hệ thống quản lý điểm sạc điện thí điểm cần chứng minh điều gì?

Một dự án thí điểm hữu ích sẽ chứng minh rằng sự kết hợp cụ thể giữa bộ sạc, phần mềm, khả năng kết nối, thanh toán và quy trình vận hành của bạn hoạt động hiệu quả cùng nhau. Dự án này cần trả lời ba câu hỏi: tài xế có thể sạc thành công không, người vận hành có thể xử lý các sự cố không, và bộ phận tài chính có thể đối chiếu số tiền và hồ sơ thu được không?

Hãy bắt đầu với mô hình hoạt động của bạn. Một mạng lưới công cộng cần có giá cả rõ ràng, phương thức thanh toán dễ tiếp cận và hệ thống quyết toán đáng tin cậy. Một kho bãi ưu tiên sự sẵn sàng khởi hành và năng lực của địa điểm. Một nhà sản xuất có thể cần sự phân tách giữa các khách thuê và quy trình tiếp nhận khách hàng lặp lại. Hãy giao trách nhiệm cho từng yêu cầu và đưa ra kết quả có thể quan sát được trước khi mời các nhà cung cấp trình diễn.

Viết các tiêu chí chấp nhận trước khi trình diễn.

Thay thế cụm từ “hỗ trợ lập hóa đơn” bằng một câu khẳng định có thể kiểm chứng được: hệ thống phải tạo ra một bản ghi chi tiết cho một phiên giao dịch vượt qua ranh giới biểu phí, với đơn vị tiền tệ, dấu thời gian và quy tắc làm tròn áp dụng. Thay thế cụm từ “có API” bằng: nhóm tích hợp của chúng tôi có thể truy xuất một phiên giao dịch đã hoàn tất và đối chiếu mã định danh của nó với dữ liệu xuất hóa đơn.

Không nên áp đặt một tỷ lệ thành công chung tùy ý. Hãy thống nhất các ngưỡng phù hợp với dịch vụ, quy mô mẫu và rủi ro thương mại của bạn. Ghi lại mọi lần thử nghiệm, kể cả những lần thất bại. Một dự án thí điểm chỉ bao gồm các minh họa thành công sẽ không thể hiện được cách nền tảng hoạt động trong thực tế.

1. Xây dựng ma trận bộ sạc và phần mềm đại diện.

Liệt kê mọi mẫu sản phẩm dự kiến ra mắt, phiên bản firmware, phiên bản giao thức, cấu hình đầu nối và phương thức kết nối. Bao gồm cả thiết bị bạn đã sở hữu, không chỉ bộ sạc mẫu do nhà cung cấp đề xuất. Nếu số lượng thiết bị lớn, hãy chọn một mẫu đại diện và ghi lại những thiết bị chưa được kiểm tra.

Việc hỗ trợ giao thức riêng biệt tách khỏi khả năng tương thích đã được kiểm tra.

OCPP định nghĩa sự giao tiếp giữa các trạm sạc và hệ thống quản lý. Tiêu chuẩn này không làm cho mọi sự kết hợp sản phẩm đều giống hệt nhau. Liên minh Open Charge Alliance điều hành một chương trình chứng nhận để kiểm tra sự phù hợp; người mua vẫn nên xác minh sản phẩm, phiên bản và phạm vi chứng nhận có liên quan và kiểm tra sự kết hợp phần cứng dự định sử dụng.

Hãy yêu cầu nhà cung cấp hiển thị kết nối, ủy quyền, bắt đầu và kết thúc phiên, thay đổi trạng thái, báo cáo công tơ và các lệnh điều khiển từ xa được hỗ trợ trên ma trận của bạn. Một lệnh điều khiển từ xa “được chấp nhận” không giống với việc xe nhận được năng lượng. Hãy giữ lại cả phản hồi lệnh và bằng chứng phiên tiếp theo.

Đối với mỗi hành vi không được hỗ trợ, hãy phân biệt giữa hạn chế của bộ sạc với sự cố phần mềm, khoảng trống nền tảng hoặc lỗi cấu hình. Điều này giúp xác định trách nhiệm và ngăn ngừa cùng một vấn đề tích hợp tái diễn trong quá trình triển khai. Đọc thêm Hướng dẫn chứng nhận OCA khi kiểm tra các tuyên bố của nhà cung cấp.

2. Kiểm tra toàn bộ hành trình của người lái xe

Bắt đầu từ bên ngoài bảng điều khiển. Tìm vị trí sạc khi là người lái xe lần đầu, xác định đúng đầu nối, đọc giá, xác nhận, cắm vào, bắt đầu sạc và kết thúc phiên. Kiểm tra xem mã định danh đầu nối hiển thị có khớp với nhãn thực tế và bản ghi trong hệ thống quản lý hay không.

Bao gồm cả những trường hợp khó chịu.

Hãy thử với thông tin đăng nhập đã hết hạn, giao dịch thanh toán bị từ chối và kết nối không khả dụng giữa lúc chọn và lúc bắt đầu. Xác nhận rằng giao diện giải thích được điều gì đã xảy ra mà không chỉ hiển thị mã chẩn đoán nội bộ làm hướng dẫn duy nhất. Kiểm tra việc nhấn liên tục vào nút bắt đầu: kết quả mong muốn phải là một lần thử thành công, không phải là hoạt động thanh toán trùng lặp hoặc các phiên song song gây nhầm lẫn.

Để truy cập mà không cần ứng dụng, hãy sử dụng một phiên trình duyệt mới và trải nghiệm di động phù hợp. Kiểm tra xem tài xế có nhận được biên lai hay không và liên hệ với bộ phận hỗ trợ. Không sử dụng màn hình xác nhận thành công của trình duyệt làm bằng chứng thanh toán: hãy so sánh trạng thái trạm, nhật ký phiên và số lượng giao hàng đã đo.

Nếu phiên giao dịch thất bại, nhân viên hỗ trợ của chúng tôi cần có đủ thông tin để phân biệt các vấn đề liên quan đến xác thực, thanh toán, liên lạc và phía máy sạc. Hướng dẫn khắc phục sự cố khởi động phiên CPMS Cung cấp một chuỗi chẩn đoán cho cuộc điều tra đó.

3. Kiểm tra xem điều gì xảy ra khi kết nối bị lỗi.

Một kết nối mạng văn phòng ổn định có thể che giấu nhiều điểm yếu trong vận hành. Hãy lên kế hoạch gián đoạn có kiểm soát trên thiết bị thử nghiệm với sự cho phép của chủ sở hữu địa điểm. Tuyệt đối không được ngắt kết nối mạng sản xuất hoặc can thiệp vào phiên làm việc trực tiếp của khách hàng chỉ để tạo ra một trường hợp thử nghiệm.

Quan sát trước, trong và sau khi gián đoạn.

Hãy chạy các trường hợp riêng biệt cho bộ sạc ngoại tuyến trước khi ủy quyền và trường hợp mất kết nối trong phiên hoạt động. Trước tiên, hãy thống nhất hành vi mong muốn với nhà sản xuất bộ sạc. Ủy quyền ngoại tuyến và bộ đệm cục bộ phụ thuộc vào thiết bị, cấu hình và cách triển khai; không nên cho rằng mọi bộ sạc đều hỗ trợ chúng.

Sau khi kết nối lại, hãy so sánh trạng thái trạm cuối cùng, thời gian bắt đầu và kết thúc phiên, giá trị đo và kết quả thanh toán. Kiểm tra các bản ghi bị thiếu, các phiên trùng lặp, trạng thái "tính phí" lỗi thời và các sự kiện bị trì hoãn được trình bày sai thứ tự. Xác nhận rằng dấu thời gian lưu giữ đủ thông tin để diễn giải múi giờ một cách nhất quán.

Hãy hỏi xem bộ phận vận hành xác định phiên làm việc chưa hoàn chỉnh cần xem xét thủ công như thế nào. Một nền tảng hiển thị rõ ràng các trường hợp ngoại lệ sẽ hữu ích hơn một nền tảng âm thầm thay thế bằng chứng thiếu sót bằng một con số hợp lý. Ghi lại các bước khắc phục và người được phép thực hiện chúng.

4. Đối chiếu phiên sạc từ năng lượng sang tiền

Hãy chọn một số ít phiên giao dịch và theo dõi từng phiên, từ bản ghi của người sạc đến khoản phí khách hàng, giao dịch của nhà cung cấp thanh toán và xuất dữ liệu tài chính. Đây là các bản ghi có liên quan, không phải là bằng chứng có thể thay thế cho nhau về cùng một sự kiện. Việc giữ lại ủy quyền, thanh toán được ghi nhận và thanh toán được hoàn tất có thể xảy ra vào những thời điểm khác nhau.

Hãy sử dụng một ví dụ về biểu phí cố tình gây khó hiểu.

Giả sử mức giá điện là 0,40 đơn vị tiền tệ/kWh. Một phiên sử dụng 18,6 kWh có phí năng lượng cơ bản là 7,44 trước khi tính đến bất kỳ thành phần nào khác. Phép tính này chỉ là ví dụ thử nghiệm, không phải là giá bán lẻ khuyến nghị. Hãy cộng thêm thuế thực tế, phí theo thời gian hoặc phí đỗ xe mà doanh nghiệp của bạn áp dụng và kiểm tra lại thứ tự tính toán đã được ghi chép.

Tiếp theo, hãy kiểm tra một phiên giao dịch bao gồm thay đổi giá theo lịch trình, nỗ lực thanh toán hết năng lượng, hoàn tiền một phần và thanh toán thất bại. Kiểm tra độ chính xác của đơn vị tiền tệ, làm tròn, mã định danh hóa đơn và cách xử lý các thay đổi giờ mùa hè (nếu có). Người phụ trách tài chính của bạn cần có khả năng giải thích từng sự khác biệt thay vì chỉ chấp nhận tổng số tiền vì nó trông có vẻ gần đúng.

Đối với dịch vụ roaming, hãy phân biệt thông tin phiên hoạt động trực tiếp với bản ghi chi tiết phí cuối cùng. Thống nhất đối tác nào chịu trách nhiệm về định giá, lập hóa đơn và xử lý tranh chấp. OCPI cung cấp các mô-đun riêng biệt để trao đổi dữ liệu; hãy xem xét lại... Tài liệu chính thức của OCPI Đối với phiên bản và các mô-đun nằm trong phạm vi tích hợp của bạn.

5. Giúp việc sạc thông minh có thể đo lường được.

Lịch trình hiển thị trên màn hình không chứng minh được rằng địa điểm đó tuân thủ các giới hạn vận hành cho phép. Cần xác định điểm đo công suất, liệu giới hạn đó chỉ áp dụng cho thiết bị sạc hay toàn bộ cơ sở, và cách tính toán các tải không liên quan đến sạc.

Hãy kiểm tra một trang web đang thay đổi, chứ không phải một giới hạn cố định.

Trên thiết bị kiểm thử được ủy quyền, hãy kết nối thêm nhiều phương tiện, thay đổi mức độ ưu tiên của chúng và đưa ra một thay đổi tiêu biểu về nhu cầu của tòa nhà. So sánh hồ sơ yêu cầu với hành vi đo được. Cho phép thời gian phản hồi đã thỏa thuận và các giới hạn của thiết bị, đồng thời ghi lại cách hệ thống hoạt động khi đồng hồ đo hoặc liên kết truyền thông không khả dụng.

Đối với một đội xe, hãy thêm thời gian khởi hành và năng lượng cần thiết. Một kế hoạch tuân thủ giới hạn của địa điểm nhưng lại để các phương tiện quan trọng không sẵn sàng hoạt động vẫn có thể không đáp ứng được yêu cầu kinh doanh của bạn. Hãy xác định cách người vận hành nhìn nhận nhu cầu không khả thi và thay đổi thứ tự ưu tiên. Bảo vệ điện tại địa điểm vẫn là trách nhiệm của kỹ sư; quản lý tải bằng phần mềm không nên được coi là sự thay thế cho hệ thống bảo vệ được thiết kế phù hợp.

6. Cung cấp cho nhân viên hỗ trợ một tình huống thực tế.

Hãy yêu cầu một người không cấu hình hệ thống điều khiển thử nghiệm điều tra lỗi khởi động hoặc trạng thái kết nối bị lỗi bằng vai trò hỗ trợ được chỉ định của họ. Liệu họ có thể xác định đúng bộ sạc, kiểm tra dòng thời gian, xác định lần giao tiếp thành công gần nhất và đưa ra hành động tiếp theo rõ ràng không?

Hãy đo lường hiệu quả các bước điều tra thay vì chạy theo một mốc thời gian giải quyết chung. Kiểm tra xem các hành động thiết yếu có yêu cầu mở nhiều hệ thống hoặc yêu cầu nhà phát triển tìm kiếm nhật ký thô hay không. Xác nhận rằng việc thiết lập lại từ xa và thay đổi cấu hình có quyền hạn phù hợp và ghi lại người thực hiện chúng.

Xác định rõ trách nhiệm giải quyết sự cố trước khi triển khai. Nhà điều hành, nhà cung cấp phần mềm, nhà sản xuất thiết bị và nhà cung cấp dịch vụ thanh toán cần biết bằng chứng nào đi kèm với yêu cầu hỗ trợ. Nếu không, một vấn đề kỹ thuật nhỏ có thể vẫn chưa được giải quyết trong khi mỗi bên lại yêu cầu một nhóm khác điều tra.

7. Kiểm tra phạm vi truy cập và khả năng di chuyển dữ liệu

Hãy tạo ra các vai trò mà tổ chức của bạn thực sự cần: nhân viên hỗ trợ, người dùng tài chính, chủ sở hữu trang web và quản trị viên mạng. Kiểm tra xem mỗi vai trò có thể hoàn thành các nhiệm vụ được yêu cầu mà vẫn không thể truy cập vào các tài khoản người dùng khác hoặc các cài đặt nhạy cảm. Tránh sử dụng tài khoản quản trị viên dùng chung cho toàn bộ chương trình thử nghiệm.

Yêu cầu xuất dữ liệu mà bạn có thể sử dụng mà không cần thông qua nhà cung cấp.

Xuất các mã định danh bộ sạc, bản đồ vị trí, bản ghi phiên, tham chiếu biểu giá và các mã định danh tài chính liên quan. Kiểm tra định dạng thời gian, đơn vị, định nghĩa trường và mối quan hệ giữa chúng. Một bảng tính chỉ chứa tổng số mà không có mã định danh ổn định có thể không đủ để đối chiếu hoặc chuyển đổi dữ liệu.

Hãy hỏi xem dữ liệu nào thuộc về tổ chức của bạn, những dữ liệu nào được phép xuất, điều gì xảy ra khi hợp đồng kết thúc và cách thức lưu trữ và xóa dữ liệu được thực hiện như thế nào. Đánh giá lại các yêu cầu này với nhóm bảo mật và pháp lý của riêng bạn khi cần thiết. Đối với những thay đổi nền tảng trong tương lai, chúng tôi sẽ... Hướng dẫn di chuyển CPMS Giải thích lý do tại sao việc lập bản đồ tài sản và duy trì tính liên tục của hồ sơ lại quan trọng.

Một bản ghi nghiệm thu nhỏ gọn mà nhóm của bạn có thể tái sử dụng.

Sử dụng một dòng cho mỗi kịch bản. Giữ cho phần mô tả đủ cụ thể để người thứ hai có thể lặp lại. Một bản ghi thực tế bao gồm yêu cầu, thiết bị và phần mềm, các bước kiểm thử, kết quả mong đợi, kết quả quan sát được, bằng chứng hỗ trợ, người chịu trách nhiệm và trạng thái kiểm thử lại.

• Sự liên quan: Bộ sạc và phần mềm được đặt tên sẽ kết nối và báo cáo trạng thái mong đợi.
• Hành trình của tài xế: Việc ủy quyền dẫn đến việc xác nhận tính phí và một bản ghi cuối cùng nhất quán.
• Sự hồi phục: Việc gián đoạn kết nối không gây ra hiện tượng thiếu hoặc trùng lặp hồ sơ thanh toán không rõ nguyên nhân.
• Tài chính: Thông tin về phiên làm việc, hóa đơn và thanh toán khớp với các trường hợp ngoại lệ đã được ghi nhận.
• Hoạt động: Bộ phận hỗ trợ có thể chẩn đoán sự cố nếu có đủ quyền hạn.
• Ra: Dữ liệu xuất ra vẫn có thể hiểu được ngay cả khi không sử dụng giao diện của nhà cung cấp.

Sử dụng các kết quả "đạt", "không đạt" và "bị chặn" riêng biệt. "Bị chặn vì phần mềm cần thiết không khả dụng" không phải là kết quả đạt. Ghi nhận các hạn chế trong quyết định mua sắm và ấn định thời hạn để giải quyết các vấn đề quan trọng trước khi ra mắt sản phẩm. Giữ các cải tiến nhỏ về khả năng sử dụng trong một danh sách công việc tồn đọng riêng biệt để chúng không che giấu các lỗi thanh toán hoặc tính phí chưa được giải quyết.

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

CPMS có giống với OCPP không?

Không. Hệ thống quản lý điểm sạc là một nền tảng phần mềm vận hành. OCPP là một giao thức truyền thông được sử dụng giữa các trạm sạc và hệ thống quản lý. Bạn vẫn cần đánh giá quy trình làm việc, thanh toán, báo cáo, quyền hạn và sự tích hợp thực tế của bộ sạc.

Chương trình thí điểm CPMS nên kéo dài bao lâu?

Hãy sử dụng việc hoàn thành các kịch bản đã được thống nhất làm tiêu chí quyết định thay vì một số ngày cố định. Cần dành thời gian cho các mức phí khác nhau, xử lý ngoại lệ và kiểm tra lại. Một bản demo ngắn có thể thiết lập kết nối cơ bản; tuy nhiên, nó không thể thay thế cho việc thử nghiệm mô hình hoạt động của bạn.

Liệu mọi nhà mạng có cần tính năng roaming trong chương trình thí điểm không?

Không. Hãy đưa nó vào khi việc chuyển vùng là một phần trong phạm vi triển khai hoặc là điều kiện ràng buộc theo hợp đồng. Nếu việc này được lên kế hoạch cho sau này, hãy ghi lại các mô-đun cần thiết, trách nhiệm của đối tác và các bài kiểm tra chấp nhận trong tương lai mà không coi khả năng chưa được kiểm thử là đã được chứng minh.

Điều gì có thể ngăn cản việc triển khai chính thức?

Các lỗi chưa được giải quyết khiến tài xế được ủy quyền không thể tính phí, tạo ra sự khác biệt về hóa đơn không rõ nguyên nhân, làm lộ thông tin của người dùng khác hoặc ngăn cản việc khôi phục hoạt động thiết yếu cần phải dẫn đến một quyết định được ghi lại trước khi triển khai. Mức độ nghiêm trọng phụ thuộc vào dịch vụ và các biện pháp kiểm soát của bạn, chứ không phải vẻ ngoài bắt mắt của bảng điều khiển.

Biến các yêu cầu của bạn thành một cuộc thảo luận hữu ích trên nền tảng.

Câu hỏi quan trọng nhất khi mua hàng không phải là “Nền tảng này có bao nhiêu tính năng?” mà là “Nhóm của chúng tôi có thể chạy các kịch bản này trên thiết bị của mình và giải thích kết quả không?” Hãy chuẩn bị sẵn bảng so sánh bộ sạc, quốc gia hoạt động, yêu cầu thanh toán, hạn chế của địa điểm và danh sách tích hợp trong cuộc thảo luận.

Khám phá TrendPower's Hệ thống quản lý điểm sạc xe điện hoặc yêu cầu thảo luận trên nền tảng Hãy xác nhận phạm vi dự án thí điểm của bạn. Xác nhận các yêu cầu về khả năng tương thích và triển khai cho dự án trước khi tiến hành triển khai thực tế.