简介：这是一篇正式录用于《计算机应用研究》期刊的学术论文PDF，由南京邮电大学李健、付雄、王俊昌撰写，面向物联网移动终端设备产生的海量、分布不均的轨迹数据，提出基于双层聚类的用户轨迹异常检测方法。方法先按空间距离与时间间隔提取停留点并进行层次聚类，划分出停留区域，再对区域间的运动轨迹段做二次层次聚类，从而同时识别异常停留区域与异常轨迹段，实验表明相较传统算法兼具检测全面性与速度优势。资源为单份689KB的PDF全文，包含摘要、关键词、引言、算法设计、实验对比及参考文献，适合物联网、数据挖掘、用户行为分析方向的研究生与研发人员用于课题调研、算法复现和论文写作参考。目前已有292人浏览学习，具有较好的参考价值。

1. 用户轨迹异常检测在物联网移动终端上：为什么“有轨迹”不等于“有数据”

物流配送手持终端、车联网T-Box、老人定位手环，这些物联网移动终端设备天天在回传定位点，轨迹异常检测听起来就是把点和历史路径比一比，偏离了就报警。真实做过的团队都知道，第一版基本都会翻车：终端上报的GPS点要么飘到隔壁街道，要么十分钟才有一条，后台进程半夜被系统杀掉，轨迹直接断成虚线。数据长这样，再好的异常检测算法也白搭。这篇笔记按“采集清洗 → 特征与相似度 → 参数整定 → 踩坑排查 → 验证进阶”往下走，把能直接复现的规则、代码和参数写清楚，适合正在做物联网方向毕业设计，或者用终端定位数据做车辆管理、人员调度、风控反欺诈的工程师。

2. 终端定位采集与清洗：把脏数据变成可用轨迹的 3 个关卡

2.1 定位源怎么选：GPS、基站和 Wi-Fi 的取舍

物联网移动终端设备常用的定位源就三种：GPS/GNSS、基站定位、Wi-Fi 定位。对应物联网三层架构，感知层是定位模组，网络层负责回传，应用层才轮到异常检测服务。选哪种定位源，直接决定后面轨迹数据的长相，不能拍脑袋。

GPS 精度最高，开阔环境下能到 3-10 米，但功耗也最高，室内基本废掉，冷启动要几十秒。基站定位覆盖最好，只要有蜂窝信号就有位置，精度却只有 200-800 米，在城市里够判断“在哪个街区”，不够判断“是不是偏离了配送路线”。Wi-Fi 定位在室内商场、办公楼里精度能到 15-50 米，但依赖 WiFi 指纹库，终端扫描 Wi-Fi 也要额外耗电。

我一般按业务场景定主定位源和辅助定位源：室外移动场景以 GPS 为主、基站为辅兜底；室内工牌和手环以 Wi-Fi 为主、基站为辅；对精度要求不高的设备，干脆只用基站定位，省电省流量。关键是要把定位源编号写进上报数据里，否则后面清洗时根本不知道该按什么精度去容忍误差。

2.2 漂移、跳变和静置抖动：三条清洗规则

定位数据有三类脏数据必须处理：漂移、跳变、静置抖动。漂移是 GPS 在某个位置附近随机乱跳，轨迹上出现小锯齿；跳变是定位从真实位置一下跑到几百米外再跳回来，像瞬移；静置抖动是终端明明放在桌上充电，坐标却在几十米范围内来回晃。

清洗规则我在做车辆轨迹时常用这三条。第一条是物理速度约束：连续两个定位点的时间和距离算出速度，超过 180km/h 直接标记异常，车辆终端超过这个值基本是定位错误。第二条是最大位移约束：单次跳变量超过 500 米且时间间隔很短，判定为跳变点。第三条是速度连续性约束：前后两点算出来 80km/h，再前后两点算出来只有 5km/h，这组数据里至少有一个点是脏的，用中间点与前一个点的合理速度去修正或丢弃后一个点。

这三条规则不是放到 SQL 里跑一次就完事，需要按设备类型做参数区分。货运车辆的 180km/h 阈值对人员手环不适用，人员步行终端超过 30km/h 就已经异常。所以清洗参数要在规则配置中心里独立维护，按设备类型下发，而不是写死在代码里。

2.3 轨迹切分与时间对齐：一个可落地的 SQL 处理流程

