汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制

这篇具有很好参考价值的文章主要介绍了汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

M&S可能很适合有效地评估ADS可能经历的各种潜在的失效模式,以及它可能失效的各种初始条件。

一些故障模式的常见根源,包括噪音和延迟,可以被建模用于虚拟测试。

故障注入和故障分析可以在虚拟环境中安全进行,但在封闭道路或开放道路测试中使用真实系统时,它们会带来危险。

此外,在ADS设计和开发过程中,M&S可以支持故障模式分析的早期和迭代,远在原型测试车辆或系统可用之前。

概述

本文描述了对ADS的FO和FS机制的评估方法。

当系统不能按预期运行时,ADS将使用FO和FS机制。

这些机制使ADS能够在最大程度上达到使车辆及其乘员脱离危险的MRC。

定义、测试和验证实现MRC的FO和FS策略是确保ADS安全运行和部署的重要步骤。

MRC

MRC在SAE J3016中被定义为:

用户或ADS在执行DDT接管后可使车辆达到的状态,以减少在特定行程不能或不应该完成时发生碰撞的风险。

DDT

SAE J3016进一步指出:

在L3级,考虑到ADS或车辆的DDT性能相关的系统故障,DDT准备接管的用户在确定有必要时,应达到最小风险的状态。

在L4级和L5级,ADS能够在必要时(即,由于ODD退出,如果适用,或ADS与DDT性能相关的系统故障)自动实现最小风险条件。在L4级和L5级自动实现最小风险条件的特点将根据系统故障的类型和程度、有关ADS功能的ODD(如果有)以及系统故障或ODD退出发生时的特定操作条件而变化。它可能需要自动将车辆停在其当前的行驶路线上,也可能需要一个更广泛的操作,旨在将车辆从一个有效的车道上移开和/或将车辆自动返回到调度设施。

样本测试框架包括故障模式行为,作为定义测试场景和程序的一个重要的高层维度。本任务所做的努力有助于确定故障模式行为如何在更大的测试架构中发挥作用,目的是评估ADS功能实现MRC的能力。

ODD

一个ODD描述了一个ADS功能在道路类型、速度范围、照明条件(白天和/或晚上)、天气条件和其他操作限制方面的具体操作域。即使一辆车有多个ADS功能,但每个ADS功能的ODD都可能不同。

汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制

内容

故障分析方法

如前所述,适当的故障缓解策略和由此产生的MRC主要取决于ADS系统出现的故障类型和性质。为此,对ADS潜在故障模式的理解是必要的。因此,进行了一次高层次的故障分析。这一分析的结果为评估FO和FS机制提供了依据。存在各种故障和危险分析技术,包括故障树分析、系统FMEA、FMECA、系统理论过程分析和HazOp。系统FMEA被确定并被选为开发高层次分析所需的初始方法,以确定每个子系统的潜在故障。代表性功能结构的每个子系统中的潜在故障,以及它们的原因和影响。

FMEA分析通常发生在系统设计阶段的早期,或者在整个设计、开发和测试阶段可能会反复进行。总的目标是试图在系统提供给客户之前识别和纠正或解决潜在的故障。FMEA通常可以分解为以下步骤:

1. 识别潜在的故障模式

2. 识别这些故障模式的潜在原因和影响

3. 根据风险对故障模式进行优先排序

4. 确定适当的纠正措施或缓解策略

在这个过程中,现有的关于ADS故障的报告和文献,包括来自美国国防部高级研究计划局的大挑战和城市挑战,以及工程判断和以前的ADS开发和测试经验都被利用和考虑。假设采用上述一系列技术的详细故障分析已经在基本车辆平台上进行,因此努力集中在与ADS具体相关的部件上。这使得对图1所示的ADS功能结构进行了更深入的研究。

汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制

图 1 ADS功能的通用功能结构

一个更详细的架构图,即SAE国际ORAD委员会的工作图,为高水平的FMEA提供了基础,如图2所示。此外,可能有安全影响的故障,而不是仅仅是不便的故障,被列为优先事项。

汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制

图2. 国际汽车工程师学会自动驾驶功能架构流程图

一个名义上的FMEA工作表被用来进行分析,其摘要见表1。该工作表的组成部分描述如下:

- 架构要素--来自ADS功能架构的系统/子系统(例如,传感器--雷达);

- 功能 - 元素服务的目的(例如,获取障碍物的范围数据);

