第七章节的主要目的：
根据其安全目标明确相关项降级的功能行为；
明确适当的约束条件，及时的检测和控制相关的故障；
明确措施来实现容错，目的是减轻驾驶员或外部措施（可减轻危害的其他相关项）的影响；
将功能安全需求分配给系统架构设计或者外部措施；以及验证功能安全概念并且明确安全验证标准；
为符合安全目标，功能安全概念包含安全措施、包含对相关项要素实施的安全机制，以及功能安全需求中已明确的安全机制，见下面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框架：要涵盖那些内容以及应该如何编写／约束。
本期的内容就分享到这里，我们下期再见啦！
