Üretimde IoT ile Kalite Kontrol: Hat İçi Sensörler ve MQTT ile Gerçek Zamanlı Kontroller

Üretimde IoT ile kalite kontrol, sorunları son muayenede ya da bir müşteri şikâyetiyle keşfetmek yerine ürün ve proses kalitesini hatta sürekli olarak ölçmek anlamına gelir. Bu rehber hangi hat içi sensörlerin kullanılacağını, ölçümlerinin MQTT üzerinden nasıl yayınlanacağını, gerçek zamanlı spesifikasyon kontrollerinin nasıl çalıştırılacağını ve aynı veri akışının istatistiksel proses kontrolünü ve izlenebilirliği nasıl beslediğini gösteriyor.

Örneklemeden Sürekli Kalite Verisine

Geleneksel kalite kontrol örneklemeye dayanır: bir kontrolör saatte birkaç parça alır, bunları bir laboratuvarda veya ölçüm istasyonunda ölçer ve sonuçları bir tabloya ya da kalite sistemine yazar. Bu işe yarar, ancak bilinen zayıflıkları vardır. Örnekler arasında başlayan sorunlar bir sonraki kontrole kadar fark edilmeden devam eder. Sonuçlar geç gelir ve parçayı üreten kesin proses koşullarıyla ilişkilendirilmesi zordur. Ve veri, ona zamanında göre aksiyon alabilecek kişilere nadiren ulaşır.

Bağlantılı kalite kontrol üç şeyi değiştirir:

1. Kapsam. Hat içi sensörler ve otomatik ölçü aletleri, vardiya başına bir avuç parça değil, her parçayı veya parçaların büyük bir kısmını ölçer.
2. Gecikme. Sonuçlar saniyeler içinde hazır olur; böylece sonraki yüz parça üretilmeden hat durdurulabilir veya ayarlanabilir.
3. Bağlam. Her ölçüm parça seri numarası, makine, reçete ve proses parametreleriyle birlikte iletilir; bu da hataları açıklanabilir olaylara dönüştürür.

Kalite Verisi Nereden Gelir?

Son iki satır kolayca gözden kaçar. Kalite sorunlarına neredeyse her zaman proses koşulları neden olur; dolayısıyla ölçümün yanında sıcaklık, basınç veya hat hızını yakalamak, daha sonra kök neden analizini mümkün kılan şeydir.

Üretimde IoT ile Kalite Kontrol İçin Bir MQTT Mimarisi

MQTT kalite verisine çok uygundur, çünkü bir ölçümün genellikle birden fazla tüketicisi vardır: hat ekranı, kalite mühendisinin SPC panosu, izlenebilirlik veritabanı ve muhtemelen MES. Publish/subscribe ile ölçü aleti bir kez yayınlar ve her tüketici bağımsız olarak abone olur. Bir MQTT broker'ın ne yaptığı yazısı bu modeli ayrıntılı olarak açıklıyor.

Tipik bir akış:

1. Sensörler, ölçü aletleri ve test istasyonları bir edge gateway'e (bir PLC, Node-RED çalıştıran bir endüstriyel PC veya küçük bir Python servisi) bağlanır.
2. Gateway parça seri numarasını, istasyonu, reçeteyi ve zaman damgasını ekler ve ölçüm veya parça başına bir mesaj yayınlar.
3. Bir kalite servisi abone olur, her değeri spesifikasyon limitleriyle karşılaştırır ve bir karar yayınlar.
4. Bir historian veya veritabanı abonesi, SPC ve izlenebilirlik için her şeyi saklar.
5. Panolar canlı değerlere ve kararlara abone olur.

Topic tasarımı

ISA-95 tarzı bir hiyerarşi izleyin ve ham ölçümleri kararlardan ayırın:

acme/plant1/assembly/line3/station40/quality/measurement
acme/plant1/assembly/line3/station40/quality/verdict
acme/plant1/assembly/line3/station40/quality/spec        (retained)

Aktif spesifikasyonu retained mesaj olarak yayınlamak kullanışlı bir yöntemdir. Bağlanan her tüketici o istasyonun güncel limitlerini anında öğrenir ve bir reçete değişikliği yalnızca yeni bir spesifikasyon yayınlamayı gerektirir.

