Tunas Akara
Kembali ke Blog

Merancang Dashboard HMI yang Benar-Benar Dipercaya Operator

oleh RayhanDiperbarui 6 menit baca
hmiscadaalarm-managementindustrialdashboard
Merancang Dashboard HMI yang Benar-Benar Dipercaya Operator

Merancang Dashboard HMI yang Benar-Benar Dipercaya Operator

Dashboard monitoring industri tugasnya cuma satu: saat ada yang salah, operator melihatnya, paham, lalu bertindak. Sisanya dekorasi.

Di sistem kelas keselamatan — monitoring fire and gas contohnya yang paling telak — dekorasi bukan sekadar buang-buang tenaga. Dekorasi ikut berebut perhatian dengan satu-satunya sinyal yang penting. Prinsip desain di bawah ini lahir dari dunia itu, tapi berlaku untuk dashboard apa pun yang menuntut manusia merespons, bukan cuma mengagumi.

Abu-abu itu warna kondisi normal

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

Filosofi high-performance HMI — Human-Machine Interface, layar kendali yang dipelototi operator pabrik dan gedung — berangkat dari aturan yang tidak enak didengar: plant yang sehat harus terlihat membosankan. Latar abu-abu, peralatan digambar abu-abu redup, nilai tampil sebagai teks gelap. Warna baru boleh muncul saat ada yang abnormal. Ikon merah di layar abu-abu mustahil terlewat. Ikon merah yang sama di layar yang sudah sesak lampu hijau "running", pipa biru, dan gradien beranimasi cuma jadi satu titik lagi di tengah keramaian.

Tooling dashboard konsumer justru mendorong ke arah sebaliknya: tema mencolok, gauge warna-warni, animasi bertebaran. Di layar operasi, tiap piksel jenuh warna ikut menyedot perhatian operator. Perhatian itu jatah yang terbatas, dan seluruh desain harus menjaganya.

Ujiannya kejam tapi sederhana. Sandingkan screenshot kondisi normal dengan screenshot saat ada alarm aktif, lalu lihat dari jarak tiga meter. Kalau layar abnormalnya tidak langsung mencolok, desainnya gagal — mau secantik apa pun waktu demo.

Cause-and-effect matrix itu spek yang sebenarnya

Sistem fire and gas dispesifikasikan lewat cause-and-effect matrix. Barisnya penyebab deteksi: gas detector high di zona 3, manual call point di dek A. Kolomnya efek: bunyikan alarm, tutup damper, trip peralatan. Tiap perpotongan menyatakan apakah penyebab itu memicu efek itu. Engineering, commissioning, sampai penerimaan regulator, semuanya berpegang ke tabel ini.

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

Begitu tampilan dan matrix sejalan, commissioning berubah dari debugging jadi verifikasi. Susuri matrix baris per baris, picu tiap penyebab, cek layar menampilkan persis yang tertulis di tabel. Dashboard yang isinya ditentukan oleh "protokolnya expose apa" — bukan "matrix-nya butuh apa" — bakal penuh data tapi tidak menjawab pertanyaan apa pun. Jebakan ini tidak khusus fire and gas; saya bahas lebih panjang di membangun dashboard dengan menghubungkan sistem yang ada.

Disiplin alarm: hierarki dan shelving

Alarm flood itu mode kegagalan klasik. Satu akar masalah — tegangan drop, komunikasi putus — beranak-pinak jadi ratusan alarm turunan. Layar berubah jadi dinding merah yang terus menggulir. Kepercayaan operator ikut tumbang.

Setelah flood kedua, operator berhenti membaca alarm sama sekali. Sistem alarm yang diabaikan lebih buruk daripada tidak punya sama sekali, karena semua orang di atasnya masih yakin sistemnya bekerja.

Dua mekanisme menjaga daftar alarm tetap bermakna:

Hierarki. Prioritas tiap alarm ditetapkan dari konsekuensinya dan seberapa cepat harus direspons — bukan dari engineer mana yang merasa sinyalnya penting. Cukup tiga atau empat level, beda visualnya tidak mungkin tertukar, diurutkan supaya puncak daftar selalu perkara paling mendesak. Kalau alarm yang masuk kelas tertinggi lebih dari segelintir, klasifikasinya cuma angan-angan.

Shelving. Alarm rewel yang penyebabnya sudah diketahui — detector rusak yang menunggu suku cadang, misalnya — boleh diparkir sementara oleh operator. Alarmnya diangkat dari daftar utama, masuk rak dengan alasan dan masa berlaku yang tercatat, lalu balik sendiri begitu waktunya habis. Tanpa shelving, operator bikin cara supresinya sendiri: indikator ditutup lakban, buzzer dibungkam. Akal-akalan begitu tidak tercatat dan tidak pernah dicabut. Shelving mengerjakan hal yang memang bakal dilakukan operator — bedanya tercatat, teraudit, dan kedaluwarsa sendiri.

Acknowledge itu workflow, bukan sekadar klik

Alarm itu percakapan antara sistem dan operator, dan state machine di bawah ini tata bahasanya:

Loading diagram…

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

Tiap transisi masuk audit trail: alarm yang mana, state apa, operator siapa, timestamp-nya kapan. Di konteks keselamatan, jejak inilah bahan rekonstruksi investigasi insiden. Di konteks mana pun, jejak ini mengubah "sistem sudah menandai tapi tidak ada yang bertindak" dari bahan debat jadi fakta yang bisa di-query.

Uji dengan orang yang pegang shift

Langkah desain terakhir bukan demo ke stakeholder. Dudukkan operator shift yang beneran di depan layar, lalu jalankan skenario: satu alarm gas, alarm yang datang beruntun, komunikasi putus, serah terima shift.

Manajer menilai dashboard dari tampilannya. Operator menilainya sambil dikejar waktu, dan temuan mereka beda kelasnya. Label yang maknanya tidak langsung tertangkap. Tombol acknowledge yang kejauhan — dua kali pindah layar dulu baru ketemu. Warna prioritas yang di penerangan control room tengah malam tidak kebedakan dari warna lain. Tiap temuan dari satu jam sesi skenario jauh lebih murah daripada temuan yang sama saat kejadian sungguhan.

Cara data di baliknya sampai ke layar — lewat polling atau by exception, keputusan yang saya bahas di Modbus polling versus event-driven — ikut main di sini. Timestamp alarm harus merekam kapan kondisinya terjadi, bukan kapan poller kebetulan menyadarinya.

Intinya

HMI yang layak dipercaya berwarna abu-abu sampai ada yang salah. Logikanya memproyeksikan cause-and-effect matrix, bukan mengarang sendiri. Daftar alarmnya tetap pendek berkat hierarki dan shelving. Acknowledge diperlakukan sebagai workflow yang teraudit. Dan semuanya sudah diuji oleh orang-orang yang bakal menatapnya jam tiga pagi.

Tidak ada satu pun dari daftar itu yang fotogenik buat portofolio. Tapi justru itu semua yang dimaksud operator waktu bilang mereka percaya pada sebuah layar.

Artikel Terkait

Mau bangun hal serupa?

Jasa Pengembangan Backend IoT & Integrasi Multi-Protokol

Backend yang menyerap telemetri perangkat lintas MQTT, WebSocket, Modbus, dan BLE, lalu menyatukannya jadi dashboard real-time yang andal.

Lihat cara saya bisa bantu