中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文作者根據(jù)自身項目經(jīng)驗，詳細復盤了商業(yè)云AIoT智能硬件產(chǎn)品項目從0到1的全過程，總結了在項目執(zhí)行過程中所遇到的問題，分享給大家用以參考學習。

寫在前面的話

筆者從2013年開始進入智能家居領域，這些年磕磕碰碰掉了不少坑，一路走來幾乎面對所有要解決的問題都找不到人可以指點，全憑自己交學費。

以前總寄希望能買到一些書籍或者網(wǎng)上資料可以對行業(yè)進行系統(tǒng)講解以獲取入行的門道，買了各種名目的書本，有道筆記上收藏的行業(yè)文章也達數(shù)百篇，到最后發(fā)現(xiàn)這些技能都是別人的 Knowhow，愿意真正把有用知識分享出來的并不多。

所以，一直在思考，互聯(lián)網(wǎng)的精神是什么？不是開放、分享嗎？我們現(xiàn)在取得的成績都是基于前輩的努力成果，如果自己花了如此龐大的精力和金錢代價所解決的問題，又讓后人重來一遍，那么這樣的社會成本付出是無價值的，It doesn’t make any sense.

以前大學期間就經(jīng)常幫老師寫教學課件，在社團也經(jīng)常負責學員授課的工作。把學到的知識分享給別人是一件快樂的事情，故而有此篇口水文章的撰寫。

注意，這篇文章面對的讀者對象并不是缺乏必要大學課本知識的中學生，筆者曾經(jīng)也設想將行業(yè)知識進行徹底講解，但是奈何篇幅實在不夠，如果真的要細化知識點到科普水平，那內(nèi)容厚度差不多要出本書了。

此篇文章的目標是希望能對一個完整涉及到互聯(lián)網(wǎng)產(chǎn)業(yè)上下游的產(chǎn)品進行覆蓋性講解，力爭通過盡量少的文字講明白一個互聯(lián)網(wǎng)產(chǎn)品各領域所涉及到的知識點。

筆者盡量在技術原理、行業(yè)知識、產(chǎn)品設計這三個方面之間做出權衡，不過分偏重技術但又避免表面知識，最基本的，會讓讀者明白未來準備涉及的相應領域要怎么入手。

本文并不攜帶商業(yè)信息，故而隱去了所有涉及公司的真實名稱，限于筆者私人時間及內(nèi)容篇幅，且文筆拙劣，文章不甚完美，錯誤之處歡迎批評指正。

一、項目立項

1.1 客戶背景

客戶來自中國臺灣，希望做一個智能語音機器人，并且?guī)殞氝h程視頻看護功能，對標大陸這邊的智伴機器人和阿爾法蛋。

客戶質(zhì)量方面，其自身積累了大量人脈，與各種渠道商都建立有大量合作，同臺灣的一些酒店連鎖集團也建立有合作關系，而且在敬老院市場也有相關渠道入口，未來銷量保底80K/Year……

客戶掏了開案費。

1.2 需求確認

由于商務合作內(nèi)容方面的關系，客戶最終要求交 Turn-key 的形式，翻譯過來就是：撒手不管但你最好按我腦子里想的要求去做。

經(jīng)多番友好溝通之后，客戶最終還是給了一份需求文檔：“你猜猜我要啥&你看著設計唄.docx”

1.3 自身經(jīng)驗

一般從零開始做一整套互聯(lián)網(wǎng)硬件產(chǎn)品，預期時間大約為一年，但是這次客戶的期望時間是6個月。

作為一個純粹的物聯(lián)網(wǎng)云服務提供商，此前完全沒有硬件及嵌入式開發(fā)經(jīng)驗，突然被要求跑去給客戶做完整套硬件產(chǎn)品的確是不小的挑戰(zhàn)，況且由于公司內(nèi)部項目的安排，只有三個程序猿可供我虐待。

1.4 Get the shit done

雖然公司業(yè)務為云服務，但好在云端系統(tǒng)從一開始就要求為模塊化設計，類似現(xiàn)在流行的中臺，內(nèi)部代號為 CloudMeet 。模塊化的好處是可以選擇組合出各種業(yè)務產(chǎn)品云端服務形態(tài)。

1.5 關鍵性問題

二、工業(yè)設計（ID）

2.1 形象定位

產(chǎn)品定位為智能語音機器人，面對的是兒童教育市場，所以在產(chǎn)品形象上要考慮小朋友的喜好，無非幾種：動物、卡通、人形機器人。

卡通形象沒錢買IP，人形機器人則太直男，最后選定動物形象：狗子。

2.2 產(chǎn)品需求確認

設計方面，找了深圳設計公司A的老王，俗稱王工；

初步面談溝通后，告知了設計師產(chǎn)品立項的背景和目標；然后再提供正式的設計需求文檔給到王工，說明產(chǎn)品的設計定位、形象要求、外觀設計要求等基本要素。

2.3 初步設計稿

在確認需求后，王工開始進行設計，一般工期大概為一周。

常規(guī)的設計公司合作方式，一般是一份設計合同提供三份不同的原型設計，然后讓客戶從中挑選一個作為選定方案。

另外，比較賤的設計公司會讓高水平的設計師設計一份稿件，再讓公司實習生或者初級設計師做兩份 Bullshit 湊數(shù)，從而讓客戶能產(chǎn)生一眼就相中的快感。

總之，設計套路深，多看別當真~

2.4 初次手板

選定了設計方案后，需要再跟王工進一步溝通細化調(diào)整，包括整體尺寸和顏色搭配調(diào)整，細節(jié)調(diào)整完成后，則開始安排制作手板。

手板的意思是驗證模型，將產(chǎn)品的設計純粹用塑料模型制作出來以便確認實際效果。

CNC雕刻加上噴油可以得出非常漂亮的質(zhì)感

這部分進行處理的是手板廠的程工，王工給程工提供設計文件，手板類型選擇了程工說的最漂亮的CNC雕刻。

2.5 直男白+中國紅

手板出來后，跟同事一起左看右看，怎么看怎么好看。

為體現(xiàn)該設計符合市場目標客戶的需求，特意帶著手板去請一個咖啡店的老板娘鑒賞，她有一個六歲的小朋友，典型的目標客戶。

一開場我便激昂而款款地談論產(chǎn)品的設計創(chuàng)意和市場目標，終于在口水多過咖啡的交流過程中得出一個結論：直男設計。

值得反思的是，畢竟連女孩子的手都沒牽過，不能正確理解母嬰市場的產(chǎn)品設計原則應該也是情有可原。

于是再去做功課，研究了市場上兒童智能設備的外觀設計比例、配色特點。人類視覺上對于“萌”的感覺有會一些關鍵特征。

比如：動漫的角色大都具有大眼睛大腦袋短身子，而人類的嬰兒也是類似的特征。

估計不按這種圖紙比例生出來的嬰兒，在遠古時期容易養(yǎng)著養(yǎng)著就被大人撒點孜然烤了，不利于物種繁衍。

2.6 比例調(diào)整

定出新的設計方向后，然后就是麻煩王工再通宵加班修改了。

