MQTT Olaylarıyla Üretim İzlenebilirlik Sistemi Nasıl Kurulur?

Bir üretim izlenebilirlik sistemi iki soruyu hızlı ve kanıta dayalı şekilde yanıtlar: bu ürünün içine ne girdi ve nasıl üretildi, ve hangi diğer ürünler aynı şüpheli malzemeyi veya koşulları paylaşıyor? Bu rehber, izlenebilirlik olaylarının nasıl tasarlanacağını, her istasyondan MQTT üzerinden nasıl yayınlanacağını, bir veritabanında nasıl saklanacağını ve bir müşteri şikâyeti ya da tedarikçi geri çağırması geldiğinde nasıl sorgulanacağını gösteriyor.

İzlenebilirlik Gerçekte Neyi Gerektirir?

İzlenebilirlik çoğu zaman "bir seri numarası basıyoruz" seviyesine indirgenir. Kullanışlı bir sistem çok daha fazlasını kaydeder:

1. Kimlik. Her ürün için benzersiz bir seri numarası ya da ürün bazında takibin pratik olmadığı yerlerde bir parti veya lot ID'si.
2. Soy ağacı (genealogy). Hangi bileşen seri numaralarının veya malzeme lotlarının hangi ürüne kullanıldığı. Geriye ve ileriye doğru izlemeyi mümkün kılan budur.
3. Rota. Ürünün hangi istasyonlardan, ne zaman ve hangi hatta geçtiği.
4. Proses verisi. Ürün işlenirken geçerli olan parametreler: bir vida için tork ve açı, bir kürleme için sıcaklık ve süre, bir pres geçme için basınç.
5. Sonuçlar. Test ve muayene sonuçları, ölçülen değerler ve yeniden işleme geçmişi.

Bu beş kayıtla geriye doğru (arızalı bir üründen malzemelerine, makinelerine ve parametrelerine) ve ileriye doğru (şüpheli bir malzeme lotundan veya kötü bir zaman aralığından etkilenen her ürüne) izleme yapabilirsiniz. İleriye doğru izleme, bir geri çağırmayı "mart ayında üretilen her şey" olmaktan çıkarıp kesin bir listeye dönüştürür.

Olay Tabanlı İzlenebilirlik Neden İşe Yarar?

Geleneksel izlenebilirlik çoğu zaman her istasyonun özel bir arayüz üzerinden doğrudan merkezi bir veritabanına veya MES'e yazmasıyla kurulur. Bu, bir istasyon ekleyene, tedarikçi değiştirene veya veriye başka bir yerde ihtiyaç duyana kadar işe yarar. Olay tabanlı bir yaklaşım üreticileri tüketicilerden ayırır: her istasyon olanı küçük bir mesaj olarak yayınlar ve istenen sayıda sistem abone olur.

MQTT buna çok uygundur. İstasyonlar ve edge gateway'ler hafif bir protokol üzerinden yayın yapar, QoS 1 her olayın en az bir kez iletilmesini sağlar ve bir kalite panosu veya bir gerçek zamanlı SPC servisi gibi yeni tüketiciler istasyonlara dokunmadan eklenebilir. Bu modelde yeniyseniz önce bir MQTT broker'ın ne yaptığı yazısını okuyun.

Her şeyden önemli bir kural vardır: broker olayları taşır, veritabanı ise saklar. Bir MQTT broker arşiv değildir; bu nedenle izlenebilirlik veritabanı, her olayı kalıcı hale getiren bir abonedir.

Olayları Tasarlamak

Olay sözlüğünü küçük ve açık tutun. Bu altı tür, kesikli üretimin çoğunu kapsar:

Her olay bir event_id (kaynakta oluşturulan bir UUID) ve senkronize bir saatten alınan bir zaman damgası taşır. Olay ID'si depolamayı idempotent hale getirir: QoS 1 zaman zaman bir mesajı iki kez iletebilir ve veritabanı yinelemeyi basitçe yok sayar.

Topic yapısı

Olayların doğal olarak tesis, alan, hat ve istasyona göre gruplanması için ISA-95 tarzı bir hiyerarşi kullanın:

acme/plant1/assembly/line2/station30/trace/event

Tesisteki her izlenebilirlik olayına ihtiyaç duyan bir abone acme/plant1/+/+/+/trace/event topic'ine abone olur. ISA-95 MQTT topic'leri yazısı bu adlandırmayı derinlemesine ele alıyor; ConnectMQ portalı da bu tür topic'leri tanır ve cihazları seviyelere göre otomatik olarak gruplar.

Örnek payload'lar

