Note: detect solder ball defects for BGA

有聽到現在X-Ray的機器一般還是人工判讀 Solder balls 的 solder bridging & voids, 不過按照一般來看這應該可以很快的用傳統的電腦影像處理方式取代才對, 估計是一般來說因為產線都只有設置產線做 trail run 時需要檢驗幾片確認製程狀況需求沒有那樣強烈的關係,才沒有那樣多的研發資源

基本上有 Circle Hough Transform 可以去抓大小與範圍, 然後做histogram 處理分離氣泡可以做 voids 偵測, 透過Circle Hough Transform + Canny 應該可以做到 Briding 的問題

不過都需要實際去調整各種參數, OpenCV 已經把演算法寫好了, 做基本實驗應該不難

廣告

Note:基本加密連線隨想

本來就有在想要怎樣做安全的交換資訊, Google等公司很早就啟用了two-factor的驗證, 本來基於我粗淺的密碼學認識就是, 在設備內存一個hash init vector, 然後透過時間區段去做特定HMAC就可以得到一個隨時間變化的驗證碼, 只要保管好這個init vector就可以簡單作到相關應用, 這個key應該被存在 TEE的環境中,在Android 應該是Keystore 機制來實施, 可能的話, 顯示的UI也許也是要TUI(Trust UI)

設計一個安全的IoT系統基本上就是要有一個可靠的系統存放各種KEY(HASH), 目前可見TEE環境與TPM, 或是各種嵌入安全晶片會越來越多

交換資訊時, 需要驗證的地方需要加入Timestamp/DeviceID 當作salt 這樣可以避免 Capture/Replay 通訊封包就侵入系統, 這樣做的目的是該封包, 等於該時該裝置才能解密後檢驗有效. 再加強的話就把連線雙方資訊也加進去。

今天早時間看了一下Google Authenticator 看起來是透過這樣的方法實作出來的
TOTP (Time-Based One-Time Password Algorithm)
HOTP (An HMAC-Based One-Time Password Algorithm)

https://tools.ietf.org/html/rfc6238
https://tools.ietf.org/html/rfc4226

Note:精通施與受的建言藝術

今天恰巧讀到 精通施與受的建言藝術 其實在工作生活中, 常常會有人要求給予建議, 我通常會在力所能及內,  提供個人看法與建議, 不過這樣多年過去後發現真的蠻多人要求建議時只是需要一個贊同的聲音而不是真的想要聽你的意見, 離開前公司分析主因就是認清這點

文內有一些建議

1. 尋找最佳人選, 個人理解是要找一個你能力所及內, 你認知道對方是一個你能放心有信任感的幾位專家, 其實這第一步很重要, 找一些沒有信任感的人, 就算給你建言的人提供你正確有建設性的作法, 你也會因為自己的侷限性, 如格局, 眼界, 經驗所限一再否定對方給你的創新性的改革建議, 就如同現在流行一句話叫做 “貧窮限制了我的想像力" 是一個道理。而且這過程是漫長建立起來的,透過一些合作與徵詢累積彼此的信任

2. 建立共識 , 這重點是徵詢的人對自己的心態控制, 否則一切都是白搭, 有的人會有很受威脅的感覺, 甚至對建言者隱藏太多關鍵細節, 這樣也很難取得好的建言, 其實終歸還是回到信任這一個環節, 所以俗語有"用人不疑"這個建議, 這其實考驗徵詢者本身對人的判斷能力與自我信心的健全與否,  建言者則是要有耐心去跟徵詢者磨合, 設法引導對方思考。

3. 琢磨可能的方案, 這是要多方思考各種可能實行的方案, 要做細部推演, 做多方發想, 分析可能的途徑, 透過雙方合作腦力激盪, 建言者要多分析自己的提案的背後思維,

4. 擇定一個決策, 經過上面的步驟後, 最後就是開始最後抉擇可行的方案選定其中最合適的方案去執行, 但是文內有看到人有傾向便宜行事的業力, 這我也遇過, 不過這是人性, 常見寬以律己, 嚴以待人, 滿口要人奉獻犧牲, 但是事情落到它頭上時, 確發現他的應對完全是另外一個模式, 我自己歸類為專講幹話的人選, 這種人通常還意外受上司歡迎, 畢竟平常會讓人覺的很像盡心盡力為團體奉獻的樣子, 該文重點其實是針對各種方案要有個開放心態, 放開去找各種可能性, 千萬不要找一個看起來最簡單最容易的方案就去執行, 個人經驗也是通常看起來最近的最遠, 反而是那種看起來繁瑣但是穩紮穩打的方案, 才能真的一步一步推進, 最後才能成功實行真的才是最快方案

5. 化建言為行動, 基本上應該就是要有執行力與應變力, 就是俗話說的"計畫趕不上變化", 當執行決策時, 可能會發現事情跟當初設定不見得一樣, 要能靈活快速的應變, 持續保持開放心態, 對事情做當下最好的處理與建議

 

Note: OpenstreesMap 商業使用

昨天聽到一個很有趣的事情說OpenStreesMap 可以商用我就問了說架了Tile server 嗎? 對方說沒有它可以直接商用, 但是根據資料應該是資料可以商用但是Tile Server之類的需要自己提供, 畢竟他是一個慈善性基金會, 沒道理要提供Server 去服務商業行為呀

不過後來我很明智的閉嘴不在糾結這些問題上, 畢竟有時候對方思維陷入他自己的區域, 而且異常有自信時, 這時講啥對方都無法接受外來意見的

https://wiki.openstreetmap.org/wiki/Introduction_to_OSM_for_Business_Users

Note: 智慧眼鏡(Smart Glass) 發想

