智能底盘技术(15) | Two-box方案‘ESC+eBooster’功能安全之安全概念设计

作者 | 磐匠

出品 | 焉知

知圈 | 进“滑板底盘群”请加微yanzhi-6,备注底盘

根据制动执行机构的不同，线控制动系统（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示意图

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）

当独立地看各个概念的定义时，理解起来没有什么难度；但是当这些概念同时出现时，却有些分不清彼此。接下来对这些概念进行对比和辨析。

1.1.  安全目标与功能安全要求

安全目标是怎么得到的呢？前文提到，通过对整车进行危害分析和风险评估，识别出需要防止、减轻或控制的危害和危害事件，为每个危害事件制定安全目标，并将汽车安全完整性等级(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等属性。

1.2.  功能安全要求与技术安全要求

通过上一节的说明读者可以发现，安全目标和功能安全要求的口吻像是甲方，“我需要功能实现XX”，从这个角度，技术安全要求就是那个要满足甲方需求的乙方，需要回答“功能应该怎么做实现XX”。

ISO 26262, part3中说明功能安全要求的导出时提到：

功能安全要求应由安全目标和安全状态导出，并考虑初步架构设想。

功能安全要求应分配给初步架构设想中的要素。

而在ISO 26262, part4中提到：

技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义:

a)外部接口，如通讯和用户接口，如果适用；

b)限制条件，例如环境条件或者功能限制；

c)系统配置要求。

想必这已经很好理解，身为“甲方”的功能安全要求只需要根据大致的架构便可确定“我需要功能实现XX”；而身为“乙方”的技术安全要求则必须知道明确的细化的系统架构，才能够回答“功能应该怎么做实现XX”。

另一方面，技术安全要求如何实现功能安全要求呢？关键是定义必要的安全机制（safety mechanism）。

安全机制是ISO 26262中另一个非常重要的概念，其定义为：

为了达到或保持某种安全状态，由电子电气系统的功能或要素或其他技术来实施的技术解决方案，以探测故障、控制失效。

总结：

• 安全目标和功能安全要求均不表述为技术解决方案，而表述为功能目的。而技术安全要求侧重于解释“如何做”。

• 技术安全要求通过定义具体的安全机制来实现“如何做”。

1.3.  功能安全概念与技术安全概念

个人认为实际上功能安全概念和技术安全概念都可以用一句话概括：

• 功能安全概念：为了实现功能安全目标，把功能安全要求分配给相关项中的初步架构要素或外部措施的一切活动的总和。

• 技术安全概念：为满足功能安全要求而设计系统架构和技术安全要求的一切活动的总和。

基于此，我们可以说，定义功能（技术）安全要求的过程就是在进行功能（技术）安全概念开发的过程，一些公司习惯性地合称为“安全概念开发，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是制动控制系统中的主执行机构。

eBooster和ESC的制动液压系统

在ESC和eBooster的协同工作下，可以衍生出更多功能。比如根据法规要求，对于舒适性制动系统，需要满足在驾驶员踩出500N的制动力时系统能够提供不小于6.43m/s²的减速度。正常情况下eBooster可以实现这一要求，而当eBooster出现故障无法继续提供助力时，要求ESC能够及时接管并通过主动建压的方式实现上述要求，这就是集成于ESC系统中的HBC（Hydraulic Brake Failure Compensation）功能的基本原理。

当HBC功能激活后，当驾驶员踩下制动踏板时，主缸压力发生变化，HBC功能根据主缸压力变化识别驾驶员制动意图，并控制建压泵工作主动建立轮缸压力，从而实现驾驶员助力。

HBC系统架构

2.1.  确定HBC功能需求

基于上述介绍，可以罗列出如下对HBC的功能需求：

#FR1: eBooster应正确监控自身的助力能力

#FR2: 当监控出无法完成助力能力时，eBooster应该向ESC发送HBC请求

#FR3: 当监控出无法完成助力能力时，eBooster应该关闭自身的助力功能

#FR4: 当收到HBC请求时，ESC应激活HBC功能

#FR5: ESC应正确标定HBC助力曲线，保证驾驶员作用500Nm的制动力时制动系统应该提供不小于6.43m/s²的减速度

2.2.  确定安全目标

继续选择上期文章中导出的一条安全目标，并补上其他安全相关属性（FTTI，fault amplitude等）。

Safety goal	eBooster应避免驾驶员制动时减速度过小。
ASIL level	ASIL D
safety amplitude	小于6m/s² (指减速度的绝对值)
FTTI	600ms
safe state	Request HBC and warn driver

