1、嵌入式原理嵌入式系統設計第1頁，共55頁，2022年，5月20日，3點8分，星期三3-1 設計方法論采用方法論有以下三個重要理由：1確認所做的每一件事情都是必須要做的。2根據設計方法論可以發展出計算機輔助工具或是累積設計經驗。汲取每一次產品開發的經驗，再經過量化之后，可以發展出一套工具或是方法，讓往后的產品設計步入自動化。3遵循同一套方法論，可以讓團隊成員更容易彼此溝通。每個人都能在短時間內了解整體過程中將經歷哪些過程，需要何種支持與接收到何種結果。 不要畫蛇添足！也不要只掃門前雪！熟能生巧！項目經理總攬全局！ 第2頁，共55頁，2022年，5月20日，3點8分，星期三3-1 設計方法論設計方

2、法論（Design Methodology） 3-1-1 設計過程3-1-2 設計流程的方法第3頁，共55頁，2022年，5月20日，3點8分，星期三3-1-1 設計過程設計過程的目標是做出一個有用且具有賣點的產品。一個產品的典型規格包含功能性、制造成本、性能表現、省電考慮和其他特性。【例】一臺個人數字助理PDA必需具有個人輔助信息的軟件和有趣的應用程序（功能性）制造成本大概需要在3、4千元以下必需具備開機速度快，操作上不能有意外的延遲現象等性能（性能表現）電力要能夠維持一個星期以上第4頁，共55頁，2022年，5月20日，3點8分，星期三3-1-1 設計過程一般產品的設計過程的目標至少必須符

3、合三種需求上市時間顧客總是想要一些新的功能，如果能夠搶先上市及時供應給顧客的話，銷售數量自然會比其他同型產品來得高。引領時尚潮流！設計成本許多消費性產品對于價格非常敏感，所以產品廠商對于成本一般總是斤斤計較的。質量在設計之初，就必須考慮到可靠性和實用性。iPhone4的天線！第5頁，共55頁，2022年，5月20日，3點8分，星期三3-1-1 設計過程設計過程中的幾個重要步驟自上至下的設計需求和規格都對產品做比較詳細的描述。規格只是描述產品的功能行為，并不說明如何建立系統。系統內部的建立方式是從架構設計開始建立，并且開始規劃系統內應該有哪些組件。組件設計與實現包括軟件模塊與硬件模塊。最后將這些

4、組件加以集成，得到一個完整的系統。自下至上的設計在不清楚系統設計的情況下采用，特別是沒有建立這類系統的經驗。采用由下至上設計的方式來邊做邊學，最后再通過這些經驗重新調整系統，完成目標。第6頁，共55頁，2022年，5月20日，3點8分，星期三3-1-1 設計過程一些重要的問題 制造成本、性能要求、省電因素與用戶接口。在設計過程中，考慮如下問題：分析設計的每個步驟以決定應該符合哪些規格。加入更詳細的內容來加強設計。確認設計符合整體系統的目標，如價格、速度等。一個好的設計方法論可以讓一個系統更快完成，而不至于受到外部和內部因素影響。一個好的系統也不該有臭蟲（bug）的存在。第7頁，共55頁，202

5、2年，5月20日，3點8分，星期三實例 火星氣象衛星的失事原因 1999年，美國所發射的一臺火星氣象衛星，沒有在正確的時間點燃維持軌道的引擎，導致與火星距離太近而失事。原因之一：美國JPL與Lockheed Martin的工程師使用的計算單位不一樣。JPL用的是牛頓，Lockheed Martin用的是磅，雙方都以為和對方用的是一樣的單位。計算出來的結果與真正的軌道差距4.45倍。第8頁，共55頁，2022年，5月20日，3點8分，星期三3-1-2 設計流程的方法設計流程（Deign Flow）指的是設計過程中所經歷的過程步驟。 常用的設計流程的方法瀑布模型（Waterfall Model）螺

