Glossary
Terms and abbreviations used in the context of vHaaS.
Platform & Services
- L2: Semi-Managed
- The base service level of vHaaS. Vector operates the central cloud platform (Application Service). The customer is responsible for operating, maintaining, and housing the local hardware setups (Execution Environments and Assemblies) within their own or third-party managed facilities.
- L3: Full-Managed
- An additive service level that includes everything in L2 plus full physical hosting of hardware by Vector in a secured datacenter in Stuttgart. Vector manages both the platform and the customer's Execution Environments and Assemblies. The customer provides the proprietary target hardware (ECUs, harnesses).
- Tenant
- An isolated organizational unit within the Application Service. Each customer organization operates within its own Tenant, with dedicated user management, resource visibility, and access control. A Tenant can include multiple Organizations, Groups, and Assemblies.
- Application Service (AS)
-
The central cloud-based SaaS platform that serves as the primary interface for users and CI/CD pipelines. It handles asset scheduling, calendar bookings, device control, monitoring, REST APIs, and identity and access management. Accessible at https://vhaas.vector.cloud.
Previously referred to as vAS or Proxy.
- vHaaS Agent
- A lightweight software component installed on an Execution Environment. It acts as a secure, outbound-only bridge between the Application Service and the local workspace hardware, enabling browser-based remote desktop, SSH access, and CI/CD integration.
- vHaaS: Vector Hardware as a Service
- The product name for a scalable managed service for embedded hardware access, remote development, automated testing, and hardware sharing. vHaaS enables developers to access physical hardware globally via a browser or CI/CD pipeline without requiring a local VPN client.
Hardware & Infrastructure
- Assembly
- A logical grouping of interconnected hardware components defined for a specific development or test scenario. An Assembly typically consists of a target board (ECU), a debugger, and optional peripherals such as network interfaces (VN/VT), measurement equipment, and Hardware Automation Interfaces (HAIs). Assemblies are modeled for automation via a JSON-based Assembly Profile.
- Assembly Profile
- A digital representation ("Infrastructure as Code") of an Assembly's physical hardware cabling, pins, and interfaces. Used by the Application Service for visual layout rendering and to enable automated hardware routines via the HAI.
- Cluster
- A rack unit that provides network connectivity, server connections, and a central power supply to host one or more Assemblies. Clusters are the physical infrastructure layer that groups and connects Assemblies within the platform.
- Cluster Partition
- A named subdivision of a Cluster scoped to a specific Organization. A Cluster can be split into multiple partitions, each with a defined number of Assembly slots and assigned to a different organization. This allows a single physical rack to serve multiple organizations independently.
- EE: Execution Environment
- A dedicated physical or virtual computing unit (e.g., Intel NUC, PC, VM, Raspberry Pi) that acts as the remote development workstation. The vHaaS Agent is installed on the EE to connect it securely to the Application Service. In L3 Hosting, EEs are fully managed by Vector.
- HAI: Hardware Automation Interface
- A hardware component used as part of an Assembly to enable programmatic, remote control of connected devices — such as powering devices on or off, triggering resets, monitoring electrical state, or reconfiguring the test setup (e.g., via relay or multiplexer extension boards). HAIs are controlled via a REST API layer exposed through the vHaaS Agent. See Assembly for the current HAI hardware.
- Jumper
- A physical short-circuit connector on a relay card that routes a HAI channel to a specific device or signal (e.g., 5V, GND, or open line). Jumpers allow the physical wiring of an Assembly to be reconfigured without hardware disassembly. See Assembly for how relay cards and jumpers fit into an Assembly.
- Workspace
- A virtual entity defining an exclusive development or test session. A Workspace bundles one or more Execution Environments and Assemblies, ensuring that only one user or CI/CD runner has access to the physical system at any given moment.
- Workspace Slot
- A standardized rack unit (1 U / 1 HE) used as the base unit for Assembly sizing and pricing in the L3 Hosting service.
Workflows & Automation
- Assembly Session
- A time-bounded, exclusive reservation of an Assembly for a specific user or CI/CD pipeline. A session grants the holder sole access to the Assembly and its connected hardware for the defined time window. Sessions can be created, extended, and released via the Web UI, CLI, or REST API.
- Session Transfer
- The handover of an active Assembly Session from one user to another. The initiating user requests a transfer; the recipient can accept or reject it. Transfers can also be forced by an administrator. Used to hand off ongoing work without interrupting the session.
- Device Sequence
- An ordered list of device operations (such as power cycling, relay switching, or HAI state changes) saved against an Assembly. Sequences can be triggered manually from the UI or via the API to automate repetitive hardware interactions. See Manage Device Sequences.
- Request Profile
- A configuration template used in CI/CD pipelines to dynamically locate, book, and spin up a matching Workspace based on hardware capability requirements (e.g., "find a system with debugger type X"). Enables fully automated, conflict-free hardware allocation across distributed environments.
- Session Context
- The state established when a user's reservation becomes active on an Assembly. Includes the user's VM access credentials, environment paths, and device ownership. Initialized at session start and cleaned up when the session ends or is transferred.
Access & Security
- ReBAC: Relationship-Based Access Control
- The authorization model used by vHaaS to determine what a user can access. Permissions are derived from the relationships between users, groups, organizations, and resources (Assemblies, tokens, Clusters) — rather than from static role lists. See Organization and Visibility Structure.
- TPM: Trusted Platform Module
- A security chip built into most modern PCs and laptops. It generates and stores private keys internally and never releases them — it can sign data on request, but the key itself cannot be read out. The vHaaS Agent uses the TPM of its Execution Environment to create the machine's identity, so that identity cannot be copied to another machine. A virtual machine may expose a vTPM provided by its hypervisor, which behaves the same way. Devices without a TPM (such as a Raspberry Pi) require an additional software-TPM package. See vHaaS Agent.