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

 融合与平衡（二）

平衡的必要性

在功能安全与现有产品融合的过程中，不可避免的会遇到平衡的问题。所以，笔者将融合与平衡放在一起论述。

什么是平衡问题？很多功能安全工程师在项目实施过程中，自始至终的关注点都是安全目标能不能实现、会不会违背，安全性非常重要、甚至高于一切。从功能安全的角度出发，这是理所应当的做法。但是对于整个项目而言，安全性只是产品的属性之一。除了安全性之外，我们耳熟能详的产品属性还包括可用性、可靠性、可维护性、可测试性、可扩展性、可移植性、可重用性……，这些都是产品研发需要考虑的方面。所以，最终的产品设计，一定是各个方面综合考虑、折中平衡的结果。

很多功能安全工程师都有过切身经历，就是在项目组中常常要和别人“吵架”，有的时候甚至要争论很久才能达成一致。这其实就是平衡问题的现实反映：每个人都有自己的立场，每个人都希望自己的观点能够变成最终结论，而其他人能够接受自己的观点，并为之做出让步和妥协。

但现实情况哪可能如此理想？你眼中的人命关天，别人可能根本就不理解、不接受，甚至都不关心。所以，对功能安全工程师来说，沟通能力非常重要。因为你需要不断的说服别人，上到管理层、下到普通员工，都可能是你需要说服的对象。如果你只会特别强硬的坚持自己的观点，最后很可能就是你一个人站在所有人的对立面，结局可想而知。

除了加强沟通之外，我们也可以尝试换位思考一下：为什么会有这么多反对的声音？有没有可能是我们的立场太狭隘、视角太片面呢？有句话叫“不忘初心，方得始终”。我们做功能安全的初衷是什么？是为了降低产品风险，防止人员伤亡。但我们不能忽略一个事实：产品是由企业研发、生产、制造、销售和维护的，产品可能造成人员伤亡的前提是有用户使用该产品。

我们来设想一些极端的例子：

• 一架永不起降的飞机；

• 一列永不出站的火车；

• 一辆永不发动的汽车；

• 一台永不运行的X光机；

• ……

这些设备都非常安全，但是没有用！因为没有人使用它们。于是一个悖论出现了：

当使用该产品的用户很少时，类似的悖论仍然有可能出现：

如果真的遇到了上面这样的情况，你会不会产生自我怀疑？坚持了这么久的功能安全，到底有什么意义和价值？

实际上，功能安全的意义和价值，是通过产品传递给用户的。产品首先需要销售给用户、让用户来使用，然后用户在使用产品的过程中可能会遇到由于电子电气故障引发的风险，这种风险可以通过功能安全来降低至合理水平。使用产品的用户越多，功能安全的意义和价值就越大。

基于此，笔者想再次强调：功能安全永远是也只能是产品的一部分，安全性只是产品的属性之一。所以，功能安全工程师千万不要把自己局限在功能安全里面。实现功能安全没有什么了不起的，这本来就是你的职责所在。如果做不到，只能说明你还不够称职，还需要继续努力。但如果仅仅只是实现了功能安全，你可以称得上合格，但还谈不上优秀。真正牛逼的功能安全工程师，需要更上一层楼，站在产品的角度来看问题，在确保产品安全性的同时，平衡好安全性和产品其它属性的关系。

案例分享

给大家分享一个笔者在实际项目中遇到的案例。系统架构如图所示，MCU通过驱动器控制执行器，并且定时对SBC喂狗。安全目标对应的FTTI为3秒，而MCU复位一次的时间约为500毫秒。将SBC的延时切断设置为2秒，既不违背FTTI，又可以容许MCU多次复位，在保证安全性的同时提高可用性。

实施建议

如何解决平衡问题？笔者认为，首先是要树立全局意识。我们的目标决不是仅仅为产品的Safety负责，我们要为产品的Dependability负责。Dependability包括Reliability、Availability、Maintainability和Safety等RAMS的各个方面。这样慢慢的你就会站在更高的层面来看待功能安全，也就能更好的将功能安全融合到产品当中去。

其次，需要具备灵活运用功能安全原理的能力，知其然并知其所以然，做到收放自如。如果只是生搬硬套、照本宣科，片面强调安全性，那就肯定无法平衡好产品的各个属性。这一点将在“理论与实践”部分再与大家详细讨论。

To Be Continued

说明：

* 文章仅代表作者个人观点，不代表'仨人谈起'立场