本文轉自硬件十萬個為什么

曾經說過，在開始動手畫原理圖之前，需要做需求分析，專題分析等等工作。但是在真正開工之前，有反復的方案設計的迭代過程。也有一些不是研發出身的老板跟我抱怨，硬件工程師讓結構先設計、結構工程師說硬件工程師應該先給大致的需求，不知道應該誰先動。

工欲善其事,必先利其器是說:工匠想要使他的工作做好，一定要先讓工具鋒利。比喻要做好一件事，準備工作非常重要。語出《論語·衛靈公》：子貢問為仁。子曰：“工欲善其事，必先利其器。居是邦也，事其大夫之賢者，友其士之仁者。” 這個準備工作，當然不只是指工具，還有動手之前的策劃、思考、評估、方案設計、架構設計等。

硬件工程師動手畫原理圖之前，需要畫的一個東東就是，用“猥瑣”（Visio）畫出電路板方案框圖。

當然，每個工程師都有自己的喜好。有的人喜歡用Visio、有的人喜歡用PPT，這都無所謂。關鍵是這個電路板的框圖不是簡單的拍腦袋就出來的。
它的誕生，就是一個電路板方案設計的過程。如果這個階段拍腦袋、回板就會拍大腿，最后只能拍拍屁股走人了。

那么我們如何能夠完成一個電路板的方案設計過程呢？除了憑借我們的經驗，還有什么是我們需要做的呢？

【步驟一、建立歸檔文件夾，明確歸檔計劃】

建議自建SVN的云服務器，講需要歸檔的文件夾，按照本企業或者本項目的需求進行設立需要的文件夾。這些自然就是我們在產品研發完成一個完整的產品，需要產生和考慮的所有維度、需要歸檔的所有內容的綱領。
github或者內網文件夾共享其實都可以，但是github速度不快有點影響設計效率，內網文件夾不便于版本管理，當服務器出現故障會影響整個團隊的開發，也不便于移動辦公。

【步驟二、建立問題跟蹤機制】
之前的系列，我們專門說過問題跟蹤，我們針對當前項目，需要建立例會的制度，根據人員情況和人員的素質不同，需要有針對性的進行例會。可能是每天晨會、也可以是每周例會，靈活把握跟蹤頻度。
但是我們需要針對項目建立該項目的問題跟蹤表格，便于整個項目過程中所有出現的問題，跟蹤閉環，避免問題跟蹤出現遺漏。

當然我們還可以計算更復雜的表格，以前我們做個一個表格可以計算每個任務的完成提前、拖延的天數，可以作為KPI進行考核。（這個做法不提倡）

【步驟三、需求跟蹤】
在華為、這個部分會由SE（系統工程師、system engineer不是stupid engineer）進行分解分配。硬件工程師根據分解分配結果對照檢查，并創建單板需求跟蹤表。跟蹤表完成后需召集SE、整機結構、產品工程工藝（PCB Layout工程師、工藝工程師）、生產、測試、軟件等周邊人員評審歸檔。

當然，我們從來都是期望需求能歸檔之后不再修改。但是我們在設計過程中會發現會不可避免的進行修改。但是我們在TR3之后是應該禁止修改的，如果在TR3之后增改需求，所有的需求變更需要通過CR（需求變更電子流）進行跟蹤。

從硬件穩定的角度來說，越在項目的后期，需求的變更帶來的影響越大，帶來的設計變動，對質量的影響越大。但是隨著敏捷的思想，以及客戶需求可能在硬件長周期過程中的變化，很多場景我們不得不去變更需求。

序號各階段介紹備注

1	Charter	責任主體：Marketing團隊和SE; 主要工作：Charter需要回答這些問題：版本的Top N需求和主要競爭需求，主要目標客戶，完整的包需求，版本的里程碑時間點，應用的時間窗口以及在版本火車中所處的位置
2	Charter-TR1	責任主體：SE團隊，同時Marketing配合完成需求的細化、澄清和修訂；主要工作：輸出設計需求（包括每個需求的輸入、輸出參數，并輸出低保真界面原型）
3	CDCP	主要工作：近年來大部分項目都裁剪，具體作用不明
4	TR1-TR2	責任主體：SE團隊；主要工作：輸出是設計規格（接口設計、高保真界面原型）
5	PDCP	責任主體：開發代表；主要工作：主要工作：代碼規模、關鍵時間點和人力需求。質量目標、SOW（工作任務書）
6	TR2-TR3	責任主體：開發組；主要工作：主要工作：需求規格說明書（SRS）；系統測試用例（STC）、概要設計（HLD）、集成測試用例（ITC）

需求的分析和理解往往不可能一步到位，研發人員的理解也有可能不能非常準確理解現場場景。所以需求跟蹤完成之后，需要進行兩輪的需求的串講、反串講。（串講，是指需求發布者與開發者講解，反串講是指開發者理解需求之后，對需求發布者進行講解）。