- 失败模式 - 元素失败的可能方式(例如,硬件故障 - 失去动力);

- 潜在原因 - 发生故障的潜在原因(例如,电源线断开);

- 潜在影响 - 失败的潜在下游影响(例如,物体分割算法未能识别主导车辆,导致与主导车辆发生碰撞);

- 发生率(O)--对故障发生的可能性的衡量;

- 严重性(S)--如果故障确实发生,对影响的严重性的测量;

- 可探测性(D) - 衡量系统探测故障的能力;

- 风险优先级数(RPN) - 与故障相关的风险的总体衡量,由发生率(O)、严重性(S)和可检测性(D)组成:(𝑅𝑅𝑅𝑅𝑅𝑅 = 𝑂𝑂∙𝑆/𝐷𝐷);

- 过程控制 - 消除或减轻故障的方法或行动。

表1. ADS FMEA的名义工作表

架构元素

功能

失效模型

潜在的原因

潜在的影响

发生率

严重程度

可检测性

RPN

激光雷达

毫米波雷达

这个工作表包括对发生率、严重性和可检测性的定量衡量,以最终根据其重要性和风险对故障模式进行优先排序。对于这项分析,故障的类型和它们的影响比它们的整体风险更有意义;然而,为了完整起见,团队完成了这项工作。这三个指标以0-10的名义进行评估,数值越大说明故障发生的频率越高,严重程度越高,可检测性越高。每项指标的数值都是根据研究小组的讨论和洞察力来确定的。

由于这些行为在ADS的许多功能中是共同的,这就提供了故障模式和这些特征之间的类似映射。

上述FMEA程序中的最后一步是确定概念性的FO和FS机制,以减轻已确定的故障。当ADS由于重大故障而不能继续运行时,将采用FS机制。当这种类型的故障发生时,系统应该以一种可预测的、可控制的方式向MRC失效。FO机制是在发生故障时采用的,但ADS仍然能够运行,尽管可能会降低能力或仅在有限的时间内。确定并描述了ADS的各种潜在的FS和FO选项,以及每种选项的优势、劣势和潜在的限制。

其他几个与ADS故障缓解技术有关的项目和正在进行的活动也被确认。美国交通部的自动车道居中控制功能安全分析项目(欢迎关注公众号,后续会更新此报告)也包括故障模式的分析,SAE国际ORAD委员会目前正在讨论ADS的故障策略。

研究结果

失效模式和影响

FMEA按结构子系统进行分解,以确定ADS "管道 "中每个步骤的潜在关键故障:

- 感知和通信

- 感知融合

- 规划和控制

- 人机界面

感知和通信

与感知和通信有关的故障主要集中在与感知、本体感知和通信有关的硬件和软件。与外感有关的传感器获取车辆周围外部环境的数据。外部感知传感器的一些例子包括毫米波雷达、激光雷达、视觉感知和超声波感知。与本体感觉有关的传感器获取有关车辆内部状态的数据,最常见的是支持定位。本体感知传感器的一些例子包括GPS、惯性测量单元、陀螺仪、轮速传感器、罗盘、方向盘传感器和制动踏板传感器。通信设备,如DSRC、蜂窝技术(3G/4G/LTE/5G)、Wi-Fi和蓝牙,提供与其他道路使用者或与基础设施的无线单向或双向数据传输。通过通信获得的数据可以包括其他车辆或道路使用者的信息(个别道路使用者或更大的交通量和模式),以及相关事件、警告或基础设施变化/更新的信息(例如,交通事故、紧急车辆和临时施工区)。

与外感觉传感器相关的故障模式包括失去电源、失去数据连接、内部硬件故障和发射器/接收器污损(如泥土、灰尘)。与本体感觉传感器相关的故障模式同样包括失去电源、失去数据连接、内部硬件故障和校准不良。与通信设备相关的故障模式同样包括失去电源、失去数据连接、内部硬件故障和失去外部信号。此外,许多这些传感器需要软件驱动,将来自每个传感器的原始数据处理成更适合ADS的数据。这些软件驱动器可能会出现故障,或者不能以期望的速度产生数据,尽管这同样可能是由内部故障或设备本身的故障造成的。