Payload tasarımı

{
  "ts": "2026-10-16T09:31:07.412Z",
  "serial": "A3-2610-004812",
  "recipe": "HOUSING-B",
  "characteristic": "bore_diameter_mm",
  "value": 22.012,
  "unit": "mm",
  "gauge": "G-40-1",
  "process": {"spindle_temp_c": 31.4, "coolant_temp_c": 21.8}
}

Her mesaja seri numarasını veya parti ID'sini ekleyin, birimleri açıkça belirtin ve mesaj başına bir karakteristik ya da parça başına karakteristiklerden oluşan açıkça adlandırılmış bir nesne kullanın. Anlamı yalnızca birinin kafasında yaşayan konumsal dizilerden kaçının.

Gerçek Zamanlı Spesifikasyon Kontrolleri

En basit kullanışlı kalite servisi, her değeri alt ve üst spesifikasyon limitleriyle karşılaştırır ve bir karar yayınlar. Aşağıdaki Python örneği (paho-mqtt 2.x) spesifikasyonları retained mesajlarda tutar; böylece bir limiti değiştirmek asla yeniden başlatma gerektirmez. Herkese açık test broker'ında çalışır; öneki kendi benzersiz ID'nizle değiştirin.

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/b6a0e4/line3"
specs = {}  # istasyon -> {karakteristik: {"lsl":..., "usl":...}}

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

def on_message(client, userdata, msg):
    station = msg.topic.split("/")[4]
    data = json.loads(msg.payload)

    if msg.topic.endswith("/spec"):
        specs[station] = data
        print("spec loaded for", station, data)
        return

    limits = specs.get(station, {}).get(data["characteristic"])
    if limits is None:
        verdict = "no_spec"
    elif limits["lsl"] <= data["value"] <= limits["usl"]:
        verdict = "pass"
    else:
        verdict = "fail"

    out = {"ts": data["ts"], "serial": data["serial"],
           "characteristic": data["characteristic"], "value": data["value"],
           "verdict": verdict}
    client.publish(f"{PREFIX}/{station}/quality/verdict", json.dumps(out), qos=1)
    if verdict != "pass":
        print("NOT PASS", out)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="qc-checker-b6a0e4")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Test etmek için komut satırından bir spesifikasyon ve bir ölçüm yayınlayın:

mosquitto_pub -h broker.connectmq.com -p 1883 -i spec-b6a0e4 -q 1 -r \
  -t "connectmq/demo/b6a0e4/line3/station40/quality/spec" \
  -m '{"bore_diameter_mm": {"lsl": 21.990, "usl": 22.020}}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i gauge-b6a0e4 -q 1 \
  -t "connectmq/demo/b6a0e4/line3/station40/quality/measurement" \
  -m '{"ts":"2026-10-16T09:31:07Z","serial":"A3-2610-004812","characteristic":"bore_diameter_mm","value":22.012}'

Basit limitler için koda hiç gerek yoktur: ConnectMQ portalının eşik uyarı kuralları sayısal bir alanı izleyebilir ve her sapmayı uyarı günlüğüne kaydedebilir. Kod tabanlı servis, limitler reçeteye bağlı olduğunda veya kararların diğer sistemler için geri yayınlanması gerektiğinde kullanışlı hale gelir.

Geçti/Kaldının Ötesinde: Sapmayı Erken Yakalamak

Spesifikasyon içindeki bir parça bile bir uyarı olabilir. Bir takım aşındığı için delik çapları üst limite doğru kayıyorsa, geçti/kaldı kontrolleri ilk hataya kadar yeşil kalır. İstatistiksel proses kontrolü bu sorunu tek tek parçalar yerine proses davranışını izleyerek çözer; her parça hâlâ geçerken trendleri, kaymaları ve artan değişkenliği tespit eder. Gerçek zamanlı SPC eğitimi kontrol kartlarını tam olarak bu ölçüm akışının üzerine kuruyor.

Proses tarafındaki sinyaller de yardımcı olur. İş mili sıcaklığıyla ilişkili olarak artan bir delik çapı termal genleşmeye işaret eder; kesim sayısıyla ilişkili olan ise çözüm olarak takım aşınması izlemeye işaret eder.

