2. 功能安全与法规基线
在 Bosch 车辆控制系统的验证与量产交付中，功能安全不是“额外加一层测试”，而是从危害分析开始、贯穿需求、设计、实现、验证、生产到运行维护的一条完整证据链。ISO 26262 是道路车辆功能安全的国际标准，它规定了从概念阶段到产品发布各阶段的活动与工作产物。理解 ASIL 等级、安全目标与安全需求分解，以及 Bosch 内部流程如何把这些要求落到量产节点，是后续所有验证活动的前提。
一、ASIL 等级：从危害到安全完整性
ASIL（Automotive Safety Integrity Level）是 ISO 26262 对安全相关系统所要求的风险降低程度的等级划分，分为 A、B、C、D 四个等级，D 最高，QM 表示仅需常规质量管理。ASIL 不是直接由“故障后果”单一维度决定，而是由三个参数共同确定：
- S（Severity，严重度）：S0 无伤害，S1 轻中度伤害，S2 重度伤害，S3 危及生命或致命。
- E（Exposure，暴露度）：E0 几乎不可能，E1 极低概率，E2 低概率，E3 中等概率，E4 高概率。
- C（Controllability，可控性）：C0 一般可控，C1 简单可控，C2 通常可控，C3 难以控制或无法控制。
三者组合后通过标准中的 ASIL 定级表确定等级。例如，制动助力失效在高速行驶中可能导致 S3、E4、C3，对应 ASIL D；而低速泊车辅助的轻微误动作可能为 S1、E2、C2，对应 ASIL A 或 QM。定级结果直接决定后续开发过程的严格程度：ASIL D 要求更完整的危害分析与验证、更高的诊断覆盖率、更严格的开发接口和独立评估。
示例（合理假设，非实测）：某电子驻车制动控制器，危害事件为“行驶中意外施加驻车制动”。若在高速公路上发生，S3；暴露度 E4；驾驶员难以在短时间内解除，C3。查表得 ASIL D。若同一功能仅在低速挪车时误触发，S2、E3、C2，可能降为 ASIL B。可见同一功能在不同运行场景下 ASIL 不同，安全目标必须绑定运行场景。
二、安全目标与安全需求分解
安全目标（Safety Goal）是针对整车层面危害事件的顶层安全要求，通常以“避免非预期……”“防止……失效”的形式描述，并绑定对应的 ASIL。安全目标不描述具体实现，而是定义可接受的风险边界。例如：“避免因控制器非预期输出导致车辆意外加速”，ASIL D。
安全目标需要逐层分解为功能安全需求（FSR）和技术安全需求（TSR）。FSR 描述功能层面必须做什么，例如“当检测到扭矩请求与驾驶员意图不一致时，应在 100 ms 内进入安全状态”；TSR 则描述硬件与软件如何实现，例如“监控模块以 10 ms 周期比较扭矩请求与踏板信号，偏差超过阈值时触发关断路径”。分解过程中必须保持 ASIL 等级不降级，除非有经过论证的分解方案（如 ASIL 分解为 ASIL B(D) + ASIL B(D)）。
需求分解的关键是建立可追溯性：危害事件 → 安全目标 → FSR → TSR → 软件/硬件实现 → 验证用例。任何一层缺失都会导致量产审核时无法证明安全需求被完整覆盖。Bosch 内部通常使用需求管理工具维护这条链路，并在每个阶段设置评审门。
三、Bosch 内部功能安全流程
Bosch 作为 Tier 1 供应商，其功能安全流程在 ISO 26262 基础上叠加了客户特定要求（CSR）和内部标准。典型流程包括：
- 安全生命周期启动：在项目报价阶段即确定 ASIL 等级、安全目标草案和开发接口协议（DIA）。DIA 明确 Bosch 与整车厂之间的责任边界，例如哪些安全需求由 Bosch 实现，哪些由整车厂承担。
- 概念阶段：完成相关项定义、危害分析与风险评估（HARA），输出安全目标与功能安全概念。此阶段需要与客户共同评审，确保整车层面假设一致。
- 系统开发：将 FSR 分解为 TSR，分配到硬件和软件。Bosch 内部要求每个 TSR 都有对应的验证方法、诊断覆盖目标和失效模式分析（FMEA/FMEDA）。
- 硬件与软件开发：遵循各自的过程模型，ASIL D 项目通常要求更高的代码覆盖率、更严格的评审和独立验证。硬件需计算 SPFM、LFM 等指标，软件需满足 MISRA 等编码规范。
- 安全验证与确认：包括功能安全验证（验证 TSR 是否正确实现）和安全确认（确认安全目标是否达成）。常用方法有故障注入、边界测试、诊断覆盖率评估和整车级场景测试。
- 生产与运行：量产阶段需保证生产过程的一致性，并建立现场监控与安全异常响应机制。任何变更都必须经过安全影响分析。
四、量产合规要求与证据链
量产合规的核心是“可证明”。Bosch 在量产节点通常需要提交安全案例（Safety Case），其中包含：
- 危害分析与风险评估报告，含 S/E/C 定级依据；
- 安全目标与安全需求规格，含 ASIL 分解论证；
- 技术安全需求与实现映射，含诊断覆盖率和失效模式分析；
- 验证与确认报告，含测试用例、覆盖结果和未覆盖项说明；
- 开发接口协议与客户确认记录；
- 生产一致性计划与现场监控方案。
常见合规风险：安全目标未绑定运行场景、ASIL 分解缺少论证、诊断覆盖率未达到目标值、需求追溯链断裂、变更未做安全影响分析。这些问题在量产审核中往往直接导致安全案例不完整，进而影响交付节点。
在实际项目中，建议把安全需求分解与验证用例的映射做成可查询的矩阵，并在每个阶段评审时检查覆盖率。对于 ASIL D 项目，独立评估和确认测量是强制要求，不能由原开发人员自行完成。只有把标准要求转化为可执行、可检查、可追溯的工程活动，功能安全才能真正支撑量产交付。