标签: iso26262

一、VCU应用层监控方案的ISO26262背景 “软件定义汽车”趋势下，更多汽车软件问题与消费者生命安全密切相关。而汽车行业ISO 26262《道路车辆功能安全》是一个国际安全标准，对安装在量产道路车辆上的电气、电子系统的功能安全进行了约束和规定，避免对人身的伤害。 ISO 26262标准将汽车“功能安全（FuSa）”定义为“不存在因电气和电子系统故障所导致的不合理风险”。 功能安全问题不是单纯的硬件系统问题，也不是单纯的软件系统问题，它是一个系统性问题，涉及硬件系统和软件系统两方面的具体操作和流程。在功能安全的开发过程中，所有活动的目的都是为了实现概念阶段经过HARA分析后导出的安全目标（SG），对原有的功能系统进行监控，避免由于E/E系统失效而违反安全目标。 VCU（整车控制器）的SG ，包括避免扭矩输出过大、避免扭矩输出反向等, 大多与扭矩相关。实现VCU的SG，在软件中实现VCU应用层监控的核心，也聚焦在了输出扭矩的监控。 就此本文将通过VCU L2应用层监控方案，讲解如何利用扭矩监控来实现功能安全要求。 二、基于E-Gas标准的监控方案参考 上世纪90年代，电子节气门系统逐步在量产车上得到应用，成为汽油发动机控制系统的核心，由此掀起了汽车电气化控制的浪潮。 与电控系统一并到来的，是人们对电子产品的可靠性的普遍担心，因此几大国际公司联合起草制定了针对发动机的ECU软件架构E-Gas，其中的三层软件架构概念已经得到世界各大OEM和Tier1认可和广泛应用。 E-Gas三层架构图 · Level 1：功能层 计算并执行发动机扭矩、组件监控、输入/输出变量诊断及检测到故障时控制系统反应 · Level 2：功能监控层 监控L1软件功能故障，比如监控计算的扭矩值或车辆加速度；发生故障时，触发系统响应 · Level 3：控制器监控层 功能控制的独立部分，在问答过程中检测程序执行的正确性 功能安全在L1功能层的基础上，开发完成L2和L3部分工作，本文主要介绍L2应用层监控方案。 三、VCU L2应用层监控方案 在功能安全的整个流程中，包括概念阶段、系统阶段、硬件阶段、软件阶段和支持过程，而L2应用层监控方案的开发主要在软件阶段实现。 功能安全开发流程 VCU在进行扭矩管理时，根据司机要求、车辆状态等工况，合理控制电机的工作状态及功率输出，满足驾驶工况要求。包括加减速、恒速、制动和后退的工况。具体的扭矩管理功能如下： ① 对驾驶员需求扭矩进行解析，识别工况和计算驾驶员扭矩 ② 进行扭矩仲裁，协调其他ECU的请求扭矩 ③ 进行扭矩限制，保证零部件安全 ④ 进行扭矩滤波，提高驾驶舒适性 四、VCU L2应用层监控内容 · 输入信号监控 L2监控安全相关输入信号，并进行故障判断和处理，包括踏板、开关硬线信号及电机转速、车速、挡位、ESC请求等CAN信号。 比如：加速踏板信号监控— 加速踏板信号监控与故障处理 · 扭矩监控 L2对各种模式下的扭矩进行解析，对L1计算的扭矩进行监控，并最终进行扭矩仲裁。L2层根据车辆状态判断当前驾驶工况，监控L1计算出的扭矩方向正确性。 比如：方向性监控— 方向性监控流程示意图 比如：绝对量监控-- L2通过扭矩的解析和计算，监控L1计算的MCU目标扭矩是否出现异常偏差，避免非预期加减速(比如：由SG/HARA分析得到的量化值减速度-2m/s²)， 绝对量监控分两部分，分别是同步前扭矩监控和同步后滤波扭矩监控： ① L2通过输入计算驾驶员需求扭矩Tor_L2，若L1计算的驾驶员需求扭矩Tor_L1在Tor_L2加一个安全范围内，则同步前扭矩监控无异常；通过同步前的比较实现较为宽泛的监控，这时只要L2的误差不是特别大，那么L1违背安全目标的非预期加速都能在此时的比较中被监测到 ② 在同步前的比较无故障的前提下，对扭矩进行同步，消除L2扭矩计算的容差，提高监控的精度和准确性、鲁棒性。再通过滤波对扭矩变化趋势做了限定，此时去监控L1的滤波扭矩，可以实现更精准的监控 具体滤波同步的解决方案，可联系经纬恒润进一步沟通。 · 扭矩仲裁 通过仲裁条件，决定VCU扭矩监控模块的输出。若监控无故障，则L1扭矩正常输出；若监控有故障，则进入对应的跛行模式，对输出扭矩进行限制： ① 根据双路加速踏板信号和车速信号监控结果判断进入何种模式，再根据对应的跛行模式的故障处理方式，判定L2计算的扭矩结果 ② 得到L2计算的扭矩结果后，对L1输出的扭矩进行监控，若出现方向性故障，则直接进入安全模式，关断扭矩输出，若出现绝对量监控故障，则根据差值阈值进入相应的跛行模式，对扭矩输出进行降级处理 信号监控对应模式 扭矩监控对应模式 根据以上结果，L2进行扭矩仲裁，若无故障则输出L1请求扭矩，若有故障则按对应方式进行故障处理。 L2扭矩仲裁 采用L2应用层监控方案收益： ① 对功能开发维护 ：通过E-Gas架构实现在L1功能层的基础上增加L2功能监控层，实现功能安全功能与原有预期功能的解耦，避免对原预期功能的全生命周期破坏介入式的影响、所有功能的全新开发测试。只需要开发独立的L2功能补丁，并进行补丁部分的安全功能验证，减少大量全功能的开发修改及功能安全测试工作量 ② 对功能平台化拓展： 方便L1层、L2层功能的移植和拓展，以及平台化和模块化建设。采用L2监控并设计相应的降级策略，在不降低用户使用体验和可用性的基础上，提高安全性，并且可以再持续维护优化降级策略 五、项目实施应用 在某自主动力域控制器项目中，经纬恒润助力用户实现ASILC等级的VCU产品功能安全开发并且拿到认证公司的认证。 · 用户现状 ① 已实现自主动力域控制器的所有功能（QM），完成实车测试。前期开发、测试投入大量的人力、物力、时间等 ② 为满足市场、OEM要求，对产品升级达到 ISO26262产品认证要求 · 项目要求 ① 经纬恒润需提供ISO26262功能安全方案，负责软件中安全相关部分开发验证，尽量避免软件做大量调整，减少原有功能的修改、测试工作；在满足功能安全的情况，选择可以缩短工期的实施方案 ② 该项目为量产项目，因此功能安全的实现需考量软件的可用性和用户的使用体验；经纬恒润需支持从监控组件开发到整车测试阶段安全相关阈值标定的工作 · 项目成果 该项目参考E-Gas标准、符合AUTOSAR架构规范，采用L2应用层监控策略及解决方案，对其原有功能（L1）的监控，实现了对应的安全目标（ASILC）。 经纬恒润帮助用户提出恰当的安全监控策略、完成L2相关功能的开发、单元与集成测试，同时，在安全监控方案中考虑合理降级策略，平衡可用性&安全性。 L1-L2总体架构图 L2监控层 如需获取更新方案信息，可在经纬恒润官网观看8月8日在线研讨会《如何快速开发量产级别功能安全应用软件》和相关主题《智能汽车域控中间件功能安全方案设计及应用》研讨会回放。 了解更多 请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

