上一篇我们完成了系统部分功能安全开发基本流程的阐述和举例。现在我们终于来到了硬件开发的阶段。老规矩，附上上一章的链接：

https://zhuanlan.zhihu.com/p/249079427zhuanlan.zhihu.com

这一章里面我们要把之前为了满足功能安全的要求而对系统进行分析推导出的硬件技术要求(TSRHW)付诸实现了，即进行详细的电路设计。

总体的任务一览如下表：

5-1 硬件设计

5-1-1 硬件结构设计（基本功能）

在上一篇系统设计阶段的时候，已经做出了系统图，现在要在其基础上进一步细化。注意这时的硬件结构图还没有加入功能安全的组件。

这张图显示了实现电动车电机逆变控制器基本功能应该具备的电子组件，也叫元素（component）， 其中包含连接器接口，电源，反激电源，放电回路，桥预驱动器，桥电路等组件，且包含了MCU内部的模块，如CPU，ROM等。惭愧的是，本人对能量回收那一块不是很熟悉，所以这里暂且不加上，同时也没有加隔离带如光耦把低压和高压分离。从图中可以看到每个组件都加了独一的编号如HW-001，HW-002，方便将来进一步分析。

根据标准的要求，需用文字简要描述主要组件的作用，组件之间的是怎么配合工作以实现功能的，这里略。

5-1-2 系统设计

图还未完善

上图，把电子组件关联起来，构成硬件系统图，并且每个组件和上图模块编号一一对应。

接下来，要把上边提到到电路小模块列出来，即功能的基本概要。

这张表的重点在于“分类” 那一栏，列出的信息和ISO26262（第五部分 附录D)关联，D.xx 指向了为了满足60%、 90%、 99%诊断覆盖率对应的、所需分析的失效模式 ，如下图中 D.7 是对模拟和数字输入输出组件诊断测试技术的指导准则，其它相关联的表作为将来设计者向评审者说明系统达到功能安全标准的依据，这些附录表格在下面章节的FTA分析中的作用非常大，可以说是详细设计基本指南。总之安全设计就是考量各个模块一旦出现了违背安全目标的故障，设计者该如何去设计电路硬件，达到相应的功能安全等级。

如下表D.1 中所示，针对IO口，如果要满足高的覆盖率99%(DC), 应该考虑三个方面失效模式： 1）直流故障模式（固着），2）漂移，和3）振荡.

D. 7表说明了为了能够检出或避免出现以上的三种故障，并且达到相应要求的覆盖率，应该采取的安全机制、措施。

比如对电机电流切断电路，通过MCU IO口输出某个高电平令切断电路激活，如下图所示，可通过主和副CPU进行表决判断是否要切断，然后输出高电平，为确保输出正确，与另外一个IO口进行输入对比，这样就可以满足D.2.6.5的99%高诊断覆盖率（DC)。嗯，请意识到，到目前为止还尚未到加任何对策的时候，因为我们还没有完成FTA等分析。这里所示的只为了说明D.xx该如何使用，为后面的FTA和硬件功能安全要求分析做准备。

5-1-3 构成基本功能的状态定义

考虑这个定义的理由：以后增加功能安全对策时可在不同的时序或状态下插入，比如可以在初始化后插入初期诊断的工作。可以看出这次比我们之前定义的状态迁移图更细化了。状态定义包含了启动和退出的过程，也包含了关键功能（输出转距）的壮态。

5-2 安全要求仕样

5-2-1 安全分析(FTA)

任务：根据技术安全概念中的危害原因以FTA图形式进行分析硬件级别的分析。

在上一篇文章中，我们得到对于功能安全目标SG-001的硬件安全仕样（部分）.

• TSRHW-001：输出正确的电流值（值、正负、时序等）。

• TSRHW-002：将运算后的PWM信号输出至转矩控制器故障检测模块。

• TSRHW-003：输入目标电流值和电流检测值。

• TSRHW-004：确认异常后，向电流切断输出指令

• TSRHW-005：检测转矩扭矩控制器故障检测（HW）的异常。

安全要求仕样分析的工作是给上面的技术要求分配更详细的硬件实施技术方案，简称HSR. 可想象，多条TSRHW 下面有共同的HSR，也可能是多个TSRHW有多个HSR.

FTA分析和我们上一篇文章中方式一样，从有可能违反功能安全目标的故障逐级展开分析，直到具体部件类别，然后把如上表D.1中故障类别作为叶节点，结束某条分枝故障的分析。

现在开始进行SG-01 的FTA 分析：

树中灰色的方框代表不会违背功能安全目标的故障，虽不必进一步分析，但请针对该节点进行不会违背安全目标的进行简单说明。如果大家有看前面的文章，第一层和系统分析结构差不多。接下来要对SG-01-1和SG-01-2 进行分析， 对SG-01-03 的分析怪我偷懒就不列出了。

SG-01-1，控制器是通过CAN总线获取电机所需要的转矩命令的，CAN相关的电路都要分析,此时标准第五部分的附录D派上用场了.

