作者 | 磐匠
智能底盘技术 (14) | Two-box 方案 "ESC + eBooster" 功能安全之危害分析与风险识别 (下)
根据制动执行机构的不同，线控制动系统（Brake-By-Wire）可以分为液压式线控制动系统（Electro-Hydraulic Brake, EHB）和机械式线控制动系统（Electro-Mechanical Brake, EMB）。其中，EHB 以传统的液压制动系统为基础，用电子器件替代了部分机械部件的功能，使用制动液作为动力传递媒介，同时具备液压备份制动系统，是目前的主流技术方案。而 EHB 根据集成度的高低，EHB 可以分为 Two-box 和 One-box 两种技术方案。
随着新能源汽车市场的扩张，「eBooster+ ESC」 组合成为了目前市场上最主流的 Two-box 方案。该方案除了实现基础的制动助力功能和稳定性控制功能外，还能在实现制动能量回收的同时协调配合，保证在电制动和液压制动的切换中实现驾驶员的踏板感一致。此外，随着高阶辅助驾驶系统和自动泊车系统的普及，「eBooster+ ESC」 在其中也扮演着实现制动冗余的角色。
另一方面，线控制动系统用电子器件代替部分机械部件，使得系统的安全性高度依赖电子器件的安全性和可靠性，这样一来，线控制动系统的功能安全开发显得尤为重要。
自从 2011 年功能安全标准 ISO 26262 自 2021 年正式发布，ISO 26262 聚焦于电子电气系统的功能安全，对产品的整个生命周期进行评估，涵盖功能性安全需求规划、设计、实施、集成、验证、确认和配置等方面，旨在通过完善的开发流程，将汽车电子电气系统故障的风险降到最低，是全球电子零部件供应商进入汽车行业的准入门槛之一。国内外各大主流汽车企业陆续将 ISO 26262 中定义的需求融入自己的研发体系和流程中。
在上两期文章中对危害分析与风险评估的方法论进行了介绍并以 「eBooster+ ESC」 组合为分析对象对该方法论展开实践，并导出了安全目标 (Safety Goal)。本章将以此为基础，结合 HBC（Hydraulic Brake Failure Compensation）功能对安全概念 (Safety Concept) 设计展开介绍和案例说明，旨在强调这一活动中的关键要点和关键步骤。
Safety concept 相关概念介绍
开发的本质实际上是实现需求。对于 「eBooster+ ESC」 系统功能安全开发而言，如何将 Safety Goal 转化成 「eBooster+ ESC」 系统架构中要素的的安全要求，是进行功能安全开发的核心之一。对应到 ISO 26262 中，这一工作包括了功能安全概念开发（Functional Safety Concept Development）和技术安全概念开发（Technical Safety Concept Development）。
在 ISO 26262 的 part3 和 part4 中，反复提到了以下几个关键的专有名词：
-
安全目标（Safety Goal）
-
功能安全概念（Functional Safety Concept）
-
功能安全要求（Functional Safety Requirement）
-
技术安全概念（Technical Safety Concept）
-
技术安全要求（Technical Safety Requirement）
当独立地看各个概念的定义时，理解起来没有什么难度；但是当这些概念同时出现时，却有些分不清彼此。接下来对这些概念进行对比和辨析。
安全目标与功能安全要求
安全目标是怎么得到的呢？前文提到，通过对整车进行危害分析和风险评估，识别出需要防止、减轻或控制的危害和危害事件，为每个危害事件制定安全目标，并将汽车安全完整性等级 (ASIL) 与每个安全目标关联。比如：
整车应避免驾驶员制动时减速度过小， ASIL D
而当相关项有造成某条安全目标所对应的危害事件的可能时，相关项就需要考虑这一条安全目标。如 「eBooster+ ESC」 系统有导致整车非预期减速的接口时，「eBooster+ ESC」 就继承了这一条安全目标：
「eBooster+ ESC」 应避免驾驶员制动时减速度过小， ASIL D
这样一来，安全目标变成了 「eBooster+ ESC」 系统最高层级的功能安全要求。
反过来，ISO 26262, part3, 8.4 中对功能安全要求的定义又指出：
如果适用，应考虑以下几点来定义每项功能安全要求:
a) 运行模式；
b) 故障容错时间间隔；
c) 安全状态；
d) 紧急运行时间间隔；及
e) 功能冗余 (例如故障容错)。
也就是说，功能安全要求除了 ASIL 等级以外，还包含部分或者全部 a) - e) 的属性。既然安全目标是最高层级的功能安全要求，那么安全目标必然也还包含部分或者全部 a) - e) 的属性。
总结：
-
安全目标是相关项最高层级的功能安全需求。
-
安全目标和功能安全需求一样，包含 ASIL 等级、FTTI、safe state 等属性。
功能安全要求与技术安全要求
通过上一节的说明读者可以发现，安全目标和功能安全要求的口吻像是甲方，「我需要功能实现 XX」，从这个角度，技术安全要求就是那个要满足甲方需求的乙方，需要回答 「功能应该怎么做实现 XX」。
ISO 26262, part3 中说明功能安全要求的导出时提到：
功能安全要求应由安全目标和安全状态导出，并考虑初步架构设想。
功能安全要求应分配给初步架构设想中的要素。
而在 ISO 26262, part4 中提到：
技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义:
a) 外部接口，如通讯和用户接口，如果适用；
b) 限制条件，例如环境条件或者功能限制；
c) 系统配置要求。
想必这已经很好理解，身为 「甲方」 的功能安全要求只需要根据大致的架构便可确定 「我需要功能实现 XX」；而身为 「乙方」 的技术安全要求则必须知道明确的细化的系统架构，才能够回答 「功能应该怎么做实现 XX」。
另一方面，技术安全要求如何实现功能安全要求呢？关键是定义必要的安全机制（safety mechanism）。
安全机制是 ISO 26262 中另一个非常重要的概念，其定义为：
为了达到或保持某种安全状态，由电子电气系统的功能或要素或其他技术来实施的技术解决方案，以探测故障、控制失效。
总结：
安全目标和功能安全要求均不表述为技术解决方案，而表述为功能目的。而技术安全要求侧重于解释 「如何做」。
技术安全要求通过定义具体的安全机制来实现 「如何做」。
功能安全概念与技术安全概念
个人认为实际上功能安全概念和技术安全概念都可以用一句话概括：
-
功能安全概念：为了实现功能安全目标，把功能安全要求分配给相关项中的初步架构要素或外部措施的一切活动的总和。
-
技术安全概念：为满足功能安全要求而设计系统架构和技术安全要求的一切活动的总和。
基于此，我们可以说，定义功能（技术）安全要求的过程就是在进行功能（技术）安全概念开发的过程，一些公司习惯性地合称为 「安全概念开发，Safety Concept Development」。
按照这个解释，Safety Concept Development 看起来是在定义可落地的系统方案和要求，与术语中给人空中楼阁之感的 「Concept」 一词有点违和。但是，如果鸟瞰整个功能安全开发，Safety Concept Development 是属于系统层的开发，输出为对系统最底层的要素 —— 软件和硬件的要求，而在完成了 Safety Concept Development 之后，只有当最底层的要素满足了功能安全要求时，才可以说产品满足了功能安全。从这个角度看，这里的 「Concept」 一词还是挺准确的。
Safety concept 设计举例
接下来将以 HBC（Hydraulic Brake Failure Compensation）功能为例，介绍 safety concept 设计的关键步骤。
ESC 和 eBooster 在车上共用一套液压系统，两者协调工作，原理如下：
-
eBooster 和 ESC 共用一套制动油壶、制动主缸和制动管路。
-
eBooster 内的助力电机产生驱动力推动主缸活塞运动，使油壶中的制动液流入主缸管路并进入 ESC 进液阀，经 ESC 中的调压阀和进液阀流入 4 个轮缸，从而建立起制动力。
-
当 eBooster 不工作时，ESC 也可以独立控制制动液从主缸流入轮缸，从而建立制动力。
-
eBooster 建压的动态响应速度比 ESC 主动建压更快，且 NVH 表现更好，因此 eBooster 是制动控制系统中的主执行机构。
在 ESC 和 eBooster 的协同工作下，可以衍生出更多功能。比如根据法规要求，对于舒适性制动系统，需要满足在驾驶员踩出 500N 的制动力时系统能够提供不小于 6.43m/s² 的减速度。正常情况下 eBooster 可以实现这一要求，而当 eBooster 出现故障无法继续提供助力时，要求 ESC 能够及时接管并通过主动建压的方式实现上述要求，这就是集成于 ESC 系统中的 HBC（Hydraulic Brake Failure Compensation）功能的基本原理。
当 HBC 功能激活后，当驾驶员踩下制动踏板时，主缸压力发生变化，HBC 功能根据主缸压力变化识别驾驶员制动意图，并控制建压泵工作主动建立轮缸压力，从而实现驾驶员助力。
确定 HBC 功能需求
基于上述介绍，可以罗列出如下对 HBC 的功能需求：
-
FR1: eBooster 应正确监控自身的助力能力
-
FR2: 当监控出无法完成助力能力时，eBooster 应该向 ESC 发送 HBC 请求
-
FR3: 当监控出无法完成助力能力时，eBooster 应该关闭自身的助力功能
-
FR4: 当收到 HBC 请求时，ESC 应激活 HBC 功能
-
FR5: ESC 应正确标定 HBC 助力曲线，保证驾驶员作用 500Nm 的制动力时制动系统应该提供不小于 6.43m/s² 的减速度
确定安全目标
继续选择上期文章中导出的一条安全目标，并补上其他安全相关属性（FTTI，fault amplitude 等）。
确定功能架构
确定功能架构的第一个目的在于明确功能的输入和输出。虽然标准的 eBooster 和 ESC 之间的接口繁多，但是单就 HBC 功能而言，所涉及的接口有限，因此为了分析的简单化，此处仅聚焦于 HBC 相关的接口。
确定功能结构的第二个目的是整理功能的信号链，这对后面进行功能安全分析很有帮助。HBC 的功能架构整理如下：
其中，DTS 传感器是 eBooster 的
一个重要输入。eBooster 助力的控制原理为：当驾驶员踩下制动踏板时，输入轴 (input rod) 推动柱塞 (Plunger) 移动，eBooster 控制电机转动实时保证柱塞和阀体 (Valve body) 的行程差为零，从而实现助力功能。DTS 传感器的作用是实时测量行程差。
确定输出信号的功能安全需求
对功能的输出信号的功能安全需求来自相关项顶层的安全目标。
根据 ECE-R13H 和国标 GB13594 的的法规要求，乘用车在电子助力失效的情况下，机械部件仍然要保证驾驶员在用 500Nm 踩制动踏板时能产生 2.44 m/s² 的减速度。eBooster 的机械设计也应满足这一法规要求。
ISO 26262 中提到：
在对相关项进行危害分析和风险评估过程中，可用的且充分独立的外部措施是有益的。
所以对 eBooster 而言，此处的机械部件可以被定义成 「外部措施」，由于这一外部措施的存在，E/E 系统故障不会造成 ASIL D 的危害，因此这条 Safety Goal 对 eBooster 而言可以降低为 ASIL C，具体要求如下：
由于 HBC 功能的存在，对于搭载 eBooster+ESC 制动系统的车辆，当整车违背 SG1 时，当且仅当下面两种情况同时发生：
-
eBooster 自身助力功能故障，且
-
eBooster 没能在助力功能故障时请求 ESC 激活 HBC 功能
因此在 eBooster 内部可以对 ASIL C 进行分解：
-
ASIL A (C): eBooster 助力功能
-
ASIL B (C): eBooster 助力功能监控和诊断
注意：此处分解有效的前提是 eBooster 助力功能和 eBooster 助力功能监控和诊断完全独立，互不影响。换句话说，eBooster 需要满足如下要求：
eBooster 需要避免存在同时导致助力功能故障和助力功能诊断故障的共因失效 (common cause), ASIL C
eBooster 实现这一需求需要在软硬件设计上都进行考虑，比较复杂，限于篇幅，对该需求不作展开，将目光回到 eBooster 的两个输出信号上。
(1) 目标助力值：BoostDemand
BoostDemand 为 eBooster 助力功能计算出的助力值，根据上面的分析，对 BoostDemand 的功能安全需求如下：
-
SR1: eBooster 需要在驾驶员踩制动踏板时正确计算助力值 BoostDemand
-
ASIL: A (C)
-
FTTI：600ms
-
safety amplitude: 错误小于 600Nm（假设产生 6m/s² 的减速度需要 600Nm 的目标助力值）
-
safe state: BoostDemand 归零
这条功能安全需求实际上包含两条功能需求：
-
SR1-1：eBooster 需要在驾驶员踩制动踏板时正确计算助力值 BoostDemand，ASIL A (C)
-
SR1-2：当 eBooster 无法正确计算 BoostDemand 时，需要在 600ms 内将 BoostDemand 归零，ASIL A (C)
(2) HBC 请求：HbcRequest
假设 ESC 在收到 HbcRequest 置为 1（激活 HBC）时，ESC 完成对驾驶员制动做出判断并在轮缸建立起对应的压力需要 200ms，因此为了满足 Safety Goal 的 FTTI 要求，eBooster 需要在 600-200=400ms 内正确检测出助力能力问题并发出 HBC 激活请求。
基于此，对 HbcRequest 要求为：
-
SR2: eBooster 在监控出助力功能异常时应发出 HBC 激活请求 HbcRequest=1
-
ASIL: B (C)
-
FTTI：400ms
确定信号链的功能安全需求并进行开发
功能安全开发是一个合作的过程，这包括供应商和主机厂之间的合作，或者供应商或主机厂内部不同角色的工程师之间的合作。无论是哪一种合作模式，对某个功能的功能安全需求实际上是对功能输出信号的需求，而要想输出信号满足需求，依赖于三点：
-
输入信号满足功能安全需求
-
软件模块满足功能安全需求
-
硬件满足功能安全需求
确定了对这些要素的功能安全需求后，接下来便依据 ISO 26262 进行功能安全开发。
释放对输入信号的功能安全需求
在功能安全分析完成后，软件工程师需要及时将对输入信号的功能安全需求释放给信号提供方，这一工作的接口通常是系统层功能安全工程师。拿供应商举例，常见的流程是软件工程师将对输入信号的功能安全需求汇总给系统功能安全工程师，系统功能安全工程师则将所有输入信号需求汇总并释放给 OEM 的系统功能安全工程师，OEM 的系统功能安全工程师向提供方 (OEM 开发工程师或者另一个供应商) 确认功能安全需求是否能够实现并将结果反馈给供应商。如果无法实现，则双方需要共同讨论是否要改变当前的 safety concept。从这个角度看，输入信号的功能安全需求是 OEM 和供应商之间推动功能安全合作的窗口。
