Glossar

A

ADAS (Advanced Driver Assistance Systems) Fortschrittliche Fahrerassistenzsysteme wie Spurhalteassistent, automatische Notbremsung oder Einparkhilfe. In OSxCAR läuft ADAS-Software als WebAssembly-Modul portabel auf heterogener Hardware.

API (Application Programming Interface) Eine Programmierschnittstelle, die definiert, wie verschiedene Softwarekomponenten miteinander interagieren. In OSxCAR ermöglichen APIs die Kommunikation zwischen WebAssembly-Modulen und dem Fahrzeugsystem.

AoT (Ahead-of-Time Compilation) Kompilierungsstrategie, bei der WebAssembly-Bytecode vor der Ausführung in nativen Maschinencode übersetzt wird. Im Gegensatz zu JIT bietet AoT deterministisches Laufzeitverhalten – wichtig für sicherheitskritische Automotive-Anwendungen.

ARM Weit verbreitete Prozessorarchitektur (Advanced RISC Machines). Dasselbe WebAssembly-Binärformat läuft in OSxCAR ohne Neukompilierung auf ARM-, x86- und RISC-V-Prozessoren.

ASIC (Application-Specific Integrated Circuit) Anwendungsspezifischer integrierter Schaltkreis, der für eine bestimmte Aufgabe maßgeschneidert ist. In Fahrzeugplattformen werden ASICs u. a. für KI-Inferenz oder Signalverarbeitung eingesetzt.

ASIL (Automotive Safety Integrity Level) Sicherheitseinstufung gemäß ISO 26262, die das erforderliche Sicherheitsniveau eines Fahrzeugsystems beschreibt. ASIL reicht von A (niedrig) bis D (höchste Anforderungen). OSxCAR-WebAssembly-Sandboxes unterstützen aktiv die Erfüllung von ASIL-D-Anforderungen.

AUTOSAR (AUTomotive Open System ARchitecture) Ein weltweiter Entwicklungspartnerschaftsstandard von Automobilherstellern, Zulieferern und Tool-Entwicklern für die Entwicklung von Automotive-Software.

Autonomous Driving Selbstfahrende Fahrzeugtechnologie, die es Fahrzeugen ermöglicht, ohne menschliche Eingaben zu navigieren und zu operieren.

B

Binary Interface Die Schnittstelle zwischen kompiliertem Code und dem ausführenden System. WebAssembly definiert eine standardisierte Binary Interface für plattformübergreifende Ausführung.

Blockchain Eine dezentrale, verteilte Ledger-Technologie, die in OSxCAR für sichere Fahrzeug-zu-Fahrzeug-Kommunikation und Authentifizierung eingesetzt werden kann.

C

CAN (Controller Area Network) Ein robustes Fahrzeugbussystem, das es Mikrocontrollern und Geräten ermöglicht, ohne Host-Computer miteinander zu kommunizieren.

COM-Express / COM-HPC Standardisierte Computer-on-Module-Formfaktoren für eingebettete Systeme. Die t.RECS-Plattform in OSxCAR unterstützt COM-Express- und COM-HPC-Module, um verschiedene Prozessorarchitekturen (x86, ARM, RISC-V) flexibel zu integrieren.

COVESA (Connected Vehicle Systems Alliance) Industriekonsortium zur Standardisierung von Fahrzeugsoftware-Schnittstellen. Das OSxCAR-Projekt nutzt den COVESA VSS (Vehicle Signal Specification) für einheitliche Fahrzeugsignal-APIs.

CPU (Central Processing Unit) Hauptprozessor eines Computersystems. In OSxCAR laufen WebAssembly-Module auf unterschiedlichen CPU-Architekturen (x86, ARM, RISC-V) ohne Neukompilierung.

Cross-Compilation Der Prozess der Kompilierung von Code auf einer Plattform (z.B. x86) für die Ausführung auf einer anderen Plattform (z.B. ARM).

D

