您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
功能安全学习笔记
 
作者:一头孙悟空
  343  次浏览      6 次
2022-11-22
 
编辑推荐:
本文主要介绍了功能安全学习相关的一些笔记记录。希望对您的学习有所帮助。
本文来自于CSDN,由火龙果软件Linda编辑、推荐。

26262系列标准共十部分,分别从管理,流程,软硬件研发,生产和操作等方面对汽车电子产品的整个生命周期进行规范和要求。

总体来说,功能安全是指避免由系统功能性故障导致的不合理风险。它关注的是系统发生故障之后的行为,而不是系统的原有功能或性能。

所谓不合理风险(unreasonable risk),如行车时气囊打开

因此功能安全的目的就是尽可能地通过增加安全机制(Safety Mechanism)去提高安全等级,当系统发生故障后,让系统进入可控的安全状态,实现安全目标(Safety Goal),即避免对人身造成伤害。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

相关项定义(Item Definition)

在功能安全工作之前,分清楚研究对象,明确产品功能和系统边界,意思就是在系统架构图中找到所有E/E相关的组件或者功能,因为机械结构是不归26262管的。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

危害事件(hazard event):运行场景(operational situation)和功能故障(Malfunction)的组合,如夜间山路上车灯非预期熄灭

危害事件的ASIL等级由以下三个参数确定:

严重度 关注的是潜在处于风险中的每个人受到的伤害情况,包括路上的行人和车上的人。 不考虑车子的损毁情况

S0:无伤害 >> S3致命伤害

暴露度 即出现的概率,该项评估基于每辆车都配备该相关项,即不考虑车辆配置

E0:不可能 >> E4:高概率

E0无需分配ASIL等级

可控性,能够充分控制危害事件以避免特定伤害的概率,预估驾驶员 或其他处于潜在风险中的人员对该危害事件的可控性

C0:可控 >> C3:不可控

C0无需分配ASIL等级

ps,S,E,C三个值怎么来的?

交通大数据,仿真,试验等。实在不确定就按高的来。

关于这一部分还有个标准可以看看,SAE J2980-2018

每个危害事件对应至少一个安全目标,安全目标的ASIL等级来源于危害事件的ASIL等级。

安全目标是最高层级的安全要求,表述为功能目的,而非技术解决方案。

有了安全目标才有功能安全要求,以避免危害事件的不合理风险。

以上都是比较虚的部分,多理解几遍发现也就那么回事,一句话概括就是:

功能安全开发时一般由整车层面的安全目标(Safety Goal) 得到概念阶段的功能安全要求(Function safety requirements),

再分析出电子电气层面的技术安全要求(Technical safety requirements)

再概括:SG-->FSR-->系统TSR-->HW/SW SR,

到最后这一步具体的对软件、硬件的技术需求出来,软硬件工程师才能开始干些实在的事情了,例如冗余采样,内存保护什么的,就是为了实现最上层的安全目标,在车辆失控(具体某个零件失效,再具体到某个电子原器件失效)的时候有个B计划,可以挽救人的生命

FSR像是甲方对乙方的“需要实现什么功能”的要求,只需要知道大致架构;TSR像是乙方对甲方所提要求的技术解决方案,根据明确的、细化的系统架构得出

ps,根据与网上一位大神的讨论,实际项目中有些公司可能只有SR这个概念,不太扣FSR和TSR,只要能把需求描述清楚就行了,有时候由于OEM和Tier1角度和角色的差异,很难清楚界定一条需求是FSR还是TSR,有的干脆统称为功能安全需求。我理解这就像OSI七层理想模型和TCP/IP的关系一样,理想与实际应用的差异,把握精髓,把活干好就行了

一个BMS的实例:

SG-->FSR,这一步是着重于功能层面的分析,就是想想得具备什么功能才能达到这个安全目标

FSR-->TSR,这一步是照着系统方案或者系统框图来分析的;

------------------------------------------------------------------------------------------------------------------------------------------------------------------

功能安全需求的属性 - 2018版 7.4.2.4

1)运行模式(operational modes),功能安全需求所对应的系统运行模式,如system off, system active, system passive, emergency operation, safe state

2)故障容错时间间隔(fault tolerant time interval / FTTI)

3)安全状态(safe state)

operating mode, in case of a failure, of an item without an unreasonable level of risk(翻译了更看不懂了)

例如,switched-off mode

我理解的系统失效时,实施了安全机制后的系统运行状态。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

功能安全概念:为实现安全目标(SG),把功能安全要求(FSR)分配给相关项的初步架构要素或外部措施的一切活动的总和。

