20101016 嵌入式系統開發之道講座

實戰教學造就非凡的你www.ittraining.com.tw

嵌入式系統開發之道講座

All you need to know to develop an embedded system project

實戰教學造就非凡的你www.ittraining.com.tw 為你把關每一道學習品質

Why you are here now?

2


電子產品開發這一行 ...

3


When HTC started up

4

Windows CE


商週：忘記會做微軟　不然就等死

5

～ 2008 2009 ～


微軟：我才不會讓你忘記我呢 ~~

6


必須忘記，是為了往前走；

敢於忘記，是因為對精髓與本質已了然於胸，此時無招勝有招！

7


子曰：「參乎！吾道一以貫之。」

曾子曰：「唯。」

8


Why I am here now?

9


• Ealin Chiu• 工作經驗 : since 1996• 專長：

– 消費性電子產品開發案之專案管理– 嵌入式系統架構設計 – 嵌入式作業系統開發– 物件導向系統設計

• 現職：– 知迅科技總經理– 資策會網路多媒體研究所顧問

• 前職：– 某上市 IC 設計公司 SA 部門經理

Who am I?


How to find me?

• Facebook: 大黑狗

• E-mail: [email protected]

• Blog:http://tw.myblog.yahoo.com/embedded_system_book

http://bigblackdog888.wordpress.com/

11


Why so many people need this book?


What this book wants to describe:

消費性電子產品開發專案＆嵌入式系統開發所需技術的

本質13


你是嵌入式系統高手嗎？

規定 vs.

觀念14


知識是資料的集合，

而智慧是分辨輕重的能力！

15


Agenda

1. 電子產品開發專案的生命週期2. 嵌入式系統從業人員的職涯發展3. Q & A


嵌入式系統開發專案生命週期

- 從成案到出貨


Mission Impossible

18

客戶：我們公司想在聖誕節與農曆春節時推出多媒體播放器


產品規格？

客戶：功能與外觀就跟 iPod Touch 一樣就好了！

19


外部專案

20

老闆：沒問題，這案子對我們公司算是

小 CASE!

老闆：沒問題，這案子對我們公司算是

小 CASE!


內部專案

21


產品規格？

Marketing ：一定要作到跟 iPod Touch 一樣的功能才賣得出去！

22


老闆又接了一個不可能的任務回來，開發團隊的選擇：

1.非自己團隊可以完成 – 先閃人再說2.設法完成 – 採用正確的專案管理方法3.邊做邊看 – 努力加班工作4.一分抗日，二分應付，七分發展自己 – 努力加班擺爛，必要時跳槽

23


為什麼你必須了解開發電子產品的生命週期？

• 越是惡劣的環境，越要減少犯錯的機會

• 專案一開始就要堅持作正確的事情：– 取得規格– 製作計畫– 前期衝撞，總比後期失控好

• 要製作具可信度的專案計畫，就一定要對專案的生命週期瞭若指掌。

24


電子產品開發週期

• 設計產品：商業行為

• 管理專案：管理行為– 不是要做出完美無敵的產品，只是讓所有的人、事、時都

能 under control.

• 開發系統：技術行為

• 生產

• 銷售


嵌入式系統專案生命週期

• 嵌入式系統專案生命週期：– 專案啟動– 規劃階段• 時程• 規格• 資源• 成本• 風險、溝通、採購、品質計畫

– 設計階段– 執行 & 監督階段– 結案


嵌入式系統專案生命週期 – 專案啟動

• 老闆的策略 vs. 專案經理與工程師的職責

• 不可能的任務也要有計畫

• 可行性評估

• 專案經理取得授權


嵌入式系統專案生命週期 – 時程規劃 (1)

• 時程規劃 :– Schedule ≠ ASAP、我盡快！– 測不準原理– Schedule 是訂來遵守的，不是訂來修改的 – 帕金森定律（ Parkinson's Law ）– Rolling Wave Planning


• 把設計時間排入時程！

• 把除錯時間排入時程！

• 把整合時間排入時程！

• 在時程中加入緩衝時間！

30


