[科技見談] 所謂的創新設計跟研發

濫觴
2013年從微星來到海邊，一個是品牌廠一個是系統廠，
對我來說是一個非常大的挑戰，前者我玩的是Android的apps開發；後者是Embedded Linux system.
而海邊系統廠做的是車電卻是像手機一樣的產品--BMW Smart key，而微星跟海邊最大差別在於自有品牌與知名汽車品牌的周邊‧微星是主打後裝市場，海邊打前裝市場。先介紹產業鏈，稍後介紹好好介紹。

所謂產品生命週期
一個偉大產品的誕生通常由需求設計與創意發想投入，通常產品是為了解決一個或多個問題並為生活帶來便利性‧
需求一但有了，研發人員會由硬體跟軟體去討論需要選擇什麼樣的技術及模組來解決問題，智慧裝置通常如此，但也有些研發工作是工業設計或是機構設計人員先啟動‧
基本上考量的是製造模式 : 是OEM還是ODM
一旦選擇平台以後，由硬體去決定使用那些模組來解決，像是物聯網的產品因為連網，基本上需要Wify或是藍芽。決定好模組以後，我們需要看哪種平台能夠滿足裝載這些模組，像有些車用的智慧裝置需要CAN bus、我們需要提供原生CAN的interface的晶片模組(SoC或是MCU/ECU)‧去確保每個模組都能夠裝載，一般來說一開始提出的規格較為高級，因為不知道後續會不會有更動或是新的需求‧等到量產階段(產品穩定以後)藉著物料EOL的契機探討替代料的導入緊接著是cost down。

量產階段的稽核會是一段痛苦的過程，尤其是車規，若是消費電子則較為輕鬆，但消費型電子的產品開發週期越縮越短，以智慧型手機這個消費型產品來說從開始的一年到一年三個月到現在半年出一隻。


說到底，不管是OEM或是ODM模式，產品是要通過量產階段問世於世人才能證明其價值‧

但是在台灣這些量產之後似乎與我們無關只因為我們是代工的命‧

唯一需要擔心的是製造良率的高低與市場反應的再接單‧




耕耘再耕耘，進化再進化 從一開始的SPI 到中途進入產線看問題及解決問題，下一步則是弄UI(RMA & Issues fix)，
我獲得了兩個領域的進展，但實際看來就是 技能點被點亂了，我索性靠著在產線等首件驗證的時間以及調教的那段日子 考了國際專案管理師的證照 -- PMP‧

PMP無法與工作結合，
接著又去做自動化測試(Python)從無到有個開發，跟德國客戶合作，後來則是導入正軌進行MCU、Linux Driver porting跟SoC底層及framework，因此我覺得是時候該把這些所學串在一起‧




設計轉角遇見創新

由於一直以來有一些創新的點子，因此我搞了一系列創新的side project，
於是乎我現在是準設計系的研究生，即使現在看來依然有點艱辛‧
我想在此刻寫這篇文章不是為了做一個成功者的回顧，成功還很遠...
而是記錄我此時此刻的心境與心情，有朝一日我在創新設計與研發整合的領域搞些具創新創意的產品時，
像是在泥濘中玩耍的科技頑童，我能夠不忘初衷 -- 繼續地堅持下去‧

另一段路程的開始
創新 + 管理 + 研發 從來不是三個單一命題，而是一個複合命題，只是海邊沒有創新‧
如果要考量創新 就是物聯網或是汽車電子 加上 人因工程&人本設計--以人為本的命題‧
海邊不像3M有部門專門從事創新思考，我只能夠透過碩論要做什麼產品

所幸海邊的Package不停的在換，所以可以體會到不同公司的管理方式，然後思索其中利弊‧

海邊的願景只是找到Income，創新設計則是找到商機 找到新的獲利模式 翻轉國家的產業結構‧

然而這點在台灣很難達成，有錢的老闆們是代工起家 代工的沉默成本較低 但是機會成本也低很多

未來我會努力耕耘對於老人照護(長照)、智慧家庭(IoT)、對於使用者需求設計與分析&福祉設計，
把我疲於服務單一品牌客戶與企業 與 想回饋社會的心 用 創新設計 + 研發 這兩大主題組成的複合命題延續下去‧

[科技見談] 關於汽車電子的三兩事

在汽車電子領域工作怎麼能不懂車呢???
列一些點來這邊做筆記好了


車身控制模組(Body Control Module；BCM) : 集大成的車身控制系統,除了對車身各部件資訊的搜集之外,也能做一些控制．
走的通訊協定跟interface有三個：
１．LIN protocol
２．CAN protocol
３．Ethernet protocol



