IIoT Protokolleri

IoT alfabe çorbasıdır. IIoT, IoE, HTTP, REST, JSON, MQTT, OPC UA, DDS ve liste devam eder gider.
IoT’deki büyük zorluk birlikte çalışabilirliktir. Yakın tarihli bir Nexus anketinde, katılımcıların %77’si birlikte çalışabilirliğin IoT’deki en büyük zorluk olduğunu belirtti. Endüstriyel cihazları, BT ve IoT platformlarına bağlamak büyük bir iştir ve çoğu kısaltmaların geldiği yerdir. Bunu başarmak için pek çok protokol var; bazıları özel, bazıları açık standartlar. Hepsi tek IoT protokolü olmak için oynuyor, ancak bunun asla böyle olmayacağı açık. Bu protokoller her biri kendi güçlü ve zayıf yönleriyle birlikte var olacak ve onları nerede ve ne zaman kullanacaklarını anlamak bizim işimiz.
Bu makalede, endüstriyi BT’ye bağlamak için açık standartlara odaklandık ve her biri için kullanım durumları sunmaya çalıştık.
Protokolleri iki kategoride gruplayabiliriz: İstemci / Sunucu (Client / Server), Yayınla / Abone Ol (Publish / Subscribe)
İstemci / Sunucu protokolleri, istemcinin sunucuya bağlanmasını ve talepte bulunmasını gerektirir. Bu modelde, sunucu verileri tutar ve istemciden gelen taleplere cevap verir. Örneğin, istemci bir sıcaklık okuyabilir. Bu, istemcinin sunucuyu önceden bilmesini ve bağlanabilmesini gerektirir.
Yayınlama / abone olma protokollerinde bağlanma ihtiyacı olan cihazlar, ortadaki aracı(broker) üzerinden veriyi konu(topic) bazında yayınlar. Bu verileri kullanacak uygulamalar, broker ile bağlantı kurabilir ve ilgili konudaki verilere abone olabilirler.
Örneğin, bir cihaz her dakika sıcaklığı örnekleyebilir ve saatte bir yayınlayabilir. Veri akışına abone olan bir uygulama, her saat başı bir saatlik, bir dakikalık örnek alır. Bu model, veri üreticisini veri tüketicisinden ayırır.
Altyapınız bilinmediğinde yayınlama / abone olma protokolleri daha uygun olur. Örneğin, uzak bir cihaz ağları değiştirirse veya aralıklarla bağlanabilirliği varsa, çevrimiçi olduğunda cihazın telefonunu aramak ve verilerini yayınlamak daha kolaydır.
Avantaj ve dezavantajları açısından, istemci / sunucu protokolleri daha fazla birlikte çalışabilir ve güvenlidir. Çünkü bunlar noktadan noktaya bağlantılara dayanır. Bununla birlikte, bunlar daha az ölçeklenebilirdir, çünkü noktadan noktaya bağlantıların yönetilmesi daha zordur ve daha fazla kaynak yoğundur.
Altyapınızı biliniyor ve kontrol altındaysa istemci / sunucu protokolleri en iyi şekilde kullanılır … Yayınlama / Abone Olma protokolleri, altyapınız bilinmediğinde daha uygun olur.”
“Yayınlama / abone olma protokolleri daha fazla ölçeklendirilebilir çünkü üreticilerin ve tüketicilerin ayrıştırılması her birinin bağımsız olarak eklenmesine ve kaldırılmasına izin veriyor. Bununla birlikte, bu protokolleri güvence altına almak daha karmaşık, çünkü daha fazla parça var. Üreticinin ve tüketicinin kaybedilmesi nedeniyle verilen birlikte işlerlik sorunları da olabilir.
Örneğin, bir üreticinin gönderdiği mesaj biçimini değiştirmek, tüm tüketicilerin yeni mesaj türüne adapte olmasını gerektirir.”
Artık temel kategorileri anladığımıza göre, istemci / sunucuya bakalım ve protokolleri daha ayrıntılı olarak yayınlayalım / abone olalım.
Protokoller
Tartışacağımız protokoller, endüstriyel cihazları IoT platformlarıyla bir araya getirme potansiyeline sahip. Her protokolü ve ne zaman kullanacağınızı açıklayacağız. İşte kapsayacağımız kısa liste:
• OPCUA • MQTT • DDS
• HTTP (REST/JSON) • CoAP • AMQP
OPC UA
OPC Birleşik Mimari (OPC UA), OPC Vakfı’ndan gelecek nesil bir standarttır. Klasik OPC endüstriyel alanda iyi bilinmektedir ve PLC’lerle iletişim kurmak için standart bir arayüz sağlar.
OPC UA bir istemci/sunucu protokolüdür. İstemciler, endüstriyel ekipmanlara bağlanır, göz atar, okur ve yazarlar. UA, uygulamadan taşıma katmanına olan iletişimi tanımlar ve bu da tedarikçiler arasında birlikte çalışabilir olmasını sağlar. Aynı zamanda oldukça güvenlidir ve iki yönlü mesaj imzalama ve taşıma şifrelemesi kullanır.
OPC UA, endüstriyel alanda geniş bir montaj tabanına sahiptir. PLC ve sensör verilerini, OPC ve OPC UA bağlantılarının zaten mevcut olduğu SCADA ve MES sistemleri gibi mevcut endüstriyel uygulamalara bağlamak için iyi bir çözümdür.
Ancak OPC UA, BT alanı için yeni. BT’deki bazı insanlar diğer BT protokollerine kıyasla UA’nın karmaşıklığından korkuyorlar. Bu karmaşıklığın çoğu, OPC UA’nın endüstriyel bir protokol olmasının bir sonucudur, ancak bu algı IoT platformları ve açık kaynak topluluğu tarafında değişmeye ve OPC UA yavaş yavaş benimsenmeye başladı.
Şimdilik, PLC ve sensör verilerini mevcut SCADA ve MES çözümlerine dahil etmeniz gerektiğinde OPC UA’yı kullanın ve IoT platform sağlayıcıları ve açık kaynak topluluğu tarafından OPC UA’nın benimsenmesinin artışına dikkat edin.
HTTP (REST / JSON)
Köprü Metni Aktarım Protokolü (HTTP – Hypertext Transfer Protocol), BT’de ve web’de her yerde bulunan bağlantısız bir istemci / sunucu protokolüdür. HTTP’yi kullanan sayısız açık kaynak aracı olduğundan ve her kodlama dilinde HTTP kitaplıkları bulunduğundan, kolay erişilebilir.
IoT’deki HTTP’ye odaklanma, istemcilerin sunucudaki kaynaklara isteklerle erişebildikleri durumsuz bir model olan Temsilsel Durum Aktarımı (REST)’dır. Çoğu durumda, kaynak bir cihazdır ve bir cihazın içerdiği verilerdir.
HTTP bir aktarım sağlar, ancak verilerin sunumunu tanımlamaz. Bu nedenle, HTTP istekleri HTML, JavaScript, JavaScript Nesne Notasyonu (JSON), XML vb. içerebilir. Çoğu durumda, IoT, JSON etrafında HTTP üzerinden standartlaşmaktadır. JSON, tüm ek yük ve şema doğrulaması olmadan, XML’e benzer ve daha hafif ve esnek hale gelir. JSON, çoğu araç ve programlama dili tarafından da desteklenir.
Endüstri, cihaz ve ürün konfigürasyonu için HTTP kullanma konusunda bazı deneyime sahiptir, ancak veri erişimi için değildir. Bu nedenle, birçok IoT ve IT platformu HTTP biçiminde veri tüketmeyi ve veri sağlamayı destekliyor, ancak destekleyen çok az endüstriyel platform var. Daha fazla ağ geçidi ve PLC’ler yerel HTTP desteği eklemeye başladıkça bu durum değişiyor.
“Birçok IoT platformu HTTP ve MQTT’ protokollerini ilk olarak destekliyor.” Her saat bir dakikalık sıcaklık okumaları gibi veri yığınlarını göndermek için HTTP kullanın. Yüksek hızlı veri akışı için HTTP kullanmayın. HTTP, ikinci saniye veri yapabilir, ancak HTTP üzerinden 100 msn’lik güncelleme yapmak zordur. Mesaj başına çok fazla ek yükü olduğundan, küçük iletiler akışı yetersizdir. HTTPS ile her zaman güvenli iletişim kurun.
HTTP ürünleriyle birlikte çalışabilirlik sorunlarının farkında olun. Sırf iki ürünün HTTP / REST / JSON’u desteklediğinden, kutudan çıkacakları anlamına gelmez. Genellikle JSON formatları farklıdır ve işleri yürütmek için minimum entegrasyon gerektirir.
MQTT
Mesaj Kuyruklama Telemetri Taşımacılığı (MQTT), SCADA ve uzak ağlar için tasarlanmış bir yayınlama / abone olma protokolüdür. Minimum başlık yükü (2 bayt başlık) ve güvenilir iletişim üzerinde duruluyor. Aynı zamanda çok basit. HTTP gibi, MQTT’nin yükü de uygulamaya özeldir ve çoğu uygulama özel bir JSON veya ikili format kullanır.
MQTT, HTTP kadar yaygın bir şekilde kullanılmamaktadır, ancak BT’de hala büyük bir pazar payına sahiptir. Her dilde çok sayıda açık kaynaklı istemci / üretici, broker, proje ve örnek var.
Bant genişliği yeterli ve altyapınızı bilmiyorsanız MQTT kullanın. Sizin veya satıcınızın, veri yayınlayabileceğiniz bir MQTT brokerine sahip olduğundan emin olun ve her zaman Aktarım Katmanı Güvenliği (TLS) ile iletişimi güvenli hale getirin.
Uç uygulama MQTT’yi desteklemiyor mu? Öyleyse, MQTT verilerini veritabanlarına ve HTTP gibi diğer biçimlere almak için birçok açık kaynak aracı vardır.
HTTP’ye benzer birlikte çalışabilirlik sorunlarına dikkat edin. Sadece iki uygulamanın MQTT’yi desteklemesi, birlikte çalışabilecekleri anlamına gelmez. İki ürünün birlikte çalışabilir olması için konu ve JSON formatlarının ayarlanması gerekebilir.
CoAP
Sınırlı Uygulama Protokolü (CoAP), HTTP’nin en az ek yük ile birlikte çalışabilirliğini sağlamak için İnternet Mühendisliği Görev Gücü (IETF) tarafından oluşturulmuştur. CoAP, HTTP’ye benzer, ancak TCP yerine UDP / multicast kullanır. Ayrıca, HTTP başlığını basitleştirir ve her isteğin boyutunu azaltır. CoAP, HTTP’nin çok kaynak yoğun olacağı uç tabanlı cihazlarda kullanılır ve genellikle HTTP ve MQTT’den sonra IoT platformları tarafından desteklenen üçüncü protokoldür. HTTPS’ye benzer şekilde, CoAP iletişimi güvence altına almak için Datagram Transport Layer Security (DTLS) kullanır.
HTTP çok fazla bant genişliği yoğun olduğunda CoAP kullanın. CoAP’ın pazar kullanımının HTTP kadar büyük olmadığını unutmayın, bu nedenle yazılım ve donanım seçeneklerinizi sınırlayabilir. CoAP mesajlarını daha birlikte çalışabilir kılan CoAP mesajlarını HTTP’ye ve HTTP’den dönüştürmek için çözümler de var.
DDS
Veri Dağıtım Hizmeti (DDS), ağın ucundaki iletişime odaklanan bir yayınlama / abone olma protokolüdür. DDS, Nesne Yönetim Grubu (OMG) tarafından yönetilen açık bir standarttır. Merkezileştirilmiş bir broker gerektiren MQTT’den farklı olarak, DDS merkezsizleşmiştir. DDS düğümleri, UDP çok noktaya yayın kullanarak doğrudan birebir şekilde iletişim kurar. Bu, merkezi ağ yönetimi ihtiyacını ortadan kaldırır ve ayrıca DDS’yi daha hızlı bir protokol yaparak milisaniyenin altındaki çözünürlüğe ulaşır.
DDS, en güvenilir, gerçek zamanlı veri iletimi için iyi bir çözümdür. Hızlı M2M iletişimi için kullanın.
DDS, brokerleri DDS ağlarını işletme ile entegre etmeye desteklemektedir, ancak pratikte brokerlar genellikle DDS ağına ikincil olduğu için endüstri ile BT arasındaki entegrasyon noktası olarak iyi konumlandırılmamıştır.
“DDS, en güvenilir, gerçek zamanlı veri iletimi için iyi bir çözümdür. Hızlı M2M iletişimi için kullanın.”
AMQP
Gelişmiş Message Queuing Protokolü (AMQP), finansal hizmetler sektöründen çıkan bir başka yayın / abone protokolüdür. BT’de bir varlığı vardır, ancak sektörde sınırlı bir varlığı vardır.
AMQP’nin en büyük yararı, işlemleri destekleyen güçlü iletişim modelidir. MQTT’den farklı olarak, AMQP işlemlerin tamamlanmasını garanti eder. Bu faydalı olsa da IoT uygulamaları için her zaman gerekli değildir.
AMQP genellikle IoT protokolleri ile gruplanır; ancak en büyük dezavantajı, ağır bir protokol olmasıdır. Bu, ağın uçları için değil, arka uç BT sistemleri içindir.
Sonuç :
OPC UA, HTTP, MQTT, CoAP, DDS ve AMQP’nin tümü IoT’de yer almaktadır. Hangi protokollerin pazar payında çoğunlukta olacağı belli değil, ancak her birinin avantajları ve dezavantajları var.
Bu avantaj ve dezavantajların farkında olmak, IoT uygulamalarınızın başarısını sağlayacak ve sizi protokol savaşlarından koruyacaktır.
“Gereksinimlerinize en uygun protokolü seçmek ve bu protokollere uyum sağlayabilecek teknoloji ortakları seçmek önemlidir.”
Kepware’in KEPServerEX ürünü, işlevi gereği OPC UA kullanırken, IoT Gateway çözümünde REST ve MQTT protokollerini desteklemektedir.