Glossary

A

ADAS (Advanced Driver Assistance Systems) Advanced driver assistance features such as lane-keeping assist, automatic emergency braking, and parking assistance. In OSxCAR, ADAS software runs as a WebAssembly module, portable across heterogeneous hardware.

API (Application Programming Interface) A programming interface that defines how different software components interact with each other. In OSxCAR, APIs enable communication between WebAssembly modules and the vehicle system.

AoT (Ahead-of-Time Compilation) Compilation strategy where WebAssembly bytecode is translated into native machine code before execution. Unlike JIT, AoT provides deterministic runtime behaviour — critical for safety-critical automotive applications.

ARM Widely used processor architecture (Advanced RISC Machines). The same WebAssembly binary runs in OSxCAR without recompilation on ARM, x86, and RISC-V processors.

ASIC (Application-Specific Integrated Circuit) An integrated circuit designed for a specific task. In vehicle platforms, ASICs are used for AI inference or signal processing and are part of the heterogeneous target platforms addressed by OSxCAR.

ASIL (Automotive Safety Integrity Level) Safety classification under ISO 26262 describing the required integrity level of a vehicle system. ASIL ranges from A (low) to D (highest requirements). OSxCAR WebAssembly sandboxes actively support compliance with ASIL-D requirements.

AUTOSAR (AUTomotive Open System ARchitecture) A global development partnership standard by automotive manufacturers, suppliers, and tool developers for developing automotive software.

Autonomous Driving Self-driving vehicle technology that enables vehicles to navigate and operate without human input.

B

Binary Interface The interface between compiled code and the executing system. WebAssembly defines a standardized binary interface for cross-platform execution.

Blockchain A decentralized, distributed ledger technology that can be used in OSxCAR for secure vehicle-to-vehicle communication and authentication.

C

CAN (Controller Area Network) A robust vehicle bus system that allows microcontrollers and devices to communicate with each other without a host computer.

COM-Express / COM-HPC Standardised Computer-on-Module form factors for embedded systems. The t.RECS platform in OSxCAR supports COM-Express and COM-HPC modules to flexibly integrate different processor architectures (x86, ARM, RISC-V).

COVESA (Connected Vehicle Systems Alliance) Industry consortium for standardising vehicle software interfaces. The OSxCAR project uses the COVESA VSS (Vehicle Signal Specification) for uniform vehicle signal APIs.

CPU (Central Processing Unit) Main processor of a computer system. In OSxCAR, WebAssembly modules run on different CPU architectures (x86, ARM, RISC-V) without recompilation.

Cross-Compilation The process of compiling code on one platform (e.g., x86) for execution on another platform (e.g., ARM).

D

DDS (Data Distribution Service) Middleware standard for real-time, decoupled publish-subscribe communication. DDS is used by ROS2 and is planned as a possible integration stack for the SDVA in OSxCAR.

Digital Twin A digital representation of a physical vehicle or system used for simulation, monitoring, and maintenance.

Docker Container A lightweight, portable runtime environment that packages applications and their dependencies in isolated containers.

E

ECU (Electronic Control Unit) An electronic control unit in the vehicle that controls various vehicle systems such as engine, brakes, or infotainment.

EFRE / ERDF (European Regional Development Fund) EU structural fund for promoting regional economic development and innovation. The OSxCAR project is funded through the EFRE/JTF programme NRW under funding reference EFRE-20800271.

ELK Stack (Elasticsearch, Logstash, Kibana) Combination of three open-source tools for centralised logging, indexing, and visualisation of system logs. The OSxCAR testbench uses the ELK stack for capturing and analysing bench logs.

Embedded System A specialized computer system that functions as part of a larger system and is usually optimized for specific tasks.

F

Fleet Management The management and monitoring of a vehicle fleet, including maintenance, tracking, and optimization.

FOTA (Firmware Over-The-Air) The ability to update firmware and software in vehicles remotely via wireless connections.

