汽车SoC安全故障的自动识别上逻辑仿真和形式分析

摘 要

ISO26262要求依据集成电路在汽车电子体系中的影响（平安、检测到或未检测到），对随机硬件故障进行分类。一样平常来说，这种分类是经由过程专家断定和对象组合来进行的。然而，因为集成电路繁杂度的赓续增长，发生了伟大的故障空间，使得这种情势的故障分类容易失足且耗时。以是有必要一种主动化和体系化的办法，对SoC中的硬件故障进行分类。本文的重点是辨认平安故障，本文所提出的办法的是，应用笼罩度阐发来辨认平安故障，同时斟酌利用法式的所有束缚。然后对利用法式的行动进行建模，如许可以应用情势阐发对象。我们用一个巡航节制体系的AutoSoC做为示例，对所提出的技术进行了评估。借助我们的办法，可以将 CPU、UART和CAN中的20%、11%和13%归类为平安故障。这种分类还可以将CPU和CAN模块的软件测试库的诊断笼罩率进步4%到6%，从而进步可测试故障笼罩率。

本专题连载共分为“上、下”两个篇章。此文为该连载系列的“上”篇，主要经由过程较周全地论述平安故障的配景常识，进而提出了利用相关的平安故障辨认办法。

1、简介

繁杂的硬件和软件体系越来越多的在平安相关情况中使用，例如汽车、飞机或医疗装备，为此人们引入了平安尺度来估量和低落风险。这些风险包括了人身危害或对人类整体康健的侵害。是以，必要特殊的灾害轻减办理计划来应对这些在症结范畴事情的体系。好比汽车行业，为了实现主动驾驶，部署在汽车中的SoC和利用法式的数目正在明显增长。当代汽车已经集成了100多个电子节制单位(ECU)，以应对繁杂利用带来的挑战，例如高档驾驶辅助体系(ADAS)。硬件和软件利用法式的繁杂性在架构和功效层面上都晋升了。此中，硬件繁杂度界说为单个SoC/芯片上集成了若干组件和模块。而软件繁杂性，除了与功效及内部交互的部件数目有关，还与光阴繁杂性有关。此外，采纳先进的集成电路(IC)技术，对汽车的平安提出了更年夜的挑战，由于诸如纳米电子老化、工艺变化或静电放电等多种征象会引入很多破绽。是以，汽车行业订定了ISO26262途径车辆功效平安尺度，以最年夜限度地低落与车辆中使用的电气和/或电子体系相关的风险。对付汽车利用，每个电子体系都必需检测并正确治理年夜部门运行进程中的故障，以避免危及人身平安的环境。为了肯定哪些故障可能会滋扰IC的平安症结功效，必需使用专家断定和对象组合阐发，并依据故障在运行模式中的影响对故障进行分类。从这个角度来看，故障可以分为平安故障或危险故障。平安故障不会导致违背平安目的，而危险故障可能会导致与整个体系相关的故障，即发生伤害。我们注意到，所有术语和界说均在ISO26262上下文中给出。平安故障包含位于利用法式未使用的IC部门的故障，以及被某些平安机制笼罩的故障。显然，故障分类对付在运行模式下测试IC至关紧张。该测试可以借助分歧的办理计划来执行，包含可测试性设计（例如BIST）和基于软件自测(SBST)范式的软件测试库(STL)。在这两种环境下，平安故障的辨认都是至关紧张的，由于它使我们可以或许从初始（通常是伟大的）故障列表中删除平安故障，并将测试事情集中在残剩的故障上，好比可测试的故障。是以，辨认平安故障可以更轻松地到达目的诊断笼罩率(DC)，从而有助于实现平安要求，例如更高的汽车平安完备性品级(ASIL)。出于这些缘故原由，发生了主动化、体系和周全的平安故障辨认技术的需求。

