第 9 章：ADAS/自动驾驶系统交互

开篇段落

本章将深入探讨语音座舱系统与高级驾驶辅助系统（ADAS）及自动驾驶（AD）系统的集成。这不仅仅是技术上的简单连接，更是构建人机信任、确保驾驶安全、提升驾驶体验的核心环节。我们将讨论如何设计一个清晰、可靠且无干扰的交互边界，使语音助手成为一个称职的“智能副驾”，而非一个混乱的指令下发者或潜在的安全隐患。学习本章后，你将能够设计出语音系统与 ADAS 系统之间安全、高效的通信协议，理解在不同驾驶等级下，语音交互的优先级、信息呈现方式，并掌握构建可追溯、可审计的事件记录链路的关键技。

9.1 与策略/感知/定位模块信息边界

将一个非安全关键域（如信息娱乐 IVI，通常为 QM 或 ASIL-B 级别）的语音系统与一个安全关键域（ADAS/AD，通常为 ASIL-D 级别）相连，首要原则是建立一个坚固的信息防火墙 (Information Firewall)。语音系统绝不能直接控制车辆的横向或纵向运动（如转向、刹车）。其角色是作为 ADAS 状态的观察者和人类可理解信息的转译者，任何看似“控制”的交互，本质上都是向 ADAS 系统提交的“建议”或“偏好设置”。

核心架构原则：单向数据流、服务化接口与 ASIL 分解

最安全的架构是采用严格的单向数据流。ADAS 系统通过车载网络（如车载以太网）以发布/订阅模式，向 IVI 域广播其关键状态信息。语音系统作为订阅者，被动接收这些信息。两者之间通过一个专门的网关 (Gateway) ECU 进行隔离，该网关负责协议转换、消息过滤和安全审计，实现 ASIL 等级的分解。

+-----------------------------------+             +--------------------------------------+
|        ADAS / AD Domain           |             |         IVI / Cockpit Domain         |
|   (Safety-Critical, ASIL-D/C)     |             |   (Non-Critical, ASIL-B or QM)       |

|   (Safety-Critical, ASIL-D/C)     |             |   (Non-Critical, ASIL-B or QM)       |
|                                   |             |                                      |
|  [Perception] --> [Fusion]        |             |      [Voice Assistant / LLM]         |
|       ^               |           |             |                  ^                   |
|       |               v           |             |                  |                   |
|  [Sensors] <-- [Planning & Decision]|<=[Gateway]==| [Vehicle State Abstraction Layer]    |
|   (gPTP Sync)      (ASIL-D)       | (Firewall)  |                  ^                   |
|                       |           | (SOME/IP)   |                  |                   |
|                       v           |             |    [ADAS Info Service Subscriber]    |
|                    [Control]      |             |                                      |

+-----------------------------------+             +--------------------------------------+
          |                                                       |
          v                                                       | (User Voice Input/Output)
    [Actuators: Steering, Brake]                                  v
                                                                [User]

通信协议与网关职责:

协议选择: 面向服务的协议如 SOME/IP 或数据分发服务 DDS 是理想选择。它们支持服务发现、强类型接口（基于 Franca IDL 或等效工具定义）和 QoS 保证，远优于原始的 CAN 报文。
网关核心功能:
1. 协议隔离: 转换安全域的内部协议与 IVI 域的协议。
2. 白名单过滤: 只允许预先定义的、非安全关键的消息 ID 和服务通过。
3. 速率限制: 防止 IVI 域的异常流量（如 DDOS 攻击）冲击安全域。
4. 内容审查 (Sanitization): 对传入的“建议”数据进行合法性检查，例如，用户请求将巡航速度设为 200 km/h，网关可以直接拒绝该无效请求。

数据接口定义 (Protobuf 示例): 使用 Protobuf 定义强类型、可扩展的数据结构，是工业界的标准实践。

// adas_service.proto
syntax = "proto3";

// ADAS 系统对外广播的整体状态
message AdasState {
  Header header = 1; // 包含高精度时间戳
  repeated PerceivedObject objects = 2; // 感知到的物体列表
  CurrentPlan plan = 3; // 当前的规划意图
  LocalizationInfo localization = 4; // 定位与地图信息
  TakeoverRequest tor = 5; // 接管请求状态
}

// 规划意图
message CurrentPlan {
  enum Action {
    MAINTAIN_LANE = 0;
    LANE_CHANGE_LEFT = 1;
    OVERTAKE = 2;
    DECELERATE_FOR_OBSTACLE = 3;
  }
  Action action = 1;
  string reason_code = 2; // 如 "OVERTAKE_SLOW_VEHICLE"
  double time_to_completion_s = 3;
}

