2. EyeQ平台与感知软件架构
Mobileye EyeQ 系列是车载视觉感知领域最具代表性的专用 SoC 家族之一。理解 EyeQ 平台与感知软件架构，是后续讨论 OTA 升级与版本治理的前提：只有先看清“芯片里有什么、软件跑在哪一层、算法模块如何划分、软硬件如何协同”，才能判断一次 OTA 究竟会改动哪些对象、影响哪些功能、需要哪些验证。
一、EyeQ 芯片系列的演进逻辑
EyeQ 的演进并非单纯堆算力，而是围绕“感知任务复杂度”与“功能安全等级”两条主线展开。早期 EyeQ1/EyeQ2 面向单目前视 ADAS，主要承担车道线识别、前车检测、交通标志识别等任务，算力在 0.1～0.5 TOPS 量级，工艺为 90nm/65nm，功耗低、成本敏感。EyeQ3 是 Mobileye 真正大规模上车的节点，支持单目+雷达融合，算力约 0.25 TOPS，被广泛用于 AEB、ACC 等 L1 功能。EyeQ4 引入多核异构架构（MIPS CPU + 专用 VMP/MPC 加速器），算力提升到约 2.5 TOPS，可同时处理三路摄像头，支撑 L2 级功能。EyeQ5 面向 L2+/L3，采用 7nm 工艺，算力约 24 TOPS，支持多路高分辨率摄像头与深度学习网络，并强化了功能安全（ASIL-D 相关设计）与信息安全能力。EyeQ6 进一步细分出 EyeQ6L（轻量）与 EyeQ6H（高性能），算力覆盖数十至上百 TOPS，面向更高阶智能驾驶与多传感器融合。
从 OTA 视角看，这一演进带来三个直接影响：其一，算力与内存增大，使“整包升级”逐渐被“分区/差分升级”取代；其二，异构核增多，使升级对象从单一固件扩展为 CPU 固件、加速器固件、DNN 模型、参数标定等多类资产；其三，功能安全等级提高，使升级过程必须满足回滚、校验、断电保护等约束。
二、感知软件组成与算法模块划分
EyeQ 上的感知软件通常可分为四层。最底层是固件与驱动层，包括芯片启动固件、外设驱动、摄像头输入接口（MIPI CSI-2）驱动、内存管理与中断服务。其上是感知基础层，负责图像预处理：去噪、去畸变、白平衡、HDR 合成、金字塔缩放等，为上层算法提供规范化输入。再上是算法模块层，这是感知软件的核心，通常按任务划分为检测、分割、跟踪、测距、融合等模块。最上层是应用与输出层，将感知结果封装为车辆控制可用的目标列表、车道线方程、可行驶区域、语义地图等，并通过 CAN/Ethernet 输出。
算法模块的划分方式直接决定 OTA 的粒度。以典型前视感知为例，可划分为：
- 目标检测模块：车辆、行人、骑行者、交通标志，输出 2D 框与类别置信度；
- 车道线模块：输出车道线三次多项式系数、车道宽度、曲率；
- 可行驶区域/语义分割模块：输出逐像素或栅格化区域；
- 跟踪与预测模块：对检测结果做时序关联，输出目标 ID、速度、加速度；
- 测距与标定模块：结合相机内外参、地面假设，输出目标距离；
- 融合模块：将视觉结果与雷达、IMU、轮速等信号融合。
这些模块在 EyeQ 上并非全部以独立进程运行，而是常被编译为若干可独立加载的二进制或模型文件。例如 DNN 模型通常以 .bin 或专用格式存放，标定参数以 .json/.xml 存放，算法逻辑以动态库或固件形式存在。OTA 系统必须能识别“哪个文件属于哪个模块”，才能做到精准升级。
三、软硬件协同关系
EyeQ 的软硬件协同体现在三个层面。第一是数据通路协同：摄像头经 CSI-2 进入 ISP，ISP 输出至 VMP（向量微处理器）做预处理，再送入 MPC（多核加速器）或 DNN 加速器执行网络推理，最后由 CPU 做后处理与输出。第二是内存与带宽协同：感知算法对带宽敏感，图像金字塔、特征图、中间张量需要在片上内存与外部 DDR 之间调度，升级若改变模型输入尺寸或层数，可能引发带宽与延迟变化。第三是安全协同：功能安全机制（如锁步核、ECC、看门狗）与感知软件的健康监控、故障降级策略相互配合，OTA 升级必须保证这些机制在升级前后一致有效。
四、OTA 影响面分析
基于上述架构，一次 OTA 的影响面可从四个维度评估。第一，升级对象维度：是固件、驱动、算法库、DNN 模型还是标定参数？不同对象的校验方式、回滚策略、断电保护要求不同。第二，功能维度：升级是否影响 AEB、ACC、LKA 等已认证功能？若影响，需重新做功能安全与法规验证。第三，资源维度：新版本是否增大内存占用、算力需求或带宽？若超出余量，可能导致帧率下降或功能降级。第四，兼容维度：新软件是否与当前整车其他 ECU、传感器固件、标定数据兼容？
下面这张图以 EyeQ 平台为对象，展示从摄像头输入到车辆输出的感知信号链，以及各层对应的 OTA 可升级资产与影响面，帮助建立“升级对象—信号链位置—影响范围”的对应关系。
五、从架构到版本治理的衔接
把上述内容落到版本治理，可以得到一个基本判断：EyeQ 平台的 OTA 不是“替换一个文件”，而是“在一条分层信号链上替换若干资产，并保证替换后整条链的功能、资源与安全约束仍然成立”。因此，版本号不能只标在整包上，而应细化到固件版本、ISP 参数版本、算法库版本、DNN 模型版本、标定版本等子项。只有子项版本清晰，才能在出现问题时快速定位是“模型换了”还是“标定漂了”，也才能支持差分升级与精准回滚。
例如，某次升级只更新了 DNN 模型权重，但未更新 ISP 参数，那么图像输入分布不变，模型精度变化可单独评估；若同时更新了 ISP 的 HDR 合成参数，则输入分布改变，模型精度评估必须与 ISP 版本绑定。这种“版本组合”意识，正是 EyeQ 感知软件 OTA 与版本治理的核心。