In Gesprächen über Embedded-Projekte prallen zwei Sprachen aufeinander: die der Entwicklung und die von Einkauf, Qualitätssicherung und Geschäftsführung. Dieses Glossar erklärt 44 Begriffe, die in industriellen Embedded-Vorhaben regelmäßig für Missverständnisse sorgen — kurz, fachlich präzise und ohne Marketing-Umweg.
Die Begriffe sind in fünf Themenfeldern geordnet: Architektur und Plattform, Test und Absicherung, Sicherheit und Normen, Wartung und Lebenszyklus sowie Zusammenarbeitsmodelle. Wo eine Aussage auf einer Norm oder Verordnung beruht, ist die Quelle genannt.
Das Glossar erklärt Begriffe. Es ist keine Norm- oder Rechtsauslegung: welche Anforderungen für ein konkretes Produkt gelten, entscheidet sich immer am Produkt selbst.
Die fünf Themenfelder im Überblick
Architektur und Plattform
14 Begriffe
Wie Embedded-Software und ihre Plattformen geschnitten werden, damit sie über Gerätevarianten und Produktgenerationen tragen.
Test und Absicherung
8 Begriffe
Wie aus Software nachweisbar geprüfte Software wird — Werkzeugkette, Automatisierung, Abdeckung.
Sicherheit, Normen und Regulatorik
11 Begriffe
Funktionale Sicherheit, industrielle Cybersecurity und die regulatorischen Pflichten.
Wartung und Lebenszyklus
7 Begriffe
Was nach dem Release beginnt: Pflege, Varianten, Altsysteme, Abkündigung.
Zusammenarbeitsmodelle
4 Begriffe
Wie die Zusammenarbeit mit einem Entwicklungspartner organisiert wird.
Architektur und Plattform
| Begriff | Definition |
|---|---|
| Embedded-System | Rechnersystem, das fest in ein technisches Produkt integriert ist und dort eine definierte Funktion übernimmt. Anders als ein Universalrechner ist es auf seine Aufgabe zugeschnitten: begrenzte Rechen- und Speicherressourcen, feste Hardware, häufig Echtzeit- und Sicherheitsanforderungen. |
| Firmware | Software, die dauerhaft auf einem Embedded-Gerät liegt und unmittelbar auf die Hardware zugreift. Sie startet das Gerät, steuert die Peripherie und bildet die Basis, auf der alle höheren Funktionen aufsetzen. „Firmware“ beschreibt damit eine Schicht, „Embedded-Software“ die gesamte Software des Geräts. |
| Echtzeitbetriebssystem (RTOS) | Betriebssystem, das Aufgaben nicht nur schnell, sondern innerhalb garantierter Zeitgrenzen abarbeitet. Entscheidend ist die Vorhersagbarkeit: eine Reaktion muss spätestens zu einem festgelegten Zeitpunkt erfolgen. Ein System, das im Mittel schnell ist, aber Ausreißer zulässt, ist nicht echtzeitfähig. |
| Hardware-Abstraktionsschicht (HAL) | Zwischenschicht, die Hardwarezugriffe hinter einer einheitlichen Schnittstelle kapselt. Die HAL ist der zentrale Hebel, um dieselbe Anwendungssoftware auf mehreren Hardwarevarianten und auf Nachfolgegenerationen zu betreiben, ohne die Anwendung anzufassen. |
| Board Support Package (BSP) | Sammlung aus Bootloader, Treibern und Konfiguration, die ein Betriebssystem auf einer konkreten Hardwareplattform lauffähig macht. Beim Wechsel auf neue Hardware ist das BSP typischerweise der erste Aufwandsblock. |
| Produktlinie und Variante | Eine Produktlinie ist eine Familie verwandter Geräte mit gemeinsamer Softwarebasis; eine Variante ist eine konkrete Ausprägung daraus — etwa eine Geräteklasse, ein Ländermodell oder eine Ausstattungsstufe. Werden Varianten aus einer gemeinsamen Basis abgeleitet statt kopiert, bleibt der Pflegeaufwand beherrschbar. Ausführlich: Produktlinien Software Engineering |
| Produktlinien Software Engineering (PLSE) | Methodisches Vorgehen, die Gemeinsamkeiten und Unterschiede einer Produktfamilie ausdrücklich zu modellieren und Varianten daraus abzuleiten. Ziel ist, dass jede zusätzliche Variante den Entwicklungs- und Nachweisaufwand nicht im gleichen Maß erhöht. Ausführlich: Produktlinien Software Engineering |
| Plattformstrategie | Die Festlegung, welche gemeinsame technische Basis aufgebaut wird und in welchen Schritten. Unterschieden werden vier Plattformarten: die interne Entwicklerplattform (Workflows und Tooling), die Infrastrukturplattform (hardware- und betriebssystemunabhängige Firmwareumgebung), die Produktplattform (Basis für die Varianten) und die Produkttestplattform (automatisierte Validierung aller Varianten). Ausführlich: Plattformstrategie – Roadmap zur Embedded Plattform |
| Feature-Modell | Modell, das die Merkmale eines Systems und ihre Beziehungen beschreibt, um Gemeinsamkeiten und Unterschiede zwischen Produktvarianten herauszuarbeiten. Übliche Beziehungsarten sind mandatory, optional, alternative, or, requires und excludes. Es ist die gängigste Technik im Produktlinien Software Engineering. |
| Domänenanalyse und Anforderungsanalyse | Zwei zu trennende Schritte: die Domänenanalyse beschreibt Entitäten und Prozesse eines Fachgebiets unabhängig von einer konkreten Lösung und liefert ein Domänenmodell; die Anforderungsanalyse beschreibt, was ein konkretes Produkt in dieser Domäne leisten soll. Werden beide vermischt, dominieren technische Begriffe die Softwarestruktur und die Fachlogik muss später aus dem Code rekonstruiert werden. |
| Embedded Platform Engineering | Aufbau und Betrieb der technischen Basis, auf der mehrere Produktgenerationen entstehen — Build-Umgebung, Bibliotheken, Dienste, Testinfrastruktur. Ausführlich: Embedded Platform Engineering |
| Package Principles | Regelsatz dafür, wie Software in Module und Abhängigkeiten geschnitten wird, damit Änderungen lokal bleiben und Zyklen vermieden werden. Ausführlich: Meilensteine der SW-Technik – Uncle Bobs Package Principles |
| Modellgetriebene Entwicklung (MDD) | Entwicklungsansatz, bei dem Software aus formalen Modellen erzeugt wird statt Zeile für Zeile geschrieben. Wiederkehrende Implementierungsaufwände sinken, und Änderungen erfolgen am Modell — sie wirken damit konsistent auf alle abgeleiteten Artefakte. Ausführlich: Modellgetriebene Softwareentwicklung für Embedded Systeme |
| Domain-Driven Design (DDD) für Embedded | Architekturansatz, der Software entlang der fachlichen Domäne schneidet statt entlang technischer Schichten. In langlebigen Geräten hält das die Architektur wartbar, weil fachliche Änderungen lokal bleiben und nicht durch das ganze System wandern. Ausführlich: Domain-Driven-Design für eingebettete Systeme |
Die drei Begriffe HAL, Produktlinie und Plattformstrategie beschreiben dieselbe Frage aus drei Höhen: Wie verhindert man, dass jede neue Gerätevariante die Entwicklungs- und Nachweiskosten mitzieht? Sie sind der methodische Kern langlebiger Embedded-Portfolios.
Test und Absicherung
| Begriff | Definition |
|---|---|
| Toolchain | Zusammenspiel der Werkzeuge, mit denen Quellcode zu einem lauffähigen Artefakt für die Zielhardware wird — Compiler, Linker, Build-System, Debugger, Flash-Werkzeuge. In regulierten Projekten gehört auch die Frage dazu, ob die Werkzeugkette reproduzierbar aufgesetzt werden kann. |
| Continuous Integration / Continuous Delivery (CI/CD) | Automatisierte Kette, die jede Codeänderung baut, prüft und bereitstellt. Im Embedded-Umfeld ist der Unterschied zur reinen IT, dass echte oder nachgebildete Hardware Teil der Kette sein muss. |
| Systemtest | Prüfung des vollständigen Geräts gegen die Anforderungen — Hard- und Software im Zusammenspiel, inklusive Schnittstellen, Zeitverhalten und Betriebsbedingungen. Er ist von Unit- und Integrationstests abzugrenzen, die einzelne Bausteine prüfen. Zur Automatisierung: Assisted Embedded Systems Testing |
| Hardware-in-the-Loop (HIL) | Testaufbau, bei dem die echte Steuerung gegen eine simulierte Umgebung läuft. So lassen sich Grenz- und Fehlerfälle reproduzierbar prüfen, die am realen Aufbau nicht oder nur mit Risiko herstellbar wären. |
| Testabdeckung | Maß dafür, welcher Anteil des Codes oder der Anforderungen durch Tests tatsächlich ausgeführt bzw. abgedeckt wird. Eine hohe Abdeckung belegt nicht, dass die Tests inhaltlich gut sind — sie zeigt nur, welche Teile überhaupt geprüft wurden. |
| Traceability | Nachvollziehbare Verknüpfung zwischen Anforderung, Umsetzung, Test und Nachweis. Fehlt sie, ist bei einem gemeldeten Fehler unklar, welche Produktvarianten betroffen sind — und der Testaufwand steigt, weil vorsorglich breiter geprüft werden muss. |
| Generische Testautomatisierungsarchitektur (ISTQB) | Referenzarchitektur des ISTQB, die eine Testautomatisierung in Ebenen trennt: Testdefinition, Testausführung und Anbindung an das Testobjekt. Der Nutzen liegt darin, dass abstrakte Testfälle unabhängig von der konkreten Gerätevariante formuliert und über das Portfolio wiederverwendet werden können. |
| Auditfähigkeit und Reproduzierbarkeit | Zwei Eigenschaften, die im regulierten Umfeld zusammen auftreten: reproduzierbar heißt, dass derselbe Test unter denselben Bedingungen dasselbe Ergebnis liefert; auditfähig heißt, dass Ergebnis, Prüfstand, Softwarestand und Zeitpunkt später nachvollziehbar belegbar sind. |
Sicherheit, Normen und Regulatorik
| Begriff | Definition |
|---|---|
| Funktionale Sicherheit | Eigenschaft eines Systems, im Fehlerfall keinen unzulässigen Zustand herbeizuführen — abzugrenzen von Cybersecurity, die den Schutz vor Angriffen meint. Funktionale Sicherheit fragt „was passiert bei Ausfall“, Cybersecurity fragt „was passiert bei Angriff“. |
| IEC 61508 und Safety Integrity Level (SIL) | Grundnorm der funktionalen Sicherheit elektrischer und elektronischer Systeme. Sie ordnet Sicherheitsfunktionen in vier Stufen ein, SIL 1 bis SIL 4, wobei SIL 4 die höchste Anforderung beschreibt. Aus der Stufe folgen Anforderungen an Entwicklung, Nachweisführung und Dokumentation (Quelle: IEC 61508, iec.ch). |
| IEC 62443 | Normenreihe zur Cybersecurity industrieller Automatisierungs- und Steuerungssysteme. Sie beschreibt unter anderem die Aufteilung von Anlagen in Zonen und Verbindungen sowie abgestufte Security Level, und richtet sich sowohl an Hersteller als auch an Betreiber (Quelle: IEC 62443, iec.ch). |
| Cyber-Resilience-Act (CRA) | EU-Verordnung, amtlich Cyber Resilience Act, (EU) 2024/2847 mit Cybersicherheitsanforderungen an Produkte mit digitalen Elementen. In Kraft seit 10. Dezember 2024; die Meldepflichten gelten ab 11. September 2026, die Verordnung insgesamt ab 11. Dezember 2027 (Quelle: Verordnung (EU) 2024/2847, eur-lex.europa.eu). |
| BSI TR-03185 | Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik zur Sicherheit im Softwarelebenszyklus. Sie beschreibt, wie ein Entwicklungsprozess aufgebaut sein sollte, damit Sicherheit nicht am Ende geprüft, sondern durchgängig mitgeführt wird (Quelle: BSI, bsi.bund.de). |
| Software-Stückliste (SBOM) | Maschinenlesbares Verzeichnis aller Softwarekomponenten und Abhängigkeiten eines Produkts. Verbreitete Formate sind SPDX, international normiert als ISO/IEC 5962:2021, und CycloneDX, standardisiert als ECMA-424 und gepflegt von der OWASP Foundation gemeinsam mit dem Ecma-Komitee TC54 (Quellen: spdx.dev, cyclonedx.org). |
| CVE | Weltweit eindeutige Kennung für eine öffentlich bekannte Schwachstelle, in der Form CVE-Jahr-Nummer. Die Kennung erlaubt es, über Hersteller- und Toolgrenzen hinweg von derselben Schwachstelle zu sprechen (Quelle: CVE-Programm, cve.org). |
| CVSS | Bewertungssystem für die technische Schwere einer Schwachstelle mit Werten von 0,0 bis 10,0. Es bewertet die Schwachstelle selbst, nicht das Risiko im konkreten Produkt — dieselbe Schwachstelle kann je nach Einsatz sehr unterschiedlich kritisch sein (Quelle: FIRST, first.org). |
| Koordinierte Schwachstellenoffenlegung | Vereinbartes Verfahren, nach dem Finder und Hersteller eine Schwachstelle gemeinsam behandeln: Meldung an eine benannte Kontaktstelle, Behebung, dann abgestimmte Veröffentlichung. Eine solche Politik vorzuhalten ist eine Pflicht aus dem CRA (Quelle: Verordnung (EU) 2024/2847, Anhang I Teil II). |
| Secure Boot und Chain of Trust | Startverfahren, bei dem jede Stufe die nächste kryptografisch prüft, bevor sie sie ausführt — von einem unveränderlichen Vertrauensanker in der Hardware bis zur Anwendung. So wird verhindert, dass manipulierte Firmware unbemerkt startet. |
| Threat Modeling | Strukturiertes Vorgehen, in dem vor oder während des Entwurfs systematisch gesammelt wird, wer ein System angreifen könnte, über welche Schnittstellen und mit welchem Ziel. Ergebnis ist eine begründete Auswahl an Schutzmaßnahmen statt einer Sammlung nach Gefühl. |
Die Abkürzung SIL bedeutet in Embedded-Projekten zwei völlig verschiedene Dinge. In der funktionalen Sicherheit steht sie für Safety Integrity Level, die Sicherheitsanforderungsstufe nach IEC 61508. In der Testtechnik steht sie für Software-in-the-Loop, eine Teststufe neben Model-in-the-Loop und Hardware-in-the-Loop. Wer beide Welten in einem Projekt hat, sollte die Abkürzung ausschreiben.
Wartung und Lebenszyklus
| Begriff | Definition |
|---|---|
| Unterstützungszeitraum | Zeitraum, in dem ein Hersteller Schwachstellen behandelt und Sicherheitsupdates bereitstellt. Nach dem CRA beträgt er mindestens fünf Jahre und ist kürzer nur zulässig, wenn das Produkt voraussichtlich kürzer in Verwendung ist; bei Produkten für industrielle Umgebungen ist die tatsächliche Nutzungsdauer regelmäßig deutlich länger (Quelle: Verordnung (EU) 2024/2847, Artikel 13 Absatz 8). |
| Patch- und Variantenmanagement | Organisierte Antwort auf die Frage, wie eine Korrektur in alle betroffenen Gerätevarianten und Produktgenerationen kommt — und wie belegt wird, welcher Stand wo installiert ist. Mit der Zahl der Varianten wächst hier der Aufwand am schnellsten. |
| OTA-Update | Aktualisierung über eine Netzverbindung („over the air“) statt vor Ort am Gerät. Die Schwierigkeit liegt nicht im Übertragen, sondern in der Absicherung: Authentizität des Updates, Rückfallebene bei Abbruch und ein definierter Zustand nach dem Neustart. |
| Autonome Wartung | Betriebsmodell, in dem wiederkehrende Wartungsschritte — Erkennen neuer Schwachstellen, Zuordnen zu betroffenen Varianten, Vorbereiten von Korrekturen — automatisiert ablaufen und der Mensch die Freigabe verantwortet. Ausführlich: Autonomous Maintenance & Quality Automation |
| Altsystem (Legacy) und Abkündigung | Ein Altsystem ist eine im Betrieb bewährte, aber technisch überholte Basis — etwa eine abgekündigte Hardwareplattform oder ein Betriebssystem ohne Herstellersupport. Abkündigung heißt, dass Hersteller Lieferung oder Pflege einstellen; ab diesem Zeitpunkt entstehen Sicherheits- und Verfügbarkeitsrisiken, die nicht mehr durch Updates gedeckt sind. Eine strukturierte Bewertung solcher Risiken bietet das Embedded Product Viability Assessment |
| Wartungsfalle | Zustand, in dem ein Hersteller so viele individuell gewachsene Firmwarestände pflegt, dass ein stetig wachsender Teil der Entwicklungskapazität in die Wartung fließt und Neuentwicklungen sich verzögern. Auslöser ist typischerweise das Kopieren von Firmware für neue Varianten statt der Ableitung aus einer gemeinsamen Basis. Ausführlich: Plattformstrategie – Roadmap zur Embedded Plattform |
| Migration und Modernisierung | Überführung eines Altsystems auf eine wart- und skalierbare Basis. Fachlich sinnvoll in drei Schritten: den Bestand rekonstruieren und verstehen, ihn testbar machen, und erst dann modernisieren — sonst fehlt der Vergleichsmaßstab für „funktioniert danach noch alles“. Ausführlich: Intelligent Software Migration & Modernization |
Zusammenarbeitsmodelle
| Begriff | Definition |
|---|---|
| Ergebnisverantwortung | Ein Partner verantwortet ein abgegrenztes Software-Ergebnis — Architektur, Umsetzung und Nachweis — statt einzelne Entwicklerkapazität bereitzustellen. Der Unterschied liegt darin, wer für das Zusammenspiel und die Qualität des Ganzen einsteht. |
| Bedarfsgerechtes Team | Team, dessen Zusammensetzung sich am Bedarf des Vorhabens orientiert und über die Projektphasen verändert, anstatt aus einzeln beauftragten und einzeln gesteuerten Personen zu bestehen. |
| Testing as a Service | Modell, in dem nicht nur eine Testumgebung aufgebaut, sondern deren Betrieb, Pflege, Auswertung und Planung dauerhaft übernommen wird. Der Auftraggeber bezieht Testergebnisse statt Testinfrastruktur. Ausführlich: Assisted Embedded Systems Testing |
| Human in the Loop | Arbeitsteilung, in der Automatisierung — auch KI-gestützte — die repetitiven Anteile übernimmt, während Architektur-, Sicherheits- und Freigabeentscheidungen beim Menschen bleiben. Im regulierten Umfeld ist das die Voraussetzung dafür, dass Nachweise belastbar bleiben. Ausführlich: Integrierte KI-Technologien |
Quellen und Normbezüge
- Verordnung (EU) 2024/2847 (Cyber Resilience Act) — eur-lex.europa.eu
- IEC 61508 (funktionale Sicherheit) und IEC 62443 (industrielle Cybersecurity) — iec.ch
- Bundesamt für Sicherheit in der Informationstechnik — bsi.bund.de
- SPDX, normiert als ISO/IEC 5962:2021 — spdx.dev
- CycloneDX, standardisiert als ECMA-424 — cyclonedx.org
- CVSS, gepflegt von FIRST — first.org
- CVE-Programm — cve.org
Stand der Angaben: September 2026. Normen und Verordnungen werden fortgeschrieben; für verbindliche Anforderungen gilt jeweils die aktuelle Fassung beim Normgeber.
Dieses Glossar erklärt Begriffe. Es ist keine Norm- oder Rechtsauslegung und ersetzt keine Prüfung am konkreten Produkt. Welche Sicherheitsstufe, welches Konformitätsverfahren und welcher Unterstützungszeitraum für ein bestimmtes Gerät gelten, ergibt sich aus dem Produkt, seinem Einsatz und der jeweils aktuellen Fassung der einschlägigen Normen und Verordnungen.
Ansprechpartner und nächster Schritt
Erste Ansprechperson für Anfragen ist Marc Gossweiler (Mitgründer, Geschäftsführung). Für tiefergehende technische und architektonische Themen — unter anderem Rust und Systemarchitektur — steht CTO Philipp Bormuth zur Verfügung.
awinia GmbH · Hanferstraße 28 · 79108 Freiburg im Breisgau · +49 761 52074490
Häufige Fragen zu Embedded-Begriffen
Was ist der Unterschied zwischen Firmware und Embedded-Software?
Firmware bezeichnet die Schicht, die unmittelbar auf die Hardware zugreift, das Gerät startet und die Peripherie steuert. Embedded-Software ist der Oberbegriff für die gesamte Software eines eingebetteten Geräts, also einschließlich Anwendungslogik, Kommunikation und Bedienoberfläche. Firmware ist damit ein Teil der Embedded-Software, nicht ihr Synonym.
Was bedeutet die Abkürzung SIL?
SIL hat zwei gängige Bedeutungen. In der funktionalen Sicherheit steht sie für Safety Integrity Level, die Sicherheitsanforderungsstufe nach IEC 61508 mit den Stufen SIL 1 bis SIL 4. In der Testtechnik steht sie für Software-in-the-Loop, eine Teststufe neben Model-in-the-Loop und Hardware-in-the-Loop. In Projekten, in denen beide Welten vorkommen, sollte die Abkürzung ausgeschrieben werden.
Wozu wird eine Software-Stückliste (SBOM) gebraucht?
Eine SBOM verzeichnet maschinenlesbar alle Softwarekomponenten und Abhängigkeiten eines Produkts. Sie ist die Voraussetzung dafür, bei einer neu veröffentlichten Schwachstelle innerhalb von Stunden zu beantworten, welche Produkte und Varianten betroffen sind. Verbreitete Formate sind SPDX, international normiert als ISO/IEC 5962:2021, und CycloneDX, standardisiert als ECMA-424.
Was unterscheidet IEC 61508 von IEC 62443?
IEC 61508 ist die Grundnorm der funktionalen Sicherheit: sie behandelt die Frage, wie ein System sich im Fehlerfall verhält, und stuft Sicherheitsfunktionen in SIL 1 bis SIL 4 ein. IEC 62443 behandelt die Cybersecurity industrieller Automatisierungs- und Steuerungssysteme, also den Schutz vor Angriffen. Bei sicherheitsgerichteten, vernetzten Geräten sind regelmäßig beide Normenwelten zugleich relevant.
Was ist ein Feature-Modell?
Ein Feature-Modell beschreibt die Merkmale eines Systems und ihre Beziehungen zueinander, um Gemeinsamkeiten und Unterschiede zwischen Produktvarianten sichtbar zu machen. Übliche Beziehungsarten sind mandatory, optional, alternative, or, requires und excludes. Es ist die gängigste Technik im Produktlinien Software Engineering und die Grundlage dafür, Varianten abzuleiten statt zu kopieren.
Wie hängen Produktlinie, Variante und Plattformstrategie zusammen?
Eine Produktlinie ist eine Familie verwandter Geräte mit gemeinsamer Softwarebasis, eine Variante eine konkrete Ausprägung daraus. Die Plattformstrategie ist die Entscheidung, Gemeinsamkeiten und Unterschiede ausdrücklich zu modellieren und Varianten daraus abzuleiten, statt Codestände zu kopieren. Ohne diese Entscheidung wächst der Pflege- und Nachweisaufwand mit jeder zusätzlichen Variante mit.