甘特圖


隨時擁有最新時程的另一個優勢是 :

可以強迫自己決定要製作哪些功能 , 並剔除最不重要的功能！

32


Critical Path

• Critical Path– 關鍵路徑是指網路從 START 節點到 END 節點的序列，該序列具有最長的總工期並決定了整個項目的最短完成時間。

– 關鍵路徑的工期決定了整個項目的工期。任何關鍵路徑上節點的延遲將直接影響項目的預期完成時間（在關鍵路徑上沒有浮動時間 )

• Crith path = 1. A->D->F2. B->C

• 最短工時 = 7


使用 M$ Project 計算 Critical Path

Critical Path 浮動時間


嵌入式系統專案生命週期 – 規格規劃

• 所有參與人員都知道這個專案要做什麼東西嗎？• 只要賣得出去的產品就是好產品 • Scope vs. Schedule - 質能守恆原理

• 請接受這個不完美的世界！讓所有成員都知道這專案不做什麼。– 嘟嘟好就好– 範圍蔓延 (Scope Creep) – 鍍金

在專案管理理論中，這兩個都是負面的名詞


• 不論用哪一種方法，你都應該強制執行“沒有規格，就不准寫程式！ " 這個簡單的規則。

• 不寫規格，是軟體專案中最大且最不必要的風險！

• 沒有規格，就定不出正確的時程！

38


人力資源規劃

• 營級組織，連級人力• 人多好辦事？• 多軍種聯合作戰 • 角色 (role) & 責任 (responsibility)

– Role: 在專案中的角色– Authority: 授權範圍– Responsibility: 應完成事項– Competency: 應具備能力

• 人月神話


人力資源規劃 (2)

• Case Study– 如果預估一個專案需要 20 個人 /月的工作量，等於要花費5 個工程師， 4 個月的時間開發的話，把工程師增加到 10個人，開發時間並不會減少到 2 個月。

– 這就像 2 個媽媽懷胎十月才能生 2 個小孩，增加到 4 個媽媽並不會讓懷胎減少到 5 個月一樣的道理。


團隊建立 - RD 組織架構

• Project Management – 專案管理組• Hardware – 硬體組• Mechanism – 機構設計• Firmware – 韌體組• System & Integration – 系統整合組• Application & Server – 應用程式組• QA/QC – 品質系統與測試• Supporting – 支援組 ( 美工、文件管理…等 )


嵌入式系統專案生命週期 – 成本規劃

• 製造成本 : 一切都為了 Cost Down

–任何數字乘以 13億之後都是個大數字• 人力成本• 訂價結構範例：

– 造價 x(1+10%) = 客戶進貨價– 客戶進貨價 x(1+20%) =代理商進貨價– 代理商進貨價 x(1+30%) = 通路商進貨價– 通路商進貨價 x(1+35%) = 門市零售價



• 嵌入式系統專案生命週期：–專案啟動–規劃階段–設計階段–執行階段–結案


因為以下兩點1. 事情沒有表面上看起來這麼簡單2. 在專案開始就要試圖降低風險

我們導出一個結論 – 你必須先做設計再去實作！

（修改程式就是無法和修改文件一樣簡單！）

46


動手之前 - 確定本專案的執行原則

• 如何執行：–專案管理–軟體工程–品質系統

47


死板的遵守教科書與國際管理 /品質標準，其實對專案有害無益！

重要的是能抓到這些規範的精神，依據專案特性與軟體工程規範，定義最合適的工作方法，並確保專案可按規格如期完成。

48


嵌入式系統專案設計階段

• 規劃階段是確定專案可行性，盡可能杜絕一切不確定性

• 設計階段最重要的工作是 :– 細部設計– 文件化– 設計審查– 變更控制– 風險評估


Case Study: 火星探測船的失事原因1999年美國所發射的一台火星探測船，在接近火星的時候失事，原因是登陸火星的引擎在點燃時已經與火星距離太近。最後的調查報告出來，其中一個很重要的原因是美國噴射推進實驗室（ Jet Propulsion Laboratory ； JPL）與合作廠商 Lockheed Martin 公司兩個單位工程師所使用的計算單位不一樣。

