在工业物联网IIoT和无线传感器网络WSN这个战场上Python脚本给我最直观的感受是传统IT安全那套规则引擎搬到车间和管廊里几乎半残废。不是因为规则不严谨而是无线传感器网络本身太“吵”——设备掉线、电池衰减、链路抖动任何一条动静都可能触发误报真正被攻击时反而淹没在噪声里。这也是我决定写这个系列的原因用Python做数据采集、特征提取、机器学习模型训练把异常从背景噪声里挑出来。这一篇先解决“怎么把数据和模型打通”的问题适合正在接触IIoT安全、想用机器学习但是还没跑通第一版代码的朋友。1. 为什么 IIoT/WSN 的安全检测必须走到“AI 机器学习”这条路1.1 车间里没有边界无线传感器网络的攻防现状传统IT网络的安全模型默认有一个“边界”防火墙、IDS都守在公司网络出入口流量进来之前先做过滤。但在无线传感器网络里根本没有“门口”一说。传感器节点分散在厂房角落、管道沿线甚至户外通过无线信道互相通信攻击者不需要物理接触就能进入通信链路。我做过一个仓储环境的温湿度传感网络40多个节点挂在LoRa网关上数据周期性地往上送。刚开始我习惯性地按IT流量去抓结果发现网关收到的每一个正常的温湿度包在协议语义上都长得一模一样价值极低反而是中间偶尔夹着的非计划内重传包、早晚高峰的手轮广播请求才真正包含安全信号。这个场景里安全检测的焦点不是“有没有非授权IP进来”而是“这批无线数据是否符合预期的行为模型”。所以无线传感器网络的安全检测必须围绕协议行为、能量消耗、时间窗口响应来做而不是围着IP和端口转。攻击者可以轻易伪装报文但要伪装成符合整个网络时空规律的“正常行为”难度就会显著抬高——这正是机器学习擅长的地方。1.2 协议碎片化、低功耗、高实时性三个让规则引擎崩溃的硬伤很多同行问过我一个问题为什么不用现成的规则引擎比如Snort或者Suricata我回答不是不能用而是规则库对这个场景“水土不服”。第一协议碎片化严重。ZigBee、6LoWPAN、Modbus RTU、MQTT-SN、LoRaWAN不同厂商的私有协议变体数不胜数。规则引擎需要有人逐条维护规则而工业现场往往一个车间就有几个年代的设备混着跑维护成本高到飞起。第二低功耗和低占空比带来了极不稳定的数据分布。传感器节点为了省电会进入休眠可能几分钟一条数据突发情况下又疯狂上报。这种“非稳态”流量让阈值型规则引擎的误报率直线飙升。第三高实时性要求。很多工业控制系统要求在几百毫秒内完成状态判断规则引擎做深度包检测时在处理解析困难的私有协议上耗时会非常不可控。机器学习模型的优势在于它能从历史数据中自动学习“基线”用偏离度来判断异常而不是依赖人工静态阈值。模型上线后还可以通过增量更新去适应环境随季节、生产计划发生的变化这在规则引擎里几乎需要重写整条规则库。1.3 机器学习在这个场景里到底能解决什么对于无线传感器网络机器学习的核心价值不是找出“已知攻击样本”而是把“未知的偏离行为”标记出来交付给安全人员复核。举个具体的例子。某个水处理车间的超声波液位计每隔20秒上报一次液位正常数据的波动范围基本稳定。恶意节点伪造数据注入时如果它伪造的是“平缓上升”规则引擎完全看不出来因为单包值在合法区间内但机器学习模型可以同时对“液位值变化率”“上报间隔熵”“相邻节点数据相关性”三个维度建模一旦发现某个节点连续60秒的上报间隔熵明显偏离历史分布就算数值看起来再合法也会被打上疑点标记。我自己比较常用两类任务组合一类是有标签数据的监督分类把已知攻击类型分出来另一类是无标签场景的异常检测跑孤立森林或自编码器把离群点揪出来。现实工业现场有干净标签的数据集是奢侈品所以我会把两者结合——先无监督圈定嫌疑区间再人工复核后回流标记长出第二阶段的监督模型。2. 环境准备Python 工具链与数据集选型2.1 Python 版本、虚拟环境与必备库开始跑这类项目时我强烈建议先从Python 3.10或3.11起步目前机器学习生态里较新的库版本对它们的兼容性最好。直接用官网安装包装完之后一定先确认pip可用再用venv建一个独立环境不要让项目依赖污染全局Python。python -m venv iiot-security source iiot-security/bin/activate # Windows 下用 iiot-security\Scripts\activate pip install --upgrade pip我们这个系列里会用到的关键库我按用途分成几组列出来数据处理与计算numpy、pandas流量解析与抓包pyshark依赖Wireshark的tshark命令行工具机器学习建模scikit-learn、lightgbm深度学习备用tensorflow或keras可视化matplotlib这里有个容易踩的坑直接pip install pyshark不会同时安装tshark。如果机器上还没有Wireshark需要先装Wireshark并确保tshark在系统PATH里。我会在第三节再展开讲怎么用它读流量。2.2 数据集选型公开 WSN 与 IIoT 数据集环境搭好之后下一个问题是数据从哪来自建一个真实的无线传感器网络测试床当然好但对大多数人来说门槛太高。我更建议先拿公开数据集把整个pipeline跑通后面再迁移到自己的抓包数据上。推荐几个我试过的WSN-DS专为无线传感器网络设计包含黑洞攻击、选择性转发、洪泛攻击等场景节点状态、能量数据齐全适合做分类模型。TON_IoT包含了IoT、IIoT和工控系统的遥测数据及攻击数据结构比较复杂但字段覆盖全面适合做特征工程练习。UNSW-NB15偏传统网络流量攻击类型多虽然不完全是WSN协议但在处理网络流特征时很有参考价值。我最早跑通基线模型用的是WSN-DS因为它的数据量适中、标签规整不至于一开始就把时间耗在清洗上。需要提示的是公开数据集里的攻击类型跟你们现场的真实攻击不一定完全对应把它当“练兵场”而不是“万能答案”更合适。2.3 数据目录与标签规范模型还没开始跑先把数据目录规范好这个习惯能让你少走很多弯路。我通常的目录结构是这样iiot-security/ data/ raw/ # 原始抓包或下载的数据 processed/ # 清洗、特征工程之后的数据 labels/ # 标签文件独立于特征存储 scripts/ capture.py # 流量采集 features.py # 特征提取 train.py # 模型训练 evaluate.py # 评估 models/ # 训练好的模型存档标签单独存放是我特别想强调的一点。很多初学者喜欢直接给原始数据加一列“1/0”标签但工业场景的标签通常是滞后的——可能需要一个月后通过工单系统或事件日志才能确认某段时间是否有异常。把标签独立管理按时间戳对齐后期维护才可能。3. 数据采集与特征工程3.1 从哪拿流量tshark PyShark 的采集姿势要训练模型首先得有数据。生产环境下在网关上用tcpdump抓包是最常见的姿势但无线传感器网络的流量通常不是走传统TCP/IP更多是802.15.4、ZigBee或自定义无线协议。如果用传统抓包工具还需要一个网卡切换到监听模式才能把空中的帧捞下来。我的习惯是分两步走平时在网关、协调器镜像口跑tcpdump写pcap文件再做离线分析需要实时日志时才用tshark做在线抓取。Python侧配合pyshark读取pcap非常方便import pyshark cap pyshark.FileCapture(data/raw/capture_01.pcap, display_filternot tcp.port 22, only_summariesFalse) records [] for packet in cap: try: records.append({ time: packet.sniff_time, protocol: packet.highest_layer, length: int(packet.length), src: packet.ip.src if hasattr(packet, ip) else None, dst: packet.ip.dst if hasattr(packet, ip) else None }) except AttributeError: continue cap.close()注意FileCapture对脏包很敏感解析失败时不能直接终止整个脚本所以我在循环里加了try/except。真实抓包里总有一些不按常理出牌的帧不跳过它们pipeline就断了。3.2 特征提取滑动窗口与统计指标拿到原始包之后不能直接丢给机器学习模型。模型需要的不是一个个孤立的包而是一段时间窗口内的“行为画像”。我按5秒、30秒、60秒三种窗口分别提取特征再让模型做选择。窗口太短抓不住周期性行为窗口太长又会淹没瞬时异常。下面这段代码是我经常用的特征提取骨架按源节点聚合窗口统计量import pandas as pd import numpy as np def window_features(df, window30s): df df.set_index(time) grouped df.groupby([src, pd.Grouper(freqwindow)]) features grouped.agg( pkt_count(length, count), pkt_len_mean(length, mean), pkt_len_std(length, std), pkt_len_max(length, max), interval_mean(timestamp, lambda x: x.diff().mean()), interval_std(timestamp, lambda x: x.diff().std()) ).reset_index() return features这里interval_mean和interval_std计算的是同一源节点相邻包之间的时间间隔统计。无线传感器网络被攻击时包间隔往往会出现明显规律性比如洪泛攻击时间隔压缩到极小选择性转发攻击时局部间隔拉长。这两个特征比单纯看包长度有用得多。不过也有个坑无线节点掉线、重连会产生很大空档interval_std会被拉得很离谱。我后来加了一步后处理把超过正常休眠阈值5倍的间隔直接截断防止一次的偶发沉默把整段特征带偏。3.3 特征选择与数据归一化特征造多了之后未必全是好事。我有一次把特征整到了60多个维度模型训练时长翻了三倍AUC却没涨多少。后来用scikit-learn的SelectKBest按与标签的相关性筛到15个特征效果反而更稳。from sklearn.feature_selection import SelectKBest, f_classif X features.drop([src, time, label], axis1) y features[label] selector SelectKBest(f_classif, k15).fit(X, y) selected_cols X.columns[selector.get_support()]归一化在树模型里不是必需品但如果你后面要接自编码器、神经网络或基于距离的模型特征尺度问题就会显现。StandardScaler解决均值方差尺度RobustScaler对含离群点的无线数据更抗造。无线传感器网络的RSSI、电池电压这类特征经常有大离群点我个人更倾向RobustScaler。数据分割也必须按时间顺序不能用普通的train_test_split随机打乱否则就是拿未来数据预测过去指标虚高。我常用的做法是划分前70%作训练后30%作测试。4. 机器学习模型实战4.1 模型选型从树模型到深度自编码器模型选型上我的经验是可以分三档推进。第一档是基线模型比如逻辑回归或决策树几分钟就能跑完用来验证数据链路是否通、特征是否具备区分度。第二档是集成树模型随机森林、LightGBM在中小规模表格数据上表现稳定训练快特征重要性可以直接输出是大多数IIoT项目的首选。第三档才是深度模型自编码器适合无监督异常检测LSTM适合有时间依赖的序列数据但训练成本和对样本量的要求都比较高一般放在标签充足或传感器数量很大之后再做。我给一个公平对比表模型适用场景训练速度可解释性无线传感器场景注意点逻辑回归二分类基线极快高对非线性行为特征识别有限随机森林中小特征集快中高特征不多时非常好用LightGBM大规模特征快中需要处理类别型和数值型混合孤立森林无监督异常检测快低适合无标签冷启动自编码器重构误差检测慢训练低适合复杂传感器关联LSTM时间序列较慢低对采样频率敏感需谨慎在一这个阶段我建议直接把LightGBM跑通性价比最高。4.2 第一个可跑的脚本LightGBM 异常检测代码用LightGBM做二分类代码不算复杂但里面的参数需要根据工业场景手动调。import lightgbm as lgb from sklearn.metrics import classification_report, roc_auc_score X_train, X_test X.loc[:split_idx], X.loc[split_idx:] y_train, y_test y.loc[:split_idx], y.loc[split_idx:] model lgb.LGBMClassifier( n_estimators300, learning_rate0.05, max_depth5, num_leaves31, min_child_samples10, subsample0.8, colsample_bytree0.8, class_weightbalanced, random_state42 ) model.fit(X_train, y_train, eval_set[(X_test, y_test)], eval_metricauc) y_prob model.predict_proba(X_test)[:, 1] y_pred (y_prob 0.5).astype(int)class_weightbalanced是我必须加的参数。工业异常样本通常只占1%-5%LightGBM不给这个参数模型很容易把所有样本都预测成“正常”因为那样整体准确率也有95%以上。加了之后模型才会对少数类敏感一些。关于阈值我不建议始终用0.5。异常检测场景下宁可多几个误报让安全人员复核也不能漏掉真实攻击所以我通常会根据验证集的F1或召回率回溯调整阈值到0.2~0.3区间。模型输出的概率本身不重要重要的是它能否拉开“正常”和“可疑”的距离。4.3 不均衡数据与评估指标做这一类项目准确率最不能信。你想想一个99%正常的传感器日志模型直接全判正常就有99%准确率但一点用处都没有。我每次评估都会输出完整矩阵from sklearn.metrics import confusion_matrix, precision_recall_fscore_support print(classification_report(y_test, y_pred)) print(AUC:, roc_auc_score(y_test, y_prob))实践下来我最看重的是召回率Recall和AUC-PR。在工控安全里漏报意味着潜在物理伤害召回率优先于精确率。但也不能只追求召回率否则安全团队会被误报折磨到直接关掉模型。比较健康的目标是保留95%以上的召回率同时把精确率压到60%以上剩下的交给人工复核。另一个常用手段是SMOTE过采样。当异常样本少得可怜时我会先把特征缩放到0-1区间再用SMOTE合成少数类样本。但要注意先分割训练测试集再在训练集上做SMOTE千万不要把测试集也一起合成了那是数据泄漏评估结果会假得离谱。5. 常见问题与排查技巧实录5.1 我踩过的坑先说无量纲问题。第一次跑WSN-DS数据时我直接把原始能量值、路由跳数、包长度扔进模型结果树模型也没能拯救我——部分特征值域差异太大分裂点全偏向了数值大的特征模型输出看着能用但实际泛化很差。后来统一做标准化情况立刻好转。再说时间对齐。有一次我抓了3个小时的流量标签是从工单系统里导出的两个系统的时间差了一个小时模型训练时怎么调都不过阈。排查到最后发现标签用的UTC时间戳抓包文件里是本地时间。这种低级错误最耗时间所以我现在一律统一使用UTC时间戳抓包文件、标签文件、特征表全用同一个时区。还有内存问题。连续抓包几个小时pcap文件能到几个GB用pyshark全量读取后Python进程会吃掉大量内存。我后来改成逐块读取每处理完删掉DataFrame引用必要时直接落成parquet文件。SQLite也是好帮手小型传感器网络的数据用库表存储比CSV靠谱。5.2 问题速查表现象可能原因排查思路pyshark读取报错没有安装tshark或tshark不在PATH命令行执行tshark -v确认Wireshark安装后重启终端抓包文件很大但解析极慢包数量太大单进程解析加显示过滤条件拆文件并行处理或用only_summariesFalse只取摘要模型AUC高但实际效果差数据分割没有按时间检查是否用了随机切分改成按时间先后训练/测试划分特征矩阵全为NaN无线节点休眠期过长无有效包填充策略缺省值补0或用前向填充然后加“是否有包”标志列标签和特征行数不匹配多源数据时间粒度不一统一时间戳精度按源节点和时间窗口做merge_asof模型预测几乎全是0类不均衡未处理给模型加class_weightbalanced或重采样或调整阈值还有一个自己摸索出来的小技巧在建模之前先对整个特征矩阵做一次相关性分析把相关系数超过0.95的特征删掉。无线传感器网络特征高度冗余删冗余后模型训练稳定性和收敛速度提升都非常明显。最后再聊两句实操感受说实话跑通一个80%准确率的模型不难难的是模型能不能在车间里真活下来。真实无线传感器网络的数据质量比任何公开数据集都要糟十倍节点掉线、电池电压跳水、电磁干扰导致的乱序包无时无刻不在挑战模型的鲁棒性。我的经验是把70%的时间花在数据处理和特征工程上只有30%留给模型调参这个比例永远划算。这次先把这个基础pipeline搭建完整下一篇我计划聊边缘侧部署也就是怎么把训练好的模型拆成轻量级推理脚本塞到树莓派或ARM网关里当边关哨兵再往后可以聊聊无标签场景下用自编码器做半监督异常发现的案例。只要你有那么一条真实或仿真的WSN链路哪怕只有十几个节点这套流程就能从数据采集一路跑到异常告警那就是整个系列最有价值的起点。 
长河君 · 2026/10/14 14:09:42 · 阅读 1.2k Python驱动IIoT无线传感器网络异常检测：从数据采集到模型部署
在工业物联网IIoT和无线传感器网络WSN这个战场上Python脚本给我最直观的感受是传统IT安全那套规则引擎搬到车间和管廊里几乎半残废。不是因为规则不严谨而是无线传感器网络本身太“吵”——设备掉线、电池衰减、链路抖动任何一条动静都可能触发误报真正被攻击时反而淹没在噪声里。这也是我决定写这个系列的原因用Python做数据采集、特征提取、机器学习模型训练把异常从背景噪声里挑出来。这一篇先解决“怎么把数据和模型打通”的问题适合正在接触IIoT安全、想用机器学习但是还没跑通第一版代码的朋友。1. 为什么 IIoT/WSN 的安全检测必须走到“AI 机器学习”这条路1.1 车间里没有边界无线传感器网络的攻防现状传统IT网络的安全模型默认有一个“边界”防火墙、IDS都守在公司网络出入口流量进来之前先做过滤。但在无线传感器网络里根本没有“门口”一说。传感器节点分散在厂房角落、管道沿线甚至户外通过无线信道互相通信攻击者不需要物理接触就能进入通信链路。我做过一个仓储环境的温湿度传感网络40多个节点挂在LoRa网关上数据周期性地往上送。刚开始我习惯性地按IT流量去抓结果发现网关收到的每一个正常的温湿度包在协议语义上都长得一模一样价值极低反而是中间偶尔夹着的非计划内重传包、早晚高峰的手轮广播请求才真正包含安全信号。这个场景里安全检测的焦点不是“有没有非授权IP进来”而是“这批无线数据是否符合预期的行为模型”。所以无线传感器网络的安全检测必须围绕协议行为、能量消耗、时间窗口响应来做而不是围着IP和端口转。攻击者可以轻易伪装报文但要伪装成符合整个网络时空规律的“正常行为”难度就会显著抬高——这正是机器学习擅长的地方。1.2 协议碎片化、低功耗、高实时性三个让规则引擎崩溃的硬伤很多同行问过我一个问题为什么不用现成的规则引擎比如Snort或者Suricata我回答不是不能用而是规则库对这个场景“水土不服”。第一协议碎片化严重。ZigBee、6LoWPAN、Modbus RTU、MQTT-SN、LoRaWAN不同厂商的私有协议变体数不胜数。规则引擎需要有人逐条维护规则而工业现场往往一个车间就有几个年代的设备混着跑维护成本高到飞起。第二低功耗和低占空比带来了极不稳定的数据分布。传感器节点为了省电会进入休眠可能几分钟一条数据突发情况下又疯狂上报。这种“非稳态”流量让阈值型规则引擎的误报率直线飙升。第三高实时性要求。很多工业控制系统要求在几百毫秒内完成状态判断规则引擎做深度包检测时在处理解析困难的私有协议上耗时会非常不可控。机器学习模型的优势在于它能从历史数据中自动学习“基线”用偏离度来判断异常而不是依赖人工静态阈值。模型上线后还可以通过增量更新去适应环境随季节、生产计划发生的变化这在规则引擎里几乎需要重写整条规则库。1.3 机器学习在这个场景里到底能解决什么对于无线传感器网络机器学习的核心价值不是找出“已知攻击样本”而是把“未知的偏离行为”标记出来交付给安全人员复核。举个具体的例子。某个水处理车间的超声波液位计每隔20秒上报一次液位正常数据的波动范围基本稳定。恶意节点伪造数据注入时如果它伪造的是“平缓上升”规则引擎完全看不出来因为单包值在合法区间内但机器学习模型可以同时对“液位值变化率”“上报间隔熵”“相邻节点数据相关性”三个维度建模一旦发现某个节点连续60秒的上报间隔熵明显偏离历史分布就算数值看起来再合法也会被打上疑点标记。我自己比较常用两类任务组合一类是有标签数据的监督分类把已知攻击类型分出来另一类是无标签场景的异常检测跑孤立森林或自编码器把离群点揪出来。现实工业现场有干净标签的数据集是奢侈品所以我会把两者结合——先无监督圈定嫌疑区间再人工复核后回流标记长出第二阶段的监督模型。2. 环境准备Python 工具链与数据集选型2.1 Python 版本、虚拟环境与必备库开始跑这类项目时我强烈建议先从Python 3.10或3.11起步目前机器学习生态里较新的库版本对它们的兼容性最好。直接用官网安装包装完之后一定先确认pip可用再用venv建一个独立环境不要让项目依赖污染全局Python。python -m venv iiot-security source iiot-security/bin/activate # Windows 下用 iiot-security\Scripts\activate pip install --upgrade pip我们这个系列里会用到的关键库我按用途分成几组列出来数据处理与计算numpy、pandas流量解析与抓包pyshark依赖Wireshark的tshark命令行工具机器学习建模scikit-learn、lightgbm深度学习备用tensorflow或keras可视化matplotlib这里有个容易踩的坑直接pip install pyshark不会同时安装tshark。如果机器上还没有Wireshark需要先装Wireshark并确保tshark在系统PATH里。我会在第三节再展开讲怎么用它读流量。2.2 数据集选型公开 WSN 与 IIoT 数据集环境搭好之后下一个问题是数据从哪来自建一个真实的无线传感器网络测试床当然好但对大多数人来说门槛太高。我更建议先拿公开数据集把整个pipeline跑通后面再迁移到自己的抓包数据上。推荐几个我试过的WSN-DS专为无线传感器网络设计包含黑洞攻击、选择性转发、洪泛攻击等场景节点状态、能量数据齐全适合做分类模型。TON_IoT包含了IoT、IIoT和工控系统的遥测数据及攻击数据结构比较复杂但字段覆盖全面适合做特征工程练习。UNSW-NB15偏传统网络流量攻击类型多虽然不完全是WSN协议但在处理网络流特征时很有参考价值。我最早跑通基线模型用的是WSN-DS因为它的数据量适中、标签规整不至于一开始就把时间耗在清洗上。需要提示的是公开数据集里的攻击类型跟你们现场的真实攻击不一定完全对应把它当“练兵场”而不是“万能答案”更合适。2.3 数据目录与标签规范模型还没开始跑先把数据目录规范好这个习惯能让你少走很多弯路。我通常的目录结构是这样iiot-security/ data/ raw/ # 原始抓包或下载的数据 processed/ # 清洗、特征工程之后的数据 labels/ # 标签文件独立于特征存储 scripts/ capture.py # 流量采集 features.py # 特征提取 train.py # 模型训练 evaluate.py # 评估 models/ # 训练好的模型存档标签单独存放是我特别想强调的一点。很多初学者喜欢直接给原始数据加一列“1/0”标签但工业场景的标签通常是滞后的——可能需要一个月后通过工单系统或事件日志才能确认某段时间是否有异常。把标签独立管理按时间戳对齐后期维护才可能。3. 数据采集与特征工程3.1 从哪拿流量tshark PyShark 的采集姿势要训练模型首先得有数据。生产环境下在网关上用tcpdump抓包是最常见的姿势但无线传感器网络的流量通常不是走传统TCP/IP更多是802.15.4、ZigBee或自定义无线协议。如果用传统抓包工具还需要一个网卡切换到监听模式才能把空中的帧捞下来。我的习惯是分两步走平时在网关、协调器镜像口跑tcpdump写pcap文件再做离线分析需要实时日志时才用tshark做在线抓取。Python侧配合pyshark读取pcap非常方便import pyshark cap pyshark.FileCapture(data/raw/capture_01.pcap, display_filternot tcp.port 22, only_summariesFalse) records [] for packet in cap: try: records.append({ time: packet.sniff_time, protocol: packet.highest_layer, length: int(packet.length), src: packet.ip.src if hasattr(packet, ip) else None, dst: packet.ip.dst if hasattr(packet, ip) else None }) except AttributeError: continue cap.close()注意FileCapture对脏包很敏感解析失败时不能直接终止整个脚本所以我在循环里加了try/except。真实抓包里总有一些不按常理出牌的帧不跳过它们pipeline就断了。3.2 特征提取滑动窗口与统计指标拿到原始包之后不能直接丢给机器学习模型。模型需要的不是一个个孤立的包而是一段时间窗口内的“行为画像”。我按5秒、30秒、60秒三种窗口分别提取特征再让模型做选择。窗口太短抓不住周期性行为窗口太长又会淹没瞬时异常。下面这段代码是我经常用的特征提取骨架按源节点聚合窗口统计量import pandas as pd import numpy as np def window_features(df, window30s): df df.set_index(time) grouped df.groupby([src, pd.Grouper(freqwindow)]) features grouped.agg( pkt_count(length, count), pkt_len_mean(length, mean), pkt_len_std(length, std), pkt_len_max(length, max), interval_mean(timestamp, lambda x: x.diff().mean()), interval_std(timestamp, lambda x: x.diff().std()) ).reset_index() return features这里interval_mean和interval_std计算的是同一源节点相邻包之间的时间间隔统计。无线传感器网络被攻击时包间隔往往会出现明显规律性比如洪泛攻击时间隔压缩到极小选择性转发攻击时局部间隔拉长。这两个特征比单纯看包长度有用得多。不过也有个坑无线节点掉线、重连会产生很大空档interval_std会被拉得很离谱。我后来加了一步后处理把超过正常休眠阈值5倍的间隔直接截断防止一次的偶发沉默把整段特征带偏。3.3 特征选择与数据归一化特征造多了之后未必全是好事。我有一次把特征整到了60多个维度模型训练时长翻了三倍AUC却没涨多少。后来用scikit-learn的SelectKBest按与标签的相关性筛到15个特征效果反而更稳。from sklearn.feature_selection import SelectKBest, f_classif X features.drop([src, time, label], axis1) y features[label] selector SelectKBest(f_classif, k15).fit(X, y) selected_cols X.columns[selector.get_support()]归一化在树模型里不是必需品但如果你后面要接自编码器、神经网络或基于距离的模型特征尺度问题就会显现。StandardScaler解决均值方差尺度RobustScaler对含离群点的无线数据更抗造。无线传感器网络的RSSI、电池电压这类特征经常有大离群点我个人更倾向RobustScaler。数据分割也必须按时间顺序不能用普通的train_test_split随机打乱否则就是拿未来数据预测过去指标虚高。我常用的做法是划分前70%作训练后30%作测试。4. 机器学习模型实战4.1 模型选型从树模型到深度自编码器模型选型上我的经验是可以分三档推进。第一档是基线模型比如逻辑回归或决策树几分钟就能跑完用来验证数据链路是否通、特征是否具备区分度。第二档是集成树模型随机森林、LightGBM在中小规模表格数据上表现稳定训练快特征重要性可以直接输出是大多数IIoT项目的首选。第三档才是深度模型自编码器适合无监督异常检测LSTM适合有时间依赖的序列数据但训练成本和对样本量的要求都比较高一般放在标签充足或传感器数量很大之后再做。我给一个公平对比表模型适用场景训练速度可解释性无线传感器场景注意点逻辑回归二分类基线极快高对非线性行为特征识别有限随机森林中小特征集快中高特征不多时非常好用LightGBM大规模特征快中需要处理类别型和数值型混合孤立森林无监督异常检测快低适合无标签冷启动自编码器重构误差检测慢训练低适合复杂传感器关联LSTM时间序列较慢低对采样频率敏感需谨慎在一这个阶段我建议直接把LightGBM跑通性价比最高。4.2 第一个可跑的脚本LightGBM 异常检测代码用LightGBM做二分类代码不算复杂但里面的参数需要根据工业场景手动调。import lightgbm as lgb from sklearn.metrics import classification_report, roc_auc_score X_train, X_test X.loc[:split_idx], X.loc[split_idx:] y_train, y_test y.loc[:split_idx], y.loc[split_idx:] model lgb.LGBMClassifier( n_estimators300, learning_rate0.05, max_depth5, num_leaves31, min_child_samples10, subsample0.8, colsample_bytree0.8, class_weightbalanced, random_state42 ) model.fit(X_train, y_train, eval_set[(X_test, y_test)], eval_metricauc) y_prob model.predict_proba(X_test)[:, 1] y_pred (y_prob 0.5).astype(int)class_weightbalanced是我必须加的参数。工业异常样本通常只占1%-5%LightGBM不给这个参数模型很容易把所有样本都预测成“正常”因为那样整体准确率也有95%以上。加了之后模型才会对少数类敏感一些。关于阈值我不建议始终用0.5。异常检测场景下宁可多几个误报让安全人员复核也不能漏掉真实攻击所以我通常会根据验证集的F1或召回率回溯调整阈值到0.2~0.3区间。模型输出的概率本身不重要重要的是它能否拉开“正常”和“可疑”的距离。4.3 不均衡数据与评估指标做这一类项目准确率最不能信。你想想一个99%正常的传感器日志模型直接全判正常就有99%准确率但一点用处都没有。我每次评估都会输出完整矩阵from sklearn.metrics import confusion_matrix, precision_recall_fscore_support print(classification_report(y_test, y_pred)) print(AUC:, roc_auc_score(y_test, y_prob))实践下来我最看重的是召回率Recall和AUC-PR。在工控安全里漏报意味着潜在物理伤害召回率优先于精确率。但也不能只追求召回率否则安全团队会被误报折磨到直接关掉模型。比较健康的目标是保留95%以上的召回率同时把精确率压到60%以上剩下的交给人工复核。另一个常用手段是SMOTE过采样。当异常样本少得可怜时我会先把特征缩放到0-1区间再用SMOTE合成少数类样本。但要注意先分割训练测试集再在训练集上做SMOTE千万不要把测试集也一起合成了那是数据泄漏评估结果会假得离谱。5. 常见问题与排查技巧实录5.1 我踩过的坑先说无量纲问题。第一次跑WSN-DS数据时我直接把原始能量值、路由跳数、包长度扔进模型结果树模型也没能拯救我——部分特征值域差异太大分裂点全偏向了数值大的特征模型输出看着能用但实际泛化很差。后来统一做标准化情况立刻好转。再说时间对齐。有一次我抓了3个小时的流量标签是从工单系统里导出的两个系统的时间差了一个小时模型训练时怎么调都不过阈。排查到最后发现标签用的UTC时间戳抓包文件里是本地时间。这种低级错误最耗时间所以我现在一律统一使用UTC时间戳抓包文件、标签文件、特征表全用同一个时区。还有内存问题。连续抓包几个小时pcap文件能到几个GB用pyshark全量读取后Python进程会吃掉大量内存。我后来改成逐块读取每处理完删掉DataFrame引用必要时直接落成parquet文件。SQLite也是好帮手小型传感器网络的数据用库表存储比CSV靠谱。5.2 问题速查表现象可能原因排查思路pyshark读取报错没有安装tshark或tshark不在PATH命令行执行tshark -v确认Wireshark安装后重启终端抓包文件很大但解析极慢包数量太大单进程解析加显示过滤条件拆文件并行处理或用only_summariesFalse只取摘要模型AUC高但实际效果差数据分割没有按时间检查是否用了随机切分改成按时间先后训练/测试划分特征矩阵全为NaN无线节点休眠期过长无有效包填充策略缺省值补0或用前向填充然后加“是否有包”标志列标签和特征行数不匹配多源数据时间粒度不一统一时间戳精度按源节点和时间窗口做merge_asof模型预测几乎全是0类不均衡未处理给模型加class_weightbalanced或重采样或调整阈值还有一个自己摸索出来的小技巧在建模之前先对整个特征矩阵做一次相关性分析把相关系数超过0.95的特征删掉。无线传感器网络特征高度冗余删冗余后模型训练稳定性和收敛速度提升都非常明显。最后再聊两句实操感受说实话跑通一个80%准确率的模型不难难的是模型能不能在车间里真活下来。真实无线传感器网络的数据质量比任何公开数据集都要糟十倍节点掉线、电池电压跳水、电磁干扰导致的乱序包无时无刻不在挑战模型的鲁棒性。我的经验是把70%的时间花在数据处理和特征工程上只有30%留给模型调参这个比例永远划算。这次先把这个基础pipeline搭建完整下一篇我计划聊边缘侧部署也就是怎么把训练好的模型拆成轻量级推理脚本塞到树莓派或ARM网关里当边关哨兵再往后可以聊聊无标签场景下用自编码器做半监督异常发现的案例。只要你有那么一条真实或仿真的WSN链路哪怕只有十几个节点这套流程就能从数据采集一路跑到异常告警那就是整个系列最有价值的起点。