第三章

第三章 嵌入式系統的系統設計嵌入式系統導論, 探矽工作室

嵌入式系統導論, 探矽工作室 本章學習重點 • 設計系統的考慮因素 • 設計系統方法論與過程 • 設計流程的方法 • 品質保證的方法

嵌入式系統導論, 探矽工作室 設計方法論 • 設計方法論（design methodology）有以下三個重要理由 • 確認我們所做的每一件事情都是必須要作的，不會做無謂的白工，也不會漏掉關鍵性的重要工作，其中包含效率最佳化或是功能測試。 • 根據設計方法論可以發展出電腦輔助工具或是設計經驗累積，汲取每一次產品發展的經驗。再經過量化之後，可以發展出一套工具或是方法，讓往後的產品設計步入自動化。 • 開發團隊遵循同一套方法論，可以讓團隊成員更容易彼此溝通。每個人都能在短時間內瞭解整體過程中將經歷哪些過程，需要何種支援與接收到何種結果；此外，也容易透過一套已經定義好的方法論，彼此相互合作協調。

嵌入式系統導論, 探矽工作室 設計過程的目標 • 上市時間：也就是time-to-market的觀念。 • 設計成本：許多消費性產品對於價格非常敏感，所以產品廠商對於成本會斤斤計較是很合理的。 • 品質：顧客也許不需要最快最便宜的產品，但是一定會要求功能品質保證，不能只用一小段時間就壞掉了。

嵌入式系統導論, 探矽工作室 設計過程的主要步驟

嵌入式系統導論, 探矽工作室 範例3-1　火星探測船的失事原因 • 1999年美國所發射的一台火星探測船，在接近火星的時候失事，原因是登陸火星的引擎在點燃時已經與火星距離太近。最後的調查報告出來，其中一個很重要的原因是美國噴射推進實驗室（Jet Propulsion Laboratory；JPL）與合作廠商Lockheed Martin公司兩個單位工程師所使用的計算單位不一樣。JPL用的是牛頓（newton），而另外一家卻是用磅來當作計算單位，可是雙方卻都以為對方和自己用的是一樣的單位，導致計算出來的結果與真正的軌道差距4.45倍。也因為這個原因，使得這艘火星探測船並沒有在正確的時間點燃引擎而失事。

嵌入式系統導論, 探矽工作室 設計流程的方法 - 瀑布模型(Waterfall)

嵌入式系統導論, 探矽工作室 螺旋模型(Spiral)

嵌入式系統導論, 探矽工作室 連續改進(Successive Refinement)

嵌入式系統導論, 探矽工作室 簡易硬體與軟體的同步(SW/HW Co-deign) 設計流程

嵌入式系統導論, 探矽工作室 階層式(Hierarchical)設計流程

嵌入式系統導論, 探矽工作室 同步工程 • 同步工程（concurrent engineering）企圖採用一個較廣泛的看法讓整體流程最佳化。 • 這種方式的目的是要消除每個小型系統設計者之間的藩籬，以免設計者侷限在自己的看法而無法與其他設計者進行溝通，造成反覆或衝突的情況不斷發生。

嵌入式系統導論, 探矽工作室 需求分析與規格 • 第一階段是收集客戶所描述的訊息，整理成需求列表； • 第二階段就是把這些需求進一步萃取之後，定成規格（specifications），這些規格就是系統架構設計的資料。

嵌入式系統導論, 探矽工作室 需求的種類 • 功能性需求是指系統必須要有哪些功能 • 非功能性需求則是指其他因素，像是大小、價格、設計時間等 • 常見的非功能性需求 • 效能 • 成本 • 實體大小與重量 • 電力消耗

嵌入式系統導論, 探矽工作室 證實需求 • 確認列出來的需求是真的為客戶所需要 • 透過模擬系統來證實需求 • 這個模擬系統將一些事先準備的資料來模擬一些功能，當作一個有功能限制的展示系統 • 說明實際作出來的系統將如何運作，可以增進客戶與設計者之間的認知

嵌入式系統導論, 探矽工作室 建議需求表格

嵌入式系統導論, 探矽工作室 好的需求文件 • 正確性：一個需求描述不可以誤解顧客所需，也不該過份描述不需要的需求。 • 精準性：需求文件應該做清楚的描述，而不是籠統的說明。 • 完整性：所有的需求都應該紀錄。 • 可證明性：所有的需求都應該有方式去證明這項需求是合理的，像是文件裡就不應該出現「親和的介面」這類字眼，因為無法定義什麼叫做親和的介面。 • 一致性：某項需求不應該和其他需求相互衝突。 • 可修改性：既然可以建立需求，當然也可以修改需求，而且不會違反上述的特性。 • 可追蹤性：每份文件都應該可以追蹤，包括為什麼會有這樣的需求開出來，彼此需求間的相關性，這些需求是否可能實現，以及最後是否滿足這些需求。

