Durum izleme ile kestirimci bakım karşılaştırması, bakım mühendisliğinde en çok karıştırılan konulardan biridir ve tedarikçiler çoğu zaman bu ayrımı bilerek bulanıklaştırır. Bu yazı ikisini net biçimde ayırıyor, birinden diğerine götüren olgunluk yolunu gösteriyor ve her biri için kuracağınız MQTT veri akışını çiziyor; böylece tesisinizin bir sonraki yatırımı nereye yapması gerektiğine karar verebilirsiniz.
Kısa Cevap
Durum izleme, bir varlığın sağlığını ölçer ve şu anda bir şeyin anormal olduğunu size söyler. Kestirimci bakım ise aynı sağlık verisini geçmişle birlikte kullanarak bir arızanın ne zaman gerçekleşmesinin muhtemel olduğunu tahmin eder; böylece onarımı en uygun anda planlayabilirsiniz.
Durum izleme bir yetkinliktir. Kestirimci bakım ise onun üzerine kurulan bir stratejidir. Durum izleme olmadan kestirimci bakım yapamazsınız, ancak tahminlere girişmeden çok önce durum izleme çalıştırabilirsiniz ve çoğu tesis de bunu yapmalıdır.
Bir Bakışta Durum İzleme vs Kestirimci Bakım
| Boyut | Durum izleme | Kestirimci bakım |
|---|---|---|
| Yanıtlanan soru | Bu makine şu anda sağlıklı mı? | Bu makine ne zaman müdahale gerektirecek? |
| Tipik çıktı | Alarm veya sağlık durumu | Eşiğe kalan tahmini süre veya kalan faydalı ömür |
| Mantık | Eşikler, bantlar, kurallar | Trendler, bozulma modelleri, istatistik veya makine öğrenmesi |
| Gereken veri | Güncel okumalar ve bir referans değer | Geçmiş arızaları da içeren uzun bir geçmiş |
| İlk değere ulaşma süresi | Günler ila haftalar | Yeterli geçmiş oluştuğunda, aylar |
| Kim aksiyon alır | Operatör veya teknisyen bir uyarıya müdahale eder | Planlamacı işi bir sonraki uygun pencereye planlar |
| Ana risk | Kötü eşiklerden kaynaklanan alarm yorgunluğu | Doğrulanmadan güvenilen modeller |
Her iki yaklaşım da reaktif bakımın (bozulunca onar) ve önleyici bakımın (duruma bakılmaksızın takvime veya sayaca göre onar) karşısında yer alır. İkisinin de hedefi aynıdır: sağlıklı parçaları değiştirmeyi bırakmak ve arızalanan parçalar tarafından gafil avlanmamak.
Pratikte Durum İzleme Neye Benzer?
Bir durum izleme sistemi, sağlığı yansıtan fiziksel bir büyüklüğü sürekli veya periyodik olarak ölçer:
- Motorlarda, pompalarda, fanlarda ve dişli kutularında titreşim
- Rulman ve sargı sıcaklığı
- Motor akımı ve gücü
- Yağ kalitesi, basıncı ve debisi
- Akustik emisyon ve ultrason
Her okuma bir limitle karşılaştırılır. Limit aşıldığında birine haber verilir. Kulağa basit geliyor ve öyle; tam da bu yüzden hızla değer üretir. Mantıklı, referans değere göre ayarlanmış bir alarmı olan bir titreşim sensörü, gevşek bir ayağı veya arızalanan bir rulmanı kilitlenmeden günler ya da haftalar önce yakalar. Titreşim izleme sensörü eğitimi bunun nasıl kurulacağını adım adım anlatır.
MQTT ile durum izleme veri akışı
Akış kısadır: sensörden broker'a, uyarı mantığına ve insanlara.
sensor/gateway --publish--> acme/plant1/press/line2/hydpump1/condition
|
MQTT broker (e.g. ConnectMQ)
| |
threshold alert rule dashboard / topic explorer
|
acme/plant1/press/line2/hydpump1/alert (retained)
Tipik bir payload yalnızca güncel değerleri ve birimleri taşır:
{
"ts": "2026-10-16T08:15:00Z",
"vib_rms_mm_s": 3.1,
"bearing_temp_c": 58.4,
"current_a": 21.7
}
ConnectMQ'da portalın eşik tabanlı uyarı kuralları bu gibi alanları izleyebilir ve her aşımı uyarı kaydına yazar; bu, ilk pilot için çoğu zaman yeterlidir. Referans değere göre limitler veya art arda birkaç ihlal şartı gibi daha ince mantıklar küçük bir abone servisinde çalışır.
Kestirimci Bakım Neler Ekler?
Kestirimci bakım daha zor bir soru sorar: bu sinyalin seyrine bakarak, aksiyon almamız gereken noktaya ne zaman ulaşacak? Bunu yanıtlamak, durum izlemenin gerektirmediği üç şey ister:
- Geçmiş. Varlık başına haftalar veya aylar boyunca, bir zaman serisi veritabanında saklanan okumalar.
- Arıza bilgisi. Neyin, ne zaman arızalandığına ve sinyallerin öncesinde nasıl göründüğüne dair kayıtlar. Bunlar olmadan bir modelin öğrenecek hiçbir şeyi yoktur.
- Bir model. Doğrusal bir trend ekstrapolasyonundan fizik tabanlı bir bozulma eğrisine veya eğitilmiş bir makine öğrenmesi modeline kadar herhangi bir şey. Makine öğrenmesi ile kestirimci bakım yazısı veri bilimi tarafını ele alır.
Çıktı bir alarm değil, bir tahmindir: "Pompa 1 rulman titreşimi günde yaklaşık 0,1 mm/s artıyor ve alarm limitini yaklaşık 12 gün içinde aşacak." Bir planlamacı da rulman değişimini plansız bir arızaya bir vardiya kaybetmek yerine mevcut bir duruşa planlayabilir.
MQTT ile kestirimci bakım veri akışı
Broker taşıma katmanı olmaya devam eder, ancak ona daha fazla tüketici bağlanır:
sensors/gateways --> MQTT broker --> historian subscriber --> time-series DB
| |
| model / trend job
| |
<------ publish prediction -------------+
acme/plant1/press/line2/hydpump1/prediction (retained)
|
CMMS integration / planner dashboard
Tahmin broker'a retained message olarak geri yayınlanır; böylece abone olan her pano veya bakım sistemi en son tahmini hemen alır:
{
"ts": "2026-10-16T09:00:00Z",
"signal": "vib_rms_mm_s",
"current": 3.1,
"alarm_limit": 4.5,
"slope_per_day": 0.11,
"days_to_limit": 12.7,
"confidence": "medium"
}
İzlemeden Tahmine Asgari Bir Adım
İlk kestirimci adımı atmak için makine öğrenmesine ihtiyacınız yok. Günlük bir toplam değer üzerinde kayan doğrusal regresyon bile kullanışlı bir "limite kalan gün" tahmini verir. Aşağıdaki Python işi günlük değerleri okur (historian'ınızdan; burada anlaşılırlık için bir liste) ve tahmini paho-mqtt 2.x ile genel test broker'ına yayınlar.
import json
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
ALARM_LIMIT = 4.5
TOPIC = "connectmq/demo/4c81d2/press/hydpump1/prediction"
# mm/s cinsinden günlük medyan titreşim RMS, en eskiden başlayarak (normalde historian'dan sorgulanır)
daily = [2.1, 2.1, 2.2, 2.2, 2.3, 2.3, 2.5, 2.5, 2.6, 2.8, 2.8, 2.9, 3.0, 3.1]
def linear_fit(values):
n = len(values)
xs = range(n)
mx, my = (n - 1) / 2, sum(values) / n
sxx = sum((x - mx) ** 2 for x in xs)
sxy = sum((x - mx) * (y - my) for x, y in zip(xs, values))
slope = sxy / sxx
return slope, my - slope * mx
slope, intercept = linear_fit(daily[-14:])
current = daily[-1]
days_to_limit = (ALARM_LIMIT - current) / slope if slope > 0 else None
forecast = {
"ts": datetime.now(timezone.utc).isoformat(timespec="seconds"),
"signal": "vib_rms_mm_s",
"current": current,
"alarm_limit": ALARM_LIMIT,
"slope_per_day": round(slope, 3),
"days_to_limit": round(days_to_limit, 1) if days_to_limit else None,
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-job-4c81d2")
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(TOPIC, json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print(forecast)
Bu kasıtlı olarak basittir. Bozulmanın son iki hafta boyunca kabaca doğrusal olduğunu varsayar; bu yavaş gelişen arızalar için çoğu zaman yeterince iyidir, ani arızalar için ise işe yaramaz. Bu sınırlama, genel olarak kestirimci bakımın dürüst bir özetidir: kademeli arızalar için uyarı sürenizi uzatır, ani olanları ise yine durum izlemenin yakalaması gerekir.
Bakım Olgunluk Yolu
Çoğu tesis bu aşamalardan sırayla geçer. Adımları atlamak, kestirimci projelerin tıkanmasının en yaygın nedenidir.
- Reaktif. Arızalanana kadar çalıştır. Veri yok.
- Önleyici. Zamana veya sayaca dayalı görevler. Veri, CMMS'te iş emirleri olarak yaşar.
- Bağlı. Makineler temel durum ve sayaç verilerini yayınlar. MQTT omurgası genellikle burada, çoğu zaman önce makine duruş takibi için ortaya çıkar.
- Durum izleme. Kritik varlıklarda uyarılı sağlık sinyalleri. Değer haftalar içinde gelir.
- Duruma dayalı bakım. İzlediğiniz varlıklar için iş emirleri takvim yerine durum uyarılarıyla tetiklenir.
- Kestirimci bakım. Trend ve model çıktıları, işleri eşik aşımlarından önce planlar.
- Reçeteli (prescriptive). Sistem, üretim planlarını ve yedek parçaları dikkate alarak aksiyonu ve en iyi zamanı da önerir.
İlerlemeyi kurulan sensör sayısıyla değil, güvenilirlik metrikleriyle ölçün. MTBF ve MTTR hesaplama, başlamadan önce bir referans ve sonrasında iyileşmeyi kanıtlamanın bir yolunu sağlar.
Yatırım Yapılacak Yeri Seçmek
Şu durumlarda durum izlemeyle başlayın:
- Hiç sağlık verisi olmayan kritik varlıklarınız var.
- Arızalar pahalı, ancak elinizde az sayıda geçmiş arıza kaydı var.
- Bir çeyrek içinde görünür sonuçlara ihtiyacınız var.
Şu durumlarda kestirimci bakıma yatırım yapın:
- Aynı varlıklarda aylardır tutarlı biçimde durum verisi toplanıyor.
- Eşleşen sensör geçmişine sahip belgelenmiş arızalarınız var.
- Planlama esnekliği mevcut; yani daha erken bir uyarı, işin ne zaman yapılacağını gerçekten değiştirir.
Her iki durumda da altyapı kararı aynıdır: sinyalleri bir kez güvenilir ve iyi adlandırılmış bir MQTT omurgasına taşıyın, izleme, historian'lar ve modellerin bağımsız olarak abone olmasına izin verin. Bir bulut MQTT broker, bu omurgaya tesisten, başka bir lokasyondaki veri ekibinden ve bir bakım planlamacısının dizüstü bilgisayarından özel noktadan noktaya entegrasyonlar olmadan erişilmesini sağlar. Akıllı üretim rehberi bu omurgayı ve ISA-95 topic yapısını ayrıntılı olarak anlatır.
Yaygın Hatalar
- İzlemeden önce tahmin satın almak. Birkaç haftalık veriyle ve kayıtlı arıza olmadan eğitilen bir model işe yarar hiçbir şey tahmin etmez.
- Kataloglardan alınan sabit eşikler. Her makinenin kendi normali vardır. Referans değerleri varlık bazında öğrenin.
- Geri bildirim döngüsünün olmaması. Teknisyenler bir uyarıya müdahale ettiklerinde ne bulduklarını kaydetmelidir; aksi halde mantığı asla doğrulayamaz veya iyileştiremezsiniz.
- Silolardaki veri. Titreşim sistemi, CMMS ve historian birbirlerinin verisini göremiyorsa tahmin bir sunumdaki slayt olarak kalır.
- Ani arızaları göz ardı etmek. Tahmin kademeli aşınmaya yardımcı olur. Diğer her şey için hızlı durum alarmlarını yerinde tutun.
İzleme Omurganızı ConnectMQ Üzerine Kurun
ConnectMQ; MQTT 5, TLS, retained message, canlı topic gezgini ve yerleşik eşik tabanlı uyarı kuralları sunan tam yönetilen bir MQTT hizmetidir. Böylece bugün durum izleme çalıştırabilir, historian'ları ve tahmin işlerini daha sonra sıradan MQTT client'ları olarak ekleyebilirsiniz. Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz Serverless planında bir broker oluşturun.
Sık Sorulan Sorular
Durum izleme ile kestirimci bakım aynı şey mi?
Hayır. Durum izleme şu andaki anormal sağlığı tespit ederken kestirimci bakım, durum verisini ve geçmişi kullanarak müdahalenin ne zaman gerekeceğini tahmin eder. Kestirimci bakım durum izlemeye bağımlıdır.
Bir tesis önce hangisini uygulamalı?
Durum izlemeyi. Hızla değer üretir ve herhangi bir kestirimci yaklaşımın daha sonra ihtiyaç duyacağı veri geçmişini oluşturur.
Kestirimci bakım için makine öğrenmesi gerekli mi?
Şart değil. İyi seçilmiş sinyaller üzerinde trend ekstrapolasyonu, kademeli arızalar için zaten kullanışlı limite kalan süre tahminleri verir. Makine öğrenmesi, zengin bir geçmişiniz ve çok sayıda kayıtlı arızanız olduğunda yardımcı olur.
MQTT her iki yaklaşımda nasıl bir rol oynar?
MQTT; sensör okumalarını, uyarıları ve tahminleri cihazlar, panolar, historian'lar ve bakım sistemleri arasında taşıyan iletim katmanıdır. Hepsi için tek bir broker kullanmak noktadan noktaya entegrasyonları ortadan kaldırır.
