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

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

1、安全需求与设计

2、功能安全与敏捷开发

3、ISO26262理解上的一处探讨

4、一定要接地气

5、工程师学习资料评荐

众所周知，功能安全基于流程驱动，包括需求开发、架构设计、详细设计、实现、集成、测试验证、确认等环节。也就是说，安全需求是功能安全开发的起点。所谓安全需求，说白了，就是带有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标准里的各项要求。但笔者认为，​​《功能安全量产落地的三座大山》​​里面提到的“三座大山”，仍然是需要想办法克服的困难。而且越是可以自由发挥，我们越要战战兢兢，如履薄冰，努力把功能安全量产落地。

笔者曾预言敏捷开发将逐渐成为汽车软件开发的主流方式，也将逐渐成为功能安全软件开发的主流方式。本文就功能安全与敏捷开发的问题进行一些初步探讨，抛砖引玉，以飨读者。

长期以来，敏捷开发方式在互联网行业比较普遍，而在汽车行业基本上很少见到。主要是因为传统的汽车研发周期通常在2年以上，而且需求比较明确，在项目过程中很少变化，不需要快速迭代。

但到了现在，市场环境已经完全不同。产品需要快速交付，硬件需要提前做好预留，而软件则通过OTA不断升级优化，这在电动汽车领域尤为明显。功能安全作为产品的一部分，同样也需要快速交付。传统的“V”模型开发方式，由于太过死板，已经越来越难以适应需要快速交付的市场了。

敏捷开发强调关注用户痛点，拥抱需求变化，通过快速迭代来持续交付软件。精简流程，精简文档，在团队内部通过高效沟通来实现分工与合作。

敏捷开发的核心是迭代开发和增量开发，将一个大任务分解成多次的、渐进的小任务，每轮开发都会发布一个有效版本，每轮开发都会比上一轮增加更多的功能，逐步改进，最终形成完善的产品。敏捷开发的每一轮迭代都是一个完整的软件开发周期，包括需求分析、设计、编码、测试、评估等环节。

敏捷开发的方法很多，国内最流行的应属Scrum，Scrum里的角色分工包括：

在项目的实施过程中，由Product Owner负责维护Backlog（需求池），包括待开发任务列表和任务优先级；在定义好迭代周期（月/旬/周）后，本轮迭代（本次Sprint）需要实现的需求也就基本确定了；接下来由Product Owner和Scrum Master共同完成本轮迭代的需求分解，再组织全员进行讨论（Scrum Meeting），包括需求讨论、技术讨论以及完成任务所需时间讨论，Scrum Master在讨论过程中负责技术决策。

接下来，通过小纸条进行任务分工和开发计划制定，启动软件开发。

通过Story Board（故事板）进行任务管理。项目组每天召开短会（站会），更新任务状态，讨论技术问题和解决方案，评估计划完成情况，并通过Burn Down Chart（燃尽图）可视化的向所有人呈现目前的工作进展。周而复始，本轮迭代周期结束后，开始下一轮迭代。

虽然敏捷开发强调精简文档，但根据实践经验，关键性的技术文档仍然需要制定并维护：

其它相对次要的文档，比如开发计划、详细设计、测试报告等一般不作要求。

由上面的介绍可知，敏捷开发不是消灭流程，而是精简流程；不是消灭文档，而是精简文档。需求仍然是开发的起点，测试也是不可或缺的环节。关键性的技术文档持续维护，省略掉的次要文档通过团队成员面对面沟通来弥补信息传递的缺失。在这些前提之下，基于Scrum的功能安全开发是完全可行的。

需要解决的关键问题点是：如何使得Scrum符合ISO26262标准的要求？笔者认为，主要包括流程和技术两个方面：

某种程度上而言，他就是专门负责功能安全的Product Owner + Scrum Master。如果做不到，起码要做到Product Owner的程度。

从整体框架而言，只要运作得当，Agile and Safe是可能的，这也符合行业发展趋势。当然，敏捷开发主要适用于软件，对于系统开发和硬件开发，不能直接套用。另外，敏捷开发对项目组成员的素质要求很高，比如功能安全工程师，需要懂产品、懂技术、懂功能安全，还必须适应快速迭代、不断变化的项目节奏，随时做出应对和调整，这样才能保证敏捷开发的产品符合功能安全的要求。

ISO 26262标准里的一个很有意思的问题。很多人都认为是标准写错了，但笔者经过仔细思考和分析，最终得出的结论并不是标准有误，而是我们没理解到位。下文针对这个问题展开讨论。

在功能安全软件开发过程中，软件验证是不可或缺的一个环节。ISO 26262标准里将软件验证分为三个阶段：软件单元验证、软件集成验证和软件需求验证，按照“V”流程进行推进：

软件验证的主要方法包括：审查、分析和测试，其中测试是最为常用、也是最为重要的验证方法。

提到测试，就不得不提到测试覆盖率。ISO 26262标准分别在软件单元层级和软件架构层级规定了相应的结构覆盖率指标（要求达到100%）。通常来说，所有“++”、也就是“highly recommended”的项目，都是需要执行的。

