m0_61714886的博客

安全计划是管理和指导开展项目中安全活动的计划，这样是可以系统化的对项目所有的安全活动及进度进行管理。常见的一个误区是，认为项目计划等同于安全计划。项目计划是对项目实施过程中所有的活动进行系统性的规划，其中当然不止功能安全相关事宜。安全计划只是项目计划的一部分。我们也可以将安全计划的内容与项目计划写在同一份文件中，但是要确保安全计划能够明显的识别，也可以将安全计划单独写一份文件，标准中对此有明确的要求。图：项目时间轴。

汽车功能安全关注汽车电子/电气系统功能的正确、完整、可靠的实现，但由于硬件要素物理因素的限制，不同的硬件要素总会出现各种随意硬件失效，这个是由于要素材质、工艺、技术等因素带来的不可消除的影响。当单点故障被安全机制覆盖时，安全机制覆盖到的部分会生成双点故障，它们单独失效都不会导致安全目标的违背，只有当器件与覆盖它失效模式的安全机制同时失效时才会违背安全目标。此时，考虑增加安全机制来防止双点失效的发生，被安全机制覆盖的部分是可探测和和感知的双点故障，安全机制未覆盖到的部分是潜伏的双点故障。

简单来讲就是安全分析和仿真一样属于产品研发阶段做的事前的分析，它可以预测产品的可靠性，判断系统的鲁棒性并且依据当前的薄弱点设计安全措施并制定持续优化的改进过程。在此篇中我们着重介绍系统阶段的安全分析，其他的不在此处赘述（会在其他的文章中体现，DFA可参考我们之前的文章：“功能安全之DFA相关失效分析”，其余的安全分析类的解读文章会陆续更新）在系统阶段的作用是通过SG导出FSR，通过FSR导出TSR，适用于复杂的系统，该方法是可选择的（不一定必须使用），在我们的前期分享的标准解读文章（

通过在设计阶段就充分考虑安全需求，采用分层的安全策略，设计安全关键组件，以及进行严格的安全验证和确认，可以有效地提高系统的安全性。个模块之间少不了有通讯或者系统层级需要有程序的烧录等情况出现，模块可能会通过CAN，CAN-FD，UART，I2C，SPI，PHY等进行片内或片外、板内或板外的通讯或者程序的烧录，下面以串口UART举例说明通讯模块的安全机制都有哪些。综上所述，系统架构设计是我们在产品开发中不可忽视的重要阶段，下面我们着重探讨“系统的架构类型”和“系统架构层级相关的安全机制”。

首先DFA（相关失效分析）的执行与ASIL没有关系，这是与FMEA还有FTA明显的一个区别，其次就是在架构设计过程中若产生了ASIL分解，有要素共存的情况（低等级的要素我们通常会认为他的开发要求不够严谨，可能会对高要求的产品造成不利影响），有冗余设计，功能电路和安全机制等情况时，那么就要执行相关失效分析。：假设我们的架构设计中存在PLL(锁相环，实现外部输入信号与内部震荡信号同步)和对其的监控电路CMC，它们之间的关系就属于功能电路和安全机制的关系，所以我们要分析这两者会不会发生相关失效。

（3）变更对功能安全的潜在影响；在完整的项目生命周期内，变更管理并不是为了拒绝变更，而是通过变更管理来控制变更，使得变更带给项目的影响变得有序可控，因此在项目启动时，建立变更管理制度和相关流程规范，以便指导和规范执行变更的相关人员进行项目变更行为。变更结束前，应当记录变更的相关明细、变更的工作产品清单和变更对象信息，并给出变更的实施时间。变更管理的目的是在整个功能安全生命周期中,分析和控制功能安全相关工作成果、相关项和要素的变更，同时在整个安全生命周期内维护工作成果、相关项和要素的相关功能和特性。

它关注的内容就比较全面和细致，不仅关注产品的开发流程是否符合标准（这里其实也就是Audit的内容，所以标准有提到Audit的内容是可以纳入到Assessment中的），还要关注所有工作成果的合理性，完整性（因为是所有的工作成果，当然也包含CR中的工作成果，所以CR的结果也可以是Assessment的一部分）。注：虽然这三个活动的名称意思比较相近，但是在ISO 26262中是有特指意义的，所以在实际执行的时候是要区分清楚，并且在一些文档的描述上要注意用词的准确性。下图就是标准对于Audit独立性的要求。