先進駕駛輔助系統(Advanced Driver Assistance Systems；ADAS)



ESP


循跡防滑控制系統(Traction Control System；TRC)
車身自動偵測打滑現象，控制並降低引擎轉速讓車子打滑的狀況減緩，試圖讓災害減至最輕。

[科技見談] 關於自動化測試

前言
自動化測試是結合 程式開發 與 品質管理的一項領域技術
有鑑於無人自動化的開發 電腦可以取代人
做營運管理的項目越多 -- 品質測試與管理 也被拿來評估與討論

濫觴
2015年底，我進入了自動化測試領域
因為客戶的需求及老闆的建議下 我開始了Python之路
而我也因此認識了Python 跟它談了 "一整年的戀愛"
Python  強調程式應優美、簡單、明瞭，像佛教的"禪"

禪的意境
禪是種意境，像風一樣，雖看不見但卻無所不在，我很嚮往 -- 逃離紛擾 邁向空無。
心靈的禪學=>我還在追尋，但至少Python的藝術 讓我領略到了這種意境。
至此之後，我認為概念式或邏輯的開發上我應該使用Python來開發並驗證
不管是在自動化系統開發或是物聯網的領域上，甚至是機器學習 大數據分析等等
Python已經提供了完整的API包 -- 讓我們站在巨人的肩膀上看世界!!!


開始的一切是如此原始
有別於一般iOS的自動化測試使用Selenium for iOS 或是 Android app的自動化測試使用 Selendroid (Selendroid for Android)

一開始的自動化測試，我使用的是 "腳本化開發方法"從Serial的驗證 到 IEEE488規範的儀器(GPIB，如電源供應器)的控制我用的是一條腸子通到底的腳本式語言很快我遇到了瓶頸 ~~ => 非常不好維護我開始分門別類地將不同的模組寫在不同的.py檔內
到了第二階段的類 C語言的開發 =>程式開始有點規模了
使用這樣的方式開發 除了乾淨外，之後的擴充或是維護 都是很好管理的

系統化的架構思維
在自動化測試系統的開發中，很多時候需要將架構開發與測試行為發展進行切割
我認為需要更好的分工模式來進行 自動化 及 測試兩個功能
所以RD專心自動化   QA專心寫測試腳本(Test cases) -- 合作無間。
這時候我認為系統還介於第二階段與第三階段之間 -- Stage 2.5 of Auto-test system.
第三代的完成 我認為除了導入了SW-QA撰寫的xml檔(test cases)機制外，還有test command與check command兩邊的分工，我將測試步驟分兩塊 -- 步驟測試(Tester)與步驟確認(Checker)

何謂步驟測試(Tester)??
SW-QA將測試程式分成很多個小步驟 除了前期判斷Pre-condition外，就是測試步驟的進行
測試步驟會分為很多模組
Charging test、Hardkey test、Touch Pannel test等等
tp我們會先在產品端埋入老化程式(大陸朋友的理解) 我跟德國佬 都稱它為 Test Proxy
Test Proxy它是代理人 會接收我們送給它的訊息從UART或是I2C...等等溝通的介面接口(Interface)，它會將我們送給它的指令轉送給產品端的其他介面或是 -- 直接控制!!!
這邊很多測試都是非常直觀的，在這裏我們還會導入Arduino去幫我們控制一些電源輸入等等透過Relay的控制來決定產品是否充電...

rejection test(排除測試)為在RD端測試過程需要確認測試手法能否付現、經由付現率從100%降至0%以確保問題解決的過程，以車用產品來說，我們使用V model來對應整個產品從RD開發到最後產品到使用者手上的測試‧

何謂步驟確認(Checker)???
我們需要透過步驟確認這個動作，來完成測試的目的
如何確認 方法很多 除了Log checker外 我們可以透過DumpUI 以及外拍存圖比對的手法達到

疑惑、迷惑還是迷失??
很多RD很輕易地傲慢，認為他們創造了一切，如此一廂情願，從一開始的疑惑到熟稔技術後會變成迷惑，最後我迷失了自己   中止迷失最重要的是 他們要認清  一切的一切應該以人為本

我們太過相信電腦處理程式的速度與能力，總認為技術與架構上能夠駕馭 我們能夠駕馭一切
但實際上的狀況是  -- 電腦還是會出錯，至少在我們教會它們學會自我學習之前。
程式開發以人為本的概念就是，想辦法讓電腦像個人

