Continuous Delivery of IoT Sensors

Im ersten Vortrag des Donnerstags stellte Ulf Lilleengen (Red Hat) das Drogue IoT Projekt vor. Es ist in Rust geschrieben und kümmert sich um die Bereiche

• Continuous Integration,
• Continuous Testing und
• Continuous Development.

Die Devices, um die es ihm geht, sind Mikrocontroller, auf denen kein Linux läuft und bei denen die Update-Mechanismen in die Applikation integriert sind. Sie sind in der Regel über ein Wireless Netzwerk angebunden, z.B. WiFi, LoRaWAN, LTE-M oder Bluetooth, und werden von den Herstellern mit vielen unterschiedlichen Entwicklungsumgebungen ausgeliefert. Ein Problem beim Update ist, dass einige der Funksysteme Beschränkungen bei der Air Time haben: So dauert es bei einer Firmware-Größe von 64 KiB z.B. bei LoRaWAN drei Tage, bis ein Gerät ein vollständiges Update von einem Standard-Gateway empfangen hat. Damit das Gerät failsafe ist, wird zumindest ein minimaler Bootloader benötigt, der über den Funkkanal ein neues Image beschaffen kann.

Die Kommunikation im Drogue IoT Framework funktioniert über REST Schnittstellen und eine Vielzahl von API Endpoints. Man kann Devices in Gruppen zusammenfassen, und verschiedene Protokolle können zur Kommunikation genutzt werden. Zum Update fragt das Gerät bei einem Delivery System an, z.B. bei HawkBit. Der Vortrag schloss mit einer Demo, in der ein MicroBit Controller im Feld geupdatet wurde.

Die meisten der vorgestellten Komponenten passen nicht in unser übliches Embedded Linux Umfeld, aber bei den verwendeten Tools gibt es schon das eine oder andere, das einen genaueren Blick wert ist, z.B. Keycloak (für das Identity Management) oder die eingesetzten Kommunikationsprotokolle.

Beyond Complex Cameras: Complex Video Graphs Using PipeWire

Im nächsten Vortrag beleuchtete George Kiagiadakis (Collabora) aktuelle Fragestellungen rund um immer komplexer werdende Kameras. Moderne Kameras haben z.B. mehr als einen Sensor-Chip, Algorithmen zur Kombination der daraus erzeugten Bilder und eine Vielzahl an Hardware-Einheiten, die aus verschiedenen Datenquellen letztlich ein Bild oder einen Videostream machen, teils auch unter Zuhilfenahme von AI Beschleunigern. Es stellt sich heraus, dass die dafür benötigten Pipelines immer komplexer werden. Typischerweise werden solche Szenarien heute mit libcamera abgedeckt, aber es gibt ungeklärte Fragen:

• Wie kombiniert man die Daten von verschiedenen Geräten?
• Kann man das Processing splitten, z.B. in Container?
• Wie realisiert man eine gute "divide and conquer" Strategie?

Zu diesem Zweck wurde das Pipewire Projekt gestartet, das einen Multi Process, Ressource Sharing, Low Latency Multimediabus bereitstellt. Es gibt einen Graphen, in dem die einzelnen Prozessierungsschritte auf verschiedene Prozesse aufgeteilt werden. Der Graph wird von WirePlumber aufgesetzt, einem scriptbaren Daemon, der die vorhandenen Geräte herausfindet und passend miteinander verbindet.

In seiner Demo zeigte George einen Face Detection Algorithmus. Weiterhin existiert ein praktisches Tool zur Anzeige der erzeugten Graphen. Eine weitere Demo zeigte, wie man ein Videoplayback mit zwei synchronisierten Ausgabedisplays hinter einem gemeinsamen Videodecoder realisieren kann.

Der Vortrag ergab einen guten Überblick über Pipewire; auch bei Pengutronix nutzen wir Pipewire zunehmend mehr in den Multimedia Projekten unseres Grafikteams.

Growing a Lab for Automated Upstream Testing: Challenges and Lessons Learned

Laura Nao (Collabora) berichtete über die Herausforderungen aus Collaboras Testlabor. Die Firma betreibt in Cambridge ein Labor mit 158 Geräten, davon 32 unterschiedlichen Gerätetypen, die von 15 Servern und der üblichen Kombination aus Netzwerkswitchen, Debug Interfaces, USB-Hubs etc. kontrolliert werden. Die meisten eingesetzten Geräte sind 64-Bit-ARM-Chromebooks, wobei es oft mehr als ein Gerät von einer Sorte gibt. Die Boards werden in 19" Racks montiert. Das Setup hört sich sehr ähnlich zu dem an, das wir bei Pengutronix als LAVA Lab betreiben; allerdings sind die meisten unserer Labs eher mit industrieller Hardware bestückt.

