儘管儀控設備廠商已於軟體應用領域投注眾多心力,以期減輕工作負擔,此舉卻催生了大量且分散的軟體工具;而且在建置、部署與維護測試系統必備的軟體工作流程中,難以彼此互通。在產品開發的各個階段中,工具必須具備可互通性;如果缺乏可互通性,勢必得另行投注大量心力進行整合。相較於將時間用在解決實際業務挑戰與建立產品上,花時間解決互通性問題幾乎毫無價值可言。
要以高效率因應緊湊的時程,除了要透過足夠的軟體抽象化功能,以簡化一般工作並重複使用程式碼之外,還得在適當階段握有相應的低階控制能力,才能進行測試專屬的完整客制化。可惜的是,目前沒有任何軟體能完美兼顧上述兩者。正因如此,若要充分發揮自身的工程設計潛力,勢必得採用兼具兩大要素的可互通軟體平台。
透過開放式的軟體導向平台,運用模組化硬體與廣大的生態系統,能提升測試與製造工程師的生產力。工程師可透過軟體來重新設定硬體,以賦予測試系統更大的靈活度,並加速實踐構想。雖然有越來越多的廠商已轉為採用「軟體設計的儀器」概念,此一現象卻也導致工程師必須疲於拼湊大量且分散的軟體工具。
在現實情況中,工程師必須面對緊湊的上市時程與嚴格的專案進度要求,因此必須在新測試系統的初期設計階段,善加運用各項資源,才能為團隊打下良好的成功基礎。新專案往往會面臨層出不窮的硬體決策:儀控設備、連接線、接頭、切換器拓撲、大量互連、機架配置、電力成本與散熱分析等。如果在確保量測品質的所有硬體拍板定案後,才發現所用軟體會造成生產力瓶頸,只怕會讓人欲哭無淚。為了協助簡化初始系統設定,原廠安裝服務會將所選軟體環境與必備硬體驅動程式,安裝至新的控制器上。如此一來,就能花更多時間考量測試需求,而不用為安裝驅動程式費神(圖1)。
視覺化環境助系統設定

工程設定往往會涉及不同廠商的儀器,而每款儀器的軟體功能也不盡相同。為此,工程師經常得耗費時間去翻閱厚重的使用者手冊,以取得子功能表設定資訊,或是搜遍網路,就為找出最新版本的裝置驅動程式;而廠商品質的參差不齊,更是讓情況雪上加霜。鑑於軟體開發而成的應用會與當中的硬體設定息息相關,使用者必須仰賴一致的管理解決方案,才能簡化這層基本關係。
NI在最新版本的LabVIEW NXG(圖2)中導入了名為SystemDesigner的圖形化畫布,可透過視覺化方式設定實體系統,將硬體設定、診斷與系統說明文件,帶入LabVIEW NXG環境中。如此一來,就能在單一環境中完整管理硬體並開發軟體,進而充分發揮開發生產力。如果NI或第三方驅動程式尚未安裝,SystemDesigner將引導用戶使用NI Package Manager(以業界標準封裝格式建置而成的介面),安裝必要的驅動程式。

在完成初期設定後,還要面對下一個無比複雜的任務:檢驗產品是否滿足所有設計要求。在測試開發程序期間,必須快速存取各種互動式量測作業(例如DMM讀取值或示波器顯示畫面),以便進行初期測試,完成訊號連線的除錯,以及檢驗量測準確度。在SystemDesigner中,可以啟動軟體人機介面,讓模組化儀器透過互動化方式監控硬體。有些儀器也可運用直接的電腦連線,進行載入與儲存波形或裝置專用設定,以利除錯。不過,若要盡可能減少人為錯誤、確保一致性,並加快上市時間,就必須將檢驗程序大幅自動化。
在檢驗設計的初期電路板時,經常需要重複執行特定測試。多次手動執行相同測試不僅冗長、枯燥,從商業觀點來看,也不符效率。如果研發小組的基本目標在於「完整檢驗設計,並迅速將其傳送給製造團隊」,就應該將他們的寶貴時間集中運用在需求與工程設計的調整上,而非浪費在可透過自動化程序完成的重複作業上。只要落實此一觀念,眼前最大的障礙,就僅剩建立測試而已;畢竟,硬體團隊與測試工程師之間的程式設計經驗,可能會有不小落差。而本階段的重點,則在於運用專業領域知識,且避免讓所選軟體的語法及程式設計建構,成為沉重的負擔。
LabVIEW NXG提供圖形化程式設計方式,可隨心所欲地進行程式設計,透過連接函式區塊來建置應用邏輯。此外,使用者介面(UI)設計也有所簡化,能透過拖放進行,進而以直覺化方式建立專業的使用者介面,供程式碼測試之用。最新版的LabVIEW NXG也將上述功能從桌面進一步延伸至網路,因此,即使沒有任何網路程式設計經驗,也可設計與部署網路架構的使用者介面;毋須透過外掛程式或安裝程式,就能在任何現代化網頁瀏覽器中,執行測試程式碼(圖3)。

