ISO26262

ISO 26262中的“免于干扰”主要用于证明不同软件要素或安全相关要素共存时，一个要素的异常不会破坏另一个要素所承担的安全要求。它常见于不同ASIL等级软件共用处理器、内存和通信资源，以及安全分解后的独立性论证。围绕“ISO 26262怎么验证免于干扰，ISO 26262免于干扰分析需要检查哪些内容”，重点应放在干扰来源识别、防护机制和验证证据是否形成完整闭环。ISO 26262-6:2018专门在附录D讨论软件要素之间的免于干扰。

开展ISO 26262的接口分析，不能仅仅把它当成是对一张通信信号表格的整理。这里所说的接口，其范围要宽泛得多，它既包括了系统与外部车辆环境、传感器、执行器之间的那些连接，也涵盖了系统内部，也就是硬件、软件以及各个不同安全要素相互之间的数据交互、控制指令、电源供给以及时序上的配合关系。ISO 26262对于产品开发的要求，是贯穿了系统、硬件和软件这几个层面的，并且要通过安全导向的分析、配置管理以及变更管理，来形成一个能够闭合的环路。

在讲ISO 26262的故障容错时间怎么去定，还有它的依据又要怎么去解释之前，有个地方得先想明白：这件事不是只写上一个毫秒级的数字就算是做完了。FTTI更像是一段留给安全机制去反应的时间窗口，从故障发生的那一刻算起，一直到车辆或者系统快要迈入危险状态的前夕，安全机制得靠着这段时间把问题处理掉。它和危险事件长什么样子、车辆跑在哪种运行场景里面、故障往前传导的速度快慢，还有诊断以及降级的能力都扭在一起，所以不能简简单单把它跟软件的任务周期画上等号。

在功能安全的前期，Item定义到底该怎么写，Item边界又该怎么去划分，这一步经常让人卡住。Item定义不是给系统写一段普普通通的介绍，更不是把控制器、传感器、执行器拉一张清单就算完事；它真正要去说明的，是当前要分析的那项车辆功能到底是什么，这个功能需要依赖哪些对象，以及边界内外怎样互相交换信息。ISO 26262-3:2018覆盖的是概念阶段，其中包含了Item Definition、危害分析与风险评估、功能安全概念等内容；而ISO 26262这个标准本身关注的，是安全相关电子电气系统因异常行为造成的危害，也包含系统之间交互带来的影响。

ISO 26262项目的裁剪工作到底要怎么开展，还有裁剪的理由又要怎样去说明，这件事情在功能安全相关的项目里面，它的重要性其实是经常被低估的，项目刚刚开始启动的时候，有的团队习惯于把标准里的那些条款，全部给塞进计划书当中，结果文档是越做越厚，可真到了要去执行的时候，团队成员却抓不住真正的重点；也有的团队为了赶一赶项目的进度，就把那些自己不想做的内容，直接给写成了不适用，可是等到后来客户评审、功能安全审核，或者是量产前再进行复盘的时候，大家就很容易陷入解释不清的麻烦了，项目裁剪这件事的目的，就是在不会削弱安全目标这个大前提下，把那些需要去做的工作、可以合并到一起的活动、能够拿来复用的证据，还有并不适用的条款，都给说清楚。

在汽车功能安全开发中，ASIL等级越高，对开发流程、验证深度和独立性的要求也越高。ISO 26262怎么进行ASIL分解，ISO 26262 ASIL分解后安全要求怎么分配，核心是通过架构冗余把高等级安全要求分配给相互独立的实现路径，同时保证原安全目标要求的安全完整性没有降低。ISO 26262-9专门规定了与ASIL相关的要求分解、元素共存和相关失效分析要求。

在聊ISO 26262硬件架构指标怎么分解、薄弱环节又怎么去识别时，光盯着SPFM、LFM、PMHF最后那几个数字是不够的。硬件架构指标本身并不是为了一张漂漂亮亮的计算表，而是要借它去弄明白，随机的硬件失效会不会真的扰动安全目标，看看哪些失效已经被安全机制兜住了，哪些地方其实还残留着风险，又有哪些故障是可以悄悄潜伏很长时间的。在真实项目里，得把安全目标、硬件单元、失效模式、诊断覆盖率，还有验证的证据串到一块儿去看，这样做出来的分析结果才会有实际的意义。

在功能安全项目当中，依赖失效分析到底该怎样去开展，依赖失效的证据又该怎样去整理，这两样事情常常容易被做得不够扎实。它并不是把FMEA、FTA再拿出来重新做一遍，而是要判断系统里边那些原本希望相互独立的元素，会不会由于同一个原因一块儿失效，或者一个元素出了毛病之后又接着去影响另一个元素。就比方说主功能与监控功能之间、主通道跟冗余通道之间，还有做完ASIL分解之后的两个子元素之间，要是在实际的设计里共用了电源、通信链路、时钟、复位或者软件资源，那就不能简简单单地写上一句“相互独立”就交代过去了。

在功能安全项目快要进入量产或者刚刚量产的阶段，常常会碰到这样一个情况，流程文件里面写得明明很完整，可一旦到了真正要执行的时候，却变成了安全经理自己一个人在不停地催文档、追问题、补证据，所以，要把ISO 26262的安全文化真正落地，靠的并不是喊几句口号，而是要让项目里面的每一个角色，都清楚地知道自己应该去做什么、在什么时间点去做，还有做了以后要留下什么样的记录。