终端上报的定位点通常是稀疏且不等的，9:00:03 一条、9:05:47 一条、9:12:20 一条，直接算相邻点距离和速度会受时间间隔影响。我习惯先把原始点清洗到一张明细表，再做时间对齐和轨迹切分。

以下 SQL 示例把原始定位表 track_point 按设备分组，用窗口函数取上一点的时间戳和经纬度，计算时间间隔和距离，标出物理速度异常的点：

with gps_raw as ( select device_id, ts_utc, lat, lng, lag(lat) over (partition by device_id order by ts_utc) as prev_lat, lag(lng) over (partition by device_id order by ts_utc) as prev_lng, lag(ts_utc) over (partition by device_id order by ts_utc) as prev_ts from track_point where ts_utc >= '2024-06-01' and ts_utc < '2024-06-08' ), gps_calc as ( select *, extract(epoch from (ts_utc - prev_ts)) as dt_sec, haversine(lat, lng, prev_lat, prev_lng) as dist_m from gps_raw ) select device_id, ts_utc, lat, lng, dist_m, dt_sec, case when dt_sec between 1 and 300 and dist_m / nullif(dt_sec, 0) * 3.6 > 180 then 1 else 0 end as speed_abnormal from gps_calc where dt_sec is not null and dt_sec > 0;

这段逻辑的关键在两点。一是lag()窗口函数按 device_id 分区、按 ts_utc 排序，取到每个点前面的相邻点；二是haversine(lat, lng, prev_lat, prev_lng)计算两个经纬度点之间的球面距离，如果数据库没有这个函数，要自己用 UDF 实现，或者先用等距投影近似再修正。dist_m / dt_sec * 3.6是把米/秒换算成 km/h，再和 180 这个阈值比较。

清洗完明细点之后，要按固定时间窗做对齐聚合。GPS 上报间隔不固定，对齐到 5 分钟窗口后，每个窗口内算平均经纬度、样本数、最大速度，形成轨迹的节拍点：

select device_id, to_timestamp(floor(extract(epoch from ts_utc) / 300) * 300) as bucket_ts, avg(lat) as lat_center, avg(lng) as lng_center, count(*) as sample_cnt, max(speed_kmh) as max_speed_kmh from cleaned_track_point group by device_id, bucket_ts order by device_id, bucket_ts;

窗口长度 300 秒是参数，不是写死的。实时性要求高的场景可以缩到 60 秒，但窗口越短，空窗越多，后面做相似度计算时对齐失败的几率越高。我一般默认 300 秒窗口，既能平滑 GPS 抖动，又不会把一段真实移动抹掉。这一步做完，轨迹才是可计算的轨迹。

3. 检测主干：轨迹相似度与行为特征两条路线怎么选

3.1 轨迹相似度度量：LCSS、DTW、Hausdorff 谁更适合终端轨迹

拿到两条经过清洗的轨迹后，最直接的想法是计算它们像不像。欧氏距离要求两条轨迹点一一对应，物联网终端的采样时间根本对不齐，直接放弃。DTW 动态时间规整能处理时间轴伸缩，很适合步态、手势这类密集型序列，但终端轨迹半小时才几个点，DTW 的弯曲路径很容易被少数漂移点带偏。

Hausdorff 距离度量两条轨迹点集间的最大不匹配程度，实现简单，但单个离群点就能把距离拉大，对脏数据非常敏感。把清洗规则再加强一版后可以用，但误报率偏高。

相比之下 LCSS 最长公共子序列的思路更适合终端轨迹：两个轨迹点距离小于容忍度就算匹配，允许跳过不匹配的点，天然容忍采样间隔不齐和局部噪声。代价是要设匹配半径，通常取 GPS 误差的 2-3 倍，也就是 30-50 米。

选型我给一张结论表：

不过相似度路线有个前提：用户有固定路线。配送员的日常路线、巡检工的巡更路线、通勤车辆的固定班线，这类场景相似度很好用。对没有固定路线的用户，比如内部物流叉车在库区里随意开，相似度判定一做一个错，这种场景就该走行为特征路线。

3.2 行为特征路线：速度、停留点和作业时段更抗噪

行为特征路线不关心轨迹长什么样，只关心从轨迹里提出来的数字是否偏离个人基线。这招对自由轨迹更皮实，也更能抵抗 GPS 跳变带来的干扰。