首先是比例調(diào)整，這次沒有再選CNC，而是選擇了3D打印。

3D打印

對于外觀及顏色的初步驗證來說，這已經(jīng)足夠，關鍵是制作周期要短很多（便宜）。

2.7 顏色調(diào)整

顏色部分遇到了一個問題，就是顏色的具體定義。我們重新選定了淡藍色和淡粉色兩個配色標準，但這兩個描述對于設計師而言，就跟我描述女生的口紅色號一樣：不是姨媽紅就是牛屎綠。

嘗試在網(wǎng)上找色盤去選定色值參數(shù)，而王工進行上色設計后，怎么看都不對。反復折騰了王工之后終于還是辦法比問題多：直接從網(wǎng)上買了一對杯子。

這兩只杯子剛好一粉一藍，而且顏色符合要求，王工直接對著杯子參考。

2.8 關鍵性問題

三、結構設計（MD)

3.1 設計需求

ID設計確認之后，下個階段便是產(chǎn)品內(nèi)部結構設計，這部分找的是深圳另一家設計公司B的劉工。

常規(guī)來說一般ID和MD都會選擇同一家公司設計，一方面合并費用低一些，另一方面減少溝通成本。

不過由于一些原因，我最終將ID和MD設計分開，所以這階段會再次產(chǎn)生設計需求的確認工作。

外觀部分，ID工程師提供設計的渲染圖及對應尺寸標注文件，并注明外觀顏色要求；結構部分，電子工程師提供電子結構空間設計要求文檔，告知所選用的關鍵電子元器件尺寸及散熱、布局和避空要求。

3.2 首次結構設計

因為整體結構比較大，發(fā)揮空間充足，所以首次結構并不需要考慮太多元器件沖突問題。

在ID確定之后，修改MD部分的時候一般由于實際的空間擺放、器件避空等要求，外觀都會有調(diào)整，這部分由于劉工也做過ID，就一并修改了。

結構設計工作完成就可以進行3D打印做手板，用以確認外觀變動、結構實際狀況。一般首次結構實物確認都是體現(xiàn)設計問題，比如螺絲柱遺漏、按鍵骨架脆弱等。

3.3 初版結構確認

在調(diào)整結構設計問題之后，再進行3D打印的手板制作，經(jīng)實物確認即可作為初版的結構定型。

下一步劉工會向電子工程師提供版框圖，電子工程師根據(jù)結構調(diào)整原理圖及元器件選用，進行后續(xù)的電路Layout，電路部分樣品制作完成將與結構進行配合驗證。

3.4 0.618

在第一次拿到電路板正式與外殼手板進行組裝之后，總還是覺得外觀有所欠缺。

改 ！??！

首先是耳朵，感覺上有點偏大，然后按一個毫米的幅度反復調(diào)整了兩三個版本，尾巴也為了卡哇伊縮短為柯基版本。而最麻煩的是身體比例，為了頭部與身體的視覺協(xié)調(diào)，反復拜托劉工進行微調(diào)，以希望頭身比例盡可能逼近黃金分割比。

在劉工電腦旁站久了之后，竟然發(fā)現(xiàn)他的光頭還挺可愛的，不知道他還有頭發(fā)的時候會是什么樣子~

3.5 MIC位置確定

（1）單 MIC

產(chǎn)品的麥克風主要作用的機器人喚醒（類似“喂，Siri”）、AI對講和遠程雙向通話，物理上要考慮拾音、回聲的問題。

一開始結構設計上考慮的是單MIC設計，這種情況下拾音效果最佳的位置是正對用戶，在ID設計初期MIC開孔放在了機器人正面嘴巴的位置。

單MIC位置

（2）MIC 陣列

ID階段制作了手板發(fā)現(xiàn)不大美觀，所以在MD設計時就放在了鈴鐺的位置。感覺美觀問題總算是解決了客戶又提了個小需求：預留雙MIC陣列，提升拾音和回音消除效果。

這個小需求怎么說呢，反正，客戶是上帝。于是跑去咨詢一個音頻算法大牛，彭工。大牛表示要想實現(xiàn)雙MIC陣列，在開孔的物理設計上有嚴格的要求，這會直接關系到拾音的能力、回音消除的效果。

賄賂了兩包黃鶴樓之后，劉工終于又修改了結構，兩個MIC的位置最終被放置在了機器人頂部。

MIC陣列位置

3.6 聲音系統(tǒng)

放音喇叭的設計是一套比較系統(tǒng)的工程，牽涉的部分也比較多，關系到：共振、MIC輸入干涉、放音品質(zhì)、設備重心等一系列考量。

正常來說，為避免SPK放出的聲音影響到MIC的輸入，喇叭在設計要盡量遠離麥克風并且最好呈背對形式。比如360小水滴、螢石C2W兩種智能攝像頭的設計。

（1）SPK位置

單MIC正前方設計時，喇叭在機身后的位置影響不大，因為彼此是背對的。

但雙MIC布局在腦袋頂部之后，就會發(fā)現(xiàn)喇叭和麥克風已經(jīng)不能背對設計了，那么SPK就要考慮盡量遠離MIC。

最開始考慮的是放在機身背部下方，劉工修改了之后看效果圖還是覺得比較丑。再往上擺，處于腦袋正下方，但由于形狀沖突（弧面過?。?，最終只能選擇在腦袋正后方。

（2）SPK選型

在測試聲音播放品質(zhì)過程中，遇到了不少問題。

首先是喇叭的選型，外磁的喇叭價格比較便宜但是重量大，內(nèi)磁的喇叭輕一些但是價格高。

由于喇叭位置在腦袋正后方，重心靠外，所以為盡量平衡產(chǎn)品的重心問題，選用了一個內(nèi)磁喇叭，然而音質(zhì)測試并不理想。

在測試聲音播放品質(zhì)時，發(fā)現(xiàn)不管更換任何測試音頻，都有一種聲音被悶住無法輸出的感覺。

在更換了三四個供應商提供的喇叭還是不滿意之后，直接從阿里巴巴上找了十幾家喇叭廠商，逐一購買了內(nèi)磁、外磁的各型喇叭數(shù)十個。

在各種喇叭快裝滿一抽屜之后，想到了從喇叭開孔問題。因為不管換了多少種喇叭，聲音都處于悶住狀態(tài)，直接把喇叭開孔全部砸開就沒問題，所以只能拜托劉工再從喇叭開孔入手。

（3）開孔設計

在物理上，喇叭的開孔并不是隨意而為之，而是有既定的開孔公式進行換算。一開始我們打算單純增加開孔數(shù)量，但是過多的開孔數(shù)量會導致孔徑變小，這會影響后續(xù)的模具問題。

權衡之下，只能嘗試在小量增加開孔數(shù)量的同時，更改開孔排列形狀，然后把幾個不同形狀的喇叭開孔打了手板進行驗證之后，但仍是差強人意。

這要上升到玄學的范疇了。

從結構設計師、喇叭供應商、電子工程師都已經(jīng)無法理解到底是什么原因?qū)е铝寺曇魺o法出來。看著劉工怨念的眼神，我突然想到為何不能仿造別家產(chǎn)品的喇叭開孔？