6、旋模型（Spiral Model）連續改進（Successive Refinement）設計方法 層次結構式設計流程第9頁，共55頁，2022年，5月20日，3點8分，星期三瀑布模型（用戶）需求通過分析確定產品的基本特性（技術）規格架構系統組成將每個功能面細分成許多組件（軟件）編程硬件制作把這些小單元實現出來并且集成測試找出臭蟲維護產品發布、臭蟲修正以及升級等一旦某個階段出現問題，可能需要逐級向上尋找bug。 第10頁，共55頁，2022年，5月20日，3點8分，星期三螺旋模型在每一個設計層次，設計者都會經歷需求分析、構建與測試階段。 在設計過程中，不斷加進前一設計周期所得的經驗，逐漸構建更完

7、善的系統。 特點多重反復的方式會在復雜系統里加入足夠的細節花費太長的時間。在時間因素影響產品成敗時，螺旋模型便不太適用。 由點到面！由淺入深！逐步推進！ 第11頁，共55頁，2022年，5月20日，3點8分，星期三連續改進設計方法連續改進設計方法論是假設系統會建立好幾次，最初的系統會是一種粗略的雛形，經過連續的方式不斷改進。通過反復建立好幾個越來越復雜的系統，可以幫助設計者檢驗架構和技術，也可以幫助設計者避免錯誤。連續改進設計方式對于打算建立一種不熟悉的系統的設計者來說比較有意義。第12頁，共55頁，2022年，5月20日，3點8分，星期三簡易硬件與軟件的同步設計流程初期階段的需求與規格設計必

8、須要同時考慮硬件與軟件兩方面。最后的階段需要集成與測試整體系統。中間階段采用獨立分開方式設計。 第13頁，共55頁，2022年，5月20日，3點8分，星期三層次結構式設計流程第14頁，共55頁，2022年，5月20日，3點8分，星期三同步工程（Concurrent Engineering） 問題：當越多人同時進行一個項目的時候，就越容易失去完整設計流程的軌跡。每個小型系統的設計者容易局限在自己的設計流程里。同步工程的目的采用一個較廣泛的看法讓整體流程最佳化。消除每個小型系統設計者之間的障礙，以免設計者局限在自己的看法而無法與其他設計者進行溝通，造成反復或沖突的情況不斷發生。設計過程中整個設計團

9、隊交流與溝通至關重要！第15頁，共55頁，2022年，5月20日，3點8分，星期三設計設計什么？如何設計？收集客戶所描述的消息，整理成需求列表。把這些需求進一步萃取之后，形成系統架構設計的數據技術規格。第16頁，共55頁，2022年，5月20日，3點8分，星期三3-2 需求分析需求與規格需求分析證實需求簡易需求表第17頁，共55頁，2022年，5月20日，3點8分，星期三需求與規格將客戶的需求理念捕捉出來，并且以正規的方式描述（用戶需求分析），同時將客戶描述的方式轉換成系統設計者的描述方式（技術規格）。 需求與規格描述系統所呈現的行為，而不是內部結構。需求是顧客想要什么樣產品的信息描述。規格是

10、更詳細、更精確的描述系統的功能。第18頁，共55頁，2022年，5月20日，3點8分，星期三需求分析需求分析需要設計者與顧客詳細溝通設計者需要了解顧客所預期的產品是什么顧客也必須了解他們到底可以得到什么樣的產品需求的種類功能性需求是指系統必須要有哪些功能。非功能性需求實體大小與重量、價格、設計時間、電力消耗、。想要什么？得到什么？第19頁，共55頁，2022年，5月20日，3點8分，星期三證實需求確認列出來的需求是真的為客戶所需要。怎樣確認？仿真系統用一些事先準備的數據來模擬一些功能，當作一個有功能限制的展示系統。給客戶一個實際看得到的模型來說明實際做出來的系統將如何運行。樣機、測試版、概念車

