編者按：由于開發(fā)人員需要等待新設備的硬件實施，因此嵌入式應用開發(fā)項目通常會出現(xiàn)延遲。工業(yè)物聯(lián)網 (IIoT) 應用開發(fā)面臨類似的瓶頸，需要等待基于機器學習方法的工業(yè)預測維護系統(tǒng)或設施自動化系統(tǒng)等應用所需的傳感器數(shù)據(jù)。本系列文章由兩部分組成，將會探討哪些替代方法能提供所需的早期數(shù)據(jù)流，以加速工業(yè)物聯(lián)網應用開發(fā)。本文是第 1 部分，介紹了如何使用模擬方法生成那些數(shù)據(jù)流。第 2 部分討論了有哪些選項可用于對傳感器系統(tǒng)進行快速原型開發(fā)，以生成數(shù)據(jù)。
大規(guī)模工業(yè)物聯(lián)網 (IIoT) 應用帶來了諸多挑戰(zhàn)，這些挑戰(zhàn)可能會使部署停滯，并讓公司對所需要的眾多實施資源的投資回報率產生質疑。為防止此類情況并幫助開發(fā)人員更快地明確工業(yè)物聯(lián)網部署的優(yōu)勢，就需要即時訪問數(shù)據(jù)進行部署模擬。
若使用模擬方法生成現(xiàn)實的數(shù)據(jù)流，開發(fā)人員在物聯(lián)網網絡部署之前就可以順利開始工業(yè)物聯(lián)網應用開發(fā)，甚至可以完善工業(yè)物聯(lián)網傳感器網絡本身的定義。
本文將說明各種物聯(lián)網云平臺如何提供數(shù)據(jù)模擬，并將介紹 Multi-Tech Systems Inc. 的示例網關，這些產品有助于進一步加快部署。
工業(yè)物聯(lián)網數(shù)據(jù)的模擬案例
當然，使用模擬數(shù)據(jù)來推動應用和系統(tǒng)開發(fā)并不是什么新鮮事物。數(shù)十年來，開發(fā)人員一直使用系統(tǒng)級模擬方法對計算基礎設施和連接服務進行壓力測試。這些測試在驗證靜態(tài)配置的穩(wěn)健性方面起著重要的作用。在云服務平臺中，這些測試提供了一種相對簡單的方法，來驗證虛擬機和其他云資源的彈性伸縮功能。
工業(yè)物聯(lián)網應用具有相同甚至更多的需求。除了幫助進行負載測試和彈性伸縮外，數(shù)據(jù)模擬還提供了一個重要工具，可用于驗證許多不同服務和資源的集成，而這些服務和資源需要用于實現(xiàn)像企業(yè)級工業(yè)物聯(lián)網應用這樣復雜的軟件。除了這些更基本的實踐之外，對于基于領先云提供商的復雜服務平臺構建的復雜工業(yè)物聯(lián)網應用，數(shù)據(jù)模擬還可以加快相關開發(fā)工作。
軟件角度
工業(yè)物聯(lián)網應用在復雜的架構上運行，這種架構在應用軟件開發(fā)人員與傳感器和執(zhí)行器系統(tǒng)開發(fā)人員看來明顯不同。對于后者，大規(guī)模的工業(yè)物聯(lián)網架構是傳感器和執(zhí)行器的龐大組合，它們與作為整個應用主體的物理過程相交互。對于應用軟件開發(fā)人員而言，企業(yè)級工業(yè)物聯(lián)網架構包含許多服務，這些服務的協(xié)調活動最終可以提供應用的功能。
從應用軟件的角度來看，Microsoft 的 Azure 物聯(lián)網參考架構提供了典型工業(yè)物聯(lián)網應用（和一般物聯(lián)網應用）的代表性視圖。此視圖總結了多種功能性服務，典型應用在云中將這些服務聚合在一起，以基于來自端點和外圍邊緣設備的數(shù)據(jù)提供見解和操作（圖 1）。
圖 1：Microsoft 的 Azure 物聯(lián)網參考架構說明了工業(yè)物聯(lián)網應用通常需要多種類型的云服務和資源，以根據(jù)外圍設備網絡生成的數(shù)據(jù)提供有用的見解和操作。（圖片來源：Microsoft Corp.）
特定的應用解決方案以適當?shù)慕M合部署這些云資源，通過標準化的交換機制在功能上進行連接，并按應用邏輯進行協(xié)調。例如，在聯(lián)網汽車解決方案中，Amazon Web Services (AWS) 顯示了如何在負責提供不同應用功能的模塊中混合搭配云服務（圖 2）。
圖 2：AWS 聯(lián)網汽車解決方案提供一個代表性視圖，顯示了典型大規(guī)模物聯(lián)網應用如何協(xié)調云服務來提供所需的功能。（圖片來源：Amazon Web Services）
正如這些代表性架構所示，創(chuàng)建工業(yè)物聯(lián)網應用所需的軟件開發(fā)工作與實施傳感器和執(zhí)行器系統(tǒng)的外圍網絡一樣具有挑戰(zhàn)性和廣泛性。很少有組織可以等到設備網絡能夠生成足夠數(shù)據(jù)后，再開始延遲開發(fā)此復雜軟件。實際上，隨著分析專家和機器學習專家開始處理應用結果，設備網絡的部署可能需要等待進一步的定義和完善。在最壞的情況下，設備網絡部署和軟件開發(fā)會陷入僵局：彼此依賴于對方的結果。
幸運的是，這一難題的解決方案在于物聯(lián)網架構的本質。除了一些廣泛的相似性之外，云服務架構（例如上面來自 Microsoft 和 AWS 的圖示架構）一定在細節(jié)上會有所不同。盡管如此，它們都展示了通常在物聯(lián)網云平臺中所見的類似架構特征：定義明確的接口服務模塊或層功能，可將物聯(lián)網設備的外圍網絡與基于云的軟件應用分開。除了提供統(tǒng)一的連接性之外，對于設備管理和安全性以及大規(guī)模工業(yè)物聯(lián)網應用所需的其他關鍵功能，這些接口服務也至關重要。
在 Microsoft 的 Azure 云中，此接口服務稱為 Azure IoT Hub（同樣參見圖 1）；在 AWS 云中，它是 AWS IoT Core（同樣參見圖 2）。在 Google Cloud Platform 中，此接口是 Cloud IoT Core，在 IBM Cloud 中，則是 IBM Watson IoT Platform 服務。類似地，其他平臺（如 ThingWorx 物聯(lián)網平臺）也通過連接服務（如 ThingWorx Edge Microserver、ThingWorx Kepware Server 或協(xié)議適配器工具包）進行連接。簡而言之，任何云平臺都需要提供可將數(shù)據(jù)從外設集中到云服務的一致接口服務，否則就要冒著從外設直接連接到云深處各個資源的混亂風險。
注入模擬數(shù)據(jù)
使用每個物聯(lián)網平臺的軟件開發(fā)工具包 (SDK)，開發(fā)人員可以按照驗證應用功能和性能所需的數(shù)量、速度和種類，將模擬的傳感器數(shù)據(jù)直接注入平臺的接口服務中。以所需速率和分辨率生成的模擬數(shù)據(jù)使用 MQ 遙測傳輸 (MQTT)、受限應用協(xié)議 (CoAP) 等標準協(xié)議到達該接口服務。對于接口服務（和下游應用軟件）而言，模擬數(shù)據(jù)流與硬件傳感器系統(tǒng)獲取的數(shù)據(jù)沒有什么區(qū)別。當設備網絡準備上線時，它們的傳感器數(shù)據(jù)流僅需替代到達接口服務的模擬數(shù)據(jù)流。
云平臺提供商通常在不同的功能級別上支持這種數(shù)據(jù)模擬方法。例如，Google 演示了一個使用參考架構和示例代碼的簡單仿真驅動應用，該應用實現(xiàn)了一個溫控風扇的簡單控制回路。像之前圖示的架構一樣，該架構利用了由 Google Cloud IoT Core 服務接口饋送的 Google Cloud Platform 服務（圖 3）。
圖 3：在任何物聯(lián)網云平臺中，設備模擬器都使用物理設備所使用的相同通信協(xié)議將數(shù)據(jù)饋送到接口服務，例如此處顯示的 Google Cloud Platform 應用架構的 Google Cloud IoT Core。（圖片來源：Google）
在此樣例應用中，溫度傳感器設備模擬器以選定的更新速率生成數(shù)據(jù)，并使用 MQTT 信息傳輸協(xié)議將數(shù)據(jù)傳遞到 Google Cloud IoT Core 接口服務。相應地，該接口服務使用平臺的標準發(fā)布-訂閱 (pub/sub) 協(xié)議將數(shù)據(jù)傳遞到模擬服務器，該服務器通過命令進行響應以按需打開或關閉風扇（圖 4）。
圖 4：Google 樣例應用演示了一個基本控制回路，其中包括一個模擬設備，該設備使用標準通信方法通過 Google Cloud IoT Core 將數(shù)據(jù)發(fā)送到模擬服務器。（圖片來源：Google）
Google 提供了實現(xiàn)此基本應用的 Python 代碼示例。在此代碼中，Device 類實例包括一種根據(jù)模擬風扇的狀態(tài)更新模擬溫度的方法。主例程以指定的速率調用該方法，并使用 Eclipse paho-mqtt Python MQTT 客戶端模塊提供的 MQTT 連接服務發(fā)送數(shù)據(jù)（清單 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 類實例，該實例可存儲模擬溫度傳感器的當前值，并提供一種根據(jù)模擬風扇的狀態(tài)更新該值的方法。（代碼來源：Google）
反過來，Server 類實例提供了一個模塊，可根據(jù)從 Device 類實例接收到的溫度數(shù)據(jù)來更新風扇狀態(tài)（清單 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() 方法為應用提供了業(yè)務邏輯，當溫度超過定義值時將風扇狀態(tài)設置為打開，而當溫度降低時將風扇狀態(tài)設置為關閉。（代碼來源：Google）
除了 Google 的示例代碼外，開發(fā)人員還可以在 GitHub 等存儲庫中找到數(shù)十個開源物聯(lián)網設備、系統(tǒng)和網絡模擬器。例如，Microsoft 的開源 Raspberry Pi 系統(tǒng)模擬器代碼包括與 Azure IoT Hub 的預置集成，用于快速開發(fā)與 Raspberry Pi valuation-boards-embedded-mcu-dsp/786?k=raspberry+pi&v=1690&pv1989=0&FV=-8%7C786&nstock=1">板對接的云應用。此外，Node-RED 等代碼較少的編程工具也支持預置模塊（節(jié)點），用于將模擬傳感器數(shù)據(jù)饋送到領先的云平臺物聯(lián)網服務接口。使用這些方法，開發(fā)人員可以輕松生成傳感器數(shù)據(jù)流。
規(guī)模運行模擬
使用設備級模擬器和相關工具的困難在于，管理數(shù)據(jù)模擬本身就會成為一個項目。像任何應用一樣，要運行模擬器，開發(fā)人員需要配置和維護資源。更令人擔憂的是，用于生成真實數(shù)據(jù)的設備模型會成為工業(yè)物聯(lián)網應用開發(fā)流程之外的一個單獨項目。隨著開發(fā)的進行，開發(fā)人員需要確保設備模型在功能上與工業(yè)物聯(lián)網設備網絡和應用定義的任何變化保持同步。對于企業(yè)級工業(yè)物聯(lián)網應用，開發(fā)人員會發(fā)現(xiàn)，擴展這些模擬最多可能會很困難，甚至會開始耗費開發(fā)應用所需的資源。
大型物聯(lián)網云平臺提供商使用物聯(lián)網設備模擬解決方案來解決這些問題，這些解決方案設計為可像它們各自平臺中的其他云資源一樣輕松伸縮。例如，AWS IoT Device Simulator 為其 CloudFormation 配置服務提供了一個 AWS 模板，該模板可部署虛擬專用網絡，用于連接在 AWS Fargate 無服務器引擎上運行的容器中實現(xiàn)的微服務（圖 5）。
圖 5：AWS IoT Device Simulator 組合了多個 AWS 服務，以將可伸縮的設備數(shù)據(jù)流提供給物理設備使用的同一 AWS IoT Core。（圖片來源：Amazon Web Services）
開發(fā)人員可以通過在 Amazon S3 服務中運行的圖形用戶界面 (GUI) 控制臺以交互方式訪問模擬，也可以通過由 Amazon API Gateway 服務中的 CloudFormation 模板生成的 IoT Device Simulator 應用編程接口 (API) 以編程方式訪問模擬。在模擬運行期間，IoT Device Simulator 微服務根據(jù)自身的配置項目中描述的總體模擬計劃，從 Amazon DynamoDB NoSQL 數(shù)據(jù)庫中提取設備配置。
這些設備配置是 JSON 記錄，用于定義設備屬性名稱（例如溫度）、數(shù)值范圍（例如 -40 至 85）以及更新設備間隔和模擬持續(xù)時間等信息。開發(fā)人員可以通過控制臺以交互方式或通過 API 以編程方式添加設備類型。通過使用常規(guī) DevOps 方法，可以快速擴展設備類型、配置和基礎設施，以實現(xiàn)到達 AWS IoT Core 和下游應用所需的數(shù)據(jù)更新率。
在 Azure 設備模擬器中，開發(fā)人員可以進一步使用模擬運行期間設備支持的一組行為，以及云應用可以直接調用的一組方法，來補充基本屬性列表。
數(shù)字雙胞胎
這種設備數(shù)據(jù)模擬在概念上與商業(yè)物聯(lián)網云平臺中興起的數(shù)字雙胞胎功能緊密相關。相比通常僅提供設備狀態(tài)靜態(tài)表示的設備影子，數(shù)字雙胞胎可擴展虛擬設備模型，使其符合物理設備狀態(tài)及其行為。
在 Microsoft 的 Azure 中，Azure Digital Twins 服務允許開發(fā)人員包括用戶定義的函數(shù)，以定義設備模擬期間的行為，并且仍像以前一樣將結果饋送給 Azure IoT Hub。無論傳入的數(shù)據(jù)是模擬數(shù)據(jù)還是真實數(shù)據(jù)，之后都將發(fā)送到事件路由服務，以在應用中進一步分發(fā)。此外，Microsoft 還會使用數(shù)字雙胞胎數(shù)據(jù)創(chuàng)建空間圖，以描述復雜分層環(huán)境（例如，包含多個網絡的工業(yè)自動化系統(tǒng)）中元件之間的交互作用和狀態(tài)（圖 6）。
圖 6：Microsoft 的 Azure Digital Twins 服務使開發(fā)人員能夠構建在功能和特性上與對應物理設備相符的虛擬設備，并提供復雜服務（例如復雜工業(yè)物聯(lián)網層次結構的空間圖）的基礎。（圖片來源：Microsoft）
對于工業(yè)物聯(lián)網應用，數(shù)字雙胞胎可以提供一種強大的機制，能夠在整個生命周期中支持圍繞這些功能構建的應用。在開發(fā)的早期階段，平臺的設備模擬服務可以成規(guī)模地驅動數(shù)字雙胞胎。當物理工業(yè)物聯(lián)網網絡上線時，可以用設備數(shù)據(jù)饋送代替那些向數(shù)字雙胞胎發(fā)送的模擬數(shù)據(jù)饋送。稍后，在完全部署的工業(yè)物聯(lián)網應用中，開發(fā)人員可以使用在物理設備與數(shù)字雙胞胎之間發(fā)現(xiàn)的任何差異作為預測維護算法或安全入侵檢測器等的額外輸入。在整個生命周期中，數(shù)字雙胞胎可以保護應用免受網絡中斷或工業(yè)物聯(lián)網設備網絡配置重大變更的影響。
物聯(lián)網平臺中數(shù)字雙胞胎的出現(xiàn)還帶來了第二個好處，即提供一種標準化方法來描述設備模型的屬性和行為。對于描述語言，Microsoft 的 Azure Digital Twins 服務使用 JSON-LD（鏈接數(shù)據(jù)的 Javascript 對象表示法）。JSON-LD 背后有萬維網聯(lián)盟 (W3C) 支持，并基于行業(yè)標準 JSON 格式提供一種標準格式來序列化鏈接數(shù)據(jù)，該格式已在許多其他應用領域中使用。
隨著傳感器和執(zhí)行器的預置數(shù)字雙胞胎描述存儲庫的出現(xiàn)，標準化的數(shù)字雙胞胎描述可以進一步加快開發(fā)速度。例如，Bosch 已經為幾款傳感器提供了以 Eclipse Vorto 語言編寫的開源數(shù)字雙胞胎描述，并發(fā)布在 Eclipse Vorto 存儲庫中。Eclipse Vorto 語言使用大多數(shù)程序員熟悉的語法，提供了一種簡單的方法來描述數(shù)字雙胞胎的模型和接口。以后，開發(fā)人員可以根據(jù)需要將 Vorto 語言描述轉換為 JSON-LD 或其他格式。
構建工業(yè)物聯(lián)網應用
無論是用分立式模擬器還是面向微服務的平臺構建，設備數(shù)據(jù)模擬都可以提供基于軟件的有效解決方案，以加速應用開發(fā)。對于使用多個設備網絡的工業(yè)物聯(lián)網應用，將設備模擬遷移到邊緣可以幫助進一步簡化向部署的過渡，而無需犧牲在應用開發(fā)初期對代表性數(shù)據(jù)的需求。
邊緣計算系統(tǒng)在大規(guī)模物聯(lián)網應用中扮演的角色越來越重要。這些系統(tǒng)提供了新興需求所需的本地資源，范圍從基本數(shù)據(jù)預處理以減少到達云的數(shù)據(jù)量，到機器學習推斷模型等高級分類功能。此外，作為場域設備網絡和高速回程網絡之間的通信網關，邊緣計算系統(tǒng)還起著更為基本的作用。
網關（例如 Multi-Tech Systems 的可編程 MultiConnect Conduit 系列）提供了將通信支持與邊緣處理功能相結合的平臺。Multi-Tech 的MTCAP-915-001A（用于 915 兆赫 (MHz) 區(qū)域）和 MTCAP-868-001A（用于 868 MHz 區(qū)域）提供了用于聚合場域網絡設備數(shù)據(jù)的 LoRaWAN 連接，以及云端上的以太網或 4G-LTE 連接?；陂_源的 Multi-Tech Linux (mLinux) 操作系統(tǒng)，這些平臺還為運行設備模擬提供了熟悉的開發(fā)環(huán)境。隨著獨立的現(xiàn)場網絡與物理傳感器和其他設備上線，每個單元都可恢復其作為通信網關的角色，從而將處理工作的重心轉為數(shù)據(jù)預處理等要求。
總結
工業(yè)物聯(lián)網應用為傳感器網絡的現(xiàn)場部署，以及能夠將傳感器數(shù)據(jù)轉換為有用結果的云應用軟件的開發(fā)帶來了重大挑戰(zhàn)。傳感器網絡和應用軟件的相互依賴關系可能導致開發(fā)陷入困境，因為傳感器部署和軟件實現(xiàn)會等待彼此達到足夠的臨界規(guī)模水平。
如上所述，開發(fā)人員可以通過在實際的數(shù)量、速度和種類水平模擬數(shù)據(jù)流，來打破這種僵局并加速工業(yè)物聯(lián)網應用開發(fā)。
