未來工廠:利用搭載人工智慧的感測器在邊緣作出決策—第2部分

作者:ADI 系統應用工程師 Tom Sharkey


摘要

提升工業系統智慧化的方法有很多種,其中包括將邊緣和雲端人工智慧(AI)技術應用於配備類比和數位元件的感測器。有鑑於AI技術方法的多樣性,感測器設計人員需要考慮多個相互衝突的要求,包括決策延遲、網路使用、功耗/電池壽命以及適合機器的AI模型。上一篇文章已經重點介紹了基於AI的無線狀態監測感測器Voyager4的概況和硬體設計。本文則將重點討論為智慧邊緣感測器創建的軟體架構和AI演算法,並說明在Voyager4上開發AI模型的完整系統級方法。

狀態監測感測器的軟體設計

Voyager4是由ADI開發的無線狀態監測平台,開發人員藉由其能夠快速將無線解決方案部署到機器或測試設定並進行測試。Voyager4等馬達健康狀況監控解決方案廣泛應用於各個產業,例如機器人以及渦輪機、風扇、泵、馬達等旋轉機械。

為這類無線邊緣裝置開發軟體可能很困難。從感測器設計的早期階段開始,開發人員就必須考慮整體系統架構,系統的各個部分如何運行,如何整合不同元件以協同工作,以及如何應用和部署有用的演算法與分析工具(如神經網路)來提升邊緣智慧水準。

對於此類專案,主要目標就是為邊緣裝置和所連接的主機創建易於理解、可修改、可升級的軟體。Voyager4內部有兩個微控制器和許多週邊,包括感測器、電源管理板、快閃記憶體和通訊介面。開發目的在控制和整合每個部分的程式碼是一項艱鉅的任務。

本文希望透過展示Voyager4的開發設計過程重點說明所採取的步驟,並提供一些具體的實現案例,以協助您能更瞭解自行開發邊緣感測器的方法。

這是闡述Voyager4狀態監測平台開發的三部分系列文章的第2部分。

  • 本系列文章的第1部分介紹了Voyager4無線狀態監測感測器,包括感測器架構的關鍵元素、硬體設計、功耗分析和機械合。
  • 本系列文章的第2部分將重點討論軟體架構和AI演算法,並說明在Voyager4上開發和部署AI模型的完整系統級方法。
  • 本系列文章的第3部分將討論AI演算法的實際實現,以及Voyager4可以檢測的各種故障,例如不平衡、未對準和軸承缺陷。

 

概述

這裡簡要回顧了Voyager的工作原理。有關狀態監測感測器的更多資訊,以及關於Voyager4專案的專有硬體、功耗和安全特性的詳細資訊,請參閱本系列文章的第1部分。

圖1顯示了Voyager4的感測器工作原理。ADXL382三軸8 kHz數位微機電系統(MEMS)加速度計用於擷取振動資料。所擷取的資料會依據工作模式遵循不同的路徑。

Figure 1. Voyager4 modes of operation.

圖1.Voyager4工作模式。

路徑A是最初採用的路徑,原始振動資料直接發送到MAX32666 低功耗藍牙®(BLE)處理器。然後,資料可以透過無線BLE或USB發送給用戶。路徑B是一種替代工作模式,可以在利用Voyager擷取原始資料並透過 MAX78000外部工具訓練模型後使用該模式。資料不會發送給使用者,而是傳遞給邊緣AI演算法來預測機器故障。路徑C和D分別代表檢測到和未檢測到馬達故障的案例。如果檢測到故障,則可以透過BLE處理器向主機發送故障標誌或使用者警報。如果未檢測到故障,感測器將返回休眠模式,直到發生下一次檢測事件。

該架構是Voyager4軟體和AI演算法開發的重點。為了從系統層面全面理解該架構,本文將討論以下幾個層面:

  • BLE術語
  • BLE週邊裝置的實現
  • BLE中央裝置的實現
  • AI演算法的訓練和部署

BLE背景知識

設計工業邊緣感測器時,連接是關鍵設計因素之一。根據可用或所需的功率,連接會影響覆蓋範圍、可靠性、裝置整體壽命和尺寸等各個層面。如表1所示,相對於其他連接標準,BLE擁有一些特別的優勢。對於我們的工業監控案例而言,BLE的覆蓋範圍、功率和可靠性尤為重要。要瞭解BLE邊緣裝置的設計和開發,首先必須瞭解所有BLE專案都會使用的一些基本術語。