JPL 用的是牛頓（ newton），而另外一家卻是用磅來當作計算單位，可是雙方卻都以為對方和自己用的是一樣的單位，導致計算出來的結果與真正的軌道差距 4.45倍。也因為這個原因，使得這艘火星探測船並沒有在正確的時間點燃引擎而失事。


設計階段 – Scope Design

• 輸出 : Product SPEC. or Functional SPEC.• 一定要正式和客戶確認規格 .

• Spec. document includes:– 硬體規格簡介– 產品設計理念、限制與應用範圍– 使用者功能說明– 操作流程圖– User Interface 與美工圖案– 效能規定 ( 例如產品耗電流 )– 特殊注意事項

詳細地定義到底要作什麼，做到什麼程度 !!!


軟體規格文件範例 – 流程圖


軟體規格文件範例 – 功能列表


設計階段 – Hardware Design

• 硬體設計階段的工作項目 :– CPU 選擇– 主要晶片選擇– 迴路設計– Layout– 零件、材料管理– 產品外型 (ID) 設計– 機構設計– 開模之前的模型製作

• 重要輸出 :硬體設計規格書• 除了外觀與機構設計外，韌體工程師應該參與每件事

情的決策


硬體、機構設計相關產出 (1)

爆炸圖3D 立體圖



線路圖 (Schematics Diagram)



PCB Layout Gerber 圖

對工程師而言 , 這是線路圖與 real board 之間的橋樑


硬體、機構設計相關產出 (5) - BOM

BOM (Bill of Materials) 表


設計階段 – System Design

• OO design in embedded system?

• Output:– 系統架構設計– API 與程式風格設計– 嵌入式作業系統設計– 模擬器設計– Source Tree 設計– 程式風格典範

使用 OO 的觀念，但不使用 OO 程式語言


系統架構範例


系統架構範例（ 2)

64


設計階段 – Testing Plan Design• 測試工作的重要性絕不亞於開發工作 • 測試工作必須被控制，測試結果才可被量化 • 避免亂槍打鳥

• Output:測試計劃書

• condition table vs. testing case


• 軟體工程師不可能寫出沒有 bug的程式，

• 測試工程師也不可能找出系統中所有的問題，

• 所以測試工作一定要經過仔細的規劃，則測試工作才可以被控制，測試結果才可以被量化，產品品質才可以被保證。

66


省下測試人員的錢，並不是真正的節省。通常結果恰恰相反！

測試工作永遠無法取代一個考慮周密，準備充分的評估與設計過程！

67


設計階段 – Quality System Design

• 品質是規劃、設計出來的，不是檢查出來的 • International Quality system

– ISO 9001– CMM

• Workable quality system– 確實可執行– 依專案量身訂作


小心方法論，方法論可以讓每個人都提升到不佳但可接受的程度！

（有才華的廚師顯然不會樂於在麥當勞做漢堡！）

69


Project Quality Baseline 範例

70

Microsoft Office Word 97 - 2003 ??


嵌入式系統專案設計階段 – 風險評估

• 莫非定律：只要可能出錯的地方，就一定會出錯！(Anything that can go wrong will go wrong!)

• 越到專案出現的風險，對專案影響越大• 嵌入式系統專案可能發生的風險 :

– 時程延宕– 需求膨脹– 人員流失– 規格崩潰– 績效低落– 技術落差– 不同領域人員或公司間的文化差異– 軟硬體整合的相關問題– 生產 /製造的相關問題 ( 零件缺貨或漲價、工廠產能不足… )


嵌入式系統專案設計階段 – 文件管理• 文件也要做版本控制

• 盡早擬定文件發展與管理計畫，應該被記錄的文件包含：– 產品規格– Schedule– 硬體設計相關文件 (CPU PIN腳配置圖、線路圖、 Layout 圖… )– 技術文件 - 晶片的 data sheet 、 3rd party軟體函式庫的 API…– 系統架構圖– 系統 ( 軟體 )設計規格書 (包含各模組 API)– 測試計畫書– 測試報告以及 bug sheets– 品質文件– 重要會議紀錄– 重要郵件備份– 其他


