没有功能，就没有功能安全

在《功能安全量产落地的三座大山》系列文章中，笔者曾提出功能安全必须与现有的产品研发相融合，才有落地的可能。因为大多数企业在导入功能安全之前，基本上都已经有自己的产品或者产品原型了。既然功能安全是后来的，那么就应该主动的融合到现有的产品当中去。这些在之前的文章中已有详细阐述，在此不再赘言。

读完之后，细心的读者可能会有疑问：你说的这种情况确实比较普遍，但如果是从零开始研发一个新产品，在导入功能安全时会不会有区别？实际上，功能安全永远是也只能是产品的一部分，这是由功能安全自身所决定的。只要你按照功能安全的方法论进行开发，就必然要和常规控制（非安全功能）相融合。下面就这一问题与大家交流讨论。

安全需求的层次和由来

众所周知，功能安全基于流程驱动，包括需求开发、架构设计、详细设计、实现、集成、测试验证、确认等环节。也就是说，安全需求是功能安全开发的起点。所谓安全需求，说白了，就是带有ASIL等级的需求。从本质上来说，安全需求反映的是安全功能的行为，而安全功能同样也属于产品功能，只不过因为它是安全相关的，需要按照ISO 26262标准进行研发。抛开ASIL等级不谈，安全功能和其它的产品功能并没有什么区别。

所以，安全需求同样可以进行分解，这也是我们会有各种不同层次安全需求的原因。SG、FSR、TSR、HSR、SSR，这些安全需求分别在相应的层次上约束着后续的设计、实现、验证等活动。抛开ASIL等级不谈，它们和相应层次上的其它产品功能也没有什么区别（这里仅针对功能性质的安全需求，其它非功能性质的安全需求，比如硬件失效率指标等不在此列）。

在所有的安全需求里，SG作为最高层面的安全需求，是所有安全需求的源头，其它的安全需求都是从SG分解、细化而来的。而SG又是通过HARA（Hazard Analysis and Risk Assessment）产生的，HARA的第一步就是场景分析和危害识别，这个危害（Hazard）其实就是Item的malfunctioning behavior。

现在大家明白了吧？功能安全需要基于产品功能（function），分析得到产品故障（malfunction），然后导出安全目标（SG），以此作为最高层面的安全需求来开展后续活动。如果连function都没有，又怎么分析malfunction？没有malfunction，又哪来的functional safety？

下面我们来看一个例子。整车控制器VCU的主要功能包括：

  • 驾驶员操作解析；

  • 扭矩需求解析；

  • 高压上下电管理；

  • 热管理；

  • 充放电管理；

  • 附件控制；

  • ……

通过HARA分析，我们可以得到VCU的主要安全目标包括：

  • 防止车辆非预期加速；

  • 防止车辆非预期减速；

  • 防止非预期起步方向错误；

  • 防止非预期未执行驻车；

  • 防止高压触电；

  • ……

试想一下，如果VCU没有“扭矩需求解析”这个功能，它怎么会有“防止车辆非预期加速”和“防止车辆非预期减速”这样的安全目标呢？所以，先有功能，后有功能安全；没有功能，就没有功能安全。不管是从零开始研发新产品，还是基于现有产品导入功能安全，这个结论都是成立的。因为不管是新产品还是老产品，产品功能肯定都是必须具备的，否则它如何能定义成这个产品呢？

设计需要统一考虑

说完了安全需求，我们再来看一下安全设计。这个其实稍微想一下就能明白，既然安全功能和非安全功能都是产品功能，那么在设计时自然就需要统一考虑。要不然很容易顾此失彼，不停的来回返工。最终的产品设计，一定是各个方面综合考虑、折中平衡的结果。

有关设计需要统一考虑的要求，在ISO 26262标准里甚至有明文规定：

系统设计：

硬件设计：

软件架构设计：

软件详细设计：

一点题外话

在笔者看来，从零开始研发新产品，没有历史包袱，其实是导入功能安全的最佳时机。这种项目没有“改不了”的阻碍，实施功能安全的灵活度比较高，相对更容易贯彻ISO26262标准里的各项要求。但笔者认为，《功能安全量产落地的三座大山》里面提到的“三座大山”，仍然是需要想办法克服的困难。而且越是可以自由发挥，我们越要战战兢兢，如履薄冰，努力把功能安全量产落地。

The End

说明：

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

赞 (0)

相关推荐