Opties voor het protocol van de applicatielaag voor M2M- en IoT-functionaliteit

Met de invoering van het internet der dingen (IoT) en industrie 4.0-functies worden apparaten steeds meer met elkaar verbonden via industriële protocollen. Bovendien wordt de huidige M2M-communicatie ( machine-to-machine) in hoog tempo gestandaardiseerd op deze protocollen. Een complicerende factor is dat IoT-protocollen niet één enkel protocol voor de toepassingslaag beschrijven, aangezien er verschillende normen in gebruik zijn. Dus terwijl vroege IoT-implementaties gebruik maakten van standaard internetprotocollen, zijn er nu ook specifieke IoT-protocollen beschikbaar.

Het modelleren van communicatiestructuren en het bepalen van het juiste protocol voor een bepaalde toepassing kan ontmoedigend zijn. In dit artikel wordt uiteengezet wat de verschillende protocollen doen en welke opties er voor deze protocollen zijn, zodat ontwerpers gemakkelijker de meest geschikte kunnen kiezen om te integreren.

Afbeelding 1: IIoT-functies in de industriële automatisering zijn afhankelijk van steeds meer verbonden apparaten die gebruik maken van industriële protocollen voor netwerkvorming. De geabstraheerde lagen van deze netwerken vereisen geen kennis van de onderliggende laagfuncties, dat is de reden waarom zoveel ontwerp-engineering zich richt op de bovenste (toepassings)laag van machinenetwerken. (Bron afbeelding: Getty Images)

Definiëren van het protocol van de toepassingslaag voor industriële netwerken

De structuren van communicatieprotocollen voor digitale M2M- en IoT-systemen worden conceptueel opgedeeld in abstracte lagen, waarbij de meest voorkomende modellen drie, vier, vijf of zeven lagen hebben. Deze conceptuele raamwerken gaan ervan uit dat elke laag in wezen de gedetailleerde werking van een bepaald apparaat of een bepaalde softwarelaag "verbergt" voor andere apparaten of algoritmen waarmee het communiceert. Dat komt omdat de lagen zo zijn gedefinieerd dat zij net genoeg informatie bevatten voor de gegevensuitwisselingen in kwestie.

Afbeelding 2: Traditionele systeemarchitecturen zijn hiërarchisch, maar cloud- en mistcomputing hebben de grenzen tussen componentfuncties doen vervagen. Dat heeft geleid tot het gebruik van nieuwe netwerkprotocolmodellen. (Bron afbeelding: motioncontroltips.com)

Welk model ook wordt gebruikt, in alle modellen wordt een toepassingslaag vastgesteld als de hoogste abstractielaag tussen apparaten die in een netwerk met elkaar communiceren. Beschouw de toepassingslaag als een concept van het Open Systems Interconnection (OSI) model- waarin het bijna drie decennia geleden voor het eerst werd gedefinieerd door de Internationale Organisatie voor Normalisatie (ISO) voor netwerkcommunicatie. Dit klassieke zeven-lagen model is enigszins overgecompliceerd voor het beschrijven van sommige van de huidige protocollen, maar is nog steeds nuttig voor het volledig begrijpen van de gegevensstroom binnen systemen:

De fysieke laag van een protocol maakt de overdracht van ruwe gegevens (digitale bits) mogelijk in de vorm van elektrische, radio- of optische signalen. Deze laag specificeert de pin-indelingen, spanningsniveaus, datasnelheden en lijnimpedanties van de fysieke elementen die de gegevens dragen. Ethernet is een algemeen protocol voor de fysieke laag. Lees het DigiKey artikel EtherNet/IP versus PROFINET voor meer informatie hierover.

De datalink-laag verbindt netwerkknooppunten met elkaar zodat apparaten verbindingen tot stand kunnen brengen en fouten op de fysieke laag kunnen corrigeren. Binnen de IEEE 802-standaard is de data-link laag onderverdeeld in een Medium Access Control (MAC) laag (ook weer om apparaten verbinding te laten maken) en een Logical Link Control (LLC) laag voor het identificeren van de volgende te gebruiken laag (de netwerklaag) alsmede foutcontrole en synchronisatie. Lees meer over de functies van de datalink-laag in het DigiKey artikel Implementing Industrial Ethernet with 32-bit MCUs. De netwerklaag daarentegen maakt het doorsturen van gegevenspakketten naar netwerkadressen mogelijk. Waar internetprotocollen verwijzen naar het Transmission Control Protocol en Internet Protocol (TCP/IP) model (behandeld in het volgende deel van dit artikel) is er een internetlaag tussen de datalink- en netwerklagen. In feite wordt de internetlaag vaak beschouwd als een onderdeel van de netwerklaag.

