Voyager4 邊緣AI ADI BLE 無線狀態監測

結合MEMS/BLE實現低功耗監測(2) 韌體架構串聯邊緣AI推理

2026-08-03
將 AI 技術(包含邊緣與雲端)嵌入整合類比/數位元件的感測器中,能為工業系統帶來高度智慧化。不過,在選擇 AI 演算法時,工程師必須全面評估運算延遲、數據頻寬、功耗管理與模型適用性等相互牽制的條件。若您已閱讀過前文關於 Voyager4 無線狀態監測感測器的硬體實作,本篇將進一步延伸至軟體設計,深入解構其邊緣感測軟體架構、演算法運用,並系統化地呈現 Voyager4 AI 模型從建構到落地的完整歷程。

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

狀態監測感測器軟體架構

Voyager4是由ADI開發的無線狀態監測平台,開發人員可利用此平台快速將無線解決方案部署到機器或測試環境並進行測試。Voyager4等馬達健康狀況監控解決方案適用於機器人及各類旋轉機械等應用。

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

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

本文將透過Voyager4的開發設計過程,說明系統開發的重要步驟,並提供具體實作案例,作為開發邊緣感測器時的設計參考。

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

► 本系列文章的第1部分介紹了Voyager4無線狀態監測感測器,包括感測器架構的關鍵元素、硬體設計、功耗分析和機械合。

► 本系列文章的第2部分將重點討論軟體架構和AI演算法,並說明在Voyager4上開發和部署AI模型的完整系統級方法。

► 本系列文章的第3部分將討論AI演算法的實際實現,以及Voyager4可以檢測的各種故障,例如不平衡、未對準和軸承缺陷。

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

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

圖1 Voyager4運作模式

 

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

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

BLE背景知識

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

全面介紹BLE的所有特性將需要一本書的篇幅。本文將介紹BLE軟體堆疊、週邊裝置與中央裝置模型,以及協定與設定檔等重要概念。

BLE軟體堆疊

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

圖2 BLE堆疊

 

一般而言,開發人員對堆疊組成部分有基本認識即可,開發人員可從一系列已提供完整BLE堆疊的硬體裝置中進行選擇。使用者只需開發應用程式中負責控制裝置本身的部分,並利用預先建置的BLE堆疊即可。

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

週邊裝置/中央裝置模型

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

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

圖3 週邊裝置與中央裝置1:1架構

 

協定和設定檔

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

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

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

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

 

當中央裝置和週邊裝置之間形成連接時,中央裝置可以請求與該週邊裝置關聯的設定檔和服務。圖5顯示中央裝置提出請求時,Voyager的GAP、GATT及自訂設定檔(含各項服務)的架構。對於Voyager,除了基本的GAP和GATT設定檔,還加入一個用於指令伺服器的自訂設定檔,其處理來自中央裝置的指令,並回傳資料或更新週邊裝置本身的配置。

圖5 Voyager設定檔結構

 

BLE韌體架構

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

裝置配置

利用MAX32666內建的BLE堆疊,只需設定相關配置參數,即可完成週邊裝置的BLE識別資訊。如圖6所示,設定掃描資料陣列的資料長度、廣播類型及一系列字元後;每次Voyager上電時,週邊裝置初始化函式都會呼叫該陣列。

圖6 設定Voyager掃描回應資料

 

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

圖7 中央裝置顯示的Voyager

 

指令伺服器

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

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

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

韌體架構

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

圖8 Voyager4硬體框圖及主要元件配置

 

可移植程式碼設計

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

圖9 通用BSP/HAL架構

 

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

圖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傳送資料所需的功耗時才是可行的。

圖11可以看到,加速度計與兩個微控制器都有直接資料路徑。在此運作模式下,AI微控制器可以直接從加速度計讀取振動資料,並使用板載AI模型進行分析。

圖11 Voyager中央裝置與週邊裝置架構

 

設計中央裝置使用者介面

由於Voyager的BLE通訊介面與整體系統同步設計,因此中央裝置與Voyager之間的通訊方式具有高度彈性。一般而言,中央裝置會先搜尋並連接Voyager裝置,再傳送字串指令,並處理裝置回傳的資料。完成初次連線後,所有BLE指令都會直接傳送至週邊裝置的自訂服務進行解析。本設計中的中央裝置為Windows PC上的圖形化使用者介面(GUI),以Python撰寫,並透過BLEak函式庫發送標準BLE指令。BLEak建構於Python標準函式庫asyncio之上,可讓BLE指令以非同步方式執行,確保使用者介面維持正常回應,不會發生凍結。

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

資料請求流程

系統透過簡單的字串指令請求資料。例如,中央裝置可以送出setphy 2指令,指示Voyager使用其2M無線電。這會提升資料通訊速度,但覆蓋範圍和可靠性會受到一定的影響。週邊裝置會先解析指令內容,確認其有效後,再呼叫內部的setphy函式,切換所使用的無線電設定。如果Voyager成功執行了此函數,則回傳Return: OK訊息至中央裝置並顯示給使用者。

解譯加速度計資料

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

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

圖12 Voyager4中央裝置GUI顯示資料

 

AI演算法設計

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

輸入

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

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

訓練

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

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

圖13 Voyager健康狀態訓練資料

 

訓練所需的理想資料量因具體情況而異。關鍵在於擁有足夠的資料來學習正常運行馬達資料的一般趨勢,同時避免過度擬合。

Voyager部署的預設認範例僅使用了30秒的正常運行加速度計資料進行訓練。同時儲存相同數量的存在不平衡故障的資料以供驗證。兩個資料集均透過Python GUI直接儲存至訓練PC中。

輸入資料用於訓練模型之前,先經過預處理。訓練腳本依序進行多次訓練迭代,並挑選表現最佳的模型。為了測試目的,需要一些故障輸入資料。基於正常運行資料訓練模型後,務必先用故障資料進行測試,以確保結果的可靠性,如圖14。

圖14 Voyager故障輸入測試資料

 

模型部署流程

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

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

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

模型部署後的運作流程

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

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

圖15 微控制器SPI通訊

 

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

圖16 AI推理狀態機

 

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

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

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

(本文作者為ADI系統應用工程師)

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!