好几天没有更新，本期衔接上期，继续阐述功能安全概念阶段相关内容。本期将按照前一篇文章的要求，设定功能安全要求，来减轻／防止SbW 电动助力转向系统的危险发生。没看到上一期文章的朋友不要担心，文末有上期的链接。一起来学习吧！

01概述

本篇主要学习如何根据ISO 26262 PART3第七章节来明确我们的功能安全需求（FSR）。本章节的目标是设置一个框架，用于检测和处理相关项的故障，从而确保相关项的安全。也就是说，我们整车在开发阶段没有表现出来的残余故障是对车辆层面造成危害的根本原因。下面的Figure1展示了这些故障如何导致了车辆层面的危险。

Figure1： Propagation of faults on horizontal interfaces； from code to vehicle，horizontal interface include： HSI， components interfaces， vehicle interfaces……

ISO 26262为不同类型故障的产品测量制定了框架：

应对随机硬件失效（Random HW Failure）的技术安全措施：冗余和自检测；

应对系统性的系统、软件和硬件（Systematic Failure）的技术安全措施：通过防御性的编程和设计决策；

然而，在功能安全概念中，我们将只在功能层面上来处理故障的减轻（即如何把危害降低到可接受的程度）。

02概念阶段的验证（Verification）

应验证包含安全目标在内的危害分析和风险评估，从而为以下方面提供证据：

1． 符合相关项的定义：我们的HARA分析是否全面（即包含相关项的所有功能）？是否涉及边界和接口相关的问题？

2． 危害事件覆盖度的完整性：我们的潜在失效模式是不是可以覆盖所有的潜在危害事件呢？

3． 操作场景的正确选取：OEM是否认为所列出的所有场景都是合乎逻辑的，并对该场景清单进行批准？

4． 与其他相关项的相关HARA保持一致性：我们应该知道我们所要做的相关项与外部相关项的接口，从而确保我们选择的其他相关项相互作用的危害与我们的相关项的危害是一致的。

5． 保证安全目标与分配的ASIL 等级和危害事件的一致性：为什么？因为我们的产品是建立在安全目标之上的，如果它没有针对正确的危害，那么我们建立的系统就是错误的。

有时候，我们不清楚所选的操作处境和危险场景之间的影响，这时候，我们不得不要求OEM来模拟我们想要的场景，并且给我们反馈结果，然后将结果添加到验证报告中。因此，上述的5点在HARA验证的结果，应该记录在一份报告中，这个报告就叫做危害分析和风险评估的验证报告（Verification report of the HARA）。

03功能安全概念（FSC）

概念一词是抽象的，它没有分配给任何类型的目标或者是ECU，甚至还没有实现。我们此时仍然是在功能级别上在工作。也就是说，到目前为止，还没有物理系统架构（Physical System Architecture）。为了执行功能安全概念，让我们来准备以下的输入：

SbW的相关项定义；

HARA报告（此处还不是已经验证的版本）；

系统架构设计（来自外部资源，因为我们不能收到其他任何的设计决策的偏见影响，这样我们才容易可以发现设计的缺陷），参见Figure2：

Figure2： Item Definition of the SbW