硬體產品專案管理經驗分享 - 規格 (specification)

前一陣子有朋友問到硬體產品專案設計/生產/測試該注意到的問題. 本來我想翻一下 google 找一些比較完整的說明 forward, 除本身這個話題範圍很廣外, 不知是我關鍵字用錯還是怎樣, 找不到比較適合的, 就順便就把我覺得 PM 該知道, 該注意的寫出來.

在有規模的系統廠, 組織的分工比較細, 硬體專案進行都有自己公司的標準 ISO 流程或 PDM/PLM 系統. 從前段規格確認, IP 專利分析規避, 合約檢查, 中段的設計檢查, 量產規劃, 到後段生產 flow, 生產 ramp up 該做的流程都蠻固定的, 但項目說起來頗多 (其實是非常多, 理論上所有 ISO 流程文件都會產出, 並且最後入到 DCC (document control center) 做統一管理). 像手持裝置 ("非" feature phone 類的) 變化又更多, 所以, 這邊介紹時會簡化很多.

在這邊除了寫規格該注意的事項外, 我覺得有幾個非技術的事情 PM 要隨時注意, 例如:

* 要保持對狀況的靈敏度 (例如: 要交付的目標是什麼, 目前共識有哪些, pending issue 有哪些, 問題的優先順序跟其他人是否一樣). 重點是, 不要讓自己或團隊狀況外. 你的產品會忠實呈現團隊狀況外的程度.

* 認識 team member 的行為模式, 不見得每個人都是華盛頓 (either 沒事會去砍櫻桃樹或面對問題認錯), 自我感覺良好不是高官們的專利. 從辦公室打掃的, 到公司管理階層, 沒出大事之前大家的感覺都會很好.

* 對自己不了解的問題, 不要輕易放水. 放水不代表不用負責, 只代表還不夠專業.

* 要記得追蹤有風險的決定, 不要以為一開始沒事就沒事. 莫非定律出現的機會通常比你的運氣好. 如果要用趕工 (crashing) 或是同步作業 (fast tracking), 請記得讓大家知道這叫 fast tracking 跟 crashing, 是有額外 cost 的. 要記得警告大家風險成本是多少.

* 問題能早解決就早解決, 拖到最後還是要解. 常見有人剛開始跟你說 ok, 但最後大家都得健忘症, 代價沒人願意承擔. 遇到這種情形, 請把深海魚油跟雞精準備好, 魚油給別人補腦力, 雞精留給自己熬夜吧 =_=

雖然大家都知道這些, 但是常因為現實環境 (成本, 時間, 部門利害關係) 而犧牲. 但是, 不管如何, 還是要隨時注意. 下面每個主題, 都只簡單介紹該領域我覺得最簡要的部份 (也就是包括, 但不限於的意思啦):

* 不要覺得規格確認是 one time work
規格確認不是一件做完就不用管的事, 而是一件到產品 phase out 之前都可能會跟著你的問題. 因為可能發生的狀況太多, 有可能零件停產, 某批零件 quality 有問題, 客戶發現新的設計問題, 有新的法規等... 不過以項目來說, 主要下面幾點:

** 硬體功能需求: 要有哪些硬體功能, 以及這些硬體功能的規格要求. 舉例來說: wi-fi 不是 chipset solution 決定就好, 輸出的 power 跟天線敏感度, 耗電量這些細節都要放到文件裡. 現在 wi-fi chipset 都會有 firmware 或是執行時要載入 firmware. Firmware 經常會有細小的差異跟 bugfix, 這些都會影響中段產品測試, 認證及產測規格. 如果客戶有指定或覺得重要的 test case (穩定在某個環境, 傳輸多少資料的效率或不中斷之類的測試), 請一定要做.
如果 wi-fi 傳輸時要亮燈, 或是可以用 packet 喚醒 suspend (IP phone 標準) 狀態的 wi-fi, 這些都跟電路的設計相關. 通常設計階段還會跟硬體及機構件的 placement (晶片放在電路板哪些位置) 相關, 這些都會影響 schedule 跟最終客戶驗收的 quality, 請注意.

