在某些行业比如轨道交通、过程工业等，安全防护设备（如SIS）和常规控制设备（如DCS）常常是分开的。也就是说，它们在物理上是独立的实体。从系统自顶向下分解而来的安全功能，基本上都由安全防护设备来承担，而安全防护设备基本上也只承担安全功能。功能安全只针对安全防护设备，以及安全防护设备和常规控制设备的系统集成。这样的系统架构泾渭分明，非常清晰，也比较容易理解。
然而在汽车行业就不一样了，安全功能和非安全功能常常是由同一个设备来承担的。不管是为了降低产品成本，还是为了节省布置空间，除了个别情况下使用ASIL分解来隔离安全功能和非安全功能外，总体上而言，我们面临的项目基本上都是需要ASIL和QM混合开发的，ASIL的内容只是项目的一部分。所以，功能安全永远是也只能是产品的一部分。笔者认为，这是汽车功能安全从业人员首先需要端正的态度和认识。
由于ISO26262标准自身非常完备，功能安全工程师很容易产生一种错觉：我已经有了葵花宝典，还要紫霞神功干啥？这种观点其实大错特错。首先，你误解了ISO 26262标准的真正含义，这一点后文会讲到。其次，你有没有想过：在目前没有国家/政府/行业强制要求的情况下，产品研发可以不导入功能安全。但反过来却完全不同，要导入功能安全必须依托产品研发。也就是说，功能安全必须与现有的产品研发融合，才有落地的可能。其中包括：
这里笔者想着重强调一下“现有”，是因为大多数企业在导入功能安全之前，基本上都已经有自己的产品或者产品原型了。甚至说该产品是可以投放市场的，只不过没有按照功能安全标准的要求进行研发而已。也就是说，先有常规控制，后有功能安全，这是汽车功能安全项目面临的普遍情况。既然功能安全是后来的，那么就应该主动的融合到现有的产品当中去。导入功能安全不是为了推翻和颠覆，而是为了继承和发扬，在与现有产品融合的过程中对其施行必要的改进和优化，这样才能以最少的成本将功能安全落地。给大家分享一个笔者在实际项目中遇到的案例。如图所示，信号传输路径为：传感器-->采集板-->主控板-->执行器。对于传感器的电路故障（开路、短路）诊断，
一般放在采集板实施，这个通常没有异议。但对于传感器的合理性故障诊断，可以放在采集板，也可以放在主控板，这两种方式都不违背功能安全的原则。到底哪种方式更合理，其实很大程度上取决于现有产品的设计。也就是说，在导入功能安全之前，主控板和采集板的分工是什么？采集板有没有协助主控板进行算法处理，还是单纯的采集和传输？采集板有没有开发软件标定功能？主控板和采集板之间的通信带宽是否允许传输更多的原始数据，还是只能增加一些故障信息？主控板和采集板的硬件余量（RAM空间、ROM空间、CPU负载率等）分别还有多大？……这些都是需要考虑的因素。笔者最后综合考虑各方面因素，选择了在主控板完成对传感器的合理性故障诊断。既然与现有产品融合如此重要，那么到底应该怎么做呢？ISO 26262标准里其实提供了一个解决方案：从现有产品研发中获得输入。下面是几个例子：
以上这些内容可能平日里大家关注没那么多，但事实上ISO 26262标准隐含的要求就是功能安全要与现有产品相融合。这个思路本身挺好，但在项目实际过程中，常常会遇到另一个现实问题：现有产品文档严重缺失，无法提供关键有效的输入。稍微夸张一点说，它就是一个黑盒。这种情况下，就算功能安全想要主动去融合，实际操作起来也有很大的困难。所以，现有产品研发流程体系越完善，功能安全越容易落地。一般来说，如果CMMI或者A-SPICE达到Level 3，可以认为产品研发流程体系比较完善。
遇到上面这种情况怎么办？其实也没有更好的办法，只能是功能安全工程师投入更多的时间、精力，通过调查、访谈、甚至是逆向工程等方法，将缺失的信息补上。毕竟，与现有产品实现融合并不意味着功能安全就能量产落地，这只是需要解决的问题之一。但是，放弃与现有产品的融合就意味着功能安全的导入必然以失败而告终，这一点毋庸置疑。
说明：
* 文章仅代表作者个人观点，不代表'仨人谈起'立场
