原创
飞机机电系统测试
2019-9-24 15:22
804
9
9
分类:
测试测量
文集:
测试测量
http://www.ni.com/zh-cn/innovations/white-papers/18/accelerating-the-product-development-lifecycle-with-faster-test-.html
灵活的测试台
严格的组件测试对于飞机、太空和国防系统来说至关重要。 您必须对DUT的耐久性进行特性分析和测试,以确保其在各种运行环境下均可符合规范要求。 随着这些DUT变得越来越复杂,您需要更精密的测试仪来确保它们能够在产品系统的使用寿命内按预期与之正常配合工作。 由于在项目过程中组件和子系统不断演变,可能会要求测试设备进行非预期且高成本的重大改装和重新设计来满足新要求。 NI提供了一种灵活的方法,可结合广泛I/O来构建测试系统,同时还提供了一个可集成第三方系统和通信协议的开放平台。 使用NI设备,即可确保您的测试设备可以随新设计和测试要求进行扩展。
概览
飞机推进系统等机电系统都是由软件、控制器和机械部件组成。 随着复杂性的不断增加,这些系统需要更复杂的测试方法,以便在项目进度和预算限制内实现所需的测试覆盖率。 此外,这些测试仪必须在长达数十年的项目周期内进行维护,以履行维护、修理和大修(MRO)服务合同规定,并定期进行整改以适应系统升级。
在较长的项目周期内支持日益复杂的待测设备(DUT)和测试系统是一项挑战,尤其在资源有限的情况下更是如此。 基于平台的灵活测试方法可以帮助您开发统一的测试架构来应对这些挑战。 采用统一的单个测试架构具有多个好处,包括缩短测试开发时间,最大限度减少整个开发周期或不同项目组的不同测试团队的重复工作。
为了获得最大益处,机电系统的统一测试架构应该:
•满足整个设计周期(从早期原型设计到软件、电气和机械验证再到系统级测试台和系统集成实验(“铁鸟”)以及生产测试)的测试需求
•支持基于模型的控制和仿真,以便在开发过程中及早进行测试,并涵盖各种难以重现的测试场景和压力测试。
•集成各种I/O和第三方设备,如传感器、执行器、仪器和软件。 这可最大化复用率以及最小化集成工作。 必须采用可配置/可扩展的分布式/同步I/O架构,以满足整个设计过程中的不同I/O需求以及实现跨项目复用。
•提供企业级和IT友好的数据管理和系统管理框架,以优化决策制定,减少重复测试以及报告时间和工作量,并提高资产利用率和正常运行时间。
内容
机电系统可将能量转换为机械运动,反之亦然。 它们包含运行专用软件的控制电子设备(例如,电子控制单元)或嵌入式控制器(例如,可更换线路单元),使用来自传感器和其他系统的输入来控制机械、驱动和物理组件。 机电系统为飞机、地面车辆和船舶提供推进力以及各种其他功能。
图1.交通工具类别示例及其中常见的机电系统类型
虽然这些系统的功能、操作方法和设计要求可能截然不同,但交通机电系统的开发和测试遵循相同的工作流程。 系统工程师设计车辆/飞机/船舶以及确定这些交通工具的系统、子系统和组件必须满足的要求。 独立的团队通过按照规范开发适当的控制电子设备、软件和机械组件来满足这些要求。 这些团队遵循他们自己的开发流程(通常是针对特定组织需求的常见方法,如Agile)来完成机电系统特定部分的设计和验证步骤。 然后,通过迭代方式建立和集成系统并分阶段测试,以生产真车/真机/真船。
图2.机电系统的常规产品开发过程
从需求到设计和验证的过程可以以各种方式表示,其中一种方式就是V模型(图3)。 即使V模型及其许多变体和解释还存在诸多疑点,但是该模型仍是用于检测通用测试架构是否能够满足整个设计过程中的测试需求的一个有用框架。
图3.表示开发过程和相关测试类型的V模型方法
一般而言,V模型的左侧通过渐进式设计决策将高级需求细分为较低级别的规范。 越来越多的决策采用基于模型的设计方法进行制定,该方法包含各种计算机辅助工程(CAE)工具,具体取决于正在开发的系统类型。 有关此主题的更多讨论,请参阅有关数字转换和数字结对的相关文献。 在V模型底部,系统已被分解为最低级别的基础组件,设计可随时转换为具体实现,组件原型已随时可以开始构建(并且代码部署到运行软件的原型中),因此V底端有时也称为“部署”。 V的右侧显示的是将这些不同的组件集成在一起、根据规格验证其操作,并根据基本组件到整车级别的每个集成步骤的要求验证性能。
注意:在确定系统、子系统和组件的详细信息后,软件、电气组件和机械组件的开发将并行进行,如图2所示。通常由具有必要领域专业知识的独立设计和测试团队来负责这个开发过程。
注意:术语“验证(verification)”和“确认(validation)”有时无区别使用,有时使用总括性术语“V&V”。 通常,验证要解决的问题是:“我是否正确构建了这个系统?” 并根据规范要求确保系统按预期运行(是否在公差或范围内)。 但确认要解决的问题是:“我是否正在构建正确的系统?”在系统开发完成后, 您需要确保系统可以执行预期的任务,并根据需求测量系统是否具备可接受的性能。
以下大致按照产品设计过程的顺序简要描述了各个测试的定义,这些测试在实际应用中具有高度迭代性。 快速有效地通过V模型进行设计迭代的能力是领先测试组织的竞争优势和关键能力。 一种批判V模型的说法是它的开发过程顺序与瀑布开发模型一样。
模型在环(MIL)测试MIL测试需要使用软件对控制器和测试对象进行建模。您可以在设计过程的早期进行此类测试,以在软件仿真环境中测试控制器策略和系统行为。 您可以在设计过程的早期进行此类测试,以在软件仿真环境中测试控制器策略和系统行为。
软件在环(SIL)测试SIL测试需要对测试对象进行建模,但是该模型需要连接到使用所选语言编写并在开发机(有时是虚拟机)上编译和执行的实际控制代码。
处理器在环(PIL)测试PIL测试类似于SIL测试,但是控制代码是针对要在已部署系统中使用的特定处理器架构和操作系统编写和编译的。 例如,如果您在具有特定设置的特定FPGA上运行代码,则可以针对这一特定场景编译代码,以确保实际处理架构正常运行并保证足够的资源可用性。 这是一个单独命名的测试步骤,因为实现所部署的处理架构和硬件可能是非常棘手且耗时,尤其是在电子控制单元(ECU)的设计优化会导致软件功能和特性受限且需要取舍时。
快速控制原型(RCP)RCP用于快速迭代可能的控制方案,使用的是在实时控制器上和/或是在通过真实I/O连接到实际测试对象的FPGA上运行的数学模型。
硬件在环(HIL)测试HIL是使用仿真的物理组件和传感器在实际嵌入式控制器上进行的软件测试,因此ECU是通过信号调理,在真实的负载水平下执行真正的电气I/O,并具有插入故障的能力。
物理测试物理测试应用使用基于传感器的测量(例如温度、压力、应力/应变、声音、加速度、位移等)来测试被测组件或系统的物理特性。 应用示例包括噪声、振动和粗糙度(NVH)测试,其中涉及需要使用麦克风和加速度计进行声音和振动测量。 另一个例子是耐久性测试/生命周期测试(高加速寿命测试或HALT,以及高加速应力筛选或HASS),其重点在于确定DUT在各种不同的预期操作条件下的行为。
系统集成测试- V模型的整个右侧强调不同级别集成测试。集成通常涉及使用两种主要类型的系统: 集成通常涉及使用两种主要类型的系统:测试台用于进行各种组件集成到单个(子)系统的系统级测试。
测试台非常适合处理各种可能的测试,因为它们将各种基础组件集成到一个正常运行的系统中。 使用正常运行的系统有助于进行测试设置和执行。 - 系统集成实验或“铁鸟”,即用于将多个子系统集成,以进行整车/机/船级测试,近似于实际的车辆/飞机/船舶布局和系统连接。 “铁鸟”用于系统群测试和系统间通信/交互/边界条件测试。 某些测试用例只能使用这么大规模的基础架构才能进行测试。 这是在为实际现场/飞行测试/试航开发原型车/机/船之前的最后一级测试。
维护、修理和大修(MRO)测试MRO或场站测试提供了交通工具系统在其长期(通常是多年和代)服役期间所需的服务、维修和升级。 有时,系统测试台使用相同的设备或其改良版。 MRO测试的一个挑战是在面对测试仪硬件和软件过时问题、人员更替以及由于定期系统升级而导致需求变化的情况下仍能够在整个项目周期中有效地维持测试能力。
现场测试用于现场测试的交通工具通常装备大量仪器,以在这类昂贵的测试中提供尽可能多关于车/机/船的运行数据。 主要的考量因素包括重量/大小、为测试设备供电的能力以及数据存储和检索。 虽然现场测试需要大量时间而且成本高,但其仍然是产品开发过程的关键部分,因为模型永远不可能完美无缺,系统之间和内部的交互非常复杂,并且可能会出现前面测试过程中未涉及的意外行为。 现场测试有助于确定车/机/船是否可以投入运行。
设计统一的测试架构:在整个设计周期内提供测试需求在熟悉了开发过程和相关的测试类型,我们就非常清楚统一测试架构的潜在优势。 使用一个测试平台即可满足整个设计周期内(从早期原型设计到软件、电气和机械验证,再到系统级测试单元和系统集成实验)的各种测试需求的能力可实现更快的测试开发和更高效的资源利用。 整个V模型各阶段之间和项目之间的设备和人员也更具互操作性和可互换性。 从测试能力和迭代方面来说,这种更快速、更轻松地完成V模型每个阶段的能力非常有价值。
统一的测试架构提供的好处类似于面向对象编程模型。 如果您知道需要使用类似方法开发相同类型的系统,则可以投资到可以跨项目使用并且可以根据每个项目的独特要求进行自定义的核心构建模块。
这种基于平台的测试方法更加强大,因为借助由灵活且可扩展的平台支撑的测试架构,您可以确信,就系统功能和测试能力方面而言,您绝对可以满足不断变化的需求和适应未预期的系统需求。 或者,换句话说,通过这种方法,您无需非常明确地设计功能,以便为未知做好准备以及预测未来的需求。 这比专门构建的固定功能系统要好得多,因为在这种系统中,您需要明确地设计您认为将来可能需要的灵活性和可扩展性。 这些固定功能系统迫使您在时间和成本以及功能和性能之间进行权衡。
设计统一测试架构:支持基于模型的控制和仿真您需要在开发过程中尽可能早地“预先加载”尽可能多的测试,以便更快地进行迭代并确保更经济、更安全的测试。 您可以通过使用基于模型的控制和仿真来充分表示实验室中的激励和现实条件。 这可以将以前只能通过现场测试进行的分析转移到系统集成实验或系统级测试平台上。 我们可以使用一些技术来改进这类测试,比如现场记录真实激励信号并通过模型控制的致动在系统上“回放”。
您还可以通过组件仿真将测试需求与其他团队的计划分离开。 但是为了确保足够的测试结果保真度,您必须花时间验证组件仿真所使用的模型和方法的准确性和有效性。
基于模型的控制和仿真提供的另一个好处是能够更好地测试难以复制、危险和极端的测试用例。 这提高了测试覆盖率,让工程师对设计更有信心。
设计统一测试架构:集成和互操作性有时要实现特定功能时,能够选择的传感器、执行器、仪器或软件的类型或品牌并不多。 让系统的所有不同部分协同工作通常占据测试系统设计成本的一大部分,尤其是在改造或重新设计传统测试仪时需要处理老化系统组件时。 内置有各种I/O和第三方设备功能的平台可以通过最大化重用和最小化集成工作来提高效率。 可配置/可扩展的分布式/同步I/O架构可满足整个设计过程中不同测试用例的各种I/O需求,并实现跨项目复用。
设计统一测试架构:数据和系统管理以更高速率进行更多的测量产生了更多各种格式的数据,这一数据量要比以前多得多。 更多客户必须在设计周期中跨各种类型的测试访问此数据,以满足更多报告需求。 确保数据可用性并且真正使用这些数据本身就极具挑战性。 您需要能够有效地查找和加载数据,以交互方式可视化和分析数据,并通过自动化报告来节省时间。 统一的测试架构必须提供企业级且IT友好的数据管理和系统管理框架,以改善决策制定,减少重复测试、报告时间和工作量,并通过使数据成为资产而非负债来提高资产利用率和正常运行时间。
分散在全球各地的开发和测试团队发现有效管理跨站点部署的测试设备以及将各个站点生成的数据关联起来越来越困难。 有效管理分布式测试系统和数据可以提高运营洞察力、减少停机时间和提高生成数据的可信度,从而节省大量成本。
使用统一的测试架构更高效地进行测试投资基于软件定义测试平台的统一测试架构是团队设计和测试先进交通机电系统的最佳方法。 与完全内部定制开发或完整的交钥匙外包解决方案相比,这种方法可以加快测试开发速度,提高测试覆盖率和运营效率,让团队更灵活、更强大,降低资本支出以及提高长期测试系统的正常运行时间和可维护性。
文章评论(0条评论)
登录后参与讨论