IIoT-oplossingen | 6 industriële IoT-communicatieoplossingen

Om te zeggen dat de taak van het selecteren van uw industriële IoT (IIoT ) communicatie-infrastructuur is een zeer complexe onderneming zou een understatement zijn. De evaluatie van de talloze commercieel beschikbare oplossingen is zowel tijdrovend als duur. Probeer meerdere oplossingen van elk type infrastructuur te downloaden en te evalueren en u bevindt zich al snel midden in een project dat meerdere technici zeker zes maanden in beslag zal nemen. We zijn er allemaal geweest en ik wil je helpen jezelf wat kostbare tijd te besparen!

Het doel van dit bericht is om u kennis te laten maken met de populaire IIoT-infrastructuuroplossingen die commercieel verkrijgbaar zijn - AMQP, CoAP, DDS, RTI Connext DDS, MQTT en ZeroMQ - en om benadrukken de mogelijkheden van elke oplossing. De zes volgende evaluatiegebieden zullen worden toegepast:architectuur, communicatiepatronen, transporten, gegevenstype en filtering, servicekwaliteit en beveiliging.

Klik hier om de afdrukbare PDF-versie te downloaden.

1. Architectuur

Afhankelijk van het architecturale patroon van een bepaalde communicatie-infrastructuur, varieert de logische verbinding (geïllustreerd in Afbeelding 1, hieronder) die toepassingen zullen gebruiken om met andere toepassingen in de infrastructuur te communiceren. De twee meest elementaire architecturen die in de huidige middleware-oplossingen worden gebruikt, zijn (1) peer-to-peer en (2) op brokers gebaseerde sterarchitecturen.

1. Peer-to-peer-architecturen applicaties in staat stellen om direct met elkaar te communiceren zonder data naar een intermediair element te hoeven sturen. Deze architecturen zijn inherent efficiënter bij het leveren van gegevens, aangezien alleen de verzendende en ontvangende toepassingen CPU-bronnen verbruiken om de overdracht te voltooien. Daarom zullen alleen de applicaties die de data hebben en de applicaties die de data nodig hebben CPU-cycli verbruiken; resulteert dus in een efficiënte verdeling van de verwerking op basis van toepassingsvereisten. Het andere voordeel van een peer-to-peer-architectuur is dat deterministische levering van gegevens veel beter haalbaar is omdat er geen "tussenpersoon" is die de gegevens tussen de producent- en consumententoepassingen afhandelt.

Figuur 1. Architecturale diagrammen voor de verschillende IoT-protocollen.

2. Op makelaars gebaseerde oplossingen vereisen dat alle applicaties die gegevens verzenden de gegevens rechtstreeks naar de brokerserver overbrengen, waarna deze zich omdraait en deze gegevens opnieuw naar de ontvangende applicaties verzendt. Het voordeel van deze architectuur is dat de broker alle complexiteit met betrekking tot het verzenden/ontvangen van gegevens beheert. Meestal hebben deze oplossingen ingebouwde tools om precies te zien welke gegevenspaden actief zijn, wie gegevens verzendt en wie gegevens ontvangt. Oplossingen op basis van makelaars introduceren latentie bij de levering van gegevens en bieden ook een enkel storingspunt, zodat als de makelaar faalt, alle communicatie ook mislukt. Om het single point of failure-probleem op te lossen, voorzien de meeste van deze implementaties in redundante en zeer beschikbare brokerservers.

2. Communicatiepatronen

Ondersteuning van communicatiepatronen is essentieel voor een infrastructuur die u gedurende de levenscyclus van uw project of productlijn kunt gebruiken. Het eerste project vereist mogelijk alleen publiceren/abonneren, maar volgende projecten of producten hebben mogelijk aanvullende patronen nodig, zoals verzoeken/antwoorden of wachtrijen. In dit opzicht kunnen niet alle bestaande IoT-oplossingen die vandaag beschikbaar zijn alle noodzakelijke patronen ondersteunen die uw project nodig heeft. Voor de vergelijkingstabel hebben we de meest voorkomende patronen geïdentificeerd die tegenwoordig worden gebruikt en of elke infrastructuuroplossing dat patroon biedt. Dit zijn de meest voorkomende patronen die tegenwoordig worden gebruikt:

