汽车软件架构正在从“每个 ECU 各管一摊”转向可发现、可组合、可持续演进的服务体系。AAOS SDV 负责把车内非安全关键能力抽象为服务，Nexus SDV 连接车辆与云端，Bigtable 承接高频遥测，Gemini 与 Agent Development Kit（ADK）则把数据分析推进到推理和行动阶段。真正的变化不只是车辆联网，而是让车辆成为能够感知上下文、调用受控能力并主动提供服务的计算节点。
车端的关键不是大屏，而是服务解耦
传统车载软件经常与特定 ECU、供应商协议和硬件生命周期绑定。空调、车窗、座椅、照明和诊断数据可能分别落在不同管线中，跨系统功能因此需要大量定制集成。
AAOS SDV 引入的方向是面向服务架构：把里程表、HVAC、天窗、电动座椅、电动车窗等资源表达为可发现的服务，并暴露运行状态。上层应用或智能体不必直接理解某块 ECU 的物理实现，而是面向稳定的服务契约工作。
这种解耦带来三项直接收益：
- 硬件尚未就绪时，可以通过 Android Cuttlefish 在云端构建数字孪生，模拟高频传感器流并验证服务行为。
- 非安全域服务可以脱离主信息娱乐系统运行，使停车后的远程监控不必持续唤醒整套座舱计算平台。
- 多模态智能体可以通过服务发现层理解车辆具备哪些能力，再对空调分区、车窗或氛围灯等非安全关键功能发起受控调用。
这里必须划清边界：服务发现不等于无限制执行。转向、制动、动力控制等安全关键域需要独立的实时控制、功能安全认证和硬件级保护，不能把大模型输出直接接到执行器上。
Bigtable 如何承接遥测数据洪流
车辆遥测同时具有高写入量、时间序列、字段稀疏和传感器持续演进等特点。一辆车可能上报电池温度、振动、转速、制动压力和液位，另一车型又增加新的电机或传感器。如果为每次车型变化重建固定关系模型，数据平台会迅速变成新的瓶颈。
Bigtable 的稀疏行模型适合容纳不断变化的传感器集合，并可按车辆和时间组织写入。来源摘要还强调了 Continuous Materialized Views（CMV）的作用：把平均电池温度、振动滚动值或车队扭矩分布等指标提前计算在存储层附近，减少每个检测任务重复扫描原始数据的成本。
可以将数据路径拆成四层：
- AAOS SDV 与 Nexus SDV 在车端发现、映射并管理车辆服务。
- 车辆通过 NATS 接口发送标准化遥测事件。
- 云端消费程序校验事件并写入 Bigtable，分析任务读取原始数据或预计算聚合。
- 异常检测模型产生结构化信号，Gemini 驱动的智能体结合里程、车型、维修记录和行程安排决定后续动作。
BigQuery 更适合跨车队分析、报表和离线探索；Bigtable 则承担高吞吐在线遥测与低延迟按键查询。两者不必互相替代，可以分别服务在线路径和分析路径。
可以这样实践：用 NATS 跑通最小遥测链路
下面是一个本地可运行的缩小版示例。它不代表 Nexus SDV 的实际 SDK，也没有连接真实车辆或 Bigtable；它假设车辆网关已经把服务数据规范化为 JSON，用 NATS 模拟车云接口，并在消费者端执行简单的电池温度滑动窗口检测。
准备 Docker 和 Python 3.10 以上版本，然后启动 NATS：
docker run --rm --name sdv-nats -p 4222:4222 nats:2.10-alpine
另开终端安装客户端：
python -m venv .venv
. .venv/bin/activate
pip install nats-py==2.9.0
创建 vehicle.py，模拟车辆每秒发布一次遥测：
import asyncio
import json
import random
import time
import nats
async def main() -> None:
nc = await nats.connect("nats://127.0.0.1:4222")
vehicle_id = "demo-vehicle-001"
for sequence in range(30):
temperature = 34.0 + random.uniform(-0.8, 0.8)
if sequence >= 22:
temperature += 8.0
event = {
"vehicle_id": vehicle_id,
"service": "battery_thermal",
"timestamp_ms": int(time.time() * 1000),
"sequence": sequence,
"metrics": {
"pack_temperature_c": round(temperature, 2),
"state_of_charge_pct": round(72 - sequence * 0.2, 1),
},
}
await nc.publish(
f"vehicles.{vehicle_id}.telemetry",
json.dumps(event).encode("utf-8"),
)
await nc.flush()
print("published", event)
await asyncio.sleep(1)
await nc.drain()
if __name__ == "__main__":
asyncio.run(main())
创建 monitor.py，订阅遥测并生成结构化告警：
import asyncio
import json
from collections import defaultdict, deque
from statistics import fmean
import nats
WINDOW_SIZE = 8
ALERT_THRESHOLD_C = 39.0
windows: dict[str, deque[float]] = defaultdict(
lambda: deque(maxlen=WINDOW_SIZE)
)
async def main() -> None:
nc = await nats.connect("nats://127.0.0.1:4222")
async def handle(message) -> None:
event = json.loads(message.data)
vehicle_id = event["vehicle_id"]
temperature = float(event["metrics"]["pack_temperature_c"])
window = windows[vehicle_id]
window.append(temperature)
average = fmean(window)
print(vehicle_id, "temperature=", temperature, "average=", round(average, 2))
if len(window) == WINDOW_SIZE and average >= ALERT_THRESHOLD_C:
alert = {
"type": "battery_temperature_anomaly",
"vehicle_id": vehicle_id,
"average_temperature_c": round(average, 2),
"recommended_action": "inspect_thermal_system",
}
print("ALERT", json.dumps(alert))
await nc.subscribe("vehicles.*.telemetry", cb=handle)
print("monitoring telemetry; press Ctrl+C to stop")
await asyncio.Event().wait()
if __name__ == "__main__":
try:
asyncio.run(main())
except KeyboardInterrupt:
pass
先运行消费者，再运行车辆模拟器：
python monitor.py
python vehicle.py
生产环境中可以把 monitor.py 的内存窗口替换为 Bigtable 写入与 CMV 聚合，把告警发布到独立主题。后续智能体只消费结构化告警，不直接处理未经筛选的全部传感器流。这样既减少模型成本，也能保留确定性的规则、审计日志和重放能力。
建议至少在遥测事件中保留 vehicle_id、服务名、事件时间、序列号、模式版本和质量标记。仅有接收时间无法正确处理车辆离线缓存、乱序上报和重复投递。
预测性维护如何进入行动阶段
预测性维护不是“检测到温度高就通知车主”这么简单。完整链路需要完成信号聚合、异常判断、上下文推理和受控执行。
例如，模型发现电池温度曲线持续偏离同车型基线后，智能体可以结合车辆里程、维修历史、未来行程和附近服务中心容量，决定是继续观察、提示驾驶员预约，还是提前准备配件。通知可回到 AAOS 车机、移动应用或服务中心工作台。
智能体输出应当是受约束的结构化决定，而不是可以任意执行的自然语言。可以定义类似下面的动作契约：
alert_type: battery_degradation
severity: medium
allowed_actions:
- notify_driver
- propose_service_slot
- create_diagnostic_case
requires_human_approval:
- order_replacement_part
forbidden_actions:
- modify_battery_control_parameters
- suppress_safety_warning
这种白名单模型能把“模型认为应该做什么”与“系统允许做什么”分开。对于 OTA 调整、配件下单等高影响动作，还应增加审批、幂等键、撤销策略和完整审计记录。
落地时先检查这几件事
Nexus SDV 提供了基于 Google Cloud、与 AAOS SDV 集成的端到端基础，并使用 NATS、Bigtable、BigQuery、Gemini Enterprise Agent Platform 等组件。其安全设计包括 mTLS、Google Cloud Certificate Authority Service、Private GKE 以及 Secure AI Framework（SAIF）相关措施。平台也针对 AAOS SDV 优化，同时保留与其他车辆框架集成的可能性。
OEM 在采用前仍应完成自己的架构评审：
- 明确安全域与非安全域边界，禁止生成式 AI 绕过车辆控制策略。
- 为每辆车签发可轮换、可吊销的身份凭证，并验证 mTLS 全生命周期。
- 设计事件模式版本、乱序处理、重复消费和车辆离线后的补传机制。
- 分开原始遥测、聚合特征、用户信息与维修数据的访问权限和保留周期。
- 同时评估误报与漏报，避免预测性维护频繁打扰用户，也避免遗漏高风险退化。
- 让所有智能体动作经过策略引擎，并为高影响动作保留人工确认。
这套架构的价值不在于给传统车联网再叠一层聊天界面，而在于建立一条从车内服务、实时数据到受控行动的统一路径。完成服务标准化、数据治理与安全边界后，AI 才可能从演示功能变成可靠的车辆能力。