從自動化到智能化:物聯網技術在轉轉智能質檢中心的應用
1. 背景
在轉轉智能質檢中心,隨著業務的不斷發展,自動化檢測硬件設備、以及設備端(手機、Pad 等)的自動化檢測能力越來越豐富。
下圖列舉了目前轉轉智能質檢中心的幾個自動化檢測設備
手機參數檢測設備和智能充電
外觀檢測
攝像頭檢測
NFC和震動檢測
音頻檢測
電池檢測
在前期發展過程中,各類自動化檢測能力的設計和開發,主要圍繞本身的功能來進行,缺少一個對整體自動化化程序的統一規劃和設計,管理維護和迭代成本都較高。
在這背景下,主要存在以下幾個問題:
- 系統維護成本高: 質檢自動化設備與其他設備的通信協議沒有做到很好的統一,各成體系。隨著業務的不斷發展,系統越發臃腫,開發和維護成本隨之增加。
- 設備狀態監控不足: 設備故障無法被及時發現,導致停機和維修成本增加。
- 數據延遲與不完整: 由于設備離線運行,數據的實時性和完整性難以保證。
- 設備維護成本高: 設備依賴人工維護,效率低下且成本高昂。
- 自動化能力集成設備越來越多,更需要穩定可靠的架構: 隨著業務發展和技術能力的突破,自動化能力建設已進步不單單是對硬件設備的調度,還不斷擴大到對針對被檢測設備(比如手機、Pad、筆記本等)的檢測能力調度。
綜上,筆者所在的團隊通過引入 物聯網(IoT) 技術,實現了自動化設備的智能化管理。通過物聯網技術,統一技術架構設計、降低開發維護成本的同時,完善自動化設備實時監控,來解決當下面臨的主要問題。本文將重點介紹物聯網技術選型和落地方案。
2. 物聯網介紹
2.1 開篇故事
在工作時渴望來一杯冰涼的咖啡提提神,但你每次走到樓下的咖啡店,卻發現咖啡店已經打烊或者心儀的咖啡已經售罄。是不是很失望?
20 世紀 70 年代末到 80 年代初,卡內基梅隆大學計算機科學系的研究人員也有同樣的煩惱,在工作時渴望喝一瓶冰涼的可樂,但每次走到樓下的自動售貨機,卻發現可樂已經賣完或者剛剛補貨還沒有冷卻。這導致他們頻繁地空跑,浪費了寶貴的時間和精力。
1982 年,幾位計算機科學系的學生,包括 Mike Kazar、David Nichols、John Zsarnay 和 Ivor Durham,決定通過互聯網解決這個問題。
他們在自動售貨機內安裝了微型開關,用于檢測每一列飲料的庫存狀態。這些開關連接到一臺計算機,通過互聯網向研究人員報告飲料的庫存和溫度狀態。
這臺聯網的可樂販賣機成為世界上第一臺連接到互聯網的設備,被認為是物聯網的早期雛形。
就這樣,這個項目啟發了后續的許多研究和發展,使得物聯網技術逐漸成熟,并應用到更廣泛的領域中,包括智能家居、智慧農業、智能制造等等。
2.2 物聯網是什么?
物聯網(IoT)是指通過傳感器、軟件和其他技術將物理設備連接到互聯網,使它們能夠相互通信和共享數據。例如,智能家居設備可以通過手機遠程控制,工業機器可以自動監測和報告運行狀態。
2.3 物聯網的基本組成
- 傳感器和設備: 采集數據并執行操作,如溫度傳感器、智能燈泡等。
- 網絡連接: 通過 Wi-Fi、藍牙、蜂窩網絡等方式將設備連接到互聯網。
- 數據處理和分析: 收集的數據通過云計算或邊緣計算進行分析,提供有價值的信息。
- 用戶接口: 用戶通過應用程序或控制面板與設備交互。
3 物聯網技術應用和選型方案
3.1 應用層協議選型
物聯網協議可以根據不同的層級和功能進行分類,包括設備層協議、網絡層協議、傳輸層協議、數據鏈路層協議和應用層協議等。這里主要介紹物聯網的應用層協議。
針對應用層協議,調研時參考了國內各云平臺的主流支持情況,從以下幾個方案中做了橫向對比:
3.1.1 HTTP/HTTPS
HTTP(超文本傳輸協議)和 HTTPS(安全超文本傳輸協議)是用于分布式、協作式和超媒體信息系統的應用層協議,廣泛應用于 Web 瀏覽和其他互聯網服務。
- 優勢:
- 標準化、通用性強,幾乎所有編程語言都有成熟的庫。
- HTTPS 提供加密,確保傳輸安全。
- 不足:
開銷大,實時性差,不適用于資源受限的設備。
通信開銷和延遲較高,不適合高頻率的小數據傳輸。
3.1.2 MQTT(Message Queuing Telemetry Transport)
MQTT 是一種輕量級的發布/訂閱消息傳輸協議,設計用于低帶寬、高延遲或不穩定的網絡。
- 優勢:
- 輕量級、高效,適合受限設備和低帶寬環境。
- 支持不同的服務質量(QoS)級別,確保消息的可靠傳遞。
- 發布/訂閱模式支持靈活的通信拓撲結構。
- 支持基于用戶名和密碼的簡單身份驗證,還可以使用 TLS(傳輸層安全)或 SSL(安全套接字層)來加密通信。
- 不足:
需要消息代理,增加了系統復雜性。
長連接,大規模場景下心跳包仍可能造成一定的網絡開銷。
3.1.3 CoAP(Constrained Application Protocol)
CoAP 是一種專為物聯網設計的協議,基于 UDP,適用于資源受限的設備和網絡。
- 優勢:
- 無連接、輕量級、低功耗,專為資源受限設備設計。
- 支持請求/響應模型,具有較好的實時性。
- 通過 UDP 傳輸,網絡開銷小,適合低帶寬和高延遲的網絡環境。
- 不足:
未建立在可靠的 TCP 上,可靠性和消息確認需要額外機制。
安全性需要額外考慮,通過 DTLS 實現較為復雜。
3.1.4 選型依據和結論
考慮在質檢過程中自動化設備以及質檢的 3C 產品都需要聯網,在設備數量達到一定程度時,核心關注點主要包括:
- 穩定性和可靠性:協議需要在復雜網絡環境中保持穩定的數據傳輸,確保系統的可靠性。
- 實時性:在質檢流程中,需要實時的數據傳輸和響應,以支持快速決策和即時反饋。
- 網絡成本:隨著設備數量的增加,網絡傳輸成本顯著提升,選擇輕量化的協議能夠有效降低成本。
方案評估:
- HTTP/HTTPS 在頻繁的數據交換過程中,協議包報文較大,網絡開銷大。
- CoAP 適用于資源受限的設備和網絡,如智能電表、燃氣表等數據上報的場景。不太適用于大規模雙向通信的場景。為了保障數據傳輸的安全性,通常需要通過 DTLS 來加密通信。自動化設備本身不是一個資源受限的設備。
- MQTT 由于協議足夠輕量適合低帶寬和高延遲的網絡環境,同時支持不同的 QoS 級別,確保消息的可靠傳遞和實時性。
綜上,MQTT 協議在協議包大小、穩定性、可靠性等方面都能夠滿足智能質檢中心的需求。尤其是在需要低延時和高可靠性的場景中,MQTT 憑借其輕量級和高效的特性成為最優選擇。因此,我們最終選擇了 MQTT 協議作為應用層協議。
3.2 Broker 選型
MQTT 消息代理(MQTT Broker)是 MQTT 協議中的核心組件,負責管理客戶端之間的消息傳遞。它在發布/訂閱模型中扮演中間人的角色,確保消息從發布者(Publisher)傳遞到訂閱者(Subscriber)。
當前,市場上有超過 20 個開源 MQTT Broker 項目,下面主要介紹 HiveMQ、 RabbitMQ 和 EMQX。
3.2.1 HiveMQ
HiveMQ 是一種企業級的 MQTT 消息代理,專注于高性能和高可靠性的物聯網(IoT)應用。
- 高可用
- 優勢:支持分布式集群部署,具有自動故障轉移和負載均衡功能,確保系統的高可用性。
- 不足:需要企業版才能獲得全套高可用性功能,免費版本功能受限。
- 安全性
優勢:支持 TLS/SSL 加密、身份驗證和授權,提供企業級安全特性,還支持 OAuth 2.0 和 X.509 證書。
不足:高級安全特性需要企業版支持。
易用性
優勢:提供直觀的管理控制臺,文檔詳盡,社區和企業支持非常強大。
不足:企業版價格較高,入門門檻較高。
3.2.2 RabbitMQ
RabbitMQ 是一個通用的消息代理,支持多種消息協議,包括 AMQP、MQTT、STOMP 等。
- 高可用
- 優勢:支持分布式集群部署、鏡像隊列和持久化,保證消息在系統故障時的可用性。
- 不足:配置復雜,集群管理和維護需要較高的運維經驗。
- 安全性
優勢:支持 TLS/SSL 加密、身份驗證和授權,提供細粒度的安全控制。
不足:安全配置較復雜,需要深入理解 RabbitMQ 的安全模型。
易用性
優勢:支持多種協議和插件擴展,功能非常豐富。
不足:初始配置和優化可能較為復雜,需要深入了解其架構。
3.2.3 EMQX
EMQX 是一種高性能、可擴展的 MQTT 消息代理,專為物聯網設計。
- 高可用
- 優勢:原生支持分布式集群和高可用性,能夠支持百萬級連接,自動故障轉移。
- 不足:配置復雜,集群管理需要一定的技術背景。
- 安全性
優勢:支持 TLS/SSL、LDAP、JWT 和 ACL 等安全機制,提供全面的安全保障。
不足:高級安全配置可能需要較高的學習成本。
易用性
優勢:提供豐富的插件和管理工具,支持可視化管理。
不足:配置和優化需要一定的技術經驗,尤其是在大規模部署中。
3.2.4 選型依據和結論
- HiveMQ:分開源版本和付費版本,開源版本基于 Java 語言開發,集群部署最大支持 5 個節點。僅支持使用用戶名和密碼進行身份驗證,不支持 TLS 加密,無法滿足高級別的安全認證。
- RabbitMQ:完全開源,核心使用 Erlang 語言開發,MQTT 支持是通過擴展實現的,因此 MQTT 功能相對而言不是原生的,這可能在性能上不如原生支持 MQTT 的 Broker。
- EMQX:分開源版本和付費版本,開源版本基于 ErLang 語言開發,集群部署最大支持 3 個節點。支持基本的用戶名和密碼認證的同時支持 TLS/SSL 加密和簡單的 ACL(訪問控制列表),滿足大多數中小型應用的需求。
綜上,EMQX 開源版本能滿足大多數中小型應用的需求,在高可用性、安全性、性能、成本和易用性等多個條件下均優于 HiveMQ 和 RabbitMQ,最終我們選擇的 EMQX 作為 MQTT 的消息代理。
3.3 QoS 消息質量選型
在 MQTT 協議中,消息質量(QoS, Quality of Service) 是一個關鍵概念,用于決定消息在傳輸過程中的可靠性。MQTT 定義了三種消息質量等級(QoS 0、QoS 1、QoS 2),它們分別適用于不同的應用場景。下面是對每種 QoS 等級的詳細分析,以及如何在實際應用中選擇適合的 QoS 等級。
3.3.1 QoS 0: 至多一次(At most once)
消息被發送一次,發送者不會要求確認消息是否被成功接收。消息可能會丟失。
- 優勢:網絡開銷最小,延遲最低。
- 不足:無法保證消息一定到達,適用于對數據可靠性要求不高的場景。
3.3.2 QoS 1: 至少一次(At least once)
消息至少會被送達一次,接收者需要確認接收到消息。如果發送者未收到確認,會重發消息,直到確認接收為止。
- 優勢:提供了較好的消息到達保障。
- 不足:可能導致消息重復,需要額外處理邏輯來消除重復影響。
3.3.3 QoS 2: 僅一次(Exactly once)
消息保證精確傳遞一次,不會重復或丟失。通過多步驟握手協議來確保消息到達。
- 優勢:提供最高的消息傳遞保障。
- 不足:需要更多的網絡開銷和處理時間,增加系統延遲。
3.3.4 選型依據和結論
在實際場景中,需要精確控制自動化設備完成一系列交互,自動化設備指令的重復執行都可能帶來嚴重后果(例如:機械手在夾持手機過程中重復執行操作可能導致手機損壞)。因此,我們在 MQTT 的三個消息質量選項中選擇了 QoS 2,具體原因如下:
- Qos 0 效率最高,但不保證消息的可靠性,可能導致消息丟失,不適合需要嚴格控制的場景。
- QoS 1 可以確保消息至少傳遞一次,但有可能導致消息重復,各端需要額外處理重復消息的邏輯,增加了開發和運維的復雜度。
- QoS 2 能夠確保消息僅傳遞一次,是最可靠的消息質量等級。盡管在網絡延遲上有所犧牲,但 PUBREC、PUBREL 和 PUBCOMP 報文大小僅為 4 個字節,使得延時在大多數情況下可以接受。選擇 QoS 2 可以讓開發人員更專注于應用邏輯,而無需過多擔心消息傳輸的可靠性問題。
綜上所述,QoS 2 是我們在嚴苛場景下的最佳選擇,能有效降低因消息重復而可能造成的風險,同時確保系統的高可靠性。
3.4 Broker 的部署方案
前面我們介紹了消息發布、消息中間件和消息質量的選型,接下來我們就要考慮該如何部署了。先簡單介紹一下背景:
- 云服務器:主要集中在華北地區。
- 智能質檢中心:全國各大區域均有分布。
在不考慮運營商、物理距離等其他外界環境影響的情況下,消息的延時可能會隨著消息量的增加而增加(正常情況下從華南到華北的網絡延時大概在 50 毫秒以上),因此提出了以下部署方案。
3.4.1 云服務器部署
將 MQTT Broker 部署在云服務器上,設備通過網絡連接到中心服務器進行消息傳遞。
- 優勢:Broker 可以做到統一管理,簡化了維護和監控。
- 不足:由于跨區域傳輸,可能會出現較高的消息延時,影響實時性。
3.4.2 本地部署
在智能質檢中心內部署,設備通過局域網連接到 Broker,處理當前質檢中心設備的消息傳遞。
- 優勢:消息傳遞幾乎是即時的。
- 不足:多個本地 Broker 需要分別進行管理和維護,增加了運維的復雜度。
3.4.3 混合部署(邊緣計算)
在智能質檢中心部署邊緣節點,處理當前質檢中心設備的消息傳遞。并與中央云服務器上的 Broker 同步數據,同時中央服務器還承載著沒有服務器資源站點的消息處理。
- 優勢:延時極低、有效減輕中心節點負載。
- 不足:在大規模部署時,邊緣節點的分散性可能增加管理的復雜性。
3.4.4 選型依據和結論
主要考慮的因素:
- 網絡延時:智能質檢中心的地域分布不均,比如華南到華北的網絡延時,如何部署 Broker 來減少延遲。
- 擴展性:未來智能質檢中心將有更多的自動化設備接入,因此系統需要具備良好的擴展能力。
方案評估:
- 云服務器部署:網絡延時較高,按照網絡延時 50 毫秒計算,單臺自動化設備完成一個完整流程可能增加約 2 秒的執行時間。
- 本地部署:消息延時幾乎為零,能夠顯著提高自動化設備的響應速度和實時性。
- 混合部署(邊緣計算):在保證低延時的同時,減輕中心節點的負載。
同時在云服務器和本地部署分別進行了以下壓測(因篇幅有限,這里僅展示不同客戶端連接數情況下消息質量 QoS 2 時報文大小為 1KB 的場景),結果如下:
壓測場景(客戶端連接數) | 本地部署延時 | 云服務器部署延時 |
10 | 6ms | 42ms |
100 | 7ms | 47ms |
1000 | 10ms | 57ms |
綜上,我們目前選擇了本地部署方案。本地部署方案能夠顯著降低延時,雖然管理上有一定挑戰,但能夠滿足當前的響應速度要求。
然而,隨著智能質檢中心自動化設備的增加,混合部署方案應該是未來的首選,即通過邊緣計算降低延時,并同步關鍵信息至中央服務器。這個方案能夠在延遲、管理難度和系統性能之間取得最佳平衡。
4 結語
通過本文的分析和討論,我們清楚地看到,物聯網技術在智能質檢中心中的應用,不僅成功地解決了傳統質檢方式中的多項難題,還為未來的業務發展提供了堅實的技術支撐。
首先,通過引入物聯網技術解耦了各端原本藕合的業務邏輯,統一了各端的通信協議。
其次,在應用層協議、MQTT Broker 的選型,以及 QoS 消息質量選擇的過程中,通過全面的對比和評估,選擇了最符合業務需求的技術方案。這些技術方案的落地實施,使得智能質檢中心能夠更加高效、穩定地運行。
最后,通過本地部署方案進一步優化了系統的響應速度和可靠性,后續我們將通過混合部署方案(邊緣計算)進一步有效地降低了因地域分布而帶來的網絡延時問題。這一部署方案,不僅滿足了當前的業務需求,也為未來的擴展和優化提供了廣闊的空間。
在轉轉,物聯網技術正推動著"智慧工廠"的崛起。物聯網實現了生產設備的互聯互通,使得生產過程更加透明化、自動化。未來,物聯網還將深化與人工智能、機器人技術的融合,開創智能制造的新篇章。