细心的人可能已经发现问题了，按理说ASIL等级越高，要求就越严格。所以“++”的数量排序应该是：ASILD >= ASIL C >= ASIL B >= ASIL A。查遍ISO 26262-2018所有的表格，基本上都符合这个规律，唯一的例外就是软件单元层级的结构覆盖率指标，ASIL C要求分支覆盖率，ASIL B反而同时要求语句覆盖率和分支覆盖率。

这是怎么回事？难道标准写错了？查一下ISO 26262-2011，发现这个地方并没有区别：

那就不合理了。从ISO 26262-2011到ISO26262-2018，经历了7年的修订时间，不太可能还留有这么明显的错误。所以，大概率是我们理解有误，而不是标准有误。接下来，让我们一起探讨一下。

二者的关系是：满足分支覆盖要求的测试用例一定能满足语句覆盖要求。

弄清楚语句覆盖率和分支覆盖率的相互关系后，让我们再次对问题进行分析：

也就是说，软件单元层级结构覆盖率指标（ASIL B）的要求是：语句覆盖率要达到100%，同时分支覆盖率要有测试（可以低于100%）。

功能安全并不是什么超越现今人类科技或知识范畴的“黑科技”，那为什么大家会觉得功能安全不接地气呢？笔者思来想去，认为跟ISO26262标准有很大的关系：

我们改变不了标准，但我们可以改变自己：在和项目组成员交流讨论时尽量少用专业术语，而是要用通俗易懂的描述来表达功能安全的要求。基于此，笔者接下来准备用自己的语言来解释几个非常基础但却非常重要的问题。

要回答这个问题，还是要从功能安全的定义说起。ISO 26262对Functional Safety的定义是：“Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems”。确实挺抽象的，下面我们一起来拆解分析。

这个概念里有三个关键点，笔者已经标识出来了：

1、absence of unreasonable risk：也就是降低风险

功能安全方法论可以将unreasonable risk降低至tolerable risk，但是请注意绝对不会是零风险。也就是说，就算严格按照功能安全的要求进行开发，也不能保证彻底消除事故。只能说概率足够低，风险可接受。这个没什么奇怪的，我们都是人，不是神。只有神才能保证绝对的万无一失。

2、malfunctioning behavior：通俗的讲就是故障

由于各种各样的原因，比如需求错误、软件bug、硬件电子元器件损坏、EMC干扰等，故障是无法彻底消除的。当产品出现故障后，很可能引发安全事故，功能安全要研究的就是在这种情况下如何避免人员伤亡。

3、E/E systems：限定了功能安全的适用范围：电子电气系统

对于其它类型的产品故障，是无法用功能安全的方法论来处理的。举个例子：功能安全方法论不能完全覆盖动力电池的安全，因为动力电池系统除了电子电气之外，还有电化学，而且电化学恰好正是最主要的不安全因素。

现在我们可以知道：功能安全针对的是电子电气系统的故障，需要将这些故障造成人员伤亡的风险降低至合理水平（所谓合理水平，是通过ASIL等级来衡量的，详见后文论述）。这就是功能安全要做的事情。

前面我们已经明白了功能安全到底在搞什么，接下来我们讨论一下功能安全到底要怎么搞。

故障是功能安全应对的主题，所以从某种角度来说，功能安全是通过故障管理来降低风险的。故障管理包括：

在产品开发过程中通过安全管理或安全设计尽量避免故障的产生，主要指的是“V”模型左侧的活动，比如安全需求的双向追溯。故障避免就好比通过锻炼、养生来提高体质，降低生病的可能性。不生病的话，自然就不需要治病。

在产品开发过程中通过验证来发现故障、消除故障（在产品量产之前），主要指的是“V”模型右侧的活动，比如测试和评审。故障消除就好比定期体检，在疾病刚刚产生时就进行治疗。

故障诊断可能是大家最为熟悉的内容，因为安全机制绝大部分都是这种类型。故障诊断就好比生病了之后去医院检查，这个时候一般是不能继续正常工作了。

诊断出故障之后我们都要进行故障处理，通常情况下是进入安全状态。但有的时候我们需要带病坚持工作，这就是故障容错。故障容错一般需要有备用的系统才能实现，也就是在故障产生后启用备用系统进行工作。

大家可以回想一下，功能安全标准里要求的各种任务、各项活动，是不是基本上都可以归到上述4种类型当中呢？所以说，功能安全并不神秘，所有的工作都是围绕故障管理这个核心来展开的。

在笔者看来，ASIL是贯穿ISO 26262标准的主线。不管在产品生命周期的哪个阶段，不同的ASIL等级都分别对应着不同的流程/技术要求。究其缘由，是因为ASIL代表安全等级，而安全等级覆盖相应的风险等级。

ASIL最早出现在HARA里，是由S、E、C三个指标打分得到的。也就是说，风险有多大，ASIL等级就有多高，它们是对应的。如果我们严格按照标准执行，将ASIL等级对应的要求落实到位，那么该ASIL等级对应的风险就能被控制住，也就是降低到合理水平。

对功能安全从业人员来说，接地气、说人话非常重要。不要总是满口专业术语，听起来好像很高大上，实际上却会让人敬而远之。试想一下，如果别人都觉得功能安全不接地气，你又怎么在项目里实施呢？高高在上的功能安全是没有生命力的，只有平易近人的功能安全才有可能量产落地。

文章转载自公众号：汽车电子与软件