到底啥是功能安全 - 5

上回更新到功能安全的"概念"阶段，系统级别的需求被分配到了子系统上并得到了相应的ASIL级别，研发过程中定义子系统的时候通常以功能模块划分，还是用安全气囊系统为例，请注意，当说系统的时候，每个厂商的出发点和理解是不一样的，比如主机厂的系统是整车，而供应商的系统是零部件。所以单纯说系统需求是不负责任的表现。确切的应该加上前置定语。比如安全气囊系统需求。好，如果以安全气囊系统为例，子系统按照功能模块定义的话，例如：

- 碰撞检测系统 + ASILB

- 仲裁系统 + ASIL A

- 通讯系统 + ASIL A

- 执行机构系统 + ASIL B

- 监控系统等。+ ASIL B （纯属虚构）

好了，当到达这一步的时候，可能你已经注意到，从上一篇以安全气囊控制器为系统的系统功能安全需求的某些角度出发，如下图：

我们已经开始分配并且设计这些功能安全需求如何去具体的分配和落实到子系统，上面的这个过程就是"技术安全需求"，Technische Sicherheitskonzepte (TSK)的一部分。也就是下图 3-8 到 4-5 的步骤。

技术安全需求 TSK 会如上图所示，细化功能安全的概念，同时考虑功能性的概念和初步的体系架构。技术安全需求通过对子系统的提具体的功能安全要求，进而实现系统级别的安全技术要求。

TSK规定了以下几个重要的方面：

• 安全机制

• 包括系统或子系统要达到安全目标的影响因素，工作模式和系统定义的状态的失效组合。比如高速120迈挂倒挡的操作会是变速箱进入保护模式（这是机械结构的保护）

• 系统本身的检测，指示和故障控制措施

• 系统达到或维持安全状态的措施，互相冲突的安全机制下优先级和逻辑仲裁

• 细化和实现警告和降级概念的措施

• 防止故障被隐藏的措施

• 安全状态的切换，容错的时间间隔，应急操作的时间间隔和维持安全状态的措施。

• ASIL 的分解

• 潜在故障的避免 （依赖于良好的工程实践和经验）

• 产品，运行，维护和结束等

TSK对系统的设计，需要考虑软件硬件的技术实现性，和整体可验证性，在这个步骤的时候要做相应的系统设计分析。

Deductive 是因果分析，inductive 是预测分析。表格中有具体分析的方法，感兴趣的朋友可以去了解，举个浅显的例子，就是要分析，假如轮胎破了，汽车会不会抛锚和汽车如果抛锚了，有没有可能是轮胎被扎了的区别。

做这些分析的终极目标，是为了实现一个高质量的系统设计，而模块化的系统设计是业界最常使用的办法。这也是本文开头说，

研发过程中定义子系统的时候通常以功能模块划分

欢乐马，公众号：汽车嵌入式到底啥是功能安全 -4

终于我们成功的回到了本文的开头。首尾呼应，终于让我自圆其说了。

对于模块化的系统设计，请参照下面的要求：

TSK的技术安全要求在接下来要分配到硬件和软件部分，如何分配取决于系统架构师的工作年限和年薪，不过在这个时候，会有一个细化工作，就是大名鼎鼎的 HSI （Hardware Software Interface）。

HSI规定的是软件和硬件的交互，应至少包含以下方面：

• 硬件设备的工作模式和配置参数

• 硬件资源的分配，包括IO，中断，计时器，RAM，ROM

• 硬件设备之间的通讯协议，主从关系

• 硬件和软件关于诊断功能的交互等

有经验的系统架构师会把功能安全需求合理的分配到硬件和软件上，两者相辅相成，共同实现功能安全目标。不仅节约人力资源，还可以在测试阶段如鱼得水。没有经验的系统架构师，会打电话给半导体供应商，问他们要相关明星产品的application notes，然后选择覆盖功能安全需求最多的设计方案。不过请注意，一般半导体厂商的芯片都是 „Safety Elements out of Context“ (SEooC)， 不过很多企业直接拿来就用了。 总而言之，如果你不会设计，就把最难的，最复杂的功能安全需求用硬件实现。剩下的交给软件系统架构师吧。

这篇是技术安全需求 "TSK" 和相应的系统设计介绍，下一篇会从系统需求分配到软件领域开始，具体看看要实现功能安全ISO26262，对软件研发工作的要求。