外感觉传感器故障的下游影响可能导致ADS无法检测和跟踪相关的障碍物(例如,无法对另一车辆进行分割或分类),或者ADS不准确地描述相关障碍物(例如,错误地估计物体的位置或形状)。本体感觉传感器故障的影响可能导致ADS不能准确估计其内部状态(例如,相对和/或绝对位置、方向、速度)。通信设备故障的影响可能导致ADS不能解释或执行 相关的警告或更新(例如,未能检测到车道关闭并作出反应)。这些故障最终会导致ADS不能准确地感知和体现周围的环境。

感知融合

与感知融合有关的故障主要集中在与传感器处理、定位和真实世界建模有关的软件算法上。传感器处理涉及支持感知领域分割(近场/中场/远场)、道路/地形分割和分类以及物体分割和分类的算法。定位涉及绝对和相对状态估计的算法。世界建模涉及将数字地图和其他静态和动态障碍物地图的信息汇总到一个共同的坐标框架中的算法,以及纳入已知的交通规则和其他虚拟信息(如地理围栏)。

与传感器处理有关的故障模式包括未能对传感器所设计的信息进行建模或检测,或提供次优结果。与定位相关的失效模式包括未能估计ADS的状态,或者更有可能提供不准确的估计。与世界建模相关的失败模式包括未能适当地将不同的数据组合和注册成一个有凝聚力的模型或地图,或者更有可能提供一个次优的模型或地图。这些感知任务的故障模式还包括典型的软件故障,如内存损坏、控制流错误或计算错误。同样,这些算法将在计算硬件上运行,而计算硬件可能会出现一系列的故障,包括内部硬件故障、电源损失或数据连接损失。

与传感器处理有关的故障的下游影响可能导致ADS忽略未检测到的物体或道路特征,或对其进行误解。与定位有关的故障的影响包括ADS失去对其位置和/或方向的跟踪,无法安全导航。与世界建模相关的故障导致系统错误地描述了ADS所处的环境。这也可能包括ADS不能识别它正在跨越ODD或OEDR的操作边界。一般来说,这些故障可能导致ADS做出次优或不安全的规划决定。

规划和控制

与规划有关的故障主要集中在与任务规划、机动/轨迹规划以及转向和速度控制有关的软件算法。任务规划涉及的算法是为ADS从其初始位置到期望的目的地推导出一条高级路线,可能包括要遵循的道路和要采取的转弯,并可能考虑到旅行时间或距离。机动和轨迹规划涉及到反复确定适当和安全的运动的算法,使ADS能够沿着其高层次路线取得进展。这包括确定第二章中确定的适当的战术机动行为,如车道跟踪、车道切换、合并、通过十字路口和执行掉头,以及车辆执行这些行为的最佳路径和遵循规定路径的适当和安全速度。转向控制涉及将这些路径的初始、近场段转换为转向执行器的控制输入的算法。速度控制涉及到将沿着所需轨迹的目标速度转换成对ADS油门和刹车执行器的控制输入的算法。

与任务规划相关的故障模式包括算法故障,其中高层路线没有生成(例如,数字地图中缺少连接),或者生成了低效或次优的路线(例如,路线不是最短的距离或持续时间)。与策略规划相关的故障包括算法故障,其中未规划必要的机动(例如,未识别转弯)或规划了不正确或不适当的机动(例如,在即将转弯之前规划了不正确的变道)。与轨迹规划相关的故障包括算法故障,其中没有发现可行的轨迹来实施机动(例如,没有生成执行变道的路径,即使存在可行的路径,车辆继续在当前车道上行驶),或者生成的轨迹不正确或不理想。与转向和速度控制有关的故障包括算法故障,其中控制输入没有产生,或者与计划轨迹有关的控制输入不正确或不理想。

与任务规划相关的故障的影响可能包括ADS无法到达其期望的目的地或遵循一条低效的路线到达目的地。与机动计划有关的失败的影响包括ADS被卡住或需要重新计算其任务路线,或可能执行不安全的机动。与轨迹规划有关的故障的影响包括ADS被卡住,或可能遵循不安全的路径。与转向或速度控制有关的故障的影响包括ADS不能准确地遵循其计划的路径,或不能安全和稳定地保持目标速度。当车辆在复杂的环境中围绕许多动态障碍物进行规划时,这些低级别的规划故障可能会产生可怕的后果,最终导致碰撞。

人机界面

