Showcase: Remote Working

Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit Prototypen-Hardware. Da wir grundsätzlich parallel mit mehreren Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine Flut von Prototypen auf den Schreibtischen unserer Entwickler. Spätestens wenn im Team an einem Prototypen gearbeitet werden soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird, muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz verkabelt werden. Erschwerend kommt hinzu, dass sich die Entfernung zwischen unseren Entwicklerschreibtischen, durch die aktuelle Homeoffice-Situation, nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.

In diesem Artikel möchten wir Ihnen unsere, ursprünglich für Continous Testing entwickelte, Remotelab-Infrastruktur vorstellen, die uns Enwicklung an zentral aufgebauten Prototypen fast ohne Personal vor Ort ermöglicht.

Unsere Remotelabs sind Racks, in denen wir unsere Embedded Boards betreiben und auf die unsere Entwickler Remote-Steuerungsmöglichkeiten haben. Sobald der Remotezugriff auf die Hardware gegeben ist, lässt sich dieser auch automatisieren und ermöglicht so die Ausführung automatischer Tests.

Ein paar Worte zum Continuous Testing

Tatsächlich ist die Möglichkeit kontinuierlich und automatisiert Tests durchführen zu können eine der Hauptantriebsfedern für unsere stetige Weiterentwicklung von labgrid (unserem Softwareframework zur Ansteuerung von Hardware-Komponenten) und Professionalisierung der Remotelab-Infrastruktur.

Die Vorteile des Continuous Testing möchten wir Ihnen in unserem Showcase: Continuous Testing näherbringen.

Wie können wir Ihnen helfen?

Als Dienstleister im Software-Umfeld können wir Ihnen zwar keine fertig aufgebaute Remotelab-Infrastruktur verkaufen, trotzdem stehen wir Ihnen gerne bei der Einrichtung zur Seite: Ob es darum geht Ihre Test-Hardware in labgrid abzubilden, Teststrategien auszuarbeiten und Tests zu entwickeln, oder labgrid in ihre Prozesse zu integrieren, sprechen Sie uns gerne an.

Auch ohne den Schritt zum eigenen Remotelab können Sie von unserer Remotelab-Infrastruktur profitieren. Sollten Sie uns als Kunde Prototypen-Hardware zur Verfügung stellen, integrieren wir diese in unsere Remotelab-Infratstruktur. So steht ihre Hardware unserem Entwicklerteam zu jedem Zeitpunkt im Produktzyklus mit wenigen Tastendrücken zur Verfügung.

Mittlerweile haben wir diverse Remotelabs aufgebaut und eingerichtet. Deshalb möchten wir im Folgenden unsere Komponentenauswahl vorstellen und unsere Erfahrung mit Ihnen teilen.

Aus welchen Komponenten besteht ein Remotelab?

19-Zoll-Rack

Die tragende Komponente unseres Remotelabs: Wir verwenden ein 19" TE Netzwerkschrank von Rittal. Besonders praktisch ist dabei der Einsatz von Transportrollen - so bleibt die Hardware von allen Seiten zugänglich. Um die Prototypen zu schützen, wird jeder Einlegeboden mit einem ESD-Regalbelag ausgelegt. Außerdem ermöglichen Kabelführungsschienen ein (zumindest anfangs) aufgeräumtes Remotelab. Zwei passende Steckdosen für Rackmontage liefern den nötigen Strom für die weiteren Infrastruktur-Komponenten.

Netzwerkswitch

Unsere Lieblinge in dieser Kategorie sind die CBS350-24P-4G von Cisco, da sie PoE-fähig, leise und gemanagt sind. Durch den Einsatz von PoE wollen wir den Bedarf an Einzel-Netzteilen in zukünftigen Hardware-Eigenentwicklungen minimal halten. Die Verwendung von Managed-Switches erlaubt es uns auf mögliche spezielle Anforderungen der Kundenhardware an das Netzwerk-Setup zu reagieren.

Außerdem ist es für uns wichtig, dass die Switches im Betrieb leise sind, da sich die Remotelabs mitunter in Entwicklerbüros befinden.

Kleiner Server