上述的PC会对“O”的取值进行优化，降低失效发生的概率，常见的PC措施就比如对设计的评审验证。对于FMEA-MSR的思考逻辑有点类似于ISO 26262中在概念阶段执行HARA（危害分析和风险评估）来确定SG的活动，HARA的三个参数S(严重度),E（暴露概率）,C（可控性），与FMEA-MSR中的S（严重度）,F（运行过程中的发生频率）,M（对失效的发现和处理的可能性或者叫难易程度），大家可以类比着进行理解。而FMEA-MSR(监控及系统响应的补充FMEA)是作为对这两种形式的补充。

在上面我们提到了ASIL分解要将分解后的需求分配到相互独立的要素上，这是一个必须满足的条件，因为ASIL分解本质概念是冗余，冗余就要求组件之间不存在共因失效或者级联失效，那么怎么来证明要素之间互相冗余？这里有必要说明一下，冗余并非是直接使用两个相同的组件互相备份，这种直接复制组件的方式称为同构冗余，同构冗余的两个组件是缺乏要素间的独立性的，因为同样的组件大概率是会存在相同的系统性失效，而系统性失效是我们在开发功能安全产品时是要尽可能避免的，所以一般会采用功能相同，设计存在明显区别的组件进行互相冗余。

例如，HWP（高速路自动驾驶）相关项完成功能时，感知系统（雷达、摄像头）提供道路信息，控制器（SoC、MCU）处理接收到的信息并运算最佳行驶轨迹，执行器实现控制器下达指令完成纵向、横向的整车运行调整。例如：车辆的高速领航功能，由智驾域控（SoC），感知系统（雷达、摄像头等）以及动力系统可以组成一个完整的车辆功能，这个系统组合就是一个相关项。从图中我们可以看出，单一的系统是相关项的最低限度也是要素的最高限度；E0（几乎不可能发生）、E1（低概率）、E2（中等概率）、E3（高概率）、E4（非常高概率）。

硬件设计包括硬件架构设计和硬件详细设计，硬件架构设计表示所有的硬件组件以及他们彼此的相互关系，从安全的角度来看，硬件的设计应该能够满足对硬件的安全要求，这种设计是为了提供功能安全和保障硬件的实际功能，可以确保系统在面对各种故障和异常情况时仍能保持安全状态，因此，设计中就必须要考虑安全机制的存在。确保硬件设计能达到必要的汽车安全完整性等级。硬件可能是基于多个样本迭代开发的，基于在集成和验证阶段的问题发现，对需求分析进行更新，再进行硬件设计的调整和安全分析，在成功集成和测试后完成硬件研发并进行工作成果的发布。

这里首先需要明确的一个概念在于，什么是配置项？配置管理中的受控对象称为配置项，它们是在生命周期中创建的信息，包括程序、数据和文档，分为基线配置项和非基线配置项两类（基线与非基线定义会在后文中进行阐述），并不局限于功能安全体系开发所要求生成的工作成果。通俗来讲，配置管理就是对项目内配置项进行的管理活动。

软件架构设计并不是功能安全独有的要求，对于功能安全软件设计而言，软件架构设计的一个重要的目标是使软件需求的实现过程以一种完整的、正确的同时尽可能简单、可理解和可验证的方式展现，从而在软件详细设计实现过程中，尽可能降低设计错误造成违反功能安全需求的可能性。具体来讲，在功能监控层架构设计过程中，可以根据具体监控的功能，进行相应的异构冗余计算，对其输入，输出，进行范围及合理性检查，异构冗余计算程序执行过程进行时内部或外部要素的时间或逻辑监控，一旦发现错误，通过错误处理机制，将系统导入安全状态。

论据：该组织在实际功能安全生命安全周期中建立了ISO 26262和质量体系的开发流程（体现为质量体系认证证书），整体的安全管理已在组织特有的功能安全开发规则和过程中定义（可体现为功能安全开发流程、功能安全文化手册），对于参与功能安全开发的人员有总结其能力的文件（例如项目成员能力评估表），在开发过程中遇到的异常问题，有对应的异常记录表进行管理。在安全档案编写中，我们已经描述了该产品的大致框架，得到了不同层级分配的安全需求，这时就需要考虑如何证明当前的开发如何实现了安全目标，即图2中提到的安全论证。