Bir yayınlama/abone olma protokolü, IIoT’deki birçok kullanım durumu için mükemmel bir çözüm gibi görünebilir, ancak farkında olmamız gereken kendi kısıtlamaları vardır. Örneğin, otomat senaryosunda, belirli bir otomat makinesinin gazlı içeceğin bittiğini hemen, gerçek zamanlı olarak bilmemiz kritik değildi.

Can sıkıcı olabilir ama dünyanın sonu gelmeyecek. Ancak, yayınla/abone ol modeli borsa değerlerini takip ediyorsa ne olur?
Şimdi bir sorunumuz var.

Stokta olmayan veya nakit kutusu dolu bir otomat, operasyon ve yönetim alanını zamanında uyarmazsa artık ticaret yapamaz ve para kaybedecektir. Ancak, stok değerlemeleri gibi hızlı değişen kriterleri göz önünde bulundurursak, gerçek zamanlı olarak bir saniyelik gecikmenin felaketle sonuçlanabileceğini bilmemiz gerekir.

Ve işte merkezi yayınla/abone ol modeliyle ilgili sorun. Yayıncılar ve aboneler arasında satır içi bir aracı sunucusu yerleştirerek gecikme ekler.

Sonuçta, aracı hizmetinin yayıncılardan alınan mesajları işlemesi ve ardından hangi abonelerin mesajı gerektirdiğini belirlemesi gerekir. Aracı, her abone için mesajı arayacak ve çoğaltacaktır, ancak bu, mikrosaniyeler de olsa zaman alır, ancak borsa söz konusu olduğunda bu kabul edilemez.

Ek olarak, aracının bu işlevleri seri olarak gerçekleştirmesi gerekir, böylece bazı aboneler diğerlerinden önce hisse senedi fiyatındaki bir değişiklikle ilgili güncel mesajlar alabilir. Bu nedenle, abone mesajlarını gerçek zamanlı olarak dağıtmanın bir yolunu bulmamız gerekiyor.

Sonuç olarak, yayınlama/abone olma modelini dağıtmanın bir aracı hizmeti gerektirmeyen başka yöntemleri vardır. Basit bir yöntem, yayınlanan mesajı UDP kullanarak ağdaki tüm ana bilgisayarlara yayınlamaktır, ancak çoğu ana bilgisayar paketleri bırakacağından ve güvenilmez olduğundan bu israftır.

Buradaki sorun, bir mesajın milisaniyeler sonra ulaşmasının, mesajı hiç almamaktan daha iyi olmasıdır. Sonuçta, gerçek zamanlı uygulamalarda kullanmak çok cazip olmasına rağmen, UDP’nin ateş olduğunu unutmayın ve unutun. Bu nedenle, farklı hizmet seviyeleri gerektirebileceklerinden, protokolleri uygulamalarla nasıl eşleştirdiğimizi yeniden düşünmemiz gerekiyor.

Yayınlama/abone olma protokolünü dağıtmanın bir başka yararı da, yalnızca tüm uygulamaları (aboneleri) “veri yolu” aracılığıyla tüm sensörlere (yayıncılara) bağlamakla kalmaz, aynı zamanda bazı durumlarda tüm cihazları, bağlı olan tüm cihazlara önemli ölçüde bağlayabilmesidir. 

Protokoller nedir
Ağ protokolleri Nelerdir
Web Hizmeti protokolleri
protokol nedir
Aracı Ağ Cihazları diğer aygıtları iletişim ve hatalar konusunda bilgilendirmez
Http Nedir
Hangisi web hizmeti Protokolü değildir

Bunun IIoT bağlamında anlamı, cihazların yayınlama/abone olma protokolü üzerinden birbirine bağlanabilmesi ve birbirleriyle iletişim kurabilmesidir. Bu, cihazların potansiyel olarak işbirliği yapabileceği ve kaynakları paylaşabileceği anlamına gelir.

Örneğin, her cihazın 3G modem ve SIM gibi uzun mesafeli iletişim teknolojisine sahip olması gerekiyorsa, bunlar daha büyük, daha ağır ve daha pahalı olacaktır. Bununla birlikte, daha küçük, daha ucuz ve daha aptal cihazlar, ağır hizmet komşularıyla işbirliği yapabilirse, daha küçük cihazın diğerinin iletişim kanalları aracılığıyla iletişim kurmasını sağlayan kaynakları paylaşabilirler.

Yayınlama ve abone olma ve olaya dayalı mesajlaşma hizmetleri, IIoT sistemlerinin verimliliğini büyük ölçüde artırır ve uygulamaya bağlı olarak bir dizi yayınlama/abone olma modeli kullanılarak dağıtılabilir. Tüm IIoT protokollerinde olduğu gibi, aralarından seçim yapabileceğiniz çok şey var gibi görünüyor, bu nedenle bugün yaygın olarak kullanılan yayınlama/abone olma protokollerinin her birini, bireysel artıları ve eksileri ve IIoT bağlamında birbirleriyle nasıl karşılaştırıldıkları dahil olmak üzere tartışacağız. .

