IoT ile Soğuk Zincir İzleme: Hücresel MQTT Telemetrisi ve Sıcaklık Sapması Uyarıları

Soğuk zincir izleme, soğutulmuş gıdaların, aşıların veya biyolojik ürünlerin depo ile müşteri arasında sıcaklık aralığının dışına hiç çıkmadığını kanıtlamak ve çıktıklarında hızla müdahale etmekle ilgilidir. Bu makalede, sıcaklık verisini hücresel MQTT üzerinden gönderen, kapsama dışı bölgelerde okuma kaybetmeden ayakta kalan ve her anlık sıçramada değil, bir sınırın ne kadar süre aşıldığına göre sapma uyarısı üreten, frigorifik kamyonlar ve konteynerler için bir izleme sistemi tasarlayacaksınız.

Soğuk Zincir İzlemenin Kanıtlaması Gerekenler

Taşımacılıkta sıcaklık kaydının iki hedef kitlesi vardır. Operasyon personelinin canlı bilgiye ihtiyacı vardır; böylece sürücü, yük kaybolmadan önce aralık kalmış bir kapıyı ya da arızalanan bir reefer ünitesini düzeltebilir. Kalite personelinin ise sefer sonrasında, çoğunlukla müşterileri ve iyi dağıtım uygulamaları gerekliliklerini karşılamak için, her okumayı zamanı ve konumuyla gösteren eksiksiz bir kayda ihtiyacı vardır.

Bu iki ihtiyaç tüm tasarımı yönlendirir:

Araçtaki Donanım

Tipik bir kurulum üç parçadan oluşur:

1. Yük alanında, genellikle iki veya daha fazla sıcaklık probu: biri evaporatörün yakınında, biri de sıcak havanın girdiği arka kapıların yanında. Palet düzeyinde takip için kablosuz BLE kaydediciler yaygındır; kablolu problar sabit reefer kurulumlarına uygundur.
2. LTE-M, NB-IoT veya LTE modemli ve GPS'li bir telematik gateway. Bu ticari bir ünite ya da hücresel HAT'li küçük bir Linux kartı olabilir. Probları okur, veriyi tamponlar ve MQTT ile yayınlar.
3. Her sıcaklık artışının bir açılışla ilişkilendirilebilmesi için kapı kontak sensörleri.

Broker ile konuşan tek cihaz gateway'dir. BLE palet kaydedicileriyle dolu uzun bir dorse bile tek bir MQTT bağlantısına dönüşür.

Soğuk Zincir İzleme için Topic Tasarımı

Seferlere göre değil, filo varlığına göre düzenleyin; seferler payload içinde meta veridir:

coldchain/<fleet>/<asset-id>/telemetry        {"ts":1760600000,"t_front":3.8,"t_rear":4.6,"door":"closed","lat":41.01,"lon":28.97,"trip":"TR-8812"}
coldchain/<fleet>/<asset-id>/status           retained {"online":true,"fw":"1.4.2","battery_v":12.6}
coldchain/<fleet>/<asset-id>/alarm            {"type":"excursion","probe":"t_rear","max":9.4,"duration_s":1260,"trip":"TR-8812"}
coldchain/<fleet>/<asset-id>/config           retained {"min":2.0,"max":8.0,"grace_s":900}

config topic'ini retained tutmak şık bir yöntemdir. Gateway bağlandığında buna abone olur; böylece bir yükü soğutulmuştan dondurulmuşa çevirmek, sevkiyat sisteminden tek bir retained yayından ibarettir ve yeniden başlayan bir gateway sınırlarını anında geri alır.

Sakla-ve-İlet Özellikli Gateway Kodu

Otoyollarda, tünellerde ve limanlarda hücresel kapsama kesintilidir. Gateway çevrimdışıyken örneklemeye devam etmeli ve bağlantı geri geldiğinde her şeyi göndermelidir. Aşağıdaki Python taslağı paho-mqtt 2.x, MQTT 5 ve gateway üzerinde bir SQLite kuyruğu kullanır. Herhangi bir bilgisayarda deneyebilmeniz için herkese açık test broker'ını hedefler; read_probes() fonksiyonunu gerçek sensör kodunuzla değiştirin.

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

PREFIX = "connectmq/demo/f2q7b5"          # kendi rastgele önekiniz
ASSET = "TRK-104"
BASE = f"{PREFIX}/coldchain/fleet1/{ASSET}"
SAMPLE_EVERY = 60                          # saniye
db = sqlite3.connect("buffer.db")
db.execute("CREATE TABLE IF NOT EXISTS q (id INTEGER PRIMARY KEY, payload TEXT)")
connected = False
limits = {"min": 2.0, "max": 8.0, "grace_s": 900}

def read_probes():
    # gerçek sensörlerle değiştirin; buradaki değerler soğutulmuş bir yükü simüle eder
    return {"t_front": round(random.uniform(3, 5), 1), "t_rear": round(random.uniform(3.5, 6), 1),
            "door": "closed"}

