Technology

Where AREN sits in the software-defined vehicle.

A single model does not displace the safety architecture of a modern vehicle. It fits inside it. The diagram below is the shortest honest answer to “where does your thing run?”

AREN in the software-defined vehicle stackArchitectural diagram showing sensors feeding an automotive SoC, which runs a safety-certified hypervisor that partitions a certified safety domain from a non-safety domain where AREN executes. The safety domain drives actuation. A fleet cloud connects via dashed arrows.CameraLiDARRadarCAN busAutomotive SoCSafety domainCertified RTOSMonitoring & arbitrationNon-safety domainARENNPU / GPU partitionSafety-certified hypervisorDeterministic fallback logicVehicle actuationFleet cloudUpdates · curated scenes · evaluation

AREN runs in the non-safety partition. A certified RTOS owns arbitration and deterministic fallback. The fleet cloud is non-realtime.

Sensors

Camera, LiDAR, radar, and CAN bus feed a synchronized tensor stream into the SoC. AREN ingests all modalities natively rather than through a cascade of per-sensor networks.

On perception →

SoC and hypervisor

AREN runs inside the non-safety partition of a safety-certified hypervisor. The certified side owns arbitration and deterministic fallback; the learned side owns inference.

On integration →

AREN

A single 3-billion-parameter multimodal model replacing the classical detection → prediction → planning pipeline. One model, end-to-end.

The AREN technical overview →

Actuation and fleet

Control intent from AREN is arbitrated against the deterministic safety layer before reaching actuation. The fleet cloud handles updates, curated scene ingestion, and evaluation — never real-time inference.

On planning →