特约专栏 | FTTI与Fail Operational

汽车安全 2年前 (2021) admin
1,560 0 0

?本文约2850字,大约需要9分钟阅读


导语:


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

欢迎关注:SASETECH



前言


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


特约专栏 | FTTI与Fail Operational

 图1:广州车展—机甲龙 


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



Safety Availability

Requirement


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


特约专栏 | FTTI与Fail Operational

 表1:常见安全措施分类 


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



EOTTI


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


特约专栏 | FTTI与Fail Operational

 图2:FTTI与EOTTI关系 


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


⚠️注意:

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



Fail Operational

两个案例


假设:特定功能的严重丢失超过时间x可能导致ASIL Y等级的危险事件,ASIL等级取决于功能丢失时的车速→SG:避免特定功能的丢失时长超过x(FTTI)(ASIL D)


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


案例1(Highly automated driving system)

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


案例2(Steering by wire system)

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


相关项描述:

①.相关项由两个足够独立的通道(channel)组成,通道A和通道B。通道A提供正常功能。通道B为备用系统,其性能高于安全运行所需的最低性能水平。


②.如果通道A故障导致功能能力严重丧失,则在时间X内激活通道B,以防止违反安全目标。


③.对系统性失效,通道A和通道B中的每个channel都满足ASIL D。


④.对随机硬件失效,通道A和通道B的组合可以满足ASIL D。



特约专栏 | FTTI与Fail Operational

 图3:Example vehicle speed history for highly automated driving system(HAD)


失效发生后的几个重要时间点:

t1:故障发生,有潜在违反安全目标可能性

t2:故障被检测到

t3:故障响应结束,紧急操作(emergency operation)开始

t4:故障响应若未完成,危害事件可能发生

t5:系统进入安全状态,紧急操作结束

t6:许最晚到达安全状态的时间

t1-t4: FTTI

t3-t6: EOTTI


特约专栏 | FTTI与Fail Operational

 图4:Example vehicle speed history for steer by wire system(SBW)


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

特约专栏 | FTTI与Fail Operational

 表2:两个案例安全分析 



Remaining Question


Question 1

为什么steer by wire的case可以要求单通道随机硬件失效满足ASIL A,而HAD case却没对单路提硬件失效指标?

我的理解:

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


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


Question 2

为什么对两通道中每个channel的系统性失效都要求ASIL D?

我的理解:

对于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)。


Question 3

为什么HAD case的图中有一段车速降为0后又起步运行一段时间后降至0?

我的理解: 

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



如何计算EOTTI


方法1:

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


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

特约专栏 | FTTI与Fail Operational


方法2:

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

特约专栏 | FTTI与Fail Operational


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

特约专栏 | FTTI与Fail Operational



总结


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


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


①.出于成本考虑两条通路经常使用同一传感器(比如激光雷达),如何保证独立性,如何解决common cause? 


②.SOTIF common cause如何考虑,比如同一trigger event将会同时引起两个通路中的零件发生功能不足或者单通路上多节点发生功能不足?


③.发生单通路失效(FUSA或SOTIF)后的降级策略如何制定,降到L2.5还是L2还是安全停车,结合降级策略如何拆解出对相关零件的安全需求?


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


END



作者简介

小南郭

某OEM 智驾功能安全工程师,负责高低速智驾功能安全开发与流程管理。4年系统功能安全开发经验,熟悉ACC/AEB/RPA/HWA/TJP等产品功能安全方案。


特约专栏 | FTTI与Fail Operational


往期精选

特约专栏 | FTTI与Fail Operational

特约专栏 | FTTI与Fail Operational

特约专栏 | FTTI与Fail Operational

特约专栏 | FTTI与Fail Operational


SASETECH专家申请(请扫右侧二维码提交)

特约专栏 | FTTI与Fail Operational

微信交流群入群

(添加管理员微信,备注公司+姓名+研究领域)

特约专栏 | FTTI与Fail Operational


SASETECH组织致力于推动功能安全、系统安全、网络安全、预期功能安全的业内交流和技术进步,打造全新智能网联汽车安全生态圈。欢迎加入!

特约专栏 | FTTI与Fail Operational

原文始发于微信公众号(SASETECH):特约专栏 | FTTI与Fail Operational

版权声明:admin 发表于 2021年12月13日 上午12:00。
转载请注明:特约专栏 | FTTI与Fail Operational | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...