加速工業 IoT 應用的開發—第 1 篇：模擬 IoT 裝置資料

編者說明：開發人員在等待新裝置進行硬體實作時，常會造成嵌入式應用開發專案的延誤。工業物聯網 (IIoT) 應用的開發，也面臨類似的瓶頸，需要等待應用所需的感測器資料，例如以機器學習方法為基礎的工業預測性維護系統或設施自動化系統等應用。本系列文章共有兩篇，將探討有哪些替代方法能及早提供必要的資料流，以加速 IIoT 應用的開發。本文為第 1 篇，說明如何使用模擬方法來產生這些資料流。第 2 篇則探討有哪些選擇，能幫助快速開發感測器系統的原型，以產生資料。

大規模的工業物聯網 (IIoT) 應用帶來諸多挑戰，可能會讓部署作業停滯，並讓公司質疑為了實作投資這麼多資源，究竟能否回本。為了避免這種情況並協助開發人員更快確信部署 IIoT 的優勢，就需要即時取得部署模擬所需的資料。

若使用模擬方法來產生真實的資料流，開發人員可在部署 IoT 網路之前就開始開發 IIoT 應用，甚至是改善 IIoT 感測器網路本身的定義。

本文將說明各種 IoT 雲端平台如何提供資料模擬，並介紹 Multi-Tech Systems Inc. 推出的幾款閘道器，有助於進一步加速部署。

IIoT 資料模擬案例

使用模擬資料來驅動應用和系統的開發，當然不是什麼新鮮事。幾十年來，開發人員一直使用系統級模擬方法，對運算基礎架構和連線服務進行壓力測試。這些測試在驗證靜態配置的耐用性上發揮了重要的作用。在雲端服務平台中，這些測試能以相對簡單的方法，驗證虛擬機和其他雲端資源的自動延展能力。

IIoT 應用不僅包含以上這些要求，除了協助負載測試和自動延展外，資料模擬還提供一個重要的工具，可用於驗證許多不同服務和資源的整合，以實作像企業級 IIoT 應用這麼複雜的軟體。除了這些較為基礎的實務外，資料模擬還可以加速複雜 IIoT 應用的開發，而這些應用通常是在領先雲端供應商提供的精密型服務平台上打造。

軟體視角

IIoT 應用可在複雜的架構上運行，從應用軟體開發人員和感測器及致動器系統的開發人員的角度來看，這些應用有很大的不同。對於後者來說，大型 IIoT 架構由大量感測器和致動器構成，會與整體應用主體的實體流程介接。對於應用軟體開發人員來說，企業級 IIoT 架構由大量服務構成，這些服務會彼此協調，最後提供應用功能。

Microsoft 的 Azure IoT 參考架構展示圖可從應用軟體角度來看典型 IIoT 應用 (和一般 IoT 應用)。此展示圖可概覽典型應用在雲端整合的多種功能服務，可依據來自端點和周邊邊緣裝置的資料提供洞見和行動 (圖 1)。

圖 1：Microsoft 的 Azure IoT 參考架構可展示 IIoT 應用通常需要的多種雲端服務和資源，以便依據周邊裝置網路產生的資料，提供有用的洞見和行動。(圖片來源：Microsoft Corp.)

具體的應用解決方案會以適當的組合來部署這些雲端資源，並透過標準化互換機制進行功能連接，然後由應用邏輯加以協調。例如，Amazon Web Services (AWS) 就在其連網汽車解決方案中，展現雲端服務如何在模組中混搭，負責提供不同的應用特點和功能 (圖 2)。

圖 2：AWS 的連網汽車解決方案展示圖，可顯示典型大型 IoT 應用如何協調雲端服務來提供所需的功能。(圖片來源：Amazon Web Services)

正如這些代表性架構所示，建立 IIoT 應用所需的軟體開發工作相當艱困且所費不貲，如同實作感測器和致動器系統的周邊網路一樣。很少企業組織可以承擔裝置網路產生足夠的資料後，再開始開發此複雜軟體所造成的延遲成本。事實上，裝置網路的部署可能需要等到分析專家和機器學習專家開始處理應用結果時，才會進一步定義和完善。在最糟的情況下，裝置網路的部署和軟體開發會陷入僵局：相互依賴彼此提供的結果。

