0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

基于仿真的自动驾驶安全分析故障注入方法

ml8z_IV_Technol 来源:未知 作者:胡薇 2018-09-07 10:14 次阅读

随着自动驾驶汽车的发展,在故障的情况下确保车辆安全变得越来越重要。本文提出了一种基于仿真试验的故障注入方法(Sabotage),以在ISO 26262的概念阶段作为传统安全分析方法的补充,依据试验数据得到失效影响,并完善安全目标及安全要求。之后将该方法应用于自动驾驶汽车横向控制系统的安全分析中,得到其模型中出现的故障的影响,基于最大横向误差及转向饱和*得到故障容错时间间隔(Fault Tolerant Time Interval,FTTI),并推导得到安全目标及安全要求。

一、 自动驾驶汽车控制架构

本文是针对高级自动驾驶汽车(HAV)的功能安全研究。HAV架构主要分为横向和纵向控制。本文研究针对横向控制系统,该系统目的是引导车辆沿着最佳路径行驶,由三个基本的功能组成:

行为规划:依据车辆行为(如车道保持、变道或者避障)来选择最好的路径。

轨迹控制:通过控制算法进行计算并保持车辆在正确的轨迹上。

转向:控制方向盘来使车辆按规划路径行驶。其输入为轨迹控制模块计算得的校正值。

二、基于ISO 26262的SABOTAGE框架

1.框架:SABOTAGE

现有版本的ISO 26262的概念阶段,主要通过例如FMEA等安全分析方法进行安全评估,由于自动驾驶汽车系统的复杂性,某一失效的影响不一定预先可知,这导致分析结果的不完整。故障注入则提供了一种评估高级自动驾驶系统安全性和可控性的有效的补充方法。在已知故障类型的条件下,利用故障注入可以得到系统运行期间发生某一故障的影响及相关故障数据。图1展示了基于故障注入仿真的自动驾驶汽车功能安全分析方法。该方法可作为评估早期设计阶段某个架构安全性的补充手段。通过分析仿真数据,可以在数个较优的安全概念之间加以权衡和选择。

图1:Sabotage:基于仿真的故障注入框架

依据该框架,本研究所提Sabotage方法的大致流程为:

第一步,识别失效模式。首先,必须已知相关项的主要功能及其故障类型。然后正确识别功能失效模式,以获得关于其影响的数据(在系统/整车层级)。这意味着如果这些失效模式定义在系统层,其影响便体现在整车上。这些故障/失效模式与保存在通用故障模型库中的通用故障模型(遗漏Omission,冻结Frozen,延迟Delay,翻转Invert,振荡Oscillation,随机Random)相关联。这些通用故障模型是预先设置的,是模拟任何组件/系统功能失效模式的特定故障模型。

第二步,配置故障注入试验。在对系统进行初步分析后,必须配置故障注入试验,将其作为工作负载生成器(Workload Generator)的一部分,这包括设置试验和驾驶场景,以及生成故障列表:

目标:在何处注入故障?

故障模型:何为代表该功能失效模式的最佳故障模型?

触发:如何在系统中触发故障?

何为故障影响的观测点?

如何定义使车辆失去其可控性的条件?

对于用户想要注入的每个故障,必须在故障列表中明确涉及的故障模型、目标信号(故障定位)、基于时间或路径位置坐标(X,Y)的故障触发条件以及故障持续时间。这些信息是生成故障发生器(Saboteur)的基础。故障发生器是为了故障注入而添加到系统行为模型中的组件。每产生一个目标信号,一个故障便被注入。

试验的配置包括车辆的选择及运行情况(Operational Situation)的定义:

地点:高速公路,城市;

道路状况:上坡,弯道;

环境条件:良好,暴雨;

交通状况:流畅;

车速;

行为:停车,超车,车道保持;

潜在风险参与者:司机,乘客,行人;

试验场景由场景配置器基于先前定义的运行情况选择场景目录中的最佳驾驶场景,以便将其加载到Dynacar平台中(一个实时车辆动力学仿真系统)。

第三步,创建故障化被测系统(Faulty System Under Test)。为此,故障注入器模块根据故障列表的信息及通用故障模型模板,创建故障发生器代码。该过程可以基于库和列表的数据自动化实现。

第四步,将故障化被测系统与无故障系统的模拟结果进行比较,分析故障影响,从而可以导出适当的安全目标及安全要求。

2.在ISO 26262概念阶段使用Sabotage

上节所提Sabotage方法可以应用于ISO 26262的概念阶段。在已知相关项功能及故障类型的前提下,通过故障注入仿真在危害分析和风险评估流程中得到某一故障产生的影响,并据此细化安全目标,并在功能安全概念流程中,推导得到安全要求。其具体的应用为:

1.通过故障注入而不是FMEA等安全分析方法进行危害识别。通过Dynacar虚拟环境可以直观地看到危害(例如在应该转弯时车辆没有转弯)。