SG-01-1-01 和SG-01-1-02 都是和CAN相关的，可以合并。

可以看到，这些异常都是来自附录上的失效提示，而且满足了99%的覆盖率的，因为我们要满足ASIL D。

当然，我们不仅仅陈列就足够，也要分析一下是否会对功能目标有影响，比如上面的失效，如果略加分析，可以确认硬件上这些失效不会违背功能安全目标，即不会发生顶层所担心场景。

到此SG-01-1 分析完成， 现在分析SG-01-2：

计算部分主要和CPU 相关，大部分的控制皆与其相关，如果计算部件没满足功能安全的要求，功能安全目标是很难达到的。

附录中有MCU内部的D码，比如D.4, D.5 等，大家有空可以去翻一下标准。

以上算是完成了对SG-01 的FTA 分析了，当然还有SG-02, SG-03..... 路比较长，不过有了方法就好办了。 还有就是不一定都对所有功能安全目标分析的（个人经验），比如挑ASIL D和ASILB的两个做个代表就行了，如果这两个已经覆盖了电路上所有的电路模块的话。另外，FTA分析也是个反复迭代的过程，错误和认识不足难免，不断的思考、重审后反复修改完备。

5-2-2 硬件安全要求仕样（规格)

这一节我们为了确定硬件级别的安全措施，要导出解决危害原因的安全要求规范。

5-2-2-1 硬件安全要求仕样

硬件安全要求规范在硬件级别被描述为应对危害原因的对策（HSR-XXX）。但如果需要软件的对策也应该考虑进去（SSR-XXX）。

对象功能安全目标：SG-01 避免无意图的转矩输出。

相关技术安全要求（硬件配置）：TSRHW-001 ，（为了参考，再放上之前的要求）

那么对TSRHW-001的要求如何呢? 为了电机的驱动检测电机电流，为了确保电流正确应：

• 独立检测电机三相的电流，输入到AD三个端口 （HSR-001)

• 软件对同时采样的电流做加法运算，检验三相电流和是否等于0A（SSR-001）。如果不是则异常产生并向安全状态迁移(HSR-002，SSR-002)。

因此可以总结如下：

相关技术安全要求（硬件配置）：TSRHW-002

故障树中这两个要求是和SG-01-03 相关的，功能有PWM 生成，故障检测计算等。那么根据PART5 附录D提示，应该会和CPU，存储等相关。具体的要求比如有：

• 使用具有锁步双核的MCU。（D.2.3.6) (HSR-003)

• 在主CPU部分（含寄存器部分）和检查CPU（含寄存器部分）中都执行目标电流计算，转矩生成和PWM信号生成的计算，并由比较单元依次比较计算结果。 如果比较结果存在差异，则确定算术单元/寄存器（算术单元）出现故障(D.2.3.5)（SSR-003），且从非软件的专用输出端口切断电机流。 (HSR-004，SSR-004)

• 计算单元的错误也可能是时钟错误引起的，因此在当外部晶振发生错误时，引起外部看门狗触发（HSR-101)

• 使用配备了具有EDC（错误校正，检测）功能的ROM / RAM的MCU。(D.2.4.1) ((HSR-005，SSR-005)

如上列表形式，略。

相关技术安全要求（硬件配置）：TSRHW-003

技术要求：

• 将电流检测信号输入到MCU的A / D端口。(HSR-006)

• MCU检测到AD转换器中的错误和多路复用器中的错误 （D. 2. 6. 3 ）(HSR-007)。

如上列表形式，略。

相关技术安全要求（硬件配置）：TSRHW-004

• 在电机线路中提供一个电流切断电路（如继电器电路），以便MCU可以切断电机电流(HSR-008)

• 将电流截止信号从MCU的输出端口输出到电流截止电路，然后迁移到错误状态((HSR-009，SSR-006)。

总结： 按照这样分析完成所有TSRHW的要求。除了以上的技术要求，还有CAN总线相关的，其技术要求包括：完全硬件冗余（D.2.7.3), 比如我们看到Tesla的电机控制器就有双CAN总线的，可以通过两个CAN传输电机转矩命令做冗余和互检（HSR-010)。比如两个转矩命令不一致，那么就可以认为出了某个故障。需要迁移进入某个安全状态。需注意的是，虽然是硬件设计，但是这里面也需考虑软件的安全要求即SSR,所以对设计人员来讲是个挑战，因此软硬件工程师的合作比较重要。

5-2-2-2 加了功能安全对策的模块图 （部分例子，因为只针对SG-01）

通过FTA分析和硬件安全要求细化，我们得出需要增加哪些功能模块来达到我们的安全目标，比如上面的双CAN 冗余， 主副CPU的互琐机制，多路复用IO, 为了紧急停机的电机电流切断电路等等。要知道我们加这些机制或功能都是有理由的，理由来自我们上面的分析结果。

接下来 要进行 《5-3 安全设计》和《5-4 技术要求验证》，但我决定不在这篇里继续了，因为内容也比较多，所以 本篇标题为《功能安全实践-硬件开发阶段（4）上》。