Rule-of-Thumb:

语音系统对 ADAS 的交互应遵循“观察，不命令；建议，不执行”的原则。信息防火墙是架构的非功能性核心，其设计和验证的优先级甚至高于功能本身。

9.2 车道/限速/障碍语义对话与播报

当语音系统获得了结构化的 ADAS 语义数据后，其核心任务是将冰冷的机器状态转化为有温度、易于理解的自然语言对话。这需要模型具备强大的情境感知 (Context Awareness) 和 意图解释 (Intent Interpretation) 能力，极大增强系统的透明度和用户的信任感。

实现机制：基于 RAG 的实时情境注入

这通常通过类似检索增强生成 (Retrieval-Augmented Generation, RAG) 的模式实现。当用户提问时，语音系统的后端服务会：

查询实时状态: 从车辆状态抽象层获取最新的 AdasState protobuf 消息。
构建动态 Prompt: 将析后的实时状态（如车辆速度、规划意图、前方障碍物）格式化为文本，与用户的提问、对话历史一起注入到一个精心设计的 Prompt 模板中。
LLM 生成回复: LLM 基于这个富含实时情境的 Prompt 生成自然、准确的回复。

精细化 Prompt Engineering 示例:

[SYSTEM]
你是车辆的智能副驾，你的回答必须冷静、精确，并基于以下提供的实时车辆数据。你的首要任务是解释车辆的行为，建立驾驶员的信任。

[VEHICLE CONTEXT]

- 当前车速: 95 km/h
- ADAS 模式: 智能巡航 + 车道保持
- 当前规划: {动作: 保持车道, 原因: 前方车辆速度稳定}
- 感知物体:
  - 物体1: {类型: 卡车, 距离: 80米, 相对速度: -2 km/h, 车道: 当前车道}
  - 物体2: {类型: 轿车, 距离: 120米, 相对速度: +15 km/h, 车道: 左侧车道}

[CONVERSATION HISTORY]
User: "前面那辆大车离我们好近啊。"
Assistant: "它和我们保持着大约80米的安全距，请放心。"

[CURRENT USER QUERY]
"我们为什么还不超车？"

