Clock Drift: Saat Jam CCTV dan Log Tidak Cocok

Jam kamera, pengendali pintu, dan sensor bisa melenceng sehingga catatan kejadian tidak cocok. Selisih yang bertambah ini disebut clock drift. Saat menelusuri insiden, simpan waktu asli, catat selisih terhadap acuan, dan periksa cara sinkronisasinya. Penanda waktu (timestamp), yaitu waktu yang tercantum dalam catatan, perlu diuji ketepatannya sebelum dipakai menyimpulkan urutan kejadian.

Dasbor dapat menampilkan waktu perangkat yang terlihat wajar meskipun tidak akurat. Perbedaan baru terasa ketika petugas harus mencari kejadian tertentu, misalnya pukul 14:32.

Mengapa jam perangkat melenceng?

Banyak perangkat yang menyimpan waktu antar-reboot memakai jam internal (real-time clock, RTC). Isinya osilator kecil, biasanya kristal kuarsa 32,768 kHz, yang detaknya dihitung terus oleh pencacah.

Jam dinding yang tidak pernah dicocokkan dapat bergeser lima menit dalam enam bulan. Pada perangkat, selisih kecil yang terus terakumulasi juga membuat catatan sulit dibandingkan.

Kristal kelas konsumen dispesifikasikan sekitar ±20 ppm pada suhu ruang. Toleransi kecil tersebut perlu dihitung terhadap lama perangkat berjalan tanpa sinkronisasi.

Dua puluh bagian per sejuta dari satu hari — 86.400 detik — sama dengan 1,7 detik. Sebulan berarti 52 detik. Itu pun kasus terbaiknya, pada perangkat yang berada di rak berpendingin.

Suhu perangkat lapangan dapat jauh lebih tinggi. Kristal berbentuk garpu tala (tuning fork) mengikuti kurva frekuensi parabolik dengan puncak di sekitar 25 °C, dengan konstanta kelengkungan sekitar −0,034 ppm/°C² (Microchip AN2648). Pengendali pada suhu 50 °C dalam kotak di atap dapat mengalami tambahan selisih sekitar 21 ppm di atas toleransi bawaan — hampir 1,8 detik lagi hilang tiap hari. Pengaruh suhu ini menurunkan frekuensi relatif terhadap puncak kurva. Selisih jam keseluruhan tetap bergantung pada toleransi awal dan kondisi perangkat.

Ada juga perangkat yang memang tidak punya kristal. Espressif menempatkan osilator RC internal ESP32 di kategori yang "time drifting in the range of several seconds per day is acceptable", dan menyarankan kristal eksternal 32 kHz kalau ketepatan waktu selama mode tidur hemat daya (deep sleep) memang dibutuhkan (ESP-IDF System Time). Untuk sensor baterai yang bangun sejam sekali dan tidak sinkron ke apa pun, beberapa detik per hari jadi hitungan menit dalam dua minggu.

DVR dan NVR punya versinya sendiri. Jamnya disetel manual saat pengujian akhir dan serah terima, ditopang baterai koin, lalu tidak pernah disentuh lagi. Begitu baterainya habis — umur pastinya bergantung pada baterai serta perangkat — mati listrik berikutnya melempar jamnya ke tanggal default firmware. Perekamnya tetap merekam. Teks waktu tetap tertanam pada setiap bingkai video. Isinya saja yang sudah salah.

Berapa mahal selisih empat menit?

Sebuah pengelola gedung perlu menyelesaikan sengketa soal siapa yang masuk koridor terbatas. Pengendali akses mencatat penggunaan kartu dengan nama serta waktu. NVR punya rekaman kontinu. Dua sistem, satu pertanyaan, mestinya selesai sepuluh menit.

Pemutaran pada waktu penggunaan kartu menampilkan koridor kosong. Menit sebelumnya kosong. Menit sesudahnya juga. Pengendali akses terhubung ke domain jaringan dan waktu acuannya tersinkron. NVR-nya jalan dengan RTC sendiri sejak hari pemasangan, dan sudah maju hampir empat menit. Kejadiannya ada di rekaman sejak awal — penanda waktunya menunjukkan waktu sekitar empat menit lebih maju daripada waktu kejadian yang benar.

Pada kasus tersebut, selisih akhirnya ditemukan. Risiko yang lebih besar ialah selisih kecil tidak diperiksa karena tampak masuk akal, lalu rekonstruksi menempatkan dua kejadian dalam urutan yang salah.