11、第20頁，共55頁，2022年，5月20日，3點8分，星期三簡易需求表名稱目的輸入輸出功能性能要求制造成本電源實體大小與重量第21頁，共55頁，2022年，5月20日，3點8分，星期三需求分析需求文件的特性正確性：既不可誤解顧客所需，也不可描述不需要的需求。精確性：需求文件應該做清楚的描述，而不是籠統的說明。完整性：所有的需求都應該記錄。可證明性：所有的需求都應該有方式可以證明是合理的。一致性：某項需求不應該和其他需求相互沖突。可修改性：既然可以建立需求，當然也可以修改需求，而且不會違反上述的特性。可追蹤性：每份文件都應該可以追蹤。包括為什么會有這樣的需求，彼此需求間的相關性，這些需求是否可能

12、實現，以及最后是否滿足這些需求。第22頁，共55頁，2022年，5月20日，3點8分，星期三如何決定需求呢? 銷售部門會幫忙反映市場的需要，或是去詢問顧客，然后將這些意見匯總進行分析。如果是顧客直接找上門，就需要和顧客進行訪談，以了解他們的期望。如果顧客能夠給設計者一個簡單的樣品，將可以幫助設計者更清楚應該要設計出什么樣的產品。設計者先做出一個雛形，請銷售部門進行展示或是意見調查，然后再將結果進行分析來決定需求的內容。第23頁，共55頁，2022年，5月20日，3點8分，星期三3-3 規格客戶與架構設計團隊之間的契約 統一建模語言SDL語言狀態圖AND/OR表第24頁，共55頁，2022年，5

13、月20日，3點8分，星期三統一建模語言UML是一種描述規格的語言，通過對系統正規化的表述，使所有看過規格的人，尤其是設計團隊里的成員充分了解所描述的產品是什么。 第25頁，共55頁，2022年，5月20日，3點8分，星期三閱讀資料：UML第26頁，共55頁，2022年，5月20日，3點8分，星期三SDL語言SDL包含了狀態、動作和每個狀態之間的轉換條件。SDL是一種以事件為對象的狀態機器模型。內部或是外部事件的不同，使得狀態之間相互轉換。 第27頁，共55頁，2022年，5月20日，3點8分，星期三狀態圖（State Charts）狀態圖用來消除以狀態為基礎的規格中雜亂的部分，澄清其中重要的結

14、構。狀態圖使用在事件驅動模型中，讓事件可以歸類在一起并且顯示共通的規格部分。兩種歸類方法：OR與AND。第28頁，共55頁，2022年，5月20日，3點8分，星期三傳統圖解與OR狀態圖第29頁，共55頁，2022年，5月20日，3點8分，星期三傳統圖解與AND狀態圖第30頁，共55頁，2022年，5月20日，3點8分，星期三AND/OR表以AND/OR表來表示一個布爾表達式。每一列標記表達式里的基本變量，每一行則對應到每一表達式項目。第31頁，共55頁，2022年，5月20日，3點8分，星期三3-4 系統分析與架構設計規格只是對事項做了描述，并沒有說明系統如何做到被要求的事項。當規格制訂完成之

15、后，接下來就是將規格轉變為架構設計。架構是對整體系統結構的計劃，說明利用哪些組件來構建系統。第32頁，共55頁，2022年，5月20日，3點8分，星期三3-4 系統分析與架構設計3-4-1 方框圖（Block Diagram）3-4-2 CRC卡片第33頁，共55頁，2022年，5月20日，3點8分，星期三3-4-1 方框圖方框圖描述系統架構，顯示系統有哪些主要組件。方框圖可能非常抽象，沒辦法使用這些方框來直接實現，不過這些方塊可以告訴接下來的工作方向是什么。可以依據方框圖所描述的工作項目進行分工，做出能夠完成更詳細的功能的、描述更多細節的方塊圖。GPS的地圖顯示功能 第34頁，共55頁，20

