Oniro Project: How to Push IoT Development to the Next Level

Ettore Chimenti (SECO SpA) stellte in meinem ersten Vortrag des letzten Tages die Ideen hinter dem Oniro Projekt der Eclipse Foundation vor. Die Grundidee ist, eine gemeinsame und offene Basis sowohl für kleine IoT Systeme auf Basis von Zephyr wie auch für große Systeme mit Linux bereitzustellen. Das Projekt möchte nicht das Rad neu erfinden, sondern so viel wie möglich "best practice" zusammenstellen. Linux Systeme werden bei Oniro mit Hilfe von Yocto und der Clang-Toolchain zusammengebaut. Ein eigener System Services Layer stellt dabei die Dienste für Device Management bereit, und es gibt einen separaten Layer für die Kundenapplikation. Oniro nutzt unser Update-Framework RAUC für's Field Upgrade, bietet aber auch Raum für andere Systeme. Neben der Runtime-Plattform kümmert sich Oniro auch um Infrastrukturthemen wie GitLab, LAVA, eine OpenChain basierte Software Supplychain und andere Tools. Alles in allem brachte der Vortrag wenig Neues, stellt aber eine gute Sammlung aktueller Best Practices zusammen.

BoF: Automated Testing and Board Farming

Chris Fiege leitete im Anschluss eine BoF-Session zum Thema Automated Testing und Board Farming. Für uns bei Pengutronix braucht man in den Board Farmen für gewöhnlich interaktiven Entwickler-Zugang auf die Hardware-under-Test (vom Büro aus oder aus dem Homeoffice), daneben benötigt aber auch das CI-System Zugriff auf die Embedded-Geräte. Unsere Labs haben jeweils 16 Lab-Plätze für Embedded-Geräte in einem 19" Rack, in dem auch ein Test-Server, ein Ethernet-Switch und Technik für den Zugang zu den seriellen Konsolen bereitstehen. Diese haben uns in der Vergangenheit jeweils eine Menge Ärger bereitet, und zwar sowohl die alten 19" Serial-Server als auch die aktuelle Generation auf Basis von USB-Seriell-Wandlern. Bis 2020 gab es in unseren Labs ein GPIO-Schalt-System auf Basis von OneWire, das heute zugunsten von CAN basierten IO-Boards abgelöst wurde. Etliche Automatisierungsaufgaben werden mittels CAN und über separate Multiplexing-Devices abgewickelt.

Die Gruppe diskutierte, wie die jeweils im Einsatz befindlichen Testlabs aussehen. Tim Bird erklärte, dass er sich vor allem für Power Control interessiert. Viele der Teilnehmer haben festgestellt, dass USB keine stabile Basis für Automatisierungsgeräte ist, und versuchen, die Technologie möglichst zu vermeiden, was aber in der Praxis schwer funktioniert. Diverse Leute nutzen Sonof WiFi-Steckdosen oder Gude Power Switches aus dem IT Bereich. Ein Mitarbeiter von TI berichtete über ein Lab mit 40 Racks, ein anderes mit 300 Ports, betrieben mit OpenTest und labgrid. Dort wurden die neuen Möglichkeiten, auch Kameras und Display-Tests in Labgrid einzubinden, interessiert aufgenommen. Ein Teilnehmer berichtete von einem Framegrabber-Board, das auch Keyboard- und Maus-Events simulieren kann, so dass sich bei x86 sogar das BIOS fernsteuern lässt. Von anderer Seite wurde PicoKVM (GitHub) empfohlen. Oleksij Rempel berichtete über unsere Aktivitäten, auch Linux-basierte Switche und generell Netzwerk-Geräte mit Hilfe von Labgrid zu testen. Aus dem Publikum kam auch der Hinweis auf YKUSH, ein Gerät, mit dessen Hilfe sich kaputte USB-Devices physikalisch resetten lassen. Rouven Czerwinski berichtete über einen kürzlich von Pengutronix gemainlineten Linux-Patch, mit dessen Hilfe sich einzelne USB-Ports abschalten lassen, wenn die Hardware diese Funktionalität unterstützt.