所幸，脫離這個困境的方法在於 IoT 架構本身的性質。除了一些廣泛的相似性，雲端服務架構 (如上述的 Microsoft 和 AWS 架構) 在細節上確實有所不同。儘管如此，這些架構都展現出 IoT 雲端平台中典型的類似架構特點：有定義明確的介面服務模組或分層功能，能分隔 IoT 裝置周邊網路和雲端架構的軟體應用。除了提供統一的連線，這些介面服務對於大規模 IIoT 應用所需的裝置管理和安全性以及其他關鍵能力也至關重要。

在 Microsoft Azure 雲端中，此介面服務稱為 Azure IoT Hub (再次參照圖 1)；在 AWS 雲端中，稱為 AWS IoT Core (再次參照圖 2)。在 Google Cloud Platform 中，此介面為 Cloud IoT Core，在 IBM Cloud 中則為 IBM Watson IoT Platform Service。其他平台 (如 ThingWorx IoT Platform)，也同樣會透過連線服務 (如 ThingWorx Edge Microserver、ThingWorx Kepware Server) 或通訊協定配接器工具套件進行連線。簡單來說，任何雲端平台都需要提供一致的介面服務，將資料從周邊裝置匯集到雲端，以免周邊裝置雜亂地直接連接到雲端深處的各個資源。

注入模擬資料

開發人員可以透過各個 IoT 平台的軟體開發套件 (SDK)，依據所需的容量、速度和類型，將模擬的感測器資料直接注入平台的介面服務，以驗證應用的功能和效能。以所需速率和解析度產生的模擬資料會透過訊息佇列遙測傳輸 (MQTT) 及受限應用通訊協定 (CoAP) 等標準協定送達介面服務。對此介面服務 (和下游應用軟體) 來說，模擬資料流與硬體感測器系統所擷取的資料之間的差異無法分辨。當裝置網路準備好上線時，感測器資料流會直接取代模擬資料流並送達介面服務。

雲端平台供應商通常能以不同的能力層級支援此資料模擬方法。例如，Google 以參考架構和範例程式碼展示出簡易的模擬導向應用，可藉此實作溫控風扇的簡易控制迴路。和前述架構一樣，此架構可享受 Google Cloud IoT Core 服務介面所帶來的 Google Cloud Platform 服務優勢 (圖 3)。

圖 3：在任何 IoT 雲端平台中，裝置模擬器都會採用與實體裝置相同的通訊協定，以將資料饋送到介面服務，如此處所示的 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 等儲存庫上，找到數十個開源 IoT 裝置、系統及網路模擬器。例如，Microsoft 的開源 Raspberry Pi 系統模擬器程式碼就含有預先構建的 Azure IoT Hub 整合項目，可快速開發與 Raspberry Pi 板介接的雲端應用。此外，Node-RED 等編程量較低的工具，可支援預先構建的模組 (節點)，將模擬的感測器資料，饋送到領先的雲端平台 IoT 服務介面。開發人員可透過這些作法輕鬆產生感測器資料流。

大規模執行模擬

使用裝置層級模擬器和相關工具的難處在於，光是管理資料模擬本身就是一項專案了。若要執行模擬器，開發人員需要佈建和維護資源，就像對待任何應用一樣。更大的問題是，用來產生真實資料的裝置模型，會成為獨立於 IIoT 應用開發過程的專案。隨著開發作業的進行，開發人員必須確保裝置模型的功能，與 IIoT 裝置網路及應用在定義上的任何變更維持同步。對企業層級的 IIoT 應用來說，開發人員可能會發現，擴充這些模擬也相當困難，甚至於會開始佔用開發應用所需的資源。

各大 IoT 雲端平台供應商則利用 IoT 裝置模擬解決方案因應這些問題，而這些解決方案可像其對應平台中的其他雲端資源一樣輕鬆擴充。例如，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 裝置模擬器中，開發人員可在模擬執行期間，使用裝置支援的行為組合，以及雲端應用可直接調用的方法組合，來進一步輔助基本的屬性清單。

數位分身

這種裝置資料模擬在概念上與商用 IoT 雲端平台中新興的數位分身能力密切相關。不同於裝置陰影通常僅會以靜態方式提供裝置狀態，數位分身會延伸虛擬裝置模型，以便符合實體裝置的狀態及其行為。

