Protokolloptionen der Anwendungsschicht für M2M- und IoT-Funktionalität
Zur Verfügung gestellt von Nordamerikanische Fachredakteure von DigiKey
2021-04-27
Seit der Einführung des Internet der Dinge (IoT) und Industrie 4.0 werden Geräte zunehmend über Industrieprotokolle verbunden. Hinzu kommt, dass die heutige Maschine-zu-Maschine-Kommunikation (M2M) schnell auf diese Protokolle standardisiert wird. Erschwerend kommt hinzu, dass die IoT-Protokolle kein einheitliches Protokoll der Anwendungsschicht beschreiben, da mehrere Standards im Einsatz sind. Während also frühe IoT-Implementierungen Standard-Internetprotokolle verwendeten, gibt es jetzt auch dedizierte IoT-Protokolle.
Die Modellierung von Kommunikationsstrukturen und die Identifizierung des richtigen Protokolls für eine bestimmte Anwendung kann entmutigend sein. In diesem Artikel wird beschrieben, was die verschiedenen Protokolle bewirken und welche Optionen für diese Protokolle zur Verfügung stehen - so können Entwicklungsingenieure leichter das am besten geeignete für die Integration auswählen.
Abbildung 1: IIoT-Funktionen in der industriellen Automatisierung basieren auf zunehmend verbundenen Geräten, die industrielle Protokolle zur Vernetzung nutzen. Die abstrahierten Schichten dieser Netzwerke erfordern kein Wissen über die Funktionen der darunter liegenden Schichten, deshalb konzentriert sich so viel Entwicklung auf die oberste (Anwendungs-)Schicht der Maschinennetzwerke. (Bildquelle: Getty Images)
Definieren des Protokolls der Anwendungsschicht für industrielle Netzwerke
Die Strukturen von Kommunikationsprotokollen für digitale M2M- und IoT-Systeme werden konzeptionell in abstrakte Schichten unterteilt, wobei die gängigsten Modelle drei, vier, fünf oder sieben Schichten aufweisen. Diese konzeptionellen Rahmenwerke gehen davon aus, dass jede Schicht im Wesentlichen die detaillierte Funktionsweise eines bestimmten Geräts oder einer Softwareschicht vor anderen Geräten oder Algorithmen „versteckt“, mit denen sie kommuniziert. Das liegt daran, dass die Ebenen so definiert sind, dass sie gerade genug Informationen für den jeweiligen Datenaustausch enthalten.
Abbildung 2: Traditionelle Systemarchitekturen sind hierarchisch, aber Cloud- und Fog-Computing haben die Grenzen zwischen den Komponentenfunktionen verwischt. Das hat zur Verwendung neuer Netzwerkprotokollmodelle geführt. (Bildquelle: motioncontroltips.com)
Unabhängig vom verwendeten Modell etablieren alle eine Anwendungsschicht als höchste Abstraktionsschicht zwischen Geräten, die in einem Netzwerk miteinander kommunizieren. Betrachten Sie die Anwendungsschicht als ein Konzept des OSI-Modells (OSI: Open Systems Interconnection) - in dem sie von der International Organization for Standardization (ISO) vor fast drei Jahrzehnten erstmals für die Netzwerkkommunikation definiert wurde. Dieses klassische Sieben-Schichten-Modell ist etwas zu kompliziert, um einige der heutigen Protokolle zu beschreiben, ist aber immer noch nützlich, um den Datenfluss innerhalb von Systemen vollständig zu verstehen:
Die physikalische Schicht eines Protokolls ermöglicht die Übertragung von Rohdaten (digitalen Bits) als elektrische, Funk- oder optische Signale. Diese Schicht spezifiziert die Pin-Layouts, Spannungspegel, Datenraten und Leitungsimpedanzen der physikalischen Elemente, die die Daten übertragen. Ethernet ist ein gängiges Protokoll der physikalischen Schicht. Lesen Sie den DigiKey-Artikel EtherNet/IP versus PROFINET für weitere Informationen dazu.
Die Datenverbindungsschicht verbindet die Netzwerkknoten, damit die Geräte Verbindungen herstellen und Fehler auf der physikalischen Schicht korrigieren können. Innerhalb des Standards IEEE 802 ist die Datenverbindungsschicht in eine MAC-Schicht (Medium Access Control, Medienzugriffssteuerung) (wiederum, um Geräte zu verbinden) und eine LLC-Schicht (Logical Link Control) zur Identifizierung der nächsten zu verwendenden Schicht (der Netzwerkschicht) sowie zur Fehlerprüfung und Synchronisation unterteilt. Lesen Sie mehr über die Funktionen der Datenverbindungsschicht im DigiKey-Artikel Implementierung von industriellem Ethernet mit 32-Bit-MCUs. Im Gegensatz dazu ermöglicht die Netzwerkschicht die Weiterleitung von Datenpaketen an Netzwerkadressen. Bei Internetprotokollen, die sich auf das TCP/IP-Modell (Transmission Control Protocol und Internet Protocol) beziehen (das im nächsten Abschnitt dieses Artikels behandelt wird), gibt es eine Internetschicht zwischen der Datenverbindungs- und der Netzwerkschicht. Tatsächlich wird die Internetschicht oft als Teil der Netzwerkschicht betrachtet.
Die erste der nächsten drei Schichten des OSI-Modells ist die Transportschicht, die die Zuverlässigkeit und Sicherheit der Kommunikation bei der Übertragung von Datenfolgen gewährleistet. Die Sitzungsschicht steuert dann, wann sich Geräte miteinander verbinden und ob die Verbindung in eine Richtung (Simplex) oder in zwei Richtungen (Duplex) erfolgt. Schließlich ermöglicht die Präsentationsschicht die Datenübersetzung, so dass Geräte mit unterschiedlichen Syntaxen kommunizieren können.
Der Schwerpunkt dieses Artikels - die Anwendungsschicht - ist die höchste Abstraktionsebene und diejenige, mit der Benutzer und Systemsoftware interagieren.
Abbildung 3: Moderne Netzwerkprotokolle (und die Anwendungsschicht) werden oft mit dem klassischen OSI-Modell für industrielle (und kommerzielle) Netzwerke beschrieben. Im Gegensatz dazu setzen dreischichtige IoT-Architekturmodelle die Anwendungsschicht über Wahrnehmungs- und Netzwerkschichten; vierschichtige Modelle setzen sie über Datenverarbeitungs-, Netzwerk- und Erfassungsschichten. Fünfschichtige IoT-Protokollmodelle sind ähnlich, fügen aber Verarbeitungs- und Unternehmensschichten hinzu. (Bildquelle: Design World)
Internet-Protokolle in der industriellen Automatisierung
Internet-Protokolle sind Datenkommunikationssysteme, die so genannt werden, weil sie Daten zwischen Netzwerken (und in der Regel wechselseitig) zur grenzüberschreitenden Kommunikation weiterleiten. Ihre Funktionen werden oft mit dem oben erwähnten Vier-Schichten-Modell von TCP/IP beschrieben. Hier entspricht die physikalische Netzwerk- oder Verbindungsschicht der physikalischen Schicht des OSI-Modells. Im Gegensatz dazu behandelt die TCP/IP-Internetschicht (die in etwa eine Kombination der Funktionen der Datenverbindungs- und Netzwerkschicht des OSI-Modells darstellt) sowohl Verbindungen als auch Datenpakete. In IPv6 verwendet diese Schicht 128-Bit-IP-Adressen, um Hosts im Netzwerk zu identifizieren - und erlaubt mehr als 1038 eindeutige Hosts.
Die Transportschicht in TCP/IP besteht im Allgemeinen entweder aus dem Transmission Control Protocol (TCP) oder dem User Datagram Protocol (UDP). TCP wird im Allgemeinen für menschliche Interaktionen wie E-Mail und Web-Browsing verwendet. Es stellt logische Verbindungen, die Bestätigung gesendeter Pakete, die erneute Übertragung verlorener Pakete und die Flusskontrolle bereit. Eingebettete Systeme verwenden jedoch UDP, um einen geringeren Overhead und eine bessere Echtzeitleistung zu erhalten. UDP wird für Domain Name Server (DNS) und das Dynamic Host Configuration Protocol (DHCP) sowie für neue IoT-Anwendungen verwendet.
Die Anwendungsschicht ist die höchste Ebene im TCP/IP-Modell der Netzwerke. Zu den Funktionen gehören diejenigen, die mit den Sitzungs- und Präsentationsschichten des OSI-Modells verbunden sind.
Allgemeine TCP/IP-Protokolle der Anwendungsschicht
Verschiedene Protokolle der Anwendungsschicht haben unterschiedliche Datenbandbreiten, Echtzeitfähigkeiten und Hardwareanforderungen. Diese Faktoren sind zusammen mit der Vertrautheit der Anlage oder des OEM-Teams mit einem Protokoll oft ein wichtiges Auswahlkriterium. Während frühe Internetprotokolle wie das Hypertext Transfer Protocol (HTTP) und das Simple Mail Transfer Protocol (SMTP) größtenteils für die vom Menschen gesteuerte und konsumierte Kommunikation verwendet werden, konzentrieren sich TCP/IP-Protokolle mit einer IIoT-Ausrichtung eher auf M2M (Maschine-zu-Maschine) und andere industrielle Kommunikation.
Erschwerend kommt hinzu, dass viele etablierte Protokolle der Anwendungsschicht, die in TCP/IP für webbasierte menschliche Interaktionen mit Informationen verwendet werden, auch im IoT für Verbraucher und Industrie eingesetzt werden. Das gilt für HTTP und SMTP ebenso wie für das Secure Shell (SSH) und das File Transfer Protocol (FTP). Die Implementierung von IoT-Funktionen mit Webtechnologien ist in der Regel machbar, wenn auch eXtensible Markup Language (XML) und JavaScript Object Notation (JSON) verwendet werden. Ein Vorbehalt ist, dass die Verwendung von HTTP Sicherheitsimplikationen hat. Deshalb ist es in der Regel am besten, wenn alle IoT-Geräte in solchen Systemen nur einen Client enthalten - und keinen Server. Dadurch wird verhindert, dass das Gerät Verbindungsanfragen erhält, die einen unbefugten Zugriff von außen auf das Netzwerk ermöglichen könnten. Hier kann das WebSocket-Protokoll eine Vollduplex-Kommunikation über HTTP aufbauen. Andernfalls kann das „Extensible Messaging and Presence Protocol“ (XMPP) für Installationen bevorzugt werden, die eine große Anzahl von Geräten mit guter Sicherheit und Echtzeit-Datenkommunikation ansprechen müssen.
Wenn IoT-Projekte von Mitarbeitern mit IT-Hintergrund geleitet werden, können diese vertrauten Standards (aus dem menschenlesbaren Web) bevorzugt werden. Allerdings können neuere IIoT-Protokolle in einigen Fällen besser für M2M und andere industrielle Kommunikation geeignet sein.
MQTT für vertikale Verbindungs-Transportfunktionen
Das MQTT-Protokoll (Message Queuing Telemetry Transport) hat sich im IIoT am schnellsten durchgesetzt - ein leichtgewichtiges Protokoll, das ursprünglich für IoT-Geräte mit begrenztem Speicher gedacht war. MQTT wurde zuerst von IBM entwickelt, um Sensoren in Ölpipelines zu verbinden und bietet eine kompakte Verarbeitungsfläche bei minimaler Bandbreite. Anders als das Constrained Application Protocol (CoAP) ist MQTT bereits nach ISO/IEC 20922 standardisiert. MQTT verwendet die etwas ressourcenintensivere TCP-Transportschicht und verbraucht daher mehr Strom, aber die Nachrichten können zwei Bytes groß sein - noch kleiner als die von CoAP.
Aufgrund seiner offenen Natur kann MQTT auch besonders einfach implementiert werden. Kein Wunder, dass AWS IoT von Amazon Web Services MQTT für den Nachrichtentransport einsetzt und (mit Einschränkungen) MQTT auf Basis der Spezifikation v3.1.1 unterstützt.
MQTT hat einige Einschränkungen, die möglicherweise darauf zurückzuführen sind, dass MQTT ursprünglich als Telemetrie-Protokoll gedacht war - im Gegensatz zum IoT-spezifischen LwM2M-Protokoll (Lightweight Machine to Machine), das wir in Kürze behandeln werden. Merkmale wie Objekte, Verbindungsüberwachung und Remote-Geräteaktionen sind nicht im Standard enthalten, so dass deren Einbindung tendenziell herstellerspezifisch ist, was den Wert des standardisierten Protokolls etwas schmälert. MQTT bietet auch keine Fähigkeiten zur Fehlerbehandlung. Schließlich kann MQTT zwar mit einem vollständigen TLS-Protokoll abgesichert werden, dies erhöht jedoch den Overhead.
Vor allem auf Unternehmensebene: AMQP
AMQP (Advanced Message Queuing Protocol) ist ein weiterer offener Standard mit einigen Ähnlichkeiten zu MQTT. Es bietet erweiterte Funktionen wie beispielsweise Nachrichtenwarteschlangen. Allerdings ist der Overhead von AMQP höher als der von MQTT, wodurch es sich schlecht für die Verbindung sehr eingeschränkter Geräte eignet. Kein Wunder, dass der Einsatz in industriellen IoT-Anwendungen weniger verbreitet ist als der Einsatz im leistungsorientierten Unternehmensnachrichtenverkehr.
CoAP für die Verbindung einfacher Geräte
Das Constrained Application Protocol (CoAP) der Internet Engineering Task Force (IETF) ermöglicht die Kommunikation in stromsparenden Netzwerken zwischen Geräten mit minimaler Speicher- und Rechenleistung. Es kann mit sehr geringem Overhead arbeiten und Anfragen und Antworten können so klein wie vier Bytes sein. CoAP verzichtet auf die Verwendung eines komplexen Transportstacks und verwendet stattdessen UDP. Weitere Informationen zu UDP finden Sie in dem oben verlinkten DigiKey-Artikel über EtherNet/IP gegenüber PROFINET. Wie HTTP verwendet auch CoAP das REST-Modell - mit Servern, die Ressourcen unter einer URL zur Verfügung stellen, und Clients, die über die Methoden POST, GET, DELETE und PUT darauf zugreifen. Darüber hinaus kann CoAP zur Integration mit anderen Web-Funktionen einfach in HTTP übersetzt werden und lässt sich mit XML und JSON integrieren. Ingenieure sollten feststellen, dass die Verbindung von IoT-Geräten mit CoAP der Verbindung von Geräten mit Web-API sehr ähnlich ist.
Abbildung 4: Das SiP von Nordic ist eine energiesparende MCU mit integriertem LTE-M- und Schmalband(NB)-IoT-Modem sowie GPS. Ein Software-Entwicklungskit ermöglicht die Einrichtung von CoAP. (Bildquelle: Nordic Semiconductor)
Verbindung von batteriebetriebenen Geräten über LwM2M
Ein Protokoll der Anwendungsschicht von der Open Mobile Alliance ist das LwM2M-Protokoll, das speziell für IoT-Anwendungen entwickelt wurde. LwM2M wird in Smart-City-Anwendungen, bei der Verfolgung von Schiffscontainern und Ladungen, bei automatisierten Off-Highway-Routinen und bei der Überwachung von Versorgungseinrichtungen eingesetzt und basiert auf CoAP, so dass es viele seiner Eigenschaften teilt. Der Standard umfasst eine Vielzahl von klar definierten und gepflegten Standardobjekten sowie Verbindungsüberwachungs- und Remote-Device-Aktionen. Automatische Firmware-Upgrades vereinfachen auch die Verwaltung der an LwM2M angeschlossenen Geräte. Die Einbindung von Modulen wie JSON erhöht zwar den Overhead, erleichtert den Entwicklern aber auch die Designarbeit. Da LwM2M speziell für IoT-Anwendungen entwickelt wurde, kann es auch ein starkes DTLS-Sicherheitsprotokoll betreiben, ohne den Overhead zu erhöhen.
DDS für verteilte Echtzeitanwendungen
Der Datenverteilungsservice (DDS) ist ein wenig anders - und wird oft eher als M2M-Middleware denn als Protokoll der Anwendungsschicht eingestuft. Es sorgt für sichere und leistungsstarke Verbindungen unter anderem in autonomen Fahrzeugen, bei der Stromerzeugung und in Flugsicherungssystemen. In diesen Umgebungen unterstützt DDS die Verbindung von eingebetteten Systemen für eine verteilte Steuerung, die nicht mehr auf Gateways angewiesen ist. DDS übernimmt auch das Routing und die Zustellung von Nachrichten, ohne dass ein Eingreifen von Anwendungen erforderlich ist. Außerdem sind die Parameter für die Qualität der DDS-Dienste konfigurierbar - so kann der Netzwerkbetrieb innerhalb der Systemgrenzen optimiert werden.
Abbildung 5: Die Software „Connext Drive“ für autonome Fahrzeuge basiert auf der DDS-Middleware (Data Distribution Service) - die als Teil der Grundlage für die adaptiven AUTOSAR- (AUTomotive Open System ARchitecture) und ROS2-Softwarearchitekturen dient. Dies ist nur ein Beispiel dafür, wie DDS die IoT-Softwareintegration unterstützt. (Bildquelle: Real-Time Innovations)
Fazit: IIoT-Protokolle der Anwendungsschicht
Alle Protokolle haben Stärken und Schwächen, aber Open-Source-Optionen, die eine schnelle Bereitstellung und Sicherheit (vorzugsweise mit geringem Overhead) ermöglichen, sind für IoT-Anwendungen am besten geeignet. Eingebettete Systeme und System-on-Chip(SoC)-Geräte mit immer größerer Rechenleistung treiben die IIoT-Implementierung weiter voran - und erweitern die Möglichkeiten auf den Anwendungsebenen verschiedener Protokolle weiter.

Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der DigiKey oder offiziellen Politik der DigiKey wider.