《功能安全量产落地的三座大山》番外篇.docVIP

《功能安全量产落地的三座大山》番外篇 1 安全需求与设计 1.1 安全需求的层次和由来 众所周知，功能安全基于流程驱动，包括需求开发、架构设计、详细设计、实现、集成、测试验证、确认等环节。也就是说，安全需求是功能安全开发的起点。所谓安全需求，说白了，就是带有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没有“扭矩需求解析”这个功能，它怎么会有“防止车辆非预期加速”和“防止车辆非预期减速”这样的安全目标呢？所以，先有功能，后有功能安全；没有功能，就没有功能安全。不管是从零开始研发新产品，还是基于现有产品导入功能安全，这个结论都是成立的。因为不管是新产品还是老产品，产品功能肯定都是必须具备的，否则它如何能定义成这个产品呢？ 1.2 设计需要统一考虑 说完了安全需求，我们再来看一下安全设计。这个其实稍微想一下就能明白，既然安全功能和非安全功能都是产品功能，那么在设计时自然就需要统一考虑。要不然很容易顾此失彼，不停的来回返工。最终的产品设计，一定是各个方面综合考虑、折中平衡的结果。 有关设计需要统一考虑的要求，在ISO 26262标准里甚至有明文规定： 系统设计： 硬件设计： 软件架构设计： 软件详细设计： 在笔者看来，从零开始研发新产品，没有历史包袱，其实是导入功能安全的最佳时机。这种项目没有“改不了”的阻碍，实施功能安全的灵活度比较高，相对更容易贯彻ISO26262标准里的各项要求。但笔者认为，《功能安全量产落地的三座大山》里面提到的“三座大山”，仍然是需要想办法克服的困难。而且越是可以自由发挥，我们越要战战兢兢，如履薄冰，努力把功能安全量产落地。 2 功能安全与敏捷开发 笔者曾预言敏捷开发将逐渐成为汽车软件开发的主流方式，也将逐渐成为功能安全软件开发的主流方式。本文就功能安全与敏捷开发的问题进行一些初步探讨，抛砖引玉，以飨读者。 长期以来，敏捷开发方式在互联网行业比较普遍，而在汽车行业基本上很少见到。主要是因为传统的汽车研发周期通常在2年以上，而且需求比较明确，在项目过程中很少变化，不需要快速迭代。 但到了现在，市场环境已经完全不同。产品需要快速交付，硬件需要提前做好预留，而软件则通过OTA不断升级优化，这在电动汽车领域尤为明显。功能安全作为产品的一部分，同样也需要快速交付。传统的“V”模型开发方式，由于太过死板，已经越来越难以适应需要快速交付的市场了。 2.1 敏捷开发简介 敏捷开发强调关注用户痛点，拥抱需求变化，通过快速迭代来持续交付软件。精简流程，精简文档，在团队内部通过高效沟通来实现分工与合作。 敏捷开发的核心是迭代开发和增量开发，将一个大任务分解成多次的、渐进的小任务，每轮开发都会发布一个有效版本，每轮开发都会比上一轮增加更多的功能，逐步改进，最终形成完善的产品。敏捷开发的每一轮迭代都是一个完整的软件开发周期，包括需求分析、设计、编码、测试、评估等环节。 2.2 Scrum简介 敏捷开发的方法很多，国内最流行的应属Scrum，