開始實作之前 – 設計審查

• 設計文件存在的意義 – 服務內部客戶• 計畫中明確訂定設計審查的執行時間

74


嵌入式系統專案生命週期 – 執行階段 (1)

• 實作階段 -執行所有設計，包含：– 程式開發與除錯– 硬體 (電子、機構 )開發– 執行軟體與硬體測試– 軟體版本控制與 bug 管理– 品質系統執行– 工廠試產 – 變更控制 (scope 、 cost 、 schedule baseline)

執行階段重點應是大量腦力、勞力密集之”人”的管理！


有效率地應用人力

• 先有系統架構，再根據設計文件長程式骨肉• Interface:

– 模組間的介面– 系統間的介面

• 軟硬體工程師的合作模式– 軟體工程師硬起來– 硬體工程師軟下去


站在巨人的肩膀上

• 再提醒一次 : 我們是作產品，不是作研究

• 善用 Sample Code– 你自己寫會比原廠寫得好嗎 ?– 重新發明有意義嗎？– 效率、成本、品質至上

• CPU 與周邊 IC 的運作方式 :– 不要用猜的、別以為理論上應該…– 有時 data sheet也會錯、更不要聽 sales唬爛– 請 FAE幫忙就是了



• 衝突– 客戶 vs. 廠商 – 軟體 vs.硬體 – 研發人員 vs. 規格訂定者 – 國內單位 vs.海外單位 – 系統整合者 vs. 外包廠商 – 工程師 vs.測試人員 – 開發端 vs. 工廠端 – QA/QC vs.其他人

PM 應該花 90% 的時間在溝通，解決衝突

如果 PM 完全不具基本的專業知識或電子產品開發生命週期，如何解決甚至預防這些衝突 ?



• 產品化 - 工廠前置作業 :– 備料計畫– 加工線排定組裝線、測試線排定– 製規 ( 標準生產製作規範 )訂定– 測試架設計– 估價並計算工時– 計算產能– 作業員教育訓練

– 環境測試– 電子安規測試 (ESD 、 EMI…)



• 產品化 - Input:– 量產同意書 from 工廠的 QA 人員 – 允許量產通知單 from 客戶

• 電子產品製造的流程 :– 軟體燒錄 or 開 Mask for ROM– PCB SMT– PCB測試– PCB 加工 (難免還是會需要人工手焊 )– PCB半成品測試 ( 使用測試架 )– 組裝– 成品測試– 包裝– 驗貨


嵌入式系統專案生命週期 – 專案結案

• 無間道：無止盡的修改與版本發行– 改的越多，功能就會越強，品質就該越好？– 品質系統本來就不是在追求完美無暇的產品，而是要求產

品開發的過程必須依定一定的程序，好讓產品的品質是可以被控制的

• 出貨 ≠結案


• Close meeting:–組織專案運行資產–行政結案– 合約結案

84

您的組織有真的做過明確的結案動作？還是從上到下，老早就各自逃難去了 ?


Q&A (1)

任一個嵌入式系統專案的生命週期都是如此 , 所以開發與管理也有一定的準則可依循


嵌入式系統從業人員的職涯發展

- 從菜鳥工程師到老闆


企業組織架構範例

87


唯有團隊成功，才會有個人的成功！

個人 = 工程師技術主管架構師專案經理產品經理

88


嵌入式系統開發 – 專案成功的定義

• 不超時• 不超支• 功能與品質合乎規格• 客戶滿意• 可順利量產 • 專案成員有成就感• 專案成果與技術累積• 公司獲利• 個人發財


如果你是老闆，最好能僱用：

可以接受新觀念，或學習任何新技術的工程師，而非剛好此刻知道如何移植 Android frame buffer driver 的人。

90

工程師

實戰教學造就非凡的你www.ittraining.com.tw 為你把關每一道學習品質 91

軟體工程師的工作性質

Programming vs. Integration


