特约专栏 | FTTI与Fail Operational

SASETECH，Safety and Security Technology，是国内首个由汽车功能安全、信息安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。安全是汽车的基石，安全从业者是人们生命及财产的守护者。我们希望SASETECH 打破高大上的壁垒，让更多工程师参与讨论、共同成长；让安全成为一个话题，是一个让大家讨论和思考的技术方向；让安全成为一种文化，是一个让企业和监管机构愈发重视的领域；建立安全的生态，让企业/从业者都能够有所收获、有所思考。

欢迎关注：SASETECH

内卷的广汽车展上，各家厂商在自动驾驶配置频频“秀肌肉”。长城沙龙搭载4颗激光雷达，整车传感器数量达38颗，双华为MDC智能计算平台；飞凡R7共配有2个ZF4D超声波雷达，6个长距点云雷达，一个1550纳米Luminar激光雷达，英伟达Orin X芯片；搭载华为全栈自研Huawei Inside智能解决方案的阿维塔11……

 图1：广州车展—机甲龙 

随着智驾的发展，越来越多的公司都愈发想突破L2的限制，向更高阶的自动驾驶迈进。其中，功能安全是一座大山，L2级智驾更多是fail safe系统，当功能达到L2+以上，fail operational经常出现在大家视野中。本文将就高阶自动驾驶fail operational策略初步探讨下。

对于许多E/E系统，丢失功能不会导致危害事件发生，因此安全状态可以是switch off the system。然而某些case下，丢失功能会导致潜在危害发生，这样的安全目标将导出safety availability requirement，需求中应包含避免危害事件的必要功能定义，故障响应，安全状态定义。对应的安全措施有：fault tolerance, fault forcasting, fault prevention, fault detection。

 表1：常见安全措施分类 

其中fault tolerance，fault prevention补充说明下，前者主要解决random HW fault，后者主要解决systematic fault。

FTTI是功能安全常见的概念，是相关项的一个特征属性，指故障在整车显现到故障无法避免的时间间隔。FHTI指安全机制的一个特征属性，包括FDTI（故障检测时间）+FRTI（故障处理时间），通常应保证FHTI＜FTTI。然而，如果安全状态无法在FTTI时间内达到时，车辆会进入紧急操作模式（emergency operation mode）, 紧急操作将在FTTI到达终点前开始，并在EOTTI (emergency operation tolerance time interval)进入安全状态。

 图2：FTTI与EOTTI关系 

对于fault tolerant item，一旦发生故障，功能将会维持一段时间后进入安全状态。在过渡到安全状态的过程中，会发生整车级的故障响应（例如，将车速限制在30 km/h）。但是，在完成车辆级故障响应前，在EOTTI内发生的另一故障可能会导致危险事件，即此时系统的ASIL capability＜ASIL Hazard。为了将风险降至最低，EOTTI将被限制在一段确定的时间，如何计算在文章最后会介绍两种方案。

⚠️注意：

某些case下，驾驶员的操作时间也应该考虑在紧急操作时间之内，而不仅仅是OEM的责任。例如，一个前照灯灯泡烧坏，检测到故障并将故障通知驾驶员。驾驶员有责任在合理的时间内修理前照灯；或者智驾系统发生紧急故障并TOR给驾驶员，驾驶员有责任在一定时间将车辆控制在本车道或刹停。

实现安全目标的两种策略：

案例1（Highly automated driving system）

item在发生故障后维持功能。功能将一直运行，直到相关项修复为止。修复前，车辆的工作状态不受限制。但需在允许的时间间隔（EOTTI）内对相关项进行修复。

案例2（Steering by wire system）

item在发生故障后维持功能，车辆运行状态将受限（如车速降低），无时间限制。在这种情况下，车辆在允许的时间间隔（EOTTI）内达到限制的车辆运行状态，车速降低至V_2Kph。

 图3：Example vehicle speed history for highly automated driving system（HAD）

 图4：Example vehicle speed history for steer by wire system（SBW）

对两个案例进行功能安全的分析，包括HARA，安全目标，安全状态，安全需求导出，整理在下方表格。

 表2：两个案例安全分析 

我的理解：

1.分解的前提是两通道正常时，满足系统性失效 ASIL D，随机硬件失效ASILD；同时有ASIL Safety Mechanism保证车辆进入安全状态(车速降低至2kph)。

2.当通道1故障时,安全状态是车速降低至V_2kph，此时系统需要的ASIL Capability是ASIL A，因此对随机硬件失效，通道2满足ASLA即可。同样如果通道2故障，车辆降低车速至2kph后，通道1的随机硬件失效满ASIL A即可。

我的理解:

对于case1（HAD）应该如此，因为如果车辆在EOTTI内, ASIL capability<asil hazard<=”” div=””>仍然有潜在的风险，HW fault可以通过限制EOTTI时间也解决,但系统性失效怎么解决?我

想从安全角度,继承原有的 safety goal等级比较合适。

对于case2（SBW），个人理解不需要单通道达到ASIL D，因为进入安全状态2后需要的ASIL capability是ASIL A，但标准仍然要求ASIL D，此处各位可以斟酌下。

这里其实涉及到ASIL分解，标准给了这样的例子：

假设Item 安全目标是：应防止在超过X的时间内损失超过60%的输出能力 ASIL D。该item包括两个独立组件，每个组件提供50%的预期输出。每个组件都有足够的能力维持40%以上的功能，并足以维持控制和预防危险。当其中一个组件发生故障时，车辆在降级模式下运行，因为其性能受到限制，HARA确定了降级模式下运行风险是的ASIL B级别，此时每个部件的最小ASIL能力应为ASIL B，最合适分解为ASIL B（D）和ASIL B（D）。

我的理解: 

当一侧通道发生故障，车辆进入降级模式，比如安全停车，之后因为另一侧通路仍然可以工作，车辆起步继续运行，直到t5时刻，车辆进入维修店，紧急操作结束。

方法1：

Teotti也可以通过将其视为发生故障或失去冗余后item状态的一个参数来加以限制。

在这种状态下，通过比较违反安全目标的概率指标与车辆预期使用量(PMHF* Tlifetime)来确定Teotti在无冗余运行时违反安全目标的概率度量。即失去冗余后车辆在一段时间内的失效概率不应该超过原有安全目标定义的整个生命周期内随机硬件失效概率。

方法2：

另一种方式可以将两通道失效看作双点失效，单通道失效模块1作为IF，模块2作为SM1，则Part10中8.3.2.4中PMHF的公式可以使用。检测潜伏失效的周期Tservice可以当做Teotti简化处理。

通过如上公式推导，可以得到Teotti计算方式如下：

本文从广州车展引入，介绍OEM智驾发展将趋向于L2+功能，重点解释fail operational中几个重要概念，并以Highly Automated Driving，Steer By Wire系统为例，分析两系统发生单通道失效后的fail operation策略，并导出初始安全需求。最后对标准中两种EOTTI的计算方式进行简要解释。

本文是对标准的解释并结合了自身的理解, 很多内容偏方法论，落实到实际应用中仍有较多问题需要解决。比如：

还有更多的问题需要行业内的专家持续努力，共同攻坚！