需求反串講，是設計者向SE、項目經理等角色逐條講解硬件需求，形成統一的認識。對于已有實現方案的需求，講解要包含方案。串講和反串講一定要讓SE/軟件/測試領域全程參與，提出的問題要在詳細設計開始前全部解決閉環。

【步驟四、關鍵器件分析】
我們研發一個新項目的時候，不可避免的會使用我們沒有使用過的器件，甚至是整個公司都沒有使用過的器件。

我們根據設計需求選定了基本方案之后，需要對新器件、關鍵器件進行應用分析，輸出應用分析報告，并召集相關人員、管理者、有經驗的工程師進行評審和分析。

方案分析過程中需要參考和更新器件的Bug List和設計注意事項。同時收集案例，并給出應對解決措施，提前預防已知問題。

關鍵器件不僅僅局限于新引入的器件，還包括復雜的器件、開發人員及項目組經驗積累都不足的器件。

這個關鍵器件的分析，我們需要對器件的datasheet進行分析、尋找并Demo板、查閱廠家的errata，尋找已經產品化或者已經完成過的設計，部分電路的改動，需要動手做電路實驗、或者做電路仿真，進行驗證。

【步驟五、預布局及結構設計】
我們根據需求，明確了必要的功能、性能、然后明確了關鍵器件，也就是電路板上面大功率器件、新器件、復雜器件都已經敲定了。那么我們可以做一個預布局，明確電路板尺寸，形狀的大致想法。

我們為了實現一個準確的預布局，需要輸出一個預布局原理圖，要求原理圖至少包含主要器件、電源、熱敏感器件和接插件。

預布局需要把電路板的信號流向、器件功能、主要器件的電源管腳分布、整個電路板的電源的基本分布和流向。

然后把相關的訴求，提供給ID工程師，給一個基本的ID設想，然后由結構工程師進行結構設計的細化。

如果是成熟的機框，則這個過程相對簡單一些，例如ATCA、VPX這種標準機框。一些個人消費電子產品這個過程反復的可能性非常大。

為了避免這個過程，硬件工程師在完成初步的預布局，之后應該把自己的設計訴求，全部記錄在《結構要素圖設計說明書》中，提供給結構和ID工程師。

【步驟六、散熱評估】
硬件工程師需要提供單板布局和器件熱耗（功耗）表、各器件散熱參數。數字器件要注意提供盡量準確的功耗數據，特別是DDR/FPGA等器件要根據使用場景進行計算。提供的器件的功耗需要準確，避免過設計，也避免散熱風險。

【步驟七、新器件導入評估】
在華為，一個新器件的導入是非常復雜的，我們不在華為，選擇新器件，也需要謹慎選取，并做相關評估。

這個其實應該是一個sourcing的過程：我們不但需求考慮新器件功能是否滿足我們的需求，同時需要考慮：可靠性、可采購性、成本、焊接工藝、功耗、散熱等維度。

【步驟八、背板管腳分配、板間FMEA分析】
我們需要根據背板標準，分配電路板的管腳。如果是新設計背板，需要考慮背板連接器的成本、速率、數量。

在產品設計階段，FMEA針對所有板間信號/關鍵器件展開分析，可確保無故障遺漏。用以分析所有故障影響，同時做到優化故障管理能力。在這個過程中存在著兩個標準，那就是對于嚴重故障，要求盡最大可能避免；對于需要處理的故障，要求能夠監測并定位到現場置換單元（FRU，Field Replacement Unit）。

【步驟九、歸一化分析】
歸一化作為DFx的一項內容，需要硬件特別關注。每個產品需整理自身的BOM歸一化器件清單，常用器件選型只能在歸一化清單中選擇。歸一化清單為本企業或者本部門使用過的器件或者采購過的器件。

盡量減少器件種類，有效減少器件種類、不但降低管理成本、同時也降低加工和采購成本。

【步驟十、可重用性分析】
所有單板都要進行可重用性分析，包含三方面內容：
1. 本單板可重用的已有電路；
2. 本單板希望能夠重用的電路；
3. 本單板完成開發后，可提供其它項目重用的電路。

【步驟十一、早期BOM審查】
1. 方案確定后就把已確定的關鍵器件，通過采購進行關鍵器件的意見反饋。
2. 所有非常規器件、非主流器件、器件必須逐一和采購進行確認，詳細評估風險，有風險的器件要選擇替代方案。
3. 有關鍵器件在設計過程中變更時，還需要與采購人員進行確認。

經過上述十一個步驟
1. 我們選定了關鍵器件、并進行了預布局、明確了結構的設計，排除了可行性、采購、可靠性、散熱方面的風險。

通過需求跟蹤，確保所有需求能夠在設計中落實，最終設計的產品符合客戶的需求。

通過歸一化、可重用性分析，提升了整體的設計效率，并且隱性的提升了設計質量。

通過《問題跟蹤表》、建立《歸檔文件夾》，確保了交付的項目管理。
完成這些準備工作之后，我們的電路原理框圖、電路原理圖的設計才是讓人安心和可靠的。

總結

以上是生活随笔為你收集整理的方案设计阶段的准备工作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。