編者按：由于開發人員需要等待新設備的硬件實施，因此嵌入式應用開發項目通常會出現延遲。工業物聯網 (IIoT) 應用開發面臨類似的瓶頸，需要等待基于機器學習方法的工業預測維護系統或設施自動化系統等應用所需的傳感器數據。本系列文章由兩部分組成，將會探討哪些替代方法能提供所需的早期數據流，以加速工業物聯網應用開發。本文是第 1 部分，介紹了如何使用模擬方法生成那些數據流。第 2 部分討論了有哪些選項可用于對傳感器系統進行快速原型開發，以生成數據。

大規模工業物聯網 (IIoT) 應用帶來了諸多挑戰，這些挑戰可能會使部署停滯，并讓公司對所需要的眾多實施資源的投資回報率產生質疑。為防止此類情況并幫助開發人員更快地明確工業物聯網部署的優勢，就需要即時訪問數據進行部署模擬。

若使用模擬方法生成現實的數據流，開發人員在物聯網網絡部署之前就可以順利開始工業物聯網應用開發，甚至可以完善工業物聯網傳感器網絡本身的定義。

本文將說明各種物聯網云平臺如何提供數據模擬，并將介紹 Multi-Tech Systems Inc. 的示例網關，這些產品有助于進一步加快部署。

工業物聯網數據的模擬案例

當然，使用模擬數據來推動應用和系統開發并不是什么新鮮事物。數十年來，開發人員一直使用系統級模擬方法對計算基礎設施和連接服務進行壓力測試。這些測試在驗證靜態配置的穩健性方面起著重要的作用。在云服務平臺中，這些測試提供了一種相對簡單的方法，來驗證虛擬機和其他云資源的彈性伸縮功能。

工業物聯網應用具有相同甚至更多的需求。除了幫助進行負載測試和彈性伸縮外，數據模擬還提供了一個重要工具，可用于驗證許多不同服務和資源的集成，而這些服務和資源需要用于實現像企業級工業物聯網應用這樣復雜的軟件。除了這些更基本的實踐之外，對于基于領先云提供商的復雜服務平臺構建的復雜工業物聯網應用，數據模擬還可以加快相關開發工作。

軟件角度

工業物聯網應用在復雜的架構上運行，這種架構在應用軟件開發人員與傳感器和執行器系統開發人員看來明顯不同。對于后者，大規模的工業物聯網架構是傳感器和執行器的龐大組合，它們與作為整個應用主體的物理過程相交互。對于應用軟件開發人員而言，企業級工業物聯網架構包含許多服務，這些服務的協調活動最終可以提供應用的功能。

從應用軟件的角度來看，Microsoft 的 Azure 物聯網參考架構提供了典型工業物聯網應用（和一般物聯網應用）的代表性視圖。此視圖總結了多種功能性服務，典型應用在云中將這些服務聚合在一起，以基于來自端點和外圍邊緣設備的數據提供見解和操作（圖 1）。

圖 1：Microsoft 的 Azure 物聯網參考架構說明了工業物聯網應用通常需要多種類型的云服務和資源，以根據外圍設備網絡生成的數據提供有用的見解和操作。（圖片來源：Microsoft Corp.）

特定的應用解決方案以適當的組合部署這些云資源，通過標準化的交換機制在功能上進行連接，并按應用邏輯進行協調。例如，在聯網汽車解決方案中，Amazon Web Services (AWS) 顯示了如何在負責提供不同應用功能的模塊中混合搭配云服務（圖 2）。

圖 2：AWS 聯網汽車解決方案提供一個代表性視圖，顯示了典型大規模物聯網應用如何協調云服務來提供所需的功能。（圖片來源：Amazon Web Services）

正如這些代表性架構所示，創建工業物聯網應用所需的軟件開發工作與實施傳感器和執行器系統的外圍網絡一樣具有挑戰性和廣泛性。很少有組織可以等到設備網絡能夠生成足夠數據后，再開始延遲開發此復雜軟件。實際上，隨著分析專家和機器學習專家開始處理應用結果，設備網絡的部署可能需要等待進一步的定義和完善。在最壞的情況下，設備網絡部署和軟件開發會陷入僵局：彼此依賴于對方的結果。

幸運的是，這一難題的解決方案在于物聯網架構的本質。除了一些廣泛的相似性之外，云服務架構（例如上面來自 Microsoft 和 AWS 的圖示架構）一定在細節上會有所不同。盡管如此，它們都展示了通常在物聯網云平臺中所見的類似架構特征：定義明確的接口服務模塊或層功能，可將物聯網設備的外圍網絡與基于云的軟件應用分開。除了提供統一的連接性之外，對于設備管理和安全性以及大規模工業物聯網應用所需的其他關鍵功能，這些接口服務也至關重要。