表1.無線連接標準比較
  範圍 功耗 可靠性 穩健性 總體持有成本 網格能力 安全性
Wi-Fi 100 m 高 低/單RF通道 低 高 是 是,WPA
BLE 20 m 至 100 m 低/中 中/高 低 中 是 是,AES
Zigbee, Thread 20 m 至 200 m 低/中 低 低 中 是 是,AES
Smart-MESH 20 m 至 200 m 低 高 高 低 是 是,AES
LoRa-WAN 500 m 至 3000 m 中 低 低 高 否 - 星型拓撲 是,AES

全面介紹BLE的所有特性將需要一本書的篇幅。本文將重點介紹實現BLE裝置時需要考慮的一些關鍵概念,包括:

  • 軟體堆疊
  • 週邊裝置/中央裝置模型
  • 協定和設定檔

BLE軟體堆疊

BLE軟體堆疊是一系列標準協定的集合,裝置必須支援這些協定才能被視為與BLE相容。為了協助您能更輕鬆地理解這個術語,圖2展示了堆疊內不同協定的分層方式。對於使用者通訊和裝置連接等進階功能,需要負責資料封裝和解析等基本任務的較低階協定提供支援。

Figure 2. A BLE stack.

圖2.BLE堆疊。

幸運的是,開發人員對堆疊組成部分有基本的瞭解通常就足夠了,他們可以從一系列已經實現各自版本堆疊的硬體裝置中進行選擇。使用者只需開發應用程式中負責控制裝置本身的部分,並利用預建構的BLE堆疊即可。

BLE堆疊通常由三個不同部分組成:應用程式、主機和控制器。應用程式定義使用者介面和使用者實現的具體應用程式碼(振動監測)。主機是指BLE軟體堆疊的上層,其控制設定檔和協定等進階功能。控制器是指BLE堆疊的底層,其處理鏈路層和實體層,如2.4 GHz無線電本身。此項目選擇使用MAX32666 BLE微控制器。這是一款低功耗Arm® Cortex®-M4微控制器,搭載低功耗藍牙5無線電,支援遠距離(4×)通訊和高資料吞吐速率(2 Mbps)。

週邊裝置/中央裝置模型

根據BLE裝置的作用,可以將其定義為週邊裝置或中央裝置。資料可以雙向流動,兩者之間最大的區別之一是其連接方式。在連接之前,週邊裝置會通告其能否連接,中央裝置則掃描可供連接的週邊裝置並發起連接。資料可以在週邊裝置和中央裝置之間雙向流動,但中央裝置被視為主機。較早期的BLE文件也將週邊裝置和中央裝置分別稱為伺服器和用戶端。

在我們的系統中,將Voyager平台定義為週邊裝置,其收集資料並將其發送到中央裝置。對於這個項目,為了簡化開發和便於理解,我們首先研究最簡單的情形:單一中央裝置與單一週邊裝置互動,如圖3所示。

Figure 3. A peripheral/central 1:1 model.

圖3.週邊裝置/中央裝置1:1模型。

協定和設定檔

在藍牙的命名術語中,協定和設定檔很容易混淆。簡單地說,協定是定義裝置操作的基本功能塊:資料封裝、格式、路由等。設定檔是組合在一起以支援基本工作模式的服務。其本質上是多種協定的組合,以實現某種整體功能。例如,電池服務設定檔可用於查詢裝置的剩餘電池電量。所有BLE裝置都必須實現非常重要的通用存取設定檔(GAP)和通用屬性設定檔(GATT),以便能夠連接到其他BLE裝置。GAP負責處理底層各項功能:廣播、裝置發現和連接管理。GATT負責管理裝置之間的進階資料組織和傳輸,使其能夠透過已建立的連接執行讀寫操作。

其他設定檔是可選的附加項,用於為裝置提供額外功能,例如接近設定檔(Proximity Profile)。這些設定檔包括由藍牙技術聯盟(SIG)創建的預定義設定檔。開發智慧型手錶或智慧電錶等典型裝置時,使用一組預定義的設定檔可能很有用,但對於需要實現大量自訂功能的裝置而言,預定義設定檔可能會帶來限制。

