功能安全~航空737案例闲聊

本文通过737MAX案例探讨功能安全与可靠性问题。强调了安全等级与可靠性的关联,指出功能安全关注失效模式的覆盖,而可靠性涉及硬件失效率。文章列举了飞行控制系统中的功能安全措施,如双重传感器、软件监测、独立监控系统和自动化回滚等,强调了持续监测和改进的重要性,以确保航空安全。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

那就举一个航空的例子737MAX机头不受驾驶员控制一直向下 是可靠性的问题 还是设计充分性的问题?

可靠性和安全等级应该是两个维度,举个例子:一个系统每天都出现一次故障,并且会影响人身安全,那可靠性一定很低。根据功能安全的定义,ASIL可能会很高,于是功能安全需求定义了足够多的安全机制去覆盖系统的故障,并且发生故障也能切到安全状态。功能安全并不关注硬件的基础失效率,而是对失效模式的覆盖度(可能有失偏颇)

安全等级的确定是从场景出发的 但同时也关联了可靠性,安全等级越高,可靠性的要求就越高,比如高等级的要求硬件失效率到5个9,航空要求6个9。要达到高可靠,是一个系统工程。因为硬件有“0缺陷”的物理模型存在,所以硬件的失效概率是可以衡量的,有一个明确的数值。但软件不一样,软件的失效是系统失效,不是随机事件。所以才需要不同严格程度的工程方法去避免失效,本质上也还是提高可靠性。

根据不同的安全目标,有两个典型的功能安全开发要求

  1. 出现故障以后功能退出,fail silent→比如ESC稳定性功能非预期激活
  2. 出现故障以后功能依旧可以使用,fail active→比如助力产品制动力丢失

对于前者,单单从功能安全的角度可以只关注故障的诊断覆盖度,哪怕诊断会因为鲁棒性差错误降级关闭(导致功能可靠性差)。
但是对于后

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

凯文的汽车之旅

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值