图1总结了故障分类流程的影响，并参考了一个常用的案例。我们假设SoC在其性命周期内只运行单个软件(SW)利用法式，并使用STL作为平安机制。是以，必需计算该STL的DC，以证实它在目的设计中检测到必定水平的危险故障。在流程的第一步，没有任何分类，所有故障都是未知的，如图1所示。然后，执行初始分类以辨认第一组布局平安故障，即从IC布局上便是平安的故障（例如，未衔接到IC主要输入和/或输出的线路上的故障）。此外，可以使用任何主动模式测试天生(ATPG)或情势阐发对象来辨认这些类型的平安故障。然则，可能存在这些对象无法辨认的其他平安故障，是以，在第一步之后仍有相称多的故障是未知的。而这些未知故障必要进一步阐发，以反省其是否会影响平安症结功效。是以，使用STL进行故障仿真，以更好地对故障进行分类。在实践中，此步调（在图1中定名为未优化分类）会发生禁绝确的成果，由于通常弗成能详尽地评估所有可能的输入激励或激活所有利用法式的运行模式。可见，未检测到的故障可能对应于平安故障或危险故障。如图1所示，故障仿真以未知故障为目的，并将其分类为已检测到或未检测到。依据在目的设计上运行的事情负载，可能会察看到弗成疏忽的未检测到的故障数目。通常，所有未检测到的故障都被守旧地归类为危险故障。出于这个缘故原由，从故障仿真中网络到的数据可能无法代表设计运行行动，由于并非所有故障都可以精确分类。在此步调中使用(1)计算DC，此中Detected是故障仿真中分类为可检测到且危险的故障数；Total是目的体系故障列表的年夜小；Safe是平安故障的数目。假如DC还不够，则必需改良测试，或者必要针对未检测到的故障进行额外的分类事情，即未检测到的故障的子集，以对其影响进行分类。专家通常依据他们的设计常识执行此步调；然则，这容易失足且耗时。是以，未优化的分类意味着故障分类守旧主义，仍有改良的空间。本文采纳一种情势阐发办法优化了故障分类（称为优化分类），如图1的第四条所示，其目的是辨认更多平安的故障，削减未检测到的故障数目，从而低落分类的整体守旧性。与未优化分类相比，优化分类经由过程增长平安故障来减小（1）的分母，增长DC。

图 1. 硬件故障分类流程。

我们经由过程主动化事情流程推动硬件故障分类，赞助平安专家削减故障分类工资差错和放行光阴。今朝的事情重点是对未检测到的故障进行主动阐发，以反省它们是否会影响IC的平安症结功效。假如故障不违背平安目的或滋扰平安症结输出，则将其界说为平安故障。我们斟酌一个现实场景，即执行单个SW利用法式的SoC，该利用法式在整个运行性命周期坚持不变。我们测验考试辨认利用法式相关的平安（App-Safe）故障。App-Safe故障的一个实例是SoC中的调试单位，在SoC的运行时代，利用法式不会使用该单位。为此，起首我们执行几个仿真逻辑，经由过程阐发代码笼罩成果来提取目的体系的运行行动。然后标志出与平安无关的平安故障的候选，并主动转换为情势属性，然后设置装备摆设情况以辨认App-Safe故障。

我们选择汽车上代表性的SoC和巡航节制利用法式(CCA)做为案例，环抱CPU内核和几个外围装备，例如UART和CAN进行探究。

本文还办理了ISO26262功效平安验证中的新问题，该问题与平安故障方面的一样平常靠得住性分歧。功效平安验证的主要目的是避免违背平安目的，而不是设计中的一样平常失效，这便是平安故障的观点。我们的假设是应用现有技术的上风，以一种立异的办法来办理这些问题。其主要内容可以列举和总结如下：

•将新的体系性办法与工程观点相联合，提供可部署到汽车行业的SoC工业办理计划。

•提出EDA对象支撑的主动化平安故障辨认技术：经由过程目的设计运行软件利用法式的逻辑仿真，提取反映软件利用法式行动的笼罩度申报，将笼罩度申报转化为利用法式的情势属性，执行情势阐发。

•经由过程ISO26262驱动的平安故障辨认技术，将测试事情集中在其他故障（危险）上，完美测试和验证理论。

•提出一种可扩大的情势属性天生办法，将设计的运行行动转化为情势阐发对象。

•使用CPU以及UART和CAN外围装备，在汽车SoC上对所发起技术的有用性进行试验演示。

•明显改善对平安故障的分类和由此发生的笼罩度，从而实现更高的平安级别。当AutoSoC运行CCA时，CPU、UART和CAN中的所有故障中分离有20%、11%和13%被分类为平安故障。CPU和CAN的DC值分离增长了年夜约6%和4%。该阐发还将CPU和CAN中未检测到的故障数目分离削减了1.5倍和1.6倍。

