IoT ile kestirimci bakım projeleri, göz alıcı olmayan ayrıntılar sayesinde başarılı olur ya da başarısız olur: doğru varlıkta doğru sensör, uçta hesaplanan mantıklı öznitelikler ve yıllarca çalışmaya devam eden bir veri akışı. Bu rehber, sensör seçiminden durum verilerini MQTT üzerinden taşımaya ve arızadan önce uyaran modeller kurmaya kadar her katmanı adım adım ele alıyor. Sonunda bir referans mimariye, çalışan uç koduna ve ilk varlığınız için adım adım bir plana sahip olacaksınız.
Kestirimci Bakım Gerçekte Ne Anlama Gelir?
Bakım stratejileri bir yelpaze üzerinde yer alır. Reaktif bakım, bir şey bozulduğunda onarır. Önleyici bakım, ihtiyaç olsun ya da olmasın parçaları sabit bir takvime göre değiştirir. Duruma dayalı bakım, ölçülen bir değer bir sınırı aştığında harekete geçer. Kestirimci bakım ise bir adım daha ileri gider: durum verilerindeki eğilimleri ve örüntüleri kullanarak bir arızanın geliştiğini tahmin eder; ideal olarak bu tahmin, onarımın planlı bir duruşa yerleştirilmesine yetecek kadar erken yapılır.
Değer zamanlamadan gelir. Planlı bir hafta sonu duruşunda değiştirilen bir rulman, bir parça ve birkaç saate mal olur. Aynı rulmanın üretim sırasında arızalanması ise parçaya, plansız duruşa, muhtemelen mile veya motora ve makine bozulurken üretilen hurdaya mal olur. Durum izleme ile tahmin arasındaki fark durum izleme ve kestirimci bakım yazısında daha ayrıntılı açıklanıyor.
Önce Varlıkları ve Arıza Modlarını Seçin
Sensörlerle başlamayın. Beklenmedik bir arızanın can yaktığı varlıkların kısa bir listesiyle başlayın ve her biri için nasıl arızalandığını yazın. Ölçümü arıza modu belirler.
| Arıza modu | Erken gösterge | Sensör |
|---|---|---|
| Rulman aşınması | Artan yüksek frekanslı titreşim, ardından sıcaklık | İvmeölçer, sıcaklık probu |
| Dengesizlik veya eksen kaçıklığı | Çalışma hızında ve katlarında titreşim | İvmeölçer |
| Pompa kavitasyonu | Geniş bantlı titreşim, basınç dalgalanması | İvmeölçer, basınç transmitteri |
| Motor sargısı veya yük sorunları | Akım değişimi, faz dengesizliği | Akım trafoları |
| Dişli kutusu aşınması | Dişli kavrama frekanslarında titreşim, yağ durumu | İvmeölçer, yağ sensörü |
| Kayış kayması veya aşınması | Hız farkı, titreşim | Hız sensörü, ivmeölçer |
| Aşırı ısınma | Aynı yükte kademeli sıcaklık artışı | Sıcaklık probu, termal kamera |
| Hidrolik kaçaklar | Basınç düşüşü, uzayan çevrim süreleri | Basınç transmitteri, çevrim verileri |
Titreşime duyarlı arıza modlarına sahip döner ekipmanlar genellikle en iyi ilk hedeftir: motorlar, pompalar, fanlar ve dişli kutuları. İvmeölçer seçimi için titreşim izleme sensörleri, elektriksel imzalar için motor akımı izleme yazılarına bakın.
IoT ile Kestirimci Bakım Mimarisi
Güvenilir bir mimarinin dört katmanı vardır:
- Algılama. Varlığa monte edilmiş ivmeölçerler, sıcaklık probları ve akım sensörleri ile PLC'den gelen çalışma bağlamı (hız, yük, çalışma durumu).
- Uç işleme. Bir ağ geçidi veya mikrodenetleyici ham sinyalleri yüksek hızda örnekler ve bunları özniteliklere indirger: RMS hız, tepe ivme, tepe faktörü, basıklık (kurtosis), bant enerjileri, sıcaklık. Ham titreşim dalga biçimleri büyüktür; öznitelikler ise birkaç yüz bayttır.
- Taşıma. Öznitelikler ve bağlam, MQTT üzerinden bir broker'a yayınlanır. Analitik, historian'lar, panolar ve alarm sistemleri her biri bağımsız olarak abone olur.
- Analitik. Bir servis zaman serisini saklar, temel çizgileri oluşturur, anomalileri tespit eder ve eğilimleri tahmin eder. Sonuçlar sağlık skorları ve alarmlar olarak MQTT üzerinden geri akar.
Ortadaki broker, bu yapıyı genişletilebilir kılan şeydir. Basit bir eşik kontrolüyle başlayıp sensörlere dokunmadan daha sonra bir makine öğrenmesi servisi ekleyebilirsiniz. Broker'ın rolü size yabancıysa bir MQTT broker'ın ne yaptığı ile başlayın.
Uç Öznitelikleri: Yerelde Hesaplayın, Özet Yayınlayın
Ham 10 kHz titreşimi gün boyu ağ üzerinden göndermek nadiren gereklidir. Öznitelikleri uçta sabit bir takvimle, örneğin her dakika bir saniyelik kayıtla hesaplayın ve özeti yayınlayın. Aşağıdaki betik, sizin sağlayacağınız bir ivmeölçer okuma fonksiyonuyla bir Raspberry Pi veya endüstriyel PC üzerinde çalışır. Matematik için NumPy kullanır.
import json
import time
import numpy as np
import paho.mqtt.client as mqtt
TOPIC = "connectmq/demo/v4c9e2/plant1/utilities/pump03/condition"
SAMPLE_RATE = 10_000 # Hz
CAPTURE_SECONDS = 1.0
def read_accelerometer(n_samples):
"""Replace with your ADC / sensor driver. Returns acceleration in g."""
t = np.arange(n_samples) / SAMPLE_RATE
signal = 0.3 * np.sin(2 * np.pi * 49.5 * t) + 0.05 * np.random.randn(n_samples)
return signal
def features(acc_g):
acc = acc_g - acc_g.mean()
rms = float(np.sqrt(np.mean(acc ** 2)))
peak = float(np.max(np.abs(acc)))
kurt = float(np.mean(acc ** 4) / (np.mean(acc ** 2) ** 2))
spectrum = np.abs(np.fft.rfft(acc)) / len(acc)
freqs = np.fft.rfftfreq(len(acc), 1 / SAMPLE_RATE)
def band(lo, hi):
mask = (freqs >= lo) & (freqs < hi)
return float(np.sqrt(np.sum(spectrum[mask] ** 2)))
return {
"rms_g": round(rms, 4),
"peak_g": round(peak, 4),
"crest": round(peak / rms, 2) if rms else None,
"kurtosis": round(kurt, 2),
"band_10_1k": round(band(10, 1000), 4),
"band_1k_5k": round(band(1000, 5000), 4),
"dominant_hz": round(float(freqs[np.argmax(spectrum[1:]) + 1]), 1),
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pump03-edge-v4c9e2")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
while True:
acc = read_accelerometer(int(SAMPLE_RATE * CAPTURE_SECONDS))
payload = features(acc)
payload.update({"running": True, "temp_c": 41.8, "ts": int(time.time())})
client.publish(TOPIC, json.dumps(payload), qos=1)
time.sleep(60)
Neden bu öznitelikler: RMS genel titreşim enerjisini izler ve dengesizlik ile gevşekliğe tepki verir; basıklık ve tepe faktörü, rulman kusurları gibi darbeli arızalarda erken yükselir; yüksek bant rulman ve dişli aktivitesini yakalarken düşük bant çalışma hızı etkilerini yansıtır. running bayrağını ve yük bağlamını her zaman yayınlayın, çünkü rölantideki titreşim ile tam yükteki titreşim karşılaştırılamaz.
Eşik Değerlerinden Modellere
Merdiveni adım adım çıkın; her basamak daha fazla veri gerektirir ve daha erken uyarı sağlar.
- Mutlak sınırlar. İlk alarm seviyesi olarak ilgili standartlardaki veya ekipman üreticisinin titreşim şiddeti kılavuzlarını kullanın. Basit, açıklanabilir ve kaba sorunları yakalar.
- Temel çizgiden sapma. Her varlık ve çalışma durumu için birkaç haftalık sağlıklı veri kaydedin, ardından öznitelikler bu temel çizgiden birkaç standart sapma uzaklaştığında alarm verin. Bu yöntem her makinenin kendi normaline uyum sağlar.
- Çok değişkenli anomali tespiti. Isolation forest veya autoencoder gibi modeller tüm özniteliklere birlikte bakar ve tek bir değer uç noktada olmasa bile olağandışı kombinasyonları işaretler. Kestirimci bakım için makine öğrenmesi yazısı bunları ayrıntılı ele alıyor.
- Kalan faydalı ömür. Yeterli arızaya kadar çalışma geçmişiyle regresyon modelleri arızaya kalan süreyi tahmin eder. Bu, en değerli ve en çok veri isteyen adımdır; birçok tesis buna hiç ihtiyaç duymaz.
Minimal bir temel çizgi aboneliği şöyle görünür:
import json
import statistics
from collections import deque
import paho.mqtt.client as mqtt
TOPIC = "connectmq/demo/v4c9e2/plant1/utilities/+/condition"
baseline = {} # asset -> deque of rms values while running
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=1)
def on_message(client, userdata, msg):
asset = msg.topic.split("/")[-2]
data = json.loads(msg.payload)
if not data.get("running"):
return
window = baseline.setdefault(asset, deque(maxlen=2000))
if len(window) > 200:
mean, sd = statistics.fmean(window), statistics.pstdev(window) or 1e-9
z = (data["rms_g"] - mean) / sd
if z > 4:
alert = {"asset": asset, "feature": "rms_g", "value": data["rms_g"], "z": round(z, 1)}
client.publish(msg.topic.replace("/condition", "/health"), json.dumps(alert), qos=1)
window.append(data["rms_g"])
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pm-baseline-v4c9e2")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Üretimde temel çizgiyi sürekli güncellemek yerine öğrenme döneminden sonra dondurun; aksi halde yavaş gelişen bozulma "normal"in içine karışır.
Kestirimci Bakım Projelerini Batıran Tuzaklar
- Montaj. Boyalı, kavisli bir gövde üzerindeki mıknatıs zayıf yüksek frekans tepkisi verir. Saplamalı montaj veya düzgün hazırlanmış düz bir yüzey, sensör fiyatından daha önemlidir.
- Çalışma bağlamının olmaması. Hız ve yük bilgisi olmadan, farklı bir ürünün neden olduğu öznitelik değişikliği arıza gibi görünür.
- Geri bildirim döngüsünün olmaması. Her alarm, kendisine karşı kaydedilmiş bir bakım bulgusuyla sonuçlanmalıdır. Bu olmadan modeller doğrulanamaz ve iyileştirilemez.
- Aynı anda çok fazla varlık. Bir avuç kritik varlıkla başlayın, önlenmiş bir arızayı kanıtlayın, ardından ölçeklendirin.
- Bağlantıyı göz ardı etmek. Ağ geçitleri çevrimdışı olur. Sessiz bir sensörün sağlıklı bir makine olarak okunmaması için MQTT Last Will mesajlarını kullanın ve sensör sağlığını izleyin.
İlk Varlık İçin Adım Adım Plan
- Bilinen bir arıza geçmişi olan kritik bir döner varlık seçin.
- Arıza modlarını listeleyin ve sensörleri buna göre seçin.
- Sensörleri ve bir uç ağ geçidi kurun; veri hattını doğrularken öznitelikleri her dakika ücretsiz genel MQTT broker üzerindeki bir test topic'ine yayınlayın.
- Üretim varlıklarını bağlamadan önce özel bir broker'a geçin.
- Çalışma bağlamıyla birlikte iki ila dört haftalık temel çizgi verisi toplayın.
- Sınır ve temel çizgi alarmlarını etkinleştirin; bunları bakım ekibine yönlendirin.
- Her alarm için bulguları kaydedin ve aylık olarak gözden geçirin.
- Benzer varlıklara genişleyin ve daha gelişmiş modelleri yalnızca uyarı süresi kazandırdıkları yerlerde ekleyin.
Veri Akışını ConnectMQ Üzerinde Çalıştırmak
Durum verileri uzun ömürlü bir akıştır: sensörler yıllarca yayın yapar ve program olgunlaştıkça yeni tüketiciler ortaya çıkar. ConnectMQ tarafından sunulan yönetilen bir MQTT broker, ekibinizin sunucu çalıştırmasına gerek kalmadan bu merkezi yönetir. Ağ geçitleri verilen kimlik bilgileriyle 8883 portunda TLS üzerinden bağlanır, cihaz görünümü varlıkları ISA-95 seviyesine göre gruplar ve portaldaki eşik alarm kuralları basit mutlak sınırları karşılarken sizin servisleriniz temel çizgileri ve modelleri çalıştırır. Analitik araçları, historian'lar ve Node-RED akışları sıradan MQTT istemcileri olarak bağlanır. Programın geneli için akıllı üretim rehberini okuyun.
ConnectMQ ile Başlayın
app.connectmq.com adresinden kaydolun, kredi kartı olmadan ücretsiz bir Serverless broker oluşturun, bir uç ağ geçidi bağlayın ve ilk kestirimci bakım varlığınız için temel çizgiyi oluşturmaya başlayın.
Sık Sorulan Sorular
Kestirimci bakım için en iyi ilk sensör hangisidir?
Döner ekipmanlarda bir titreşim sensörü (ivmeölçer), en yaygın mekanik arızalar için en erken uyarıyı verir. Destekleyici sinyaller olarak sıcaklık ve akım ekleyin.
Ham titreşim verilerini MQTT üzerinden göndermeli miyim?
Genellikle hayır. Öznitelikleri uçta hesaplayıp özetleri yayınlayın; ham dalga biçimlerini yalnızca talep üzerine veya bir anomali tespit edildiğinde kaydedin ve planınızın mesaj boyutu sınırı içinde tutun.
Tahminlerin işe yaraması için ne kadar geçmiş veriye ihtiyacım var?
Temel çizgi ve anomali tespiti birkaç haftalık sağlıklı veriden sonra başlayabilir. Kalan faydalı ömür modelleri ise toplanması çok daha uzun süren arızaya kadar çalışma geçmişi gerektirir.
Kestirimci bakım makine öğrenmesi olmadan çalışabilir mi?
Evet. İyi seçilmiş sınırlar ve temel çizgiden sapma alarmları değerin büyük kısmını sağlar. Temeller oturduktan sonra makine öğrenmesi daha erken ve daha incelikli tespit ekler.



