Deteksi Anomali Mesin: Kapan Ambang Batas Tak Lagi Cukup

Setelah sensor terpasang dan dashboard berjalan, pertanyaan berikutnya hampir selalu sama: "bisakah sistem ini memprediksi kerusakan?" Jawaban jujurnya — bisa, tetapi tidak secara otomatis, dan tidak untuk semua kasus. Deteksi anomali berbasis machine learning memberi nilai nyata pada kondisi tertentu, dan hanya membuang biaya pada kondisi lainnya. Membedakan keduanya sejak awal adalah bagian tersulit sekaligus paling menghemat anggaran.

Batas dari alarm ambang batas

Alarm ambang adalah fondasi yang benar dan wajib ada: bila suhu bearing melewati 80 °C, alarm harus berbunyi. Masalahnya, ambang batas memiliki tiga keterbatasan yang melekat:

• Berbunyi setelah masalah terjadi. Saat suhu benar-benar melewati batas, kerusakan sering sudah berlangsung.
• Buta terhadap kombinasi. Getaran naik sedikit, suhu naik sedikit, arus turun sedikit — semuanya masih di dalam batas, tetapi kombinasi itu tidak normal untuk mesin tersebut. Ambang batas per parameter tidak pernah melihat pola gabungan.
• Tidak mengenal konteks operasi. Getaran yang wajar pada beban 100% belum tentu wajar pada beban 40%. Ambang tunggal memaksa Anda memilih antara terlalu sering berbunyi atau terlambat berbunyi.

Di sinilah pendekatan berbasis data masuk: alih-alih menetapkan batas, sistem mempelajari seperti apa kondisi normal mesin ini pada berbagai keadaan operasi, lalu menandai penyimpangan dari pola tersebut.

Prasyarat yang sering diabaikan

Model tidak bisa mempelajari sesuatu yang tidak ada dalam datanya. Sebelum bicara algoritma, empat prasyarat ini menentukan berhasil atau tidaknya proyek:

• Riwayat data yang memadai. Idealnya beberapa bulan operasi yang mencakup variasi normal: pergantian shift, perubahan produk, musim, dan periode perawatan.
• Frekuensi sampling yang sesuai. Data setiap 15 menit cukup untuk tren energi, tetapi terlalu jarang untuk menangkap gejala getaran mekanis.
• Konteks operasi ikut tercatat. Beban, jenis produk, status shift, dan mode mesin. Tanpa ini, model tidak bisa membedakan "berbeda karena rusak" dari "berbeda karena sedang produksi varian lain".
• Catatan kejadian. Riwayat kapan mesin bermasalah dan perawatan apa yang dilakukan. Ini yang memungkinkan hasil model diverifikasi, bukan sekadar dipercaya.

Bila prasyarat ini belum terpenuhi, langkah pertama yang benar bukan membangun model, melainkan membenahi pengumpulan datanya lebih dulu.

Pendekatan bertahap yang realistis

1. Kumpulkan dan rapikan data. Satukan data sensor dengan konteks operasi dalam satu basis data yang konsisten, dengan penanda waktu yang selaras antar sumber.
2. Bangun baseline statistik. Sebelum menyentuh model kompleks, hitung rentang normal per mode operasi. Tahap ini saja sering sudah mengungkap penyimpangan yang selama ini tersembunyi — dan biayanya jauh lebih rendah.
3. Terapkan deteksi anomali. Setelah normal terdefinisi dengan baik, model dapat menandai kombinasi parameter yang menyimpang dari pola historis.
4. Validasi bersama tim lapangan. Setiap anomali yang ditandai harus dinilai oleh teknisi: apakah benar ada sesuatu, atau sekadar variasi wajar? Tanpa tahap ini, sistem cepat kehilangan kepercayaan pengguna.
5. Baru bicara prediksi sisa umur. Estimasi kapan komponen akan gagal membutuhkan data kegagalan yang cukup banyak. Sebagian besar pabrik belum memilikinya di tahun pertama — dan itu wajar.

Kasus yang cocok dan yang tidak

Menilai kelayakan di awal jauh lebih murah daripada menghentikan proyek di tengah jalan. Beberapa pola yang membedakan:

• Cocok: aset berputar yang berjalan terus-menerus. Pompa, kompresor, blower, dan motor besar menghasilkan pola getaran, arus, dan suhu yang stabil ketika sehat. Penyimpangan dari pola itu bermakna, dan datanya melimpah karena mesin jarang berhenti.
• Cocok: proses dengan parameter yang saling terkait. Oven, boiler, dan sistem pendingin memiliki hubungan antara suhu, tekanan, aliran, dan konsumsi energi. Ketika hubungan itu berubah meski setiap parameter masih normal, biasanya ada yang mulai bergeser.
• Kurang cocok: mesin yang jarang beroperasi. Peralatan yang menyala beberapa jam seminggu membutuhkan waktu sangat lama untuk mengumpulkan data normal yang memadai.
• Kurang cocok: proses yang berubah-ubah setiap batch. Bila setiap order memakai resep dan parameter berbeda, "normal" menjadi sasaran yang bergerak. Model tetap mungkin dibangun, tetapi memerlukan konteks batch yang tercatat rapi — sesuatu yang harus dibereskan lebih dulu.
• Tidak perlu model sama sekali. Bila masalah terbesar Anda adalah mesin yang mati mendadak karena tidak ada yang memantau, alarm ambang batas yang dirancang baik sudah menyelesaikan sebagian besarnya — dengan biaya jauh lebih rendah.

Menyatakan bahwa sebuah kasus belum layak adalah hasil yang sah dan bernilai. Yang mahal adalah membangun model selama enam bulan di atas data yang tidak pernah bisa mendukungnya.

Kesalahan yang paling mahal

Kegagalan proyek analitik industri jarang disebabkan pemilihan algoritma. Penyebab yang paling sering:

• Terlalu banyak notifikasi palsu. Sistem yang berbunyi setiap hari untuk hal yang tidak penting akan diabaikan dalam dua minggu, dan tidak akan pernah dipercaya lagi setelah itu.
• Hasil tanpa penjelasan. Teknisi membutuhkan alasan — "getaran menyimpang dari pola normal pada beban ini" — bukan skor tanpa konteks.
• Tidak terhubung ke alur kerja. Deteksi yang tidak menghasilkan perintah kerja hanyalah grafik yang menarik dilihat.
• Mulai dari model, bukan dari masalah. Tentukan lebih dulu kegagalan mana yang paling mahal bagi Anda, lalu bangun deteksi untuk kegagalan itu.

Dari data ke keputusan

Fondasinya tetap sama: data yang terkumpul rapi dan andal. IncludeBox dan IncludeGateways menangani pengumpulan dari mesin dan sensor, sementara platform INCLUDE Smart Industry menyimpan dan menampilkannya. Di atas fondasi itu, layanan AI & Machine Learning Development pada layanan INCLUDE mengembangkan model deteksi anomali yang sesuai dengan karakter mesin dan proses Anda — bukan model umum yang dipaksakan.

Urutannya penting: pengukuran dulu, pemahaman kemudian, prediksi terakhir. Melompati urutan ini adalah cara tercepat menghabiskan anggaran tanpa hasil operasional.