Embedded-Systeme, Risiken und zwei IT-Geschäftsmodelle

Chronologie: 1. September 2026 · Auftakt des Kurses. Primärquelle: vollständiges automatisches Transkript. Status: aus der Originalaufzeichnung rekonstruiert und am 28. September 2026 eingefroren.

Warum es diesen Kurs gibt

Dieser Kurs beschäftigt sich weniger mit der Syntax von Programmiersprachen oder der Algorithmentheorie als mit dem gesamten ingenieurtechnischen und geschäftlichen Lebenszyklus eines Embedded-Projekts. Das in der Vorlesung formulierte Ziel ist, den Weg von einer Idee bis zu ersten Einnahmen, über die alltägliche Umsetzung bis zum Abschluss des Projekts oder Geschäfts nachzuvollziehen.

Das zentrale Modell des Kurses:

Idee
          ↓
Bedarfsdefinition
          ↓
Kunde / Markt / Finanzierung
          ↓
Team + Prozesse + Arbeitsergebnisse
          ↓
Entwicklung eines eingebetteten Systems
          ↓
Verifikation / Validierung / Integration
          ↓
Lieferung / Unterstützung / Abschluss

Die Leistungsbewertung stützt sich auf Teamprojekte und Demonstrationen, nicht nur auf die Wiedergabe von Theorie. Die Studierenden bilden ihre Teams selbst. Deren Rollen und Liefergegenstände entwickeln sich im Kursverlauf weiter.

1. Was „Embedded“ in diesem Kurs bedeutet

Das praktische Kennzeichen eingebetteter Software ist ihre Entwicklung für eine bestimmte Hardwareumgebung als Bestandteil eines physischen Produkts oder Systems. Neben Programmfunktionen zählen deshalb Speicher, Rechenressourcen, Energieverbrauch, Peripherie, Schnittstellen, Zeitverhalten und die physischen Folgen eines Fehlers.

Die Vorlesung stellt zwei häufige Systemtopologien gegenüber.

1.1. Kompaktes System: Anwendung → HAL → Hardware

Bei vergleichsweise kleinen MCU-Lösungen kann die Anwendungslogik unmittelbar auf der HAL- oder Treiberschicht des Herstellers laufen.

Anwendung / Geschäftslogik
          ↓
HAL + hardwarenahe Treiber
          ↓
MCU / DSP / SoC / anderes Zielsystem

Vorteile sind ein kleinerer Software-Stack, kontrollierbarer Ressourcenverbrauch und Vorhersagbarkeit. Dem stehen eine stärkere Bindung an die Zielhardware und der Bedarf gegenüber, mehr Infrastruktur selbst zu realisieren.

1.2. Mehrschichtiges System: Anwendung → Middleware/OS → HAL → Hardware

Bei größeren Systemen kann die Wiederverwendung vorhandener Netzwerk-, Dateisystem-, Diagnose- und weiterer Dienste zweckmäßig sein.

Anwendung
          ↓
Middleware / Dienste
          ↓
Betriebssystem / Laufzeitumgebung
          ↓
HAL / Treiber
          ↓
Hardware

Ein solcher Aufbau macht das System nicht automatisch „besser“. Es handelt sich um einen anderen Kompromiss: mehr Wiederverwendung und Flexibilität, zugleich aber einen komplexeren Software-Stack, größere Integrations-, Aktualisierungs- und Angriffsflächen sowie zusätzliche Abhängigkeiten.

2. Warum Embedded Engineering mehr als „nur Software“ ist

Code wirkt letztlich auf die physische Welt: Er erzeugt elektrische Signale, steuert Aktoren und überträgt Daten über physische Schnittstellen. Ein Fehler zeigt sich daher nicht bloß als falscher Bildschirmtext, sondern möglicherweise als:

• falscher Steuerbefehl für einen Aktor;
• Beschädigung der Hardware;
• unsicherer Betriebszustand einer Anlage;
• kostspielige Nacharbeit an einer bereits gefertigten Charge;
• Nichteinhaltung von Safety- oder Security-Anforderungen;
• Verlust des Kundenvertrauens.

Daraus folgt die zentrale These: Hochwertige Embedded-Entwicklung ist untrennbar mit Testing, Systems Engineering und Risikomanagement verbunden.

3. Funktionale Sicherheit und Cybersicherheit sind unterschiedliche Risikodimensionen

Die Vorlesung stellt zwei Ursachen unerwünschten Systemverhaltens vor:

Diese Disziplinen beeinflussen einander, ersetzen sich aber nicht gegenseitig.

Redaktionelle Präzisierung 01 — ISO 26262

Die mündliche Formulierung in der Vorlesung war weiter gefasst als der tatsächliche Geltungsbereich des Standards. ISO 26262 behandelt funktionale Sicherheit elektrischer und elektronischer Systeme in serienmäßig hergestellten Straßenfahrzeugen. Für Industrie, Luft- und Raumfahrt, Schienenverkehr, Medizin und andere Domänen gelten jeweils eigene einschlägige Normen. ISO 26262 ist keine universelle Grundlage aller sicherheitskritischen Branchen.

Offizielle Quelle: https://www.iso.org/standard/68385.html

Redaktionelle Präzisierung 02 — QM und ASIL

Im Automotive-Bereich verwendet ISO 26262 QM und die Stufen ASIL A–D. Die ASIL-Einstufung aus HARA entsteht nicht durch eine einfache Multiplikation „Wahrscheinlichkeit × Konsequenz“. Vielmehr werden Severity, Exposure und Controllability kombiniert. Die detaillierte Methode ist in ISO 26262-3 nachzulesen.

