4. OTA在EyeQ感知软件中的典型场景

EyeQ平台上的感知软件并不是一个单一可执行文件，而是由基础固件、感知运行时、神经网络模型、标定参数、配置策略以及安全组件共同构成的软件集合。OTA（Over-The-Air）升级在EyeQ感知软件中的价值，正是让这些不同层次、不同更新节奏的组件能够以受控方式完成替换或增量更新。理解OTA的典型场景，关键不是记住六个名词，而是看清每类升级在“更新对象、影响范围、验证重点、回滚代价”上的差异。

一、六类场景的更新对象与影响面

功能升级通常面向感知能力本身，例如新增交通锥桶识别、扩展可行驶区域输出、增加对特定车道线类型的支持。它往往同时涉及感知运行时逻辑、后处理配置，甚至引入新的模型文件，因此影响面较大，验证需要覆盖新功能与既有功能的兼容性。

性能优化不改变感知语义，而是降低时延、减少CPU/加速器占用或改善内存峰值。典型做法包括算子融合、模型量化、后处理并行化、缓存策略调整。这类升级的验证重点是性能指标与精度不退化，而不是新功能是否出现。

缺陷修复针对已确认的感知异常，例如特定光照下误检、雨雾场景漏检、时间戳对齐错误或某类目标跟踪ID跳变。修复包通常较小，但必须能复现原缺陷并证明修复有效，同时防止引入回归。

标定更新面向摄像头内外参、安装角度、畸变参数或感知与车辆坐标系的转换关系。标定数据一旦变化，会影响所有依赖该摄像头的感知输出，因此必须与车辆配置、镜头批次、安装工装严格绑定，不能跨配置误刷。

模型替换是EyeQ感知OTA中最敏感的场景之一。模型文件体积大、推理行为变化复杂，且可能改变输出分布。替换时不仅要校验模型哈希与签名，还要确认模型与运行时算子版本、输入尺寸、量化方式匹配。

安全补丁分发则面向漏洞修复、密钥轮换、通信协议加固或启动链安全增强。它可能不直接改变感知精度，但一旦失败会导致设备无法启动或无法建立安全通道，因此必须支持A/B分区、原子切换和失败回滚。

二、功能升级：从“能识别”到“可交付”

功能升级的OTA包通常包含三部分：感知运行时的新逻辑、后处理配置以及可能的新模型。以新增“施工区锥桶检测”为例，升级包中会包含锥桶检测头模型、锥桶类别映射表、输出阈值配置以及对应的后处理融合规则。升级前需要确认当前EyeQ固件版本是否支持新模型所需的算子集；若不支持，则必须先升级运行时或固件，再升级模型，不能颠倒顺序。

功能升级的验证不能只看新功能是否出现，还要检查原有车道线、车辆、行人输出是否发生偏移。一个实用的做法是：在升级前后分别采集同一段路的感知输出，对比目标数量、位置误差和跟踪ID连续性。若新功能开启后原有目标漏检率上升超过预设阈值，则说明新逻辑与旧逻辑存在资源竞争或阈值冲突，需要回退或调整配置。

三、性能优化与缺陷修复：指标驱动与复现驱动

性能优化类OTA的验收标准是量化的。例如某次优化将单帧感知时延从42ms降至35ms，同时mAP下降不超过0.3个百分点。升级包中可能只替换了后处理动态库或量化后的模型文件。验证时需要在目标EyeQ型号上跑固定回放集，记录每帧耗时、CPU占用、内存峰值和精度指标，确认优化没有以牺牲关键场景为代价。

缺陷修复类OTA则强调“可复现、可验证”。假设某版本在隧道出口强光下出现车道线误检，修复包可能调整了曝光补偿与车道线置信度阈值。验证时必须使用能复现该缺陷的回放数据，确认修复后误检消失，同时检查正常光照、夜间、雨天等场景没有回归。缺陷修复包通常较小，但版本号必须严格递增，避免与旧包混淆。

四、标定更新：绑定关系比参数本身更重要

标定更新是OTA中最容易被低估的场景。摄像头内参、外参、畸变系数一旦变化，感知输出的物理含义就会改变。因此标定包不能只包含参数文件，还必须包含适用的车辆配置标识、镜头批次、安装工装版本和生效条件。升级时，OTA代理需要先读取车辆当前配置，与标定包中的绑定条件比对，只有匹配时才允许写入。

标定更新后的验证应关注：车道线在图像中的位置是否与车辆坐标系一致、目标距离估计是否发生系统性偏移、AEB或LKA等下游功能是否出现异常触发。若标定参数写错，感知可能仍然“有输出”，但输出在物理上是错误的，这类问题比完全无输出更危险。

五、模型替换：哈希、算子与量化三重匹配

模型替换是EyeQ感知OTA中风险最高的操作之一。一个可用的模型替换流程至少包含以下检查：模型文件哈希与签名验证、模型输入尺寸与运行时配置一致、算子版本与当前推理引擎兼容、量化方式与加速器支持匹配。任何一项不匹配都可能导致推理失败、输出异常或性能骤降。

实际执行时，建议采用A/B分区策略：新模型写入备用分区，设备重启后从备用分区加载并运行自检。自检内容包括模型加载成功、推理时延在预期范围、输出张量形状正确、典型回放帧的检测结果与基准偏差在允许范围内。只有自检通过，才将备用分区标记为可启动；否则回滚到原分区。

六、安全补丁分发：原子性与不可回滚性

安全补丁分发与普通功能升级的最大区别在于：它必须支持原子切换，且通常不允许回滚到存在漏洞的旧版本。EyeQ平台上的安全补丁可能涉及启动链校验、密钥存储、通信协议或权限控制。升级过程中若断电或通信中断，设备必须能够恢复到可用状态，而不是变砖。

因此安全补丁的OTA设计需要包含：双分区镜像、启动计数器、签名验证、失败自动回退到最近可用分区，以及防回滚版本号。升级完成后，设备应上报新的安全版本号，云端记录该车辆的补丁状态。若某车辆长时间未完成安全补丁升级，应在版本治理策略中标记为高风险并限制其使用新功能。

把这六类场景放在同一套版本治理体系中，才能避免“一个OTA包打天下”的粗放做法。每类场景应有独立的版本号规则、验证清单、回滚策略和灰度节奏。功能升级和模型替换适合小范围灰度后再全量；性能优化和缺陷修复可以按批次推进；标定更新必须与车辆配置强绑定；安全补丁则应尽快覆盖并持续跟踪未完成车辆。只有场景与治理策略一一对应，EyeQ感知软件的OTA才能真正做到可控、可验证、可回退。