def on_connect(client, userdata, flags, reason_code, properties):
    global connected
    connected = not reason_code.is_failure
    if connected:
        client.subscribe(f"{BASE}/config", qos=1)
        client.publish(f"{BASE}/status", json.dumps({"online": True}), qos=1, retain=True)

def on_disconnect(client, userdata, flags, reason_code, properties):
    global connected
    connected = False

def on_message(client, userdata, msg):
    limits.update(json.loads(msg.payload))

def flush(client, batch=50):
    rows = db.execute("SELECT id, payload FROM q ORDER BY id LIMIT ?", (batch,)).fetchall()
    for row_id, payload in rows:
        info = client.publish(f"{BASE}/telemetry", payload, qos=1)
        info.wait_for_publish(timeout=10)
        if not info.is_published():
            return                           # bağlantı koptu; kalan satırları tut
        db.execute("DELETE FROM q WHERE id = ?", (row_id,))
        db.commit()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"gw-{ASSET}-f2q7b5",
                     protocol=mqtt.MQTTv5)
client.will_set(f"{BASE}/status", json.dumps({"online": False}), qos=1, retain=True)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=2, max_delay=120)
client.connect_async("broker.connectmq.com", 1883, keepalive=120)
client.loop_start()

while True:
    reading = {"ts": int(time.time()), "trip": "TR-8812", **read_probes()}
    db.execute("INSERT INTO q (payload) VALUES (?)", (json.dumps(reading),))
    db.commit()
    if connected:
        flush(client)
    time.sleep(SAMPLE_EVERY)

Her okuma önce kuyruğa girer ve yalnızca broker onu QoS 1 ile onayladıktan sonra silinir. Bu, tamponu gerçeğin kaynağı yapar: güç kaybı, yeniden başlatmalar ve uzun kapsama dışı bölgeler boşluk oluşturamaz; ts alanı da ölçümün ne zaman geldiğini değil, ne zaman alındığını kaydeder. Teslimat garantileri hakkında daha fazlası için MQTT QoS seviyeleri yazımıza bakın.

Gürültüyü Görmezden Gelen Sapma Uyarıları

"Sıcaklık 8 °C'nin üzerindeyse uyar" gibi saf bir kural, bir teslimat noktasında kapılar her açıldığında ya da evaporatör her defrost yaptığında tetiklenir. Gerçek soğuk zincir uyarısı süreye bakar: yalnızca bir prob, bir tolerans süresinden daha uzun süre aralık dışında kaldığında alarm verir.

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/f2q7b5"
LIMITS = {"min": 2.0, "max": 8.0, "grace_s": 900}
state = {}   # (asset, probe) -> aralık dışına ilk çıkış zaman damgası

def check(client, asset, probe, value, ts):
    key = (asset, probe)
    out = value < LIMITS["min"] or value > LIMITS["max"]
    if not out:
        state.pop(key, None)
        return
    start = state.setdefault(key, ts)
    if start is not None and ts - start >= LIMITS["grace_s"]:
        alarm = {"type": "excursion", "probe": probe, "value": value, "since": start,
                 "duration_s": ts - start}
        client.publish(f"{PREFIX}/coldchain/fleet1/{asset}/alarm", json.dumps(alarm), qos=1)
        state[key] = None   # sapma başına bir kez alarm; aralığa dönünce sıfırla

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

def on_message(client, userdata, msg):
    asset = msg.topic.split("/")[-2]
    r = json.loads(msg.payload)
    for probe in ("t_front", "t_rear"):
        if probe in r:
            check(client, asset, probe, r[probe], r["ts"])

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

Ölçüm zaman damgasını kullandığı için dedektör tamponlanmış veriyi doğru işler: bir tünelde yaşanan yirmi dakikalık bir sapma, birikmiş veri geldiğinde de yirmi dakika olarak tanınır. Canlı bir değer üzerindeki basit sabit sınırlar için portaldaki eşik uyarı kuralları hızlı bir başlangıçtır; bunun gibi süre mantığı ise kendi abonenize veya Node-RED'e aittir.

Filoyu İzlemek

Test sırasında her şeye abone olun:

mosquitto_sub -h broker.connectmq.com -p 1883 -i ops-f2q7b5 -t "connectmq/demo/f2q7b5/coldchain/#" -v

Herkese açık MQTT test broker'ı bu prototip için uygundur; ancak sevkiyat verisi ve müşteri konumları herkesin okuyabildiği bir alandan geçmemelidir. Üretimdeki gateway'ler 8883 portunda TLS ve portalda oluşturulan kimlik bilgilerini kullanmalıdır.

Hücresel Bağlantı İpuçları

