Kaders en transporten:de beste IIoT-connectiviteitsoplossing kiezen

Het bouwen van een gedistribueerde systeeminfrastructuur in het huidige opkomende Industrial Internet of Things (IIoT)-landschap kan op zijn zachtst gezegd een ontmoedigende taak zijn. Als u een ontwikkelaar of systeemarchitect bent, weet u dat er veel tools en protocollen beschikbaar zijn om gegevens in uw gedistribueerde toepassing te verplaatsen. Om nog maar te zwijgen over de mogelijkheid om uw eigen aangepaste oplossing rechtstreeks op TCP- of UDP-sockets uit te bouwen. Zou het niet geweldig zijn als een groot deel van het werk dat gedaan moest worden voordat u een beslissing kon nemen over uw volgende infrastructuur al voor u was gedaan?

Weet je wat? Het werk is gedaan en is nu beschikbaar om u te helpen die beslissing te nemen. U vraagt ​​zich vast af:"Wie heeft al dit onderzoek gedaan en is het bevooroordeeld door een bedrijf dat zijn eigen oplossing wil verkopen?" Het goede nieuws is dat het onderzoek is uitgevoerd door een onafhankelijk consortium, het Industrial Internet Consortium (IIC). Het werd op een leveranciersneutrale, onbevooroordeelde manier uitgevoerd en de resulterende informatie is nu voor u beschikbaar.

Volledige disclaimer:Ja, ik werk voor een bedrijf dat een infrastructuur voor het industriële internet levert, maar ik zeg zeker niet dat onze oplossing de beste oplossing is. Het echte antwoord op de vraag:"Wat is de beste oplossing?" is:"Het hangt ervan af."

Het antwoord hangt af van wat u nodig heeft van een infrastructuuroplossing:

• Moet je alleen maar bytes aan data van punt A naar punt B sturen?
• Heeft u de gegevens nodig om betrouwbaar aangeleverd te worden?
• Heeft u datacentrisch bewustzijn nodig zodat de infrastructuur een aantal efficiënte leveringsbeslissingen kan nemen voor een intelligentere oplossing?
• Hoeveel van de gegevensverwerking wilt u uit handen geven aan de infrastructuur?

De antwoorden op deze kritische vragen, en nog veel meer, onderzoek ik in dit bericht. Aan het einde van dit bericht heb je hopelijk de informatie die je nodig hebt om een ​​weloverwogen beslissing te nemen over wat de beste oplossing is voor jouw unieke toepassing.

Over het Industrial Internet Consortium (IIC)

De IIC is in 2014 opgericht door enkele zeer grote spelers in het industriële internetlandschap. De oprichtende bedrijven (Cisco, Intel, AT&T, IBM en GE) wilden een organisatie creëren die zich uitsluitend richtte op de behoeften van industriële internettoepassingen. Nu bestaat het consortium uit meer dan 250 bedrijven, zowel groot als klein. De resultaten van dit consortium omvatten een reeks documenten die de behoeften en mogelijke oplossingen voor dit soort industriële internettoepassingen schetsen. Het document IIC Industrial Internet Connectivity Framework (IICF), een document met richtlijnen, is perfect om u te helpen bij het bepalen van de beste oplossing voor marktgebaseerde voorbeelden. Naast verschillende documenten hebben ze ook testbedden opgezet die zullen worden gebruikt om het vermogen van verschillende technologieën te bewijzen om te voldoen aan verschillende praktijkvoorbeelden op de markt. Informatie over de beschikbare documenten en marktgebaseerde testbeds is te vinden op de IIC-website.

Gegevens leveren:transporten en frameworks

Er zijn tegenwoordig veel oplossingen beschikbaar om gegevens tussen applicaties te krijgen. In het IICF-document worden deze oplossingen onderverdeeld in twee categorieën:transporten en raamwerken. Laten we eens kijken naar deze twee soorten oplossingen voor gegevensoverdracht om te zien waar ze passen in de algemene stapel connectiviteitslagen. Afbeelding 1 hieronder toont deze connectiviteitsstack.

Afbeelding 1. IIC Connectivity Framework Stack

Vrijwel iedereen die dit document leest, heeft een connectiviteitsstack als deze gezien, maar de IIC-stack heeft één duidelijk onderscheid:de transport- en raamwerklagen.

Meestal hebben we de neiging om alle oplossingen die u in de categorieën transport en raamwerk ziet te groeperen, maar er is één heel groot verschil tussen een transport en een raamwerk. Een transport wordt gebruikt om gegevens van punt A naar punt B te leveren, terwijl een raamwerk in feite gebruikmaakt van de mogelijkheden van een transport en tegelijkertijd een gegevenstypesysteem biedt voor interoperabiliteit. Simpel gezegd, wanneer alleen een transport wordt gebruikt, moet de applicatie de gegevens formuleren in een generieke buffer voor overdracht aan het transport. Met een framework hoeft de applicatie alleen de gegevens aan het framework over te dragen, en het framework zorgt voor het bouwen van een buffer voor het onderliggende transport om door te gaan en zijn gegevens te verzenden. Werken op gegevensniveau voor een applicatie heeft veel voordelen voor applicaties die mogelijkheden bieden zoals inhoudfiltering en detectie, terwijl als uw applicatie alleen iets op de transportlaag gebruikt, het aan de applicatie is om detectie en filtering te implementeren indien nodig. Tabel 1 geeft u alle mogelijkheden die beschikbaar zijn op elke transportlaag of raamwerk.

