智能驾驶安全专题 | 你若安“芯”，便是晴天

千家信息网最后更新 2025年02月02日智能驾驶安全专题 | 你若安“芯”，便是晴天

"芯芯"向荣背后的安全隐患

全球范围内处于传统汽车至智能网联汽车变革期，随着人工智能、5G、物联网、云计算等新一代信息技术的飞速发展，将在智能网联汽车技术发展中产生巨大协同效应，重塑汽车产业业态和商业模式，为人类出行方式带来根本性变革。整车占比60%以上的电子电气系统中，智能网联汽车芯片能够高效地实现感应、控制、执行、决策、通信、导航等功能，是智能网联汽车的关键核心部件。 图1 汽车半导体的主要趋势 车规级IC不同于消费电子IC,高度强调可靠性及功能安全，需要承受极端工作环境（-40°C to +150°C）的考验，要满足 ISO-26262 、AEC-Q100等汽车行业标准。 对于半导体的开发过程，在ISO-26262第一版的要求中主要和ECU的硬件开发合并在Part5,硬件开发阶段的内容中提出要求。但考虑到半导体开发和硬件开发在具体实施上差异较大，因此在2018版ISO26262的标准上，又新提出了Part11半导体功能安全开发的指南，作为对Part5的补充和完善，其安全生命周期模型框架如下：

图2 ISO26262功能安全生命周期模型框架 以IC中的IP/SoC安全开发及验证为例，IP/SoC的功能安全开发目标主要包括两个方面：避免系统性失效的发生和避免随机失效的发生，其开发过程中的安全活动与标准的映射关系如下： 图3 IP/SoC与ISO26262映射

符合功能安全标准的IC开发流程

符合功能安全标准半导体的开发模式一般有两种： • Design in Context • Safety Element out of Context(SEooC) 目前芯片厂商基本采用SEooC的开发模式。在SEooC开发过程中会对安全生命周期内的功能安全活动进行剪裁，以满足实际的开发需求。 图4 基于SEooC半导体开发流程 基于SEooC模式进行半导体的开发主要分为两个过程： • SEooC硬件组件开发 • 相关项开发 核心过程一，SEooC硬件组件开发。它包含系统级假设和SEooC设计，芯片厂商依据市场调研的结果及对产品的定位制订系统级假设，主要内容包括技术安全需求假设以及外部设计假设，芯片厂商依据系统级假设进行后续的开发设计。 图5 需求假设与SEooC开发之间的关系 SEooC的设计主要包含的功能安全活动为：硬件安全需求的描述及验证、硬件设计的描述及验证、DFA分析、FMEA/FTA分析、硬件量化指标评估及验证、硬件的集成验证等。 • 硬件安全需求的描述及验证：硬件安全需求由假设的技术安全需求导出，包含了功能性需求（预期功能以及安全机制）以及约束性需求（失效率指标、FFI等）；根据硬件安全需求的ASIL等级采取相应的验证方法（走查、审查、半形式化验证、形式化验证）验证硬件安全需求的正确性、完整性、可测性、一致性、可实现性等 • 硬件设计的描述及验证：主要包含半导体的架构设计、RTL设计、门级设计以及布局布线等；通过走查、审查、安全分析（FTA/FMEA）、模拟仿真等方法对其进行验证 • DFA分析：通过DFA分析确保不同ASIL等级的模块之间满足共存的要求,ASIL等级分解的模块之间满足独立性，预期功能和安全机制之间满足独立性 • FMEA/FTA分析：主要是针对各种复杂系统设计和初样设计阶段进行可靠性、安全性分析。用于系统的故障分析、预测和找出系统的薄弱环节，以便在设计、制造和使用中采取相应的改进措施 • 硬件量化指标评估及验证：主要包含FMEDA和PMHF计算，通过架构指标（单点故障指标、潜在故障指标）来评估硬件架构设计水平 ，通过PMHF值评估表明随机硬件失效导致违背安全目标的残余风险是否足够低 • 硬件的集成验证：根据ASIL等级采取相应的验证措施，验证硬件设计是否满足相应的硬件安全需求 核心过程二，相关项开发。它的主要内容是系统级假设验证。当芯片集成方（OEM/Tier1）进行系统级别的设计时，需要验证芯片的技术安全需求假设与外部设计假设和当前系统中分配给芯片的技术安全需求以及当前系统设计是否一致。若两者一致，则可以进入后续的功能安全开发阶段；若两者不一致，则视实际项目情况由芯片开发方或芯片集成方进行变更。