于是立即下單買了個小米的米兔，帶著一包玉溪又拜托劉工比對米兔的開孔設計修改了一次——聲音終于是肯出來了，最后為了音質(zhì)，還是選定了一個外磁的喇叭。

（4）后音腔

聲音能出來之后，雖然音質(zhì)滿意，但是洪量度不夠，又雙叒叕請劉工再調(diào)整設計，增加了后音腔。

但手板打出來之后測試發(fā)現(xiàn)沒啥幫助，加上客戶考慮到增加的模具費用，最終并未使用后音腔設計，但預留了裝配空間。

（5）劉工瘋了

魯迅有講，“人類的悲歡并不相通” ，深以為然。

坦白來說，我的確不大知道在修改了26次結構設計之后，劉工心里在想著什么。

在雕刻一件藝術品？正在打造一款東半球最棒的智能機器人？不過看起來當時他手里那把40米的大砍刀似乎是從瑞士買的。

3.7 最終設計

3.8 關鍵性問題

四、模具設計

4.1 設計資料

在結構部分確認之后，劉工將提供ID文件和MD文件給到模具廠的老陳，王工再將外觀設計要求文檔一并給到老陳。

老陳是模具廠的老板，工程出身。雖然是做技術的，但是實際上是個表面人畜無害，內(nèi)心猥瑣巴拉的老實人。一般模具報價、生產(chǎn)報價、工期都是老陳直接給出，

這次項目由于是Turn-key所以模具報價方面需要代客戶溝通。雖然其內(nèi)心猥瑣，但是要在報價上拗過老陳卻不是件容易的事。

羊毛不可能出在豬身上

4.2 砍價

制造業(yè)這行做的多半是酒桌生意，但老陳一向不喜歡應酬，他覺得畢竟請客戶吃飯最終也是羊毛出在羊身上，不實在。

我也不喜歡應酬吃喝，一方面畢業(yè)幾年因為工作的緣故胖成了工傷，另一方面由于家族遺傳缺乏乙醇分解酶，基本三瓶青島就會倒。

但這次老陳帶了個業(yè)務妹子一起吃飯。

一陣酒桌公式化寒暄客套之后，

我便掉入了陷阱——光顧著跟模具廠老板聊人生談理想不知不覺就喝掉了12罐百威。

推杯換盞之后老陳長什么樣已不大記得，代駕回來在平巒山腳的社區(qū)醫(yī)院門口地板直接就躺下了。

睡不著，滾不動，光想著漂亮女鬼。

直到一個多小時后，被Talan叉起了身子，鍍著月光回去。

4.3 開模

三天后老陳的報價少了四萬塊，這邊千恩萬謝兄弟兄弟之后，便是付款開模。

一般開模時間取決于模具復雜度和大小，這次包括購買鋼材和設計模具在內(nèi)時間大約在45天。

這玩意大概長成下面這樣：

4.4 試模

模具制作完成，模具廠會先購買原料通過注塑機（啤機）試產(chǎn)小數(shù)量成品進行驗證，包括外觀、結構、顏色相關問題。

（1）觸控鍵

機器人頭頂設計有一個觸控按鍵，這個按鍵需要通過銅皮利用電容效應進行觸發(fā)，為避免電路觸發(fā)不夠靈敏，所以在銅皮貼合位置的殼子部分進行了減膠做薄處理。

由于在殼子上挖了個正方形的矩形坑，導致生產(chǎn)時帶來了縮水的問題，最后解決的辦法是將矩形坑做圓角處理，減輕注膠冷卻時各區(qū)域收縮不一致問題。

（2）電池倉

機器人支持電池使用模式，為追求終端用戶體驗設計選用了兩顆18650電池組，就是特斯拉上的那種。

這種類型鋰電池有較好的穩(wěn)定性，但是缺點是偏重。固定電池的電池倉一開始設計的是兩條腿固定，但是實際組裝后進行摔落測試發(fā)現(xiàn)很容易出現(xiàn)斷腿事件，討論之后只能增加腿的數(shù)量到四條，改結構。

（3）耳朵硬度

耳朵一開始為了小朋友摸起來舒服，將硬度設計得很低，這使得耳朵稍微使勁一拽就掉了。

讓模廠調(diào)整材料，變成硬質(zhì)形式，又導致機器人很不扛摔，多次修改嘗試之后，最終選定了一個材料硬度系數(shù)在保證不被摳出來的同時又讓耳朵盡量柔軟。

（4）顏色校正

外觀顏色方面，雖然ID給了詳細的數(shù)值，但是實際生產(chǎn)出來的效果仍然還是有細微差距，因為色粉的值并不是完全跟計算機圖示效果一致，所以最終把王工手里的兩個杯子給拿到了模廠進行比對配色。

4.5 定型

（1）簽樣

再多次試模之后，便最終確定模具的設計及生產(chǎn)要求，外殼部分模具廠生產(chǎn)工程師陳小姐，會出具一份紙質(zhì)承認書及對應殼子樣品，進行簽字。

（2）驗收標準

而生產(chǎn)部分，我這邊會根據(jù)討論，出具一份成品驗收標準書給到品質(zhì)工程師李工，由模具廠、組裝工廠、客戶（PM）三方進行確認，其中關鍵的部分是外觀檢查標準卡。

因為外殼越大，產(chǎn)生色點和污染的概率越大，外觀檢查卡用以測定外觀污點的尺寸，需要指定一個多方可接受的標準。

五、硬件開發(fā)

5.1 規(guī)格確認

電子部分由東莞一家OEM廠進行配合，電路設計交由該廠的張工負責。

張工是河南人，每次看到網(wǎng)上有井蓋出現(xiàn)他都要義憤填膺一番，天天把戒煙戒酒掛在嘴邊，但身體從來都很誠實。

在張工開始設計之前，我需要先編寫產(chǎn)品電子規(guī)格文檔交給張工，除了產(chǎn)品的功能描述和市場定位，還包括攝像頭參數(shù)、點陣參數(shù)、電池容量、耳朵顏色等。

5.2 設計資料確認

產(chǎn)品電子規(guī)格確認之后，需要組織CPU原廠、嵌入式工程師、電子設計工程師進行討論，原廠的工程師會告知嵌入式系統(tǒng)的一些特性及電路設計上的要求。

工程師之間的溝通往往比較質(zhì)樸，悶頭講完畫幾個白板就是各自留郵箱和微信了，該階段原廠這邊會將電路設計用到的芯片資料和原理圖資料發(fā)出來。

5.3 EVT階段

Engineering Verification Test，該階段設計純粹驗證電路原理設計及Layout的設計。

（1）硬件設計

張工拿到原廠給的資料首先會進行的是電路原理設計。

該階段硬件第一步目標首先要進行驗證性研發(fā)，既完整產(chǎn)品涉及到的所有硬件功能節(jié)點都設計到一塊電路板上，主要用于原理設計及元器件選型的可行性驗證。

原理圖設計完成張工會將設計文件發(fā)回給原廠，原廠的硬件工程師Evans會進行原理圖的設計review，以保證張工的原理設計是符合芯片技術要求。