開發人員還可以使用並非由藍牙SIG創建的自訂設定檔,如此做法可以提升設計彈性,但會犧牲一定的可攜性。每個設定檔將其資料組織成服務,服務由多個特性組成,如圖4所示。

Figure 4. A custom command server profile.

圖4.自訂指令伺服器設定檔。

當中央裝置和週邊裝置之間形成連接時,中央裝置可以請求與該週邊裝置關聯的設定檔和服務。圖5顯示了中央裝置發出請求時,Voyager的GAP、GATT和自訂設定檔(及其服務)的結構。

Figure 5. A voyager profile structure.

圖5.Voyager設定檔結構。

對於Voyager,除了基本的GAP和GATT設定檔,我們還定義了一個用於指令伺服器的自訂設定檔,其處理來自中央裝置的指令,並返回資料或更新週邊裝置本身的配置。

韌體實現

BLE微控制器是該系統的核心,其確保所有週邊感測器和裝置的資料都可以由相連的BLE中央裝置搜尋或修改。

裝置配置

我們利用MAX32666上預先建構的BLE堆疊,透過填充相關配置功能來建構週邊裝置的外觀。例如,在圖6中,我們為掃描資料發現陣列提供了資料長度、廣播類型和一系列字元,每次Voyager上電時,週邊裝置設定函數都會調用該陣列。

Figure 6. Setting Voyager scanning data.

圖6.設定Voyager掃描資料。

像如此的BLE裝置將有大量的設定需要配置,包括無線電的傳輸功率和返回資料類型。建議從所使用硬體附帶的預建構範例入手,然後在其基礎上進行自訂修改。MAX32666提供了一個BLE資料伺服器(週邊裝置)的範例程式碼,名為BLE DATS,Voyager專案就是以此為基礎建構的。配置後,當中央裝置掃描可用裝置時,週邊裝置的名稱顯示為Voyager。這也可以用於過濾搜尋清單,以便中央裝置僅顯示預期名稱的裝置。如圖7所示,裝置名稱與裝置MAC位址和接收訊號強度指示(RSSI)一同顯示。

Figure 7. A central view of Voyager.

圖7.中央裝置中顯示的Voyager。

堆疊內的其他配置設定控制裝置其他模式的預期名稱和行為,例如製造商ID、對讀/寫指令的回應等。

指令伺服器

Voyager4應用的中心端和週邊端是同步設計的,因此可以利用含有單一BLE服務的自訂設定檔來簡化週邊裝置介面。該設定檔將負責接收來自中央裝置的指令,並以加速度計數據、溫度資料和其他裝置資訊的形式返回回應。

對於像Voyager如此複雜的裝置,採用該單一自訂服務進行BLE通訊是不同尋常的做法,但卻帶來了幾點好處。這種做法不僅支援Voyager版本之間的向下相容性,而且增強了指令彈性,因為透過將字串用於Voyager週邊裝置的指令輸入,應用可以根據資料的解析方式,彈性支援各種類型的指令和值。

一旦週邊裝置和中央裝置之間形成連接,為了建立雙向通訊,中央裝置就會向自訂特性發出通知指令,如圖11所示。如此就在週邊端建立了一個通知系統,並在中心端指定了相應的回呼函式。這表示每當有更新的資料分配給該自訂特性時,都會通知中央裝置,傳輸新資料,並觸發中央裝置的回呼函式。

韌體架構

圖8中的硬體示意圖顯示了Voyager中包含的各種元件以及相關的資料路徑和電源。大多數軟體發展都是在BLE微控制器上進行的,因為其作為指令中心,負責協調裝置的BLE介面以及感測器和微控制器資料的內部管道。為了與系統中的不同感測器和微控制器進行互動,我們必須開發供BLE微控制器和AI部分中討論的AI微控制器使用的裝置驅動程式。實際上,這些驅動程式的開發和整合占了聯網邊緣感測器所需程式化工作的很大一部分。

Figure 8. The Voyager4 hardware block diagram using the MAX3207E, DS28C40A, ADXL382, ADG1634, MAX32666, ADXL367, MAX78000, MAX17262, MAX20335, and MAX38642.

