Yüksek performanslı IIoT için uç bilişim desenleri

Endüstriyel veri akışlarında uç bilişim desenleri

Uç bilişim, veri toplama, ara belleğe alma, dönüştürme ve karar destek işlerinden bir kısmını prosesin hemen yanına taşır. Gecikme, kesilip gelen bağlantılar, büyük veri hacmi ya da tesisin kendi başına çalışabilmesi gereği tamamen merkezî bir tasarımı uygunsuz kıldığında bu yaklaşım değer kazanır.

Sahada ağ her zaman erişilebilir değildir, gecikme dalgalanır ve yüksek frekanslı sinyaller merkeze giden bağlantının kapasitesini ya da bütçesini aşabilir. Güvenlik açısından kritik kontrol PLC'de ve emniyet sistemlerinde kalır. Uç yazılım bu sınırı aşmadan izlemeyi ve operasyon süreçlerini destekler.

Aşağıdaki beş desen her yerde uygulanacak hazır kalıplar değil, tasarım seçenekleridir. Nasıl davranacakları ara bellek kapasitesine, bağlantı bileşenlerinin alındı onayı (acknowledgement) mekanizmasına, iş yüküne, ağ yapısına ve kurtarma tasarımına bağlıdır. Devreye alma ve yetkilendirme konularına genel bir bakış için endüstriyel uç platformu sayfasından başlayabilirsiniz.

Beş desene hızlı bakış

Sonuçlar iş yüküne, donanım kapasitesine ve kurulum yapısına bağlıdır.

Uç bilişim neden önemli?

Bir yanda seyrek okunan proses değerleri, bir yanda olay sinyalleri, öbür yanda yüksek frekanslı arıza teşhis verileri olan bir tesis düşünün. Bütün sinyallere aynı şekilde davranırsanız tesisin dış bağlantısı tıkanabilir ya da gereksiz yere depolama maliyeti oluşur. Doğru tasarım ölçmekle başlar: veri noktası sayısı, örnekleme sıklığı, mesaj boyutu, ne kadar kesintiye dayanılabileceği ve arıza incelemesi için ne kadar ayrıntı gerektiği.

Uç bilişim bu sorunu veriyi yerinde süzerek, özetleyerek ve işleyerek çözer; merkeze yalnızca anlamlı özetler gider. Üretim ortamında bu yaklaşım, tek başına yürütülen bir Edge Gateway projesi olarak değil, daha kapsamlı bir endüstriyel veri platformunun parçası olarak en iyi sonucu verir.

Desen 1: Uçta ara belleğe alma

Her veri noktası değişikliğinde canlı bir bağlantıya muhtaç kalmak yerine uç katman, kaynak ile merkezdeki bütün sistemler arasında yerel bir ara bellek tutar. Bu bölüm kısa özettir; ara belleğin boyutlandırılması, yeniden gönderim ve sonradan tamamlama Uçta geçmiş veri nasıl korunur? Ara bellek, depola ve ilet, sonradan tamamlama rehberinde ayrıntılı olarak anlatılıyor.

Nasıl çalışır?

• Ham sensör verisi Modbus, S7 ya da OPC UA üzerinden Edge Gateway'e gelir.
• Bir sonraki durak veriyi kabul edemediği sürece akış yerel ve kalıcı bir ara bellekte bekler.
• Filtreler (eşik, ölü bant, sıçrama bastırma) veri tesisten çıkmadan önce hacmi azaltabilir. Özetleme gerekiyorsa bu, ayrıntı kaybını da beraberinde getiren ayrı bir tasarım kararıdır.
• Merkeze yalnızca veriyi kullanan sistemlerin gerçekten ihtiyaç duyduğu bilgi gönderilir.

Proxus'ta ara bellek, Edge Gateway sürecinin yanında çalışan bir mesajlaşma konteynerinde tutulur; uç tarafta veritabanı yoktur. Merkez sunucuya gönderilecek veri burada varsayılan olarak 48 saat saklanır (her Edge Gateway için 30 güne kadar ayarlanabilir) ve özgün zaman damgalarıyla yeniden gönderilir. Proxus kaynakta değerleri ölçekler, dönüştürür ve filtreler; uçta özetleme (aggregation) yaptığını iddia etmez.

Operasyona katkısı