DDS (Data Distribution Service) Middleware-Standard für echtzeitfähige, entkoppelte Publish-Subscribe-Kommunikation. DDS wird u. a. von ROS2 genutzt und ist in OSxCAR als möglicher Software-Stack für die SDVA vorgesehen.

Digital Twin Eine digitale Repräsentation eines physischen Fahrzeugs oder Systems, die für Simulation, Überwachung und Wartung verwendet wird.

Docker Container Eine leichtgewichtige, portable Laufzeitumgebung, die Anwendungen und ihre Abhängigkeiten in isolierten Containern verpackt.

E

ECU (Electronic Control Unit) Ein elektronisches Steuergerät im Fahrzeug, das verschiedene Fahrzeugsysteme wie Motor, Bremsen oder Infotainment steuert.

EFRE (Europäischer Fonds für regionale Entwicklung) EU-Strukturfonds zur Förderung regionaler wirtschaftlicher Entwicklung und Innovation. Das OSxCAR-Projekt wird durch das EFRE/JTF-Programm NRW unter dem Förderkennzeichen EFRE-20800271 gefördert.

ELK-Stack (Elasticsearch, Logstash, Kibana) Kombination von drei Open-Source-Tools für zentrales Logging, Indexierung und Visualisierung von Systemlogs. In der OSxCAR-Testbench wird der ELK-Stack für Erfassung und Analyse von Bench-Logs eingesetzt.

Embedded System Ein spezialisiertes Computersystem, das als Teil eines größeren Systems fungiert und meist für spezielle Aufgaben optimiert ist.

F

Fleet Management Die Verwaltung und Überwachung einer Fahrzeugflotte, einschließlich Wartung, Tracking und Optimierung.

FOTA (Firmware Over-The-Air) Die Fähigkeit, Firmware und Software in Fahrzeugen remote über drahtlose Verbindungen zu aktualisieren.

FPGA (Field-Programmable Gate Array) Frei programmierbares Logik-IC, das nach der Fertigung für spezifische Aufgaben konfiguriert werden kann. In der OSxCAR-Testbench werden FPGAs als flexible Beschleuniger und für spezielle Signalverarbeitungsaufgaben eingesetzt.

G

Git Ein verteiltes Versionskontrollsystem, das in der Softwareentwicklung zur Verfolgung von Änderungen im Quellcode verwendet wird.

GitHub Eine webbasierte Plattform für Versionskontrolle und Zusammenarbeit, die Git-Repositories hostet.

GNN (Graph Neural Network) Neuronales Netz, das auf Graphdaten operiert und Beziehungen zwischen Knoten lernt. In OSxCAR werden GNN-Modelle (z. B. RouteNet) im WP5 für die KI-gestützte Optimierung von Fahrzeugnetzwerktopologien (SDN) eingesetzt.

GPU (Graphics Processing Unit) Prozessor für massiv-parallele Berechnungen, der für KI-Inferenz und Simulation genutzt wird. OSxCAR-WebAssembly-Module laufen ohne Neukompilierung auch auf GPU-beschleunigten Plattformen.

Grafana Open-Source-Plattform zur Visualisierung von Metriken und Zeitreihendaten. In der OSxCAR-Testbench wird Grafana zusammen mit Prometheus für das Echtzeit-Monitoring der Bench-Performance eingesetzt.

H

Hardware Abstraction Layer (HAL) Eine Softwareschicht, die eine einheitliche Schnittstelle zwischen der Anwendungssoftware und der Hardware-spezifischen Funktionalität bietet.

HIL (Hardware-in-the-Loop) Testmethode, bei der echte Steuergeräte-Hardware mit einem simulierten Fahrzeugumgebungsmodell interagiert. HIL ist die dritte Stufe der OSxCAR-Testkette: MIL → SIL → HIL → VIL → Produktion.

HMI (Human-Machine Interface) Die Benutzeroberfläche, über die Menschen mit Maschinen oder Systemen interagieren, z.B. Touchscreens im Fahrzeug.