Die Diskussion beschäftigte sich sodann mit der Frage, welche Testsuiten bei den Teilnehmern im Einsatz sind. Bei Pengutronix sind dies in den meisten Fällen in pytest geschriebene Testsuiten, die direkt auf das jeweilige Gerät zugeschnitten sind. Die TI-Leute nutzen eine vom Linux Test Project geforkte Variante. Oleksij Rempel berichtete, dass es oft schwierig ist, Standard-Testsuiten direkt in Produktivumgebungen zu integrieren. Auch zum Testen von WiFi und Bluetooth sind Lösungen im Einsatz: So haben unsere Racks bei Pengutronix je ein WiFi- und Bluetooth Gerät pro Rack, gegen das sich die einzelnen Geräte ggf. testen können.

Aus dem Publikum kam die Frage, ob es in labgrid möglich ist, in einem einzelnen Test mehrere labgrid-Places zu nutzen; dies ist (unter anderem mit reservations) der Fall.

Für die Fortsetzung der Diskussion wurde auf die automated-testing Mailingliste verwiesen.

Linux for Space - Mission Begins

Lenka Kosková Třísková & Lukáš Mázl (Technical University of Liberec) berichteten über den Einsatz von Linux in der Raumfahrt. Sie haben herausgefunden, dass es bereits an diversen Stellen Open Source Software gibt, jedoch sind noch nicht so viele Linux-Projekte in Raumfahrtanwendungen präsent. Somit haben sie das Linux4Space-Projekt gegründet und versuchen dort, die Anforderungen aus diversen ESA-Standards zu erfüllen.

Ein Bereich, der zunächst naheliegend ist, sind die sogenannten CubeSat Mini-Satelliten: Dies sind Satelliten mit 10x10x10 cm³, auf denen jeweils ein Controller sowie diverse Anwendungen installiert sind. Der Bau eines solchen Satelliten ist derweil recht einfach geworden, aber der Start ist weiterhin sehr teuer. Da diese Art Hardware zunehmend besser zugänglich ist, gibt es hier einen großen Bedarf an Zusammenarbeit.

Der Betrieb eines Linux Computers im Weltraum bedeutet, dass diverse Anforderungen zu erfüllen sind; glücklicherweise haben die Raumfahrtagenturen dazu aber bereits Standards erarbeitet. Die größte Herausforderung liegt im Bereich der Strahlungsresistenz, aber auch mit einem kleinen Powerbudget will umgegangen sein. Generell ist es bei diesen Geräten schwierig, sie fernzusteuern. Die Gruppe hat in einer ECSS-E-ST-10-06 Requirements Specification die bisher bekannten Anforderungen zusammengetragen.

Auf solchen Satelliten werden die meisten Systeme redundant ausgeführt, da die Elektronik bei einem Strahlungseinschlag sehr schnell ausgeschaltet werden kann. Es gilt, verschiedene verbreitete Schnittstellen wie SpaceWire oder SpaceFibre zu unterstützen. Dateisysteme werden in der Regel read-only betrieben.

Das Projekt ist noch recht neu, es gibt aber schon einige Protokolle der letzten Sitzungen, die auf linux4space.org verlinkt sind. Es wird an einem Demo Setup für einen Stratosphärenballon auf Basis eines Raspberry Pis gearbeitet. Weiterhin arbeitet das Team an einem Referenzboard auf Basis eines ARM Prozessors. Für die Kommunikation gibt es ein spezielles CubeSat Protokoll.

Podman 101 and Beyond!