• Veri kaybı riski azalır: Kesinti sırasında ara bellek yerel diske yazılır.
• Veri yeniden gönderilebilir: Bağlantı geri geldiğinde ara bellekteki uygun veri, özgün zaman damgalarıyla yeniden gönderilebilir. Verinin eksiksiz ve doğru sırada ulaşması kapasiteye, saklama süresine, alındı onaylarına ve hedef sistemin toparlanma davranışına bağlıdır.

Desen 2: Yerel karar verme

Bazı kararlar bekleyemez. Devreye girmesi 200 ms süren bir güvenlik alarmı, sahada başlı başına bir risktir.

Uçta verilen kararlara örnekler

• Bakım uyarısı: Makine sıcaklığı 85°C'yi geçer → hemen yüksek öncelikli bir bakım kaydı açılır.
• Işıklı kule: Hat 30 saniyeden uzun süre durur → ışıklı ve sesli uyarı devreye girer.
• Yedek sensöre geçiş: Ana basınç sensörü arızalanır → sistem kendiliğinden yedek sensöre geçer.

Proxus'ta uygulama

Proxus'ta bu kararlar Edge Gateway'de çalışan alarm kurallarıyla verilir ve ağ kesildiğinde de çalışmaya devam eder.

1. yol: İfade kuralları (kod yazmadan) Proses mühendisleri eşikleri ve koşulları ifade olarak tanımlar. Anomali kuralları Z-skoru, IQR, hareketli ortalama, değişim hızı, kayma (drift), sabit kalma (flatline) ve veri boşluğu tespitini kapsar. Amaç, olayı ağa olabildiğince az bağımlı kalarak yerinde ele almaktır. Sözde kodla:

IF Temperature > 85°C AND NOT(Alarm_Triggered)
THEN Publish MQTT Alert "Line1/Maintenance/ThermalWarning"
AND Trigger Webhook "Create_SAP_WorkOrder"

2. yol: C# fonksiyonları Daha özel ilişkilendirmeler için geliştiriciler Proxus SDK ile C# fonksiyonları yazar; bu fonksiyonlar merkez sunucuda derlenip Edge Gateway'lere dağıtılır. Birden fazla sinyali bir arada değerlendiren, doğrulama pencereleri uygulayan ve bir olayın yayınlanmasına, üst kademeye bildirilmesine ya da yok sayılmasına karar veren yerel mantık bu şekilde kurulabilir. Burada önemli olan SDK'nın ayrıntıları değil, mimari sınırdır: Mantık yerelde çalışır, böylece hiçbir eylem buluta gidip gelen bir isteği beklemez.

Desen 3: Birden çok hedefe dağıtım

Endüstriyel veriyi nadiren tek bir sistem kullanır. Bir tesis aynı veriyi genellikle şu sistemlerin hepsine birden göndermek zorundadır:

• Bulut analitiği (makine öğrenmesi)
• Zaman serisi veritabanları (panolar)
• Mesajlaşma sistemleri (Data Lake)
• Kurumsal sistemler (SAP, Oracle)

Noktadan noktaya bağlantı kâbusu

Ekipler geleneksel olarak her sistem için ayrı bir bağlantı yazar: PLC → Cloud, PLC → InfluxDB, PLC → SAP. Bu da ciddi bir bakım yükü getirir ve verinin sistemler arasında tutarsız olma riskini artırır.

Proxus ile dağıtım

PLC → Edge Gateway → Proxus UNS (MQTT Broker)
 ├─→ Cloud Analytics (Subscribes to Topic)
 ├─→ TimescaleDB (Subscribes to Topic)
 └─→ SAP (REST target)

Sonuç: Bütün sistemler aynı güvenilir kaynaktan beslenir. PLC'ye ya da Edge Gateway'e dokunmadan yeni sistemler eklenebilir. Kullanılabilen hedef türleri, InfluxDB ve SQL Server'dan Apache Kafka ve Azure IoT Hub'a kadar, entegrasyonlar sayfasında listeleniyor.

Desen 4: Önbellekleme ve akıllı birleştirme

Her veri aynı bant genişliği önceliğini hak etmez.

Bu kademeler bir tasarım desenidir, ürün özellikleri listesi değildir. Proxus'ta uç katman değerleri kaynakta ölçekler, dönüştürür ve filtreler. Ortalama gibi özetler genellikle sonraki aşamada, geçmiş veri deposunda ya da veriyi kullanan sistemde hesaplanır.

Desen 5: Devre kesici ve kontrollü işlev kaybı

Fabrikanın internet bağlantısı kesildiğinde ne olur? Buluta bağımlı IIoT sistemleri çöker ya da zaman aşımı dolana kadar HMI ekranlarını kilitler.

