取消
小编有个习惯，做一件事之前必须要深刻理解这件事的全部过程和关键输出。对于汽车工程师而言，开发经验可以慢慢积累，但是我们做事情的思路是否清晰很大程度上影响我们的工作质量。
我还记得16年刚入职时，还是一个职场小白，领导交给我一个关于故障响应策略开发的任务。那时候对于Fault reaction strategy的理解是，跟乘客安全有关系，属于系统量产必须的部分。但是这部分工作跟功能安全有什么关系，真是不知道。也是在第二年参加部门组织的培训时，才开始知道ISO26262, 功能安全这些东东。
Fault reaction strategy属于功能安全的技术安全概念的一部分，也会涉及到一部分的功能安全技术需求分配。如果功能安全活动足够完整，从技术安全需求文档里可以整理出来Fault reaction strategy了。哎哟卧槽，想想那会还挺NB, 都不知道功能安全是个啥，都开始独立写技术安全概念文档了(开个玩笑)。现在市面上无人驾驶、ADAS异常火爆，有点资历的功能安全工程师都被重金挖走了。可不是嘛，自动驾驶L3以上，这么多ASIL D的要求，没有个豪华的安全团队都对不起风险投资上亿美金的投入。
像俺们这种做乘用车变速器的小作坊团队，是招不起这些大牛的。但是我一直跟王博说，虽然咱们团队小，资金紧张，但是乘用车开发的要求我们一个也不能省。招不起功能安全工程师，咱们自己学。
万能的淘宝，一百块钱，就能买到一些靠谱的学习资料，主要有分析模板更加不错，真是看的我头晕眼花
但是这么野路子，你怎么知道你理解的是对的，你写的文档是经得起推敲的呢？讲煽情的故事没人愿意听，还是要看功能安全活动是否有高质量的输出，是否产生了真正有竞争力的产品。前同事、球友、同学，但凡有点功能安全经验的大多被我电话、微信“骚扰”了个遍。功能安全上，我还是个小白工程师，从本期开始，会有一系列的学习文章陆续释放出来，非常渴望持续改进，持续进步。
本期用一个案例来讲讲功能安全的故事，如果有大牛阅读到，非常欢迎批评和指导。
功能安全应用范围
功能安全的分析对象针对汽车电子产品，包括软件和硬件部分，机械件是不在分析范围内的。功能安全活动的大部分的工作输出体现在软件和硬件电路的设计开发中。
功能安全标准-ISO26262
功能安全的开发必须要符合标准的，新版的ISO26262总共有9章，涉及到产品的全生命周期。但是对于开发人员而言，第三章~第六章是开发的核心。
举个例子，在第二章的功能安全管理中，对于功能安全活动的确认机制，提了如下的要求。我们可以看出，对于ASIL D等级产品而言，功能安全的评估对团队成员有特殊的要求。这种要求其实蛮主观的，你很难去证明你确实是这么干的，但是可以感觉出ISO26262的制定者们确实在努力用很多手段和方法去提高产品开发的质量。
Case study: Torque safety concept design
第一步：对象定义(Item definition)
对象定义主要干两件事:Structure diagram以及Function list.
假定我们分析的对象纯电动电驱系统(我们分析的是纯电动车驱动系统，不是子部件系统)。
Structure diagram简图如下：
Function list(功能列表)
纯电动电驱系统的功能列表的编写，颗粒度把握是一个重点。在功能安全层面，我们在描述Function list时，关注在整车层面，而不是子系统层面。比如要写VCU functional requirement，可以写上百条，举下面几个例子，从FR01到FR04是非常细节的功能描述。
控制策略开发工程师拿到需求FR01,可以直接开发VCU功能逻辑，如下图所示。
但是功能安全活动时，需求列表里的东西就不需要写那么细。我们能写到的程度，如下表所示：
第二步：危害分析和风险评估(HARA)
HARA主要的工作包括：
1.确定功能失效，也即是:function-->malfunction
2.危害分析，也就是:malfunction-->Hazard
3.确定Hazard event
4.进行Risk anlysis, 确定ASIL等级
5.制定功能安全目标(Safety goal)
6.确定功能安全需求(Functional safety requirements)
1.Function-->Malfunction
功能描述是一段整车层面的定性描述，功能失效并不是一个非0即1的过程，在做HARA分析时，首先要列出功能所有可能的失效形式。
比如某功能需求：产生并传输驱动扭矩到轮端驱动车辆，可能的失效模式列举如下：
2.Malfunction-->Hazard
还是上面的例子，我们基于功能不同失效形式，确定整车层面产生的危害，需要特别注意的是这里的Hazard我们关注在Vehicle level。
3.确定Hazard event
Hazard event的确定顺序是：
我们继续上面的例子，确定Hazard event
4.Risk analysis,确定ASIL等级
危害和对应的运行场景，构成了危害事件，接下来要对危害事件的严重度(S), 场景暴露率(E)和交通参与者的控制能力(C)进行评分，得到每个危害事件的ASIL等级。
在分析严重度(S)，危害产生的后果针对对象是交通参与者，也就是行人、驾驶员或者乘客，而非零部件的损坏。S值的计算，来源于ISO26262的法规，如下表所示。
其中AIS等级来源于汽车事故医学高级协会(Association for the Advancement of Automotive Medicine)。AIS分为7个等级：
在分析场景暴露率(E)的时候，也是对着ISO26262标准来的，但是这里作了不同额区分：使用基于“持续时间”和基于“频率”的暴露率分级。也就是说在计算E值时，要参考2个不同的表格。但是但是，我是实在分不清什么时候参考表B.2,什么时候参考表B.3，知道的同学可以私信我
表B.2 基于运行场景持续时间的暴露概率分解
表B.3 基于运行场景频率的暴露率分级
在分析可控性(C)的时候, 参考表B.4计算C值
在确定了S,E,C三个参数的值后，会计算危害时间的ASIL等级，ASIL等级计算方法比较简单：
S+E+C<7, QM level
S+E+C=7, ASIL A level
S+E+C=8, ASIL B level
S+E+C=9, ASIL C level
S+E+C=10, ASIL D level
5.制定功能安全目标(Safety goal)
Safety goal怎么确定，Safety state是什么样子的，也是非常重要的步骤。不同ASIL等级的Safety goal会有对应的功能安全需求，举个简单的例子：做过电控的人都听说过监控(Monitoring)。ISO2626里面对监控的逻辑也是有不同的要求，低ASIL等级可能只需要做Range check, 更高ASIL等级的监控还要实现合理性校验等逻辑。具体实现方法可以参考ISO2626第5章附录D。功能安全Monitoring的逻辑，我们后面会写专题深入分析，也期待自己可以理解到位。
Safety goal后面还有功能安全需求，技术安全需求以及软硬件分配的技术安全需求文档。每个文档都比较难写，需要对车辆运动、功能软件、硬件电路非常熟悉才可以，刚买了《单片机原理》和《模拟电路》等参考书，靠你们了。本期篇幅有点长，我们下期继续...