原理圖修正并確認后，既可進行PCB Layout設計，將元器件布局到電路上。

（2）洗板

所有設計經(jīng)過確認之后，便可以交由洗板廠進行PCB洗板，洗板所花費的時間會受到PCB層數(shù)的影響，比如從二層板、四層板、六層板所需要的洗板時間會以此增加，費用也會更貴，當然對于硬件性能來說也會更好些。

（3）SMT

PCB洗板完成，物料備齊之后便是上機貼片（SMT）。

SMT是表面貼裝技術Surface Mounted Technology的縮寫，SMT貼片指的是在PCB基礎上進行加工的系列工藝流程的簡稱。

電路板通過鋼網(wǎng)刷上錫膏之后，由高速貼片機(SMT)將相應元器件貼合至電路板上，該步驟得出的結果便是PCBA。

這是機器的樣子

（4）組裝

將外圍器件，比如MIC、SPK、電池等相關器件，通過相應電子連線串接至PCBA上，便可得到一個完整的硬件設備，由于處于EVT階段，硬件設計與結構無相關性，所以這里組裝并不涉及外殼。

（5）測試

該階段硬件測試主要是電路的工作測試，比如上電之后CPU是否能正常點亮，各種模塊的電流、電壓是否正確等等。對于問題的修正，一般用飛線的形式進行操作驗證。

所有的元器件都集合到一個板子

5.4 DVT階段

Design Verification Test，該階段修正EVT階段的電路原理設計，并根據(jù)外殼結構進行Layout驗證。

（1）設計

在EVT階段驗證通過之后，便可以進行下一階段的DVT設計。

張工根據(jù)EVT的測試結果，重新修正原理圖設計并發(fā)給原廠review，并根據(jù)從設計公司B的劉工那給出的結構版框圖重新進行l(wèi)ayout，將元器件按正式的外殼結構進行布局。

（2）結構驗證

該階段板子洗完并貼片后，即可與初版的外殼手板進行匹配驗證。包括電路板與螺絲柱契合是否正確，結構與板型對于生產(chǎn)方面的簡易程度、抗摔性等。外殼結構及電路布局設計都會進行微調(diào)以實現(xiàn)兩者鍥合度最佳化。

（3）軟硬件功能配合開發(fā)

電路設計的經(jīng)過EVT的驗證，在DVT階段修改了layout之后，則開始配合嵌入式、單片機程序進行驗證。

單片機、嵌入式程度，對于電路硬件的驗證會進行反復調(diào)整修正，以確定硬件設計是符合軟件要求。同時OEM工廠會與天線工廠完成天線的位置測定。

這個階段是整個項目開發(fā)的主要工作，基本會占到整個項目開發(fā)時間的65%，硬件、嵌入式、單片機會在這個階段完成到可試產(chǎn)狀態(tài)。

5.5 NCC認證

（1）目的

類似于大陸市場的消費類電子產(chǎn)品需要做3C認證，臺灣市場的監(jiān)管要求電子產(chǎn)品需要做NCC認證。

對于本產(chǎn)品的認證測試包括：

A.大于1GHz高頻的EMC測試，主要是WiFi模塊。

B.低于1GHz低頻的EMC測試，其他普通元器件。

C.傳導發(fā)射（Conducted Emission）測試， 通常也會被稱為騷擾電壓測試，主要是測試連接適配器時對供電系統(tǒng)的影響。

D.靜電測試

（2）高頻EMC

這里的高頻是指大于1GHz的電磁輻射測試，設備中主要是WiFi模塊會涉及這個部分測試。

A. WiFi定頻

在開始之前首先要對WiFi模塊進行定頻。這個部分是由WiFi模組廠進行協(xié)助處理，負責對接的是彭工。

我們將完整設備帶到實驗室，彭工首先進行WiFi功率測定，將模塊的工作功率設定至合理水平，然后將WiFi工作頻率和通道進行限定測試，通過之后會給出相應的操作指令文檔。

B.輻射測試

這個部分我們找了深圳的一家測試實驗室A，對方的測試工程師是個萌妹子，但她強烈要求我稱她為溫大俠。

設備的輻射測試需要將設備放到一個巨大的屏蔽房，然后將設備調(diào)整到正常運行狀態(tài)，再測定各頻率波段的輻射情況。

屏蔽房

由于電路在設計之初就考慮到了過認證測試的情況，所以預留了相應設計用于進行屏蔽修改，對于需要增加屏蔽的部分焊上相應參數(shù)的磁珠即可。

過程不大順利，雖然焊磁珠解決了部分問題，但是測試幾次都仍然有不能通過的部分。而WiFi的定頻測試比較順利，設定幾個頻率接入測試設備后都通過了。

（3）低頻EMC

在測試實驗室A多次修改之后，低頻部分都測試不過，需要進行詳細的整改?？紤]到每個小時高達700軟妹幣的整改費用，于是我們靠友誼的友誼的友誼找到了另一家測試實驗室B。

測試實驗室B

靠臉皮的關系拜托了梁工加班整改，在嘗試了調(diào)整攝像頭驅(qū)動等級，給電路板增加磁珠，給連接線增加磁環(huán)等各種方式后，對輻射波形進行讀點操作終于符合了認證要求。

（4）傳導發(fā)射

傳導發(fā)射（Conducted Emission）測試，通常也會被稱為騷擾電壓測試，主要是測試連接適配器時對供電系統(tǒng)的影響。這部分也是在測試實驗室A完成的，相對比較走運測試一次既通過了。

（5）靜電測試（ESD）

Electro-Static discharge，在用戶操作設備的過程中，有可能會因為自身的靜電而擊傷電路元器件，所以還需要對設備進行靜電測試并作出整改以符合標準。

（6）領證

在所有的測試都通過之后，實驗室A、實驗室B都會分別出具相應的整改報告給到OEM廠，由張工根據(jù)整改報告將設備進行整改之后，便可以將設備寄送至臺灣NCC認證機構進行測試審核，通過之后便可頒發(fā)相應證書。

5.6 PVT

在DVT及NCC通過之后，便可以進行試產(chǎn)。

Process Verification Test，該階段的目的：一方面是開始向客戶交付測試樣機檢驗功能及穩(wěn)定性，一方面是開始為批量生產(chǎn)的流程確定標準。

（1）簽樣

在NCC整改確認之后，量產(chǎn)之前OEM廠首先會要求在生產(chǎn)之前進行電路板的簽樣，以確定原理設計、layout、BOM符合客戶要求。

客戶簽字既鎖定版本，OEM廠將以簽樣標準進行后續(xù)生產(chǎn)，如果由于市場原因需要更換物料，則要通知客戶確認并重新進行測試簽樣。該部分簽樣由OEM廠的生產(chǎn)工程師李工負責對接。

（2）最終設計

5.7 關鍵性問題

六、嵌入式系統(tǒng)

6.1 需求確認

在確認完硬件完整規(guī)格后，我這邊還需要設計一份系統(tǒng)功能規(guī)格文檔，用來給嵌入式開發(fā)的Danny和單片機開發(fā)的Talan，并且需要開個小會面談功能以確認功能的理解。

