在本文中，我們將重點介紹可用于CN0549不同組件的軟件生態系統、數據分析工具和軟件集成，以及工程師和數據科學家如何利用它們進行應用程序開發。這是關于使用 CN0549 開發平臺的基于狀態的監控 （CbM） 和預測性維護 （PdM） 應用程序的兩部分系列文章中的第二篇。新平臺旨在加速定制 CbM 解決方案從原型到生產的開發流程。第 1 部分側重于 MEMS 振動技術和捕獲用于 CbM 應用的高質量振動數據。

生產之旅以及如何更快地做到這一點！

在構建狀態監測解決方案時，它們必須包含傳感器、本地處理、連接以及某種形式的軟件或固件，以使其全部發揮作用。CN0549 通過為硬件和軟件方面提供可定制的選項來解決所有這些挑戰，因此工程師和軟件開發人員可以在使用通用工具和基礎設施的同時在其應用程序中進行設計權衡。例如，如果您想選擇一個特定的微控制器或 FPGA 進行處理，更喜歡使用 Python 編碼，或者有一個您想要重用的最喜歡的傳感器。這使得 CN0549 成為那些希望構建優化的 CbM 解決方案的強大平臺，可以根據他們的需求定制處理、功率、性能、軟件和數據分析。

嵌入式系統開發流程

讓我們考慮一個嵌入式系統從概念到生產的通用開發流程。圖 1 提供了抽象流的頂層概覽。

圖 1 所示設計過程的第一步是數據研究階段。在此階段，用戶將他們的需求映射到其應用程序所需的不同硬件和軟件需求。從硬件角度來看，這些參數可能是沖擊容限、模擬信號帶寬或測量范圍等參數。在考慮軟件要求時，樣本數量、采樣率、頻譜、過采樣和數字濾波是 CbM 應用的重要參數。該平臺非常有用且靈活，允許研究人員使用不同的傳感器組合并根據自己的應用需求調整數據采集參數。

數據研究階段之后是算法開發階段，在此階段證明了系統的應用或使用。這通常需要在最終移植到嵌入式系統的高級工具中開發模型或設計算法。然而，在優化設計之前，必須使用真實數據和硬件在環進行驗證，而這正是 CN0549 真正擅長的地方，因為它不僅提供與流行的高級分析工具的直接集成，而且還允許硬件在循環驗證。

一旦設計得到驗證，優化和嵌入必要的軟件組件的工作就開始了。在嵌入式設計細化階段，這可能需要重新實現某些算法或軟件層才能在 FPGA 或資源受限的微控制器中工作。在將設計移植到原型或接近生產硬件以進行最終驗證時，必須非常小心地持續驗證設計。

圖 1. 嵌入式系統開發流程。

最后，我們到達了生產階段，這可能與設計開始使用的原始開發環境幾乎沒有相似之處，但仍然需要滿足相同的要求。由于最終系統可能已經遠離原始研究系統，因此運行相同的代碼或測試可能是不可能的或極其困難的。這可能會導致生產測試問題和單元故障，并且可能需要額外的時間和金錢投資來進行補救。

通過最大限度地重復使用來降低風險

在設計過程中降低風險的最簡單方法之一是在每個階段重復使用盡可能多的硬件和軟件組件，CN0549 為開發人員提供了許多開箱即用的資源，以便在開發流程的所有階段直接利用。CN0549 解決方案提供原理圖和電路板布局文件、用于優化和全功能環境的開放軟件堆棧，以及用于 MATLAB? 和 Python 等高級工具的集成選項。最終用戶可以利用 ADI 的經過驗證的組件，并在從研究到生產的過程中選擇他們想要維護或更改的組件。這也使最終用戶能夠專注于算法開發和系統集成，而不是使用 ADI 零件的原理圖輸入或基礎軟件開發。利用硬件模塊和重用軟件層，

軟件開發流程和過程