技术安全概念:为满足功能安全要求而设计系统架构和技术安全要求(TSR)的一切活动的总和。

翻译成人话,安全概念开发的过程就是定义需求的过程。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

ASIL分解

如果一个功能安全要求可以分解为两个冗余的功能安全要求,那么原来的功能安全要求的ASIL等级可以分解到这两个冗余的功能安全要求上,因为只有当两个功能安全要求同时不满足,才会导致系统的失效。

分解后的两个冗余单元之间不应发生从属失效(dependent failure),从属失效分为共因失效(common cause failure)和级联失效(cascading failure)

ASIL分解原则

ASIL分解可以在概念、系统设计、软硬件设计各个阶段进行,而且可以多次分解

一个例子:

另一个恒润的例子,

系统相关部件继承功能安全等级

加入速度传感器后分解,这一步后不同ASIL等级的软件存在于同一个ECU,需要MPU等方法保证这两块软件相互独立

加入硬件进一步分解如下,与上面那个比较相似了

------------------------------------------------------------------------------------------------------------------------------------------------------------------

系统性失效(systematic failure)和随机硬件失效(random hardware failure)

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 6: Product development at the software level

功能安全开发在软件层面的实施

ISO26262 Part6对软件部分,提了一大堆要求,但却没有告知路径

目前来看,autosar是最符合26262要求的软件架构,从知乎Michael Sun可以看出,利用autosar工具链搞功能安全软件开发确实方便不少

功能安全如何体现在软件上,有哪些比较靠谱的研究方法。怎么来计算一个软件的SIL啊??? - 知乎

企业在开发符合26262标准的软件时有两种做法:

1)不论软件模块实际的ASIL等级要求如何,全部统一按照最高ASIL等级开发

2)按照软件模块实际的ASIL等级要求开发,同时提供模块间免于干扰的证据

软件模块之间相互干扰主要有时序干扰和空间干扰

对于空间干扰,常见的措施是使用内存保护单元(Memory Protection Unit , MPU)来实现软件分区。

MPU是MCU上的一个单独的硬件模块,详细了解需要查看芯片手册

内存保护涉及最底层的软件设计,需要对RAM和Flash进行合理划分。程序烧录区域NorFlash是不可写的,不用额外保护。

某ECU的Flash区划分:

Ram区划分:

软件功能安全:

架构设计时常见的措施:

异构冗余(不同的代码实现同样的功能)

故障检测

功能降级

什么叫功能安全软件, 进行充分功能安全分析,采用最新技术进行开发的高可靠性高可用性软件。安全分析包含两大类: 概念设计的安全分析, 相关失效的安全分析

概念设计的安全分析方法:FTA(针对多点失效), FMEA(针对单点失效), ETA相关失效分析: 级联失效,共因失效

采用安全分析还不能充分保证软件质量,还需要采用最新的技术进行开发。因为软件复杂度越来越高,最多的分析和测试也无法覆盖100%的场景。所以只能借助最新的技术帮助实现更高的安全性。最新的技术分为两大类,一个是最佳流程实践如ASPICE,一个是技术层面的要求如高内聚和低耦合的autosar架构,生成代码代替手写代码。

 

   
343 次浏览       6
相关文章

一文了解汽车嵌入式AUTOSAR架构
嵌入式Linux系统移植的四大步骤
嵌入式中设计模式的艺术
嵌入式软件架构设计 模块化 & 分层设计
相关文档

企点嵌入式PHP的探索实践
ARM与STM简介
ARM架构详解
华为鸿蒙深度研究
相关课程

嵌入式C高质量编程
嵌入式操作系统组件及BSP裁剪与测试
基于VxWorks的嵌入式开发、调试与测试
嵌入式单元测试最佳实践

最新活动计划
PowerBI 数据分析与可视化 2-15[北京]
MBSE(基于模型的系统工程) 2-23[北京]
图数据库与知识图谱 2-25[北京]
人工智能+python+大数据 2-27[北京]
自动驾驶系统软件架构设计 3-9[北京]
基于SysML和EA系统分析设计 3-27[北京]
 
最新文章
物联网安全概述
史上最详细的区块链技术架构分析
一文读懂区块链整体架构及应用案例
区块链技术架构
安全架构评审实战
最新课程
Web应用安全架构、入侵检测与防护
物联网关键技术、安全与边缘计算
区块链安全技术实践指南
云服务与安全架构
互联网安全开发方法与实践
成功案例
中国银行 信息安全技术及深度防御
北京 Web应用安全架构、入侵检测与防护
某财税领域知名IT服务商 Web安全测试
普瑞克斯 web安全设计、测试与优化
北京和利时 性能和安全性测试