2.5 安全目标与功能安全概念——从“它不能坏“到“它应该怎样安全“

HARA结束了。你的面前摆着一张清单：22个危害事件，每个都有S、E、C的评级，每个都在表格的尽头标注了ASIL等级。其中6个是ASIL D，4个是ASIL C，8个是ASIL B，3个是ASIL A，1个最终判定为QM。

你把这张清单递给项目经理。他扫了一眼，问了一个让你沉默的问题：

“好吧，所以呢？我们接下来做什么？”

你愣住了一秒。是的，HARA告诉你“哪里会出问题“以及“问题有多严重“，但它没有告诉你什么才叫“安全“。

你需要的是：把“高速公路上转向系统非预期输出力矩 = S3+E4+C3 = ASIL D“这一行，变成一句操作性的、可验证的、技术中立的安全承诺。

这就是安全目标（Safety Goal）。

免疫隐喻：从威胁识别到免疫策略的制定

回到免疫系统。你的身体通过模式识别受体（PRR）检测到了一种病原体相关分子模式（PAMP）：比如细菌细胞壁的脂多糖（LPS）。你判断出这是一个“ASIL C“级别的威胁：可能导致严重的全身感染（S3），在环境中普遍存在（E4），身体自身的基础防御有一些效果但不够（C3）。

然后呢？免疫系统需要制定免疫策略：也就是安全目标。

“阻止该病原体在血液中扩散”。这是一个安全目标。它不是具体的技术方案（要不要发热？要不要制造抗体？），而是顶层的功能目标。它回答了“安全意味着什么“的问题。

从安全目标，免疫系统展开功能安全概念：

• 发热：提高体温抑制病原体复制（这是“故障检测“：检测到病原体后的响应策略）
• 血管扩张：让免疫细胞更快到达感染部位（这是“降解操作“：通过辅助通道维持部分功能的能力）
• 补体激活：标记病原体，促进吞噬（这是“故障响应“：具体的安全机制）
• 疼痛和疲劳感：迫使你休息（这是“驾驶员警告“：对上层（意识层）的状态通报）
• 如果所有上述措施失败，启动全身免疫风暴：终极防线（这是“紧急操作“：最后的故障容错时间间隔内的降级措施）

你看，免疫策略和功能安全概念是一模一样的逻辑：说清楚要做什么，但不规定怎么做。制造抗体还是激活T细胞，那是“技术安全概念“，是免疫系统的“实现层面“的事了。在功能安全概念层面，你只需要说“必须清除该病原体，FTTI（故障容错时间间隔）为24小时“。

安全目标（Safety Goal）：一句话定义“安全“

ISO 26262-3的第6.4.4节对安全目标做了如下定义：

安全目标是顶层的安全需求，作为功能安全概念的输入。每个安全目标与一个危害事件关联，表达为实现或维持某相关项的安全状态所需的功能目标。

拆解一下这段话的含义：

1. 顶层的安全需求：安全目标位于整个安全需求金字塔的顶端。它不是技术需求，不是架构约束，不是测试用例。它是“皇帝“：下命令的人。

2. 与危害事件关联：每个安全目标都来源于HARA中识别的一个或多个危害事件。这种关联必须有追溯性（Traceability），你必须能够说清楚“这个安全目标来自哪一行HARA“。

3. 功能目标：安全目标说的是功能上要达成什么，而不是技术上如何实现。它在“什么“层面，不在“如何“层面。

4. 某相关项的安全状态：ISO 26262中“相关项“（Item）是实施功能安全的系统单元：可以是一整套转向系统，也可以是一个单独的ECU。

安全目标的撰写规范

安全目标不是随意的一句话。它必须满足以下特性：

1. 技术中立（Technologically Agnostic）

