4. 功能安全概念（FSR）：安全目标定义、功能安全概念导出、安全状态定义、容错时间间隔（FTTI）
各位好，我是老张。在车载功能安全这个行当里摸爬滚打了十来年，今天咱们聊聊功能安全概念（FSR）的落地。说白了，FSR 就是把上一章做的 HARA 分析结果，翻译成工程团队能直接执行的“设计需求说明书”。
我个人习惯把 FSR 比作一座桥——桥的一头是“风险分析”（HARA），另一头是“技术实现”（TSR）。桥没搭好，后面所有工作都是空中楼阁。今天咱们就拆开这座桥，看看每一块砖怎么砌。
4.1 安全目标定义：从“危险”到“必须”
安全目标（Safety Goal, SG）是 FSR 的起点。它回答一个核心问题：“系统必须避免什么？”
每个安全目标都来自 HARA 中识别出的一个危险事件。我见过不少新手直接把 HARA 里的“危险描述”复制过来当安全目标，这是大忌。安全目标必须用“系统应避免……”或“系统应防止……”的句式，并且要明确到可验证的程度。
安全目标定义三要素：
- ASIL 等级：直接继承自 HARA 中对应危险事件的 ASIL 等级（QM / A / B / C / D）
- 安全状态：系统在检测到故障后应进入的状态（后面会细讲）
- FTTI：从故障发生到系统进入安全状态的最大允许时间
举个例子，我在一个 AI 座舱项目中遇到过这样的场景：
| 危险事件 | ASIL | 安全目标（SG） |
|---|---|---|
| AI 误识别导致方向盘自动转向 | ASIL D | 系统应防止非驾驶员意图的自动转向指令输出 |
| 座舱摄像头故障导致驾驶员监控失效 | ASIL B | 系统应在摄像头故障时，在 100ms 内降级至“仅音频提示”模式 |
| 语音助手误触发紧急制动 | ASIL C | 系统应防止语音指令直接触发制动执行器 |
嗯，这里要注意：安全目标不能写“系统应尽量可靠”这种废话。每个目标必须能通过测试来验证——要么通过，要么不通过，没有“差不多”。
4.2 功能安全概念导出：把“目标”变成“方案”
安全目标定好了，接下来就是功能安全概念（Functional Safety Concept, FSC）。这一步的核心是：“怎么实现这些安全目标？”
功能安全概念要回答三个问题：
- 谁来检测故障？——故障检测机制
- 检测到故障后怎么办？——故障响应措施
- 系统最终进入什么状态？——安全状态定义
我习惯用“三明治结构”来组织 FSC：
我的 FSC 导出模板：
- 上层：安全目标（SG）——输入
- 中层：功能安全需求（FSR）——每个 SG 分解为 3~8 条 FSR
- 下层：技术安全需求（TSR）——FSR 的硬件/软件实现
注意：FSR 是“功能层面”的需求，不涉及具体芯片型号或算法。比如“系统应在 50ms 内检测到摄像头信号丢失”是 FSR，而“使用 I²C 心跳检测”是 TSR。
举个例子，针对上面那个“AI 误识别导致方向盘自动转向”的安全目标，我导出的 FSC 大概长这样：
SG-01：系统应防止非驾驶员意图的自动转向指令输出（ASIL D）
FSR-01.1：转向指令必须经过“驾驶员意图验证”模块确认后才能执行（ASIL D）
FSR-01.2：系统应在 10ms 内检测到转向指令与驾驶员操作冲突（ASIL D）
FSR-01.3：检测到冲突后，系统应在 20ms 内切断自动转向输出（ASIL D）
FSR-01.4：转向执行器应具备独立的硬件看门狗，监控指令合法性（ASIL B）
FSR-01.5：系统应记录所有被拒绝的转向指令，用于离线分析（QM）
你看，同一个 SG 分解出的 FSR 可以有不同的 ASIL 等级。这就是“ASIL 分解”和“ASIL 裁剪”的用武之地——后面章节会专门讲。
4.3 安全状态定义：系统“认输”的正确姿势
安全状态（Safe State）是功能安全里最容易糊弄、也最容易翻车的地方。说白了就是：系统发现搞不定了，怎么体面地“认输”？
我曾经在一个项目中吃过亏：团队把安全状态定义为“系统关机”。结果在高速上摄像头故障，系统直接黑屏——驾驶员慌了，差点出事。后来我们才意识到，安全状态不是越“安全”越好，而是要“在保证安全的前提下，尽可能维持可用性”。
安全状态定义避坑指南：
- 不要一刀切“关机”：除非是 ASIL D 且无其他选择
- 考虑降级模式：比如“仅显示，不控制”、“仅被动监控，不主动干预”
- 明确退出条件：系统从安全状态恢复到正常状态的条件是什么？
- 区分“永久安全状态”和“临时安全状态”：前者需要维修，后者可自动恢复
常见的 AI 座舱安全状态分级：
| 安全状态等级 | 描述 | 适用场景 |
|---|---|---|
| Level 0 | 全功能正常运行 | 无故障 |
| Level 1 | 降级模式（如关闭 AI 推荐，保留基础显示） | 非安全关键故障（如语音识别异常） |
| Level 2 | 受限模式（如仅显示车速、警告灯） | 安全关键故障（如摄像头故障） |
| Level 3 | 安全停机（如切断所有非必要功能，仅保留制动和转向） | 严重安全故障（如域控制器过热） |
每个安全目标都要明确指定其安全状态。比如前面那个“摄像头故障”的例子，安全状态就是“降级至仅音频提示模式”——而不是“关闭整个座舱系统”。
4.4 容错时间间隔（FTTI）：和时间赛跑
FTTI（Fault Tolerant Time Interval）是功能安全里最“硬”的指标之一。它定义了：从故障发生到系统进入安全状态，最多能容忍多长时间？
你想想看，如果系统检测到故障需要 1 秒，但 FTTI 只有 100ms——那检测机制本身就不合格。所以 FTTI 要分解成两部分：
- FDTI（Fault Detection Time Interval）：故障检测时间
- FHTI（Fault Handling Time Interval）：故障处理时间（包括决策和执行）
公式很简单：FTTI ≥ FDTI + FHTI
我在项目中一般会留 20% 的余量。比如 FTTI 要求 100ms，那我设计时会让 FDTI + FHTI ≤ 80ms。为什么？因为硬件有公差、软件有抖动、温度有影响——不留余量就是给自己挖坑。
FTTI 分配示例（AI 座舱摄像头故障场景）：
- FTTI 要求：100ms（来自安全目标）
- FDTI：40ms（摄像头心跳检测 + 图像帧超时判断）
- FHTI：40ms（决策：确认故障 → 执行：切换显示模式）
- 余量：20ms
注意：FDTI 和 FHTI 的分配不是固定的。如果检测算法复杂，FDTI 可能占大头；如果执行机构响应慢，FHTI 可能更长。
不同 ASIL 等级对 FTTI 的典型要求范围（经验值，非标准）：
| ASIL 等级 | 典型 FTTI 范围 | 说明 |
|---|---|---|
| ASIL D | 10ms ~ 100ms | 转向、制动等安全关键功能 |
| ASIL C | 100ms ~ 1s | 动力系统相关功能 |
| ASIL B | 1s ~ 10s | 驾驶员监控、信息显示 |
| ASIL A | 10s ~ 100s | 舒适性功能（如座椅调节） |
嗯，这里要特别提醒：FTTI 不是拍脑袋定的。它必须基于“车辆在故障状态下能保持安全的最长时间”来推导。比如高速上方向盘突然卡死，驾驶员能承受的失控时间可能只有几十毫秒——这就是 FTTI 的来源。
4.5 本章知识体系总览
说了这么多，咱们用一张图把 FSR 的核心逻辑串起来：
这张图把 FSR 的完整流程串起来了：从 HARA 输入，到安全目标定义，再到功能安全概念导出，最后分解为可执行的 FSR 清单。每个环节都离不开安全状态、FTTI 和 ASIL 这三个核心要素。