功能安全可以理解为一套正向开发方法论，它强调的是正向开发，各个环节环环相扣，各个环节尽量做到可被验证，各个环节尽量做到可被管理、可被追溯，其中“V”模型开发是其中的主体思想。
01 总体理解
功能安全可以理解为一套正向开发方法论，它强调的是正向开发，各个环节环环相扣，各个环节尽量做到可被验证，各个环节尽量做到可被管理、可被追溯，其中“V”模型开发是其中的主体思想。
这样一套思想，一套方法，不仅仅是产品经理需要了解，凡是涉及到产品开发的任何一个工程师都应该了解，并从中汲取营养。所以我想说的是，虽然你不是功能安全经理，但是你依然可以从中获得你想要的知识。
所以在此我特意鸣谢ISO26262标准委员会，你们出的标准，我依然反反复复看且爱不释手。
下面我的语言可能有点不那么正式，希望大家小喷别虐。
02 概念阶段
吹牛，我们是打草稿的
我们要搞事情，但是首先我们要确定我们来搞点啥事情，所以得弄清楚哪些事情不搞，哪些事情我们要搞大搞好搞强。
2.1 相关项定义
用我们专业术语来说，叫Item Definition，用人类更好的语言来说 叫相关项定义。下面，我们有一些具体草稿要打了。
其一，我们的“产品”要有啥功能，比如我们也是一般的车 可以前进、后退，但是还可以“横着走”，这里强调一下，应尽量站在整车角度来定义我们的功能，用我们客户的语言来善待我们的客户；
其二，我们的“产品”在哪些环境下可以使用，比如晴天、雨天、雪天、冰雹天，高温、低温、气压啥的都不在话下，但是不可以“上刀山、下火海”；
其三，我们的“产品”可能和其他“产品”发生了些关系，比如BMS离不开电池，MCU离不开电机，VCU离不开司机操作，这里的关系你可以以这种方式来描述，我离不开你哪些东西，你要我给你哪些东西；
其四，既然我们的“产品”只是“车车”的一部分，并且和其他“产品”还发生了关系，那么我们就要定义好这些关系、这些接口、这些边界条件，省的往后组装不起来，或者产品与产品之间还相互扯皮，所以为了更形象展示，画一个物理架构图，方便大家都理解，呼应下主题--吹牛我们打草稿了。
最后，我们产品都符合功能安全了，那必须得说明，咱做的产品是在全宇宙体制下，合法合规的，咱的产品可以卖到仙女座，卖到猎户座，卖到其他平行宇宙。
2.2 HARA分析
我们知道我们要搞的事情是啥子了，但是我们要把事情搞好啊，所谓要搞好，首先我们要保证用我们产品的人不要挂了，不要受伤了，要用我们“产品”的人活得好好的。所以，在产品设计前，我们提前预想好所有可能让我们上帝（客户）不安全的情况，并且定义好每种情况有多不安全，用我们专业的语言来说，首先定义危害事件，然后从S（严重度）、E（暴露概率）、C（可控性）三个角度来定义危害事件的危害等级，得出一个叫ASIL的得分表，得分越高，表示这个事件危害越高，那么我们针对这类事件就要越重视。
给大家加个鸡腿：加起来=7的就是ASILA 加起来=8的就是ASILB 加起来=9的就是ASILC 加起来=10就是ASILD
HARA分析一般主机厂来做，这个东西目前还是比较有争议的，预想后期可能会有参考出来。
2.3 功能安全目标
HARA分析之后，我们知道哪些情况对我们的“上帝”（客户）不利，因此我们就有一个方向，要着重往哪些方面加强，来提升我们产品的安全性。
2.4 安全需求与安全概念
我们有个伟大的目标，但是目标之所以伟大，而不是空想，是因为我们将其分解为一步一步，直到我们可以真正实现。所以这个目标必须细化为可实现的步骤。
所谓的功能安全概念，就是从安全目标中导出功能安全需求，并且将安全需求分配到系统初始架构的各个单元中去。
所以这里我们有两件事要做，一是安全需求，二是初始安全架构。
有了安全目标和相关项定义，我们可以导出安全需求；
有了安全需求和相关项定义，我们可以初步设计安全架构；
下一步，应把安全需求分配到初步的架构元素中去。
这样一说，似乎有点点空洞啊，我可不能只会吹Bi，所以我打算举起一个栗子（比心）：
咱们的车车都有车门吧，对于车门来说，它具有开门和关门功能（基本功能定义），当车速过高的时候，我们认为不太安全，所以车速大于xxKM/H时，应避免车门打开（安全目标），我们的车门一般有个ECU来控制它，一个ECU一般由传感器 处理器 执行器组成(初始架构)，因为和整车车速有关，因此我们这个ECU的传感器就应获得车速，这个车速信息是其他的ECU通过CAN线传过来的，那么我们就可以这样写两条功能安全需求：
FSR1：那个叫“其他”的ECU应将正确的车速信息发送给“我们的”ECU；（这条不好，可忽略）
FSR2：“我们的”ECU的CAN链路应正确获取车速信息。（CAN链路这个架构元素就被分配了一条安全需求）
又来给大家夹鸡腿了，这里的功能安全需求的验证活动 对应 Item的集成与测试。
03 系统阶段
闭门造神车，我们开始修炼
前面，我们已经把产品的“草稿”打好了，好啦，我们要正式开始修炼了。
3.1 技术安全需求（TSR）
前面我们做过一部分分解工作，比如将安全目标，分解到安全需求和初步架构，要实现那个“伟大的”目标，我们要更加脚踏实地，因此要进一步的细化我们的工作。所谓的技术安全需求，就是要结合实际（不能吹牛了），提炼成一条一条可以实现的需求。为了不至于太飘太空洞，我们延续上面的FSR2来讲一讲TSR应该如何写：
TSR1：“我们的”ECU通过CAN链路获取的车速信号应通过E2E保护确保信号的正确。
发现木有：所谓的TSR就是把具体的方案以及安全机制加入进去了。
3.2 系统架构设计
我们都有TSR了，说明在我们心中，我们有安全机制，也有安全方案了，所谓系统架构设计，就是将我们的需求，方案，安全机制以及功能模块，用框图的方式描述出来。一提到架构，我们第一时间要反映过来的就是接口，对这个框图就是要重点展示各个模块的输入接口，输出接口，同时将我们的接口串起来，就是系统架构了。
虽然鸡腿吃多了长胸，但是这里还得夹两个鸡腿，因为功能安全要求环环相扣，因此这里的TSR的ID要与系统架构的ID对应，确保需求与架构对应，此外模块的接口参数应在架构的接口参数中体现，确保模块与架构对应。
3.3 安全分析与独立性分析
前面我们提到了HARA分析，那是从整车角度分析各种危害，下面我们要根据我们已有的安全目标，来分析我们的产品有哪些情况会危害到安全目标。HARA针对整车，这里的安全分析就是针对我们的系统。
一般有两种方法，一种叫FTA，一种叫FMEA，前者是演绎分析法，是一种从上往下找出违背安全目标的原因，后者是归纳分析，是一种自下往上的分析方法。在功能安全开发过程中，一般利用两者来分析验证架构是否满足安全需求。
独立性分析，其实应该是相关性失效分析，就是大名鼎鼎的 DFA，主要是识别不同的ASIL等级的模块之间是不是有共因，是不是有干扰，比如A失效，将到时B和C同时失效，那么A就是他们的共因，而DFA就是为了识别系统中所有这种共因。
3.4 软硬件接口（HSI）
一个系统是由软件和硬件组成的，一个功能也是需要软硬件的配合才能实现，一般情况下，软件开发和硬件开发不是一拨人，虽然我们是一个Team，但是我们专长不一样，为了让我们这个Team更好的协作，因此我们定义了一个叫HSI的东西，它其实就是软硬件沟通的桥梁。同时硬件别来扯我软件的皮，软件也别扯我们硬件的皮，大家皮肉各自在一起。
HSI咋写呢？小编 我又来举起“栗子”（比心）：
比如我们要获得 某个温度，硬件要干的事情就是 用一个传感器，给其供电，获得一个电压值，通过芯片的ADC采样，转换为一个数字值（0~4096），软件根据这个数字，通过一定的系数（或查表）转换为温度，同时为了提高这个温度值得可信度，还需要做一些诊断监控，比如传感器掉线了，过温等。因此我们要提炼下上面的属性，把这样一个软硬件交互清晰定义下来。
归纳HSI的要点属性就是：硬件PIN脚、对应芯片的引脚、是输入还是输出、模拟量还是数字量、规格参数（系数、偏移、表格标定等）、安全等级要求、详细的需求以及采取的安全机制等。各位看官可以动动手，按照这个属性，把上面的 栗子 写一下。
再次给各位客官奉上 一记 香喷喷的鸡腿：这里的HSI 通过后面的软硬件集成与测试活动来进行验证。
04 硬件阶段
苦其心志，苦练筋骨
系统阶段给我们搭了一个框架，硬件阶段，我们来好好捯饬捯饬这副经骨。
4.1 硬件架构
系统把一部分TSR（技术安全需求）分给硬件来实现，那么我们进一步细化就得到硬件安全需求。硬件安全需求就是将需求落实到具体的硬件功能甚至元器件上。提到架构我们第一时间要想到啥？Yiiiiiiii，莫不是接口吧。所谓的硬件架构，就是将硬件的功能分解为一个一个子功能，然后定义好每个子功能的输入和输出接口，最后串起来就是硬件架构。所以这里最核心的工作就是如何很好的分解一个一个子功能，这，我当然不好给大家举栗子了，希望大家在设计的过程中，把架构设计的秘诀——解耦内聚 牢记于心吧。
继续夹鸡腿：这里的硬件架构的验证 会在后续的硬件集成与测试来进行验证哦！
4.2 硬件详细设计
这里的详细设计就是，将上面一个一个分解的功能，进行原理图级别的设计，更通俗点就是把各个元器件，按照要求给串起来。最近不是老美在打压中国嘛，这种原理图设计工具不知道受不受影响啊，这是题外话。
到了这一步的话，就要SCH、BOM、PCB了，相信搞硬件的贼**熟悉。
哟哟哟，鸡腿飞来了、飞来了、飞来了，这里的详细设计将会对应硬件的单元测试哦。
4.3 安全分析——FMEDA
前面进行了一部分的安全分析，比如系统FMEA、FTA，但是这些分析仅仅是定性分析而已，作为处女座追求完美的我们，造出来的产品，那必须也是可定量评估其好赖的。因为为了准确评估出硬件随机失效，在硬件详细设计后（过程中），就要进行FMEDA。搞几个专业词汇来吓唬吓唬你们，比如ASILC的产品，要求PMHF < 100FIT，SPFM≥97%，LFM≥80%(不懂得小伙伴去查查标准哦，用来测测你爱不爱ISO26262 ...其实是我懒，不解释)。对，没错，FMEDA就是去校验这几个参数，是否满足我们开始预期的ASIL等级要求。
一般要玩这个玩意（FMEDA）还是借助下工具吧，过程的话，就是将你的硬件BOM导入工具，然后一个一个元器件去分析，当然不能凭空分析，一般工具需要你买两个行业标准库，叫SN29500以及IEC62380来获得基础失效率，然后通过计算获得一个汇总的失效。具体计算过程，其实ISO26262 标准的附录里面给了例子，小伙伴有兴趣还是好好去看看那个例子吧（小编我又很懒，不解释）。
05 软件阶段
打通筋骨，造就灵魂
这个名字有点霸气啦，其实主要是为了体现在汽车电子领域，软件工程逐渐变得越来越重要，甚至后续会变得更加重要。所以我称之为咱“产品”的灵魂（发个小广告，别撕我的小卡片，我的其他博客，有对软件更多详细介绍哦）。
5.1 软件架构设计
系统设计完之后，有些TSR就分配给软件了，进一步细化就得到软件安全需求，如何细化？就是把TSR细分到具体的软件元素上去。
架构设计，就是根据分配给软件的需求，分解功能，定义好各个功能的交互接口。软件架构设计，可是大有来头啊，我依然无法一句话两句话说清楚，汽车电子领域其实有一个架构很不错，叫Autosar，这可是一波顶尖的人才搞出来的，值得学习。还是那句秘诀——解耦内聚。哦，别忘了，除了静态架构，记得动态的架构也要哦。
再补两句话，我认为一个好的架构就是，各个模块之间的交互关系很清晰，你知道数据流怎么走，控制流怎么走，你可以一眼看出他们的层次、逻辑、时序关系，你底下的实现兄弟，只要负责实现，系统拼起来就可以正常工作。
飞来了，飞来了，你的鸡腿请接住，这里的架构设计的验证 对应 软件集成与测试 这个子活动。
5.2 软件详细设计
同样的，软件详细设计就是实打实的码代码，或者建模了，其实在汽车电子领域，大家都会认为建模比写代码好，因为建模更简单直观，同时基于MBD开发，测试结果很好统计，同时因为汽车更注重的是安全，而不仅仅是代码的执行效率，我想MBD会是主流吧。
这里的软件单元的验证就是对应 软件单元测试了。
5.3 软件安全分析
虽然软件无法像硬件那样，具体计算一个失效值出来，但是必要的安全分析也不能少，一般我们称之为SWFMEA，即软件FMEA，其实就是把安全相关的组件（软件功能单元）的接口，函数，参数等分析其失效模式，然后按照ISO26262的安全机制的诊断覆盖度参考，确认当前设计的组件是否满足诊断覆盖度要求，若不够则增加安全机制或者预防措施等。