本期内容以系统架构设计为例，讲解如何在ISO 26262产品开发过程中实施安全分析，半导体层面的芯片设计也可以参考本文相关内容执行安全分析。 安全分析方法 ISO 26262要求根据不同ASIL等级组合地使用“演绎分析”和“归纳分析”，如表1所示： 表1：安全分析方法 根据表1所列信息，开发团队会常常误认为ASIL B是不需要执行“演绎分析”。事实上，ISO 26262的要求对于连续数字（1，2，3……）所列方法，“+”、“++”分别是推荐、强烈推荐实施的。因此，ASIL B也是推荐实施“演绎分析”的（若没有实施，则需要提供理由）。 演绎分析：人们以一定反映客观规律的理论认识为依据，从服从该事物的已知部分，推理得到事物的未知部分的思维方法。即，从一般规律到个例。通常，“演绎分析”方法采用FTA（Fault Tree Analysis，故障树分析）。 归纳分析：人们以一系列经验事物或知识素材为依据，寻找出其服从的基本规律或共同规律，并假设同类事物中的其他事物也服从这些规律。即：从个例到一般规律。通常，“归纳分析”方法采用FMEA（Failure Mode and Effects Analysis，失效模式和影响分析）。 FMEA分析步骤 关于FMEA方法，建议参考AIAG-VDA FMEA手册，市面上已经有很多成熟的软件工具支持FMEA分析。值得一提的是，在根据AIAG-VDA第5版FMEA手册中，增加FMEA-MSR（Monitoring and System Response，监视和系统响应），作为DFMEA的补充。 通常，FMEA按下图所示的七步法进行： 图1：FMEA七步法 1、DFMEA分析步骤 第1步-策划和准备：确定负责人和团队、项目名称、时间安排和分析工具等信息。 第2步-结构分析：结构化分析对象，例如设计系统架构。 第3步-功能分析：产品功能可视化，例如确定系统架构要素的功能。第3步是在第2步的基础上实施的，因此第2步的“要素”和第3步的“功能”是对应的。 第4步-失效分析：每个功能的潜在失效影响，失效模式和失效起因。 第5步-风险分析：分析针对失效起因的现行预防控制；分析针对失效起因和（或）失效模式的现行探测控制。 第6步-优化：识别、实施降低风险的必要措施。 第7步-结果文件化 将上述第1步～第6步的实施情况记录在FMEA模板或分析工具中，形成完整的FMEA报告。FMEA的总结与分析，包含以下内容： a.文件化FMEA过程中的所有分析记录和采取的措施； b.组织内部/顾客/供应商对结果和分析结论进行沟通，组织FMEA评审验证； c.持续跟进预防措施和探测措施的实施情况，定期动态更新AP值，确保在设计定稿前风险已降到可接受的程度。 2、FMEA-MSR 2.1、FMEA-MSR决策流程 FMEA-MSR作为DFMEA的补充，更加关注产品在实际用户条件下的失效，因此进一步地完善了FMEA在安全相关机电系统（所谓机电系统就是系统中至少包括传感器、电子控制器和执行器或它们的组件）领域的应用。在实际项目开发过程中，研发人员容易把DFMEA和FMEA-MSR搞混，导致了许多重复或遗漏的分析工作。 下图展示了FMEA-MSR决策流程，提供了一个DFMEA和FMEA-MSR配合使用的思路。 图2：FMEA-MSR决策流程 1)在上述流程中，若一个失效模式的严重度被评为8、9、10分，则认为是违背法律法规或功能安全要求。 2)若上述1)不成立，继续执行第5、6步的DFMEA分析。可选择性地根据组织现有流程以及改进计划，增加MSR机制。 3)若上述1)成立，则此时需要分析系统是否已经存在针对客户操作期间发生该失效模式的MSR机制。 4)若上述3）不成立，继续执行第5、6步的DFMEA分析，必须增加MSR机制。增加MSR机制后，由于作了设计变更，因此更新DFMEA，更新后上述第3)点成立，执行第5)点。这里需要注意的是，作为MSR本身而言，通过DFMEA来分析即可。 5)若上述3）成立，则此时直接针对该失效模式进行FMEA-MSR分析。 总结上述内容，下图提供一个形成DFMEA文件和FMEA-MSR文件的思路。事实上，两者既可合并在一起，也可以单独形成文件，取决于开发组织自身的流程。 图3：DFMEA文件和FMEA-MSR文件 2.2、FMEA-MSR分析步骤 FMEA-MSR同样采用图1所示的七步法，且仅第5、6步与DFMEA不同，下面只针对这两个步骤的分析展开描述。 第5步-风险分析（FMEA-MSR）：分析失效模式发生频率F（也可称为频度），指系统在实际工作时间内产生失效的频率，该频率需要统计数据论证其合理性；分析针对失效起因的现行诊断监视；分析针对诊断到失效模式后的现行系统响应；分析MSR起作用后的失效影响严重度。 第6步-优化（FMEA-MSR）：识别、实施降低风险的必要措施。 FMEA分析示例 如下图所示，假设现有一个用于ADAS系统的ALC（自动车道居中）的ECU（电子控制单元）的系统架构，其主要功能是从Ext_01接口接收外部传感器SPI数据，作为MCU的路径规划决策输入。 图4：ALC的ECU系统架构 （注：该架构仅方便用于FMEA分析，不考虑其内部合理性，不作为真实架构用途） 1、DFMEA的分析示例 以下示例假设其中一个模块（Sys_element01）故障，假设ECU针对Sys_element01故障没有任何诊断监视措施，按照DFMEA的分析步骤展开。 图5：带故障的ECU 1）识别每个模块的功能，例如Sys_element01的主要功能是向MCU传输传感器数据；（DFMEA第3步） 2）识别模块的失效行为，例如Sys_element01故障导致传感器数据错误、延迟、丢失等；（DFMEA第4步） 3）确定传感器数据错误将导致的后果严重程度（得到严重度S评分），例如：该故障发生时导致MCU路径规划错误，影响行车安全，严重度达到S=10；（DFMEA第4步） 4）确定是否存在预防控制措施，例如，该系统架构使用可信的设计方案、使用鲁棒性设计、通过设计评审等；（DFMEA第5步） 5）定在上述预防控制措施之下该模块的故障频度（得到频度O评分），例如：已使用可信设计、鲁棒性设计、设计评审后，故障频度可降至O=2；（DFMEA第5步） 6）确定是否存在探测控制措施，例如，功能测试、故障注入测试、DV测试、量产测试等；（DFMEA第5步） 7）确定上述探测控制措施的探测度（得到探测度D评分）；例如：实施功能测试、故障注入测试、DV测试、量产测试后，探测度可达D=3；（DFMEA第5步） 8）根据S、O、D评分，综合得出措施优先级AP值，AP=L；（DFMEA第5步） 9）必要时，根据AP值，制定进一步的风险降低措施；（DFMEA第6步） 10）文件化将上述分析步骤。（DFMEA第7步） 根据第3)步骤显示，该示例中的ECU是一个安全相关的机电系统，且存在失效模式导致违背功能安全，满足2.1节FMEA-MSR决策流程第4)的条件，在后续的设计优化中必须增加MSR机制。 2、FMEA-MSR的分析示例 本节基于前面1节DFMEA的分析示例的ECU示例，在其基础上增加了MSR机制，优化了该ECU的系统架构，如下图所示。其中绿色模块（安全相关）为分配了ASIL等级的安全需求，灰色模块（非安全相关）开发为QM要素。其中： · Sys_element04开发为安全要素； · 增加Sys_element06用于诊断来自Sys_element01的数据的正确性和一致性； · 增加Sys_element07故障收集和诊断模块； · 增加Sys_element08用于诊断MCU内部失效。 图6：优化后的ECU系统架构（注：该架构仅方便用于FMEA分析，不考虑其内部合理性，不作为真实架构用途） 下面同样假设其中一个模块（Sys_element01）故障，假设ECU针对Sys_element01故障已经采取诊断监视措施，按照FMEA-MSR的分析步骤展开。 图7：带故障的ECU及其诊断路径 1）识别每个模块的功能，例如Sys_element01的主要功能是向MCU传输传感器数据；（FMEA-MSR第3步） 2）识别模块的失效行为；例如：假设Sys_element01（SPI通信模块）故障导致传感器数据错误；（FMEA-MSR第4步） 3）确定传感器数据错误将导致的后果严重程度（得到严重度S评分），例如：该故障发生时导致MCU路径规划错误，影响行车安全，严重度达到S=10；（FMEA-MSR第4步） 4）确定该模块的故障频率（得到频率F评分），例如，这里假设Sys_element01在其使用生命周期内故障发生的概率非常低（实际项目中应结合可靠性预测结果来评估），频率F=3；（FMEA-MSR第5步） 5）确定系统中是否有监控措施（即监视和系统响应，或者称之为安全机制）及其监控能力，例如，该Sys_element01发生故障时，不能通过Sys_element06的校验，由Sys_element07向上级系统发出错误警报（如图7红色曲线路径所示），假设该安全机制的诊断覆盖率为99%，监视则可评定为M=3。在汽车功能安全中，一个非常重要的概念是FTTI（故障容错时间间隔），如下图所示。 图8：功能安全概念中的时间约束 FTTI可以用来衡量安全机制的有效性，它来自车辆层面的安全目标，用于表示车辆部件在某个场景下发生故障直到产生对人身产生危害事件的这段时间间隔。进一步地细分，相关的时间概念还有FDTI（故障检测时间隔离）、FRTI（故障响应时间时间）以及FHTI（故障处理时间间隔）。在设计监视和系统响应机制时需要考虑上述时间约束，确保系统或子系统满足分配其的时间要求：FDTI + FRTI = FHTI < FTTI。（FMEA-MSR第5步） 6）分析在MSR起有效作用后，即系统响应安全机制后失效的严重度；例如，如上述第5)点的监控措施启动后，车辆通知向驾驶员发出接管方向盘的警示，尽管车道偏离可能已经偏离，但在FTTI的时间内驾驶员已经及时接管方向盘并将方向回正（假设驾驶员有能力处理这种情况），此时原先定义的严重度可适当降低到S=6；（FMEA-MSR第5步） 7）根据S、F、M评分，综合得出措施优先级AP值，AP=L；（FMEA-MSR第5步） 8）必要时，根据AP值，制定进一步的风险降低措施；（FMEA-MSR第6步） 9）文件化将上述分析步骤。（DFMEA第7步） 这里需要注意的是，如2.1FMEA-MSR决策流程第4）点所述，对比DFMEA的分析示例： · Sys_element04由于设计变更（由原先的QM要素开发为安全要素），需要更新其先前的DFMEA结果； · 新增Sys_element06~08的三个模块，需要新增它们的DFMEA。 广电计量功能安全服务能力 广电计量在汽车、铁路系统产品检测方面拥有丰富的技术经验和成功案例，能为主机厂、零部件供应商、芯片设计企业提供整机、零部件、半导体、原材料等全面的检测、认证服务，保障产品的可靠性、可用性、可维护性和安全性。 广电计量拥有技术领先的功能安全团队，专注于功能安全（包括工业、轨道、汽车、集成电路等领域）、信息安全和预期功能安全领域的专家，具有丰富的集成电路、零部件和整机功能安全实施经验，可根据相应行业的安全标准为不同行业的客户提供培训、检测、审核和认证一站式服务。 广电计量半导体服务优势 工业和信息化部“面向集成电路、芯片产业的公共服务平台”。 工业和信息化部“面向制造业的传感器等关键元器件创新成果产业化公共服务平台。 国家发展和改革委员会“导航产品板级组件质量检测公共服务平台”。 广东省工业和信息化厅“汽车芯片检测公共服务平台”。 江苏省发展和改革委员会“第三代半导体器件性能测试与材料分析工程研究中心。 上海市科学技术委员会“大规模集成电路分析测试平台”。 在集成电路及SiC领域是技术能力最全面、知名度最高的第三方检测机构之一，已完成MCU、AI芯片、安全芯片等上百个型号的芯片验证，并支持完成多款型号芯片的工程化和量产。 在车规领域拥有AEC-Q及AQG324全套服务能力，获得了近50家车厂的认可，出具近400份AEC-Q及AQG324报告，助力100多款车规元器件量产。

