4. EyeQ软件安全架构解析
EyeQ 作为面向 ADAS/AD 的 SoC，其软件安全架构不是“在应用层加几个检查”那么简单，而是从芯片启动到应用任务执行的一条纵向安全链。理解这条链，关键在于回答四个问题：哪些软件层承担安全职责、每层部署什么安全机制、不同安全等级的任务如何分区与隔离、以及整车安全目标如何逐级分配到具体软件模块。本节围绕这四个问题展开，并给出可对照的架构视图。
一、EyeQ 上的安全相关软件层
从下往上，EyeQ 软件可划分为若干承担安全职责的层次。最底层是硬件安全基础，包括锁步 CPU 核、ECC 保护的 SRAM、内置自检（BIST）、看门狗、时钟与电压监控等；这些由芯片安全手册定义，是软件安全机制的物理前提。其上是启动与固件层，负责上电自检、镜像校验、安全启动链和基础驱动初始化。再往上是实时操作系统与调度层，EyeQ 通常运行符合功能安全要求的 RTOS（如基于 AUTOSAR Classic 或专用安全内核），提供任务调度、内存保护、时间监控等服务。其上是安全中间件层，包括安全通信、诊断、E2E 保护、安全状态管理等。最上层是感知、融合、规划等应用功能，其中与安全相关的部分需按 ASIL 等级开发。
需要强调的是，EyeQ 的独特之处在于其视觉处理加速器（如 EyeQ 系列中的 VMP、PMA 等）与 CPU 协同工作。安全相关软件层必须覆盖这些异构单元：加速器本身可能不具备完整锁步能力，因此需要软件层面的结果合理性检查、冗余计算或时间监控来补偿。
二、核心安全机制及其部署位置
EyeQ 软件安全机制可归纳为几类，每类都有明确的部署位置和触发条件：
- 安全启动与镜像校验：上电后由 Boot ROM 校验一级引导加载程序的签名，逐级建立信任链。若校验失败，系统进入安全状态或受限模式，不启动应用。
- 运行时自检：包括 CPU 逻辑 BIST、RAM March 测试、锁步比较器周期性检查。通常在启动阶段执行完整自检，运行中以背景方式执行部分自检。
- 内存保护与分区：通过 MPU/MMU 为不同安全等级的任务划分地址空间，防止低等级任务写入高等级任务的数据区。
- 时间与执行监控：看门狗、程序流监控（如基于检查点的执行序列验证）、截止时间监控，用于发现任务超时、死循环或执行顺序异常。
- 数据完整性保护：对安全相关数据采用 E2E 保护（CRC、计数器、超时），对存储数据采用 ECC 或冗余存储。
- 安全状态管理：当检测到故障时，根据故障等级执行降级、切换冗余通道或进入安全状态，并记录 DTC。
这些机制并非孤立存在，而是通过安全架构串联成一条“检测—反应—记录”的闭环。下图给出 EyeQ 软件安全架构的层次与机制部署关系，重点表现各层之间的依赖方向和安全机制的落点。
三、分区与隔离策略
EyeQ 上同时运行安全相关任务和非安全任务，隔离是防止故障传播的关键。隔离策略通常从三个维度实施：
空间隔离：利用 MPU/MMU 为每个分区分配独立的地址空间。例如，ASIL-D 的融合任务运行在受保护分区，QM 的显示或日志任务运行在普通分区。任何跨分区访问必须经过受控接口，且接口本身需做数据校验。空间隔离的目标是：即使 QM 分区出现野指针或内存越界，也不会破坏 ASIL-D 分区的代码和数据。
时间隔离：通过调度表或时间分区机制，为不同安全等级的任务分配固定的时间窗口。安全任务在其窗口内独占 CPU，非安全任务不得抢占。时间隔离可防止低优先级任务长期占用 CPU 导致安全任务超时。EyeQ 的 RTOS 通常支持基于时间触发（TT）的调度配置，安全任务以固定周期执行，非安全任务填充剩余时间片。
执行隔离：安全任务与非安全任务不共享可写数据区，通信通过消息队列或共享内存的只读快照完成。对于必须共享的数据，采用 E2E 保护或双区冗余。此外，安全任务的关键变量应避免与 QM 任务放在同一缓存行，以减少干扰。
四、软件安全需求分配
安全需求分配是把整车安全目标（如“避免误制动”）逐级分解到 EyeQ 软件模块的过程。分配不是简单贴标签，而是建立“安全目标—功能安全需求—技术安全需求—软件安全需求”的追溯链。以“避免误制动”为例：整车安全目标要求制动输出不得在无目标时激活；功能安全需求分配给感知和融合模块，要求目标确认需满足多帧一致性；技术安全需求进一步要求融合模块对感知输入做合理性检查；软件安全需求则落到具体函数：在融合输出前，检查目标置信度、距离变化率和时间戳连续性，任一不满足则抑制输出。
在 EyeQ 上，软件安全需求通常按模块分配，并标注 ASIL 等级、验证方法和失效反应。下表给出一个简化的分配示例，用于说明分配粒度与字段。
| 软件模块 | 安全需求示例 | ASIL | 验证方法 | 失效反应 |
|---|---|---|---|---|
| 感知目标确认 | 连续 3 帧同一目标置信度 ≥ 0.85 才输出 | ASIL-B | 故障注入 + 场景回放 | 抑制目标输出 |
| 融合输出检查 | 输出前校验时间戳偏差 ≤ 20 ms | ASIL-D | 边界值测试 + 时间监控 | 切换冗余通道 |
| 制动指令生成 | 指令需带 E2E CRC 和滚动计数器 | ASIL-D | E2E 协议测试 | 丢弃指令并报 DTC |
| 安全状态管理 | 检测到不可恢复故障后 100 ms 内进入降级模式 | ASIL-D | 故障注入 + 计时测量 | 进入安全状态 |
分配完成后，需要验证每条软件安全需求都有对应的实现和测试用例，且追溯链完整。EyeQ 项目通常使用需求管理工具维护追溯矩阵，并在集成测试阶段检查覆盖率。若某条需求无法分配或无法验证，应回到架构层重新设计，而不是降低要求。
五、架构落地的关键检查点
在实际项目中，EyeQ 软件安全架构的落地效果可通过几个检查点快速判断：安全启动链是否完整且不可绕过；各安全机制是否有明确的触发条件和反应时间；分区边界是否与 ASIL 等级一致；跨分区通信是否全部经过校验；安全需求是否逐条追溯到代码和测试。这些检查点不追求形式上的完整，而是确保架构在故障发生时真正能“检测到、反应快、不扩散”。
综上，EyeQ 软件安全架构的核心是“分层部署、分区隔离、需求追溯”。安全相关软件层从硬件基础到应用功能形成纵向链条，安全机制在每层有明确落点，分区与隔离防止故障跨等级传播，安全需求分配则保证每条要求都有实现和验证。理解这四者的关系，才能在后续的 SOTIF 验证和故障注入测试中有的放矢。