在 Microsoft 的 Azure 云中，此接口服務稱為 Azure IoT Hub（同樣參見圖 1）；在 AWS 云中，它是 AWS IoT Core（同樣參見圖 2）。在 Google Cloud Platform 中，此接口是 Cloud IoT Core，在 IBM Cloud 中，則是 IBM Watson IoT Platform 服務。類似地，其他平臺（如 ThingWorx 物聯網平臺）也通過連接服務（如 ThingWorx Edge Microserver、ThingWorx Kepware Server 或協議適配器工具包）進行連接。簡而言之，任何云平臺都需要提供可將數據從外設集中到云服務的一致接口服務，否則就要冒著從外設直接連接到云深處各個資源的混亂風險。

注入模擬數據

使用每個物聯網平臺的軟件開發工具包 (SDK)，開發人員可以按照驗證應用功能和性能所需的數量、速度和種類，將模擬的傳感器數據直接注入平臺的接口服務中。以所需速率和分辨率生成的模擬數據使用 MQ 遙測傳輸 (MQTT)、受限應用協議 (CoAP) 等標準協議到達該接口服務。對于接口服務（和下游應用軟件）而言，模擬數據流與硬件傳感器系統獲取的數據沒有什么區別。當設備網絡準備上線時，它們的傳感器數據流僅需替代到達接口服務的模擬數據流。

云平臺提供商通常在不同的功能級別上支持這種數據模擬方法。例如，Google 演示了一個使用參考架構和示例代碼的簡單仿真驅動應用，該應用實現了一個溫控風扇的簡單控制回路。像之前圖示的架構一樣，該架構利用了由 Google Cloud IoT Core 服務接口饋送的 Google Cloud Platform 服務（圖 3）。

圖 3：在任何物聯網云平臺中，設備模擬器都使用物理設備所使用的相同通信協議將數據饋送到接口服務，例如此處顯示的 Google Cloud Platform 應用架構的 Google Cloud IoT Core。（圖片來源：Google）

在此樣例應用中，溫度傳感器設備模擬器以選定的更新速率生成數據，并使用 MQTT 信息傳輸協議將數據傳遞到 Google Cloud IoT Core 接口服務。相應地，該接口服務使用平臺的標準發布-訂閱 (pub/sub) 協議將數據傳遞到模擬服務器，該服務器通過命令進行響應以按需打開或關閉風扇（圖 4）。

圖 4：Google 樣例應用演示了一個基本控制回路，其中包括一個模擬設備，該設備使用標準通信方法通過 Google Cloud IoT Core 將數據發送到模擬服務器。（圖片來源：Google）

Google 提供了實現此基本應用的 Python 代碼示例。在此代碼中，Device 類實例包括一種根據模擬風扇的狀態更新模擬溫度的方法。主例程以指定的速率調用該方法，并使用 Eclipse paho-mqtt Python MQTT 客戶端模塊提供的 MQTT 連接服務發送數據（清單 1）。

復制 class Device(object):      """Represents the state of a single device."""      def __init__(self):          self.temperature = 0          self.fan_on = False          self.connected = False       def update_sensor_data(self):          """Pretend to read the device's sensor data.         If the fan is on, assume the temperature decreased one degree,         otherwise assume that it increased one degree.         """          if self.fan_on:              self.temperature -= 1          else:              self.temperature += 1 ...def main(): ...     device = Device()         client.on_connect = device.on_connect      client.on_publish = device.on_publish      client.on_disconnect = device.on_disconnect      client.on_subscribe = device.on_subscribe      client.on_message = device.on_message         client.connect(args.mqtt_bridge_hostname, args.mqtt_bridge_port)         client.loop_start()         # This is the topic that the device will publish telemetry events      # (temperature data) to.     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)         # This is the topic that the device will receive configuration updates on.     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)         # Wait up to 5 seconds for the device to connect.     device.wait_for_connection(5)         # Subscribe to the config topic.     client.subscribe(mqtt_config_topic, qos=1)         # Update and publish temperature readings at a rate of one per second.     for _ in range(args.num_messages):          # In an actual device, this would read the device's sensors.Here,          # you update the temperature based on whether the fan is on.         device.update_sensor_data()             # Report the device's temperature to the server by serializing it          # as a JSON string.         payload = json.dumps({'temperature': device.temperature})          print('Publishing payload', payload)          client.publish(mqtt_telemetry_topic, payload, qos=1)          # Send events every second.         time.sleep(1)         client.disconnect()      client.loop_stop()      print('Finished loop successfully.Goodbye!')

