开源、可重用的软件堆栈支持CbM的实时处理和算法开发

开源、可重用的软件堆栈支持CbM的实时处理和算法开发

生产之旅以及如何更快地做到这一点！

让我们考虑一个嵌入式系统从概念到生产的通用开发流程。图 1 提供了抽象流的顶层概览。

数据研究阶段之后是算法开发阶段，在此阶段证明了系统的应用或使用。这通常需要在最终移植到嵌入式系统的高级工具中开发模型或设计算法。然而，在优化设计之前，必须使用真实数据和硬件在环进行验证，而这正是 CN0549 真正擅长的地方，因为它不仅提供与流行的高级分析工具的直接集成，而且还允许硬件在循环验证。

一旦设计得到验证，优化和嵌入必要的软件组件的工作就开始了。在嵌入式设计细化阶段，这可能需要重新实现某些算法或软件层才能在 FPGA 或资源受限的微控制器中工作。在将设计移植到原型或接近生产硬件以进行最终验证时，必须非常小心地持续验证设计。

图 1. 嵌入式系统开发流程。

最后，我们到达了生产阶段，这可能与设计开始使用的原始开发环境几乎没有相似之处，但仍然需要满足相同的要求。由于最终系统可能已经远离原始研究系统，因此运行相同的代码或测试可能是不可能的或极其困难的。这可能会导致生产测试问题和单元故障，并且可能需要额外的时间和金钱投资来进行补救。

通过最大限度地重复使用来降低风险

软件开发流程和过程

CN0549 系统堆栈

图 2. CN0549 平台的系统堆栈。

建议开发人员从 Linux 开始学习并开始使用他们的系统进行开发，因为它提供了最多的工具。Linux 还提供了大量的软件包和驱动程序，为理想的开发环境创造了条件。一旦系统设计稳定并准备好进行优化，通常会切换到无操作系统并仅发布必要的软件。但是，这高度依赖于应用程序，由于它们提供的灵活性，许多人将发布完整的 Linux 系统。

与可编程逻辑的 HDL 一样，整个内核源代码、Kuiper Linux 映像和 No-OS 项目都是完全开源的，最终用户可以根据需要修改任何组件。如果需要，这些代码库也可以移植到不同的处理器系统或不同的运行时环境。

访问 CbM 数据——入门

使用 Arm 处理器和 PL 通常发生在设计流程的更进一步阶段，此时系统正在针对部署进行优化。因此，开发人员最初的一个常见入口点将涉及从工作站远程连接到嵌入式系统。在嵌入式系统上运行 Linux 时，由于基础架构的设计方式，在工作站上远程或本地运行代码是一个相对透明的过程。这主要是由于一个名为libIIO的开放库。 libIIO 是一个接口库，它允许对内核中 Linux IIO 框架内构建的不同设备驱动程序进行简化且一致的访问模型。该库是 CbM 平台使用如此灵活并提供数据流和设备控制功能的核心。

libIIO 本身分为两个主要组件：

称为 iiod 的 IIO 守护进程负责管理 libIIO 库或使用该库的客户端与实际驱动程序的内核接口之间的访问。

libIIO 和 iiod 本身是由不同的组件编写的，这些组件允许以不同的方法访问所谓的后端中的驱动程序。后端允许本地和远程用户对 libIIO 进行控制和数据流，并且由于它们是组件化的，因此可以将新的后端添加到系统中。目前，libIIO 支持四个后端：

本地：允许访问连接到同一台机器的硬件的本地可访问驱动程序。

网络：最常用的远程后端，它是基于 IP 的，用于跨网络访问驱动程序。

图 3. 使用网络后端的 libIIO 系统概要。

图 3 提供了如何使用 libIIO 的组件以及它们如何适应整个系统的系统级概览。图的左侧是嵌入式系统，它安装了 libIIO 库并运行 iiod 守护进程。从嵌入式系统，用户可以访问本地后端，甚至网络后端。在他们的代码中，他们可以通过单行更改在两者之间切换以解决任一后端。不需要对目标代码进行其他更改。

图 4. libIIO 远程与本地示例。

应用程序和工具

IIO 工具是一组与 libIIO 一起提供的命令行工具，可用于通过脚本进行低级调试和自动任务。例如，对于实验室测试，将平台设置为不同的采样率模式并收集一些数据可能很有用。这可以通过几行 bash 或通过利用 IIO 工具的批处理脚本轻松完成。图 5 显示了一个简单的示例，可以在本地或远程运行以修改采样率和更改 ADC 的输入共模。该示例使用了一个名为 iio_attr 的 IIO 工具，它允许用户轻松更新设备配置。

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

