LabVIEW如何减少下一代测试系统中的硬件过时 1 点击:240 | 回复:0



fjczd

    
  • 精华:0帖
  • 求助:0帖
  • 帖子:552帖 | 36回
  • 年度积分:703
  • 历史总积分:1294
  • 注册:2008年8月14日
发表于:2022-12-22 20:11:52
楼主

LabVIEW如何减少下一代测试系统中的硬件过时 1

许多测试系统的问题是,整个系统运行的时间必须超过单个系统组件的支持时间。有时被测试的设备有几十年的有效使用寿命,而许多测试仪器已经过时,在5年或更短的时间后就不再支持了。其他时候,被测试的设备的有效使用寿命以月为单位。这两个都是生命周期不匹配的例子。

生命周期不匹配导致需要在不改变测试应用程序、测试fixture和被测设备(dut)的情况下升级过时的仪器,或者需要在不改变任何硬件或特定于硬件的软件的情况下改变测试应用程序软件。更新测试系统需要新的测试软件开发、重新验证和重新记录,这些都是昂贵的、资源密集型的和耗时的。为了尽量减少与迁移或升级测试系统相关的时间和成本,您可以在测试系统中使用硬件抽象层(hal)来将测试应用程序与仪器硬件分离。本文涵盖了HAL的架构、最佳实践、特性和优点,并概述了LabVIEW和基于c的实现的示例。

硬件抽象类HAL

大多数HAL可以分为三组:行业标准、供应商定义和用户定义。行业标准HAL由行业标准机构定义和维护。供应商定义的HAL由单个供应商提供和维护。用户定义的HAL由构建测试系统的最终用户定义和维护。本文主要关注用户定义的HALs。

行业标准

一个著名的行业标准HAL是由IVI基金会维护的可互换虚拟仪器(IVI)。IVI为八种部署最广泛的仪器类型提供了标准的应用程序接口(API)。IVI规范具有基本、扩展和特定于仪器的API选项;检查范围;模拟;以及其他功能,使升级仪器更容易。IVI的一个限制是用户可能需要仅在特定于仪器的驱动程序中可用的功能,从而降低了互换性。这是因为用户很难扩展现有的IVI类驱动程序。

供应商定义

供应商定义的HAL是指供应商为不同的仪器类型和型号创建一个插件系统。厂商定义的HAL具有由厂商投资于设计、生产、支持和维护的优势。供应商定义的HALs的限制包括支持的仪器的广度和深度、质量以及快速轻松添加新仪器的能力——尤其是竞争对手的仪器。此外,供应商可能会专注于最大化系统中仪器的性能,而不是整体系统性能。依赖HAL供应商的技术支持可能会增加停机时间和成本,特别是在不提供源代码的情况下。源代码的缺乏限制了您可以帮助自己或快速添加新工具的能力。此外,供应商定义的HAL的过时将有效地淘汰您的整个测试系统。

用户定义的

用户定义的HAL的优点是,可以自定义它们以满足独特需求并优化系统性能。如果架构良好,HAL将促进更好的测试应用程序开发并增加重用。建议选择一个广泛使用、支持良好的应用程序开发环境(ADE),该环境足够强大且不需要高级编程技能。用户定义的HAL的限制包括设计、实现和维护它们的时间和成本

以仪器为中心和特定于应用程序的HALs

三个HAL类别中的每一个都有一个以仪器为中心的应用程序接口(API),一个特定于应用程序的API,或两者的组合。

Instrument-Centric

以仪器为中心的API通过使用一组通用的仪器类函数调用来抽象仪器的差异,这些函数调用是唯一仪器可以支持的。例如,IVI采用以工具为中心的抽象视图——也就是说,让顶级测试应用程序调用以工具为中心的API,使所有工具看起来相似(例如,iviscope_configureacquitiontype)。具有以仪器为中心的API的用户定义的hal可以使用“myDMM”或“standardSigGen”调用来抽象唯一的仪器。

特定于应用程序

在特定于应用程序的方法中,测试应用程序调用特定于应用程序的API,该API与其需要执行的测试类型(例如,LED test)保持一致。特定于应用程序的HALs将您与特定仪器类型的行为隔离开来。用户定义的hal更有可能使用特定于应用程序的api,因为除了硬件差异之外,它们还可以抽象仪器的复杂性。特定于应用程序的HALs有助于将特定于dut的参数与可重用的测试逻辑分离。此外,特定于应用程序的hal可以使用以仪器为中心的hal来提供额外的抽象层。

HAL选择优先事项

类别选择

如果能满足您的要求,请选择一个行业标准HAL。许多公司的投资和标准多年来的稳定性减少了您设计、开发和维护它的需要,节省了您的时间和金钱。如果行业标准的HALs不能满足您的需求,其余选项是由供应商定义的或用户定义的。通过实现您自己的用户定义的HAL,您可以选择最适合您的应用程序的架构、工具和行业软件标准。非常仔细地考虑供应商定义的HAL解决方案,因为它们可能会将您锁定在他们的技术架构和业务结构中,限制您更快更容易地迁移的能力——这是HAL的首要要点。

API的选择

在设计用户定义的HAL时,重要的是要确定以仪器为中心的API还是特定于应用程序的API最能满足您的需求。如果以仪器为中心的API是更好的选择,那么定义一个内部通用的以仪器为中心的API“标准”,您可以跨多种类型的dut使用它。将函数分成类似于IVI的三类——基本、扩展和特定。每种仪器类型的最常用函数都包含在基本函数中。在许多(但不是所有)工具中共享的函数被分组在扩展函数中,如果该函数存在于

最后,将不常用函数分组到特定函数中。在可能的情况下构建IVI标准,因为它减少了在系统升级期间定义和实现以及迁移的时间和精力。如果特定于应用程序的API对于您的需求来说是更好的选择,那么您需要确定应用程序功能的哪个部分开发效率最高且最容易重用

自定义HAL架构

下图显示了用户定义的HAL的体系结构。测试应用程序位于顶层。测试应用程序开发人员只需要知道要运行哪些测试、这些测试的参数以及测试硬件需求(采样率、分辨率等等)。在设计测试时,开发人员不需要知道具体的仪器。LabVIEW示例中的测试应用程序名为“Main test App.vi”,它调用来自HAL的函数。建议在HAL中有两个级别。示例HAL有一个应用程序分离层(ASL),测试应用程序将调用它,还有一个特定于设备的软件插件(DSSP), ASL将调用它。

需要说明的是,上述的例程和文档,都是可以下载的,双击即可打开,其中压缩文件是可以采用粘贴复制的方式,拷贝到硬盘上。这不是图片,各位小伙伴看到后尝试一下,这个问题就不用加微信咨询了。有关LabVIEW编程、LabVIEW开发等相关项目,可联系们。附件中的资料这里无法上传,可去公司网站搜索下载。




楼主最近还看过


热门招聘
相关主题

官方公众号

智造工程师