1. Payload'ları küçük tutun. Kısa anahtarlar ve dakikalık örnekler veri paketlerini makul tutar; paketiniz mesaj başına ücretlendiriyorsa mesaj başına birkaç okumayı toplu gönderin.
2. Cömert bir keep-alive ayarlayın. İki ila beş dakikalık değerler, bağlantı kopmasının algılanmasını çok geciktirmeden radyo uyanmalarını azaltır.
3. MQTT 5 session expiry kullanın, böylece abonelikler kısa kopmalardan sağ çıkar; bkz. MQTT 5 özellikleri.
4. Yeniden bağlanırken geri çekilin. Üstel gecikmeler, bir baz istasyonu geçişinden sonra ağı yüklenmekten korur.
5. Modemi izleyin. Kapsama dışı bölgeleri teşhis etmek için sinyal gücünü ve ağ tipini status içinde yayınlayın.

Sık Yapılan Hatalar

Yalnızca evaporatörün yanında prob. Bu prob kasadaki en soğuk havayı gösterir ve kapılardaki sıcak bir bölgeyi gizleyebilir. Ürünün en çok risk altında olduğu yerde ölçün.

Sunucu tarafı zaman damgaları. Okumaları vardıklarında damgalarsanız, tamponlanmış bir birikim tek bir dakikaya sıkışır ve sapma süreleri anlamsızlaşır. Her zaman ölçüm anında damgalayın.

Yeniden bağlanma sonrası alarm fırtınaları. Bir saatlik veriyi boşaltan bir gateway aynı anda çok sayıda uyarı tetikleyebilir. Yukarıdaki dedektörün yaptığı gibi sapma başına bir kez alarm verin ve geç gelen alarmları "geçmiş" olarak işaretleyin; böylece sevkiyat sorumluları olayın çoktan bittiğini bilir.

Filo genelinde paylaşılan kimlik bilgileri. Sızan tek bir giriş tüm kamyonları açığa çıkarır. Her gateway'e kendi kimlik bilgilerini ve client ID'sini verin.

Devreye Alma Kontrol Listesi

1. Problar yük alanının en sıcak ve en soğuk noktalarına yerleştirilmiş ve kalibre edilmiş.
2. Kapı sensörleri takılmış ve her telemetri mesajında raporlanıyor.
3. Gateway kalıcı depolamaya tamponluyor ve yalnızca onaydan sonra siliyor.
4. Zaman damgaları senkronize bir saatten (GPS veya NTP) geliyor.
5. Sınırlar varlık başına retained yapılandırma olarak iletiliyor.
6. Ürün kategorisi başına süreye dayalı sapma kuralları.
7. Sefer raporları için her okumayı bir veritabanına yazan kalıcı bir arşiv abonesi.
8. Gateway başına TLS ve benzersiz kimlik bilgileri.

İlgili Kalıplar

Filo izleme, diğer dağıtık IoT sistemleriyle pek çok ortak noktaya sahiptir. Varlık başına gateway fikri, bir akıllı şehir IoT mimarisindeki saha gateway'lerini yansıtır; birçok varlığı canlı durum görünümlerinde toplamak da akıllı otopark IoT yazısında çözülen problemle aynıdır. Kalıcı bir retained durum modeli kurmak için su kaçağı tespiti projemiz retained alarmları daha küçük bir ortamda gösteriyor; IoT otomasyon rehberinde ise daha fazla örnek var.

Soğuk Zincir Telemetrinizi ConnectMQ'da Çalıştırın

Filo telemetrisi, her hücresel ağdan erişilebilen, TLS ile güvenceye alınmış ve günün her saati bakımı yapılan bir broker gerektirir. ConnectMQ; MQTT 5, TLS, oluşturulan kimlik bilgileri ve her kamyonun raporlarını izleyebileceğiniz canlı bir topic gezgini içeren bir yönetilen MQTT broker sunar. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker ile başlayın ve filo büyüdükçe ücretli veya dedicated bir plana ölçeklenin. Barındırma hakkında arka plan bilgisi için bulut MQTT broker yaklaşımını okuyun.

Sık Sorulan Sorular

Frigorifik bir kamyon sıcaklığı ne sıklıkla raporlamalıdır?

Bir ila beş dakikada bir örnekleme tipiktir. Çevrimdışıyken bile bu hızda yerel olarak örnekleyin ve kapsama geri geldiğinde tamponlanmış okumaları gönderin.

Kamyonun sinyali yoksa ne olur?

Gateway, okumaları ölçüm zaman damgalarıyla birlikte yerel depolamada saklar ve bağlandığında bunları sırayla yayınlar; her birini yalnızca broker onayladıktan sonra siler.

Neden tek bir yüksek okuma yerine süreye göre uyarı verilir?

Kapı açılışları ve defrost döngüleri ürüne zarar vermeyen kısa sıçramalara neden olur. Bir tolerans süresi bunları filtrelerken gerçek sapmaları yakalamaya devam eder.

ConnectMQ sıcaklık geçmişini saklıyor mu?

Hayır. ConnectMQ mesajları gerçek zamanlı iletir. Sefer raporları ve denetimler için her okumayı kendi veritabanınıza yazan bir abone çalıştırın.