圖8.Voyager4硬體框圖,採用了 MAX3207E、DS28C40A、 ADXL382、 ADG1634、MAX32666, ADXL367、 MAX78000、MAX17262、MAX20335和 MAX38642。

編寫可移植程式碼

開發韌體時,我們將程式碼劃分成幾個抽象層,以將特定微控制器的具體細節與應用程式和驅動程式程式碼區分開來。這種做法很常見,通常會在應用層之外再劃分出三個明確的層次來管理不同的程式碼功能,即硬體抽象層(HAL)、板支援包(BSP)和驅動程式層。此架構如圖9所示。

Figure 9. A generic BSP-HAL architecture.

圖9.通用BSP-HAL架構。

HAL為程式與不同硬體的互動提供了一種統一方法,程式無需知道每個裝置的具體細節。BSP定義了依賴於硬體的軟體,而驅動程式層定義了各個裝置的更具體細節,如暫存器映射。例如,Voyager有兩個微控制器,MAX32666用於BLE連接,MAX78000 具有一個板載卷積神經網路(CNN)加速器。如圖10所示,Voyager中的HAL定義了微控制器、SPI和I2C將使用的基本通訊指令。舉例來說,任何裝置驅動程式發出任何SPI通訊請求時,此任務最初都會被委託給HAL中的SPI函數,然後HAL查找BSP的具體資訊,以便針對該微控制器使用正確的SPI指令。

Figure 10. The Voyager BSP HAL architecture.

圖10.Voyager BSP HAL架構。

對於系統中的每個電路板,HAL保持不變,但對於每個微控制器,BSP會更新。BSP還負責定義系統的通用建構模組,以將應用程式調用與所使用的具體裝置解耦。在圖10中,BSP中的MAIN_ADXL模組是所使用的底層加速度計的抽象塊。任何加速度計的常用指令(如初始化和讀取)都在BSP層中定義,而低階函數(如get_raw_xyz_data)則在ADXL382模組中的驅動程式級別上定義。將驅動程式程式碼從MAX32666移植到MAX78000微控制器時,加速度計程式碼保持不變,因為其僅與加速度計本身有關。只有BSP層中的檔需要更新,以便能夠與新微控制器通訊。

這對於系統中零組件的更換或升級來說,也具有明顯的優勢。在Voyager中,一個真實例子是我們決定升級所用的主加速度計。升級僅需更新驅動程式層中的程式碼,維護、修改和測試工作都得以簡化。

資料管道和BLE中央裝置

雖然溫度和電池資訊可根據要求提供給BLE中央裝置應用程式,但Voyager的主要作用是作為狀態監測器和振動感測器。關於資料吞吐速率和資料發送頻率,我們重點考慮振動感測器和典型狀態監測場景,例如每天進行一次短暫測量。BLE不支援高資料吞吐速率。ADXL382是一款高頻寬、3軸加速度計,在高性能模式下每秒每軸擷取16,000個樣本。根據系統所包含的元元件,有幾種資料發送方式可供選擇。

發送即時資料

沒有任何形式的緩衝,當中央裝置請求資料時,只要資料可用,便立即發送。這種方式在展示模式下很有用,可以即時展示高性能加速度計數據,但是電池電量很快就會耗盡,並且由於生成資料的速度超過發送的速度,資料封包會被丟棄或損壞。

從記憶體發送資料

另一種方式是將資料保存到快閃記憶體中。如此我們就可以安全地記錄加速度計數據,而不必擔心覆蓋以前的值。保存的資料隨後會直接發送到中央裝置,或在收到中央裝置的指令後進行報告。該系統不再是即時的(資料可能是幾分鐘甚至幾天前的),因此我們還可以利用BLE對資料封包的應答系統,確保資料完整無缺地到達中央裝置,如有任何資料丟失則重新發送。

對於典型的工業狀態監測場景而言,這種方案更為實用,但裝置的電池壽命大部分浪費在發送每天變化不大的振動資訊上。

在邊緣執行分析

為了延長電池續航時間,在邊緣執行一些分析會更好,確保僅相關資料才透過無線電鏈路傳輸。當然,這只有在邊緣產生具有意義洞察所需的功耗明顯低於透過BLE發送資料所需的功耗時才是可行的(有關這方面的更多資訊,請參閱本系列文章的第1部分)。

