Engineering-Team und physische Delivery-Kette

Chronologie: 2. September 2026 · zweite Veranstaltung. Primärquelle: vollständiges Transkript. Zusammenhang: Fortsetzung von Vorlesung 01 – von der Definition eingebetteter Systeme zu Menschen, Bauteilen und physischer Lieferung.

1. Vom Software-Stack zum physischen Produkt

In der vorigen Veranstaltung wurde Embedded-Software als Software auf festgelegter Hardware definiert. Dieses Konzept wird jetzt zu einer vollständigen Engineering-Kette erweitert.

Anwendung
          ↓
Middleware / Betriebssystem / Dienste
          ↓
HAL / Treiber
          ↓
MCU / SoC
          ↓
PHY / Transceiver / Versorgung / Schutz
          ↓
Leiterplatte + Mechanik + Steckverbinder
          ↓
physische Umgebung

In einem realen Produkt ist das Hardwaredesign nicht mit der Wahl eines MCU oder SoC abgeschlossen. Erforderlich sind weiterhin Versorgungsspannungen, Reset- und Taktschaltungen, möglicherweise Speicher, Schutzmaßnahmen, physische Schnittstellen, Steckverbinder, Leiterplatte, Wärmemanagement, Gehäuse, Fertigung und Integration.

2. Hardware Engineering: Das Zielsystem ist nur der Anfang

Die Vorlesung zerlegt den Hardware-Arbeitsbereich in Schritte von der Auswahl der Zielplattform bis zur Gestaltung der Umgebung, die einen realen Einsatz ermöglicht.

2.1. Mindestfragen an den Entwurf

• Welcher MCU, SoC, DSP oder FPGA passt hinsichtlich Rechenleistung, Speicher, Peripherie und Produktlebenszyklus?
• Wie wird das System versorgt?
• Wie startet es und wie erfolgt der Reset?
• Welche Taktquellen werden benötigt?
• Welche externen Schnittstellen müssen realisiert werden?
• Welcher elektrische Schutz ist erforderlich?
• Welche EMV- und ESD-Anforderungen ergeben sich aus der Betriebsumgebung?
• Wie werden Leiterplatte und Bauteile gekühlt und mechanisch befestigt?
• Sind die Bauteile in der geplanten Stückzahl verfügbar?

2.2. Logische und physische Schicht einer Schnittstelle

Ein MCU kann eine digitale Peripheriefunktion anbieten. Das bedeutet noch nicht, dass seine Pins direkt an ein Kabel oder Netzwerk angeschlossen werden dürfen. Viele Schnittstellen benötigen einen Transceiver oder PHY für die physische Signalübertragung.

Als Beispiel dient CAN:

CAN-Controller im MCU
          ↓
TX/RX-Logik
          ↓
CAN-Transceiver
          ↓
differenzielles physisches Signal
          ↓
CAN_H / CAN_L-Bus

Redaktionelle Präzisierung 01 — CAN und galvanische Trennung

Die mündliche Aussage „CAN ist eine galvanisch getrennte Schnittstelle“ ist zu pauschal. Ein CAN-Transceiver wandelt digitale Controllersignale in die physische, gewöhnlich differenzielle Signalform des Übertragungsmediums um. Galvanische Trennung ist eine zusätzliche Entwurfsentscheidung, wenn das System sie benötigt. CAN garantiert diese Trennung nicht von sich aus.

Offizielle Terminologiereferenz von CiA: https://www.can-cia.org/fileadmin/cia/documents/brochures/can_dictionary_v13_2026.pdf

3. ESD, EMV und Abschirmung sind keine Synonyme

Die Vorlesung betont zu Recht, dass die physische Robustheit nicht auf „später“ verschoben werden darf. Die Begriffe sind aber zu trennen:

Metallabschirmungen, TVS-Dioden, Gleichtaktdrosseln, galvanische Trennung, Filter, Erdung und Leiterplattenlayout behandeln unterschiedliche Aspekte des Problems.