Zur Verwaltung der Geräte im Remotelab wird jeweils ein kleiner Server benötigt. Die Hardware-Anforderungen für diesen labgrid-Knoten sind recht gering. Wir achten bei der Auswahl auf folgende Aspekte:

  • Leiser Betrieb -- Unsere Remotelab-Server nutzen PC Engines APU.2E4 und sind somit komplett lüfterlos.
  • Stabiles USB -- Große USB-Installationen, wie sie unsere Remotelabs sind, bergen unserer Erfahrung nach viel Potenzial für Frustration. Die internen USB-Controller der APU.2E4 und unsere zusätzlich verbauten EXSYS EX-49010-2 Controller haben sich im Betrieb als vergleichsweise zuverlässig gezeigt.
  • CAN-Bus-Integration -- Zur Kommunikation mit unserer in-house entwickelten Hardware versuchen wir, wenn es geht, auf USB zu verzichten und setzen stattdessen auf CAN. Entsprechend verbauen wir CAN-FD-Fähige miniPCIe-Karten von Peak System, die vier unabhängige CAN-Busse zur Verfügung stellen.

Schaltbare Steckdose

Have you tried turning it off and on again? -- Der einfachste Weg zum Hardware-Neustart ist das Anschalten der Versorgungsspannung, beispielsweise über Netzwerk-Steckdosen, die vollautomatisch durch labgrid angesteuert werden können. Als günstige Alternative für kleinere Aufbauten sammeln wir auch erste Erfahrungen mit über WLAN schaltbaren Einzel-Steckdosen. Für den Einsatz im Remotelab, wo viele Geräte angesteuert werden sollen, verwenden wir GUDE 8080-Steckdosenleisten, für einzelne Geräte experimentieren wir mit Steckdosen des Herstellers SONOFF, die mit der freien Tasmota-Firmware bespielt werden.

USB-Hubs

USB ist in der Embedded-Entwicklung fast unumgänglich, wir nutzen es zur Kommunikation mit der Hardware und zum Einspielen der Software. Bei der Suche nach verlässlichen USB-Hubs gilt es es Produkte von verschiedenen Herstellern auszuprobieren. Wir haben gute Erfahrungen mit den 10-Port-Hubs UA0096 von LogiLink gemacht.

Ein interessanter Anwendungsfall, der durch diese Hubs leider nicht abgedeckt wird, ist das ein- und abschalten der Versorgungsspannung einzelner Ports mittels uhubctl.

WLan-Router

Um Bluetooth und WLAN-Funktionalitäten der Embedded-Hardware testen zu können, verfügt jedes Remote-Lab über einen eigenen WLAN-Router, der mit der freien OpenWRT-Firmware bespielt ist. Dieser Router ist weder mit dem Internet, noch mit einem anderen Netzwerk verbunden und dient lediglich dem Test des Verbindungsaufbaus in automatischen Tests.

Serielle Konsole

Zur Anbindung der seriellen Konsolen der Embedded-Geräte nutzen wir einfache USB-Seriell-Wandler, auf denen vorzugsweise ein CP210x-Chip von Silicon Labs verbaut ist. Dieser Chip erlaubt es auf einfache Weise in jedem USB-Seriell-Wandler eine eindeutige ID zu hinterlegen. Wir beschriften jeden USB-Seriell-Wandler mit seiner programmierten ID und behalten so auch mit über einem Dutzend Wandler pro Lab den Überblick.

Ferngesteuertes Setzen von Jumper-Pins

Um möglichst flexibel Reset- oder Boot-Options-Jumper setzen und lösen zu können, sind potenzialfreie Schalter hilfreich. Hier setzen wir auf per OneWire oder CAN angebundene Eigenentwicklungen. Alternativ bieten sich aber auch per USB gesteuerte Relais, oder professionelle Modbus-basierte Geräte an.

Der Zugriff aus der Ferne: Unsere labgrid-Integration

Um das Remotelab vollständig nutzen zu können, reicht die Hardware alleine nicht aus. Für die Steuerung der Embedded-Boards vom Entwickler-PC und als Grundlage für Tests und Entwicklung auf echter Hardware kommt bei Pengutronix das Open-Source Werkzeug labgrid als Abstraktionsschicht zum Einsatz.

labgrid stellt für automatisierte Tests genau so wie für die interaktive Arbeit eine intuitive und zugleich vielseitige Schnittstelle zum Arbeiten mit Embdded-Linux-Geräten zur Verfügung.

Mehr Informationen zu labgrid

Unser Kollege Chris Fiege hat auf der FOSDEM 2021 den Talk "About the joy and tears of testing Embedded Devices" zu unserer bisher dreijährigen Erfahrung mit labgrid-Tests gehalten.

