嵌入式控制系統設計/設計過程

華夏公益教科書

嵌入式控制系統設計

本章描述了設計新的嵌入式系統或改進現有嵌入式系統的過程。也就是說，一個工程師或一個工程師和專案經理團隊如何在系統化方式中處理嵌入式系統的設計。本章試圖將不僅僅是工程師對設計過程的看法納入進來：通常，一個過程從公司的首席技術官（CTO）與客戶討論新產品的功能（需求分析）開始，人力資源（HR）和首席財務官（CFO）在第二階段（高階設計）介入，估計需要多少人以及哪些人參與專案，以及它對公司的複雜性和風險有多大。只有這樣，工程師才能開始詳細設計階段，並開始考慮實現和測試。

雖然本書重點關注包含大量機械子系統的嵌入式系統，但設計步驟可能也適用於大多數其他工程領域的設計問題。

引言

本章描述了設計新的嵌入式控制系統或改進現有嵌入式系統的過程。也就是說，一個工程師或一個工程師和專案經理團隊如何在系統化方式中處理設計。相對於傳統的設計過程觀點，本章增加了一個額外的觀點——每個特定系統的設計環境——以增進對傳統設計步驟之間各種互動作用及其相對重要性的理解。最後一節討論了大型系統設計中的一些橫截面問題。

設計過程：預定義模式？

文獻描述了一組每個開發團隊都將經歷的階段或步驟

系統辨識，瞭解過程並識別輸入和輸出之間的關係
需求定義，確定滿足新產品或更改產品的需求或條件，同時考慮到各種利益相關者（例如受益人、法律當事人或使用者）可能相互衝突的（技術、功能和非功能）需求。
系統規範，描述系統要求的行為。
功能設計。定義系統中需要哪些子過程（或元件）。
詳細設計，最終形成系統必須由所有模組組成的具體結構。
實現，構建和測試最終系統的原型。

有些案例（例如這個示例）經過了所有這些階段，但很難明確描述每個新設計必須經歷的階段，以及設計團隊在每個階段應該做些什麼。一些設計將在功能設計階段花費更多時間，另一些將在系統規範階段花費更多時間，等等。

市場對提供越來越複雜系統的需求，以及對定製、終身維護支援以及系統使用壽命結束後回收和拆卸要求的需求，導致設計活動不再能夠遵循任何傳統的、結構化程度很高的設計過程模型。除了可能是在航空等領域，需要滿足嚴格的規定和認證。

傳統設計過程模型

本節討論了一些流行的傳統設計過程模型

瀑布模型是最嚴格的模型，建議只有在完成並完善了前一個階段後才能進入下一個階段。瀑布模型中的開發階段是完全分開的，沒有迭代或重疊的空間。
V 模型與瀑布模型具有相同的嚴格序列結構，但它建議在進入更詳細的設計級別之前，應該已經測試了可以在當前設計抽象級別測試的所有系統功能和屬性。
增量模型允許在一些設計階段進行多次迭代，從而形成一個多級瀑布過程。
螺旋模型類似於增量模型，但更強調風險分析。螺旋模型有四個階段：規劃、風險分析、工程和評估。軟體專案在迭代中反覆經過這些階段（在這個模型中稱為螺旋）。
模型驅動工程是一種新興的設計過程，透過支援每個設計級別的測試階段，透過模擬系統軟體模型，在真實實現存在之前。

設計環境

在實踐中，特定系統的設計過程不僅取決於要經歷哪些階段、以什麼順序進行，還取決於環境的特殊性，系統將在其中設計：是否要製作現有成功產品的下一個版本？是否要設計基於仍處於部分不成熟技術的第一代創新系統原型？是否要設計一個系統來參加競賽？等等。以下部分透過展示一組（非詳盡的）典型環境，為設計環境問題提供一些結構。

從零開始的環境

在這種專案中，設計團隊從頭開始工作，因此需要對所有內容進行組織和設計。這既是缺點也是優點：完成這些專案需要大量工作（時間和金錢），但可以以所有元件都能很好地互動的方式設計整個系統。以Senseo 咖啡機為例。這款產品並非來自以前的型號，而是從無到有設計出來的。使用的技術、基本原理、外觀……所有這些都是全新的，沒有從舊款咖啡機中借鑑（無論是飛利浦公司還是任何競爭對手）。

在一個典型的專案中，其設計流程遵循圖1所示的迴圈。從“需求定義”開始，這可以由設計團隊定義或從市場調查中推斷出來，整個過程經過逐步細化。在“系統規格”、“功能設計”或“詳細設計”階段，如果出現問題，則需要調整需求，這十分方便。

另一個重要的步驟是測試或“實現”階段。由於產品是全新的，因此應對其進行全面測試。此時，錯誤訊息的反饋至關重要。這些原型也是調整架構或詳細設計的來源。在極端情況下，甚至需要重新開發需求定義，例如，當原型表明需求在物理上不可實現時。

整個迭代過程使得專案耗時很長。

適應環境

在這種情況下，設計團隊從其產品的先前模型、版本等開始，並試圖透過減少缺點和強調優點來改進概念。很明顯，與從頭開始的專案相比，這些專案更加節省時間。可以使用這種工作方法進行多個版本，但存在使事物變得比應有的複雜。因此，有時重新開始是很有用的。