CN0549 在開發過程中為工程師提供了多種選擇，使他們能夠使用常用語言（包括 C 或 C++）工作，同時使用他們熟悉的數據分析工具，例如 MATLAB 或 Python。這主要是通過利用和構建開放標準以及支持來自不同制造商的多個嵌入式平臺的現有解決方案來完成的。

CN0549 系統堆棧

圖 2 所示的系統堆棧提供了構成 CN0549 系統的不同組件的基本概覽。左上角的深藍色方框是傳感器和數據采集 （DAQ） 板，而淺藍色和紫色方框勾勒出用于數據處理的 FPGA 分區。該平臺直接支持英特爾 DE10-Nano 和 Xilinx? CoraZ7-07s，涵蓋兩大主要 FPGA 供應商。綠色框表示與主機 PC 的連接。這提供了從硬件到用于算法開發的高級數據分析工具的直接數據訪問。

所有 HDL 代碼都是開源的，它允許開發人員進行修改以將數字信號處理 （DSP） 插入可編程邏輯 （PL） 內的數據流中，如圖 2 所示。這可以是從濾波器到狀態機的任何東西，甚至是機器學習，根據你的系統劃分，這一步也可以在用戶空間或者應用層完成。由于代碼是公開可用的，它可以移植到來自不同制造商的其他 FPGA 或移植到不同的處理器系列，具體取決于您的最終應用需求。

圖 2. CN0549 平臺的系統堆棧。

Arm? 處理器內部有兩個軟件選項。它們的使用將取決于用例，并且大多數開發人員都可能會使用它們：

Linux?：為內核中的輸入輸出工業 （IIO） 框架內構建的 DAQ shield 提供內核驅動程序。這與一個名為 Kuiper Linux 的完整嵌入式 Linux 發行版相結合，該發行版在 Arm 核心用戶空間中運行并基于 Raspberry Pi OS。

無操作系統：裸機項目提供了與 Linux 內核中使用的相同驅動程序，可與 Xilinx 或 Intel 的 SDK 一起使用。這也可以作為替代實現方式實現到實時操作系統 （RTOS） 環境中。

建議開發人員從 Linux 開始學習并開始使用他們的系統進行開發，因為它提供了最多的工具。Linux 還提供了大量的軟件包和驅動程序，為理想的開發環境創造了條件。一旦系統設計穩定并準備好進行優化，通常會切換到無操作系統并僅發布必要的軟件。但是，這高度依賴于應用程序，由于它們提供的靈活性，許多人將發布完整的 Linux 系統。

與可編程邏輯的 HDL 一樣，整個內核源代碼、Kuiper Linux 映像和 No-OS 項目都是完全開源的，最終用戶可以根據需要修改任何組件。如果需要，這些代碼庫也可以移植到不同的處理器系統或不同的運行時環境。

圖 2 的最后一個組件是與主機 PC 的連接，如綠色框所示。運行系統時，可以配置設備，并將數據流式傳輸到主機系統進行分析，開發人員將在主機上利用 MATLAB 或 TensorFlow 等標準工具創建算法。然后最終將這些算法轉移到嵌入式目標，允許它們使用本地處理能力進行更快的算法開發迭代。

訪問 CbM 數據——入門

使用 Arm 處理器和 PL 通常發生在設計流程的更進一步階段，此時系統正在針對部署進行優化。因此，開發人員最初的一個常見入口點將涉及從工作站遠程連接到嵌入式系統。在嵌入式系統上運行 Linux 時，由于基礎架構的設計方式，在工作站上遠程或本地運行代碼是一個相對透明的過程。這主要是由于一個名為libIIO的開放庫。 libIIO 是一個接口庫，它允許對內核中 Linux IIO 框架內構建的不同設備驅動程序進行簡化且一致的訪問模型。該庫是 CbM 平臺使用如此靈活并提供數據流和設備控制功能的核心。

libIIO 本身分為兩個主要組件：