De eerste van de volgende drie lagen van het OSI-model is de transportlaag, die zorgt voor de betrouwbaarheid en veiligheid van de communicatie tijdens de overdracht van gegevensreeksen. Vervolgens regelt de sessielaag wanneer apparaten verbinding met elkaar maken en of de verbinding eenrichtings- (simplex) of tweerichtingsverkeer (duplex) is. Tenslotte maakt de presentatielaag de vertaling van gegevens mogelijk, zodat apparaten die verschillende syntaxen gebruiken, kunnen communiceren.

Het zwaartepunt van dit artikel, de toepassingslaag, is het hoogste abstractieniveau en het niveau waarmee gebruikers en systeemsoftware interageren.

Afbeelding 3: Moderne netwerkprotocollen (en de toepassingslaag) worden vaak beschreven aan de hand van het klassieke OSI-model van industriële (en commerciële) netwerken. Bij drielagige IoT-architectuurmodellen staat de toepassingslaag daarentegen boven de perceptie- en netwerklagen; bij vierlagige modellen staat de toepassingslaag boven de gegevensverwerkings-, netwerk- en detectielagen. Vijflagige IoT-protocolmodellen zijn vergelijkbaar, maar voegen verwerkings- en ondernemingslagen toe. (Bron afbeelding: Design World)

Internetprotocollen in industriële automatisering

Internetprotocollen zijn datacommunicatiesystemen, zo genoemd naar de manier waarop zij gegevens doorgeven tussen netwerken (en gewoonlijk wederzijds) voor grensoverschrijdende communicatie. Hun functies worden vaak beschreven met het vierlagenmodel van TCP/IP dat hierboven is genoemd. Hier is de fysieke netwerk- of link-laag dezelfde als de fysieke laag van het OSI-model. De TCP/IP-internetlaag daarentegen (die ruwweg een combinatie benadert van de functies van de datalink- en netwerklaag van het OSI-model) behandelt zowel verbindingen als gegevenspakketten. In IPv6 gebruikt deze laag 128-bit IP-adressen om hosts op het netwerk te identificeren - en staat meer dan 10³⁸ unieke hosts toe.

De transportlaag in TCP/IP bestaat over het algemeen uit het transmissiecontroleprotocol (TCP) of het gebruikersdatagramprotocol (UDP). TCP wordt over het algemeen gebruikt voor menselijke interacties zoals e-mail en surfen op het web. Het biedt logische verbindingen, bevestiging van verzonden pakketten, hertransmissie van verloren pakketten en flow control. Ingebedde systemen gebruiken echter UDP om een lagere overhead en betere real-time prestaties te verkrijgen. UDP werkt voor domeinnaamservers (DNS) en het dynamisch hostconfiguratieprotocol (DHCP), maar ook voor nieuwe IoT-toepassingen.

De toepassingslaag is het hoogste niveau in het TCP/IP-model van netwerken. De functies omvatten die welke verband houden met de sessie- en presentatielagen van het OSI-model.

Generieke TCP/IP-toepassingslaagprotocollen

Verschillende protocollen voor de toepassingslaag hebben verschillende gegevensbandbreedten, real time-mogelijkheden en hardwarevereisten. Deze factoren, samen met de bekendheid van de fabriek of het OEM-team met een protocol, vormen vaak een belangrijk selectiecriterium. Hoewel vroege internetprotocollen zoals het hypertext transfer protocol (HTTP) en het simple mail transfer protocol (SMTP) grotendeels worden gebruikt voor mensgestuurde en door mensen geconsumeerde communicatie, zijn TCP/IP-protocollen met een IIoT-inslag meer gericht op machine-to-machine (M2M) en andere industriële communicatie.