本篇的别的部门布局如下：第2节提供了一些配景常识，包含硬件故障分类和实现这种分类的技术，例如故障仿真和情势阐发；第3节具体界说了App-Safe故障，并慢慢先容了建议的办法。另外，在此连载专题的“下”篇章中，其第1节扼要先容了AutoSoC对标体系，包含它的CPU、外设和我们在这项事情中使用的软件利用法式；第2节总结并讨论了所提出技术的试验成果；第3节得出了一些结论。

2、配景

本节起首提供有关硬件故障分类的根基常识。然后，解释故障仿真和硬件故障分类的情势办法。

2.1 硬件故障分类

ISO26262将电气/电子元件的故障分为两类，体系故障和随机故障。体系故障以肯定性的方式表示出来，只能经由过程流程或设计步伐来预防。随机故障在硬件元件的性命周期内，弗成猜测地产生。当我们斟酌平安症结体系设计时，例如汽车、医疗或航空航天设计，平安和验证工程师必需同时斟酌到体系和随机故障，证实设计的正确性和平安性都获得保证。

随机硬件故障存在多种起源，例如极度前提、老化或现场辐射。此外，每种故障类型都应该有一个故障模子，该模子描写了若何在恰当的硬件设计抽象级别（例如，在门级别或存放器传输级别“RTL”）对这些故障进行建模。

此外，故障可所以永远性的和瞬态的，瞬态故障产生后消散。永远故障产生并一直存在，直到被移除或修复。在本连载专题中，我们只存眷随机硬件故障（分外是永远性故障），主要讨论永远性的stuck故障，好比旌旗灯号永远固定在某个逻辑值，即stuck-at-0,SA0或stuck-at-1,SA1。我们还注意到，stuck故障可能实用于所有网表旌旗灯号，例如逻辑门或存放器的端口。

为了肯定故障导致平安症结失效的概率，其影响必需分为以下两个分歧的种别。

•平安：平安故障不会滋扰任何平安症结功效，由于它不在平安相关逻辑中，或者在平安相关逻辑中，但无法影响设计的平安症结功效（即，它不克不及违背平安目的）。

•危险：危险故障会影响装备的平安性，并发生可能导致违背平安目的的伤害。

2.2.故障仿真

作为平安芯片开发的一个构成部门，故障仿真是一种普遍使用的辨认故障影响的技术。故障仿真对象经由过程使用一些给定的测试激励执行仿真，来阐发IC的RTL或门级抽象。一样平常来说，故障注入流程是基于正常运行成果与故障运行成果之间的比拟。起首，运行正常的法式以天生参考值。在此步调中，指定监测故障流传的察看点。然后，在注入故障的环境下执行故障法式。末了，将正常运行获得的参考值，与故障运行发生的故障值进行比拟，对每个注入故障进行分类，从而断定每个注入故障是检测到照样未检测到。当指定察看点至少有一个输出值产生变化时，将故障分类为检测到。不然，故障被归类为未检测到。

只管故障仿真是工业界和学术界普遍使用和采纳的技术，但它存在两个问题：

•不完备的成果：斟酌到繁杂的利用法式和装备，弗成能仿真所有可能的输入序列组合。是以，使用故障仿真技术无法将某些故障精确分类为平安或危险。

•无效故障：注入到目的体系中但在执行时代未激活的故障将发生无效故障。这些故障被分类为未检测到的。这会导致含糊其词的成果，由于当使用分歧或更周全的输入激励时，这些故障可能是危险的。

因为上面列出的两个缘故原由，可能必要使用额外的分类技术，例如情势化办法，在故障仿真后对故障进行分类，无论它们是否平安。我们必需注意到，检测到的和未检测到的故障，都可能包括平安和危险的故障。是以，假如一个故障没有被分类，而且没有被证实是平安的，那么它应该被守旧地以为是危险的。

以下末节解释了情势化办法若何对故障进行分类，若何区分平安和危险。

2.3.情势化办法

情势化办法有助于依据故障的影响对故障进行分类。经由过程阐发来肯定目的设计是否满意一组属性或前提。这种办法通常是静态阐发和算法计算等分歧技术的组合。与利用单一激励的故障仿真相比，情势阐发的限定较少，由于它可以从任何特定激励中抽象出来。另一方面，计算繁杂度可能会限定情势阐发的实用性。在这种环境下，弗成能对所有故障进行分类；是以，情势阐发对象应该由情势属性提供，认真开发，充足斟酌来自SW利用法式的束缚，并在计算可行性和成果精确性之间探求均衡。

通常，情势化对象利用布局阐发反省和情势阐发反省来辨认平安故障，如下所述。

2.3.1 布局阐发反省

