AI Skill Report Card

Justifying AV Taxi Infrastructure

A-83·Nov 8, 2026·Source: Web
14 / 15

Given a deployment scenario (city district, fleet size, service area), produce a parameter justification covering five domains:

  1. Curb & pickup/dropoff (PUDO) zones — count, spacing, dimensions
  2. Road/lane markings & signage legibility for sensor perception
  3. Charging/depot infrastructure — stall count, power capacity
  4. V2X / connectivity coverage — latency and redundancy requirements
  5. Operational Design Domain (ODD) boundary infrastructure — geofencing support, weather/lighting thresholds

For each parameter: state the recommended value, the driving constraint, and the calculation method. Never present a number without its derivation.

Example snippet:

PUDO zone spacing: 300–400 m in dense CBD areas. Driving constraint: average pedestrian walking tolerance (≤5 min / ~400m per FHWA ped studies) balanced against curb space scarcity. Calculation: service area (km²) × trip density (trips/km²/hr) → required PUDO throughput → zones = throughput / (avg dwell time⁻¹ × curb slots per zone).

Recommendation▾
Include an English-language example in addition to the Russian ones for broader accessibility/consistency, or clarify why Russian was chosen
14 / 15

Progress:

  • Step 1: Define deployment context (ODD, fleet size, demand density, climate)
  • Step 2: Derive curb/PUDO infrastructure parameters
  • Step 3: Derive perception-infrastructure requirements (markings, signage, lighting)
  • Step 4: Derive energy/depot infrastructure parameters
  • Step 5: Derive connectivity/V2X parameters
  • Step 6: Cross-check parameters against regulatory precedent (e.g., CPUC, NHTSA AV STEP, city AV pilot ordinances)
  • Step 7: Package as justification document with sensitivity notes

Step 1: Define Deployment Context

Collect/assume: service area size (km²), expected fleet size, trip density, street typology mix (arterial/collector/local), climate/weather profile, existing transit/curb regulation.

Step 2: Curb & PUDO Zones

  • Zone count = peak-hour trip volume / (zone throughput capacity)
  • Zone throughput = 3600s / (avg dwell time per vehicle, typically 30–90s)
  • Spacing derived from walkability standards (~250–400m urban, up to 800m suburban)
  • Dimensions: minimum 6.5m length per AV stall (accounts for conservative approach/departure buffers vs. 6m for human-driven)

Step 3: Perception Infrastructure

  • Lane marking retroreflectivity: ≥130 mcd/lux/m² (above MUTCD minimum of 100) to ensure camera/LiDAR redundant detection in rain/low light
  • Signage: standardized font/placement height consistency within ±10cm of MUTCD spec — AV perception models trained on standard geometry degrade with outliers
  • Lighting: minimum 10 lux at crosswalks/intersections for camera sensor performance in low-light ODD

Step 4: Charging/Depot

  • Stall count = fleet size × (avg daily charge time / operational hours) × utilization buffer (1.2–1.3x)
  • Power capacity (kW) = stall count × charger power rating × simultaneity factor (0.6–0.8 for staggered charging)
  • Depot siting: ≤15 min deadhead from service area centroid to minimize non-revenue miles

Step 5: Connectivity/V2X

  • Latency budget: ≤100ms round-trip for teleoperation fallback; ≤20ms for safety-critical V2I (signal phase/timing)
  • Coverage redundancy: dual-carrier or 5G + C-V2X overlap in ≥95% of ODD area
  • Teleoperation bandwidth: ≥10 Mbps uplink per concurrent assisted vehicle

Step 6: Regulatory Cross-Check

Validate against precedent frameworks (CPUC AV deployment decisions, SAE J3016 ODD taxonomy, local DOT curb management pilots). Flag any parameter deviating >20% from precedent and justify explicitly.

Step 7: Package

Deliver as a table: Parameter | Recommended Value | Constraint | Derivation | Sensitivity/Risk.

Recommendation▾
Add a brief note on handling missing/unavailable input data (e.g., unknown climate or demand figures) as an edge case
16 / 20

Example 1: Input: "Робо-такси сервис в центральном деловом районе площадью 8 км², пиковый спрос 1200 поездок/час, флот 150 машин."

Output:

Параметр: Количество зон PUDO
Значение: 24 зоны
Ограничение: пропускная способность одной зоны при среднем времени посадки 60с = 60 поездок/час
Расчёт: 1200 поездок/час / 60 поездок/час на зону = 20 зон, +20% буфер на неравномерность спроса = 24 зоны
Риск: при росте спроса >15% потребуется пересмотр

Параметр: Разметка полос (ретроотражательность)
Значение: ≥130 mcd/lux/m²
Ограничение: устойчивое распознавание камерами/LiDAR в дождь и сумерках
Расчёт: базируется на MUTCD минимуме 100 + 30% запас для AV-сенсорной деградации

Параметр: Зарядная инфраструктура
Значение: 45 зарядных стойл, 2.4 МВт пиковая мощность
Расчёт: 150 машин × (4ч зарядки / 20ч операционных) × 1.25 буфер = 37.5 → 45 стойл с запасом;
мощность = 45 × 75кВт × 0.7 коэффициент одновременности ≈ 2.4 МВт

Example 2: Input: "Пригородный маршрут, низкая плотность, зимний климат."

Output:

Параметр: Расстояние между зонами PUDO
Значение: 600-800 м
Ограничение: низкая плотность спроса не оправдывает частые зоны; приемлемо увеличение пешей доступности

Параметр: Минимальная освещённость перекрёстков
Значение: 15 люкс (выше городского стандарта в 10 люкс)
Ограничение: снежный покров снижает контраст для камерных сенсоров, требуется компенсация

Параметр: V2X резервирование
Значение: dual-carrier покрытие обязательно (не 95%, а 100% ODD)
Ограничение: сельская/пригородная зона имеет меньше вышек — выше риск потери связи при телеоперации
Recommendation▾
Provide a compact summary template table upfront in Quick Start so users see the full output shape before diving into derivations
  • Always tie a number to a named constraint (physical, regulatory, or demand-based) — never present "industry standard" without the underlying study/spec.
  • Build in buffers (15–30%) for demand variability and sensor degradation in adverse weather; state the buffer explicitly, don't hide it in the headline number.
  • Use ranges, not single points, when the underlying context (climate, density) is variable — collapse to a point value only once context is fixed.
  • Reference recognized frameworks (SAE J3016, MUTCD, NHTSA, CPUC) as anchors — this strengthens justification credibility to regulators.
  • Separate "hard constraints" (physics, safety) from "soft constraints" (cost optimization, UX) in the final deliverable.
  • Don't copy human-driven-vehicle infrastructure specs unchanged — AV sensor requirements (lighting, marking contrast, geometry consistency) are stricter.
  • Don't ignore weather/lighting ODD boundaries — infrastructure adequate in clear daylight may be insufficient and must trigger service suspension zones, not be "worked around."
  • Don't size depot/charging only for average demand — peak-hour and charge-cycle overlap drive real capacity needs.
  • Don't treat connectivity as binary (covered/not covered) — latency and bandwidth thresholds differ by use case (safety-critical V2I vs. teleoperation vs. fleet telemetry).
  • Don't omit sensitivity analysis — parameters derived from assumed demand/fleet size should state how much the recommendation shifts if inputs change ±20%.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
14/15
Examples
16/20
Completeness
17/20
Format
14/15
Conciseness
13/15