HPC (High-Performance Computing / COM-HPC) (1) High-Performance Computing: Hochleistungsrechnen für rechenintensive Aufgaben wie KI-Inferenz. (2) COM-HPC: Standardisierter Computer-on-Module-Formfaktor, der von der t.RECS-Plattform in OSxCAR unterstützt wird.

I

IoT (Internet of Things) Das Netzwerk physischer Objekte, die mit Sensoren, Software und anderen Technologien ausgestattet sind, um Daten über das Internet auszutauschen.

ISA (Instruction Set Architecture) Befehlssatzarchitektur, die die Menge der von einem Prozessor ausführbaren Befehle definiert (z. B. x86, ARM, RISC-V). Da WebAssembly ISA-unabhängig ist, läuft OSxCAR-Code auf allen diesen Architekturen ohne Neukompilierung.

ISO 26262 Ein internationaler Standard für Funktionale Sicherheit von elektrischen und/oder elektronischen Systemen in Kraftfahrzeugen.

ISO/SAE 21434 Internationaler Standard für Cybersicherheit in Straßenfahrzeugen. OSxCAR-WebAssembly-Sandboxes unterstützen aktiv die Einhaltung von ISO/SAE-21434-Anforderungen.

J

JSON (JavaScript Object Notation) Ein leichtgewichtiges, textbasiertes Datenformat, das häufig für den Datenaustausch zwischen Anwendungen verwendet wird.

JIT (Just-In-Time) Compilation Eine Kompilierungstechnik, bei der Code zur Laufzeit kompiliert wird, um die Performance zu optimieren.

JTF (Just Transition Fund) EU-Fonds zur Unterstützung des Übergangs zu einer klimaneutralen Wirtschaft in besonders betroffenen Regionen. Das OSxCAR-Projekt wird durch das EFRE/JTF-Programm NRW gefördert.

K

Kubernetes Eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.

L

LiDAR (Light Detection and Ranging) Eine Fernerkundungstechnologie, die Laserlicht verwendet, um Entfernungen zu messen und 3D-Karten der Umgebung zu erstellen.

Linux Ein Open-Source-Betriebssystem, das häufig in eingebetteten Systemen und als Basis für OSxCAR-Entwicklungsumgebungen verwendet wird.

M

Machine Learning Ein Teilbereich der künstlichen Intelligenz, der Algorithmen verwendet, um aus Daten zu lernen und Vorhersagen zu treffen.

MCU (Microcontroller Unit) Ressourcenbeschränkter Mikrocontroller für eingebettete Steueraufgaben im Fahrzeug. OSxCAR-Module lassen sich als WebAssembly auch auf MCUs mit begrenztem Speicher ausführen.

Microservices Eine Architektur, bei der Anwendungen als Sammlung kleiner, unabhängiger Services entwickelt werden.

MIL (Model-in-the-Loop) Erste Stufe der OSxCAR-Testkette: Simulation auf Modellebene, bei der ein Algorithmusmodell in einer Simulationsumgebung getestet wird (MIL → SIL → HIL → VIL → Produktion).

MQTT (Message Queuing Telemetry Transport) Ein leichtgewichtiges Messaging-Protokoll für die Kommunikation zwischen IoT-Geräten.

N

Native Code Code, der direkt vom Prozessor ohne Interpretation oder Compilation zur Laufzeit ausgeführt wird.

Neural Network Ein Rechensystem, das von biologischen Neuronennetzwerken inspiriert ist und für maschinelles Lernen verwendet wird.

O

OBD (On-Board Diagnostics) Ein Fahrzeugdiagnosesystem, das Zugang zu Statusinformationen verschiedener Fahrzeugsysteme bietet.

Open Source Software, deren Quellcode öffentlich verfügbar ist und von jedem eingesehen, modifiziert und verteilt werden kann.

