标签: 车规级认证

市场背景 随着科技水平的快速发展，5G时代来临，汽车的自动驾驶功能已经越来越广泛地被运用在实际生活中。 激光雷达以其具备高精度和高适用性、高环境感知力作为自动驾驶和高级驾驶辅助系统的核心硬件之一，也迎来了发展新机遇。据相关数据显示，激光雷达整体市场正在迎来高速发展，预计2023年全球搭载激光雷达的车辆就将突破30万台，2025年全球市场规模将达到135.4亿美元(约合870亿元人民币)，前景十分可期。 激光雷达“点云”图 资料来源：搜狐汽车，长江证券研究所 激光雷达光电组件 激光雷达主要包括激光发射、扫描系统、激光接收和信息处理四大系统。激光发射和激光接收是激光雷达的光电组件部分。 其中发射模块中的激光器发出脉冲激光，通过光束控制器、发射光学系统，将激光照射至目标物体，常见的激光发射器包括边发射激光器（Edge Emitting Laser，EEL）、垂直腔面发射激光器（Vertical Cavity Surface Emitting Laser，VCSEL）。 而接收系统将目标物体反射回来的激光转化为接收信号，主要包括雪崩二极管（Avalanche Photo-Diode，APD）、单光子雪崩二极管（Single Photon Avalanche Diode，SPAD）、硅光电倍增管（Silicon photomultiplier，SiPM）。 激光雷达结构拆分 资料来源：麦姆斯，长江证券研究所 808nm VCSEL Diodes(2-10W)_ 新亮光子（brightphoton.cn） 雪崩二极管（APD）_ 光传感器_滨松（hamamatsu.com.cn） 车规AEC-Q可靠性的要求 基于激光雷达在汽车中的应用场景和汽车自身的高可靠性要求，激光雷达及其组件要进入车用供应链，必须通过严苛的可靠性验证。 AEC-Q102是公认、通用的光电半导体国际可靠性验证标准，可为相关产品提供全面详尽的验证方案。 中国是全球最大的新能源汽车市场，新能源汽车产品力的不断提升，促使产业供应链不断重塑优化，给国内的激光雷达产业带来了新的机遇。而激光雷达的核心光电部件(激光器、探测器)的车规验证是证明质量与可靠性的重要手段。 AEC-Q102验证可有效解决国产元器件不敢用、怎么用的问题，帮助其扎根车规供应链。 AEC-Q102中对激光雷达组件的可靠性要求主要分为环境应力加速试验、加速寿命模拟试验、封装完整性测试、电气特性验证试验、腔封装完整性验证试验。试验要求零失效，且只有通过相对应的标准规定的全部测试项目，供应商才能声称该产品通过了相应的AEC-Q认证。 AEC-Q102流程图 来源：AEC-Q102 Rev A标准 近年来激光雷达光电组件厂商在国内市场逐渐涌现，元器件的制造技术和结构设计不断更新，给元器件验证技术手段的带来了新要求。 对于激光雷达组件的AEC-Q102中环境应力和寿命试验，主要存在批次或批量性验证一致性、施加应力过程监控、应力条件达不到标准或器件故障模型的要求、标准条款适用性解读等问题。例如VCSEL的短脉冲加电试验、APD光照下HTRB、应力后功能验证问题。 广电计量是国内第一家完成激光发射器、探测器全套AEC-Q102车规认证的第三方检测机构，具备APD、VCSEL、PLD等批次性验证试验能力，能实现对APD等器件全过程雪崩电流的监控以及光照下的HTRB试验能力。在人才队伍上，形成以博士、专家为核心的车规验证团队，具备国内最权威的车规标准解读能力和试验能力，能够提供一站式车规认证方案。

