傳統自動測試系統缺乏通用性，最根本的解決方法是標準化。本文以ABBET（A BroadBased Environment for Test）標準為主，與ATS（Automatic Test System）相關的其他國際標準為輔，采用符合標準描述的軟件層次結構，使用COM組件和CORBA等軟件設計技術，開發了面向信號的通用自動測試系統軟件平臺。采用基于國際標準ATS開發模式，一方面可以使面向信號的測試最大限度地實現儀器無關性和TPS（Test Program Set）通用性；另一方面這種開發模式簡化了軟件系統架構難度，提高系統的可靠性和兼容性，對外部診斷方法提供了統一的接口。

隨著電子科學、材料科學等技術的飛速發展，航空航天設備、軍用武器系統等高技術產品的復雜程度日益提高，傳統的人工檢測維護手段已經無法滿足現代化裝備的支持保障要求，ATS（自動測試系統）正逐步成為復雜系統與設備可靠運行的必要保證。

然而，我國目前尚無統一的測試技術體制和管理體制，也沒有需要強制執行的測試軟件體系標準。各種軟件采用的數據結構不相同，系統模型千差萬別，帶來測試軟件系統繁多的種類和低水平的重復研制。另外，測試軟件運行環境不規范，使用的測試語言不統一或版本各異，導致系統測試軟件不通用，造成開發周期長、重復開發、移植性差、交換能力弱等缺陷，在很大程度上影響了用戶對其的掌握和使用。以上因素使得測試系統軟件平臺的通用化、標準化、模塊化、系列化方面與國際水平差距很大，成為制約我國自動測試系統發展的首要因素。

本文重點研究了測試泛環境（ABBET）標準體系結構和實現軟件平臺通用性的關鍵技術，將ABBET定義的軟件體系框架結構細化為5個可操作的軟件層次（測試策略與需求層、測試程序層、資源管理層、儀器控制層、硬件層），利用每層相關標準分別開發其功能，實現層次間通信，最終開發出面向信號的通用自動測試軟件平臺。

1　測試相關國際標準概述

IEEE 1226 ABBET標準是一種軟件體系結構規范，使按照該體系結構搭建起來的軟件平臺之間進行標準化的數據交換和相互操作。ABBET 對測試軟件作了重點描述和規范，從信息建模的角度對測試信息進行形式化描述，消除了層次間測試信息移植、共享和應用的障礙。在軟件設計上，強調系統重構或重組，能夠根據被測對象或測試流程的不同而動態地進行重組，降低系統重組的代價。但是ABBET標準僅僅提出了ATS框架并描述了測試開發過程中各個層次之間的關系，在具體應用上如何實現這些層次的功能，實現一個完整的面向信號的自動測試系統，則需要設計者自行開發。

IEEE 1226.3和IVI儀器驅動規范描述如何最大限度地實現儀器互換性。

IEEE 1641標準提供了基于COM技術實現的信號描述與控制的能力，使得用戶可以選擇任意支持COM的開發平臺與程序設計語言，而且能夠很方便地實現測試程序的可移植。

IEEE 1671提供了一個開放的信息傳輸的標準，使得信息可以在不同測試儀器的測試程序之間傳輸，為TPS可移植與互操作、儀器可互換提供了便利條件。

IEEE 1232標準定義了ATS故障診斷服務接口。它提供了基本診斷服務，同時允許各種診斷方法添加到ATS中去，大大提高了ATS故障診斷水平。

2　測試平臺軟件架構

2.1　ABBET結構層次

ABBET結構由基礎結構中的單一類別創建的類別集合所構成。這個基礎提供了基礎類和主要類的參考結構。這可以被指定在不同的層次創建通用測試環境（框架結構）或專用測試應用程序。

ABBET標準的體系結構分為3個層次：基礎框架結構、擴展框架結構和應用。

基礎框架的組織類似于一種接口的集合，其中每個接口與一個或多個ABBET組件標準相關，或者與IEEE或其他公認的組織發布的行業標準相關。定義了適合某個產品系生命周期內不同階段相適應的基礎接口。

一個TAF是一個可再用類別集合，來完成一個特定應用領域的要求。每個TAF服務于測試主題中的特定類別、技術、資源或需求。擴展框架就是由一個或多個這樣的應用框架（TAF）組成。

ABBET提供從開發工具和TAF直接訪問應用。一個應用可能使用一個或多個框架來提供到執行應用的類的訪問。圖1顯示了ABBET結構層次，圖2說明了根據與ABBET 組件標準有關的操作、功能以及組織進行劃分的ABBET體系結構。

圖1　ABBET結構層次 　圖2　ABBET體系結構

表1列舉了測試泛環境的分層模型及每層需要用到的設計和測試標準。

表1　測試泛環境分層測試標準

2.2　測試平臺軟件結構

要實現通用ATS，則要求對資源的需求描述、虛擬資源的模型，以及對真實資源的驅動均基于信號接口，要摒棄驅動基于儀器的做法。TPS的可移植性和儀器可互換性的關鍵在于驅動模型的構造。