6.2 原廠SDK驗證

從CPU原廠會拿到三樣資料：SDK文件、開發(fā)資料文檔、evb開發(fā)板。

為確保后續(xù)開發(fā)不引入已知問題，Danny首先在開發(fā)板上進行SDK的功能驗證，以確保原廠的SDK能正確工作。

6.3 協(xié)議及規(guī)格定制

在正式開發(fā)之前，與開發(fā)確認完系統(tǒng)功能規(guī)格后，為減輕開發(fā)的工作量，我還需要定制通信的報文協(xié)議及表情、提示音內(nèi)容。

（1）設備與APP交互指令

該協(xié)議用于設備和APP之間進行交互控制，比如查看電量、控制靜音等等。

CloudMeet平臺本身支持為各種類型的設備提供服務，此前為方便各種廠商設備接入我已經(jīng)定制了一個通用的協(xié)議表，而機器人由于是新增設備，所以還需要增加一些協(xié)議，比如兒童鎖、睡眠之類的控制。

協(xié)議內(nèi)容采用JSON格式，支持 HTTP 和 TCP 兩種通信類型。

（2）單片機與SoC交互協(xié)議

SoC處理的功能與單片機不同，所以兩者之間也需要進行通信交互。

由于兩者走的是 UART串口，所以需要自己定義協(xié)議。這里我們基于16進制定義了報文頭和數(shù)據(jù)段及報文長度。

（3）表情規(guī)格書

設備的表情由兩組8×8 LED陣列進行控制，由 0/1 定義每顆LED燈的亮滅，再逐列進行點亮控制。

由于表情的IC連接在單片機的引腳上，所以表情的執(zhí)行都通過單片機，我需要將表情的二進制數(shù)據(jù)設計出來并轉(zhuǎn)化為單片機可執(zhí)行的16進制數(shù)組。

編號：ID 001 ；含義：笑臉；場景：功能規(guī)格書指定；方式：逐列掃描

（4）提示音規(guī)格書

機器人的各項操作都會伴隨一些提示音，而這些提示音的編號及音頻內(nèi)容都要定義清楚，并由系統(tǒng)功能規(guī)格文檔指定調(diào)用場景。

6.4 嵌入式開發(fā)

嵌入式開發(fā)部分主要是基于Embedded Linux做開發(fā)，一些需求快速啟動的產(chǎn)品則多半基于RTOS系統(tǒng)，前者是分時操作系統(tǒng)，后者是實時操作系統(tǒng)。

RTOS硬件資源占比小很多，但是開發(fā)上限制也很多。Embedded Linux資源占比較大，但是開發(fā)難度要低許多，該部分由Danny開發(fā)為主。

在正式開發(fā)之前Danny會先編寫嵌入式功能設計技術文檔，用以定義嵌入式的技術內(nèi)容，以便未來其他人維護及開發(fā)，這會比代碼寫注釋還要重要。

（1）聯(lián)網(wǎng)模塊

該模塊主要是解決設備的配網(wǎng)功能，首先通過APP將配網(wǎng)用的WiFi信息生成二維碼，然后設備端調(diào)用攝像頭采集圖像并將二維碼解碼得出對應的WiFi信息。聯(lián)網(wǎng)程序得到相關WiFi資料后執(zhí)行聯(lián)網(wǎng)操作，成功之后再將認證信息提交至CloudMeet系統(tǒng)。

（2）回音消除

回音消除功能(Acoustic Echo Cancellation,AEC)，作用是避免喇叭播放出來的聲音又經(jīng)過麥克風錄制到系統(tǒng)，形成回聲。該功能模塊需要電路設計配合，即硬回采設計。

Codec模塊將聲音采集電路傳入的音頻提交到系統(tǒng)，系統(tǒng)再通過相應的AEC算法進行回聲消除，從而得到單一的原始播放聲音。這部分由SoC原廠的Kason配合算法部分開發(fā)。

（3）喚醒模塊

喚醒，也叫做“熱詞”，類似iPhone“喂，Siri”。這個用以設備待機時喚醒設備或者設備執(zhí)行其他動作時進行打斷。

程序首選會進行VAD監(jiān)測，發(fā)現(xiàn)有說話聲音后再進入通過ASR進行熱詞識別，比如模型設定的是“啊貓啊貓”，你叫“啊狗啊狗”設備就不會鳥你。熱詞喚醒之后才會提交到云端AI進行處理。

（4）NLP模塊

AI模塊主要是自然語言處理，既NLP。在熱詞喚醒之后將用戶輸入音頻提交至AI云端，進行語音識別，云端再回復相關內(nèi)容至設備或執(zhí)行相應動作。

（5）點播模塊

點播模塊的作用是用戶從APP端H5頁面點播內(nèi)容時，經(jīng)由CM IoT服務推送至設備端進行播放。

（6）播放模塊

設備所有的聲音、音頻內(nèi)容都是由播放模塊進行處理。由于客戶要求較高，需要設備直接播放YouTube連接內(nèi)容，Danny這邊直接用FFmpeg移植到設備端，并進行二次開發(fā)。

（7）音視頻模塊

視頻通話這塊，因為之前在PC和移動端做過Webrtc，所以一開始曾經(jīng)考慮將Webrtc移植到嵌入式端。多番討論后覺得移植成本過大，最終選擇了使用P2P通信，走的是RTSP協(xié)議。

（8）云存儲模塊

產(chǎn)品的定位是兒童智能教育+家長看護，所以帶有攝像頭功能。而CloudMeet本身具有視頻云存儲服務，所以一開始我們根據(jù)需求給客戶開發(fā)了視頻云存儲功能，走RTMP協(xié)議。

BUT，測試通過后客戶想想不對勁，一個兒童故事機為啥需要云存儲功能？最后還是取消了，對此Danny只是嘴角微微上揚了一下……

（9）智能控制

用以控制IoT設備，比如用戶喚醒設備后，說出指令：幫我打開窗簾。則機器人會自動發(fā)出指令讓窗簾自動打開。

（10）按鍵模塊

設備的按鍵部分由于涉及到電路的控制，由Talan進行處理，從驅(qū)動層捕獲到按鍵事件后直接通知Danny的應用層進行處理。

（11）OTA模塊

OTA則是系統(tǒng)固件更新，這個要麻煩不少。根據(jù)我之前設定的交互指令，需要先App先從CloudMeet OTA服務處查詢可用更新，再將更新信息和指令發(fā)送至設備端，設備端驗證通過后再將固件下載到設備端，設備再重新系統(tǒng)進入內(nèi)存模式進行更新系統(tǒng)。

6.5 單片機(MCU)開發(fā)

單片機相對SoC要低階很多，但是好處是便宜還能待機，所以一些開關操作都會交給單片機進行處理。這個部分由Talan負責，同時開始之前會先編寫一份單片機設計技術文檔。

（1）開關機控制

為了美觀，設備開關機按鍵沒有使用早期設計的直接控制通斷的分立元件，既撥動開關形式，而通過單片機監(jiān)控。