验证的基本形式 验证是ISO26262中关于成果认可最重要的环节。 ISO26262对验证（Verification）的定义是检查对象是否满足特定的要求，验证的形式包括了验证评审（verification review）、走查（walk-through），检查（inspection）、验证测试（verification testing）、模拟仿真（simulation）、原型机验证（prototyping）和分析（analysis包括安全分析、控制流程分析、数据流分析等等）。 从验证本身的系统性和正式程度从小到大排序，验证的各个形式可以排为检查、走查、模拟仿真、原型机验证、分析、验证评审。 验证在功能安全活动不同阶段的对象也有差异，比如在产品概念提出阶段，验证的对象主要为：依据危害风险评估导出的安全目标以及根据安全目标定义的功能安全概念，如场景危害识别是否适用、相关性定义是否正确、是否与其他相关项定义的危害和风险评估一致、危害事件是否覆盖实际应用等。如，在产品开发阶段，验证主要是针对硬件设计的架构，验证其需求规范、架构设计、模型或代码是否符合安全要求。 验证的基本程序 验证以建立验证计划作为开始，如上述的产品各个开发阶段的验证都是从验证计划开始的。 验证计划要包括 1）所需验证的对象：组成待验证的成果清单，要考虑成果的复杂性，进行适当的拆分； 2）针对每个待验证的成果，确定相应的验证目的，确定验证目的时要充分借鉴前期的验证经验，如维修的历史数据、已经使用的经历等，这可以指导验证目的和制定的验证方法的剪裁； 3）对工作成果采用什么样的验证方法，评审/检查/走查/测试/仿真/分析，验证方法最终要细化为“验证规范”作为验证支持依据，同时要保证验证方法是充分的，必要时要进行几种验证形式的组合； 4）如果采用的是测试或者模拟作为验证方法，则要明确验证的环境和验证所需的设备，要充分考虑验证技术的成熟度，不能采用最新的未经过经验证明有效性的方法和设备进行验证； 5）分配验证资源； 6）验证过程中出现异常时，明确应该采取或建议采取的闭环活动； 7）对于哪些已经经过验证后，进行了变更的成果，制定回归策略，即对验证计划的剪裁（是部分重复验证，还是全部重复验证）。 对于验证方法的细化就形成了验证规范，验证规范最需要细化的是测试用例。 测试用例应具有 1）测试用例的唯一识别性，即该测试应用到哪项成果，什么目的验证； 2）测试用例针对的是哪个版本的工作成果； 3）对验证目标采用何种预处理或配置，比如将MCU应用在什么场景下，配置什么功能或系统，如果对于通用型的要素，其会在很多场合应用，则需将要素置于一种通用的（覆盖多种应用场景的）条件下进行验证； 4）环境条件，就是与测试过程或模拟过程相关的物理条件，比如温度。 5）验证过程中要监测的行为，比如输出数据，可接受的范围，时间或容差的特性，测试时需要考核前后数据的变化趋势，就需要对初始值进行明确的定义；有可能存在不同的测试用例下，会存在多种预处理、配置或环境条件和规范，这时候可以采用一种明确能覆盖多种测试用例的验证配置进行验证。 6）测试通过和不通过的判据。 测试用例可以根据测试设备和测试环境、逻辑和时序关系、所利用的资源进行分组，比如对于可以分为回归测试用例或者完整的测试用例。 验证要求第二/三方验证，即不能用工作成果的完成人进行验证。验证完成后要对验证的结果进行评估。 验证结果评估需包括 1）评估验证的成果是不是唯一的； 2）评估验证计划和验证规范的完整性和适用性； 3）评估验证过程中所用到的环境配置、验证工具及标定数据是否符合要求； 4）评估验证结果与预期结果的一致性； 5）综合给出验证通过或不通过，并对于不通过的给出具体的理由以及整改建议； 6）如果存在验证过程未按照验证计划或规范执行，需要给出理由。 单一层级的验证，比如只针对开发的硬件进行功能、性能等安全性的评估，并不能提供硬件满足安全要求的充分证据，比如：硬件与其他接口兼容性、硬件与其他已有硬件的匹配性、硬件对整车安全的贡献性、硬件开发的种种假设证明的有效性等等，这些都无法单独在硬件验证的层面进行评估。 因此，为充分评估开发硬件的功能安全，往往要通过将硬件与软件、其他要素、系统甚至整车集成起来，按照“验证原型机测试”的标准去考核。 ISO26262给出集成测试的相关规定。 集成与验证的相关规定 关于集成测试，某一开发的硬件要通过三个阶段集成至整车系统，完成安全目标的确认。 集成测试是以软硬件集成为起点，而整车级的验证对安全目标是否达成是最具权威的。 但是从集成的难度和所需要的资源的考虑，集集成阶段越高，集成验证的难度越高，占用资源越多，因此尽可能选择低阶段的集成策略。 如何选择集成验证的策略： 1）明确需要验证测试的目标，比如要验证安全机制对传感器的诊断，EDC对数据错误的诊断和控制等； 2）定义这些承载这些测试目标的相关项和测试的要求（预期的行为，集成的等级），比如验证开发的硬件与接口的兼容性，就必须考虑硬件与系统的集成； 3）确定了测试的目标和承载这些目标的相关项和测试要求，要进行梳理，确保每一条测试的目标都能够进行至少一次地验证，比如某项测试目标无法在软硬件集成阶段进行验证，则需要到系统集成阶段进行验证； 4）要考虑硬件开发概念阶段是否采用了假设，如SEooC的开发，是基于应用假设为前提的，对这种假设需要在系统，甚至是整车的层面进行集成验证； 5）如果系统集成时，存在多个可能的集成变体，即所谓的多配置，那么我们就要充分评估，在未来整车量产时，可能采用哪些系统配置，尽可能地包络这些系统配置（或形成系统的集合）完成系统级的验证。 确定目标和相应的集成策略后，根据需要选择相对应的方法，ISO26262 part4 第7.4.2-7.4.4给出了三个集成阶段的测试方法，总体上包括： A 鉴定式的测试 1）功能和非功能的测试：对集成硬件的功能和性能对照规格书要求的测试； 2）内外接口测试：包括模拟，数字输入输出测试、边界测试和等价类测试，评估接口功能兼容性、时序容错性。 B 仿真与试验相结合测试 1）故障注入测试：采用特殊方法向运行中的测试对象注入故障，如骚扰、错误数据、延迟时序等； 2）背靠背测试：在具有仿真模型和结果的情况下，采用实际试验对仿真模型和结果的差异进行评估和分析。 C 基于经验性测试 1）错误猜测法测试：类似故障注入法，基于专家知识和经验数据预测被测对象可能错在的错误，然后设计评估方法去检查这些错误； 2）来自现场经验的测试：直接从使用现场采集的数据，如试车时的运行数据； 3）长期测试：类似来自现场经验的测试，只是将普通用户作为测试者，收集实际使用条件下的数据。 D 鲁棒性测试 1）资源使用测试：对集成系统所能容纳的最大负载，代码，功率等能力进行测试； 2）压力测试：测试对象在高负载和恶劣环境下是否能够长期稳定运行的能力进行测试。