与车辆界面有关的故障集中在与视觉显示或声音或触觉警告有关的硬件和软件故障,人机界面状态是操作员顺利接管的必要条件。人机界面对于有人的ADS至关重要,在这种情况下,乘员可能需要在发生重大故障时执行备用用户的功能。人机界面提供了关于环境状态的信息,以及系统的内部状态和其按计划运行的能力。如果没有提供这些信息,或者提供的信息不正确,操作者在必要时可能无法重新控制车辆,或者可能缺乏重要的信息或背景以促进安全的接管。

与人机界面相关的故障模式包括内部硬件故障,如显示屏、扬声器或触觉机制不能按预期运行(例如,显示屏失效,方向盘不能振动)。它们还包括与为操作者提供相关数据或警告有关的软件故障。数据或警告的软件故障(例如,误报自动化状态,没有发出即将发生的碰撞的声音警告)。

这些故障的下游影响包括操作员在被要求时重新控制车辆的延迟,或者操作员没有被告知有必要接管。

或者,操作者可以成功地重新控制,但可能根据提供的错误数据或缺乏数据而做出错误的决定。这些类型的故障可能在L4系统中得到缓解,因为ADS实现了MRC;然而,对于L3系统,这些类型的故障可能与安全有关。

总结

一般来说,上面描述的许多ADS故障模式都可以归结为信息故障。这些故障被总结为三个主要类别,即归因于以下原因的故障:

- 没有数据--信息完全没有;

- 质量不高的数据--信息的质量很差或退化了;

- 潜在的数据--信息是延迟的或旧的;

对于这三类中的每一类,故障的时间性也是解决的关键因素。信息故障可以是瞬时的/间歇性的或持续性的。间歇性或瞬时性的数据故障可能会被过滤或功能架构中许多元素的递归性质所缓解。它们也可能更难检测。持续的数据故障可能更严重,但也可能相对快速地表现出来,并且更容易检测。许多ADS架构将通过融合和过滤来自多个来源的数据(例如,融合来自一套感知传感器的数据,过滤来自多个相对和绝对定位传感器的数据,扩展卡尔曼过滤器)来提供对其中一些故障的稳健性。在出现持续错误或故障的情况下,这种鲁棒性可能仍然具有有限的功能时间范围(例如,状态估计的漂移积累)。

故障在ADS架构中的进展或传播也是一个挑战。在管道早期发生的小错误或故障(例如,传感故障)可能最终发展成为管道末端的更重要的错误或故障(例如,感知系统没有识别相邻车辆,导致规划子系统产生导致碰撞的轨迹)。同样,在不同的子系统中同时出现的小错误有可能导致意外的或不希望出现的行为。在管道的每一步为输出数据提供信心或其他质量措施,可以支持早期识别故障或失效,并允许缓解。

这些故障的影响被总结为四个主要类别,尽管每个类别都可能建立在其他类别之上:

- 不理想的性能(例如,拥抱车道的一侧,驾驶速度比允许的慢,采取低效的路线或轨迹)。

- 意外的/不可预测的行为(例如,突然加速/减速,不稳定的转向震荡)

- 不安全的行为(例如,驶出所需的车道,对相关的障碍物没有反应)。

- 碰撞

导致次优性能的故障可能大多是良性的,更多的是不便,而不是安全问题,尽管识别和量化它们可能仍然是有益的。导致意外或不安全行为或碰撞的故障肯定是一个安全问题,在制定故障应对策略时需要仔细考虑。

在ADS功能结构的每个阶段都有可能出现各种各样的故障模式。再加上故障的广泛组合和传播空间,对安全部署ADS提出了重大挑战。单一故障或故障序列的性质和程度在确定适当的故障响应方面起着关键作用。

ADS行为映射

在完成ADS结构的FMEA后,总结了各种故障模式和影响,并将其映射到三个下采样ADS功能(L3交通拥堵自动驾驶、L3高速公路自动驾驶和L4高度自动化车辆/TNC)的相关操纵机动和OEDR行为中。这在概念上提供了一个从FMEA中确定的具体故障,到上面总结的一般故障,再到各种ADS功能实施的行为的映射。

例如,如果被测试的ADS不能安全和持续地保持其指定的车道,测试团队可以按照详细的映射来确定可能的根本原因(例如,由于负责检测和跟踪车道标记的相机间歇性断电而导致相对定位解决方案不稳定)。

表 2. L3交通拥堵自动驾驶故障模式/影响总结

失效行为

影响

未能保持车道

影响邻近车辆或基础设施

未能保持安全的跟车距离

冲击主导车辆