我从终端轨迹里常用四组特征。第一组是速度特征，包括平均速度、最大速度、速度超过 60km/h 的样本占比，用来区分“正常驾驶”和“超速甚至飞车”。第二组是停留特征，用 DBSCAN 对轨迹点聚类，停留半径 100 米、最短停留 5 分钟算一个停留点，统计停留点数量和最长停留时长，用来发现“在禁停区域逗留”或“长时间不动”的异常。第三组是区域特征，算轨迹点的中心点和 90% 置信半径，用户平时活动半径 2 公里内，某天突然出现在 20 公里外，区域特征直接爆掉。第四组是时段特征，按凌晨、白天、夜间分组统计移动距离，夜间移动距离突然拉高，在老人防走失和仓储安防场景里是强异常信号。

3.3 轻量检测流程：从定位点到异常评分的 Python 示例

下面用一个最小可运行流程演示行为特征路线：读入一台设备一周的轨迹点，按天切分，算出每天的速度和活动半径特征，再和周基线做 z-score 对比，超过阈值就标记异常。

import pandas as pd import numpy as np from sklearn.cluster import DBSCAN # 读取清洗后的轨迹点 # 字段: device_id, ts_utc, lat, lng, speed_kmh df = pd.read_csv("cleaned_track_points.csv", parse_dates=["ts_utc"]) # 提取日期，按天聚合 df["date"] = df["ts_utc"].dt.date # 拉帮结派算活动半径 def daily_radius(day_df): coords = day_df[["lat", "lng"]].values if len(coords) < 3: return None center = coords.mean(axis=0) dist = np.sqrt(((coords - center) ** 2).sum(axis=1)) return np.percentile(dist, 90) # 90%置信半径 # 按天统计速度与半径特征 day_feat = df.groupby(["device_id", "date"]).agg( avg_speed=("speed_kmh", "mean"), max_speed=("speed_kmh", "max"), ) day_feat["radius_km"] = df.groupby(["device_id", "date"]).apply(daily_radius) # 用前6天做基线，第7天做检测 baseline = day_feat[day_feat["date"] < day_feat["date"].max()] target = day_feat[day_feat["date"] == day_feat["date"].max()] # 计算 z-score feat_cols = ["avg_speed", "max_speed", "radius_km"] for col in feat_cols: mu = baseline[col].mean() sigma = baseline[col].std() target[col + "_z"] = (target[col] - mu) / sigma # 任一特征 z 分数超过 3 或低于 -3，标记异常 abnormal = target[feat_cols + ["avg_speed_z", "max_speed_z", "radius_km_z"]] abnormal["is_abnormal"] = ( (abnormal["avg_speed_z"].abs() > 3) | (abnormal["max_speed_z"].abs() > 3) | (abnormal["radius_km_z"].abs() > 3) ) print(abnormal)

这段代码里有三个参数需要重点说。np.percentile(dist, 90)用的是 90 分位数而不是最大值，防止单个定位点把活动半径撑爆。z-score 的阈值选 3，对应约 99.7% 置信区间，如果历史基线只有 6 天，样本太少，z-score 会偏激，这时候可以把阈值放宽到 2.5，宁可多一点疑似异常让人工复核。DBSCAN 聚类在daily_radius里没直接用，如果要做停留点统计，需要单独对每天的点做 DBSCAN 聚类，eps取 0.001（约 100 米），min_samples取 3，才能把停留点聚类出来。

4. 参数整定：阈值、窗口和模型选型的 4 个必调点

4.1 阈值用分位数定：P95 比固定值靠谱

速度阈值、活动半径阈值、时长阈值，最忌讳拍脑袋写死。不同设备、不同业务类型，用户的正常行为差异极大。给巡检人员定的平均速度阈值，放到快递三轮车上就是天天误报。

我一般用历史数据的分位数定阈值。取过去 30 天每天的特征值，算 P95 作为黄色预警阈值、P99 作为红色告警阈值。这样能天然过滤掉 5% 的正常波动，减少无意义告警。

import pandas as pd feat = pd.read_csv("30d_daily_features.csv") # 列: avg_speed, max_speed, radius_km p95 = feat[["avg_speed", "max_speed", "radius_km"]].quantile(0.95) p99 = feat[["avg_speed", "max_speed", "radius_km"]].quantile(0.99) print("黄色预警(P95):", p95.to_dict()) print("红色告警(P99):", p99.to_dict())