16、22年，5月20日，3點8分，星期三方框圖細化應用舉例硬件與軟件的架構方塊圖 采用細化方框圖的方式更精確的描述每一個方塊該有的架構，最后經過幾次的重新錘煉與整理，完成系統架構設計。軟件方塊圖更清楚的描述每一個功能之間的相互關系。 硬件方塊圖還描述了應該要搭配的某些外圍設備。 第35頁，共55頁，2022年，5月20日，3點8分，星期三方框圖架構設計必須同時滿足功能性與非功能性的需求。不僅要符合所有需要的功能，也必須符合成本、速度、電力與其他非功能性需要，因此做架構設計的時候，除了注意功能單元之外，還要想到軟件與硬件限制的部分。如何知道實際上軟件與硬件的限制到什么程度呢?在設計系統架構的每一個方

17、塊時，大概就需要估計方塊圖里每一個組件的特性。例如：用戶界面的顯示速度或是數據庫的查找速度。要估計這些組件的特性，必須依靠設計者的經驗，這項工作考驗設計者對于該系統的熟悉程度，如果不能做準確估計，產品的架構設計就不會理想。第36頁，共55頁，2022年，5月20日，3點8分，星期三3-4-2 CRC卡片CRC系統分析模型將相關信息寫在一張包括了類、責任與合作對象等信息的索引卡片上，并且相互討論與更新這些卡片數據，直到討論出結果為止。 類（Classes）：定義數據與功能的邏輯歸類。責任（Responsibilities）：定義每個類該做些什么。合作對象（Collaborators）：定義其他類

18、所做的工作。第37頁，共55頁，2022年，5月20日，3點8分，星期三CRC卡片把某些功能封裝起來便稱為一個類。一個類可以描述一個真實對象或是一個系統的某個環節。一個類存在自己的內部狀態與對外接口。對外的接口就是這個對象所表現出來的功能。責任就是類的接口。責任的作用在于描述類的功能接口，而不是內部的運行與實現方式。合作對象是指該類究竟和哪些類互相溝通，以及該類使用了其他類的哪些功能或是其他類交付了什么樣的工作。第38頁，共55頁，2022年，5月20日，3點8分，星期三3-5 設計硬件與軟件組件組件設計就是遵照架構與規格建立嵌入式系統第39頁，共55頁，2022年，5月20日，3點8分，星期

19、三3-5 設計硬件與軟件組件標準組件：已經制造好了的組件微處理器等幾乎是一種標準的硬件，通過這些標準組件的組合，可以節省很多精力。選擇標準組件（例如數據庫功能），使用現成的函數庫，節省設計與實現的時間。定制組件：設計者設計的屬于自己的組件要設計出電路板來連接微處理器或存儲器等標準組件，或是做很多客戶特別要求的部分。將標準軟件模塊移植嵌入式系統上，使之在現有的硬件上實時運行。第40頁，共55頁，2022年，5月20日，3點8分，星期三3-6 系統集成把設計的組件組成一個完整的系統 第41頁，共55頁，2022年，5月20日，3點8分，星期三3-6 系統集成通常會在系統集成階段找到很多臭蟲好的規劃

20、可以幫助很快找到臭蟲比如，足夠的測試案例或是進行集成的時候先將幾個模塊放在一起，確認臭蟲是否存在。不要在組合到復雜系統后才開始確認臭蟲，那時已經很難識別這些臭蟲的來源了。在系統架構與組件設計時，需要考慮將來如何確認臭蟲，是否可以將這些組件功能的關系互相獨立，以方便確認。系統集成是非常困難的到這個階段已經很難確認問題究竟是出在哪一個部分，而且嵌入式系統的調試工具與接口通常都很有限，比臺式機更難找出問題所在。第42頁，共55頁，2022年，5月20日，3點8分，星期三3-7 質量保證質量保證的過程是維持一個高質量產品必需的過程 3-7-1 質量保證技術3-7-2 確認需求與規范3-7-3 設計復審

