Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 5 Jahren

1-2-2019

  • Text
  • Software
  • Elektromechanik
  • Positioniersysteme
  • Antriebe
  • Stromversorgung
  • Feldbusse
  • Kommunikation
  • Robotik
  • Qualitaetssicherung
  • Bildverarbeitung
  • Automatisierungstechnik
  • Sensorik
  • Messtechnik
  • Visualisieren
  • Regeln
  • Msr
  • Boards
  • Systeme
  • Sbc
  • Ipc
Fachzeitschrift für Industrielle Automation, Mess-, Steuer- und Regeltechnik

IoT Vom Rand bis in die

IoT Vom Rand bis in die Cloud EDGE Computing die IoT-Schlüsseltechnologie Autor: Dr. Erik Lins, Entwicklungsleiter, m2m Germany GmbH, Karin Reinke-Denker M.A., PR & Marketing m2m Germany GmbH www.m2mgermany.de Glaubt man den Analysten, dann wird sich das Datenvolumen in den nächsten zehn Jahren um ein Vielfaches verdoppeln. Bereits im Jahr 2025 soll die Menge an Neu-Daten bei über 163 Zettabyte liegen. Noch wird das Gros der Computing-Last von konventionellen Datacentern befördert – sie sichern, verwalten und stellen die Daten bereit. Doch die zu erwartende Datenflut wird dies konventionelle Computing-Modell in die Knie zwingen. Dabei ist es nicht nur die Menge, die diesen Wechsel herbei zwingt, sondern auch die immer stärker wachsende Echtzeit-Relevanz neuer Daten. Motor dieses Echtzeit-Booms ist das IoT. Die stetig wachsende Zahl vernetzter „Dinge“ und der permanente Zugriff auf die gesammelten Daten, befeuern das Wachstum. Ein Zustand, der von üblichen Datacentern nicht mehr gehandelt werden kann. Für eine maximale Nutzung des IoTs wird EDGE-Computing eine unverzichtbare Schlüsseltechnologie werden. Was ist Edge Computing? Der klassische Ansatz „Alles in die Cloud“ hat in Zeiten zahlloser und immer mehr werdender, Daten generierender IoT-Devices ausgedient. Die Datenmengen verstopfen förmlich die Leitungen in die Cloud und Telekomanbieter lassen sich den Upload der Daten teuer bezahlen. Edge Computing soll diesem Umstand mit einer Zwischenschicht der Datenverarbeitung entgegenwirken. Wo genau diese Zwischenschicht angesiedelt ist, wo genau die Grenze - die Edge - liegt lässt sich nicht einheitlich sagen. Spezialisierte IoT- Gateways oder Router etwa können Daten von vielen drahtlos angebundenen IoT-Devices empfangen, lokal auswerten und reduziert in die Cloud weitergeben. Aber auch IoT- Devices selbst können die Messwerte ihrer Sensoren (vor-)auswerten und nur aktiv werden, wenn bestimmte Bedingungen eintreten. Die Grenze zur Cloud wird fließend, weshalb auch der Begriff “Fog Computing” verwendet wird. Die Rechenleistung wird dezentral auf viele Knoten verteilt, die Datenmenge in Richtung Cloud wird reduziert. daten_zur_cloud.zip Grundsätzlich schränkt die Reduzierung oder Filterung der Daten aber immer auch deren Informationsgehalt ein und reduziert damit auch die Möglichkeit zu deren Interpretation in der Cloud-Applikation. Das ist kein Mangel, sondern bedarf nur einer sensiblen Hand habung und erfordert ein detailliertes Reglement. Beim Aufstellen der entsprechenden Regeln und Algorithmen zur Datenfilterung und -reduzierung muss der passende Kompromiss gefunden werden und muss mit dem Use-Case der gesamten Anwendung abgeglichen werden. Dabei gilt es auch zu unterscheiden wie und wo die Datenreduzierung stattfindet – auf der Device- Ebene (Sender) oder auf der Gateway-Ebene (Empfänger). Datenreduzierung auf Device-Ebene Beispiel GPS Tracker Als Beispiel auf Device-Ebene kann ein batteriebetriebener GPS Tracker dienen, der zyklisch seine Position bestimmt und seine Daten drahtlos, z. B. per LoRa oder Mobilfunk, an einen Gateway überträgt. Der Messzyklus muss so gewählt werden, dass hinreichend oft eine Position bestimmt und gesendet wird, aber selten genug, damit eine lange Batterielebensdauer erzielt wird. Dabei kann es passieren, dass mehrfach dieselbe Position gesendet wird, wenn sich das Device während des Messzyklus nicht bewegt hat. Genauso kann es passieren, dass sich das Device innerhalb des Messzyklus bewegt und dabei Positionen verloren gehen, da erst am Ende des Zyklus wieder gemessen und gesendet wird. Durch Integration eines Bewegungssensors (Accelerometer) in das Device, kann dieses eine Bewegung erkennen und so aktiv werden. Abhängig vom Use-Case kann z. B. der Messzyklus während der Bewegung verkleinert werden, um die Positionsauflösung zu erhöhen. Oder die Positionsmessung wird nur am Ende der Bewegung aktiv, um 18 PC & Industrie 1-2/2019

