好几天没有更新，本期衔接上期，继续阐述功能安全概念阶段相关内容。本期将按照前一篇文章的要求，设定功能安全要求，来减轻/防止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
第七章节的主要目的：
根据其安全目标明确相关项降级的功能行为；
明确适当的约束条件，及时的检测和控制相关的故障；
明确措施来实现容错，目的是减轻驾驶员或外部措施（可减轻危害的其他相关项）的影响；
将功能安全需求分配给系统架构设计或者外部措施；以及验证功能安全概念并且明确安全验证标准；
为符合安全目标，功能安全概念包含安全措施、包含对相关项要素实施的安全机制，以及功能安全需求中已明确的安全机制，见下面Figure3。
什么是安全措施？
为确保我们的架构安全所要遵循的一组活动。我们应该安全概念阶段说明这些措施，这些措施/活动包含安全机制。
什么是安全机制？
一种用达成安全合规水平的技术。有时候措施和机制互换使用。
Figure3: Safety goal allocation on item's elements via allocation of FSRs
在上面的图片中，我们可以注意到，安全目标B和安全目标A具有共同的功能安全要求。
考虑到系统架构，功能安全需求应该从安全目标中导出。每个安全目标至少要导出一条功能安全需求。也就是说，不要把不必要的需求塞进FSC中，并且不要感到愧疚如果你的FSC文件中只有一个FSR来实现安全目标，这样就不会浪费时间了，我们可以继续向前进行。如果适用的话，FSR应明确下面九点策略：
fault avoidance;
faults detection;
transition to a safe state, and if applicable, from a safe state;
fault tolerance;
driver warnings to reduce risk exposure (E) time to an acceptable duration;
driver warnings to increase controllability ( go to lower C)by the driver;
the degradation of the functionality in the presence of a fault and its interaction with 5) or 7);
define fault handling time to meet Fault Tolerant Time Interval (FTTI);
avoidance/ mitigation of a hazardous event due to improper arbitration of multiple control request generated simultaneously by different functions;
战略只是整体的计划，我们还要善于将其分解成具体的战术，从而赢得战争的胜利。也就是说，我们要用FSR来实现我们的战略目的。
各功能安全需求应该考虑以下的5个限制条件来规定（如果适用的话）：
1. Operation Modes;2. FTTI;3. Safe State;4. EOTI;5. Functional Redundant (e.g. Fault Tolerance);上面的陈述是说在适用的情况下，我们可以用上述的5个约束条件中的每一点来规定九点的每一个要求。最后，总结一下：我们讨论了HARA验证和功能安全概念阶段的准备，提供了：相关项定义、HARA报告和没有安全机制的系统架构。之后，我们讨论了功能安全要求的ISO 26262框架：要涵盖那些内容以及应该如何编写/约束。
最后，附上上一篇的原文链接，方便小伙伴们随时查看。
ISO26262 FunctionalSafetyConcept（上）
本期的内容就分享到这里，我们下期再见啦！
如果觉得本篇文章不错的话，请点击右下角“在看”或者“点赞”，让更多的小伙伴儿加入到学习的队伍中来。
