Was Embedded Software von klassischer Softwareentwicklung unterscheidet
Embedded Software läuft nicht auf einem Rechner mit Betriebssystem, Tastatur und Monitor. Sie läuft auf einem Mikrocontroller in einem Gerät. Direkt auf der Hardware. Oft ohne Display, ohne Netzwerkverbindung, ohne die Möglichkeit, nach einem Absturz einfach neu zu starten.
Das klingt nach einer technischen Randnotiz. In der Praxis bestimmt es alles: Wie der Code strukturiert wird, welche Sprachen zum Einsatz kommen, wie man testet, welche Fehler tolerierbar sind und welche nicht.
Wer klassische Applikationsentwicklung kennt, unterschätzt diesen Unterschied gerne. Softwareentwicklung Embedded verlangt ein anderes Denken. Ressourcen sind knapp. Reaktionszeiten sind definiert. Und ein Fehler im Feld bedeutet oft: Rückruf, Garantiefall, Reputationsschaden.
Warum Embedded Software im Gerätebau über Erfolg oder Misserfolg entscheidet
Ein mechatronisches Gerät ist nur so gut wie sein schwächstes Glied. Mechanik und Elektronik können einwandfrei ausgelegt sein. Wenn die Embedded Software unzuverlässig reagiert, Sensordaten falsch verarbeitet oder bei unvorhergesehenen Eingaben einfriert, ist das Gerät im Feld nicht einsetzbar.
Das passiert häufiger, als man denkt. Nicht weil die Entwickler schlecht sind, sondern weil Embedded Software unter Rahmenbedingungen entsteht, die Fehler begünstigen: enge Zeitpläne, Hardware, die noch nicht final ist, und Anforderungen, die sich während der Entwicklung ändern.
Für Entwicklungsleiter bedeutet das: Die Qualität der Embedded Software muss von Anfang an mitgedacht werden. Nicht erst beim Integrationstest.
Die Grundarchitektur: Bare-Metal, RTOS oder Linux
Bei jedem Embedded-Projekt steht früh eine grundlegende Entscheidung an. Welche Software-Architektur trägt das System?
Bare-Metal
Kein Betriebssystem. Der Code läuft direkt auf dem Mikrocontroller, gesteuert durch eine einfache Hauptschleife oder Interrupts. Bare-Metal ist schnell, deterministisch und ressourcensparend. Für einfache Steuerungsaufgaben mit klaren Timing-Anforderungen oft die richtige Wahl.
RTOS (Real-Time Operating System)
Ein Echtzeitbetriebssystem wie FreeRTOS, Zephyr oder RTEMS ermöglicht parallele Aufgaben mit definierten Prioritäten. Mehrere Prozesse laufen nebeneinander, Reaktionszeiten bleiben garantiert. Das ist relevant, sobald ein Gerät gleichzeitig Sensoren ausliest, Daten verarbeitet und über eine Schnittstelle kommuniziert.
Embedded Linux
Für Geräte mit höherer Rechenleistung, komplexen Protokollstacks oder grafischen Oberflächen kommt Embedded Linux zum Einsatz. Die Flexibilität ist groß, der Ressourcenbedarf ebenfalls. Nicht jede Hardware trägt das. Und die Zertifizierung für sicherheitskritische Anwendungen wird aufwändiger.
Die Wahl der Architektur ist keine rein technische Entscheidung. Sie beeinflusst Entwicklungsaufwand, Testbarkeit, Wartbarkeit und langfristige Updatefähigkeit des Geräts.
Programmiersprachen in der Embedded-Entwicklung
C ist nach wie vor die dominierende Sprache. Nah an der Hardware, deterministisches Verhalten, breite Toolchain-Unterstützung. Für die meisten Mikrocontroller-Projekte ist C die Standardwahl.
C++ gewinnt an Boden, besonders wenn Objektorientierung und Wiederverwendbarkeit gefragt sind. Allerdings muss man wissen, was man tut. Dynamische Speicherverwaltung, Exceptions und bestimmte STL-Funktionen sind in ressourcenbeschränkten Umgebungen problematisch.
Rust wird in der Embedded-Community zunehmend diskutiert. Speichersicherheit ohne Garbage Collector klingt verlockend. In der breiten Praxis des Gerätebaus ist Rust noch kein Standard, aber die Entwicklung ist zu beobachten.
Python, JavaScript oder ähnliche Hochsprachen haben in der Embedded-Welt nur in sehr spezifischen Kontexten eine Rolle, etwa bei MicroPython auf bestimmten Plattformen. In der industriellen Geräteentwicklung sind sie die Ausnahme.
Entwicklungswerkzeuge und Toolchain
Eine funktionierende Toolchain ist das Fundament jeder Embedded-Entwicklung. Sie umfasst Compiler, Linker, Debugger und das Build-System. Fehler in der Toolchain-Konfiguration kosten Stunden, manchmal Tage.
| Kategorie | Typische Tools |
|---|---|
| Compiler | GCC (ARM), IAR, Keil MDK |
| IDE / Editor | STM32CubeIDE, VS Code + Plugins, Eclipse |
| Debugger | JTAG/SWD, J-Link, OpenOCD |
| Versionskontrolle | Git (obligatorisch) |
| Build-Automatisierung | CMake, Make, Ninja |
| Statische Analyse | PC-lint, Polyspace, Cppcheck |
Hinzu kommen Emulatoren und Hardware-in-the-Loop-Systeme, die es erlauben, Software zu testen, bevor finale Hardware verfügbar ist. Wer darauf verzichtet, schiebt Risiken in die Integrationsphase und zahlt doppelt.
Testen von Embedded Software: Was wirklich zählt
Testen ist in der Embedded-Entwicklung kein nachgelagerter Schritt. Es ist Teil des Prozesses.
Unit-Tests auf dem Host-Rechner ermöglichen schnelle Iterationen ohne Hardware. Frameworks wie Unity oder CppUTest sind dafür verbreitet. Entscheidend ist, dass der Code so strukturiert ist, dass er testbar ist. Wer Hardwarezugriffe nicht abstrahiert, kann auf dem Host nicht testen.
Integrationstests auf der Zielhardware prüfen, ob Softwaremodule korrekt zusammenarbeiten und ob das Timing stimmt. Systemtests mit vollständig integrierten Geräten schließen die Kette.
Für regulierte Branchen (Medizintechnik, Funktionale Sicherheit nach IEC 61508 oder ISO 26262) gelten darüber hinaus normative Anforderungen an Testabdeckung und Dokumentation. Diese frühzeitig zu kennen, spart erhebliche Nacharbeit.
Schnittstellen und Kommunikationsprotokolle
Embedded Systeme kommunizieren. Mit Sensoren, Aktoren, anderen Steuergeräten, Gateways oder Cloud-Diensten. Die Wahl des Protokolls hängt vom Anwendungsfall ab.
Geräteinterne Kommunikation
- UART: Einfach, weit verbreitet, gut für Debug-Ausgaben und einfache Datenleitungen.
- SPI: Schnell, synchron, für Displays und Speicher-ICs verbreitet.
- I²C: Mehrteilnehmerfähig, geringer Leitungsaufwand, ideal für Sensoren.
- CAN: Standard in Fahrzeugen und Industrieautomation, robust gegen Störungen.
Externe Kommunikation
- Ethernet / TCP-IP: Für vernetzte Industriegeräte und IIoT-Anwendungen.
- Modbus, Profibus, EtherCAT: Industrielle Feldbusse mit spezifischen Stärken je nach Umgebung.
- Bluetooth LE, Zigbee, LoRa: Drahtlose Protokolle für batteriebetriebene oder mobile Geräte.
Wer Protokolle früh festlegt und sauber implementiert, vermeidet Integrationsprobleme auf dem Weg zur Serienreife.
Embedded Software im mechatronischen Gesamtsystem
Softwareentwicklung Embedded endet nicht an der Softwaregrenze. In einem mechatronischen Gerät greifen Mechanik, Elektronik und Software ineinander. Änderungen in der Hardware beeinflussen die Software und umgekehrt.
Das stellt Entwicklungsteams vor eine organisatorische Herausforderung. Wer Hardware und Software in getrennten Silos entwickelt, trifft sich erst beim Integrationstest. Und genau dort entstehen die teuersten Probleme.
Interdisziplinäre Abstimmung von Anfang an ist kein Luxus. Es ist die Voraussetzung dafür, dass ein Gerät termingerecht zur Serienreife kommt. Bei GBN Systems entwickeln Mechanik-, Elektronik- und Softwareingenieure gemeinsam an einem Projekt. Nicht sequenziell, sondern parallel und abgestimmt.
Embedded Software outsourcen: Worauf es wirklich ankommt
Viele Entwicklungsleiter stehen vor der gleichen Frage: Das interne Team ist zu klein oder zu spezialisiert, um Embedded Software parallel zu anderen Vorhaben zu entwickeln. Ein externer Partner soll die Lücke schließen. Aber welcher?
Die Entscheidung ist keine reine Kapazitätsfrage. Sie ist eine Qualitätsfrage. Schlechte Erfahrungen mit externen Dienstleistern entstehen fast immer aus denselben Ursachen: unklare Anforderungen zu Projektbeginn, fehlende Dokumentation, kein strukturierter Übergabeprozess, und ein Partner, der entwickelt, aber nicht versteht, wie das Gerät am Ende funktionieren soll.
Was einen guten Partner von einem schlechten unterscheidet, lässt sich an konkreten Punkten festmachen.
- Kann der Partner die Anforderungsanalyse aktiv mitgestalten, oder wartet er auf fertige Spezifikationen?
- Wird der Code so dokumentiert, dass interne Teams später damit weiterarbeiten können?
- Hat der Partner Erfahrung mit dem Weg bis zur Serienreife, nicht nur bis zum funktionierenden Prototypen?
- Gibt es nachvollziehbare Prozesse für Änderungsmanagement und Versionskontrolle?
Wer diese Fragen im Erstgespräch nicht klar beantworten kann, ist wahrscheinlich nicht der richtige Partner für ein serienreifes Produkt.
Häufige Fragen zur Softwareentwicklung Embedded
Das hängt stark von Komplexität, Plattform, Echtzeitanforderungen und Normierung ab. Ein einfaches Steuerungsprogramm auf einem Mikrocontroller ohne Betriebssystem ist in Wochen umsetzbar. Ein sicherheitskritisches System mit RTOS, dokumentierter Testabdeckung und normativen Anforderungen erfordert Monate. Pauschalen ohne Kontextkenntnis sind unseriös.
Von wenigen Wochen für einfache Firmware bis zu einem Jahr oder mehr für komplexe Systeme mit Zertifizierungsanforderungen. Entscheidend ist: Wie früh wird die Softwarearchitektur definiert? Wie stabil ist die Hardware-Plattform? Gibt es klare Anforderungen?
Ja, in den meisten Fällen. Bei Geräten mit Over-the-Air-Update oder USB-Flashfunktion ist das einfach. Bei Geräten ohne Update-Mechanismus im Feld müssen Änderungen entweder vor Auslieferung oder durch physischen Zugriff eingespielt werden. Das spricht dafür, Update-Fähigkeit von Anfang an einzuplanen.
Normen wie IEC 61508 oder EN ISO 13849 definieren, wie Software in sicherheitskritischen Anwendungen entwickelt, getestet und dokumentiert werden muss. Das betrifft Anforderungsmanagement, Testabdeckung, Coderichtlinien und Nachweispflichten. Wer das nicht von Anfang an berücksichtigt, hat im Zertifizierungsprozess ein ernstes Problem.
Embedded Software ist kein Anhängsel eines Geräteprojekts. Sie ist sein Kern. Wer das versteht und entsprechend plant, bringt sein Produkt sicher und termingerecht in die Serie.