這項新功能可協助工程師透過多種裝置與作業系統遠端監控測試,並將資訊提供給同事共用(對需要長期執行的測試而言特別實用)。
微調生產測試滿足產量需求
在產品自研發檢驗步入最終的製造測試後,就必須縮短裝置測試時間,以盡可能提高單位總生產量。在設計檢驗階段與生產階段重複使用儀控設備,可望降低兩個階段之間的量測關聯性心力,並提高軟體微調效率。
如果以相同的方式獨立執行與裝置檢驗階段相同的測試,可能會難以符合製造所需。正因如此,測試方式必須進行微調,以滿足產量需求。雖然大部分的程式碼都可以而且應該重新調整,唯有使用位於軟體堆疊最頂層的抽象化測試管理工具,才能將所有相關的客制化測試結合成一致的測試序列,並更有效率地測試一部裝置,或同時測試多部裝置,以找出其規格限制。但從零開始打造這類測試系統,需要耗費極大心力;相較之下,商用解決方案不僅能省下開發心力,還可加快上市時間。
TestStand是一款立即可用的測試管理環境與架構,能簡化生產測試系統的設計程序。TestStand可呼叫以多數程式設計語言撰寫的程式碼模組,協助團隊在LabVIEW NXG與LabVIEW 2017中,重複使用以G撰寫的測試,以及使用其他多種程式設計語言(例如C、C#與Python)撰寫的測試。這個環境會抽象化重要的生產測試函式開發程序,例如報表、資料庫記錄與平行執行,而且依舊可在需要時進行低階客制化。只要運用可畫分測試程式碼模組(通常專屬於受測裝置)以及測試執行系統(所有不同的受測裝置均相同)的模組化軟體架構,就能得到一個可擴充且靈活的架構,並壓低長期的開發、支援與維護成本(圖4)。舉例來說,自從Motorola的特性參數描述團隊與生產測試軟體團隊,採用以TestStand與LabVIEW為基礎的單一模組化測試應用進行標準化後,雙方的整體年度維護與新產品開發成本,便減少了一半以上。

公用程式滿足大規模部署
絕大多數的大規模測試系統都未採用獨立架構;而這些測試所提供的解決方案,可用於多個測試站點或是整個生產線。在測試開發完成後,再以手動方式部署測試序列及其所有必要相依性,經常會造成一大後勤挑戰。請想像一下,如果在完成20個測試器的手動部署安裝之後,才發現需要將歷經微幅修改的更新版測試序列重新部署至所有測試器,會發生什麼情況?如果測試器的數量高達1,000個,情況又會如何?
TestStand可使用內建的部署公用程式來部署測試序列、程式碼模組,以及所需的Run-Time驅動程式,進而簡化這項程序。另外,也可以使用自身熟悉的開發環境,以建立要使用測試序列部署的客制化操作介面(O/I)。實作使用者認證之後,TestStand功能存取就可自軟體架構的低階執行詳細資訊,一路向上延伸至操作人員;在已部署測試站的操作介面上,操作人員只需要按一下單一「執行」(Run)按鈕,合格/不合格(Pass/Fail)結果就會自動儲存至磁碟。
大型的分散式系統,則可使用名為SystemLink(圖5)的新款NI軟體產品,以協調大規模軟體部署、管理目標環境的驅動程式版本,並監控系統診斷資訊。中央伺服器節點可透過網路連線來管理分散式端點,同時簡化NI與第三方軟體將大型套件分配至目標系統的作業,進而減輕系統管理負擔,並降低與系統管理功能相關的後勤成本。

每間公司的產品開發週期皆不盡相同。許多公司會一再重複產品檢驗階段,以確保品質足以達到生產門檻,而過程中,極有可能需要重新審視設計與設定。在此同時,如果單憑生產預測來看,有些新創公司可能從未完整部署生產測試器。畢竟,如果每間公司的開發週期完全相同,而且每次的成功機率皆為100%,市場上絕不可能發生瞬息萬變的競爭局面。電子產品設計人員與製造商所採用的工具平台,必須要能在產品新增功能或提升規格(為求保持競爭性)時,順利進行修正。即使我們必然會在產品開發週期的初步階段,盡全力主動解決問題;但在現實情況下,唯有時時保持靈活機動性,才是上策。身為工程師,無時不刻都面臨此一挑戰,而工具絕不能成為阻礙。