İzlenebilirlik Bedavaya Gelir

Her mesaj bir seri numarası taşıdığı için akışı bir veritabanında saklamak size parça başına bir kalite kaydı verir: onu hangi istasyonun, hangi ölçü aletiyle, hangi reçete ve proses koşulları altında ölçtüğü. Bir müşteride hata bulunduğunda "aynı koşullar altında başka hangi parçalar üretildi" sorusunu dakikalar içinde yanıtlayabilirsiniz. Üretim izlenebilirlik sistemi rehberi veritabanı tarafını, soy ağacını (genealogy) ve olay tasarımını ele alıyor.

Uygulama Kontrol Listesi

1. Tek bir istasyondaki tek bir kritik karakteristikle başlayın; tercihen zaten hurdaya veya şikâyetlere neden olan bir karakteristikle.
2. Ölçümü bağlantılı bir ölçü aleti veya sensörle dijitalleştirin; değerleri yeniden yazmaktan kaçının.
3. Bağlamı edge'de ekleyin: seri numarası, reçete, istasyon, ölçü aleti ID'si, zaman damgası.
4. QoS 1 ile yayınlayın; böylece ölçümler ağ kesintilerinde sessizce kaybolmaz.
5. Spesifikasyonları istasyon ve reçete başına retained mesaj olarak yayınlayın.
6. Bir karar servisi ekleyin ve sonuçları saniyeler içinde hatta gösterin.
7. Her şeyi SPC ve izlenebilirlik için bir veritabanında saklayın; broker bir arşiv değil, bir taşıma katmanıdır.
8. Güvenli hale getirin: özel broker kimlik bilgileri, TLS ve her gateway'e uygulanmış MQTT güvenliği en iyi uygulamaları.

Kalite Omurgasını Barındırmak

Kalite verisi iş açısından kritiktir ve çoğu zaman gizlidir; bu nedenle herkese açık demo broker yalnızca denemeler içindir. Üretimde bir yönetilen MQTT broker, siz broker sunucuları çalıştırmadan her istasyona kimlik doğrulamalı ve şifreli erişim sağlar; ConnectMQ portalının canlı topic gezgini ise her istasyonun beklediğiniz veriyi yayınladığını doğrulamayı kolaylaştırır. Tesis genelindeki bağlam için akıllı üretim rehberini okuyun.

Kalite Verinizi ConnectMQ Üzerinde Çalıştırın

ConnectMQ; TLS, retained mesajlar, ücretli planlarda QoS 1 ve 2, canlı topic gezgini ve eşik uyarı kuralları içeren özel bir MQTT 5 broker sunar. Kredi kartı gerektirmeden app.connectmq.com adresinde ücretsiz Serverless planında bir broker oluşturun ve ilk kalite istasyonunuzu bugün bağlayın.

Sık Sorulan Sorular

Üretimde IoT ile kalite kontrol nedir?

Kaliteyi hatta sürekli olarak ölçmek için bağlantılı sensörlerin, ölçü aletlerinin ve test istasyonlarının kullanılması ve sonuçların operatörler, mühendisler ve kalite sistemleriyle gerçek zamanlı paylaşılmasıdır.

Kalite istasyonları hangi protokolü kullanmalı?

MQTT iyi çalışır, çünkü tek bir ölçüm noktadan noktaya entegrasyonlar olmadan panolar, SPC, veritabanları ve MES tarafından aynı anda tüketilebilir.

Her parçayı ölçmem gerekir mi?

Her zaman değil. Otomatik sensörlerin bunu ucuz hale getirdiği yerlerde her parçayı ölçün, diğer yerlerde manuel örnekleme kontrollerini dijitalleştirin. En büyük kazanç çoğu zaman her ölçüme bağlam eklemekten gelir.

Bunun SPC'den farkı nedir?

Spesifikasyon kontrolleri tek tek parçaları geçti veya kaldı olarak değerlendirir. SPC ise proses davranışını zaman içinde izler ve parçalar hatalı hale gelmeden önce sapmaları ve kaymaları tespit eder.