{
  "event_id": "8f1c2e7a-5b9d-4c11-9e0f-2a7d61c3b4f0",
  "event": "component_consumed",
  "ts": "2026-10-16T07:52:13.118Z",
  "serial": "PMP-26-0041877",
  "station": "station20",
  "part_number": "MOT-0.75KW",
  "component_serial": "M2609-118422"
}

{
  "event_id": "c3a90b5e-0d2f-47b8-8d6e-91f4a7e02b1c",
  "event": "station_result",
  "ts": "2026-10-16T07:55:40.902Z",
  "serial": "PMP-26-0041877",
  "station": "station30",
  "result": "pass",
  "values": {"torque_nm": 12.4, "angle_deg": 186.0, "leak_rate_ml_min": 0.8},
  "program": "SCREW-P7",
  "operator": "OP114"
}

İzlenebilirlik Abonesini Kurmak

Aşağıdaki Python servisi bir önek altındaki tüm izlenebilirlik olaylarına abone olur, onları doğrular ve SQLite'a yazar. Eksiksizlik için olayın tamamını JSON olarak saklar ve en sık sorguladığınız alanları indekslenmiş sütunlara çıkarır. SQLite, örneği kendi içinde bağımsız tutar; aynı şema üretimde PostgreSQL'de de çalışır. paho-mqtt 2.x ve herkese açık ConnectMQ test broker'ını kullanır.

import json
import sqlite3
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/a41b06"
db = sqlite3.connect("traceability.db", check_same_thread=False)
db.executescript("""
CREATE TABLE IF NOT EXISTS events (
    event_id TEXT PRIMARY KEY,
    event TEXT NOT NULL,
    ts TEXT NOT NULL,
    serial TEXT NOT NULL,
    station TEXT,
    topic TEXT,
    payload TEXT NOT NULL
);
CREATE INDEX IF NOT EXISTS ix_serial ON events(serial);
CREATE INDEX IF NOT EXISTS ix_station_ts ON events(station, ts);
CREATE TABLE IF NOT EXISTS genealogy (
    serial TEXT NOT NULL,
    component TEXT NOT NULL,
    part_number TEXT,
    PRIMARY KEY (serial, component)
);
CREATE INDEX IF NOT EXISTS ix_component ON genealogy(component);
""")

REQUIRED = {"event_id", "event", "ts", "serial"}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/+/trace/event", qos=1)

def on_message(client, userdata, msg):
    try:
        e = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("invalid JSON on", msg.topic)
        return
    if not REQUIRED.issubset(e):
        print("missing fields", e)
        return
    with db:
        db.execute("INSERT OR IGNORE INTO events VALUES (?,?,?,?,?,?,?)",
                   (e["event_id"], e["event"], e["ts"], e["serial"],
                    e.get("station"), msg.topic, json.dumps(e)))
        if e["event"] == "component_consumed":
            component = e.get("component_serial") or e.get("lot")
            db.execute("INSERT OR IGNORE INTO genealogy VALUES (?,?,?)",
                       (e["serial"], component, e.get("part_number")))

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="trace-writer-a41b06",
                     clean_session=False)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

İki ayar bilinçli olarak seçilmiştir. Sabit bir client ID ile clean_session=False, yazıcı kısa süreliğine çevrimdışıyken broker'dan aboneliği korumasını ve QoS 1 mesajlarını (broker'ın oturum sınırları içinde) kuyrukta tutmasını ister. Olay ID'si üzerindeki INSERT OR IGNORE ise yinelenen iletimleri etkisiz hale getirir.

Bir terminalden test olayı yayınlayın:

mosquitto_pub -h broker.connectmq.com -p 1883 -i station30-a41b06 -q 1 \
  -t "connectmq/demo/a41b06/line2/station30/trace/event" \
  -m '{"event_id":"c3a90b5e-0d2f-47b8-8d6e-91f4a7e02b1c","event":"station_result","ts":"2026-10-16T07:55:40Z","serial":"PMP-26-0041877","station":"station30","result":"pass"}'

İzlenebilirlik Verisini Sorgulamak

Sistemin değeri, biri zor bir soru sorduğunda ortaya çıkar. Bu üç sorgu incelemelerin çoğunu kapsar.

Geriye doğru izleme: tek bir ürüne olan her şey.

SELECT ts, station, event, payload FROM events
WHERE serial = 'PMP-26-0041877' ORDER BY ts;

İleriye doğru izleme: şüpheli bir bileşen lotunu kullanan her ürün.

SELECT serial FROM genealogy WHERE component = 'LOT-SEAL-2609-07';

Zaman aralığı izleme: bir istasyon kontrol dışıyken orada işlenen her ürün.

SELECT DISTINCT serial FROM events
WHERE station = 'station30'
  AND ts BETWEEN '2026-10-16T07:30:00Z' AND '2026-10-16T08:15:00Z';