巧婦當為無米之炊

任天堂紅白機

-8bit CPU-1.77MHz

• 評估實現瑪俐兄弟的困難度 ?•In PC•In Embedded Device


其他限制• SPEC.• Schedule• Developer Resource• Computing power• Memory Size• Component Selection• 機器外型 (機構設計 )

Cost93


直覺上簡單的事情，在較弱的平台上 , 也會變得複雜起來！

94


計算機系統

an IC


驅動程式＆基本硬體知識

97

實戰教學造就非凡的你www.ittraining.com.tw 為你把關每一道學習品質 98

時序圖


量測儀器

99


精密手工藝

100


嵌入式作業系統

• RTOS (real time OS)

• Embedded Linux/Android• Windows Mobile• …

101


全心參與專案

如果有一天，由你來設計這些產品，最重要的考量是什麼？


架構師• 可擴充性 /可重組性• 可移植性• 可維護性

103


架構師

• 建構嵌入式系統平台– 開發環境設計– 開發流程設計

– 系統架構設計– API 設計

讓應用程式工程師可以不管硬體與系統的細節，專注在應用程式開發！

104


嵌入式系統平台


嵌入式系統軟體開發團隊組織架構

Middleware 開發 management

IC 驗證 OSHAL 版本

控制

文件

控制既有

功能移植

新功能

開發

系統整合

LCD Audio Video …

HA

L A

PI

OS

AP

I客戶A

PI

架構

AP

模擬器

架構

設計

tools

Driver 開發

Project Leader

系統平台開發小組

組織架構乃依實際狀況而定沒有完美的組織架構但組織架構必須直接反應系統架構


系統平台開發小組

• 負責任務 :– 系統架構設計與實現– 嵌入式作業系統設計與實現– API 設計與實現– 記憶體使用配置– 開發環境設計– 模擬器設計與實現– 系統整合 ( 整合底層的驅動程式、系統程式，以及上層的子系

統、函式庫與應用程式 )– 版本製作


系統架構設計

• 從技術角度來看 :– 硬體規格

• CPU速度 • 記憶體容量 • 周邊裝置的效能

– 產品規格 – 驅動程式、系統、子系統與應用程式各層

之間的溝通介面

– 產品特性


系統架構設 (2)

• 從專案管理的角度來看 :– 人力與時程 – 品質要求

• 從系統的角度來看 :– 即時 (Real Time) 的需求– 多功 (multi-tasking 或 multi-threading) 的需求– 電源管理的重要性– 可擴充性的重要性– 可移植性的重要性


系統架構範例


資料流架構範例


軟體架構師的成功秘訣

• 分層抽象設計• 多層次設計模型 (Model)• 堅持的勇氣


何謂系統架構？ - 結論 (I)

• 系統架構沒有一定的標準或對錯，但不能沒有• 所有專案參與人員都必須熟知既定之系統架構• 系統架構帶來的好處：– Abstraction – 盡量不要重複開發某功能– 工作較容易被 breakdown– 所有程式開發的 scope被限制，可較準確地預估時程– 工程師對目前在做的專案可有整體性的技術考量– 在底層未完成之前，上層程式可先簡單地模擬既定的

API ，開發工作可同步展開


何謂系統架構？ - 結論 (II)

• 根據研究，圖形表示是最容易讓人的大腦理解並留下記憶的方式；實務上也是如此，好的圖示勝過千言萬語。

• 尤其作軟體設計的人，一定要學會用圖形表達系統架構與資料流。當架構圖畫完後，負責文件寫作的同仁只要按圖說故事就可以了。


技術主管• Functional Manager – 工程團隊管理

– 承接並執行組織與專案任務– 團隊內部制度建立– 工作配置與進度追蹤– 士氣管理– Code Review

• 必須兼顧團隊中長期的發展 (roadmap) ，以及所承接專案的進度

115


專案經理如果您在台灣擔任專案經理一職，最好可具備以下技能與相關觀念：

-專案管理-技術管理-電子產品開發週期-系統架構-生產管理

116


關於專案