分位数阈值有两个坑。第一个是季节性变化：夏季和冬季的出行规律不同，用全年数据算一个阈值，春秋天误报率会明显升高，建议按月份或按工作日/周末分别计算。第二个是用户异质性：一线销售一天跑 100 公里，仓库管理员一天挪 2 公里，全局 P95 对后者形同虚设。要么按用户分组算个性化阈值，要么按业务类型分组建模。我见过的项目里，按用户分组算阈值的效果显著好于全局阈值，代价是要保证每个用户至少有 14 天历史数据。

4.2 时间窗口：5 分钟、15 分钟还是 2 小时

时间窗口决定特征计算的时间粒度，也决定告警延迟。5 分钟窗口适合实时性要求高的场景，比如车辆偏离规划路线、外卖骑手长时间停留不动；窗口内只保留 1 个定位点也能计算速度特征，但窗口内超过 5 分钟没有数据，宁可标记为空窗，不要用前后两个窗口的点去补速度，补出来的速度往往是跳变的假速度。

15 分钟窗口是行为特征的折中选择，每个窗口能攒下 3-6 个定位点，平均速度、最大速度、停留概率都算得稳。适合做巡检覆盖率和老人活动能力评估。

2 小时窗口适合夜间异常场景。老人手环夜间长时间静止后突然出现短时间快速移动，在 5 分钟窗口里看就是一个正常点，放到 2 小时窗口里看，就是“夜间离家”的强异常信号。我建议按业务同时维护多套窗口：5 分钟窗口做实时告警，15 分钟窗口做行为模型输入，2 小时窗口做夜间巡检。多窗口并存很常见，不是非要选一个。

4.3 检测频率与云端代价：端侧算还是云端算

终端设备上千台甚至几万台，每 5 分钟上报一次定位，一年下来是上亿条记录，全部丢到云端实时计算，成本撑不住。常见做法是端侧做第一级规则过滤，云侧做第二级模型判断。

终端 Android 设备上用 SDK 周期性采集定位，先本地算速度和位移，只有位移超过 100 米或速度超过 60km/h 才触发上报。静止场景可以做到 30 分钟不产生一条上行数据。数据通过 MQTT 上报到物联网平台，再由规则引擎流转到轨迹异常检测服务。阿里云物联网平台这套链路是现成的，终端 SDK 采集、设备影子存状态、规则引擎转发消息，不需要自己从零搭消息中间件。

4.4 模型选型：规则引擎、孤立森林还是 LSTM

模型选型取决于三个约束：标注数据有多少、实时性要求多高、硬件资源多紧张。

我在实际项目里的建议是：先上规则引擎，用速度、停留、区域、时段四组特征把误报率压到可接受范围，再考虑模型。孤立森林适合多维特征，把平均速度、夜间移动量、活动半径、停留时长等几十个特征丢进去，异常比例设 0.1-0.5%，能抓出规则想不到的组合式异常。LSTM 看起来很高级，但终端轨迹采样间隔不均匀，喂进去之前要做大量插值预处理，训练成本高，而且可解释性差，给业务方解释“为什么这个用户是异常”时很难交代。

先规则、再孤立森林、LSTM 放最后尝试，是这条线最务实的路径。

5. 避坑与排查：终端轨迹异常检测的 5 条踩坑记录

5.1 漂移点引发误报率飙升

现象：设备放在仓库里一整天不动，轨迹异常检测却不断报警，显示用户在一个小时内往返移动了十几公里。

原因：GPS 在室内或遮挡环境下发生漂移，终端上报的坐标在真实位置周围数百米随机跳动。清洗规则只过滤了“点与点之间的物理速度”，没过滤“单点相对中心点的位置跳变”，静置状态下两点距离可能达到 300 米，但时间间隔只有 1-2 秒，算出来的瞬时速度确实达到 300km/h，规则没拦住是因为清洗阈值设到了 180km/h，而漂移跳变恰好低于这个阈值。

解决：在清洗阶段增加静态检测，当一个设备在 10 分钟内坐标中心点基本不变，但各点到中心点的平均距离超过 50 米时，判定为静置漂移，直接丢弃这批点。参数上把静置判断的时间窗口设为 600 秒，距离阈值 80 米，误判率和漏判率相对平衡。

5.2 后台定位被系统杀死，轨迹断成虚线

现象：Android 终端息屏一段时间后彻底停止上报，轨迹在下午 2 点到 4 点之间完全消失，异常检测系统判定为“离线异常”，实际是系统把后台定位服务杀了。

原因：国内主流手机操作系统对后台定位限制严格，应用在后台长时间运行会被冻结。终端 App 只申请了前台定位权限，没有正确处理开机自启和服务保活。

