加速工業 IoT 應用的開發 - 第 2 篇：快速部署 IIoT 感測器

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

大規模的工業物聯網 (IIoT) 應用，基本上要仰賴對資料流的分析與回應，而這些資料流可透過在目標環境中部署的感測器網路來產生。如果無法在開發早期取得這些資料流，IIoT 應用可能會跟不上緊湊的進度或達不到公司的期望。

雖然模擬方法可解決許多應用的資料需求，但有些應用可能需要與目標環境完全相符的資料。對於這些應用，要投入巨大的工程去取得有效的模擬結果，可能不切實際。然而，使用現成的感測器與閘道器，可能可以提供一個快速取得資料的途徑。這些裝置專為工業環境所設計，支援廣泛的感測器類型與連接選項，讓使用者無需費力。

本文是關於加速 IIoT 應用開發系列文章的第二篇 (共兩篇)，將會介紹多款預先配置的 IIoT 感測器與閘道器，可用於產生所需的資料，加速 IIoT 應用開發。

IIoT 資料模擬的局限性

感測器資料是 IIoT 應用的核心，但若想完全部署這些應用，既需要有能提供這些資料的感測器系統，也要有將這些資料轉化成有用資訊的軟體系統。對某些 IIoT 應用來說，模擬方法可能無法提供足夠有用的資料。如果沒有謹慎注意模擬的參數，模擬的資料流可能會呈現出導致應用偏向某個特定工作範圍的特性。

例如，若資料模擬配置為在 -40°C 至 +125°C 範圍內提供呈均勻分佈的隨機溫度，則可能會導致應用偏向極端溫度，超出目標環境的實際環境範圍。此外，這種簡單模擬提供的溫度資料，也可能輕易從一個測量段跳到下一個段，一次跳數十度。在典型的 IIoT 應用中，如此極端且不切實際的溫度變化，可能會對過程控制迴路及其他應用結果帶來極大破壞。

如果應用要嵌入機器學習推斷模型，則尤其需要注意資料的品質及其表現真實條件的程度。資料科學家已瞭解到，以不良的資料訓練推斷模型，會得到同樣糟糕的結果。因此，若想建立這些模型所需的有效資料模擬，投入的工作量可能會暴增。

對於大多數的 IIoT 專案而言，將應用開發延到部署好感測器系統後再進行絕非良策。事實上，當需要執行軟體應用來提供所需資訊或驗證能否完全部署時，等待感測器部署的做法甚至是不可行。例如，資料科學家可能需要透過複雜演算法的結果，來判斷是否需要更高解析度的資料、更高的更新率，甚至是不同類型的感測器資料，以解決結果中的模糊之處或最佳化應用。

基於所有這些原因，企業可能會不情願地決定延遲 IIoT 應用的開發，也不願使用不能很好代表目標工業製程和環境的模擬資料來開發應用。所幸，隨著經過預先構建的 IIoT 感測器系統及相關閘道器元件越來越容易取得，企業至少能快速部署應用開發所需的關鍵感測器組。

快速部署感測器網路

IIoT 感測器將感測器、處理器和連接介面整合在一個封裝中，該封裝能承受典型工業環境的壓力。除了用於溫度、振動、壓力和濕度的單個感測器外，開發人員還可以在市面上找到多感測器裝置，而這些裝置封裝了特定應用能力 (如預測性維護) 所需的感測器組合。

預測性維護方法可監測一些特性，以便指出設備潛在故障。例如在馬達中，特定的振動頻率和溫度變化，能可靠指出特定的馬達故障類型。IIoT 感測器可擷取此類資料，例如 National Control Devices (NCD) 的 PR55-20A 預測性維護感測器，整合所需的感測器和低功率微控制器以及 DigiMesh 無線網狀網路連接選項 (圖 1)。

圖 1：NCD 的 PR55-20A 預測性維護感測器整合多個感測器和所需的網狀網路連接選項，可將資料傳送至本地無線節點。(圖片來源：National Control Devices)

為了加速 IIoT 應用的開發，開發人員可輕鬆地將 NCD 預測性維護感測器等專用感測器，與 NCD PR49-24G 無線環境感測器等其他感測器整合在一起。NCD PR49-24G 採用一個由兩顆 AA 電池供電的工業封裝，並整合溫度、濕度和氣體感測器。

除了各種特定的感測器類型外，IIoT 感測器製造商還提供經過預先構建的通訊閘道器，可用於簡化感測器與本地連接網路的整合。事實上，開發人員可能發現市面上有些閘道器，已預先配置為連接特定的商用雲端，或支援連接 IoT 雲端平台所常用的通訊協定。