嵌入式系統導論, 探矽工作室 規格 • 規格比需求更精確許多，這是當作客戶與架構設計團隊之間的契約，所以在撰寫時需更加小心，才能夠正確的反應客戶的需求，並且在接下來的設計期間瞭解每一步設計過程 • 規格一定要讓人一目了然，符合系統的需求，也能讓客戶很清楚的瞭解他會得到什麼樣的產品。設計者常常會因為不清楚規格而產生一些問題，例如誤解規格裡某些功能，結果做出錯誤的功能，或是規格裡某些地方不完整，導致最後忽略了許多必要的功能。 • 透過規格制訂語言使大家清楚規格描述

嵌入式系統導論, 探矽工作室 統一塑模語言(Unified Modeling Language) • UML是一種描述規格的語言，藉由這套語言的表達，達到系統正規化的表述，使所有看過規格的人都瞭解所描述的產品是什麼 • 一種物件導向（object-oriented）的塑模語言 • 鼓勵將設計分成好幾個互動物件的方式，取代單一方塊的設計 • 這些物件可以代表真實世界的軟體與硬體，利用UML的方式來對應到使用者與外部其他機器

嵌入式系統導論, 探矽工作室 SDL ( Specification Description language)語言 • 為了通訊工業所設計的，包含了狀態、動作和每個狀態之間的轉換條件

嵌入式系統導論, 探矽工作室 OR狀態圖(State-based Diagram)

嵌入式系統導論, 探矽工作室 AND狀態圖

嵌入式系統導論, 探矽工作室 AND/OR表

嵌入式系統導論, 探矽工作室 系統分析與架構設計 • 規格中並沒有說明系統如何做到被要求的事項，只是對事項做了描述。至於描述如何做到這些事項的步驟，則是在架構設計的時候來進行 • 規格制訂完成之後，接下來的工作就是將一份規格轉變為架構設計（architecture design）。 • 架構是一種對於整體系統結構的計畫，說明利用哪些元件來建構系統。

嵌入式系統導論, 探矽工作室 方塊圖 • 利用方塊圖（block diagram）的方式來描述系統架構，顯示這個系統有哪些主要元件。這個方塊圖還是非常抽象，沒辦法使用這些方塊來直接實作，不過這些方塊可以告訴我們接下來的工作方向為何 • 我們可以依據這裡所描述的工作項目分工並進，做出進一步的功能

嵌入式系統導論, 探矽工作室 硬體方塊圖

嵌入式系統導論, 探矽工作室 軟體方塊圖

嵌入式系統導論, 探矽工作室 CRC卡片 • CRC其實是以下面三種主要功能的縮寫： • 類別（classes）：定義資料與功能的邏輯歸類。 • 責任（responsibilities）：定義每個類別該作些什麼。 • 合作對象（collaborators）：定義其他類別所做的工作。 • 卡片上的項目包括了類別、責任與合作對象等資訊，使用者將這些項目寫下，並且相互討論與更新這些卡片資料，直到討論出結果為止。

嵌入式系統導論, 探矽工作室 CRC卡片的步驟 • 發展出一個最原始的類別列表 • 寫下這張原始列表的責任與合作對象 • 建立一些使用情境 • 排練情境 • 重新整理與加強類別、責任與合作對象 • 增加類別關連性

嵌入式系統導論, 探矽工作室 設計硬體與軟體元件 • 元件設計就是遵照架構與規格來建立系統 • 一般包含了硬體模組，例如FPGA（field-programmable gate arrays）、設計電路板等，以及軟體模組部分。 • 採用了標準元件可以加快開發速度 • 設計者仍必須設計一些屬於自己的元件

嵌入式系統導論, 探矽工作室 系統整合 • 把所有設計好的元件放在一起？ • 通常我們會在系統整合階段找到很多臭蟲 • 避免冗長的除錯策略 • 有好的規劃 • 足夠的測試案例 • 先將幾個模組放在一起，確認臭蟲是否存在 • 是否可以將這些元件功能的關係互相獨立，以方便確認 • 至今系統整合還是一項困難的挑戰