• 70% 的專案失敗是因為管理不善引起的 , 而非技術原因

• 大約只有 10% 的項目能夠在預定的費用和進度計劃下交付

• 大部分的新任專案經理會認為專案管理是一種意外的工作


專案管理的迷思

• PMI: PM最重要的工作是溝通， PM 應該要有 90%的時間花在溝通

• PMI: 專案的品質是規劃出來的– 實際上，幾乎所有專案都是用檢查來保證品質– 實際上，很多嵌入式系統專案連檢查都做不徹底！


是專案規格真的很困難，還是因為你的團隊讓它變得比實際上還要困難？

121


專案

• 專案是為完成某一獨特的產品或服務所做的一次性努力 – 目標導向，每個專案都是唯一的– 非批次或日常活動

• 軟體專案 :– 軟體開發規範嚴謹度遠不及其他領域 ;經驗在軟體專案上仍起著極大的影響力

– 軟體仍未脫離手工開發模式，而人的管理是最麻煩的– 軟體開發仍是最複雜的領域之一– 軟體是純知識產品，其開發進度和質量很難估計和度量


一般專案 vs 嵌入式系統專案

• 嵌入式專案包含所有軟體專案的特性，除了 :– 對硬體性能的依賴– 對硬體成本相當敏感– 涉及生產相關事宜– 產品品質要求視最終市場定位而定


專案管理 + 軟體工程

• 專案管理與軟體工程都關注達成目標前的過程，意圖歸納出最佳實踐 (best practices)

專案規劃專案監控

專案實施

軟體開發

軟體開發過程定義＆改善

軟體開發品質保證＆監控

軟體工程

專案管理


專案管理五大步驟


專案管理九大知識體系

• 整合 (Integration) 管理• 範圍 (Scope) 管理• 時間 /時程 (Time) 管理• 成本 (Cost) 管理• 品質 (Quality) 管理• 人力資源 (Human Resource) 管理• 溝通 (Communication) 管理• 風險 (Risk) 管理• 採購 (Procurement) 管理


艾森豪： Plans are nothing, but planning is everything!

128


產品經理 (Product Manager or Leader)• 大 PM• 新產品的市場與需求分析• 用戶體驗分析• 團隊建立• 成本與時程控制• 為產品成敗負責

129


產品經理的五力

• 規劃力• 設計力• 溝通力• 執行力• 推廣力

130


發展新技術與推出新產品

131

• 決定不做什麼，比決定作什麼重要！• 適時的踩煞車！


專案管理基本概念

Schedule

Scope/Quality

• 專案管理的鐵三角 – 質能守衡定律

Cost


如果你沒辦法把一堆木塊塞進一個箱子，你有兩個正確的解決方法：

找個更大的箱子，或拿掉一些木塊。

以及一個最爛的選擇：讓工程師加班，直到塞進去為止！

133


嵌入式系統專案 – 組織文化問題

1. Communication! 2. Communication!3. Communication!

如何克服組織裡的障礙，使產品順利出貨？


多軍種聯合作戰計畫

• 敵情偵查• 氣象狀況預估• 各軍種部隊集結• 敵後空降• 艦炮• 步兵搶灘• 空軍掩護• 建立灘頭堡

產品設計與競爭者分析市場調查晶片、 solution 與廠商選擇軟體、硬體、機構設計備料與生產計劃銷售計畫 MP & Shipping


善用專案管理工具

136


• 從流程中導入工具– 每週報告的表格– 專案經理使用 Project檔執行進度追蹤– RD只處理 bugzilla 發出的問題– 測試人員不用額外製作報告，直接使用 Bugzilla 自動產生

的報告– 測試人員只能從 SVN抓下最新的 code ， build 後進行測試。不接受任何 binary版本的測試工作。

– …

137


工商服務時間


What’s new?

139


Before ending...

道德經 :

上士聞道，勤而行之；

中士聞道，若存若亡；

下士聞道，大笑之 !

140


Q & A

歡迎任何與嵌入式系統這一行有關的問題


Thank You!

142

20101016 嵌入式系統開發之道講座

Documents