libIIO 庫，這是一個用于訪問不同 IIO 驅動程序屬性或函數的 C 庫。這包括流入和流出 ADC、DAC 和傳感器等設備的數據流。

稱為 iiod 的 IIO 守護進程負責管理 libIIO 庫或使用該庫的客戶端與實際驅動程序的內核接口之間的訪問。

libIIO 和 iiod 本身是由不同的組件編寫的，這些組件允許以不同的方法訪問所謂的后端中的驅動程序。后端允許本地和遠程用戶對 libIIO 進行控制和數據流，并且由于它們是組件化的，因此可以將新的后端添加到系統中。目前，libIIO 支持四個后端：

本地：允許訪問連接到同一臺機器的硬件的本地可訪問驅動程序。

USB：利用 libusb，此后端允許通過 USB 鏈接遠程控制驅動程序。

串行：為通過串行連接連接的板提供更通用的接口。UART 是最常見的用途。

網絡：最常用的遠程后端，它是基于 IP 的，用于跨網絡訪問驅動程序。

圖 3. 使用網絡后端的 libIIO 系統概要。

圖 3 提供了如何使用 libIIO 的組件以及它們如何適應整個系統的系統級概覽。圖的左側是嵌入式系統，它安裝了 libIIO 庫并運行 iiod 守護進程。從嵌入式系統，用戶可以訪問本地后端，甚至網絡后端。在他們的代碼中，他們可以通過單行更改在兩者之間切換以解決任一后端。不需要對目標代碼進行其他更改。

圖 4. libIIO 遠程與本地示例。

圖 3 的左側代表一個遠程主機，它可以運行任何操作系統。有適用于 Windows、macOS、Linux 和 BSD 的官方軟件包。圖中使用了網絡或基于 IP 的后端，但這也可以是串行、USB 或 PCIe 連接。從用戶的角度來看，libIIO 可以從 C 庫本身或許多與其他語言的可用綁定中得到利用，包括：Python、C#、Rust、MATLAB 和 Node.js。為需要與其應用程序中的不同驅動程序交互的用戶提供大量選擇。

應用程序和工具

在開始使用新設備時，一般不建議直接使用 libIIO。因此，存在許多構建在 libIIO 之上的更高級別的應用程序，它們為任何 IIO 設備從命令行和 GUI 格式提供基本的可配置性。這些分別是 IIO 工具和 IIO 示波器。

IIO 工具是一組與 libIIO 一起提供的命令行工具，可用于通過腳本進行低級調試和自動任務。例如，對于實驗室測試，將平臺設置為不同的采樣率模式并收集一些數據可能很有用。這可以通過幾行 bash 或通過利用 IIO 工具的批處理腳本輕松完成。圖 5 顯示了一個簡單的示例，可以在本地或遠程運行以修改采樣率和更改 ADC 的輸入共模。該示例使用了一個名為 iio_attr 的 IIO 工具，它允許用戶輕松更新設備配置。

圖 5. IIO 工具的 iio_attr 部分的示例用法。

但是，用戶最常見的入口點是 GUI 應用程序 IIO 示波器，通常稱為 OSC。OSC 與 IIO 工具一樣，被設計成通用的，可以控制任何 IIO 驅動程序，并且由于它基于 libIIO，它可以遠程運行或在板上運行。但是，它還包含一個插件系統，其中可以為特定驅動程序或驅動程序組合添加專門的選項卡。圖 6 顯示了為基于CN0540的板自動加載的插件選項卡，包括控制和監控選項卡。這些選項卡提供了一個簡單的界面來訪問 CN0540 的 ADC、DAC 和控制引腳的低級功能，以及數據采集板和測試點監控的基本圖。Analog Devices上提供了更多 OSC 文檔 如果您想了解其他可用的默認選項卡和插件，請訪問Wiki 。

