摘要：智能汽车的安全合规体系由功能安全(ISO 26262)、预期功能安全(SOTIF)和信息安全(ISO 21434)三大支柱构成。功能安全应对硬件故障，采用ASIL分级和冗余设计；SOTIF解决算法局限和未知场景；信息安全防范网络攻击，构建纵深防御体系。三者协同保障车辆"能上路"，贯穿开发全生命周期。新发布的ISO/PAS 8800标准专门针对车载AI系统的安全挑战，完善了现有标准体系。这些安全要求已成为智能汽车量产的必备条件，决定产品能否合法上路。

安全与合规 (Safety & Security) —— 系统的底线

现在的智能车如果不谈安全，就无法量产上路。这部分是横跨你所有模块的。

• 功能安全 (Functional Safety, ISO 26262): 针对智驾、底盘、BMS等核心控制器。如何设计ASIL等级？如何做冗余（Fail-operational vs Fail-safe）？
• 预期功能安全 (SOTIF, ISO 21448): 针对自动驾驶。解决“系统没故障，但因为传感器局限或算法逻辑导致的安全问题”。
• 信息安全 (Cybersecurity, ISO 21434 / UN R155): 既然有TCU和OTA，黑客入侵防御就是必须的。涉及SecOC（车载通讯加密）、防火墙、IDPS（入侵检测）、HSM（硬件安全模块）。

在 SDV 时代，安全与合规不再是开发完成后的“补丁”或“认证流程”，而是必须贯穿在需求-设计-开发-测试-发布全生命周期的核心基因（Safety/Security by Design）。

如果说智驾和座舱决定了车“好不好卖”，那么安全与合规决定了车“能不能卖”（合法上路）。我们可以把这三大支柱比作**“内科医生”、“心理医生”和“保镖”**：

---

1. 功能安全 (ISO 26262)：系统的“内科医生”

它的核心是应对电子电气系统的故障（E/E System Failures）。即：假如芯片烧了、软件死循环了、电容爆了，车该怎么办？

• ASIL 等级 (Automotive Safety Integrity Level)：
  • 从 A（最低）到 D（最高）。
  • ASIL-D： 针对那些一旦失效会直接导致车毁人亡的系统，如转向（Steering）、制动（Braking）、高压断电。
  • ASIL-B： 通常用于仪表显示、车灯控制等。
  • 分解 (Decomposition)： 为了降低成本，可以将一个 ASIL-D 的功能分解为两个 ASIL-B 的独立模块（1+1=2），但这要求两个模块必须完全独立，不能有共因失效（Common Cause Failure）。
• 架构的质变：Fail-Safe vs. Fail-Operational
  • Fail-Safe (故障安全)： 传统 L2 时代的逻辑。如果转向助力失效，系统立刻切断电源，报错，要求驾驶员立刻接管。这在 L3/L4 是不可接受的，因为驾驶员可能正在睡觉。
  • Fail-Operational (故障运行/冗余)： L3+ 必须具备的能力。如果主控制器挂了，备份控制器必须在毫秒级内无缝接管，保证车辆能继续行驶一段时间，或者执行MRM (最小风险策略)，比如安全地靠边停车。
  • 硬件实现： 这就是为什么自动驾驶域控会有双 SoC、双电源、甚至双绕组电机。

---

2. 预期功能安全 (SOTIF, ISO 21448)：系统的“心理医生”

它的核心是应对系统的局限性和未知场景。即：系统没有坏（硬件完好、代码无Bug），但因为“太笨”或“看不懂”导致了危险。

• 解决什么问题？
  • 感知局限： 摄像头被强光致盲；把路边的白色广告牌误认为是横在路中间的白色货车（Ghost Braking，幽灵刹车）。
  • 算法逻辑不足： 自动驾驶严格遵守交规不想压实线，结果被旁边的大车挤出了道路。
  • 人员误用： 驾驶员在开启 L2 时试图睡觉或在方向盘上挂重物欺骗系统。
• 核心方法论：
  • 缩小 “未知的非安全区域” (Unknown Unsafe)。
  • 通过海量的仿真测试和路测，把“未知”变成“已知”，并通过优化算法把“不安全”变成“安全”。

---

3. 信息安全 (Cybersecurity, ISO 21434 / UN R155)：系统的“贴身保镖”

随着汽车变成“轮子上的手机”，攻击面（Attack Surface）急剧扩大。黑客不需要撬车门，通过 WiFi、蓝牙甚至胎压监测信号就能控制车辆。

