2. 功能安全与SOTIF基础
在Mobileye EyeQ这类面向自动驾驶与高级驾驶辅助系统（ADAS）的SoC开发中，安全讨论通常从两个标准同时展开：ISO 26262（功能安全，Functional Safety，FuSa）与ISO 21448（预期功能安全，Safety of the Intended Functionality，SOTIF）。两者不是替代关系，而是从不同“失效来源”出发，共同覆盖系统安全。理解它们的核心概念、术语、适用范围以及在EyeQ开发中的关系与差异，是后续所有验证活动的前提。
一、两个标准各自回答什么问题
ISO 26262的核心问题是：当系统发生故障（fault）时，能否把风险控制在可接受范围内？它关注的是电子电气系统的随机硬件失效与系统性失效，例如寄存器位翻转、总线通信错误、电源异常、软件逻辑缺陷等。其基本逻辑是：识别危害 → 评估ASIL等级 → 制定安全目标 → 分解安全需求 → 设计安全机制 → 验证与确认。
ISO 21448的核心问题则是：当系统没有发生故障，但功能本身的能力边界或场景理解不足时，是否仍可能产生不合理风险？它关注的是“无故障但功能不足”导致的危害，例如感知算法在逆光、雨雾、异形车辆、隧道出口等场景下漏检或误检。其基本逻辑是：定义预期功能 → 识别功能不足与触发条件 → 评估危害行为 → 定义改进措施 → 验证剩余风险。
一句话区分：ISO 26262管“坏了怎么办”，ISO 21448管“没坏但不够好怎么办”。
二、关键术语对照
两个标准共享一部分安全语言，但侧重点不同。下表给出在EyeQ开发中最常出现的术语对照，便于在需求、架构、测试用例中统一口径。
| 维度 | ISO 26262（FuSa） | ISO 21448（SOTIF） |
|---|---|---|
| 危害来源 | 故障（fault / failure） | 功能不足 + 触发条件 |
| 核心对象 | E/E系统、硬件、软件 | 预期功能、感知/决策/执行链路 |
| 风险度量 | ASIL A~D（严重度×暴露率×可控性） | 危害行为 + 场景覆盖 + 剩余风险 |
| 关键活动 | 安全目标、安全机制、FMEDA、DFA | 场景分析、触发条件识别、ODD边界验证 |
| 验证重点 | 故障注入、诊断覆盖率、安全机制有效性 | 场景测试、边缘案例、剩余风险论证 |
| 典型输出 | 安全案例（Safety Case） | SOTIF论证与剩余风险评估 |
三、适用范围与边界
ISO 26262适用于道路车辆中由E/E系统实现的与安全相关的功能，覆盖概念、系统、硬件、软件、生产运行、支持过程等全生命周期。它不适用于机械、液压等非E/E部分，也不直接处理“功能本身设计不足”的问题。
ISO 21448适用于那些“没有故障但可能因功能不足而产生危害”的驾驶自动化功能，尤其是依赖感知、融合、决策的功能。它不替代ISO 26262，也不覆盖纯机械失效或明显违反交通法规的误用。两者在ODD（运行设计域）边界、场景库、危害分析上存在大量交集。
四、在EyeQ开发中的关系与差异
EyeQ作为感知与计算平台，同时承载FuSa与SOTIF活动。其关系可以概括为：FuSa保证“平台在故障下仍可控”，SOTIF保证“平台在无故障时对场景理解足够充分”。两者在开发流程中并行推进，但在分析对象、证据形式和验证方法上有明显差异。
例如，EyeQ内部的安全岛、锁步核、ECC、看门狗、总线保护等属于FuSa范畴；而感知算法在夜间、逆光、雨雾、遮挡、异形目标下的漏检/误检分析，则属于SOTIF范畴。FuSa关注“故障是否被检测并进入安全状态”，SOTIF关注“功能在真实场景中的表现是否满足预期”。
五、开发中的协同要点
在EyeQ项目中，FuSa与SOTIF并非各自独立。危害分析与风险评估（HARA）会同时识别故障类危害与功能不足类危害；安全需求会同时包含“故障检测与响应”和“场景性能边界”；验证活动会同时包含故障注入与场景测试。差异在于：FuSa的证据更偏向“机制是否有效”，SOTIF的证据更偏向“场景是否覆盖、剩余风险是否可接受”。
实践提示：在EyeQ需求文档中，建议为每条安全需求标注来源（FuSa / SOTIF / 两者），并明确对应的验证方法。例如“感知在逆光下漏检率”属于SOTIF，“感知模块通信CRC错误检测”属于FuSa。这样可以避免在评审时把两类问题混为一谈。
常见误区：认为“通过了ISO 26262就安全了”。实际上，ISO 26262无法覆盖感知算法在真实场景中的功能不足。EyeQ的感知链路必须同时开展SOTIF活动，否则会出现“无故障但误判”的风险缺口。
总结来看，ISO 26262与ISO 21448在EyeQ开发中分别对应“故障安全”与“功能充分”两条主线。前者以ASIL和故障注入为核心，后者以场景和触发条件为核心。两者共享危害分析与安全论证框架，但在分析对象、证据形式和验证方法上各有侧重。只有把两者放在同一安全案例中协同论证，才能形成对EyeQ平台完整的安全覆盖。