电子工程师技术服务社区
公告
登录
|
注册
首页
技术问答
厂商活动
正点原子
板卡试用
资源库
下载
文章
社区首页
文章
ISO 26262基本内容介绍
分 享
扫描二维码分享
ISO 26262基本内容介绍
功能安全
汽车电子设计
研发流程
雨下了一季
关注
发布时间: 2020-05-07
丨
阅读: 1171
#### Part1: Vocabulary 第一部分主要讲一些术语以及相应的解释,这部分大家直接看标准就可以了。推荐直接看2018版的标准,因为里面增加了新的术语(比如:卡车,摩托车,公共汽车等)。这里所列的术语在后续章节会大量出现,建议仔细查看,做到心中有数。 #### Part2: Management of functional safety 第二部分主要为负责整个安全生命周期的组织定义要求。也可以说本章是安全生命周期活动的先决条件。 无规矩不成方圆,同样,本标准也适用。只有好的管理,才能保证安全做的到位。这些管理包括,安全文化管理,员工功能安全能力管理等。相关项目要确保核心开发团队配备功能安全经理,功能安全经理会在项目开始的早期阶段根据项目节点制定并维护相关安全计划,监督整个项目的安全活动过程。 *本部分的主要工作产物有:安全计划,功能安全能力证据,组织特有的功能安全流程和特殊规则,质量管理系统相关证据等。* #### Part3:Concept phase 第三部分主要讲的是相关项的定义、危害分析和风险评估、功能安全概念。 所谓相关项的定义,就是说在我们开始分析产品之前,我们需要知道那些信息。比如:产品的预期用途,产品状态和运行模式,系统的边界和接口,环境条件,使用的限制,相关的法律法规,潜在的危害来源等。 所谓危害分析和风险评估,它是我们评估产品功能安全等级(ASIL等级)和确认安全目标的分析手段。主要考量参数有三,分别为:可控性(C)、暴露概率(E)、严重度(S)。其中C和S有三个等级,及C1,C2,C3、S1,S2,S3;E有四个等级,及E1,E2,E3,E4。数字越大,相应的概率就越大。我们可以用下面的公式来计算ASIL等级:ASIL等级= E+C+S,其中不难看出组合E4+C3+S3为最高等级(D),这里有个小技巧,ASIL等级所对应的数字分别为:A-7,B-8,C-9,D-10。 前面我们知道了产品的定义,功能,我们也根据分析得出了产品的ASIL等级和安全目标,那么接下来我们就要确定产品的功能安全概念,也就是定义对于本产品而言,如果失效了我们要做什么,我们要如何做出响应,需要多长时间做出响应,哪些是我可以接受的失效…… 也就是对安全目标而言,我们还需要确认安全状态,故障响应时间间隔等等。如果是联合开发,还需要定义双方之前的分工职责,及开发接口协议(DIA)。 *本部分的主要工作产物有:相关项定义,功能安全概念,DIA,危害分析和风险评估报告等。* #### Part4:Product development at the system level 第四部分主要讲的是在系统开发层面,主要活动有技术安全概念(包含:技术安全需求,安全机制,系统架构设计,系统分析等)、系统集成和测试(包含:软硬件集成和测试,系统集成和测试,整车集成和测试)。从系统层面我们可以计划系统开发过程中每个子阶段的功能安全活动。 技术安全需求就是实施或者说细化功能安全概念,将功能安全需求细化到系统级别的技术安全需求,并进一步分配给软件和硬件模块。接下来,还要对系统进行安全分析,标准里推荐的分析方法有两种:演绎分析和归纳分析。比较常用的方法是FTA和FMEA。通过安全分析后,我们可以发现系统的单点失效,潜在失效等失效模式,然后针对某一失效,我们可以设计安全机制来平衡。 本部分的主要工作产物有:技术安全需求、系统架构设计规范、软硬件接口规范、集成和测试策略、安全验证规范等。 #### Part5:Product development at the hardware level 第五部分主要讲的是在硬件开发层面,主要活动有硬件安全需求规范、硬件设计、硬件架构指标的评估、随机硬件失效导致的安全目标的违背的评估、硬件集成和验证等。 硬件安全需求规范的主要目的有三个:(一)明确硬件安全需求(该需求是从技术安全概念和系统架构设计规范中分离出来的);(二)完善在系统层面设计时启动的软硬件接口规范;(三)验证硬件安全需求和软硬件接口规范与技术安全概念和系统架构设计规范是一致的。 硬件设计的主要目的有三个:(一)支持安全分析,考虑安全分析的结果,满足硬件安全需求,满足软硬件接口规范,保持与系统架构设计规范一致和满足所需的硬件设计属性;(二)明确需求并且提供硬件在生产,运行,维护和报废整个生命周期与功能安全相关的信息;(三)验证硬件设计可以满足硬件安全需求和软硬件接口规范。 硬件架构指标的评估主要目的是为硬件架构设计在检测和控制与安全相关的随机硬件失效方面的适用性提供证据。(这里主要评估单点失效率和潜在失效率,具体指标参见新版标准第五部分表4和表5)。 随机硬件失效导致安全目标违背的评估主要目的是为由于随机硬件失效失效导致安全目标违背的残余风险足够低。这里随机硬件失效的目标值随着ASIL等级的不同而不同(具体值参见新版标准第五部分表6)。 硬件集成和验证的主要目的是确保硬件的开发符合硬件安全需求。 *本部分的主要工作产物有:硬件安全需求规范、硬件安全需求验证报告、硬件设计规范、硬件安全分析报告、相关项结构对随机硬件失效有效性的分析、硬件专用措施规范、硬件集成和验证规范等。* #### Part6:Product development at the software level 第六部分主要讲的是在软件开发层面,主要活动有产品在软件层面开发的通用话题、软件安全需求规范、软件架构设计、软件单元设计和实现、软件单元验证、软件集成和验证、嵌入式代码的测试等。 产品在软件层面开发的通用话题主要目的是:(一)确保软件开发过程的合适和一致性;(二)确保软件开发环境的合适性。 软件安全需求规范的主要目的是:(一)明确/精炼从技术安全概念和系统架构设计规范中分离的软件安全需求;(二)定义软件需要实现的与安全相关的功能和属性;(三)完善在系统层面启动的初始的软硬件接口需求;(四)验证软件安全需求规范和软硬件接口与软件开发适配,并且与技术安全概念和系统架构设计规范一致。 软件架构设计的主要目的是:(一)开发满足软件安全需求和其他软件需求的软件架构;(二)验证软件架构设计能够满足软件安全需求所分配的ASIL等级;(三)支持软件的实现和验证。 软件单元设计和实现主要目的是:(一)开发遵循软件架构设计,设计标准和分配的支持实现和验证的软件单元需求的软件单元;(二)实现明确的软件单元。 软件单元验证的主要目的是:(一)为软件单元设计满足所分配的软件需求和合适的实现提供证据;(二)验证是否正确实现了基于安全分析得出的已经定义的安全措施;(三)为已实现的软件单元符合软件设计并且满足所分配的ASIL等级的安全需求提供证据;(四)为软件单元既不包含与功能安全不期望的功能也不包含不期望的属性提供充足的证据。 软件集成和验证的主要目的是:(一)持续定义集成步骤和集成软件元素直到嵌入式软件完全集成;(二)验证由软件架构层面的安全分析得出的已定义的安全措已经正确实现;(三)为已经集成的软件单元和软件组件满足遵循于软件架构设计的需求提供证据;(四)为集成好的软件既不包含功能安全不期望的功能也不包含不期望的属性提供足够的证据。 嵌入式软件测试等我主要目的是:(一)当软件执行在目标环境中时要满足安全相关的需求;(二)不包含与功能安全相关单位不期望的功能和属性。 *本部分的主要工作产物有:软件开发环境文档、软件安全需求规范、软件验证报告、软件架构设计规范、相关失效分析报告、安全分析报告、软件单元设计规范、软件单元的实现、软件验证规范、嵌入式软件代码等。* #### Part7:Production,operation,service and decommissioning 第七部分主要讲的是产品的生产,运行、维护和报废相关,主要活动有生产,运行,维护和报废全周期的计划、生产相关、运行,维护和报废相关等。 生产,运行,维护和报废的计划主要目的是:(一)开发和维护安装在道路车辆上的安全相关的元素/相关项的生产过程(如果组织的生产过程遵循IATF 16949标准,本条即可满足);(二)给与安全相关要素/相关项有交互的用户开发有关运行,维护和报废相关的信息,以确保在车辆的整个生命周期中实现功能安全。 生产的主要目的是确保相关的制造商、个人或组织在产品在生产各自负责的产品生产阶段达成功能安全(主机厂,供应商,子供应商)。 运行,维护和报废的主要目的是确保功能安全在车辆全生命周期的运行,维护和报废阶段的达成。 *本部分的主要工作产物有:安全相关内容的生产计划、安全相关内容的生产控制计划(包含测试计划)、生产需求规范、生产过程能力报告、安全相关内容的服务计划、安全相关内容的服务说明、运行,服务和报废的需求规范、控制措施报告、现场观察说明等。* #### Part8:Support process 第八部分主要讲的是支持过程,主要活动有分布式开发接口、安全需求的规范和管理、配置管理、变更管理、验证、文档管理、软件工具的置信度、软件组件的认证、需求和推荐、硬件要素的评估、在用证明等。 分布式开发接口的主要目有三个:(一)为客户和供应商开发活动定义好相互作用和依赖性;(二)描述分配的职责;(三)明确相关项/要素的分布式开发的工作产物的交换。 规范和管理安全需求的主要目的有两个:(一) 确保正确的规范针对安全要求的属性和特征;(二)保证贯穿整个安全周期的安全需求的一致性管理。 配置管理的主要目的有两个:(一)保证任何时候工作产物,相关项和原则以及创造他们的通用条件都被独一无二的标记并且通过可控的方式进行重复生产;(二)确保早期和当前阶段的版本的相关性和不同可以被追溯。 变更管理的主要目的是分析和控制在整个安全周期中的安全相关的工作产物的变更。 验证的主要目的是确保工作产物符合他们的需求。 文档管理的主要目的是为了促进高效且可重复的文档管理流程开发文档管理策略。 使用的软件工具的置信度主要目的有两个:(一)提供一个标准来决定可使用的软件工具所需的置信度水平;(二)为了创造软件工具能够被用来支持需要遵循功能安全标准的活动或任务的证据,提供适用的软件工具认证的方法。 软件组件的认证主要目的是为软件组件适用于符合功能安全标准的相关项在开发中的重复使用提供证据。 硬件要素的评估主要目的是确保功能定位足够满足分配的安全需求,因此,由于硬件要素的系统故障导致的安全目标或者安全需求的违背的风险要足够低。 在用证明的主要目的是为在用证明提供指导。当现场数据可用时,可以使用在用证明对已有相关项/要素进行重复使用,作为符合功能安全标准的替代方法。 *本部分的主要工作产物有:供应商选择报告、开发接口协议(DIA)、供应商项目计划、供应商安全计划、功能安全评估报告、供应协议、配置管理计划、变更管理计划、变更需求、影响分析和变更计划、变更报告、验证计划、验证规范、验证报告、文档管理计划、文档指南要求、软件工具准则评估报告、软件工具认证报告、软件组件文档、软件组件认证报告、硬件要素评估报告、硬件要素测试计划、在用证明分析报告、用于在用证明的候选项描述等。* #### Part9: Automotive safety #### integrity level (ASIL)-oriented and safety-oriented analysis 第九部分主要讲以汽车安全完整性等级为导向和以安全为导向的分析,主要活动有遵从ASIL裁剪的需求分解、元素共存的标准、相关失效分析、安全分析等。 遵从ASIL裁剪的需求分解的主要目的有两个:(一)确保安全需求在更细的层次被分解成冗余的安全需求,并且他们被分配了足够的相关设计要素;(二)根据允许的ASIL分解模式应用ASIL分解。 共存要素的准则的主要目的有两个:(一)安全相关的子要素与没有安全相关的子要素;(二)分配了不同ASIL等级的安全相关单位子要素。 相关失效分析的主要目的有两个:(一)通过分析潜在的原因或者发起者,确认在设计中充分实现了所需要的独立性或者界面的自由性;(二)定义安全措施来减少可能的相关失效,如果必要的话。 安全分析的主要目的是确保由于系统失效或者随机硬件失效而违背安全目标的风险足够低。 *本部分的主要工作产物是:相关失效分析(DFA)、相关失效分析验证报告、安全分析、安全分析验证报告等。* #### Part10: Guidelines on ISO 36262 #### Part11: Guidelines on application of ISO 26262 to semiconductors #### Part12: Adaptation of ISO 26262 for motorcycles 第十部分是ISO 26262指导; 第十一部分是ISO 26262在半导体上的应用指南; 第十二部分是ISO 26262 对摩托车的使用。 本篇文章对以上三个部分不再介绍,感兴趣可以自行查看标准相关内容。 本次的ISO 26262的基本内容介绍就分享到这里。对于标准这种文件,本身就是很枯燥的东西,本人经验有限,文中叙述不清楚或者不准确的地方欢迎大家批评指正。我们下期再见^-^
原创作品,未经权利人授权禁止转载。详情见
转载须知
。
举报文章
点赞
(
0
)
雨下了一季
关注
评论
(0)
登录后可评论,请
登录
或
注册
相关文章推荐
MK-米客方德推出工业级存储卡
Beetle ESP32 C3 蓝牙数据收发
Beetle ESP32 C3 wifi联网获取实时天气信息
开箱测评Beetle ESP32-C3 (RISC-V芯片)模块
正点原子数控电源DP100测评
DP100试用评测-----开箱+初体验
Beetle ESP32 C3环境搭建
【花雕体验】16 使用Beetle ESP32 C3控制8X32位WS2812硬屏之二
X
你的打赏是对原创作者最大的认可
请选择打赏IC币的数量,一经提交无法退回 !
100IC币
500IC币
1000IC币
自定义
IC币
确定
X
提交成功 ! 谢谢您的支持
返回
我要举报该内容理由
×
广告及垃圾信息
抄袭或未经授权
其它举报理由
请输入您举报的理由(50字以内)
取消
提交