對於 DigiMesh 無線感測器，NCD 的 PR55-21 閘道器系列使用 Wi-Fi 連線來連接特定的雲端服務，如 Microsoft Azure IoT (PR55-21_AZURE)、Amazon Web Services IoT (PR55-21_AWS)，或 Losant IoT 平台 (PR55-21_LOSANT)。此外，PR55-21_MQTT 閘道器支援和任何採用 ISO 標準訊息佇列遙測傳輸 (MQTT) 協定的主機進行通訊。與 PR55-21 系列的其他成員一樣，PR55-21_MQTT 閘道器也將低功率的工業微控制器與相關子系統整合在一起，不僅能建立本地的 DigiMesh 無線連線，還可與本地或遠端 MQTT 伺服器建立加密的 Wi-Fi 回程連線 (圖 2)。

圖 2：NCD 的 PR55-21_MQTT 閘道器不僅支援以無線方式連接 DigiMesh 網狀網路，還可透過 Wi-Fi 連接與伺服器進行 MQTT 訊息交換。(圖片來源：National Control Devices)

開發人員可使用在閘道器嵌入式網路伺服器上提供的選單型工具，快速配置 DigiMesh 本地網路及 MQTT Wi-Fi 連接。例如，元件螢幕顯示 DigiMesh 連線元件及其訊號強度和活動，並提供一個中心點來管理配置 (圖 3)。

圖 3：NCD 的 PR55-21_MQTT 閘道器嵌入式網路伺服器，可讓使用者變更設定並檢視連接到本地網路的感測器的活動。(圖片來源：National Control Devices)

DigiMesh 網狀網路可在電池供電的感測器系統中，有效擴大所需低功率收發器的有效範圍。當然，工業環境中可能只用到其中一種連接選項，製造商也為這些選項提供類似的感測器與閘道器組合。例如，Laird 的 Sentrius RS1xx 系列包含支援藍牙和 LoRaWAN 連接的工業感測器。該公司的 Sentrius RG1xx 系列含有互補的閘道器，可支援部署 LoRaWAN 所需的區域頻率。此外，這些閘道器還支援本地藍牙連接以及 Wi-Fi 回程網際網路連接。

在某些應用中，強大的電磁干擾 (EMI) 來源會降低無線通訊的訊號完整性。在這些情況下，如果能將感測器功能與通訊功能分隔開來，會是個重要的優勢。除了自家的無線工業感測器外，Banner Engineering 還提供可透過 RS-485 或單線序列介面連接到獨立無線節點的感測器。因此，對於與強 EMI 來源 (如高速馬達) 相連的感測器，操作人員可間隔一定的距離再放置無線通訊節點 (圖 4)。

圖 4：對於馬達振動測量等電磁干擾較大的情況，開發人員可以將 Banner Engineering 裝設於馬達上的振動感測器，與相距雜訊來源一定距離放置的無線節點相連。(圖片來源：Banner Engineering)

Banner Engineering 提供多種無線節點支援此配置， DX80N9Q45VTP 無線節點可與該公司的 QM30VT1 單線振動與溫度感測器連接，而 DX80N9Q45TH 無線節點可與 M12FTH4Q 單線溫度及濕度感測器連接。若需要更廣泛的感測器介面，該公司的 DX80N9Q45U 可用作通用單線無線節點，而 DX80G9M6S 系列的無線節點則支援將 RS-485 感測器連接到多躍網路。

本地處理

即使能快速部署 IIoT 感測器網路，開發人員可能也需要預先考慮一定程度的本地處理，以減少資料量或減輕下游資源的處理負載。事實上，進階的工業感測器 (如 Banner Engineering 的 QM30VT2 振動與溫度感測器) 可讓使用者將測得的振動頻率分成多達 20 個頻帶。這個能力對預測性維護應用特別重要，原因在於各個頻帶內的變化可指示特定類型的故障。

除了由感測器進行預處理外，在早期部署感測器網路時，可能也會需要進行一系列本地處理。Banner Engineer 可藉由 DXM700 控制器與閘道器提供此能力。DXM700 的尺寸僅為 70 x 86 x 55 mm，提供多個本地無線與有線連接，並可透過回程乙太網路連至主機伺服器 (圖 5)。

圖 5：Banner Engineering 的 DXM700 控制器與閘道器提供多個本地和網際網路連接選項，並支援本地 ScriptBasic 處理。(圖片來源：Banner Engineering)

