WRD/Box - Intro ...

[kdw]

Hallo Forum.



Die WRD/Box ist für SSV so etwas, wie ein „Swiss Army Knife“ für verschiedene Remote-Aufgaben. Damit lassen sich im Rahmen von Entwicklungsprojekten unterschiedliche Fernzugriffsaufgaben erledigen. Dazu gehören:

Remote Assisted Development: Team-basierte Entwicklung einer Datenintegration direkt in der Zielumgebung, z. B. eine KI-basierte Softsensorlösung für eine bestimmte Maschine. Auf der WRD/Box werden vor der Auslieferung bestimmte Softwarebausteine vorinstalliert, die von „Remote“-Experten betreut bzw. genutzt werden.

IoT-Datenaggregationen: Rohdaten aus vernetzten Quellen (z. B. Geräte, Sensoren) sammeln, kombinieren und zusammenfassen, um ein aussagekräftiges Gesamtbild zu schaffen.

Remote-Diagnostik: Ferndiagnosen und vollständige Ende-zu-Ende (E2E)-Tests, um das Verhalten der Baugruppen und Subsysteme vor Ort detailliert zu untersuchen und ggf. vorhandene Probleme zu identifizieren.

Remote Access: VPN-, SSH- bzw. HTTPS-gesichter Fernzugriff auf die WRD/Box selbst oder auf Funktionseinheiten vor Ort, die über eine geeignete Schnittstelle (z. B. CLI per RS232) mit der WRD/Box verbunden sind.

Remote Debugging: Debug-Aufgaben auf einem Zielsystem vor Ort in der Nähe einer WRD/Box über eine Fernzugriffsverbindung ausführen. Dazu gehören auch die Code-Ausführung per Single Step, dass Setzen von Breakpoints, Trace-Datenerfassung usw.

Remote Software-Updates: Aktualisierung von Funktionen, Verbesserungen und Fehlerbehebungen durch den Austausch der Software in den Baugruppen und Subsystemen vor Ort (Device Flash Updates, DFU) über die Fernzugriffsverbindung der WRD/Box.

WRD/Boxen sind grundsätzlich modular aufgebaut. Dafür werden in einem robusten Industriegehäuse die für eine bestimmte Aufgabenstellung erforderlichen Baugruppen auf einer 35 mm-Hutschiene montiert. Die erforderliche Fernzugriffsverbindung wird in der Regel über ein integriertes 4G-Modem inklusive einer Global-SIM-Karte für den weltweiten Einsatz realisiert. Siehe hierzu auch: https://www.ssv-embedded.de/doks/daten/datasheet_wrd_box.pdf.

VG KDW

[kdw]

OT/IT Connectivity: Unter OT/IT-Konnektivität versteht man die Integration von Betriebstechnologie (OT) und Informationstechnologie (IT), um Daten aus der Produktionssteuerung (OT-Systeme wie Maschinen, SPS, Sensoren) mit Geschäftsinformationen (IT-Systeme wie ERP, MES, Datenbanken) zu verknüpfen. Diese Verbindung wird auch als OT/IT-Konvergenz bezeichnet. Sie ermöglicht die Nutzung von Produktionsdaten für Analysen, Prozessoptimierung und verbesserte Entscheidungsfindung. Die Herausforderung liegt in der sicheren und zuverlässigen Vernetzung der zwei unterschiedlichen Systemwelten, die jeweils spezifische Anforderungen an Netzwerk, Protokolle und Cybersicherheit haben.

IoT Connectivity: IoT-Konnektivität ermöglicht die Vernetzung von Geräten im Internet der Dinge (IoT), damit diese Daten austauschen und kommunizieren können. Dafür werden verschiedene Technologien wie WLAN, Mobilfunk (LTE-M, NB-IoT, 5G), Bluetooth, LPWAN (z.B. LoRaWAN) und Satelliten (NTN)-Funkverbindungen genutzt. Die Wahl der richtigen Konnektivität hängt von Faktoren wie Reichweite, Bandbreite, Energiebedarf und Kosten ab.

Embedded AI/ML: Eingebettete KI integriert künstliche Intelligenz bzw. maschinelles Lernen direkt in physische Geräte und Systeme sowie Sensoren, um Daten lokal zu verarbeiten und Entscheidungen in Echtzeit zu treffen. Diese Technologie ermöglicht Anwendungen wie autonome Fahrzeuge, Roboter, Drohnen und intelligente Gesundheitsmonitore sowie industrielle Automatisierungsanwendungen auch ohne eine Cloudverbindung unabhängig zu agieren. Dabei ergeben sich durch die jeweils genutzte Hardware unterschiedliche technische Herausforderungen, z. B. über Batterie-basierte Energieversorgungen sowie begrenzte Speicher- und Rechenleistung. Siehe hierzu auch https://ssv-comm.de/forum/viewtopic.php?t=1660.