在布局阐发反省中，情势化对象依据设计的拓扑特性，来肯定每个故障的可测试性。布局故障阐发的三种办法：

•影响锥外(COI)阐发：该办法反省给定节点是否在给定察看点的COI之外；在这种环境下，故障是平安的。在图2中，位于out1（以绿色显示）的COI中的节点上的所有故障都是平安的，由于在示例阐发中斟酌的察看点是out0。很显著，G3单位端口上的stuck故障不克不及流传到out0，由于它们与out0没有物理衔接。是以，G3上的故障是平安的。

•弗成激活阐发：反省SA0或SA1故障是否位于常数0或1的节点上；假如是如许，则无法激活故障。在这种环境下，故障是弗成激活且平安的。在图3中，假设in0与逻辑0相联系关系，则SA0的f0是弗成激活且平安的。

•弗成流传阐发：执行此操作以反省故障是否被激活而且在所斟酌的察看点的COI中，但不克不及流传到输出。在这种环境下，故障是平安的。在图3中，假如in1或in2之一始终为逻辑值0，但与门G2可以阻止f1的流传。是以，f1对付SA1或SA0是平安的，由于它永久不会流传到out0。

图2.Out-of-COI示例，当out0是独一的平安症结输出时。

图3.弗成激活和弗成流传的阐发示例。

2.3.2.情势阐发反省
情势阐发反省也用于对故障进行分类，与斟酌设计的物理衔接的布局阐发相反，该办法使用相似于故障仿真的好机和坏机，并在坏机中注入故障进行情势阐发。末了，比拟好机和坏机的输出旌旗灯号值，反省注入的故障是否流传。

情势化对象通常天生由电路（或其一部门）实现的功效的布尔表现，并使用上述情势化技术来证实该布尔方程。情势阐发对象使用基于布尔表达式，和操控技术的各类引擎，例如二元决议计划图(BDD)来详尽地证实情势属性。这种阐发有两种类型：

•激活阐发：该阐发反省是否可以从输入功效激活故障。假如不是，则肯定它是平安的。

•流传阐发：这一项反省故障是否可以流传到相关输出。假如它不克不及，那么它是平安的。

第3节中描写的技术，使用告终构和情势阐发反省。

3、利用相关平安故障辨认办法

在第2节中，我们解释了平安故障不会滋扰任何平安症结功效，由于它不位于任何平安相关逻辑或平安相关组件中。基于此解释，我们将平安故障进一步分类如下：

•布局平安（Str-Safe）：因为设计的布局束缚，这些故障不克不及被任何测试序列激活或流传到感兴致的输出。例如，冗余逻辑或浮动收集（即任何没有负载的收集）中的故障是Str-Safe。另一个例子是supply0和supply1收集。详细来说，supply0收集上的SA0故障和supply1收集上的SA1故障是Str-Safe。末了，上拉门上的SA1故障和下拉门上的SA0故障是Str-Safe。

•功效平安：与布局平安故障相反，存在功效平安故障的测试或测试序列而且它们的影响可能会流传到设计输出。然则，它们不会影响任何平安症结功效。例如，因为硬件设置装备摆设而未使用的CPU调试单位中的故障，在功效上是平安的。

今朝的事情着重于功效平安故障的子集，对应于利用法式相关的平安故障（App-Safe）。App-Safe故障与目的体系执行的SW利用法式有关，它们不会滋扰运行模式下的平安症结功效。是以，可以说故障对付一个软件利用法式是App-Safe的，但对付另一个软件利用法式可能是危险的。

更详细地说，这项事情中斟酌的目的体系，在整个运行寿命时代执行单个软件利用法式。在现场运行进程中，该利用法式及其输入数据集不会拜访所有设计部门；是以，弗成拜访的组件会发生App-Safe故障。例如，假如SW利用法式不使用任何乘法运算，则与乘法操作码相关的所有资本都将成为App-Safe故障。是以，SW利用法式的运算码是App-Safe故障辨认的一个很好的指标。再次参考乘法示例，当目的设计上运行的SW利用法式不包括乘法运算码时，SW利用法式不会触发乘法算术逻辑单位(ALU)中的硬件，是以这些组件上的故障会导致App-Safe故障。App-Safe故障的另一个例子，可以在设计的测试设计模块中找到。SW利用法式在正常运行模式下不使用这些硬件元素；是以，响应的故障是利用平安的。

