1. 课程导入与全局认知

在智能驾驶量产项目中，Mobileye EyeQ 系列芯片（EyeQ4、EyeQ5、EyeQ6）承担着前视感知的核心计算任务。围绕这颗芯片运行的感知软件，并不是"一次刷写、终身不变"的固件，而是一个需要持续迭代、受控发布、可追溯回滚的软件资产。本课程要解决的，正是这类软件在OTA升级与版本治理两个维度上的工程问题。

先明确两个核心概念。所谓感知软件OTA，指的是通过空中下载方式，把新的感知算法包、参数标定文件、神经网络模型或配置项，安全地传输并激活到车端EyeQ芯片上运行的过程。它涉及传输、校验、写入、激活、验证五个关键环节。而版本治理，则是围绕"哪个版本、在哪些车上、处于什么状态、能否回退、由谁批准"这一整套元数据与流程的管理体系。二者关系可以这样理解：OTA是"把新版本送上车"的动作，版本治理是"确保送上去的版本是对的、可查的、可退的"的规则。

为什么这两件事在EyeQ平台上格外棘手？原因有三。第一，EyeQ的感知软件通常由Mobileye提供底层算法，Tier1或OEM在其上做集成与标定，形成"多层版本叠加"——芯片固件版本、EyeQ感知算法版本、主机厂标定参数版本、整车配置版本，四者必须严格匹配，任意一层错配都可能导致感知功能降级甚至失效。第二，感知软件直接关联AEB、LKA、ACC等安全功能，属于功能安全相关项，任何一次OTA都必须满足可回滚、可审计、可验证的要求。第三，车端算力与存储有限，OTA包体大、写入慢，升级过程往往需要车辆处于特定状态（如驻车、电量充足），这给批量推送带来现实约束。

本课程的学习路径，按照"认知—机制—实操—治理—复盘"五层递进展开。前几章建立EyeQ感知软件的整体架构与版本模型认知；中段深入OTA的传输协议、差分升级、签名校验、双分区切换等机制；随后进入实操层面，包括升级包制作、推送策略配置、车端日志判读、失败回滚演练；再往后是版本治理体系，涵盖版本命名规范、基线管理、灰度发布、合规审计；最后通过典型故障案例复盘，把前面所有知识串成一条完整的工程链路。

下面这张图给出了本课程要建立的全局认知框架：从EyeQ感知软件的版本构成，到OTA的完整信号链，再到版本治理的闭环控制，三者如何咬合在一起。

这张图传递的核心信息是：版本构成、OTA信号链、版本治理三者不是并列关系，而是咬合关系。版本构成决定了"要升什么"，OTA信号链决定了"怎么升上去"，版本治理决定了"升得对不对、退不退得回"。任何一环缺失，都会在量产阶段暴露为批量问题。

举个具体的工程场景来理解这种咬合。假设某OEM要推送一版新的AEB感知模型，版本号为 EQ5-PER-2.4.1，配套标定参数 CAL-AEB-2024-07。在版本治理层面，需要先确认这版模型对应的EyeQ固件最低版本是 FW-5.1.2，如果车端固件低于此版本，OTA包必须拒绝安装或先升级固件。在OTA信号链层面，推送时采用差分升级，包体从完整包的约 480MB 压缩到约 95MB，车端在驻车且电量高于 30% 时执行写入，写入完成后通过签名校验确认包完整性，再切换到备用分区激活。激活后，车端需要上报感知模块的自检结果——如果连续 3 个点火循环内 AEB 功能自检失败，则触发自动回滚到上一稳定版本。在版本治理层面，这次推送的批次号、覆盖车辆VIN列表、成功/失败数量、回滚数量，全部要记录到审计日志中，供后续追溯。

可以看到，一个看似简单的"推送新模型"动作，背后牵扯到版本匹配、传输优化、安全校验、状态判断、回滚决策、审计留痕六个层面的协同。这正是本课程要培养的工程能力：不是只会点"推送"按钮，而是理解每一步背后的约束与判断依据。

最后说明本课程对学习者的基础要求。你需要了解CAN/以太网通信的基本概念，知道什么是固件、什么是标定，最好有过一次车端软件升级的实操或观察经验。如果暂时没有，也没关系——课程中会用具体的版本号、包体大小、日志片段、回滚条件等真实工程对象来展开，帮助你建立直观认知。接下来的章节，我们将从EyeQ感知软件的架构与版本模型开始，逐层深入。