• Publiceren / abonneren :Een applicatie (abonnee) vraagt ​​1 keer gegevens op en vervolgens worden alle daaropvolgende updates van de gegevens naar de abonnee “gepusht”. U hoeft niet voortdurend om gegevensupdates te vragen.
• Verzoek/Antwoord/RPC (Procedureoproep op afstand ):Een aanvraagtoepassing verzendt verzoeken en een antwoordtoepassing beantwoordt de aanvraag.
• In de wachtrij staan (of punt-naar-punt ):Gegevens worden naar een server gepusht die de informatie in een wachtrij zal bewaren. Gegevens kunnen vervolgens uit de wachtrij worden gehaald of naar de consument worden gepusht. Anders dan bij Publiceren/Abonneren, wordt elk stukje data gedistribueerd naar slechts één ontvangende applicatie.
• Eén op velen :Mogelijkheid om een ​​groot aantal ontvangende applicaties dezelfde gegevens van een enkele bron te laten krijgen.
• Veel op één :Mogelijkheid om gegevens uit vele bronnen te ontvangen in een enkele verbruikende applicatie.

3. Transport &Routing/Overbrugging

De meeste communicatiemiddleware-oplossingen ondersteunen TCP als hun primaire communicatieprotocol. Het gebruik van TCP geeft u een betrouwbare levering van gegevens met behulp van het ingebouwde betrouwbaarheidsmechanisme dat inherent is aan TCP. Dit kan ideaal zijn voor specifieke datastromen die betrouwbaarheid vereisen, maar is overdreven en voegt onnodige overhead toe aan eenvoudige sensordata waarvoor geen betrouwbare levering vereist is. Sommige IoT-oplossingen zoals ZeroMQ en DDS ondersteunen ook andere transporten, zoals gedeeld geheugen. Een opmerkelijk transport is het gebruik van het UDP-transport voor DDS. Omdat de implementatie van betrouwbaarheid in DDS is ingebouwd, is er geen betrouwbaar transport onder nodig. Dit stelt applicaties in staat om te kiezen welke datastromen betrouwbare levering zijn en welke stromen de beste inspanning leveren.

Het routeren van gegevens tussen transporten en over het WAN is iets dat al deze oplossingen op de een of andere manier bieden. In de huidige wereld waarin bedrijfssystemen, gebruikmakend van ESB's en webtechnologieën, ook toegang moeten hebben tot sommige realtime gegevens, is het essentieel dat communicatiemiddleware ook verbinding met deze technologieën ondersteunt. Hierdoor zult u routering en bridging zien als een kerncomponent voor gedistribueerde systeemmiddleware.

4. Gegevenstype en filtering

Hoe gegevens worden ingekapseld en weergegeven op de draad, is ook uniek voor de gegeven infrastructuur. Sommige oplossingen verzenden alleen onbewerkte bytes aan gegevens en het is aan de toepassing om de gegevens te serialiseren en te deserialiseren. Anderen verzenden alleen tekst-/stringgegevens, zodat de informatie kan worden weergegeven in XML- of JSON-indeling. Dit scenario is tegenwoordig heel gebruikelijk in webtechnologieën, maar kan erg inefficiënt zijn omdat bij elke verzending van gegevens het pakket ook de beschrijving van de gegevens bevat, waardoor de pakketgrootte soms meer dan 3x de oorspronkelijke grootte is. Grotere pakketgroottes verhogen het bandbreedtegebruik en het CPU-gebruik aan zowel de verzendende als de ontvangende kant van de overdracht. Zet daar een broker tussen en je verdubbelt nu ook het aantal pakketten op de draad.

Andere oplossingen, zoals DDS, maken het gebruik van sterk getypte gegevens mogelijk die uniek geserialiseerd en gedeserialiseerd zijn door de middleware. Het schema wordt apart meegestuurd, wat bij XML of JSON niet het geval is, en je betaalt dus geen boete per bericht (of sample). Dit wordt ook erg belangrijk voor het filteren van aspecten. Stel dat u één uitgever opzet met veel abonnees. Sommige abonnees willen misschien alle gegevens, maar sommige abonnees willen slechts een deel van de gegevens. Zonder een sterk getypeerde data-oplossing, zullen uw applicaties al deze filterfunctionaliteit moeten beheren, wat nog meer code is die u moet schrijven. Met oplossingen zoals DDS waarbij de type-informatie sterk is gedefinieerd, kan de middleware alle filtering voor u beheren. Minder code =blijere ontwikkelaars :). In feite heeft RTI Connext DDS extra functionaliteit voor het leveren van deze filtering aan de schrijverskant van de gegevensoverdracht, wat resulteert in minder bandbreedtegebruik op de draad en minder CPU-verwerking op toepassingen die de gegevens niet hoeven te filteren.

5. Kwaliteit van de dienstverlening

Niet alle gegevens zijn gelijk gemaakt. Wat betekent dit? Welnu, sommige gegevens in een realtime gedistribueerde toepassing zijn streaming sensorgegevens. Meestal hoeven dit soort gegevens niet gegarandeerd te worden geleverd. Voor een bepaalde sensor kan het u gewoon schelen dat een bepaalde deadline voor het aanleveren van gegevens is gehaald of, nog b

[1] [2] 下一页