OTA (Over-The-Air) Die drahtlose Übertragung von Software-Updates, Konfigurationen oder anderen Daten an Geräte.

P

Performance Profiling Der Prozess der Analyse der Laufzeiteigenschaften einer Anwendung zur Identifizierung von Performance-Engpässen.

PHY (Physical Layer) Die physikalische Übertragungsschicht (OSI-Schicht 1). In der OSxCAR-Testbench werden spezialisierte PHY-Chips (z. B. Ethernovia) für Low-Latency-Ethernet-Switching eingesetzt.

POC (Proof of Concept) Machbarkeitsnachweis, der zeigt, dass ein Konzept technisch umsetzbar ist. Im OSxCAR-Projekt werden POCs für neue Integrationsszenarien (z. B. AUTOSAR-WebAssembly-Brücken) entwickelt.

POSIX (Portable Operating System Interface) Unix-basierter Schnittstellenstandard für einheitliche Betriebssystem-APIs. Herkömmliche Fahrzeugsoftware ist oft stark POSIX-abhängig; WASI bietet eine portable Alternative für WebAssembly.

Prometheus Open-Source-Monitoring- und Alerting-System. In der OSxCAR-Testbench wird Prometheus zusammen mit Grafana für das Echtzeit-Monitoring von Latenzen und Systemmetriken eingesetzt.

PSFP (Per-Stream Filtering and Policing) IEEE-802.1Q-Mechanismus für deterministisches TSN: Jeder Datenstrom wird individuell gefiltert und auf Bandbreiteneinhaltung überwacht. OSxCAR konfiguriert und validiert PSFP-Einstellungen in der Testbench.

PWA (Progressive Web App) Webanwendungen, die native App-ähnliche Funktionen und Erfahrungen bieten.

PWM (Pulse Width Modulation) Pulsweitenmodulation – Steuerungsverfahren, bei dem ein Signal durch variables Tastverhältnis analoge Größen (z. B. Motorgeschwindigkeit) regelt. In der interaktiven OSxCAR-Demo wird PWM für die simulierte Motoransteuerung genutzt.

Q

QNX Ein kommerzielles, Unix-ähnliches Echtzeitbetriebssystem, das häufig in Automotive-Anwendungen eingesetzt wird.

Quality Assurance (QA) Der Prozess der Sicherstellung, dass Software den spezifizierten Anforderungen und Qualitätsstandards entspricht.

R

RECS (Rack-based Embedded Computing System) Modulare Hardwareplattform von CETEQ (t.RECS/u.RECS/RECSBox), die in OSxCAR als SDVA-Testbench eingesetzt wird. t.RECS unterstützt Standard-Formfaktoren (SMARC, COM-HPC) für x86-, ARM- und RISC-V-Prozessoren sowie GPU/FPGA-Erweiterungen.

Real-Time Operating System (RTOS) Ein Betriebssystem, das für Anwendungen entwickelt wurde, die eine schnelle, vorhersagbare Reaktion auf Ereignisse erfordern.

REST (Representational State Transfer) Ein Architekturstil für die Entwicklung von Webservices, der HTTP-Methoden für die Kommunikation verwendet.

RISC-V Offene, lizenzfreie Befehlssatzarchitektur. RISC-V ist eine der Zielarchitekturen für OSxCAR-WebAssembly-Module – dasselbe Binärformat läuft auf RISC-V wie auf x86 und ARM.

ROS2 (Robot Operating System 2) Middleware-Framework für Robotik und autonome Systeme mit Publish-Subscribe-Kommunikation über DDS. In OSxCAR ist die Integration von ROS2/DDS als Software-Stack in der gemeinsamen Bench-Umgebung vorgesehen.

Rust Eine Programmiersprache, die für Sicherheit, Geschwindigkeit und Parallelität entwickelt wurde und in OSxCAR-Modulen verwendet wird.

S

