Bildquelle: imgflip.com
Firmware und Embedded Software bezeichnen unterschiedliche Abstraktionsebenen innerhalb desselben Systems – eine Unterscheidung, die bei der Projektplanung, Zertifizierungsstrategie und Partnerwahl direkt Auswirkungen auf Kosten und Timeline hat. Wer beides synonym verwendet, riskiert Fehlkommunikation mit Entwicklungspartnern und falsch zugeordnete Zertifizierungsanforderungen, besonders in der Medizintechnik und industriellen Automatisierung.
Dieser Artikel richtet sich an Produktverantwortliche und Engineering Leads, die Hardware-Produkte entwickeln oder beauftragen. Er klärt die technischen Grenzen beider Begriffe, zeigt wo diese Grenzen in der Praxis verschwimmen und welche Entscheidungen davon abhängen.
Was ist Firmware und wofür wird sie eingesetzt?
Firmware ist hardwarenaher Code, der direkt auf einem Mikrocontroller ausgeführt wird, typischerweise aus nichtflüchtigem Speicher (Flash oder ROM), ohne vollständiges Betriebssystem. Sie initialisiert Peripherie, implementiert Kommunikationsprotokolle auf Register-Ebene und steuert Sensoren und Aktuatoren mit deterministischem Timing.
Typische Zielplattformen sind ressourcenbeschränkte Mikrocontroller in IoT-Geräten, Wearables, industriellen Steuerungen und Medizinprodukten – Systeme mit oft unter 256 KB Flash und unter 64 KB RAM, bei denen jede Speicherzuweisung und jeder Interrupt-Handler explizit geplant werden muss.
Ein häufig unterschätztes Risiko: Firmware, die im Feld nicht aktualisierbar ist (kein OTA-Mechanismus), bindet das Produkt an den Entwicklungsstand zum Zeitpunkt der Auslieferung. Sicherheitslücken oder Protokolländerungen – etwa bei BLE-Stack-Updates – lassen sich dann nur durch Hardware-Rückruf beheben. OTA-fähige Firmware erhöht den Flash-Bedarf um typischerweise 30–50 % durch den Bootloader und den zweiten Image-Slot, was bei der Plattformauswahl einkalkuliert werden muss.
Was ist Embedded Software und wie unterscheidet sie sich von normaler Software?
Embedded Software ist der Oberbegriff für alle Software auf eingebetteten Systemen – einschließlich Firmware, RTOS, Treibern und Anwendungslogik. Sie ist für eine spezifische Hardwareplattform optimiert, muss Echtzeit-Anforderungen erfüllen und unter definierten Energiebudgets laufen, die sich aus Batteriekapazität und Ziellebensdauer ergeben.
Der strukturelle Unterschied zu Desktop- oder Web-Software liegt in der fehlenden Abstraktionsschicht: Kein universelles Betriebssystem puffert Hardware-Zugriffe, kein Memory Manager verhindert Stack-Overflows automatisch, kein Watchdog greift ein, wenn er nicht explizit implementiert wurde. Embedded-Entwickler müssen elektrische Eigenschaften der Hardware – Pegelspannungen, Timing-Diagramme, Interrupt-Latenzen – direkt in Softwareentscheidungen einbeziehen.
Ein praktisches Beispiel aus der Industrie: Ein Condition-Monitoring-Gerät für rotierende Maschinen muss Vibrationsdaten mit präzisem Zeitstempel erfassen, lokal vorverarbeiten und über ein Feldbus-Protokoll übertragen – alles innerhalb eines Energiebudgets, das durch einen 3,6-V-Lithium-Primärzelle mit 2.400 mAh über fünf Jahre definiert ist. Diese Kombination aus Timing, Rechenleistung und Energiebudget ist in Standard-Software-Entwicklung nicht abbildbar.
Wer Embedded-Entwickler mit reinem Software-Hintergrund einsetzt, unterschätzt regelmäßig den Aufwand für Hardware-Bring-up und Treiberentwicklung – erfahrungsgemäß 20–40 % des Gesamtprojektaufwands bei neuen Plattformen.
Was ist der genaue Unterschied zwischen Firmware und Embedded Software?
Firmware bezeichnet die unterste Softwareschicht: bare-metal Code oder minimaler HAL-Code, der direkt auf dem Prozessor läuft und Hardwareregister anspricht. Embedded Software umfasst alle Schichten darüber – RTOS, Middleware, Protokoll-Stacks, Anwendungslogik – die auf dieser Firmware-Basis aufsetzen.
Jede Firmware ist Embedded Software. Nicht jede Embedded Software ist Firmware. Die Grenze ist nicht immer scharf, weil moderne Mikrocontroller-Frameworks wie Zephyr oder Arduino die Trennung zwischen HAL und Anwendungslogik bewusst aufweichen, um Portabilität zu erhöhen.
- Firmware: hardwarenaher Code, oft ohne Betriebssystem, direkt auf dem Mikrocontroller – steuert Peripherie, Interrupts, Boot-Sequenz
- Embedded Software: Gesamtheit aller Software auf eingebetteten Systemen, einschließlich Firmware, RTOS, Treibern und Anwendungslogik
Für die Projektplanung ist die Unterscheidung relevant, wenn verschiedene Schichten unterschiedlichen Zertifizierungsanforderungen unterliegen. Nach IEC 62304 (Medizinprodukte-Software) müssen sicherheitsrelevante Software-Einheiten unabhängig von ihrer Schichtzugehörigkeit klassifiziert und dokumentiert werden. Wer diese Zuordnung erst spät im Projekt vornimmt, riskiert Nacharbeiten, die 8–16 Wochen zusätzliche Zertifizierungszeit kosten können.
Wann spricht man von Firmware und wann von Embedded Software?
Von Firmware spricht man, wenn der Code direkt auf einem Mikrocontroller läuft, Hardwareregister anspricht und keine oder minimale Betriebssystem-Abstraktion verwendet. Von Embedded Software spricht man, wenn das System mehrere Softwareschichten umfasst – RTOS, Protokoll-Stacks, Anwendungslogik – die unabhängig voneinander entwickelt, getestet und zertifiziert werden können.
Konkretes Beispiel: Der Code, der einen BLE-Controller über SPI initialisiert, HCI-Kommandos sendet und Interrupt-Handler für eingehende Pakete registriert, ist Firmware. Die Softwarearchitektur eines IoT-Gateways, die diesen BLE-Stack mit einer MQTT-Verbindungsschicht, einem lokalen Datenpuffer und einem OTA-Update-Manager kombiniert, ist Embedded Software.
In der Medizintechnik und industriellen Automatisierung bestimmt diese Unterscheidung die Zertifizierungsstrategie. IEC 62304 und IEC 61508 verlangen eine Rückverfolgbarkeit von Anforderungen bis auf Softwareeinheiten-Ebene. Wer Firmware und Anwendungslogik in einer monolithischen Codebasis vermischt, kann diese Rückverfolgbarkeit nicht ohne erheblichen Nachaufwand nachweisen – ein häufiger Grund für Verzögerungen in der Konformitätsbewertung.
Die Architekturentscheidung zwischen monolithischer Firmware und geschichteter Embedded Software muss vor dem ersten Schreiben von Produktionscode getroffen werden. Eine nachträgliche Refaktorierung kostet bei mittlerer Projektgröße typischerweise 6–12 Wochen Entwicklungszeit.
Welche Rolle spielen Echtzeit-Betriebssysteme wie FreeRTOS oder Zephyr?
Ein RTOS ist dann gerechtfertigt, wenn das System mehrere zeitkritische Aufgaben parallel ausführen muss und deren Ausführungsreihenfolge nicht durch einfaches Polling oder Interrupt-Handler zuverlässig kontrolliert werden kann. Der Overhead eines RTOS – typischerweise 5–15 KB Flash und 1–4 KB RAM für FreeRTOS auf Cortex-M – ist auf ressourcenbeschränkten Plattformen kein vernachlässigbarer Faktor.
FreeRTOS eignet sich für Projekte mit begrenzten Ressourcen und einfacher Task-Struktur. Die Lizenz (MIT) ist unkompliziert, die Community-Dokumentation ist umfangreich, und der minimale Footprint macht es auf Cortex-M0/M0+ einsetzbar. Zephyr bietet eine modernere Treiberarchitektur, nativen BLE- und Wi-Fi-Stack sowie ein Kconfig-basiertes Build-System, das Portabilität über Plattformen hinweg erleichtert. Der Einstiegsaufwand ist höher: Zephyr-Projekte benötigen erfahrungsgemäß 2–4 Wochen mehr Einarbeitungszeit für Teams ohne Zephyr-Erfahrung.
Ein bekanntes Fehlermuster bei RTOS-Einsatz: Priority Inversion, bei der ein niedrig priorisierter Task eine Ressource hält, die ein hochpriorisierter Task benötigt. Ohne Priority-Inheritance-Mechanismus – den FreeRTOS optional unterstützt, der aber explizit konfiguriert werden muss – führt das zu nicht-deterministischen Latenzen, die in sicherheitskritischen Anwendungen zum Systemausfall führen können.
Wir bei Oxeltech wählen das RTOS anhand von Plattform-Constraints, Zertifizierungsanforderungen und der vorhandenen Team-Expertise. Mehr über unsere Herangehensweise erfahren Sie auf der Über-uns-Seite von Oxeltech.
Welche Fehler sollte man bei der Firmware- und Embedded-Software-Entwicklung vermeiden?
Die kostspieligsten Fehler in der Embedded-Entwicklung entstehen nicht durch falsche Algorithmen, sondern durch Architekturentscheidungen, die zu spät getroffen oder zu früh festgeschrieben werden. Die folgenden drei Muster sind in der Praxis am häufigsten und am teuersten.
Fehlende Anforderungsanalyse
Reaktionszeitanforderungen, Kommunikationsprotokolle und Energiebudgets müssen vor Entwicklungsbeginn quantifiziert sein – nicht als Richtwerte, sondern als testbare Kriterien. Ein Wearable mit 200 mAh Zelle und einem Ziel von 7 Tagen Laufzeit erlaubt im Durchschnitt einen Ruhestrom von unter 120 µA. Wer diese Rechnung nicht vor der MCU-Auswahl durchführt, wählt möglicherweise eine Plattform, deren Peripherie-Leckströme das Budget bereits ohne Anwendungslogik ausschöpfen.
Anforderungsänderungen nach Beginn der Firmware-Entwicklung kosten überproportional viel: Eine geänderte Sampling-Rate für einen Sensor kann Interrupt-Konfiguration, DMA-Setup, Pufferdimensionierung und Energiemanagement-Logik gleichzeitig betreffen.
Keine frühzeitige Hardware-Software-Integration
Firmware, die ausschließlich auf Simulatoren oder Evaluation Boards entwickelt wird, trifft auf der Zielplattform regelmäßig auf Timing-Probleme, die im Simulator nicht sichtbar waren: SPI-Taktfrequenzen, die mit dem Layout-bedingten Leitungswiderstand interagieren, I²C-Pull-up-Dimensionierungen, die bei bestimmten Temperaturen die Anstiegszeit aus der Spezifikation treiben, oder Interrupt-Latenzen, die durch DMA-Arbitrierung variieren.
Hardware-Software-Integration sollte spätestens mit dem ersten Prototypen beginnen, nicht mit dem Pre-Production-Sample. Jede Iteration, die erst auf späten Hardware-Revisionen stattfindet, verlängert den Entwicklungszyklus um typischerweise 4–8 Wochen pro gefundener Systeminteraktion.
Vernachlässigung von Energieoptimierung und Sicherheit
Energieoptimierung, die erst nach funktionaler Fertigstellung adressiert wird, erfordert häufig Architekturänderungen, keine Parameter-Anpassungen. Ein System, das Sleep-Modi nicht von Anfang an in seine Task-Struktur integriert, kann diese nicht nachträglich ohne Refaktorierung des gesamten Scheduling-Konzepts einführen.
Sicherheit in der Firmware betrifft konkret: Secure Boot, verschlüsselte OTA-Updates, Schutz von Kryptoschlüsseln im Flash und Absicherung von Debug-Schnittstellen (JTAG/SWD) in Produktions-Images. Ein Medizinprodukt oder industrielles Steuergerät ohne diese Maßnahmen erfüllt die Anforderungen der EN 18031 (ehemals ETSI EN 303 645 im IoT-Kontext) nicht und riskiert Marktzugangsprobleme in der EU ab 2025.
Wenn Sie ein Projekt planen und einen erfahrenen Partner für die Firmware- oder Embedded-Software-Entwicklung suchen, nehmen Sie Kontakt mit uns auf und besprechen Sie Ihr Vorhaben mit unserem Team.
Ähnliche Beiträge
- Wie lange dauert die Entwicklung eines IoT-Geräts bis zur Serienreife?
- Wie skaliert man die Produktion eines Wearables von 100 auf 10.000 Einheiten?
- Was ist ein Embedded System und wie wird es eingesetzt?
- Wie entwickelt man ein ultra-kompaktes Wearable-Design?
- Wie schützt man Wearable-Elektronik vor Schweiß und Feuchtigkeit?
