Üretimde alarm yönetimi, operatörün gördüğü her alarmın gerçek, ilgili ve aksiyon alınabilir olmasını sağlama disiplinidir. Bu rehber, alarm sellerinin neden oluştuğunu, ISA-18.2 yaşam döngüsünün sizden ne beklediğini, öncelikleri ve ölü bantları nasıl belirleyeceğinizi ve alarm olaylarını MQTT üzerinden nasıl yayınlayacağınızı anlatıyor; böylece panolar, bildirimler ve analiz araçları aynı gerçeği görür.
Alarm Yönetimi Neden Önemlidir?
Bir alarm, operatöre bir şeyin sınırlı bir süre içinde müdahale gerektirdiğini söylemek için vardır. Bu söz bozulduğunda insanlar alarmları görmezden gelmeyi öğrenir. Alarm yönetimi olmayan tesislerdeki tipik belirtiler:
- Kalıcı (standing) alarmlar: Kimse nedenini gideremediği ya da gidermek istemediği için günlerce aktif kalan alarmlar.
- Titreşen (chattering) alarmlar: Bir limit etrafında dakikada defalarca açılıp kapanan alarmlar.
- Alarm selleri: Bir aksaklıktan sonra tek bir kök nedenin onlarca sonuç alarmını tetiklediği ve önemli olanın ekrandan kaydığı durumlar.
- Her şeyin yüksek öncelikli olması: Öncelik artık hiçbir bilgi taşımaz.
- Tanımlı bir müdahalesi olmayan alarmlar: Devreye alma sırasında "ne olur ne olmaz" diye yapılandırılmış alarmlar.
Sonuç alarm yorgunluğudur. Operatörler okumadan onaylar ve gerçekten kritik bir alarm geldiğinde gürültüyle yarışmak zorunda kalır. Bilinen birçok endüstriyel kazanın incelemeleri, aşırı yüklenmiş operatörleri katkıda bulunan bir etken olarak göstermiştir; alarm yönetiminin resmi bir disipline dönüşmesinin nedeni budur.
ISA-18.2 Temelleri
ANSI/ISA-18.2 (ve uluslararası karşılığı IEC 62682), proses endüstrilerinde alarm yönetimi için referans standarttır ve fikirleri kesikli üretime de aynı ölçüde uygulanabilir. Temel kavramı bir alarm yönetimi yaşam döngüsüdür:
| Aşama | Ne olur | Çıktı |
|---|---|---|
| Felsefe | Alarmın ne olduğunu, öncelikleri, renkleri, müdahale sürelerini, KPI'ları tanımlama | Alarm felsefesi dokümanı |
| Tanımlama | Tehlike analizleri, kalite ve bakım ihtiyaçlarından aday alarmları bulma | Aday listesi |
| Rasyonalizasyon | Her alarmı gerekçelendirme: neden, sonuç, müdahale, müdahale süresi, öncelik | Ana alarm veritabanı |
| Detaylı tasarım | Limitleri, ölü bantları, gecikmeleri, bastırma mantığını belirleme | Yapılandırılmış alarmlar |
| Uygulama | Devreye alma, test, operatör eğitimi | Canlı sistem |
| İşletme | Operatörler müdahale eder; rafa kaldırma ve servis dışı bırakma prosedürle yönetilir | Alarm olayları |
| Bakım | Enstrümanları onarma, alarmları test etme | Bakımı yapılmış sistem |
| İzleme ve değerlendirme | Alarm oranlarını, selleri, en sık alarm verenleri ölçme | İyileştirme aksiyonları |
| Değişiklik yönetimi | Eklemeleri, silmeleri ve limit değişikliklerini kontrol etme | Denetim izi |
| Denetim | Felsefeye göre periyodik gözden geçirme | Denetim raporu |
Çoğu tesis için en değerli adım rasyonalizasyondur. Her alarm için sorun: neden nedir, kimse müdahale etmezse ne olur, operatör tam olarak ne yapmalı ve ne kadar zamanı var? Üçüncü soruya net bir cevabı olmayan alarm, alarm değildir; bir olay ya da bildirimdir ve operatör ekranında değil, bir kayıtta yer almalıdır.
ISA-18.2 ayrıca operatör başına alarm yükü için yaygın kullanılan referans değerler verir ve alarm selini, bir operatörün başa çıkabileceğinden fazla alarm patlaması olarak tanımlar; tipik eşik on dakikada ondan fazla alarmdır. Kendi rakamlarınızı icat etmek yerine felsefenizde standardın değerlerini kullanın.
Üretim Ekiplerinin Sürdürebileceği Alarm Yönetimi: Öncelikler ve Tasarım
Öncelikleri Belirleme
Öncelik iki faktörden gelmelidir: sonucun ciddiyeti ve müdahale için mevcut süre. Basit bir matris işinizi görür:
| Sonuç | Dakikalar içinde müdahale gerekir | Bir saat veya daha uzun sürede müdahale gerekir |
|---|---|---|
| Güvenlik, çevre veya büyük ekipman hasarı | Yüksek | Orta |
| Ürün kaybı veya kalite blokajı | Orta | Düşük |
| Küçük verimlilik kaybı | Düşük | Alarm değil (olay veya bildirim) |
Yüksek öncelikli alarmların payını küçük tutun. Yapılandırılmış alarmların küçük bir azınlığından fazlası yüksek öncelikliyse rasyonalizasyonu yeniden gözden geçirin.
Ölü Bantlar ve Gecikmeler
Titreşen alarmların çoğu proses sorunu değil, tasarım sorunudur:
- Ölü bant (histerezis): 80 °C üzerinde tetiklenen bir alarm, örneğin yalnızca 78 °C'nin altında temizlenir.
- Açma gecikmesi (on-delay): Alarmın aktifleşmesi için koşulun belirli bir süre boyunca doğru olması gerekir; anlık sıçramalar filtrelenir.
- Kapanma gecikmesi (off-delay): Alarmın normale dönmesi için koşulun belirli bir süre boyunca temiz olması gerekir; hızlı yeniden tetiklenme önlenir.
Bastırma ve Rafa Kaldırma
Planlı bir duruş sırasında, durmuş bir pompadaki düşük debi alarmları beklenen ve işe yaramayan alarmlardır. Duruma dayalı bastırma, makinenin mevcut durumunda anlamsız olan alarmları gizler. Rafa kaldırma (shelving), operatörün gereksiz bir alarmı kontrollü bir prosedürle ve otomatik bir süre sınırıyla geçici olarak kaldırmasını sağlar; böylece alarm unutulup gitmez.
Alarm Olaylarını MQTT Üzerinden Yayınlama
Alarmlar genellikle PLC, DCS veya SCADA sistemlerinden çıkar. Bunları MQTT üzerinden yayınlamak, diğer tüketicilerin (andon panoları, mobil bildirimler, bakım sistemleri, analiz) ayrı entegrasyonlara gerek kalmadan aynı olayları kullanmasını sağlar. İki topic türü birlikte iyi çalışır:
acme/plant1/press/line3/press2/alarm/HYD_TEMP_HI retained: current state of this alarm
acme/plant1/press/line3/alarm-events not retained: every transition, for history
Alarm başına retained topic, herhangi bir client'a yalnızca .../alarm/# aboneliğiyle güncel aktif alarm listesini verir. Olay akışı ise saatlik alarm sayısı, en sık alarm veren ilk on ve sel dönemleri gibi alarm KPI'ları için bir veritabanını besler.
Aşağıdaki Python örneği, bir sıcaklık okuması üzerinde ölü bant ve açma gecikmesine sahip bir alarm uygular ve her iki topic'e de yayın yapar. paho-mqtt 2.x kullanır ve test için ücretsiz genel MQTT broker'ı kullanır.
import json
import time
import uuid
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/alm-2e7b/press2"
ALARM_ID = "HYD_TEMP_HI"
HIGH, CLEAR, ON_DELAY_S, PRIORITY = 80.0, 78.0, 5.0, "HIGH"
active = False
pending_since = None
def publish_alarm(client, state, value):
event = {"alarm": ALARM_ID, "state": state, "priority": PRIORITY,
"value": value, "limit": HIGH, "ts": time.time()}
client.publish(f"{BASE}/alarm/{ALARM_ID}", json.dumps(event), qos=1, retain=True)
client.publish(f"{BASE}/alarm-events", json.dumps(event), qos=1)
print(event)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/hydraulic/temp", qos=1)
def on_message(client, userdata, msg):
global active, pending_since
value = json.loads(msg.payload)["tempC"]
now = time.time()
if not active:
if value > HIGH:
pending_since = pending_since or now
if now - pending_since >= ON_DELAY_S:
active = True
publish_alarm(client, "ACTIVE", value)
else:
pending_since = None
elif value < CLEAR:
active, pending_since = False, None
publish_alarm(client, "CLEARED", value)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"alarm-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Beş saniyeden uzun süre 80'in üzerinde okumalar gönderin, alarm aktifleşir; yalnızca 78'in altında temizlenir. Onaylama da aynı şekilde eklenebilir: HMI bir onay olayı yayınlar ve alarm servisi retained durumu ACTIVE_ACKED olarak günceller.
Alarm Yönetimi Kontrol Listesi
- Yeni bir şey yapılandırmadan önce tek sayfalık bir alarm felsefesi yazın.
- Mevcut alarm listesini dışa aktarın ve alarmları sıklığa göre sıralayın; genellikle ilk on alarm yükün büyük kısmını oluşturur.
- Önce bunları rasyonalize edin: neden, sonuç, müdahale, süre, öncelik.
- Titreşen her alarma ölü bant ve gecikme ekleyin.
- Operatör aksiyonu olmayan alarmları olay veya bildirime düşürün.
- Durmuş ya da ürün değişimindeki makineler için duruma dayalı bastırma uygulayın.
- Operatör başına alarm oranını ve sel dönemlerini haftalık olarak ölçün.
- Limit ve öncelik değişikliklerini değişiklik yönetimi üzerinden kontrol edin.
ConnectMQ'nun Yeri
ConnectMQ, alarm olaylarını kontrolörler, panolar ve bildirim servisleri arasında taşıyan, MQTT 5, retained message, TLS ve tarayıcı tabanlı andon ekranları için güvenli WebSocket desteğine sahip barındırılan bir MQTT broker'dır. Portal ayrıca eşik tabanlı uyarı kuralları ve bir uyarı kaydı içerir; bunlar basit izleme bildirimleri için kullanışlıdır, örneğin bir soğuk odanın veya bir rulman sıcaklığının sabit bir limiti aşması. Bunlar PLC veya SCADA'nızdaki rasyonalize edilmiş proses alarmlarını ve güvenlik sistemlerini tamamlar, ancak onların yerini almaz; operatör aksiyonu gerektiren alarmların yeri yine oralardır.
Alarmları hatta görünür kılmak için bunları bir dijital andon sistemi ve makine durum izleme ile birleştirin. Akıllı üretim rehberi, alarm verilerinin tesisin tüm veri mimarisine nasıl oturduğunu gösterir.
Alarm Olaylarınızı ConnectMQ Üzerinden Yönlendirin
Kredi kartı gerekmeden app.connectmq.com adresinde ücretsiz bir Serverless broker oluşturun, ilk alarm topic'lerinizi yayınlayın ve aktif alarm listesinin topic gezgininde canlı olarak güncellenmesini izleyin.
Sık Sorulan Sorular
Alarm seli nedir?
Alarm seli, alarmların operatörün müdahale edebileceğinden daha hızlı geldiği bir dönemdir; çoğu zaman tek bir aksaklık çok sayıda sonuç alarmını tetiklediğinde ortaya çıkar. ISA-18.2'de eşik olarak genellikle operatör başına on dakikada ondan fazla alarm kullanılır.
Alarm rasyonalizasyonu nedir?
Her alarmın nedenini, sonucunu, gerekli operatör aksiyonunu, izin verilen müdahale süresini ve önceliğini belgelemek için yapılan sistematik incelemedir. Bu incelemeden geçemeyen alarmlar kaldırılır veya olaya dönüştürülür.
ISA-18.2 yalnızca proses endüstrisi için mi?
Proses endüstrileri için yazılmıştır, ancak yaşam döngüsü, rasyonalizasyon ve performans izleme yaklaşımı kesikli üretim hatlarına da uygulanabilir.
MQTT güvenlik alarmları için kullanılabilir mi?
Güvenlik fonksiyonlarının yeri sertifikalı güvenlik sistemleri ve PLC'lerdir. MQTT, alarm bilgisini panolara, bildirimlere ve analize dağıtmak için çok uygundur, güvenlik aksiyonlarını yürütmek için değil.
