- 汽车安全完整性等级（ASIL）表达了与系统功能相关的关键性
- 它定义了系统设计和开发必须满足的安全要求，即使在故障情况下，系统也能为用户（驾驶员，乘客，道路交通参与者等）提供足够的安全保障。
- ASIL不是为物理系统组件计算的，而是为功能计算的
- 与功能相关的ASIL由实现该功能的软件和硬件元素继承
- 一个硬件组件或软件组件可能会实现多个不同ASILs的功能(如单片机)
- 与硬件或软件组件相关联的ASIL从运行在其上的ASIL最高功能继承而来
- 在某些情况下，ASIL可以通过ASIL分解（ASIL Decomposition）技术降低
- IEC 61508中已经存在这一概念
- 它并不是全新的！
- 这可能是有利的
- 例如，在生产成本方面 - 通常根据较低的ASIL开发成本较低（劳动力，时间，工具
- 但是必须遵守严格的基本概念和规则
- 实现用于解决给定安全目标的具有给定的ASIL的元素，可以被分解为可能具有较低的ASIL两个独立元素
- 每个人必须解决相同的安全目标
- 每个人必须采取相同的安全状态
- ASIL分解可用于以下阶段
- 功能安全概念
- 系统设计
- 硬件设计
- 软件设计
- ASIL分解是一个定性概念，更多地解决系统问题（架构）而不是随机错误（硬件可靠性）
- 它可以使架构更加健壮
- 类似于61508容错架构概念
- ASIL分解是引入冗余的一种方式吗？
- yes and no
- 请记住（一般情况下）汽车系统实际上只有很少的冗余
- 只有一个气泵，只有一个电池，......
- 成本！这被广泛接受
- ASIL分解引入了功能冗余
- 两个独立的架构元素朝着相同（冗余）的安全目标努力
- 这些独立的架构元素几乎总是多样化的
- 通过架构设计元素实现异构冗余
- 这不是我们通常在61508中考虑的同构硬件冗余
- 考虑一个功能F，当从传感器S1，S2，...的组合输入时，Sn向执行器M（“电机”）发出激活命令
- 假设F的安全状态为“M停用”
- 假设危险和风险分析已确定功能F的ASIL D.
- 假设我们已经确定了以下安全目标：“避免不期望的M激活”
- 因此“不期望的”意味着“由于传感器S1，S2，...... Sn的错误组合”
- 进一步假设传感器S1，S2，...... Sn测量一些不同的值
- 也就是说，传感器彼此独立且非冗余
- 此外，在这种情况下，我们假设这些传感器中的每一个，如果有故障，本身可能导致要违反的安全目标
- 标准的ASIL理论说因此每个传感器还必须继承分配给功能F的ASIL D.
- 此时，我们开始分析我们的架构，推断实际架构中哪些元素具有违反安全目标的能力
- 这可能会利用所涉及技术的特定知识
- 在这个例子中，我们从理论上知道控制无刷三相直流电动机，三相需要及时精确定义的信号
- 因此有些部件（例如，驱动器及其相关的命令通道）在发生故障的情况下，不可能产生错误激活M所需的精确信号
- 因此它们本身无法违反安全目标
【注】：注意ASIL只分析故障情况，安全目标是出现故障后需要马达立刻停机。如果马达或马达驱动器本身是有故障的，那马达就不会运行，也就是本身就是安全的。这很好理解，如果一个车开不起来，那当然是安全的。如果开起来后，遇到紧急问题，我们需要马达停机，但因为控制器的故障而不能停机这才叫不安全。
通过这种分析，我们有理由将驱动器，电机和命令通道的ASIL降低到QM
- 请注意，这完全取决于技术;如果电机是基于连续技术，那么就不可能将ASIL降低到QM
- 我们现在通过利用危害和风险（H＆R）分析的结果来寻找改进安全架构的方法
- 在当前形式中，架构仅考虑“错误的传感器输入”，无论操作场景如何
- 但假设 H＆R分析区分了操作场景，例如车辆的速度？（这是典型的）
- 假设H＆R分析产生的结果是，M的不期望的激活仅在大于某个阈值的速度下是危险的？
- （作为另一个例子，考虑不期望的安全气囊展开 - 其效果取决于车辆的速度）
- 其他典型的操作场景示例可能是“驾驶员侧车门打开”或“发动机温度大于某个阈值”
- H＆R分析的结果产生了我们可以利用的信息，以便在我们的架构中引入安全机制
- 我们现在引入一种安全机制：“当车速大于指定的阈值时，不得激活功能M”
- 这有效地引入了一种“与”门，以降低M被错误激活的可能性
- 不期望的M激活只发生在：如果功能F失效，且v>阈值.
- 请注意，我们现在实际上已经改变了架构
- 我们引入了新的传感器V
- 我们已经引入了新的软件
- 但是我们改变了ASIL分配吗？
- 答案是“否”
- 仅仅添加安全机制本身并不会改变ASIL分配
我们发现系统软件的ASIL D太高，但我们不希望在控制逻辑中引入硬件冗余。因此我们决定在软件级别应用ASIL分解
- 答：只有满足独立性标准，才能接受建议的软件级ASIL分解
- 这不仅包括检查软件，还包括硬件
- 此外：硬件度量如何？它们会成为ASIL QM还是ASIL D？或者基于百分比的某种组合？
- 答案：硬件指标不受影响，所以它们仍然是ASIL D！
- 有几个问题
- 如何与底层操作系统共享软件资源？
- 共享固件？
- 如何共享内存，ALU等硬件资源？
- 我们对软件级分解的分析表明存在太多问题，我们决定进行硬件级分解
- 硬件方面的安全元素究竟是什么？
- 这不一定是一个完整的微处理器
- 它可能是一个可编程的门阵列，基本上只是一个状态机，只编程一次，没有操作系统 - 它们的成本仅为整个微处理器的十分之一，并且非常 可靠，具有自己的时钟和电源，易于管理
- 没有嵌入式逻辑 - 因此没有软件
- 这对26262安全过程产生影响
- 您不再需要第6部分，只需要第5部分 （注：ISO26262第5部分介绍硬件，第六部分介绍软件）
- 这就是为什么它只被称为安全元件
- 它取决于要执行的安全功能
经验教训：硬件级别ASIL分解涉及对可用硬件特性的深入了解，因此可以正确平衡独立性，功能性和成本。
- 当我们有许多可以限制在微观上的非关键功能，以及有限数量的安全关键功能共享相同的安全状态（驱动器停用）时，我们刚刚介绍的硬件级别分解可能是有利的。
- 在两个元素上分解原始ASIL（D）还有哪些其他可能性？
- 两种可能性：
- 1.ASIL B（分配给μP）+ ASIL B（分配给安全元件）
- 2.ASIL C（分配给μP）+ ASIL A（分配给安全元件）
第一个替代分解表现为具有两个基本上等效的具有冗余功能的处理器
- 但它已经是硬件方面的昂贵解决方案（处理器比例如简单的传感器昂贵得多）
- 此外，软件必须使用“多样性”技术开发，也被认为是非常昂贵的
- 最后的替代方案再次代表了非对称布局
- 分配给主微处理器的软件实现了控制器的整体功能
- 安全元件简单，廉价且可靠
- 为什么不反过来？为什么没有处理器ASIL A和安全元件ASIL C - 这通常是直观的选择吗？
- 因为在某些情况下，安全元件可能是以前设计中的遗留元素，并且在此特定项目中使用了它
- 可能过于简单，无法处理更复杂的安全功能
- 10.ASIL仅处理硬件开发
- ASIL对硬件，软件和支持流程产生影响
- 9.可以将硬件元素设计为ASIL X用于任何系统
- 硬件元件可以设计为满足ASIL X安全性在给定系统中的要求
- 8.ASIL分解是硬件冗余的一种形式
- yes and no：ASIL分解意味着功能冗余，但也具有多样性，独立性和免受干扰
- 7.ASIL分解用于降低HW度量目标
- 不！在ASIL分解之后，初始安全目标（分解前）的相同目标适用于分解的HW / SW元素
- 6.ASIL分解主要是关于随机故障
- 对于IEC61508是正确的，但不适用于ISO 26262。它更多的是处理系统问题（例如架构）
- 5.26262标准要求ASIL分解
- 实际上，它不是必需的步骤。可以将其视为在SW分区到HW元件期间分配具有不同安全关键性的均匀功能的机会。
- 4.软件级别ASIL分解比硬件级别分解更简单，更便宜
- 实际上，由于对多样性和独立性的严格要求，软件级别分解通常比硬件级别分解更困难且更昂贵
- 3.ASIL分解是唯一的方法 降低元素的ASIL
- 实际上，有时可以通过对所涉及的技术和体系结构进行知情和仔细分析来直接降低元素的ASIL。许多人仍然没有意识到这一点。(比如例子中马达定级为QM)
- 2.ASIL分解总是可行的
- 实际上，使用有许多不同的ASILS等级实现的多个功能（如在现代微控制器中）可能使得在某些情况下实现ASIL分解基本上是不可能的。
- 1.ASIL分解始终是可取的
- 实际上，总是存在成本 - 收益权衡，并且经过仔细分析后，ASIL分解通常会表现为不需要的。
- ASIL分解可以降低系统元素（硬件和软件）所需的ASIL
- 它需要采取架构决策
- 它们可能会影响硬件，软件或两者兼而有之
- 有时这些决策极难评估
- 有时候问题表现出独立性，并且需要做太多工作才能证明成本合理
- 有许多因素需要考虑！
故障树分析是一种自顶向下的演绎推理分析方法，是用来分析故障的，而不是需求。
故障树分析（FTA）是当今概率风险评估(PRA)和系统可靠性评估中使用的最重要的逻辑和概率技术之一。
在20世纪60年代早期进行风险和可靠性评估的方法起源于美国的航空航天和导弹计划。故障树分析就是这样一个例子，在六十年代中期非常流行。在阿波罗计划的早期，人们被问及成功将宇航员送上月球并将其安全返回地球的可能性。进行某种风险或可靠性计算，结果是任务成功概率低得无法接受。这一结果阻止了NASA进一步定量风险或可靠性分析，直到1986年Challenger事故发生之后。相反，NASA决定依靠使用故障模式和影响分析（FMEA）以及其他定性方法进行系统安全评估。挑战者事故发生后，PRA和FTA在系统风险和可靠性分析中的重要性得以实现，并且在NASA的使用已经开始增长。
FTA是用来验证随机硬件失效导致的违背安全目标。FTA的目的是验证由于硬件随机失效导致的违背安全目标的残余风险足够低。
-
根本原因分析
- 识别导致不良事件的所有相关事件和条件
- 确定并行和顺序事件组合
- 模型涉及的多样化/复杂事件相互关系
-
风险评估
- 计算不需要事件的概率（风险等级）
- 识别安全关键组件/功能/阶段
- 测量设计变更的影响
-
设计安全评估
- 证明符合要求
- 显示需要安全要求的地方
- 识别和评估潜在的设计缺陷/薄弱环节
- 确定共模故障
也称为：潜在的失效模式和影响分析; 失效模式，影响和危害分析（FMECA）。
美国军方在20世纪40年代开始，故障模式和影响分析（FMEA）是一种逐步的方法，用于识别设计，制造或装配过程或产品或服务中的所有可能的故障。它是一种常见的过程分析工具。
- “失效模式”是指某些事物可能失效的方式或方法。失效是任何错误或缺陷，尤其是影响客户的错误或缺陷，可能是潜在的或真实的。
- “效果分析”是指研究这些失效的后果。
根据严重程度，发生的频率以及检测的容易程度，对失效进行优先排序。FMEA的目的是采取措施消除或减少失效，从最高优先级的失效开始。
失效模式和影响分析还记录了当前关于失效风险的知识和行动，以用于持续改进。在设计过程中使用FMEA来防止失效。然后它在过程的持续运行之前和期间用于控制。理想情况下，FMEA始于设计的最早概念阶段，并在产品或服务的整个生命周期中持续进行。
故障模式和影响分析(FMEA)是一种“自下而上”的系统分析，是功能安全标准认证(IEC 61508及其派生的所有标准)所必需的。这种类型的分析可以作为“自顶向下”分析方法(如故障树分析(FTA))的补充;然而，使用FMEA对功能安全系统进行定量或概率分析的标准任务要求在FMEA中考虑功能安全系统的每个组成部分。(FMEDA，故障模式及影响诊断分析，与FMEA没有区别;“诊断”只是强调从FMEA中得到的一个结果，指出特定FMEA的主要目的。)
- 在质量功能部署(QFD)之后，设计或重新设计流程、产品或服务。
- 当以一种新的方式应用现有的流程、产品或服务时。
- 在制定新工艺或修改工艺的控制计划之前。
- 为现有流程、产品或服务制定改进目标。
- 分析现有流程、产品或服务的故障时。
- 在过程、产品或服务的整个生命周期中定期进行
注:这是一个通用程序。具体细节可能会随组织或行业的标准而异。在进行FMEA过程之前，通过其他参考资料和培训了解更多关于组织和行业中的标准和具体方法。
- 组建一个跨职能的团队，由对流程、产品或服务以及客户需求具有不同知识的人员组成。通常包括的功能包括:设计、制造、质量、测试、可靠性、维护、采购(和供应商)、销售、营销(和客户)和客户服务。
- 确定FMEA的范围。是概念、系统、设计、流程还是服务?边界是什么?我们应该详细到什么程度?使用流程图来确定范围，并确保每个团队成员都详细地理解它。
- 填写FMEA表格顶部的识别信息。其余步骤询问将进入表单列的信息。
- 确定范围的功能。问:“这个系统、设计、流程或服务的目的是什么?”我们的客户希望它做什么?用动词加名词来命名。通常将范围划分为单独的子系统、项目、部件、程序集或流程步骤，并确定每个步骤的功能。
- 对于每个功能，确定所有可能发生故障的方式。这些是潜在的失效模式。如果有必要，返回并更详细地重写功能，以确保故障模式显示该功能的丢失。
- 对于每种故障模式，确定对系统、相关系统、流程、相关流程、产品、服务、客户或法规的所有后果。这些都是失败的潜在影响。问:“由于这个失败，客户体验到了什么?”当失败发生时会发生什么?”
- 确定每种影响的严重程度。这是严重程度等级，或者S。严重程度通常从1到10进行评分，1是不重要的，10是灾难性的。如果故障模式具有多个影响，则仅对该故障模式的最高严重程度评级写入FMEA表。
- 对于每种故障模式，确定所有潜在的根本原因。使用分类为原因分析工具的工具，以及团队的最佳知识和经验。在FMEA表单上列出每种故障模式的所有可能原因。
- 对于每个原因，确定发生级别，或O。该级别估计在您的作用域的生命周期内由于该原因发生故障的概率。事件的发生通常以1到10为分值，1是极不可能的，10是不可避免的。在FMEA表中，列出每个原因的发生率。
- 对于每个原因，标识当前流程控制。这些是测试、过程或机制，您现在已经准备好了这些测试、过程或机制，以防止故障到达客户。这些控制可能会阻止原因的发生，降低原因发生的可能性，或者在原因已经发生但客户还没有受到影响之前检测故障。
- 对于每个控件，确定检测等级，或D。该等级估计控件在发生原因或故障模式之后(但在客户受到影响之前)能够检测到的程度。检测通常在1到10的范围内进行评分，1表示控件绝对能够检测到问题，10表示控件一定不能检测到问题(或者不存在任何控件)。在FMEA表中，列出每个原因的检测等级。
- 大多数行业都可以选择:询问“这种故障模式是否与某个关键特性相关?”(关键特征是反映安全或符合政府规定并需要特殊控制的度量或指标。)如果是这样，标记为“Classification”的列将接收一个Y或N，以显示是否需要特殊的控件。通常，关键特征的严重程度为9或10，发生和检测等级在3以上。
- 计算风险优先级编号，或RPN，它等于S×O×D。还可以通过将严重性乘以发生次数S×O来计算临界性。
- 确定建议的行为。这些操作可能是为了降低严重性或发生而设计或处理更改。它们可能是改善检测的额外控制。还要注意谁负责行动和目标完成日期。
- 当操作完成时，在FMEA表单上记录结果和日期。此外，请注意新的S、O或D评级和新的rpm。
FMEDA是硬件架构度量的一种验证方法。它在FMEA基础上增加了两部分信息：
- 对所有要分析的部件给出定量的失效数据
- 系统或子系统通过自动在线诊断发现失效的能力
FTA和FMEA用来支持硬件设计，FMEDA用来进行硬件设计的验证。
