1. 为什么用裸机MCU做状态监测而不是直接上大型工控系统接触这个项目之前我其实在设备状态监测这条路上绕了不少弯。最初接到任务时甲方要求对一组分散在厂区各处的旋转设备做在线监测预算有限、工期紧张、现场环境电磁干扰还不小。第一反应是上PLC加触摸屏加振动变送器算下来一套点位成本高得离谱更别说还要布一堆线。后来退一步想这台设备要监测的参数无非就是轴承温度、三相电流、振动幅值这几路信号我需要的不是一套完整的工控平台而是一个能干活的“采集与判断前端”——这时候STM32方案的价值就出来了。这里得先说清楚一个容易被忽略的事实条件监测Condition Monitoring的核心不是“采集数据”而是“从数据里判断设备状态”。很多人以为状态监测就是把传感器信号接进来、显示曲线就完事了实际上真正的项目难点在于信号采集的稳定性和准确性怎么保证异常特征怎么在本地快速识别以及异常发生之后数据怎么可靠地和上层系统对接。STM32这类MCU在主频、内存、外设资源上当然比不过PC或者嵌入式Linux板卡但它的实时响应能力、外设丰富度、成本优势以及在恶劣环境下的稳定性恰好卡在工业状态监测节点的核心需求上。我最终敲定的方案是STM32F407作为主控负责多通道模拟量采集、特征量计算、异常判断以及通信上报。选择F407而不是F103原因很实际——F407的主频有168MHz带FPU硬件浮点单元做FFT和均方根值计算时性能余量更充足而且它的ADC有3个可以配置成多通道扫描模式配合DMA使用这对同时采集多路模拟信号来说是刚需。如果只是监测一两路慢变温度信号F103完全够用但一旦涉及振动信号的采样频率和点数要求F103的运算能力就有点吃紧了。用MCU做状态监测的另一层考量是可靠性和可维护性。大型系统动不动就要装操作系统、升级驱动、配置网络在工业现场这种环境里节点越简单反而越不容易出问题。MCU上的程序是直接跑在硬件上的没有中间层启动时间毫秒级异常复位后恢复也快而且一颗芯片的故障影响面比一套工控系统小得多。对于“没人在现场值守、但设备不能停”的场景这种特性是实打实的优势。后面我会把整个项目的关键设计从传感器选型一路讲到通信协议结合我这几个月在实际调试和部署中踩过的坑尽量把每个环节的原理、选择和取舍都讲透。这套东西不挑具体行业凡是涉及电机、泵、风机、空压机这类旋转设备的监测需求基本都能直接套用或稍作改造。2. 监测信号链路的设计从传感器到MCU引脚的每一级都得较真2.1 传感器选型不是越贵越好而是匹配测量对象状态监测的信号源是传感器这一级选错后面所有算法和逻辑都白搭。常见监测对象和传感器对应关系大概是这样的温度PT100热电阻或热电偶经变送器输出4-20mA或0-10V标准信号。振动压电式加速度传感器输出电荷信号或经过内置IC放大后的电压信号。电流电流互感器配合采样电阻或者直接用霍尔电流传感器输出模拟电压。这个项目里主要监测轴承温度和电机运行电流。温度用的是PT100加变送器输出4-20mA经过250Ω电阻转成1-5V电压信号送入ADC。电流采用的是开环霍尔传感器选了一款输出2.5V±0.625V的型号这样0A对应2.5V正负电流都有测量范围方便用中点偏置做双极性检测。这里有个很关键的经验不要把传感器输出直接怼到MCU的ADC引脚上中间必须加一级信号调理。原因有两个——阻抗匹配和电气隔离。传感器输出的电压信号可能带有比较高的输出阻抗直接接ADC会影响采样保持电容的充电速度导致转换结果偏小第二是工业现场可能有共模干扰或意外过压不加隔离和保护MCU引脚很容易被打坏。我的做法是每个模拟通道进ADC之前都加了一级运算放大器构成的电压跟随器同时在输入端加了TVS管做浪涌保护并在ADC引脚对地并联一个100nF的滤波电容。2.2 ADC多通道扫描、循环采样和DMA的配合逻辑监测节点需要同时采集3路信号一路温度、一路电流、一路备用而且要求各路信号的采样时刻尽量接近这样才能保证后续计算特征量时各通道数据的同步性。STM32的ADC如果配置成“多通道扫描模式”它会在一次触发后按照扫描顺序依次转换所有使能的通道但如果只用单ADC转换完一轮后必须等下一轮触发效率不高。更好的做法是使用两个ADC并联的规则组模式让ADC1和ADC2分别采集不同的通道组在同一个触发信号下同步启动转换这样可以把通道间的时间差压缩到纳秒级别。DMA在这里解决的是数据搬运问题。如果不用DMA每采集一个通道的数据CPU都要进中断把ADC转换结果读出来高频采样下CPU基本被拖死。配置了DMA循环模式后ADC转换完成会自动把数据搬运到内存缓冲区CPU只需要在缓冲区满了之后一次性处理一整块数据。对于振动信号的连续采样场景这种设计几乎是唯一合理的做法。我的具体配置大致是这样的ADC1启用3个通道采样时间设为84个时钟周期开启扫描模式、连续转换模式DMA设为循环模式数据宽度半字缓冲区大小设为1024个采样点。当DMA传输过半和全部完成时触发中断CPU在中断里处理数据。这样每轮DMA中断可以拿到512个样本点足够后续做一次短时傅里叶变换或者波形特征计算。2.3 采样率和数据长度的定夺依据采样率的确定取决于监测信号的频率范围。拿振动信号来说普通滚动轴承的故障特征频率通常在几十赫兹到几千赫兹之间齿轮箱的啮合频率可能到十几千赫兹。根据奈奎斯特采样定理采样率至少是信号最高频率的2倍实际工程中一般取5到10倍。这个项目里主要是监测电机和泵的振动最高关心的频率成分到5kHz已经足够所以采样率定在20kSps每个周期采集1024个点覆盖约50ms的信号窗。这里要解释一个很多新手容易搞混的概念ADC的采样率和DMA的缓冲大小不是一回事。采样率是“每秒采多少个点”缓冲大小是“一共攒多少个点才处理一次”。两者配合决定了频率分辨率频率分辨率等于采样率除以点数。20kSps采样率、1024个点对应的频率分辨率大约是19.5Hz这对于判断“振动是不是在某个特征频率附近明显增大”够用了。如果要做更精细的频谱分析可以增加缓冲点数到2048或4096代价是内存占用增大以及CPU做FFT的耗时增加。2.4 信号调理级联的幅度标定问题模拟链路一旦串了传感器、变送器、电阻、运放、ADC这么多级每一级都有可能引入增益误差和偏移误差最终结果就是ADC读到的值和真实物理量之间有一个线性偏离。解决办法是在软件里做“两点标定”补偿。我的做法是在现场分别给传感器加一个已知的零点和满量程输入比如把PT100变送器的输入端短路模拟0℃记录此时的ADC原始值作为零偏再用一个高精度信号源输入满量程电压记录对应的ADC值然后在线性变换公式里补偿这两个系数。ADC读数通过以下公式换算为物理量物理量的工程值 (ADC原始值 - 零点原始值) × (满量程物理量 - 零点物理量) ÷ (满量程原始值 - 零点原始值) 零点物理量这个公式看着简单但如果不做零点偏移修正很多传感器在零点附近输出并不严格等于标称值累积误差会导致温度显示偏好几度电流在小电流时偏差比例更大。所以标定这一步千万别省。3. 特征提取与异常判断策略如何区分真实故障和瞬时毛刺3.1 波形特征量和频谱特征量哪个更实用状态监测的核心问题不是采到数据而是从数据里“看出问题”。常用的特征提取手段可以分成两大类第一类是时域特征量直接在时间序列上计算平均值、峰值、均方根值、峰值因子峰值除以均方根值、峭度四阶矩归一化。这些指标计算量小STM32跑起来毫无压力而且物理意义直观。比如均方根值反映总体振动能量峰值因子和峭度对早期故障的冲击特征非常敏感。第二类是频域特征量先对信号做FFT变换再分析频谱总能量、某个频段的能量占比、边频带特征等。这套方法对滚动轴承故障外圈、内圈、滚动体故障、齿轮啮合问题识别能力更强但计算量和内存开销都更大。这个项目里我采用了两级判断策略先算时域特征量做快速筛查一旦发现均方根值或峰值因子异常再对信号做FFT做频域确认。这样既能保证日常运行时的低开销又能在异常出现时拿到充足的“证据”避免误报。3.2 阈值判断的滑窗机制和迟滞区间设计阈值判断最忌讳的就是“到点就报”。现场设备的振动和电流信号天然有波动电源电压抖动、负载瞬间变化、甚至路过的一辆叉车都可能让采样值瞬间超标。如果每次检测到超阈值就立刻告警结果就是一天到晚误报运维人员最终会把告警当噪声忽略掉。我的做法是在MCU里维护一个滑动窗口窗口长度取最近N次特征量计算结果比如连续10次只有当窗口内超过阈值的次数达到一定比例比如超过7次才触发一级预警。同时引入迟滞区间这个关键设计报警阈值设为100但恢复正常要等特征值回落到90以下才算解除。迟滞区间可以防止特征量在阈值边缘抖动时反复触发和复位这在工业现场非常重要。经验来谈阈值初始值不能拍脑袋定。把传感器装上设备后先让它正常运行一段时间优先收集“健康状态”的数据统计出正常工况下特征量的均值和标准差然后把预警阈值设为均值加3倍标准差。3倍标准差在正态分布假设下对应99.7%的置信区间正常波动基本不会越线真故障导致的偏移则很容易突破这个界限。3.3 FFT实现中关于窗函数和计算资源的那点事做FFT之前有一个容易被忽视的步骤加窗。直接对截取的一段信号做FFT会因为在窗口边界处信号不连续产生频谱泄漏导致真实频率成分的能量“泄漏”到附近的频点上在看频谱时会出现一个宽宽的峰而不是尖锐的谱线。解决方法是给数据乘一个窗函数让窗口两端平滑衰减到零。常用窗函数有汉宁窗、汉明窗、布莱克曼窗。工程上最常用的是汉宁窗主瓣略宽但旁瓣衰减快对大多数工业信号都适用。STM32F407做FFT有硬件优势Cortex-M4内核带FPU和DSP指令集CMSIS-DSP库提供了arm_rfft_fast_f32函数调用非常方便。1024点实FFT在168MHz主频下耗时大约几百微秒级别完全在可接受范围内。我建议直接使用CMSIS-DSP库而不是自己写FFT自己写轮子调试周期长、数值稳定性难保证库里函数经过优化且测试充分直接用最省事。FFT算完之后后面可以做的事很多找频谱中的峰值频率和对应幅值、统计某个频段的能量积分、观察是否有边频带出现。我在代码里将FFT结果按每20Hz一个bin做了能量累加建立了一个简易的“频谱能量分布表”当某个bin的能量突然比历史均值高出5倍以上时标记为疑似故障频率并上报给上位机。3.4 误报抑制的工程细节滤波、去直流和抗混叠信号链路上的滤波处理直接影响特征量的可靠性。ADC采样进来的原始数据如果直接拿去做时域特征计算混入的噪声会大幅抬高均方根值导致误判。我采取了三级滤波策略第一级是硬件抗混叠滤波ADC引脚前面的RC低通滤波器截止频率设置在采样率的一半以下滤除高于奈奎斯特频率的成分。这个滤波器不加的话高频噪声会混叠到低频区间在频谱上形成假峰。第二级是软件去直流用高通滤波器或直接减去平均值把信号里的直流偏置去掉。如果不做这个处理频谱的0Hz处会出现一个大能量峰还会通过泄漏影响附近的低频成分严重干扰诊断。第三级是滑动平均滤波对时域特征量比如均方根值再做一次滑动平均让输出曲线平滑避免某个极端采样点直接驱动告警。这一套组合拳打下来误报率基本能控制在可接受范围。我自己实测在没有做滤波之前系统在一台正常运行的电机上每天能误报两三次加上三级滤波和滑动阈值之后连续跑了十天零误报。4. 数据落盘与通信上报异常事件怎么才能既快又稳地传出去4.1 本地存储为什么选择片内Flash加外部SPI Flash的搭配状态监测节点即使缺网上线不了也不能丢失采集到的异常数据。我的设计是两级存储MCU片内Flash保存关键配置参数和最近几次事件记录外部SPI Flash选择型号W25Q648MB容量专门负责保存异常波形数据和较长周期的统计趋势数据。片内Flash这里得提醒一个重要事项STM32的Flash擦写寿命约一万次如果毫不在意地把高频数据往片内Flash写几百个小时就能把Flash写报废。所以片内Flash只用来保存配置参数和事件索引信息这类数据写入频率极低。外部SPI Flash的擦写寿命约十万次稍好一些但依然不能高频写入。工业上标准的做法是有事件触发时才写一段波形数据平时只按小时往Flash里写一条统计记录平均值、最大值、均方根值等这样写频很低寿命完全不是问题。SPI Flash的写入还要考虑“擦写平衡”问题。W25Q系列是按扇区擦除的每个扇区4KB擦除操作耗时约几百毫秒且擦写会增加扇区磨损。我的做法是建立一个环形分区管理机制把Flash划分为若干扇区组通过一个逻辑扇区号循环写入最新数据覆盖最旧的数据这样每个物理扇区的擦除次数基本均匀不会出现某个扇区被频繁擦写而其他扇区完全没动过的情况。4.2 基于Modbus RTU的上位机对接实践对于工业设备的状态监测节点通信方案首选Modbus RTU原因是它足够老、足够稳定、兼容性极好——几乎任何PLC、组态软件、SCADA系统都原生支持Modbus RTU协议。我用STM32的USART2接了一个RS485收发器型号SP3485通过Modbus RTU从站方式与上位机通信波特率选9600bps还是38400bps要视现场线缆长度和干扰情况而定通常距离在100米以内可以选38400超过100米或者现场干扰大就降到9600。Modbus RTU的数据帧结构这里简单说地址码、功能码、数据区、CRC16校验。从设备STM32收到主站请求后解析功能码执行对应操作返回响应帧。在状态监测场景里我开放了以下几类寄存器保持寄存器读取实时特征量比如当前温度、三相电流均方根值、振动峰值因子等。输入寄存器读取历史事件记录的计数、事件时间戳。线圈寄存器控制报警输出的复位、开启或关闭远程报警使能。这里有个实操细节Modbus RTU帧的时间间隔要求——相邻两帧之间必须至少间隔3.5个字符时间接收端用这个间隔来判断一帧是否结束。STM32的串口接数据是用超时中断实现的我用的是HAL库的UART接收空闲中断加一个软件定时器超过3.5个字符时间没再收到数据就认为当前帧接收完毕。这个逻辑说起来简单调试时不注意容易被数据帧尾部多余字节坑到。如果项目现场有wifi或者4G路由也可以把Modbus RTU经过一个串口转以太网模块接上去这样上位机就可以通过网络远程读取监测数据节点本身不用改代码传输距离问题就解决了。4.3 无线上报的低功耗取舍有部分应用场景不具备布线的条件比如安装在移动设备或难以接线的工况上那我建议换用无线上报模式STM32 LoRa模块或NB-IoT模块定时把监测数据上报到云平台。LoRa的优势是功耗低、通信距离远视距可达几公里缺点是带宽低、只能传小数据包NB-IoT的优势是直接接入运营商网络、无需自建网关缺点是偏远地区信号覆盖可能不稳定且需要考虑SIM卡流量资费。低功耗设计时要考虑完整的状态切换正常工作比如每秒采样一次时电流约30mA这已经算比较小了设定为每10分钟醒来一次醒来后完成一次采样、特征量计算、数据传输然后立即进入STOP模式平均功耗可以降到几毫安以内。如果用一节大容量锂电池供电理论上能跑几个月。需要注意启用STOP模式后内部RC振荡器精度会下降如果不依赖RTC做严格时间同步问题不大否则需要外部晶振配合或使用RTC校准。对于大部分固定安装的工业设备我更推荐RS485加Modbus RTU的有线方案稳定性和实时性都更好无线方案适合做补充监测点。5. 部署后才真正明白的几件事电源、看门狗、校准和长期稳定性5.1 电源设计现场翻车一次重载启动引发的ADC参考电压漂移问题这个坑必须单独拿出来说。项目第一次部署时系统在空载和轻载情况下一切正常数据也非常漂亮。结果设备带载一启动各路监测数据立刻出现剧烈跳变尤其是电流通道的读数偏差大得离谱连温度通道都跟着小幅波动。用示波器看MCU供电引脚发现设备启动瞬间整个电源轨有一个几十毫伏的跌落而且伴随着高频振荡噪声。问题根源出在电源模块的负载调整率上。我最初用的是一个小尺寸DC-DC模块为MCU供电空载和轻载状态下输出纹波很小但一旦现场设备的变频器或电机启动母线电压被拉低DC-DC模块输入端电压也跟着波动导致其输出端出现明显的暂态跌落。ADC参考电压VREF直接取自3.3V电源电源轨被干扰ADC参考电压就会跟着抖动转换结果自然全面漂移。解决措施有三条最终一起上才彻底解决第一在MCU的3.3V供电前加一级低噪声LDO用LDO把DC-DC输出的纹波和负载调整率问题隔离掉第二ADC的VREF引脚用独立的参考电压芯片供电我选了ADR421输出2.5V超高精度低噪声基准ADC的采集精度直接上了一个台阶第三在靠近MCU电源引脚的位置加足够容量的去耦电容网络10μF100nF组合给高频开关噪声提供低阻抗泄放路径。这三条做完之后再复测满载启动场景数据稳定性和空载时几乎一致。这个经验意味着做工业信号采集类产品电源设计的重要程度不亚于软件算法模拟性能的天花板往往由供电质量决定。5.2 看门狗、异常复位和日志记录让无人值守节点能自愈状态监测节点往往部署在没人常驻的设备间或厂区角落一旦跑飞或者死机不能每次都派人过去断电重启。因此看门狗是标配。STM32内部有独立看门狗IWDG用LSI低速内部时钟驱动一旦系统超过设定时间没有刷新就自动产生复位。但看门狗的喂狗时机有讲究。简单粗暴地在主循环里喂狗只能防住“主循环死掉”如果卡在某个中断处理函数里或者某个外设死等标志位上主循环依然会跑看门狗一样被正常喂养。所以我的做法是把喂狗逻辑放在“所有关键任务都完成过一轮”之后才执行比如每轮采样、特征计算、存储、通信都必须完成才喂一次狗同时给每个关键模块都加上超时保护比如等待DMA完成超过50ms就强制复位DMA并重新初始化防止外设假死。还要在代码里加入异常复位原因的记录。STM32的RCC控制寄存器里有个复位状态寄存器可以区分是上电复位、外部复位、看门狗复位还是软件复位。我每次启动时先读取这个寄存器把复位原因记录到Flash事件区之后上位机读取分析时就能知道节点曾经因为什么原因复位过。这个数据对于定位现场长跑稳定性的问题非常有价值。5.3 远程校准与现场维护的频次规划传感器和信号链路用久了增益和偏移会产生漂移。温度传感器PT100本身长期稳定性较好但变送器和信号调理电路里的精密电阻、运放会随温度和湿度缓慢漂移。为了不频繁跑现场我在通信协议里预留了远程校准指令上位机下发校准命令后节点进入校准模式运维人员只远程给传感器施加一个标准信号软件自动计算新的零偏和增益系数并写入片内Flash保存整个过程不需要开箱。对于这套系统我实际制定的维护周期是每季度做一次远程校准每半年做一次零点漂移验证每年可以抽查一两个节点做一次现场对比验证。按照这个节奏跑下来两年多的实际部署经验显示数据稳定性完全在可控范围内。5.4 从原型到量产需要注意的几处“隐形坑”从开发板原型转为正式小批量生产这一步最容易出的问题不在代码层面而在元器件选型和PCB布局层面。挑几个真实踩过的坑说一下第一ADC采样引脚的长度问题。PCB上ADC输入走线尽量短且两侧包地如果走线过长分布电容会与运放输出阻抗构成低通滤波器悄悄改变传感器信号的频率响应影响高频振动信号的幅值准确度。第二模拟地和数字地单点汇接。MCU的AGND和DGND最终在底层一点汇接汇接点在电源入口处不要让数字电路的高频开关电流流过模拟地的路径。这个布局做对了ADC采集噪声能低一个数量级。第三SPI Flash和传感器的电源纹波。有外部大电流器件继电器、蜂鸣器、无线模块时它们的电源引脚一定要和MCU模拟部分分开走线否则动作瞬间的电流冲击会通过共用电源走线耦合到模拟电路出现偶发的采样值毛刺。第四程序里的所有浮点中间量在计算前必须检查数据范围。CMSIS-DSP库的FFT函数对输入范围有要求如果输入信号含有直流偏置或者有尖峰超限FFT结果可能溢出产生NaN后续特征计算就全乱了。我在每次做FFT前会先对数据做一次饱和检查超限数据先归一化再送入FFT。6. 扩展思路从单点监测到多节点组网和轻量级预测性维护这套STM32状态监测方案做好单个节点之后很自然就想到多节点组网的问题。一条RS485总线理论上可以挂32个节点加中继器还能扩展每个节点分不同的Modbus地址通过总线把所有节点的特征量汇总到一起。我在上位机端用Python写了一个简单的采集程序定时轮询每个节点的保持寄存器把数据存成CSV格式供后续分析。这样整个车间几十台设备的健康状态可以集中到一个看板上。再往上走一步可以用这些历史数据做基于统计的预测性维护。比如持续观察某个设备轴承振动均方根值随时间变化的趋势线假如以每天0.5%的速率递增结合设定的阈值可以估算出大概还要多久会到警戒线从而提前安排备件和检修窗口。这个不依赖复杂的机器学习模型简单的线性回归加指数平滑就足够用。对于STM32节点本身它的职责就是稳定、准确地提供原始数据趋势判断和寿命预测放在上位机或云端去处理更合理。还有一点很值得提的设计思路把节点程序做成支持“离线标定在线升级”的结构。离线标定解决的是传感器换新后无需返厂的问题在线升级为后续算法改进保留了途径。STM32的Bootloader和应用分区做成两个独立区域上位机通过Modbus或者串口下发固件包节点接收到完整固件后先校验再写入应用区最后跳转执行。这个机制让现场维护者可以在不影响其他节点的情况下单独升级某个节点的诊断算法对长期运行项目来说非常实用。我个人的习惯是项目交付后一定会在测试环境里模拟各种异常场景把上下电、短路、通信中断、弱信号全都轮一遍观察节点的行为和复位记录。做工业状态监测最理想的状态是节点长期工作若干年后除了定期校准之外几乎不需要人为干预。这套STM32方案在这两年多的实跑中基本达到了这个目标——设备的故障被提前发现了几次每次都是有惊无险地安排检修而不是等设备突然停机再来抢险。这也算是做这个项目最有成就感的时刻了。 基于STM32的工业设备状态监测系统设计与实践
1. 为什么用裸机MCU做状态监测而不是直接上大型工控系统接触这个项目之前我其实在设备状态监测这条路上绕了不少弯。最初接到任务时甲方要求对一组分散在厂区各处的旋转设备做在线监测预算有限、工期紧张、现场环境电磁干扰还不小。第一反应是上PLC加触摸屏加振动变送器算下来一套点位成本高得离谱更别说还要布一堆线。后来退一步想这台设备要监测的参数无非就是轴承温度、三相电流、振动幅值这几路信号我需要的不是一套完整的工控平台而是一个能干活的“采集与判断前端”——这时候STM32方案的价值就出来了。这里得先说清楚一个容易被忽略的事实条件监测Condition Monitoring的核心不是“采集数据”而是“从数据里判断设备状态”。很多人以为状态监测就是把传感器信号接进来、显示曲线就完事了实际上真正的项目难点在于信号采集的稳定性和准确性怎么保证异常特征怎么在本地快速识别以及异常发生之后数据怎么可靠地和上层系统对接。STM32这类MCU在主频、内存、外设资源上当然比不过PC或者嵌入式Linux板卡但它的实时响应能力、外设丰富度、成本优势以及在恶劣环境下的稳定性恰好卡在工业状态监测节点的核心需求上。我最终敲定的方案是STM32F407作为主控负责多通道模拟量采集、特征量计算、异常判断以及通信上报。选择F407而不是F103原因很实际——F407的主频有168MHz带FPU硬件浮点单元做FFT和均方根值计算时性能余量更充足而且它的ADC有3个可以配置成多通道扫描模式配合DMA使用这对同时采集多路模拟信号来说是刚需。如果只是监测一两路慢变温度信号F103完全够用但一旦涉及振动信号的采样频率和点数要求F103的运算能力就有点吃紧了。用MCU做状态监测的另一层考量是可靠性和可维护性。大型系统动不动就要装操作系统、升级驱动、配置网络在工业现场这种环境里节点越简单反而越不容易出问题。MCU上的程序是直接跑在硬件上的没有中间层启动时间毫秒级异常复位后恢复也快而且一颗芯片的故障影响面比一套工控系统小得多。对于“没人在现场值守、但设备不能停”的场景这种特性是实打实的优势。后面我会把整个项目的关键设计从传感器选型一路讲到通信协议结合我这几个月在实际调试和部署中踩过的坑尽量把每个环节的原理、选择和取舍都讲透。这套东西不挑具体行业凡是涉及电机、泵、风机、空压机这类旋转设备的监测需求基本都能直接套用或稍作改造。2. 监测信号链路的设计从传感器到MCU引脚的每一级都得较真2.1 传感器选型不是越贵越好而是匹配测量对象状态监测的信号源是传感器这一级选错后面所有算法和逻辑都白搭。常见监测对象和传感器对应关系大概是这样的温度PT100热电阻或热电偶经变送器输出4-20mA或0-10V标准信号。振动压电式加速度传感器输出电荷信号或经过内置IC放大后的电压信号。电流电流互感器配合采样电阻或者直接用霍尔电流传感器输出模拟电压。这个项目里主要监测轴承温度和电机运行电流。温度用的是PT100加变送器输出4-20mA经过250Ω电阻转成1-5V电压信号送入ADC。电流采用的是开环霍尔传感器选了一款输出2.5V±0.625V的型号这样0A对应2.5V正负电流都有测量范围方便用中点偏置做双极性检测。这里有个很关键的经验不要把传感器输出直接怼到MCU的ADC引脚上中间必须加一级信号调理。原因有两个——阻抗匹配和电气隔离。传感器输出的电压信号可能带有比较高的输出阻抗直接接ADC会影响采样保持电容的充电速度导致转换结果偏小第二是工业现场可能有共模干扰或意外过压不加隔离和保护MCU引脚很容易被打坏。我的做法是每个模拟通道进ADC之前都加了一级运算放大器构成的电压跟随器同时在输入端加了TVS管做浪涌保护并在ADC引脚对地并联一个100nF的滤波电容。2.2 ADC多通道扫描、循环采样和DMA的配合逻辑监测节点需要同时采集3路信号一路温度、一路电流、一路备用而且要求各路信号的采样时刻尽量接近这样才能保证后续计算特征量时各通道数据的同步性。STM32的ADC如果配置成“多通道扫描模式”它会在一次触发后按照扫描顺序依次转换所有使能的通道但如果只用单ADC转换完一轮后必须等下一轮触发效率不高。更好的做法是使用两个ADC并联的规则组模式让ADC1和ADC2分别采集不同的通道组在同一个触发信号下同步启动转换这样可以把通道间的时间差压缩到纳秒级别。DMA在这里解决的是数据搬运问题。如果不用DMA每采集一个通道的数据CPU都要进中断把ADC转换结果读出来高频采样下CPU基本被拖死。配置了DMA循环模式后ADC转换完成会自动把数据搬运到内存缓冲区CPU只需要在缓冲区满了之后一次性处理一整块数据。对于振动信号的连续采样场景这种设计几乎是唯一合理的做法。我的具体配置大致是这样的ADC1启用3个通道采样时间设为84个时钟周期开启扫描模式、连续转换模式DMA设为循环模式数据宽度半字缓冲区大小设为1024个采样点。当DMA传输过半和全部完成时触发中断CPU在中断里处理数据。这样每轮DMA中断可以拿到512个样本点足够后续做一次短时傅里叶变换或者波形特征计算。2.3 采样率和数据长度的定夺依据采样率的确定取决于监测信号的频率范围。拿振动信号来说普通滚动轴承的故障特征频率通常在几十赫兹到几千赫兹之间齿轮箱的啮合频率可能到十几千赫兹。根据奈奎斯特采样定理采样率至少是信号最高频率的2倍实际工程中一般取5到10倍。这个项目里主要是监测电机和泵的振动最高关心的频率成分到5kHz已经足够所以采样率定在20kSps每个周期采集1024个点覆盖约50ms的信号窗。这里要解释一个很多新手容易搞混的概念ADC的采样率和DMA的缓冲大小不是一回事。采样率是“每秒采多少个点”缓冲大小是“一共攒多少个点才处理一次”。两者配合决定了频率分辨率频率分辨率等于采样率除以点数。20kSps采样率、1024个点对应的频率分辨率大约是19.5Hz这对于判断“振动是不是在某个特征频率附近明显增大”够用了。如果要做更精细的频谱分析可以增加缓冲点数到2048或4096代价是内存占用增大以及CPU做FFT的耗时增加。2.4 信号调理级联的幅度标定问题模拟链路一旦串了传感器、变送器、电阻、运放、ADC这么多级每一级都有可能引入增益误差和偏移误差最终结果就是ADC读到的值和真实物理量之间有一个线性偏离。解决办法是在软件里做“两点标定”补偿。我的做法是在现场分别给传感器加一个已知的零点和满量程输入比如把PT100变送器的输入端短路模拟0℃记录此时的ADC原始值作为零偏再用一个高精度信号源输入满量程电压记录对应的ADC值然后在线性变换公式里补偿这两个系数。ADC读数通过以下公式换算为物理量物理量的工程值 (ADC原始值 - 零点原始值) × (满量程物理量 - 零点物理量) ÷ (满量程原始值 - 零点原始值) 零点物理量这个公式看着简单但如果不做零点偏移修正很多传感器在零点附近输出并不严格等于标称值累积误差会导致温度显示偏好几度电流在小电流时偏差比例更大。所以标定这一步千万别省。3. 特征提取与异常判断策略如何区分真实故障和瞬时毛刺3.1 波形特征量和频谱特征量哪个更实用状态监测的核心问题不是采到数据而是从数据里“看出问题”。常用的特征提取手段可以分成两大类第一类是时域特征量直接在时间序列上计算平均值、峰值、均方根值、峰值因子峰值除以均方根值、峭度四阶矩归一化。这些指标计算量小STM32跑起来毫无压力而且物理意义直观。比如均方根值反映总体振动能量峰值因子和峭度对早期故障的冲击特征非常敏感。第二类是频域特征量先对信号做FFT变换再分析频谱总能量、某个频段的能量占比、边频带特征等。这套方法对滚动轴承故障外圈、内圈、滚动体故障、齿轮啮合问题识别能力更强但计算量和内存开销都更大。这个项目里我采用了两级判断策略先算时域特征量做快速筛查一旦发现均方根值或峰值因子异常再对信号做FFT做频域确认。这样既能保证日常运行时的低开销又能在异常出现时拿到充足的“证据”避免误报。3.2 阈值判断的滑窗机制和迟滞区间设计阈值判断最忌讳的就是“到点就报”。现场设备的振动和电流信号天然有波动电源电压抖动、负载瞬间变化、甚至路过的一辆叉车都可能让采样值瞬间超标。如果每次检测到超阈值就立刻告警结果就是一天到晚误报运维人员最终会把告警当噪声忽略掉。我的做法是在MCU里维护一个滑动窗口窗口长度取最近N次特征量计算结果比如连续10次只有当窗口内超过阈值的次数达到一定比例比如超过7次才触发一级预警。同时引入迟滞区间这个关键设计报警阈值设为100但恢复正常要等特征值回落到90以下才算解除。迟滞区间可以防止特征量在阈值边缘抖动时反复触发和复位这在工业现场非常重要。经验来谈阈值初始值不能拍脑袋定。把传感器装上设备后先让它正常运行一段时间优先收集“健康状态”的数据统计出正常工况下特征量的均值和标准差然后把预警阈值设为均值加3倍标准差。3倍标准差在正态分布假设下对应99.7%的置信区间正常波动基本不会越线真故障导致的偏移则很容易突破这个界限。3.3 FFT实现中关于窗函数和计算资源的那点事做FFT之前有一个容易被忽视的步骤加窗。直接对截取的一段信号做FFT会因为在窗口边界处信号不连续产生频谱泄漏导致真实频率成分的能量“泄漏”到附近的频点上在看频谱时会出现一个宽宽的峰而不是尖锐的谱线。解决方法是给数据乘一个窗函数让窗口两端平滑衰减到零。常用窗函数有汉宁窗、汉明窗、布莱克曼窗。工程上最常用的是汉宁窗主瓣略宽但旁瓣衰减快对大多数工业信号都适用。STM32F407做FFT有硬件优势Cortex-M4内核带FPU和DSP指令集CMSIS-DSP库提供了arm_rfft_fast_f32函数调用非常方便。1024点实FFT在168MHz主频下耗时大约几百微秒级别完全在可接受范围内。我建议直接使用CMSIS-DSP库而不是自己写FFT自己写轮子调试周期长、数值稳定性难保证库里函数经过优化且测试充分直接用最省事。FFT算完之后后面可以做的事很多找频谱中的峰值频率和对应幅值、统计某个频段的能量积分、观察是否有边频带出现。我在代码里将FFT结果按每20Hz一个bin做了能量累加建立了一个简易的“频谱能量分布表”当某个bin的能量突然比历史均值高出5倍以上时标记为疑似故障频率并上报给上位机。3.4 误报抑制的工程细节滤波、去直流和抗混叠信号链路上的滤波处理直接影响特征量的可靠性。ADC采样进来的原始数据如果直接拿去做时域特征计算混入的噪声会大幅抬高均方根值导致误判。我采取了三级滤波策略第一级是硬件抗混叠滤波ADC引脚前面的RC低通滤波器截止频率设置在采样率的一半以下滤除高于奈奎斯特频率的成分。这个滤波器不加的话高频噪声会混叠到低频区间在频谱上形成假峰。第二级是软件去直流用高通滤波器或直接减去平均值把信号里的直流偏置去掉。如果不做这个处理频谱的0Hz处会出现一个大能量峰还会通过泄漏影响附近的低频成分严重干扰诊断。第三级是滑动平均滤波对时域特征量比如均方根值再做一次滑动平均让输出曲线平滑避免某个极端采样点直接驱动告警。这一套组合拳打下来误报率基本能控制在可接受范围。我自己实测在没有做滤波之前系统在一台正常运行的电机上每天能误报两三次加上三级滤波和滑动阈值之后连续跑了十天零误报。4. 数据落盘与通信上报异常事件怎么才能既快又稳地传出去4.1 本地存储为什么选择片内Flash加外部SPI Flash的搭配状态监测节点即使缺网上线不了也不能丢失采集到的异常数据。我的设计是两级存储MCU片内Flash保存关键配置参数和最近几次事件记录外部SPI Flash选择型号W25Q648MB容量专门负责保存异常波形数据和较长周期的统计趋势数据。片内Flash这里得提醒一个重要事项STM32的Flash擦写寿命约一万次如果毫不在意地把高频数据往片内Flash写几百个小时就能把Flash写报废。所以片内Flash只用来保存配置参数和事件索引信息这类数据写入频率极低。外部SPI Flash的擦写寿命约十万次稍好一些但依然不能高频写入。工业上标准的做法是有事件触发时才写一段波形数据平时只按小时往Flash里写一条统计记录平均值、最大值、均方根值等这样写频很低寿命完全不是问题。SPI Flash的写入还要考虑“擦写平衡”问题。W25Q系列是按扇区擦除的每个扇区4KB擦除操作耗时约几百毫秒且擦写会增加扇区磨损。我的做法是建立一个环形分区管理机制把Flash划分为若干扇区组通过一个逻辑扇区号循环写入最新数据覆盖最旧的数据这样每个物理扇区的擦除次数基本均匀不会出现某个扇区被频繁擦写而其他扇区完全没动过的情况。4.2 基于Modbus RTU的上位机对接实践对于工业设备的状态监测节点通信方案首选Modbus RTU原因是它足够老、足够稳定、兼容性极好——几乎任何PLC、组态软件、SCADA系统都原生支持Modbus RTU协议。我用STM32的USART2接了一个RS485收发器型号SP3485通过Modbus RTU从站方式与上位机通信波特率选9600bps还是38400bps要视现场线缆长度和干扰情况而定通常距离在100米以内可以选38400超过100米或者现场干扰大就降到9600。Modbus RTU的数据帧结构这里简单说地址码、功能码、数据区、CRC16校验。从设备STM32收到主站请求后解析功能码执行对应操作返回响应帧。在状态监测场景里我开放了以下几类寄存器保持寄存器读取实时特征量比如当前温度、三相电流均方根值、振动峰值因子等。输入寄存器读取历史事件记录的计数、事件时间戳。线圈寄存器控制报警输出的复位、开启或关闭远程报警使能。这里有个实操细节Modbus RTU帧的时间间隔要求——相邻两帧之间必须至少间隔3.5个字符时间接收端用这个间隔来判断一帧是否结束。STM32的串口接数据是用超时中断实现的我用的是HAL库的UART接收空闲中断加一个软件定时器超过3.5个字符时间没再收到数据就认为当前帧接收完毕。这个逻辑说起来简单调试时不注意容易被数据帧尾部多余字节坑到。如果项目现场有wifi或者4G路由也可以把Modbus RTU经过一个串口转以太网模块接上去这样上位机就可以通过网络远程读取监测数据节点本身不用改代码传输距离问题就解决了。4.3 无线上报的低功耗取舍有部分应用场景不具备布线的条件比如安装在移动设备或难以接线的工况上那我建议换用无线上报模式STM32 LoRa模块或NB-IoT模块定时把监测数据上报到云平台。LoRa的优势是功耗低、通信距离远视距可达几公里缺点是带宽低、只能传小数据包NB-IoT的优势是直接接入运营商网络、无需自建网关缺点是偏远地区信号覆盖可能不稳定且需要考虑SIM卡流量资费。低功耗设计时要考虑完整的状态切换正常工作比如每秒采样一次时电流约30mA这已经算比较小了设定为每10分钟醒来一次醒来后完成一次采样、特征量计算、数据传输然后立即进入STOP模式平均功耗可以降到几毫安以内。如果用一节大容量锂电池供电理论上能跑几个月。需要注意启用STOP模式后内部RC振荡器精度会下降如果不依赖RTC做严格时间同步问题不大否则需要外部晶振配合或使用RTC校准。对于大部分固定安装的工业设备我更推荐RS485加Modbus RTU的有线方案稳定性和实时性都更好无线方案适合做补充监测点。5. 部署后才真正明白的几件事电源、看门狗、校准和长期稳定性5.1 电源设计现场翻车一次重载启动引发的ADC参考电压漂移问题这个坑必须单独拿出来说。项目第一次部署时系统在空载和轻载情况下一切正常数据也非常漂亮。结果设备带载一启动各路监测数据立刻出现剧烈跳变尤其是电流通道的读数偏差大得离谱连温度通道都跟着小幅波动。用示波器看MCU供电引脚发现设备启动瞬间整个电源轨有一个几十毫伏的跌落而且伴随着高频振荡噪声。问题根源出在电源模块的负载调整率上。我最初用的是一个小尺寸DC-DC模块为MCU供电空载和轻载状态下输出纹波很小但一旦现场设备的变频器或电机启动母线电压被拉低DC-DC模块输入端电压也跟着波动导致其输出端出现明显的暂态跌落。ADC参考电压VREF直接取自3.3V电源电源轨被干扰ADC参考电压就会跟着抖动转换结果自然全面漂移。解决措施有三条最终一起上才彻底解决第一在MCU的3.3V供电前加一级低噪声LDO用LDO把DC-DC输出的纹波和负载调整率问题隔离掉第二ADC的VREF引脚用独立的参考电压芯片供电我选了ADR421输出2.5V超高精度低噪声基准ADC的采集精度直接上了一个台阶第三在靠近MCU电源引脚的位置加足够容量的去耦电容网络10μF100nF组合给高频开关噪声提供低阻抗泄放路径。这三条做完之后再复测满载启动场景数据稳定性和空载时几乎一致。这个经验意味着做工业信号采集类产品电源设计的重要程度不亚于软件算法模拟性能的天花板往往由供电质量决定。5.2 看门狗、异常复位和日志记录让无人值守节点能自愈状态监测节点往往部署在没人常驻的设备间或厂区角落一旦跑飞或者死机不能每次都派人过去断电重启。因此看门狗是标配。STM32内部有独立看门狗IWDG用LSI低速内部时钟驱动一旦系统超过设定时间没有刷新就自动产生复位。但看门狗的喂狗时机有讲究。简单粗暴地在主循环里喂狗只能防住“主循环死掉”如果卡在某个中断处理函数里或者某个外设死等标志位上主循环依然会跑看门狗一样被正常喂养。所以我的做法是把喂狗逻辑放在“所有关键任务都完成过一轮”之后才执行比如每轮采样、特征计算、存储、通信都必须完成才喂一次狗同时给每个关键模块都加上超时保护比如等待DMA完成超过50ms就强制复位DMA并重新初始化防止外设假死。还要在代码里加入异常复位原因的记录。STM32的RCC控制寄存器里有个复位状态寄存器可以区分是上电复位、外部复位、看门狗复位还是软件复位。我每次启动时先读取这个寄存器把复位原因记录到Flash事件区之后上位机读取分析时就能知道节点曾经因为什么原因复位过。这个数据对于定位现场长跑稳定性的问题非常有价值。5.3 远程校准与现场维护的频次规划传感器和信号链路用久了增益和偏移会产生漂移。温度传感器PT100本身长期稳定性较好但变送器和信号调理电路里的精密电阻、运放会随温度和湿度缓慢漂移。为了不频繁跑现场我在通信协议里预留了远程校准指令上位机下发校准命令后节点进入校准模式运维人员只远程给传感器施加一个标准信号软件自动计算新的零偏和增益系数并写入片内Flash保存整个过程不需要开箱。对于这套系统我实际制定的维护周期是每季度做一次远程校准每半年做一次零点漂移验证每年可以抽查一两个节点做一次现场对比验证。按照这个节奏跑下来两年多的实际部署经验显示数据稳定性完全在可控范围内。5.4 从原型到量产需要注意的几处“隐形坑”从开发板原型转为正式小批量生产这一步最容易出的问题不在代码层面而在元器件选型和PCB布局层面。挑几个真实踩过的坑说一下第一ADC采样引脚的长度问题。PCB上ADC输入走线尽量短且两侧包地如果走线过长分布电容会与运放输出阻抗构成低通滤波器悄悄改变传感器信号的频率响应影响高频振动信号的幅值准确度。第二模拟地和数字地单点汇接。MCU的AGND和DGND最终在底层一点汇接汇接点在电源入口处不要让数字电路的高频开关电流流过模拟地的路径。这个布局做对了ADC采集噪声能低一个数量级。第三SPI Flash和传感器的电源纹波。有外部大电流器件继电器、蜂鸣器、无线模块时它们的电源引脚一定要和MCU模拟部分分开走线否则动作瞬间的电流冲击会通过共用电源走线耦合到模拟电路出现偶发的采样值毛刺。第四程序里的所有浮点中间量在计算前必须检查数据范围。CMSIS-DSP库的FFT函数对输入范围有要求如果输入信号含有直流偏置或者有尖峰超限FFT结果可能溢出产生NaN后续特征计算就全乱了。我在每次做FFT前会先对数据做一次饱和检查超限数据先归一化再送入FFT。6. 扩展思路从单点监测到多节点组网和轻量级预测性维护这套STM32状态监测方案做好单个节点之后很自然就想到多节点组网的问题。一条RS485总线理论上可以挂32个节点加中继器还能扩展每个节点分不同的Modbus地址通过总线把所有节点的特征量汇总到一起。我在上位机端用Python写了一个简单的采集程序定时轮询每个节点的保持寄存器把数据存成CSV格式供后续分析。这样整个车间几十台设备的健康状态可以集中到一个看板上。再往上走一步可以用这些历史数据做基于统计的预测性维护。比如持续观察某个设备轴承振动均方根值随时间变化的趋势线假如以每天0.5%的速率递增结合设定的阈值可以估算出大概还要多久会到警戒线从而提前安排备件和检修窗口。这个不依赖复杂的机器学习模型简单的线性回归加指数平滑就足够用。对于STM32节点本身它的职责就是稳定、准确地提供原始数据趋势判断和寿命预测放在上位机或云端去处理更合理。还有一点很值得提的设计思路把节点程序做成支持“离线标定在线升级”的结构。离线标定解决的是传感器换新后无需返厂的问题在线升级为后续算法改进保留了途径。STM32的Bootloader和应用分区做成两个独立区域上位机通过Modbus或者串口下发固件包节点接收到完整固件后先校验再写入应用区最后跳转执行。这个机制让现场维护者可以在不影响其他节点的情况下单独升级某个节点的诊断算法对长期运行项目来说非常实用。我个人的习惯是项目交付后一定会在测试环境里模拟各种异常场景把上下电、短路、通信中断、弱信号全都轮一遍观察节点的行为和复位记录。做工业状态监测最理想的状态是节点长期工作若干年后除了定期校准之外几乎不需要人为干预。这套STM32方案在这两年多的实跑中基本达到了这个目标——设备的故障被提前发现了几次每次都是有惊无险地安排检修而不是等设备突然停机再来抢险。这也算是做这个项目最有成就感的时刻了。