FPGA (Field-Programmable Gate Array) Reprogrammable logic IC that can be configured for specific tasks after manufacture. In the OSxCAR testbench, FPGAs are used as flexible accelerators and for specialised signal processing.

G

Git A distributed version control system used in software development to track changes in source code.

GitHub A web-based platform for version control and collaboration that hosts Git repositories.

GNN (Graph Neural Network) Neural network operating on graph-structured data, learning relationships between nodes. In OSxCAR, GNN models (e.g., RouteNet) are used in WP5 for AI-driven optimisation of vehicle network topologies (SDN).

GPU (Graphics Processing Unit) Processor for massively parallel computation, used today primarily for AI inference and simulation. OSxCAR WebAssembly modules run without recompilation on GPU-accelerated platforms.

Grafana Open-source platform for visualising metrics and time-series data. In the OSxCAR testbench, Grafana is used together with Prometheus for real-time monitoring of bench performance.

H

Hardware Abstraction Layer (HAL) A software layer that provides a uniform interface between application software and hardware-specific functionality.

HIL (Hardware-in-the-Loop) Testing method in which real ECU hardware interacts with a simulated vehicle environment model. HIL is the third stage of the OSxCAR test chain: MIL → SIL → HIL → VIL → Production.

HMI (Human-Machine Interface) The user interface through which humans interact with machines or systems, e.g., touchscreens in vehicles.

HPC (High-Performance Computing / COM-HPC) (1) High-Performance Computing: High-throughput processing for compute-intensive tasks such as AI inference. (2) COM-HPC: Standardised Computer-on-Module form factor for high-performance embedded systems, supported by the t.RECS platform in OSxCAR.

I

IoT (Internet of Things) The network of physical objects equipped with sensors, software, and other technologies to exchange data over the internet.

ISA (Instruction Set Architecture) Defines the set of instructions a processor can execute (e.g., x86, ARM, RISC-V). Because WebAssembly is ISA-independent, OSxCAR code runs on all these architectures without recompilation.

ISO 26262 An international standard for functional safety of electrical and/or electronic systems in motor vehicles.

ISO/SAE 21434 International standard for cybersecurity in road vehicles. OSxCAR WebAssembly sandboxes actively support compliance with ISO/SAE 21434 requirements.

J

JSON (JavaScript Object Notation) A lightweight, text-based data format commonly used for data exchange between applications.

JIT (Just-In-Time) Compilation A compilation technique where code is compiled at runtime to optimize performance. In the WebAssembly context, JIT contrasts with AoT — AoT is preferred for automotive safety requirements.

JTF (Just Transition Fund) EU fund supporting the transition to a climate-neutral economy in particularly affected regions. The OSxCAR project is co-funded through the EFRE/JTF programme NRW.

K

Kubernetes An open-source platform for automating the deployment, scaling, and management of containerized applications.

L

LiDAR (Light Detection and Ranging) A remote sensing technology that uses laser light to measure distances and create 3D maps of the environment.

Linux An open-source operating system commonly used in embedded systems and as a basis for OSxCAR development environments.

M

Machine Learning A subset of artificial intelligence that uses algorithms to learn from data and make predictions.

MCU (Microcontroller Unit) Resource-constrained microcontroller for embedded control tasks in the vehicle. OSxCAR modules can be executed as WebAssembly even on MCUs with limited memory.

Microservices An architecture where applications are developed as a collection of small, independent services.

MIL (Model-in-the-Loop) First stage of the OSxCAR test chain: simulation at model level, testing an algorithm model in a simulation environment (MIL → SIL → HIL → VIL → Production).

MQTT (Message Queuing Telemetry Transport) A lightweight messaging protocol for communication between IoT devices.

N

Native Code Code that is executed directly by the processor without interpretation or runtime compilation.

Neural Network A computing system inspired by biological neural networks used for machine learning.

O

OBD (On-Board Diagnostics) A vehicle diagnostic system that provides access to status information of various vehicle systems.

