譯者 | 陳峻

審校 | 孫淑娟

在物聯網世界中，MQTT（消息隊列遙測傳輸協議）和OPC-UA（OPC統一架構）已經成為了在工業物聯網（IIoT）和工業4.0用例中，數據交換的開放協議和平臺獨立標準。而Apache Kafka的數據流用于實時集成和處理任何規模的、海量數據的數據中心。本文將探討Kafka和各種IoT協議之間的關系，何時該使用哪種技術，以及為何有時HTTP/REST是更好的選擇。最后，我們將探討兩個來自寶馬和奧迪的使用案例。

1.工業4.0數據流平臺通過連接設備來提高工廠的整體效率 

工業4.0和工業物聯網（IIoT）需要通過系統近乎實時地傳輸、處理、分析和提供數據。這會導致數據量的逐日攀升，并讓制造商面臨數據多樣化的挑戰。然而，使問題進一步復雜化的是，傳統的IT環境持續存在于各種制造設施中。這往往限制了制造商實現跨業務進行數據有效集成的能力。因此，大多數制造商都需要將數據復制和同步策略予以混合實施。目前，他們也正在從產品設計和制造到運維環節，努力提高其生產設施的整體設備效率（OEE）。與此同時，由于新冠疫情的流行和2021年蘇伊士運河的中斷，都會導致即時生產與供應鏈問題的凸顯。因此企業需要通過實時的流程和監控，在如下方面確保生產線的自適應能力：

• 準時（JIT）的預測
• 構建工廠的產能
• 人員配備與倒班狀況
• 原材料和產品價格的波動

通常，由設備產生的數據必須在生成之后立即被轉換，并在整個企業中可用，來體現數據被提取的最大價值，提高工廠的整體效率，進而避免嚴重故障。如今，寶馬和特斯拉之類的汽車制造商已經認識到了數據流平臺的潛力，正在利用Apache Kafka生態系統來流轉數據。可以說，數據流對于數據驅型制造公司的好處，不僅體現在數字化和自動化轉型上，還包括如下方面：

• 使生產過程更加高效
• 多快好省
• 盡量減少錯誤率

2.何時使用Kafka、MQTT和OPC-UA 

如前文所述，Kafka是一個出色的數據流平臺，可被用于大規模的實時消息傳遞、存儲、數據集成和處理。不過，Kafka并非包治百病，它未能實現如下方面：

• 數百萬客戶級別（如移動應用）的代理
• API管理平臺
• 用于復雜查詢和批量分析的數據庫
• 具有設備管理等功能的物聯網平臺
• 一種用于硬實時應用的技術

鑒于上述原因，Kafka需要通過與MQTT和OPC-UA的協同使用，來補齊短板。以近乎實時的方式，在工廠、公司、以及在全球范圍內，實現大量數據的處理和交換。

全球Apache Kafka和事件流用例

如上圖所示，Apache Kafka通常作為分散式數據流的數據網格節點，能夠集成各種系統，其中包括：邊緣、物聯網設備、以及業務軟件，并能夠獨立于底層基礎設施（如：邊緣、本地、公共、多云和混合云等）來執行。因此，開放、可擴展、以及靈活的架構對于與舊環境的集成，和利用現代化云原生應用都是至關重要的。由事件驅動的Apache Kafka等數據流平臺正好滿足了此類需求。它們收集相關傳感器的遙測數據、以及來自IT系統的數據，并在數據傳輸時，對其進行處理。這便是“動態數據”的概念。它區別于將事件存儲到數據庫中，以待日后查看的“靜態數據”。在物聯網用例中，我們通常認為處理靜態數據的是一種“過時的架構”。

3.使用域驅動設計和真正的解耦來進行分離 

其實，工廠的IT環境被建立在什么樣的基礎設施上并不重要。重要的是，新舊系統能夠實現數據的實時集成，能夠以解耦的方式維持數據的持續流動和消息存儲。而與其他消息系統（如IT領域的RabbitMQ、或物聯網領域中的MQTT）相比，Apache Kafka的域驅動設計（DDD）實現了背壓處理和數據可重放性的真正解耦，同時提升了高可用性和故障安全（fail-safe）性，這些都是生產環境中至關重要的。

用于工業物聯網MQTT和OPC UA的Kafka域驅動設計

4.OPC-UA、MQTT、HTTP與其他 

目前，開放且標準化的物聯網架構有三個通用的標準：OPC-UA（Open Platform Communications Unified Architecture，開放平臺通信統一架構）和MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸），這兩個是特定于物聯網的協議，另一個是簡單的REST/HTTP。當然，業界也有一些私有的特定協議。例如：Skynet的專有DataHub傳輸協議（DHTP，https://skkynet.com/iiot-protocol-comparison），以及開放標準的替代方案--AMQP等。下表展示了它們在特性上的比較：

工業物聯網協議的比較

5.評估物聯網協議的決策樹 

