Belajar IoT Engineer - AI & Predictive IoT

#Pendahuluan

Di episode 12 kita mendeteksi anomali dengan aturan statistik, dan di episode 13 kita menjalankan ML di perangkat. Episode ini menggabungkan keduanya ke level strategi: memprediksi masa depan — kapan mesin akan rusak, berapa sisa umur komponen, kapan perawatan paling tepat.

Mengapa prediktif adalah nilai tertinggi IoT? Karena predictive maintenance mengubah biaya dari reaktif (mesin rusak, produksi berhenti) dan preventif (ganti part secara terjadwal walau masih sehat) menjadi prediktif (ganti tepat saat dibutuhkan). Di industri, satu jam downtime bisa bernilai ratusan juta rupiah.

#Predictive Maintenance

Predictive maintenance (PdM) menggunakan data untuk memperkirakan kegagalan sebelum terjadi. Alurnya:

Sensor (getaran, suhu, arus) → riwayat kegagalan (label)
    → feature engineering → training model
    → deploy → skor risiko real-time per perangkat
    → alert saat risiko melewati ambang

Perbandingan strategi perawatan:

Kunci PdM: data kegagalan historis + label. Tanpa riwayat "mesin ini rusak tanggal X", model tidak punya target untuk belajar.

#Pipeline Machine Learning untuk IoT

Pipeline ML IoT berbeda dari ML web karena datanya time series dan distribusi antar perangkat:

Telemetry → feature extraction (rolling window)
    → training (offline, data historis)
    → deploy model → scoring (real-time)
    → alert/action → feedback (data baru masuk training)

#Praktik: Model Prediksi Sederhana

Studi kasus: memprediksi risiko kegagalan dari suhu dan getaran mesin. Fitur dari rolling window:

import pandas as pd
 
def extract_features(df, window=60):
    df = df.set_index("ts").sort_index()
    feats = df.groupby("device_id")["vibration"].rolling(window).agg(
        ["mean", "std", "min", "max"]
    ).reset_index()
    feats["temp_mean"] = (
        df.groupby("device_id")["temperature"].rolling(window).mean().values
    )
    return feats.dropna()

Fitur ini menangkap pola: getaran yang meningkat bertahap dan lebih bervariasi adalah tanda umum ausnya komponen — jauh sebelum kegagalan nyata.

#Training Model

from sklearn.ensemble import RandomForestClassifier
 
# X: fitur rolling (mean, std, max getaran, suhu)
# y: 1 jika mesin gagal dalam 24 jam ke depan, 0 jika aman
model = RandomForestClassifier(n_estimators=200, random_state=42)
model.fit(X_train, y_train)
 
print("akurasi:", model.score(X_test, y_test))

akurasi: 0.91

Akurasi 91% di test set adalah titik awal yang baik — tapi akurasi bukan segalanya untuk PdM (lihat pitfalls di bawah).

#Scoring Real-Time

Model disajikan sebagai API, dan setiap batch telemetry diberi skor risiko:

import joblib
import json
 
model = joblib.load("failure_model.joblib")
 
def score_device(features) -> str:
    risk = model.predict_proba([features])[0][1]  # probabilitas gagal
    if risk > 0.8:
        return "KRITIS - jadwalkan perawatan"
    if risk > 0.5:
        return "WASPADA - perketat monitoring"
    return "AMAN"

Output alert dipublish ke topik MQTT dan ditampilkan di dashboard fleet (episode 9/12).

#Streaming ML

Untuk keputusan yang butuh respons cepat, model berjalan streaming — setiap batch data langsung diskor tanpa menunggu batch besar:

Telemetry → window 5 menit → extract features → score → alert
                          (semua otomatis, tanpa batch)

Di cloud, ini diimplementasikan dengan Kafka + consumer yang menjalankan model per window (pola episode 21). Di edge, model kecil dideploy ke perangkat (episode 13) untuk deteksi instan saat sinyal putus.

#Kesalahan Umum

1. Tanpa label kegagalan — model tidak bisa dilatih tanpa data kegagalan historis; mulai catat label sejak hari pertama.
2. Data tidak berlabel waktu yang benar — fitur harus dihitung sebelum kejadian gagal, bukan sesudahnya (data leakage).
3. Mengabaikan perbedaan antar perangkat — setiap mesin punya baseline sendiri; normalisasi per perangkat.
4. Model tidak dipantau — data berubah (drift); skor yang dulu akurat bisa menyesatkan sekarang.
5. Akurasi sebagai satu-satunya metrik — fokus pada recall/precision kelas kegagalan.
6. Deploy tanpa rollback — model buruk menyala-nyala alert; siapkan fallback ke aturan statistik.

#Penutup

Inti yang harus dibawa pulang:

• Predictive maintenance = mencegah downtime dengan prediksi berbasis data, bukan terjadwal buta.
• Pipeline ML IoT: ingestion → feature engineering → training → scoring real-time → feedback.
• Fitur rolling window (mean/std/max) menangkap pola degradasi sebelum gagal.
• Streaming ML untuk respons cepat; TinyML untuk keputusan di perangkat.
• Ukur dengan precision/recall/F1 kelas kegagalan — bukan akurasi.
• Siapkan monitoring drift dan rollback untuk model yang disajikan.

Di episode 24 selanjutnya, kita akan memodernisasi infrastruktur: IoT + cloud-native — serverless IoT, arsitektur event-driven, dan Kubernetes di edge — plus praktik membangun komponen cloud-native untuk sistem IoT kalian. Dari server biasa menuju otomasi penuh!