SAE (Society of Automotive Engineers) Internationale Ingenieurvereinigung für Automobil-, Luft- und Raumfahrttechnik. Bekannt für die SAE-Autonomiegrade (L0–L5) und die Norm ISO/SAE 21434 (Fahrzeug-Cybersicherheit).

Sandbox Eine isolierte Ausführungsumgebung, die verhindert, dass Anwendungen auf Systemressourcen außerhalb ihrer autorisierten Bereiche zugreifen.

SDK (Software Development Kit) Eine Sammlung von Entwicklungstools, die es ermöglichen, Anwendungen für eine bestimmte Plattform zu erstellen.

SDN (Software-Defined Networking) Netzwerkarchitektur, bei der die Steuerungsebene softwarebasiert vom Datenpfad getrennt ist. In OSxCAR wird SDN für die dynamische Konfiguration der Fahrzeugnetzwerke genutzt; GNN-Modelle optimieren die SDN-Regeln automatisch.

SDV (Software-Defined Vehicle) Fahrzeugkonzept, bei dem Funktionen überwiegend durch Software definiert und per OTA aktualisiert werden können. SDV ist das zentrale Thema des OSxCAR-Projekts.

SDVA (Software-Defined Vehicle Architecture) Die Systemarchitektur eines SDV, bestehend aus Hardware-Plattform, Middleware, Kommunikationsinfrastruktur und Softwaremodulen. OSxCAR entwickelt und erprobt eine skalierbare SDVA mit der t.RECS-Testbench.

Sensor Fusion Die Integration von Daten aus mehreren Sensoren zur Erstellung genauerer und zuverlässigerer Informationen über die Fahrzeugumgebung.

SIL (Software-in-the-Loop) Testmethode, bei der Softwarecode auf dem Entwicklungsrechner gegen ein simuliertes Fahrzeugmodell getestet wird. SIL ist die zweite Stufe der OSxCAR-Testkette (MIL → SIL → HIL → VIL → Produktion).

SIMD (Single Instruction, Multiple Data) Parallelverarbeitungskonzept, bei dem ein Befehl gleichzeitig auf mehrere Datenpunkte angewendet wird. WebAssembly SIMD ist eine Erweiterung des WASM-Standards für rechenintensive Algorithmen in OSxCAR.

SMARC (Smart Mobility ARChitecture) Standardisierter Computer-on-Module-Formfaktor (64×30 mm) für energieeffiziente eingebettete Systeme. Die t.RECS-Plattform in OSxCAR unterstützt SMARC-Module für ARM- und x86-Prozessoren.

T

TEE (Trusted Execution Environment) Isolierte, sichere Ausführungsumgebung auf Prozessorebene (z. B. ARM TrustZone), die sicherheitskritische Berechnungen vor dem restlichen System abschirmt. TEEs werden in OSxCAR für sicherheitssensible Fahrzeuganwendungen eingesetzt.

Telemetry Die automatische Erfassung und Übertragung von Daten von entfernten oder unzugänglichen Punkten.

Thread Ein leichtgewichtiger Prozess, der es ermöglicht, mehrere Operationen gleichzeitig innerhalb einer Anwendung auszuführen.

TISAX (Trusted Information Security Assessment Exchange) Branchenspezifischer Informationssicherheitsstandard der Automobilindustrie, basierend auf ISO 27001. TISAX-Audits prüfen die Informationssicherheit entlang der Lieferkette; das OSxCAR-Projekt berücksichtigt TISAX-Anforderungen.

TLS (Transport Layer Security) Kryptografisches Protokoll für sichere Netzwerkkommunikation. In der OSxCAR-Testbench wird TLS 1.3 für Multi-Tenant-Isolation und verschlüsselte Datenübertragung eingesetzt.

TSN (Time-Sensitive Networking) IEEE-802.1-Erweiterungen für deterministisches Ethernet mit garantierten Latenzen. TSN ist eine Schlüsseltechnologie in der OSxCAR-Testbench für deterministische Fahrzeugnetzwerkkommunikation.

