Lampu Jalan Tenaga Surya Pintar (LoRa / NB-IoT) - Aturan Pemantauan, Kontrol & Pengadaan

Di Mana Panduan Ini Cocok

TL; DR (Aturan keputusan)

  • Beli hasil, bukan kata kunci: menentukan tujuan O&M (pengurangan waktu henti, visibilitas kesehatan baterai, peringatan pencurian, kontrol peredupan).
  • Pilihan jaringan adalah keputusan bisnis: LoRa sering kali menyiratkan opsi jaringan pribadi/dikelola; NB-IoT sering kali menyiratkan konektivitas yang dikelola operator. Pilih berdasarkan kepemilikan, cakupan, dan biaya operasional jangka panjang.
  • Fitur pintar mengubah anggaran energi: Interval pelaporan dan waktu aktif radio harus disertakan dalam asumsi Wavg/Wh-night.
  • Aturan pengadaan: jika pemasok tidak dapat memberikan paket “titik data + alarm + mode offline + keamanan + SLA” yang jelas, kutipannya adalah Tidak Sebanding / Berisiko Tinggi.

Referensi internal utama (untuk keandalan dan bukti):

Apa yang seharusnya diberikan oleh “pintar” (tentukan kasus penggunaan Anda terlebih dahulu)

Pilihlah fungsi-fungsi yang benar-benar akan Anda gunakan. Jika tidak, Anda membayar untuk dasbor yang tidak akan pernah Anda gunakan.

Kasus penggunaan inti (sebagian besar proyek)

  • Pemantauan kesehatan: tegangan baterai/indikator SOC, status pengisian daya, status pengontrol, bendera kesalahan
  • Visibilitas energi: sinyal pengisian/pengosongan harian dasar untuk mengetahui kekurangan ukuran lebih awal
  • Kontrol peredupan jarak jauh: pembaruan jadwal waktu dan jejak audit perubahan
  • Alur kerja alarm: pemberitahuan pemadaman / pemadaman dini / perilaku abnormal

Kasus penggunaan bernilai tinggi (situs tertentu)

  • Peringatan pencurian/perusakan: di mana risiko pencurian itu nyata dan responsnya dapat dilakukan
  • Inventarisasi aset: pemetaan serial-ke-lokasi dan manajemen siklus hidup
  • Bukti pemeliharaan: log yang mendukung klaim garansi dan pertanggungjawaban vendor

Halaman terkait untuk menstandarkan bukti dan operasi:


LoRa vs NB-IoT - cara memilih (lensa pengadaan)

Jangan memperdebatkan teknologi radio dalam ruang hampa. Putuskan dengan menggunakan kepemilikan, cakupan, biaya operasional, dan kompleksitas penyebaran.

Pilihlah berdasarkan pertanyaan-pertanyaan keputusan berikut ini

  • Siapa yang memiliki jaringan? (tim / integrator / operator Anda)
  • Apa yang terjadi jika cakupannya lemah? (metode survei lokasi dan kriteria penerimaan)
  • Apa yang dimaksud dengan model biaya berulang? (biaya konektivitas, biaya platform, kursi pengguna)
  • Bagaimana Anda akan mendukungnya selama bertahun-tahun? (SLA, pembaruan firmware, penyediaan perangkat)

Aturan pengadaan (praktis)

  • Membutuhkan rencana konektivitasbagaimana perangkat terhubung, bagaimana perangkat disediakan, dan bagaimana pemadaman ditangani.
  • Membutuhkan metode penerimaan situscara Anda memverifikasi cakupan/konektivitas selama uji coba.

Fitur pintar harus disertakan dalam model energi

Perangkat pintar mengkonsumsi energi. Jika Anda mengabaikan hal ini dalam anggaran energi, performa di musim hujan dapat menurun.

Apa yang harus diungkapkan oleh pemasok

  • Interval pelaporan: seberapa sering data dikirim (dan apakah data berubah berdasarkan mode/musim)
  • Perilaku radio: strategi tidur/bangun (pengungkapan tingkat tinggi sudah cukup)
  • Lembar anggaran energi: termasuk konsumsi modul pintar dalam asumsi Wavg / Wh-night

