嵌入式控制系統設計/設計流程
|
的華夏公益教科書
嵌入式控制系統設計
|
本章描述了設計一個新的嵌入式系統，或改進一個現有系統的流程。也就是說，一個工程師，或一個工程師和專案經理團隊如何以一種系統的方式來處理嵌入式系統的設計。本章試圖不僅僅包含工程師對設計流程的看法：通常，一個流程從公司CTO（首席技術官）與客戶（需求分析）討論新產品的功能開始，然後HR（人力資源）和CFO（首席財務官）在第二階段（高階設計）介入，以估計需要多少人和哪些人參與專案，以及它給公司帶來了多少複雜性和風險。只有在那之後，工程師才能開始詳細設計階段，並開始考慮實現和測試。
儘管本書側重於包含大量機械子系統的嵌入式系統，但設計步驟可能也適用於大多數其他工程領域的設計問題。
本章描述了設計一個新的嵌入式控制系統或改進現有系統的流程。也就是說，一個工程師或一個工程師和專案經理團隊如何以一種系統的方式來處理設計。相對於對設計流程的傳統看法，本章增加了一個額外的視角——每個特定系統的設計環境——以增進對傳統設計步驟之間各種互動及其相對重要性的理解。最後一部分討論了大型系統設計中的一些橫截面問題。
文獻描述了一組階段或步驟，每個開發團隊都將經歷
- 系統辨識，理解過程並識別輸入和輸出之間的關係
- 需求定義，確定新產品或修改產品的需求或條件，同時考慮利益相關者（例如受益人、法律當事方或使用者）之間可能存在衝突（技術、功能和非功能）的需求。
- 系統規範，描述系統所需的效能。
- 功能設計，定義系統中需要的子流程（或元件）。
- 詳細設計，最終形成系統必須由其構成所有模組的具體結構。
- 實現，構建和測試最終系統的原型。
有些情況（例如這個例子）會經過所有這些階段，但很難清楚地描述每個新設計要經歷的確切階段，以及設計團隊在每個階段應該做什麼。有些設計會在功能設計階段花費更多時間，而另一些會在系統規範階段花費更多時間，等等。
市場要求交付越來越複雜的系統，以及越來越多的定製、終身維護支援以及系統使用壽命結束後的回收和拆卸要求，導致設計活動無法再遵循任何傳統的、高度結構化的設計流程模型。除了可能在航空等領域，需要滿足嚴格的規定和認證。
本節討論一些流行的傳統設計流程模型
- 瀑布模型是最嚴格的模型，建議只有在完成並完善了前一個階段後才能進入下一個階段。瀑布模型中的開發階段被嚴格地分開，沒有迭代或重疊的空間。
- V模型與瀑布模型具有相同的嚴格序列結構，但它建議在進入更詳細的設計級別之前，應該先測試所有可以在當前設計抽象級別測試的系統功能和屬性。
- 增量模型允許在某些設計階段進行多次迭代，形成一個多瀑布過程。
- 螺旋模型類似於增量模型，更強調風險分析。螺旋模型有四個階段：計劃、風險分析、工程和評估。軟體專案反覆地透過這些階段進行迭代（在這個模型中被稱為螺旋）。
- 模型驅動工程是一種新興的設計流程，它透過支援每個設計級別的測試階段來改進V模型，這些階段由軟體模型模擬，這些模型在實際實現存在之前就模擬了系統。
在實踐中，特定系統的設計流程不僅取決於要經歷哪些階段以及順序，還取決於系統要被設計到的環境的具體情況：是否要製作一個已經成功的產品的下一個版本？是否要設計一個基於尚未成熟的技術的創新系統的第一個原型？是否要設計一個系統來參加比賽？等等。以下幾節透過介紹一套（非詳盡的）典型環境，將設計環境問題進行結構化。
在這種型別的專案中，設計團隊從頭開始工作，因此需要對所有內容進行組織和設計。這既是劣勢也是優勢：完成這些專案需要大量工作（時間和金錢），但整個系統可以設計得讓每個元件都能與其他元件良好地互動。以Senseo咖啡機為例。該產品不是從之前的型號發展而來，而是從無到有設計出來的。使用的技術、基本原理、外觀......所有這些都是全新的，並非來自舊款咖啡機（無論是來自飛利浦公司還是來自任何競爭對手）。
這種環境中的典型專案會按照圖1所示的迴圈進行。從“需求定義”開始，可以由設計團隊定義或從市場調查中推斷出來，這個過程經歷了越來越詳細的級別。在“系統規範”、“功能設計”或“詳細設計”步驟中出現問題，從而需要調整需求是很方便的。
另一個重要的步驟是測試或“實現”階段。由於產品是全新的，因此應該對系統進行徹底的測試。錯誤訊息的反饋在此階段至關重要。這些原型也是架構設計或詳細設計調整的來源。在極端情況下，甚至需要重新開發需求定義，例如當原型表明需求在物理上不可實現時。
所有這些迭代使得專案非常耗時。
設計團隊通常會從其產品的先前模型、版本...入手，並試圖透過減少缺陷和強調優點來改進概念。很明顯，與從零開始相比，這些專案更節省時間。這種工作方法可以應用於幾個版本，但存在使事情變得比實際更復雜風險。因此，有時重新開始是有必要的。
我們報告了存在不同適應性的事實。有時系統會擴充套件全新的功能，這可能從一兩個設計需求的根本性變化到許多小調整不等。另一種適應性是對現有設計需求的最佳化。
在汽車行業，設計師通常在這種環境中工作。汽車製造商通常擁有幾種型號，這些型號會隨著最新技術的改進而改進，例如第一輛保時捷卡雷拉 911於 1963 年推出，但其概念仍然每隔幾年更新一次。即使在開發新細分市場的新車型時，設計團隊也可以重複使用舊的概念或元件，例如底盤。
圖 2 顯示，與從零開始的環境相比，參與的反饋或迭代明顯減少。需求定義主要來自市場研究。客戶被詢問對當前產品的滿意度和不足之處，以便公司能夠解決這些缺陷。例如，在汽車行業，概念車首先會向公眾展示。根據公眾的反應，汽車製造商可以決定概念是否已準備好投入生產，或者是否還需要進行一些修改。
需要注意的是，並非所有需求都可以從市場研究中得出。例如，安全氣囊不是直接從市場研究中得出的，因為你無法期望任何市場研究能得出這樣的結果。在這種情況下，市場研究結果可能涉及安全缺陷。然後，工程師必須將這一需求轉化為一個新系統。沒有客戶會說：“設計一個汽車碰撞時會爆炸的氣囊”。
原型可能會迫使詳細設計發生改變，因為所需的功能沒有實現，但通常不會向系統規範進行迭代。
如今，維護（或售後支援）的方面變得越來越重要。在商品化的早期階段，一個能用的產品就是一個好產品，但現在客戶要求更高，如果一個產品設計不好，公司會在短期或長期內受到懲罰。因此，全面質量管理是一個有用的工具。
許多公司會組織比賽，獲勝團隊將被選中生產或建造提出的產品（例如，在建築環境中）。這類專案的典型特徵是截止日期以及由組織者制定的嚴格邊界條件或規範。這些目標通常難以實現，導致設計師必須富有創造力和靈活。這通常需要迭代式的運作方式，第一個設計會經過多次修改才會完成。
這種環境的一個例子是機器人世界盃挑戰賽。在這個比賽中，不同的團隊試圖建造能夠踢足球的機器人。
在圖 3 中，可以看到描述設計流程的迴圈。迭代參與了設計，但它集中在測試階段。儘管概念、使用的技術和細節可能會頻繁變化，但需求卻非常堅定且不可替代（在圖 3 中用粗體框架表示）。只有當這些頻繁的轉換不花費太多成本時，它們才被允許。更改驅動程式原始碼中的某些引數不花錢，但更改系統中的硬體元件卻要花錢！
設計師不會考慮系統的維護方面。產品應該滿足需求，但不需要商業化或大規模製造。在某些情況下（例如，建築競賽），維護或耐用性方面可能是組織者定義的需求之一。在這種情況下，它顯然不可忽略。
儘管研究通常與大學有關，但它是現代公司的一項重要活動（有時超過 20% 的銷售額都會注入研發部門）。這類專案的最大特點是需求設定靈活。人們從一個既定的目標入手，並透過這樣做，會找到相關專案，他們可以進行研究，並可能導致有趣的新發展。
例如，谷歌以其“20% 時間”而聞名。在這種理念中，所有谷歌員工都被鼓勵將 20% 的時間（或一週中的一天工作時間）花在他們認為有趣的事情上。這樣就可以發現許多以前沒有想到的新領域。
與競爭環境相比，需求沒有那麼嚴格地概述。透過定義系統規範，透過尋找新的發展或分析原型，可能會出現一些有趣的新主題，這些主題會取代或補充之前定義的需求。
與競爭環境類似的是缺乏維護設計步驟。處理的系統沒有商業目標，因此不需要考慮潛在的客戶。一旦研究專案取得明確成果，公司決定將特定產品推向市場，這些步驟就會變得重要，專案將轉移到從零開始或適應環境。一個在研究環境中的專案的良好例子是陽光動力。
通常很難結束這些專案，“繼續研究是否有必要？”或“我們是否有足夠的資訊來構建新產品？”這些問題並不容易回答。在公司中，研發經理負責這些問題，就像他是決定哪些研究專案有趣，哪些專案不有趣的人一樣。
- 研究環境中的設計團隊通常專注於一個或兩個使用者需求。
- 關於這種環境的另一個重要問題是資金。例如，衍生公司一直在花費時間尋找願意為其專案提供資金的人或組織。
本節討論了所有設計步驟中相似之處或重要的專案。這些跨部門問題還涵蓋了不同設計階段之間的連續性。有關明顯跨部門問題（即溝通、資源、質量等）的資訊，可以在維基百科上找到。
一個好的設計會在儘可能長的時間內等待，直到填入實際元件和硬體。這為以後的實現留下了更多選擇，從而為意外情況留下了更大的餘地。
在設計流程中能夠保持多長時間的廣闊視野，通常很大程度上取決於市場。這個視野可以保持到將特定系統或產品與客戶關聯的點，這個點被稱為訂單滲透點。根據產品交付策略（庫存生產、按需組裝、按需生產、按需工程），這個視野可以在整個流程中保持廣闊，或者在設計流程開始時就由終端使用者確定。