TypeScript Eine von Microsoft entwickelte Programmiersprache, die JavaScript um statische Typdefinitionen erweitert.

U

Unit Testing Eine Testmethode, bei der einzelne Komponenten einer Software isoliert getestet werden, um sicherzustellen, dass sie korrekt funktionieren.

UX (User Experience) Die Gesamterfahrung eines Benutzers bei der Interaktion mit einem Produkt oder System.

V

V2V (Vehicle-to-Vehicle) Kommunikationstechnologie, die es Fahrzeugen ermöglicht, Informationen direkt miteinander auszutauschen.

V2X (Vehicle-to-Everything) Kommunikationstechnologie, die Fahrzeuge mit ihrer Umgebung vernetzt, einschließlich andere Fahrzeuge, Infrastruktur und Fußgänger.

VIL (Vehicle-in-the-Loop) Testmethode, bei der ein reales Fahrzeug in eine Hardware-in-the-Loop-Umgebung eingebunden wird. VIL ist die letzte Stufe der Testkette vor dem Produktionseinsatz (MIL → SIL → HIL → VIL → Produktion).

Virtualization Die Erstellung virtueller Versionen von Computerressourcen wie Betriebssystemen, Servern oder Speichergeräten.

VLAN (Virtual Local Area Network) Logische Netzwerksegmentierung auf Basis von IEEE 802.1Q. In der OSxCAR-Testbench werden VLANs für Multi-Tenant-Isolation und TSN-QoS-Konfigurationen eingesetzt.

VSS (Vehicle Signal Specification) COVESA-Standard für einheitliche Fahrzeugsignal-APIs, der Sensordaten, Aktuatoren und Fahrzeugzustandsgrößen in einer hierarchischen Taxonomie beschreibt. OSxCAR nutzt COVESA VSS für standardisierte Fahrzeug-APIs.

W

WASI (WebAssembly System Interface) Standardisierte Systemschnittstelle, die WebAssembly-Modulen kontrollierten Zugang zu Betriebssystemdiensten (Dateisystem, Netzwerk, Uhr) ermöglicht. WASI ersetzt in OSxCAR POSIX-Abhängigkeiten und macht Fahrzeugfunktionen portabel und isoliert.

WASM (WebAssembly) Ein binäres Instruktionsformat für eine stapelbasierte virtuelle Maschine, die es ermöglicht, Code in nahezu nativer Geschwindigkeit im Web und anderen Umgebungen auszuführen.

WebAssembly Runtime Die Laufzeitumgebung, die WebAssembly-Module ausführt und die notwendigen APIs und Services bereitstellt.

WebGL Eine JavaScript-API für das Rendern interaktiver 2D- und 3D-Grafiken in Webbrowsern ohne Plugins.

WIT (WebAssembly Interface Types) Schnittstellenbeschreibungssprache für WebAssembly-Komponenten, die typsichere, sprachunabhängige APIs zwischen Modulen definiert. In OSxCAR werden Fahrzeugfunktionen in Rust implementiert und über formale WIT-Schnittstellen verbunden.

X

XML (eXtensible Markup Language) Eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien.

Y

YAML (YAML Ain’t Markup Language) Ein menschenlesbares Datenformat, das häufig für Konfigurationsdateien und Datenaustausch verwendet wird.

Z

Zenoh Leichtgewichtiges Pub/Sub- und Query-Protokoll, das für ressourcenbeschränkte Systeme und Echtzeitkommunikation optimiert ist. Zenoh ist als möglicher Integrations-Stack in der OSxCAR-SDVA-Bench-Umgebung vorgesehen (neben ACF und ROS2/DDS).

Zero Trust Security Ein Sicherheitsmodell, das davon ausgeht, dass keine Entität innerhalb oder außerhalb des Netzwerks standardmäßig vertrauenswürdig ist.

Weiter: Häufig gestellte Fragen