EPB功能安全笔记(3)：如何定义一条完整的Safety Goal？

本文要点

在上文【EPB功能安全笔记​​（1）​​​​(2)）​​】中，对EPB系统地进行了危害分析与风险评估。ISO 26262要求，应为具有ASIL等级的每个危害事件确定一个安全目标。比如对于以下危害事件：

我们可以定义一条Safety Goal：

EPB应避免错误建压而造成过高的减速度 → ASIL C

Safety Goal本质上是最高层级（整车层）的功能安全需求，也是功能安全开发的目标和基础。但是，面对着上面这一条需求，开发人员很难不一头雾水。因为我们可以问出一系列问题：

1.减速度大于多少算是“过高”？

2.减速度过高一定会导致危害吗？

3.减速度过高导致的危害都是ASIL C吗？

实际上，除了ASIL等级以外，Safety Goal还有其他属性，本文将对Safety Goal的其他属性进行介绍，以期读者在阅读完本文后可以回答上述问题。

ISO 26262对功能安全需求的定义

ISO 26262-2018第三部分7.4.2.4中总结了功能安全需求的属性。

Each functional safety requirement shall be specified by considering the following, as applicable。

     a) operating modes;

     b) fault tolerant time interval;

     c) safe states;

     d) emergency operation time interval; and

     e) functional redundancies (e.g. fault tolerance).

这里需要特别注意比较容易忽略的词：“as applicable（如果适用）”。这表明，并不是每条功能安全需求都需要同时包含a)~e)。但是即便如此，a)~c)是三个基础的属性，每个Safety Goal都应该定义这三个属性。

对于d)和e)，由于涉及到的use case比较复杂，计划在系列文章的后半段再展开说明，本文暂不做涉及。

1.1.operating modes (运行模式)

conditions of functional state that arise from the use and application of an item or element.（相关项或要素的可感知的功能状态。）

EXAMPLE: System off; system active; system passive; degraded operation; emergency operation; safe state.

这个属性比较好理解，就是功能安全需求所对应的系统运行模式。

1.2.fault tolerant time interval, FTTI (故障容错时间间隔)

minimum time-span from the occurrence of a fault in an item to a possible occurrence of a hazardous event, if the safety mechanisms are not activated. (在没有安全机制的情况下从相关项出现故障到危害事件发生的最小事件间隔)

fault tolerant time interval, FTTI

FTTI可以说是功能安全最重要的概念之一。本文以2018版ISO 26262的定义为基准。

2018版ISO 26262对FTTI定义最主要的一点更新就是强调了“without safety mechanism”。为什么要强调这一点呢？前面的文章提到：“在危害分析和风险评估过程中，应对不含内部安全机制的相关项进行评估，即在危害分析和风险评估过程中不应考虑将要实施或已经在前代相关项中实施的安全机制”；而Safety Goal是基于危害分析和风险评估得到的，换句话说，确定Safety Goal的过程中也不考虑任何安全机制。从这一点上看，2018版的这一处更新是在强调：FTTI是Safety Goal的一个属性。如果把Safety Goal看作是整车层的功能安全需求，那么FTTI也应该在整车层定义。这一更新也是对2011版ISO 26262的FTTI概念定义不清的纠正。做过功能安全开发的朋友可能深有体会，2011版ISO 26262对FTTI的概念定义在整车层、系统层、软硬件层是混用的。

1.3.safe state(安全状态)

operating mode, in case of a failure, of an item without an unreasonable level of 

risk. (没有不合理风险的相关项的运行模式)

EXAMPLE: Switched-off mode

safe state

讨论safe state的前提是考虑了执行安全措施（safety mechanism）。因为当相关项的故障发生后，只有正确且及时地执行了安全措施，危害才有可能避免。

那么如何定义safe state呢？我们也许可以从一个问题上入手：产品是用不是用在自动驾驶车辆中？

对于自动驾驶，当系统在出现故障之后，需要系统来自己操作避免事故（自动驾驶等级越高，驾驶员可以越晚介入接管甚至是完全不用接管），出了事故是厂家的责任而不是驾驶员的责任。

在这种情况下，整车层的safe state的定义方向为：及时切换到冗余系统。

对于非自动驾驶系统，可以把所有的E/E系统看作是帮助驾驶员更好驾驶的辅助产品。那么既然是辅助产品，当系统出现故障以后，只要系统及时退出工作，并正确向驾驶员报告了故障，那么接下来是驾驶员的责任，无论事故是否能够被避免。

