文末福利:開發者藏經閣

一、背景

工業互聯網是近年工業領域的熱門話題,不只是它被列入國家層面的戰略計劃,更是工業製造轉型的必要需求。工廠數字化是未來工業的價值所在,工業互聯網則是數字化轉型實現的形式和必經之路。

工廠的數字化方案極爲關鍵的一部分是將各類工廠線下數據標準化接入上雲,其中工廠數據包含貨品、原料、庫存、生產計劃、生產進度、訂單、大盤等各式各樣的數據信息,如何將這些紛亂的數據以標準格式低成本、快速地接入到雲平臺,是當下面臨最關鍵的問題,本文將介紹一套搭載動態化腳本引擎的數據設備網關軟硬一體化方案,幫助工廠數據低成本快速上雲。

二、痛點

如上文所描述,我們的目標是將各個工廠紛亂複雜的工廠數據藉助設備網關以標準化格式接入到雲端數據平臺,其中我們就遇到來如下3個問題。

問題現狀

1)數據源接口種類繁多:不同工廠規模化與信息化程度不同,有些大廠擁有自己的ERP系統,我們的設備可以通過TCP/HTTP等網絡協議與其對接,而很多依靠人工管理的小廠只有幾臺機牀,我們只能通過Modbus/UART/CAN等硬件總線與機牀設備對接,採集生產數據。

2)廠家私有協議氾濫:部分具有信息化管理能力的工廠,在ERP系統通過私有協議對生產過程進行管理,而更多時候我們無法直接從ERP獲取詳細的生產數據,需要我們從私有協議中提取有效信息。但我們面臨的現狀是各個工廠私有協議五花八門,沒有統一的規律。

3)數據格式標準缺失:在工廠數據採集過程中,我們會面對不同層次的數據,從ERP歸類的頂層數據到底層機牀輸出的字節流源數據,我們需要對這些紛亂的數據過濾清洗、歸類整理,封裝成標準的數據格式接入到我們的數據平臺。

鑑於以上的問題現狀,開發人員將直面以下3個難點。

難點

1)開發成本高:IOT設備端搭環境、反覆編譯燒錄費時費力;單進程應用,硬件驅動與數據協議轉換邏輯耦合,遇到一種數據源開發一種,存在很多重複勞動。

2)人員要求高:開發人員需要了解行業、廠家協議與數據接入;代碼層面需要懂從底層到上層應用全鏈路嵌入式開發,同時熟悉各類網絡及硬件協議。

3)運維成本高:無法線上運維,IOT設備出異常需出差到工廠現場;每種數據源對應一個設備固件,管理工作量大;固件升級、批量操作手工完成,費時費力。

三、技術方案

NO.1

動態化解決方案

如上圖所示,本文提出一套以設備端動態化腳本引擎爲主、涵蓋前端、後端的全鏈路的設備控制檯軟硬一體解決方案,其主要包含應用管理、在線調試、狀態監控、雲端運維等功能,核心在於用腳本語言編寫業務邏輯,降低設備端開發與運維的成本。

核心內容

1)建設通信鏈路:基於雲端RPC,建設通信鏈路,將設備端能力透出到雲端頁面。

2)抽象設備硬件能力:如外設配置、開啓/關閉、數據讀/寫,並按一定格式JSON協議透出。

3)腳本語言編寫業務邏輯:基於已抽象的硬件能力與JSON協議,編寫算法/業務邏輯並輸出結果。

4)應用容器化:從雲端頁面下發腳本應用,全程管理應用生命週期,如同手機APP一般管理各個應用。

方案優勢

1)降低開發成本:根據設備能力,封裝主流硬件總線能力,C/C++主程序固化複用,無需反覆修改;工廠源數據轉換由腳本應用完成,一種接入一個腳本,代碼量少,動態性好,無需反覆編譯燒錄,雲端下發管理腳本應用;硬件透明化,開發門檻低,硬件與業務開發分離,懂腳本就能完成協議適配開發。