Tabel 1. Transport- en kadermogelijkheden

Kun je een gedistribueerde industriële internettoepassing bouwen met behulp van een transport? Ja. Kun je een gedistribueerde industriële internettoepassing bouwen met behulp van een framework? Ja. Is de een beter dan de ander? Het echte antwoord is:"Het hangt ervan af." Het hangt af van de vereisten van uw applicatie welke oplossing het meest geschikt is voor uw infrastructuur. De rest van dit bericht zal een aantal van deze frameworks en transporten doornemen, zodat u kunt beslissen welke de juiste technologie is voor uw toepassing.

Vervoer

Er zijn tegenwoordig veel oplossingen beschikbaar om gegevens tussen applicaties te krijgen. In de IICF worden transporten opgeroepen die gebruikmaken van de standaard IP-socketinterfaces van UDP of TCP. Als uw toepassing betrouwbare gegevensoverdracht nodig heeft, zou een ontwikkelaar voor TCP kiezen vanwege de verbindingsgerichte mogelijkheden en betrouwbare mechanismen. Voor een eenvoudigere verbinding en onbetrouwbare gegevensoverdracht, zou UDP worden gekozen vanwege het gebruiksgemak en de multicast-levering. Jarenlang gebruikten de meeste netwerkapplicaties deze basisinterfaces voor het verzenden en ontvangen van gegevens. Alle mogelijkheden die worden geboden door de transporten van de hogere laag (vermeld in tabel 1) zouden direct in de applicatie moeten worden gebouwd. Als we kijken naar de hogere laagtransporten van DDS-RTPS, CoAP, MQTT, HTTP en OPC-UA Bin, kijken we eigenlijk alleen naar de details voor CoAP en MQTT. De DDS-RTPS-, HTTP- en OPC-UA Bin-transporten zijn in principe direct gekoppeld aan de bovenliggende frameworks van respectievelijk DDS, Web Services en OPC-UA. De mogelijkheden van deze transporten zullen worden besproken als onderdeel van de kaderdiscussie die volgt.

MQTT

Laten we eens kijken naar Message Queuing Telemetry Transport (MQTT). Nogmaals, MQTT wordt hier vermeld als een transport omdat het geen datamodel voor applicaties afdwingt of implementeert. Het biedt alleen een buffer waarop applicaties hun gegevens moeten formuleren voor het verzenden en ontvangen. Het primaire doel waarvoor het is gemaakt, staat in de naam vermeld:telemetrie. Een apparaat of applicatie in het veld verbinden met en rapporteren van gegevens aan een backend cloud of off-site verwerkingslocatie. Dit transport is geweldig voor zaken als een IoT-gateway voor thuis of beheerder van een set geïmplementeerde apparaten. De primaire architectuur voor MQTT is gebaseerd op brokers, zoals te zien is in figuur 2.

Figuur 2. MQTT Broker-architectuur

In deze architectuur sturen alle externe clients hun gegevens naar de MQTT-broker, en de broker is verantwoordelijk voor het verzenden van zijn gegevens naar alle clients die om die gegevens hebben gevraagd. Deze op brokers gebaseerde architectuur maakt het gemakkelijk om gegevens op een losjes gekoppelde manier te verzenden en ontvangen, maar leent zich niet voor het ondersteunen van zeer deterministische industriële toepassingen met lage latentie. Als transport heeft MQTT een plaats in het totale landschap van gedistribueerde industriële toepassingen. Het volgende is een hulpmiddel dat u kunt gebruiken om te bepalen of MQTT iets is dat u zou moeten gebruiken voor uw volgende of huidige project. Hier zijn vijf "ja" of "nee" vragen voor jou. Als uw antwoord op drie of meer van deze vragen "ja" is, dan is MQTT de juiste keuze voor u.

MQTT-vragen

1. Denk je aan je applicatie als gegevensverzameling?
2. Is er weinig communicatie tussen apparaat en apparaat?
3. Is interoperabiliteit geen overweging?
4. Heb je veel kleine apparaten?
5. Is software een kleine uitdaging?

MQTT is het enige transport dat in het IICF-document wordt vermeld en dat niet echt gebonden is aan een raamwerk van een hogere laag. Dit is de reden dat we het apart hebben uitgebroken als transport. Laten we nu eens kijken naar de kaders die worden vermeld in het IIC-document.

Kaders

Zoals eerder vermeld, is het onderscheidende verschil tussen een raamwerk en transport het feit dat een raamwerk ee

[1] [2] 下一页