Dasbor HMI: Alarm yang Jelas bagi Operator

Dasbor HMI (Human-Machine Interface, layar penghubung operator dengan mesin) perlu membantu orang mengenali gangguan dan menentukan tindakan. Dalam sistem SCADA, yang mengumpulkan data dan mengawasi peralatan, alarm harus punya prioritas jelas, penanggung jawab, serta catatan respons. Uji tampilan dengan operator pada skenario sibuk, termasuk gangguan komunikasi.

Pada sistem keselamatan, misalnya pemantauan kebakaran dan gas, hiasan visual dapat mengalihkan perhatian dari tanda bahaya. Prinsip berikut membantu operator mengenali gangguan dan bertindak. Prinsip yang sama juga berguna bagi dasbor operasional di luar sistem keselamatan.

Abu-abu itu warna kondisi normal

Bayangkan lampu lalu lintas yang merah terus tanpa alasan. Lama-lama pengendara berhenti menoleh. Dasbor yang ramai warna bernasib sama.

Prinsip HMI berkinerja tinggi (high-performance HMI) menempatkan kondisi normal sebagai latar yang tenang. Latar dan gambar peralatan memakai abu-abu redup, sedangkan nilai ditampilkan sebagai teks gelap. Warna menandai kondisi yang menyimpang. Ikon merah mudah dikenali pada layar abu-abu, tetapi bisa tenggelam jika layar sudah penuh indikator berwarna dan animasi.

Perangkat pembuat dasbor umum sering menawarkan tema mencolok, pengukur warna-warni, dan animasi. Pilih elemen tersebut dengan hati-hati untuk layar operasi. Warna yang terlalu banyak menyulitkan operator membedakan informasi rutin dari kondisi yang membutuhkan tindakan.

Ujinya sederhana. Sandingkan tangkapan layar kondisi normal dengan tangkapan layar saat ada alarm aktif, lalu lihat dari jarak tiga meter. Jika perbedaannya sulit dikenali, tampilan perlu diperbaiki meskipun terlihat menarik saat demonstrasi.

Matriks sebab-akibat sebagai acuan rancangan

Sistem pemantauan kebakaran dan gas menggunakan matriks sebab-akibat (cause-and-effect matrix) sebagai acuan. Baris memuat kondisi pemicu, seperti konsentrasi gas tinggi di zona 3 atau tombol manual di dek A. Kolom memuat tindakan, seperti membunyikan alarm, menutup damper, atau menghentikan peralatan. Setiap perpotongan menentukan hubungan pemicu dan tindakan untuk rancangan, pengujian, serta penerimaan.

Dasbor wajib jadi proyeksi setia dari matriks yang sama — bukan karangan tandingan dari tim UI. Tiap penyebab bisa ditampilkan sebagai status, status tiap efek terlihat, dan begitu satu penyebab aktif, operator bisa menelusuri efek mana saja yang ikut terpicu.

Ketika tampilan mengikuti matriks, pengujian dapat dilakukan baris demi baris: picu kondisi, lalu periksa status serta tindakannya pada layar. Dasbor yang hanya menampilkan data yang tersedia dari protokol dapat melewatkan informasi yang diperlukan operator. Pola serupa dibahas dalam dasbor yang menghubungkan sistem yang ada.

Prioritas alarm dan penangguhan sementara

Alarm flood, yaitu lonjakan alarm secara bersamaan, merupakan kegagalan yang umum. Satu gangguan tegangan atau komunikasi dapat memicu ratusan alarm turunan. Daftar merah yang terus bergulir membuat operator sulit menemukan penyebab utama.

Jika kejadian ini berulang, operator dapat berhenti memperhatikan daftar alarm. Keadaan itu berbahaya karena manajemen mungkin tetap menganggap setiap peringatan sudah ditangani.

Dua mekanisme menjaga daftar alarm tetap bermakna:

Hierarki. Prioritas tiap alarm ditetapkan dari konsekuensinya dan seberapa cepat harus direspons — bukan dari perekayasa mana yang merasa sinyalnya penting. Gunakan tiga atau empat tingkat dengan penanda visual yang mudah dibedakan, lalu urutkan yang paling mendesak di atas. Jika terlalu banyak alarm masuk prioritas tertinggi, tinjau kembali klasifikasinya.

Penangguhan sementara (shelving). Operator dapat mengeluarkan sementara alarm yang penyebabnya sudah diketahui, seperti detektor rusak yang menunggu suku cadang. Sistem mencatat alasan dan batas waktunya, lalu mengembalikan alarm secara otomatis setelah waktu habis. Tanpa mekanisme ini, operator mungkin menutup indikator atau mematikan bunyi alarm tanpa catatan. Penangguhan membuat tindakan tersebut dapat diperiksa dan tidak berlangsung tanpa batas.

Konfirmasi alarm sebagai bagian alur kerja

Sistem perlu membedakan alarm aktif, alarm yang sudah dilihat operator, dan alarm yang sudah pulih. Diagram perubahan status berikut menunjukkan perbedaannya:

Acknowledge artinya "sudah ada manusia yang melihat ini dan memegang responsnya". Acknowledge tidak pernah membungkam kondisi di baliknya. Alarm yang telanjur pulih sebelum sempat di-acknowledge pun tetap menuntut acknowledge — sebab ada kejadian yang lewat tanpa satu orang pun melihatnya.

Setiap perubahan masuk ke jejak audit: alarm, status, operator, dan waktu kejadian. Catatan ini membantu rekonstruksi insiden keselamatan. Pada operasi sehari-hari, catatan yang sama menunjukkan apakah peringatan sudah diterima dan ditindaklanjuti.

Uji bersama operator yang sedang bertugas

Langkah desain terakhir bukan demo kepada manajemen dan pihak yang berkepentingan. Dudukkan operator yang menjalankan shift di depan layar, lalu jalankan skenario: satu alarm gas, alarm yang datang beruntun, komunikasi putus, serah terima shift.

Operator menilai dasbor dalam keadaan mendesak dan dapat menemukan masalah yang luput saat demonstrasi. Misalnya, label sulit dipahami, tombol konfirmasi baru ditemukan setelah dua kali berpindah layar, atau warna prioritas sulit dibedakan dalam pencahayaan ruang kendali malam hari. Menemukan masalah melalui uji skenario membantu tim memperbaikinya sebelum kejadian nyata.

Cara data sampai ke layar juga memengaruhi pencatatan alarm. Saya membahas pengambilan data berkala (polling) dan pengiriman saat ada perubahan dalam artikel Modbus: polling versus berbasis kejadian.

Jika perangkat menyediakan cap waktu kejadian, simpan bersama waktu penerimaan data. Jika tidak, catat waktu deteksi dan interval pembacaan. Waktu deteksi belum menunjukkan waktu kejadian yang pasti; kondisi dapat berubah di antara dua pembacaan. Catatan ini membantu tim memahami batas ketepatan urutan kejadian.

Intinya

HMI yang dapat diandalkan membedakan kondisi normal dari gangguan, mengikuti matriks sebab-akibat, dan menampilkan alarm menurut prioritas. Konfirmasi serta penangguhan alarm harus tercatat. Uji semua alur tersebut bersama operator yang akan memakainya saat keadaan mendesak.

Kepercayaan operator tumbuh dari kemampuan layar menjelaskan kondisi dan tindakan berikutnya. Nilai itu perlu diuji dalam skenario kerja, bukan hanya dinilai dari tampilan demonstrasi.

Apa yang perlu diuji sebelum serah terima?

Pilih bersama operator beberapa gangguan nyata: satu alarm penting, alarm beruntun, dan komunikasi putus. Minta vendor menunjukkan prioritas, siapa yang mengonfirmasi, dan riwayat tindakannya. Untuk sistem keselamatan, rancangan alarm dan proteksi tetap perlu mengikuti penilaian teknis serta standar yang berlaku pada fasilitas itu.