İyi tasarlanmış bir uç katman ise devre kesici gibi davranır:

• Kapalı (normal durum): Veri merkez sunucuya akar.
• Açık (bağlantı koptu): Yeniden bağlanma denemeleri sınırlandırılır, yerel işler merkez bağlantısını beklemeden sürer.
• Yarı açık (toparlanma): Bağlantı yoklanır ve ara bellekteki veri sırasıyla gönderilmeye başlanır.

Proxus'ta merkez sunucuya ulaşılamadığı sürece alarm kuralları Edge Gateway'de çalışmaya devam eder. Veritabanları, MQTT, Kafka, REST ve diğerleri dâhil her veri hedefi için veri, aynı saklama süresiyle Edge Gateway'de kuyruğa alınır. Hedef yeniden erişilebilir olduğunda kuyruk sırasıyla ve en az bir kez (at least once) yazılır. Bu nedenle veriyi kullanan sistem, ara sıra gelebilecek mükerrer kayıtları sorunsuz karşılayabilmelidir.

Sonuç

Doğru mantığı sahaya taşıyan üretim tesisleri daha dayanıklı çalışır, kararları daha hızlı verir ve merkeze giden gereksiz trafiği azaltır. Buradaki fayda pazarı ele geçirmekle ilgili bir slogan değildir. Gecikme, bant genişliği ya da kesintiye dayanıklılık önemli olduğunda kritik kararları prosese yakın tutmakla ilgilidir.

Bu yaklaşım ne zaman uygun olmayabilir?

• Seyrek gelen telemetri, tamamen dağıtık bir yapının karmaşıklığına değmeyebilir.
• Küçük, tek hatlık tesisler işe daha basit mimarilerle başlamayı tercih edebilir.
• Eski sistemlerden gelen katı kısıtlar, geçişin aşama aşama yapılmasını gerektirebilir.
• Güvenlik açısından kritik kapalı çevrim kontrol, PLC ve Safety PLC katmanlarında kalmalıdır.

Sonuçlar iş yüküne, donanıma ve ağ yapısına göre değişir.

Sık sorulan sorular

Uç bilişim bulut maliyetini ne kadar düşürür?

Her durumda geçerli, savunulabilir bir yüzde yoktur. Ham ve seçilmiş veri hacmini, depolama sınıfını, saklama süresini, buluttan dışarı veri çıkış yolunu ve sorgu yükünü ölçün. Akıllı filtreleme merkeze giden hacmi azaltabilir, ancak arıza teşhisi için gereken ayrıntıyı da yok edebilir.

Edge Gateway'in kendisi arızalanırsa ne olur?

Bu, seçilen kurulum yapısına, depolamaya, arızanın nasıl tespit edildiğine, kaynak bağlantısının hangi cihazda olduğuna ve kurtarma prosedürüne bağlıdır. Depola ve ilet (store and forward) yaklaşımı ara bellekteki uygun veri için kayıp riskini azaltır. Ancak Edge Gateway'in yeniden ayağa kaldırılmasının, yedekliliğin, yedeklemenin ya da denenmiş işletme prosedürlerinin yerini tutmaz.

Uç kuralları PLC mantığının yerini alabilir mi?

Hayır, almamalı da. PLC mantığı deterministik ve güvenlik açısından kritik kontrolü (motor kilitlemeleri, acil duruşlar) üstlenir. Uç kuralları ise daha üst düzeydeki iş mantığını yürütür: OEE hesapları, kestirimci bakım puanlaması, cihazlar arası ilişkilendirme ve kurumsal bildirimler. İki katman birbirini tamamlar.

Kaynaklar

1. IEC 62443: Endüstriyel siber güvenlik standardı; OT ağlarındaki uç kurulumların güvenliği açısından önemlidir.
2. AWS IoT Greengrass / Azure IoT Edge: Bulut sağlayıcılarının uç çerçeveleri; Proxus gibi endüstriyel protokolleri doğrudan konuşan uç platformlarla karşılaştırma yapmak için faydalıdır.
3. ISA-95 / IEC 62264: Kurumsal sistemlerle kontrol sistemlerinin entegrasyonuna dair standart; uç bilişimin çalıştığı hiyerarşi katmanlarını (Seviye 1-2) tanımlar.

İlgili yazılar: Unified Namespace mimarisi için uygulamalı rehberi ya da uçta mantık kurmanın yollarını anlatan yazıyı okuyabilirsiniz.