embedded world 2025 ...

kdw · Joined: 05 May 2006 Posts: 1514

Wireless Remote Development (WRD)

Mit dem neu entwickelten Werkzeugkasten WRD Toolbox bietet SSV den Entwicklern von Wireless IoT-Anwendungen verschiedene Werkzeuge für Debugging, Ende-zu-Ende-Tests und dem Monitoring mit Telemetriedaten zu allen relevanten Anwendungskomponenten. Die modularen WRD Toolbox-Funktionsbausteine ermöglichen umfassende Feldtests in realen Anwendungsumgebungen.

Jeder, der schon einmal an der Neuentwicklung einer etwas komplexeren Embedded Systems-Software beteiligt war, kennt die Herausforderung: Alle Einzelkomponenten wurden einem Unit-Test unterzogen, das Zusammenspiel über Integrations- sowie Funktionstests sichergestellt und abschließend noch ein umfassender Systemtest erfolgreich durchgeführt. Trotzdem sind einige Baugruppen mit der neuen Software sofort nach der ersten Auslieferung bei den Kunden ausgefallen. Eigentlich sind auch die Ausfallgründe bekannt: Die zuvor genannten Tests wurden schließlich in der Entwicklungsumgebung und in speziellen Prüflaboren durchgeführt. Die Umgebungsbedingungen und ganz besonders mögliche Störgrößen in einer Anwendungsumgebung sehen aber häufig völlig anders aus – besonders, wenn Wireless-Funktionen und Batteriebetriebsarten genutzt werden, sind hier zahlreiche Überraschungen zu erwarten. Hinzu kommt die unvorhersehbare Kreativität der Anwendungsnutzer und dadurch verursachte Interaktionssequenzen. Eine bekannte Fragestellung in diesem Kontext lautet daher: Wie ermitteln wir die ursächlichen Details für jeden einzelnen Ausfall und welche Softwareänderungen sind erforderlich, um derartige Ausfälle zu vermeiden?

Um den Herausforderungen einer Wireless IoT-Entwicklung zu begegnen, hat SSV einen neuen Werkzeugkasten mit dem Namen “Wireless Remote Development (WRD)” entwickelt. Die WRD Toolbox beinhaltet Methoden und Funktionsbausteine für die drei Aufgabenbereiche Debuggen, Ende-zu-Ende (E2E)-Testen und Monitoring. Die zentrale Komponente der SSV-Neuentwicklung sind die WRD Services. Sie werden als Integrationsebene in einer Cloud oder On-Premises zwischen den Embedded Systemen und IT-Softwarekomponenten einer IoT-Anwendung betrieben. Über diese Dienste lässt sich ein DevOps Team fortlaufend mit Telemetriedaten der gesamten Anwendung versorgen. Des Weiteren ermöglichen die WRD Services speziell gesicherte Debugging-Fernzugriffe auf alle Softwarefunktionen, also vom einzelnen Embedded System eines Wireless IoT-Sensors bis zur Smartphone App des Anwenders der IoT-Applikation. Durch den Umfang dieser horizontalen Systemintegration steht IoT-Entwicklern erstmals eine multifunktionale E2E-Testplattform als modulare Anwendung zur Verfügung.

F&E-Manager Jürgen Fitschen von SSV erklärt: „Aus der Cybersecurity-Perspektive ist besonders das Wireless Remote Debugging eines IoT Endpunkts eine hochsensible Angelegenheit. Deshalb haben wir eine Pairing-Methode sowie einen hochsicheren Ende-zu-Ende-Tunnel entwickelt, der zwar einen zentralen WRD Rendezvous Service als transparente Infrastrukturkomponente nutzt. Aber selbst dieser Kommunikationsservice kann die verschlüsselten Sessiondaten weder einsehen noch manipulieren. Der erforderliche Schlüssel zum Pairing beider Endpunkte wird mittels einer optischen Datenübertragung zwischen dem Entwickler-PC-Bildschirm und der Remote Debugger Device direkt ausgehandelt. Ein ähnliches Verfahren wird beispielsweise auch im Bankwesen zur Generierung sicherer TANs per Flickercode genutzt. Eine gesicherte Remote Debug-Verbindung kann nur durch ein neues Pairing oder per Sperrliste gelöst werden.“

