Kundenspezifische Systemintegration
Embedded Redesign
Board Support Package für Systemhäuser
Wenn Build, Test und Release nicht mehr nachvollziehbar zusammenpassen
In gewachsenen Embedded-Projekten entstehen Abhängigkeiten oft schleichend. Build-Umgebungen unterscheiden sich, Bibliotheken werden manuell gepflegt und Releases hängen an einzelnen Rechnern oder Erfahrungswissen. Mit zunehmender Produktlaufzeit wird daraus ein technisches und organisatorisches Risiko.
Nicht reproduzierbare Build-Umgebungen
Unklare Abhängigkeiten
Manuelle Releases und UpdatesDocker-Container sind nicht immer Linux-basiert
Containerisierung ist grundsätzlich nicht auf Linux beschränkt. Moderne Windows-Systeme können Windows-Container ausführen. Für Linux existieren mit Docker und vergleichbaren Container-Technologien allerdings besonders etablierte Mechanismen für die Paketierung und Isolation von Anwendungen.
Linux-basierte Embedded-Systeme
- Typischer Einsatzbereich für Docker auf ARM-basierten Zielgeräten
- Yocto ermöglicht eine gezielt zugeschnittene Linux-Systembasis
- Geeignet für die Trennung von Linux-Anwendungen und ihren Laufzeitabhängigkeiten
Moderne Windows-Systeme
- Windows-Container können für passende Windows-Anwendungen eine Option sein
- Erfordert in der Regel einen kompatiblen modernen Windows-Host
- Eignung hängt von Windows-Version, Anwendungsarchitektur und Betriebsumgebung ab
Für die Containerisierung klassischer Windows-Anwendungen ist eine individuelle technische Bewertung erforderlich. Windows Embedded Compact beziehungsweise WinCE ist nicht mit modernen Windows-Container-Umgebungen gleichzusetzen und in der Regel keine Docker-Zielplattform.
Containerisierung ist keine vollständige Embedded-Systemarchitektur
Die nachfolgende technische Einordnung konzentriert sich auf Linux-basierte Embedded-Systeme. Hier bilden Kernel, Treiber und eine beispielsweise mit Yocto erstellte Systembasis die Grundlage, auf der Docker-Container betrieben werden können.
Containerisierung strukturiert die Anwendungsebene. Sie ersetzt weder Embedded Linux, Kernel und Treiber noch ein Update-, Persistenz- oder Recovery-Konzept.
Docker-basierte Container kapseln Anwendungen und ihre definierten User-Space-Abhängigkeiten. Das kann Entwicklung, Test und Auslieferung deutlich besser beherrschbar machen. Die hardwarenahe Systembasis bleibt jedoch weiterhin eine zentrale Aufgabe der Embedded-Entwicklung.
Was Containerisierung leisten kann- einzelne Dienste getrennt versionieren und bereitstellen
- Build- und Testumgebungen reproduzierbarer gestalten
- definierte Images als nachvollziehbare Release-Artefakte erzeugen
- versionierte Anwendungsreleases kontrollierter organisieren
Was auf Systemebene entschieden werden muss- Hardwarezugriffe auf Schnittstellen und Peripherie
- Systemdienste, Benutzerrechte und Netzwerkarchitektur
- Ressourcenmanagement, Startverhalten und Echtzeitanforderungen
- Systemupdates, Persistenz, Recovery und Rückfallstrategien
Der Unterschied zwischen Containerisierung und Virtualisierung
Container und virtuelle Maschinen verfolgen beide das Ziel, Anwendungen voneinander zu trennen. Die technische Umsetzung ist jedoch grundlegend verschieden.
| Kriterium | Container | Virtuelle Maschine |
|---|---|---|
| Betriebssystem | Nutzt das Betriebssystem des Hosts | Enthält ein eigenes Gastbetriebssystem |
| Linux-Kernel | Wird mit dem Hostsystem geteilt | Läuft innerhalb des jeweiligen Gastbetriebssystems |
| Ressourcenbedarf | In der Regel geringer, abhängig von Anwendung und Image | Höher durch zusätzliches Betriebssystem und Virtualisierung |
| Startverhalten | Typisch schneller, abhängig von Anwendung und Initialisierung | Meist längerer Systemstart |
| Isolation | Trennung auf Betriebssystemebene | Trennung über virtualisierte Hardware |
| Typischer Embedded-Einsatz | Modularisierung von Linux-Anwendungen auf geeigneten Zielgeräten | Spezielle Anforderungen an Plattformtrennung oder Ausführungsumgebungen |
Container sind damit nicht automatisch die bessere Lösung. Für Embedded-Projekte lautet die relevante Frage:
Verbessert die Container-Grenze Wartbarkeit, Wiederholbarkeit und Updatefähigkeit so deutlich, dass sie den zusätzlichen Betriebsaufwand rechtfertigt?
Wann Docker-Containerisierung im Embedded-Umfeld sinnvoll ist
Containerisierung ist kein Standardbaustein für jedes Gerät. Sie sollte eingesetzt werden, wenn sie einen nachvollziehbaren technischen Nutzen liefert.
Docker-Containerisierung ist häufig sinnvoll, wenn …
- mehrere Dienste oder Anwendungen getrennt versioniert werden sollen
- Anwendungen klare Abhängigkeitsgrenzen besitzen
- Build- und Testumgebungen reproduzierbar werden müssen
- einzelne Komponenten unabhängig vom Basis-OS aktualisiert werden sollen
- ein klarer Build-, Test- und Releaseprozess aufgebaut werden soll
Eine andere Architektur kann geeigneter sein, wenn …
- Flash-, RAM- oder CPU-Reserven sehr begrenzt sind
- eine schlanke native Anwendung dieselbe Aufgabe einfacher erfüllt
- der Hardwarezugriff sehr eng und privilegiert mit der Anwendung verbunden ist
- besonders deterministische Reaktionszeiten im Mittelpunkt stehen
- eine Container Runtime den Gerätebetrieb unverhältnismäßig komplex macht
Die Entscheidung entsteht nicht anhand eines einzelnen Kriteriums. SIGMA bewertet Zielhardware, Zielsystem, Anwendungsarchitektur, Schnittstellen, Ressourcen und den geplanten Gerätebetrieb im Zusammenhang.
Die wichtigsten Bausteine einer Docker- und CI/CD-Architektur
Ein Dockerfile beschreibt nachvollziehbar, wie ein Container-Image aufgebaut wird: Basis-Image, Abhängigkeiten, Build-Schritte und Startverhalten der Anwendung.
Ein Container Image ist ein versioniertes Anwendungsartefakt. Es enthält die Anwendung und ihre definierten Laufzeitabhängigkeiten in einem reproduzierbaren Zustand.
Ein Container ist die laufende Instanz eines Images. Ressourcen, Berechtigungen, Netzwerk- & Gerätezugriffe und Datenpfade werden für den Betrieb festgelegt.
Docker Hub ist eine öffentliche Container Registry für Basis- und Anwendungs-Images. Für Produktivsysteme sollten Herkunft, Version und Eignung der verwendeten Images kontrolliert werden.
Git versioniert Quellcode, Konfigurationen, Build-Beschreibungen und Pipeline-Dateien. Änderungen bleiben nachvollziehbar und zeigen einen definierten Entwicklungsstand.
Eine CI/CD-Pipeline automatisiert wiederkehrende Schritte wie Build, Test, Artefaktablage und Bereitstellung. Dadurch sinkt die Abhängigkeit von manuellen Abläufen.
So funktioniert Docker auf einem Embedded-System
Auf der Zielhardware stellt ein beispielsweise mit Yocto aufgebautes Embedded Linux Kernel, Treiber und Systemdienste bereit. Darüber führt die Docker Engine Anwendungen in getrennten Containern aus.
- Container: enthalten Anwendung, Laufzeitbibliotheken und ein eigenes Dateisystem.
- Gemeinsame Basis: Alle Container nutzen den Linux-Kernel des Hostsystems.
- Klare Grenze: Bootloader, Kernel, Treiber und Hardwareintegration bleiben Teil der Systembasis.
Vom Quellcode zum nachvollziehbaren Release
Code und Dockerfile versionieren
Anwendung, Build-Beschreibung und Tests liegen nachvollziehbar im Git-Repository
GitLab-Pipeline ausführen
Ein GitLab Runner führt die definierten Build- und Testschritte der Pipeline aus
ARM-Image erzeugen
Das Container Image wird passend zur Zielarchitektur des Embedded-Systems gebaut
Image in Registry ablegen
Geprüfte Versionen werden versioniert in einer Container Registry bereitgestellt
Kontrolliert ausliefern
Das Zielgerät erhält das freigegebene Image über den vorgesehenen Update- oder Deployment-Prozess
GitLab im Embedded-Workflow
GitLab kann Git-Repository, CI/CD-Pipelines und Container Registry in einer Plattform verbinden. GitHub kann ebenfalls für Versionsverwaltung und automatisierte Workflows eingesetzt werden. Welche Umgebung zu Ihrem Projekt passt, hängt von vorhandener Infrastruktur, Berechtigungsmodell und Build-Prozess ab.
Yocto stellt die Systembasis bereit – Docker strukturiert die Anwendung
Ein Yocto-basiertes Embedded Linux kann gezielt auf Zielhardware und Produktanforderungen zugeschnitten werden. Bootloader, Kernel, Treiber, Systemdienste und der benötigte Softwareumfang werden auf Systemebene definiert.
Docker setzt oberhalb dieser Basis an. Container strukturieren Anwendungen und deren Abhängigkeiten, ohne die hardwarenahe Verantwortung vom Embedded-System zu entkoppeln.
Yocto-basierte Systembasis
- Bootloader, Kernel und Treiber
- Board-spezifische Konfiguration
- Hardwarezugriffe und Schnittstellen
- Benutzerrechte, Netzwerk und Systemdienste
- Grundlage für Update, Recovery und Betriebssicherheit
Containerisierte Anwendungsebene
- getrennte Anwendungskomponenten
- definierte Bibliotheken und Laufzeitabhängigkeiten
- reproduzierbare Build-Umgebungen
- versionierte Container-Images
- getrennt planbare Anwendungsreleases
Ein Container kann nur dann stabil betrieben werden, wenn die darunterliegende Linux-Systembasis zur Hardware, zur Anwendung und zum geplanten Lebenszyklus des Geräts passt. Diese Architektur beschreibt den Linux-basierten Schwerpunkt. Für moderne Windows-Container gelten andere Voraussetzungen hinsichtlich Hostsystem, Kompatibilität und Betriebsmodell.
Was bei Containerisierung auf Embedded-Geräten zusätzlich zählt
Docker-Container nutzen auf Linux-Systemen den Kernel des Hostsystems. Die Anwendung und ihre nativen Bibliotheken im Container müssen dennoch zur CPU-Architektur des Zielgeräts passen.
Ein Container Image, das für einen Intel- oder AMD-Rechner mit x86_64 erstellt wurde, läuft auf einem ARM-basierten Embedded-System – etwa mit einem i.MX System on Chip – nicht nativ. Dass beide Systeme Linux verwenden, reicht dafür nicht aus.
Das Image muss daher passend zur Zielarchitektur erzeugt werden. Je nach Projekt kommen dafür native ARM-Builds, Cross-Compilation oder Multi-Platform-Builds mit geeigneten Build-Umgebungen in Betracht. GitLab CI/CD kann diese architekturgerechte Build- und Testkette automatisieren.
Container sind leichter als virtuelle Maschinen, benötigen aber trotzdem Ressourcen. Container Runtime, Images, temporäre Dateien, Logs und persistente Daten müssen im realen Betrieb in das Flash-, RAM- und CPU-Budget passen.
GPIOs, USB-Geräte, serielle Schnittstellen, Kameras, Netzwerkadapter und weitere Peripherie bleiben explizite Integrationsaufgaben. Berechtigungen, Gerätedateien, Schnittstellenstabilität und Fehlerverhalten müssen auf Systemebene geplant werden.
Container-Images werden üblicherweise unveränderlich behandelt. Konfigurationen, Kalibrierwerte, Nutzdaten und Logdaten benötigen deshalb ein klar definiertes Persistenzkonzept.
Ein neues Container-Image ist kein vollständiges Updatekonzept. Es muss klar sein, wie Versionen freigegeben, verteilt, aktiviert und bei Fehlern zurückgenommen werden. Auch die Wechselwirkung mit Betriebssystem, Kernel und Gerätedaten ist zu berücksichtigen.
Containerisierung schafft keine Echtzeitfähigkeit. Zeitkritische Anforderungen müssen durch die gesamte Architektur erfüllt werden – von Hardware und Treibern über Betriebssystem und Scheduling bis zur Anwendung.
Container-Images kontrolliert erstellen und bereitstellen
Docker-Container sind nur dann belastbare Produktbausteine, wenn Herkunft, Version und Inhalt der verwendeten Images nachvollziehbar bleiben.
Kontrollierte und geprüfte Image-Quellen
Öffentliche Basis-Images können Entwicklung beschleunigen. Herkunft, Version und Eignung für das Zielsystem müssen jedoch geprüft werden.
Versionierte und freigegebene Artefakte
Nur geprüfte und freigegebene Images sollten auf Zielgeräte gelangen. Klare Versionsstände erleichtern Wartung und Fehleranalyse.
Keine vertraulichen Daten im Image
Zugangsdaten und Schlüssel gehören nicht in Dockerfiles oder Images. Sie benötigen ein separates Berechtigungs- und Verwaltungskonzept.
Containerisierung ist kein eigenständiger Sicherheitsnachweis. Sicherheit entsteht im Rahmen von Embedded Security Anpasungen und durch das Zusammenspiel von Systembasis, Berechtigungen, kontrollierten Images, Netzwerkarchitektur, Updateprozess und sauber entwickelter Software.
Containerisierung als Teil einer belastbaren Embedded-Architektur
SIGMA unterstützt nicht nur beim Einsatz einzelner Tools. Wir betrachten Containerisierung im Zusammenhang mit Linux-Systembasis, Zielhardware, Anwendung, Build-Prozess und Gerätebetrieb.
Container-Eignung und Architektur bewerten
Embedded Linux und Yocto integrieren
Build, Test und CI/CD strukturieren
Update, Recovery und Übergabe planenIn sechs Schritten zur passenden Container-Architektur
Ausgangssystem erfassen
Zielhardware, Betriebssystem, Anwendungen, Schnittstellen sowie bestehende Build- und Releaseprozesse aufnehmen.
Container-Grenzen definieren
Festlegen, welche Komponenten zur Systembasis gehören und welche Dienste sinnvoll containerisiert werden können.
Referenzarchitektur entwickeln
Image-Struktur, Berechtigungen, Persistenz, Logging, Registry und Bereitstellungsweg definieren.
Build und Test automatisieren
Build, Tests und Artefakterzeugung in einen nachvollziehbaren Prozess überführen – passend zur Zielarchitektur.
Auf Zielhardware validieren
Ressourcen, Startverhalten, Schnittstellen, Ausfallszenarien und Updatepfade auf dem realen Zielsystem prüfen.
Dokumentieren und übergeben
Architektur und Betriebsprozesse dokumentieren, transparent abstimmen und langfristig wartbar übergeben.
Containerisierung braucht Embedded-Verständnis unterhalb der Anwendungsebene
Ein Docker-Image allein macht aus einer Anwendung kein zuverlässig betreibbares Embedded-Produkt. Entscheidend ist das Verständnis für die gesamte Kette – vom SoC und der Zielhardware über das Betriebssystem, Kernel und Treiber bis zur Anwendung, zum Updateprozess und zur Wiederherstellung im Fehlerfall.
SIGMA verbindet diese Ebenen in der Embedded-Softwareentwicklung. Wir produzieren keine Hardware und sind nicht an einzelne Plattformanbieter gebunden. Dadurch bewerten wir Technologien wie Docker, Yocto oder GitLab anhand ihres tatsächlichen Nutzens für Ihr Gerät.
Containerisierung wird bei SIGMA auf Grundlage von Linux-, Yocto-, BSP- und ARM-Erfahrung eingeordnet.
Wir bewerten Architekturen nach Zielhardware, Produktanforderungen und langfristiger Wartbarkeit.
Wir entwickeln robuste, nachvollziehbare Software für Geräte mit langfristigem Betrieb.
FAQ
Nein. Containerisierung ist nicht ausschließlich an Linux gebunden. Moderne Windows-Systeme unterstützen ebenfalls Windows-Container.
Im Embedded-Umfeld wird Docker-basierte Containerisierung jedoch überwiegend auf Linux-Systemen eingesetzt. Linux lässt sich mit Buildsystemen wie Yocto gezielt auf Zielhardware zuschneiden. Zudem sind Container-Technologien dort breit etabliert und die Systembasis kann präzise auf Ressourcen, Treiber, Schnittstellen und den geplanten Gerätebetrieb abgestimmt werden.
Windows Embedded Compact beziehungsweise WinCE ist nicht mit modernen Windows-Container-Umgebungen vergleichbar und in der Regel keine Docker-Zielplattform.
Nein. Ob Docker sinnvoll ist, hängt von Kernel-Konfiguration, Ressourcen, Anwendungsarchitektur, Sicherheitsanforderungen und Betriebsmodell ab. Bei sehr kleinen Systemen oder besonders schlanken Anwendungen kann eine native Integration die bessere Lösung sein.
Das kann für Anwendungen auf modernen Windows-Systemen grundsätzlich möglich sein. Entscheidend sind unter anderem die verwendete Windows-Version, die Kompatibilität zwischen Host und Container, die Anwendungsarchitektur sowie Anforderungen an Hardwarezugriffe und Betrieb.
Der Schwerpunkt dieser Seite liegt auf Linux-basierten Embedded-Systemen. Für Windows-Anwendungen sollte die technische Eignung deshalb projektbezogen bewertet werden.
Das ist grundsätzlich möglich, muss aber gezielt integriert werden. Gerätedateien, Rechte, Schnittstellenstabilität, Fehlerverhalten und Updatefähigkeit sind Teil der Systemarchitektur und nicht allein eine Docker-Konfiguration.
Nicht nativ. Die enthaltenen Anwendungen, Bibliotheken und Basis-Images müssen zur ARM-Zielarchitektur passen. Dafür können native ARM-Builds, Cross-Compilation oder Multi-Platform-Builds eingesetzt werden.
Ja. GitLab kann Versionsverwaltung, CI/CD-Pipelines und eine Container Registry verbinden. Die konkrete Ausgestaltung richtet sich nach Projektgröße, bestehender Infrastruktur, Zielarchitekturen und dem gewünschten Freigabeprozess.
Teilweise. Anwendungen können getrennt vom Basisbetriebssystem versioniert und aktualisiert werden. Abhängigkeiten zwischen Container Runtime, Kernel, Treibern, Systemdiensten und Anwendung müssen dennoch berücksichtigt werden.
Docker schafft keine Echtzeitgarantie. Bei zeitkritischen Funktionen müssen Latenz, Determinismus und Fehlerreaktion über Hardware, Treiber, Betriebssystem, Scheduling und Anwendung hinweg geplant und validiert werden.
Lösungen für Ihre Branche und Ihre Prozesse stellen wir Ihnen gerne vor. Sprechen Sie mit den Spezialisten für den Mittelstand.
Jetzt anfragen