在圖8中可以看到,加速度計與兩個微控制器都有直接資料路徑。在我們於邊緣執行某些分析的案例中,AI微控制器可以直接從加速度計讀取振動資料,並使用板載AI模型進行分析。

設計中央裝置使用者介面

BLE週邊裝置與Voyager週邊裝置同步設計,因此兩者的對話模式存在非常大的彈性。一般來說,中央裝置需要掃描並連接Voyager週邊裝置,然後發送字串指令並處理其返回值。初次連接後,所有BLE指令都直接發送到週邊裝置的自訂服務進行解析。在本例中,中央裝置是Windows PC上的圖形化使用者介面(GUI),用Python編寫,並利用BLE週邊裝置庫(BLEak)發出標準BLE指令。BLEak建立在Python的asyncio標準庫之上,允許BLE指令非同步運行,確保使用者介面保持可互動狀態且不會凍結。

當GUI成功連接到週邊裝置時,系統會自動向Voyager的單一自訂特性發出通知指令,如圖11所示。如此可確保對此特性的任何更新都會報告給中央裝置。這一點很重要,因為Voyager會對後續指令提供應答或回應,表示這些指令是否已成功執行。

Figure 11. The Voyager central peripheral architecture.

圖11.Voyager中心/週邊裝置架構。

如何請求資料?

始終使用簡單的字串指令來請求資料。例如,中央裝置可以發出setphy 2指令,指示Voyager使用其2M無線電。這會提升資料通訊速度,但覆蓋範圍和可靠性會受到一定的影響。週邊裝置會解析此指令以確保其有效,然後以輸入值2調用自己的內部setphy函數,進而切換所用的無線電。如果Voyager成功執行了此函數,則Return: OK指令會被發回中央裝置並顯示給使用者。

解譯加速度計數據

接收資料之前,GUI使用者可以選擇使用setadxlcfg指令配置所連Voyager的加速度計。一旦週邊裝置發出啟動指令,加速度計數據就會從週邊裝置流向中央裝置。預設情況下,中央裝置和週邊裝置以即時資料模式運行,這對於展示目的很有用。

在週邊裝置端,內部先進先出(FIFO)緩衝區按照使用者指定的取樣速率填充新資料。一旦FIFO填滿,系統就會在Voyager自訂服務上設定一個標誌,通知週邊裝置有新資料可用。然後,資料被發送到週邊裝置並進行解析,轉化為x、y、z三個軸的加速度數據的格式化陣列。資料始終以圖形方式顯示,使用者可以選擇「保存資料」選項,以將資料保存到csv檔供以後分析。

Figure 12. The Voyager4 central GUI plotting data.

圖12.Voyager4中央裝置GUI繪圖資料。

AI演算法設計

本專案的目標是檢測馬達的健康狀況何時開始下降。邊緣AI分析目的在透過分析音訊、溫度、振動等一種或多種輸入資料,生成馬達健康狀況的指標或特徵,進而取代或補充人類資料分析。振動分析是現今狀態監測應用中常用的技術手段。

輸入

許多邊緣AI處理器往往非常耗電,這與無線狀態監測解決方案的目標之一(即延長續航時間)背道而馳。MAX78000(如前所述)能夠快速、低功耗地進行AI推理,其總功耗比使用無線BLE還要低。但是,在使用低功耗邊緣AI處理器時,應注意神經網路的規模不能超出電路板的規格。該板搭載一個512 kB資料記憶體的CNN加速器。其主要用於目標檢測、音訊處理和時間序列資料處理。

我們解決方案可用的資料是加速度時間序列。為了儘量提高所訓練演算法的性能,我們嘗試了幾種預處理方法,以確定哪種方法對準確度影響最大。本系列文章的第3部分將對此加以詳細討論。

訓練

線上資源「Analog Devices AI」GitHub詳細說明了訓練神經網路並將其部署到MAX78000的過程。一般來說,首先使用PyTorch®或TensorFlow®等常規工具集在主機PC上創建模型。此模型需要訓練資料,這些資料必須由目標裝置保存並傳輸到PC。輸入的一部分成為訓練集,專門用於訓練模型。還有一部分成為驗證集,用於觀察損失函數(網路性能的衡量標準)在訓練期間如何變化。