21、3-7-4 衡量驅動質量保證第43頁，共55頁，2022年，5月20日，3點8分，星期三3-7-1 質量保證技術國際標準組織（International Standards Organization，ISO）建立了一套知名的質量標準，稱為ISO9000。 人工執行確認系統設計以及保證質量設計復審依靠工具的確認方式幫助管理較復雜的系統里所產生出的大量信息。測試產生程序可以自動地取代令人煩悶的測試問題追蹤工具可以幫助人們找出每個步驟的進行方式設計流程工具則可以自動地處理設計運行數據不需要太高深的管理技巧與復雜的程序，源代碼版本控制就可以達到很好的質量管理。 第44頁，共55頁，2022年，5月20

22、日，3點8分，星期三質量保證技術CMM能力成熟模型提供一個模型來判斷一個組織的質量成熟程度1初始（Initial）階段：只有少量定義完備的程序，項目的成功依賴的是個人的努力，而不是組織的力量。2可重復的（Repeatable）階段：具有基本的追蹤機制，可供管理成本、計劃進度，可以讓系統發展符合預期目標。3己定義（Defined）階段：所有管理與工程進行的過程都已經利用文件記錄并且標準化，所有的項目也都使用文件建立，且符合標準方式。4己管制（Managed）階段：這個程度可以通過仔細衡量，完成開發程序與產品質量的保證。5最佳化（Optimizing）階段：在最高級階段里，可以通過仔細的衡量取得改

23、進建議，并且持續改善組織內的程序。第45頁，共55頁，2022年，5月20日，3點8分，星期三3-7-2 確認需求與規范如果不能找出需求與規范中的臭蟲，對于未來系統的發展將會衍生出更多的錯誤，而且極可能無法修正。如果一開始就存在臭蟲，時間愈往后，將會付出愈昂貴的代價。一個程序設計中所產生的臭蟲，可能在產品賣出去之后，還需要付出不少費用回廠檢修。如果一開始設計規范就出現錯誤，而且不能及時發現的話，整個產品或是項目就必須從頭開始。早期發現需求或是規范里的臭蟲，可以避免提供顧客有瑕疵的產品、降低設計成本以及縮短設計時間。 存在越久的臭蟲，修正成本越高 第46頁，共55頁，2022年，5月20日，3點

24、8分，星期三需求確認雛形產品（Prototypes） ：樣機、測試版一個雛形產品可以幫助產品用戶在功能面與非功能面給予意見。已有的系統以前已經做好的系統也可以用來幫助產品用戶了解他們的需求，特別是用戶不喜歡之前做好的系統。想要得到一些新的產品，可以從以前的經驗里進行需求確認。 有時需要在已有系統的基礎上構建出一個新的雛形產品來進行需求確認。 第47頁，共55頁，2022年，5月20日，3點8分，星期三規范確認雛形產品（Prototypes） ：樣機、測試版案例情景（Usage Scenarios） 正規化技術（Formal Techniques） 第48頁，共55頁，2022年，5月20日，3

25、點8分，星期三3-7-3 設計復審（Design Review） 設計復審可以在設計過程中以最簡單而且最經濟的方式找出臭蟲所在。設計復審通常是設計成員開一個會，重新審視系統設計的每一個組件。有些臭蟲可以在準備開會前就被找出來。因為這樣的方式會強迫設計者更仔細的思考所有的細節，否則開會的時候就會被釘在臺上下不來。有些臭蟲會在會議進行的時候被找出來。因為一個人的能力是有限的，通過集思廣益的方式可以找出設計者的設計缺陷。越早找出臭蟲，不讓有問題的設計進入實現階段，越能節省成本以及工作時間。第49頁，共55頁，2022年，5月20日，3點8分，星期三設計復審一般可以自行建立一個能夠清楚表達設計復審的重點的設計復審格式，幫助在會議中審視系統里特定的組件。一個設計復審團隊的成員設計者（Designer）：設計者自己最清楚所設計的組件，在審視的過程中，報告與解釋為什么需要這樣的設計規格。包括需求、接口描述以及與系統的關系。復審主席（Review Leader）：協調會議之前的準備工作、會議進行以及會后的追蹤工作，確保會議順利進行。復審記錄（Review