Sie finden SSV auf der embedded world 2025 in Halle 4 auf Stand 4-638.

kdw · Joined: 05 May 2006 Posts: 1514

Hallo Forum.

Ein sehr großes Interesse bestand an unserer „Wireless Remote Debugging“-Demo. Wir hatten zwar zunächst etwas mit den stark schwankenden Latenzzeiten der LTE Cat-M1-Verbindung in den Nürnberger Messehallen zu kämpfen, aber eine solche Messe mit vielen Besuchern ist auch immer ein ideales Testumfeld für unsere These „Eine funkbasierte Embedded Systems-Anwendung verhält sich vor Ort in der Anwendungsumgebung immer völlig anders, als in der Entwicklungsumgebung“. Das Problem ließ sich aber lösen.

Anschließend konnten wir vielen interessierten Besuchern live vorführen, wie man per Visual Studio Code (VSCode) von einem Entwicklungsrechner aus, der per Wi-Fi und 4G mit dem Internet verbunden war, am anderen Ende unseres Messestands eine neue Firmware in den Flash eines STM32 Nucleo-Boards programmieren und debuggen konnte. Diese Remote-Seite der Demo hatte über unsere Neuentwicklung, den WRD/Probe, einen LTE Cat-M1-basierten Internetzugang. Für den Remote-Zugriff wurde das GDB/gdbserver-Protokoll mit einigen Erweiterungen und ein von uns betriebener Rendezvous Service verwendet.

Jeder, der schon einmal an der Entwicklung eines IoT-Endpunkts (also einer IoT Devices) beteiligt war, kennt die Herausforderungen: Durch MCU und Embedded-Betriebssystem, Sensoren, RF-Kommunikationsfunktionen und vielfach auch einer Batteriespannungsversorgung, ist eine IoT Device ein relativ komplexes System, dass sich nur sehr bedingt innerhalb einer Entwicklungsumgebung mit Hilfe simulierter Umgebungsparameter und größten Teils idealen Umgebungsbedingungen vollständig testen lässt. Insofern werden zahlreiche Debugaufgaben im Rahmen eines Feld- bzw. Ende-zu-Ende (E2E)-Tests direkt in der Anwendungsumgebung durchgeführt. Dafür schafft ein WRD/Probe zusammen mit einem speziellen Rendezvous Service die technischen Voraussetzungen.

Bei der Entwicklung dieser Wireless Remote Development (WRD)-Lösung war uns besonders wichtig, dass ein Nutzer am seinem Arbeitsplatz für das WRD-Debugging die gleichen Werkzeuge wie zum lokalen Debuggen nutzen kann: Mit anderen Worten: Das WRD-Debuggen wird nahtlos in die jeweils existierende Entwicklungsumgebung integriert. Das Starten des Build-Vorgangs, einen Breakpoint setzen, Variablen inspizieren usw. bleibt von der Bedienung her gleich.

Der batteriebetriebene WRD/Probe lässt sich durch die LTE Cat-M1-Funkschnittstelle und den integrierte SIM-Modul eines virtuellen Mobilfunkbetreibers (MVNO) weltweit völlig ortsunabhängig einsetzen und per Internet über den Rendezvous Service mit einer Entwicklungsumgebung irgendwo anders auf der Welt verbinden. Dabei entsteht ein virtuelles Debug-Kabel. Es stellt mit Hilfe etablierter Standards eine GDB-Schnittstelle bereit, die sich nahtlos in typische Entwicklungsumgebungen wie VSCode oder Eclipse integrieren lässt. Hier eine Übersicht der fünf wichtigsten WRD/Probe-Funktionen:

1. Debug-Session: Remote Debuggen direkt aus der vertrauten Entwicklungsumgebung mit GDB/gdbserver-Funktionen.

2. Flash-Update: Einen neues Flash-Image in die Target Device programmieren.

3. Serial Logging: Aufzeichnen der seriellen Ausgaben einer Target Device.

4. Power Consumption Monitoring: Messen der Energieaufnahme der Target Device.

5. Target Device Reset: Erzeugen eines Reset-Signals für die Target Device, um einen definierten Ausgangszustand herzustellen.

VG KDW

kdw · Joined: 05 May 2006 Posts: 1514

Hallo Forum.

Ein weiteres Beispiel veranschaulichte die Entwicklung einer KI-basierten-Softsensorlösung, um mit Hilfe virtueller Betriebsstundenzähler bedarfsgerechte Wartungstermine für eine Anlage zu koordinieren. Die finale Sensorik soll sich im Rahmen eines digitalen Retrofits nachrüsten lassen. Als Laufzeitumgebung für die Softsensorfunktionen kommt die Retrofitsensorik in der Anlage selbst bzw. ein bereits vorhandenes Edge-Gateway in Frage. Die einzelnen virtuellen Betriebsstundenzähler sollen die Summenwerte für vier unterschiedliche Betriebszustände bilden.

Zur Datenevaluierung und KI-Modellentwicklung lässt sich eine WRD/Box mit verschiedenen Hardware-Sensoren direkt vor Ort in der Anwendungsumgebung in der Anlage installieren. Ein externes Entwicklerteam kann per Sensorfernzugriff die erforderlichen Datenanalysen in der Entwicklungsumgebung ausführen, ein KI-Modell entwickeln und über weitere Fernzugriffe in der Anwendungsumgebung mit echten Betriebszuständen austesten. Auch der finale Ende-zu-Ende (E2E)-Test der gesamten Lösung lässt sich in diesem Szenario durchführen.

Eine große Herausforderung bei der KI-Modellentwicklung für eine Softsensorlösung im Umfeld von Maschinen und Anlagen sind die Daten – zum einen hinsichtlich der Quantität, besonders aber mit Blick auf die Qualität. Insofern wird am Anfang des Entwicklungsvorhaben zunächst einmal ein zur Aufgabenstellung passendes Eingangsdatenbild entworfen. Dabei eignet sich ein Top-Down-Ansatz als zielführende Vorgehensweise, z. B. mit der hier folgenden Gliederung:

1. Welche Fragestellung soll beantwortet werden?
2. Welche Informationen werden für die Antwort benötigt?
3. Welche Daten sind zur Informationsgewinnung erforderlich?
4. Welche Sensoren werden zur Datenerzeugung benötigt?

Besonders die letzte Frage (Welche Sensoren werden benötigt?) erfordert eine gewisse Flexibilität. Es ist davon auszugehen, dass in der Anfangsphase der Entwicklung diverse Datenerfassungsversuche mit verschiedenen Sensorelementen durchgeführt werden.

Siehe auch: https://www.ssv-embedded.de/doks/manuals/sr_rmg938a_en.pdf (das RMG/938AL wird in der WRD/Box eingesetzt).

Insgesamt folgt die Entwicklung einer KI-basierten Softsensorlösung dem Workflow eines MLOps (Machine Learning Operations), also einer Reihenfolge von Entwicklungsschritten für die Softwareentwicklung und -pflege Machine Learning-basierter Anwendungen. Durch eine WRD/Box entsteht eine Kommunikationsverbindung zwischen Anwendungs- und Entwicklungsumgebung, die sich sowohl zur Datenerfassung als auch für verschiedene Testszenarien nutzen lässt.