大多数原始设备制造商不会从电动汽车（ EV ）的销售中获利，但计划快速进入市场的电动汽车初创公司不必遭受同样的损失。 随着电池价格飙升、零部件成本高昂和销量低迷，电动汽车初创公司的盈利能力逐渐下降，必须将软件开发视为提高预算、进度和工作水平的一种方式。了解电动汽车软件开发面临的主要挑战有助于初创公司领导者找到解决这些问题的途径。 正如我们在 这篇博客中 所解释的那样，收回成本并不一定意味着提高车辆价格或裁员 —— 相反，它是关于在高度复杂和受监管的软件环境中寻找更智能地工作的选择。 电动汽车软件开发的范围 每辆电动汽车都是车轮上的软件平台，因此设计、编写和验证代码是寻求开发效率的第一步也就不足为奇了。车辆组件可以分解为不同的软件域，以帮助您了解对工作量、预算和进度的影响。 对于电动汽车初创公司来说，这些领域在很大程度上倾向于具有重要功能安全和安保要求的新型前沿软件组件。与传统的原始设备制造商不同，初创公司必须从头开始建立这些能力，同时还要管理投资者信心、开发人员招募和监管合 规 等业务现实。 电动汽车初创公司应关注的 3 个 挑战 除了上市时间和供应链问题外，以下是影响电动汽车软件开发的三个最大挑战，以及开发团队如何解决这些问题。 1. 通过遵守标准来保护消费者和企业 开发人员可能认为，遵守汽车安全和安保标准会降低创新和发布里程碑的速度。现实情况是，标准和准则提供了一个预定义的框架，用于保护业务免受现场代价高昂的故障的影响。 三种常见的汽车标准包括： ISO 26262 认证 ISO 26262 标准 规定了功能安全流程，以减少对车辆乘员的危害，并基于称为汽车安全完整性等级（ ASIL ）的风险分类系统和证明合 规 性的开发工件的验证。 MISRA MISRA 由制造商、组件供应商和工程咨询公司开发和维护，为 C 和 C++ 提供了编码指南，以帮助代码确保安全性、可靠性和可移植性。 CERT CERT 编码标准 是由软件开发和软件安全专业人员社区开发的 C 、 C++ 和 Java 准则，旨在帮助确定违反该特定规则或建议的可能后果。 电动汽车初创公司在标准合 规 性方面面临着艰巨的任务：规划、测试和报告必须从头开始纳入开发流程。如果被推迟或忽视，随着发布窗口的缩小和监管机构要求提供证据，缺乏合 规 框架将威胁到原型和消费者交付。 2. 尽量减少通货膨胀的影响 通胀压力正在破坏整个汽车供应链中已建立的定价模式，并限制消费者的购买力。电动汽车初创公司不能等待有利的市场条件，但它现在可以在软件团队中寻找机会，创造成本效益高、可持续的实践。 初创公司的好处是开发人员没有时间请求许可来测试和采用新工具来简化他们的工作。他们正在积极研究任何有助于他们专注于重要事情的事情：提供强大且符合要求的新功能。开发领导者可以通过了解以下内容来加速这种灵活性： • 当前处于开发过程中的所有应用程序和工具 • 新工具卸载手动工作和提高工作产出的机会 • 每种工具的所有权和责任 • 谁访问 它们以及访问频率 • 每个用户 / 团队的每个工具的成本 • 工具和流程中的冗余 • 许可条款和续订日期 3. 采用有效的自动化技术 鉴于对标准 和安全合 规 性 的严格要求 ，电动汽车初创公司可以在 这里利用 静态分析工具等自动化技术： • 编码标准合 规 性 — 识别违反安全和安保标准中规定的规则和准则的情况。 • 代码覆盖率合 规 性 — 满足 ISO 26262 代码覆盖率要求，如语句、分支和 MC/DC 。 • 问题优先级 — 根据风险对问题进行排名，以避免浪费时间或对开发人员造成 “ 问题疲劳 ” 。 通过静态分析将电动汽车初创公司的创新成本降至最低 现在是电动汽车初创公司明智地减少浪费的时候了。随着通货膨胀造成供应链波动，市场监管壁垒越来越高，电动汽车软件开发团队现在必须优化支出并培养 其工具 和流程的弹性。 Perforce 静态分析和 SAST 工具通过精确准确的静态代码分析工具，确保代码质量、可靠性、安全性和安全性的持续合 规 性，从而简化有效的电动汽车软件开发。从概念验证到移植到新车型， Helix QAC 和 Klocwork 保持了高开发速度并降低了市场风险。 欢迎联系北汇信息获取试用~