En yaygın olarak dağıtılanlar:

• MQTT • XMPP • AMQP • DDS

Bu protokollerin tümü, gerçek zamanlı olarak çalışan ve on binlerce cihazı işleyebilen orijinal yayınlama/abone olma protokolleri olduğunu iddia eder. Ancak, bunlar çok farklıdır ve bazıları farklı seviyelerde çalışır. Örneğin, bu protokolleri genel olarak cihazdan cihaza, cihazdan sunucuya ve sunucudan sunucuya düzeyde çalışan olarak kategorize edebileceğimizi düşünün. O zaman, her protokol için zamanla ölçülen performansı daha iyi anlamalı ve beklemeliyiz.

MQTT

Mesaj Kuyruğu Telemetri Aktarımı olan MQTT, cihaz verilerinin toplanmasına odaklanan bir yayınlama/abone olma protokolüdür. MQTT’nin ana amacı telemetri veya uzaktan izlemedir, bu nedenle binlerce uç cihazdan veri almak ve toplu trafiği operasyonel ve yönetim alanına geri taşımak için tasarlanmıştır. Bu nedenle, genel sınıflandırmada MQTT’yi cihazdan sunucuya bir protokol olarak kabul edeceğiz.

“Mesaj Kuyruğu Telemetri Aktarımı, yüksek gecikmeli veya kısıtlı ağlar boyunca yaygın cihazlardan mesajlar şeklinde telemetri tarzı verilerin bir sunucuya veya küçük mesaj aracısına aktarılmasını kolaylaştıran M2M iletişimleri için tasarlanmış bir açık mesaj protokolüdür.”

Bu nedenle, MQTT, uç dönüştürücülerden veri toplamak ve toplanan verileri operasyonlar ve yönetim alanındaki bir toplama sunucusuna geri göndermek için tasarlandığından, zorunlu olarak olmasa da, bir merkezden uç noktaya topolojiye dayanmaktadır.

Bu tasarım nedeniyle MQTT, cihazdan cihaza bağlantıları kolaylaştırmaz ve cihazlar ile toplama sunucusu arasında noktadan noktaya bir ilişki içinde çalışır. Bu, MQTT’nin açık bir tasarım hedefi olduğundan, birkaç yapılandırma seçeneğine sahiptir ve gerçekten herhangi bir seçenek gerektirmez. MQTT’nin iş özelliği, cihazlardan veri toplamak ve verileri güvenilir bir şekilde toplama sunucusuna geri taşımaktır.

Ancak, bu güvenilir aktarım, güvenilir bir aktarım protokolü gerektirir, bu nedenle MQTT, TCP/IP üzerinden çalışır. Bunun sonuçları, cihaz ve toplama sunucusu arasında tam bir TCP/IP bağlantısının gerekli olmasıdır. Bu, birkaç nedenden dolayı çok sorunludur; ilk olarak, cihazın tam bir TCP/IP yığınını destekleyebilmesini gerektirir; ikincisi, TCP/IP bağlantısının her zaman sürdürülmesi gerektiği için makul bir ağ bağlantısı gerektirir.

Üçüncüsü, TCP/IP kullanmak, MQTT’nin gerektirdiği güvenilirliği sağlayabilir, ancak LAN ve halihazırda güvenilir bir ağın bulunduğu diğer WAN dışı altyapılar gibi durumlarda gereksiz yere performansı ve paket ek yükünü etkileyecektir.

Bu tasarım özelliklerinin bir sonucu olarak, MQTT, bir petrol veya gaz boru hattının durumunun izlenmesi gibi harici ve uzaktan cihaz izleme veya binlerce kısıtlamasız TCP/IP özellikli sensör/cihazın veri gönderilmesini gerektirdiği benzer uygulamalar için uygundur. ortak bir sunucuya/uygulamaya.

Zorlu ortamlarda uzaktan telemetri izleme gibi uygulamalarda, TCP/IP protokollerinin güvenilirliği bir nimettir ve performans ikincildir. Sonuç olarak, MQTT, beklenen cihazdan sunucuya rakamların saniyeler içinde sayılmasıyla yüksek performans için tasarlanmamıştır.

The post Protokoller – Endüstri 4.0 – Ödev Hazırlatma – Tez Yazdırma – Proje Yaptırma Fiyatları – Ödev Örnekleri – Ücretli Proje Yaptırma – Tez Yaptırma Ücretleri first appeared on Online (Parayla Ödev Yaptırma).