安全目标不规定用什么样的传感器、什么样的MCU、什么样的通信协议。它只描述功能层面的安全要求。“转向系统应防止车辆运行期间非预期的转向力矩超过100N”。这是好的安全目标，因为它没有规定用什么样的电机、什么样的控制算法来实现。“转向系统应使用冗余扭矩传感器并通过锁步MCU进行交叉校验”。这不是安全目标，这是技术安全需求（TSR）。

2. 可验证（Verifiable）

安全目标必须有可以验证的判定标准。你怎么知道它被满足了？必须有可量化的指标。“转向系统应防止危险的转向行为”。这句话无法验证。什么叫“危险“？什么叫“防止“？“转向系统应防止车辆运行期间非预期的转向力矩超过100N”：100N是可以测量的，非预期是可以定义的，满足/不满足是可以判定的。

3. 可追溯（Traceable）

每个安全目标必须能追溯到HARA中具体的一个或多个危害事件。这要求你在安全目标文档中明确标注来源。后续的所有安全活动：功能安全需求、技术安全需求、测试用例：都必须追溯到安全目标。追溯性（Traceability）是功能安全审计中最常见的不符合项，因为很多团队在开发过程中慢慢“忘记“了需求和来源之间的联系。

FTTI：安全目标的时间硬约束

很多安全目标会附带一个故障容错时间间隔（Fault Tolerant Time Interval, FTTI）。

FTTI的定义是：从故障发生到可能出现危害事件的最短时间间隔。

这可不是一个简单的参数。FTTI的意思是：如果你在FTTI内没有检测到故障并进入安全状态，那你就算失败。FTTI是你的“安全反应时间预算“。

一个典型的例子：转向系统的非预期力矩输出。从力矩传感器检测到异常，到实际产生足以改变车辆航向的力矩，这中间的安全时间窗口是200ms。如果驾驶员不介入，200ms后车辆将偏离车道。这200ms就是FTTI。你的整个安全机制：故障检测、确认、安全状态转换：都必须在这个时间窗口内完成。

FTTI的来源是什么？它来自危害分析中对可控性参数的深度研究。C3意味着驾驶员很难在给定时间窗口内避免伤害。这个“给定时间窗口“就决定了FTTI的上限。如果你说C3，但FTTI是10秒。那这两者是矛盾的。10秒足够大多数驾驶员做出反应，可控性评级应该重新评估。

将多个危害事件合并为一个安全目标

标准允许你把多个类似的危害事件合并到一个安全目标下。比如：

• 危害事件1：高速公路直行时EPS意外向左输出力矩（S3+E4+C3 = ASIL D）
• 危害事件2：高速公路变道时EPS意外向右输出力矩（S3+E3+C3 = ASIL C）
• 危害事件3：城市道路低速转弯时EPS意外反向助力（S2+E3+C2 = ASIL B）

这三个事件都指向同一个安全目标：“转向系统在车辆运行期间，应防止非预期的转向力矩超出安全范围。”

注意合并规则：多个危害事件共享一个安全目标时，安全目标继承最高的ASIL。在这个例子中，安全目标取ASIL D。

但合并不是无限制的。你不能把制动失效和转向失效合并为一个“确保车辆不失控“的安全目标。它们涉及不同的功能域、不同的时间约束、不同的安全状态定义。合并的前提是这些危害事件在功能层面上有相同的“安全定义“。如果两个事件的安全状态完全不同（比如一个是“切断动力“，另一个是“维持动力“），就不能合并。

功能安全概念（Functional Safety Concept, FSC）：安全目标的展开

安全目标是一句声明。它告诉你“什么是安全的“。但仅有一句声明，开发团队还是不知道要做什么。

功能安全概念（Functional Safety Concept, FSC）就是把这个声明展开为具体的安全功能：一种与硬件和软件都无关的、用功能语言描述的安全行为。

ISO 26262-3第7.4条定义FSC必须包含以下内容：

1. 故障检测与故障响应策略

FSC必须说明：系统通过什么类型的机制来检测故障，检测到故障后做什么。

例如，从“转向系统应防止非预期的转向力矩“这个安全目标，可以派生以下FSC级别的需求：