Wat de zaak nog ingewikkelder maakt, is dat veel gevestigde protocollen voor de toepassingslaag die in TCP/IP worden gebruikt voor webgebaseerde menselijke interacties met informatie, ook worden gebruikt voor consumenten- en industriële IoT-toepassingen. Dat geldt zeker voor HTTP en SMTP, maar ook voor de beveiligde schil (SSH) en het protocol voor bestandsoverdracht (FTP). Het implementeren van ivd-functies met webtechnologieën is meestal haalbaar als ook gebruik wordt gemaakt van eXtensible Markup Language (XML) en JavaScript Object Notation (JSON). Een voorbehoud is dat het gebruik van HTTP veiligheidsimplicaties heeft. Daarom is het meestal het beste als IoT-apparaten in dergelijke systemen alleen een client omvatten en geen server. Dit voorkomt dat het apparaat verbindingsverzoeken ontvangt die ongeoorloofde toegang van buitenaf tot het netwerk zouden kunnen verschaffen. Hier kan het WebSocket-protocol een full-duplex communicatie tot stand brengen via HTTP. Anders kan het extensible messaging and presence protocol (XMPP) de voorkeur verdienen voor installaties die een groot aantal apparaten moeten aanspreken met een goede beveiliging en real-time datacommunicatie.

Wanneer ivd-projecten worden geleid door personeel met een IT-achtergrond, kan de voorkeur worden gegeven aan deze vertrouwde normen (van het menselijk leesbare web). Nieuwere IIoT-protocollen kunnen in sommige gevallen echter beter geschikt zijn voor M2M en andere industriële communicatie.

MQTT voor verticale connectiviteitstransportfuncties

De snelste adoptie in IIoT is het Message Queuing Telemetry Transport (MQTT) protocol, een lichtgewicht protocol dat oorspronkelijk bedoeld was voor IoT-apparaten met een beperkt geheugen. MQTT is ontwikkeld door IBM om sensoren op oliepijpleidingen met elkaar te verbinden. Het systeem werkt op compacte verwerkingsoppervlakken en vereist minimale bandbreedte. In tegenstelling tot het beperkte toepassingsprotocol (CoAP) is MQTT reeds gestandaardiseerd volgens ISO/IEC 20922. MQTT maakt gebruik van de TCP-transportlaag, die iets meer middelen vergt en verbruikt daarom meer stroom, maar berichten kunnen twee bytes groot zijn, nog kleiner dan die van CoAP.

Door zijn open karakter kan MQTT ook bijzonder gemakkelijk te implementeren zijn. Geen wonder dat Amazon Web Services' AWS IoT MQTT gebruikt voor berichtentransport en (met kanttekeningen) MQTT ondersteunt op basis van de v3.1.1-specificatie.

MQTT heeft enkele beperkingen, die te wijten kunnen zijn aan het feit dat MQTT oorspronkelijk bedoeld was als telemetrieprotocol, in tegenstelling tot het IoT-specifieke Lightweight Machine to Machine (LwM2M) protocol dat binnenkort zal worden behandeld. Functies zoals objecten, connectiviteitsmonitoring, en remote device actions zijn niet in de standaard opgenomen, zodat de opname ervan vaak verkoperspecifiek is, wat de waarde van het gestandaardiseerde protocol enigszins vermindert. MQTT biedt ook geen mogelijkheden voor foutenbehandeling. Tenslotte, hoewel MQTT beveiligd kan worden met een volledig TLS protocol, verhoogt dit de overhead.

Voornamelijk op ondernemingsniveau: AMQP

Advanced Message Queuing Protocol (AMQP) is een andere open standaard die enige gelijkenis vertoont met MQTT. Het biedt geavanceerde functies zoals message queuing. De overhead van AMQP is echter hoger dan die van MQTT, waardoor het slecht geschikt is om zeer beperkte apparaten aan te sluiten. Geen wonder dat het gebruik ervan in industriële IoT-toepassingen minder gebruikelijk is dan het gebruik ervan in performante bedrijfsberichten.

CoAP voor het verbinden van eenvoudige apparaten

