由於開發人員需要等待新裝置進行硬體實作，因此嵌入式應用開發專案常常會出現延誤。IIoT應用的開發，也面臨類似的瓶頸，需等待以機器學習為基礎的預測性維護系統，或自動化系統應用所需的感測器資料。

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

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

IIoT 資料模擬案例

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

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

軟體視角

IIoT 應用在複雜的架構上運行，而這些架構在應用軟體開發人員，以及感測器和致動器系統的開發人員看來有很大的不同。對於後者來說，大型 IIoT 架構由大量感測器和致動器構成，與作為整個應用主體的實際過程相介接。對於應用軟體開發人員來說，企業級 IIoT 架構則由大量服務構成，這些服務的協調活動，最後會提供該應用的功能。

微軟（Microsoft）的 Azure IoT 參考架構，從應用軟體的角度提供典型 IIoT 應用 (和一般 IoT 應用) 的代表性視圖。此視圖總結典型應用在雲端整合的多個功能服務，以根據來自端點和周邊邊緣裝置的資料，提供洞見和行動 (圖 1)。

圖1 : Microsoft 的 Azure IoT 參考架構展示 IIoT 應用通常需要的多種雲端服務和資源，用於從周邊裝置網路產生的資料提供有用的洞見和行動。（source：Microsoft）

具體的應用解決方案會以適當的組合，來部署這些雲端資源，並透過標準化互換機制進行功能連接，然後由應用邏輯加以協調。例如，Amazon Web Services（AWS）在連網汽車解決方案中，建議如何在不同功能與能力的模組中，混搭雲端服務（圖2）。

圖2 : AWS 的連網汽車解決方案的代表性視圖，顯示出典型大型 IoT 應用如何協調雲端服務來提供所需的功能。（source：Amazon Web Services）

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

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

在Microsoft的Azure雲端中，此介面服務稱為Azure IoT Hub；在AWS雲端中，稱為AWS IoT Core 。在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 等。（source：Google）

在此範例應用中，溫度感測裝置的模擬器以選定的更新率產生資料，並透過 MQTT 傳訊協定，將資料傳送至 Google Cloud IoT Core 介面服務。而該介面服務使用平臺的標準「發佈-訂閱（pub/sub）」協定，將資料傳送至模擬伺服器，依需求發出指令，以開啟或關閉風扇（圖4）。

圖4 : Google 範例應用展示一個由模擬裝置組成的基本控制迴路，可以標準通訊方法透過 Google Cloud IoT Core 將資料傳送到模擬伺服器。（source：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。（source：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 層次結構的空間圖形。（source：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 應用的開發。