未能发现并应对其他车辆的机动动作

冲击领先车辆或邻近车辆

未能检测到车道内或附近的相关障碍物

撞击障碍物

未能识别ODD/OEDR边界

在ODD/OEDR能力范围之外运行

表3. L3高速公路自动驾驶故障模式/影响总结

失效行为

影响

未能保持车道

影响邻近车辆或基础设施

未能保持安全的跟踪距离

撞击领头车辆

未能保持适当/安全的速度

超过速度限制,失去稳定性,影响主导车辆

未能发现并应对其他车辆的机动动作

撞击主导车辆或相邻车辆

未能检测到车道内或附近的相关障碍物

撞击障碍物

未能识别ODD/OEDR边界

在ODD/OEDR能力范围之外运行

表4. L4高度自动化车辆/TNC故障模式/影响总结

失效行为

影响

未能保持车道

影响邻近车辆或基础设施

未能保持安全的跟踪距离

撞击领头车辆

未能保持适当/安全的速度

超过速度限制,失去稳定性,影响主导车辆

未能适当/安全地进行机动操作(例如,改变车道、交叉路口变化、交叉路口)。

撞击车辆或基础设施

未能发现并应对其他车辆的机动动作

冲击主导车辆或相邻车辆

未能探测到车道内或附近的相关障碍物

撞击障碍物

未能遵守交通规则和礼节

撞击车辆

未能识别和应对非标准危险(如工作区、紧急车辆)。

不安全地航行,撞击障碍物

未能识别ODD/OEDR边界

在ODD/OEDR能力范围外操作

失效缓解策略

基于确定的一般故障模式,潜在的故障模式反应和策略被确定下来。这项工作的重点是针对ADS因重大故障而无法继续运行的情况的FS策略,以及针对ADS即使面临故障也能继续运行的FO策略。

故障安全机制

故障安全策略的主要目标是迅速实现车辆和乘员安全的MRC。三个候选的安全机制被考虑用于进一步评估:

- 过渡到故障就绪的用户控制

- 安全地停在行车道上

- 安全地移出行车道并停止

对于L3系统来说,请求准备接管用户的干预可能是主要的FS策略。这假定操作者在现场并注意到人机界面。此外,还有一个假设,即ADS通过人机界面提供的信息适合重新吸引操作员。这种策略的一个挑战是在需要干预之前向操作员提供足够的警告。之前的研究表明,在L2和L3系统中,这种警告的时间可能很重要,取决于事件的性质和提供的警报。此外,ADS功能需要继续运作,直到该过渡发生。如果用户没有做好接管准备(例如,睡着了,没有注意到干预请求),就会产生额外的问题和挑战。这种干预请求也可能是L4系统的一个可行的FS策略,同样假设有一个可以接管的用户在场,并且必要的信息是可用的;然而,L4系统可以在操作者不可用或未能采取行动的情况下实现MRC。

在当前行车道上停车的策略是技术和政策界争论的一个方法。在这种情况下,ADS可以迅速但安全地减速到停止,同时保持其当前车道。所需的行动和时间是最小的;然而,对于这对车辆、乘员和其他道路使用者来说是否是一种安全状态,存在很大的分歧。在回答这个问题时,ODD和驾驶条件发挥了作用。例如,在低速的城市道路上,在能见度良好的主动车道上停车可能是一种相对安全的状态,而在高速的农村公路上,在盲道后的主动车道上停车可能不符合安全状态的意图。故障的频率、性质和程度也是回答这个问题的关键。例如,如果ADS的一个或多个主要传感器发生故障,无法探测到邻近的障碍物,在行驶的车道上停车可能比试图从行驶车道上机动停车更安全。如果可以呼唤远程操作员来协助将车辆操纵到安全状态,远程车队管理整合可以进一步支持这一策略。

最后,ADS安全地离开活动道路并停车/泊车提出了一个有吸引力的金融服务机制。故障的频率、性质和程度,以及最初的驾驶条件,在决定这是否是一个可行的策略方面再次起作用。例如,如果车辆在一条大型高速公路的中间车道上,可能需要在相当长的时间内进行一系列复杂的操作,以便在邻近的交通周围转移一个或多个车道,从而能够并入路肩或安全区域,实现MRC。如果它的一个或多个主要传感器发生故障,或者没有路肩或安全港湾,那么这种策略可能是不切实际的。

故障运行机制