** 與硬體相關使用者行為確認
使用者介面分為兩個, 一個是純軟體的 UI, 另一個是跟硬體的互動 (通常是 LED/按鍵/Dial/track ball 等等). 拿 iPod 當例子來說, 當 iPod 在播放音樂時, 把耳機線拔掉, 音樂就會停. 這就是硬體設計 interrupt 支援軟體行為可能性的範例. 盡可能把所有 user case 釐清楚. 請千萬記住, 硬體是沒辦法跟軟體一樣說改就改. 軟體按 make 重新 compile 的成本很低 (至少一般人感覺很低啦 =_= ), 以為改硬體也是重新焊個元件, 改個電路, 加個電阻或換個 filter. 但是改硬體馬上就有原有料變廢料,重新驗証新料/電路的時間, 新洗板子, 打件驗証的時間, DFM (design for manufacturing) 變更, 這時間跟成本其實是難以想像的高.
或許有人會提 rework 可節省一些驗證的時間, 但是問題是: rework 的 quality 通常不穩定, 很多驗證時會發生: 這是原有的問題, 還是 rework 的問題? 功能可能可以 rework 驗證, 但 DFM 可能還是要重新來一次才能確保 quality.

** 使用環境: 裝置是手持式, 車用, 家用, 工業用, 玩具都有不同的測試規範. 主銷非洲市場跟用在俄羅斯的產品要做的測試重點也不太一樣. 請針對環境可能的需求, 讓客戶盡量描述清楚, 並跟相關人員討論增加一些對應的 test case, 以及對應的入料檢驗規範. 在環測測試中, 你會發覺大部分東西遠比你想像的容易壞, 而零件的價格跟品質大部分都是有道理的. 請記得, 零件供應商的產品規格不檢驗的問題在 "你", 客戶通常是不會找零件供應商的. 東西該摔就要摔, 該震就要震, ESD 該打多少就多少. 產品的 quality 控制就靠這些細節執行. 我也相信 PMI 說的 quality 是 design in, 不是 inspect in, 但事實是: 通常大家都覺得已經 design in 了, 直到 fuse 爆掉那一天.

** 使用壽命: 使用壽命跟產品的成本 Life cycle 管理, 供應商管理, 售後服務都有關係. 跟產品的設計, 用料都有直接的關係. 機構料本身的 cycle 數使用限制, 到 SD 卡插槽的跟 SD 卡接點 pin 耐磨程度, connector 的鍍金厚度. 都是 base on 使用環境跟使用者行為來評估. 另外售後服務的時間, 跟備 customer support 的料的量, 都應該找相關部門以評估成本.

** 認證: 認證大致有幾種 1. 安規 Safty 類 2. 不同國家進口的額外需求 3. 客戶營運商需求 (PTRCB/FTA/etc) 4. 綠色環保類 (Green, RoHS, WEEE) 5. 還有要掛 Logo 類 (Bluetooth/Wi-Fi/etc). 不同國家的安規規定, 也會造成產品包裝/標示/說明書問題, 甚至送認證的名稱都可能會影響後續進口流程及系列產品認證, 這些都在認證時要考慮.

標準的安規例如 FCC/CE, 需要注意的地方是要跟安規實驗室 (lab) 討論 user test case. 產品的硬體版本, 及相關 accessory (尤其是變壓器/充電器), 連接 cable 等, 在進 lab 前請先確認. 同時, 進 lab 前記得要先做 pre-test, 如果 pre-test 沒過, 通常都是有 RD 沒說的隱藏問題, 一般來說送 lab 前還有這些問題, 這些問題都會影響最後 quality.

安規看起來大家都在做很平常, 但其實可以幫你從外部 lab 角度看產品 EMC/EMI 跟穩定問題. 不同國家, 可能有不同的認證需求, 像手機進台灣還要做 NCC. 如果是包含 GSM/3G 功能, 但是使用的是 chipset 而不是現成的 module (如 原為 Siemens 的 Cinterion), CE 還會需要 GSM protocol 相關測試, 這類 protocol 測試一個 run 要上百小時. 如果包含多個 RF 射頻的智慧型裝置, 不同國家還有不同的功率規定及通報規費 and 額外的時間, 請把它算到你出貨的 schedule.

Green 相關常見有 RoHS 跟 WEEE, RoHS 可依廠商宣告書管裡做自我宣告, 這部份每個公司對於廠商宣告書的 policy 跟管理工具都不太一樣. 當然 Lab 也有 X ray 掃描或化學方式可做分析, 但是大部分還是以供應商管理比較多. WEEE 除了要拆解說明書外,還要跟歐盟認可的廢棄物處理商簽約才算有效.

