之前的文章功能安全入门-1内功心法ISO26262介绍介绍的英文规范ISO26262范围太大英文的也难理解。本篇来个说人话的中文版本****GB_T 34590看完带你入门功能安全。网上关于功能安全的中文文章也不少根本学不过来直接摘了一些大家先自己看之后介绍下国产的GB_T 34590一下就能看明白不少再回过头去看ISO26262就容易了。注意文末彩蛋有ISO26262和GB_T34590的全套规范文档分享链接大家一起学习。本文部分内容来自AUTO世代。更新本篇文章被《AUTO世代》投诉没经过他们授权复制了他们的内容依据就是《6-11 安全验证与测试章节》复制了《12 - 汽车功能安全(ISO 26262)系列: 软件开发 - 软件详细设计及安全测试》微信公众号裁决把文章删了。所以对《6-11 安全验证与测试章节》进行整改后再次发了出来。整改过程发现AUTO世代参考的GB_T34590不是最新版本本文直接参考新的GB_T34590-2022进行讲解并使用ChatGPT进行了一些修改讲述。最后附上功能安全系列的往昔系列文章功能安全入门-1内功心法ISO26262介绍功能安全入门-2 ISO26262说人话版本GB_T 34590–本篇文章功能安全的架构设计七_ 芯片篇-上功能安全的架构设计八_ 芯片篇-下功能安全入门-功能安全岛(FSI)功能安全入门-SoC设计漫谈功能安全入门-再谈FSI0. 一些功能安全资料焉知汽车EPB功能安全笔记系列https://mp.weixin.qq.com/mp/appmsgalbum?__bizMzU5ODQ5ODQ1Mwactiongetalbumalbum_id1677479963144339460scene173from_msgid2247532677from_itemidx1count3nolastread1#wechat_redirect解说功能安全系列https://mp.weixin.qq.com/s/oeFYsw97kyOuQUEbajfGuQ 其他自己搜AUTO世代功能安全 ISO26262https://mp.weixin.qq.com/mp/appmsgalbum?__bizMzkzMDM0NjE4Ngactiongetalbumalbum_id2357683539976290305scene173from_msgid2247484942from_itemidx1count3nolastread1#wechat_redirectCSDNFunctionnal Safetyhttps://blog.csdn.net/coroutines/category_9489713.html车辆功能安全https://blog.csdn.net/weixin_42012149/category_11930840.html知乎穷困潦倒的资本家https://www.zhihu.com/people/qiong-kun-liao-dao-de-zi-ben-jia-59/postsSafetydexhttps://www.zhihu.com/people/brisingr-51阿宝说车https://www.zhihu.com/column/c_13759414650722508801. 什么是功能安全1.1 安全三剑客下图表示了整个汽车操作安全技术体系可以看到功能安全属于汽车操作安全体系的一部分除此之外汽车操作安全中还包括可用性、可靠性、预期功能安全、用户使用安全和信息安全。可用性可用性指的是评估特定的用户在特定条件下使用系统、产品或服务以达到特定目标时的有效性、效率和满意度。可用性尤其在侧重人机交互的系统中是一项非常重要的属性。可靠性可靠性指的是元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。可靠性同时适用于机械和电子电气系统。人身安全人身安全指的是规避汽车操作对驾驶员或者路人或周边车辆内人员注意不仅是驾驶员的人身危害。人身安全中包括了功能安全、预期功能安全和用户使用安全。功能安全简称FuSa功能安全指的是不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。功能安全是在汽车电子电气技术基础上发展而来的一项安全技术对应的标准为ISO 26262。预期****功能安全简称SOTIF预期功能安全指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于智能网联汽车技术的一部分对应的标准为ISO 21448。用户使用安全规避由于用户误操作而造成的不合理风险。信息安全指的是规避重要信息泄露、被篡改、盗窃或遗失。信息安全同样属于智能网联汽车技术的一部分对应的标准为ISO/SAE 21434和SAE J3061。以上安全体系中功能安全、预期功能安全、信息安全这三者是和IT技术或者说EE有关的。这三项安全技术也一起并成为智能网联汽车操作安全性的“安全三剑客”。三者关系功能安全和信息安全的联系来自车辆外部的信息安全威胁同样可能会造成人身危害因此可以将信息安全威胁纳入功能安全的危害源头进行协同分析。功能安全和预期功能安全的关系随着智能网联汽车技术的发展人们发现并不是所有的车辆安全问题都源于系统错误和失效而是很多时候来源于环境影响或系统本身的功能/性能不足。因系统功能不满足预期而导致的安全风险就是预期功能安全要解决的问题。功能安全用于解决电子电气失效对人造成的危害而预期功能安全用于解决系统非故障原因对人造成的危害。ISO 26262标准中对电子电气系统的标称功能及性能没有要求预期功能安全的存在弥补了这部分遗憾。1.2 功能安全如何解决问题除通常质量管理QM外对汽车E/E系统软硬件全生命周期安全开发流程方法等进行约束和规范主要是通过ASIL尽可能降低人为结构性的系统失效对控制器硬件部分进行概率化度量尽可能降低随机硬件失效除过程约束外设定安全状态一旦系统发生故障在故障容错时间内将系统导入安全状态避免对人身、财产造成伤害基于上述三点提出了汽车功能安全法规ISO 26262属于方法论模型。其定义了部分开发流程、明确了各阶段工作输出产物并给出了一些常用的分析方法。总体上并没明确如何具体操作这导致功能安全开发相对难以落地不同开发商对功能安全理解也不尽相同不同企业产品功能安全无法直接横向对比。针对一个功能异常分析出其风险等级设计出合理的安全措施实施并验证。其解决问题的思路识别危害先定义研究对象找到研究对象实现了哪些系统级别的功能如加速、减速等识别这些功能失效时存在的潜在危害如车辆突然不受控加速减速等评估风险将功能失效与不同用车场景结合产生危害事件对其进行风险评估量化危害即设定ASIL等级。危害无法完全避免ASIL风险越高重视程度就应该越高。使用系统工程方式降低风险利用系统工程学的方法将风险降低到一个可以接受的范围内。方法包含对汽车软件和控制器硬件开发流程进行约束在可能出现危害的薄弱环节制定相应的安全措施等。ASIL等级越高约束程度或者安全措施要求越高。一方面从设计的角度出发尽可能避免失效。另一方面如果发生了失效尽早发觉故障给驾驶员警示故障让驾驶员可以进行有效干预或控制车辆系统进入一个安全状态防止伤害最终产生。2. ISO26262说人话版本ISO26262对应的GB_T 34590里面主要就是这个V字模型主要由概念阶段、产品开发阶段、生产与运行阶段组成。3-5 相关项先将汽车功能进行拆分拆分出的相关项item成为后续功能安全分析的对象。相关项定义的本质为确定功能安全研究的对象相关项 结构 功能描述 对象属性特征结构: 研究对象是什么由哪些系统及组件构成功能描述: 研究对象实现了哪些系统级别的功能是后续危害分析和风险评估HARA基础。对象属性特征: 对象预期的功能危险内部以及对外依赖关系以接口体现相关法律法规。对于相关项的拆分硬件可以按IP拆分软件则可以按功能或者可被测试的最小单元函数进行拆分然后定安全目标。澄清功能安全流程中对于需求的四层管理模型3-7 危害分析和风险评估危害分析与风险识别Hazard Analysis Risk Assessment缩写HARA根据相关项定义的功能分析其功能异常表现识别其可能的潜在危害Hazard及危害事件Hazard Event并对其风险进行量化即确定ASIL等级导出功能安全目标Safety Goal和ASIL等级以此作为功能安全开发最初最顶层的安全需求。相关方法论故障模式与影响分析FMEA、危险与可操作性分析HAZOP、SCE ASIL定级。危害事件 危害 运行场景分析相关项功能异常导致的整车危害车辆纵向加速、纵向减速、旋转等或是灯光不够亮、无法加速、无法刹车等将该整车危害放在不同的运行场景中白天、晚上、高速、低速、上坡、下坡等组合出危害事件hazardous event对危害事件进行风险评估给出风险的量化分析结果即功能安全等级ASIL-A/B/C/D为该相关项输出安全目标每条安全目标都包含了ASIL安全等级的信息。危害分析时可以采用HAZOPHazard and operability analysis方法论使用下图模板3-8功能安全****方案基于安全目标用系统工程学方法得到功能安全需求与初步的架构假设。过程为从安全目标推导出功能安全要求FSR将FSR分配至系统架构形成功能安全方案FSC并将这些功能安全要求分配到项目的要素中。FSR功能安全要求基于两个角度定义需求——事前预防 事后补救。FSC功能安全方案重点是列出为了满足安全目标需要做的安全措施一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称。相关方法论归纳分析法Inductive analysis、演绎法Deductive analysis、故障模式与影响分析FMEA、故障树分析FTA4-5 系统层面需要将FSR进一步细化为技术层面的安全需求TSR即怎么做为后续的软件和硬件的安全开发奠定技术需求基础。安全系统阶段开发内容可以分为两大部分技术安全需求及方案开发及验证 系统集成测试及安全确认Validation。系统级产品开发之后系统分成了硬件与软件两部分。相关方法论Fail to safe 安全架构、Fail to operational 安全架构。技术安全需求TSR 由FSR技术化的安全需求 安全机制 Stakeholder需求车辆使用法律法规生产和服务方面相关的安全需求将技术安全需求描述的功能模块用框图的形式表示出来即为每一条需求的技术解决方案以框图形式表达。框图的输入、输出接口就是功能模块的输入、输出接口所有的框图组合在一起形成系统架构图。不同ASIL等级下的设计要求安全分析和相关性失效分析在系统阶段的安全分析需要用到两种分析方法——FMEA、FTA。FMEA和FTA都是以识别系统性失效的原因和系统性故障影响的工具FTA是演绎分析法从上往下分析导出安全目标违背的根本原因FMEA是归纳分析法从下往上采用故障模型可采用HAZOP关键字对可能导致安全目标违背的所有失效模式进行分析。安全机制应该包含检测系统性及随机硬件故障的措施。例如针对系统I/O总线信号范围检查冗余校验有效性检测逻辑计算单元数据流及程序流监控控制器硬件底层软件监控等。显示故障。例如对驾驶员进行声音不同类型及颜色的指示灯提示文字等预警增加驾驶员对车辆的可控性。控制故障的措施。例如Fail to safe: 将系统在指定的故障容错时间间隔FTTI导入安全状态包括降级故障仲裁故障记录等。如果不能还需要定义紧急运行时间间隔及运行状态。或者Fail to operational通过并行冗余系统当一个系统失效后进入另外一个并行系统继续提供全部或部分功能。常见的安全机制:传感器传感器硬件冗余独立供电多通道冗余采集信号质量检测控制单元在线诊断比较器多数投票器执行器执行器硬件冗余执行器控制信号质量检测通讯冗余发送信息冗余CRC时间监控问答机制传感器与执行器的安全设计对于传感器与执行器通常采用硬件冗余机制实现高级别的ASIL要求。传感器硬件冗余采集可以是利用相同的两个传感器对同一信号进行重复采集也可以是利用不同类型传感器对强相关的两个信号分别进行采集执行器属于系统功能实现终端执行器冗余会极大增加系统成本一般在Fail to operational 安全架构中才会采用。控制单元安全设计在系统级产品开发阶段对控制单元的安全设计主要在 Fail to safe 与 Fail to operational 两类安全架构上。而不是控制器硬件冗余、CPU Dual Core LockStep、看门狗、程序流监控等这些都是后续流程中的软件或硬件安全机制。Fail to safe最典型的应用就是在线监控将整个控制单元分为功能实现和在线监控两部分即所谓的的1oo1D类型系统具体如下图所示:特点是一旦发现问题就将系统导入安全状态停止提供系统原有功能或者维持最必要的功能。Fail to operational 属于相对高级的安全架构比较器和多数投票器都属于这类安全架构整个系统由相对独立的两条或多条功能链路构成每条功能链路都拥有自己独立的传感器控制单元甚至执行器。可以实现1oo2D安全架构如下图所示:特点是当其中一条功能链路出现异常控制系统可以切换到其他功能链路保证系统继续正常工作或者降级运行。5-5 硬件级产品开发基于系统设计规范硬件开发过程以v模型概念为基础左侧为硬件需求说明、硬件设计与实现右侧为硬件集成与验证。核心在于分析并实现硬件安全机制。相关方法论FMEDAISO 26262中基于概率论的定量危害分析仅限适用于硬件部分因为只有硬件存在随机失效并符合概率分布原理。6-5 软件层面根据系统设计规范软件开发过程以v模型的概念为基础软件需求规范和软件架构设计与实现在左侧软件集成与验证在右侧。核心在于分析并实现软件安全机制。相关方法论半形式法架构设计、FFI免干扰设计、上面的只是一个开发流程在正规的软件公司里面基本也是按照这个方法开发软件的。软件安全机制包括:与应用软件本身、基础软件或操作系统失效探测、指示和减轻有关的自检或监控功能。例如: 应用层软件程序流监控输入输出合理性检测等; 基础软件自检等。与安全相关硬件要素故障探测、指示和减轻相关的功能。例如: 涉及基础软件相关安全机制包括控制单元电源时钟内存等硬件要素故障信息探测指示和控制。使系统达到或维持安全状态或降级状态的功能。例如: 错误管理安全状态等。6-6 软件架构安全设计要求根据不同的软件分层软件架构安全设计基本分为两大部分功能监控层安全设计基础软件安全设计功能监控层安全设计在功能监控层软件架构设计主要是将和架构相关的错误探测和错误处理等安全机制应用于功能监控层架构设计。虽然根据不同类型的控制器其安全机制具体实施有所差别但总体而言主要包含以下安全机制用于错误探测的安全机制包括输入输出数据的范围检查合理性检查例如使用期望行为参考模型、断言检查、或不同来源信号比较数据错误探测例如检错码和多重数据存储外部要素监控程序执行例如通过专用集成电路ASIC或者其他软件要素来执行看门狗功能。监控可以是逻辑监控或时间监控或者两者的结合程序执行的时间监控设计中的异构冗余—在软件或硬件中实施的访问冲突控制机制与授权访问或拒绝访问安全相关共享资源有关。用于错误处理的安全机制可能包括为了达到和维持安全状态的功能关闭静态恢复机制例如恢复块、后向恢复、前向恢复以及通过重试来恢复通过划分功能优先级进行平稳降级从而最小化潜在失效对功能安全的不利影响设计中同构冗余主要侧重于控制运行相似软件的硬件中瞬态故障或随机故障的影响例如软件在时间上的冗余执行基础软件安全设计基础软件多和控制器硬件相关是保证上层软件应用层功能监控层正常运行基本条件。整个基础软件全部依据最高ASIL等级开发成本过高通常采用Partition分区方式使用免于干扰FFI分析法是不同ASIL等级的要素共存。为了实现非或不同ASIL等级要素共存需要在基础软件部分采用相应的安全措施避免高ASIL等级软件受到低ASIL等级或QM软件的干扰进而破坏安全需求具体如下图所示:以MCU的系统软件为例研究FFI干扰类型与对应的安全机制执行和时序Timing Execution干扰 如执行阻塞 blocking of execution、死锁 deadlocks、活锁 livelocks 等 对应的安全机制有内外部看门狗Internal/External Watchdog、程序监控Program Flow Monitor等内存Memory干扰如内容损坏corruption of content、堆栈溢出或下溢stack overflow or underflow等 对应的安全机制有使用内存保护单元Memory Protection Unit , MPU来实现内存分区等信息交换Exchange of information干扰 如信息重复 repetition of information、 信息丢失 loss of information、信息损坏 corruption of information等 循环冗余校验cyclic redundancy check、E2E保护 End2End Protection等避免软件要素间的相互干扰软件要素间干扰的形式主要有两类时序干扰空间干扰时序干扰可能存在以下几种形式执行阻塞 blocking of execution死锁 deadlocks活锁 livelocks执行时间的不正确分配 incorrect allocation of execution time软件要素间的不正确同步 incorrect synchronization between software elements空间干扰包括内存存储干扰以及信息交换干扰常见的形式为内容损坏 corruption of content对已分配给其他软件要素的内存进行读写访问 read or write access to memory allocated to another software element信息重复 repetition of information信息丢失 loss of information信息延迟 delay of information信息插入 insertion of information信息伪装或信息的不正确寻址 masquerade or incorrect addressing of information信息次序不正确 incorrect sequence of information信息损坏 corruption of information对于空间干扰常见的措施是使用内存保护单元Memory Protection Unit ,MPU来实现软件分区。MPU是微控制器上的一个特殊硬件它可以限制和监视对存储器映射表某些地址范围的访问。当MPU检测到对保护区的任何写入或执行访问时该访问将被阻止并进入相应的安全状态。MPU实现软件分区应满足如下要求一个软件分区内的任务彼此之间不能免于干扰。一个软件分区不能改变其他软件分区的代码或数据也不能控制其他软件分区的非共享资源。一个软件分区从共享资源获取的服务不能被另一个软件分区影响。这包括相关资源的性能以及对资源调度访问的使用率、延迟、抖动和持续时间。ECU的内存由以下三部分组成ROM Read Only Memory程序存储器RAM Random Access Memory随机访问存储器EEROMElectrically Erasable Programmable Read-Only Memory电可擦编程只读存储器或者称为Flash由于ROM不会被修改因此MPU对内存分区主要运用于RAM和Flash。6-7 设计行为规范ISO 26262对功能安全相关的软件架构设计还根据不同ASIL等级提出了其他相关约束包括:软件架构细致程度应能够承载SWSR。软件架构设计原则包括: 适当分层限制软件组件规模和复杂度限制接口规模组内高内聚组间低耦合限制中断使用等。软件架构设计验证方法包括: 设计走查设计检查控制流数据流分析仿真快速原型等。HWSR应被分配至软件架构中的组件。不同或非ASIL等级软件组件开发需满足以下原则之一:按最高ASIL等级。要素共存FFI例如软件分区。对SWSR和具体实施之间的可追溯性。软件架构包含静态和动态方面的静态方面的主要和不同软件单元之间的接口1软件结构包括其分级层次2 数据处理的逻辑顺序3 数据类型和它们的特征参数4 软件组件的外部接口5软件的外部接口及 约束包括架构的范围和外部依赖。动态方面的涉及1功能和行为2控制流和并发进程3 软件组件间的数据流4 对外接口的数据流时间的限制。6-8 单元设计和实现的要求软件单元的实现包含源代码生成和转换为目标代码。6-11 安全验证与测试本小节全部来源于GB_T 34590直接复制的规范上的内容。ISO和GB规范大家都可以看到不属于某人所有也不神秘大家都可以免费学习。ISO 26262规范和GB_T 34590 2022的pdf版本在文档末尾彩****蛋欢迎大家下载。打开《GB_T 34590.6-2022 道路车辆 功能安全 第6部分产品开发软件层面.pdf》第九章软件单元验证。第十章软件集成和验证。第十一章嵌入式软件测试。第九章软件单元验证关于软件单元验证方法如下静态分析和动态分析见上面箭头所示。9.4.4 为了评估验证的完整性并提供证据证明已充分实现单元测试目标,应确定在软件单元层面的要求覆盖率,同时应按照表9列出的度量对结构覆盖率进行测定。10.4.4 为了评估验证的完整性并提供证据证明已充分实现集成测试的测试目标,应确定测试用例在软件架构层级对要求的覆盖率。如有必要,应规定额外的测试用例,或提供基于其他方法的理由。10.4.5 按照4.4,该条适用于 ASIL(A)、(B)、C 和 D等级:为了评估测试用例的完整性,并提供证据证明已充分实现集成测试的测试目标,应按照表12列出的方法来评估结构覆盖率。根据表9和表12覆盖率有5类语句覆盖率分支覆盖率函数覆盖率调用覆盖率MC/DC修改条件/判定覆盖率使用AI解释下MC/DC修改条件/判定覆盖率MC/DCModified Condition/Decision Coverage修改条件/判定覆盖是一种软件测试技术用于评估测试用例集对程序逻辑的覆盖程度。它特别关注程序中条件语句的测试要求测试用例能够独立地影响每个条件的结果并最终影响整个判定表达式的结果。MC/DC 的目标是确保每个条件都被独立地测试为真和假。确保每个条件对判定表达式的结果有独立的影响。确保判定表达式的每个可能结果都被测试到。MC/DC 的优势更强的逻辑覆盖: 相比语句覆盖或分支覆盖MC/DC 能更全面地测试程序的逻辑条件发现更多潜在缺陷。更少的测试用例: 在保证较高覆盖率的同时MC/DC 通常只需要较少的测试用例提高测试效率。适用于安全关键系统: MC/DC 被广泛应用于航空航天、医疗设备等对安全要求极高的领域。MC/DC 的应用场景由于 MC/DC 对逻辑覆盖要求较高因此更适用于逻辑复杂、条件语句较多的程序。对于安全关键系统强烈建议使用 MC/DC 进行测试以最大程度地降低风险。简单的例子假设有如下条件语句:if(a10b5){//dosomething}else{//dosomethingelse}为了满足 MC/DC 标准需要设计测试用例使a 10和b 5这两个条件独立地影响整个条件表达式的结果并测试到所有可能的结果真/假。总而言之MC/DC 是一种强大的测试技术可以提高测试覆盖率发现更多缺陷尤其适用于安全关键系统。第十章软件集成和验证在此子阶段,按照软件架构设计,对软件要素之间特有的集成层次和接口进行验证。软件要素的集成和验证的步骤直接对应着软件的分层架构。嵌入式软件可能由安全相关和安全无关的软件要素组成。第十一章嵌入式软件测试该子阶段的目的是提供证据,证明该嵌入式软件:a) 在目标环境执行时满足安全相关要求;b) 不包含与功能安全相关的非预期功能和特性。对单元验证集成验证嵌入式软件验证的动态和静态测试划分如下单元验证: 静态分析为主和动态分析集成验证: 静态分析 和 动态分析为主嵌入式软件验证: 动态分析7-6运行、服务与报废这一阶段涉及确保产品或元件在生产、操作、服务和退役方面的功能安全的过程、手段和指示。考虑了与安全有关的特殊特性以及项目或元件的生产、运行、服务维护和维修和退役的说明书的制定和管理。后记本文用中文的表述让大家更加明白功能安全ISO26262到底该怎么做原则和方法及流程是什么。当我们去审视我们的软硬件的时候就会去思考哪里会出问题怎么样才能更安全然后用这些原则和方法去制定特定的技术方案下一节会继续讲具体的软硬件设计的时候该注意什么当然在工作中我们可能只负责一个小模块那也不妨碍我们有功能安全的思维去审视我们的设计尽管可能仅仅做了一个故障上报处理或者故障纠错的功能形成合力可以助力我们过ASIL-D。“啥都懂一点啥都不精通干啥都能干干啥啥不是专业入门劝退堪称程序员杂家”。欢迎各位有自己公众号的留言申请转载纯干货持续更新欢迎分享给朋友、点赞、收藏、在看、划线和评论交流**文末彩蛋**ISO26262和GB_T 34590的全套pdf规范文档链接https://pan.baidu.com/s/1QDkrjJ8K3a95NTDH0F7XnA提取码公众号留言公众号“那路谈OS与SoC嵌入式软件”欢迎关注个人文章汇总https://thatway1989.github.io