DevOps nutzen, um Herausforderungen bei Embedded Software zu meistern

DevOps gilt als der beste Weg, um die Marktanforderungen an Embedded Software nach mehr Anwendungen und neuen Funktionen in kürzerer Zeit zu erfüllen.

Für die Embedded-Softwareentwicklung braut sich ein perfekter Sturm zusammen. Embedded Devices proliferieren – besonders durch neue Konnektivitätsoptionen wie 5G, die innovative vernetzte Anwendungen ermöglichen. Gleichzeitig erfordern Geräte-Lebenszyklen, wie die Reaktion auf sich entwickelnde Cyberangriffe, schnelle Software-Änderungen und -Bereitstellungen.

Diese Bedingungen stellen neue Anforderungen an Entwicklungs- und Betriebsteams. DevOps wird zunehmend als der beste Weg gesehen, um Marktanforderungen nach mehr Anwendungen und Funktionen in kürzerer Zeit zu erfüllen. RTInsights sprach kürzlich mit Graham Morphew, Senior Director of Product Management bei Wind River, über die Herausforderungen der Embedded-Softwareentwicklung, Unterschiede zwischen DevOps für traditionelle Umgebungen und Embedded Devices, und mehr.

Hier ist eine Zusammenfassung des Gesprächs.

Wie unterscheidet sich DevOps für Embedded Devices von traditionellen DevOps-Ansätzen?

Morphew: In traditionellem DevOps in einer IT-Unternehmensumgebung hat man eine allgegenwärtige Ausführungsumgebung – entweder Intel-Server in der Cloud oder Intel-PCs. Embedded ist grundlegend anders: Die Ziel-Ausführungsumgebung hat meist eine andere Architektur als die Entwicklungsumgebung. Die Vielfalt der End-Hardware und die Bereitstellung darauf bringen mehr Herausforderungen mit sich. Bei Cloud-Software weiß man, dass sie in Google Cloud, Azure oder AWS läuft. Bei Embedded Software ist die Vielfalt der Bereitstellungsumgebungen nahezu unendlich, und Geräte können an abgelegenen Standorten stehen.

Es gibt viele Unterschiede, wie man über Software denkt und wie diese in DevOps-Implementierungsherausforderungen übersetzt werden.

Man muss mit spezialisierter Hardware, Cross-Compiling, Cross-Debugging, Speicher-Footprints und Sicherheitsfragen umgehen. Man hat nicht die fast unbegrenzten Ressourcen wie in der Cloud. Es gibt eine „Insel der Ausführung“, die man beim Design im Blick behalten muss. Sicherheit ist ein weiteres Thema: Man hat nicht unbedingt physische Kontrolle über die Gerätesicherheit und muss physische Manipulationen berücksichtigen.

Eine weitere Herausforderung: Daten von diesen Geräten sind schwerer zu sammeln. In DevOps will man einen kontinuierlichen Feedback-Loop. Das ist einfach, wenn Entwicklung auf kontrollierten Servern läuft. Bei verteilten, nicht immer online Geräten spielen viele verschiedene Faktoren eine Rolle.

Warum bewegt sich die Embedded-Community Richtung DevOps?

Morphew: Bei Embedded Software wächst der Bedarf an häufigeren Updates und höherer Qualität. Dafür braucht man Automatisierung. Automatisierung wird eine große Rolle in der Zukunft von DevOps und Embedded Software spielen. Vor ein oder zwei Jahrzehnten lag der Fokus auf Hardware als Treiber der Gerätekapazitäten. Heute ist der differenzierende Technologiefaktor unter Geräteherstellern viel stärker Software.

Ein weiterer Treiber: der demografische Wandel in der Softwareentwicklung. Es gibt zwei Lager: traditionelle Embedded-Entwickler (oft älter, viele gehen in Rente) und neue Absolventen/Entwickler aus anderen Software-Domänen. Traditionelle Entwickler lernten noch Hardware-Handbücher und Register-Programmierung – das lehren Hochschulen heute kaum noch. Neue Entwickler kommen mit Python, höheren Abstraktionsniveaus.

DevOps kann diese Barriere zwischen Anwendungsumgebung und der vertrauten Umgebung für neue Entwickler überwinden. Unternehmen haben Schwierigkeiten, neue Software-Talente für rudimentäre C-Umgebungen zu gewinnen. Viele Absolventen wollen zu Silicon-Valley-Unternehmen. Für Industrie- oder Luftfahrt-/Rüstungsunternehmen ist es schwerer, Talente zu gewinnen.

Eine vertraute Entwicklungsumgebung hilft. Deshalb setzt Wind River auf Visual Studio Code – ein Umfeld, das neue Absolventen gut kennen, während Eclipse weniger bekannt ist. Man muss dort sein, wo die Zielgruppe schon ist.

Welche Probleme haben Unternehmen bei der DevOps-Einführung?

Morphew: Die größte Hürde ist der kulturelle Wandel im Unternehmen – nicht embedded-spezifisch, aber tief in Entwicklungspraktiken verankert. Kleine Teams, Einzelpersonen mit spezifischen Aufgaben: DevOps erfordert Zusammenarbeit, die Menschen aus ihrer Komfortzone holt. „Alle arbeiten zusammen.“