故障运行策略允许ADS继续运行,即使在发生一个或多个故障的情况下。重要的是要注意,这种操作可能只支持有限的时间,或者有可能减少一套能力。为进一步分析,我们考虑了三种主要的FO机制。

- 硬件/软件冗余

- 自适应补偿

- 降级的操作

o 最高速度降低

o 自动化程度降低

o 减少了ODD

o 机动能力降低

o 降低OEDR能力

集成冗余的硬件或软件,这更像是一种设计策略,为关键的设备或逻辑过程提供备份。例如,在ADS上可以安装多个相同的ECU,运行一个转向控制应用程序。在主ECU出现硬件故障的情况下,一个逻辑机制可以触发系统开始对副ECU的输出作出反应。这种策略可以从操作的角度提高可靠性和稳健性,从而使ADS继续运作。

然而,这种策略增加了成本、复杂性和ADS功能的潜在 "足迹"(例如,需要额外的电源和电缆,占用额外的空间)。

自适应补偿允许ADS子系统对一个或多个部件的故障进行补偿,如果有的话,可以更多地依靠其他互补的部件或过程。例如,如果一个GPS接收器遭遇硬件故障并提供噪音或间歇性数据,状态估计系统有可能减少GPS数据的权重并增加其他可用传感器(如IMU、轮速传感器)的权重,以继续提供一个强大的、经过过滤的解决方案。这种策略对于已经融合了多个来源的数据的子系统(如感知和定位)来说可能特别有效,尽管对其他子系统来说可能不是这样。这种补偿技术也可能只在有限的时间内有效(例如,如果没有获得GPS或其他绝对数据,状态估计器的漂移可能导致车辆随着时间的推移失去其绝对位置的追踪)。随着开发商寻求将其ADS上的组件最小化以推向市场,这种策略可能会变得不太实用。

最后,存在各种退化的操作模式,可以使ADS在发生故障后继续运作。降速运行是缓解与资源受限(如网络带宽、处理能力、处理延迟/滞后)有关的故障或失效的一个有用工具。这种策略为ADS提供了额外的时间来评估一个场景并做出规划决定;然而,在一些驾驶场景中(如高速公路、HOV车道),它可能是不切实际或不安全的。在一个较低的自动化水平下操作是另一种选择,尽管它可能会转移DDT或接管性能的一个或多个方面的责任(例如,从L4减少到L3意味着有一个可接管的用户)。这一策略可能包括强调驾驶员状态的监控,如果适用的话,以确保操作者专心致志。因此,对于没有确定驾驶员的ADS功能(如L4或L5高度自动化车辆/TNC功能、自动送货车辆)来说,它可能不切实际。在减少ODD的情况下操作,进一步限制了ADS可以发挥作用的条件和领域(例如,只在白天,只在低速)。

总结

这项任务考虑并分析了通用ADS的潜在故障模式,以及可能的故障缓解策略。进行了高水平的系统FMEA,以确定故障模式及其对ADS功能结构中主要子系统的影响。

故障主要与物理和逻辑故障和错误造成的信息故障有关。失效模式根据其影响的严重程度进行归纳,并分别与第2章和第4章中确定的战术机动行为和OEDR行为以及向下选择的ADS功能相匹配。

潜在的机制被确定和评估,这些机制允许ADS在发生关键故障时安全失效,使车辆不能继续发挥设计功能,或者在发生故障时操作失效,使车辆能够继续发挥功能。FS策略通常试图尽可能有效地实现MRC,而FO策略通常试图继续执行DDT的主要内容,尽管可能是在有限的时间内或以减少的一套能力。已确定的FS和FO策略各有优缺点。这些机制的分级可能是必要的,因为适当的故障缓解策略将在很大程度上取决于故障的性质和程度,以及故障发生时的初始条件。

重新审视了测试方案框架和测试架构,将失效响应的评估纳入拟议的架构中。失效模式行为适合作为测试方案框架的第四个层面(如图3所示)。

汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制

图 3 ADS测试方案矩阵

M&S可能很适合有效地评估ADS可能经历的各种潜在的失效模式,以及它可能失效的各种初始条件。一些故障模式的常见根源,包括噪音和延迟,可以被建模用于虚拟测试。故障注入和故障分析可以在虚拟环境中安全进行,但在封闭道路或开放道路测试中使用真实系统时,它们会带来危险。此外,在ADS设计和开发过程中,M&S可以支持故障模式分析的早期和迭代,远在原型测试车辆或系统可用之前。文章来源地址https://www.toymoban.com/news/detail-431434.html

