Wenn Speicher, Zeit und Strom die Entscheidung treffen
Im Gerät gibt es keine zweite Instanz und kein schnelles Nachliefern. Was du auslieferst, läuft dort Jahre, oft ohne dass jemand daran je wieder ein Kabel steckt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Grenzen stehen fest, bevor die erste Zeile geschrieben ist
In der Anwendungsentwicklung ist ein Engpass eine Frage von mehr Rechenleistung. Im Gerät ist er endgültig: Der Baustein hat so viel Speicher, wie er hat, weil er in Stückzahl beschafft wurde und der Preis je Gerät zählt. Wer feststellt, dass die Anwendung nicht hineinpasst, kann nicht aufrüsten, sondern muss die Software ändern oder eine Hardwareänderung durchsetzen, die Monate kostet.
Die zweite Besonderheit ist die Reihenfolge. Software entsteht regelmäßig, bevor die endgültige Hardware existiert, zuerst gegen ein Entwicklungsboard, später gegen die ersten Muster. In dieser Zeit ändert sich die Hardware noch, und jede Änderung an einem Anschluss oder einem Baustein zieht Anpassungen in Treibern und Konfiguration nach sich.
Die dritte ist die Lebensdauer. Ein Gerät läuft oft zehn Jahre und länger, teilweise ohne Netzverbindung. Fehler, die im Feld auftreten, lassen sich nicht mit einem schnellen Nachliefern beheben, sondern brauchen einen Aktualisierungsweg, der beim Entwurf mitgedacht sein muss. Wer diesen Weg weglässt, produziert Geräte, die man später nur noch ersetzen kann.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, und wer setzt um
Eingebettete Projekte scheitern selten am Code und häufig an der Schnittstelle zwischen Hardware, Produktverantwortung und Software. Diese fünf Zeilen sind die üblichen Reibungspunkte.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Auswahl des Bausteins und der Ausstattung | Die Hardwareentwicklung zusammen mit dem Einkauf, weil Stückkosten und Verfügbarkeit daran hängen | Die Softwareseite beziffert vorher den Bedarf an Speicher, Rechenleistung und Schnittstellen und prüft die Vorauswahl | Der Bedarf der Software wird geschätzt, bevor die Anwendung entworfen ist. Wenn der Speicher später knapp wird, ist die Leiterplatte längst gefertigt, und die Software zahlt die Rechnung. |
| Basissystem: ohne Betriebssystem, Echtzeitsystem oder Linux | Die Systemarchitektur gemeinsam mit der Produktverantwortung, weil daran Zertifizierung, Aufwand und Lizenzfragen hängen | Die eingebettete Entwicklung baut das Systemabbild und pflegt es über die Produktlebensdauer | Linux wird gewählt, weil es bequem ist, und niemand plant die Pflege ein. Ein eigenes Abbild ist kein einmaliger Aufwand, sondern eine Verpflichtung über die gesamte Laufzeit des Geräts. |
| Zeitschranken und Reaktionszeiten | Die Produktverantwortung legt fest, was das Gerät in welcher Zeit tun muss, im regulierten Umfeld zusammen mit der Sicherheitsbetrachtung | Die Softwareseite entwirft Aufgabenprioritäten und weist die Einhaltung durch Messung nach | In der Anforderung steht schnell genug statt einer Zahl. Ohne festgelegte Schranke lässt sich weder prüfen noch belegen, dass das Gerät sie einhält. |
| Aktualisierung im Feld | Die Geschäftsführung und die Produktverantwortung, denn es geht um Kosten, Haftung und die Frage, wie lange ein Gerät gepflegt wird | Die Entwicklung baut den Aktualisierungsweg samt Rückfallebene und Prüfung der Herkunft eines Abbilds | Geräte gehen ohne Aktualisierungsweg in Serie. Sobald in einer mitgelieferten Bibliothek eine Lücke bekannt wird, gibt es dann nur noch die Wahl zwischen Rückruf und Weiterbetrieb. |
| Fehlersuche zwischen Hardware und Software | Beide Seiten gemeinsam, nach vereinbarter Reihenfolge und nicht nach Zuruf | Die Softwareseite grenzt mit Debugger und Protokoll ein, die Hardwareseite misst Spannungen, Signale und Zeitverläufe | Jeder unklare Fehler gilt zuerst als Softwarefehler, weil Software billiger zu ändern scheint. Ohne gemeinsame Messung dauert die Suche das Vielfache, und beide Seiten arbeiten aneinander vorbei. |
Auswahl des Bausteins und der Ausstattung
- Wer entscheidet
- Die Hardwareentwicklung zusammen mit dem Einkauf, weil Stückkosten und Verfügbarkeit daran hängen
- Wer setzt um
- Die Softwareseite beziffert vorher den Bedarf an Speicher, Rechenleistung und Schnittstellen und prüft die Vorauswahl
- Stolperfalle
- Der Bedarf der Software wird geschätzt, bevor die Anwendung entworfen ist. Wenn der Speicher später knapp wird, ist die Leiterplatte längst gefertigt, und die Software zahlt die Rechnung.
Basissystem: ohne Betriebssystem, Echtzeitsystem oder Linux
- Wer entscheidet
- Die Systemarchitektur gemeinsam mit der Produktverantwortung, weil daran Zertifizierung, Aufwand und Lizenzfragen hängen
- Wer setzt um
- Die eingebettete Entwicklung baut das Systemabbild und pflegt es über die Produktlebensdauer
- Stolperfalle
- Linux wird gewählt, weil es bequem ist, und niemand plant die Pflege ein. Ein eigenes Abbild ist kein einmaliger Aufwand, sondern eine Verpflichtung über die gesamte Laufzeit des Geräts.
Zeitschranken und Reaktionszeiten
- Wer entscheidet
- Die Produktverantwortung legt fest, was das Gerät in welcher Zeit tun muss, im regulierten Umfeld zusammen mit der Sicherheitsbetrachtung
- Wer setzt um
- Die Softwareseite entwirft Aufgabenprioritäten und weist die Einhaltung durch Messung nach
- Stolperfalle
- In der Anforderung steht schnell genug statt einer Zahl. Ohne festgelegte Schranke lässt sich weder prüfen noch belegen, dass das Gerät sie einhält.
Aktualisierung im Feld
- Wer entscheidet
- Die Geschäftsführung und die Produktverantwortung, denn es geht um Kosten, Haftung und die Frage, wie lange ein Gerät gepflegt wird
- Wer setzt um
- Die Entwicklung baut den Aktualisierungsweg samt Rückfallebene und Prüfung der Herkunft eines Abbilds
- Stolperfalle
- Geräte gehen ohne Aktualisierungsweg in Serie. Sobald in einer mitgelieferten Bibliothek eine Lücke bekannt wird, gibt es dann nur noch die Wahl zwischen Rückruf und Weiterbetrieb.
Fehlersuche zwischen Hardware und Software
- Wer entscheidet
- Beide Seiten gemeinsam, nach vereinbarter Reihenfolge und nicht nach Zuruf
- Wer setzt um
- Die Softwareseite grenzt mit Debugger und Protokoll ein, die Hardwareseite misst Spannungen, Signale und Zeitverläufe
- Stolperfalle
- Jeder unklare Fehler gilt zuerst als Softwarefehler, weil Software billiger zu ändern scheint. Ohne gemeinsame Messung dauert die Suche das Vielfache, und beide Seiten arbeiten aneinander vorbei.
Fünf Grenzen, gegen die diese Rolle täglich arbeitet
- 01 Speicher, der in Kilobyte gemessen wird und nicht wächst.
- 02 Zeitschranken, die eingehalten werden müssen, nicht meistens.
- 03 Ein Energievorrat, der über Jahre reichen soll.
- 04 Hardware, die sich während der Entwicklung noch ändert.
- 05 Eine Lebensdauer, in der niemand mehr ein Kabel ansteckt.
Was diese Rolle tatsächlich verantwortet
Der Zuschnitt schwankt zwischen Häusern stärker als in anderen Entwicklungsrollen. Die folgenden Punkte tauchen in fast jeder Stelle auf, unabhängig davon, ob das Gerät eine Steuerung, ein Messgerät oder ein Fahrzeugteil ist.
C dort beherrschen, wo es wehtut
Du arbeitest mit Zeigern, Speicherlayout und Bitoperationen und weißt, warum in vielen Projekten dynamische Speicherreservierung zur Laufzeit ausgeschlossen ist.
Das Basissystem wählen
Du unterscheidest, wann eine Anwendung ohne Betriebssystem auskommt, wann ein Echtzeitsystem die richtige Wahl ist und wann sich der Aufwand für ein eigenes eingebettetes Linux lohnt.
Zeitschranken einhalten
Du legst Prioritäten von Aufgaben fest, misst die tatsächliche Reaktionszeit statt sie zu schätzen und erkennst, wo eine Sperre die zeitkritische Aufgabe blockiert.
Zur Hardware sprechen
Du liest ein Datenblatt, bindest einen Baustein über die üblichen Busse an und findest mit Messgerät und Debugger heraus, ob ein Fehler in deiner Software oder in der Schaltung sitzt.
Ein eigenes Systemabbild bauen
Du stellst ein Linux für ein Gerät zusammen, kennst den Unterschied zwischen einem Entwicklungsstand und einem ausgelieferten Abbild und weißt, welche Lizenzpflichten mit der Weitergabe entstehen.
Aktualisierbarkeit einplanen
Du entwirfst einen Weg, ein ausgeliefertes Gerät sicher zu aktualisieren, mit Rückfallebene für den Fall, dass die Aktualisierung mitten im Vorgang abbricht.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was den Alltag ausmacht, und was Leute falsch erwarten
Der Alltag hat einen deutlich höheren Anteil an Werkzeugkette als andere Entwicklungsrollen. Übersetzen für eine fremde Prozessorarchitektur, Aufspielen über einen Programmieradapter, Fehlersuche mit einem Debugger direkt am Baustein, Protokolle über eine serielle Verbindung. Zwischen einer Codeänderung und dem Ergebnis auf dem Gerät liegen Schritte, die anderswo ein Tastendruck sind.
Falsch erwartet wird die Nähe zur Elektronik. Du liest Datenblätter und Schaltpläne und sprichst täglich mit der Hardwareentwicklung, aber du legst keine Schaltung aus. Umgekehrt unterschätzen viele, wie viel klassische Softwarearbeit dazugehört: Struktur, Testbarkeit, Fassungsverwaltung, Aufbauprozesse. Ein Gerät, dessen Software niemand automatisiert bauen kann, wird nach zwei Jahren zum Problem.
Der dritte Punkt ist Geduld. Ein Fehler, der einmal in zwei Tagen auftritt, ist in diesem Feld normal, und die Ursache liegt oft in einer Verzahnung aus Zeitverhalten, Speicherzugriff und Hardware. Wer solche Fehler mit Reproduktionsaufbauten und Messung angeht statt mit Vermutungen, ist in dieser Rolle deutlich schneller.
Der Weg hinein, und welche Nachweise zählen
Anders als in der Anwendungsentwicklung ist der akademische Weg hier häufig: Elektrotechnik, technische Informatik oder Mechatronik. Das liegt weniger an einer formalen Hürde als am Stoff, denn Signalverläufe, Abtastung und Grundlagen der Elektronik werden vorausgesetzt. Der zweite Weg führt über die Ausbildung und Berufserfahrung in einem Industriebetrieb, der dritte aus der Anwendungsentwicklung, meist über C und ein privates Interesse an Geräten.
Zertifikate spielen kaum eine Rolle, gefragt sind konkrete Kenntnisse: C, ein Echtzeitsystem, Erfahrung mit eingebettetem Linux und den üblichen Bussen zur Anbindung von Bausteinen. In der Fahrzeugtechnik kommt das Wissen um funktionale Sicherheit dazu, wo eine eigene Normenreihe vorgibt, wie Software für sicherheitsrelevante Funktionen entwickelt und nachgewiesen wird.
Für den Quereinstieg ist eigenes Gerät der beste Nachweis. Ein Mikrocontroller-Board kostet wenig, und wer darauf eine Aufgabe mit Zeitschranke gelöst, den Stromverbrauch gemessen und die Software über eine Fassungsverwaltung geführt hat, kann im Gespräch genau die Fragen beantworten, die gestellt werden.
Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden
Der erste Unterschied ist Messen statt Schätzen. Wer die Reaktionszeit einer Aufgabe mit einem Signal an einem freien Anschluss sichtbar macht und am Messgerät abliest, hat eine Zahl. Wer sie aus dem Code herleitet, hat eine Vermutung, und Vermutungen halten bis zur ersten Serie.
Der zweite ist der Umgang mit Speicher und Stapel. Wer die Auslastung des Stapels und die Speicheraufteilung im Blick behält, findet die Klasse von Fehlern, die sich sonst als sporadischer Neustart nach Tagen äußert. Diese Fehler gelten als schwer, sind aber vor allem eine Frage der Beobachtung.
Der dritte ist die Fähigkeit, mit der Hardwareseite auf Augenhöhe zu sprechen. Wer im Schaltplan die richtige Stelle zeigt und mit dem Kollegen gemeinsam misst, löst in einer Stunde, was sonst zwei Wochen als Ticket zwischen zwei Abteilungen hin und her geht.
Wohin die Rolle führt
Drei Vertiefungen sind üblich. Funktionale Sicherheit, wenn du in Fahrzeugtechnik, Medizintechnik oder Anlagenbau arbeitest und Software für Funktionen entwickelst, deren Ausfall Menschen gefährden kann. Gerätesicherheit im Sinne von Schutz vor Angriffen, die durch die europäischen Anforderungen an vernetzte Produkte deutlich an Gewicht gewonnen hat. Und die Systemarchitektur, also der Schnitt zwischen Hardware, Basissystem und Anwendung.
Eine vierte Richtung ist die Sprachwahl. In sicherheitsnahen und speichernahen Bereichen wird zunehmend geprüft, ob Rust neben C tragfähig ist, weil ein Teil der klassischen Speicherfehler dort nicht entstehen kann. Das ersetzt in der Breite nichts, ist aber ein Feld, in dem sich früh Kenntnis lohnt.
Zu den Zahlen weiter unten gehört eine Einschränkung: Es sind die allgemeinen Zellen für Softwareentwicklung, eine eigene Zeile für eingebettete Systeme gibt es nicht. Der Median darin sagt mehr aus als der Durchschnitt, weil einzelne Spitzenverdienste den Mittelwert anheben. Es sind Monatswerte für Vollzeit ohne Sonderzahlungen, und gerade in tarifgebundenen Industriebetrieben fällt das zusätzliche Weihnachts- und Urlaubsgeld spürbar aus.
Dazu passende Kurse
Für den Einstieg in diese Welt gibt es Kurse, in denen du dir dein eigenes Linux für ein Gerät zusammenbaust , dazu Echtzeitsysteme und die Treiberebene.
Die amtlichen Zahlen zu dieser Rolle
Eine eigene Zelle für eingebettete Systeme gibt es nicht, deshalb stehen hier zwei Anforderungsniveaus derselben Berufsgattung Softwareentwicklung, und das Niveau beschreibt den Zuschnitt der Stelle und nicht deine Berufserfahrung. Für diese Rolle ist die Zelle besonders unscharf, weil eingebettete Stellen überwiegend in Industriebetrieben sitzen, wo eine Tarifbindung im Metall- und Elektrobereich den Verdienst stärker bestimmt als die Berufsgattung, und weil Fahrzeugtechnik, Medizintechnik und Anlagenbau in derselben Zeile landen. Zieh deshalb den Median heran und nicht den Durchschnitt, den einzelne hohe Verdienste anheben.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
KldB 43414, Durchschnitt 6.313 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Brauche ich ein Studium für diese Rolle?
C oder C++, und was ist mit Rust?
Echtzeitsystem oder eingebettetes Linux, was lerne ich?
Wie realistisch ist der Quereinstieg aus der Anwendungsentwicklung?
Passt thematisch dazu
Bevor du eine zweite Sprache anfängst, lohnt der nüchterne Blick darauf, wo Rust auf Mikrocontrollern heute steht .
Weil Aktualisierbarkeit inzwischen rechtlich unterlegt ist, gehört zur Planung die Frage, welche Pflichten für vernetzte Produkte gelten .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Grenzen lernt man am Gerät, nicht am Schaubild
Bei cmt baust du ein eigenes Systemabbild, entwickelst gegen ein Echtzeitsystem und gehst bis auf die Treiberebene hinunter, statt über eingebettete Entwicklung zu lesen.