OSC 的最后一個重要方面是捕獲窗口。捕獲窗口為從 ADC 或任何基于 libIIO 的緩沖區收集的數據提供繪圖功能。圖 7 顯示了在頻域模式下使用的捕獲窗口，其中繪制了數據的頻譜信息。其他圖，包括時域圖、相關圖和星座圖，都是可用的。這對于抽查設備、調試或在評估過程中很有用。這些圖包括常見的實用程序，如標記、峰值檢測、諧波檢測，甚至相位估計。由于 OSC 也是開源的，因此任何人都可以對其進行擴展以添加更多插件或繪圖，甚至修改現有功能。

圖 7. 頻域模式下的 IIO 示波器捕獲窗口。

算法開發環境集成

到目前為止，我們已經介紹了大多數工程師在首次使用 CN0549 時開始使用的核心低級工具。首先了解這些很重要，這樣開發人員才能了解系統的靈活性以及他們可以使用的不同選擇或接口。然而，在基線系統啟動并運行后，開發人員將希望使用 MATLAB 或 Python 等工具快速將數據轉移到算法開發中。這些程序可以從硬件導入數據。必要時可以設計額外的控制邏輯。

在機器學習開發周期的上下文中，通常有一個通用流程，開發人員將遵循獨立于他們所需的軟件環境來處理數據。圖 8 中概述了此過程的一個示例，其中收集數據，分為測試和訓練，開發模型或算法，最后部署模型以進行現場推理。對于實際服務，會不斷執行整個過程，以將新知識引入生產模型。TensorFlow、PyTorch 或 MATLAB 機器學習工具箱等工具都考慮到了這個過程。這個過程是有意義的，但通常可以忽略或完全忽略收集、組織和管理數據的復雜任務。為了簡化這項任務，

Python 集成——連接到 Python 分析工具

首先，從 Python 開始，CN0549 的設備特定類可通過模塊PyADI-IIO獲得。圖 6 提供了一個配置設備采樣率和通過以太網提取緩沖區的簡單示例。沒有復雜的寄存器序列、晦澀的內存控制調用或需要記憶的隨機位。這是由驅動程序、libIIO 和 PyADI-IIO 為您管理的，這些驅動程序在電路板上運行、在工作站上遠程運行，甚至在云中。

可通過 pip 和 conda 安裝的 PyADI-IIO 將控制旋鈕公開為易于使用和記錄的屬性。它還以通常可消化的類型（如 NumPy 數組或本機類型）提供數據，并在可用時處理數據流的單位轉換。這使得 PyADI-IIO 可以輕松添加到 Jupyter Notebook 等環境中，并且可以輕松地將數據輸入機器學習管道，而無需求助于不同的工具或復雜的數據轉換——讓開發人員可以專注于他們的算法，而不是一些困難的 API 或數據對話。

MATLAB 集成 - 連接到 MATLAB

在 MATLAB 方面，通過 Analog Devices 傳感器工具箱提供對 CN0549 及其組件的支持。該工具箱與 PyADI-IIO 一樣，具有針對不同部件的設備特定類，并將它們作為 MATLAB 系統對象 （MSO） 實現。MSO 是 MathWorks 作者可以與硬件和不同軟件組件接口的標準化方式，并提供高級功能來協助代碼生成、Simulink 支持和一般狀態管理。許多 MATLAB 用戶可能會在不知情的情況下利用作為 MSO 實現的 MATLAB 功能，例如示波器或信號發生器。在圖 10 中，我們使用 CN0532 接口和 DSP 頻譜分析儀示波器，兩者均作為 MSO 實現。同樣，像 PyADI-IIO 一樣，有一個對傳統 MATLAB 用戶友好的界面。

除了硬件連接之外，傳感器工具箱還集成了用于 HDL 和 C/C++ 的代碼生成工具。這些是用于開發、仿真和部署 IP 的絕佳工具，即使對于那些不熟悉 HDL 設計或工具但了解 MATLAB 和 Simulink 的人來說也是如此。

圖 10. 帶有示波器的 Sensor Toolbox 流式傳輸示例。

使用 TensorFlow 的分類示例

