硬體 DVT 延誤:智慧裝置專案為何卡在原型到量產之間
硬體開發最讓人摸不著頭緒的階段,不是發現什麼跑不動、這種本來就在意料之中的問題,而是中段——原型機能動了、demo 也夠有說服力,團隊對專案非常有把握的時候。而這個階段,往往也正是最燒錢的問題悄悄長大的階段。
所謂 DVT 延誤,指的是專案卡在設計驗證階段、在進入量產前不斷累積修改循環的情況,這是第一次做硬體開發時最常見的失敗模式之一。而搞懂它為什麼會發生,正是打造一套不再重蹈覆轍開發流程的起點。
DVT 到底在測什麼
設計驗證測試(Design Validation Testing)的目的,是確認產品在實際使用會遇到的各種操作條件下,都能達到規格要求的表現。它測的不只是產品「能不能動」,而是它能不能穩定地、可重複地,並且在真實使用者會製造出的各種狀況下正常運作。
上述區別很重要的原因,是因為原型驗證和 DVT 測的是兩件不同的狀況。原型機證明的是一個概念在受控環境下「技術上可行」;DVT 檢驗的則是產品是否已經準備好大量生產、並投入真實世界使用。大多數的 DVT 延誤,就藏在開發者對這兩件事之間的落差裡。
原型機成功,證明的是工程概念走得通;它並不代表產品已經可以量產。這是兩個不同的問題,需要兩套不同的解法。
DVT 修改循環最常見的幾個來源
複合負載下的散熱表現,是最常見的 DVT 失敗模式之一。一台裝置單獨跑某個子系統時溫度控制得還可以,但當行動網路、Wi-Fi、藍牙和主應用處理器在封閉的機構空間裡同時運作時,表現就可能超出規格。原本單獨驗證過的散熱設計,必須放回完整系統的環境下重新驗證,而這個階段的修改往往得動到模具。
RF 共存問題和散熱密切相關。某些無線協定之間的相互干擾,在受控的 RF 測試環境(電波暗室)裡不會出現,卻會在倉儲、零售或車隊等實際佈建場景中浮現——因為那些環境的 RF 條件既密集又難以預測。在 DVT 階段處理共存問題,得修改天線設計、韌體排程,或兩者都要動,而 RF 修改的驗證週期並不短。
產線測試的系統涵蓋不足,則構成第三類 DVT 延誤,性質和功能表現問題不同。一台裝置就算通過所有功能測試,如果產線測試流程沒有跟產品同步設計,照樣沒辦法有效率地量產。需要人工校正步驟的測試治具、耗時超過目標節拍的測試流程、以及讓不良品流到現場才被發現的測試涵蓋漏洞——這些都是會在 DVT 階段才冒出來、且需要工程人力去解決的問題。
為什麼該改的是開發節奏本身
對有經驗的硬體團隊來說,DVT 失敗其實很少是意外。複合負載下的散熱、密集環境中的 RF 共存、產線測試涵蓋率——這幾類風險大家都心知肚明。它們之所以拖到後期才浮現,是結構性的原因:大多數硬體開發流程,都是按照一個個前後相接的階段在跑,而製造端的意見,往往要等到設計大致定案之後才進得來。
更根本的問題在於,開發節奏本身就建立在一個把設計和製造當成兩個獨立階段的模式上:先把設計做出來,製造端再來評估設計出了什麼。等到製造上的限制終於浮上檯面,要回頭處理的成本早就大幅墊高了。
那些能穩定縮短 DVT 週期的開發流程,組織方式不一樣。製造工程、測試工程和供應鏈的意見,是在設計階段就到位,而不是事後才補上。這不只是「把對的人找進會議室」而已,而是要讓開發排程裡明確設下幾個決策節點,在設計拍板之前先評估製造可行性。需要圍繞這些觀點及早整合來安排的,是專案的節奏,而不只是團隊的組成。
整合經驗,是專案的一項資產
對於要和外部設計夥伴合作的團隊來說,該問的問題是:這個夥伴以前有沒有做過類似產品、並成功量產出貨的經驗?他們會不會在設計階段就主動點出可製造性的限制?如果一個夥伴的製造經驗要到 DVT 才看得出來,那等於是在提供「太晚的回饋」——而晚回饋要付出的代價,遠比早回饋高出許多。
供應鏈上的決策,會以一種很容易被低估的方式讓問題雪上加霜。當初為了做原型而選用的零件,有時還沒下量產採購單就已經停產或供貨吃緊。一旦這種情況發生在 DVT 或更後面的階段,後果就不只是「換一顆料」這麼簡單——它可能是一輪牽動認證的重新驗證、一次牽動模具的設計變更,或是一場影響到客戶承諾的時程大亂。
結語
硬體開發出現 DVT 延誤,並不代表工程做得差。它通常代表的是:開發流程的安排方式,把最燒錢的決策,硬是拖到了時程上最燒錢的那個點。做出一台能動的原型機,是一項工程成就;但要從原型機走到一個能穩定大量生產的產品,則是一個系統與流程的問題。把這兩件事當成同一個問題來處理的團隊,往往就是那些在預計量產三個月後,還困在 DVT 修改循環裡的團隊。
常見問題(FAQ)
Q:在硬體開發中,EVT 和 DVT 有什麼差別?
A:工程驗證測試(EVT)確認的是設計概念走得通、主要技術風險已經排除。設計驗證測試(DVT)確認的則是產品在完整操作範圍內都能符合規格、且已經可以進入量產。EVT 失敗是預期之中的,代表有設計問題要解;DVT 失敗則代表產品還沒準備好量產,需要額外的開發循環。
Q:DVT 延誤通常會讓硬體開發時程多拖多久?
A:DVT 延誤對時程的影響,會因問題類型而有很大差異。不需要動硬體的韌體、軟體問題,有時兩到四週就能解決。需要修改機構或電路設計、接著還得改模具的問題,則可能讓時程多出三到六個月。需要重新設計天線的 RF 認證失敗,拉長的時間也差不多是這個量級。
Q:產線測試的規劃,應該在開發的哪個階段就開始?
A:產線測試的規劃,應該在設計階段、模具還沒拍板之前就開始。目標測試節拍、涵蓋率需求和校正流程,都該和硬體設計同步定義,而不是等設計做完才補。如果測試規劃拖到 DVT 才開始,結果幾乎一定是一套「不是為這個產品量身設計」的測試流程,得靠工程返工來補救,平白增加量產爬升的時間和成本。