Integrasi parkir
Integrasi Manajemen Parkir
Integrasi manajemen parkir untuk gedung: hunian, status palang, pemanduan, dan tautan lintas sistem, tanpa menyediakan palang atau perangkat keras parkir.
Ruang lingkup: integrasi, bukan perangkat keras parkir
Manajemen parkir dalam konteks ini berarti menghubungkan sistem parkir yang sudah ada atau milik pihak ketiga ke platform gedung. Kami tidak menyediakan palang, mesin tiket, terminal pembayaran, kamera ANPR, atau sensor ruang. Vendor parkir tetap bertanggung jawab atas peralatannya, transaksi, dan garansi. Peran kami adalah membawa keterisian, status palang, peristiwa masuk dan keluar, serta gangguan peralatan ke dalam gambaran operasional gedung, lalu mengaitkannya dengan pencahayaan, ventilasi, kontrol akses, dan pelaporan. Batas ini menjaga tanggung jawab tetap jelas dan memungkinkan klien mempertahankan sistem parkir yang sudah diadakan. Ketika sistem baru sedang dispesifikasikan, kami dapat menetapkan persyaratan antarmuka. Daftar antarmuka disepakati sebelum vendor parkir dan tim gedung mulai bekerja. Daftar antarmuka tertulis juga merupakan perlindungan paling jelas terhadap klaim terlambat bahwa integrasi sudah termasuk dalam paket pihak lain. Kejelasan itulah yang membuat pergantian vendor parkir di masa depan tetap dapat dikelola, dan hal ini harus tercermin dalam gambar, daftar titik, dan kontrak pemeliharaan.
- Kami mengintegrasikan sistem parkir yang sudah ada atau milik pihak ketiga
- Palang, mesin tiket, dan kamera tetap menjadi tanggung jawab vendor parkir
- Persyaratan antarmuka dapat ditetapkan sebelum pengadaan
- Batas tanggung jawab dituliskan dalam ruang lingkup
Data dan antarmuka
Sistem parkir menyajikan data dengan cara yang berbeda-beda. Instalasi lama menyediakan kontak bebas tegangan (volt-free) untuk palang terbuka, papan tanda penuh, atau alarm. Sistem yang lebih baru menawarkan API perangkat lunak, ekspor basis data, atau gateway Modbus atau BACnet. Integrasi harus dimulai dari daftar data: apa yang dibutuhkan, pada frekuensi berapa, dan siapa yang memiliki setiap titik. Jumlah keterisian, jumlah per lantai, peristiwa masuk dan keluar, status pembayaran, dan kode gangguan adalah hal yang umum. Sinkronisasi waktu lebih penting daripada yang terlihat: peristiwa masuk yang selisih dua menit dari CCTV mempersulit peninjauan insiden. Setiap titik memerlukan nama, satuan, flag kualitas, dan sumber yang terdokumentasi. Daftar data harus membedakan status langsung dari catatan historis, karena keduanya biasanya tiba melalui jalur berbeda, dengan latensi dan aturan retensi yang berbeda. Jika vendor tidak bersedia mendokumentasikan antarmukanya, negosiasi harus dilakukan sebelum kontrak, bukan setelah gangguan pertama.
- Daftar data disepakati sebelum pekerjaan antarmuka dimulai
- API, ekspor basis data, Modbus, BACnet, atau kontak bebas tegangan
- Sinkronisasi waktu dengan CCTV dan catatan akses
- Setiap titik memiliki nama, satuan, flag kualitas, dan sumber
Penghitungan keterisian dan pemanduan
Setelah jumlah dapat diandalkan, platform dapat menjalankan pemanduan: papan tanda ruang tersedia, indikator lantai, tampilan zona, dan tampilan aplikasi. Logika pemanduan harus menyertakan histeresis agar papan tanda tidak berkedip antara penuh dan tersedia pada ambang batas, serta fallback ketika jumlah menjadi kedaluwarsa. Status ruang EV dapat ditampilkan jika titik pengisian melaporkannya. Pemanfaatan historis mendukung keputusan tentang alokasi, kebijakan tarif, dan akses di luar jam kerja. Platform dapat membandingkan pola hari kerja dan akhir pekan, mengidentifikasi zona yang selalu penuh, dan menunjukkan berapa lama kendaraan berada di dalam. Ini adalah wawasan operasional, bukan pengganti sistem pendapatan milik operator parkir. Tampilan pemanduan yang menjanjikan ruang yang tidak dapat diverifikasi lebih buruk daripada tidak ada tampilan sama sekali, karena pengemudi berhenti mempercayai sistem setelah salah belok kedua kali. Jumlah yang kedaluwarsa harus diganti dengan pesan netral, bukan dengan angka terakhir yang diketahui. Jumlah harus dikalibrasi terhadap survei manual pada hari pertama operasi dan lagi setelah setiap pekerjaan sensor.
- Papan tanda ruang tersedia dan indikator lantai
- Histeresis untuk mencegah kedipan pada ambang batas
- Status ruang EV jika titik pengisian melaporkannya
- Tren pemanfaatan per zona dan pita waktu
Pencahayaan, ventilasi, dan kontrol CO
Peristiwa parkir menjadi berguna ketika terhubung ke bagian lain gedung. Kendaraan yang masuk ke lantai bawah tanah dapat memicu scene pencahayaan dan tahap ventilasi untuk zona tersebut. Gangguan palang dapat memunculkan alarm fasilitas dan mengarahkan operator ke kamera terdekat. Peristiwa keluar dapat melepaskan catatan akses terkait. Ventilasi harus mengikuti data CO dan keterisian, bukan timer tetap, dengan kecepatan kipas bertahap dan periode pembersihan (purge) yang ditetapkan. Kontrol bertahap yang tipikal menggunakan ambang CO pada kisaran 20 hingga 30 ppm untuk tahap pertama dan tingkat alarm yang lebih tinggi di atas 50 ppm, tetapi nilai sebenarnya harus berasal dari desain ventilasi tempat parkir dan persyaratan setempat. Pengendalian kebakaran dan asap tetap berada pada sistem kebakaran; integrasi parkir tidak boleh menunda atau mengesampingkan urutan keselamatan jiwa.
- Peristiwa masuk memicu pencahayaan dan ventilasi zona
- Gangguan palang diteruskan ke fasilitas dan CCTV
- CO dan keterisian mengendalikan tahap ventilasi
- Pengendalian kebakaran dan asap berada di luar urutan BAS
Batas akses, pengisian EV, dan pembayaran
Akses dan pembayaran adalah batas yang perlu ditetapkan sejak awal. Sistem parkir memiliki tiket, tarif, validasi, dan pembayaran; platform gedung dapat menerima status dan peristiwa untuk korelasi, tetapi tidak boleh menjadi sistem transaksi. Jika kredensial yang sama membuka pintu lobi dan palang parkir, sistem kontrol akses dan sistem parkir memerlukan hubungan yang jelas, termasuk apa yang terjadi ketika salah satunya offline. Pengisian EV menambah hubungan komersial kedua: operator titik pengisian memiliki sesi dan penagihan, sementara platform gedung dapat membatasi permintaan daya lokasi atau menggeser pengisian ke arah pembangkitan. Setiap batas harus menyebutkan sistem acuan (system of record), arah data, dan perilaku fallback. Ambiguitas pada batas-batas ini biasanya ditemukan oleh pengemudi di palang, yang merupakan tempat paling tidak nyaman untuk menyelesaikannya.
- Sistem parkir tetap menjadi sistem transaksi
- Hubungan kredensial ditetapkan antara akses dan parkir
- Sesi dan penagihan EV tetap pada operator titik pengisian
- Sistem acuan dan fallback disebutkan untuk setiap batas
Pelaporan dan operasi
Laporan parkir harus menjawab pertanyaan operasional: seberapa penuh setiap zona, kapan, berapa lama, dan seberapa sering pemanduan salah? Platform dapat menampilkan tren keterisian, jumlah masuk dan keluar, gangguan palang, serta waktu henti peralatan. Platform dapat merekonsiliasi jumlah dengan total transaksi operator parkir jika antarmuka memungkinkan, tetapi rekonsiliasi adalah pemeriksaan, bukan sistem penagihan. Alarm harus dikelompokkan berdasarkan peralatan dan lokasi, dengan jalur yang jelas ke vendor parkir untuk gangguan di luar ruang lingkup integrasi. Tinjauan bulanan atas pemanfaatan dan gangguan biasanya lebih berharga daripada dasbor langsung yang tidak ada yang memantau. Tinjauan juga harus menguji logika pemanduan terhadap kedatangan aktual, karena jumlah yang akurat pada tengah malam bisa tetap salah pada jam sibuk pagi. Tren harus disimpan cukup lama untuk membandingkan musim, bukan hanya minggu.
- Tren keterisian dan durasi parkir per zona
- Gangguan palang dan waktu henti peralatan tercatat
- Rekonsiliasi hanya jika antarmuka memungkinkan
- Gangguan di luar ruang lingkup diteruskan ke vendor parkir
Pengiriman, pengujian, dan batas vendor
Pengiriman dimulai dengan survei antarmuka dan rencana pengujian. Setiap titik dibuktikan terhadap sistem parkir, termasuk nilai normal, pemutusan koneksi, restart, dan data kedaluwarsa. Papan tanda pemanduan diperiksa pada ambang batas, bukan hanya pada rentang tengah. Kaitan ventilasi diuji dengan sinyal CO simulasi dan dengan mode kebakaran, karena kedua kondisi tersebut tidak boleh saling bertentangan. Serah terima mencakup daftar data, peta titik, dokumentasi API atau register, perutean alarm, dan kontak eskalasi untuk kedua vendor. Uji bersama dengan vendor parkir layak dijadwalkan, karena sebagian besar masalah integrasi adalah masalah kepemilikan, bukan masalah protokol. Perjanjian dukungan harus menyebutkan siapa yang merespons lebih dulu ketika palang, penghitung, atau gateway gagal, dan apa yang dilakukan tim gedung selama vendor dalam perjalanan.
- Survei antarmuka dan rencana uji bersama disepakati
- Setiap titik dibuktikan, termasuk pemutusan koneksi dan data kedaluwarsa
- Ventilasi diuji terhadap CO dan mode kebakaran
- Kontak eskalasi dan respons pertama disebutkan
Fungsi integrasi parkir dan pemeriksaan kegagalan
14 rows| Fungsi | Sistem sumber | Antarmuka tipikal | Peran platform | Kegagalan yang diperiksa |
|---|---|---|---|---|
| Keterisian ruang dan zona | Sensor atau penghitung parkir | API, Modbus, kontak kering | Tren, pemanduan, dan pelaporan | Penyimpangan penghitung setelah restart |
| Status palang | Kontroler palang | Kontak kering atau API | Memantau dan memunculkan alarm gangguan | Status macet terbuka atau tertutup |
| Peristiwa masuk dan keluar | Sistem parkir | API atau ekspor basis data | Referensi silang CCTV dan akses | Waktu peristiwa tidak selaras dengan video |
| Status pembayaran dan tiket | Sistem parkir | API | Hanya status; tanpa transaksi | Platform dianggap menangani pembayaran |
| Papan tanda ketersediaan | Kontroler papan tanda | API atau relay | Menjalankan logika pemanduan | Kedipan papan tanda pada ambang batas |
| Status ruang EV | Sistem titik pengisian | API atau Modbus | Menampilkan ketersediaan | Ruang terisi dilaporkan kosong |
| Gangguan peralatan | Sistem vendor parkir | API atau kontak kering | Meneruskan alarm ke vendor yang bertanggung jawab | Alarm tanpa pemilik |
| Peristiwa ANPR | Sistem parkir | API | Hanya korelasi dan pencatatan | Data pelat nomor disimpan tanpa aturan |
| Kaitan pencahayaan | BAS | I/O lokal atau field bus | Scene zona saat masuk dan keluar | Lampu tetap menyala setelah keluar terakhir |
| Kaitan ventilasi dan CO | Sensor CO dan BAS | I/O lokal atau Modbus | Kipas bertahap dan purge | Tahap macet atau purge dinonaktifkan |
| Korelasi akses | Sistem kontrol akses | API atau ekspor peristiwa | Menghubungkan peristiwa kendaraan dan kredensial | Kredensial tetap valid setelah palang gagal |
| Pelaporan pemanfaatan | Semua sumber parkir | Model data platform | Tren per zona dan pita waktu | Laporan dibangun dari jumlah kedaluwarsa |
| Sinkronisasi waktu | Sistem parkir dan BAS | Waktu jaringan atau protokol | Rekonstruksi peristiwa yang konsisten | Penyimpangan jam setelah pembaruan vendor |
| Eskalasi vendor | Kedua vendor | Perjanjian dukungan | Meneruskan gangguan ke tim yang tepat | Kedua pihak menolak panggilan |
Gambar proyek
3 images
Pertanyaan umum
01Apakah Anda menyediakan palang atau mesin tiket?
Tidak. Kami mengintegrasikan dan memantau. Palang, mesin tiket, terminal pembayaran, dan kamera ANPR disediakan serta didukung oleh spesialis parkir, sehingga tanggung jawab dan garansi peralatan tetap pada satu pihak. Ini juga berarti klien dapat mengganti vendor parkir di kemudian hari tanpa mengganti platform gedung, asalkan antarmukanya tetap tersedia.
02Apakah Anda dapat mengintegrasikan sistem parkir kami yang sudah ada?
Tergantung pada antarmuka yang disediakannya. Sistem dengan API, ekspor basis data, Modbus, atau kontak kering biasanya dapat diintegrasikan. Mulailah dengan survei antarmuka dan daftar data sebelum menetapkan ruang lingkup. Sistem yang lebih lama mungkin memerlukan gateway atau antarmuka perangkat keras kecil, dan biaya tersebut harus diketahui sebelum proposal ditetapkan.
03Apakah platform dapat menerima pembayaran?
Tidak. Pembayaran dan transaksi tetap pada sistem parkir atau penyedia pembayarannya. Platform hanya membaca status untuk pemantauan dan rekonsiliasi. Menjauhkan transaksi dari platform gedung juga mengurangi cakupan keamanan dan audit, yang merupakan keuntungan, bukan keterbatasan.
04Apakah parkir dapat mengendalikan pencahayaan dan ventilasi?
Ya. Masuknya kendaraan, keterisian zona, atau konsentrasi CO dapat memicu scene pencahayaan dan tahap ventilasi. Logikanya harus disepakati dengan desain kelistrikan dan persyaratan ventilasi tempat parkir. Mode kebakaran lebih diutamakan daripada setiap urutan normal, dan keduanya harus diuji bersama, bukan secara terpisah.
05Apakah aplikasi dapat menampilkan ruang kosong?
Ya, jika sistem parkir menyediakan jumlah per zona yang andal. Pemanduan memerlukan histeresis dan fallback yang ditetapkan ketika jumlah menjadi kedaluwarsa, agar tampilan tidak menjanjikan ruang yang tidak dapat diverifikasi. Pesan netral lebih baik daripada angka salah yang meyakinkan, dan operator harus dapat melihat kapan jumlah terakhir diperbarui.
06Apakah ANPR termasuk?
Kami tidak menyediakan kamera. Jika sistem parkir menyediakan peristiwa pengenalan melalui API, platform dapat menerimanya untuk korelasi masuk dan keluar serta penyimpanan catatan. Aturan retensi, akses, dan privasi untuk data pelat nomor berada pada operator parkir dan kebijakan data gedung, bukan pada integrasi semata.
07Apakah beberapa lokasi dapat dikelola bersama?
Ya. Setiap lokasi mempertahankan sistem parkir dan kontrol lokalnya, sementara platform menyediakan pemantauan, pelaporan, dan perutean alarm terpusat. Model data harus konsisten di seluruh lokasi sejak awal. Pelaporan terpusat hanya berguna jika titik yang sama memiliki arti yang sama di semua tempat, sehingga aturan penamaan dan penghitungan harus masuk pada fase pertama.
Langkah berikutnya
Bawa gedung Anda kepada kami.
Beri tahu kami jenis gedung, sistem dalam ruang lingkup, dan hasil yang Anda butuhkan. Kami akan memetakan jalur terpendek menuju sistem yang berfungsi.