1. 功能安全概述：ISO 26262标准背景、功能安全定义、V模型开发流程简介
各位工程师朋友，大家好。我是你们这门课的老朋友。咱们今天开篇，先聊聊功能安全到底是个啥，为啥汽车行业现在这么看重它。
说实话，我入行那会儿，功能安全还没这么火。大家更关心的是“这功能能不能跑起来”、“性能够不够强”。直到有一次，我参与的一个项目在路试时，因为一个软件逻辑的边界条件没处理好，导致车辆在高速上突然动力中断。虽然没出事故，但那一脚“踩油门没反应”的体验，让整个团队后背发凉。从那以后，我才真正理解——功能安全不是锦上添花，而是底线。
1.1 ISO 26262 标准背景
ISO 26262，全称是“道路车辆功能安全”标准。它脱胎于工业领域的IEC 61508，专门为汽车电子电气系统量身定制。
为什么会单独搞一个汽车版？你想想看，汽车是个移动的产品，每天在路上跑，跟人、跟环境交互。一个刹车失灵、一个转向卡死，后果可能是灾难性的。所以，汽车行业需要一个更具体、更严格的指导框架。
这个标准从2011年发布第一版，到2018年推出第二版，覆盖范围从乘用车扩展到了卡车、巴士、摩托车，甚至包括了半导体（芯片）的开发。我个人习惯把ISO 26262看作一本“安全开发百科全书”——它不告诉你具体怎么设计电路、怎么写代码，但它告诉你：为了达到可接受的风险水平，你应该走完哪些流程，产出哪些证据。
核心要点： ISO 26262 不是设计规范，而是风险管理规范。它关注的是“如何避免系统性故障”和“如何控制随机硬件故障”。
1.2 功能安全的定义
咱们先给个标准定义：功能安全是指不存在由电子电气系统的功能异常表现所导致的不合理风险。
听起来有点绕？说白了，就是：系统出错了，但不能害人。
举个例子：你车上的自适应巡航（ACC）系统。正常情况下，它应该根据前车距离自动加减速。但如果传感器故障，它错误地认为前方没车，然后全油门加速——这就是“功能异常表现”。如果这个异常导致了追尾事故，那就是“不合理风险”。
功能安全要做的，就是通过一系列技术手段（比如冗余设计、故障检测、安全状态切换），让这种“异常表现”要么不发生，要么发生了也能把危害降到最低。
这里有个概念容易混淆，我提一下：功能安全 ≠ 预期功能安全（SOTIF）。ISO 26262 管的是“系统本身故障”导致的风险；而 ISO 21448（SOTIF）管的是“系统本身没坏，但因为场景复杂或性能局限”导致的风险。比如，摄像头没坏，但大雾天看不清——这属于SOTIF的范畴。咱们这门课主要聚焦在ISO 26262上。
| 概念 | 关注点 | 典型场景 |
|---|---|---|
| 功能安全 | 系统故障（硬件/软件） | 传感器短路、内存位翻转、软件跑飞 |
| 预期功能安全 | 系统性能局限/场景误判 | 强光眩目、雨雾遮挡、未知障碍物 |
1.3 V模型开发流程简介
ISO 26262 推荐的开发模型，就是经典的 V模型。它不是汽车行业独有的，但在功能安全领域，V模型被赋予了非常具体的“安全活动”内涵。
V模型的核心思想是：左侧做分解和设计，右侧做集成和验证，左右两侧一一对应。
我画了一张图，帮你直观理解这个结构：
从这张图你能看到，V模型的左侧是“自上而下”的分解过程：从整车级的相关项定义，一直分解到具体的硬件/软件设计。右侧是“自下而上”的集成验证过程：从单元测试开始，一步步集成到整车，最后做安全确认。
在功能安全开发中，V模型的每个阶段都有对应的安全活动。比如：
- 在“危害分析与风险评估”阶段，我们要定义安全目标（Safety Goal），并确定它的ASIL等级。这是咱们这门课的核心内容之一。
- 在“功能安全概念”阶段，我们要把安全目标分解成功能安全要求（FSR）。
- 在“技术安全概念”阶段，我们要把FSR进一步细化为技术安全要求（TSR）。
- 在右侧的测试阶段，我们要验证这些要求是否被正确实现。
我的经验： 很多团队容易犯一个错误——左侧的分解做得马马虎虎，就急着跳到右侧去写代码、做测试。结果到了集成阶段，发现安全目标没覆盖全，或者ASIL等级分解错了，不得不返工。记住：V模型左侧花的时间越多，右侧返工的成本越低。
1.4 本章小结
咱们这一章，主要铺垫了三个基础概念：
- ISO 26262 的背景——它是一本“安全开发百科全书”，核心是风险管理。
- 功能安全的定义——系统出错了，但不能害人。它和SOTIF是两码事。
- V模型开发流程——左侧分解，右侧集成，安全活动贯穿始终。
嗯，基础打牢了，后面咱们才能深入聊“安全目标怎么定”、“ASIL等级怎么分解”。这些内容，我会结合我踩过的坑、总结的经验，一点一点讲给你听。