清單 1：來自 Google 樣例應用的這個代碼片段說明了 main 例程如何定期更新 Device 類實例，該實例可存儲模擬溫度傳感器的當前值，并提供一種根據模擬風扇的狀態更新該值的方法。（代碼來源：Google）

反過來，Server 類實例提供了一個模塊，可根據從 Device 類實例接收到的溫度數據來更新風扇狀態（清單 2）。

復制 class Server(object):      """Represents the state of the server."""...     def _update_device_config(self, project_id, region, registry_id, device_id,                                data):          """Push the data to the given device as configuration."""         config_data = None          print('The device ({}) has a temperature '                'of: {}'.format(device_id, data['temperature']))          if data['temperature'] < 0:              # Turn off the fan.             config_data = {'fan_on': False}              print('Setting fan state for device', device_id, 'to off.')         elif data['temperature'] > 10:              # Turn on the fan              config_data = {'fan_on': True}              print('Setting fan state for device', device_id, 'to on.')         else:              # Temperature is OK, don't need to push a new config.             return

清單 2：在 Google 樣例應用程序的這個代碼段中，Server 類中定義的 _update_device_config() 方法為應用提供了業務邏輯，當溫度超過定義值時將風扇狀態設置為打開，而當溫度降低時將風扇狀態設置為關閉。（代碼來源：Google）

除了 Google 的示例代碼外，開發人員還可以在 GitHub 等存儲庫中找到數十個開源物聯網設備、系統和網絡模擬器。例如，Microsoft 的開源 Raspberry Pi 系統模擬器代碼包括與 Azure IoT Hub 的預置集成，用于快速開發與 Raspberry Pi valuation-boards-embedded-mcu-dsp/786?k=raspberry+pi&v=1690&pv1989=0&FV=-8%7C786&nstock=1">板對接的云應用。此外，Node-RED 等代碼較少的編程工具也支持預置模塊（節點），用于將模擬傳感器數據饋送到領先的云平臺物聯網服務接口。使用這些方法，開發人員可以輕松生成傳感器數據流。

規模運行模擬

使用設備級模擬器和相關工具的困難在于，管理數據模擬本身就會成為一個項目。像任何應用一樣，要運行模擬器，開發人員需要配置和維護資源。更令人擔憂的是，用于生成真實數據的設備模型會成為工業物聯網應用開發流程之外的一個單獨項目。隨著開發的進行，開發人員需要確保設備模型在功能上與工業物聯網設備網絡和應用定義的任何變化保持同步。對于企業級工業物聯網應用，開發人員會發現，擴展這些模擬最多可能會很困難，甚至會開始耗費開發應用所需的資源。

大型物聯網云平臺提供商使用物聯網設備模擬解決方案來解決這些問題，這些解決方案設計為可像它們各自平臺中的其他云資源一樣輕松伸縮。例如，AWS IoT Device Simulator 為其 CloudFormation 配置服務提供了一個 AWS 模板，該模板可部署虛擬專用網絡，用于連接在 AWS Fargate 無服務器引擎上運行的容器中實現的微服務（圖 5）。

圖 5：AWS IoT Device Simulator 組合了多個 AWS 服務，以將可伸縮的設備數據流提供給物理設備使用的同一 AWS IoT Core。（圖片來源：Amazon Web Services）

開發人員可以通過在 Amazon S3 服務中運行的圖形用戶界面 (GUI) 控制臺以交互方式訪問模擬，也可以通過由 Amazon API Gateway 服務中的 CloudFormation 模板生成的 IoT Device Simulator 應用編程接口 (API) 以編程方式訪問模擬。在模擬運行期間，IoT Device Simulator 微服務根據自身的配置項目中描述的總體模擬計劃，從 Amazon DynamoDB NoSQL 數據庫中提取設備配置。

這些設備配置是 JSON 記錄，用于定義設備屬性名稱（例如溫度）、數值范圍（例如 -40 至 85）以及更新設備間隔和模擬持續時間等信息。開發人員可以通過控制臺以交互方式或通過 API 以編程方式添加設備類型。通過使用常規 DevOps 方法，可以快速擴展設備類型、配置和基礎設施，以實現到達 AWS IoT Core 和下游應用所需的數據更新率。

在 Azure 設備模擬器中，開發人員可以進一步使用模擬運行期間設備支持的一組行為，以及云應用可以直接調用的一組方法，來補充基本屬性列表。

數字雙胞胎

這種設備數據模擬在概念上與商業物聯網云平臺中興起的數字雙胞胎功能緊密相關。相比通常僅提供設備狀態靜態表示的設備影子，數字雙胞胎可擴展虛擬設備模型，使其符合物理設備狀態及其行為。

