• 发文
  • 评论
  • 微博
  • 空间
  • 微信

ISO26262 Functional Safety Concept(叁)

Elektroauto 2020-07-22 08:33 发文


嗨,大家好!本期还是继续上一期的话题,接着聊聊功能安全概念阶段相关的话题。本期主要聊一聊功能安全要求,并举例说明一些功能安全机制。

01


什么是安全机制?
1. 安全机制是检测/避免/控制失效或者减轻其有害影响的技术解决方案;
2. 安全机制是由E/E功能、元件或其他技术实现的;3. 安全机制是能够将相关项维持在安全状态或者提醒驾驶员去控制失效的影响。
下面的例子展示了如何使用E/E功能(Sense, Logic, Actuate)来实现安全机制:
Figure1-Safety Mechanism for Vehicle Headlamp

如果车辆的前大灯在夜间失效了,那么驾驶员是可以注意到的。但是,如果前大灯在白天错误地打开了,驾驶员是不会注意到的,因此,红色的警告灯将会亮起,来警示驾驶员限制在HARA分析中进行的危害暴露(E)的暴露时间。通过在功能级别上实施的安全机制,我们可以节省电池的消耗。

另外,如果前大灯的故障模式错误地关闭了而我们又想在夜间警告驾驶员,那我们就把逻辑改成 NAND,因此,红色警告灯将在任何故障(前大灯、开关、线束、蓄电池等)时被激活。也即,逻辑和控制器是根据驾驶时间来调整的。现在,是时候来重新审视一下我们的功能安全要求了。


02


功能安全要求回顾

在我们评论可能的功能安全策略之前,我们首先要明确下两个术语:

Fail- Safe ->故障安全;

Fail- Operational -> 故障可操作性;

第一种方式是说,如果故障发生了,那我们必须禁用该功能或者对功能进行降级(部分功能的连续操作)以减轻危害。

而故障操作,是通过冗余支持功能来保持功能的可用性。也就是说,故障安全和故障可操作性都是某种安全的状态。

Fail-Safe -> Degraded Mode -> Fail-Operational;

如果适用的话,功能安全要求应该规定9点策略:

1. 故障避免 ->Fault avoidance

这是一个面向过程的概念,目的是防止故障被引入系统。通过小心仔细的设计和制造系统,故障可以被避免。

2. 故障检测 -> Fault detection

故障发生时检测故障的机制。
3. 过渡到安全状态,并且如果适用的话,从安全状态过渡 -> Transition to a safe state, and if applicable, from a safe state我们必须明确一个安全状态的入口点以及如何从该安全状态退出。相同的相关项定义可以有多个安全状态。4. 故障容错 -> Fault tolerance这是一个面向产品的概念,它以有限的能力承受故障,并且掩盖其表现形式。为了使系统具有容错性,无论系统的哪个部分发生了失效,都能够使系统继续运行。5. 驾驶员警告,目的是将危害暴露(E)时间缩短到可接受的范围内 -> driver warning to reduce risk exposure (E) time to an acceptable duration举例:如果气囊传感器出现故障,安全气囊控制器应该向仪表板发出警告信息。(注意,这里我们没有指定要发送警告的故障类型,因为这是在功能的级别;我们可以在FSC中列出潜在的故障,这样我们可以在后续的TSC中来跟踪。)这样一来,风险暴露的时间就大大的降低了,因为驾驶员有时间开车去修理店维修。6. 驾驶员警告,目的是增加驾驶员对车辆的控制性 -> Driver warning to increase controllability by the driver如果驾驶员得到及时反馈当相关项失效发生时,那么由于驾驶员对某一故障的及时响应,参数 C 的额定值就会降低。比如:AEB 故障应发送到仪表显示。当驾驶员看到此故障时,他就不会再依赖于AEB,如果车辆前方有障碍物,他就会踩下制动踏板,因此警告信息增强了驾驶员对车辆的控制性。7. 故障时的功能降级,以及它和 5、6点的相互作用 ->The degradation of the functionality in the presence of a fault and its interaction with 5 or 6我们需要描述发生故障时的降级功能。举例:将车辆维持在跛行模式,知道点火开关由ON 切换到OFF。8. 定义故障处理时间以满足故障容错时间间隔 -> Define the FHDI to meet the FTTI

每个安全目标都有一个对应的FTTI,因此在车辆级别上应该遵循该间隔将最大的处理时间约束定义为小于FTTI。

所描绘的时间线说明了在FTTI结束之前必须进入到安全状态,为什么呢?

因为过了这段时间,危害就会产生,从而导致安全目标的违背。

如果FTTI时间是2秒,并且我们在第2.5秒进入到安全状态,那就已经违反了安全目标了。

9. 避免/减轻由于不同功能同时生成的多个控制请求的不当仲裁而导致的危害事件 -> Avoidance/mitigation of a hazardous event due to improper arbitration of multiple control request generated simultaneously by different functions

