Capability-Based Architecture for Automated Vehicles

• Capability-based architecture is a method that organizes automated vehicle systems by explicitly defining sensor, actuator, and dynamic capabilities for module deployment.
• It enhances modularity and safety through strict compatibility checks that verify each module's requirements against the vehicle's available capabilities.
• Real-world applications in shuttles, passenger cars, and AGVs demonstrate its scalability, adaptability, and effectiveness in achieving reliable operational safety.

A capability-based architecture for automated vehicles organizes the perception, planning, and control stack around explicit representations of the available and required system capabilities. Each function or module is described in terms of the sensors, actuators, and dynamic properties it needs, and each vehicle exposes a tuple of actual capabilities. This design paradigm supports modularity, scalability, safety traceability, runtime self-assessment, and systematic integration across a heterogeneous set of platforms. The approach has become central to recent automated driving stacks, systems engineering frameworks, and runtime monitors, providing the backbone for both real-world deployments and theoretical safety guarantees.

1. Core Principles of Capability-Based Architecture

At its core, a capability-based architecture formalizes every vehicle $\mathrm{V}$ by a capability tuple

$C_V = (S_V,\, A_V,\, D_V)$

where $S_V$ is the set of installed sensors, $A_V$ the set of available actuator interfaces, and $D_V$ a profile of dynamic limits (e.g., maximum speed, acceleration, steering angle, steering rate). Each software module $M_i$ declares its requirements as

$$\mathrm{Req}(M_i) = (S_{\mathrm{req}},\, A_{\mathrm{req}},\, D_{\mathrm{req}})$$

and is only deployed if $\mathrm{Req}(M_i) \subseteq C_V$ in all components. This inclusion is enforced as a strict Boolean subset check, guaranteeing that every module's operational assumptions are explicitly validated against the platform on which it is launched (Ochs et al., 2024).

The framework establishes boundaries between modules via strict interfaces, strict timestamping, status codes, and health fields. Integration across different vehicles or module versions only requires updating the capabilities descriptors and performing a compatibility check, without the need for interface re-engineering.

2. Stack Organization and Modular Decomposition

Capability-based architectures typically decompose the automated driving stack into a set of functionally distinct layers. The TCS-AD stack, for example, is structured as follows (Ochs et al., 2024):

1. Localization (L): Computes 6D ego pose and velocity relative to a high-definition map.
2. Perception (P): Constructs a 2D occupancy grid (costmap) and a list of dynamic obstacles with semantic class and kinematic estimates.
3. Prediction/Maneuver (Π/M): Predicts trajectories for surrounding traffic participants and resolves semantic "traits" to shape the admissible driving area.
4. Planning (R): Generates a comfort-optimized, collision-free trajectory within the admissible area, often using Particle Swarm Optimization or spline interpolation.
5. Execution & Safety (E+S): Monitors run-time trajectories against dynamic envelopes, applies control commands, and performs continual health aggregation.

This structure places vehicle-specific capability adaptation at the interface between the core stack and the vehicle hardware. At stack initialization, the capability tuple $C_V$ is read and modules are instantiated or configured accordingly (e.g., SLAM vs. GNSS-RTK for localization, controller gains for different actuator dynamics).

Real-world deployments demonstrate the system's modularity and adaptability. For instance, a shuttle vehicle (EasyMile EZ10) with six Velodyne LiDARs and dual-axis steering, and a passenger car (Audi Q5) with different LiDARs, Ackermann steering, and higher dynamic limits both run the identical software stack, with only per-vehicle configuration changes (Ochs et al., 2024).

3. Formalization, Compositionality, and Safety

Capability-based architectures provide a mathematical foundation for module–vehicle compatibility and emergent property traceability. The formal definitions underpinning this approach are as follows:

• A module $M_i$ is compatible with vehicle $C_V = (S_V,\, A_V,\, D_V)$0 if $C_V = (S_V,\, A_V,\, D_V)$1, $C_V = (S_V,\, A_V,\, D_V)$2, and for all dynamic limits, $C_V = (S_V,\, A_V,\, D_V)$3 for each $C_V = (S_V,\, A_V,\, D_V)$4.
• Compositional integration across a fleet is achieved if, for a family $C_V = (S_V,\, A_V,\, D_V)$5 and a set of modules $C_V = (S_V,\, A_V,\, D_V)$6, $C_V = (S_V,\, A_V,\, D_V)$7 for all $C_V = (S_V,\, A_V,\, D_V)$8.
• All emergent properties, such as safety constraints or behavioral requirements, are traced from high-level capabilities down to software and hardware artifacts via formal correspondence maps, $C_V = (S_V,\, A_V,\, D_V)$9, between functional, software, and hardware views (Bagschik et al., 2018).

Empirical safety enforcement is achieved through explicit "guards" that monitor potential violations, stopping or replanning as soon as dynamic limits may be breached. Diagnostics modules aggregate health status at both module and capability levels, enabling both offline traceability and real-time safety validation (Ochs et al., 2024).

4. Capability Graphs, Monitoring, and Runtime Adaptation

A key feature of these architectures is the capability (or skill/ability) graph—an acyclic, often hierarchical, graph encoding both the composition and the runtime quality of system abilities (Nolte et al., 2017, Schubert et al., 2024). Each node represents a skill (what must be done) or ability (how well it can be done), and is annotated with performance metrics and state (e.g., "good," "probably good," "probably bad," "bad"). The dependencies encode horizontal composition (e.g., lateral and longitudinal control) and vertical mapping from capabilities to concrete functional blocks and down to hardware.