目前智慧眼鏡開始進入企業商業應用範疇, 但是有一些降低成本需求的聲音某些時候只是為了有一個屏, 輔助使用者再某些情境的應用, 因此考量該需求會希望降低該眼鏡成本, 而且需要長時間的使用, 開始有一種攜帶式裝置搭配電源採取連線的設計

個人看法這應該可以直接採取 USB-Type C 透過Alt DisplayPort or HDMI直接傳送影像的設計,這樣可以大幅減少成本, 然後為了標準開放的話,可以跟USB  協會提案一個新的profile, 透過USB Device configuration 可以回傳眼鏡本身的硬體特性, 如EDID或是影像成像相關校正特性矩陣, 因為對於攜帶裝置來說只是加上一層幾何變換處理當GPU夠強大時可以直接套用, 做AR/MR時可以再疊一層Overlayer 設計

有鏡片焦距資料/形變矩陣/投影大小, 系統也可以自適應的調整對應UI 這樣才能更完美推進使用者應用情境

Note: About An e-Seal system design

e-Seal 主要是應用在貨櫃轉口或是由保稅倉庫轉移貨物, 基本上就是要由一個保稅場域移轉到另外一個保稅場域的設計, 傳統有海關派人押運, 後來演變成為封條設計, 近十多年來各國普遍發展出RFID 的電子封條設計

電子封條,主要有兩個部份設計因為是鎖住貨櫃所以有機械鎖的部份, 這部份有ISO 17712機械鎖的國際標準可以遵循, 跟採用RFID電子標籤技術結合的 ISO 18185國際標準
ISO 18185 分為 5個部份, 分別為

  1. 通訊協定, 有433MHz(Type A)/2.4GHz(Type B) 兩個頻段的LRL(Long Range Link),跟低頻的SRL(Short Range Link) 跟資料鍊路層(Data link, L2)的定義
  2. 應用需求, 包含使用情境, 基本需求資料
  3. 耐候環境特性, 包含高低溫, 振動, 外力衝擊, 鹽霧, 濕度, 冰與雨, 熱衝擊, 等等
  4. 資料保護, 定義機械鎖跟電子所的啟閉封安全需求避免被破壞跟仿製電子封條
  5. 實體層, 定義Type A/Type B的實體層設計如OOK/FSK 調變

這上面算是被動式一次性電子封條的需求, 追求的便宜安全, 因為一次性, 但電子封條未起用前成為不可讀, 而讓仿冒的可能性降到最低, 因為會有唯一ID設計, 如果再加上一些貨物相關資料編碼做電子加密後才能啟用, 系統可以設計滾動式亂數密碼, 啟用時寫入電子標籤與上傳系統,進一步杜絕中間被代換的可能性。

目前有看到一個需求主動式電子封條,為了追求更安全的使用情境, 加入GNSS Tracking System 去追蹤貨物運輸狀況

基本的資料應該是一樣的會有電子封條唯一識別資訊, 不同是這種主動式封條本身因為價格問題應該是可重複使用的所以系統設計有些許不同, 基於安全需求為設計為使用一個固化電子憑證儲存,本身唯一資訊, 然後每次使用前應該也是由系統配發一個任務碼進行加封包含相關資料做加密寫入區塊。

加封時須已經完成定位跟顯示相關任務資訊內容待授權人進行確認核可。

加封後應持續發送封條辨識碼, 定位資訊與封條狀態,此時採用MQTT Server 並用SSL加密, 甚或payload 本身採取任務碼與其他特徵為key做AES256 加密, 藉以達成資料安全保密需求防止資料被竄改的可能, 後台採用MQTT後端系統, 可以再發展資料收集系統或是與其他系統相連功能做電子資料交換(EDI)

到達目的地解封時,系統可以採取判斷是否資料有異常特徵,紀錄監管解封狀態等等資料

 

海關推出智慧化電子封條讀取器

“截至今(一○五)年八月底止,以加封電子封條方式取代之人工押運櫃合計三十四萬二千七百九十九只"
據稱現在台灣有接近45萬只貨櫃/年(2018), 從年押運量來看 用200個工作天計算, 一天約需要2200個但是因為不可能達到理想化分配採取x3 約為6600只, 再加上1000餘裕配置, 約估計台灣最多只需要8000只可重複配置的電子封條鎖
不懂進出口關務真的會做出錯誤判斷 😛
就算按照裡面說的不包含需要押運的每天平均車次也才2萬次, 最樂觀看來5萬只就是爆量了

Note:Auto-Recovery for Windows System Boot crash

現在這個年代只討論 UEFI, Legacy BIOS 也可以做但是透過Customization Bootloader會更好一點,  簡單想法是透過NVRAM 存一個Boot Count, 個人偏好 RTC的CMOS空間, 當然要寫再Flash 也不是不行這個東西不是為了頻繁開關機的環境下設計的, 所以不會有頻繁擦寫Flash 的問題 後來想到本來UEFI 就有一個Monotonic Counter 設計來給Secure Boot用的, 等於是做一個簡化類似的東西, 但是配合自己系統改變

然後在系統內裝一個Agent, 最好是一個Automation啟動的Service 讓它負責抹除Boot Count, 個人會設計啟動一個Thread在系統啟動差不多3~5秒後才抹除確保系統不是開機到一半當掉 XD

然後透過BIOS 在BDS前去讀取該變數, 譬如累加到3次, 代表已經開機三次不成功, 這時BDS跳到選擇做Recovery的Partition 啟動, 讓它自動進入Recovery 步驟
or 是透過PXE去啟動系統 直接網路Recovery

類似下面這個

Make your own automatic Windows restore partition
IT Geek: How to Network Boot (PXE) the WinPE Recovery Disk with PXElinux v5 & Wimboot