AFSIM--WSF_TRACK_PROCESSOR

WSF_TRACK_PROCESSOR 完整详解（AFSIM）

WSF_TRACK_PROCESSOR = 航迹/跟踪处理器，是平台级核心processor。
作用：多源航迹关联、卡尔曼滤波、航迹融合、航迹生命周期管理；把本机传感器探测+编队数据链收到的外部航迹，合并成一份统一的「平台态势图」，输出TRACK对象给WSF_TASK_PROCESSOR（就是前面ENGAGE开火状态机读取的那个TRACK）。

串联前面整套链路：传感器 → WSF_TRACK_PROCESSOR → data_mgr → comm TEAM_DATALINK（向外分发航迹）；同时接收comm收到的友机航迹送入TrackProcessor融合

一、核心定位

Track不是真实目标真值，是本机对目标的带误差认知（含测量噪声、延迟、虚警、漏跟踪）。
WSF_TRACK_PROCESSOR负责：

1. 接收本机传感器原始探测量测（雷达/IRST：距离、方位、俯仰）
2. 接收外部航迹（TEAM_DATALINK数据链传来友机的航迹）
3. 数据关联：判断新探测属于哪一条已有航迹；新建航迹/删除过期航迹
4. 滤波（内置卡尔曼）：平滑目标位置、速度估计，降低传感器噪声
5. 多源融合：同一目标，本机雷达+友机数据链两条航迹融合成一条更优航迹
6. 维护航迹列表（WsfTrackList），输出统一航迹给data_mgr、task_mgr
7. 周期性把本机融合后的航迹打包，交给comm向外广播给编队其他节点

一句话区分：

• WSF_TRACK_PROCESSOR：做航迹生成、关联、滤波、融合（感知层）
• WSF_TASK_PROCESSOR：读取航迹，做战术决策、状态机、开火指令（决策层）
• data_mgr：航迹数据的中转/缓存，对接comm通信链路
• WSF_P6DOF_MOVER：平台动力学运动解算（物理层）

二、脚本基础写法

platform_type BLUE_FIGHTER WSF_PLATFORM # 挂载跟踪处理器 processor tracker WSF_TRACK_PROCESSOR update_interval 0.05 # 航迹更新周期，一般和雷达扫描周期对齐 filter_type KALMAN # 滤波器类型：KALMAN / SIMPLE max_track_age 10.0 # 航迹丢失后，超过10s自动删除这条航迹 association_gate 2000.0 # 关联门限，新量测落在门内则关联到现有航迹(m) end_processor # 传感器输出量测送入tracker sensor radar WSF_RADAR_SENSOR internal_link tracker end_sensor # data_mgr承接tracker融合后的航迹，供给task_mgr和comm processor data_mgr WSF_DATA_MGR end_processor processor task_mgr WSF_TASK_PROCESSOR internal_link data_mgr # 这里就是前面SEARCH/TRACK/ENGAGE状态机，读取TRACK end_processor # 前面你写的TEAM_DATALINK通信块，internal_link data_mgr end_platform_type

关键参数说明

三、完整数据流（重点！串联你前面全部代码）

1. 本机雷达/IRST传感器探测目标 → 输出原始点迹(量测，带噪声) ↓送入 2. WSF_TRACK_PROCESSOR - 关联：新点迹匹配已有航迹 - 卡尔曼滤波更新目标状态（LLA位置、速度、加速度、误差协方差） - 接收TEAM_DATALINK通过data_mgr送来的友机外部航迹 - 多源融合，合并成一条高质量航迹 ↓输出融合航迹 3. data_mgr（航迹缓存管理器） ↓两路分发 ├─→ WSF_TASK_PROCESSOR（战术状态机，拿到TRACK，进入ENGAGE，调用Fire()开火） └─→ comm TEAM_DATALINK（打包航迹广播到编队其他平台）

编队其他飞机收到这条广播航迹 → 送入对方的data_mgr → 对方WSF_TRACK_PROCESSOR做融合。实现A机雷达发现目标，B机不打开雷达也拿到目标航迹、可以发射导弹（静默协同交战）。

四、航迹对象 WsfTrack / TRACK 内置属性

task_mgr状态机里直接使用的TRACK变量，就是TrackProcessor输出的航迹实例：

• 目标经纬度、高度、速度、航向
• 航迹置信度、误差协方差（不确定度）
• 敌我属性（IFF）、目标类型（飞机/导弹）
• 航迹ID、航迹年龄、跟踪状态（稳定跟踪/暂失锁）
• 本机到目标距离、方位角、相对高度

# task_mgr脚本里可以直接读取TRACK属性示例 if (TRACK.range < 80000 && TRACK.side == RED) set_state ENGAGE end_if

五、能力边界 & 适用场景

✅ 适合

• 机载雷达/红外传感器目标跟踪、多传感器融合
• 编队协同态势共享（TEAM_DATALINK数据链协同交战）
• 仿真感知不确定性：传感器噪声、虚航迹（假目标）、航迹断链、关联错误
• 评估协同探测、A射B导作战逻辑

❌ 不适合

• 不需要传感器感知的简单平台：直接用kinematic mover，不需要挂TrackProcessor（节省算力）
• 高精度底层信号级仿真：AFSIM的TrackProcessor是交战级/任务级，不是雷达信号处理级模型

六、常见坑点（工程高频踩坑）

1. 忘记把sensor内部链接到tracker：雷达探测到目标，但是点迹送不到TrackProcessor，永远生成不出航迹
2. association_gate设置不合理：门限过大，多目标合并成单条航迹（航迹混淆）；门太小，航迹频繁断裂、反复新建销毁
3. max_track_age太长：目标飞离雷达视野很久，态势图上还残留过期假航迹
4. 融合冲突：本机传感器航迹和数据链收到的外部航迹ID冲突，融合后航迹抖动剧烈；需要配置航迹ID去重策略
5. 算力开销：大量平台同时开启TrackProcessor+卡尔曼滤波，大兵力场景仿真速度下降；只给关键作战平台挂载
6. 航迹没有送到task_mgr：tracker输出必须经过data_mgr中转，不能直接internal_link连task_mgr

七、模块对比表