---
title: Capability-Based Architecture for Automated Vehicles
url: https://www.emergentmind.com/topics/capability-based-architecture-for-automated-vehicles
type: topic
---

# Capability-Based Architecture for Automated Vehicles

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 [2404.02645].

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 [2404.02645]:

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 [2404.02645].

## 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 $V$ if $S_{\mathrm{req}} \subseteq S_V$, $A_{\mathrm{req}} \subseteq A_V$, and for all dynamic limits, $D_{\mathrm{req}}(j) \leq D_V(j)$ for each $j$.
- Compositional integration across a fleet is achieved if, for a family $\{V_1, ..., V_p\}$ and a set of modules $\{M_1, ..., M_q\}$, $\mathrm{Req}(M_j) \subseteq C_{V_i}$ for all $i, j$.
- 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, $\kappa_{F/S/H}$, between functional, software, and hardware views [1804.07020].

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 [2404.02645].

## 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 [1708.02532, 2404.16502]. 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 $b_i$ 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 [2404.16502].

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 [2404.16502].

## 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 [2404.02645].
- **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 [2503.04928].
- **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 [2408.12499].
- **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 [2512.03886].

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 [1708.02532].
- 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) [1804.07020]. 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 [2405.11995].
- Concrete dynamic functions $B(v)$ (braking distance) and $C(v, VL)$ (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) [2405.11995].

## References

- [2404.02645] One Stack to Rule them All: To Drive Automated Vehicles, and Reach for the 4th level
- [1804.07020] A System's Perspective Towards an Architecture Framework for Safe Automated Vehicles
- [2404.16502] A Prototypical Expert-Driven Approach Towards Capability-Based Monitoring of Automated Driving Systems
- [1708.02532] Towards a Skill- And Ability-Based Development Process for Self-Aware Automated Road Vehicles
- [2408.12499] Integrated Hardware and Software Architecture for Industrial AGV with Manual Override Capability
- [2503.04928] AUTOFRAME -- A Software-driven Integration Framework for Automotive Systems
- [2512.03886] A Modular Architecture Design for Autonomous Driving Racing in Controlled Environments
- [2405.11995] Safe by Design Autonomous Driving Systems

Source: https://www.emergentmind.com/topics/capability-based-architecture-for-automated-vehicles