ISO 26262安全计划怎么写，ISO 26262交付物清单怎么整理，写得能用的关键是两条线：一条线把功能安全活动排进项目节奏并写清谁负责谁签字，另一条线把交付物按阶段归档成可检索的证据包。计划与清单对齐后，评审、审核与交付就不再靠临时补材料。

在功能安全开发中，降级策略要怎样去设计，和它配套的那些验证场景又要怎么去覆盖，这两块内容是比较容易被写得发虚的。降级策略不能只是轻飘飘的一句“故障后进入降级模式”，而是要交代清楚故障发生之后，系统用什么办法去限制风险，哪些功能还得继续保留，哪些功能必须完全退出，驾驶员在什么时候应该接手，以及后面靠哪些测试来证明这套办法确实有用。只有把设计、验证和证据这几个环节串在一块儿，降级策略才算真正地落了地。

在进行软件单元测试、集成测试，还有硬件和软件的接口验证，以及安全机制的验证这些阶段的时候，常常会碰到一类工作，那就是ISO 26262里的故障注入，到底要怎么去规划，还有注入之后得到的结果，又该怎样去记录；故障注入这件事情，它的目的并不是要故意去把系统给搞坏，而是要把那些有可能会出现的传感器异常、通信时丢掉了帧、存储上出了错、计算发生了溢出，或者执行的时候超了时这些情况，按照预先做好的计划，一个个地放进测试的环境里面去，然后再去观察，我们的安全机制，是不是按照事先预想好的那样去动作了；如果规划这一块做得太粗糙，测试就会很容易变成一种随手去试错的行为；而要是记录做得乱七八糟，到了后面要去做安全论证、客户评审，还有问题复盘的时候，处理起来都会变得非常麻烦。

在ISO 26262项目里，软硬件接口最容易出问题的，不是“有没有接口文档”，而是接口定义停留在寄存器表和信号表，后面一到集成、验证和变更评估，就发现假设条件、时序约束、故障处理和安全依赖并没有写清。公开资料对HSI的表述很一致，它不是单纯的端口清单，而是用来说明硬件和软件如何交互、软件依赖哪些硬件资源、以及两者之间有哪些安全相关约束的工作产物；而变更追踪也不是简单改版本号，而是要把影响分析、需求链路和验证证据一起更新。

做ISO 26262认证时，供应链配合的难点不在于把文档堆齐，而在于把责任边界、接口假设、变更节奏和证据口径统一起来。你把这些前置规则定清楚，后面供应商交付的每一份报告、每一次测试、每一次版本变更，才能对得上安全目标与ASIL分配，不会在集成阶段反复返工。

做ISO 26262功能安全时，安全分析不是越多越好，而是要选对问题角度与生命周期位置：你要回答的是危险场景怎么来、组件怎么坏、坏了会带来什么、以及怎么被检测与控制。如果一开始选错方法，后面常见的结果是表做得很满但无法支撑安全目标，或能解释风险却落不到设计与验证上。

ISO 26262软件安全需求，它处于技术安全设计与软件开发中间的位置，需要将分配给软件的那些安全职责，转变成能够去实现、测试和追踪的具体要求。这些需求既不能仅仅是“保证安全”“及时处理故障”这种模糊的说法，也不应该太早去限定函数和代码的结构。在编写的时候，需要将触发条件、预期行为、时间限制、异常处理和验证依据都写明白。

在聊ISO 26262的安全状态该怎么定义、切换条件该如何确定之前，有个误区需要先提一下：安全状态并不是故障后把功能关掉那么简单。车辆还在行驶的时候，转向、制动、动力输出这类功能要是忽然退出了，驾驶员不一定能马上适应过来，整车反而可能冒出新的风险。ISO 26262这个标准本来就是面向道路车辆安全相关电子电气系统的功能安全开发，其中2018版的第3部分对应的是概念阶段，里面会牵涉到项目定义、HARA这些东西，安全状态通常也得顺着危害场景往下定。

在功能安全相关的项目里，有一件事的重要性经常被低估，那就是ISO 26262当中工具置信度该怎么去判定，以及为了证明这个置信度，相关的证据又要怎么去准备，很多项目团队，在一开始的时候，注意力往往只放在工具到底能不能用，还有它能不能顺利地导出报告上面，一直要等到客户来评审，或者是安全审核的时候，才会突然意识到，工具本身其实也是需要去说明，它到底有多可信的，工具置信度这件事，并不是简单地给工具贴上一个“可靠”的标签就行了，它是要去证明，这个工具在项目里的使用方式、它失效后会带来的影响、对它进行验证的手段，还有过往已经积累下来的使用经验，这几样东西都是能够讲得通的，在做这个判定的时候，我们不能脱离具体的项目去空谈，也不能把供应商给过来的材料，直接当成了完整的证据来用。

ISO 26262危害分析怎么做，ISO 26262风险等级怎么确定，关键是把危害事件写成可验证的场景组合，再用严重度S、暴露度E、可控性C把ASIL或QM判定落成可复核记录，后续安全目标与安全需求才不会断链。

很多团队做ISO 26262时，前面的概念、系统、硬件和软件开发都抓得很紧，到了车辆退役、拆解、停用和替换阶段，反而容易把管理动作做得很轻。可从标准生命周期看，报废并不是体系外的尾声，而是功能安全闭环里的一段正式活动。ISO 26262明确把生产、运行、服务和报废放在同一部分里管理，整个汽车安全生命周期也覆盖从概念到decommissioning的全过程，所以报废阶段不能只理解成“停止使用”，还要继续考虑残余风险、信息交接和受控退出。