• FSR-01：系统应持续监控转向力矩指令与实际输出的差异。当差异超过X阈值时，应判定为力矩控制故障。
• FSR-02：系统应持续监控力矩传感器信号的合理性（两个独立通道的信号偏差不超过Y阈值）。
• FSR-03：确认力矩控制故障后，系统应在T1时间内从正常工作模式过渡到安全状态。

注意这些FSR的语言：它们说的是“应监控什么“、“应检测什么”、“应过渡到安全状态”，而不是“用什么样的ADC采样“、“用什么样的CRC校验”、“用什么样的GPIO拉低使能脚”。

2. 安全状态定义

**安全状态（Safe State）**是功能安全概念中最核心的概念之一。

ISO 26262-1对安全状态的定义是：相关项在发生故障时，通过安全机制维持的运行模式，该模式不存在不合理的风险。

关键词是“不存在不合理风险“：不是“零风险“。安全状态不是“完美状态“，而是“可接受风险的状态“。

不同系统的安全状态不同：

• 转向系统的安全状态可能是：转向助力逐步降低并最终切断，保留机械转向能力
• 制动系统的安全状态可能是：转入备用制动模式（如EPB辅助制动），同时点亮制动警告灯
• 电池管理系统的安全状态可能是：立即断开高压接触器，使高压系统进入无电状态
• 自动驾驶系统的安全状态可能是：执行最小风险策略（Minimal Risk Maneuver），靠边停车

一个系统可能有多个安全状态，对应不同的故障严重程度。轻度故障可以进入“降级运行“安全状态（仍然有功能，但性能受限），严重故障则必须进入“立即关闭“安全状态。

3. 故障容错与降级

FSC不假设所有故障都能被完美地管理：部分故障会导致系统性能下降。FSC必须定义：

• 哪些故障可以被容忍（继续运行但功能降级）
• 降级到什么程度（性能、精度、可用功能）
• 降级状态下可以运行多长时间（紧急操作时间窗口）

这是免疫系统的“发热策略“：身体没有因为感染病毒就直接“关机“（死亡），而是提高体温（降级运行），抑制病毒复制的同时维持其他生命功能。如果感染继续恶化，才会升级到更严重的免疫反应（进一步降级或改变安全状态）。

4. 驾驶员警告与交互

如果安全目标的达成依赖于驾驶员的操作（比如“看到警告灯后立即停车“），那么这个依赖必须明确写入FSC中，并且必须有证据证明：

• 驾驶员有能力识别警告（警告灯足够醒目、声音足够清晰）
• 驾驶员有足够的时间做出反应（警告发出的时机必须早于FTTI耗尽之前）
• 驾驶员有正确的控制手段（如果要求驾驶员接管，方向盘和制动踏板必须可用）

5. 功能安全需求（FSR）与相关项架构的分配

FSC中的每一条功能安全需求都必须被分配到系统架构的某个元素上：即使架构的细节还没有确定，至少要在“功能块“的层面进行分配。

例如：FSR-01（监控力矩差异）分配给“力矩监控功能块“，该功能块预期位于“EPS控制器“内。这为后续的技术安全概念和**HSI（硬件-软件接口）**定义提供了输入。

FTTI与FHTI：安全反应的时间链条

在FSC层面，FTTI被进一步细化为**故障处理时间间隔（Fault Handling Time Interval, FHTI）**的责任分配。

FHTI是FTTI的子集。它是在FTTI总预算内，留给安全机制处理故障的时间。

典型的分配：

• FTTI = 200ms（总的安全反应时间预算）
  • 故障发生到故障被检测到：≤ 20ms（诊断时间间隔）
  • 故障确认（消除瞬态误报）：≤ 5ms
  • 故障响应（过渡到安全状态）：≤ 50ms（FHTI）
  • 余量：125ms（保守裕量，用于覆盖分析的不确定性）

