功能安全量产落地的三座大山（六）

ISO 26262你真的理解了吗

其实严格来说，“理论与实践”应该放到最前面来讲。因为不管是“融合与平衡”，还是“周期与成本”，都会涉及到“理论与实践”的问题，这一点我们在前面的讨论中已经提到过。只不过“理论与实践”的问题没有那么显式，或者说它往往是某些现象背后的根本原因，所以不太容易被察觉到。在遇到一些实际的项目问题后，再来讨论“理论与实践”的问题，可能更容易引起大家的共鸣。

功能安全工程师在项目过程中常常会被问到这样的问题：

• 这样设计符不符合功能安全？
• 这个方案有什么问题？为什么不行？
• 要怎么修改？到底要怎么做？
• ……

很多时候大家都会回答“ISO 26262标准就是这么要求的”。这种回答没有错，但如果你只会这么回答，那么很可能你的项目会以失败而告终。言必谈标准，说明你只会教条主义、生搬硬套。试问有哪个项目是100%符合标准的呢？遇到那些不符合的部分，又该如何处理？

ISO26262标准在Scope里面说自己是一个框架，同时包含了流程和技术两方面的内容。既然是框架，那么当它落实到某个具体产品、具体项目时，肯定是有灵活性的。也就是说，标准是一样的，但执行起来会有不同。同样的要求可以有不同的解决方案，而且不同的解决方案之间往往也不存在谁对谁错，有的只是谁更合理、谁更合适。只有达到灵活运用的水平，才能从容面对各种不同的项目场景，功能安全才能落地，这也是功能安全的精髓——方法论的价值所在。

尽管ISO 26262标准比较抽象，但它仍然是实施功能安全所围绕的核心。毕竟我们评价一个产品是否满足功能安全的要求，都是通过其是否符合ISO 26262标准的要求来判定的。换句话说，灵活运用功能安全其实就是灵活运用ISO 26262标准，而灵活运用标准的前提在于深刻理解标准。大家不要小看“理解”这两个字，不同的人对于标准的理解很可能是不一样的，甚至差别很大。下面举几个实例进行说明：

实例1

举个例子，ISO 26262表格里的技术和方法，两个“+”号的一般都是要实施的，这一点应该没有什么异议。那一个“+”号的呢？从标准里的解释来看，一个“+”号对功能安全也是有益的，否则不会“recommend”。

当技术和方法可选时，优先选择两个“+”号，对一个“+”号如何处理没有明说，但显然不会是反对或禁止，肯定是可以考虑使用的。

所以如果存在两个“+”号无法满足的情况时，是不是可以用一个“+”号来替代呢？以下表为例，ASILB的开发目标，如果1i无法满足（对于基于SEOOC模式开发的产品来说有可能是现实存在的情况），我们是直接略过？还是选择用一个“+”号的技术和方法来替代？如果选择的话，又选择哪个？或者只选择一个并不算充分，需要再增加更多？仅从技术层面考虑，在这种情况下补充使用更多的技术和方法（哪怕是一个“+”号），对功能安全肯定是有益的，当然这会涉及到成本。

实例2

再举个例子，如果某个ASIL对应的要求是在括号（）里，那么其实它只是一个建议，而不是要求。

所以对于ASIL A和ASIL B来说，诊断潜伏故障的安全机制并不是强制要求，只是建议。

同样，对于ASIL B来说，计算SPFM、LFM也不是强制要求，只是建议。

实例3

再举个例子，PMHF大家应该都比较熟悉了。不同ASIL等级的安全目标，对应的PMHF值有不同的要求。

但是如何理解这个PMHF值呢？如果没有达到上表中的指标要求，我们是不是必须反过头来修改设计呢？我们看看标准里是怎么说的：

看到了吗？首先，表6只是PMHF目标值的来源之一。其次，计算PMHF不是为了必须达到某个值（不管这个值是引用表6还是其它来源），而是为了与既有产品进行比较。

以上这三个例子都是从标准本身的要求来展开分析的，是不是和大家通常的理解或者做法不完全一样呢？大家对标准里明文规定的内容都有不一样的认识，更何况是隐藏在背后的逻辑？下面我们再来看一个例子。

实例4

如下表所示，按理说ASIL等级越高，要求就越严格。所以“++”的数量排序应该是：ASIL D >= ASIL C >=ASIL B >= ASIL A。但这个表里ASIL B有两个“++”，而ASIL C只有一个。这是不是很奇怪？

笔者和一些同行讨论过这个问题，很多人都认为是标准写错了。但笔者经过仔细思考和分析，最终得出的结论并不是标准有误，而是我们没理解到位。这个问题很有意思，有机会和大家单独讨论。

一千个人眼中有一千个哈姆雷特。由于每个人的教育背景、项目经验、知识结构都不完全一样，所以每个人对ISO 26262标准的理解也不完全一样。在学习功能安全时，别人怎么理解并不重要，重要的是你必须形成自己的理解，并且能够逻辑自洽，这才是我们能否做到灵活运用的关键。否则的话，一旦项目情况发生变化，你怎么可能做到灵活处理、随机应变呢？所以在学习功能安全时，一定要多思考、多揣摩，争取做到深刻理解。

笔者认为，对ISO 26262标准的理解可以分为由浅入深的三个层面：

• What（第一层面）：标准里描述的要求是什么？那些专业名词术语是什么含义？硬件失效率公式怎么计算？……
• Why（第二层面）：标准为什么提出这样的要求？背后的原因是什么？这个要求和其它章节的哪些要求是相关的？……
• How（第三层面）：怎么做才能满足标准的要求？如果做不到或者做不了，有没有替代方案？如果就是无法满足，有什么影响？……

很多人追求“短平快”，上来就想学会 “How”，然后直接上手。这种心情可以体谅，但如果不能真正理解“What”和“Why”，又怎么可能真正理解“How”呢？一味追求“How”的人，做项目只能是生搬硬套，照猫画虎。一旦出现以下情况：

• 增加了新功能或原有功能出现调整
• 采用新的技术方案
• 使用场景发生变化
• ……

也就是说，只要出现了新情况、知识库里没有对应的“How”可以模仿，那些未能真正理解“What”和“Why”的人，一下子就会懵逼，不知道该怎么办才好。“How”的精髓，不仅在于如何做才能符合标准要求，更加在于当出现不符合的情况时如何判断：是让步接受？是带条件通过？还是返工重来？没有“What”和“Why”的支撑，“How”是走不到这一步的。

文章转载自公众号：仨人谈起