电子发烧友App
随着汽车行业电气化智能化的快速发展，功能安全标准ISO 26262逐渐被各大汽车制造企业及零部件供应商重视。近期，《智能网联汽车生产企业及产品准入指南》明确将功能安全和预期功能安全作为汽车制造和生产的准入要求，体现了国家对于汽车安全的重视，功能安全的实施与否已经成为了衡量汽车制造企业及零部件供应商造车能力的关键性指标。 然而，功能安全标准的发布和实施历史并不悠久。根据笔者观察，尤其国内大部分汽车制造和零部件供应商企业，基本从2014年起才开始关注功能安全设计。因此功能安全在国内的发展其实还远未达到成熟期，可以说目前依然处于概念建立期或者快速发展期。 因此，面对日新月异的汽车电子电气系统的发展，如何正确地理解或者考虑该产品的安全设计给很多同行带来了困惑。
对于一个系统，架构设计通常决定了该系统的整体性能表现，而功能安全标准对架构设计的要求及安全分析方法论引用比较复杂，如何在系统设计之初，合理并充分的考虑其安全设计成为了当前很多同行在做安全设计的一个难点。 笔者从事功能安全领域工作八年有余，有过多家外企合资企业的三电系统，ADAS系统相关产品的安全开发设计经验。此次受SESETECH安全技术论坛邀请，结合个人经验分享一下对系统安全架构设计的浅薄理解，希望能够解决部分同行对于安全架构设计的痛点。限于个人认知，此文仅供各位同行交流讨论，不针对任何企业或者产品安全提出设计建议。 内容框架：
安全架构设计必须了解的术语及安全方法说明
E-GAS三层架构的理解及使用约束
ADAS系统安全架构设计及安全等级的分解
安全架构设计必须了解的术语及安全方法说明
在ISO 26262的第三部分，第四部分及第九部分，提到了很多关于系统或者相关项的安全术语，包括故障类型判断，安全分解策略，故障控制/避免措施，等。如何正确地理解并应用这些术语及背后的方法论，对于安全架构设计尤为重要。本文主要针对涉及到系统安全架构设计的必要术语进行一些系统性阐述，帮助大家理解其中关系。
故障控制措施（Fault control）和故障避免措施（Fault avoidance）
在功能安全标准或者一些教学中，经常会提到系统性失效和随机硬件失效两个概念作为电子电气系统的两大失效来源。在安全设计时，我们应当理解，并非所有的失效都能够通过安全机制来诊断或者控制，例如，基于系统层面FMEA或者FTA分析，导出可能违背安全目标的可能失效来源后，需要基于具体的失效原因制定对应的安全措施。 对于某个器件的随机硬件失效或者某个功能的系统性失效，如果可以通过特定安全机制进行诊断或者控制达到安全状态的，我们把这一类安全措施归纳为故障控制措施。（本文提到的故障控制措施包含故障诊断以及容错（fault tolerance）） 对于某个算法或者安全控制逻辑设计如果没有可以采用的安全机制能够对它合理性进行诊断及控制，那么就应该功能实现本身设计为对应的安全等级以对该功能的系统性失效进行覆盖，我们把它归纳为故障避免措施。 需要注意的是，从安全分解的角度，对于故障控制措施的安全需求，我们通常无需考虑进一步分解，对该功能直接进行对应安全级别的设计即可；对于故障避免措施的安全需求，如果有必要，我们才需要考虑进行进一步ASIL分解，进行冗余设计。（本文提到的故障避免措施，仅指代在功能设计时应当考虑的通过符合该功能安全设计流程和方法用于降低故障发生概率，其广泛含义还包含各阶段的安全分析，确认等标准要求的安全活动。）
安全分解（Decomposition）和分配（Allocation）
对于安全分解和分配，通常在上游安全需求往下游设计细化时考虑。其中，安全分解并非是必须的，而安全分配则是必须的。在考虑安全分解或者分配时，需要有一定程度细化的系统初始架构，包括物理和逻辑架构。结合系统安全分析FTA， FMEA识别的故障控制措施或者故障避免措施，将安全相关的诊断或者控制需求分配到架构元素中去。 进行安全分配和分解考虑时需要注意：
分配最简原则
如果对于某个安全目标或者故障控制措施，能够由系统架构中的一个单独元素完成。则将该安全功能完全分配到该元素中去，并保持该功能元素与其他非安全功能之间的独立性。
分配最后原则
如果对于某个安全目标或者故障控制措施，能够由一条安全关键路径的最后一个元素来实施，那么可以将该安全功能分配到该路径的最后一个元素中去。需要保证该元素对安全需求的实现不受前级输入影响。
分解最大可用性原则
充分利用初始架构中已经存在的冗余元素进行安全需求的分解，而不是去新增新的冗余元素。这里的冗余元素不局限于相同的传感器或者控制器执行机构等，只要两者之间有固定的算法或者合理性关系皆可以考虑构成分解。
分解最简原则
考虑安全分解时，如果实现安全目标或者故障避免措施的诊断或者实施过程比较复杂，那么采用分解策略时，应当采取更为简单有效的安全设计对预期的功能进行分解，并给其分配更高的安全等级，通常推荐QM（X）+X（X）方式进行分解。
冗余（Redundant）和独立性（Independent） 设计
基于标准描述，进行安全分解后，需要保证分解后的两个功能具备对上级安全需求的实现的冗余并且完全独立。
冗余理解为
分解后的两个或者多个功能能够分别独立地完成上游安全需求。注意，通常预期功能和其安全机制不能直接构成冗余，除非该安全机制能够完全执行预期功能的安全要求并能独立的控制系统进入安全状态。 例如，MCU的功能控制与外部看门狗不能构成安全分解的关系，因为外部看门狗并不能取代MCU单独的完成所有安全诊断和控制任务；而对于CAN通讯的E2E安全机制可以与CAN总线协议的诊断功能构成安全分解，因为E2E机制可以通过CRC和Rolling Counter覆盖信号传输过程中的信号安全诊断要求，并且独立于CAN总线协议使系统进入安全状态。（E2E诊断要求可以作为安全控制措施成为FSR，而对通讯整体不提安全要求，这种情况下则无需考虑分解，将该控制措施直接按照对应的安全级别实施即可。）
独立性理解为
分解后的两个或者多个功能之间不存在共同的导致初始安全需求被违背的失效来源或者该类型的失效能够被合理的安全机制覆盖； 注意，标准不仅要求对分解后的安全功能之间做共因失效分析，用于评估安全机制的有效性也需要做分析（预期功能与安全机制之间的独立性）。 要素共存的需要，如果在系统或者软件层面存在不同安全级别或非安全的功能运行在同一块资源区间，则需要保证低安全等级的功能失效不会导致高安全等级的功能失效，或者该失效类型能够被合理的安全机制覆盖。 以上独立性的要求，可以被概括为避免共因失效（Common Cause Failure）和避免级联失效（Cascading Failure），这两类失效通常由FTA及FFI分析后识别，通过DFA分析才能确认分解后的元素完全独立。
失效安全（Fail safe）、失效静默（Fail silent）、失效运行（Fail operational）及紧急运行（Emergency operation）
在考虑不同产品的功能失效时，需要基于产品功能的可用性要求，在行业内，经常会有如下几个关于安全架构概念阶段的名词，用于定义产品架构级别的失效属性，从而判断该采取哪一种设计作为安全状态。
失效安全（Fail safe）是指一个系统失效后特定功能关闭能够让系统维持在安全状态。例如，对于发动机管理系统的避免非预期扭矩输出这个安全目标，可以考虑采用关闭发动机扭矩输出作为安全状态。或者对于L2及以下的自动驾驶系统功能，也通常考虑采用关闭该特定功能作为安全状态。
失效静默（Fail silent）失效静默类似于失效安全，但是通常理解为系统失效后的一种状态属性，失效静默表示系统失效后对外表现为静默状态，不对其他的功能和输出产生干扰。该词汇用于描述功能失效后的影响，不常用于安全状态定义。
失效运行（Fail operational）如果一个安全状态无法通过功能关闭来实现，而是要保证系统的可用性，那么就需要选择失效运行作为其安全状态。例如对于L4及以上的自动驾驶系统，如果设计要求系统失效后车辆依然可以按照既定的操作进行自动驾驶，则需要设计一套冗余的控制系统，在主控制系统失效后，Fallback系统能够及时接管车辆在既定的ODD运行。类似失效运行的概念，还有失效降级（fail degraded， fail partial），通常对于有失效后可用性要求，又不需要完整的冗余接管的系统，例如，对于车辆灯光控制系统的防止近光灯非预期的完全关闭，这个安全目标需要考虑通过双电源和日间行车灯对近光灯的冗余，保证失效后至少有一个近光灯或者日间行车灯对路面进行照明。
紧急运行（Emergency operation）这个术语不等同于失效运行。紧急运行是指如果安全状态无法在可接受的时间内实现，则需要定义一个紧急操作，让系统在FTTI时间之内能够顺利的过渡到安全状态。这里的安全状态可能是指fail silent或者fail operational。例如，对于L3级别的自动驾驶系统，如果MRC作为系统的安全状态（fail silent），那么fallback系统的MRM功能则可以定义为紧急运行。 限于篇幅，对于概念和系统阶段其他的术语笔者不作展开，主要阐述在安全架构设计时应当考虑的几个基本点，即：
如何分配安全需求；
如何考虑安全分解；
如何考虑安全状态设计。
在开展具体的安全架构设计时，还需要充分地参考安全标准具体要求。
E-GAS三层架构的理解及使用约束
早期从事功能安全的同行对汽油发动机管理系统的E-GAS三层安全架构应该都有了解。虽然该架构并非为实现功能安全而专门设计，但是该架构提供了一个很好的应用安全分解的解决方案。基于目前市场上的类似电控系统设计，该架构基于Lockstep Core设计可以支持到最高ASIL D级别的设计要求。
图3.1-E-GAS三层安全架构带LC示意图
对于三层架构，如果运用安全分解策略，我们应该要注意：
L2层级的安全控制功能的输入需要独立于L1层级，以保证两者的独立性
L2可以对L1层级的输出信号进行诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性
L2 也可以通过输入信号进行独立的功能诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性
外部监控设备需要能够独立的对系统进行关断控制而不必依赖于L1或者L2的控制指令，用于避免L1和L2的相关性失效。
在考虑应用E-GAS架构时，对其安全分解策略并无固定要求，但是通常推荐采用QM（X） + X（X）的分解策略。主要考虑：
如果系统功能设计已经比较成熟，而引入功能安全后，对该系统进行功能重构复杂程度高。因此采用QM（X） + X（X）的分解能够让系统设计本身保持QM的等级，而只是对安全要求进行冗余的设计，这样能够最小化的影响功能的稳定性。
系统功能安全需求数量不多，并且该系统能够采用相对简单的策略对故障避免措施进行额外的冗余设计。这样能够最小化地增加开发成本。
L2 也可以通过输入信号进行独立的功能诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性 例如，传统的三电系统，发动机管理系统，变速箱控制系统及车身控制系统皆可以采用上述架构。通过E-GAS三层架构，对安全的功能和系统控制功能进行合理的分解，再配合目前主流的英飞凌AURIX（带Lockstep）+SBC（ASIL D）硬件解决方案，能够高效快速的实现高等级的功能安全设计。除此之外，对于VCU， MCU等新能源汽车上的一些控制器，通过E-GAS三层架构来实现ASIL D等级的设计也是很多主机厂和供应商的优先选择。
需要注意的是，对于一个复杂的新系统开发，或者系统功能安全需求数量大且不易做安全分解的，则不建议首先采用E-GAS三层架构。例如，对于自动驾驶系统的域控制器及备份控制器开发，安全需求除了MCU本身控制功能之外，对于感知，定位和规划算法均有涉及，而SoC和MCU之间很难采取统一的安全监控架构。因此，即使采用E-GAS架构实施安全分解策略后，也需要做大量冗余功能及独立性设计，并不能获得很好的时间或者成本的收益。对于这样的系统，可以考虑直接对安全的功能路径进行对应级别的开发，并做好独立性设计。
ADAS系统安全架构设计及安全等级的分解
在考虑ADAS系统的安全设计时，应当首先考虑该系统的自动驾驶等级以帮助判断该系统安全状态，参考SAE J3016定义：
图4.1-SAE J3016自动驾驶功能等级定义
基于定义来看，如果一个ADAS功能定义在SAE LEVEL 2及以下，则驾驶员需要时刻监督系统的运行用于保证驾驶安全。那么在定义该系统安全状态时，可以考虑采用失效静默架构，当系统失效时，对功能进行关闭即可满足该要求。 而对于SAE LEVEL 3级别的ADAS功能，由于系统定义在发生失效后的一定时间内（通常规定10s及以上），系统仍然需要正确的执行DDT，或者进行功能降级运行状态。因此在考虑该系统的安全架构时，需要设计紧急操作或者失效运行功能（L4及以上）。当主控制器发生安全相关失效而又无法进入安全状态时，备份系统至少需要在规定时间以内保持动态驾驶任务并提示驾驶员接管。 值得注意的是，SAE 并没有要求自动驾驶系统设计必须要做完全的失效运行，只要求接管系统在系统失效时一定时间内能够让车辆到达最小风险状态。因此在考虑ADAS架构设计时，不一定需要考虑系统失效时还能执行完整DDT的能力，只需要考虑接管系统是否有能力通过功能降级及驾驶员未接管后由紧急运行使车辆最小风险状态即可。
L3及以上级别自动驾驶系统安全等级评估
从功能安全的角度出发，由于高安全等级自动驾驶系统允许驾驶员脱眼或者脱手，在评估某系统的功能安全目标时，部分危害事件S，E，C会评定为最高分，继而得到ASIL D级别的安全目标。而当安全目标被违背时，系统又无法通过功能静默直接进入安全状态，因此对于控制信号的可用性设计也会要求满足ASIL D。 当前市场上ADAS系统的设计有很多，各家都在自研架构，但是整体的功能安全目标及最高级别通常均为ASIL D。
为了实现最小成本的解决方案，我们需要从系统架构层级，在满足安全要求的前提下尽量简化系统的设计。因此建议在基于SAE标准下的系统架构要素，用于功能安全需求的分解。例如，将fallback系统与Main系统进行冗余，将控制指令可用性失效需求分解由fallback和Main系统实现，考虑两者之间的独立性设计，及可以将部分的安全指标降级。本文将引入一个抽象的ADAS系统架构，用于描述功能安全ASILD级别在架构上的分解及分配关系。假设该ADAS架构抽象为如下图：
图4.2-L3+ADAS自动驾驶系统抽象架构 注意：在图4.2 架构中，为实现ADAS域控制指令的独立性，实现安全分解，将ADAS指令仲裁功能分配给底盘动力域控制器。在实际项目中，指令仲裁功能也可能由ADAS Main控制器实现，通过一定的机制实现自动指令转换，基于此结构，运动域控可以不需要；另外指令仲裁功能也可以集成在底盘域控系统中。对于执行器端的冗余设计，可以基于不同的ADAS功能和安全降级的要求进行必要冗余，而非横纵向完全冗余。执行器端具体方案在本文不做详细展开。 如果定义ADAS系统的整体安全目标简化为：
防止非预期的不能提供控制指令，ASIL D：
基于图4.2，Fallback系统作为Main系统的冗余系统，通过完全的冗余和独立可以将安全指令的可用性需求分解为ASIL B（D）即： 1. Main 系统需要提供正确的横向和纵向控制指令ASIL B（D） 2. Fallback 系统需要提供正确的横向和纵向控制指令ASIL B（D） 3. Main 系统和Fallback系统的控制指令需要完全独立 ASIL D（独立性要求） 需要注意的是，Fallback和Main控制器需要”热冗余”。热冗余是指在Main运行过程中，Fallback也应当同时运行，主要用于减少主控制器失效时指令切换的时间。同时，从安全角度，两者对自身失效进行诊断以防止非预期的失效导致自身控制指令不可用，无论哪个控制器诊断出自身失效，ADAS系统需要在一次驾驶循环内进行MRM或者不允许ADAS功能下次激活
防止非预期的发出错误控制指令，ASIL D
基于图4.2，由于ADAS系统运行时主要由Main系统进行仲裁及整车控制，因此对于Main系统，其安全诊断级别应当做到ASIL D。 由于 Fallback的整车接管控制在Main失效后才会启动。因此，在考虑Fallback系统安全级别时，可以从如下角度考虑适度降低： 例如，如果我们定义SAE ADAS L4系统，在主系统失效后，Fallback系统接管后最大有效运行时间为1小时， 对Fallback接管功能做HARA分析： 1.Fallback系统的失效造成严重度与Main系统失效相同 （S3）; 2. Fallback系统失效后可控度与Main系统失效相同 （C3）； 3. 在评估暴露度时，基于Fallback功能控车总共时长不超过1小时，相比较Main系统失效场景暴露度E，可以降低其指标，分析过程如下表：
表4.1-1 Fallback系统暴露度指标评估参考 发生永久性故障后接管系统的最大操作时间：假定在最坏情况下，Main控制器在其操作时间内失效。
假定系统运行过程由于瞬态切换而累积的接管操作持续时间：假定主系统由于系统性原因或者SOTIF影响短暂切换到Fallback系统，恢复后退回Main控制器。考虑在1000小时的ADAS操作时间内，每小时切换3s。
基于以上分析，我们可以看到，对于fallback系统，其实际的operation time只占ADAS系统operation time不到1%， 因此，可以将其E值由E4降为E2。继而，对Fallback系统发出错误的控制指令ASIL级别由ASIL D降为 ASIL B。
备注：1. 以上分析假定的前提为Main控制器与Fallback控制器完全独立，其指令仲裁在底盘系统中实施；2. HARA分析中对暴露度E值的评估方法与本文提及的降低策略有偏差，从本文的角度，实际上基于产品Operation time定义来降解，更多的是从降低随机硬件失效概率。对于Fallback控制器系统性失效，很多同行会认为需要按照原始等级（ASIL D）来实施。该分析仅做参考。
基于以上两点，可以简单总结ADAS系统的安全概念：
FSR-1： 在ADAS系统运行过程中，如果Fallback控制器诊断出自身失效，导致无法发出控制指令，Main控制器应当基于Fallback状态，控制系统运行一段时间或者进入MRC*。ASIL B（D） （FSR a，可用性设计，*这里也可以考虑在一个驾驶循环内持续进行DDT）;
FSR-2： 在ADAS系统运行过程中，如果Main控制器诊断出自身失效，导致无法发出控制指令，Fallback控制器应当基于当前失效状态，控制系统运行或者降级一段时间或者紧急操作进入MRC。ASIL B（D） （FSR a，可用性设计）;
FSR-3： Main控制器应当监控并正确的发出横纵向控制指令，如果Main控制器失效导致无法发出正确的控制指令，Main控制器应当关闭控制输出。ASIL D（FSR b， 防止提供错误的控制指令）；
FSR-4： Fallback系统在进行紧急操作或者接管系统驾驶任务过程中，如果Fallback系统监测到自身失效，导致无法发出正确的控制指令，则应当停止发送控制指令 ASIL B （FSR b， 防止提供错误的控制指令）
由于目前行业内ADAS系统设计，国内外还没有一个权威且受认可的方案，因此以上分析及见解仅作为参考。
本文基于ISO 26262标准的定义，并结合当前部分汽车零部件供应商或者主机厂对于产品的功能安全架构设计实践以及笔者个人经验，尝试对功能安全产品架构设计进行了一些浅薄的描述。希望能够对各位同行解答一部分疑惑或者难点。
编辑：黄飞
工商网监
评论