发动机ECU HIL测试介绍
什么是HIL仿真?
在闭环控制系统中,被控制系统的当前状态通过传感器测量馈回控制器。对于汽车来说,电子控制单元(ECU)使用这些测量值来确定适当的执行器值,以获得所需的工作条件。 例如,发动机ECU接收有关节气门位置、发动机转速和排气氧含量的信息,以确定燃油喷射器位置、点火正时和进气口对应的执行器命令,以保持最大的发动机性能和 减少有害尾气排放。最终还是需要对整个系统进行物理测试; 但是通过HIL仿真,工程师 可以在没有车辆甚至发动机的情况下彻底测试ECU,获取重要的信息。
图1. 硬件在环测试系统包含了模拟ECU工作环境所需的几个关键功能
通过HIL仿真提高效率
HIL仿真可重现与ECU交互的物理系统,并执行激励信号生成和测试结果数据记录等测试执行功能。发动机ECU的激励生成可能需要创建一系列期望的发动机速度(以模拟踩下油门踏板)和车辆载荷(以模拟各种道路状况)。同时需要观察整个系统以确保所有组件正确运行,并记录测试结果,以便与理想的系统响应进行比较。
虽然HIL仿真并不能完全取代物理测试,但它确实可通过以下优势来降低测试成本以及提高产品质量:
- 在开发过程中更早地进行测试—更及时地发现设计错误,减少修正成本以及对上市时间的影响
- 降低测试成本—无需使用物理系统,减少测试连接件的购置、维修和维护费用
- 增加测试覆盖率—在无法进行物理测试的极端条件下测试ECU,避免安全和设备损坏问题
- 提高测试灵活性—扩展测试功能,无需考虑外部因素(例如:即使在炎热的夏天,也可以模拟冬季道路状况,以便测试车辆)
- 提高测试可重复性—隔离ECU的缺陷,即使这些缺陷仅在某些情况下才发生
图2. 典型的HIL测试系统包含许多常见的硬件组件
HIL测试软件基础
组织采用HIL仿真的基本动机是提高其开发和测试过程的工作效率。用于HIL仿真的硬件和软件工具需要能够帮助工程师专注于测试ECU,而不是忙于配置、支持和维护测试系统。 HIL测试软件应该兼顾易用性和灵活性,以适应不断变化的要求。 HIL系统的价值取决于所能节省的时间和提高的产品质量。
仿真基础
对象模型和模型来源
在HIL测试,通常使用仿真模型来“欺骗”被测嵌入式设备(DUT),让DUT觉得自己正在控制一个真正的机械系统。机械系统的物理学机制可使用数学工具来重现,这些工具生成的信号通过电线传输并连接到DUT。过去,物理仿真是一个极具挑战性的过程,需要深入了解与机械过程相关的数学原理,如流体动力学、应力特性和材料特性。
图3. 使用各种建模环境来确保高效且有效的HIL测试
今天,有许多商用现成(COTS)工具可用为物理和电气系统建模,而且不需要了解系统构建的基础数学原理。其中有许多物理仿真工具专门为汽车动力总成HIL测试领域而设计。常见的汽车建模工具及其主要用途包括:
Gamma Technology 公司开发的 GT-SUITE 软件—GT-SUITE 是一款仿真软件工具,为汽车工程应用提供了多种功能和库,包括快速概念设计、详细的系统或子系统/组件分析、设计优化以及根本原因调查等。 GT-SUITE架构提供了独一无二的系统集成模型构建功能,可以跨子系统、物理域和模型等级进行集成。
AVL 公司开发的 BOOST 和 CRUISE 软件—BOOST 是一款完全集成的虚拟发动机仿真工具,提供了先进的模型来准确预测发动机性能、噪声和废气处理装置的效率。在发动机开发过程中借助该软件,您可以提供给定汽车概念所需的扭矩和功率以及优化排放、油耗和乘客舒适度(噪声和瞬态工况)。
CRUISE 是一款系统级仿真工具,适用于从概念规划到产品发布等一整个开发过程中的日常车辆系统和传动系统分析任务。其应用范围涵盖了传统车辆动力系统、高度先进的混合动力系统和纯电动汽车。 CRUISE提供了参数优化和组件匹配功能,可帮助您实现实用且可行的解决方案。
ITI 公司开发的 SimulaTIonX—SimulaTIon X标准软件用于评估所有技术系统组件之间的相互作用,提供了丰富的模型库,适用于一维机械、三维多体系统、动力传动、液压、气动、热力学、电气学、电气驱动、磁学和控制学等领域。SimulaTIonX是用于物理效应建模、仿真和分析的通用CAT工具。。
Mechanical Simulation 公司开发的 CarSim 软件—CarSim 用于模拟乘用车、赛车、轻卡和多功能车的动态行为。它可生成动态仿真测试,并输出超过800个计算变量来进行绘图和分析或导出到Excel等其他软件。
通过确定性确保准确的仿真
HIL测试的有效性取决于仿真能否准确反映ECU周边环境。仿真模型必须通过数学计算对ECU命令进行准确的响应,并且这些响应所发生的时间范围必须与所仿真的机械系统一致。因此,大多数HIL应用都需要使用实时系统执行确定性 *** 作。您还可以使用实时系统来执行实时测试序列,以了解ECU功能和稳健性相关的信息。如果实时系统可以确定地代表机械系统,并具有足够高的保真度,则可以对ECU参数进行校准,以优化和调整整个闭环系统的性能。实时系统的性能很大程度取决于可以从测功机转移到实验室的测试量,因为这直接影响测试成本和上市时间。
不同类型动力系统的关键考虑因素
在动力总成控制模块(PCM)上执行HIL测试对系统提出了新的要求。由于其高度专业化特性,PCM除了依赖通用微控制器外,还依赖于专用协处理器。例如,内燃发动机PCM必须处理特定的高速发动机信号,例如转动位置、爆震、气缸压力和精确执行器控制[2]。 PCM测试需处理这些独特的I/O和协处理器。因此,PCM测试系统,如待测组件,使用相应复杂的测试系统来测专用协处理器来提供足够的I/O复杂性。此外,尽管公司会不断发布新的PCM硬件和软件,但测试系统通常需要具有多年使用寿命。高度灵活性便成为测试系统的一个最基本要求
如今,FPGA是满足这些需求的理想器件,其高性能和灵活性非常适合满足当今先进PCM快速变化的测试需求[3]。 FPGA具有显着优势,例如并行处理、设计可扩展性、超快的引脚到引脚的响应时间、设计可移植性和终身可升级性。所有这些优势都有助于构建强大的自适应测试系统。但是,FPGA编程通常只有非常专业的工程师才懂,但这类工程师非常稀缺。高级别抽象的FPGA编程软件的出现以及易于访问的现成FPGA库极大地提高了部署基于FPGA的测试系统的可行性。
内燃动力系统
从本质上说,内燃机ECU的作用是让发动机转动。为此,ECU通过精心设计的编码器轮提供的传感器反馈来监测发动机的位置,如图4所示的曲轴轮,并激活喷油器和火花塞来产生电能。
图4. 现在的曲轴轮采用复杂的pattern,如图中所示的pattern非常独特且不断变化。
内燃机ECU HIL测试仪的用途除了测量踏板等用户输入之外,还用于测量和生成这些燃烧信号。 表1显示了典型的发动机ECU信号。
表1. 在开发测试仪时应考虑这些常见的发动机ECU信号。
图5显示了一个典型发动机ECU测试仪的框图(不包含负载和开关)。 测试仪包含了在CPU上运行的实时OS,用于执行低中速(1 kHz-10 kHz)建模。 CPU与模拟、数字和总线通信等独立I/O结合,可让低中速信号随着模型的执行进行同步更新。不管对于哪类ECU测试系统,这些都是核心组件,但为了满足内燃机ECU测试的特定要求,还需要增加一个用于实例化角度处理单元(angle processing unit,APU)的FPGA协处理器。
图5. 典型的发动机ECU测试仪框图包含了在FPGA上进行实例化的APU协处理器。
APU用于执行高速、高保真的发动机转动仿真。转动仿真是一个接受速度输入值的过程,随着时间的推移,0到360度连续发布转动位置的仿真值。由于ECU编程为相对于其转动位置控制发动机,因此验证ECU时,需要在测试仪中模拟转动位置并进行与转动位置相关的测量。
图6. 模拟可变磁阻传感器输出的旋转信号。
将转动仿真任务从CPU上剥离出来有许多好处。首先,使用专用硬件,APU可以高速运行,不受高级实时 *** 作系统任务(如线程调度程序)的干扰。为了在10,000 rpm下实现0.1度 的分辨率下,转动仿真必须至少以600,000 Hz的频率运行,这在通用CPU上是不可能实现的。
其次,APU和CPU可以异步运行。这可允许CPU以固定的时间步进间隔运行物理对象模型,有助于提高许多对象建模和实时OS工具链的工作效率,同时获得来自APU协处理器的基于角度的信息。
最后,通过将APU放置在靠近I/O引脚的位置,可以在转动仿真和相关数据之间建立低延迟连接,以关联到仿真的位置值。事件发生的时间及其与位置相关的时间之间的延迟会直接导致测量误差。为了避免这一误差,可以将APU放在与I/O相同的FPGA芯片。
前面讨论的ECU信号、FPGA上的APU协处理器以及发动机物理模型相结合,就构成了一个闭环发动机ECU HIL测试仪。图7显示了该系统基于实际执行器负载的数据流。
图7. 发动机ECU HIL闭环数据流
对于内燃动力系统,设计ECU HIL系统时,另一个重要考虑因素是燃油喷射器驱动的测量。实现这一目标的最佳方法之一是将真实执行器纳入测试系统,就像将它们置于真实车辆中一样。 ECU经过电流测量信号调理卡连接到喷油器,并为测试系统的FPGA提供电流测量值。这可允许FPGA测量流经喷油器的电流,以确定何时开启和关闭电磁阀(图8)。
图8. 柴油燃料喷射器的电流和电压曲线表明必须测量电流才能精确地捕获正确的时机
对于汽油喷射器,一个更简单的替代方案是直接测量ECU的数字输出,以检测喷射器何时 被命令打开和关闭。但是,测量通过实际喷射器的电流可得到更准确的结果,因为 打开电磁阀需要一定量的激活电流。此外,如果实际负载没有连接到喷射器输出,大多数ECU会出现诊断故障。
混合动力和纯电动动力系统
在许多全电动或混合动力系统中,ECU必须管理多个独立电源产生的电力。例如,混合动力传动系统包含一个或多个电动机以及一个内燃发动机。无论使用的是何种混合动力传动系统类型,都意味着ECU必须以安全且可重复的方式控制两个耦合对象,这两个对象的动态速度可能截然不同,需要大量测试才能确保控制系统的稳定性。
例如,在路面结冰的驾驶条件下,车轮会突然失去牵引力。在加速时,这可能会导致电机速度急剧增加,需要安全地应对。但是,从物理角度考虑,这种安全行为不可能在测功机上再现,即使是在测试跑道上,也是非常耗时和高难度的。由于针对这种特定安全条件开发的复杂控制算法必须进行验证,测试需要考虑到极端的驾驶条件,以满足量产车辆的质量要求。
图9. 混合动力系统的HIL测试需要考虑更多的因素
混合动力和全电动传动系统都增加了ECU测试的复杂性。不管是哪种情况,驱动电动机都需要ECU产生高速PWM信号来驱动电力电子硬件。如果要HIL测试系统对来自被测ECU的高速数字信号做出正确的响应,仿真必须以数量级达1μs的超快速循环速率运行。另一个需要考虑的方面是,电动机表现出复杂的非线性行为,例如磁性饱和和齿槽转矩,这些行为都很难直接建模。线性模型可用于测试ECU的基本功能,但复杂的行为也需要建模,才能进行更严格的测试、调整和优化。
传统的仿真系统无法达到1μs的循环速率,这限制了控制系统设计人员的测试能力,迫使他们严重依于赖昂贵的测功机或现场测试。在失去牵引力的情况下,如果要通过现场测试来确保在所有可能运行条件下的安全性,所需的费用非常高昂甚至不可能实现。然而,提高仿真速度和保真度有助于在仿真中进行更多可重复的测试,从而减少物理测试的时间和成本。
要达到1μs的模拟周期,需要测试彻底改变电动机和电力电子HIL测试系统的设计。一个关键方法是摒弃传统的基于处理器的HIL系统,采用基于FPGA的仿真器。
由于通信总线将处理器和I/O分离开,传统的基于处理器的HIL系统可提供的最大速度仅为50 kHz左右。在仿真的单个时间步长内,对输入进行采样后,采样数据传输到处理器进行处理,处理结果传输回I/O节点,并更新输出结果。对于PCI或PXI总线,通信的延迟通常可占整个仿真周期的四分之三。将计算任务转移到FPGA上有助于提高计算速度。然而,提高速度的最快方法是在单个设备上并列配置处理节点和I/O节点,这样可最小化通信延迟。
对高级电机驱动器进行实时仿真时,面临的另一个挑战是实现仿真保真度和速度的平衡。虽然进行功能级HIL测试时,简单的常量参数或线性模型就足够了,但通常需要提高模拟保真度来提高测试的可靠性以及优化先进电机驱动器。在不增加计算复杂度的情况下提高模拟保真度的一个有效方法是使用查找表替换模型参数,并在每次仿真迭代时更新这些参数。
使用有限元分析结果或通过实验得出的表格,您可以模拟复杂的非线性行为,例如齿槽转矩或磁饱和,并设计可正确响应复杂现象的控制器。无论是哪种情况,查找表都可以捕获复杂的行为,而无需在仿真中直接对其进行建模。
最大化测试覆盖率
创建测试用例
为ECU制定测试计划和测试用例需要设计和测试团队之间密切合作。对ECU要求进行文档记述是此过程的一个关键步骤。通常,这些要求可以分为三个高级类别:安全性、功能性和性能。
安全性
在产品设计中,我们应用称为故障模式和影响分析(FMEA)的过程来定性地识别可能的故障及其对系统的整体影响。FMEA是20世纪40年代末测试军事系统的可靠性工程师开发的,并沿用至今。当识别出可能的故障时,就会详细描述故障并分配相应的概率值、严重程度值以及计算出的总体风险值(概率和严重程度的乘积)。表2显示了一个FMEA表的示例。
表2. 设计工程师创建故障模式和影响分析表作为有效的安全测试起点。 (表格由Quanser提供)
完成FMEA后,设计工程师会添加一些功能来减缓识别到的风险最大的故障。 例如,他们可以添加传感器来检测机械组件的故障,然后软件会自动将车辆切换到跛行回家模式,以防止进一步损害。 测试这些补救措施是ECU验证和确认的关键部分。如果要为每个故障设计相应的测试用例,需要设计团队提供故障树分析(FTA)。 图10显示一个FTA的例子。
图10. 在创建对安全至关重要的测试用例时,故障树分析是一个重要的参考文档。
使用FTA作为流程图,您可以为每个具有足够高风险的FMEA项目设计测试用例(“足够高”的阈值由产品管理人员设定)。考虑到一些故障的危险系数非常高,如果能在HIL仿真中对这些项目进行测试,那将是一项非常有价值的投资。
在验证安全要求时,必须确保测试准确无误,尤其是对于汽车和航空航天等必须符合功能安全标准的受管制行业。错误的验证可能导致项目在投入生产和处于安全关键状态时,产生极为不利的后果。另外,由于电子复杂性的不断增加,相同的时间内需要进行的测试增多,这就引入了自动化验证需求。但是,我们如何知道所使用的测试自动化工具是否如预期的那样正常工作?自行开发测试自动化工具的成本可能非常高,特别是在设计时需要确保工具的功能安全性。除此之外,还需要对整个验证过程进行详细且全面的文档记述。正确地创建该文档可能非常耗时,因此所使用的任何工具必须能够生成适当的工件,这使得许多人认为手动工具认证是唯一的方法。
使用在某些方面符合特定功能安全项目要求的COTS验证工具可以满足这一需求,且可让您对测试工具充满信心。 NI联盟合作伙伴CertTech针对NI测试自动化软件工具TestStand开发了一款资格鉴定包。 TestStand是一款随时可运行的测试管理软件,旨在帮助您更快地开发、执行和部署自动化测试系统。由于CertTech工程师对受监管行业和功能安全标准非常熟悉,他们很理解用户迫切需要使用符合DO-178C和ISO 26262等标准的合格工具。TestStand鉴定包全面覆盖了最常用功能的要求和测试种类,提供了验证指定要求的全套测试以及一个易于扩展的框架,因此用户可以根据需要扩展测试覆盖范围。此外,CertTech还使用工具生成了所需的文档,作为合规性的必要工件。这个文档是必不可少的,因为我们的总体目标是确保验证过程的完全透明性,以便测试可以快速地重建。 借助鉴定包,CertTech将生成该文档所需的时间缩短了95%。
一些较新的功能安全标准,如ISO 26262和DO-178C要求项目使用“合格工具”来完成一些不需要人工审核的验证和确认任务,这使得使用像TestStand这样的合格工具变得更为重要。这些标准需要您对未进行适当测试的工具的总体影响进行评估,然后判定一个TCL值,也就是ISO 26262等标准所称的工具置信度( Tool Confidence Level,TCL)。两个主要因素决定了TCL:工具影响(TI)和工具错误检测(TD)。 TI1和TI2是TI的两个级别。当故障软件工具不可能违反安全要求时,则选择TI1。其他所有情况均选择TI2。 TD分为TD1、TD2和TD3。 TD1表示工具检测错误的置信度很高,TD2表示置信度中等,TD3表示置信度很低。测试工具的不同TCL等级意味着用户所承担的额外负担也有所不同。
最大化测试覆盖率
创建测试用例
为ECU制定测试计划和测试用例需要设计和测试团队之间密切合作。对ECU要求进行文档记述是此过程的一个关键步骤。通常,这些要求可以分为三个高级类别:安全性、功能性和性能。
安全性
在产品设计中,我们应用称为故障模式和影响分析(FMEA)的过程来定性地识别可能的故障及其对系统的整体影响。FMEA是20世纪40年代末测试军事系统的可靠性工程师开发的,并沿用至今。当识别出可能的故障时,就会详细描述故障并分配相应的概率值、严重程度值以及计算出的总体风险值(概率和严重程度的乘积)。表2显示了一个FMEA表的示例。
表2. 设计工程师创建故障模式和影响分析表作为有效的安全测试起点。 (表格由Quanser提供)
完成FMEA后,设计工程师会添加一些功能来减缓识别到的风险最大的故障。 例如,他们可以添加传感器来检测机械组件的故障,然后软件会自动将车辆切换到跛行回家模式,以防止进一步损害。 测试这些补救措施是ECU验证和确认的关键部分。如果要为每个故障设计相应的测试用例,需要设计团队提供故障树分析(FTA)。 图10显示一个FTA的例子。
图10. 在创建对安全至关重要的测试用例时,故障树分析是一个重要的参考文档。
使用FTA作为流程图,您可以为每个具有足够高风险的FMEA项目设计测试用例(“足够高”的阈值由产品管理人员设定)。考虑到一些故障的危险系数非常高,如果能在HIL仿真中对这些项目进行测试,那将是一项非常有价值的投资。
在验证安全要求时,必须确保测试准确无误,尤其是对于汽车和航空航天等必须符合功能安全标准的受管制行业。错误的验证可能导致项目在投入生产和处于安全关键状态时,产生极为不利的后果。另外,由于电子复杂性的不断增加,相同的时间内需要进行的测试增多,这就引入了自动化验证需求。但是,我们如何知道所使用的测试自动化工具是否如预期的那样正常工作?自行开发测试自动化工具的成本可能非常高,特别是在设计时需要确保工具的功能安全性。除此之外,还需要对整个验证过程进行详细且全面的文档记述。正确地创建该文档可能非常耗时,因此所使用的任何工具必须能够生成适当的工件,这使得许多人认为手动工具认证是唯一的方法。
使用在某些方面符合特定功能安全项目要求的COTS验证工具可以满足这一需求,且可让您对测试工具充满信心。 NI联盟合作伙伴CertTech针对NI测试自动化软件工具TestStand开发了一款资格鉴定包。 TestStand是一款随时可运行的测试管理软件,旨在帮助您更快地开发、执行和部署自动化测试系统。由于CertTech工程师对受监管行业和功能安全标准非常熟悉,他们很理解用户迫切需要使用符合DO-178C和ISO 26262等标准的合格工具。TestStand鉴定包全面覆盖了最常用功能的要求和测试种类,提供了验证指定要求的全套测试以及一个易于扩展的框架,因此用户可以根据需要扩展测试覆盖范围。此外,CertTech还使用工具生成了所需的文档,作为合规性的必要工件。这个文档是必不可少的,因为我们的总体目标是确保验证过程的完全透明性,以便测试可以快速地重建。 借助鉴定包,CertTech将生成该文档所需的时间缩短了95%。
一些较新的功能安全标准,如ISO 26262和DO-178C要求项目使用“合格工具”来完成一些不需要人工审核的验证和确认任务,这使得使用像TestStand这样的合格工具变得更为重要。这些标准需要您对未进行适当测试的工具的总体影响进行评估,然后判定一个TCL值,也就是ISO 26262等标准所称的工具置信度( Tool Confidence Level,TCL)。两个主要因素决定了TCL:工具影响(TI)和工具错误检测(TD)。 TI1和TI2是TI的两个级别。当故障软件工具不可能违反安全要求时,则选择TI1。其他所有情况均选择TI2。 TD分为TD1、TD2和TD3。 TD1表示工具检测错误的置信度很高,TD2表示置信度中等,TD3表示置信度很低。测试工具的不同TCL等级意味着用户所承担的额外负担也有所不同。
表3. ISO 26262标准中的工具置信度意味着对工具进行鉴定时的工作量不同
TCL2工具对于用户的价值最大,因为任何TCL1工具不是对安全没有任何实质影响,就是已经具有高置信度,因而不需要额外的资格鉴定和文档记述。而TCL3工具置信度较低,不管如何都需要一定程度的人工资格鉴定。
功能性
从高层次来说,ECU功能的测试非常简单。我们可以简单地逐个功能进行测试;但是嵌入式软件的详细信息可以帮助发现需要严格测试的可能故障点。因此,功能测试的设计同样需要与ECU设计团队密切合作。
此外,特定ECU的特性可以与状态图相结合来指导测试用例的设计。
性能
与安全和功能测试用例不同,设计基于性能的测试却不需要与ECU设计团队协作。这些测试的开发通常从用户的角度来考虑。设计团队能接受的对于用户来说可能是无法接受的,因而这些反馈非常重要。幸好,有些用户关心的性能问题,例如每加仑英里数(MPG),可以根据联邦政府定义的测试程序直接变为测试用例。图11显示了联邦政府针对市区驾驶规定的车速随时间的变化图(FTP-75)。
图11. 联邦政府针对车辆MPG性能规定标准化测试,例如FTP-75驾驶工况。
另一种基于性能的测试是内部性能,例如总线消息时序、ECU CPU利用率或ECU事件
响应时间。这些类型的测试可能需要测试仪具有额外的功能,包括ECU校准、调试数据链路(以读取微处理器参数)和/或过程数据日志时间戳发布(以验证可接受的总线消息行为)。有关使用NI DIAdem软件进行此分析的示例,请查看 时间相关的NI VeriStand数据日志。
需求创建、可追溯性和实现
需求可追溯性的重要性
为了确保嵌入式软件和一般软件的质量,经证明在软件开发过程的所有阶段跟踪需求工件是非常重要的。典型的软件过程包括研究、定义、开发、测试和部署。通过跟踪来建立各种关系以及分析软件更改的影响是软件开发过程的常见 *** 作,尤其是对于故障成本非常高或故障可能导致生命危险的领域。
经证明,软件项目如果缺乏足够的需求可追溯性,就会出现较多严重影响系统安全性和可靠性的缺陷。即使是微小的变化,也可能产生很大的连锁效应,导致最终产品无法完全满足项目启动时确定的所有要求。
由于监管机构出于对安全问题的考虑,以及企业不期望发生代价巨大的产品召回事件,因此两者联手,制定了大量关于需求管理的标准、最佳工程实践和软件工具。在未来的项目中,应对需求可追溯性进行硬性规定
测试自动化
在现代测试系统中,从最上层的功能到测量仪器均可自动化。这是一个复杂的过程,涉及来自不同供应商的多个工具和不同 *** 作系统,其中一些任务可能需要在实时HIL系统上执行。因此需要尽早与工具提供商确认,以确保兼容性。测试自动化是经济高效地确保需求可追溯性的关键因素。
除了执行测试脚本来驱动虚拟汽车之外,具有前瞻性思维的组织还会使用测试自动化框架来进一步实现测试执行和自动化。借助这些框架,就可以批量运行测试,对测试数据执行后期处理和分析,并生成报告,且运行时无需任何人工交互。只需配置测试系统,测试执行就可以独立完成。测试自动化可自动将产品需求和测试用例链接到测试结果,帮助工程师更有效地进行沟通。这样就无需人工对测试数据与需求进行比较,从而提高了工作效率。
ECU测试团队的一个高级目标是开发一个提供足够测试覆盖率的测试用例库。这个库是确保ECU质量的关键因素。随着测试用例库不断扩展,测试可以设置为连夜自动运行或者在软件发生变化时自动触发运行回归测试。及时的回归测试报告可以避免最新出现的嵌入式软件错误持续数周并逐渐变得难以修复。
为您的ECU选择合适的HIL系统
开放性、可扩展性、灵活性
选择HIL系统时,首先应考虑是要购买组件并自行集成系统还是购买完整的交钥匙系统。大多数交钥匙系统供应商通常不销售组件,而销售组件的供应商通常通过合作伙伴提供交钥匙系统。
如果选择购买组件,则需要拥有掌握专业知识的工程人员来集成组件,这样可以更灵活地控制系统的可扩展性和定制性。而选择购买交钥匙系统可以减轻工程负担,但必须确保系统能够满足您当前和未来的需求。保证这一点的一个方法是购买“开放”且“可扩展”的平台。由多个供应商支持的开放式平台提供了最大的可能价值并可保护您的投资。
HIL测试系统灵活性的重要性
将HIL仿真集成到测试系统的方式有很多种。随着降低测试成本的需求日益迫切,灵活的解决方案对于在开发过程中融入HIL仿真至关重要。高效的HIL仿真解决方案应能够快速适应开发过程中遇到的各种变化,而且不需要大幅修改HIL仿真仪就能够对测试过程或配置进行小改动。以目前的创新速度,单靠一个供应商是无法满足所有最新技术的上市时间、质量和成本预期。基于COTS工具的开放式HIL仿真解决方案可确保您始终可以集成ECU测试所需的技术。
图12. 灵活的HIL测试系统可以满足未来需求和项目扩展的要求。
尽管HIL系统已广泛应用到嵌入式测试领域,但它们仍然只是测试环节的一部分。在选择HIL测试策略时,请务必考虑除了嵌入式软件验证之外应如何将HIL系统集成到测试工作流程中。相比仅关注测试周期的某个特定领域的公司,对测试具有整体观的测试工具公司能够提供更有价值的见解。
NI HIL平台是一个COTS解决方案,可进行扩展和自定义来满足不断变化的需求。由于其模块化架构和开放式软件,NI工具既可以在小型台式系统上使用,也可以进行扩展,用于具有紧密同步的分布式高通道数系统,例如铁鸟飞机模拟器。 NI设计的产品可以满足从工业控制到消费电子等各个行业的需求。这些要求苛刻的应用所需的性能、可靠性和灵活性同样也适用于工程师进行HIL仿真,这使得NI成为嵌入式软件测试的理想合作伙伴。
责任编辑:gt
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)