4. E/E架构安全工程概述

在汽车电子/电气（E/E）架构中，“安全”并不是一个单一指标，而是由多个标准体系共同约束的系统属性。功能安全（ISO 26262）关注由系统故障引发的危害，预期功能安全（SOTIF，ISO 21448）关注在无故障情况下因性能局限或可预见误用导致的风险，网络安全（ISO/SAE 21434）则关注恶意攻击与信息篡改带来的威胁。三者共同构成现代智能汽车的安全工程基线，并通过安全生命周期与安全管理机制贯穿概念、开发、生产、运行到报废的全过程。

一、核心原理：三类安全的边界与互补

功能安全的核心问题是“系统坏了会不会伤人”。它通过危害分析、安全目标、功能安全概念、技术安全需求、硬件/软件安全机制等，把风险降低到可接受水平。典型手段包括冗余、监控、看门狗、ECC、双核锁步、安全状态切换等。

SOTIF 的核心问题是“系统没坏，但能力不够或场景超出设计范围会不会伤人”。例如 AEB 在逆光、雨雾、异形车辆场景下漏检，或驾驶员误用辅助驾驶。SOTIF 强调场景库、已知/未知不安全场景、验证与确认、运行阶段监测与 OTA 改进。

网络安全的核心问题是“系统会不会被恶意利用”。ISO/SAE 21434 要求建立网络安全治理、TARA（威胁分析与风险评估）、安全需求、安全设计、验证、事件响应与漏洞管理。它关注攻击面、信任边界、密钥、诊断接口、OTA、网关与域控制器。

二、方法流程：从危害到安全生命周期的闭环

安全工程通常遵循“分析—定义—实现—验证—运行—改进”的闭环。以功能安全为例：先做 HARA（危害分析与风险评估），确定 ASIL 等级；再制定安全目标与功能安全概念；随后分解为技术安全需求并分配到硬件、软件、通信；最后通过测试、评审、确认措施证明达成。SOTIF 则更强调场景驱动的验证与确认，以及未知不安全场景的探索。网络安全则从资产识别、威胁建模、TARA 开始，输出安全需求并落实到架构与组件。

安全生命周期与安全管理要求组织建立安全文化、角色职责、能力管理、变更管理、配置管理、供应商管理、确认措施与发布后监控。没有管理机制，技术措施很难持续有效。

三、案例/场景：AEB 与网关诊断接口的安全协同

以 AEB（自动紧急制动）为例。功能安全视角下，需要分析传感器失效、制动执行器失效、通信丢帧等故障，并设计安全目标“避免非预期制动或漏制动”。SOTIF 视角下，需要分析逆光、雨雾、异形车辆、行人突然横穿等场景，确认系统在 ODD 内的性能边界，并识别未知不安全场景。网络安全视角下，需要防止攻击者通过 CAN 注入虚假障碍物信息或篡改制动指令，因此要设计 SecOC、网关过滤、诊断接口认证与密钥管理。

再以 OTA 升级为例。功能安全要求升级过程不能导致车辆进入危险状态，需有回滚与安全状态；SOTIF 要求升级后重新验证场景覆盖；网络安全要求签名验签、防回滚、防降级、安全启动与日志审计。三者必须在同一升级流程中协同，而不是各自为政。

四、误区/复盘：常见安全工程误区

• 误区一：做了功能安全就等于安全。功能安全不覆盖无故障的性能局限与恶意攻击，SOTIF 与网络安全必须独立开展。
• 误区二：网络安全只靠防火墙。网络安全需要 TARA、安全需求、安全设计、验证、事件响应与漏洞管理的完整闭环。
• 误区三：安全生命周期只是文档。没有配置管理、变更管理与发布后监控，安全措施会在迭代中失效。
• 误区四：供应商安全责任可以转移。OEM 仍需对整车安全负责，必须对供应商进行安全能力评估与接口约束。

五、安全工程关键活动清单

安全需求示例（伪代码）：
FUSA-REQ-001: 当制动执行器失效时，系统应在 100ms 内进入安全状态并点亮故障灯。
SOTIF-REQ-007: 在逆光且目标对比度低于阈值时，AEB 应降级并提示驾驶员接管。
CS-REQ-012: 所有诊断写服务必须经过双向认证，未认证请求应被网关拒绝并记录安全日志。

综上，E/E 架构安全工程的核心不是单独满足某一个标准，而是把功能安全、预期功能安全与网络安全统一到安全生命周期与安全管理框架中。只有让三类安全在需求、设计、验证、运行与变更中持续协同，才能真正支撑智能汽车的安全落地。