Schauen Sie gerne einmal vorbei, um einen Überblick über die verschiedenen labgrid-Komponenten und -Arbeitsweisen zu bekommen. (Youtube, Slides)

Es gibt verschiedene Möglichkeiten, um über labgrid auf die laufenden Geräte zuzugreifen, z.B.:

  • Serielle-Konsole -- Diese steht fast immer zur Verfügung, auch schon früh im Bootprozess, ist aber weniger komfortabel als der …
  • … Zugriff über Netzwerk und ssh -- Dieser ist Besonders im späteren Entwicklungsprozess sehr komfortabel. Es können mehrere Verbindungen gleichzeitig geöffnet und auch Dateien übertragen werden.
  • Display ablesen über eine Webcam -- Eine klare Ausnahme, aber auch durch labgrid unterstützt. Diese Variante ist besonders relevant während der Treiberentwicklung und der Entwicklung grafischer Applikationen.

Wie kommt die Software auf das Embedded-Board?

Das ist von der Entsprechenden Hardware abhängig und davon, welche Teile des Systems getestet werden sollen.

Eine Option ist das Laden der Systemdaten über das Netzwerk durch den Bootloader. Eine Andere die Nutzung eines Programmier-Adapters des Prozessorherstellers oder das Einspielen der Software über USB.

Hier bei Pengutronix nutzen wir, wenn möglich, allerdings den USB-SD-Mux, der eine Micro-SD-Karte zwischen dem Remotelab-Server und der Hardware hin und her schalten kann. Das ermöglicht einfaches Einspielen eines kompletten Firmware-Images samt Bootloader.

Zurück zur Messeseite

Weiterführende Links

Showcase: Embedded off-the-shelf

Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex. Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an einem versionskontrollierten Board Support Package (BSP) mit kontinuierlichen Updates und Tests auf dem neuesten Mainline-Linux-Kernel.


Showcase: Continuous Testing

In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind Bugfixes. Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines modernen Linux-Systems sind. Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System aktuell zu halten. Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen oder Inkompatibilitäten entstehen.


Pengutronix at FOSDEM 2021

"FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. In 2021, they will gather online." -- FOSDEM


Pengutronix auf dem Live Embedded Event

Conference, Event, Testing

Jetzt, wo sich durch die COVID-19-Pandemie alle an die Digitalisierung und Online-Konferenzen gewöhnt haben, war es noch nie so einfach, eine Konferenz zu organisieren und alle Experten und Interessierten aus einem Bereich für wenige Stunden des intensiven Ideenaustauschs zusammenzuholen.


#FlattenTheCurve – Vorstellung unserer Remote-Infrastruktur

Die Corona-Krise hat uns alle, sowohl als Privatpersonen als auch als Firmen, plötzlich ziemlich hart getroffen und stellt unsere gesamte Gesellschaft vor neue Herausforderungen. Wir als Pengutronix möchten uns bei denjenigen bedanken, die in systemkritischen Berufen arbeiten und unsere alltägliche Versorgung sicherstellen.


A Logo for labgrid

Enrico Jörns | | labgrid

It took us a while to find a good logo for one of our latest (but already quite-a-few-years-out) software projects, called labgrid. In case you have not heard of it yet, feel free to read our short blog post from 2017 or visit labgrid's GitHub page.


Pengutronix at FrOSCon 2018

This year, a team from Pengutronix attended FrOSCon in St. Augustin for the first time. We took the opportunity to shake hands, talk about our latest developments and meet hackers interested in working with embedded Linux.


USB-SD-Mux: Automated SD-Card Juggler

Once the bootloader on your embedded device is up and running the development of kernel and userland in PTXdist-based BSPs is usually based on booting from network. Thus there is no need for the developer to write the boot media with a new image.


PTXdist: Schon gewusst? Heute: Mal eben neu booten

Wer während der Entwicklung an einem embedded System selbiges immer wieder mal komplett neu starten muss, wird es zu schätzen wissen, wenn so wenig wie möglich getan werden muss, um bei veränderten Daten das System im konsistenten Zustand zu halten.


PTXdist: Schon gewusst? Heute: Das Entwicklerleben verschönern

Es gibt Dinge, die machen das Leben als Entwickler einfacher - und schöner. Hier dazu ein Beispiel.