在SbW系统架构中,我们注意到线控转向控制器接受来自多个发送方的转向请求,并且从中仲裁执行命令。如下面图所示。

制动系统快(ESC, ABS);

车道保持辅助(LKA)功能块;

驾驶员;

如果来自多个发送方的多个请求,那个发送方将是主导的转向功能?我猜测是LKA模块,我的猜测是正确的吗?

因此,为了避免任何不当的仲裁,我们应该实施安全机制。比如:当ADAS要求安全监控时,我们应确保安全。此外,它可以保证来自不同来源的驱动电流模式来检查LKA转向请求的合理性。什么是合理性(Plausibility)?这个是下期的讨论话题,本期不过多阐述。

根据以上的9种功能安全策略,我们应该在功能级别上为每一个策略生成FSR。此外,每个功能安全要求应通过考虑以下五个限制条件来规定,如果适用的话:

1. 操作模式->operational modes:

ADAS/Driver-train/Standby, etc。

2. 故障容错时间间隔->FTTI:

将FTTI附加到FSR。

3. 安全状态->safe state:

如果故障发生,将适当的安全状态附加到特定的功能安全要求中。比如:转向辅助系统应在低速时可用,高速时禁用。比如:应禁用所有的转向辅助。

4. 紧急操作时间间隔->EOTI:

规定EOTI,即不能达到安全状态时,应执行紧急的操作。如果安全状态是禁用功能,则紧急情况可以停止车辆或者禁止其他主要功能以减轻危害。

5. 功能冗余->functional redundancies:

如果主功能失效,我们还有冗余的功能可用。

我们可以在以上9种策略的基础上增加一个策略,来确保系统要素始终正确运转。那么,FSC最后应该是什么样子呢?


03


功能安全概念-FSC


FSC应该包含:

初始的系统架构,相关项定义;

安全目标;

安全策略;

Use Case:

SG01: The EPS system shall prevent unintended self-steering in any direction under all vehicle operation conditions (ASIL-D)

非预期的自动转向是指驾驶员未启动的任何转向,或者其他系统(假定运行正常)由于失效而导致的:1-意外启动转向;2-电动转向卡滞在非零扭矩输出上;3-转向错误;请注意,这里我们设定了安全目标并且以适当的方式进行了描述,之后我们将添加功能安全策略,这些策略会在需求中进行描述。那制定策略的功能安全要求应该是什么样的呢?model: < one of the 9 strategies> + < one of the 5 constrains, if applicable>example: <detection strategy> + <FTTI + safe state><The EPS system shall perform Power On self-test and periodic tests to ensure the safety related signals are correct>+< and if there is a fault, the system shall go to safe state #2(All steering-assist shall be disabled within 2 secs)FSR1:The EPS system shall perform Power On self-test and periodic tests to ensure the safety related signals are correct and if there is a fault, the system shall go to safe state #1 within 2 secs.Safe State 1: All steering-assist shall be disabledFTTI : 2 secs功能安全概念可以通过使用FMEA或者FTA对初步的系统架构进行安全分析来支持。也就是说,我们将确定功能级别的潜在危害,然后提出安全策略来防止或者减轻危害。尽管如此,很多的功能安全要求并不是直接来自于安全目标,而是源于减轻FMEA/FTA危害输出的策略(即做FMEA和FTA分析时的一些为避免单点和潜伏失效而增加的机制)。

因此,安全概念是用于(SG 和Concept FMEA/FTA)的策略,然后我们写下元需求,以便可以在功能接构建这些策略。注意,也应涵盖基于FMEA和FTA分析而得出的功能安全策略。这些将是通用的功能安全要求,而不是针对某个安全目标的。

除此之外,功能安全要求应该在逻辑层面。也就是说,可以分配到不同的HW体系架构,而不需要详细的技术细节,也即,我们所写出的FSC对于供应商X Y Z而言都是有效的。


免责声明:本文章中内容是由小编翻译自外文资料,免费分享知识,只限于参考学习,请勿作其他用途



声明:本文为OFweek维科号作者发布,不代表OFweek维科号立场。如有侵权或其他问题,请及时联系我们举报。
2
评论

评论

    相关阅读

    暂无数据

    Elektroauto

    本维科号定期更新新能源电动汽车设...

    举报文章问题

    ×
    • 营销广告
    • 重复、旧闻
    • 格式问题
    • 低俗
    • 标题夸张
    • 与事实不符
    • 疑似抄袭
    • 我有话要说
    确定 取消

    举报评论问题

    ×
    • 淫秽色情
    • 营销广告
    • 恶意攻击谩骂
    • 我要吐槽
    确定 取消

    用户登录×

    请输入用户名/手机/邮箱

    请输入密码