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

Note: 台北公車上的行車記錄器

上週五搭公車去某公司面試, 觀察了一下現在車上的行車紀錄器(新店客運)的約莫是7″ LCD, 然後在路線上顯示同時有大概7~8ch的輸入的設計。當公車靠站會自動切換靠車門的鏡頭, 算是有打到需求。鏡頭解析度應該還是D1以內規格

然後我就好奇了這樣的硬體設計要怎樣成本壓低, 想到可以用DragonBoard 410c 接兩路DSI Camera, 一路負責4 ch, 但是這樣的設計要需要有一個搭配CVBS (Colour, Video, Blank, and Sync) to DSI 的convertor/bridge 查了一下 Intersil  ISL79987 剛好適合, 而且NXP有一個for Linux 的patch camera surround view solution

這樣應該可以比較容易的設計出類似的需求而且可以相對壓低成本, 當然要便宜選Rockchip RK3288W 可能更合適

如果要導Automotive Ethernet 到是可以直接考慮 Allwinner T2 去當做Input source Bridge 成本會高一點但是可以更模組化設計擴充, 每顆T2 自帶有四個VideoInput, 配256/512MB RAM應該就夠了 不過如何作到 robust 倒是學問

 

ref.
1. 對岸倒是有直接推出用T2做比較低階的4 input 版本的設計N970WA(T2)
2. NXP 的IMX6 MIPI CSI2 文件 AN5305 講解了 CSI的DATA ID/Virtual channel
3. Backup – my collect
4. CVBS (Colour, Video, Blank, and Sync): Composite Video Signal

Note: 某公司可能的問題

今天早上跟某公司電話溝通一下某職位內容, 該職位會需要NFC相關知識, 從溝通內容聽起來好像使用上有遇到一些問題, 細節我就不清楚, 但是有問一下使用的Transceiver廠商是哪一家的, 然後查了一下該廠商好像只有一個型號, 基於我之前NFC應用經驗, 我第一個會懷疑是NFC本身RF相關問題, 然後看到只有兩檔Output power 可以選, 最大還只有200mW, 就有點發涼, 雖然我沒摸過它家產品, 但是基於該產品是需要防碰撞的設計, 可想而知本身的Housing 應該是有一定厚度才能作到安規需求

跟朋友聊一下它常見的問題, 個人評估有兩種可能一種是真的電極接觸問題, 一種是NFC Output Power 輸出衰退造成的, 當然實際不清楚, 沒看到Failed log 只能這樣憑空臆測, 查了一下其他晶片廠商應該有更好的選擇

200mW的應用情境按照我之前的經驗比較合適是1~3cm感應距離的, 實際上因為應用環境因素可能會縮短感應距離。

後來又查了一下該公司產品資訊好像近期有爆出使用狀況, 感覺是想找人進去救火

做了一下午案例研究
雖然手上沒資料 但是從各種網路使用者反應的現象, 估計是NFC傳輸已經出問題, 造成斷電或是後續更新變成降出功率, 這個現象應該是有80%是 NFC Tx的功率已經開始降低造成
因為是已經運行了兩年, 不知道它們設計的通訊間隔多久, 有做好產品壽命管理嗎? 這個本身是賣服務的公司應該要確保服務品質
又研究一下
如果要處理現在問題, 一個可能方案是透過RSSI去偵測檢測是否有開始有異常
有朋友跟我說跟NFC Power本身無關, 這就好奇了
因為網路上看來的案例應該多多少少有關是NFC連線問題
當然有可能是link reliability的問題, 這實際上跟它產品規格有關, 無線通訊天生在reliability 這個關卡就是需要多下功夫, 但是也跟它應用規格有關, 最糟的情況要透過降低某些規格來權衡系統的穩定度
例如採用Tech , NFCA, 106kbits 應該是相對穩定的狀態, LLCP(Logic Link Control Protocol) 可能要改寫, 採用 Passive mode P2P, 這一切都要系統性的確認與檢查還有模擬實際使用情境, 才有辦法做系統優化