Der „Ops“-Teil bei Embedded DevOps ist eine Herausforderung: In traditionellem Cloud-DevOps ist Ops standardisiert. Bei Embedded geht es um ein Gerät im Feld, dessen Funktion firmenspezifisch ist. Oft sind Gerätehersteller nicht die Betreiber. Ein Gerätehersteller verkauft an ein großes Energie- oder Fertigungsunternehmen – diese betreiben die Geräte. Manchmal unterstützt der Hersteller, aber es ist kein geschlossener Loop wie bei Cloud-Lösungen.

Toolset-Kompatibilität: Gemeinsame Entwicklungsumgebungen stoßen auf Widerstand – wieder Kultur und Management-Backing.

Hardware: Wie bekommt man genug Hardware für die Automatisierungsumgebungen, die DevOps real machen? Laufende Herausforderung. Erfolgreiche Kunden nutzen Mix aus Hardware und Simulation zum Skalieren der Testprozesse.

Gibt es Tools, die den DevOps-Übergang erleichtern?

Morphew: Die Verfügbarkeit von Tools hilft – viele Open Source oder mit Free-Versionen. Früher Konsolidierung um Source Code Management (oft Git). Jetzt integrieren Organisationen mehr DevOps-Tools. Das erleichtert den Übergang.

Es gibt viel Auswahl – manchmal zu viel. Die Herausforderung: Wie bringt man sie zu einer funktionierenden Lösung zusammen?

Viele Unternehmen starten Projekte mit internen Teams für den Übergang zu digitaler Entwicklung. Wir sehen einen Übergang im Embedded-Bereich wie bei früheren Technologie-Übergängen: oft „Do-it-yourself“, „bauen wir das perfekte System für uns“. Das bindet immer mehr Ressourcen nur für Wartung. Das wird sich wahrscheinlich Richtung Managed Services entwickeln.

Ein weiterer Hebel: klare Trennung zwischen Anwendungsentwicklung und Wartung der Software-Plattformen. Früher kleines Team für beides, Application und Platform verschmolzen. Jetzt braucht man klare Trennung für Modularisierung und dass Leute an dem arbeiten, wofür sie die besten Skills haben.

Welche Branchentreiber gibt es für Lösungen, die Embedded-Entwicklung und -Test erleichtern?

Morphew: Konvergenz von IT und OT: Geräte sind ans Internet angebunden – großer Treiber für Neubewertung der Software-Auslieferung. Compliance-Anforderungen für Software-Updates in Geräten (z. B. Medizintechnik: Nachweis, dass Geräte bei Sicherheitslücken aktualisierbar sind – lebenswichtig).

Diese Treiber zwingen Unternehmen, ihre Prozesse auf Remote-Updates zu prüfen. Große Unternehmen fühlen sich bedroht von digital-nativen Newcomern – Begriff: „Teslafication“. Man muss mehr wie Tesla sein: software-fokussiert statt Hardware-Denken. Produkte differenzieren sich zunehmend über Software.

Die Pandemie beschleunigt den Trend: Software-Belegschaft arbeitet von zu Hause, viele kehren nicht ins Büro zurück. Großer Shift – braucht neue Denkweise für produktive Remote-Arbeit. Schreit nach mehr Kollaborationstools und Standardisierung, weil Face-to-Face-Entfällt.

Warum sind schnelle Software-Iterationen kritischer Wettbewerbsvorteil? Zusammenhang mit automatisiertem Testen?

Morphew: Ich habe mehrere Projekte vom Wasserfall- zum agilen Modell begleitet. Continuous Testing, automatisiertes Testen ist oft der Flaschenhals für Produktivitätssteigerung. Wenn man schnell laufen will und Qualität halten will, ist es unverzichtbar. Digital Twin des Endgeräts ermöglicht viel Testen im großen Maßstab.

Großer Fortschritt: Simulation des Embedded Devices im Cloud-Maßstab nutzen. Hundert Tests gleichzeitig – nur durch Cloud-Ressourcen begrenzt. Transformation, die viele Unternehmen durchlaufen und hoch schätzen.

Wind River hat seit Jahren Simulations-Geschäft. Frühe Adopter skalierten Simulationen auf eigenen Servern. Cloud macht es flexibler: Hardware-Typ und Menge steuerbar, hoch- und runterskalierbar nach Bedarf, statt Capex für große Hardware und IT-Teams. Aktuell Hybrid: teils On-Premises, teils Public Cloud.

Weitere Punkte?

Morphew: Bei DevOps und Cloud-nativer Embedded-Entwicklung gibt es große Veränderungen. Zusammenarbeit: Ich versuchte einen Linux-Build, hatte Probleme. Ein Linux-Architekt sah meine fehlgeschlagenen Builds, kontaktierte mich per Chat: „Hey, ich seh dein Problem, Einstellung ändern, läuft. Hab's für dich gefixt.“ In lokaler Umgebung hätte niemand gewusst, ich hätte fragen müssen, Szenario nicht reproduzierbar können, wahrscheinlich den ganzen Tag festgesteckt, vielleicht aufgegeben. Schnelle Zugriff auf Software ohne lokale Installation, gemeinsamer Sandbox – großer Augenöffner für veränderte Arbeitsweise durch geteilte Assets.

RTInsights: Noch was?

Morphew: In naher Zukunft: digitale Feedback-Loops – Daten vom Gerät und aus Entwicklungsumgebung zurückführen, um Software zu verbessern. KI/ML spielen hinein. Welche Infos vom Gerät? Wie im großen Cloud-Scale/Big-Data-Modell analysieren und in zukünftige Entwicklung einspeisen? Könnte System-Optimierung insgesamt ermöglichen.