Korelasi lintas sistem justru alasan log disimpan terpisah. Dan korelasi baru jalan kalau selisih tiap sistem terhadap satu acuan bersama diketahui:

Langkah normalisasi hanya mungkin kalau ada yang mengukur selisihnya sebelum perangkat dimulai ulang, disinkronkan ulang, atau diganti. Setelah perubahan itu, selisih sebelum perubahan mungkin tidak lagi dapat diukur. Selisih juga dapat berubah selama periode perekaman. Gunakan catatan sinkronisasi, mulai ulang, dan acuan kejadian yang tersedia; jangan menerapkan selisih hari ini pada seluruh data lama tanpa bukti pendukung.

Apakah cukup dengan memasang NTP?

NTP menyinkronkan jam perangkat dengan sumber waktu acuan. Ketepatan sinkronisasi dan kepercayaan terhadap sumber atau jaringan tetap perlu diperiksa. Mengisi alamat server NTP belum membuktikan sinkronisasi berjalan.

Tiga kegagalan menyumbang hampir semua kasus yang saya temukan di lokasi:

• Sinkron hanya saat boot. Banyak firmware perangkat tertanam memanggil SNTP sekali saat mulai berjalan, lalu tidak pernah lagi. Gateway dengan uptime 90 hari berarti 90 hari drift menumpuk, sementara halaman konfigurasinya tetap memajang alamat server NTP dengan percaya diri.
• UDP 123 diblokir ke luar. VLAN kamera dan pengendali sengaja diisolasi, dan akses ke sumber waktu belum diizinkan dalam daftar kendali akses (ACL). Perangkatnya sudah dikonfigurasi NTP. Ia belum pernah sekali pun sampai ke server.
• Selisih waktu tidak dipantau. Status sinkronisasi perlu menjadi metrik. chronyc tracking melaporkan selisih saat ini dalam detik; ekspor datanya, tampilkan grafik, dan tetapkan ambang peringatan sesuai kebutuhan. Tempatnya sama dengan keterjangkauan dan lama operasi pada tampilan kesehatan perangkat — cara membangun lapisan polling-nya dibahas di memantau fleet CCTV dengan SNMP.

Ada juga sisi keamanan, dan urusan yang satu ini masih jauh dari beres — lebih jauh daripada dugaan kebanyakan orang. Di presentasi Februari 2026 yang diliput LWN, Ruben Nijveld menyebut NTP "fundamentally a broken protocol": penyerang di jalur jaringan bisa mengubah timestamp saat transit tanpa terdeteksi. Network Time Security, distandarkan sebagai RFC 8915 pada 2020, menambahkan autentikasi pada pertukaran pesan waktu. RFC 8915 juga menjelaskan bahwa autentikasi tidak menghilangkan serangan yang menunda paket. Adopsinya lambat. Implementasi referensi ntpd belum mendukung NTS sama sekali, dan laporan yang sama mencatat belum ada implementasi SNTP yang mendukungnya. Banyak perangkat tertanam memakai SNTP. Periksa dukungan autentikasi dan pilihan perlindungan jaringan pada model yang digunakan; kemampuan setiap firmware dapat berbeda.

Untuk penerapan di Indonesia, BMKG menjalankan acuan waktu nasional di ntp.bmkg.go.id berdasarkan UU 31/2009, berdampingan dengan time.bmkg.go.id dan jam.bmkg.go.id (BMKG Tanda Waktu). Sumber waktu lokal dapat mengurangi waktu perjalanan pulang-pergi jaringan dibanding sumber yang lebih jauh. Ia juga memberi jawaban yang bisa dipertanggungjawabkan kalau ada yang menanyakan jam mana yang Anda jadikan acuan.

Bagaimana membuktikan jamnya benar?

Forensik digital punya jawaban formalnya. Di Forensic Science International: Digital Investigation volume 49 (2024), Vanini, Hargreaves, van Beek, dan Breitinger mendefinisikan acuan kejadian (time anchor): peristiwa yang waktunya dipatok sumber eksternal terpercaya, sehingga pemeriksa bisa menguji jam perangkat terhadap kenyataan dan mengukur selisih jamnya — bukan menganggapnya sudah beres.

Versi operasionalnya empat kebiasaan:

1. Ukur offset sebelum menyentuh apa pun. chronyc tracking, ntpdate -q pool.ntp.org, atau foto layar jam NVR bersebelahan dengan HP yang menampilkan waktu jaringan. Tulis angkanya di catatan insiden. Pencatatan singkat ini menjaga selisih sebelum mulai ulang yang mungkin hilang sesudahnya. Catatan sinkronisasi dan kejadian dengan waktu independen masih dapat membantu rekonstruksi.
2. Pilih perangkat yang mencatat event sinkronnya sendiri. Catatan pengukuran chrony dan systemd-timesyncd sama-sama meninggalkan jejak. Catatan koreksi langsung sebesar 228 detik menunjukkan koreksi pada saat itu; bukan bukti bahwa seluruh catatan sebelumnya memiliki selisih sama.
3. Sediakan satu anchor per sistem yang bisa diverifikasi pihak lain. Struk SMS, pemberitahuan balik dari layanan pembayaran, header Date dari API cloud. Sesuatu yang bisa dikonfirmasi tanpa bergantung pada infrastruktur Anda sendiri.
4. Jangan pernah menulis ulang timestamp lama. Simpan offset hasil pengukuran di sebelahnya, terapkan koreksi ketika menjalankan kueri sesuai bukti yang tersedia. Menimpa datanya justru menghapus satu-satunya jejak bahwa data itu pernah salah.

Disiplin yang sama membuat badge event dan video bisa dipakai bersama sejak awal. Sisi integrasinya dibahas di integrasi VMS dan access control.

Siapkan sistem menghadapi perubahan detik kabisat

Ketentuan waktu global juga sedang berubah. Resolusi 4 CGPM (2022) menyatakan nilai maksimum selisih UT1−UTC "will be increased in, or before, 2035" — yang secara praktis mengakhiri penyisipan detik kabisat (leap second). CIPM diminta mengusulkan batas barunya menjelang CGPM ke-28 (BIPM). Pertemuan itu tahun ini.

Di saat yang sama, rotasi Bumi justru mengencang. Makalah Duncan Agnew di Nature (27 Maret 2024) memperkirakan leap second negatif — satu detik dibuang, bukan ditambahkan — mungkin dibutuhkan sekitar 2029 (Nature). Dari 27 leap second yang disisipkan antara 1972 dan 2016, semuanya positif. UTC belum pernah menerapkan detik kabisat negatif. Sistem tetap perlu diuji untuk kemungkinan tersebut.

Empat aturan menjauhkan sistem dari urusan itu:

• Simpan UTC. Bukan waktu lokal, bukan "apa pun yang dilaporkan perangkat". Fleet yang tersebar di WIB, WITA, dan WIT menampilkan satu momen dengan tiga wajah; itu urusan tampilan, bukan format penyimpanan.
• Gunakan jam monoton (monotonic clock) untuk durasi. CLOCK_MONOTONIC, performance.now(), steady_clock. Watchdog yang mengukur selang waktu menggunakan jam kalender (wall clock) akan melaporkan durasi negatif begitu NTP melangkah mundur.
• Koreksi waktu bertahap (slew) pada sistem aktif. maxslewrate chrony menjaga urutan tetap utuh; simpan makestep untuk saat boot, ketika belum ada yang sedang dihitung waktunya.
• Catat sumber sinkron di baris log. Saat dua sistem berselisih nanti, pertanyaannya jam mana yang dipercaya, dan jawabannya ada di acuan waktu masing-masing.

Pemeriksaan perangkat di lapangan

• Tiap perangkat yang menulis timestamp punya server NTP terkonfigurasi dan jalur yang terbukti sampai. Verifikasi jalurnya, bukan kolom konfigurasinya.
• Sinkronisasi berjalan sebagai layanan latar belakang (daemon), bukan sekali jalan waktu boot.
• Selisih jam menjadi metrik yang dipantau dengan ambang peringatan.
• Penggantian baterai RTC masuk jadwal maintenance bersama komponen lain.
• Perangkat bertenaga baterai tanpa kristal melaporkan ketidakpastiannya sendiri, atau mengirim nomor urut yang diberi penanda waktu oleh server saat tiba.
• Prosedur insiden dimulai dengan mencatat offset tiap perangkat yang terlibat.

Penutup

Penanda waktu adalah hasil pengukuran yang dipengaruhi osilator, suhu, dan riwayat sinkronisasi. Perlakukan ketepatannya seperti alat ukur lain yang perlu diperiksa.

Sediakan sumber waktu yang terjangkau, layanan sinkronisasi aktif, dan metrik selisih pada dasbor. Saat insiden terjadi, catat selisih sebelum memulai ulang perangkat agar bukti yang membantu rekonstruksi tidak hilang.