2.3.  确定功能架构

确定功能架构的第一个目的在于明确功能的输入和输出。虽然标准的eBooster和ESC之间的接口繁多，但是单就HBC功能而言，所涉及的接口有限，因此为了分析的简单化，此处仅聚焦于HBC相关的接口。

确定功能结构的第二个目的是整理功能的信号链，这对后面进行功能安全分析很有帮助。HBC的功能架构整理如下：

HBC功能架构

其中，DTS传感器是eBooster的

一个重要输入。eBooster助力的控制原理为：当驾驶员踩下制动踏板时，输入轴(input rod)推动柱塞(Plunger)移动，eBooster控制电机转动实时保证柱塞和阀体(Valve body)的行程差为零，从而实现助力功能。DTS传感器的作用是实时测量行程差。

2.4.  确定输出信号的功能安全需求

对功能的输出信号的功能安全需求来自相关项顶层的安全目标。

根据ECE-R13H和国标GB13594的的法规要求，乘用车在电子助力失效的情况下，机械部件仍然要保证驾驶员在用500Nm踩制动踏板时能产生2.44 m/s²的减速度。eBooster的机械设计也应满足这一法规要求。

ISO 26262中提到：

在对相关项进行危害分析和风险评估过程中，可用的且充分独立的外部措施是有益的。

所以对eBooster而言，此处的机械部件可以被定义成“外部措施”，由于这一外部措施的存在，E/E系统故障不会造成ASIL D的危害，因此这条Safety Goal对eBooster而言可以降低为ASIL C，具体要求如下：

Safety goal	eBooster应避免驾驶员制动时减速度过小。
ASIL level	ASIL C
safety amplitude	小于6m/s² (指减速度的绝对值)
FTTI	600ms
safe state	Request HBC and warn driver

由于HBC功能的存在，对于搭载eBooster+ESC制动系统的车辆，当整车违背SG1时，当且仅当下面两种情况同时发生：

1.eBooster自身助力功能故障，且

2.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

2.5.  确定信号链的功能安全需求并进行开发

功能安全开发是一个合作的过程，这包括供应商和主机厂之间的合作，或者供应商或主机厂内部不同角色的工程师之间的合作。无论是哪一种合作模式，对某个功能的功能安全需求实际上是对功能输出信号的需求，而要想输出信号满足需求，依赖于三点：

• 输入信号满足功能安全需求

• 软件模块满足功能安全需求

• 硬件满足功能安全需求

确定了对这些要素的功能安全需求后，接下来便依据ISO 26262进行功能安全开发。

2.6.  释放对输入信号的功能安全需求

在功能安全分析完成后，软件工程师需要及时将对输入信号的功能安全需求释放给信号提供方，这一工作的接口通常是系统层功能安全工程师。拿供应商举例，常见的流程是软件工程师将对输入信号的功能安全需求汇总给系统功能安全工程师，系统功能安全工程师则将所有输入信号需求汇总并释放给OEM的系统功能安全工程师，OEM的系统功能安全工程师向提供方(OEM开发工程师或者另一个供应商)确认功能安全需求是否能够实现并将结果反馈给供应商。如果无法实现，则双方需要共同讨论是否要改变当前的safety concept。从这个角度看，输入信号的功能安全需求是OEM和供应商之间推动功能安全合作的窗口。

功能安全合作示意图

系列文章介绍
焉知智能汽车持续关注智能底盘的进化，同时致力于打造系列文章将涵盖智能底盘的所有领域，推出《智能底盘技术系列文章》，对底盘系统的技术方案及发展趋势进行深入的探讨。基于这一定位，系列文章将围绕以下框架展开深入的研究。

• 底盘系统的主流产品介绍与行业动态（产品介绍、功能设计、功能安全设计、国内外玩家现状等方面展开）

• 制动系统篇

• 转向系统篇

• 驱动系统篇

• 悬架系统篇

• 智能底盘的发展新趋势

• 底盘域融合

• 新电子电气（E/E）架构

• 智能底盘安全拓展 （功能安全，预期功能安全，信息安全）

• 滑板底盘

该系列文章将在“焉知智能汽车”公众号上持续连载更新，欢迎感兴趣的读者点击左下角“阅读原文”订阅专栏，或订阅“智能底盘”合集标签。同时欢迎留言讨论。受限于作者的水平，如文章有不正确之处也欢迎读者留言指正。