摘　要： 驅動器是連接虛擬儀器物理硬件和測試應用程序的橋梁和紐帶，回顧了虛擬儀器驅動器技術規范的發展歷程。在分析規范的基礎上給出了兩種驅動器設計類型，預測了其今后的發展趨勢。分析了驅動器發展過程中的相關支撐技術，論述了我國的研究現狀，指出基于組件技術的信號型驅動器設計是虛擬儀器驅動器的發展方向。
　　關鍵詞： 虛擬儀器 驅動器 信號接口 COM 軟件工程

　　IVI-MSS 中IVI-MSS Solution作為一個獨立的軟件層，為儀器互換提供了解決方案；RCM由開發人員根據需求來定義，對于不同的測試需求，即使是同一測試儀器平臺，RCM也是不同的。在更換儀器后，只要提供與原始儀器功能相同或相當的RCM，就可實現相同的測試功能，這樣大大拓展了儀器互換的空間。
1.6 IVI-Signal Interface
　　2000年，IVI基金會的Signal Interface工作組在TYX公司和HP公司的領導下開始制定IVI-Signal Interface標準。它基于COM(Component Object Model)技術，是一系列COM組件的統稱。
　　在IVI-MSS模型基礎上發展起來的IVI-Signal Interface標準把原先的儀器控制命令轉化為對測試信號的需求，把IVI-MSS Server功能接口進一部封裝形成IVI-Signal Interface信號接口。這克服了“面向儀器”的TPS開發中存在的弊端，實現了更高層次的儀器互換。信號接口的標準化增強了不同廠商儀器之間的互操作性，方便了代碼移植。同時，為儀器驅動器開發帶了巨大商機，提高了IVI信號組件的開發效率和質量，有很看好的應用前景。
　　綜上，當前占主導地位的驅動器設計規范主要有兩種： VPP規范和IVI系列規范。兩種驅動器開發規范的共同點是均建立在IEEE-488.2和SCPI命令以及VISA庫之上，都包括接口和內部實現兩部分。不同點是前者已發展成熟，它以儀器本身的特征應用為中心，是功能驅動的，多由儀器生產商提供，接口沒有嚴格的語義標準，實現了儀器的即插即用" title="即插即用">即插即用，沒有實現儀器互換和軟件移植等功能；而后者建立在VPP之上，正處在發展完善之中，它面向UUT的測試需求，是需求驅動的，由測試系統集成人員或第三方軟件開發人員編寫，接口有嚴格的語義標準，部分地實現了儀器互換性和軟件移植性，并最終向著完全實現而努力。目前VPP規范已被多數廠家所采納進行自己產品的驅動器開發，因此將在未來很長的一段時間內占統治地位。但由于它在解決儀器互換性問題上無能為力，隨著IVI系列規范的進一步完善，必將被其替代。
2 驅動器開發
　　根據以上驅動器設計規范發展回顧及分析可知，驅動器開發也分為兩種類型：基于VPP規范的即插即用型驅動器開發和基于IVI系列規范的互換型驅動器開發。
2.1即插即用型驅動器開發
　　開發基于VPP規范的即插即用型驅動器的過程分為兩步。第一是儀器驅動器外部接口的設計，它表示儀器驅動器如何與外部軟件接口，通常提供兩種方式的接口：程序式開發接口和圖形軟面板。軟件開發者通過程序式開發接口可以理解每個儀器驅動器函數的功能以及在應用程序中如何調用每個函數、另一種接口方式是圖形化軟面板，通過這一軟面板可以直接操作控制物理儀器。第二是要完成儀器驅動器的內部模塊設計，實現儀器的硬件功能。使用程序式開發接口的用戶了解了這一功能，可以在應用程序中直接應用這些模塊，而不必通過軟面板操作。
　　要完成第一項工作應選用界面編輯功能較強的編程環境，減少儀器軟面板的開發時間；第二項工作通過調用 VISA I/O庫中的函數來完成，編程語言按照VPP規程可以選用ANSI C、BASIC或者Ada等。選用合適的圖形軟件工具可以把這兩部分工作集成到一個環境下完成，省去兩部分的連接工作，例如NI公司的可視化軟件平臺 LabWindows/CVI。CVI開發環境中兩部分組成：用戶界面設計器和源代碼" title="源代碼">源代碼編輯器。
2.2互換型驅動器開發
　　與即插即用型驅動器類似，基于IVI系列規范的互換型驅動器開發也包括兩部分。第一是分析測試系統的功能需求，以功能或信號的形式分類定義驅動器組件的接口。這些接口是對UUT測試需求的描述，有嚴格的語義標準，將不隨儀器種類和軟件類型而改變，是標準的，通用的。第二是驅動器組件接口的內部實現，它被封裝在組件內部，可以根據具體的開發工具和編程人員特長來開發，是非標準的、特殊的。
　　對于基于IVI系列規范的驅動器開發，目前還沒有專業的、IVI基金會指定的開發工具。但由于其采用COM技術，因此可以使用任何支持組件開發的編程平臺進行開發。設計人員在理解技術規范的基礎上可以利用現有的圖形化編程工具(比如VC++、VB等)進行設計。
　　需要說明的是，IVI是介于VPP和IVI-MSS之間的一個過渡性規范，它既有IVI-C的C語言形式，也有基于COM的IVI-COM組件形式，并且接口的嚴格語義標準目前只發布了八類儀器的技術規范，因此可以根據具體情況選用相應工具進行開發。
3 發展趨勢
　　(1)信號型驅動器
　　由前面對IVI-Signal Interface標準的介紹可知，信號型驅動面向UUT的測試需求，是需求驅動的，符合當前計算機體系結構發展趨勢，而且實現了更高層次的儀器互換和互操作，通用性好。隨著面向信號的商業化虛擬儀器軟件開發平臺的不斷涌現，如PAWS、ATLAS 2K等，迫切需要給出標準化的軟件開發平臺與底層硬件模塊之間的接口，而信號型驅動器恰好實現了面向信號的TPS開發平臺與底層硬件模塊的完美對接。基于以上分析，信號型驅動器將是虛擬儀器驅動器設計標準發展的必然結果。
　　(2)網絡化驅動器
　　網絡的普及給各個行業都帶來了巨大沖擊，測試領域也不例外，網絡化虛擬儀器和儀器網絡化現已成為當前測試技術的一個研究熱點。而要想實現遠程控制儀器就必須提供儀器設備的網絡化驅動器或在現有儀器驅動器的基礎上添加網絡化功能。基于此，VXI聯盟(VXI Consortium)提出了VXI-11規范，這個規范主要是對IEEE-488總線的擴展，也就是通過TCP／IP發送IEEE-488總線命令。該擴展的目的在于實現遠端的客戶端通過網絡與現場儀器通信并完成測試任務，并且對用戶來講好像是在本地使用儀器一樣。隨著虛擬儀器技術和網絡技術的發展，網絡化驅動器將取得更大的發展空間。
　　(3)VISA兼容更多的接口類型
　　計算機接口技術不斷發展，涌現了許多商業化PC總線，如USB、Ethernet等，這也是影響虛擬儀器發展的關鍵技術之一。由于這些總線最初是為網絡PC和連接PC外設而設計的，要更方便地控制儀器，這些總線需要軟件構架來簡化通信并與其他一起控制標準兼容。因此，需要對虛擬儀器驅動器標準框架VISA進行擴展。
　　(4)與商業TPS開發平臺“即插即用”
　　驅動器是連接計算機和物理儀器的中間環節，是虛擬儀器開發的重要資源。當前的TPS開發平臺向著集成、高效、商家壟斷方向發展，如HP公司的VEE、NI公司的LabVIEW、LabWindows/CVI等。為了擴展自己的市場空間和便于用戶開發使用，虛擬儀器硬件設計廠商或第三方軟件開發單位應該提供與這些商業開發平臺“即插即用”的驅動器。同時，為了加強合作和簡化集成，商業TPS開發商也應該給出與自己平臺兼容的驅動器設計標準并提供相關技術支持。
　　(5)源代碼級開放式結構
　　當前，從源代碼開放的角度來講，虛擬儀器設計領域存在三種驅動器類型：封閉黑盒型，封裝型和開放源代碼型。其中封閉黑盒型不提供對源代碼的訪問，不具備擴展和編寫儀器新功能的能力；封裝型驅動可作為驅動器二次開發的原始接口或封裝器；而開放源代碼型驅動原生于相應的開發環境，提供對源代碼的完全訪問權限，經過優化和改進后能易于使用并具有集成的靈活性，能讓開發人員定制自己的功能需求，把開發觸角伸向了儀器設備的心臟地帶。
　　虛擬儀器的一個重要特點是硬件的功能由軟件來定制，而從某種層面上講，驅動器是儀器功能的描述和表達。當前多數儀器硬件模塊開發廠商在發布自己的產品時，都把驅動器作為“黑盒子”來發布，這不利于客戶定制自己需要的功能和進行二次開發。另一方面，由于軟件升級換代相當迅速，這也給驅動器開發提出了新的要求。現在多數儀器驅動在向.NET平臺移植時都存在各種各樣的困難，而驅動器源代碼級開放是解決這些問題的前提。不僅如此，開放源代碼型驅動還能簡化與儀器硬件的連接，使開發人員不僅是驅動器的使用者而且是擁有者。因此，儀器驅動器采用開放源代碼式結構將是一個重要的發展方向。
　　(6)可視化配置操作
　　可視化與完備的人機交互能力是現代軟件開發的基本要求，作為虛擬儀器核心的驅動器在這方面應能滿足客戶的更高的需求。把軟件開發人員從繁重的代碼編寫任務中解脫出來，而把主要精力放在測試功能的實現上是驅動器設計迫切需要解決的問題。將儀器連接配置、編寫測試代碼、測試任務的組合設定等繁瑣工作轉變成友好人機界面下的鼠標操作，必將簡化虛擬儀器系統的集成開發。為此，在驅動器設計領域出現了虛擬資源、虛擬通道等概念。它們把物理資源和通道的信息(比如量程、端口配置等)進行封裝，通過友好的界面與開發人員進行信息交互，實現了儀器控制的可視化配置操作。
　　(7)拓展應用空間
　　儀器驅動器是計算機控制物理儀器設備的中間環節，隨著虛擬儀器的不斷發展，這一思想也拓展了嶄新的發展空間。驅動器越來越多地以“服務”的形式為測試程序提供功能調用。如IEEE 1451.4標準給模擬傳感器定義了電子數據表格并內嵌于其中，測試系統或TPS開發平臺可以通過模擬傳感器提供的數字接口讀取電子數據表中的數據并對其進行配置，這在一定意義上也是驅動器應用的新領域。使用基于IEEE1451.4設計的智能傳感器可以簡化傳感器的連接過程，實現傳感器的“即插即用”和自動配置。ISP(Programmable in-system)技術在電子設計自動化領域得到了廣泛應用，基于此，NI公司提出的RIO(Reconfiguration I/O)技術完成了物理儀器的在線可編程控制，實現了用戶自定義硬件，是儀器驅動器概念的升華。
4 關鍵技術
　　(1)COM技術
　　COM技術的核心是組件，組件是可以明確辨識和管理、可以提供某項服務的自包含的軟件模塊。它封裝了一定的數據(屬性)和方法(函數)，并提供特定接口。開發人員通過訪問這些特定接口來使用組件，與其它程序模塊通信、交互，實現預期功能。組件是實現儀器驅動器語言、平臺無關和網絡位置透明的關鍵技術。
　　基于組件技術的驅動器模塊通過標準接口與其它軟件模塊通信，各個組件就像掛在“軟總線”上一樣通過公共通道傳遞信息。基于此，編程人員可以象“搭積木”似的開發自己的測試程序。更換儀器后，只要驅動器接口不變就不用更改測試程序。使用驅動器組件使得儀器模塊的互換性、測試軟件的開放性和可重用性得到了根本保證，同時實現了軟件開發和應用的不斷“迭代和增量”過程。
　　(2)多線程技術
　　同步、觸發、時序操作是儀器控制的客觀要求，而多線程技術是滿足這一要求的關鍵技術。Windows操作系統是一個多任務、多線程操作系統，實行的是搶先式、多任務工作模式。在Windows環境中，每一個測試項目可以由一個線程來代表，這意味著一個測試程序可以同時完成多個測試任務。在多線程執行中系統會根據線程的優先級和同步要求分配時間單元用于執行多個線程，這樣實現了多任務分時占有CPU，可在一個段時間內并行完成多個測試任務。多任務、多線程之間通過同步、通信(如共亨內存映射文件、訪問共亨數據以及使用同一消息隊列等)以實現復雜的測試、控制邏輯。
　　(3)引擎技術
　　測試程序的儀器操作過程是TPS利用驅動器控制硬件儀器的過程。為了優化這一控制過程，需要引擎技術，把軟件代碼的控制需求轉變成實際的物理儀器操作。測試中用到的最多的同步、觸發功能，若有多個同步步驟需要連續、高速觸發，在這樣的情況下，僅需要測試代碼去控制是很難滿足需求的。為此，可以設計基于引擎技術的同步觸發引擎，把測試需求編程一定的序列輸入到相應的同步觸發引擎中。依據測試程序的執行自行觸發這一序列，將大大提高測試效率，滿足更高的測試速率要求，使測試程序具有自主觸發和時鐘路由能力。另外，隨著便攜式、模塊化、嵌入式實時環境對虛擬儀器的要求越來越迫切，還需要開發驅動器在這些不同環境下的運行時引擎，以滿足各種需求。綜上，引擎技術在測試領域中有很大的發展空間，應倍加重視。
　　(4)軟件工程技術
　　儀器驅動器是對物理儀器的功能描述，軟件工程技術將能保證驅動器設計的功能完備性。1997年由 OMG(Object Management Group)發布的統一建模語言(UML，unified modeling language)和統一軟件開發過程是軟件工程領域中的重要成果，標志著面向對象技術走向第二代。UML支持從系統需求分析到詳細設計再到系統的驗證測試的全部過程，當出現問題時提供跟蹤機制。使用UML會幫助設計人員在建造驅動器框架中理解模型，把握儀器的全貌和功能、部件之間的聯系，防止過早地陷入各個模塊細節中去，有利于提高驅動器軟件的質量，縮短研制周期，降低開發費用。統一軟件開發過程是用戶驅動、以架構為中心、不斷迭代和增量過程。基于這一過程，可以設計出功能完備、接口標準、易于升級換代的驅動器。
5 國內現狀
　　我國在虛擬儀器驅動器研究方面取得了一定的進展：成都電子科技大學開發出了具有自主知識產權的VISA庫；哈爾濱工業大學電氣工程系開發的虛擬儀器軟件開發平臺—ATS95可以實現對VXI、GPIB等總線接口的控制；成都611所在引進PAWS平臺的同時也對面向信號的驅動器設計和平臺開發做了一定研究等等。但由于我國介入虛擬儀器研究比較晚，在硬件模塊方面沒有自己上規模、成系列的產品，導致了測試軟件沒有全面發展，很多關鍵技術仍處于起步階段，在驅動器設計方面沒有自己知識產權的技術規范和相關產品，仍需要很長的路要走。鑒于此，我們應在以下方面進行努力：(1)開發自己的總線控制器，占領虛擬儀器技術的心臟地帶；(2)設計各種儀器模塊產品并形成系列化，降低虛擬儀器系統的集成成本；(3)設計完備成熟的VISA庫，把握自己的知識產權； (4)開展面向信號的驅動器技術研究，與國際接軌，深入研究虛擬儀器核心技術。
參考文獻
1 IVI Foundation. IVI-3系列規范[EB/OL]. http://www.ivi-foundation. org.
2 National Instrument Corporation. Instrumentation Newsletter. Second Quarter 2004:8～9
3 National Instrument Corporation. Instrumentation Newsletter. Four Quarter 2004:19
4 National Instrument Corporation. Instrumentation Newsletter. Third Quarter 2004:6～7