2. ISO 26262核心概念与Bosch落地框架
ISO 26262 是道路车辆功能安全的国际标准，它把“安全”从一句工程口号转化为可分解、可验证、可追溯的工程活动集合。对 Bosch 这样的 Tier 1 供应商而言，标准不是纸面合规，而是贯穿需求、设计、实现、验证、量产与运维的工作方式。本节围绕四个核心概念——ASIL 等级、安全生命周期、相关项定义、危害分析与风险评估（HARA）——以及 Bosch 功能安全管理体系的组织方式展开。
一、ASIL 等级：风险被量化为四个档位
ASIL（Automotive Safety Integrity Level）由三个维度共同决定：严重度 S（Severity，S0–S3）、暴露率 E（Exposure，E0–E4）和可控性 C（Controllability，C0–C3）。三者组合后映射为 QM、ASIL A、ASIL B、ASIL C、ASIL D 五个结果，其中 ASIL D 要求最严，QM 表示按常规质量管理即可。
严重度描述伤害程度：S0 为无伤害，S1 为轻中度伤害，S2 为重度可能危及生命的伤害（有存活可能），S3 为致命伤害。暴露率描述运行场景出现的概率：E0 几乎不可能，E1 极低概率，E2 低概率，E3 中等概率，E4 高概率。可控性描述驾驶员或其他交通参与者能否及时避免伤害：C0 通常可控，C1 简单可控，C2 一般可控，C3 难以控制或无法控制。
举例说明（以下为教学示例，非实测结论）：某前置摄像头在高速公路上误将前方静止车辆识别为可通行，导致 AEB 未触发。若碰撞可能造成致命伤害，取 S3；高速公路跟车场景频繁出现，取 E3；驾驶员在 1 秒内几乎无法接管制动，取 C3。S3+E3+C3 组合对应 ASIL D。若同一功能仅在停车场低速场景误判，S2+E1+C2 可能只落到 ASIL A。可见 ASIL 不是“功能重要不重要”的主观判断，而是场景化、参数化的推导结果。
ASIL 等级直接决定开发要求：ASIL D 对硬件失效率指标（如单点故障度量 SPFM、潜伏故障度量 LFM）、软件架构（如无干扰、内存保护、程序流监控）、验证方法（如形式化验证、故障注入）都有更严格约束。等级越高，安全机制越冗余，证据链越完整。
二、安全生命周期：从概念到报废的闭环
ISO 26262 把安全活动组织为安全生命周期，覆盖概念阶段、产品开发（系统、硬件、软件）、生产运行、直至报废。核心阶段包括：相关项定义、HARA、功能安全概念、技术安全概念、系统/硬件/软件设计与验证、安全确认、生产与运行、运行维护与退役。
生命周期强调“追溯”与“闭环”：每一条安全目标都要能追溯到危害事件，每一项安全需求都要能追溯到安全目标，每一个测试用例都要能追溯到安全需求。Bosch 在实践中通常用需求管理工具（如 DOORS 或 Polarion）建立双向链接，确保变更影响可分析、可审计。
三、相关项定义：先划清边界，再谈安全
相关项（Item）是功能安全分析的起点，指实现车辆功能的系统或系统组合。相关项定义要明确：功能描述、边界与接口、运行环境、依赖关系、假设条件。边界不清，HARA 就会把不属于本相关项的危害纳入或遗漏。
以 Bosch 的 AEB 相关项为例，定义时需说明：摄像头/雷达输入、AEB 控制器、执行器（ESC/制动助力）、与整车 CAN 的交互、驾驶员作为外部参与者、以及假设（如制动系统本身满足其安全目标）。只有边界清晰，后续的 ASIL 分配和安全机制设计才有意义。
四、HARA：危害分析与风险评估
HARA 的目标是识别危害事件、评估风险、确定安全目标与 ASIL。典型流程为：识别功能异常 → 分析车辆级危害 → 确定危害事件（危害+运行场景）→ 评估 S/E/C → 确定 ASIL → 制定安全目标。
安全目标是对危害事件的顶层安全需求，例如“AEB 应避免在高速公路上对静止车辆漏触发导致碰撞”。安全目标再分解为功能安全需求（FSR）和技术安全需求（TSR），最终落到硬件和软件设计。
五、Bosch 功能安全管理体系概览
Bosch 的功能安全管理体系（FSM）通常包含：安全文化、安全组织与角色（安全经理、安全工程师、DIA 接口）、安全计划、安全案例、确认措施、供应商管理、变更管理、工具链与置信度。其核心是把 ISO 26262 的要求嵌入到已有的 ASPICE 与质量管理体系中，而不是另起一套流程。
在项目层面，Bosch 通常按“安全计划 → 安全分析 → 安全需求 → 安全设计 → 安全验证 → 安全确认 → 安全案例”的主线推进，并用 DIA（开发接口协议）明确与 OEM 及其他供应商的职责边界。安全案例是最终交付物，汇总所有安全活动证据，证明相关项满足安全目标。
六、从概念到落地的关键衔接
理解上述概念后，实际项目中最容易出问题的不是“不知道标准”，而是“概念之间没有对齐”。例如：相关项边界没划清，HARA 就会把不属于本相关项的危害纳入；ASIL 分配没有场景支撑，安全目标就会空泛；安全需求没有追溯到安全目标，验证就无法证明覆盖。Bosch 的做法通常是用一张“安全追溯矩阵”把相关项、危害事件、安全目标、ASIL、FSR、TSR、测试用例逐行关联，任何变更都能快速评估影响范围。
总结来看，ISO 26262 的核心概念构成一条从“定义对象”到“评估风险”再到“分配等级”的逻辑链，而 Bosch 的落地框架则把这条链嵌入到安全生命周期和功能安全管理体系中，用追溯、验证和安全案例保证每个环节可证明、可审计。掌握这些概念，是后续学习安全需求分解、硬件指标计算和软件安全机制设计的基础。