Bir IIoT kavram kanıtı (proof of concept, PoC), kısa ve sabit bir sürede gerçek tesis verisiyle tek bir iş sorusunu yanıtlamalıdır; kapsamı dar tutarsanız 30 gün yeterlidir. Bu rehberde haftalık bir plan, başlamadan önce üzerinde uzlaşılması gereken başarı metrikleri, bir gateway, yönetilen bir MQTT broker ve bir panodan oluşan hafif bir teknoloji yığını ve donanım daha gelmeden veri hattını kurabilmeniz için çalışan bir simülatör bulacaksınız.
IIoT Pilotlarının Çoğu Neden Tıkanır?
Endüstriyel IoT pilotları nadiren teknoloji çalışmadığı için başarısız olur. Kapsam "tüm hattı bağlayalım"a büyüdüğü için, başarının neye benzediği konusunda kimse uzlaşmadığı için ya da pilot, onaylanması aylar süren altyapıya bağlı olduğu için tıkanırlar. Sonuç, meşhur pilot arafıdır: bir kez etkileyen ve bir daha asla kullanılmayan bir demo.
İyi bir kavram kanıtı bunun tam tersidir. Bitirilebilecek kadar küçük, sahadaki birinin sonucunu isteyeceği kadar önemli ve başarılı olursa yeniden yazılmadan ölçeklenebilecek bileşenler üzerine kurulmuştur.
1. Adım: Dar ve Değerli Bir Kapsam Seçin
Belirli bir kişinin yanıtlanmasına ihtiyaç duyduğu tek bir soru seçin. İyi örnekler:
- "Hücre 3'teki darboğaz CNC neden ve ne kadar süre duruyor?"
- "Tesis gece boştayken kompresör çalışıyor mu?"
- "Fırın 2 sıcaklık bandını ne sıklıkla aşıyor?"
Ardından kapsamı bilinçli olarak sınırlayın:
- Bir ila üç makine, ideal olarak aynı tipte.
- Durum, parça sayısı, akım ve bir alarm gibi üç ila on sinyal.
- Yalnızca okuma. Kavram kanıtında PLC'lere yazma yok.
- İsmi belli kişilerin kullandığı tek bir pano.
Hedef makinenizin ağ arayüzü yoksa bunun yerine ek sensörler planlayın. Eski makinelerin IoT için güçlendirilmesi rehberimiz akım pensleri ve parça sayaçlarını ele alıyor.
2. Adım: 1. Günden Önce Başarı Metriklerinde Uzlaşın
Metrikleri yazıya dökün ve tesis müdürüne imzalatın. Teknik ve iş ölçütlerini karıştırın.
| Metrik | Örnek hedef | Nasıl ölçülür |
|---|---|---|
| Veri bütünlüğü | Üretim dakikalarının en az %98'inde veri mevcut | Zaman serisindeki boşluklar |
| Gecikme | Makine durumu 5 saniye içinde panoda görünür | Makinenin başında kronometreyle karşılaştırma |
| Doğruluk | Duruş olayları operatör kaydıyla eşleşir | Bir hafta boyunca yan yana karşılaştırma |
| Benimsenme | Vardiya amiri panoyu her gün kontrol eder | Sorun veya pano erişimini kontrol edin |
| İçgörü | Veri sayesinde en az bir aksiyon alınır | Belgelenmiş karar |
| Makine ekleme eforu | Ek makine başına bir günden az | Son eklemenin süresini ölçün |
Yukarıdaki hedefler örnektir. Kendi hedeflerinizi belirleyin ama ölçülebilir olsunlar. "IIoT'nin değerini göstermek" bir metrik değildir. Pek çok ekip iş gerekçesi için beklenen geri ödemeyi de kayıt altına alır; IIoT yatırım getirisi yazımız bunun dürüstçe nasıl çerçeveleneceğini açıklıyor.
3. Adım: Hafif Bir Teknoloji Yığını Seçin
Bir platform inşa etme isteğine direnin. Bir kavram kanıtının dört şeye ihtiyacı vardır:
- Bir veri kaynağı. Bir protokol gateway'i üzerinden makinenin PLC'si veya bir mikrodenetleyici üzerinden ek sensörler.
- Bir edge gateway. Kaynağı okuyup MQTT yayımlayan Node-RED, bir Python betiği veya ticari bir gateway çalıştıran küçük bir endüstriyel PC ya da Raspberry Pi.
- Bir broker. Kimsenin ilk haftayı bir sunucu kurup güvenli hâle getirerek geçirmemesi için yönetilen bir MQTT broker.
- Bir pano. Node-RED Dashboard, küçük bir abonenin beslediği Grafana veya ilk günler için broker'ın kendi panosu.
Bu, IIoT mimarisi referansımızda anlatılan katmanlı modelin aynısıdır; yalnızca her katmanda tek bir bileşen vardır. Her katman MQTT konuştuğu için her parça daha sonra diğerlerine dokunmadan değiştirilebilir.
30 Günlük IIoT Kavram Kanıtı Planı
| Hafta | Hedef | Temel faaliyetler | Çıkış kriteri |
|---|---|---|---|
| 1 | Temeller | Kapsamı ve metrikleri teyit edin, ağ yolunu çıkarın, dışa giden 8883 için güvenlik duvarı kuralı talep edin, broker oluşturun, topic adlarını tanımlayın, simülatörü çalıştırın | Simüle veri bir panoda görünür |
| 2 | Gerçek veri | Gateway'i kurun, PLC'ye veya sensörlere salt okunur bağlanın, broker'a yayımlayın, değerleri HMI ile doğrulayın | Tüm pilot makinelerden canlı veri |
| 3 | Faydalı hâle getirin | Panoyu operatörlerle birlikte oluşturun, durum sürelerini ve duruş listesini ekleyin, eşik uyarıları tanımlayın | Vardiya amiri panoyu her gün kullanır |
| 4 | Kanıtlayın ve karar verin | Metrikleri ölçün, manuel kayıtlarla karşılaştırın, eforu ve dersleri belgeleyin, sonuçları sunun | Rakamlarla desteklenen devam veya dur kararı |
- haftadaki ağ çalışması için IIoT bağlantı kontrol listesi size kesin kuralları ve test komutlarını verir.
Donanım Gelmeden Veri Hattını Kurun
Donanım ve güvenlik duvarı onayları çoğu zaman bir hafta veya daha uzun sürer. Beklemeyin. Public MQTT test broker üzerinde bir simülatörle ilk gün tüm veri hattını kurun; böylece gerçek gateway devreye girdiğinde simülatörün yerini almış olur.
import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
POC_ID = uuid.uuid4().hex[:6]
BASE = f"connectmq/demo/{POC_ID}/plant1/cell3"
MACHINES = ["cnc01", "cnc02"]
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"poc-sim-{POC_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
print(f"Subscribe to: {BASE}/#")
state = {m: {"state": "RUNNING", "parts": 0} for m in MACHINES}
while True:
now = datetime.now(timezone.utc).isoformat(timespec="seconds")
for m in MACHINES:
s = state[m]
# Rastgele durum değişiklikleri: çoğunlukla çalışıyor, bazen boşta veya durmuş
r = random.random()
new_state = "RUNNING" if r < 0.85 else ("IDLE" if r < 0.95 else "STOPPED")
if new_state != s["state"]:
s["state"] = new_state
client.publish(f"{BASE}/{m}/state",
json.dumps({"value": new_state, "ts": now}),
qos=1, retain=True)
if s["state"] == "RUNNING":
s["parts"] += 1
client.publish(f"{BASE}/{m}/parts",
json.dumps({"value": s["parts"], "ts": now}),
qos=1, retain=True)
amps = round(random.uniform(8, 12) if s["state"] == "RUNNING" else random.uniform(0.5, 2), 2)
client.publish(f"{BASE}/{m}/current",
json.dumps({"value": amps, "unit": "A", "ts": now}), qos=0)
time.sleep(5)
Akışı başka bir terminalden, betiğin yazdırdığı topic ile izleyin:
mosquitto_sub -h broker.connectmq.com -p 1883 -i poc-watch-$RANDOM \
-t 'connectmq/demo/<POC_ID>/plant1/cell3/#' -v
Simülatör, gerçek gateway'in kullanacağı topic yapısını ve payload biçimini kullanır: retained durum ve parça sayısı, retained olmayan akım okumaları ve her mesajda bir ISO zaman damgası. Panonuzu buna göre oluşturun. Gateway hazır olduğunda panoyu ve gateway'i TLS ve portaldaki kimlik bilgileriyle özel broker'ınıza geçirin. Public broker herkes tarafından okunabildiği için yalnızca geliştirme amaçlıdır.
30 Gün Boyunca Kim Ne Yapar?
Bir kavram kanıtının yönlendirme komitesine değil, rolleri net küçük bir ekibe ihtiyacı vardır. Genellikle üç veya dört kişi yeterlidir:
- Sponsor, çoğu zaman tesis veya üretim müdürü, iş sorusunun sahibidir ve 30. günde devam veya dur kararını verir.
- Kontrol mühendisi, makinedeki her şeyin sahibidir: hangi tag'lerin veya sensörlerin okunacağı, salt okunur erişim ve değerlerin HMI ile doğrulanması.
- IT veya veri sorumlusu, ağ yolunun, broker kimlik bilgilerinin ve panonun sahibidir.
- Son kullanıcı, tipik olarak bir vardiya amiri veya bakım sorumlusu, 3. haftadan itibaren panoyu her gün test eder ve işe yarayıp yaramadığını dürüstçe söyler.
Haftada iki kez on beş dakikalık bir durum toplantısı yapın. İki günden fazla tıkanan her şey doğrudan sponsora gider, çünkü 30 günlük bir planda onay beklemeye ayrılmış pay yoktur.
Kavram Kanıtında Sık Yapılan Hatalar
- İşe en zor makineyle başlamak. Erişilebilir bir arayüzü ve iş birliğine açık bir sahibi olan makineyle başlayın.
- Operatörleri dahil etmemek. Operatörler panonun oluşturulmasına dahil olmadıysa onu kullanmazlar; benimsenme de bir başarı metriğidir.
- Her şeyi toplamak. İki bin tag pilotu yavaşlatır ve içgörüyü bulmayı zorlaştırır. Sorunuzu yanıtlayan sinyallerle başlayın.
- Sıkıcı metrikleri atlamak. Veri bütünlüğü ve gecikme, ölçeklemeden önce IT ve OT ekiplerinin soracağı şeylerdir. Ölçün.
- Kullanıp atılacak altyapı kurmak. Birinin dizüstü bilgisayarındaki broker, ölçeklemek için yeniden kurulmak zorundadır. Üretime geçişi taşıyabilecek bir şey kullanın.
Kavram Kanıtından Yaygınlaştırmaya
Pilot başarılı olursa sıradaki soru, ne kadar hızlı makine ekleyebileceğinizdir. Temiz bir topic hiyerarşisi ve plana göre ölçeklenen bir broker ile onuncu makineyi eklemek ikinciyi eklemekle aynıdır. ConnectMQ, 30 günlük bir pilotu rahatça karşılayan ücretsiz Serverless planla (25 bağlantıya kadar, QoS 1'e kadar, 256 KB mesaj) başlamanıza ve yaygınlaştırma büyüdükçe QoS 2 ve shared subscription içeren ücretli Serverless'a ya da bir Dedicated kümeye topic'leri veya client kodunu değiştirmeden geçmenize olanak tanır. Portalın canlı topic explorer'ı, ISA-95 cihaz görünümü ve eşik uyarı kuralları 2. ve 3. haftaları doğrudan destekler. Pilotun ötesindeki yolculuğun tamamı için MQTT ile Endüstriyel IoT rehberini okuyun.
30 Günlük Pilotunuzu ConnectMQ'da Başlatın
app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun. İlk gün simülatörü kendi ConnectMQ broker'ınıza karşı çalıştırın, donanım siparişteyken panoyu oluşturun ve 30. güne gerçek rakamlarla ulaşın.
Sık Sorulan Sorular
Bir IIoT kavram kanıtı ne kadar sürmeli?
Dar bir soruya sahip bir ila üç makine için 30 gün civarı gerçekçidir. Daha uzun pilotlar karar üretmeden kapsam olarak büyüme eğilimindedir.
Bir IIoT kavram kanıtının maliyeti nedir?
Çoğunlukla insanların zamanı, artı bir gateway ve muhtemelen sensörler. Ücretsiz bir yönetilen broker katmanı ve Node-RED gibi açık kaynak araçlar yazılım maliyetini düşük tutar.
Bir pilot kaç makine içermeli?
Bir ila üç, ideal olarak aynı tipte. Bu, pilotu bir yaygınlaştırmaya dönüştürmeden veri yolunu ve değeri kanıtlamaya yeter.
Başarılı bir kavram kanıtından sonra ne olur?
Makine başına belgelenmiş eforu ve ölçülen metrikleri kullanarak aşamalı bir yaygınlaştırma planlayın. Aynı topic hiyerarşisini ve broker'ı koruyun; böylece pilot, atılan bir deneme değil ilk aşama olur.
