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

1元 10元 50元





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



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   模型库  
会员   
   
基于 UML 和EA进行分析设计
9月9-10日 北京+线上
大模型核心技术RAG、MCP与智能体实践
8月14-15日 厦门
图数据库与知识图谱
8月28日-29日 北京+线上
   
 
 订阅
一文了解软件安全分析与组件鉴定
 
作者:initiallizer
  54  次浏览      6 次
 2025-8-1
 
编辑推荐:
本文主要介绍了Autosar ComStack相关内容。希望对您的学习有所帮助。
本文来自于微信公众号Autosar 汽车电子进阶,由火龙果软件Alice编辑、推荐。

从本文开始,笔者将结合工作中对功能安全实战部分的开发经验进一步介绍,包括功能安全分析,DFA分析方法,以及结合主流英飞凌TC3xx,瑞萨RH850等常用MCU对其SM( Safety Mechanisms )如 SMU ,电压监控,LBIST,MBIST,时钟监控,ECC, MPU , 总线监控,关键寄存器监控等进行介绍。

本篇介绍下软件安全分析( FMEA )及组件鉴定部分,基本框架如下:

图片

1.功能安全分析

如下将从why?what?及How三个角度分别对为什么需要,安全分析是什么及如何开展进行详细介绍。

1.1 Why?

根据GB/T 34590.6,在软件架构设计阶段,为证明当前架构设计是否能满足对应的功能安全需求,需要开展安全分析,确定是否存在违反功能安全目标的行为,如当前已存在的安全机制不满足要求,并制定相应的安全措施,对软件安全需求进行补充,执行,再次进行迭代最终达到对应的功能安全目标。 根据26262规范,在软件层面的功能安全的主要目的为识别或确认软件的安全相关部分,对相关部分的失效模式进行分析验证其安全措施有效能满足对应的ASIL等级。

图片

1.2 What?

在安全分析中有定量分析及定性分析两种常用方法:定量分析及定性分析。

定量分析方法预测了失效的频率,而定性分析方法识别了失效但不预测失效频率。两种分析方法都依赖于对相关的故障类型和故障模型的了解。 

定性分析方法包括:  定性 FMEA;  定性 FTA ; 危害与可操作性分析(HAZOP);及定性 ETA。 

定量分析方法包括:  定量 FMEA;  定量 FTA; 定量 ETA; 马尔科夫(Markov)模型;及可靠性框图。

定量安全分析是对定性安全分析的补充 。它们用于验证硬件设计是否符合已定义的硬件架构度量评估目标值和因随机硬件失效导致违背安全目标的评估目标值(参见GB/T  34590.5-XXXX,第8章和第9章)。定量安全分析还要求掌握硬件要素定量失效率的知识。 

安全分析的另一种分类方法是基于 分析的执行方法 给出的: 

  • 归纳分析方法是由下而上的方法,由已知的原因识别可能的影响; 
  • 演绎分析方法是由上而下的方法,由已知的影响探寻可能的原因。 
  • 归纳分析和演绎分析相辅相成,因而增加了结果的覆盖面。 

注:

1.FEMA 和ETA是典型的归纳分析方法,FTA和可靠性框图是典型的演绎方法。 

2.一般对于ASILB及以下的功能安全目标,进行定性分析即可,但对于ASILC/D有更高功能安全目标的系统则需要进行定量的分析,定量分析的话一般需要借助专业的工具,在本文中主要介绍定性分析的软件FEMA。

1.3 How?

那如何进行功能安全分析,如何识别及确认软件的安全相关部分?如何支持其有效性?接下来介绍具体的方法论

1.3.1 分析范围确定?

在软件层级的功能安全分析中,可以通过 数据流 的方式从需求的角度分析哪些组件涉及功能安全,最终分析得到功能安全相关的组件。

图片

1.3.2 失效模式分析?

对每个软件组件进行失效模式分析,这里可以使用引导词生成问题去检查架构要素的特定功能或特性。当使用引导词时,使用引导词重复执行每个设计要素的特定功能或特性的安全导向分析,直到预定的引导词都被检查过。

分析其失效是否会违反功能安全目标?如违反了功能安全目标,则需要参考下一章节制定功能安全措施,可参考的引导词如下:

图片

1.3.3 安全措施制定?

本节是对组件失效模式且违反了功能安全目标后,需要制定对应的安全措施,

如存在时序影响问题,需要制定的安全措施是程序流监控;

如出现了通信数据错误,重复等错误就需要E2E保护等措施。

1.3.4 确认是否满足功能安全目标?

功能安全分析的最终的目的是达到功能安全目标要求,当真的出现某种失效模式且当前安全机制无法覆盖时就需要重新考虑架构的合理性,重新对架构进行调整直到满足功能安全目标。 2.软件组件鉴定

2.1 Why?

一方面随着汽车工业的快速发展,Autosar架构的普及,越来越多的软件开发借助于第三方商业组件,例如Vector,普华,东软睿驰等使用非常广泛,另一方面在软件开发过程中难免会复用现有平台的一些组件,那就需要对以上组件进行鉴定,确保其满足功能安全需求。

软件组件鉴定的目的是提供证据,以证明在符合GB/T 34590开发的相关项中对它们的重复使用是合适的。

在软件组件鉴定时涉及的活动主要包括:组件鉴定+组件鉴定活动的checklist评审。

1.2 How?

1)如使用第三方的组件,则最重要的材料是需要供应商提供组件满足对应功能安全等级的证明材料,设计文档,集成文档,测试报告等,这是针对第三方组件鉴定的最有力证据;

2)对于复用的平台或其他项目的组件,则需要提供其设计文档,测试报告,可满足的最高功能安全等级来证明其本身是满足;

3)以上材料相关准备完成后即可根据鉴定要求进行逐项检查确认;

4)组件鉴定完成后,需要对鉴定相关的文档,活动本身进行评审确保鉴定活动是按要求开展的。

   
54 次浏览       6
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证

最新活动计划
大模型RAG、MCP与智能体 8-14[厦门]
图数据库与知识图谱 8-28[北京]
OCSMP认证:OCSMP-MBF 8-29[北京]
基于 UML 和EA进行分析设计 9-9[北京]
软件架构设计方法、案例实践 9-24[北京]
需求分析师能力培养 10-30[北京]
 
 
最新文章
iPerson的过程观:要 过程 or 结果
基于模型的需求管理方法与工具
敏捷产品管理之 Story
敏捷开发需求管理(产品backlog)
Kanban看板管理实践精要
最新课程
基于iProcess的敏捷过程
软件开发过程中的项目管理
持续集成与敏捷开发
敏捷过程实践
敏捷测试-简单而可行
更多...   
成功案例
英特尔 SCRUM-敏捷开发实战
某著名汽车 敏捷开发过程与管理实践
北京 敏捷开发过程与项目管理
东方证券 基于看板的敏捷方法实践
亚信 工作量估算
更多...