到了这里,关于汽车电子功能安全FuSa之二:L3级以上故障运行及安全机制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【汽车电子】5分钟了解汽车操作系统(科普篇)

    在智能汽车+电动汽车的浪潮下,「软件定义汽车」的理念已经成为很多厂家的共识,未来决定汽车个性化差异的不再是马力大小、座椅材质、底盘软硬等,而应该是人工智能、大数据和云计算技术的综合体。 要想实现这一切,就要给汽车安装一个或者多个操作系统。 操作系

    2024年02月01日
    浏览(54)
  • 汽车电子行业入门指南「当下汽车工业的挑战」

    自动驾驶技术是汽车行业目前的热门话题之一,它的发展前景非常广阔,但是也面临着一些挑战和问题。目前,自动驾驶技术已经在一些高端车型上得到了应用,但是在大规模商业化应用方面还存在不少困难。目前自动驾驶技术通常分为以下6个级别: L0级别 :无自动化,驾

    2023年04月09日
    浏览(58)
  • 一文详解汽车电子LIN总线

    汽车电子LIN总线不同于CAN总线。 LIN总线基本上是CAN总线的廉价补充,相比于CAN总线,它提供较低的可靠性和性能。同时LIN总线也是一个应用非常广泛的网络协议,并且越来越受欢迎。 再一次,我们准备了一个关于LIN总线的简要介绍。以下涉及多个方面的主题与研究内容。本

    2024年02月08日
    浏览(45)
  • 汽车电子Autosar之DTC

    目录 一、DTC基本介绍 1、DTC基本组成 2、DTC故障类型 3、DTC与event区别与联系

    2024年02月08日
    浏览(45)
  • 一文详解汽车电子CAN总线

    CAN总线(控制器区域网络Controller Area Network)是一个中央网络系统,连接不同的电子控制单元(ECU)以及车辆中的其他设备。现在的汽车可以有100个ECU,因此CAN总线通信变得非常重要。 集中式 :CAN总线系统允许对连接到网络的ECU进行集中控制,使控制ECU变得容易。 鲁棒性 :CAN总线协

    2024年02月08日
    浏览(41)
  • 关于汽车电子NVM的笔记

    NVM是英文“Non-Volatile Memory”的缩写,中文翻译为“非易失性存储器”。它是指一种能够在断电情况下依旧保留数据的存储器件。NVM用于存储一些不需要频繁更改的数据,例如汽车电子控制单元(ECU)中的程序代码、校准数据、配置参数以及历史故障码等。 传统的可擦写可编

    2024年02月08日
    浏览(43)
  • AUTOSAR汽车电子系统架构标准

    目录 AUTOSAR RTE SWC和BSW SWC访问代码实现 ARXML(AUTOSAR XML) Interface Client-Server接口代码实现 AutoSAR OS Application AUTOSAR(Automotive Open System Architecture)正式发布日期是2003年,是一种开放的汽车电子系统架构标准,旨在提供汽车电子系统的 标准化和模块化 解决方案。它由一系列的 规

    2024年02月11日
    浏览(48)
  • 汽车电子AUTOSAR之EcuM模块

    目录 前言 正文 EcuM模块总体介绍 主要功能 总状态机(Flexible 与 Fixed)

    2024年02月08日
    浏览(42)
  • 【电子取证篇】汽车取证检验标准

    汽车取证鉴定可能涉及的测试/测量方法—【蘇小沐】 GA/T 976-2012《电子数据法庭科学鉴定通用方法》; GA/T 1998-2022《汽车车载电子数据提取技术规范》; GA/T 1999.2-2022《道路交通事故车辆速度鉴定方法 第2部分:基于汽车事件数据记录系统》; GB 39732-2020《汽车事件数据记录系

    2024年02月10日
    浏览(42)
  • 汽车电子中的TC8测试

    Tech Committee,简称TC。 其中TC8定义了测试流程并支持建立能够执行ECU测试的测试机构,并建立对测试规范和合作伙伴要求的定期审核,以提高汽车系统中以太网ECU和网络的通信质量。 一:主要以TCPIP协议栈的链路层以上为主,包括ARP、ICMPv4、IPv4、UDP、TCP、DHCP、SOMEIP等协议的测

    2023年04月18日
    浏览(34)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包