使用面向信號的驅動組件，當虛擬資源映射成真實信號時，儀器暴露給軟件系統的是信號接口，而不是具體儀器。ABBET采用TFF信號模型描述測試需求，與具體測試系統無關。

圖3顯示了基于TFF信號模型的面向信號測試系統軟件平臺結構。

圖3　軟件平臺結構

測試策略和需求層用于用戶配置測試信息，如測試需求、測試策略。

測試程序層完成測試流程設計，并從測試需求和測試流程轉換為測試代碼。TFF信號模型組件庫為不同編程開發環境的TPS開發提供信號模型。

資源管理層完成虛擬資源到實際資源的映射，執行具體的測試流程。編程語言接口將各種編程語言表示的測試信號資源需求形式變換成虛擬資源。資源模型庫用來具體資源建模。驅動組件對驅動實際資源。

儀器控制層全面遵守IVI儀器驅動規范，利用IVICOM技術，驅動實際測試儀器。

3　關鍵技術討論

3.1　RTS運行機制

RTS是資源管理層中核心組件，它首先對測試程序進行語法檢查和編譯，轉換為信號模型對應的條目（信號類型、UUT 端口連接、信號范圍、信號屬性、方法調用等）；然后啟動查詢引擎，將虛擬資源定位到真實資源；接下來調用驅動引擎，按照連接模型執行UUT端口和信號端口連接算法，并執行信號模型規定操作，實現測試流程。

RTS機制保證了虛擬資源與真實資源完全隔離。虛擬資源只提出測試需求，不涉及ATS儀器配置。RTS在TPS運行中始終處于工作狀態，捕獲TPS的測試需求，控制驅動組件驅動實際儀器執行測試流程，直到TPS執行完成后才退出。

3.2　虛擬資源管理機制實現

資源管理層是平臺的核心層。在RTS組件中的“虛擬資源管理器”模塊的作用是對具體信號進行分析，然后對具體儀器進行選取和驅動。虛擬資源管理結構如圖4所示。

3.2.1　虛擬資源建模

平臺中虛擬資源采用TFF信號模型建模方法和組件技術，按照面向對象的思想，將信號分為有限的幾類：常值、斜坡、隨機、指數、脈沖、階越、衰減正弦、梯形、噪聲（非周期類），正弦曲線、三角、方波、標準正弦、其他波形（周期類）。其中，每類信號都以統一參數屬性表建模，以便于實例化。

3.2.2　信號驅動組件

儀器驅動組件模型采用TFF 信號驅動組件模型，模型包括信號信息（名稱和邏輯地址等）、信號屬性、信號能力、信號端口及其信號驅動方法。這和虛擬資源的需求是一一對應的，有利于虛擬資源到真實資源的映射。同時它還包含信號名稱、邏輯地址及其能力等信息，提供給RTS做查找真實資源和定位。具體來說，向上對信號驅動組件通過信號模型中的方法和事件實現，向下對底層儀器的操作使用通用的重封裝的具體儀器驅動實現。

3.2.3　資源模型實現

測試資源模型提供ATS對系統資源配置和與被測單元連接通路的數據模型及管理，資源模型包括設備模型、配置模型及適配器模型，使用數據庫建立和表示模型，使模型規范化和易修改。

設備資源模型DM描述了具體資源的相關信息，是實現資源管理器依照信號需求選擇儀器的基礎。在數據庫中通過設備記錄表和設備功能表來描述設備模型：設備記錄表描述了ATE系統中所有的測試設備的相關信息；設備功能表記錄了測試系統中儀器設備的信號發生/測試能力。

配置CM模型定義了具體測試系統的開關資源的輸入、輸出關系。其中包含了各種開關資源、模擬總線的連接問題，因而具有較復雜的連接關系。適配器模型AM定義了開關資源與UUT的連接關系，與配置模型比較類似。采用數據庫表的形式來建模，與測試系統配合，實現儀器的匹配、通道的選擇和整條通路的連接。

圖4　虛擬資源管理結構

3.3　最佳通路選擇問題

實際應用中，具體的硬件設備種類比較多，而且每一種硬件設備都能實現多種信號功能，開關和通路連接也不止一種方式，這樣就帶來RTS對儀器和通路的選擇問題。

測試路徑搜索可以用到狀態圖搜索的理論，目前成熟的算法也比較多。根據實際問題的情況和對最優解的需求，選取A*算法作為最優測試路徑選擇問題的基本解決方法。A*算法通過對估價值的計算來處理節點的取舍，在最優測試路徑選擇的實際問題中，在計算估價值之前利用約束條件、節點位置等信息減少節點的數量，極大地減少搜索的盲目性，迅速求得最佳路徑。

結語

在已有平臺上的試驗證明，這種軟件平臺的設計是可行的。基于國際標準設計測試系統軟件平臺，解決了儀器互換性和TP可移植問題，體現了面向對象的思想，實現了測試系統軟件平臺的通用性。