Ein üblicher Testlauf startet mit dem Einschalten eines Prüflings; es startet der Bootloader, der Bootvorgang wird abgebrochen, Kernel und Ramdisk werden übertragen, dann wird der Bootvorgang fortgesetzt, das System bootet, das Testsystem loggt sich ein, startet eine Reihe von Testscripten, und schließlich wird das Board am Ende wieder ausgeschaltet. Die Konfigurationsfiles sind YAML-Files, die mit Jinja 2 getemplatet werden. Mittels eines Health-Jobs wird sichergestellt, dass das Lab selber gut funktioniert. Kernel-Log-Informationen werden mit einem Script aus dem Syslog gezogen. Ein GitLab-Runner ermöglicht, Jobs zu erzeugen. Neu ins Labor gehängte Geräte durchlaufen zunächst ca. 1000 Health Checks, bevor sie in den regulären Testbetrieb gehen.

Der Testflow für die Chromebook-Applikationen sieht schon sehr anders aus als bei normalen Linux-Applikationen. Da allgemein das Testen auf Chrome-OS schwierig ist, ersetzt Collabora es durch ein normales Linux.

Das Lab selbst ist in einen Staging- und einen Produktionsbereich getrennt. Auch die Upstream-Kernel werden im Staging-Bereich getestet. Lediglich bereits releasete Versionen werden im Produktionsbereich getestet.

Auch Kernel CI und Mesa CI Streams laufen auf dem Lab. Dabei ist das Ziel, die Upstream-Entwickler mit Testergebnissen zu versorgen und somit Fehler in der Revisionskontrolle so früh wie möglich aufzudecken. Die Mesa Tests sind noch relativ neu, dort werden auf x86 Pre-Merge Conformance Tests gemacht.

Auf dem Lab laufen sehr viele Jobs, somit kann auch eine Menge schiefgehen. So kann es vorkommen, dass die Hardware Probleme hat, ab und zu fallen auch Server aus, oder es schlagen Firmware-Bugs zu. Da z.B. Mesa die Aufnahme neuer Features von positiven Testergebnissen abhängig macht, ist es für die Betreuer des Testlabs wichtig, Infrastruktur-Fails von echten Testfehlern zu unterscheiden.

Einige Erkenntnisse:

• Robuste Health Checks sind sehr wichtig.
• Infrastruktur-Fehler müssen sauber detektiert werden.
• Nur mit genügend redundanten Devices ist eine gute Testabdeckung möglich.
• Es werden dauerhaft zwei Personen benötigt, um das Labor vor Ort zu betreuen.

Je größer das Lab wächst, desto mehr Platz, Komponenten aber auch Manpower wird zu dessen Betrieb benötigt.

Technical Introduction to EVerest: Open Source Firmware for EV Charging Stations

Auch für uns bei Pengutronix ist das Thema "Erneuerbare Energien" derzeit spannend, und es gibt Pläne, die entsprechende Infrastruktur mit möglichst vielen Open Source Komponenten zu betreiben. Insofern gab der Bericht von Kai-Uwe Hermann und Piet Gömpel (PIONIX GmbH) einen interessanten Einblick in die Welt der Ladestationen für Elektroautos.

EVerest ist ein Softwarestack für Auto-Ladeinfrastruktur. Es stellt sich heraus, dass das Thema Ladeinfrastruktur überraschend komplex ist. Eine Ladestation besteht in der Regel aus Leistungselektronik und einem Controller für die Ablaufsteuerung (oft mit Linux). Es sind diverse unterschiedliche Standards beteiligt, sowohl auf der Stecker- als auch auf der Kommunikationsseite. Zwischen dem Controller und dem Cloud-Backend wird das OCPP Protokoll gesprochen, von dem es in der Praxis mehr als 150 Dialekte gibt, aber auch andere Protokolle wie IEC631100, MQTT und andere. Es gibt Bestrebungen für "plug-and-charge", aber dafür wird eine komplexe Authentifizierung benötigt, so dass es in der Praxis noch fast keine Implementierungen gibt.

Ein weiterer Themenkomplex beschäftigt sich mit der Interaktion zu anderen Komponenten in einer lokalen Ladeinfrastruktur, z.B. wenn man dann laden möchte, wenn die Sonne gerade scheint und eine lokale PV Anlage Solarstrom erzeugt. Nimmt man diesen Komplex hinzu, gibt es eher noch viel mehr Protokolle, die eine Rolle spielen. Ähnlich ist es im Bereich der Grid-Kommunikation.

