LabVIEW在面向对象编程中利用硬件抽象层(HAL)设计1
LabVIEW面向对象编程(OOP)采用仪器为中心的硬件抽象层(HAL)，使用面向对象的设计模式，可以部署一个仪器重用库，该库可以随着需求和仪器趋势的变化而增长，同时在不可避免的硬件过时中，可以继续使用，避免软件维护成本。
硬件抽象层(HAL)允许测试开发人员在与用户沟通时使用高级功能。通常，OEM开发或定制的仪器驱动程序是特定于某个型号或仪器系列的。对于HAL，底层实现对于顶层的开发人员来说并不重要。该设备可以使用IVI或SCPI，它可以是GPIB，以太网，串口等。HAL不会改变仪器的接口。比如对于电源，希望设置电压并打开输出，作为测试开发人员，并不必关心它是如何发生的。
使用HAL的优点：
不需要依赖于特定的仪器型号
可以轻松地在模拟硬件和实际硬件之间切换
无需重新编译EXE即可更改仪器和软件
使用它的缺点包括：
需要更多的前期设计
需要更多的软件开发来设计好它
对于简单的程序开发来说，似乎就不适用了，但如果想持续提升自身水平，或者项目需要持续升级和维护，那这些缺点不值一提。
DMM是常用的设备，很多厂家都有DMM产品，每一家的功能类似，但程序却不尽相同。
传统方法是使选择结构。这个例子是一个完整的配置、读取、关闭循环，但是如果这些函数分布在代码中，或者当需要添加新设备时该怎么办?开发人员必须找到所有的仪器驱动程序，并添加一个新的案例或替换为新的驱动程序集。
在开发中还会有不同的问题—两个设备之间的配置测量输入不相同。是否需要强制转换以匹配不同的驱动程序集。但是，无需如此操作。
著名的程序员比尔·盖茨，曾经说过，“我选择一个懒惰的人去做艰苦的工作。因为懒人总能找到简单的方法”
回到定义——抽象的工具没有具体的存在。它只是想要执行的实际功能的接口。使用LabVIEW面向对象编程的概念来实现。
父类是抽象的实现——没有真正的功能，只是定义了接口
子类是具体的实现——实现接口的功能并匹配连接器窗格
现在所讨论的大多数仪器都相当简单:电源、DMM等。那复杂的仪器呢?频谱分析仪，矢量网络分析仪?该如何部署HAL使用?如何选择正确的子类?
如LabVIEW开发的射频试验台需要控制众多仪器，包括：
10台电源
2块电表
1台矢量网络分析仪(VNA)
1台频谱分析仪
1 台示波器
1台信号发生器
2台交换机
3 张开关卡
2 台万用表
2台形发生器
涉及众多公司比NI， Keysight，Rohde& Schwarz，Tektronix，Gigatronics等。要实现包括所有这些仪器的自动化测试台架的跨功能、跨公司的开发工作。建立3个测试试验台，使用期限在20年。
那么如何部署HAL?开发人员如何知道使用哪个函数?为哪些功能创建驱动程序?使用什么输入?以下是使用这么多仪器所面临的问题。
1. 如何部署HAL供开发人员使用?
2. 软件开发人员如何知道使用哪个函数?
3. 需要为哪些功能创建驱动程序?
4. 使用什么输入?特别是当它是环形输入时，不同的驱动器有不同的解决方案
通过讨论，发现最好的方法是使用打包的项目库(*.lvlibp)来部署代码——不能意外编辑，并且可以设置为可调试。这就要求做到：
•在项目中创建父工具类并编译
•所有仪器类型继承自父仪器
开发人员不应该使用子对象，那样会破坏整个目的
•创建调色板以确保开发人员使用的是顶级函数
•手动创建调色板文件
•添加到库(不是类)
•构建打包的库
•创建一个部署的调色板，将调色板文件从打包的库中拉出来
顶级工具使用相同的颜色(蓝色)，所有子类使用相同的颜色(红色)，这样就很容易在代码审查中判断是否使用了不正确的函数
需要说明的是，上述的例程和文档，都是可以下载的，双击即可打开，其中压缩文件是可以采用粘贴复制的方式，拷贝到硬盘上。这不是图片，各位小伙伴看到后尝试一下，这个问题就不用加微信咨询了。有关LabVIEW编程、LabVIEW开发等相关项目，可联系们。
设备有通讯协议，根据协议开发了LabVIEW程序，如下附件所示。
相关资料说明，如下所示。