在 Microsoft 的 Azure 中，Azure Digital Twins 服務可讓開發人員納入使用者定義的函數，藉此定義裝置模擬期間的行為，且仍像以前一樣會將結果饋送到 Azure IoT Hub。傳入的資料無論是模擬還是真實的資料，隨後都會發送到事件路由服務，進一步在應用中分發。此外，Microsoft 還使用數位分身資料來建立空間圖形，針對在複雜的層次環境中 (如多個網路構成的工業自動化系統)，各個裝置之間的相互作用和狀態進行描繪 (圖 6)。

圖 6：Microsoft 的 Azure Digital Twins 服務可讓開發人員打造可在能力和特性上與實體裝置相當的虛擬裝置，並為複雜的服務提供基礎，例如複雜的 IIoT 層次結構的空間圖形。(圖片來源：Microsoft)

對 IIoT 應用來說，數位分身可提供強大的機制，能針對以這些能力為基礎所打造的應用，在其整個生命週期間提供支援。在開發的早期階段中，數位分身可由平台的裝置模擬服務大規模驅動。隨著實體 IIoT 網路上線，傳送到數位分身的模擬資料流就可由裝置資料流取代。之後，開發人員就可在完全部署的 IIoT 應用中，使用實體裝置和數位分身之間找到的任何差異，作為預測性維護演算法或安全性侵入偵測器等的額外輸入。數位分身在整個生命週期中，可避免應用遭受網路中斷或 IIoT 裝置網路配置發生重大變化時所帶來的影響。

在 IoT 平台中興起的數位分身還帶來第二個優點，就是提供一套標準化方法來描述裝置模型的屬性和行為。在描述語言方面，Microsoft 的 Azure Digital Twins 服務採用 JSON-LD (JavaScript Object Notation for Linked Data)。JSON-LD 已取得全球資訊網協會 (W3C) 的支援，基於業界標準 JSON 格式，提供一種標準格式來序列化連結資料，目前已用於其他許多應用領域。

在預先建構的感測器和致動器數位分身描述儲存庫逐漸興起下，標準化的數位分身描述可進一步加快開發速度。例如，Bosch 已針對多款感測器提供開源數位分身描述，就是以 Eclipse Vorto 語言編寫，並發佈於 Eclipse Vorto 儲存庫。Eclipse Vorto 語言使用絕大多數程式設計人員所熟悉的語法，能以簡單的方法描述數位分身的模型和介面。若有必要，開發人員可在之後將 Vorto 語言描述轉換成 JSON-LD 或其他所需的格式。

構建 IIoT 應用

無論是要用離散式模擬器或是用微服務導向的平台構建，裝置資料模擬都可提供有效的軟體式解決方案，可加快應用的開發速度。對於採用多個裝置網路的 IIoT 應用而言，將裝置模擬移轉到邊緣，有助於進一步平順地過渡到部署階段，而不用犧牲應用開發早期對代表性資料的需求。

邊緣運算系統在大規模 IoT 應用中扮演著越來越重要的角色。這些系統提供新興需求所需的本地資源，包括為減少傳送到雲端的資料量而進行的基本資料預處理，以致於機器學習推論模型等進階分類能力等。邊緣運算系統也具有奠定基礎的功用，可在現場裝置網路和高速回程網路之間當作通訊閘道器。

有些閘道器可提供平台，結合了通訊支援與邊緣處理能力，例如 Multi-Tech Systems 的可編程 MultiConnect Conduit 系列。Multi-Tech 的 MTCAP-915-001A (適用於 915 MHz 區) 和 MTCAP-868-001A (適用於 868 MHz 區)，就提供 LoRaWAN 連線，可匯集現場網路裝置資料，並在雲端採用乙太網路或 4G-LTE 連線。此外，這些平台以開源 Multi-Tech Linux (mLinux) 作業系統為基礎，可提供熟悉的開發環境，以便執行裝置模擬。隨著各個現場網路與實體感測器及其他裝置上線，每個單元都可重新回歸通訊閘道器的角色，將處理工作重新導向至資料預處理等需求。

結論

IIoT 應用面臨的挑戰相當艱鉅，必須在現場部署感測器網路，更要開發雲端應用軟體，將感測器資料轉換成有用的結果。感測器網路和應用軟體的相依性會導致開發陷入困境，原因就在於感測器部署和軟體實作都在等待彼此達到足夠的臨界質量。

如本文所述，以真實的容量、速度和類型程度來模擬資料流，開發人員就可打破這個僵局並加速 IIoT 應用的開發。