王再躍 顧長利 劉奧琦
(安徽合肥聯寶信息技術有限公司 安徽省合肥市 230091)
隨著科技不斷發展和智能時代的到來,計算機作為智能產品已經在很多領域占有重要地位。與此同時,市場對計算機的產品形態,應用場景也提出了更多的要求。所以品牌計算機在研發和制造的過程中,會面臨如下幾個場景的挑戰:
為了避免單一硬件供應商的供貨壓力,在對硬件廠商的技術規格要求一致的情況下,在產品在設計初期會在同一配件上選擇2-3個同類型硬件廠商作為供給源。但不同的硬件廠商所提供的組件的軟件驅動是不一樣的,這就要求產品在研發階段需要針對不同的硬件+軟件做充分的整合測試,進而導入到出貨系統中。
在提升產品多市場覆蓋率方面,對產品研發初期的定位集中在需要針對不同的應用場景搭配不同的系統版本,以此做到一機多用,既能減少研發成本,也能便于后期維護和延長產品的生命周期。
以上兩個場景,在實際研發生產過程中會遇到以下幾個問題:
(1)傳統的系統灌錄方案是將特定的Windows 系統和適配的硬件驅動綁定為個體,通過拷盤或者Ghost 方式,可以實現“一對一”的適配安裝。但是,面對批量生產的計算機訂單,傳統的“一對一”方案無法高效作業,且對于系統+硬件組合過多的場景,無法做到準確安裝。
(2)如果采用自動灌軟方式,在Windows 系統和驅動的組合搭配上有局限,目前只能實現“一套系統+多套硬件驅動”的組合方式,當涉及到“多套系統+多套硬件驅動”時,需要針對每一套系統單獨創建灌錄單位,當場景1 和場景2 重疊條件過多的話,不利于后期維護。
本研究目的在于找尋一種智能灌軟方案,增加對“多套系統+多套硬件驅動”組合的灌錄支持。該方案能將現有需要使用到的系統版本和不同的硬件驅動整合為一個完整的灌錄單位,要求灌錄單位內模塊化設計系統和驅動,并增加標簽識別,通過執行腳本來判定系統和驅動之間的搭配關系,從而實現在同一個產品上,根據實際訂單所指定的出貨系統,智能判斷并撈取對應的適配驅動安裝,確保組合關系準確,從而在生產制造過程中減少繁瑣的數據庫維護,降低后期系統灌錄時間成本,最終提高產能。
如圖1所示,在現有流程中,產品需要灌錄的系統a 是唯一的,產品所裝配的硬件會有唯一的硬件ID 作為標識,在為硬件安裝軟件驅動時會給每個驅動增加ID 判斷的動作,當識別到某個硬件ID存在時,通過腳本調用該硬件適配的驅動進行安裝。

圖1
此時增加一個不同版本的系統b,如圖2所示,單個硬件會提供不同版本的A,B 兩組驅動的支持,分別對應不同的系統版本,但是硬件ID 卻是唯一的。那么判斷硬件ID 的方案就無法準確地對應不同系統版本進行選擇安裝。

圖2
針對這種場景,我們發現:既然已經能獲悉系統版本和與之對應的驅動搭配,如果可以預先對系統+驅動進行分組,那么在流程上只需要對系統層多增加一個判斷邏輯,就可以實現從系統源頭上將同一硬件的不同驅動版本加以區分。
首先,我們從產品立項階段獲取到目標系統的版本組合,嘗試從多個目標系統找出唯一體現系統屬性的特征作為判定標識,例如:系統版本號,系統名稱等。 當唯一特征確認后,和硬件廠商確認是否需要針對不同系統提供不同的驅動版本支持。通常情況下,如果系統之間的版本跨度過大,則必須將硬件驅動加以區分,例如硬件A 在兩種Windows 系統下的驅動版本支持
已知硬件A 的驅動20.0.0 和 19.0.0 是針對不同系統版本所設計的軟件版本,而硬件ID 唯一,當兩個版本的驅動整合在一個灌錄單位內,則需要對上層系統版本做初步判斷。
其次,在上表中我們發現兩個系統版本名稱不同,此差異點可以作為突破口,于是嘗試在圖1的流程X 到流程Y 之間設置斷點,抓取系統輸出的信息,確認不同的系統在安裝后所顯示的版本名是否唯一。通過多次實驗得出,兩個系統分別在完成流程X 之后輸出以下信息:
在確認以上信息穩定輸出且具備唯一性之后,我們:
(1)在流程X 結束位置增加了一個BAT 腳本用來抓取該系統版本名并將其打印到一個新建文本文檔中。
(2)保留該文檔作為此次灌錄流程中的一個特征判定Anchor(以下簡稱“Anchor”): Anchor 中包含抓取到的值為LTSC 或者Win10 Professional(例),用于在流程Y 中作為匹配標識。如圖3所示。

圖3
(3)以上Anchor 創建過程是通過腳本實現的,而同時我們也需要對驅動列表賦予標簽,確保Anchor 中體現的當前系統版本能和驅動匹配后再安裝。
(4)在流程Y 執行過程中,該Anchor 會和所有硬件驅動模塊進行比對,類似于當硬件A 被識別為存在時,原有流程下會調用硬件A 驅動,而灌錄單位中同時存在20.0.0 和19.0.0 兩套驅動。此時Anchor 啟動,查找驅動模塊中預先被賦予的系統標簽,如果和該Anchor 中的保存信息一致,則啟動安裝;反之,則跳過安裝,繼續查找直到從灌錄單位中找到包含與Anchor 信息一致的驅動版本。
在實際執行過程中,我們發現對于預先標簽化驅動模塊的維護容易出錯,例如為驅動添加標簽時的拼寫錯誤;標簽中空格無法識別;判定邏輯寫反等。 基于以上問題,需要嘗試用一種更加簡單明確的標簽定義方式避免潛在的人為失誤。為此,我們針對事先在系統端生成的Anchor 進行二次轉譯:用0 和1 替換先前冗長的版本名稱,當抓取到系統版本名為LTSC 時,Anchor 存為0;如非LTSC 則存為1。更改后的適配邏輯為:
(1)當Anchor 值為0,表示當前系統為LTSC,Anchor 在尋找適配驅動時,遇到標簽為0 的驅動模塊才執行安裝,反之不安裝;
(2)當Anchor 值為1,表示當前系統為常規系統,Anchor 在尋找適配驅動時,遇到標簽為0 的驅動模塊直接跳過,僅安裝未加標簽的驅動模塊列。
至此,通過預先確認到的多系統Anchor 信息并將其作為唯一標簽,區分了同個硬件ID 上的不同驅動版本,實現了兩套系統+兩套驅動版本的灌軟流程管控。通過該方案,對研發過程中針對任何軟件應用需求的定制化得以實現,可以在灌軟流程的任意節點上設置斷點,讀取所需信息并加以判定,從而編寫腳本根據判定結果實施下一步定制化操作。
該方案的導入減少了量產訂單的維護成本,從維護多套系統灌軟組合縮減為僅需維護一套集成系統灌軟單位;從投線數量上減少了繁瑣的站別管控,精簡了人力耗材的投入,從而進一步避免了由于復雜繁多的系統組合造成灌軟錯誤的風險。為產線智能制造提供了合理的解決方案。