Note: Windows 10 IoT core

這個目前還是有一些工控領域有對應市場, 然後很多應用不用royalty fee 所以會有經濟誘因,

不過對於技術人員來看, 做這個image 開發有點介於以前的Windows Compact Embedded 但是大部分接近於原生Windows Embedded 的image build 工作, 簡單講就是客製化的彈性相對少很多, 會極度趨近原生Windows

需要 ADK/WDK 要一致的版本編號 確保OS API/DDI的變化, 這樣變成如果商用有不同版本需要維護會需要切換安裝版本, 應該可以透過環境變數控制, 這需要測試一下

然後 Image 這時簡單分為開發與測試用的Test, 跟實際出貨的Retail

buildimage ProductA Retail/Test

Image 的產生流程可以參考IoT Core manufacturing guide

ref.

廣告

Note: golang with docker

Docker 這幾年對於各種運維很流行,實際上在開發各種嵌入式裝置與Android BSP維護上也會遇到很多相依性問題,這一兩年也看到越來越多公司開始採用 Docker 去維護開發環境了,尤其當你需要多地協同開發時,與第三方客戶或是夥伴開發更是如此,可以透過設定好的Dockerfile 去做開發環境的維護,降低各種溝通與反覆試誤的成本。

這裡舉一個 台灣工控一哥的例子 可以看到連結內有許多不同OS版本對應的不同開發環境,這樣你開發的環境不用去管理各種不同版本的套件相依性問題,對客戶跟第三方合作廠商都可以快速的發布,對於有多樣客戶是一個相對省力的支援方式

因為IoT Era 的到來,今天測試一下Docker 做Golang 開發

底下是一個 golang with git, gcc and make 的Dockerfile,用的是Alpine distribution, 要改成其他Distribution 也可以, 官方有Debian可選 , 可以直接用Docker pull golang:$tagname 之類的方式去拉下image
下面是我新增git & make & gcc 的開發用Dockerfile

FROM golang:1.10.1-alpine

RUN apk add --no-cache git make gcc

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH

然後可以參考官方文件的Docker-compose 去結合其他service 像是資料庫PostgreSQL
這樣可以開發一些Microservice 來做一些應用,需要水平擴展時可以加上反向代理等等,做現在所謂雲端的開發

如果想放像DockerHub 讓大家都可以使用你的Dockerfile 也可以參考工控一哥的這篇

透過上面的Dockerfile 可以用docker build 變成image 我這裡用 docker tag 改成 mygolang
透過docker image ls 可以看到下面狀況

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
mygolang            latest              2da237294097        2 hours ago         475MB
golang              1.10.1-alpine       52d894fca6d4        5 days ago          376MB
postgres            9.6.8-alpine        b27674feae2a        6 weeks ago         38MB

然後建一個 docker-compose.yml 如下, golang 那區塊應該有點問題還需要更正

# Use postgres with golang
version: '3'

services:
    db:
        image: postgres:9.6.8-alpine
        restart: always
        ports:
            - "5432:5432"
        environment:
            POSTGRES_DB: dev
            POSTGRES_PASSWORD: IdQuivgebobr9Dra
            POSTGRES_USER: postgres
    go:
        image: mygolang:latest
        ports:
            - "8080:8080"
        working_dir: /go
        depends_on:
            - db
        links:
            - db

然後下 docker-compose up -d 這樣會出現

Starting mydocker_db_1 ... done
Creating mydocker_go_1 ... done

在接著用 docker-compose run go 重跑一次mygolang 這樣就可以開始開發相關service
透過 docker-compose ps 可以觀察到下面 container status

      Name                     Command              State            Ports         
-----------------------------------------------------------------------------------
mydocker_db_1       docker-entrypoint.sh postgres   Up       0.0.0.0:5432->5432/tcp
mydocker_go_1       /bin/sh                         Exit 0                         
mydocker_go_run_1   /bin/sh                         Up

Update: 這篇還沒整理完,參考 Where and how to persist application data 可以知道應該透過Volume/Bind 跟Host的目錄連結,這樣才能持續開發並且不增加container 需要在花一些時間整理
至於一些使用Docker 快速提示可以參考這個 docker cheatsheet

Note: MyDriving/Azure

台灣近年某些產業很喜歡跟著潮流走,一堆公司目前花各種資源投入物聯網或是車用電子,如車聯網的應用(fleet telematics),Microsoft 當然不會錯過這種議題,早在2016為了展示他的Azure 就有出現一個 Azure Samples Demo – MyDriving 用來協助展示他的Azure功能,翻了一下,它可以讓新創快速參考打造一個展示系統,可以用來展示給終端客戶去吸引合作機會,不過就是很基礎的功能實作出來,如果要實際應用在現實場景還是需要不少資源去客製化,但是可以幫助想踏入這個領域的廠商快速有個概念與做業務展示去擷取眼球爭取曝光
Update: 後來讀了他的 Reference Guide , Microsoft 的PM 也很清楚的說這是起點,然後系統架構圖等等也很清楚簡單的畫出來,這好像是台灣競爭落差的感覺

不然如果從GIS等等搭建起可能需要付出數倍資源與時間