嵌入式系統導論, 探矽工作室 品質保證 • 品質保證（quality assurance；QA）的過程是維持一個高品質產品必須的過程 • 品質保證技術 • 國際標準組織（The International Standards Organization；ISO）建立了一套「ISO 9000品質標準」 • 卡內基美隆大學（Carnegie Mellon University；CMU）的軟體工程師協會所發展的「能力成熟模型（Capability Maturity Model；CMM）」，並且推出整合式能力成熟度模式 CMMI（Capability Maturity Model Integration）評鑑制度

嵌入式系統導論, 探矽工作室 ISO 9000品質管理系統的國際標準 • ISO 9000公佈有三套評鑑標準 • ISO 9001適用於組織具有設計／開發，生產，安裝及服務。 • ISO 9002可用於沒有設計活動的組織，亦即依據既存設計去生產或提供服務而不包括設計功能者。 • ISO 9003適用於製造簡單產品的組織，其產品的品質可藉最終檢驗與測試來確保而無需在製造階段實施任何特定的品質管制。

嵌入式系統導論, 探矽工作室 ISO 9000的品質保證 • 品質保證的基本哲學就是提昇所謂預防的文化，而使問題可被預期進而在其惡化前就加以截阻 • 擁有一套工作的方法使其能確保在各階段中作業的有效管制與不符合事項的消除。 • 程序是重要的：雜亂的開發程序只會做出雜亂的產品，品質必然不佳。所以瞭解每個程序步驟才能夠做出高品質的產品。 • 文件是重要的：文件扮演幾個角色：文件的建立可以幫助瞭解程序，文件也同時幫助內部品管小組確保開出來的需求確實是被執行的，而且也幫助外面的人，例如顧客或是稽核員，瞭解程序以及程序如何被實現。 • 溝通是重要的：品質最後還是依賴在人的身上，好的文件確實能夠幫助人們瞭解整個品質程序，不過還是需要組織內的所有人，不只是瞭解自己本身所指派的工作，也需要瞭解自己的工作對於整個系統所可能產生的影響。

嵌入式系統導論, 探矽工作室 CMM • CMM適用軟體工程、系統工程、整合式產品發展及採購等軟體工業之工作領域。 • 初始（initial）階段：這是最差的組織程序，只有少量定義完備的程序，專案的成功依賴的是個人的努力，而不是組織的力量。 • 可重複的（repeatable）階段：這個層級具有基本的追蹤機制，可供管理成本、計畫進度，並且可以讓系統發展符合預期目標。 • 已定義（defined）階段：所有管理與工程進行的過程都已經利用文件記錄並且標準化，所有的專案也都使用文件建置，且符合標準方式。 • 已管制（managed）階段：這個程度可以透過仔細衡量，達成發展程序與產品品質的保證。 • 最佳化（optimizing）階段：在最高級階段裡，可以透過仔細的衡量取得改進建議，並且不斷持續改善組織內的程序。

嵌入式系統導論, 探矽工作室 確認規格存在越久的臭蟲，修正成本越高

嵌入式系統導論, 探矽工作室 設計重審 • 設計重審通常是設計成員開一個會，重新審視系統設計的每一個元件 • 越早找出臭蟲，不要讓有問題的設計進入實作階段，越能節省許多成本以及工作時間。 • 在重新設計之後，可能會和其他元件有新的介面，這時候就必須要重新召開重審會議

嵌入式系統導論, 探矽工作室 衡量驅動品質保證 • 衡量驅動品質保證（measurement-driven quality assurance）方法論 • 利用衡量的方式找出臭蟲比率，就可以藉這些統計資料來幫助我們控制品質。而且有了這些統計資料，不只可以決定最後系統進行測試所需要的大約數量，也可以在往後產品開發的時候作為參考，瞭解大概會有那些臭蟲出現 • 日立公司（Hitachi）的軟體品質評估（Software Quality Evaluation；SQE）系統 • 衡量驅動品質保證方式並不能幫助減少臭蟲 • 用意在於持續改進設計過程，當我們不能夠做出完美系統，至少要知道從哪些方面來進行改善。 • 採用衡量設計過程的方式，並且用這些結果來找出我們將來在其他專案應該要注意的地方。

嵌入式系統導論, 探矽工作室 總結 • 採用方法論的方式將會提升設計過程的品質 • 從需求分析、規格分析、架構設計，到軟體與硬體的實現、系統整合，以及最後我們如何進行品質保證 • 掌握專利權可以成為很好的武器，確保專案成果與競爭力

第三章

第三章

Presentation Transcript