從本地感測器網路接收資料時，控制器可執行以 ScriptBasic 編寫的程式，以檢視輸入資料、根據輸入資料啟動輸出或執行簡單的資料轉換。Banner Engineering 文件包含 ScriptBasic 範例程式碼，其中展示了一些典型的操作，例如回應感測器資料的變化等 (清單 1)。

複製
 
...'Function to read the T/H sensor
FUNCTION GetTempHumidityData
   LastValueTempC = TempC
   LastValueHumidity = Humidity
   Humidity =GETREG(SensorHumidity_reg, TH_SID, MBtype) 
   TempC = GETREG(SensorTempC_reg, TH_SID, MBtype)
   IF Humidity > 65535 or TempC > 65535 THEN 
         PRINT "Read Error - humidity / temp reading...", Humidity,"  ",TempC,"\n\r"
   END IF
   WrErr = SETREG (Humidity_reg, Humidity, LocalRegSID, MBtype)
   WrErr = SETREG (TempC_reg, TempC, LocalRegSID , MBtype)
 
FUNCTION StateMachine
'State machine definitions for the periodic reading of temp/humidity
' TH_State = 0  current state of the state machine
' TH_Idle= 0  initial state
' TH_Wait= 1  wait time between samples
' TH_Sample= 2  get samples from remote sensor
' TH_Error= 3 error state - unknown condition

   LOCAL StartState
   StartState = TH_State
   WrErr = SETREG (SM_reg, TH_State, LocalRegSID, MBtype)
   
   IF TH_State = TH_Idle THEN
          StartTime = NOW
          TH_State = TH_Wait
   ELSEIF TH_State = TH_Wait THEN
      IF NOW >= (StartTime + WaitTime) THEN 
         TH_State = TH_Sample
      ELSE 
         TH_State = TH_Wait
      END IF 
   ELSEIF TH_State = TH_Sample THEN
      GetTempHumidityData
      TH_State = TH_Idle
   ELSE 
      TH_State = TH_Error
   END IF 
   IF StartState <> TH_State THEN
      PRINT "\r\n Time ",NOW,"  SM Started-> ",THState[StartState],"  End->",THState[TH_State]," \r\n"
   END IF

END FUNCTION 

