Uygulama ile platform arasındaki fark
Endüstri 4.0 çözümlerini değerlendiren üreticiler çoğunlukla ağırlığı veri görselleştirmede olan ürünlerle karşılaşır. Bu panolar ciddi bir değer sunar, ama mimariyi planlarken bir IIoT "uygulaması" ile bir IIoT "platformu" arasındaki farkı görmek önemlidir.
Belirli bir sensör grubunu görselleştiren bir yazılım, işe yarar bir IIoT uygulaması olabilir. Bir IIoT platformu ise genellikle bunun üzerine yeniden kullanılabilir bağlantı altyapısı, cihaz ya da Edge Gateway yönetimi, veri işleme ve uygulama dağıtımı ekler. Endüstriyel veri platformu ise konuyu bir adım öteye taşır: ortak işletme bağlamı, kurallar ve yetkiler, geçmiş verinin saklanması ve verinin OT ile IT tarafındaki kullanıcılara kontrollü biçimde aktarılması.
Üreticileri değerlendirirken aşağıdaki beş alanı, her duruma uyan bir sertifika listesi olarak değil, sorulacak sorular olarak kullanın. Ne kadar derine inmeniz gerektiği; kaynakların çeşitliliğine, tesis sayısına, işletmede sorumluluğun kimde olduğuna, güvenlik bölgelerine, veriyi kullanan sistemlere ve kurulum modeline bağlıdır.
- 5 bileşen: Bir platformda bulunması gereken temel mimari parçalar
- Ortak temel: İşletme verisini tüm sistemler aynı yerden kullanır
Sonuçlar iş yükü profiline, donanım kapasitesine ve kurulum yapısına bağlıdır.
Fabrika verisi neden sahada kalmalı?
Her iş yükü buluta ya da merkezi bir sunucuya taşınmamalıdır. Nerede çalışacağına gecikme, bant genişliği, kesintiye dayanıklılık, verinin sınıfı, saklama süresi ve işletmedeki sorumluluk karar verir.
Gerçek bir IIoT platformunda genellikle güçlü bir uç bilişim katmanı bulunmalıdır. Bu katman, Modbus'ı MQTT'ye çeviren basit bir protokol dönüştürücüden fazlası olmalıdır. Platform, dünyanın dört bir yanındaki binlerce Edge Gateway'i merkezi bir bulut arayüzünden yönetmenizi sağlamalıdır.
Dünyanın öbür ucundaki bir fabrikada duran Edge Gateway'e, sahaya dizüstü bilgisayarlı bir teknisyen göndermeden yeni protokol sürücüleri yükleyebilmeli, yazılımını güncelleyebilmeli ve veri toplama sıklığını değiştirebilmelisiniz. En önemlisi de uç katman, ağ kesintilerinde veri kaybı riskini en aza indirmek için depola ve ilet desteği sunmalıdır.
Unified Namespace ortak bir işletme modeli sunar
1. montaj hattı → MQTT veri merkezi: Durumu yayınla
Paketleme hattı → MQTT veri merkezi: Durumu yayınla
MQTT veri merkezi → SAP ERP: Abone ol
MQTT veri merkezi → Kestirimci yapay zekâ: Abone ol
Eski usul bir fabrikada sistemler birbirleriyle noktadan noktaya konuşur (spagetti mimarisi). Kalite veritabanı doğrudan PLC ile, ERP ise SCADA ile konuşur.
Bir Unified Namespace, kurallara bağlanmış işletme konularını ve modellerini yetkili kullanıcılara açarak tekrar tekrar yapılan noktadan noktaya eşlemeleri azaltabilir. MQTT sunucusu taşımayı sağlar; veri ağacını kullanılabilir kılan ise konu sahipliği, şema, kimlik, kalite, yetkilendirme ve yaşam döngüsü kurallarıdır. Bu kurallar Unified Namespace mimarisi için uygulamalı rehber yazısında ayrıntılı olarak anlatılıyor.
Platform, ham PLC veri noktalarını (DB4.DBX2.1 gibi) temiz ve anlamı belli varlık modellerine (FactoryA/PressLine1/Temperature gibi) dönüştürecek araçları sunmalıdır. Veriyi taşımak için yalnızca sabit kodlanmış, noktadan noktaya API betiklerine dayanan bir platformda, kurumsal bir temelden beklenen standart veri modelleme yetenekleri eksik olabilir.
Kural motoru veriyi anında aksiyona çevirir
Aksiyona dönüşmeyen veri işe yaramaz. Kritik motorunuzdaki titreşim sensörü güvenli eşiği aştığında ne olacak?
Bir platform alarmlar, olayların zenginleştirilmesi, bildirimler, hesaplamalar ve kurallara bağlı iş akışları için bir kural motoru sunabilir. Sahaya geri yazma ise ayrı bir komut modeli, yetkilendirme, doğrulama, kayıt tutma, zaman aşımı ve emniyet değerlendirmesi gerektirir. Acil durdurmalar ve deterministik kilitlemeler PLC'de ve emniyet sistemlerinde kalır.
Zaman serisi veritabanı veri selini saklar
İlişkisel veritabanları (SQL) personel bordrosunu yönetmek için harikadır, ama yüksek frekanslı sensör okumalarıyla yüklendiklerinde hızla darboğaza dönüşebilir.
Bir IIoT platformunda, çok yoğun veri akışını kaldıracak şekilde tasarlanmış, platformla sıkı entegre bir zaman serisi veritabanı (TSDB) bulunmalıdır. Bu veri deposu, yapay zekâ eğitimi, raporlama ve anomali tespiti için geçmiş veriye anında erişim sağlamalıdır. Ayrıca veri saklama kurallarını kendiliğinden uygulamalıdır (örneğin disk alanından tasarruf etmek için milisaniyelik ham veriyi 30 gün, 15 dakikalık ortalamaları ise 5 yıl saklamak).
Katmanlı savunma ve açıkça çizilmiş güven sınırları
Çalışan bir PLC'yi IT ağına bağladığınız anda, etkisi büyük bir riskin kapısını açmış olursunuz. Bir platform, ancak güvenlik modeli kadar iyidir.
Kurumsal IIoT platformları güvenliği her katmanda uygular:
- Yalnızca dışa doğru bağlantı kuran köprüler: Yüksek güvenlik gerektiren kurulumlarda Edge Gateway, güvenlik duvarında içeri doğru port açılmasını gerektirmemelidir. Veriyi platforma kendisi göndermelidir.
- Rol tabanlı erişim kontrolü (RBAC): İşe yeni başlayan bir stajyerin yalnızca 1. hattın panolarını görmesini, 2. hattaki sıcaklık ayar değerlerini değiştirememesini güvenle sağlayabiliyor musunuz?
- Değişiklik kayıtları: Bir kuralı değiştirmek, bir alarmı onaylamak ya da bir yapay zekâ modelinin MCP sorgusu çalıştırması gibi her işlem, mevzuata uyum için kalıcı olarak kayıt altına alınmalıdır.
Proxus bu tablonun neresinde?
Proxus kontrollü ve izlenebilir bir endüstriyel veri katmanı, yani OT ve IT operasyonları için bir endüstriyel veri platformu olarak tasarlandı. Bağlantı bu platformun yalnızca bir parçasıdır; yanında işletme modellemesi, uçta veri işleme, depolama, panolar, kurallar ve kurumsal sistemlere kontrollü veri aktarımı yer alır.
Proxus'u yukarıdaki beş alana göre değerlendirmek için: karşılaştırmalar Proxus'u bağlantı sunucuları, modelleme katmanları, SCADA platformları ve geçmiş veri depolarıyla karşılaştırıyor; fiyatlandırma sayfası maliyetin veri noktasına göre değil, Edge Gateway sayısı ve veri hızına göre nasıl belirlendiğini gösteriyor; sürücü listesi ve entegrasyonlar ise Proxus'un nereden veri okuduğunu ve nereye aktardığını gösteriyor.
Bu yaklaşım ne zaman uygun olmayabilir?
- Düşük frekanslı telemetri, dağıtık bir mimarinin tüm karmaşıklığına değmeyebilir.
- Tek hatlı küçük tesisler önce daha sade mimarileri tercih edebilir.
- Katı eski sistem kısıtları aşamalı bir geçiş gerektirebilir.
- Emniyet açısından kritik kapalı çevrim kontrol, PLC ve emniyet PLC'si 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
IIoT platformunun SCADA'dan farkı nedir?
SCADA sistemleri belirli bir prosesin gerçek zamanlı görselleştirilmesi ve kontrolü için tasarlanır. IIoT platformu ise Edge Gateway'lerin yönetimini, bir Unified Namespace, kural motorlarını, data lake'te kalıcı saklamayı ve kurumsal entegrasyonları kapsayan daha geniş bir veri altyapısı katmanıdır. SCADA, IIoT platformunun verisini kullanan sistemlerden biri olabilir. Ayrıntılı karşılaştırma için SCADA ve UNS yazısına bakın.
IIoT platformu mevcut MES'imin yerini alabilir mi?
Genellikle hayır. IIoT platformu, MES'te eksik olan gerçek zamanlı veri altyapısını sağlayarak MES'i tamamlar. MES sistemlerine temiz ve anlamı belli veri gönderir; MES'in geleneksel olarak dayandığı kırılgan noktadan noktaya entegrasyonların yerini alır.
Bir IIoT platformundan hangi protokol desteğini beklemeliyim?
Hedef tesislerde gerçekten bulunan protokollerden ve cihaz davranışlarından yola çıkın. Sürücülerin kapsamını, sorgulama ve abonelik davranışını, veri türü desteğini, kalitenin nasıl ele alındığını, güvenliği ve hangi sürümde ya da pakette sunulduğunu doğrulayın. Yayınlanmış ürün kapsamı için Proxus bağlantı sayfasına ve sürücü listesine bakın.
Kaynaklar
- IEC 62264 (ISA-95): Kurumsal sistemlerle kontrol sistemlerinin entegrasyonu; bir IIoT platformunun kapsadığı işlevsel katmanları tanımlar.
- MQTT v5.0 OASIS Standard: UNS'in taşıma katmanı olarak kullanılan yayınla-abone ol protokolü. mqtt.org
- Anthropic, "Model Context Protocol": Yapay zekâ modellerini dış veri kaynaklarına güvenli biçimde bağlamak için açık spesifikasyon; 5. bileşen (güvenlik) ile ilgilidir. MCP spesifikasyonu
Son güncelleme: 6 Ağustos 2026