Note: HockeyApp SDK for Mobile/IoT devices

剛注意到 Azure 目前提供一個Free servcie, 叫做 HockeyApp 他是用來管理Mobile Device上面的App, 透過它OpenSource的SDK 去整合到自有的App裡面,然後使用Azure內的Service 去做本身App的管理, 主要有下圖的功能

Distribution(Update)/Crash Report/User Metrics 算是可以再這物連網時代,幫助中小型公司快速打造自有產品的好服務,可以節省很多時間與金錢去打造原型產品,而且支援常見的Android/iOS/Windows 平台

Note: IOTA with Industry 4.0 的一些想法

最近在看IOTA 的一些東西,今天早上突然有個想法是應用IOTA 的帳本紀錄在工業4.0上面,假設有個工廠想要導入IOTA相關技術到生產管理上面,實際上需要建立一個或多個Full Node 目前IOTA提供的參考實作 IRI 是透過JAVA EE 寫的,個人覺的他有一個缺點是JAVA EE 本身需要比較大的計算資源,可能的話我個人覺的是在工廠的生產場線場景,透過各種IoT Gateway 執行這個Full Node 功能,這時選擇比較輕量架構應該是一個降低整各應用場景成本的,例如用Python/Go/NodeJS/Rust 等等語言去實現這個FullNode

而考慮應用場景的後續管理維護問題Full Node 與IOTA Devices(Wallet)也需要應用上 Neighbour Discovery Protocol,這樣才有可能達到快速佈建與減低後續維護管理的成本。

再來IOTA Deivce需要自動產生 Seed 並且隔離在應用層,這個應該可以應用目前 Trust/App OS 分離的設計,透過MPU/Hypervisor/TrustZone … 等等技術去隔離

當然以上是考量用比較小的成本去執行,昨天還看到對岸某各機器人公司用ROS做的設備那些東西的成本可以忽略執行IRI成本,但是考量後續管理維護成本其他東西還是需要補齊,考量初始裝設成本跟後續維護成本的比例實際上這裡初始裝設只佔比較小的部份

 

Note: MQTT to IOTA Tangle

http://learn.iota.org/tutorial/storing-mqtt-messages-on-the-tangle
https://github.com/nicoschtein/iota-mqtt-poc
看了一下大概就是把MQTT收到的MESSAGE 重新編過變成Tribytes後轉成IOTA的交易送出,
這個是一個概念驗證示範, 不過說明了這種架構需要比較大的頻寬, 可以看成有一個比較大的資料塊存少量訊息會有比較大的浪費, 看應用可負擔的成本而定, PM2.5 LASS 好像有計畫導入有成功的機會因為基本上都是走WIFI, 不過之後應該會有人做LoRa版本那應該會改成有類似Data collection Hub 在轉上Tangle 比較合適才對

亂想

今天看了一下IOTA 的一些東西, 看來IOTA 越來越確認目前不是那種萬物可上的狀態, 基本上它考慮了很多東西, 看起來MCU 是可以跑得起來因為只需要驗證交易而已, 但是忽略對外頻寬的壓力, 當然這個在未來10年內可能可以解除? 透過5G時代來臨的話也許對外頻寬成本可以解決? 不過估計短期(5年)內不可能已經是確定的, 目前最好的模式還是 還是在私有網路搭配一個 IoT Gateway的設計比較實際

IOTA 目前有Open Source 一個Full Node 實作 IRI (IOTA Reference Implementation)用的是 JAVA 8 and later(程式碼有用 lambda ), 從源碼看來是直接用undertow 去嵌入一個web server, 然後API.java 裡面的process() 函式處理那些API(commad)

目前因為很多東西還沒確定, 所以還持續演化中, 像是經過snapshot 後清掉所有交易紀錄只剩下當下Address 與 IOTA 的對應關係, 這有優點也有缺點, 優點是可以reduce database, 缺點是無法追蹤交易細節, 不過針對缺點有提了一個Permanodes 的提案, 但是啥時會有還不確定,個人估計今年應該就有才是

2018應該是AI & Blockchain 的爆發年,  然後2年後會死掉一堆公司, 這有點像2000年的.com 浪潮, 不過從歷史看, 新產業都是這樣, 大家一窩蜂投錢賭天使投資成功換回千倍回報, 不過天使投資100家能成2~3家就是很高的勝率!

IOTA 目前優勢是已經獲得國際上許多合作 看起來有蠻大的機會成功, 估計越多公司加入會驅使整個方案的成熟

不過重點還是資料來源是否是可靠的! 目前看來已經有許多硬體跟軟體正在整合中, 差不多這5年內, Trusted OS/Device 之類的會變成必須! 不過傳統裝置會不會有估計還是會佔多數, 不過會越來越偏就是了! 因為會變成基礎設施! 目前最大的問題還是看不出有統一的protocol, 不過可以看到各家(AWS IoT/Mbed Cloud) 都有在推自己的安全連線設計的embedded OS 環境, 方便終端裝置直接連上它們的管理界面, 做資料收集, 估計Amazon 的FreeRTOS之後一樣會有Hypervisor 才是