Im nächsten Vortrag wurde von Pierre Blanc (RedHat) über den Podman Container- (oder besser: Pod-) Manager berichtet. Das Design ist sowohl rootless als auch daemonless und somit vergleichsweise sicher. Pierre startete seinen Vortrag mit einem Überblick über die Historie der Container-Technologie und berichtete dann über die Möglichkeiten zum Umgang mit Container Images. Hat man erstmal ein passendes Container-Image gefunden, kann man es starten und mit Netzwerkports kommunizieren. Der Zugriff auf Daten erfolgt über in den Container gemountete Verzeichnisse. Im Gegensatz zu z.B. Docker ist es nicht nötig, Podman als Root laufen zu lassen.

Bei Pods handelt es sich um Gruppen von Containern, aus denen ein gemeinsamer Anwendungsfall zusammengestellt wurde. Damit können auch Applikationen verwaltet werden, die aus mehreren Diensten bestehen.

Weiterhin stellte Pierre diverse Sicherheitsfeatures und weitere hilfreiche Tools aus dem Podman Ökosystem vor, z.B. buildah und skopeo.

Mit Hilfe von 'podman machine' ist es in aktuellen Versionen auch möglich, nicht nur Container, sondern auch virtuelle Maschinen zu verwalten.

Open Source Enabled Power Grid Management Architecture

Nach dem Mittagessen stellten Lucian Balea & Benoît Jeanson vom französischen Stromnetzbetreiber RTE die Open Source Strategie der LF Energy Gruppe der Linux Foundation vor: Die Idee ist es, eine auf Open Source basierende Grid Software Control Architektur zu bauen. Bei einer Analyse wurde festgestellt, dass es im Zuge der Energiewende notwendig ist, die Strukturen auf ein mehr dezentrales System hin zu verändern, in dem eine zunehmend größere Anzahl an Akteuren unterwegs ist. Dadurch steigt die Komplexität. Als Painpoints wurden Interoperabilität, Modularität, Updatebarkeit, Kosteneffizienz und die allgemeine Geschwindigkeit bei Innovationen identifiziert. Die beteiligten Firmen haben sich dann angeschaut, wie andere Industriezweige diese Probleme angehen und kamen - Überraschung! - zu der Erkenntnis, dass Open Source zur Lösung der Probleme beitragen kann. Das war der Auslöser zur Zusammenarbeit im LF Energy Projekt.

Auf der Softwareseite wurde mit OperatorFabric, GridExchangeFabric und PowSyBl gestartet und eine Architektur um diese Projekte herum entworfen; derzeit tummeln sich 18 Open Source Projekte im Architekturdiagramm, wobei es in einigen Teilanwendungsfeldern jedoch noch weiße Flecken auf der Landkarte gibt. Neben der Software wurde aber vor allem die Kollaboration in der Community von den beteiligten Unternehmen als sehr hilfreich identifiziert. Das Projekt sucht noch weitere Mitstreiter.

From Zero to A/B: Swimming Upstream with Yocto, Barebox and RAUC

Roland Hieber & Ahmad Fatoum (Pengutronix) versuchten im nächsten Vortrag, das Publikum zu motivieren, Upstream-Komponenten statt der jeweiligen Downstream-Software (Stichwort: Vendor-BSPs) der Chiphersteller zu verwenden. Dazu wird es später noch einen separaten Bericht geben.

RISC-V and Open Source Hardware Projects BoF

Drew Fustini (BayLibre) leitete eine BoF-Session über Open Source RISC-V. Die RISC-V Architektur ist nicht wie teils von vielen angenommen selbst Open Source, sondern nur "Open Specification", aber es ist durchaus möglich, damit auch Open Source-Hardware zu erstellen. In letzter Zeit gibt es mehrere Ansätze, auch für die Community einen Zugang zu den Halbleiterprozessen der großen Hersteller zu ermöglichen, z.B. bei chipflow.io. Auch in der Industrie werden diverse Ansätze für Open Source Prozessoren verfolgt, z.B. SweRV, Core-V und LowRISC Ibex.

Closing Game