4. Drei grundlegende Engineering-Arbeitsbereiche

Die Vorlesung führt das Kernteam eingebetteter Systeme auf drei voneinander abhängige Disziplinen zurück:

SYSTEM / PRODUKT
          ↓
Firmware + Hardware + Mechanik
          ↓
Integration

Firmware / Software

Von der Anwendungslogik über hardwarenahe Treiber, Boot und Updates bis zu Diagnose, Kommunikation, Zeitverhalten und Tests.

Hardware

Schaltpläne, Bauteilauswahl, Leiterplattenlayout, Stromversorgung, Schnittstellen, Schutz, Inbetriebnahme des Prototyps und Fertigungsbegleitung.

Mechanik

Gehäuse, Befestigung, Schnittstellen, Wärmepfade, Zugänglichkeit, Fertigbarkeit und Schutz vor der physischen Umgebung.

Diese Arbeitsbereiche können nicht ehrlich als drei voneinander unabhängige Teams betrachtet werden, deren Ergebnisse erst „am letzten Tag“ integriert werden. Der mechanische Bauraum beeinflusst die Leiterplatte; die Leiterplatte bestimmt Steckerposition und Firmware-Inbetriebnahme; Leistungs- und Temperaturgrenzen beschränken Softwarebetriebsarten; Testbarkeit erfordert Entscheidungen aller drei Gruppen.

5. Architekt / Systemingenieur: Entscheidungen vor der Integration verbinden

Der Architekt ist in dieser Vorlesung nicht der „Chef der Ingenieure“, sondern sichert die innere Schlüssigkeit der Lösung:

• überträgt Produktbedürfnisse in eine Systemstruktur;
• koordiniert Schnittstellen zwischen Fachbereichen;
• ermittelt technische Zielkonflikte;
• verbindet technische Entscheidungen mit Normen und Randbedingungen;
• unterstützt die Festlegung der Teamzusammensetzung;
• verhindert, dass die Optimierung einer Disziplin das Gesamtsystem beschädigt.

In der frühen Pre-Sales-Phase hilft diese Rolle außerdem zu bestimmen, welche Kompetenzen dem Kunden zu zeigen sind und ob das vorgeschlagene Vorhaben mit dem Team tatsächlich umgesetzt werden kann.

6. Servant Manager / Servant Leader

Die Managementfunktion wird als Dienst am Team, nicht als Befehlskette von oben verstanden.

In der Praxis bedeutet das:

• Hindernisse zwischen Hardware und Mechanik beseitigen;
• technische Probleme mit dem Kunden abstimmen;
• Rechtsfragen, Einkauf und Eskalationen organisieren;
• externe Spezialisten finden;
• Engineering-Zeit vor unnötiger Organisationslast schützen;
• Entscheidungen herbeiführen, für die Ingenieuren Befugnisse oder der vollständige Kontext fehlen.

Management und Architektur arbeiten somit eng zusammen, lösen jedoch verschiedene Aufgaben: Die Architektur sichert technische Kohärenz, das Management organisiert Abläufe und ermöglicht die termingerechte Lieferung.

7. Embedded Engineering braucht eine Lieferkette

Anders als rein softwarebasierte Auslieferungen sind Embedded-Projekte an die physische Welt gebunden. Daraus leitet die Vorlesung eine zusätzliche Kette ab:

Entwurf
          ↓
Bauteilbeschaffung
          ↓
Leiterplatten- und Mechanikfertigung
          ↓
Montage
          ↓
Transport / Zoll
          ↓
Inbetriebnahme
          ↓
Nacharbeit / nächste Iteration

Der Engineering-Plan hängt folglich nicht nur von der Entwicklungsgeschwindigkeit ab, sondern auch von Bauteilverfügbarkeit, Lieferzeiten, Fertigungskapazitäten, Logistik und der Möglichkeit weiterer Iterationen.

Redaktionelle Präzisierung 02 — Hersteller- und Länderrisiken