图 7. 频域模式下的 IIO 示波器捕获窗口。

算法开发环境集成

到目前为止，我们已经介绍了大多数工程师在首次使用 CN0549 时开始使用的核心低级工具。首先了解这些很重要，这样开发人员才能了解系统的灵活性以及他们可以使用的不同选择或接口。然而，在基线系统启动并运行后，开发人员将希望使用 MATLAB 或 Python 等工具快速将数据转移到算法开发中。这些程序可以从硬件导入数据。必要时可以设计额外的控制逻辑。

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

可通过 pip 和 conda 安装的 PyADI-IIO 将控制旋钮公开为易于使用和记录的属性。它还以通常可消化的类型（如 NumPy 数组或本机类型）提供数据，并在可用时处理数据流的单位转换。这使得 PyADI-IIO 可以轻松添加到 Jupyter Notebook 等环境中，并且可以轻松地将数据输入机器学习管道，而无需求助于不同的工具或复杂的数据转换——让开发人员可以专注于他们的算法，而不是一些困难的 API 或数据对话。

MATLAB 集成 - 连接到 MATLAB

图 10. 带有示波器的 Sensor Toolbox 流式传输示例。

使用 TensorFlow 的分类示例

让我们看看 Python 中的这种方法。在 PyADI-IIO 提供的一个示例中，通过将 CN0532 安装到摆动风扇上进行了多次测量。这是在风扇的不同设置（睡眠、常规、过敏原）下完成的，在每种模式下，捕获了 409，600 个样本。在检查图 11 中的数据时，很容易识别过敏原病例的时域，但其他两种情况更难区分。这些可能可以通过检查来识别，但是让算法识别这些情况可能在时域中容易出错。

为了帮助更好地区分用例，将数据转换为频域，并使用频谱图绘制不同频率随时间的浓度。与图 11 相比，图 12 中显示的频谱图在数据上的差异更加明显，并且在时间维度上保持一致。这些频谱图是有效的图像，现在可以使用传统的图像分类技术进行处理。

图 11. 时间序列中的风扇振动数据。

图 12. 捕获的振动数据的频谱图。

图 13. CNN 训练精度随时间变化的振动频谱图。

GitHub 上 PyADI-IIO 源代码树下的所有 Python 脚本、笔记本和数据集都可用于此示例。由于提供了数据集，TensorFlow 的示例演示甚至可以在没有 CN0549 硬件的情况下使用。然而，通过硬件，训练后的模型可以用于实时推理。

边缘到云：转向嵌入式解决方案

创建模型后，可以将其部署用于推理目的或决策制定。使用 CN0549，它可以放置在远程 PC 上，数据从 CN0540 流式传输或直接在嵌入式处理器上运行。根据实现的不同，将模型放置在处理器中将需要更多的工程努力，但可以提高一个数量级的功率效率，并且能够实时运行。幸运的是，在过去几年中，用于部署机器学习模型的工具和软件取得了巨大的发展增长。

利用 FPGA

图 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 网络拓扑。

图 15 中显示的最左侧配置是离线收集案例，它可能发生在远程站点或无法连接到 Internet 的地方。在这种情况下，大型存储介质将与平台共存，并按计划手动收集。或者，其他两个选项将数据流式传输到公共端点。图 15 的中间配置是一个孤立的网络，它可能仅位于组织内部，也可能只是位于远程位置的一组平台，用于集中收集数据。这可能是出于安全考虑或只是缺乏连接性而需要的。CN0549 的设置对于任何这些配置都很容易，并且可以针对最终部署的特定需求进行定制。

当云和本地进程之间存在一致的连接时，可以将不同的算法拆分为我们已经讨论过的需要或可以在本地运行的内容以及可以在云中运行的内容。这将在算法复杂性的处理能力要求、事件延迟以及可以发送到云的带宽限制之间进行自然权衡。但是，由于它非常灵活，因此可以轻松探索这些因素。

结论

CN0549 CbM 平台在开发应用程序时为设计人员提供系统灵活性和大量软件资源。围绕如何利用不同的组件进行 CbM 和预测性维护 （PdM） 开发进行了对软件堆栈的深入探讨。由于软件、HDL、原理图的开放性以及与数据科学工具的集成，设计人员可以在整个堆栈中利用其终端系统所需的组件。总之，这种状态监测设计提供了一种易于使用的开箱即用解决方案，并配有开源软件和硬件，以提供灵活性并允许设计人员在更短的时间内实现更好的定制结果。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。