内容提要：此文为该连载系列的“上”篇，主要通过较全面地阐述安全故障的背景知识，进而提出了应用相关的安全故障识别方法。

摘 要   

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安全故障的自动识别（下）：案例研究及实验结果”，关注牛喀网，学习更多汽车科技。

有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！