这种分配不是在功能安全概念层面详细规定的（那是技术安全概念的事），但FSC需要明确FTTI的值以及这个值对FSR的约束意义：“任何FSR的实现都必须确保从故障发生到进入安全状态的时间不超过FTTI”。

FSC的验证

ISO 26262要求功能安全概念必须经过验证（Verification）。验证报告是FSC的工作产品之一。

FSC验证的核心问题是：

1. 每一条FSR是否与安全目标一致且充分？
2. 所有的FSR合在一起，是否足够覆盖安全目标？
3. FSR之间是否有冲突？
4. FSC中定义的故障检测和故障响应策略在功能层面是否可行？
5. 安全状态的定义是否合理且在相关场景下是可接受的？
6. FTTI是否被正确分配？

验证的方法通常是评审（Review）：由独立于FSC开发团队的有经验的功能安全专家和安全评估员来进行。对于高ASIL等级（C和D），这种评审更加严格和正式。

从安全目标到FSR：一个完整的推演案例

让我们用一个具体的例子来展示整个流程。

第一步：HARA识别危害事件

• 危害事件HE-014：高速公路行驶时，EPS控制器因看门狗失效导致程序跑飞，持续输出最大左转力矩（约50Nm），导致车辆以约0.3g的侧向加速度向左偏移，在驾驶员未介入的情况下2秒内将完全偏离车道。
• S：S3（致命）
• E：E4（转向始终在使用）
• C：C3（高速场景下非预期转向极难控制，正常驾驶员无法在短时间内纠正方向并稳定车辆）
• ASIL：ASIL D
• FTTI分析：基于车辆动力学仿真，在120km/h车速、0.3g侧向加速度条件下，车辆完全偏离3.75m宽车道的时间约为1.8秒。考虑驾驶员正常反应时间（约1.0-1.5秒的认知+决策+操作时间），余量不足0.3秒。安全机制必须在200ms内完成检测和响应，才能为驾驶员留出足够的接管时间余量。FTTI = 200ms。

第二步：制定安全目标

SG-01 [ASIL D]：转向系统在车辆处于运行状态时，应防止非预期的、导致车辆偏离预定行驶路径的转向力矩。当过大的非预期转向力矩发生时，系统应在FTTI（200ms）内检测到故障并过渡到安全状态。

第三步：展开功能安全概念

安全状态定义： 安全状态SG-01-SS定义为：“EPS系统切断助力电机的驱动力，使转向系统回到纯机械转向模式，同时通过仪表盘上的转向故障警告灯通知驾驶员。”

FTTI分配：

• 故障检测窗口：≤ 50ms
• 故障确认窗口：≤ 10ms
• 安全状态过渡窗口：≤ 40ms
• FHTI合计：≤ 100ms
• FTTI裕量：100ms

功能安全需求：

*注：FSR-05的警告功能本身不直接阻止危害发生，它是对驾驶员的辅助通知。根据ISO 26262-9的ASIL分解规则，它可以分配为较低的ASIL，但前提是ASIL D级别的安全目标已经通过FSR-01~FSR-04的高ASIL机制得到保证。

本篇小结

1. 安全目标是顶层功能安全的“宪法“：简洁、技术中立、可验证、可追溯、有明确的时间约束
2. 安全目标的ASIL继承自关联的危害事件，合并的前提是共享相同的安全定义
3. 功能安全概念将安全目标展开为具体的FSR：故障检测策略、安全状态定义、降级方案、驾驶员交互
4. FSC的所有需求必须在功能架构层面分配
5. FSC需要正式验证

【下集预告】： FSR说“检测故障并进入安全状态“，但硬件工程师问：用什么检测？用ADC比较器、锁步核、还是看门狗？下一节的关键一步：你从一条功能安全需求出发，在一个具体的技术架构上，“生长“出TSR-042、TSR-043、TSR-044。HSI规范还要确保当软件说“进入安全状态“时，硬件确实听懂了。这不是翻译，是嫁接手艺。