Online monitoring frameworks leverage this structure: expert-provided Bayesian networks compute the belief in the current health $S_V$0 of each capability, using both continuous measures (e.g., position standard deviation) and binary flags (e.g., sensor or actuator faults). These beliefs are then used to gate or select driving maneuvers, ensuring only actions with sufficient capability belief are attempted (Schubert et al., 2024).

As an illustrative example, the longitudinal "follow-speed" capability depends recursively on the health of the powertrain, braking system, and estimation filter. If a single power unit degradation is detected, the belief in "accelerate" drops, which propagates to "control," disabling "follow-speed" and allowing only the "stop" maneuver (Schubert et al., 2024).

5. Engineering Integration and Real-World Examples

The capability-based paradigm is widely applied across diverse vehicle types and operational settings:

• Robust Real-World Shuttles: The TCS-AD stack operated shuttles and passenger vehicles in urban deployments for thousands of kilometers without any safety driver interventions, with guard-trigger events averaging less than 0.2 per 10 km, and each event resulting in smooth, sub-second decelerations (Ochs et al., 2024).
• Centralized Software Integration: AUTOFRAME encapsulates each capability in a containerized module, enforces security and resource constraints, and supports dynamic over-the-air updates. Hardware abstraction layers ensure the same capability module can be deployed to different hardware configurations with only the adapter modified (Kirchner et al., 6 Mar 2025).
• Factory/Industrial AGVs: Industrial vehicles with manual override are integrated with a capability-based mode-switching supervisor. Safety-critical functions (e.g., manual-override response) are managed to yield sub-80 ms switching latency between autonomous and manual modes, even under variable load and fail-over scenarios (Iob et al., 2024).
• Competitive Environments: Modular capability-based design is critical for the high-performance requirements of autonomous racing, allowing hot-swap of faulted modules, distributed simulation, and fine-grained isolation in multi-node systems (Fontan-Costas et al., 3 Dec 2025).

A comparative table of selected real-world deployments is provided below:

Platform	Sensor Suite	Actuator Interface	Results/Findings
EZ10 Shuttle	6× VLP-16 LiDAR, GNSS-INS	Dual-axis, CAN-bus	2,000+ km, 0 safety interventions
Audi Q5	5× IbeoLux, RTK-GNSS, Cameras	Ackermann, CAN-bus	1,000+ km, always within limits
AGV	LiDAR, Camera, GPS, Encoders	CAN + manual override	<80 ms manual/autonomous switch

6. Development Process, Traceability, and Safety Compliance

Capability-based models serve as a bridge between high-level functional goals, safety engineering, and runtime operational assurance:

• During development, skill graphs are elaborated from use-cases and mapped to safety goals, which are refined into functional safety requirements per node (e.g., maximal lateral error for "follow hard shoulder"). This structure supports ISO 26262-compliant development, keeps hazardous scenario analysis aligned with observed system behavior, and provides artifacts for certification (Nolte et al., 2017).
• At runtime, the skill graph is instantiated as an "ability graph," and each node is dynamically annotated with current performance. Monitoring exploits traces and confidence estimates to trigger degraded modes or safe halt as soon as performance falls below specification.

This paradigm ensures traceability both horizontally (across function, software, and hardware) and vertically (from safety requirements down to monitorable metrics at module or hardware level) (Bagschik et al., 2018). Failure root-cause analysis and safe reconfiguration are supported by this explicit mapping.

7. Hybrid Control and Theoretical Guarantees

Capability orientation in architectural design facilitates the application of compositional safety proofs and hybrid control paradigms:

• Model-based approaches formalize each driving operation as a unique capability, often factorized into a finite set of "vistas" (e.g., road following, merging, intersection crossing). Each vista is handled by a two-phase policy: a "caution" phase mitigating risk (e.g., decelerating toward a limit), followed by a "progress" phase executing the maneuver under a precise clearance condition (Bozga et al., 2024).
• Concrete dynamic functions $S_V$1 (braking distance) and $S_V$2 (speed-control step) enable per-vehicle instantiation of policies using only the vehicle's dynamic capability tuple, directly enabling system-wide safety guarantees under mild visibility and timing assumptions.

Such architectures admit compositional safety theorems: if each vehicle always selects maneuvers provably safe with respect to its stated capabilities and context, then the entire multi-vehicle system exhibits collision avoidance and speed-limit compliance (under simple map separation and observation conditions) (Bozga et al., 2024).

• (Ochs et al., 2024) One Stack to Rule them All: To Drive Automated Vehicles, and Reach for the 4th level
• (Bagschik et al., 2018) A System's Perspective Towards an Architecture Framework for Safe Automated Vehicles
• (Schubert et al., 2024) A Prototypical Expert-Driven Approach Towards Capability-Based Monitoring of Automated Driving Systems
• (Nolte et al., 2017) Towards a Skill- And Ability-Based Development Process for Self-Aware Automated Road Vehicles
• (Iob et al., 2024) Integrated Hardware and Software Architecture for Industrial AGV with Manual Override Capability
• (Kirchner et al., 6 Mar 2025) AUTOFRAME -- A Software-driven Integration Framework for Automotive Systems
• (Fontan-Costas et al., 3 Dec 2025) A Modular Architecture Design for Autonomous Driving Racing in Controlled Environments
• (Bozga et al., 2024) Safe by Design Autonomous Driving Systems