功能安全量产落地的三座大山（六）
理论与实践（一）
ISO 26262你真的理解了吗
其实严格来说，“理论与实践”应该放到最前面来讲。因为不管是“融合与平衡”，还是“周期与成本”，都会涉及到“理论与实践”的问题，这一点我们在前面的讨论中已经提到过。只不过“理论与实践”的问题没有那么显式，或者说它往往是某些现象背后的根本原因，所以不太容易被察觉到。在遇到一些实际的项目问题后，再来讨论“理论与实践”的问题，可能更容易引起大家的共鸣。
功能安全工程师在项目过程中常常会被问到这样的问题：
这样设计符不符合功能安全？
这个方案有什么问题？为什么不行？
要怎么修改？到底要怎么做？
……
尽管ISO 26262标准比较抽象，但它仍然是实施功能安全所围绕的核心。毕竟我们评价一个产品是否满足功能安全的要求，都是通过其是否符合ISO 26262标准的要求来判定的。换句话说，灵活运用功能安全其实就是灵活运用ISO 26262标准，而灵活运用标准的前提在于深刻理解标准。大家不要小看“理解”这两个字，不同的人对于标准的理解很可能是不一样的，甚至差别很大。下面举几个实例进行说明：
实例1
举个例子，ISO 26262表格里的技术和方法，两个“+”号的一般都是要实施的，这一点应该没有什么异议。那一个“+”号的呢？从标准里的解释来看，一个“+”号对功能安全也是有益的，否则不会“recommend”。
当技术和方法可选时，优先选择两个“+”号，对一个“+”号如何处理没有明说，但显然不会是反对或禁止，肯定是可以考虑使用的。
所以如果存在两个“+”号无法满足的情况时，是不是可以用一个“+”号来替代呢？以下表为例，ASILB的开发目标，如果1i无法满足（对于基于SEOOC模式开发的产品来说有可能是现实存在的情况），我们是直接略过？还是选择用一个“+”号的技术和方法来替代？如果选择的话，又选择哪个？或者只选择一个并不算充分，需要再增加更多？仅从技术层面考虑，在这种情况下补充使用更多的技术和方法（哪怕是一个“+”号），对功能安全肯定是有益的，当然这会涉及到成本。
实例2
所以对于ASIL A和ASIL B来说，诊断潜伏故障的安全机制并不是强制要求，只是建议。
实例3
但是如何理解这个PMHF值呢？如果没有达到上表中的指标要求，我们是不是必须反过头来修改设计呢？我们看看标准里是怎么说的：
看到了吗？首先，表6只是PMHF目标值的来源之一。其次，计算PMHF不是为了必须达到某个值（不管这个值是引用表6还是其它来源），而是为了与既有产品进行比较。
以上这三个例子都是从标准本身的要求来展开分析的，是不是和大家通常的理解或者做法不完全一样呢？大家对标准里明文规定的内容都有不一样的认识，更何况是隐藏在背后的逻辑？下面我们再来看一个例子。
实例4
如下表所示，按理说ASIL等级越高，要求就越严格。所以“++”的数量排序应该是：ASIL D >= ASIL C >=ASIL B >= ASIL A。但这个表里ASIL B有两个“++”，而ASIL C只有一个。这是不是很奇怪？
笔者和一些同行讨论过这个问题，很多人都认为是标准写错了。但笔者经过仔细思考和分析，最终得出的结论并不是标准有误，而是我们没理解到位。这个问题很有意思，有机会和大家单独讨论。
一千个人眼中有一千个哈姆雷特。由于每个人的教育背景、项目经验、知识结构都不完全一样，所以每个人对ISO 26262标准的理解也不完全一样。在学习功能安全时，别人怎么理解并不重要，重要的是你必须形成自己的理解，并且能够逻辑自洽，这才是我们能否做到灵活运用的关键。否则的话，一旦项目情况发生变化，你怎么可能做到灵活处理、随机应变呢？所以在学习功能安全时，一定要多思考、多揣摩，争取做到深刻理解。
What（第一层面）：标准里描述的要求是什么？那些专业名词术语是什么含义？硬件失效率公式怎么计算？……
Why（第二层面）：标准为什么提出这样的要求？背后的原因是什么？这个要求和其它章节的哪些要求是相关的？……
How（第三层面）：怎么做才能满足标准的要求？如果做不到或者做不了，有没有替代方案？如果就是无法满足，有什么影响？……
增加了新功能或原有功能出现调整
采用新的技术方案
使用场景发生变化
……
也就是说，只要出现了新情况、知识库里没有对应的“How”可以模仿，那些未能真正理解“What”和“Why”的人，一下子就会懵逼，不知道该怎么办才好。“How”的精髓，不仅在于如何做才能符合标准要求，更加在于当出现不符合的情况时如何判断：是让步接受？是带条件通过？还是返工重来？没有“What”和“Why”的支撑，“How”是走不到这一步的。
To Be Continued
说明：
* 文章仅代表作者个人观点，不代表'仨人谈起'立场