Alles in allem war das Fazit: Es gibt zu viele Standards, und es werden eher noch mehr. Da man diese Sorte Probleme nicht durch Hinzufügen eines weiteren Standards beheben kann, versucht das EVerest Projekt, eine Community Referenzimplementierung bereitzustellen. Es sollen so viele Hardware-Plattformen wie möglich unterstützt werden, ohne dass das Rad neu erfunden werden muss. Die Codebase ist in C++ geschrieben und unter der Apache 2.0 Lizenz auf GitHub veröffentlicht. Für eine einfache Konfiguration gibt es eine Web-Applikation. Derzeit wird OCPP in der Version 1.6 unterstützt - hier ist der Stack Feature-Complete, wohingegen an Version 2.0 derzeit gearbeitet wird.

Das Projekt gibt es nun seit zwei Jahren, es gibt eine Mailingliste und regelmäßige Meetings. Die Demo-Setups laufen auf Hardware von der Phytec und Mahle, aber es gibt derzeit noch keine marktfertigen Lösungen.

A Month Off: Migrating a Robot Controller from the Proprietary INtime RTOS to Linux

Dirk Eibach arbeitet für die Carl Cloos Schweißtechnik GmbH, einen Hersteller von industriellen Schweißrobotern. In 2021 startete er die Migration eines Roboters auf Preempt-RT.

Die existierenden Roboter-Controller bestehen aus einem selbst entwickelten PC, auf dem ein CAN-Bus, EtherCAT und ein Satz an Servomotoren als EtherCAT Slaves betrieben werden. Die Axen laufen dabei in einem "cyclic synchronous position mode" (CSP): Auf einem 1-4 ms Buszyklus stellt das System für alle Axen neue Zielpositionen bereit. Ein Motion Planner läuft auf einem Takt von 8...16 ms, wobei für den schnelleren Bustakt interpoliert wird. Mittels eines physikalischen Modells wird die Dynamik des Roboters simuliert.

Die Codebasis besteht aus 3 Millionen Lines-of-Code. Ursprünglich wurde diese mal in PL/M geschrieben und später auf C portiert. Es gibt nach wie vor 386 Assembler-Code und ANSI C, eine alte MFC GUI und eine neue Qt GUI (leider noch nicht Feature-Complete). Es gibt die übliche Technical Debt in der Codebase, es haben Mitarbeiter die Firma verlassen, und dabei ist auch Wissen verlorengegangen.

Im Jahr 2021 wurde mit KEBA gesprochen, da es dort einen recht vielversprechenden D3 Automation Controller mit 32 Bit Debian Linux gab, der eine integrierte Safety Lösung mitbrachte. Dadurch, dass auf diesem System die Möglichkeit bestand, alle Software auf einem System laufen zu lassen, konnten bereits eine ganze Reihe proprietärer Lizenzen eingespart werden. Jetzt war der Zeitpunkt günstig, so dass der Referent seinem Team vorschlug, in einem 6-Wochen Sprint eine Portierung auf Linux zu probieren. Dabei war ein wichtiger Aspekt, dass sich alle beteiligten Kollegen (auch Nicht-Linux-Entwickler) mit einer Entscheidung für eine Linux-Portierung wohlfühlen sollten. Überraschend gab es im Team Konsens, das Projekt zu starten.

Die komplette API wurde im Userspace als Shared Library implementiert, so dass die eigentliche Applikation nicht angefasst werden musste. Zunächst wurden Headerfiles nachimplementiert, dann mussten alle Funktionen implementiert werden, die vom Linker als fehlend ausgegeben wurden. Gleichzeitig begannen die GUI Entwickler mit der Migration der Oberfläche. An ein paar wenigen Stellen (IPC auf physikalischem Speicher) wurde letztlich doch die Applikation verändert.

Am Ende des 6-Wochen-Zeitraums war die Applikation so weit portiert, dass sie starten konnte; auch eine rudimentäre GUI war soweit funktionstüchtig, jedoch noch nicht abgeschlossen. Das Team war sich darüber im Klaren, dass man bei dem Projekt eine Menge gelernt hatte und der Ansatz generell der Richtige ist. Weiterhin ergab sich ein gutes Gefühl dafür, wie viel Arbeit der Rest der Portierung noch sein könnte. Selbst die bislang an Windows gewöhnten Entwickler waren mit der Arbeit mit Visual Studio zufrieden, so dass es wiederum eine gemeinsame Entscheidung gab, die Aktivitäten fortzuführen. Leider wurde der Abschluss des Projekts dann durch die Chipkrise ausgebremst.