未来工厂：利用搭载人工智能的传感器在边缘做出决策—第2部分
阅读本系列中的其他文章：
摘要
提升工业系统智能化的方法有多种，其中包括将边缘和云端人工智能(AI)技术应用于配备模拟和数字器件的传感器。鉴于AI技术方法的多样性，传感器设计人员需要考虑多个相互冲突的要求，包括决策延迟、网络使用、功耗/电池寿命以及适合机器的AI模型。上一篇文章重点介绍了基于AI的无线状态监控传感器Voyager4的概况和硬件设计。本文将重点讨论为智能边缘传感器创建的软件架构和AI算法，并说明在 Voyager4上开发AI模型的完整系统级方法。
状态监控传感器的软件设计
Voyager4 是由ADI公司开发的无线状态监控平台，开发人员借助它能够快速将无线解决方案部署到机器或测试设置并进行测试。Voyager4等电机健康状况监控解决方案广泛应用于各行各业，例如机器人以及涡轮机、风扇、泵、电机等旋转机械。
为这样的无线边缘设备开发软件可能很困难。从传感器设计的早期阶段开始，开发人员就必须考虑整体系统架构，系统的各个部分如何运行，如何集成不同组件以协同工作，以及如何应用和部署有用的算法与分析工具（如神经网络）来提升边缘智能水平。
对于此类项目，主要目标就是为边缘设备和所连主机创建易于理解、可修改、可升级的软件。Voyager4内部有两个微控制器和许多外设，包括传感器、电源管理板、闪存和通信接口。开发旨在控制和整合每个部分的代码是一项艰巨的任务。
本文希望通过展示Voyager4的开发设计过程，重点说明所采取的步骤，并提供一些具体的实现案例，以帮助读者更好地了解自行开发边缘传感器的方法。
这是阐述Voyager4状态监控平台开发的三部分系列文章的第2部分。
- 本系列文章的第1部分介绍了Voyager4无线状态监控传感器，包括传感器架构的关键元素、硬件设计、功耗分析和机械集成。
- 本系列文章的第2部分将重点讨论软件架构和AI算法，并说明在Voyager4上开发和部署AI模型的完整系统级方法。
- 本系列文章的第3部分将讨论A I算法的实际实现，以及Voyager4可以检测的各种故障，例如不平衡、未对准和轴承缺陷。
概述
这里简要回顾了Voyager的工作原理。有关状态监控传感器的更多信息，以及关于Voyager4项目的专有硬件、功耗和安全特性的详细信息，请参阅本系列文章的第1部分。
图1显示了Voyager4的传感器工作原理。ADXL382 三轴8 kHz数字微机电系统(MEMS)加速度计用于采集振动数据。采集的数据会依据工作模式遵循不同的路径。
图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项目都会使用的一些基本术语。
| 范围 | 功耗 | 可靠性 | 稳健性 | 总拥有成本 | 网格能力 | 安全性 | |
| 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 | Medium | 低 | 低 | 高 | 否 - 星型拓扑 | 是, AES |
全面介绍BLE的所有特性将需要一本书的篇幅。本文将重点介绍实现BLE设备时需要考虑的一些关键概念，包括：
- 软件堆栈
- 外围设备/中心设备模型
- 协议和配置文件
BLE软件堆栈
BLE软件堆栈是一系列标准协议的集合，设备必须支持这些协议才能被视为与BLE兼容。为了帮助读者更轻松地理解这个术语，图2展示了堆栈内不同协议的分层方式。对于用户通信和设备连接等高级功能，需要负责数据封装和解析等基本任务的较低级协议提供支持。
图2. BLE堆栈。
幸运的是，开发人员对堆栈组成部分有基本的了解通常就足够了，他们可以从一系列已经实现各自版本堆栈的硬件设备中进行选择。用户只需开发应用程序中负责控制设备本身的部分，并利用预构建的BLE堆栈即可。
BLE堆栈通常由三个不同部分组成：应用程序、主机和控制器。应用程序定义用户接口和用户实现的具体应用代码（振动监测）。主机是指BLE软件堆栈的上层，它控制配置文件和协议等高级功能。控制器是指BLE堆栈的底层，它处理链路层和物理层，如2.4 GHz无线电本身。此项目选择使用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和自定义配置文件（及其服务）的结构。
图5. Voyager配置文件结构。
对于Voyager，除了基本的GAP和GATT配置文件，我们还定义了一个用作命令服务器的自定义配置文件，它处理来自中心设备的命令，并返回数据或更新外围设备本身的配置。
固件实现
BLE微控制器是该系统的核心，它确保所有外围传感器和设备的数据都可以由相连的BLE中心设备检索或修改。
设备配置
我们利用MAX32666上预先构建的BLE堆栈，通过填充相关配置功能来构建外围设备的外观。例如，在图6中，我们为扫描数据发现数组提供了数据长度、广播类型和一系列字符，每次Voyager上电时，外围设备设置函数都会调用该数组。
图6. 设置Voyager扫描数据。
像这样的BLE设备将有大量的设置需要配置，包括无线电的传输功率和返回数据类型。建议从所使用硬件附带的预构建示例入手，然后在其基础上进行自定义修改。MAX32666提供了一个BLE数据服务器（外围设备）的示例代码，名为BLE DATS，Voyager项目就是以此为基础构建的。配置后，当中心设备扫描可用设备 时，外围设备的名称显示为Voyager。这也可以用于过滤搜索列表，以便中心设备仅显示预期名称的设备。如图7所示，设备名称与设备MAC地址和接收信号强度指示(RSSI)一同显示。
图7. 中心设备中显示的Voyager。
堆栈内的其他配置设置控制设备其他模式的预期名称和行为，例如制造商ID、对读/写命令的响应等。
命令服务器
Voyager4应用的中心端和外围端是同步设计的，因此可以利用含有单个BLE服务的自定义配置文件来简化外围设备接口。该配置文件将负责接收来自中心设备的命令，并以加速度计数据、温度数据和其他设备信息的形式返回响应。
对于像Voyager这样复杂的设备，采用该单一自定义服务进行BLE通信是不同寻常的做法，但却带来了几点好处。这种做法不仅支持Voyager版本之间的向后兼容性，而且增强了命令灵活性，因为通过将字符串用作Voyager外围设备的命令输入，应用可以根据数据的解析方式，灵活支持各种类型的命令和值。
一旦外围设备和中心设备之间形成连接，为了建立双向通信，中心设备就会向自定义特性发出通知命令，如图11所示。这样就在外围端建立了一个通知系统，并在中心端指定了相应的回调函数。这意味着，每当有更新的数据分配给该自定义特性时，都会通知中心设备，传输新数据，并触发中心设备的回调函数。
固件架构
图8中的硬件示意图显示了Voyager中包含的各种元器件以及相关的数据路径和电源。大多数软件开发都是在BLE微控制器上进行的，因为它作为命令中心，负责协调设备的BLE接口以及传感器和微控制器数据的内部管道。为了与系统中的不同传感器和微控制器进行交互，我们必须开发供BLE微控制器和AI部分中讨论的AI微控制器使用的设备驱动程序。实际上，这些驱动程序的开发和集成占了联网边缘传感器所需编程工作的很大一部分。
图8. Voyager4硬件框图，采用了 MAX3207E、 DS28C40A、 ADXL382, ADG1634、MAX32666, ADXL367、 MAX78000, MAX17262、 MAX20335 和 MAX38642。
编写可移植代码
开发固件时，我们将代码划分成几个抽象层，以将特定微控制器的具体细节与应用程序和驱动程序代码区分开来。这种做法很常见，通常会在应用层之外再划分出三个明确的层次来管理不同的代码功能，即硬件抽象层(HAL)、板支持包(BSP)和驱动程序层。此架构如图9所示。
图9. 通用BSP-HAL架构。
HAL为程序与不同硬件的交互提供了一种统一方法，程序无需知道每个设备的具体细节。BSP定义了依赖于硬件的软件，而驱动程序层定义了各个设备的更具体细节，如寄存器映射。例如，Voyager有两个微控制器，MAX32666用于BLE连接，MAX78000带有一个板载卷积神经网络(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发送数据所需的功耗时才是可行的（有关这方面的更多信息，请参阅本系列文章的第1部分）。
在图8中可以看到，加速度计与两个微控制器都有直接数据路径。在我们于边缘执行某些分析的用例中，AI微控制器可以直接从加速度计读取振动数据，并使用板载AI模型进行分析。
设计中心设备用户界面
BLE外围设备与Voyager外围设备同步设计，因此两者的交互方式存在非常大的灵活性。一般来说，中心设备需要扫描并连接Voyager外围设备，然后发送字符串命令并处理其返回值。初次连接后，所有BLE命令都直接发送到外围设备的自定义服务进行解析。在本例中，中心设备是Windows PC上的图形用户界面(GUI)，用Python编写，并利用BLE外围设备库(BLEak)发出标准BLE命令。BLEak建立在Python的asyncio标准库之上，允许BLE命令异步运行，确保用户界面保持可交互状态且不会冻结。
当GUI成功连接到外围设备时，系统会自动向Voyager的单个自定义特性发出通知命令，如图11所示。这样可确保对此特性的任何更新都会报告给中心设备。这一点很重要，因为Voyager会对后续命令给出应答或响应，表明这些命令是否已成功执行。
图11. Voyager中心/外围设备架构。
如何请求数据？
始终使用简单的字符串命令来请求数据。例如，中心设备可以发出setphy 2命令，指示Voyager使用其2M无线电。这会提升数据通信速度，但覆盖范围和可靠性会受到一定的影响。外围设备会解析此命令以确保其有效，然后以输入值2调用自己的内部setphy函数，从而切换所用的无线电。如果Voyager成功执行了此函数，则Return: OK命令会被发回中心设备并显示给用户。
解译加速度计数据
接收数据之前，GUI用户可以选择使用setadxlcfg命令配置所连Voyager的加速度计。一旦外围设备发出启动命令，加速度计数据就会从外围设备流向中心设备。默认情况下，中心设备和外围设备以实时数据模式运行，这对于演示目的很有用。
在外围设备端，内部先进先出(FIFO)缓冲区按照用户指定的采样速率填充新数据。一旦FIFO填满，系统就会在Voyager自定义服务上设置一个标志，通知外围设备有新数据可用。然后，数据被发送到外围设备并进行解析，转化为x、y、z三个轴的加速度数据的格式化数组。数据始终以图形方式显示，用户可以选择“保存数据”选项，以将数据保存到csv文件供以后分析。
图12. Voyager4中心设备GUI绘图数据。
AI算法设计
本项目的目标是检测电机的健康状况何时开始下降。边缘AI分析旨在通过分析音频、温度、振动等一种或多种输入数据，生成电机健康状况的指标或特征，从而取代或补充人类数据分析。振动分析是当今状态监控应用中常用的技术手段。
输入
许多边缘AI处理器往往非常耗电，这与无线状态监控解决方案的目标之一（即延长续航时间）背道而驰。MAX78000（如前所述）能够快速、低功耗地进行AI推理，其总功耗比使用无线BLE还要低。但是，在使用低功耗边缘AI处理器时，应注意神经网络的规模不能超出电路板的规格。该板搭载一个512 kB数据内存的CNN加速器。它主要用于目标检测、音频处理和时间序列数据处理。
我们解决方案可用的数据是加速度时间序列。为了尽量提高所训练算法的性能，我们尝试了几种预处理方法，以确定哪种方法对准确度影响最大。本系列文章的第3部分将对此加以详细讨论。
训练
在线资源 “Analog Devices AI” GitHub详细说明了训练神经网络并将其部署到MAX78000的过程。一般来说，首先使用PyTorch®或TensorFlow®等常规工具集在主机PC上创建模型。此模型需要训练数据，这些数据必须由目标设备保存并传输到PC。输入的一部分成为训练集，专门用于训练模型。还有一部分成为验证集，用于观察损失函数（网络性能的衡量标准）在训练期间如何变化。
根据所用的模型类型，可能需要不同类型和数量的数据。要识别特定的电机故障，您需要使用标注好的数据训练模型。这些数据不仅要包含各种故障状态下的振动信息，还要包含无故障的正常状态下的振动数据作为对比。
图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控制器的命令。
图15. 微控制器SPI通信。
收到推理请求时，AI微控制器会唤醒，并向加速度计请求数据。重要的一点是，它随后会对该时间序列数据执行与训练时相同的预处理步骤。最后，此预处理的输出会送到已部署的神经网络，由其报告分类结果。
图16. AI推理状态机。
出于省电考虑，AI微控制器被设计成在唤醒时自动执行推理。因此，BLE微控制器可以仅在需要进行分析时才启动AI微控制器。
在典型设置中，BLE微控制器可以每天短暂地从低功耗休眠模式唤醒，请求对现有加速度计数据进行AI推理，如果数据不满足用户设定的条件，比如模型以99%的置信度判断数据正常，则返回休眠模式。反之，如果数据看起来异常或无法判断是否正常时，则BLE微控制器可以连接到附近的BLE主机并共享数据。通过这种方式，在边缘进行分析就无需主机系统理解数据，从而节省了电池电量。
结语
本文介绍了无线振动监测系统Voyager4，它采用边缘AI分析来提升其作为状态监控工具的智能水平和电池续航时间。设计有效的状态监控传感器需要考虑多个方面。我们讨论了Voyager4的硬件信号链、用于将不同系统元素集成在一起的固件，以及该设备作为BLE外围设备的外观。我们还探讨了AI在Voyager中的应用，并提供了有关如何开发和部署边缘AI模型的一些见解。
请继续阅读本系列的第3部分，了解有关Voyager板上AI算法具体实现的更多信息，包括几种常见电机故障的分类。
关于作者
关联至此文章
最新视频 21