在這個階段我獲得了一些指導跟方向
我們不能 一廂情願 更不能"射後不理"
在此向資深的同事們學習 車用電子的精隨 -- 嚴謹
需要透過狀態的確認 我認為這是第四代的自動化測試
即使是我所知道的 其他團隊開發的自動化測試 雖然是不同的寫法 OO
但那始終是Coding style的不同，對於自動化測試中代數的演進，我認為是無差別。


下一個里程碑
2016~2017 我們在自動化的浪潮之上時而被新的資訊與技術 淹沒 但又像勇敢冒險的衝浪客 克服技術(湧浪)的困難與瓶頸 爬上浪尖
我認為自動化測試，應該結合人工智慧(機器學習)並透過類神經網路模組去學習行為
這樣的配置或許過於豪華 但我認為是必須的弊
在我跟同事們合作的過程中，我們花了大部份的時間 分析test cases行為的合理性並Debug
我始終認為好的程式 應該是幫助人類 而非證人入罪
之所以會自動化是因為 人需要休息並且人會出錯
我們給了機器思考跟學習的能力 我們除了一開始教他之外，剩下的時間
我們應該把時間花在教它更多新的事物 而非 找尋跟修正我們自己的錯誤

只是 那條路...還很漫長~~~ 那是最後一哩路

[科技見談]安全的標準跟安全的編程規範

車規的標準 :
ISO20001
TS16949 : TS16949
6Sigma

MISRA C

其中RD最常碰到的莫過於MISRA C，無論在汽車上 或是醫療 航太等等 都會用此標準
核心思想 無非就是降低人為造成的ISSUE
其中更倡導 不要使用動態記憶體去放變數跟其位址
而是使用靜態記憶體
所以C中的malloc跟free是能不用就不要用
關於自己寫的程式是否有符合MISRA C的標準是可以使用工具檢查出來的!!

[科技見談]Good Coding Style

1.宣告馬上用，勿宣告一大堆變數再同時assign數值。

2.變數命名長度不超過１７個英文字母。

3.記得命名有意義。

4.組合字記得用底線隔開　或是連在一起但第二個單字的開頭大寫。

5.for迴圈少用i,j,k盡量用有意義的單字eventIndex。

6.類別是靜態的切勿用動態動詞命名。

7.類別Abstraction 先宣告一批public，再接續宣告private，且private宣告用指針 切勿透漏 如此才能達到資訊隱藏目的。

8.一行70~80個字元，勿太多。

9.Function 100~200行 勿太多。

Google Python命名規則　　　轉載自凍仁的筆記

module_name, package_name, ClassName, method_name, ExceptionName, function_name,GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name,local_var_name.

避免使用的命名：

1. 除了計數器及迭代器之外，不要用單一字母為變數命名。
2. package 及 module 的名稱中不要包含破折號 "-"
3. 變數名稱前後不要加上兩個雙底線 (如：__double_leading_and_trailing_underscore__ )。

命名慣例：

1. "internal" 指 module 內或 class 中的 private 或 protected 的變數。
2. 要保護 module 變數或函式，可在變數名稱前加上單一底線，若用 from foo import * 時，這些變數不會被 import。(編案：若用 from foo import _var 則還是能使用 _var 變數)。若要在 class 內宣告 private 變數或方法，則在變數名或 方法名之前加上兩個底線 (__)，private 的效果是透過 name mangling 達成。(編案： name mangling 本質上只是把變數重新命名，因此使用者若執意要呼叫 private 變數還 是能夠達成。)
3. 把相關的 class 及 頂層的 function 放在同一個 module 中。你不需要像 Java 般 限制每個 module 只能有一個 class。
4. 命名 class 時，使用每個單字的字首用單寫 (如：CapWords)。命名 module 時，用 小寫及底線 (如：lower_with_under.py)。雖然某些既有的 module 命名仍使用大寫字 母 (如：CapWords.py)，但不建議這麼做，因為當 module 名稱與 class 名稱相同時它 們將難以分辨。(你通常寫 import StringIO 或 from StringIO import StringIO ?)

命名通則：

1. package: lower_with_under (public)
2. modules: lower_with_under (public), _lower_with_under (internal)
3. classes: CapWords (public) _CapWords (internal)
4. exceptions: CapWords (public)
5. functions: lower_with_under() (public), _lower_with_under() (internal)
6. global/class constants: CAPS_WITH_UNDER (public), _CAPS_WITH_UNDER (private)
7. global/class variables: lower_with_under (public), _lower_with_under (private)
8. instance variables: lower_with_under (public), _lower_with_under (protected),__lower_with_under (private)
9. method names: lower_with_under() (public), _lower_with_under() (protected),__lower_with_under() (private)
10. function/method parameters: lower_with_under
11. local variables: lower_with_under (public)

