從自動化到智慧化:物聯網技術在轉轉智慧質檢中心的應用

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 訊息品質選擇的過程中,透過全面的比較和評估,選擇了最符合業務需求的技術方案。這些技術方案的落地實施,使得智慧質檢中心能夠更有效率、穩定地運作。

最後,透過本地部署方案進一步優化了系統的響應速度和可靠性,後續我們將透過混合部署方案(邊緣運算)進一步有效地降低了因地域分佈而帶來的網路延遲問題。這項部署方案,不僅滿足了當前的業務需求,也為未來的擴展和最佳化提供了廣闊的空間。

在轉轉,物聯網技術正推動著"智慧工廠"的崛起。物聯網實現了生產設備的互聯互通,使得生產過程更加透明化、自動化。未來,物聯網也將深化與人工智慧、機器人技術的融合,開創智慧製造的新篇章。

5 參考鏈接