在这种情况下，整车层的safe state的定义方向为：系统退出并报警提醒驾驶员。

如何确定Safety Goal的其他属性？

通过上节我们可以看到，operation mode和safe state相对比较好确定，因此补充完整Safety Goal的关键在于确定FTTI。

实际功能安全开发过程中是如何定义FTTI的呢？概括来说，就是设计相应的测试用例，通过故障注入的方式进行实车测试或者模型仿真。

整车测试的优势在于真实性，但是成本高昂，且容易受到不必要因素的干扰，尤其是对于多车参与的场景；仿真在成本上优势明显，且对场景的复现性强，更有利于排除不必要因素的干扰。因此，除了对整车动力学模型精准度要求极高的场景（比如车辆失稳）外，一般都采用仿真的方式。

为尽可能保证仿真结果的可信度，一般选取偏保守的参数，使得仿真得出的结果相比实车更严苛。但同时也可能在一些安全目标上增加了功能安全开发的难度。

接下来就以下面这条Safety Goal为例，说明如何通过仿真确定FTTI。Safety Goal背后的场景为：两辆车运行在同一车道且速度相近，前车非预期减速。

EPB应避免错误建压而造成过高的减速度 → ASIL C

同一车道内前车突然非预期减速

针对这一场景搭建的整车模型至少需要包含如下关键参数：

根据仿真结果，我们可以得到不同减速度和不同初始速度下两车是否会发生碰撞，以及发生碰撞时刻两车的相对速度。

不同的碰撞速度将影响S值评分，如下图所示：

场景：同一车道内前车非预期减速

对于E值，可以根据两车初速度对场景做进一步的细分，如下表所示。

对于C值，如果两车在碰撞发生前持续的时间比较长，则后车驾驶员有较高的可能性在这段时间内通过转向避免和前车相撞。因此C值也可以适当调整：

综合上述的S/E/C评分标准和仿真得到的碰撞速度的结果，我们可以大致得到这样一个表格。这个表格定量地给出了评价Safety Goal是否被违背的标准，因此也被称为safety margin (或safety criteria) 。

仿真得到的safety margin

注意：这里的参数和结果举例仅为了解释说明，具体值和真实的开发存在差距。

前面提到，FTTI在没有安全机制的情况下从相关项出现故障到危害事件发生的最小事件间隔。根据仿真结果，我们可以看到，不同的ASIL等级对应不同的FTTI。比如造成ASIL C的hazard，FTTI最短为1.4s；而造成ASIL A的hazard，FTTI最短为0.6s。

与此同时，不同的ASIL等级也对应着不同的减速度范围。比如减速度小于-7m/ss才可能造成ASIL C的hazard；而当减速度小于-3m/ss时就有可能造成ASIL A的hazard。

由此，对于开头提出的三个问题也有了答案。

总结

Safety Goal作为最高层级的功能安全需求，除了ASIL等级以外，还有其他的属性。只有当其他属性也被清晰地定义后，这条Safety Goal才是完整的，接下来才能以Safety Goal为目标和指导进行功能安全开发。

基于上面的分析，我们可以将本文开始提到的Safety Goal补充完整。

Safety Goal：EPB应避免错误建压而造成过高的减速度

ASIL: C 

FTTI：see safety margin

safe state: EPB shut down and warn driver

safety margin:

这里有一点需要补充，按照上面这条Safety Goal的描述，相当是按照不同的ASIL等级及对应的FTTI细分出了三条Safety Goal，这对后续的功能设计来说未免有点复杂。比如为了实现Safety Goal，我们会设计相应的安全机制（safety mechanism），那么理论上这里需要定义三个安全机制。但是实际上这三个安全机制的作用是重叠的，本质上都是对减速度进行限制。简单的做法就是按照最高要求设计一个安全机制，同时覆盖三条细分的Safety Goal的需求。这样一来，对ASIL等级和FTTI都选取最严格的值，得到一条简化后的Safety Goal。

Safety Goal：EPB应避免错误建压而造成过高的减速度

ASIL: C 

FTTI：600ms

safe state: EPB shut down and warn driver

safety margin: deceleration < -3m/ss

这样定义的Safety Goal简化了功能安全设计，但是显然是增加了开发难度的。所以如果后续的开发能够满足这样严苛的Safety Goal那就充分利用了简化的优势；如果无法满足，可以按照原始的safety margin降低难度再进行开发。

本文转载自：焉知智能汽车