根據所用的模型類型,可能需要不同類型和數量的資料。要識別特定的馬達故障,您需要使用標註好的資料訓練模型。這些資料不僅要包含各種故障狀態下的振動資訊,還要包含無故障的正常狀態下的振動資料作為對比。

Figure 13. Voyager healthy training data.

圖13.Voyager健康狀況訓練資料。

Voyager最初採用自動編碼器類型的神經網路開發。自動編碼器無需藉由資料標籤就能學會如何對資料進行分類。雖然這種類型的模型不適合複雜的故障分類,但其可以快速完成訓練,並且僅需使用客戶已有的資料,例如正常運行馬達資料。

訓練所需的理想資料量因具體情況而異。關鍵在於擁有足夠的資料來學習正常運行馬達資料的一般趨勢,同時避免過度擬合。Voyager部署的默認範例僅使用了 30秒的正常運行加速度計數據進行訓練。同時保存了同樣數量的存在不平衡故障的資料以供驗證。兩個資料集均透過Python GUI直接保存到訓練PC中。

圖14.Voyager故障測試資料。

輸入資料用於訓練模型之前,經過了預處理。然後,訓練腳本按順序運行幾次訓練反覆運算,並挑選出表現突出的模型。為了測試目的,需要一些故障輸入資料。基於正常運行資料訓練模型後,務必先用故障資料進行測試,如此才能確保結果的可靠性。

如何部署演算法?

模型訓練完成後,必須使用ADI的線上工具集進行量化和合成。量化步驟透過捨入或截斷,將所生成模型的權重映射到更小的數值區間集合,進而減少模型儲存所需的記憶體。這是將神經網路部署到較小邊緣裝置的標準步驟。合成步驟將量化模型轉換成微控制器可理解的C檔。

此步驟生成三個檔,隨後必須將這些檔案複製到微控制器的活動項目中,並在下次韌體更新時載入。其中兩個檔(cnn.h和cnn.c)包含用於CNN配置的暫存器寫入操作,以及所載入模型的其他有用功能。第三個文件(weights.h)包含訓練(和量化)得到的模型權重。

透過有線更新(藉由除錯埠)或無線(OTA)更新載入新韌體後,就完成了模型部署,BLE微控制器就能依照需求查詢模型,執行AI推理。

部署後如何使用?

一旦部署新韌體,AI微控制器就會作為有限狀態機運行,透過SPI接受並回應來自BLE控制器的指令。

Figure 15. Microcontroller SPI communication.

圖15.微控制器SPI通訊。

收到推理請求時,AI微控制器會喚醒,並向加速度計請求數據。重要的一點是,其隨後會對該時間序列資料執行與訓練時相同的預處理步驟。最後,此預處理的輸出會送到已部署的神經網路,由其報告分類結果。

Figure 16. AI inference state machine.

圖16.AI推理狀態機。

出於省電考慮,AI微控制器被設計成在喚醒時自動執行推理。因此,BLE微控制器可以僅在需要進行分析時才啟動AI微控制器。

在典型設定中,BLE微控制器可以每天短暫地從低功耗休眠模式喚醒,請求對現有加速度計數據進行AI推理,如果資料不滿足於使用者設定的條件,例如模型以99%的置信度判斷資料正常,則返回休眠模式。反之,如果資料看起來異常或無法判斷是否正常時,則BLE微控制器可以連接到附近的BLE主機並共用資料。透過這種方式,在邊緣進行分析就無需主機系統理解資料,將可進一步節省電池電量。

結論

本文介紹了無線振動監測系統Voyager4,其採用邊緣AI分析來提升其作為狀態監測工具的智慧水準和電池續航時間。設計有效的狀態監測感測器需要考慮多個層面。我們討論了Voyager4的硬體訊號鏈、用於將不同系統元素整合在一起的韌體,以及該裝置作為BLE週邊裝置的外觀。我們還探討了AI在Voyager中的應用,並提供了有關如何開發和部署邊緣AI模型的一些見解。

請持續關注本系列的第3部分文章,瞭解有關Voyager板上AI演算法具體實現的更多資訊,其中並包括幾種常見馬達故障的分類。