Es war einmal...

Vielleicht haben Sie von folgendem Szenario gehört, vielleicht kennen Sie es nur zu gut...

Der Zeitplan ist eng und es werden Abkürzungen genommen. Beim Update kollidieren einige Komponenten miteinander, einige werden behoben und einige bleiben unverbessert. Im besten Fall werden einige Sicherheitsprobleme identifiziert und die Korrekturen zurückportiert. Eine andere Komponente wurde vor langer Zeit geforkt, um ein damals neues Hardware-Feature zu unterstützen, aber jetzt, Jahre später, kollidieren diese Änderungen mit dem aktuellen Stand des Upstream-Projekts und erfordern viel Aufwand, um sie in Einklang zu bringen. Der Großteil wurde durch das initiale Board Support Package des Herstellers bereitgestellt, aber jetzt liegt das Interesse des Herstellers auf zukünftigen Produkten und der Gewinnung neuer Kunden. Personalwechsel beim Anbieter und im eigenen Unternehmen führen dazu, dass das Wissen über einige der obskuren Wege verloren geht und die Fehlersuche immer mehr Zeit in Anspruch nimmt.

Da der wichtigste Stakeholder nahezu abwesend ist, belasten alle Entscheidungen der Vergangenheit diejenigen, die noch die derivative Software im Feld warten. Während ihre Zahl den Hardware-Anbieter immer noch motiviert, Produktionsläufe zu planen, wird die Wartungslast immer noch von jedem allein getragen, da Probleme individuell identifiziert und gepatcht werden.

Als ob das nicht schon genug wäre, wird es bei einer ausreichend langen Produktlebensdauer immer schwieriger, Ersatz für die Hardware-Komponenten zu finden, was den Aufwand für die Software-Wartung noch erhöht.

Obwohl der Trend zu immer komplexerer Software und der Bedarf an Konnektivität und Sicherheit dieses Problem verschärft, ist es keineswegs eine neue Erkenntnis. Die Auswirkung von technischen Schulden ist bekannt, aber die Folgen der Abwägung zwischen schnellem Prototyping und "richtigem" Tun werden meist erst viel später spürbar.

Wie können wir Ihnen helfen?

Als Embedded-Linux-Dienstleister hat Pengutronix im Laufe der Jahre viel Erfahrung darin gesammelt, Kunden bei der Restrukturierung technischer Schulden zu helfen.

Wir wissen, dass ein langfristig wartbares Produkt bei den allerersten Ideen und Entscheidungen beginnt. Wir wissen auch, dass die Entwicklung von Hardware und Software Hand in Hand gehen muss. Deshalb möchten wir Ihnen so früh wie möglich bei einem Projekt helfen, d.h. wir überprüfen Schaltpläne und beraten Sie bei Komponentenentscheidungen.

Während die Hardware-Abteilung einen Prototyp entwickelt, muss auch die Software-Architektur entworfen werden. Wir helfen Ihnen, auf Basis eines aktuellen Yocto oder PTXdist Build-Systems, ein Board Support Package zu erstellen, das genau auf Ihre Hardware zugeschnitten ist und Ihren Bedürfnissen entspricht. Wir ergänzen fehlende Treiber und Softwarekomponenten in einer testgetriebenen Entwicklung und stellen sicher, dass Ihr BSP reproduzierbar, gut strukturiert und auf dem aktuellen Stand der Technik ist.

Sobald Ihr Produkt verkauft wird, helfen wir Ihnen, es durch kontinuierliche Tests und sichere Updates zu pflegen.

Machbarkeitsstudie: Linux-Automation MC-1

Unser technischer Demonstrator ist für eine breite Palette von Anwendungsfällen konzipiert: Es könnte ein Bedienfeld zur Überwachung Ihrer häuslichen Infrastruktur sein (wie Ihre Solarpaneele oder Türklingeln). Es könnte ein Informations- oder Unterhaltungssystem in Ihrem Fahrzeug sein oder alles andere, was Sie sich vorstellen möchten.

Daher war Display-Unterstützung eine Voraussetzung, ebenso wie eine Netzwerkverbindung, denn alle IoT-Geräte brauchen eine Netzwerkverbindung ;-) Und wenn wir eine Netzwerkverbindung haben, können wir Power over Ethernet nutzen, um das Gerät mit Strom zu versorgen.

Eine letzte Anforderung: Das Board soll klein genug sein, um in die Rückseite des Displays zu passen.

In Zusammenarbeit mit unserem Schwesterunternehmen Linux Automation GmbH und unseren Partnern Octavo Systems und Bopla präsentieren wir einen Proof of Concept für die Design for Mainline-Strategie.

Unser Embedded Board enthält nur handelsübliche Komponenten, die von Mainline-Linux-Treibern gut unterstützt werden.

Daher betrug der anfängliche Aufwand für das Design der Schaltung für diesen Prototyp nur etwa zwei Wochen und eine weitere Woche, um den gesamten Software-Stack zu erstellen. Möglich wurde dies durch eine durchdachte Auswahl der Komponenten, die wir Ihnen an dieser Stelle vorstellen wollen:

• Mögliche SoCs werden nicht nur nach ihrem Funktionsumfang, Preis und ihrer Verfügbarkeit bewertet, sondern auch nach der Offenheit der Dokumentation und dem vorhandenen Upstream-Support. Für diesen PoE-gespeisten Display-Controller erfüllt der STM32MP1 alle Kriterien.
• Der OSD32MP1x macht es einfach, eine Brücke zwischen der IT und der physischen Welt zu schlagen. Wenn man eMMC-Speicher hinzufügt, hat man bereits einen vollwertigen Linux-Computer; auf einer Platine mit geringer Lagenzahl.
• Upstream-Support in den Linux Kernel wurde für das Board durch die Projekte ARM Trusted Firmware und Barebox Bootloader eingebracht. Es müssen keine Software-Komponenten gepatcht werden, um ein Linux-System zum Laufen zu bringen.
• Ein BSP sammelt Konfigurationsparameter und endgültige Versionen aller verwendeten Softwarekomponenten. Softwareversionen können auch nach Jahren noch reproduziert werden.
• Das BSP baut auf etablierten und von einer breiten Community geschützten Build-Systemen wie Yocto oder PTXdist auf, wo viele Firmen und Enthusiasten gemeinsam an der Aktualisierung der verschiedenen Komponenten arbeiten und dabei die Kompatibilität aufrechterhalten.
• Die von Etnaviv betriebene Grafikpipeline, die von Pengutronix im Linux-Kernel gepflegt wird, bietet dem Anwender eine vertraute Umgebung: Grafik-Toolkits, ähnlich wie sie auf einem Standard-Linux-Desktop-PC eingesetzt werden.
• Neue Software wird kontinuierlich auf das Board aufgespielt und Testsuiten laufen, um Regressionen während der Entwicklung abzufangen.
• Um den Kernel-Entwicklern so früh wie möglich Rückmeldung über Regressionen zu geben, kann das Board zusätzlich in die weltweite KernelCI-Infrastruktur integriert, die die Linux-Kernel-Maintainer informiert, wenn neue Patches zu Problemen auf der jeweiligen Hardware führen.