要把 Wi-Fi 跟 Bluetooth 的認證 Logo 合法掛在盒子上, 通常都有額外的認證/測試流程. 想掛 Logo 你必須先加入對應組織的會員 ( Alliance 或是 SIG (special interest group)). 加入價錢從免費 (Bluetooth), 到數千 USD 不等, 你必須選擇適合你的 package. 然後才是根據掛 Logo 需要的條件做認證. 請記得, 有 Wi-Fi 跟 Wi-Fi certified 是兩件事. RD 說功能 ok 不代表你可以掛 Logo. 掛 Logo 不是紙盒上印就有的, 要 1. 加入會員, 2. 做過認證 3. 符合相關掛 logo 規定才算. 最後記得把成本算進去. 有些 Logo 還有 IPR 的費用 (DVD/CD/MP3/etc), 付費方式也不一, 請先注意.

如果是你自己開公司作產品, 或公司本身先前沒有為 device 申請 MAC 專屬位置: 還需要先到 IEEE 申請一個 OUI (就是 MAC 位址前3 byte 啦), USB forum 申請一個 USB ID. 含通訊功能的手機或移動裝置的話, 還需要去申請一段空的 IMEI number 供使用.

IEEE OUI: http://standards.ieee.org/regauth/index.html
USB: https://www.usb.org/members_landing
IMEI: http://www.babt.com/gsm-imei-number-allocation.asp

取得 Freerunner 原始碼及編譯完整 image 的方式 - 使用 mokomakefile

原本當初 Openmoko 新手手冊預計會寫 20 篇, 前 10 篇是基本操作, 後 10 篇預計是寫 tool/build 相關的. 最早會想寫的原因有幾個, 包含: 減少大家問重複問題的機會, 補充網路上一些中文資料不完整的地方, 還有順便當自己備忘錄 :)

後 10 篇最後沒寫是因為覺得網路上資料其實夠多, 像 OpenEmbedded (OE) 跟 git 都很多說明資料在 blog (英文很多) 或是有 PDF 格式可供下載, 一般 developer 如果這類閱讀問題沒辦法解決, 要真正加入 FOSS community development 的開發會很困難. 另外有公司組織上功能區分的原因 ;-)