Das Beispiel verdeutlicht auch die Komplexität eines ML-Lebenszyklus mit Datenerfassung, Datenaufbereitung, Training, Modelloptimierung, Modellimplementierung, Integration in eine Edge-Hardware, Überwachung, Erklärbarkeit und vielem mehr. Zudem erfordert er die Zusammenarbeit und übergreifende Aufgabenverteilung mehrerer Teams – vom KI-Modell-Architekten über Modell-Integratoren bis hin zu den Anwendern. Ebenso ist eine Konsequenz aller Beteiligten notwendig, um die erforderlichen Prozesse zu synchronisieren und gemeinsam zu bearbeiten. MLOps umfasst das Experimentieren, Iterieren und fortlaufende Verbessern des ML-Lebenszyklus. Im Rahmen einer KI-basierten-Softsensorentwicklung schafft eine WRD/Box die erforderlichen Voraussetzungen für ein gemeinsames Daten- und Funktionsverständnis.

VG KDW

kdw · Joined: 05 May 2006 Posts: 1514

Hallo Forum.

Unter dem Produktnamen „WRD/Box“ bieten wir ein modulares Rechnersystem mit einer funkbasierten Internetverbindung in einem industriellen Installationsgehäuse mit integrierter DIN-Hutschiene an, um die datenbasierte OT- und IoT-Anwendungsentwicklung zu unterstützen. Ein typisches Anwendungsbeispiel wäre die Datenevaluierung am Anfang sowie der Ende-zu-Ende (E2E)-Test zum Abschluss der Entwicklungsarbeiten einer KI-basierten Softsensorbaugruppe in der Anwendungsumgebung eines Kunden.

Für den E2E-Test wird die neu entwickelte Softsensorbaugruppe als „Device Under Test (DUT)“ mit der WRD/Box verbunden. Diese Verbindung lässt sich je nach den individuellen Anforderungen hardware- und softwareseitig flexibel gestalten. Im einfachsten Fall reicht eine USB-, UART- oder Ethernet-LAN-Schnittstelle aus. Aber auch SWD- und JTAG-Debug-Interfaces sowie Bluetooth, WLAN (Wi-Fi) und andere ISM-Funkschnittstellen sind möglich.

Eine WRD/Box besteht immer aus mindestens einem Netzteil und einem Wireless-Gateway, die zusammen auf eine Hutschiene im Installationsgehäuse montiert und verdrahtet werden. Hier die wichtigsten Eckdaten einer WRD/Box-Beispielkonfiguration mit einem RMG/938L-Gateway:

Jede WRD/Box besitzt eine WWAN-Verbindung (WWAN = Wireless Wide Area Network) zum Internet, über die sich ein entsprechend autorisierter (Remote-) Experte per Fernzugriff mit der Box verbinden und auf die DUT zugreifen kann. Für diese Internetverbindung werden verschiedene Technologien, wie 4G, 5G oder ein Satelliten-Link als Alternativen genutzt. Darüber hinaus existiert auch eine lokale Schnittstelle (z. B. ein Ethernet-LAN-Interface), um dem Anwender vor Ort ebenfalls den Zugriff auf die WRD/Box-Ressourcen zu ermöglichen.

Eine WRD/Box basiert auf einem Linux-Betriebssystem und bietet verschiedene Webschnittstellen sowie einen SSH-Zugang für den Benutzerzugriff. Zusätzlich ist in das Linux ein spezieller Wireless Remote Development Software Stack eingebunden, z. B. um einen Software-Update in die angeschlossene DUT einzuspielen, eine Debugging-Sitzung der DUT-Firmware oder ein Monitoring mit Telemetriedaten zu ermöglichen. Insgesamt dient die WRD/Box als Werkzeug für Entwickler- bzw. DevOps-Teams, um im Rahmen einer Internet-basierten Remote-Sitzung vor Ort in einer Anwendungsumgebung die jeweils erforderlichen Debug-, Test- und Monitoringaufgaben auszuführen und darüber hinaus mit dem Anwender zu kooperieren.

Siehe auch: https://www.ssv-embedded.de/doks/manuals/sr_rmg938a_en.pdf (das RMG/938AL wird in der WRD/Box eingesetzt).

Siehe auch: https://www.ssv-embedded.de/doks/daten/datasheet_wrd_box.pdf.

VG KDW