何謂Memory Leak?

我們常常會聽到程式開發人員嘴邊老喊著︰記憶體不足。
會發生這個問題，其中可能包含Memory Leak。

維基百科對Memory Leak(記憶體洩漏)做了以下的解釋︰ 在電腦科學中，內部記憶體泄漏指由於疏忽或錯誤造成程式未能釋放已經不再使用的內部記憶體的情況。 內部記憶體泄漏並非指內部記憶體在物理上的消失，而是應用程式分配某段內部記憶體後，由於設計錯誤，導致在釋放該段內部記憶體之前就失去了對該段內部記憶體的控制，從而造成了內部記憶體的浪費。

Android官方布落格提到︰ A "memory leak" in your code is when you keep a reference to an object that is no longer needed. Sometimes a single reference can prevent a large set of objects from being garbage collected.

以下文章引用自女工程師的美加生活手札的部落格，
裡面提到︰
在電腦世界裡，有一個performance的隱性敵人，它會造成記憶體的使用量隨著時間慢慢增加直到消耗殆盡，這個敵人俗稱Memory Leak (中文翻成記憶體漏洩)。

Memory Leak造成的原因是某個被配置(allocated)的記憶體無法在被參照(referenced)，也無法被釋放(released)；那塊被配置的 記憶體就有如記憶體孤兒般，無法被系統再使用，所以要看一個程式有否Memory Leak，很簡單的方法就是去看作業系統(For standalone application)或是Application Server(如果是Web Application)的實體記憶體使用圖，如果隨著時間增加，記憶體的使用量呈現明顯增加的趨勢，這個程式就極有可能有潛在的Memory Leak問題。

Memory Leak在C/C++語言中是很常見的人為過失，因為C/C++並沒有自動Garbage Collector (垃圾收集器)的機制，程式設計師必需在使用完資源後，人為釋放資源。雖然在Java、C#有自動Garbage Collector的機制，Memory Leak的機會大幅下降，但仍然不能完全倖免，只要程式設計師不小心仍然會造成Memory Leak。

有些人以為Java有Garbage Collector(GC)就不會有Memory Leak，其實是錯的。如果一個物件仍然有被參照，Garbage Collector是不會回收該物件的。 

比如以下狀況： 

假設你有一個Java程式，裡面你運用了一個宣告為static 的Array A來儲存已經開啟的視窗-JFrame instance。如果使用者開啟了一個視窗W1，W1會被存入Array A中，而當W1關閉後，你沒有把W1從Array A裡移除，這時，雖然W1已被指到null，Garbage Collector卻不會回收W1。

原因很簡單，因為Array A仍保有W1的參照，GC假設W1之後有被使用的機會，所以沒有回收W1。如果這個程式持續開關大量視窗，它所用的記憶體也會呈現增加的趨勢，而造成了典 型的Memory Leak狀況。

解決的方式很簡單，只要在W1被關閉時同時把W1從Array A裡移除即可。

[科技見談]SMT段打件流程

專案管理術語 

階段: SR (Sample Run), ER (Engineering Run), PR (Pilot Run), MP (Mass Production)

PS: PR 也有人說 Trial Run / Control Run / Ramp Up 

各階段產品:
* ES (Engineer Sample): 用來確認產品基本功能，不保證實用性、耐用度
* CS (Customer Sample): 功能都要能正常工作，不能當機、掛點、失效
* MP (Mass Production): 消費者手上拿到的量產版

測試驗證:
* EVT (Engineering Verification Test)
* DVT (Design Verification Test)
* PVT(Production Verification Test)

最後就是 EOL(End Of Life)

SMT 專有名詞   
錫膏板
膠質板
爐前AOI
PCB : 沒有上零件的電路板
PCBA : 有上零件的電路板
0201 :　
gerber out : 將電路圖出給板廠打版
百百測 :
錫裂 :
Feeder:



Lv 6 SMT流程 
0.來料烘烤
1.進版(送板子)
2.上錫膏
3.SPI
4.打件(SMT)   將電子零件打上去
5.爐前AOI        (爐前電腦系統影像比對檢察)
6.過爐RE-FLOW  
7.爐後AOI  
8.X-RAY  
9.目檢
10.ROUTING     (撈板)
11.壓Shelding
12.點膠  
13.烘烤
＝＝＝＝＝＝＝＝＝首件完成 準備下載＝＝＝＝＝＝＝＝＝＝＝
14.軟體下載
15.軟體測試1  
16.高低溫    
17.軟體測試2
18.組裝    
19.總檢OQC/FQC + 包裝出貨