也就是：關機模式時，用戶長按Power鍵，觸發(fā)單片機監(jiān)測進入計時器，到達預定時長后控制電源模塊給SoC上電，Linux系統(tǒng)進行啟動，反之亦然。

機器人開關

（2）電池管理

電池的充放電管理由硬件控制，但是電流檢測及充電狀態(tài)則由單片機執(zhí)行，再將結果通信給SoC。

（3）表情模塊

根據(jù)系統(tǒng)功能規(guī)格書，具體到每個行為都會有對應的一個表情，這些表情都通過表情規(guī)格書進行編碼。

6.6 測試文檔

功能開發(fā)完成后，需要根據(jù)功能規(guī)格文檔編寫測試文檔進行測試。測試方式是按照一般的操作流程寫出預期的正確結果和錯誤結果，然后完成跑一遍文檔的流程以驗證測試結果是否符合功能設計預期。

6.7 關鍵性問題

七、云端系統(tǒng)

7.1 CloudMeet

本云端系統(tǒng)在設計的定位上是一種模塊化設計，類似現(xiàn)在流行的中臺設計。該種設計的特點是：所有的模塊都是解耦的，而選用不同功能模塊則可以組成不同的云端服務能力。

對于智能機器人產(chǎn)品而言，則是從CloudMeet的模塊中挑選出需要的服務，部分欠缺的細節(jié)功能再補充開發(fā)即可。機器人新增的服務功能部分由Jack負責，流程依然是先提供需求文檔然后開發(fā)，最后測試驗收。

7.2 AI系統(tǒng)

一個完整的AI對話系統(tǒng)大致包含四大模塊：ASR、STT、NLP、TTS。

（1）ASR（Automatic Speech Recognition）

語音識別，一般簡稱ASR，其作用是將聲音轉(zhuǎn)換為文字的過程。對于機器人而言，語音識別的主要應用方式是遠場語音識別（Farfield Voice Recognition），這里我們選用了蘇州的一家語音服務商，這部分由蘇州的語音服務廠商劉工配合，該服務包含兩個主要模塊。

1）語音激活檢測（VAD）

Voice Active Detection，主要作用是在麥克風持續(xù)工作并輸入音頻的過程中，檢測何時才是發(fā)生有效的聲音輸入，識別并消除長時間的靜音期。

2）語音喚醒（KWS）

Keyword Spotting，當輸入的聲音經(jīng)過VAD處理后，進行語音識別。該識別會判斷是否包含用戶輸入的語音中是否包含關鍵字，該關鍵字可認為是機器人設備的“名字”，例如iPhone的“Siri”、亞馬遜Echo的“Alexa”等。如果檢測語音中包含該關鍵字，則將設備喚醒。

（2）STT( Speech to Text)

語音識別的一種應用類型，將音頻轉(zhuǎn)換成文字。這部分我們?nèi)匀贿x用了蘇州的服務商。

（3）NLP(Natural Language Processing)

自然語音處理，通俗的解釋就是理解用戶到底在說什么。

用戶輸入的語音通過STT識別為文字時，系統(tǒng)是無法理解內(nèi)容闡述的是什么，需要進行語義理解，分析出對話所要表達的內(nèi)容，然后才能安排下一步的回應動作，比如問答形式回復用戶，或者是指令相關控制性指令。

因為目標是臺灣市場，所以我們選擇了一家臺灣的AI服務商，這部分由臺灣的AI服務商Nick配合。

（4）TTS（Text to Speech）

在NLP系統(tǒng)理解了用戶的對話后，需要作出對話回復，該回復一般是即時文字內(nèi)容生成，對于設備端而言需要播放的是音頻，所以需要預先將回復的內(nèi)容轉(zhuǎn)換為音頻再進行進行播放。

一開始用的也是跟STT相同的蘇州服務商，但是對方不具備臺灣腔的語調(diào)。最后我們選用了KDXF的TTS服務，以實現(xiàn)臺灣腔調(diào)的音頻。

（5）完整時序圖

7.3 AIoT系統(tǒng)

客戶的訴求之一是需要通過語音交互實現(xiàn)物聯(lián)網(wǎng)設備的控制，由于我們之前就有IoT的服務，所以在系統(tǒng)設計上并無太多難度。

最終實現(xiàn)的場景為：用戶通過語音給設備下指令，設備將語音提交至AI系統(tǒng)處理，解析出用戶操作指令后調(diào)用CM的IoT服務，再由MQTT協(xié)議推送至物理設備端以實現(xiàn)交互控制。

比如用戶喚醒設備后，下達語音指令：幫我打開電視。機器人收到指令后將命令提交到云端，然后再通過云端控制打開電視機。

7.4 關鍵性問題

八、APP客戶端

8.1 UI設計需求

（1）功能需求文檔

與Jennifer的溝通界面首先要提供一個功能需求文檔，并告知產(chǎn)品的市場定位、目標受眾、同類型產(chǎn)品參考等。

（2）原型設計

根據(jù)設計師配合的形式各異，有些設計師僅處理UI部分，不做UX部分設計，這種情況需要PM提供原型設計，我一般會用Axure。

由于項目工期緊張，為節(jié)約時間這里Jennifer會囊括UX的設計，所以這次我并不需要再提供原型。

8.2 交互要求

交互部分我一般會有兩個基本的設計要求，分別是目標路徑、目標成本。

（1）目標路徑

所謂目標路徑既用戶到達其目標的路徑。舉個例子，對比微信在iOS和原生Android兩個系統(tǒng)下啟用微信“位置權限”的設定的典型操作。

工程師思維與用戶交互思維往往會相左。工程師會希望保證工程（功能）的整潔性而傾向?qū)δ苣K進行收納、歸類、分組，但是這會導致用戶操作的目標路徑變深變長。

而用戶永遠追求“一眼就看到”的使用需求，操作路徑越短越好，但是這對交互設計而言又會使得功能模塊過度扁平化形成層次邏輯混亂的焦慮。

但就交互設計的目標而言，永遠都是盡可能縮短目標路徑。

（2）目標成本

所謂目標成本，是指在用戶在目標路徑上操作時間成本的數(shù)學期望。

做個假設：微信在未來除了提供普通群聊，還提供更高一級的高級群聊，則目標路徑深度分別如下：

我們假定微信所有的群創(chuàng)建類型都符合冪律分布，選取普通群:高級群=8:2，微信的每一步操作成本計量值為10，則得出目標成本計算公式：

由此可見在不同的設計情況下，應用到用戶實際場景中會帶來不同的目標成本預期。

所以在設計上，我們希望通過改變用戶的交互形式來使得這個成本盡量變小。

8.3 APP配色風格

（1）暖色調(diào)

由于產(chǎn)品的目標人群是兒童，而APP的目標人群是父母，所以APP的配色風格一開始優(yōu)先考慮的是暖色調(diào)。

我們參考MIUI的設計情景，為了追求暖色調(diào)而大量使用橙色、黃色、紅色這些配色，用戶初期視覺接觸感很好，用久了之后卻會形成視覺壓力從而造成使用者的視覺疲勞。

（2）安全色