Die Vorlesung enthält pointierte Beispiele mit bestimmten Herstellern und Ländern. In diesen Notizen werden sie zu überprüfbaren Lieferkettenrisiken verallgemeinert: Bauteillebenszyklus, NRND-/EOL-Status, langfristige Verfügbarkeit, Zweitquellenstrategie, geopolitische oder exportrechtliche Einschränkungen, Herstellerbindung, Preisschwankungen, Supportqualität und Herkunftsnachweis. Diese Kriterien sind ingenieurtechnisch nützlicher als pauschale Aussagen über nationale Herkunft von Marken.

8. Kostenoptimierung in der Serienfertigung

Bei eingebetteten Produkten kann sich eine kleine Differenz in den Stückkosten der Materialliste auf Tausende oder Millionen Geräte multiplizieren. Deshalb gibt es keine universell richtige Entscheidung zwischen einem teuren hochintegrierten SoC und einem einfacheren MCU mit externen PHY-Bausteinen.

Ein sachgerechter Vergleich berücksichtigt:

Stückkosten der Materialliste + Leiterplattenfläche + Montageaufwand + Prüfkosten + Entwicklungsaufwand + Beschaffungsrisiko + Auswirkungen auf die Zertifizierung + Lebenszykluskosten

Ein lokal günstigeres Bauteil kann die Fertigungs- oder Supportkosten erhöhen. Umgekehrt kann ein teurerer Schaltkreis die gesamte Materialliste, Leiterplattenfläche und Montagekosten reduzieren.

9. Praktische Organisation studentischer Teams

Am Ende geht die Veranstaltung von der breiten Theorie zur Gruppenarbeit über. Die Studierenden organisieren sich in kleinen Teams. Dies ist nicht nur Verwaltungsarbeit: Jedes Team modelliert später ein Unternehmen, und die Rollen verändern sich vom geschäftlichen Erstkontakt und Pre-Sales hin zu Engineering und Delivery.

Die Ausgangsregel lautet: Ein Team soll klein genug für wirksame Koordination, aber vollständig genug für sinnvolle Arbeitsteilung sein.

10. Kontrollfragen

1. Weshalb ist ein MCU-Peripheriecontroller noch keine unmittelbar nutzbare physische Schnittstelle?
2. Welche Aufgabe erfüllt ein CAN-Transceiver?
3. Warum darf CAN nicht mit galvanischer Trennung gleichgesetzt werden?
4. Wodurch unterscheidet sich ESD von EMV?
5. Welche drei Arbeitsbereiche bilden das Kernteam für eingebettete Systeme in diesem Kurs?
6. Wie unterscheiden sich die Aufgaben von Architekt und Manager?
7. Warum können Beschaffung und Logistik Teil des kritischen Projektpfades werden?
8. Weshalb führt der niedrigste Materiallistenpreis nicht immer zu den niedrigsten Systemkosten?

11. Einprägsames Schema

KUNDEN- / PRODUKTBEDARF
          ↓
Systemarchitekt
          ↓
Firmware + Hardware + Mechanik
          ↓
Integration
          ↓
Prüfung / Fertigung
          ↓
Beschaffung / Logistik
          ↓
Lieferung; ein Servant Manager beseitigt fachübergreifende Hindernisse.

12. Übergang zum 8. September 2026

Nun existiert ein Team, das potenziell etwas entwickeln kann. Die nächste Frage lautet: Woher kommt die Arbeit? Der Kurs geht deshalb zur Entwicklung eines Dienstleistungsgeschäfts über: Wie wird ein unbekanntes Unternehmen sichtbar, wie entsteht Vertrauen und wie wird aus einem Kontakt ein Lead?

Geprüfte Referenzen

• AUTOSAR Classic Platform — Schichtenarchitektur: https://www.autosar.org/standards/classic-platform
• CAN in Automation, CAN Dictionary 2026: https://www.can-cia.org/fileadmin/cia/documents/brochures/can_dictionary_v13_2026.pdf