2.根据仿真结果和危害识别细化安全目标。

3.FTTI和安全状态的确定。如图2所示,FTTI是从一个故障被注入到危害发生之间的时间。对于高级自动驾驶系统,FTTI决定了使车辆不会失去控制所需的容错等级(如冗余、功能降级)。

4.比较无故障和有故障的仿真模拟结果,安全要求可由两种仿真间的最大差异推导得到。

5.根据先前结果,将安全要求将被划分到功能安全概念中。

图2:故障-错误-失效链及FTTI的定义

三、横向控制系统的安全评估

本节为将Sabotage应用于基于ISO 2626概念阶段的对现有横向控制系统(其为高级自动驾驶车辆车道保持功能的一部分)的安全评估的实例。由于该模型没有适当的安全机制,通过分析FI仿真结果可以解决以下问题:

根据故障注入仿真的结果,获取特定故障在车辆和相关项层级的影响数据。

完成安全分析:确定安全目标(包括FTTI值及安全状态)、功能安全要求和安全概念。

以下为本次研究在ISO 26262概念阶段各流程的分析过程及结果:

1 相关项定义

如第二章所述,本文所提方法的应用前提是在ISO 26262的相关项定义流程中明确相关项功能及其故障类型:横向控制相关项可以分解为多个功能和子功能,其故障包括:转向(遗漏错误Omission、委托错误Commission),轨迹控制(遗漏或委托错误),行为规划器(不需要的局部规划,不需要的感知, 不需要的决策)。

2危害分析和风险评估

FI仿真结果可以作为该流程在安全分析方法外的一个补充办法,主要是依据仿真进行危害识别,并得到安全目标(以FTTI值为主)。

本次研究所做FI仿真试验为在交通流畅的城市环境下,以45km/h的恒定速度行驶并开启车道保持功能的车辆,当车辆在弯道上行驶时将触发故障,再现与差分GPS(DGPS)和转向系统相关的功能失效模式。实验中所设置故障列表如表1所示。

*该表格仅为本次研究中故障列表的部分示例,故与表2并非一一对应

按照第二章的步骤,故障发生器基于先前建立的故障列表自动注入故障。为了使故障产生最严重影响,这些故障在几个曲线点触发,以得到最严重的影响。由于我们仿真的主要目的是计算横向控制的FTTI值,因此被观测信号为横向误差和转向饱和。图3描绘了转向控制的FTTI的的计算原理。

图3:FTTI的计算原理

使用如下公式定义的最大横向误差作为系统失控的标准:

表2描述了基于FI的仿真结果得到的危害识别信息。通过通用故障模型对不同相关项层级的失效进行建模, 以测量其在整车层级的影响和导致的危害行为。

表2:整车层失效的影响

根据表2和仿真试验数据,可以分析得到危害分析和风险评估的部分结果,如表3所示,其中包括根据图2和图3计算得到的特定功能的最严重失效模式(表示为故障模型)的FTTI值。而故障持续时间即以一种适当的方式处理故障(过渡到安全状态)的时间。例如,与轨迹控制器相关的故障可以在危害事件发生之前在系统中存在400ms:其中240ms以检测和反应,160ms来控制故障,这样可做到不违反安全目标。表3中具体的安全目标定义如表4所示。

表3:危害分析和风险评估

表4:安全目标

3 功能安全概念

在上一流程所得安全目标的基础上,结合FI仿真结果推导得到功能安全要求,如表5所示。其中最大横向误差的计算公式如下所示:

表5:安全要求

至此,功能安全要求通过模拟数据而非传统的相关失效分析(Dependent Failure Analysis, DFA)得到。其主要结论是在当前的横向控制设计不能保证系统不受干扰,因此,需要重新设计其架构以确保该属性,即转向系统应是冗余的,以达到所需的可用水平。具体而言:基于表3的数据,为了防止危险的发生,必须将与转向功能相关的故障控制在196ms内。车辆如果翻转或旋转,乘客就可能受伤,因此,转向功能必须在70ms内可用。关于与行为规划相关的失效,例如由于DGPS故障导致失效,其反应时间为155ms,因此可能需要适当的功能降级。最后,必须正确划分不同的功能,以避免发生级联故障。

四、结论

以上介绍了一种基于模拟的故障注入方法,以评估自动车辆功能的安全性。并将该方法应用到嵌入自动横向控制功能的城市车辆案例中。本文将重点放在基于最大横向误差和转向饱和的永久性故障的FTTI值的确定上。本文所提方法的一个主要优点是它可以作为安全分析方法的补充,实现一个ISO 26262兼容的安全评估过程。

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 自动驾驶
    +关注

    关注

    773

    文章

    13000

    浏览量

    163137

原文标题:自动驾驶功能安全评估 | 基于仿真的故障注入