在以下末节中，我们将解释在工业级SoC上运行软件利用法式时，辨认利用法式平安故障的建议流程。

3.1 建议的流程

在图4中，分步论述了辨认App-Safe故障的建议流程。在流程的开端，我们有一个被测设计(DUT)电路（通常是SoC）和一个正在运行的软件利用法式在上面。起首，我们使用分歧的代表性输入数据集运行多个逻辑仿真。运行逻辑仿真的目标是，阐发设计在运行软件利用法式时的行动。接下来，开发特定于利用法式的情势属性，从而将设计的运行行动转化为情势情况。情势属性为情势阐发对象提供输入，以辨认App-Safe故障。末了，部署情势阐发对象，列出平安故障。在以下末节中，我们将具体讨论每个步调。

图4.发起的利用相关的平安故障辨认流程。

3.1.1 逻辑仿真

在这一步中，我们对被测设计(DUT)执行多个逻辑仿真，以执行具有分歧现实数据输入序列（即set1到setn）的代表性SW利用法式，如图4所示。此中一些使用分歧的输入数据运行，由于我们的目的是肯定哪些设计部门自力于输入数据集。执行逻辑仿真的目标有两个：

•相识哪些设计部门受到输入数据集的影响；

•提取设计在运行软件利用法式时的运行行动。

为了实现这些目的，我们为每个逻辑仿真天生硬件设计代码笼罩率数据，并将它们存入笼罩率申报中。

一样平常来说，逻辑仿真旨在检测哪些点没有被翻转，由于这些是必需办理的App-Safe候选点。关于笼罩率指标，拟议的事情着重于硬件代码笼罩率，经由过程指向不相符所需笼罩率尺度的设计组件，来评估激励对设计代码的执行水平。我们的技术部署了设计代码笼罩的翻转和模块笼罩子类型来辨认利用法式平安故障。此中，模块笼罩率是一个主要的代码笼罩率指标，用于辨认代码中的哪些行已被执行，哪些尚未被执行。另一方面，翻转笼罩监控、网络和申报旌旗灯号翻转运动，容许辨认未使用的旌旗灯号或坚持恒定值0或1的旌旗灯号。

显然，模块和翻转笼罩率指标提供了对IC性命周期内SW利用法式行动的洞察。是以，我们可以辨认功效平安故障列表中包括的App-Safe候选清单。更详细地说，模块笼罩可以指导某些状况从未被激活，这注解SW利用法式没有使用响应的设计组件。同样，由翻转笼罩辨认的恒定旌旗灯号，可以凸起显示无效设置装备摆设、未使用的功效等。此外，应细心阐发模块和翻转笼罩数据的组合，由于它们可以指出有关SW利用法式行动的更多信息。举例来说，未翻转旌旗灯号可能永久不会激活状况机模块，这会导致其他一些模块在仿真时代坚持未激活状况。清单1和表1中的Verilog代码阐明了模块笼罩率、翻转笼罩率，并解释了为什么要细心阐发它们两个。清单1显示rf_data_in模块从未激活，由于break_error从未翻转到逻辑1，如表1所示。此笼罩成果还意味着rf_data_in从未在第402行得到右侧值，由于该模块未激活。这个例子指出了同时评估模块和翻转笼罩的紧张性。

在运行逻辑仿真，并丈量上述硬件代码笼罩率指标后，硬件笼罩率指标数据可用于申报天生和阐发。在这一步停止时，笼罩率申报代表了设计在分歧输入数据集的影响下的运行行动。当这种行动被转化为情势属性时，如下末节所述，我们称它们为利用法式特定的情势属性。

清单1.模块笼罩示例：r f_data_in未执行。

表1.切换笼罩率示例：break_error未切换。

3.1.2.特定利用法式的情势属性开发

IC的开发周期始于目的体系的规范和要求。此外，必需依据设计和验证工程师订定的验证方案来验证DUT。然后创立DUT的功效或要求并将其映射到情势属性，以将它们部署在情势阐发对象中。情势属性是依据设计规范和电路实现创立的。是以，在经由过程逻辑仿真提取目的体系的运行行动之后，在这一步中，我们将此行动转换为情势属性，以在情势阐发对象中使用，该对象将辨认额外的App-safe故障。