[ASSISTANT'S RESPONSE]

LLM 基于此 Prompt 可能生成：“虽然左侧车道目前是通畅的，但由于我们与前方卡车的速度基本一致且保持在安全距离内，系统判断目前没有超车的必要。如果您希望超车，可以说‘帮我提速到110公里每小时’，系统会在安全时机执行。”

处理模糊性与主动澄清: 当用户指令模糊时（如“小心点！”），系统不应猜测。正确的做法是结合上下文进行澄清。

用户：“小心点！”
系统（检测到右侧有车辆汇入）：“您是指右侧正在汇入的白色轿车吗？我已经注意到并调整了车速，为它预留了空间。”

Rule-of-Thumb:

对话的核心是解释“为什么”（Why），而不仅仅是报告“是什么”（What）。一个好的 ADAS 语音交互，能将驾驶员从“乘客”心态转变为“监督者”心态，这对于 L2/L3 系统安全性至关重要。

9.3 接管请求/注意力管理/人因工程

在 L2/L3 级自动驾驶中，驾驶员状态监控（DMS）和接管请求（Takeover Request, TOR）是核心安全功能。语音系统在此扮演着不可或替代的补充角色，能够显著提升接管的成功率和安全性。

多模态、分级递进的接管请求 (Multi-modal, Escalating TOR): 一个健壮的 TOR 流程应是多模态、分级递进的，以应对不同程度的驾驶员分心情况。

           (TOR Triggered by ADAS)
                    |
                    v
+----------------------------------------+
| L1: Prompt (Graceful Handover)         |
| - Visual: "请准备接管" (Blue UI)       |
| - Audio: 温和提示音 + "前方路况复杂，请准备接管" |
+----------------------------------------+
                    | (If no response in T1, e.g., 5s)
                    v
+----------------------------------------+
| L2: Warning (Urgent Handover)          |
| - Visual: "立即接管" (Yellow, Flashing) |
| - Audio: 急促提示音 + "请立即接管方向盘！"  |
+----------------------------------------+
                    | (If no response in T2, e.g., 3s)
                    v
+----------------------------------------+
| L3: Emergency (Minimum Risk Maneuver)  |
| - Visual: "紧急！车辆即将执行风险最小化策略" (Red) |
| - Audio: 持续警报音 + 语音重复 + 安全带预紧 |
+----------------------------------------+

基于 DMS 的自适应注意力管理: 结合车内摄像头，语音系统可以从被动警告转变为主动干预。DMS 系统通常会输出一些量化指标，如：

PERCLOS: Percentage of Eyelid Closure over time.
Head Pose: 头部姿态角度。
Gaze Direction: 注视方向。

一个简化的疲劳/分心评分模型可以是： $S_{distraction} = w_1 \cdot \text{PERCLOS}_{avg} + w_2 \cdot \text{OffRoadGazeTime} + w_3 \cdot \text{YawnCount}$

当 $S_{distraction}$ 超过预设阈值 $\theta_1$ 时，触发 L1 语音提醒（“请保持专注”）。若超过更高阈值 $\theta_2$，则可以主动建议（“您看起来有些疲劳，是否需要开启醒神模式并导航到最近的服务区？”）。

人因工程 (Human Factors Engineering):

认知负荷: 所有语音交互都必须在设计时考虑其对驾驶员认知负荷的影响。在复杂的驾驶场景（如城市拥堵、恶劣天气）下，应自动降低语音交互的频率和复杂度。
措辞的确定性: 安全相关的语音指令必须是命令式的、清晰的、不容置疑的。避免使用“也许”、“可能”等模糊词汇。例如，用“立即刹车！”而不是“你可能需要刹车了”。

Rule-of-Thumb:

安全相关的语音交互，清晰性（Clarity）和确定性（Certainty）远比自然度（Naturalness）更重要。TOR 的语音提示应该像飞机上的驾驶舱告警一样，经过严格的人因工程学验证。

9.4 辅助驾驶中的语音先级与去干扰

当车辆处于辅助驾驶状态时，来自 ADAS 的信息播报拥有极高的优先级。必须建立一套严格的音频焦点（Audio Focus）管理机制，确保安全信息不会被娱乐信息所覆盖、延迟或削弱。这通常在操作系统音频子系统层面实现（如 Android Automotive 的 AudioPolicyService 或 QNX 的 io-audio）。

音频优先级与打断策略矩阵:

Priority | Audio Stream (Attribute) | Behavior vs. Lower Priority Streams
--------------------------------------------------------------------------------------
P0       | E-Call / Crash Alert     | Mute All: 立即静音所有其他音频，以最大音量播放
P1       | ADAS Takeover Request    | Mute All: 同上
P2       | ADAS General Alert       | Duck: 将其他流音量降至 10-20% (e.g., V_new = V_old * 0.15)
P3       | Navigation Guidance      | Duck: 将媒体/助理音量降至 20-30%
P4       | Phone Call (HFP/VoIP)    | Duck or Pause: 暂停或降低媒体音量
P5       | Voice Assistant TTS      | Duck or Pause: 暂停或降低媒体音量
P6       | Media (Music/Podcast)    | Base: 最低优先级，可被任意打断或 Ducking

实现机制: 当一个高优先级音频流请求播放时，音频策略管理器会：

查询当前所有活动流的优先级。
根据矩阵规则，向所有低于请求流优先级的音频会话发送指令（PAUSE, SET_VOLUME）。
在高优先级流播放结束后，恢复之前被中断或降低音量的流的状态。

动态去干扰策略 (Dynamic De-interference): 语音助手的“健谈度”应与驾驶模式和环境复杂度动态关联。

ADAS 激活时: 自动进入“专注模式”，禁用主动闲聊、新闻推送等非关键交互。
环境复杂度高时: （如传感器数据显示周围车辆密集、天气恶劣）进一步收紧交互策略，仅响应与驾驶任务直接相关的指令。

Rule-of-Thumb:

设计一个“静默是金 (Silence is Golden)”的式。当 ADAS 系统接管车辆或环境复杂时，语音助手应自动激活该模式，只允许最高优先级的语音交互通过。用户的任何主动交互都应被视为高优先级事件。

9.5 事件回放与责任链路记录

一旦发生事故或安全事件（SIs），能够回溯人机交互的全过程至关重要。这不仅是技术调试的需要，更是满足法律和监管要求（如 SOTIF - ISO 21448）的必要条件。

日志记录要点 (Black Box Logging): 系统需要一个类似飞行数据记录器的模块，记录与全局同步时钟（通过 gPTP/IEEE 802.1AS 在车载以太网实现）对齐的关键信息。

ADAS 状态: 模式切换（手动/辅助/自动），TOR 发出/取消/超时，MRM（Minimum Risk Maneuver）触发。
规划意图快照: 在关键时刻（如 TOR 前 5 秒，碰撞前 10 秒）记录 CurrentPlan protobuf 的完整内容。
HMI 输出:
- 播放的语音指令文本及音频文件 ID。
- 屏幕显示的视觉警报内容、颜色、时间。
- 警报音类型和播放时间。
驾驶员状态与输入:
- DMS 监测到的驾驶员状态（眼/头/面部特征向量）。
- 方向盘/踏板的物理输入。
用户语音指令: [高度隐私敏感] 必须在获得用户明确、可撤销的同意后才能记录。最佳实践是只在端侧记录转写后的文本、意图和置信度，而非原始音频。记录应加密存储，并有严格的访问控制。

责任链路 (Chain of Responsibility): 通过这些日志，可以清晰地重建事件序列，回答关键问题：

系统在 T-5.2s 检测到危险，并在 T-4.8s 发出 L1 TOR。
语音播报在 T-4.7s 开始，内容为“请准备接管”。
DMS 数据显示，在 T-5.0s 到 T-2.0s 期间，驾驶员视线偏离道路。
在 T-0.2s，驾驶员才开始有方向盘输入。这对于界定事故责任、改进系统 HMI 设计具有决定性意义。

Rule-of-Thumb:

日志记录的原则是“无可辩驳的可重现性 (Irrefutable Reproducibility)”。确保记录的信息足以让工程师和调查员在离线环境中复现整个交互场景。所有日志必须带有精确、同步的全局时间戳，并进行加密和防篡改处理。

本章小结

信息边界是基石: 语音系统与 ADAS 的集成必须通过严格的网关和单向数据流实现，并遵循 ASIL 分解原则，确保安全域不受侵犯。
对话的核心是“为什么”: 利用 RAG 等技术将 ADAS 的机器状态翻译成人类可理解的决策原因，是建立信任、提升系统透明度的关键。
安全交互需多模态和自适应: 接管请求和注意力管理必须结合视觉、听觉和触觉，并根据驾驶员状态进行分级和自适应调整，严格遵循人因工程原则。
优先级决定生死: 必须在系统层面实现严格的音频焦点管理，通过优先级矩阵确保安全信息永远会被阻塞或削弱。
日志是责任的保障: 详尽、时间同步且防篡改的事件日志是事故分析、系统迭代和满足法规要求的必要条件，同时必须严格遵守隐私保护法规。

常见陷阱与错误 (Gotchas)

数据延迟与不同步: 语音播报的信息是 500ms 前的 ADAS 状态，导致播报与现实不符，甚至在快速变化的路况中误导驾驶员。解决方案: 在消费 ADAS 数据时强制检查时间戳，为每个消息设置一个“生存时间(TTL)”。对于延迟过大的数据，要么丢弃，要么在播报时明确指出其不确定性（例如，“根据刚才的信息…”）。
“话痨”副驾与警报疲劳: 系统过于频繁地播报无关紧要的状态变化（如每次微小的速度调整），对驾驶员造成严重干扰和认知负荷，最终导致其忽略真正重要的警告。解决方案: 设计精细的播报策略，基于事件的“重要性”和“新颖性”进行滤。引入可配置的“简洁/详细”播报模式，并利用 DMS 判断驾驶员是否已注意到某个事件（如已注视危险源），从而避免不必要的重复提醒。
边界渗透与安全漏洞: 在快速迭代中，开发人员为了方便调试，在网关上添加了可以“绕过”安全策略的后门，并在量产版本中忘记移除，导致严重安全风险。解决方案: 实行严格的代码审查和架构设计评审。使用静态分析工具扫描代码，寻找潜在的非法跨域访问。定期进行渗透测试，模拟攻击者试图从 IVI 域控制车辆。
模糊指令的灾难性误解: 用户说“快点！”，在不同情境下可能意味着“加速”、“快点完成变道”或“快点播报导航”。如果系统错误理解并向 ADAS 发出“提高巡航速度”的建议，可能导致危险。解决方案: 建立一个风险评估模型。对于高风险领域的模糊指令（如涉及车辆动态控制），系统必须进行澄清式提问（“您是想让我提高巡航速度吗？”），在得到明确确认前，不执行任何操作。
测试与验证的噩梦: ADAS 交互场景组合爆炸，很难在实车测试中完全覆盖。例如，在传感器部分失效的情况下，测试 TOR 语音交互的有效性。解决方案: 大量投资于高保真的仿真平台，包括硬件在环（HIL）和软件在环（SIL）测试。通过自动化测试脚本注入各种故障和边缘场景，系统性地验证 HMI 在所有预期和非预期情况下的行为是否符合安全规范。