Gunakan halaman ini untuk menjaga kejujuran ukuran:


Minimum “Paket Spesifikasi Cerdas” (yang harus diserahkan oleh setiap peserta lelang)

Jika pemasok tidak dapat mengirimkan paket ini dengan jelas, Anda tidak dapat mengoperasikan atau menegakkan garansi di kemudian hari.

A) Poin data (apa yang dapat Anda lihat)

  • Dukungan pemetaan ID perangkat dan nomor seri
  • Status pencahayaan dan bendera kesalahan dasar
  • Indikator status baterai (minimal: indikator voltase/SOC) dan status pengisian daya
  • Indikator status pengontrol

B) Fungsi kontrol (apa yang dapat Anda ubah)

  • Pembaruan jadwal peredupan waktu (dan konfirmasi pengaturan yang diterapkan)
  • Pengungkapan konfigurasi mode (waktu/PIR/hibrida jika ada)
  • Jejak audit: siapa yang mengubah apa, kapan (persyaratan minimum untuk akuntabilitas)

C) Aturan alarm dan alur kerja (cara Anda bertindak)

  • Peringatan pemadaman/pematian dini (apa yang memicu peringatan)
  • Penanganan kehilangan konektivitas (bagaimana hal ini dilaporkan dan dieskalasi)
  • Pengungkapan metode pengiriman alarm (email/aplikasi/dll.) dan alur kerja pemberitahuan

D) Mode offline (tidak dapat dinegosiasikan)

Konektivitas terkadang akan gagal. Cahaya harus tetap aman dan dapat diprediksi.

  • Menyatakan perilaku pencahayaan offline (jadwal mundur) ketika komunikasi terputus
  • Nyatakan berapa lama pengaturan lokal bertahan dan bagaimana pengaturan tersebut dipulihkan

E) Keamanan & kepemilikan data (harus eksplisit)

  • Siapa yang memiliki data operasional?
  • Siapa yang dapat mengakses perangkat dan dasbor?
  • Bagaimana kredensial dikelola (setidaknya pengungkapan “akses berbasis peran”)
  • Tanggung jawab dan kebijakan pembaruan firmware (siapa yang mendorong pembaruan, kapan)

Komisioning & penerimaan (membuat fitur pintar dapat diaudit)

Hasil uji coba minimum

  • Pemetaan serial-ke-lokasi (ID perangkat + ID tiang + GPS atau referensi alamat)
  • Catatan verifikasi konektivitas (metode lulus/gagal)
  • Rekaman pengaturan profil peredupan (mode + jadwal/pengaturan PIR)
  • Uji alarm: tunjukkan setidaknya satu jalur peringatan dan pengakuan

Gunakan halaman-halaman ini untuk menstandarkan bukti serah terima:


Pola kegagalan yang umum terjadi pada proyek “pintar” (dan cara mencegahnya)

  • “Smart menguras baterai”: pelaporan terlalu sering atau model energi mengabaikan konsumsi komunikasi → menegakkan pengungkapan Wavg.
  • Dasbor ada tetapi tidak ada tindakan: alarm tidak didefinisikan dan tidak ada yang memiliki alur kerja → menerapkan aturan alarm + SLA.
  • Kejutan konektivitas: tidak ada metode uji penerimaan → terapkan uji konektivitas commissioning.
  • Sengketa garansi: tidak ada log/penelusuran → menerapkan pemetaan serial + catatan komisioning + log pemeliharaan.

Halaman diagnosis/kontrol terkait:


Aturan pengadaan LULUS/GAGAL (edisi pintar)

Tandai tawaran GAGAL (Tidak Sebanding / Risiko Tinggi) jika tidak memiliki salah satu dari ini:

  • Paket Spesifikasi Cerdas (titik data + kontrol + alarm + mode offline + keamanan/kepemilikan data)
  • Lembar anggaran energi termasuk dampak modul pintar (asumsi Wavg / Wh-night)
  • Hasil kerja komisioning (pemetaan serial-ke-lokasi + catatan pengaturan peredupan + uji konektivitas)
  • Jaminan SLA dan batas dukungan yang jelas (siapa yang mendukung perangkat/jaringan/platform)