Open Source Software whose source code is publicly available and can be viewed, modified, and distributed by anyone.

OTA (Over-The-Air) The wireless transmission of software updates, configurations, or other data to devices.

P

Performance Profiling The process of analyzing the runtime properties of an application to identify performance bottlenecks.

PHY (Physical Layer) The physical transmission layer (OSI layer 1). The OSxCAR testbench uses specialised PHY chips (e.g., Ethernovia) for low-latency Ethernet switching.

POC (Proof of Concept) Feasibility demonstration showing that a concept is technically viable. In OSxCAR, POCs are developed for new integration scenarios (e.g., AUTOSAR–WebAssembly bridges).

POSIX (Portable Operating System Interface) Unix-based interface standard providing uniform OS APIs. Traditional vehicle software is often heavily POSIX-dependent; WASI offers a portable alternative for WebAssembly.

Prometheus Open-source monitoring and alerting system. In the OSxCAR testbench, Prometheus is used together with Grafana for real-time monitoring of latencies and system metrics.

PSFP (Per-Stream Filtering and Policing) IEEE 802.1Q mechanism for deterministic TSN: each data stream is individually filtered and policed for bandwidth compliance. OSxCAR configures and validates PSFP settings in the testbench.

PWA (Progressive Web App) Web applications that provide native app-like functionality and experiences.

PWM (Pulse Width Modulation) Control technique in which a signal’s duty cycle varies to regulate analogue quantities (e.g., motor speed). The interactive OSxCAR demo uses PWM for simulated motor control.

Q

QNX A commercial, Unix-like real-time operating system frequently used in automotive applications.

Quality Assurance (QA) The process of ensuring that software meets specified requirements and quality standards.

R

RECS (Rack-based Embedded Computing System) Modular hardware platform by CETEQ (t.RECS/u.RECS/RECSBox) used in OSxCAR as the SDVA testbench. t.RECS supports standard form factors (SMARC, COM-HPC) for x86, ARM, and RISC-V processors as well as GPU/FPGA extensions.

Real-Time Operating System (RTOS) An operating system designed for applications that require fast, predictable response to events.

REST (Representational State Transfer) An architectural style for developing web services that uses HTTP methods for communication.

RISC-V Open, royalty-free instruction set architecture. RISC-V is one of the target architectures for OSxCAR WebAssembly modules — the same binary runs on RISC-V as on x86 and ARM.

ROS2 (Robot Operating System 2) Middleware framework for robotics and autonomous systems using publish-subscribe communication over DDS. Integration of ROS2/DDS as a software stack in the OSxCAR shared bench environment is planned.

Rust A programming language designed for safety, speed, and concurrency, used in OSxCAR modules.

S

SAE (Society of Automotive Engineers) International engineering organisation for automotive, aerospace, and mobility. Known for the SAE autonomy levels (L0–L5) and the standard ISO/SAE 21434 (vehicle cybersecurity).

Sandbox An isolated execution environment that prevents applications from accessing system resources outside their authorized areas.

SDK (Software Development Kit) A collection of development tools that enable creating applications for a specific platform.

SDN (Software-Defined Networking) Network architecture where the control plane is software-defined and separated from the data path. In OSxCAR, SDN is used for dynamic configuration of vehicle networks; GNN models optimise SDN rules automatically.

SDV (Software-Defined Vehicle) Vehicle concept in which functions are largely defined by software and can be updated via OTA. SDV is the central theme of the OSxCAR project.

SDVA (Software-Defined Vehicle Architecture) The system architecture of an SDV, comprising hardware platform, middleware, communication infrastructure, and software modules. OSxCAR develops and validates a scalable SDVA using the t.RECS testbench.

Sensor Fusion The integration of data from multiple sensors to create more accurate and reliable information about the vehicle environment.

SIL (Software-in-the-Loop) Testing method where software code is tested on a development machine against a simulated vehicle model. SIL is the second stage of the OSxCAR test chain (MIL → SIL → HIL → VIL → Production).