基于需求的测试，是在汽车电控单元软件测试中的基本要求，也是ISO26262中的动态测试的强烈推荐的测试方法。 为了保证整个测试过程的正确高效，需要对测试需求和测试用例进行有效管理 ， 例如能够从需求管理工具中将需求导入，再将测试用例和需求链接起来，并且实现数据的双向同步等。 汽车行业常用需求管理工具中，主流的产品包括DOORS及Reqtify 等，对 产品 整个生命 周期进行 需求 管理 。借助需求管理工具DOORS/ Reqtify ，TPT可以实现对测试需求导入、测试用例创建、测试需求与测试用例链接 ，实现 整个测试过程追踪追溯，以满足ISO26262的要求。 德国PIKETEC公司的 TPT 软件作为汽车行业著名的针对嵌入式系统基于模型的测试工具，几乎 包含了所有常见嵌入式软件的支持平台，适用于整个电控开发测试过程， 可以实现测试用例的复用，并且实现了测试执行、测试评估和测试报告生成的整个过程自动化。针对 MATLAB/Simulink/Stateflow 、ASCET以及 TargetLink 等， TPT 提供了全方位的支持进行模型测试。北汇信息作为PKETEC公司的 合作 伙伴，将为客户提供相应的产品支持和测试服务。 TPT 对需求管理的支持 支持创建和管理需求与测试用例之间的关联 支持需求变更后的冲突分析 支持在TPT中对需求进行浏览 支持IBM Rational DOORS 、 Reqtify 支持从需求管理工具导入测试需求 支持测试用例导出到需求管理工具 支持从需求管理工具导入测试用例 支持在需求管理工具和TPT之间同步测试用例 支持 需求覆盖报告 下面 以DOORS为例，来介绍TPT 对需求管理 的支持。 从DOORS 导入 测试需求 TPT可以很好 地 实现与需求管理工具DOORS的交互。在TPT安装目录下， 带有 与 DOORS交互的接口程序，将该程序拷贝到DOORS的安装目录相对应的文件夹下，即可在DOORS的菜单栏 下 找到TPT选项。 通过 TPT 选项 ，可以实现向TPT导出测试用例、测试需求以及导入TPT创建的测试用例等。 可以在TPT里，加载DOORS导出的测试需求。 如 Fig. 1 所示。 Fig. 1 需求链接 在TPT里，将导入的测试需求与构建的测试用例进行关联（Link）。如Fig.2所示的Test Case对应Requirement里边的ID为 1/3/4三个测试需求。每一个测试需求都会在Linked Objects显示。 Fig.2 测试追踪 每一个测试测试需求下边都注明了关联的测试用例。双击该测试用例，TPT会自动跳转到该测试用例，方便测试人员进行追溯。如Fig.3所示。 Fig.3 冲突分析 如果在DOORS 对测试需求进行更新 ，在TPT 里 进行同步化之后 ，则变化的测试需求以及与 该测试需求 相关的测试用例都可 以直观 体现 ，相关的test case会有颜色变化 。 可以在Modification s 查看 更改前后的测试需求内容 。 如Fig.4所示 。 Fig.4 需求 覆盖报告 在测试完成后， 可以 查阅测试需求报告 ，报告支持 HTML 以及PDF版本 。在报告中，可以查阅每个测试需求动态 覆盖 情况以及 对应的测试用例的执行 结果 。 在 TPT里，可以通过添加脚本评估条件， 得到 测试需求的动态覆盖报告 。 如Fig. 5 所示 ， 可以 查阅 每个 测试需求的动态覆盖情况，比如 TestCase 3 里边关联 的测试用例的执行情况 。 Fig.5

