從自動化到智能化：物聯網技術在轉轉智能質檢中心的應用
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 消息質量選擇的過程中，通過全面的對比和評估，選擇了最符合業務需求的技術方案。這些技術方案的落地實施，使得智能質檢中心能夠更加高效、穩定地運行。
最后，通過本地部署方案進一步優化了系統的響應速度和可靠性，后續我們將通過混合部署方案（邊緣計算）進一步有效地降低了因地域分布而帶來的網絡延時問題。這一部署方案，不僅滿足了當前的業務需求，也為未來的擴展和優化提供了廣闊的空間。
在轉轉，物聯網技術正推動著"智慧工廠"的崛起。物聯網實現了生產設備的互聯互通，使得生產過程更加透明化、自動化。未來，物聯網還將深化與人工智能、機器人技術的融合，開創智能制造的新篇章。
