Pengisi daya muncul secara online di dasbor. Kendaraan uji mulai mengisi daya. Semua orang siap untuk menyatakan proyek selesai. Kemudian pelanggan pertama membayar dua kali, manajer lokasi melihat pendapatan operator lain, atau sesi menghilang setelah kegagalan koneksi. Inilah masalah yang terlewatkan oleh pemeriksaan konektivitas sederhana.
Pengujian penerimaan perangkat lunak pengisian daya EV memeriksa apakah pengisi daya, pengaturan pembayaran, dan aturan pengoperasian Anda benar-benar berfungsi bersama sebelum pelanggan bergantung padanya. Hal ini memberikan operator dan pemasok definisi bersama tentang "siap", yang didukung oleh catatan yang dapat diperiksa kemudian.
Jawaban singkat: Rencana penerimaan yang bermanfaat menguji seluruh proses: koneksi pengisi daya, akses pengemudi, pengiriman energi, penyelesaian sesi, perhitungan biaya, penanganan pembayaran, pelaporan, dan pemulihan operasional. Jalankan rencana ini terhadap setiap kombinasi model pengisi daya dan firmware yang telah disepakati. Inspeksi kelistrikan dan pengujian keselamatan tetap menjadi alur kerja terpisah yang ditangani oleh personel yang berkualifikasi.