Het beperkte toepassingsprotocol (CoAP) van de Internet Engineering Task Force (IETF) maakt communicatie mogelijk op netwerken met een laag stroomverbruik tussen toestellen met een minimaal geheugen en verwerkingsvermogen. Het kan werken met een zeer lage overhead en verzoeken en antwoorden kunnen zo klein zijn als vier bytes. CoAP vermijdt het gebruik van een complexe transport stack en maakt in plaats daarvan gebruik van UDP. Raadpleeg het DigiKey artikel over EtherNet/IP versus PROFINET waarnaar hierboven wordt verwezen voor meer informatie over UDP. Net als HTTP maakt ook CoAP gebruik van het REST-model - waarbij servers hulpbronnen beschikbaar stellen onder een URL en cliënten er toegang toe krijgen via POST-, GET-, DELETE- en PUT-methoden. Bovendien kan CoAP gemakkelijk worden vertaald naar HTTP voor integratie met andere webfuncties en integreert het met XML en JSON. Ingenieurs zouden moeten vaststellen dat het verbinden van IoT-apparaten met CoAP zeer vergelijkbaar is met het verbinden van apparaten met Web API.

Afbeelding 4: Nordic's SiP is een MCU met laag vermogen met een geïntegreerde LTE-M- en smalband (NB)-IoT-modem, evenals GPS. Een software-ontwikkelingskit maakt de installatie van CoAP mogelijk. (Bron afbeelding: Nordic Semiconductor)

Aansluiten van batterijgevoede apparaten met LwM2M

Een protocol voor de toepassingslaag van de Open Mobile Alliance is het LwM2M-protocol, dat speciaal is gebouwd voor IoT-toepassingen. LwM2M wordt gebruikt in smart-city toepassingen, bij het volgen van containers en vracht, bij geautomatiseerde off-highway routines en bij de bewaking van nutsvoorzieningen, en is gebaseerd op CoAP, zodat het veel van de attributen daarvan deelt. De norm omvat een breed scala van duidelijk gedefinieerde en onderhouden standaardobjecten, alsmede connectiviteitsmonitoring en remote-device-acties. Automatische firmware-upgrades vereenvoudigen ook het beheer van op LwM2M aangesloten apparaten. Hoewel het opnemen van modules zoals JSON de overhead verhoogt, maakt het ook het ontwerpwerk voor ontwikkelaars eenvoudiger. Omdat LwM2M specifiek voor IoT-toepassingen is ontworpen, kan het ook met een sterk DTLS-beveiligingsprotocol werken zonder de overhead te verhogen.

DDS voor real-time gedistribueerde toepassingen

De gegevensdistributiedienst (DDS) is een beetje anders en wordt vaak geclassificeerd als een M2M-middleware in plaats van een protocol voor de toepassingslaag. Het biedt veilige en krachtige verbindingen in (onder meer) autonome voertuigen, energieopwekking en luchtverkeersleidingssystemen. In deze omstandigheden ondersteunt DDS de verbinding van ingebedde systemen voor gedistribueerde besturing zonder al te veel afhankelijkheid van gateways. DDS zorgt ook voor de routering en aflevering van berichten zonder tussenkomst van toepassingen. Bovendien zijn de parameters voor de kwaliteit van de DDS-dienst configureerbaar - zodat de netwerkactiviteiten kunnen worden geoptimaliseerd om binnen de systeembeperkingen te werken.

Afbeelding 5: Connext Drive-software voor autonome voertuigen is gebouwd op data distribution service (DDS) middleware - die als onderdeel van de basis dient voor AUTomotive Open System ARchitecture(AUTOSAR) Adaptive en ROS2-softwarearchitecturen. Dit is slechts één voorbeeld van hoe DDS de integratie van IoT-software ondersteunt. (Bron afbeelding: Real-Time Innovations)

Conclusie: IIoT applicatielaag protocollen

Alle protocollen hebben sterke en zwakke punten, maar open-source opties die een snelle invoering en beveiliging mogelijk maken (bij voorkeur met een lage overhead) zijn het meest geschikt voor IoT-toepassingen. Ingebedde systemen en systeem-op-chip (SoC) apparaten met steeds meer rekencapaciteiten blijven de IIoT-implementatie stimuleren en zorgen voor een verdere uitbreiding van wat mogelijk is op de toepassingslagen van verschillende protocollen.