文章出处:【微信号:IV_Technology,微信公众号:智车科技】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    后驱动技术在故障注入中的退化机理的研究

    【作者】:李璠;曾晨晖;【来源】:《测控技术》2010年03期【摘要】:后驱动技术作为故障注入的有效方法,适用于数字电路在线故障注入,然而后驱动技术对器件产生的加速退化作用不容忽视。在分析
    发表于 04-22 11:29

    PXI故障注入开关模块应用于故障注入测试

    方法不是什么新颖的说法,它是ECU验证的一个重要的部分和系统电气故障的重要方法故障注入测试)。它是一个可以模仿很多情形,如因为腐蚀,短/开路和其他的由于使用时间过长引起的电气
    发表于 03-05 09:39

    【话题】特斯拉首起自动驾驶致命车祸,自动驾驶的冬天来了?

    `特斯拉首起自动驾驶致命车祸,自动驾驶的冬天来了?“一个致命的事故一定是由多个小的错误组成的。”  7月初,特斯拉发表博客叙述了NHTSA(美国国家公路交通安全管理局)正在着手调查第一起Tesla
    发表于 07-05 11:14

    自动驾驶真的会来吗?

    。autopilot是用户驾驶的一个辅助功能,可以帮助驾驶员在开车过程中进行更好的判断、更轻松的操作。这个Google等进行的自动驾驶有明显的不同。”张璐说。美国高速公路安全委员会(N
    发表于 07-21 09:00

    因为「不够安全」,我们就必须拒绝自动驾驶汽车上路?

    自动驾驶汽车,而不再把人类驾驶员当作后备支持。可以期待他们的车辆是足够安全的,至少在传感器故障的时候不会来个吓人的急刹车。但缺点是将这项技术做到完美,进而上市销售,尚需时日。Waym
    发表于 04-08 11:17

    自动驾驶的到来

      传统汽车厂商更趋向于通过技术的不断积累,场景的不断丰富,逐步从辅助驾驶过渡到半自动驾驶,进而在将来最终实现无人驾驶;某些高科技公司则希望通过各种外部传感器实时采集海量数据,处理器经过数据
    发表于 06-08 15:25

    如何让自动驾驶更加安全

    最近,国内多个城市开始发放自动驾驶的开放道路测试牌照,意味着自动驾驶的汽车可以在公共道路上进行测试。不过,驾驶安全性仍是社会关注的焦点,美国优步公司进行
    发表于 05-13 00:26

    联网安全接受度成自动驾驶的关键

    随着时代的演进与汽车工业技术、机器视觉系统、人工智能和传感器相关技术上不断创新与进步,无人自动驾驶汽车已不是一件遥不可及的梦想,Google与国际车厂相继针对自动驾驶技术致力研究开发,进一步让
    发表于 08-26 06:45

    如何保证自动驾驶安全

    自动驾驶技术为人们勾勒出了一副美好的未来出行的画面:坐上没有方向盘的汽车,一觉睡到公司门口;甚至我们可能不再拥有一辆汽车,需要出门时共享自动驾驶汽车会自己到来,送到目的地时会自行离开……不过自动驾驶
    发表于 10-22 07:45

    如何从安全的角度看自动驾驶

    安全的角度看自动驾驶
    发表于 01-25 06:42

    是否有推荐的方法或工具可用于在TPL接口上执行故障注入测试?

    是否有推荐的方法或工具可用于在 TPL 接口上执行故障注入测试?
    发表于 04-18 08:24

    分布式星载系统故障注入研究

    基于软件的故障注入是对星载计算机系统可靠性进行的一种评测技术。本文首先提出了用软件方法进行的故障注入系统,并提出故障注入模型;其次阐述了由本课题组自主研究开
    发表于 12-23 12:06 17次下载

    船舶一体化网络系统的故障注入平台设计

    船舶一体化网络系统的故障注入平台设计
    发表于 06-27 15:07 7次下载

    基于仿真的自动驾驶可靠性估计(二)

    前 言 SAIMO Preface 基于仿真的自动驾驶可靠性估计(一)中已经介绍 ,使用定步长泛化、朴素蒙特卡罗等方法生成验证自动驾驶系统的仿真
    的头像 发表于 10-25 19:10 272次阅读
    基于<b class='flag-5'>仿真的</b><b class='flag-5'>自动驾驶</b>可靠性估计(二)

    功能安全验证之软件故障注入方法

    软件故障注入是一种假设实验,它可能起源于软件开发过程的任何阶段,包括需求分析、设计和编码活动。在给定的工作负载下执行目标,并将故障插入目标系统的特定软件组件中。
    的头像 发表于 11-06 18:22 635次阅读
    功能<b class='flag-5'>安全</b>验证之软件<b class='flag-5'>故障注入</b><b class='flag-5'>方法</b>