利用GOOP编程技术的大规模系统集成与自动欧洲战斗

Author(s):
John Duncalf - 主要单元团队负责人－ BAE Systems (英国)
James Peter - 技术总监－ TBG Solutions (英国)

Industry:
Government/Defense, Aerospace/Avionics

Products:
Data Acquisition, Distributed I/O, Industrial Communications, Software

The Challenge:
通过提供一种有效的软件架构，替换现有的测试软件，从而能够提供更好的技术支持与测试可靠性。完成这项工作不应导致较长时间的停产，而应确保方便进行持续改进。

The Solution:
利用GOOP（图形化面向对象编程）软件架构以提供模块化且可拓展的系统组件，可以提供一种渐次改变的方式。这是通过将现有代码分解为一个个离散的模块，并从一个完全重新设计的用户界面（UI）动态调用这些模块来实现的。

硬件

该系统的硬件由两个测试头“湾”和一个工作间组成。每个测试湾拥有约1400个输入/ 输出（I/O）通道，而工作间具有约600个I/O 通道。这些I/O 通道都通过三个独立的由NI FieldPoint模块构成的RS485网络连接，并通过OPC服务器访问，一个OPC 服务器对应一个RS485网络。除I/O 通道外，测试湾周围还有各种其他仪器，主要是RS232设备（DMM与PALL 污染监测设备）和两个NI PCI DAQ 板卡。

最初的系统软件包含约370 Mb代码，这是一项耗时约35年的开发成果。整个代码通过单个顶层VI（虚拟仪器）进行调用，可能需要长达5分钟的时间才能加载至PC 存储器。这使得系统难于调试，而且几乎无法维护。稳定该系统的最显著的优势在于将代码分解成测试与工具模块。

这些模块一经识别，便通过一些内部封装有测试数据的GOOP- 类VI 对其进行改造。一旦完成该项工作，系统便支持根据需要动态加载这些模块至系统存储器或自系统存储器卸载。因而，UI便可与系统代码的其余部分相分离。

系统架构展现了OOP 类中的数据封装

这样显著地降低了系统中的存储器占用――约2 Mb（供UI 使用）加上1~5 Mb（取决于同时使用哪一个。其他方面的系统改进包括将系统的某些时间关键的处理工作（如E-stop 处理子例程）分发至网络的其他部分，以避开OPC 服务器中的延迟。这是通过Compact FieldPoint 与LabVIEW 实时模块实现的。
展望

系统在获得所期望的性能与灵活性的同时，也支持我们规划设备的更替。现在可以升级部分设备而不影响其他部分。例如，现在的RS232- 驱动的DMM将由通过LAN控制的NI PXI 替代。这可以通过在某个测试湾中使用GOO 来完成，而不必使用主要设备宕机。
总结

长期开发这一设备的想法早就被放弃。这使得后来几个月的开发过程的管理更为轻松。

就灵活性、可维护性、代码性能、装配可靠性和成本节省而言，向GOOP 编程模式的转换所获得的回报远远超出预期。

在生产流水线环境下，新的架构使得动态修改系统得以实现，以获得对开发中的中间产品的支持。

如果您有任何问题,请留言给NI工程师，我们会尽快给您回电！

Author Information:
For more information on this Case Study, contact:
John Duncalf
主要单元团队负责人－ BAE Systems (英国)