如果花點時間去研究下，我們會發(fā)現(xiàn)Facebook、WhatsApp、支付寶、App Store、餓了么、Safari，這些巨型應用的ICON或界面主色調(diào)多為藍色/淡藍色。而根據(jù)調(diào)查數(shù)據(jù)顯示，大多數(shù)人都喜歡藍色。在全球范圍內(nèi)來講，藍色也是最安全的顏色。

8.4 視覺稿件

在確認完設計的相關要求并溝通清楚功能需求后，Jennifer便可開始進行設計。

初版設計完成后會先輸出視覺稿件，用以確認功能、配色、交互上是符合預期的。

8.5 UI FLOW

視覺稿件經(jīng)多次修改確認后，在正式輸出設計文件之前，先要輸出UI FLOW，這是一個完整的交互流程圖，除了部分細節(jié)彈窗提示，絕大部分的界面跳轉(zhuǎn)都會體現(xiàn)出來。

該設計的輸出一方面方便設計師自我檢查，也方便PM進行二次交互設計確認，最后也需要給到工程師以便于了解完整設計。

8.6 UI文件輸出

（1）標注文件

在正式切圖輸出之前，需要對界面設計進行標注，包括元素的寬高、色值、字體等。

（2）切圖文件

根據(jù)Android系統(tǒng)、iOS系統(tǒng)的規(guī)格要求，切圖并輸出對應分辨率要求的設計元素圖片。

8.7 App功能需求確認

（1）需求可行性確認

在功能需求文檔設計完畢，首先會跟APP開發(fā)討論，Jack和Talan會根據(jù)功能需求，告知功能是否可實現(xiàn)及實現(xiàn)的成本。

PM需要再進行功能取舍，一個被揍比較少的PM，都會盡量少提“APP主題顏色要跟隨手機殼顏色變化”之類的需求。

（2）設計可行性確認

正所謂“UI動動手，RD跑斷腿”，設計師很多時候會為了追求交互、視覺體驗，設計各種酷炫的交互效果，而不顧開發(fā)成本。

PM就需要在UI和RD之間的訴求做權衡。所以在跟UI討論設計方向的初期，就會把UI的設計設想反饋給RD進行可行性確認。

（3）功能規(guī)格

需求及設計可行性確認后，將功能需求細化為規(guī)格文檔，定義出輸入邊界、操作粒度等細節(jié)。

8.8 開發(fā)

正式開發(fā)之前先由Jack編寫APP功能設計技術文檔，文檔用以描述技術開發(fā)內(nèi)容定義，用以iOS和Android進行規(guī)格統(tǒng)一。

（1）賬戶系統(tǒng)

用戶用以注冊登錄賬號的功能，一開始給客戶提供了全球手機號+郵件地址的賬號體系，不過后面客戶去掉了郵件地址。

（2）點播功能

該功能具體是在APP嵌套一個H5頁面，該頁面由AI服務商提供，主要是媒體內(nèi)容，故事、英語、兒歌之類。點擊之后由AI服務商的內(nèi)容服務端向CloudMeet服務端發(fā)起請求然后推送至設備進行播放。

（3）看護功能

該功能既是視頻監(jiān)控功能，叫做baby monitor。用戶可在APP上遠程查看設備的攝像頭內(nèi)容，并且支持雙向音頻對講。

（4）設備管理

該功能包括設備配網(wǎng)、添加設備、設備分享、遠程控制、OTA升級等功能。

（5）群聊功能

由于機器人具有家庭看護的功能，所以客戶要求有一個設備與多個APP端群聊的功能，方便孩子與父母親進行對話。這部分實際上是IM的功能，消息要支持音頻和文字兩種。

APP端發(fā)出的文字消息則需要經(jīng)過TTS進行轉(zhuǎn)換才發(fā)送至設備。因為以前開發(fā)設計過社交軟件，這部分并未使用第三方IM服務商，直接由CloudMeet服務解決。

（6）個人設置

個人設置包括一些個人昵稱、賬號等相關信息。

（7）撥打電話

如果APP端的用戶設置了昵稱，比如“爸爸”，則機器人被語音呼叫“打電話給爸爸”時，APP端會響起來電，點擊接聽即可實現(xiàn)APP與設備視頻端通話。

8.9 測試

APP開發(fā)完整需要編寫APP測試文檔，測試驗證功能開發(fā)是否正確符合設計需求。在APP上架之前，Android通過APK包形式進行安裝測試，iOS則通過TestFlight進行測試。

8.10 上架

App Store的上架比較麻煩，提交上架時需要同時準備賬號和設備，以便審核人員進行遠程測試驗證。Google Play 的上架則要容易一些。

而國內(nèi)的Android市場則需要在上架時提交軟件著作權登記證書，這需要提前40天左右準備好。

8.11 關鍵性問題

九、官網(wǎng)&控制臺

9.1 官網(wǎng)

客戶的官網(wǎng)比較簡單，一個WEB前端頁面，包含大屏banner輪播、產(chǎn)品簡介等基本內(nèi)容，并無發(fā)布新聞、登錄操作等相關后端開發(fā)。

（1）需求確認

首先跟客戶確認要展示的內(nèi)容，希望的設計以及對應的文字內(nèi)容及風格確認等。

（2）UI設計

將客戶需求整理并告知Jennifer，然后進行設計切圖。

（3）開發(fā)

由于頁面簡單，得到切圖文件后，Jack使用Bootstrap框架簡單為客戶開發(fā)了一個官網(wǎng)。需要特別聲明的是，logo和banner并不屬于我的品位。

9.2 控制臺

（1）SN號管理

SN號為設備的唯一標示，作為云端服務器識別設備身份是否合法的關鍵信息，CloudMeet后臺提供了該管理功能，包括新SN號導入、刪除等。

（2）設備追蹤

客戶通過不同的渠道銷售的設備都希望得到跟蹤，所以需要一個設備激活、有效狀態(tài)、渠道信息等的管理界面，這個也包含在CloudMeet的服務之中，所以客戶直接使用即可。

（3）OTA升級

設備端的固件升級需要經(jīng)過OTA系統(tǒng)，由客戶掌控升級的進度及版本管理，該功能也在CloudMeet服務中提供。

（4）界面內(nèi)容

9.3 Line官方賬號

類似中國大陸的企業(yè)公眾號和服務號，中國臺灣地區(qū)主要使用的Line社交軟件也具備類似的服務，叫做官方賬號2.0。我們?yōu)榭蛻粼O計了以下功能：

（1）賬戶綁定

通過關注Line官方賬號，可綁定自身賬戶。

（2）自動應答

Line的官方賬號有聊天機器人功能，在開發(fā)者后臺預設相應的關鍵字及回復內(nèi)容及可自動回復用戶的信息，這主要是一些產(chǎn)品信息的基本問答。

（3）消息推送

在Line上叫做推播功能，當機器人端呼叫某一APP用戶時，除了APP會彈出來電界面，Line官方賬號也會提送相關消息給用戶。

9.4 關鍵性問題

十、工廠生產(chǎn)

10.1 包裝設計

（1）緩沖結構