Für Cybersecurity Engineering über den Lebenszyklus elektrischer und elektronischer Fahrzeugsysteme ist ISO/SAE 21434 die einschlägige Referenz: https://www.iso.org/standard/70918.html.

4. Idee + Ressourcen = die Chance auf eine Technologie

Die Vorlesung betrachtet das Geschäft anhand zweier notwendiger Bestandteile:

IDEE + RESSOURCEN → TECHNOLOGIE → MARKTWERT

Eine Idee allein garantiert noch kein Produkt. Erforderlich sind Menschen, Zeit, Geld, Ausrüstung, Fertigung, Marketing, juristische und IP-Arbeit, Tests sowie Marktzugang. Geld dient als praktische allgemeine Darstellung von Ressourcen, ist aber nicht die einzige Ressource.

5. Zwei Geschäftsmodelle als erste grundlegende Weichenstellung

5.1. Produktunternehmen

Ein Team entwickelt eine eigene Produktidee und übernimmt das entsprechende Marktrisiko: Was wird für wen gebaut? Wie schützt man geistiges Eigentum? Wie skaliert man die Fertigung und organisiert den Support?

5.2. Dienstleistungsunternehmen

Ein Kunde hat eine geschäftliche oder technische Anforderung und nimmt dafür externe Ingenieurkapazitäten in Anspruch. Ein Dienstleister stellt Menschen, Prozesse, Infrastruktur, Domänenwissen und unter Umständen Hardware- oder Fertigungskapazitäten bereit und wird nach einem vereinbarten Geschäftsmodell vergütet.

Der Kurs beginnt bewusst mit dem Dienstleistungsmodell. So lassen sich zunächst reale Abläufe – Lead-Generierung, Pre-Sales, Angebot, Personaleinsatz und Lieferung – kennenlernen, bevor das Produktgeschäft betrachtet wird.

6. Geistiges Eigentum und NDAs: Was vor Arbeitsbeginn klar sein muss

Die Vorlesung betont zwei praktische Grenzen von Dienstleistungsaufträgen: Geheimhaltung und Rechte an Arbeitsergebnissen.

Redaktionelle Präzisierung 03 — NDA

Die korrekte Langform lautet Non-Disclosure Agreement, nicht „Not Discussion Agreement“. Eine Geheimhaltungsvereinbarung regelt Pflichten zur Nichtweitergabe vertraulicher Informationen. Die konkreten Grenzen ergeben sich aus ihrem Wortlaut und dem anwendbaren Recht.

Redaktionelle Präzisierung 04 — Rechte am geistigen Eigentum

Die Aussage, „bei einem Dienstleister gehört IP immer dem Kunden“, beschreibt eine verbreitete vertragliche Gestaltung, aber keine universelle Rechtsregel. Eigentum, Rechtsübertragung, Lizenzen, bestehendes Background IP, neu entstandenes Foreground IP und Wiederverwendungsrechte hängen von Vertrag und Recht ab. Maßgeblich sind MSA, SOW und IP-Klauseln, nicht allein die Bezeichnung „Outsourcing“.

7. Berufliche Perspektive des Dozenten

Die Vorlesung vermittelt eine persönliche Empfehlung: Zunächst Erfahrung in echten Dienstleistungsprojekten sammeln, gute und schlechte Prozesse beobachten und den Umgang mit Kunden und Risiken lernen. Mit einer tragfähigen Idee und hinreichenden Ressourcen kann anschließend die Entwicklung eines eigenen Produkts folgen.

Dies ist ein Karrierehinweis des Dozenten, kein einzig zulässiger oder allgemein vorgeschriebener Berufsweg.

8. Kontrollfragen

1. Was unterscheidet Embedded-Software von beliebigen Desktop- oder Webanwendungen?
2. Wann ist ein Bare-Metal-/HAL-Ansatz gegenüber einem Betriebssystem-Stack vorzuziehen?
3. Warum kann ein Softwarefehler in einem eingebetteten System zum Hardware- oder Sicherheitsproblem werden?
4. Wie unterscheiden sich funktionale Sicherheit und Cybersicherheit?
5. Warum stellt eine Idee allein noch keine Technologie dar?
6. Was verkauft ein Produktunternehmen, und was ein Dienstleistungsunternehmen?
7. Warum lässt sich IP-Eigentum nicht allein aus dem Begriff „Outsourcing“ ableiten?
8. Welche Verpflichtungen kann eine Geheimhaltungsvereinbarung einem Ingenieur auferlegen?

9. Kurze Übung

Beschreiben Sie eine Embedded-System-Idee unter zwei Geschäftsbedingungen:

• Produkt: Sie finanzieren das Produkt selbst und verkaufen es eigenständig.
• Dienstleistung: Ein Kunde bringt denselben Bedarf mit; Sie verkaufen die dafür notwendigen Ingenieurleistungen.

Ermitteln Sie für beide Modelle den Eigentümer der Idee, den Risikoträger, die Finanzierungsquelle, das erwartete Ergebnis und die wesentlichen Fragen zu IP und NDA.

10. Übergang zum 2. September 2026

Nachdem Embedded Systems und die beiden Geschäftsmodelle definiert sind, stellt sich logisch die nächste Frage: Wer überführt die Idee in ein physisches Produkt? Die nächste Veranstaltung betrachtet dafür das Engineering-Team: Firmware, Hardware, Mechanik, Architektur, Management und physische Lieferkette.

Geprüfte Referenzen

• ISO 26262-3:2018, Konzeptphase / HARA: https://www.iso.org/standard/68385.html
• ISO/SAE 21434:2021, Road Vehicles — Cybersecurity Engineering: https://www.iso.org/standard/70918.html
• AUTOSAR Classic Platform: https://www.autosar.org/standards/classic-platform