关于功能安全的若干“误解

“真正阻碍我们前行的不是我们不知道的事情，而是那些我们自以为知道却并非如此的事情”------马克吐温
对于一款工业产品来说，如果这款工业品在用户正常使用过程中会威胁用户生命，甚至直接导致用户丧命，或者产生重大财产损失。那么，这款工业品是没有价值可言的。良好的用户体验是建立在安全的前提上的，如果无法保证基本的安全问题，一切的质量与体验都是空中楼阁，水中之月可望而不可及。
回到我们今天的主角“功能安全”，有些事情正向很难理解，但是，反向往往容易很多。在讨论功能安全之前，不妨先讨论一下“功能不安全”.如果你的系统功能不安全会怎么样？（此处的安全指的是Safety与Security）从后果看，功能不安全的后果不仅会导致用户产生巨大财产损失，甚至会导致用户死亡。至于产生功能不安全的原因很多，最常见的三类一般是：内部失效、外部威胁以及意外事件。从后果上很容易看出，功能安全是一门与风险打交道的学科，需要评估危害的严重程度与可能性。达成基本共识后，让我们来看看关于功能安全的一些常见误解。
一 高质量等于高安全
质量和安全作为两个特别容易纠缠在一起的问题，十分容易产生混淆。以软件为例，目前最常见的软件质量保证办法就是流程保证，就是通过一些列严格的流程降低产品缺陷发生率即bug。但是，无论多么严格的流程，都会有bug发生，只是更加严格的流程bug会少一些而已。对于软件缺陷，从安全角度看，有缺陷没问题，只要别要了客户命，或者，给客户造成巨大财产损失就行。而且即便是高质量的软件也不代表它就是安全的，最典型的例子就是1999年美国“火星极地着陆器探测器撞地事件”，由于需求描述的问题，机载软件混淆了着陆腿部署与地面接触颠簸的信号，在40高空提前关闭发动机致使探测器坠毁。质量以控制缺陷为目标，而安全则以控制风险为主要目标，对于高风险事件需要做到“零容忍”。所以安全专家与质量专家一样，是企业发展的重要保证，而且，融合了安全理念的企业流程最显著的特征就是有明确的产品危害识别与风险评估过程及意识。
二、 功能安全只要符合标准就可以了
由于近年来各种安全问题逐渐增多，标准组织不断推出新的标准来平衡行业发展。这些新的标准往往让人看的头晕目眩，而且常常误把要求当指南。以ISO 26262为例，新标2018版总计12份近600页上千条需求涵盖了开发管理、生产售后的诸多方面，而且从半导体到整车几乎都谈了一遍。由于安全是系统属性，加之标准本身以一种自上而下的V型框架来展开，让人很容易有一种错觉“危害分析与风险识别是整车的事情或者最多也就是大的一级供应商的事情”。产品分布式开发的层级越深这种问题越明显，而且，越到底层越容易将质量与安全混为一谈。无论是契约式开发还是商业现货开发，张口就是你的安全需求拿出来。试问没有危害识别，没有风险分析，哪有安全需求可言呢？ISO26262作为一个明显的描述型标准，提供的只是要求并不是指南，而且最重要的一点是，由于开发保证的安全论证观点强调流程，标准极其容易被误用。最明显的误用就是将常规功能需求当成安全需求，然后将所有的标准规定方法论在所有功能开发上强行用一遍，然后就天然的以为自己产品就安全了。这样做不仅增加企业运营成本，而且最重要的是由于缺少必要的危害识别与风险分析，往往造成主次不分，甚至往往最需要关注的危害没有被识别出来，造成开发上的遗漏从而产生系统性失效。所以，做好产品安全的最重要步骤不是先套用标准的要求，而是先做好危害识别，只有真正的危害被识别出来了，后续的一切工作才有意义。
三、预期功能安全、信息安全与功能安全谈的不是一回事
信息安全、预期功能安全和功能安全，每一个新词汇的出现，都在引领时尚同时在不断转移的大家的注意力，由于应用的特殊性，感觉这些词汇说的完全不是一件事。事实并非如此，他们不是孤立的，而是一个整体，只是从不同的视角去看而已。就像是一个圆柱体不同的投影面看可以是方的也可以是圆的，但是究其本质立方体只是一个。上面的这些术语是同样的道理，对于传统深度嵌入式的控制系统，只要控制好失效危害往往都能解决大部分安全问题。但是新技术的引入，汽车需要网联也需要使用高性能计算平台，还需要智能算法，这时我们需要在内部失效安全之外，引入威胁模型和外部触发事件来进一步评估需求落实开发。对于做安全的人最重要的一点就是不要被这些眼花缭乱的术语所误导，需要结合场景识别真正的危害才是最重要的。就像我国禅宗中指月之指的典故一样，一定要看准月亮不要只盯着手指。
对于功能安全的误解还有很多，比如敏捷、瀑布甚至DevOps的冲突，功能安全到底是谁的责任，这些笔者会慢慢在后续文章中继续展开。