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