Embedded Engineering
vom Eigentümer gesetzt- C/C++ auf produktionsreifem Niveau, insbesondere modernes C++ und Embedded C.
- MCU/SoC-Architekturen: ARM Cortex-M/A, ggf. RISC-V, Speicherarchitektur, MMU/MPU, Interrupts, DMA.
- Bare Metal und RTOS, z. B. FreeRTOS, Zephyr, ThreadX; bei größeren Systemen Embedded Linux.
- Bootloader, Firmware Update, OTA, Secure Boot.
- Device Driver, HAL/BSP, Register-Level-Debugging.
- Echtzeitverhalten: Scheduling, Prioritäten, Interrupt-Latenzen, Timing, Race Conditions, Deadlocks.
- Speicher- und Ressourcenmanagement unter harten Constraints.
- Debugging mit JTAG/SWD, Logic Analyzer, Oscilloscope und Trace.
Ein Lead schreibt hier keinen Treiber. Er erkennt, ob ein Timing-Problem ein Fehler oder ein Architekturschaden ist — und ob die Antwort „wir optimieren das später“ diesmal trägt.
Tracing — und warum es hier im Zentrum steht
vom Eigentümer gesetzt- Ablaufverfolgung auf dem Gerät: Instruction- und Datentrace über die Trace-Schnittstellen des Kerns, Ereignisausgabe über SWO, Trace-Puffer im RAM, wenn keine Leitung nach draussen geht.
- Ereignisaufzeichnung im Betriebssystem: Taskwechsel, Interrupts, Blockaden, Prioritätsumkehr — der einzige Weg, ein Zeitproblem zu sehen statt zu vermuten.
- Zeitstempel und Uhrenabgleich über mehrere Steuergeräte hinweg. Ohne gemeinsame Zeit ist eine verteilte Spur eine Sammlung von Vermutungen.
- Aufzeichnung im Feld: was mitgeschrieben wird, wie lange es liegen bleibt, wer es lesen darf, und was davon personenbezogen ist.
- Auswertung: aus einer Spur wird erst dann ein Befund, wenn jemand sie gegen eine Erwartung hält.
- Rückverfolgbarkeit von der Anforderung über den Code bis zum Testfall und zum Nachweis — dieselbe Frage auf der Prozessebene.
Zwei Dinge heissen hier Tracing, und sie beantworten dieselbe Frage: **was ist wirklich passiert.** Die Spur auf dem Gerät beantwortet sie für eine Millisekunde, die Rückverfolgbarkeit für ein Vorhaben. Wer eines von beiden nicht hat, argumentiert im Zweifelsfall mit seiner Meinung — vor dem Kunden, vor der Abnahme, vor Gericht. Deshalb steht Tracing auf dieser Seite nicht bei den Werkzeugen, sondern bei der Führung: es ist die Technik gewordene Form des Grundsatzes, dass eine Entscheidung belegt sein muss.
Hardware- und Software-Systemverständnis
Vorschlag, zu bestätigen- Schaltplan und Datenblatt lesen können — und wissen, wann man dem Datenblatt nicht glaubt.
- Bussysteme: SPI, I²C, UART, CAN und CAN FD, LIN, Automotive Ethernet; off-highway zusätzlich J1939 und ISOBUS.
- Signalintegrität, EMV und die Fehlerbilder, die daraus im Feld werden.
- Energiebudget, Spannungsversorgung, Schlaf- und Weckpfade.
- Sensorik und Aktorik: Kennlinien, Kalibrierung, Ausfallverhalten.
- Fertigung und Test: was am Bandende geprüft wird, und was danach nie wieder erreichbar ist.
Der Punkt, an dem Software-Entscheidungen Hardware-Kosten erzeugen und umgekehrt. Wer beide Seiten nicht liest, verhandelt blind.
Architektur und Plattform
Vorschlag, zu bestätigen- Der Schnitt: was ein Baustein ist, wo die Grenze liegt, was über die Grenze darf.
- Variantenführung: eine Plattform über Produktlinien und Märkte, ohne dass jede Variante ein eigenes Produkt wird.
- Klassische und dienstorientierte Architektur nebeneinander, samt Übergang.
- Middleware und Kommunikationsmuster, und was sie an Determinismus kosten.
- Migration eines Bestands, der weiterläuft, während er überführt wird.
Hier entscheidet sich, was eine Änderung in fünf Jahren kostet. Das ist keine Frage der Technik, sondern der Verantwortung.
Sicherheit und Nachweisführung
Vorschlag, zu bestätigen- Funktionale Sicherheit in der Normfamilie, die für die Domäne gilt — und das Wissen, welche das ist.
- Cybersicherheit über den Lebenszyklus, samt Melde- und Aktualisierungspflichten.
- Nachweisführung: wer liefert die Nachweise, wer pflegt sie, und was passiert bei einem Lieferantenwechsel.
- Werkzeugqualifizierung — auch für alles, was KI im Ablauf übernimmt.
- Rückverfolgbarkeit von der Anforderung bis zum Testfall.
Der teuerste Teil ist nie der Code, sondern der Nachweis. Wer ihn zu spät plant, plant den Termin zweimal.
Werkzeugkette und Prozess
Vorschlag, zu bestätigen- Build, Konfiguration, Generierung — und wem die Konfiguration gehört.
- Fortlaufende Integration für Geräte: Simulation, Hardware im Regal, Testautomatisierung.
- Test auf allen Ebenen, von der Einheit bis zum Fahrzeug oder der Maschine.
- Reifegradmodelle und was sie im Alltag wirklich verlangen.
- Bestandsanalyse mit KI dort, wo Artefakte maschinenlesbar sind.
Die Kette ist die längste Bindung im ganzen Vorhaben — länger als jeder Lieferantenvertrag.
Lieferanten und Make-or-buy
Vorschlag, zu bestätigen- Wer liefert welche Schicht, und wo verläuft die Grenze im eigenen Vorhaben.
- Lizenz-, Liefer- und Betriebsmodelle, und was sie über die Laufzeit binden.
- Was ein Anbieterwechsel kostet, bevor man ihn braucht.
- Quelloffene Bausteine: wo sie tragen, wo sie es nicht tun, und wer sie verantwortet.
Die Entscheidung, für die es ein Instrument gibt — und eine Akte, die sie überlebt.
Führung selbst
Vorschlag, zu bestätigen- Entscheidungsrecht: wer entscheidet, wer zustimmen muss, wer gehört wird.
- Eine Organisation, die zum Schnitt der Architektur passt — nicht umgekehrt.
- Roadmap gegen Abhängigkeiten, nicht gegen Wunschtermine.
- Eskalation, bevor sie nötig ist, und die Fähigkeit, ein Nein zu begründen.
- Wissen halten: was passiert, wenn die zwei Leute gehen, die es wirklich verstehen.
Der Teil, den man nicht delegieren kann, weil er die Delegation selbst regelt.
Diese Karte ist bewusst grösser als eine Person. Genau das ist ihr Zweck: sie zeigt, wo Führung Fachleute braucht und wo sie selbst entscheiden muss. Wer behauptet, das Ganze allein abzudecken, hat es nicht gelesen.