解决：定位采集要分策略。最关键的业务时段用前台服务保活，申请“后台定位”权限并引导用户加入电池优化白名单；非关键时段降级到省电模式，用基站定位每 30 分钟上报一次。同时云端要区分“设备离线”和“轨迹异常”，离线超过 1 小时只发通知，不直接触发轨迹异常告警，否则误报会把运营团队淹没。

5.3 轨迹稀疏时检出率暴跌

现象：某些设备上报间隔长到 10 分钟一条，用 LCSS 算轨迹相似度时，两条相同路线因为采样点错开，匹配半径里一个点都匹配不上，相似度直接归零，正常用户被标成严重异常。

原因：轨迹相似度算法依赖匹配半径，而匹配半径受采样密度影响。采样越稀疏，相邻轨迹点的空间间隔越大，点对点匹配概率越低。终端自身的省电策略让上报间隔动态变化，轨迹密集时段和稀疏时段混杂，单一半径无法适配。

解决：相似度算法改用“路段匹配”：先把轨迹点连成线段，再计算两条轨迹线段的 Hausdorff 距离，匹配的基本单元从点变成段，对采样密度不敏感。或者干脆走行为特征路线，速度分位数和活动半径在 10 分钟间隔下仍然稳定。轨迹稀疏是物联网终端的常态，算法选型阶段就要用真实数据的采样间隔做压力测试，别拿 1 秒一条的手机 GPS 日志做算法验证。

5.4 离线评估“看起来很好”，上线后完全不是一回事

现象：离线测试准确率 98%，上线后误报率翻了几倍，运营每天收到几百条无效告警。

原因：离线评估用的是清洗后的干净数据，而线上检测处理的是实时脏数据流。清洗逻辑在评估时是“先清洗再评价”，上线时变成“先识别再清洗”，脏数据没被识别出来就直接进了特征计算。另外离线数据集里的异常样本是人工标定的，标注密度远低于实际业务中的真实比例。

解决：搭一个回放框架。把终端上报的原始数据按时间顺序逐条喂给检测服务，服务端边清洗边检测，输出告警后再和人工标注比对。回放时用滚动时间窗口，不要用已经标注好的一次性数据集。评估指标也要看误报率和漏报率的具体分布，不要只看整体准确率，98% 准确率在 1% 异常占比的数据集上没有任何意义。

5.5 冷启动：没有历史轨迹怎么建立基线

现象：新设备接入系统当天就被判为异常，因为行为特征 z-score 需要历史基线，新用户没有基线，系统直接输出 NaN。

原因：z-score 和分位数阈值都依赖历史数据，新设备、新用户没有足够的历史轨迹，特征计算不出正常范围。

解决：冷启动阶段用群体基线做降级。同一业务类型、同一区域的设备，取全体用户过去 7 天的特征分位数作为临时阈值，检测到异常先打上“低置信度”标签，不做强告警，只记录。等新用户积累 7-14 天数据后，再逐步切换到个性化阈值。这个降级策略能覆盖新设备上线高峰期的误报潮，代价是冷启动期间的异常发现率会低一些，可接受。

6. 验证与进阶：从离线回测到边端协同，还能再做深的事

轨迹异常检测的验证不能只看一个准确率数字。我的习惯是分用户、分时段做分层回测：把用户按活跃度分成高、中、低三组，分别统计精确率和召回率；把样本按白天、夜间拆分，确认夜间误报率是否被高估。回测时按时间切训练集和测试集，禁止随机划分，否则未来数据泄漏到训练集里，上线后立刻打回原形。

进阶方向上，边端协同是目前性价比最高的演进路径。端侧跑轻量规则，拦截掉 80% 的无效数据，只把异常片段和原始轨迹摘要传到云端，云侧用孤立森林或集成模型做二次判断。这样做一是省流量、省云端算力，二是隐私友好，端侧只上报异常片段而不是全量轨迹。物联网设备的轨迹数据涉及个人行踪，上传前做脱敏和分段加密，是合规底线，不是可选项。

如果这是你的物联网工程毕设选题，我会建议把重心放在回测评估和误报率控制上，而不是一味堆模型。曾经一个项目里我盯着模型准确率调了两周，后来发现只是把清洗规则里的速度阈值从 180 改到 120，误报率就降了一半。从那以后，我先看数据质量报告，再看模型指标，这个习惯帮我少走了很多弯路。希望帮到你。

本文还有配套的精品资源，点击获取