一、ISO26262的起源 安全性是汽车研发制造最关注的要素。 一款新型汽车无论集成多么先进的驾驶功能，设计者都需要提供充足的证据以证明新增加的功具备足够的安全性以满足整车安全的要求。 随着汽车电气化和智能化程度的提高，整车电气和电子系统的复杂性也随之提升。电子/电气系统复杂性的提升带来了系统失效和随机失效风险的增高，随之带来的汽车安全的不确定性，这成为了当今汽车智能化变革路上最大的挑战。 2011年国际标准化组织道路车辆技术委员会基于IEC61508（2000年首次发布）对“道路汽车” 的电气/电子系统的特殊安全性进行了梳理，提出了与汽车功能安全相关的电气/电子硬件和软件以及相关组件在设计、生产、服务以及报废全生命周期的安全要求及验证要求。ISO26262《公路汽车功能安全性》正式诞生。目前ISO26262认证是产品进入汽车电子/电气零部件及系统供应链体系的必要条件。 二、ISO26262的具体要求 ISO26262为车辆全生命周期（包括产品研发、生产、使用、维保和报废）中保证电子/电气系统的功能安全提供了相应的安全保证措施，如提供了如何评估/改善/验证安全性的要求、方法和管控流程，同时还提供了包括机械、液压、气压等其他技术在内的安全性保证框架。 ISO26262从整车功能安全性角度出发，通过对功能相关项的危害分析、风险评估、确定汽车安全完整性等级（ASIL），进而确定安全目标。 为达成安全目标，细分了功能相关项，组成相关项的电子/电气系统，组成系统的各组件，以及组成各组件的元器件几层，针对每个层级制定相应的功能安全概念和技术安全概念，并通过评审、验证等手段对相关项安全性是否达成和有效进行评价。 评审一般针对在系统开发过程中，为达成相关项安全目标所做工作而形成的工作成果而进行评审（走查/检查/认可评审），工作成果包括约86类成果文件，涵盖了从产品概念提出阶段直至报废全生命周期功能安全活动的文档资料，也包括研制方和供应商的管理文件。 对于电子组件和元器件研制和制造者，ISO26262提供相应的安全认证指南。针对ISO26262进行专门开发的电子组件或元器件，需按照ISO26262-5的开发要求安全活动进行开发和验证。 而对货架电子组件或元器件，开发阶段并没有引入ISO26262的安全概念，需根据ISO26262-8对硬件要素的评估要求进行安全功能评估和背离安全目标风险评估。对于此类货架电子组件和元件器在评估时，根据产品的特性、评估难度的差异以及要素在安全概念中的作用进行分类（Class Ⅰ-Class Ⅲ）。 三、Class Ⅰ-Class Ⅲ Class Ⅰ Class Ⅰ类组件或元器件属于最简单的认证要素（电子组件/元器件的统称），被动元件和分立器件属于此类要素，共性特点工作模式较少，工作参数能够全面评价且内部没有故障诊断和控制机制。 在ISO26262-11-2011版本中，此类被评估要素只需经过ISO16750或AEC-Q相应的标准认证即可，而在2018版本中，此类要素不需要进行单独评估，而是在更高的集成层面进行评估即可。 Class Ⅱ Class Ⅱ类要素的特点是工作模式多样，但内部同样不具备安全诊断和控制机制，如传感器，没有集成IP内核的集成电路属于此类要素。此类要素的评估需按照ISO26262-8采用分析（对数据、文件、模型、记录的分析）和测试（针对功能，使用环境的安全性进行试验验证）进行评估，被评估的要素对外界应力的鲁棒性测试按照ISO26262-5进行评估。 评估的目的是分析和验证要素的功能性能是否能够符合其规范，以及满足其预期用途。这些性能要求应充分考虑被评估要素在正常环境下以及造成故障发生环境下的性能要求。 Class Ⅲ Class Ⅲ类要素的特点是工作模式多样，而且必须要在考虑实际工作情况下才能对其功能性能进行评估，内部嵌入安全诊断和控制机制，如MCU、DSP、集成IP内核的集成电路属于此类要素。对Class Ⅲ类要素评估最为复杂和苛刻，此要素除了要满足如Class Ⅱ类要素安全评估各项要求外，还要采用额外的评估措施，以能够说明背离安全目标和安全要求的风险足够低。额外的评估措施包括但不限于： a) 需要根据具体的使用功能和使用环境完成安全相关功能的验证。 b）最好具备类似使用场景的使用历程，以作为硬件安全评估的支撑依据。 c）硬件内部要具备独立多样化的执行诊断功能的内核，能够进行芯片安全性的监控。 d）硬件的开发过程执行了某些安全标准，且安全标准与ISO26262的ASIL等级相当。正因如此ISO26262中对非按照ISO26262开发的Class Ⅲ类要素的评估是不建议采纳的，希望此类要素能够在未来的升级时充分按照ISO26262-5硬件层开发要求进行升级。 ISO26262-2018版本相比于2011版本增加了ISO26262-11《应用于半导体开发指南》，专门针对半导体组件及元器件的开发过程提供了方法和用例。 四、广电计量的服务能力 广电计量具备专业技术团队，开展以产品安全功能验证为特色的ISO26262认证技术支持服务。以产品功能安全达成为目标，为客户提供ISO26262安全体系建立，产品各阶段技术安全概念建立与达成，辅导客户相关认可及验证评审等提供专业一体化的技术服务。 特色服务包括： ●芯片功能安全需求分析。 ●芯片结构分析。 ●基础失效率分析与计算。 ●软错误率测试与评估。 ●FMEA和HAZOP分析。