那么，哪一種更值得我們去選用呢？首先，需要強調的是，此類討論只有在您擁有選擇權的情況下才有意義。如果您在車間購買并安裝了一臺新機器或PLC，而僅提供特定接口，那么您只有用的份，沒有選擇可言。當然，不同領域的人員可能會有不同的選擇偏好。甚至有人會從TCO和ROI的角度，認為專有方案會是更好的選擇。而總地說來，對于不同的物聯網協議，我的建議是：盡可能地使用開放標準，甚至可以按需將它們組合到一起。下面，讓我們來看一個簡單的、如何在OPC-UA、MQTT、HTTP和其他專有的工業物聯網協議之間，做出選擇的“決策樹”：

MQTT、OPC UA、HTTP REST的工業物聯網決策樹

讓我們來討論一下上面的決策樹：

• HTTP/REST非常適合簡單的用例（盡可能地保持簡單）。HTTP的易懂易用特性，幾乎適用于任何場景。它不需要額外的工具、API或中間件，而且其通信是同步式的“請求-響應”。如果您能夠采用HTTP（S）的80或443端口，而不是其他TCP端口的話，還能順利地得到安全團隊的協助。當然，HTTP屬于單向通信。例如，聯網的汽車需要一個HTTP服務器，來獲取從云端推送的數據，它們會使用pub/sub。
• MQTT非常適合于連接著數萬或數十萬臺設備，使用有限的帶寬和間斷性網絡的場景（如，聯網汽車的基礎設施）。其通信是使用MQTT代理作為中間人的異步發布與訂閱。MQTT不使用標準的數據格式，但是開發人員可以使用Sparkplug作為構建附加的組件。MQTT非常輕量級，其服務質量（QoS）、遺囑式功能，開箱即用地解決了物聯網用例的各種要求。同時MQTT非常適合雙向通信（如，聯網汽車<-->云通信）等IT用例。此外，LoRaWAN和其他低功耗的廣域網都非常適合MQTT。
• OPC-UA非常適合工業自動化（如，生產線上的機器）。今天的通信通常是客戶端/服務器，但也支持發布/訂閱。它使用標準數據格式，并提供豐富、強大、復雜的功能、組件、以及行業特定數據格式集。OPC-UA非常適合OT與IT相集成的場景。OPC UA的TSN（time-sensitive networking，時間敏感網絡）是一個可選組件。它是一種以太網通信標準，可以提供開放、確定性、以及硬實時（hard real-time）通信。
• 專有協議適用于那些基于標準化的實現無法解決的特定問題。這些協議通常是瑕瑜互見。它們在帶來強大的高性能的同時，往往也比較昂貴且帶有局限性。

如前文所述，我們在OPC-UA、MQTT和其他協議之間進行選擇時，并不是非此即彼的。在許多工業案例中，我們可以將OPC-UA和MQTT同時用于現代化應用中，取長補短，讓每種協議都發揮其出色的作用，從而讓老舊的應用和專有的SCADA系統、或其他歷史遺留數據與專有中間件相集成。

6.MQTT、OPC-UA和Kafka之間的集成 

在將MQTT、OPC-UA和Kafka的集成過程中，我們通常會涉及到如下設備與組件：

Kafka Connect連接器：可以實現協議級別的原生Kafka集成。Confluent Hub（https://www.confluent.io/hub/）可以作為它的替代方案。一些企業往往會構建他們自定義的Kafka Connect連接器。

自定義集成：通過低級別的MQTT/OPC-UA API（如，使用Kafka的HTTP/REST代理）或Kafka客戶端（如，用于Windows環境的.NET/C++）進行集成。

開放的第三方物聯網中間件：通用的開源式集成中間件（如，帶有IoT連接器的Apache Camel）、特定于IoT的框架（如Apache PLC4X或Eclipse Ditto），或基于標準API的專有第三方IoT中間件。

商業化物聯網平臺：適合現有的歷史遺留部署，并能夠起到“膠合”代碼與協議作用（如Modbus、西門子S7等）。傳統的歷史數據、專有協議、單體架構、有限的可擴展性、ETL批處理平臺都非常適合采用商業化物聯網平臺，在內部部署和云服務之間架起一座橋梁。

7.使用OPC-UA或MQTT去連接機器與設備 

雖然OPC UA和MQTT并非為數據處理和集成而設計，但是它們的優勢在于實時建立與設備、機器、PLC、物聯網網關或車輛之間的雙向“最后一英里”通信。如上文所述，這兩種標準有著不同的側重點，可以被結合起來使用。目前，幾乎所有的現代化機器、PLC和智能工廠的物聯網網關都可以支持OPC-UA。而MQTT主要被用于較差的網絡、以及大規模的設備場景中。數據流往往通過連接器流入數據流平臺。此類平臺既可以與“邊緣”的物聯網平臺并行部署，也可以被組合到混合云的場景中。作為靈活的數據中心，數據流平臺可以在OT和IT應用之間進行數據的集成和處理。除了OT端的OPC-UA和MQTT，無論是在邊緣、本地、還是在云端，MES、ERP、CRM、數據倉庫、以及數據湖等IT應用都是實時連接的。

Apache Kafka作為具有MQTT和OPC UA的開放式可擴展歷史數據庫（https://www.kai-waehner.de/blog/2020/04/21/apache-kafka-as-data-historian-an-iiot-industry-4-0-real-time-data-lake/）