在 Microsoft 的 Azure 中，Azure Digital Twins 服務允許開發人員包括用戶定義的函數，以定義設備模擬期間的行為，并且仍像以前一樣將結果饋送給 Azure IoT Hub。無論傳入的數據是模擬數據還是真實數據，之后都將發送到事件路由服務，以在應用中進一步分發。此外，Microsoft 還會使用數字雙胞胎數據創建空間圖，以描述復雜分層環境（例如，包含多個網絡的工業自動化系統）中元件之間的交互作用和狀態（圖 6）。

圖 6：Microsoft 的 Azure Digital Twins 服務使開發人員能夠構建在功能和特性上與對應物理設備相符的虛擬設備，并提供復雜服務（例如復雜工業物聯網層次結構的空間圖）的基礎。（圖片來源：Microsoft）

對于工業物聯網應用，數字雙胞胎可以提供一種強大的機制，能夠在整個生命周期中支持圍繞這些功能構建的應用。在開發的早期階段，平臺的設備模擬服務可以成規模地驅動數字雙胞胎。當物理工業物聯網網絡上線時，可以用設備數據饋送代替那些向數字雙胞胎發送的模擬數據饋送。稍后，在完全部署的工業物聯網應用中，開發人員可以使用在物理設備與數字雙胞胎之間發現的任何差異作為預測維護算法或安全入侵檢測器等的額外輸入。在整個生命周期中，數字雙胞胎可以保護應用免受網絡中斷或工業物聯網設備網絡配置重大變更的影響。

物聯網平臺中數字雙胞胎的出現還帶來了第二個好處，即提供一種標準化方法來描述設備模型的屬性和行為。對于描述語言，Microsoft 的 Azure Digital Twins 服務使用 JSON-LD（鏈接數據的 Javascript 對象表示法）。JSON-LD 背后有萬維網聯盟 (W3C) 支持，并基于行業標準 JSON 格式提供一種標準格式來序列化鏈接數據，該格式已在許多其他應用領域中使用。

隨著傳感器和執行器的預置數字雙胞胎描述存儲庫的出現，標準化的數字雙胞胎描述可以進一步加快開發速度。例如，Bosch 已經為幾款傳感器提供了以 Eclipse Vorto 語言編寫的開源數字雙胞胎描述，并發布在 Eclipse Vorto 存儲庫中。Eclipse Vorto 語言使用大多數程序員熟悉的語法，提供了一種簡單的方法來描述數字雙胞胎的模型和接口。以后，開發人員可以根據需要將 Vorto 語言描述轉換為 JSON-LD 或其他格式。

構建工業物聯網應用

無論是用分立式模擬器還是面向微服務的平臺構建，設備數據模擬都可以提供基于軟件的有效解決方案，以加速應用開發。對于使用多個設備網絡的工業物聯網應用，將設備模擬遷移到邊緣可以幫助進一步簡化向部署的過渡，而無需犧牲在應用開發初期對代表性數據的需求。

邊緣計算系統在大規模物聯網應用中扮演的角色越來越重要。這些系統提供了新興需求所需的本地資源，范圍從基本數據預處理以減少到達云的數據量，到機器學習推斷模型等高級分類功能。此外，作為場域設備網絡和高速回程網絡之間的通信網關，邊緣計算系統還起著更為基本的作用。

網關（例如 Multi-Tech Systems 的可編程 MultiConnect Conduit 系列）提供了將通信支持與邊緣處理功能相結合的平臺。Multi-Tech 的MTCAP-915-001A（用于 915 兆赫 (MHz) 區域）和 MTCAP-868-001A（用于 868 MHz 區域）提供了用于聚合場域網絡設備數據的 LoRaWAN 連接，以及云端上的以太網或 4G-LTE 連接。基于開源的 Multi-Tech Linux (mLinux) 操作系統，這些平臺還為運行設備模擬提供了熟悉的開發環境。隨著獨立的現場網絡與物理傳感器和其他設備上線，每個單元都可恢復其作為通信網關的角色，從而將處理工作的重心轉為數據預處理等要求。

總結

工業物聯網應用為傳感器網絡的現場部署，以及能夠將傳感器數據轉換為有用結果的云應用軟件的開發帶來了重大挑戰。傳感器網絡和應用軟件的相互依賴關系可能導致開發陷入困境，因為傳感器部署和軟件實現會等待彼此達到足夠的臨界規模水平。

如上所述，開發人員可以通過在實際的數量、速度和種類水平模擬數據流，來打破這種僵局并加速工業物聯網應用開發。