安全分析助力SEooC开发

从上述的符合功能安标准的IC流程关键技术剖析不难看出，如何进行半导体的安全分析对SEooC开发至关重要，高效、准确的完成安全需求管理与追溯、FMEA、FMEDA、安全机制设计、故障注入与仿真、FTA、DFA以及相关的变更管理与影响分析等是SEooC开发面临的挑战，传统的使用Excel等单点工具已经很难满足安全开发设计的要求。 图6 半导体开发面临的挑战 其中在进行FMEDA分析时，芯片的设计不但要考虑永久故障，还必须考虑由于电路干扰、电磁干扰而导致的瞬态故障。一般而言，对于永久故障，封装Package和晶圆Die的失效率分布一般由行业专家来判定，而晶圆Die内部各个功能模块具体的失效率，比如数字电路、模拟电路、CPU等，首先要按照SN29500、IEC62380等标准并根据晶体管数量计算总的失效率，然后再根据每个功能模块的面积来计算相应的失效率。对于瞬态故障，标准建议是总故障率按照门的数量乘以基本瞬态失效率来计算，因此芯片内部失效率的计算，需要提取芯片内部模块的面积以及门的数量。对于永久故障和瞬时故障失效率的计算，如果采取人工的方式进行数据的提取和分析，非常耗时耗力，因此需要特定的工具进行辅助。

IC功能安全解决方案-Medini Analyze

针对半导体的功能安全开发及验证，Medini Analyze推出完整的安全分析解决方案，支持把IC设计文件导入到工具中，自动识别所需数据进行一系列的分析和计算。 图7 Medini针对半导体的FMEDA工作流程 对于半导体FMEDA的开发，基于Medini Analyze平台的主要分析流程如下： • STEP1，IP设计数据的无缝导入并与高层架构模型映射 • STEP2，支持IPD-XML格式包含die area/gate counts的设计数据导入，通过设计数据与高层架构模型映射，高层架构模型能够自动汇总失效率的分布 • STEP3，失效率预计，根据映射关系自动将失效率分布至各个功能模块 • STEP4，执行FMEDA，计算SPF/LF metrics,safe fault fraction等，从映射后的高层架构模型能够直接生成FMEDA的表格，并基于安全机制DC值自动估算SPFM/LFM指标 • STEP5，从FMEDA生成故障列表，以进行故障注入模拟，通过导出的故障列表来支持EDA工具进行故障注入测试，以便得到更加准确的DC值 • STEP6，执行故障注入以确定安全机制的诊断覆盖率 • STEP7，更新安全机制的诊断覆盖率和故障注入安全故障比例，基于准确的DC值Medini将自动更新FMEDA表格，并计算相应的硬件指标 此外，Medini Analyze还具备安全需求追溯管理、FTA分析、FMEA分析以及DFA分析等功能。"DC Configurator"功能可以把芯片厂商的安全分析工作以工程文件的形式导出，工具自动收集所有相关的高层架构数据，里面只包含安全分析相关的信息，而不包含芯片的具体设计，从而实现安全分析的信息共享并同时保护知识产权。 经纬恒润从2008年开始研究及实施功能安全，并于同年组建了功能安全团队，从消化ISO-26262标准到参与2017年GB/T 34590功能安全标准的制定；结合自身汽车电子产品研发实践，经纬恒润的功能安全团队在智驾域、底盘域、动力域、车身域实施国内外100+成功案例，积累了丰富的经验。迎合市场所需，结合量产产品功能安全落地实施的技术难点，经纬恒润功能安全团队以智能驾驶功能安全为主题，陆续发布解决方案系列文章，欢迎大家共同探讨！