CN0549 套件提供了幾個示例，從基本數據流到機器學習分類示例。時間序列數據的機器學習，例如來自CN0532的振動數據，可以從幾個不同的角度進行處理。這可以包括支持向量機 （SVM）、長短期記憶 （LSTM） 模型，如果數據被直接解釋為時間序列，甚至可以包括自動編碼器。但是，在許多情況下，將時間序列問題轉換為圖像處理問題并利用在該應用領域開發的豐富知識和工具會更方便。

讓我們看看 Python 中的這種方法。在 PyADI-IIO 提供的一個示例中，通過將 CN0532 安裝到擺動風扇上進行了多次測量。這是在風扇的不同設置（睡眠、常規、過敏原）下完成的，在每種模式下，捕獲了 409，600 個樣本。在檢查圖 11 中的數據時，很容易識別過敏原病例的時域，但其他兩種情況更難區分。這些可能可以通過檢查來識別，但是讓算法識別這些情況可能在時域中容易出錯。

為了幫助更好地區分用例，將數據轉換為頻域，并使用頻譜圖繪制不同頻率隨時間的濃度。與圖 11 相比，圖 12 中顯示的頻譜圖在數據上的差異更加明顯，并且在時間維度上保持一致。這些頻譜圖是有效的圖像，現在可以使用傳統的圖像分類技術進行處理。

將數據集拆分為訓練集和測試集，將頻譜圖輸入到具有三個密集層的僅中性網絡 （NN） 模型和較小的卷積神經網絡 （CNN） 模型中。兩者都是在 TensorFlow 中實現的，并且能夠在不到 100 個 epoch 內輕松收斂到接近 100% 的測試驗證。CNN 在大約一半的時間內以大約 1% 的可調參數收斂，使其成為迄今為止更高效的設計。圖 13 中提供了精度與 epoch 的訓練收斂圖，以概述 CNN 的快速收斂。

圖 11. 時間序列中的風扇振動數據。

圖 12. 捕獲的振動數據的頻譜圖。

圖 13. CNN 訓練精度隨時間變化的振動頻譜圖。

GitHub 上 PyADI-IIO 源代碼樹下的所有 Python 腳本、筆記本和數據集都可用于此示例。由于提供了數據集，TensorFlow 的示例演示甚至可以在沒有 CN0549 硬件的情況下使用。然而，通過硬件，訓練后的模型可以用于實時推理。

邊緣到云：轉向嵌入式解決方案

創建模型后，可以將其部署用于推理目的或決策制定。使用 CN0549，它可以放置在遠程 PC 上，數據從 CN0540 流式傳輸或直接在嵌入式處理器上運行。根據實現的不同，將模型放置在處理器中將需要更多的工程努力，但可以提高一個數量級的功率效率，并且能夠實時運行。幸運的是，在過去幾年中，用于部署機器學習模型的工具和軟件取得了巨大的發展增長。

利用 FPGA

Xilinx 和 Intel 都擁有高級綜合 （HLS） 工具，可將高級語言轉換為在 FPGA 上運行的 HDL 代碼。這些通常會與 TensorFlow、PyTorch 或 Caffe 等 Python 框架集成，以幫助將模型轉換為 IP 內核——允許工程師將 IP 部署到 DE10-Nano、Cora Z7-07S 或自定義系統。然后將這些 IP 內核拼接到 ADI 提供的開放式 HDL 參考設計中。圖 14 顯示了 Vivado 的 Cora Z7-07S CN0540 的帶注釋屏幕截圖，重點關注數據路徑。在設計中，來自 CN0540 的數據通過 SPI 引腳讀取，24 位樣本由 SPI 引擎解釋并傳遞到 DMA 控制器到內存中。任何 DSP 或機器學習模型都可以直接在數據路徑中插入到此管道中。

圖 14. Vivado 2019.1 中顯示的 Cora Z7-07S HDL 參考設計數據路徑。