FUNCTION LED_driver  
IF LastValueTempC < TempC THEN    WrErr = SETREG (TempGoingUp_LED2_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingUp_LED2_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF LastValueTempC > TempC THEN    WrErr = SETREG (TempGoingDown_LED3_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingDown_LED3_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF (Humidity > 65535 ) OR (TempC > 65535) THEN    WrErr = SETREG (CommsError_LED4_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (CommsError_LED4_reg,0,DisplaySID, MBtype) 
   END IF 
   
   IF GETREG(ScriptRunnning_LED1_reg, DisplaySID, MBtype) THEN
      WrErr = SETREG (ScriptRunnning_LED1_reg,0,DisplaySID, MBtype) 
   ELSE 
      WrErr = SETREG (ScriptRunnning_LED1_reg,1,DisplaySID, MBtype) 
   END IF
   
END FUNCTION 

‘Main program loop
BEGIN:
   PRINT "Script Starting\r\n"
   ITERATE:
      'PRINT "\r\n Time = ",NOW," \r\n"
      StateMachine
      LED_driver
      Sleep(1)
   GOTO ITERATE
END

清單 1：此程式碼片段來自於 Banner Engineering，展示開發人員如何對 Banner Engineering DXM700 進行編程，從本地回應感測器資料。本例是以開啟和關閉 LED 的方式來回應溫度與濕度感測器資料的變化。(原始程式碼：Banner Engineering)

有些閘道器在本地處理方面具有更大的彈性，如 Multi-Tech Systems 的 MTCAP-Lxxx 系列等。此系列支援感測器端的本地 LoRaWAN 連接，以及回程通道的乙太網路與可選廣頻 LTE 連接，可滿足各種連接需求。至於作業環境，此閘道器系列以開放原始碼 Multi-Tech Linux (mLinux) 作業系統為基礎。因此，開發人員可使用熟悉的開發環境來建立本地處理軟體常式。此外，這些閘道器還支援 Node-RED，這是一個編程量較低的開發選項，對 IIoT 等以事件驅動的應用很有幫助。本文後面提供了 Node-RED 的更多資訊。

低編程量的快速原型開發

藉由快速部署實體感測器網路，在全面設計、開發和調試感測器網路之前就能提供早期的關鍵資料來源，從而有助於加速 IIoT 應用的開發。如果快速部署帶來大量附帶的軟體開發需求，則也會妨礙進行部署。前面提到的預配置 IIoT 感測器與閘道器在許多情況下都可以避免這種情況，但超出現成感測器與閘道器能力的獨特資料要求，可能會帶來相關的軟體要求。

為了滿足獨特的資料要求，Arduino 和 Raspberry Pi 等快速原型開發平台提供多種專用的感測器與致動器作為附加板。混搭這些附加板後，開發人員即可快速構建幾乎符合所有感測器資料需求的原型。

對於通常需要最小覆蓋區和功能的 IoT 應用，製造商推出了符合相應需求的多感測器板，讓應用的原型開發變得更簡單。有些開發板如 ON Semiconductor 的 RSL10-SENSE-GEVK 評估套件或 STMicroelectronics 的 STEVAL-STLKT01V1 SensorTile 開發套件，將高效能處理器與穿戴式裝置及 IoT 裝置通常需要的多種感測器整合在一起。舉例來說，SensorTile 將 STMicroelectronics 的 STM32L4 處理器與 STMicroelectronics 的 BLUENRG-MS 收發器及一個感測器陣列整合起來，此陣列包含該公司的 LPS22HBTR 微機電系統 (MEMS) 壓力感測器、帶有加速計和陀螺儀的 LSM6DSMTR MEMS 慣性量測單元 (IMU)，以及帶有線性加速度和磁性感測器的 LSM303AGRTR MEMS 電子羅盤 (圖 6)。

圖 6：STMicroelectronics 的 SensorTile 以 STMicroelectronics 的 STM32L4 處理器為基礎，可提供一個靈活的硬體平台來構建感測器系統，能夠滿足超出現成 IIoT 感測器系統能力之外的獨特需求。(圖片來源：STMicroelectronics)

作為流行的低編程量開發環境，Node-RED 可讓開發人員透過繪製連接功能元件 (節點) 的圖表 (流程)，對這些板件及其他硬體系統 (如 NCD 元件和 Multi-Tech 閘道器) 進行編程。這些流程與節點之間的互動相對應，而這些節點則對應於一些特定的功能，包括讀取感測器資料、對資料執行作業、將資料傳送到其他功能元件 (如雲端閘道器) 以及顯示資料等 (圖 7)。

圖 7：Node-RED 開發環境可讓開發人員連接從龐大開源儲存庫中提取的節點，並以此建立應用。(圖片來源：National Control Devices)

由於開源 Node-RED 流程儲存庫中有超過 225,000 個模組，此環境可為開發事件驅動型應用提供豐富的生態系統，例如採集感測器資料並將其傳送到雲端等。雖然 Node-RED 提供了一些方法，可將所產生的流程整合到生產應用中，但由於仰賴 Node.js，因此可能不適合某些應用和生產環境。

Digi-Key 的 DK IoT Studio 提供另一個低編程量開發環境。該環境大幅消除了對人工開發軟體的需求，同時仍提供 C 語言的原始程式碼。藉助 DK IoT Studio，開發人員可在 DK IoT Studio 畫布上拖放與 SensorTile 每個功能相關的組件，來建立所需的功能 (圖 8)。

圖 8：Digi-Key 的 DK IoT Studio 可在畫布 (中) 上連接以圖示方式放置的功能組件，並根據需要修改關聯的特性 (右)，從創建的應用中自動產生程式碼 (左)。(圖片來源：Digi-Key/STMicroelectronics)

除了支援特定的硬體組件，這個環境也提供類似的可拖放式功能組件，來代表雲端資料傳輸或雲端資源作業。在繪製完描述資料流程與作業的圖表後，開發人員可下載所產生的程式碼，以上傳到 SensorTile。在構建典型原型時，此過程幾乎或完全不需額外的程式碼開發。有關此快速原型開發流程的更多資訊，請參閱《快速部署以電池供電的藍牙 5 認證多感測器物聯網裝置》。

結論

開發大規模 IIoT 應用主要仰賴於能否取得真實代表目標環境的資料。如本系列文章的第一篇所述，雖然模擬方法可解決許多應用的資料需求，但有些應用可能需要與目標環境完全相符的資料。對於這些應用，要投入巨大的工程去取得有效的模擬結果，可能不切實際。而使用現成的感測器與閘道器，則為快速交付資訊提供一個更為簡單的解決方案。

如第二篇 (即本文) 所述，這些裝置支援廣泛的感測器類型與連接選項，讓使用者無需太費力。使用這些產品，開發人員可快速部署感測器網路，提供加速 IIoT 應用開發所需的資料。