我們報告存在不同的適應方式。有時系統會擴充套件全新的功能，這可能從設計需求中的一兩個重大改變到大量微小調整不等。另一種適應方式是最佳化現有設計需求。

在汽車行業中，設計師通常在這種環境下工作。汽車製造商通常擁有幾個型號，這些型號透過最新技術進行改進，例如，第一輛保時捷卡雷拉911於1963年推出，但其概念每隔幾年就會更新。即使開發了新細分市場的新車型，設計團隊也可以重複使用舊概念或元件，例如底盤。

圖2顯示，與從頭開始的環境中的設計流程相比，反饋或迭代明顯更少。需求定義主要來自市場調查。客戶會詢問當前產品的滿意度和不足，以便公司可以解決這些缺陷。例如，在汽車行業，概念車首先會向公眾推出。根據公眾的反應，汽車製造商可以決定概念是否已準備好投入生產，或者是否還需要進行一些修改。

應該注意，這些需求並非全部都來自市場調查。例如，安全氣囊並非直接來自市場調查，因為你不能指望市場調查得出這樣的結果。在這種情況下，市場調查結果可能涉及安全缺陷。然後，工程師必須將此需求轉換為新的系統。沒有顧客說過：“設計一個在汽車碰撞時會膨脹的氣囊。”

原型可能會迫使詳細設計發生改變，因為所需的函式無法實現，但是，向系統規範的迭代是不尋常的。

如今，維護（或售後支援）方面變得越來越重要。在商品化的早期，只要產品能工作，就是一個好產品，但現在，客戶的要求更高，如果一個產品設計不好，公司就會在短期或長期內受到懲罰。因此，全面質量管理是一個有用的工具。

競爭環境

許多公司會組織競賽，獲勝團隊將被接受生產或建造提議的產品（例如，在建築環境中）。此類專案的典型特徵是截止日期和組織者規定的嚴格邊界條件或規格。這些目標通常很難實現，這使得設計師必須具有創造力和靈活性。它通常需要一種迭代的工作方式，第一個設計將在完成之前經過多次調整。

此環境的一個例子是RoboCup挑戰賽。在這個比賽中，不同的團隊試圖建造一個能夠進行足球比賽的機器人。

在圖3中，可以看到描述設計流程的迴圈。設計中涉及迭代，但重點在於測試階段。雖然概念、所用技術和細節可能會頻繁發生變化，但需求是堅如磐石且不可替代的（在圖3中用粗框表示）。只有在這些頻繁的轉換不花費太多成本的情況下才允許進行轉換。更改驅動程式原始碼中的某些引數不花任何錢，但更改系統中的硬體元件卻需要花很多錢！

系統維護方面不在設計師的考慮範圍內。產品應該滿足需求，但不需要商業化或大規模製造。在某些情況下（例如，建築設計競賽），維護或耐用性方面可能是組織者定義的需求之一。在這種情況下，它顯然不容忽視。

研究環境

研究雖然通常與大學有關，但卻是現代公司中的一項重要活動（有時超過20%的銷售額都投入到研發部門）。這類專案的主要特點是需求的靈活設定。從給定的目標開始，在做這件事的過程中，會找到相關專案，可以進行研究，並可能帶來有趣的全新發展。

例如，谷歌以其“20%時間”而聞名。在這種理念中，所有谷歌員工都被鼓勵將20%的時間（或一週中的一個工作日）花在他們認為有趣的主題上。這樣就可以發現許多以前從未想到的新領域。

與競爭環境相比，需求沒有嚴格的界定。透過定義系統規格，透過尋找新的發展方向或透過分析原型，可能會出現一些有趣的新的主題，這些主題會取代或補充先前定義的需求。

類似於競爭環境，維護設計步驟也缺失。所處理的系統沒有商業目標，因此不需要考慮潛在的客戶。一旦研究專案取得了明確的結果，公司決定將特定產品推向市場，這些步驟就變得重要，專案就會轉移到從頭開始或適應環境中。一個在研究環境中進行專案的很好的例子是陽光動力。

終止這些專案通常很困難，諸如“繼續研究是否有效？”或“我們是否有足夠的資訊來製造新產品？”這樣的問題並不容易回答。在一個公司裡，研發經理要對這些問題負責，就像他要負責確定哪些研究專案很有趣，哪些專案沒有趣一樣。

研究環境中的設計團隊通常側重於一個或兩個使用者需求。
與該環境相關的另一個重要問題是資金。例如，分拆公司不斷花費時間來尋找願意為其專案提供資金的個人或組織。

交叉問題

本節將討論所有設計步驟中重要的相似之處或專案。這些交叉問題還涵蓋了不同設計階段之間的連續性。有關明顯交叉問題的資料（即溝通、資源、質量等）可以在維基百科上找到。

後期設計承諾

好的設計會盡可能長時間地等待，直到填充實際的元件和硬體。這為以後的實現留下了更多選擇，從而為意外情況提供了更多餘地。

在設計流程中，能夠保持廣闊視野的程度通常取決於市場。視野可以一直保持到某個特定系統或產品與客戶聯絡的那一刻，這個點被稱為訂單滲透點。根據產品交付策略（備貨生產、按訂單組裝、按訂單生產、按需求設計），視野可以保持整個過程的廣闊，或者從設計過程開始就由終端使用者決定。