2)降低運維成本:設備能力前端頁面透出,解決非屏類設備交互困難問題;雲端控制檯,支持異地運維,無需出差現場;支持一鍵式應用升級、批量管理。

頁面展示

上圖展示的是設備端在阿里雲IOT Pass的基本信息,我們可有看到設備的在線情況、固件版本、激活時間、IP地址等等。

上圖展示的是設備端的雲端控制窗口,雲端控制部分有3個功能,第一個RPC-Shell可以看作是一個簡易的終端窗口,我們可以遠程執行shell命令並返回其結果,當然其執行權限必需安全可控;第二個功能是雲端推送mqtt消息至設備端,方便雲端mock消息到設備端進行聯調;第三個功能是遠程ssh,常規ssh只能訪問無公網IP的局域網設備,而開啓遠程後我們可以在任意網絡環境,通過密鑰保護的ssh鏈接,開啓web-shell遠程ssh登陸到該設備,方便了設備的異地運維。

上圖展示的是設備端應用管理,包含腳本應用添加下發、應用開關、日誌查看、應用更新、代碼查看等功能,每個應用信息存儲在設備端,在web端以卡片形式展示並提供相應的UI交互,腳本應用持續運行在設備端,將工廠端原始數據清洗過濾後轉爲標準格式數據,上報到雲端。

C/C++主程序封裝了各類硬件總線並基於local mqtt以JSON協議透出,腳本應用可通過local mqtt對硬件總線進行配置開啓,然後腳本便能從local mqtt獲取到硬件總線讀取的數據,進行清洗與協議轉換後,輸出給網關讓其轉發上雲。

上圖展示的是設備端的狀態監控,目前我們將設備端的網絡、進程、網卡、內存與外存信息透到web端,開發與運維的同學可以隨時查看當前的設備運行狀態。

四、技術思考

我們再來看上面這張圖,除了彩色部分的外設與業務邏輯是根據場景而變化,其他灰色的模塊都是中性化不帶業務屬性的,因此這套動態化架構的大部分能力是可複用的,以下是此架構方案的個人思考與實踐。

思考與實踐:

思考1:其他非工業領域的IOT場景能否複用此架構?

Yes,全場景覆蓋!先前雲棲大會項目套用此架構,核心的算法業務邏輯代碼僅100多行,以上2個是非常典型的IOT場景化應用的例子,分別爲持續化算法檢測與持續化反饋控制的場景。

思考2:腳本引擎是否有限制?

理論上,只要支持mqtt的輕量化腳本均能適配,如node.js、python、lua、php等。

思考3:此方案最大的難點在哪?

設備端硬件能力抽象與應用全週期管理。

思考4:是否有劣勢?

進程間通信的延遲與系統資源的消耗。目前在NXP的imx6ul單核芯片平臺上,一個node應用內存消耗10-20M(2%-4%),CPU佔用3-4%,進程間通信延遲1-2ms。

思考5:技術架構能否輸出?

Yes,根據業務方開發資源的不同,能以設備端、設備端+服務端SDK、設備端+服務端SDK+前端多種形式輸出。

五、未來展望

設備交互友好化

安卓系統讓帶屏的設備交互變得友好,而非屏類設備用雲控制檯頁面代替屏幕進行隨時隨地交互。

開發過程輕量化

IOT開發需要降低開發成本與入門門檻,我們需要儘可能減少搭建環境、編譯打包、串口調試、固件升級等費時費力的操作,讓更多新手低成本入手IOT開發,開箱即用。

輸出與推廣?

目前以快速支持工廠數據標準化接入業務爲主,根據需求支持其他線下業務。後續能否考慮打造一款類似天貓精靈、樹莓派的小而美的硬件,搭載動態化架構引擎,以社區化形式推廣,讓更多人體驗IOT開發的樂趣,這點值得探討。

推薦閱讀

一種高性能的Tree組件實現方案

VS Code 源碼分析 - 多語言實現

揭祕手淘召喚術| 幫助千萬級用戶直達手淘的黑科技

文末福利

關注後回覆“藏經閣”

喜歡就點在看哦〜

相關文章