1. Tentukan cakupan pengujian sebelum menghubungkan pengisi daya.
Mulailah dengan proses bisnis, bukan daftar fitur. Lokasi pengisian daya publik membutuhkan rencana penerimaan yang berbeda dari depot swasta. Tuliskan siapa yang dapat mengisi daya, bagaimana mereka mengidentifikasi diri, siapa yang membayar, tarif mana yang berlaku, dan siapa yang bertanggung jawab jika terjadi kegagalan. Buat setiap persyaratan dapat diamati.
Buat matriks peralatan yang berisi pabrikan, model, firmware, pengenal konektor, metode komunikasi, dan versi protokol yang didukung. Dua pengisi daya dari merek yang sama dapat berperilaku berbeda setelah perubahan firmware. Perlakukan konfigurasi yang berbeda secara signifikan sebagai kasus uji terpisah, alih-alih menganggap bahwa satu sesi yang berhasil mencakup seluruh jaringan.
Tetapkan pemilik untuk setiap pengujian. Operator harus menyetujui hasil bisnis, sementara penyedia perangkat lunak, produsen pengisi daya, integrator pembayaran, dan penginstal memberikan bukti untuk bagian masing-masing. Catat ketergantungan sejak dini agar akun pedagang yang hilang tidak terlihat seperti cacat platform.
2. Verifikasi integrasi pengisi daya di luar indikator online.
Pemeriksaan pertama harus mencakup identitas dan status. Pastikan pengisi daya, lokasi, dan konektor yang benar muncul di platform. Bandingkan label fisik dengan dasbor dan antarmuka pengemudi. Pengemudi yang memindai konektor dua tidak boleh secara tidak sengaja mengaktifkan konektor satu.
Uji pendaftaran boot, perubahan status, pelaporan meteran, dan penyelesaian transaksi. Kemudian uji perintah yang tercantum dalam kontrak Anda, seperti start jarak jauh, stop jarak jauh, dan pengambilan diagnostik. Perintah yang ditandai "diterima" hanyalah salah satu bukti; verifikasi bahwa hasil fisik yang diinginkan benar-benar terjadi.
Itu Open Charge Alliance menjelaskan bahwa OCPP 1.6 dan 2.0.1 tidak kompatibel.Sebuah platform yang melayani kedua kebutuhan tersebut memerlukan implementasi yang tepat dan validasi tingkat pengisi daya. Tanyakan fungsi mana yang telah diuji pada peralatan Anda secara spesifik, daripada menerima pernyataan kompatibilitas yang luas.
Untuk informasi latar belakang mengenai ruang lingkup integrasi, silakan tinjau. Panduan dukungan OCPP yang diterbitkan oleh TRENDPOWERSimpan matriks model dan firmware yang telah disepakati yang dilampirkan pada catatan penerimaan.
3. Akses uji dan perjalanan pengemudi secara lengkap
Lakukan proses ini dari sudut pandang pengemudi baru, bukan sebagai administrator yang sudah tahu letak setiap tombol. Temukan situsnya, identifikasi konektornya, baca harganya, otentikasi, mulai penagihan, dan dapatkan catatan akhir. Periksa pengalaman seluler pada perangkat dan peramban yang benar-benar digunakan audiens Anda.
Sertakan kredensial yang valid dan tidak valid, akses yang kedaluwarsa, konektor yang sudah digunakan, dan permintaan mulai berulang. Verifikasi bahwa pengemudi yang tidak berwenang menerima penjelasan yang bermanfaat tanpa mengekspos informasi akun. Jika RFID, antarmuka web, atau aplikasi bermerek disertakan, uji setiap rute secara terpisah.
Untuk situs bersama, uji izin dari kedua sisi. Konfirmasikan bahwa pengunjung yang disetujui dapat melakukan pembayaran dan pengunjung yang izinnya telah kedaluwarsa tidak dapat melakukannya. Kemudian konfirmasikan bahwa perubahan akses tidak mengubah catatan riwayat sesi sebelumnya secara retroaktif.
4. Hitung ulang hasil penagihan dan pembayaran secara independen.
Pilih sekelompok kecil sesi dengan input yang diketahui. Gunakan tarif energi saja yang sederhana terlebih dahulu, kemudian uji biaya koneksi, komponen waktu, diskon, atau biaya siaga yang disepakati. Hitung biaya yang diharapkan secara terpisah dan bandingkan dengan catatan platform, tanda terima, dan penyedia pembayaran.
Sertakan kondisi batas: perubahan tarif pada tengah malam, sesi yang mencakup dua periode harga, sesi tanpa energi, dan pembulatan pada unit mata uang terkecil yang didukung. Catat zona waktu yang berlaku dan kebijakan untuk sesi yang sedang berlangsung ketika tarif berubah.
Pengujian pembayaran harus mencakup otorisasi berhasil, otorisasi gagal, kegagalan memulai penagihan, dan pemberitahuan penyedia yang tertunda. Periksa apakah panggilan balik berulang tidak menghasilkan penagihan berulang. Untuk gambaran yang lebih luas tentang pengaturan komersial, gunakan Gambaran umum solusi pembayaran pengisian daya kendaraan listrik beserta persyaratan integrasi dari penyedia layanan Anda.
| Tes | Hasil yang diharapkan | Bukti yang perlu disimpan |
|---|---|---|
| Sesi berbayar yang berhasil | Satu sesi, satu biaya akhir yang tepat. | ID sesi, versi tarif, tanda terima, dan ID pembayaran. |
| Pembayaran disetujui; pengisi daya gagal menyala. | Tidak ada biaya akhir yang tidak didukung; alur kerja pembatalan yang disepakati. | Informasi pengisian daya, status pembayaran, dan pesan pengemudi. |
| Pemberitahuan mulai atau pembayaran berulang | Tidak ada sesi ganda atau tindakan keuangan yang berulang. | ID permintaan, ID acara, dan buku besar akhir. |
| Koneksi jaringan terputus | Pemulihan terdokumentasi tanpa kehilangan atau duplikasi catatan. | Log perangkat dan ekspor sesi yang telah direkonsiliasi |
| Akun staf terbatas | Hanya situs dan tindakan yang diizinkan yang dapat diakses. | Pengaturan peran dan hasil uji akses |
5. Validasi kontrol beban dalam kondisi realistis.
Jika manajemen beban termasuk dalam lingkup pekerjaan, ujilah dengan teknisi lapangan dan instrumentasi yang telah disepakati. Tetapkan batas kendali dengan jelas: kelompok pengisi daya, saluran distribusi, atau seluruh bangunan. Total pada dasbor yang hanya berdasarkan data pengisi daya tidak dapat membuktikan bahwa seluruh bangunan tetap berada dalam batas yang ditentukan.
Gunakan uji terkontrol untuk menambah permintaan pengisian daya dan mengubah beban bangunan yang relevan. Bandingkan batas yang diminta, respons pengisi daya, dan hasil pengukuran. Perhitungkan interval respons dan toleransi pengukuran yang telah didokumentasikan; jangan membuat ambang batas universal yang tidak dapat dipenuhi oleh peralatan.
Uji sistem cadangan yang disepakati ketika meteran lokasi, pengontrol lokal, atau koneksi cloud tidak tersedia. Catat siapa yang menerima peringatan dan bagaimana operasi dilanjutkan. Penjadwalan perangkat lunak mendukung strategi kontrol yang telah dirancang; ini tidak menggantikan proteksi listrik atau desain lokasi yang telah disetujui.
6. Menjalankan skenario kegagalan dan pemulihan
Jaringan produksi membutuhkan perilaku yang dapat diprediksi ketika komponen hilang. Putuskan koneksi internet pengisi daya, mulai ulang aplikasi jika diizinkan, dan simulasikan notifikasi yang terlewatkan di lingkungan yang terkontrol. Periksa tampilan pengemudi, peringatan operator, dan rekonsiliasi yang mungkin terjadi.
Perilaku offline bergantung pada kemampuan dan konfigurasi pengisi daya. Jangan berasumsi bahwa sesi dapat dimulai secara offline hanya karena sesi yang ada berlanjut. Pisahkan kasus-kasus tersebut dan nyatakan secara tepat metode akses dan kontrol lokal mana yang diharapkan berfungsi.
Setelah terhubung kembali, periksa garis waktu untuk celah, duplikat, dan stempel waktu yang salah. Baca yang sudah ada. panduan pengisian daya EV offline Saat mendefinisikan kasus-kasus ini, sertakan bukti pemulihan dalam penyerahan, bukan hanya tangkapan layar pengisi daya yang kembali online.
7. Periksa izin, ekspor, dan serah terima operasional.
Masuk sebagai pengelola situs, agen dukungan, pengguna keuangan, dan administrator. Uji tindakan yang diizinkan dan yang diblokir, termasuk perubahan tarif, pengembalian dana, ekspor, dan perintah jarak jauh jika fungsi tersebut ada. Suatu peran harus memiliki akses yang cukup untuk menjalankan tugasnya tanpa menjadi jalan pintas ke data setiap situs.
Ekspor sesi pengujian dan bandingkan totalnya dengan dasbor. Periksa identitas konektor, stempel waktu, satuan energi, mata uang, kolom pajak jika berlaku, dan status keuangan. Tanyakan bagaimana koreksi ditampilkan dan apakah jejak audit mengidentifikasi orang atau sistem yang bertanggung jawab.
Terakhir, serahkan tugas-tugas rutin kepada orang-orang yang akan mengoperasikan jaringan. Mereka harus tahu cara menyelidiki kegagalan pengoperasian, menghubungi pemasok yang tepat, menemukan referensi pembayaran, dan menjelaskan pembayaran yang tertunda kepada pengemudi. Platform yang secara teknis lengkap pun masih dapat gagal dalam proses serah terima jika langkah-langkah tersebut tetap tidak jelas.
8. Sepakati kriteria rilis dan peluncuran bertahap.
Gunakan kriteria rilis tertulis yang disepakati sebelum pengujian. Misalnya, proyek Anda mungkin mensyaratkan setiap alur kerja kritis harus lolos, semua cacat yang menghambat harus ditutup, dan setiap masalah kecil yang diterima harus memiliki pemilik dan tanggal target. Ini adalah keputusan proyek, bukan skema sertifikasi di seluruh industri.
Mulailah dengan proyek percontohan kecil yang mewakili jaringan yang lebih luas. Sertakan jenis pengisi daya, metode akses, dan alur pembayaran yang memiliki risiko operasional paling tinggi. Perluas hanya setelah meninjau catatan langsung dan memastikan bahwa tim dukungan dapat menangani masalah yang diamati.
Paket penerimaan harus berisi matriks peralatan, kasus uji, hasil, catatan kerusakan, dasar konfigurasi, kontak operasional, dan prosedur pengembalian. Ini menjadi referensi yang berguna ketika pembaruan firmware atau perubahan tarif di kemudian hari menimbulkan perilaku yang tidak terduga.
Pertanyaan yang sering diajukan
Apakah uji koneksi OCPP sudah cukup untuk diterima?
Tidak. Ini hanya mengkonfirmasi sebagian dari sistem. Anda masih perlu memverifikasi perjalanan pengemudi yang disepakati, tarif, hasil pembayaran, izin, laporan, dan prosedur penagihan pada konfigurasi proyek yang sebenarnya.
Apakah setiap pengisi daya harus menjalani pengujian yang sama?
Setiap unit yang terpasang memerlukan pemeriksaan pengoperasian yang telah disepakati. Kedalaman pengujian perangkat lunak berulang dapat mengikuti rencana pengambilan sampel berbasis risiko, tetapi model yang berbeda, versi firmware, dan konfigurasi lokasi yang tidak biasa memerlukan cakupan yang eksplisit.
Siapa yang menyetujui perangkat lunak tersebut?
Operator harus menunjuk seorang penanggung jawab yang berwenang. Pemasok memberikan bukti untuk lingkup pekerjaan mereka sendiri, sementara penerimaan terkait kelistrikan dan keselamatan tetap menjadi tanggung jawab pihak yang berkualifikasi. Jadikan tanggung jawab tersebut sebagai bagian dari perjanjian proyek.
Rencanakan implementasi yang dapat diuji.
Saat membahas sebuah Platform manajemen pengisian daya TRENDPOWERSertakan matriks pengisi daya, tarif, pasar pembayaran, dan alur kerja yang wajib dilewati. Detail ini akan mempermudah penentuan ruang lingkup integrasi dan penerimaan yang praktis. Hubungi TRENDPOWER untuk mendiskusikan kebutuhan proyek Anda. dan mintalah demonstrasi yang dibangun berdasarkan hasil yang perlu diverifikasi oleh tim Anda.

