本篇属于汽车功能安全专题系列第03篇内容,我们接着聊功能安全概念开发阶段剩余内容。
ISO 26262 基于V模型,汽车功能安全开发活动始于概念阶段,该阶段主要包含以下内容:
-
相关项定义(Item Definition),即定义研究对象
-
危害分析和风险评估(HARA),即导出安全目标及ASIL等级
-
功能安全方案开发(FSC),即形成系统化概念阶段工作方案输出
在上一篇文章”02 – 汽车功能安全系列之概念阶段开发 – Item Definition & HARA”(我是链接)中,我们聊到了前两部分内容,定义了功能安全研究的对象,即相关项,通过HARA过程,对相关项的功能进行系统级别安全分析,导出了危害事件并量化其风险(ASIL),最终得到功能安全目标(SG)及其ASIL等级,作为整个功能安全研究最初的安全需求。
今天主要聊聊功能安全概念阶段第三个部分内容(强烈建议先看前面几篇文章),具体包括:
-
什么是功能安全需求(FSR)
-
什么是功能安全方案(FSC)
-
怎么从安全目标(SG)得到功能安全需求(FSR)
-
FSR分配至系统架构
01
什么是FSR
功能安全需求(Functional Safety Requirements, FSR)是我们在概念阶段最常听到的概念之一,那什么是FSR呢?
功能安全目标(SG)属于基于车辆或系统级别的安全需求,过于抽象,我们需要将其进行细化,得到为满足安全目标,基于组件级别的相对比较具体的,但依旧还是基于功能层面的逻辑功能需求,这个就是FSR。
大家可能好奇,为什么非要搞得这么麻烦,直接细化到技术层面,信号层面不好吗?
是的,不好!一方面,研究分析工作需要循序渐进,一口吃不成大胖子,对于简单或者非常熟悉的研究对象,在大牛加持下可能可以直接从安全目标导出技术层面的安全需求,但对于大部分系统或者大部分工程师而言,这个很难做到,很容易出现错误或缺失。另外一方面,没有中间工作产物,功能安全评审也过不了。
那么我们应该从哪些方面去定义组件层面的功能安全需求或者功能安全需求应该解决哪些问题呢?根据ISO 26262-3-2018,功能安全需求应该针对以下几个方面,提出相应功能级别的解决方案,作为FSR:
-
故障预防
-
故障探测,控制故障或功能异常
-
过渡到安全状态
-
容错机制
-
发生错误时功能的降级及与驾驶员预警的相互配合
-
将风险暴露时间减少到可接受的持续时间所必需的驾驶员预警
-
驾驶员预警,以增加驾驶员对车辆的可控性
-
车辆级别时间相关要求,即故障容错时间间隔,故障处理时间间隔,和
-
仲裁逻辑,从不同功能同时生成的多种请求中选择最合适的控制请求。
如何理解呢?通俗的讲,FSR无非就是基于以下两个角度定义安全需求:
-
事前预防: 从设计的角度出发,为尽可能避免系统中软件和硬件相关的失效,系统中的组件应该实现或具备哪些功能。
-
事后补救: 如果系统还是发生了失效,及时探测,显示,控制故障。尽早给驾驶员警示故障,让驾驶员有效干预,或控制车辆系统进入一个安全状态,防止或减轻伤害产生。
1
FSR本质是需求,一般是甲方(主机厂)对供应商提出的安全要求,只考虑为满足安全目标及ASIL等级,系统应该怎么正常工作,不涉及具体的技术实现方式。
2
3
4
5
例如,功能安全需求示例: 制动踏板开度必须正确反映驾驶员制动意图(ASIL D)。至于应该采用什么传感器,具体怎么反应意图都不是功能层面考虑的问题。
02
什么是FSC
1
安全措施: 事前预防+事后补救,较为广泛,一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称。
2
其中,安全状态主要包括: 关闭功能,功能降级,安全运行模式,Limp Home等Fail to safe策略,目前Fail to operational,如冗余运行等策略相对较少。
系统一旦违反安全目标,安全机制必须在容错时间间隔(FTTI)将系统转移到安全状态。
一般可以根据安全目标所对应的代表性危害事件(一般是ASIL等级最高的危害事件),通过对应运行场景定量或定性评估得到,包括历史数据,仿真计算,实际测试等。
在实际操作中,如果难以计算确定,可以根据经验对其进行预设,然后对代表性危害事件进行实车运行场景模拟,最后根据测试数据和安全确认指标(Validation criteria)确定假设合理性。
对于ASIL等级较高的安全需求,理论上都应该进行车辆测试确认。
首先,FSR一般都是直接包含在FSC之中,多采用需求管理或者文本工具,如Doors,Word进行书写和管理,方便进行版本管理和评审。
其次,FSC内容没有统一的结构要求,将所需内容合理组织形成输出结果且保证分析结果可追溯性即可。
03
怎么从SG得到FSR
和安全目标(SG)导出,即HARA过程相比,从安全目标(SG)到功能安全需求(FSR),也需要进行安全分析,其区别在于:
-
安全分析的对象基于组件层次,非车辆或系统级别。
-
除了归纳分析法(Inductive analysis),还可采取演绎(Deductive analysis)分析方法。
FMEA
典型的归纳分析法: 是从多个个别的事物中获得普遍的规则。
定性分析。
自下而上,从原因到结果,即从可能的故障原因,分析可能的危害结果。
FTA
典型的演绎分析方法: 从已知的定律经过逻辑推演得到新的定律的方法。
定性和定量分析,概念和系统阶段多定性分析,硬件度量分析多定量分析。
自上而下,从结构到原因,即从危害结果或事件,分析可能导致其产生的原因。
首先,FMEA在设计阶段一般指DFMEA,即Design FMEA。FMEA一般用于产品设计或工艺在真正实现之前,对其进行安全分析发现产品弱点,并优化改进。所以FMEA意味着事件发生之前的行为,尽可能避免危害产生,只包括事前预防,这一点和功能安全安全机制需求完全不同,事后补救是功能安全重要的保证安全的措施。
其次,FTA自上而下,从结果到原因的分析方法和从SG到FSR的导出方向一致,操作更为便捷,更容易完整地识别故障原因和影响。
(感兴趣的朋友可以私信我,我再考虑后续是否有必要出一篇安全分析文章)
04
FSR分配至系统架构
-
将不同安全目标对应的安全需求及ASIL落实到架构中具体的软件或硬件组件当中去,进而确定不同组件开发对应的所有安全需求及最高ASIL等级要求,以便于后续系统,软件和硬件的进一步开发。 -
架构作为需求和具体软/硬件实现之间的桥梁,是基于模型的系统工程开发(MBSE)重要内容,能有效改善基于文本或文档开发的弊端,实现模型统一的管理,维护,及需求和测试的可追溯性,可验证性。
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
2022-04-18
2022-04-24
2022-05-10
2022-04-15
原文始发于微信公众号(AUTO世代):03 – 汽车功能安全(ISO 26262)系列: 概念阶段开发 – 功能安全需求及方案(FSR&FSC)