利用微處理器

與其將算法轉換為 HDL 層，不如直接在 Arm 內核中運行。根據算法的數據速率和復雜性，這是一條合理的開發路徑，通常更直接。為 Arm 內核開發 C 代碼甚至可能是 Python 將比 HDL 花費更少的開發資源和時間，并且通常更易于維護。

MATLAB Embedded Coder 等工具甚至可以簡化這一過程，并自動將 MATLAB 轉換為針對 Arm 內核的可嵌入和優化的 C 代碼?；蛘?，TensorFlow 擁有諸如 TensorFlow Lite 之類的工具，它們是其 Python 庫的可嵌入 C 版本，以允許更簡單地過渡到嵌入式目標。

智能決策拓撲

基于狀態的監控并不是一刀切的適用于硬件和軟件的所有空間，這就是 CN0549 設計靈活的原因。當我們考慮諸如 CbM 異常檢測之類的問題時，通?？梢詮膬蓚€時間尺度來處理：一個是我們需要立即做出反應，例如在與安全相關的場景中，或者在與維護或維護更相關的長期時間尺度上。設備更換。兩者都需要不同的算法、處理能力和方法。

作為理想情況下的機器操作員，我們將擁有一個大型數據湖來訓練我們的模型，并且既可以處理沒有干擾事件的短期檢測，又可以從正在運行的設備連續傳輸數據以用于未來的維護預測。然而，對于大多數運營商而言，情況可能并非如此，數據湖更像是干涸的河床?？紤]到安全問題、物理位置、網絡或拓撲要求，一些現成的解決方案也可能難以執行數據收集。這些困難推動了對更多定制解決方案的需求。

圖 15. CbM 網絡拓撲。

CN0549 是具有多種連接選項的獨立系統。由于它運行標準 Linux，以太網和 Wi-Fi 等傳統網絡堆棧開箱即用，如果需要，甚至可以連接蜂窩調制解調器。在實際應用中，有幾個典型的拓撲比較突出，如圖 15 所示。

圖 15 中顯示的最左側配置是離線收集案例，它可能發生在遠程站點或無法連接到 Internet 的地方。在這種情況下，大型存儲介質將與平臺共存，并按計劃手動收集?；蛘撸渌麅蓚€選項將數據流式傳輸到公共端點。圖 15 的中間配置是一個孤立的網絡，它可能僅位于組織內部，也可能只是位于遠程位置的一組平臺，用于集中收集數據。這可能是出于安全考慮或只是缺乏連接性而需要的。CN0549 的設置對于任何這些配置都很容易，并且可以針對最終部署的特定需求進行定制。

最終配置是直接云選項，每個平臺直接訪問互聯網并將測量推送到云端。由于 CN0549 在 Linux 上運行，因此該平臺可以通過 Python 等語言輕松利用 Microsoft Azure IoT 或 Amazon IoT Greengrass 等不同云供應商的 API——為開始為新連接的設備構建數據湖創造了一條簡單的途徑。

當云和本地進程之間存在一致的連接時，可以將不同的算法拆分為我們已經討論過的需要或可以在本地運行的內容以及可以在云中運行的內容。這將在算法復雜性的處理能力要求、事件延遲以及可以發送到云的帶寬限制之間進行自然權衡。但是，由于它非常靈活，因此可以輕松探索這些因素。

結論

CN0549 CbM 平臺在開發應用程序時為設計人員提供系統靈活性和大量軟件資源。圍繞如何利用不同的組件進行 CbM 和預測性維護 （PdM） 開發進行了對軟件堆棧的深入探討。由于軟件、HDL、原理圖的開放性以及與數據科學工具的集成，設計人員可以在整個堆棧中利用其終端系統所需的組件。總之，這種狀態監測設計提供了一種易于使用的開箱即用解決方案，并配有開源軟件和硬件，以提供靈活性并允許設計人員在更短的時間內實現更好的定制結果。

審核編輯：郭婷