İleriye doğru izleme ve zaman aralığı sorgularını sevkiyat olaylarıyla birleştirdiğinizde müşteri hizmetlerine tam olarak hangi paletlerin bekletileceğini söyleyebilirsiniz.

Uygulama Kontrol Listesi

1. Seri numarası atama noktasını tanımlayın. Seri numaralarının nerede oluşturulacağına karar verin ve o istasyonun unit_created yayınlamasını sağlayın.
2. İzlenebilir her bileşeni okutun. Soy ağacı, ancak montajdaki okutma disiplini kadar eksiksizdir.
3. Saatleri senkronize edin. Her gateway ve istasyon PC'sinde NTP kullanın; zaman aralığı sorguları buna bağlıdır.
4. Olay ID'lerini kaynakta oluşturun. Asla veritabanında değil; aksi halde yinelemeler ayırt edilemez hale gelir.
5. QoS 1 ile yayınlayın. Yazıcı için kalıcı oturumlar kullanın.
6. Edge'de arabelleğe alın. İstasyonlar ağ kesikken olayları yerelde kuyrukta tutmalı ve yeniden bağlandığında yayınlamalıdır.
7. Doğrulayın ve izleyin. İstasyon başına saatlik olay sayısını tutun ve bir istasyon sessizleştiğinde uyarı verin.
8. Saklama süresini tanımlayın. Kayıtların sektörünüz ve müşterileriniz için ne kadar süre saklanması gerektiği konusunda uzlaşın ve veritabanı depolamasını buna göre planlayın.
9. Hattı güvenli hale getirin: MQTT güvenliği en iyi uygulamalarını izleyerek özel kimlik bilgileri ve TLS kullanın.

İzlenebilirliği Kaliteye Bağlamak

İzlenebilirlik, canlı kalite verisine bağlandığında en güçlü halini alır. Üretimde IoT ile kalite kontrol bir hata tespit ettiğinde, izlenebilirlik veritabanı size hangi önceki lotların ve makinelerin işin içinde olduğunu söyler. SPC kontrol dışı bir dönemi işaretlediğinde, zaman aralığı sorgusu karantinaya alınacak her ürünü listeler. Akıllı üretim rehberi, bu sistemlerin tek bir veri omurgasını nasıl paylaştığını gösteriyor.

Üretimde Barındırma

İzlenebilirlik olayları iş kayıtlarıdır; bu nedenle herkese açık bir test broker'ında değil, her zaman özel ve kimlik doğrulamalı bir broker'da olmalıdır. Tam yönetilen bir MQTT hizmeti, siz broker altyapısını işletmeden her istasyon için TLS uç noktaları ve verilen kimlik bilgileri sağlar. Daha katı yalıtım gereksinimleri olan tesisler, dedicated bir küme kullanabilir veya broker'ı BYOC kapsamında kendi bulut hesaplarında çalıştırıp yine de yönetilen bir hizmet olarak kullanabilir.

İzlenebilirlik Omurganızı ConnectMQ Üzerine Kurun

ConnectMQ; TLS ile MQTT 3.1.1 ve 5.0, kalıcı oturumlar, ücretli planlarda QoS 1 ve 2, ISA-95 topic algılama ve her istasyonun olaylarını doğrulamak için canlı bir topic gezgini sunar. Kredi kartı gerektirmeden app.connectmq.com adresinde ücretsiz Serverless planında bir broker oluşturun ve ilk istasyonunuzu bugün bağlayın.

Sık Sorulan Sorular

Üretim izlenebilirlik sistemi nedir?

Her ürünün veya partinin kimliğini, bileşenlerini, rotasını, proses parametrelerini ve sonuçlarını kaydeden bir sistemdir; böylece hem bir üründen geriye doğru hem de bir malzemeden veya olaydan ileriye doğru izleme yapabilirsiniz.

İzlenebilirlik seri numarasıyla mı yoksa partiyle mi yapılmalı?

Ürünlerin yüksek değerli veya güvenlik açısından önemli olduğu yerlerde ürün seri numaralarını, ürün markalamanın pratik olmadığı yerlerde ise parti veya lot ID'lerini kullanın. Birçok tesis, seri numaralı ürünlerin parti takipli malzemeler kullandığı şekilde ikisini birleştirir.

MQTT broker izlenebilirlik geçmişini saklayabilir mi?

Hayır. Broker olayları taşır. Bir abonenin her olayı, resmi kayıt sistemi olan bir veritabanına yazması gerekir.

QoS 1 ile yinelenen kayıtlardan nasıl kaçınırım?

Kaynakta benzersiz bir olay ID'si oluşturun ve veritabanı eklemesini bu ID üzerinde idempotent hale getirin; böylece yeniden iletilen mesajlar yok sayılır.