8.用于開發和預測仿真的數字孿生 

通過持續地以流式傳輸數據，以及處理和集成傳感器的數據，數據流平臺能夠創建一個開放、可擴展且高度可用的基礎架構，并用于部署數字孿生。

數字孿生結合了物聯網、人工智能、機器學習和其他技術，旨在創建物理組件、設備和流程等虛擬模擬。通過參考歷史數據，數字孿生也可以在物理對應物所生成的數據發生變化時，立即進行自我更新。通常，Kafka可與其他技術相結合，以構建數字孿生。例如，Eclipse Ditto是一個將Kafka與IoT協議相結合的項目。一些團隊也會使用Kafka和MongoDB等數據庫，定制數字孿生。

Apache Kafka助力工業 4.0和工業物聯網的數字孿生

如上圖所示，在工業4.0中，機器操作員可以通過數字孿生，詳細了解其模擬或監控的元素的生命周期，不斷優化產品和流程，測試單個部件或整個系統的功能和性能，進而對能耗和磨損進行預測。

9.狀態監測和預測性維護 

在現代化維護中，機器操作員往往需要及時了解到：所有設備是否能按照預期運行？在需要進行維護工作之前，這些設備通?？梢赃\行多長時間？異常和錯誤的原因是什么？

一方面，他們需要依賴可靠且可擴展的基礎架構，以支持數據流的處理、分析和集成，進而實時地檢測出諸如：嚴重的溫度波動或振動等關鍵性指標，以便采取措施，保障工廠的生產效率。另一方面，數字孿生可以通過監測和診斷，將當前傳感器捕捉到的數據與歷史數據相關聯，從而識別故障的原因，方便采取預測性的維護措施。而最重要的是，通過確保設備和設施僅在必要時得到維修，他們可以更加有效地實施預測性維護計劃，既做到為制造型企業節省寶貴的資源，又可以避免代價高昂的停機時間。

使用Apache Kafka的ksqlDB和TensorFlow進行狀態監控和預測性維護（https://www.kai-waehner.de/blog/2021/10/25/apache-kafka-condition-monitoring-predictive-maintenance-industrial-iot-digital-twin/）

10.聯網汽車和流式機器學習 

聯網汽車是可以與車外其他系統進行雙向通信的汽車。它實現了汽車與車內、車外的各種設備和應用共享互聯網上的訪問和數據。而前面提到的MQTT與Kafka相結合的方式，便可以服務于聯網汽車及其基礎設施的用例。

下圖展示了Kafka如何與數萬、甚至數十萬個物聯網設備相集成，并實時地處理數據。在聯網汽車的基礎設施中，該流程可以自動化地進行預測性防護（即異常檢測），以及預測發動機的故障：

Kappa架構、Kafka MQTT的Kubernetes和Tensorflow用于流式機器學習

11.寶馬案例研究使用智能工廠和云服務實現制造4.0 

讓我們從技術角度來探討一下，寶馬是如何成功地將Kafka和OPC-UA作為邊緣設備和云端應用之間的實時數據中心。在實施之前，寶馬希望達到的目標是：

• 在不影響其他服務的情況下，獲取IoT數據，并將其傳輸到正確的位置
• 一次收集，多次處理和消費（不同的消費端在不同的時段，使用不同的通信范式，如：實時、批處理、請求-響應）
• 實現可擴展性的實時處理，并縮短上市的時間

寶馬團隊通過使用OPC-UA連接器，直接與Azure中的Confluent Cloud進行通信，成功地將其全球智能工廠的負載相連接，并在公共云中實現了實時復制。其中，作為消息傳遞平臺的Kafka提供了不同接口之間的真正解耦、透明化和數字創新。而Confluent通過產品和專業知識，增加了制造系統的穩定性。此外，實時優化的供應鏈管理方案也提供了有關物理上、以及ERP系統中的正確庫存信息。

 12.奧迪案例研究

 采用群體智能（Swarm Intelligence）的聯網汽車 

奧迪使用Apache Kafka構建了聯網汽車的基礎設施。他們在Kafka峰會上分享并探討了其用例和架構。

他們構建了實時數據分析、群體智能、合作伙伴協作、以及預測性AI，實現了聯網汽車的所有傳感器數據，經過實時處理與存儲，用于歷史分析和實時報告的一整套流程。

13.題外話 

如果網絡基礎設施的連接性允許您在自己IoT項目中使用“無服務器Kafka”的話，那么您也可以像上述寶馬的案例那樣，利用Confluent Cloud在全球推廣智能工廠，用“無服務器Kafka”來處理和集成數據流。通過無服務器數據流，您可以更加專注于物聯網業務的應用，并提高設備綜合效率（OEE）。原文鏈接：https://dzone.com/articles/opc-ua-mqtt-and-apache-kafka-the-trinity-of-data-s

譯者介紹

陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗；持續以博文、專題和譯文等形式，分享前沿技術與新知；經常以線上、線下等方式，開展信息安全類培訓與授課。