原先 document team 有 "理想" 要把 wiki 內容整理到 Floss manuals 這個 project (http://en.flossmanuals.net/), 這樣只要再把整理的文件, 翻譯成中文, 這樣也比較會有一致性. 而 Flossmanuals 是另一個希望能讓 open source software 工具, 能有一個清楚説明公開文件的 project.

最早 Openmoko 在公開 wiki 時, 就提供了 SVN 的 u-boot/kernel 及 based on OpenEmbedded (OE) 的 package 在網路上供人下載. 同一時間, 少量的 Neo1973 的工程樣品, 也免費送到各個重要的 Open source community (phase 0 user) 的開發人員手上, Rod Whitby 是其中的一位, 他就幫 Openmoko 寫了一個非常強力的 makefile, 目的是讓 developer 能夠用簡單的方式, 透過 OE 能讓每個 developer 都能用 "一樣" 的 code base, 自己 build 完整的 distribution (kernel + rootfs). 早期的 mokomakefile 需要先自行安裝及設定 monotone (版本管理軟體, OE 在 2008 年前使用), 後來 OE 改用 git 當版本管理程式, mokomakefile 幾乎能全自動的完成所有 build image 的程序. 個人第一次使用時覺得: 這個 Makefile 真是超神奇跟強大的工具, 雖然當初在我的舊 PIII 1.2 G NB 編了快 3 天, 但自動化跟穩定程度真是神奇, 值得大家試試看.

* Mokomakefile 的主要說明網址: http://wiki.openmoko.org/wiki/MokoMakefile

Mokemakefile 全自動完成以下的幾件事:

* 下載 OpenEmbedded 的 Bitbake, 及相關設定檔原始檔

* 從網路上各個 bitbake recipt 指定的 git/svn 位置, 及下載套件指定訂版本原始碼

* 下載 recipt 裏的 patch 及相關設定

* 設定/建立 Host 端 OpenEmbedded 所需的設定, 包含工作目錄, 暫存目錄, image 存放目錄, 套件存放目錄...等等

* 依照編譯設定檔, 套用 recipt 指定的 patch 後, 編譯所有的套件, 包含 kernel 及建立 rootfs 所需的所有套件

* 根據設定檔的設定, 編譯套件的 ipk/opk 檔

* 將編譯好 rootfs, 根據設定, 做成 flash 可接受的 image 格式, 以及完整 rootfs.tar.gz 壓縮檔

OE 的系統龐大, 如果工具不熟, 對於開發人員是很大的負擔. 熟悉後, 它的優點及缺點大致如下:

* 優點: 能夠快速而且彈性的建立新的跨平台 embedded 專案套件, 不需要自己trace OE 套件都維持在最新的版本. 分散式開發架構, 國外開放/嵌入社群熟悉的工具及交流模式.

* 缺點: 學習曲線長, 速度慢, 開發工作易被外部的套件更新影響, 把原先簡單的工作複雜化 (如不是自己開發的套件發生 bug, 原本只需要在 local patch, 重 build, 重新 package. 使用 OE 協調多個 team 可能要繞一大圈, 效率低而且容易溝通出錯)

如果要使用 OE, 我建議還是讀一次 OE 的手冊, 尤其是第 7 跟第 8 章講授的系統概念部份.除了 OE 官方的英文外, 大陸 developer 有翻一份中文的, 如果習慣大陸編程語法的程式員們, 可以參考 http://blog.chinaunix.net/u1/52172/showart_1346396.html

Openmoko 版的 mokomakefile 現在由於無專職人員 maintain 加上 download path 有變更, 所以如果使用網站上的 mokomakefile (from freesmartphone) 會出現一些目錄找不到導致的 bitbake python 錯誤. 但是不用緊張, 還是有 community 的 team 負責維護相似的 mokomakefile. 目前主要有法國 Bearstech 的 SHR (http://shr.bearstech.com/ or http://shr-project.org/trac) 跟德國 Micky 帶領的 freesmartphone.org http://www.freesmartphone.org/index.php/Main_Page . 不過據最近 (2009.8) mailing list 討論, Freesmartphone (FSO) team 未來可能會 based on SHR 的 distribution 開發上層 dbus based application framework, 不會自己再發行 FSO distribution.

使用 mokomakefile (或是 SHR 的 Makefile) 很簡單, 但是時間可能很長 (一般來說, C2D 機器第一次 build 可能會到一整天), 大概步驟如下:

* 在 ~ 下建立一個屬於該 distro 的目錄
* 用 wget 把 http://shr.bearstech.com/ Makefile 檔案抓下來, 放到目錄下
* 根據自己 OS, 參考 http://wiki.openmoko.org/wiki/MokoMakefile 的說明, 安裝 host 端 (PC) 所需要的基本編譯套件. 每個 distribution 不太一樣, 例如 SHR 還需要額外的 curl. 基本上編譯時請先看 download site 對應的 readme, 以及編譯時的訊息, 缺什麼補什麼.
* 然後 make 或是 make "套件名稱" 像是 make shr-testing 之類的
* 然後第一次大概需要等一天, 依所使用的機器不同而不同. C2D E6420 大須需要 18-24 小時. 同時 download 套件可能需要數 G 的容量.

編譯完後, 可以在 deploy 目錄找到, 如圖.

如果你有多台電腦, OM 的 developer 會使用 icecc 來做編譯的工作, 靠著 5-7 台左右的 quad-core 電腦網路分散編譯, 把完整編譯時間縮短到一小時內. 這算一個很不錯的使用 linux 編東西 hint 跟 technique.

在 2008 資策會創新應用服務研究所的開放原始碼行動平台研討會上, 我有整理一份 Openmoko 相關環境的介紹 http://t0ny.net/openmoko/doc/Openmoko_enviorment_n.pdf 可以當參考.

被忽略的M2M (Machine to Machine / 物聯網)

近來好像大家的注意焦點都擺在小筆電, 或是智慧型手機平台這類產品上. 不論各家廠商如何行銷自己的功能 (多點觸控, 待機時間長, 便宜, UI 炫, 開機使用服務快不快) 但檢驗法則很簡單, 就是使用者 (人) 對於產品的接受度.

小筆電 (x86 based netbook) 目前基本上廠商都只能在 Intel 跟 MS 定下的規則下面玩 (螢幕尺寸, 使用的周邊 chipset, 甚至 Windows 版本). 接下來半年應該是看看 ARM based 的 smartbook 面世後, 看的是一般使用者對於效能及功能上的滿意度. 還有 netbook 跟 smartbook 的 BOM/Retail 價格是不是能重新區隔出一個市場.

Smartphone 智慧型手機看起來雖然家數很多, 目前能提供整合軟硬體的使用者體驗的其實只有 Apple (iTunes/App store) 跟 Blackberry (push mail). 不把 Google/Nokia/HTC/Samsung 算進去是因為 Google 不是自己作硬體, 而 Nokia 的 Ovi store 使用者太少, HTC/Samsung 並沒有使用者忠誠度高的軟體服務.

最近一則新聞沒佔到什麼版面, 不小心閒閒沒事翻 news 翻到, 引起了我的注意. 就是 Verizon Wireless 跟 Qualcomm 要合資組一間專做 M2M 的公司. M2M 是 Machine to Machine 的縮寫, 字面上來說, 就是機器對機器. 寫到這邊, 覺得本篇的標題下錯了. 因為, 今年暑假最 hito 的就是 M2M 啦, 連小孩都愛的 M2M...變形金剛啦!!!

基本上 M2M 涵蓋的範圍很廣, 簡單的例子, 從搭捷運用 RFID 卡到高速公路 ETC 易通機, 或者計程車隊服務都算 M2M 的基本應用. M2M 通常需要整合軟體服務架構及硬體設備, 以提供一個穩定的服務, 所以大部分都是以專案的方式進行. 這裡有一篇介紹 m2m scope 的內容可參考.

http://cdnet.stpi.org.tw/techroom/analysis/2008/pat_08_A021.htm

因為 M2M 中間並不會有 "人", 所以系統穩定性要求很高, 軟體服務設計架構與測試也比一般的 utility 難度高很多. 因為不管是工業應用上的 SCADA 或是移動式車隊服務, 考慮通訊時的狀態/通訊 handshaking 時間窗口/連線穩定都是很大的挑戰. 但是由於資訊服務是內嵌在 M 的 (machine), 所以 M (machine) 只要工作, 就會 "固定" 使用到這些資訊服務跟頻寬, 提供這些服務跟頻寬的公司就可以收到 $$. 這個 ecosystem 裡, 一般通常包含以下的角色:

* 硬體提供者: 製作硬體的公司
* 通訊服務提供者: 通常是電信公司或是網路營運商
* 軟體服務提供者: 提供特定的軟體後台, 以及通訊 middleware
* System Integrator: 整合軟硬體服務

目前專案 M2M 大概包含這些角色. 但是 M2M 是不是只有這樣呢? 前幾年因為專案的關係, 做過一些 M2M applications, 後來因緣際會 Project 剛好有機會接觸到 Dash Navigation 的公司 (前一陣子被 Blackberry 的 RIM 併購), 除了 GPS 導航軟體/通訊服務 (T-mobile/Google wi-fi network)/軟體後台 (JMS/Oracle) 外, 他們基本上扮演了第 5 種角色:

* 整合資訊流提供者: 包含即時路況播送, 網路搜尋, 以及其他 LBS (location based service) 相關資訊提供給 device, 同時 device 也將最新的資料透過內建的統計資料庫及 trigger 將資料即時 feedback 回資訊提供者.

傳統的 M2M 的資料都在原先建好的系統架構中流動, 跟外界基本上是隔絕的. 但是資訊流提供者的角色, 是將整合不同的資訊流 (政府即時路況/搜尋/車隊特定服務/ Telcom 網路) 不斷的將新的外界資訊 Push/Sync 到 Machine 中, Machine 也把資料回饋給外部系統, 讓 Machine 跟 Machine, 以及 Machine 跟人有新的互動可能性. 這也是目前許多 GPS/LBS 廠商, 想要整合的 "功能". 但是, 其實這是一個整合資訊流的新角色.

現在除了 LBS (location based service) 外開始有另一個新名詞 real-time GPS. 也許以後支援這類動態 + 即時 + 雙向交換資訊的 GPS (PND) 會貼一個 real-time GPS, 然後 powered by T-Mobile (or other Telcom) 也說不定.

Dash Navigation 提供不同的資訊流整合 (即時路況/搜尋引擎/來自各地的訊息) 技術, 透過客戶端 request 或將客製化的資訊 push 到每一台 device. 這個軟體 framework 是獨立在硬體之上的, 所以可以預見 RIM 以後, 有計畫提供這類的 LBS based push 服務 (push LBS?).

舉例來說, 這類服務除了可以幫你找附近哪間加油站便宜, 超商在特價外. 對商用人士的服務甚至可能幫你安排兩個人見面的最適當地點, 提供最有效率的評估, 提供建議, 並完成安排行程所有程序 (booking tickets/make reservations/etc).
Verizon Wireless 跟 Qualcomm 的合資 M2M 是只是朝 MVPN 邁進, 還是會像新的整合資訊流提供者呢?