IoT einen neuen Standort des Devices zu erfassen. Beides kommt der Batterielebensdauer zugute und reduziert die Datenmenge auf das Maß, das für den Use-Case relevant ist. Unabhängig von der Bewegungsregel kann ein solches Device, z. B. nach Ablauf einer bestimmten Zeit, in jedem Fall ein Datenpaket senden. Damit weiß die Cloud-Applikation auch in längeren Zeiten ohne Bewegung, dass das Device noch aktiv ist und kann z. B. dessen Batteriezustand überwachen. Dies wird oft als „Keep-Alive“ Daten paket bezeichnet. Beispiel Indoor Lokalisierung Eine Anwendung, die derzeit immer höhere Bedeutung gewinnt, ist die Indoor Lokalisierung von Dingen. Die Anbringungen von fixen Bluetooth LE Beacons und die Orientierung anhand derer in einem Device ist eine Lösungsmöglichkeit dazu. Das Device empfängt dazu die Advertisings der Beacons und misst dessen Empfangsfeldstärke, was ein Maß für die Entfernung ist. Die IDs der Beacons mit der zugehörigen Empfangsfeldstärke werden zu einem Gateway übertragen, das sie in die Cloud schickt. Dort findet die Auswertung statt und die Position des Devices relativ zu den Beacons wird berechnet. Für eine hohe Positionsauflösung werden oft viele Beacons platziert, was die Anzahl der empfangenen Advertisings erhöht. Abhilfe kann auch hier, wie oben beschrieben, ein Bewegungssensor schaffen, der das Prozedere nur bei oder nach Bewegung anstößt. Darüberhinaus kann das Device aber auch eine Vorauswahl der zu übertragenden IDs und Feldstärkewerte treffen. Beispielsweise werden nur die drei am stärksten empfangenen Beacons berücksichtigt und tatsächlich gesendet, da diese für die Positionsbestimmung i.d.R. ausreichen. Das Device könnte auch mehrere aufeinanderfolgende Messungen mitteln und nur den Mittelwert der Feldstärke senden. Auch das reduziert die Datenmenge und beinhaltet immernoch alle für den Use-Case notwendigen Daten. Beispieldevice Als Beispiel für ein flexibles Tracking Device, das für beide eben beschriebenen Anwendungen geeignet wäre und mit umfangreicher onboard Sensorik ausgestattet ist, ist der SmartTAG L500 der conbee GmbH. Der conbee BLE / LoRa / GNSS HybridTAG L500 ist ein autarkes IoT-Device für Sensor- 2Cloud-Anwendungen. Es kombiniert Bluetooth Low Energy BLEund LPWAN-Funktionalität mit GPS-Ortung und einer Reihe von Sensoren. Der BLE / LoRa Hybrid- TAG L500 benötigt keine SIM-Karte und ist mit gängiger Anwendungsund Cloud-Software kompatibel. Je nach Applikation können im Hybrid- TAG L500 verschiedene Sensorsysteme aktiviert werden. Der TAG meldet in definierbaren Intervallen oder Ereignis gesteuert, selbstständig nach Anforderung seine Identifikationsnummer, Temperatur-, Bewegungs-, Licht und Beschleunigungsdaten, sowie Batteriestatus und Position. Die Sensorwerte können über große Entfernungen zu einem LoRaWAN-Gateway und weiter zu IoT-Cloud-Plattformen übertragen werden. Bei Auslieferung befindet sich der TAG im sogenannten „hibernate“-Modus und kann berührungslos via Magnetfeld aktiviert werden. Jeder TAG ist nach entsprechender Authentifizierung Remote konfigurier- und wieder verwendbar, darüberhinaus ist der Hybrid Tag L500 LoRaWAN zertifiziert. Der conbee TAG ist schnell integriert und einsatzbereit. Er bietet ideale Voraussetzungen für Behälter management, Pallettenverfolgung, Lageroptimierung, Telematik-Anwendungen, Asset-Szenarien, Ortung, Diebstahlschutz, Facility-Management, Indoor & Outdoor Ortung und vielem mehr. PC & Industrie 1-2/2019 19

hf-praxis

PC & Industrie

© beam-Verlag Dipl.-Ing. Reinhard Birchel