SIMD (Single Instruction, Multiple Data) Parallel processing concept where a single instruction is applied to multiple data points simultaneously. WebAssembly SIMD is a WASM extension used in OSxCAR for compute-intensive algorithms.

SMARC (Smart Mobility ARChitecture) Standardised Computer-on-Module form factor (64×30 mm) for energy-efficient embedded systems. The t.RECS platform in OSxCAR supports SMARC modules for ARM and x86 processors.

T

TEE (Trusted Execution Environment) Isolated, secure execution environment at processor level (e.g., ARM TrustZone) that protects security-critical computations from the rest of the system. TEEs are used in OSxCAR for security-sensitive vehicle applications.

Telemetry The automatic collection and transmission of data from remote or inaccessible points.

Thread A lightweight process that enables multiple operations to run simultaneously within an application.

TISAX (Trusted Information Security Assessment Exchange) Automotive industry information security standard based on ISO 27001. TISAX audits assess information security along the supply chain; the OSxCAR project takes TISAX requirements into account.

TLS (Transport Layer Security) Cryptographic protocol for secure network communication. The OSxCAR testbench uses TLS 1.3 for multi-tenant isolation and encrypted data transmission.

TSN (Time-Sensitive Networking) IEEE 802.1 extensions for deterministic Ethernet with guaranteed latencies. TSN is a key technology in the OSxCAR testbench for deterministic vehicle network communication.

TypeScript A programming language developed by Microsoft that extends JavaScript with static type definitions.

U

Unit Testing A testing method where individual components of software are tested in isolation to ensure they function correctly.

UX (User Experience) The overall experience of a user when interacting with a product or system.

V

V2V (Vehicle-to-Vehicle) Communication technology that enables vehicles to exchange information directly with each other.

V2X (Vehicle-to-Everything) Communication technology that connects vehicles to their environment, including other vehicles, infrastructure, and pedestrians.

VIL (Vehicle-in-the-Loop) Testing method in which a real vehicle is integrated into a hardware-in-the-loop environment. VIL is the final stage of the test chain before production deployment (MIL → SIL → HIL → VIL → Production).

Virtualization The creation of virtual versions of computer resources such as operating systems, servers, or storage devices.

VLAN (Virtual Local Area Network) Logical network segmentation based on IEEE 802.1Q. In the OSxCAR testbench, VLANs are used for multi-tenant isolation and TSN QoS configurations.

VSS (Vehicle Signal Specification) COVESA standard for uniform vehicle signal APIs, describing sensor data, actuators, and vehicle state variables in a hierarchical taxonomy. OSxCAR uses COVESA VSS for standardised vehicle APIs.

W

WASI (WebAssembly System Interface) Standardised system interface giving WebAssembly modules controlled access to OS services (filesystem, network, clock). WASI replaces POSIX dependencies in OSxCAR, making vehicle functions portable and isolated.

WASM (WebAssembly) A binary instruction format for a stack-based virtual machine that enables code to run at near-native speed on the web and other environments.

WebAssembly Runtime The runtime environment that executes WebAssembly modules and provides the necessary APIs and services.

WebGL A JavaScript API for rendering interactive 2D and 3D graphics in web browsers without plugins.

WIT (WebAssembly Interface Types) Interface description language for WebAssembly components, defining type-safe, language-agnostic APIs between modules. In OSxCAR, vehicle functions are implemented in Rust and connected through formal WIT interfaces.

X

XML (eXtensible Markup Language) A markup language for representing hierarchically structured data in text files.

Y

YAML (YAML Ain’t Markup Language) A human-readable data format commonly used for configuration files and data exchange.

Z

Zenoh Lightweight pub/sub and query protocol optimised for resource-constrained systems and real-time communication. Zenoh is planned as a possible integration stack in the OSxCAR SDVA bench environment (alongside ACF and ROS2/DDS).

Zero Trust Security A security model that assumes no entity inside or outside the network is trustworthy by default.

Next: Frequently Asked Questions