Salin/Tempel Klausul RFQ (Lampu Jalan Tenaga Surya Cerdas)

Klausul 1 - Paket Spesifikasi Cerdas (wajib)

Pemasok harus menyerahkan Paket Spesifikasi Cerdas yang mencakup: (1) poin data yang tersedia, (2) fungsi kontrol, (3) aturan alarm dan alur kerja pengiriman, (4) perilaku fallback offline, dan (5) pernyataan keamanan dan kepemilikan data. Penawaran tanpa paket ini tidak dapat dibandingkan.

Klausul 2 - Model energi mencakup konsumsi cerdas

Pemasok harus menyediakan lembar anggaran energi (Wavg, jam kerja, Wh/malam) yang mencakup asumsi pelaporan modul pintar (interval pelaporan dan perilaku operasional). Ukuran otonomi dan musim hujan harus konsisten dengan asumsi-asumsi ini.

Klausul 3 - Bukti komisioning dan penerimaan

Pemasok/kontraktor harus menyerahkan bukti uji coba termasuk pemetaan serial ke lokasi, catatan verifikasi konektivitas, catatan pengaturan peredupan, dan demonstrasi uji coba alarm. Hasil kerja ini diperlukan untuk penerimaan dan pemberlakuan garansi.

Klausul 4 - Batas dukungan dan SLA

Pemasok harus menetapkan batas dukungan (perangkat, jaringan, platform) dan memberikan SLA untuk respons dan diagnosis. Pemasok harus menjelaskan tanggung jawab untuk pembaruan firmware dan ketersediaan platform.

Klausul 5 - Kepemilikan data dan kontrol akses

Pemasok harus menyatakan siapa yang memiliki data operasional dan memberikan pernyataan kontrol akses (peran/pengguna). Kredensial dan tanggung jawab akses admin harus ditetapkan.

Minta Perangkat RFQ & Penerimaan Pencahayaan Cerdas

Dapatkan toolkit yang dapat diedit untuk menstandarkan persyaratan cerdas dan mencegah proyek “hanya dasbor”:

  • Templat Smart Spec Pack (data/kontrol/alarm/offline/keamanan)
  • Daftar periksa penerimaan konektivitas (lulus/gagal dalam uji coba)
  • Templat alur kerja alarm (kepemilikan + eskalasi + SLA)
  • Lembar tambahan anggaran energi (asumsi pelaporan cerdas)
  • Daftar periksa bukti garansi (pemetaan serial + log)

Ingin pemeriksaan kewarasan teknik yang cepat?

Bagikan kelas jalan, tinggi tiang, target lux/keseragaman, dan asumsi PSH bulan terburuk.

Langkah Selanjutnya (Jaga agar Proyek Anda Tetap Siap untuk Tender)

Pastikan proyek lampu jalan tenaga surya Anda memenuhi semua standar pengadaan dan teknik.

Templat & Bukti


PERTANYAAN YANG SERING DIAJUKAN

LoRa atau NB-IoT - mana yang lebih baik?

Tidak ada yang “selalu lebih baik”. Pilihlah berdasarkan kepemilikan jaringan, metode verifikasi cakupan, model biaya operasional, dan dukungan jangka panjang. Pengadaan harus memerlukan rencana konektivitas yang jelas dan uji penerimaan.

Apakah fitur pintar mengurangi masa pakai baterai?

Hal ini dapat terjadi jika pelaporan terlalu sering atau konsumsi modul pintar diabaikan dalam model energi. Memerlukan pengungkapan asumsi pelaporan dan menyertakannya dalam ukuran Wavg/Wh-night.

Apa bukti penerimaan minimum untuk sebuah proyek cerdas?

Pemetaan serial-ke-lokasi, catatan verifikasi konektivitas, catatan pengaturan peredupan, dan setidaknya satu jalur alarm yang teruji dengan alur kerja pengakuan.