對于設備的內(nèi)部緩沖結構，一開始考慮的是珍珠棉，這玩意對于偏大型產(chǎn)品的保護效果好，又比較美觀，但是找了好幾個廠商后發(fā)現(xiàn)價格過高。

又考慮過換成瓦楞盒，但是在樣品測試摔落時表現(xiàn)不好，長得也比較廉價，再三考慮錢包問題，最后選用了吸塑。

首先要將完整設備提供給材料廠商李工，用以評估產(chǎn)品重量并進行進行抄數(shù)。

抄數(shù)的意思是對設備整個外形的尺寸數(shù)據(jù)進行測量，然后根據(jù)該參數(shù)進行制作對應的吸塑模具。

（2）彩盒

外包裝彩盒的設計比較簡單，我這邊先跟客戶Mic討論他的想法，然后Jennifer提供相應的設計圖形。

最后整理資料，包括圖形文件、顏色及四面排版要求，印刷廠的黃小姐即可將元素按照吸塑的外形重新排版設計。

（3）說明書

說明書稍麻煩點，印刷廠黃小姐明確表示，說明書如果找他們做只包印刷不包設計。所以這邊找了一直兼職配合我做文案的Jensen，客戶Mic先提供相關說明書內(nèi)容，我這邊準備App截圖，然后請Jensen設計為PPT然后再交由黃小姐。

（4）組裝說明文檔

緩沖結構、彩盒、說明書都確認之后，我這邊會出具一份外包裝組裝說明文檔給到工廠，產(chǎn)線將按照該標準進行最后的組裝。

10.2 外殼

生產(chǎn)訂單下給模具廠，排期大約兩周可以交付。由模廠的品質(zhì)總監(jiān)李工按照驗收標準文檔進行質(zhì)量檢查，符合標準之后運送至OEM廠。OEM廠這邊由品質(zhì)工程師何工進行驗收，符合標準之后完成驗收并安排給產(chǎn)線生產(chǎn)工程師李工。

10.3 SMT

Layout完成的電路設計會交由洗板工廠洗出印刷電路板（PCB），然后進行元器件貼片（SMT）得到PCBA，再將外圍元器件（喇叭、電池等）與外殼進行組裝后得到完整產(chǎn)品。

10.4 PCBA產(chǎn)測

PCB進行貼片后，由于是批量生產(chǎn)，除了工廠自身的通電測試，還需要進行PCBA的批量測試。

這個部分由于涉及到硬件端口的讀寫控制，所以由Talan與OEM廠的張工進行討論后，編寫相應測試程序并提供操作文檔給到OEM廠的黃工，黃工的責任為生產(chǎn)測試。

黃工會在PCBA組裝好之后單純將板子聯(lián)通到一起，然后通過測試程序自動逐一測試對應功能，如果有測試不通過則給出錯誤提示。

10.5 裝配

在PCBA完成測試之后，硬件交由組裝產(chǎn)線進行PCBA+輔料+外殼的整體裝配工序。

這階段工廠會由生產(chǎn)工程師制作并打印裝配指導手冊，告知產(chǎn)線工人按照什么標準進行產(chǎn)品的組裝。

10.6 整機測試

設備組裝完畢，進入到整機批量測試工序。由Danny與OEM廠的張工進行討論后，將系統(tǒng)應用功能做成一個自動化執(zhí)行的程序，并提供相應的操作文檔，由OEM廠的黃工安排工人按照自動測試流程對整機進行測試。

同時測試通過之后，進入設備信息燒錄，Danny提供燒錄程序讓產(chǎn)線工人將設備的SN號自動燒錄到設備中，完成生產(chǎn)工作。

10.7 成品質(zhì)檢

在成品按照相應標準組裝完成之后，由OEM廠何工先安排工人先進行內(nèi)部抽檢，通過之后再交由客戶（我）進行檢查，PVT首次試產(chǎn)都要進行全檢，后續(xù)生產(chǎn)則進行抽樣檢查，不良率一般可接受標準為 <3%。

10.8 關鍵性問題

十一、項目成果

11.1 項目協(xié)調(diào)

由于整個項目涉及第三方合作商非常多，并且分隔各地，各參與角色所負責的需求確認、各方之間的技術對接、資源協(xié)調(diào)、跨公司的項目排期等等都是些挺折騰的事情。

11.2 關于開發(fā)模式

（1）瀑布流式和敏捷式

瀑布流式開發(fā)是傳統(tǒng)的開發(fā)模式，強調(diào)文檔和流程，相對缺少迭代與反饋，不適合客戶需求不斷變化的開發(fā)場景，但是好處是從一開始終點目標就清晰明確。

敏捷式開發(fā)強調(diào)“快”，要求快速迭代以獲取頻繁的反饋，適合應對市場和客戶需求不斷變化的互聯(lián)網(wǎng)場景，缺點是很容易欠下技術債。

舉個例子，假如要造一臺汽車。瀑布流式開發(fā)會花上好幾個月來確認每一個汽車零件，然后再動手；但是敏捷模式則會拆分階段，每個階段都會先做一個“可被測試”的東西。

如果這個不管用，那就再做一個，逐步逼近一臺真正的車子。

（2）模式選擇

在APP應用類型的開發(fā)中非常適合敏捷式開發(fā)，因為市場的需求很多時候是未知的，產(chǎn)品經(jīng)理拍腦袋想出來的great idea往往可能是個坑。

而敏捷開發(fā)的好處是快速迭代，并且短時間內(nèi)即可驗證想法。否則一個功能模塊的上新需要等待兩個月之后才能知道市場反饋，整個團隊的試錯成本極高。

但在智能硬件領域，我個人覺得還是比較適合瀑布流模式。

首先電路設計的更改成本極高，隨便更換一個設計就要重新畫原理圖、ayout、洗板、貼片、測試，一個周期下來差不多一個月時間就過去了。

其次產(chǎn)品系統(tǒng)模塊之間的聯(lián)動性極強，比如APP端如果要調(diào)整控制報文的發(fā)送模式，那就會導致云端要同步更改、測試，嵌入式端要同步更改、測試。

再者是資源協(xié)調(diào)和工程排期問題，除非是大型的公司，否則小公司研發(fā)硬件多半需要各種不同的公司一起配合研發(fā)。而任何要變更一個需求，都需要重新協(xié)調(diào)對應的公司工程師資源及對方的排期安排。

這一系列的聯(lián)動性都會使得項目在開發(fā)過程中不合適過多的調(diào)整變更設計。

11.3 項目交付

項目的工期卡得相當緊，客戶期望是6個月可以出貨，在現(xiàn)有的經(jīng)驗和資源下幾乎是個 Impossible Mission。

最后我們花了8個月時間實現(xiàn) Case Close，雖然比客戶設定的時間晚了兩個月，但總算是順利交付客戶。

十二、標準作業(yè)程序(SOP)

 

作者：Kesure，微信公眾號：kesure225；長期扎根于AIoT智能硬件領域，擼過算法，寫過應用，編過文案，干過推廣，蹲過生產(chǎn)，拿過投資，專業(yè)并專注的產(chǎn)品背鍋俠~

本文由 @Kesure 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議