Showcase: Remote Working
Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere 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 die Entfernung zwischen unseren Entwickler-Schreibtischen 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 Entwicklung 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 Remote-Zugriff 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 Software-Framework 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?
Die volle Kontrolle über Ihr Entwicklungs-Board zu haben, ohne es tatsächlich vor Ort zu haben zu müssen, kann, nicht nur in Pandemie-Zeiten, ein entscheidender Faktor für die Effektivität und Flexibilität der Entwicklung und damit auch der Wettberwerbsfähigkeit sein.
Auch, wenn wir als Dienstleister im Software-Umfeld Ihnen zwar keine fertig aufgebaute Remotelab-Infrastruktur verkaufen können, so möchten wir trotzdem unsere langjährige Erfahrung mit Ihnen teilen und stehen Ihnen gerne bei der Beratung und Einrichtung zur Seite: Egal ob es darum geht, nur das Remote-Arbeiten zu ermöglichen, oder Ihre Test-Hardware in labgrid abzubilden, Teststrategien auszuarbeiten und Tests zu entwickeln, oder labgrid in ihre Prozesse zu integrieren: Sprechen Sie uns gerne an!
Als Kunde profitieren Sie von unserer Remotelab-Infrastruktur natürlich auch ohne den Schritt zum eigenen Remotelab. Sollten Sie uns eine (für die effiziente Entwicklung meist zwingend erforderlichen) 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 Embedded-Linux-Geräten zur Verfügung.
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 MesseseiteWeiterfü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.
labgrid geht auf Live-Tour!
labgrid erlaubt es uns, Embedded-Linux-Geräte aus der Ferne zu steuern und Integrationstests von Embedded-Linux auf echter Hardware zu implementieren. Pengutronix und andere Firmen setzen daher schon einige Zeit erfolgreich auf labgrid als Mittelpunkt ihrer Embedded-Software-Entwicklungsinfrastruktur.
Linux Automation Test Automation Controller: Ein all-in-one labgrid Exporter
Unsere Tochter Linux Automation GmbH stellt mit dem LXA TAC (Linux Automation Test Automation Controller) einen all-in-one labgrid exporter vor. Das LXA TAC bietet die üblichen Schnittstellen, um ein oder mehrere Embedded Geräte (DUTs, Devices under Test) mit labgrid interaktiv oder automatisiert steuern zu können.
Yes we CAN... add new features
Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?
DSA in Barebox
The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.
Pengutronix at Embedded World 2022
Welcome to our booth at the Embedded World 2022 in Nürnberg!
First Steps using the candleLight
So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.
labgrid Tutorials
This week, we started our series of YouTube labgrid tutorials. In the next few weeks we will publish more video tutorials showing you labgrid's features and giving you handy tips and tricks.
Lab-Automatisierung mit LXA IOBus
Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen, seitdem haben wir viele Normen gelesen, Dinge über Webshops und den Alltag der Elektronikfertigung gelernt und still und heimlich an neuen Produkten getüftelt. Heute möchte ich das LXA IOBus-System vorstellen, bestehend aus einem CAN-basierten Kommunikationsprotokoll, einem zugehörigen Gateway-Server und einer neuen Klasse an Linux Automation GmbH Produkten. Zwei dieser neuen Produkte sind der Ethernet-Mux und das 4DO-3DI-3AI Input/Output-Board.