我们使用两种类型的情势属性来界说设计的正确行动。第一种是假设语句，它为指定的布尔表达式创立一个假设，其计算成果为真或假。在一样平常意义上，它指定给定属性是一个假设，用于天生输入激励。是以，当我们界说设计设置装备摆设或见告对象设计输入的行动方式时，假设语句会很有赞助。假如没有这个假设，情势对象会反省DUT的所有可能输入组合。在情势情况中使用假设语句有两个利益。起首，它可以排除非法输入组合。正当输入是我们期望在正常运行时代看到的输入。当注入所有可能的输入组应时，期望设计正确运行是不实际的，除非我们明白界说设计理论上可预知的每组可能的输入组合。使用假设语句的第二个利益是它故意地削减了状况空间，当没有界说假设时，它是穷举的。例如，当我们想要斟酌设计的运行行动来预备我们的情势情况时，我们应该禁用scan_enable引脚，由于扫描链在运行时代不会被激活，而且仅用于测试目标。在这种环境下，创立(2)中给出的假设语句，从而关照情势对象有关scan_enable旌旗灯号行动；是以，情势阐发对象的输入测试激励受到响应的束缚，（2）中给出的敕令关照对象scan_enable始终为逻辑0。并且，假设语句还经由过程领导增长情势阐发对象的平安故障辨认才能。此外，相似于下面给出的示例，设计实例的输入端口是假设语句的适宜候选者。

第二个情势属性是故障流传屏蔽，它创立了一个阻止故障流传的情势屏蔽。在这种环境下，故障不克不及在此屏蔽之后流传；是以，它们不会滋扰任何平安症结功效。例如，知道调试单位未用于设计的运行模式，我们可以阻止所有故障从它进行流传，并辨认更多的利用法式平安故障。如(3)所示，要求情势阐发对象阻止流传到du_dat_o的所有故障，du_dat_o是调试单位的数据输出旌旗灯号。在这个给定的例子中，输出端口是故障流传屏蔽的适宜候选者，而不是假设语句，输入端口是适宜的候选者。

是以，可以使用假设语句和故障流传屏蔽，来开发特定于利用法式的情势属性。经由过程如许做，目的体系的内部架构和逻辑细节、运行束缚（若有）或设计的初始设置装备摆设可以界说为情势阐发步调中使用的情势属性。是以，设计的运行行动可以从逻辑仿真转移到情势阐发对象中。下一末节解释了情势阐发对象若何使用这些特定于利用法式的情势属性。

3.1.3 情势阐发

以适宜的符号指定目的设计的情势属性后，可以使用情势阐发对象来天生利用法式平安故障。情势阐发的长处是，它提供了一个关于故障是否流传的准确谜底，由于它斟酌了所有可能的输入激励组合（因为前面解释的假设语句而设置装备摆设和限定），是以它打消了对输入激励的依附。在我们流程的这一步中，一个情势阐发对象反省目的设计中的每个故障，看看它是否可以流传到察看点。假如任何输入激励不克不及流传故障，则将其归类为平安；在我们的例子中，它是利用平安的。不然，故障属于危险种别。

情势阐发流程包含三个阶段，如图5所示。第一阶段从创立输入文件开端，这些输入文件是在前一阶段和DUT中树立的情势属性。然后为情势阐发对象开发对象敕令语言(TCL)设置剧本。而安装剧本由Verilog文件、库和情势属性文件构成。安装剧本起首阐发设计和属性文件，以反省语法差错。然后，它界说时钟和复位旌旗灯号。而时钟界说是指定在情势阐发运行时代，若何驱动时钟的特征。同时，重置规范旨在将设计带入已知状况，并避免无法达到的故障状况。在下一步中，假如情势属性与DUT之间存在不匹配，情势阐发对象将天生警告。例如，在DUT中接地的旌旗灯号和将该旌旗灯号界说为始终为逻辑1的假设语句，可能会导致不匹配，并天生警告。然则，因为我们主动将笼罩率申报转换为情势属性，是以本事情中提出的事情并非如斯。然后，在第二阶段，情势引擎经由过程运行“2.3节”中先容的布局和情势反省，来证实情势属性。末了，在第三阶段，辨认利用平安故障被并总结申报。

简而言之，情势阐发对象使用情势属性来天生平安故障。当我们包括由SW利用法式驱动的情势属性时，如前所述，我们使该对象可以或许在明白指定的设置装备摆设中事情。是以，使用情势属性的情势阐发会增长已辨认的App-Safe故障的数目。

图5.情势阐发阶段。

更多内容，请存眷：汽车SoC平安故障的主动辨认（下）：案例研讨及试验成果”，存眷牛喀网，进修更多汽车科技。