• 纵深防御体系 (Defense in Depth)：
  • 云端与边界： 防火墙、证书体系 (PKI)。
  • 车内通信 (SecOC - Secure Onboard Communication)：
    • 原理： 给 CAN/Ethernet 报文加个“防伪标签”（MAC值）。
    • 作用： 防止黑客接入 OBD 接口后，伪造一条“刹车”指令。ECU 收到指令会校验标签，如果标签不对，直接丢弃。
  • 端点保护 (Host Security)：
    • HSM (Hardware Security Module)： 芯片里的“保险柜”。所有的私钥、证书都存在这里，主 CPU 只能调用不能读取。即使黑客攻破了 OS 拿到了 Root 权限，也偷不走密钥。
    • Secure Boot (安全启动)： 每次启动时，硬件检查 Bootloader 签名，Bootloader 检查 OS 签名，OS 检查 App 签名。一环扣一环，确保软件没有被篡改。
• 合规的强制性：UN R155
  • 这是欧盟的强制法规。车企必须建立 CSMS (网络安全管理体系)。如果不合规，车辆无法出口到欧洲。这也是目前中国出海车企最头疼的认证之一。

---

总结：三位一体的“安全盾”

在系统设计时，这三者往往是纠缠在一起的：

• 场景： 黑客通过网络攻击攻破了智驾系统（信息安全失效），导致车辆发出了疯狂加速的指令。
• 防御 1： 网关的防火墙和 IDPS（入侵检测）应该拦截该攻击（信息安全）。
• 防御 2： 如果拦截失败，底层的电机控制器（MCU）发现加速指令超出了物理安全范围（如扭矩突变），通过功能安全机制（E-Gas 监控层）强制切断扭矩（功能安全）。
• 防御 3： 如果是为了躲避某种极端场景而加速，系统必须确认这不是因为传感器的幻觉（预期功能安全）。

没有功能安全，车会自己坏；没有预期功能安全，车会乱开车；没有信息安全，车会被人害。 只有三者合一，才能构成智能汽车的信任基石。

再补充一下AI相关

ISO/PAS 8800:2024（全称：Road vehicles — Safety and artificial intelligence）是国际标准化组织（ISO）在 2024 年正式发布的针对道路车辆人工智能安全的公共可用规范（PAS）。

随着自动驾驶和高级驾驶辅助系统（ADAS）的普及，AI 模型（尤其是深度学习）的黑盒属性、不可解释性和对数据的依赖性，给传统的汽车安全标准（如 ISO 26262 功能安全和 ISO 21448 预期功能安全 SOTIF）带来了巨大挑战。ISO/PAS 8800 正是为了填补这一空白而诞生的。

---

核心内容与架构

该标准不仅是一个技术指南，它为 AI 在车载系统中的全生命周期提供了框架。其核心讨论点集中在以下六个方面：

1. AI 安全生命周期

定义了从需求明确、设计、开发、验证到部署后持续监控的完整闭环。它强调 AI 系统不是“一劳永逸”的，需要根据环境变化进行动态评估。

2. AI 系统安全设计

标准建议从架构和开发两个维度引入安全措施。例如：

• 引入冗余机制（Redundancy）。

• 设计安全外壳（Safety Enclosure）来监控 AI 的输出是否超出安全边界。

3. 数据集的质量与管理

AI 的安全性高度取决于训练数据。标准详细规定了：

• 数据集生命周期：从采集、清洗、标注到维护。

• 数据完整性：如何避免数据偏差（Bias）或覆盖不足（Under-fitting）导致的安全风险。

4. 验证与确认 (V&V)

传统的测试方法难以覆盖 AI 所有的边缘案例（Edge Cases）。ISO/PAS 8800 提出了：

• 虚拟测试与物理测试结合：强调仿真环境在 AI 安全评估中的重要性。

• 安全性论据（Safety Argument）：开发者需要提供证据证明其 AI 模型在目标场景下是足够安全的。

---

与其他标准的关系

ISO/PAS 8800 并不是孤立存在的，它更像是现有安全标准的“AI 增强插件”：

标准	关注点	与 ISO/PAS 8800 的关系
ISO 26262	功能安全 (FuSa)	解决 E/E 系统故障引起的问题。8800 补充了 AI 组件失效的特殊性。
ISO 21448	预期功能安全 (SOTIF)	解决功能不足或合理误用。8800 专注于 AI 算法导致的性能局限和不确定性。
ISO/IEC 42001	AI 管理体系	侧重于企业级的 AI 治理。8800 则是针对道路车辆的具体工程落地。

为什么它很重要？

1. 合规性依据：为车企和供应商（如 Tier 1）提供了开发 AI 功能时的行业共识，降低了法律和准入风险。

2. 技术落地：针对神经网络的不可解释性，提供了基于性能监控和风险分析的实际操作建议。

3. 全球协同：该标准由中、德、美、日等多国专家共同参与，具有很强的国际普适性。