[kdw]

Eine WRD/Box lässt sich auch als OoB Debug- und Test-Proxy für Wireless IoT-Lösungen direkt in einer Zielumgebung einsetzen, um effektive Ende-zu-Ende-Test durchzuführen. Zu einem solchen Testszenario gehören die folgenden Fragestellungen:

Hat der WSN-Knoten etwas gesendet? Die einzelnen Funksensoren im WSN senden in einer sternförmigen Netzwerktopologie diverse Datenpakete an das Gateway. Mit Hilfe einer SDR Sniffer Mode-Konfiguration lässt sich feststellen, was jeweils gesendet wurde.

Hat das Gateway es gehört? Durch einen speziellen Gateway Service Link-Zugriff wird geprüft, ob die jeweiligen WSN-Daten auch empfangen wurden (in der Regel lösen diese WSN-Daten auch eine Datenübertragung vom Gateway an den Cloud Service aus).

Hat der Cloud Service die Sendedaten erhalten? Mit Hilfe gezielter Cloud Service-Zugriffe lässt sich feststellen, ob die vom IoT Gateway per WWAN gesendeten Daten den Cloud Service erreicht haben.

Konnte der Cloud Service die Sendedaten verwerten (also z. B. dekodieren/zuordnen)? Die an den Cloud Service gesendeten Daten müssen bestimmte Vorgaben (beispielsweise bzgl. der Zugriffsrechte, Datenformate usw.) erfüllen, damit sie bestimmungsgemäß verarbeitet werden können. Per Cloud Service-Zugriff lässt sich das Ergebnis prüfen.

Hätte der Cloud Service etwas zurücksenden sollen bzw. müssen? Über Cloud Service-Zugriffe lässt sich feststellen, ob die Cloud etwas an das IoT Gateway sendet oder nicht (hier sind evtl. Steuerungsfunktionen der Cloud bzw. Benutzerinteraktionen einzubeziehen, z. B. mittels einer externen Smartphone-App).

Hat der Cloud Service etwas an das Gateway gesendet? Per Gateway Service Link-Zugriff lässt sich prüfen, ob die WWAN-Datenübertragung vom Gateway auch empfangen und verarbeitet wurde.

Hat das Gateway diese Daten an den WSN-Knoten gesendet? Falls die WWAN-Datenübertragung von Cloud Service zum Gateway eine WSN-Datenübertragung zur Folge hat, lässt sich per SDR Sniffer Mode prüfen, ob die WSN-Daten vom Gateway erwartungsgemäß verschickt wurden.

Hat der WSN-Knoten die Daten empfangen? Diese Frage lässt sich nur sicher beantworten, wenn das zum Einsatz kommende Kommunikationsprotokoll eine Bestätigung vorsieht, die sich mittels dem SDR Sniffer Mode aufzeichnen lässt oder wenn eine zusätzliche Debug-und-Test-Verbindung zum WSN-Knoten besteht (z. B. per SWD).

Eine wichtige Funktionseinheit für solche speziellen Aufgabenstellungen ist das Software Defined Radio (SDR) der WRD/Box. Eine typische SDR-Hardware besteht aus einem (analogen) Sender- und Empfängermodul als RF-Interface, sowie mehreren A/D- und D/A-Wandlern plus einem digitalen Base Band Processing, also z. B. eine Software-basierte digitale Signalverarbeitung mit Digitalen Signalprozessoren (DSPs). Zwischen den Wandlern und dem DSP ist ein Digital Front End mit einer IQ-Datenschnittstelle zu finden, der verschiedene Adaptionsaufgaben ausführt.



SDRs lassen sich mittels Software-basierter Konfigurationsdaten auf verschiedene Frequenzbereiche einstellen. Dafür werden sogenannte Variable Frequency Oscillators (VFO) genutzt. Sie erzeugen die jeweils erforderliche Referenzfrequenz (z. B. 868,3 MHz, wie in der folgenden Abbildung erkennbar), um die IQ-Daten innerhalb der ebenfalls konfigurierbaren Bandbreite abzutasten. Typische SDR-Baugruppen ermöglichen Anwendungen im Bereich zwischen 70 MHz bis 6 GHz. High-end Varianten für militärische Anwendungen lassen sich sogar für Mikrowellen im 40 GHz-Bereich nutzen.



Mit einem SDR und der passenden Software lassen sich die jeweils erfassten IQ-Daten sowohl als Echtzeit-Frequenzspektrum als auch der FFT-Plot mit Wasserfalldiagramm für die Datenübertragung eines Wireless IoT-Sensor-Netzwerks im 868 MHz-Frequenzbereich visualisieren. Damit ist dann auch die individuelle Auslastung des jeweiligen Funkkanals (Airtime) innerhalb einer bestimmten Anwendungsumgebung bestimmbar.