1. 课程导入

在汽车电子与软件规模快速膨胀的今天，功能安全已从“可选项”变成整车与零部件开发的“准入条件”。ISO 26262 正是道路车辆功能安全领域最核心的国际标准，它把“避免因电子电气系统失效而导致不可接受风险”这一目标，拆解为可管理、可验证、可追溯的工程活动。理解它的起源、发展、适用范围与整体框架，是后续所有安全活动、文档模板与审核要点的共同起点。

一、起源与发展：从 IEC 61508 到道路车辆专用标准

ISO 26262 并非凭空出现。它的方法论根基是 IEC 61508《电气/电子/可编程电子安全相关系统的功能安全》，但通用标准无法覆盖汽车行业的特殊约束：批量大、成本敏感、供应链长、整车生命周期内软件可更新、以及“驾驶员仍在环”的独特人机关系。因此，2011 年 ISO 26262 第一版发布，将功能安全从通用工业领域“翻译”为道路车辆语言。

2018 年第二版发布，是标准演进的关键节点。它把适用范围从乘用车扩展到摩托车，新增了半导体开发指南，强化了软件与硬件开发接口，并引入更明确的信息安全与功能安全协同考虑。对学习者而言，这意味着不能只记“2011 版条款”，而要理解第二版对分布式开发、ASIL 分解、安全论证的更新要求。

二、适用范围：谁必须用、用在哪里

标准适用于道路车辆上所有与安全相关的电子电气系统，包括硬件、软件、传感器、执行器、通信网络以及它们之间的接口。典型对象包括整车控制器、电池管理系统、制动控制、转向助力、安全气囊、自动驾驶域控制器等。需要特别注意的是，标准以“E/E 系统”为边界，但安全责任会沿供应链向上游传递：主机厂、Tier 1、Tier 2、芯片与软件供应商都可能承担相应安全活动。

标准也明确了不适用范围：不适用于机械、液压、气动等非 E/E 系统本身，但若这些系统由 E/E 系统监控或控制，则其接口与安全机制仍可能被纳入。另一个常见误区是认为“只有 ASIL D 才需要做功能安全”。实际上，只要存在危害事件且安全目标被识别，即使 ASIL A 或 QM，也需要按对应要求开展活动，只是严格程度不同。

三、整体框架：以安全生命周期为主轴

ISO 26262 由多个部分组成，学习时不应孤立背诵条款，而应抓住“安全生命周期”这条主线。下图展示了标准的核心结构：从概念阶段的安全目标与危害分析，到系统、硬件、软件层面的开发与集成，再到生产、运行、服务和退役，最后通过安全论证与确认措施形成闭环。

从图中可以看到，标准的核心不是单一文档，而是一条“概念—系统—硬件—软件—生产运行—确认”的链条。支持过程像地基一样贯穿始终，ASIL 等级则决定每个环节的严格程度。学习时建议先建立这条主线，再逐层深入具体条款。

四、方法流程：一个最小可用的安全活动闭环

以“电动车窗防夹控制”为例，可以快速理解功能安全的活动顺序。首先定义相关项：车窗控制模块及其输入输出。然后进行 HARA，识别“车窗上升时夹住乘员”这一危害事件，评估严重度、暴露率与可控性，得出 ASIL 等级。接着制定安全目标，例如“避免车窗在夹住障碍物时继续上升”，并导出功能安全需求与安全状态。随后在系统、硬件、软件层逐级分配技术安全需求，设计防夹算法、电流检测与反向驱动机制，最后通过测试与安全论证证明目标达成。

相关项定义 → HARA → 安全目标 → 功能安全需求
        → 技术安全需求 → 系统/硬件/软件设计
        → 集成与验证 → 安全确认 → 安全案例

这个闭环的关键在于“需求可追溯”。每一个安全目标都应能向下追溯到具体设计，向上追溯到危害事件。缺少追溯链，安全论证就会变成无法审核的“口头承诺”。

五、常见误区与复盘

• 误区一：把 ISO 26262 当成一次性认证。它要求的是持续的安全管理，包括变更管理、现场监控与安全相关更新。
• 误区二：只关注 ASIL D。低 ASIL 同样需要完整的安全活动，只是方法深度不同。
• 误区三：安全活动由安全工程师独自完成。功能安全是系统工程，需要系统、硬件、软件、测试、质量与供应商共同参与。
• 误区四：先开发后补文档。安全案例应在开发过程中同步构建，而不是最后拼凑。

六、关键术语速查清单