独立安全要素的应用场景 ISO26262针对为不同应用场景和不同客户开发的通用安全相关要素，规定了其相应的开发要求，称这种要素为独立安全要素（Safety Element out of Context-SEooC）。 顾名思义，“独立安全要素”的存在不是为了某个特定的安全相关项或为了某种车型而设立，而是针对 ▶一套系统 ▶一系列系统组合 ▶子系统 ▶软件 ▶硬件 ▶元器件（如ECU、MCU） ▶使用通讯协议的软件 ▶汽车开放系统架构（AUTOSAR）软件等而设立 独立安全要素的特点 与ISO26262有相应鉴定方法的复用成熟软件或是货架产品硬件不同（此类产品在开发之初不考虑ISO26262的相关系列标准），SEooC的开发过程是基于一系列安全要求假设基础上，充分按照ISO26262的标准要求进行的开发设计。 ISO26262给出了四种情况来描述不同的硬件或软件的认证状态类型，如下表所示，设计者或用户可以根据需要选择要开发或者评估相应的要素。 独立安全要素的安全要求 在开发SEooC时，设计者往往无法从用户方得到明确的安全要求。针对这个问题，ISO26262要求在开发独立安全要素前，要进行适当的假设，假设独立安全要素可能适用的更高层级要素分配的安全要求，或者是为了配合其他同层级别要素实现安全功能而分配到的安全要求。 如何保证这些假设在相关项层面是成立的？ISO26262中规定了，在开发SEooC时进行假设需要在更高层级的相关项开发时，进行验证或评估，如： 当SEooC在与实际的相关项集成过程中，通过考量相关项对SEooC的应用要求（环境要求，功能要求，外围要求）等，对比SEooC的开发假设是否与这些要求吻合，进而确认假设是否成立，如果出现“差异”就需要进行“影响分析”： 1）如果差异不会造成违背相关项的安全目标，就认为SEooC的开发假设与实际的差异是可接受的； 2）如果差异造成了违背相关项的安全目标，但通过安全度量计算满足系统目标安全等级要求，差异可接受； 3）如果差异造成了违背相关项的安全目标，而且无法满足系统安全等级要求，可以对相关项的定义或功能安全概念进行变更； 4）如果差异造成了违背相关项的安全目标，而且无法满足系统安全等级要求，又无法对相关项的定义或功能安全概念进行变更，则需要对SEooC进行变更，以适应差异带来的影响。 以MCU作为SEooC为例 MCU实际集成到更高层级的系统或相关项时，MCU作为SEooC的相应的假设要进行逐项分析： 1）对内的技术安全要求是否能够符合系统或相关项的安全目标的要求； 2）系统或相关项的配置是否能够符合MCU对外的技术安全要求的假设； 如果发现假设与实际情况不匹配，则需要采取硬性分析和相应的技术变更。 关于广电计量半导体服务 广电计量在全国设有元器件筛选及失效分析实验室，形成了以博士、专家为首的技术团队，构建了元器件国产化验证与竞品分析、集成电路测试与工艺评价、半导体功率器件质量提升工程、车规级芯片与元器件AEC-Q认证、车规功率模块AQG324认证等多个技术服务平台、满足装备制造、航空航天、汽车、轨道交通、5G通信、光电器件与传感器等领域的电子产品质量与可靠性的需求。 我们的服务优势 ● 配合工信部牵头“面向集成电路、芯片产业的公共服务平台建设项目”“面向制造业的传感器等关键元器件创新成果产业化公共服务平台”等多个项目； ● 在集成电路及SiC领域是技术能力最全面、知名度最高的第三方检测机构之一，已完成MCU、AI芯片、安全芯片等上百个型号的芯片验证； ● 在车规领域拥有AEC-Q及AQG324全套服务能力，获得了近50家车厂的认可，出具近300份AEC-Q及AQG324报告，助力100多款车规元器件量产。