从架构到仿真：DoDAF 怎么落地成能跑的 AFSIM/CMO 想定

这是全系列最关键的一篇。前面六篇讲的都是 DoDAF 本身——视角、视图、元模型。这一篇讲怎么用。贯穿案例是天眼-01红方我方天基 ISR 体系防御蓝方欧美海上编队来袭。很多人学完 DoDAF 的最大困惑不是看不懂而是然后呢画了一堆图怎么让它驱动仿真 这篇就把这条路走通——而且是真走通文中的 AFSIM 想定片段全部用mission.exeAFSIM 2.9.0实测过Simulation complete。先问自己一个问题你在仿真里做的事DoDAF 管不管你在 AFSIM 里写一个天基想定干了这些事定义一个场景红方侦察星 skyeye-01蓝方海上编队设战场环境轨道参数、任务区坐标、时间窗口给 skyeye-01 挂侦察传感器设定轨道给地面站配接收链路给打击平台配武器写交战规则发现编队目标后在指示有效期内发起打击这五件事在 DoDAF 里全有对应你做的事DoDAF 里的对应哪张视图定义场景星座 编队部署作战概念描述OV-1设战场环境轨道/坐标/时间窗想定数据通过 AV-1 界定范围AV-1挂传感器/链路/武器系统功能与接口SV-1 SV-4交战规则发现→指示→打击作战规则模型OV-6c任务目标过顶侦察/拦截作战活动分解OV-5b你一直以为自己只是在写 SDL或者搭场景。换个视角看你做的事就是把 DoDAF 架构翻译成可执行的仿真想定。只是你跳过了画图这一步直接上手写了。一条完整的架构→仿真映射链把 OV → SV → 仿真输入串起来一次完整的映射是这样的。我们按天眼-01 的反舰超视距打击链走一遍第一步从 OV-1 和 OV-2 提取天上有什么、怎么部署。OV-1 给出雷达成像星 skyeye-01轨道LEO 700 kmrevs_per_day 14.6倾角 98°、地面站 gs-0118N/128E虚构任务区、蓝方编队4 舰自东南方向 25–30 kn 逼近。轨道参数直接对应 SDL 里mover WSF_SPACE_MOVER的revs_per_day/inclination/raan/anomaly地面站对应position 18.00n 128.00e altitude 0 m msl。第二步从 OV-5b 提取作战活动怎么拆。OV-5b 给出活动链轨道预报 → 过顶侦察 → 目标识别 → 威胁评估 → 目标指示 → 超视距打击 → 战果评估。把这个活动链转换成 processor 的行为规则——AFSIM 里用on_update、on_track_drop这类真实事件钩子承载处理分支on_track_detected并不存在。每一步活动对应 processor 里一个处理分支。第三步从 SV-1 提取系统之间怎么连。SV-1 给出星间激光链路1 Gbit/s、中继星—地面站 Ka 下行300 Mbit/s过顶窗口内可用、指控网10 Mbit/s、打击数据链1 Mbit/s。这些信息流对应 comm 模型里的transfer_rate带宽、network_name子网、propagation_speed/重传策略时延。关键差异天基链路是间歇的——过顶窗口外链路不可用这是 OV-3 频率列的窗口语义。第四步从 SV-4 和 StdV-1 提取系统功能和标准。SV-4 给出skyeye-01 挂SAR 成像功能 → 映射到 AFSIM 的 sensor几何传感器近似视场角 → 地面覆盖带地面站挂数传接收功能。StdV-1 给出坐标 WGS-84、星地下行 CCSDS/Ka → 对应 comm 的transfer_rate/network_name配置。第五步从 OV-6c 提取什么条件触发什么动作。OV-6c 给出规则编队类型确认 进入责任区 目标指示在有效期内≤12 min三个条件满足后触发打击。这直接变成 processor 里的if判断。OV-6a 的指示须人工授权约束则对应一个全局授权开关。整条流水线画出来是这样OV-1 部署SDL 平台定义卫星 mover 地面站 positionOV-5b 活动链processor 行为规则OV-2 信息流comm 模型参数transfer_rate/窗口SV-1 接口SV-4 功能sensor 挂载StdV-1 标准OV-6c 规则if-then 交战逻辑指示有效期判断AFSIM 想定 .txt运行仿真输出指标 Measure回灌 CV-2 能力评估注意最后一行仿真输出的指标Measure会回灌到 CV-2 的能力评估里。探测率够不够、发现→指示时延达不达标≤8 min、拦截成功率多少——这些 Measure 直接回答CV-2 里’天基广域感知’超视距目标指示’这两项能力到底形成了没有。这就是架构→仿真→评估→架构的闭环而不是画完图就完事。备注上面这套流程我试过手动做。开始觉得很蠢——一条一条从 Word 文档里抄参数到 SDL 文本里效率极低。后来发现真正高效的做法是反过来——写脚本直接从 DoDAF 建模工具比如 EA 或 MagicDraw里导出结构化的 XML/XMI再用一个转换脚本把它映射成 SDL 想定。架构变了一次脚本重跑一遍就行。这才是 DM2 的 PES物理交换规范真正发力的地方——架构数据是机器可读的不是给人手抄的。天眼-01 这种 15 节点的体系从改架构到重出想定我们后来从两周压到半天。自动化转换一个可行的脚本骨架不用神话这件事。核心逻辑就是读 XML → 按映射表生成文本。一个 Python 骨架按验证过的语法来写注意卫星和地面站生成方式不同importxml.etree.ElementTreeasETdefarch_to_scenario(xml_path):rootET.parse(xml_path).getroot()# 片段式AFSIM 2.9 里 scenario 顶层包裹是非法命令lines[# 由 DoDAF 架构自动生成的想定片段式]forpinroot.findall(.//Performer):pidp.get(id)ptypep.findtext(resourceType)# 来自 SV-4 功能集ifptypeRECON_SAT:# 卫星轨道参数 - moverlines[fplatform{pid}{ptype},f edit mover,f raan{p.findtext(raan)}deg,f anomaly{p.findtext(anomaly)}deg,f end_mover,end_platform,]else:# 地面站/舰船positionlatfloat(p.findtext(latitude))lonfloat(p.findtext(longitude))lat_sniflat0elseslon_seiflon0elsewlines[fplatform{pid}{ptype},f position{abs(lat):.2f}{lat_s}{abs(lon):.2f}{lon_s}altitude 0 m msl,end_platform,]# 每个 Activity(performs) - platform_type 里一段 processor 骨架foractinroot.findall(.//Activity):ifact.findtext(type)engagement:linesbuild_processor(act)# 把 OV-6c 的规则映射成 on_updatelines.append(end_time 3600 sec)return\n.join(lines)这个骨架说明一件事你不需要懂 DoDAF 才能写仿真你需要的是把架构数据和仿真输入之间的映射关系代码化一次。映射关系定好了架构一变想定自动跟着变。这比改一处图、手动同步十个文件靠谱得多。配套的完整实现放在本系列tools/dodaf2afsim.py读 PES 风格 XML → 生成 SDL产物已实测跑通。天基想定对应的轨道参数支持07 之后可以按同思路扩展。AFSIM 侧的对照——你每天写的 SDL其实是一份架构执行文件拿天眼-01 的最小想定举例逐行标上这行来自哪张视图这段是完整可跑的AFSIM 2.9.0 实测 Simulation complete# 这部分来自 OV-1(部署) OV-5b(任务) SV-4(功能) platform_type SKYEYE_SAR WSF_PLATFORM side red # OV-1 的兵力归属我方 icon Satellite mover WSF_SPACE_MOVER # SV-4 的轨道能力 revs_per_day 14.6 # OV-2 的轨道参数≈98 min/圈 inclination 98 deg # 太阳同步轨道 end_mover sensor imager WSF_GEOMETRIC_SENSOR # SV-4 的侦察载荷 on internal_link data_mgr # 探测结果接入航迹管理 maximum_range 1500 km frame_time 5.0 sec end_sensor processor data_mgr WSF_TRACK_PROCESSOR # 航迹处理器 purge_interval 60 sec end_processor end_platform_type platform_type GROUND_STATION WSF_PLATFORM side red mover WSF_SURFACE_MOVER end_mover end_platform_type # 这部分来自 SV-1(接口) StdV-1(标准) comm skyeye_downlink WSF_COMM_TRANSCEIVER # StdV-1 的星地标准 transfer_rate 300 mbits/sec # OV-3 带宽列Ka 下行 end_comm # 这部分来自 OV-1(部署)平台实例 platform skyeye-01 SKYEYE_SAR edit mover # 该星的具体轨道相位 raan 30 deg anomaly 0 deg end_mover end_platform platform gs-01 GROUND_STATION position 18.00n 128.00e altitude 0 m msl # OV-1 地面站部署 end_platform # 这部分来自 AV-1时间窗口 end_time 600 sec这段代码不是示意——每个语法点都用mission.exe实测过scenario顶层包裹、latitude/longitude、platform 直属speed、comm 里的data_rate/transmit_range在 AFSIM 2.9 里全部报Unknown command。正确写法是片段式没有scenario包裹、地面/海面位置用position 18.00n 128.00e altitude 0 m msl、卫星轨道用mover WSF_SPACE_MOVERrevs_per_day/inclination/raan/anomaly、带宽用transfer_rate 300 mbits/sec、处理器事件用on_update这类真实钩子on_track_detected并不存在。每一行 SDL都能在 DoDAF 的某个视图里找到为什么这么写的理由。下次有人问你这个 transfer_rate 凭什么定 300 mbits/sec你不用翻脑子——翻 OV-3交换矩阵SAR 条带 2 GB 需在窗口内下传300 Mbit/s 约 53 s 传完和 StdV-1Ka 频段标准就行。comm 关键参数速查OV-3 是怎么变成 AFSIM 参数的参数所在层类型/单位典型值取值说明调参影响transfer_ratecomm 类型数据率 mbits/sec300 mbits/sec星地下行带宽对应 OV-3 带宽列低于需求 → 图像传不完、下传超窗口network_namecomm 组件平台实例层字符串local:master/local:slave子网名同名才能互连local:自动建网两边不一致 → 平台间静默失联transmit_modecomm 组件层intermittent / continuousintermittent发射方式影响被发现概率与干扰建模channelscomm 组件层整数1并行通道数提升多路并发容量queue_type / queue_limitcomm 组件层fifo/lifo/priorityfifo消息排队策略与上限高负载下丢包与优先级行为retransmit_attemptscomm 组件层整数0重传次数抗丢包 vs 时延上升的权衡propagation_speedcomm 组件层速度光速默认传播速度随机速度参考影响链路时延对应 OV-3 时延列注意层的区别transfer_rate写在顶层 comm 类型定义里comm NAME WSF_COMM_TRANSCEIVER ... end_commnetwork_name、transmit_mode这些属于平台实例里的 comm 组件。天眼-01 里还有个独特约束星地下行只在过顶窗口内可用——OV-3 表里频率列写的是每 98 min 窗口 ×10 min 连续落到想定里就是链路可用性调度这是地面案例没有的。完整可跑把架构→仿真的最小闭环走一遍把上面整段存成skyeye_minimal.txt在 AFSIM 2.9 环境里运行cdE:\afsim-2.9.0\study\verify\dodaf_syntax_testsetAF_SIM_DIRE:\afsim-2.9.0 E:\afsim-2.9.0\bin\mission.exe skyeye_minimal.txt预期输出结尾Initializing simulation complete. Starting simulation. Simulation complete跑通之后你可以做两个架构驱动仿真的实验改 OV-3 → 改带宽把transfer_rate 300 mbits/sec改成30 mbits/sec对应架构里星地下行带宽需求降下来了——SAR 条带 2 GB 原本 53 s 传完现在要 9 分钟超过过顶窗口下传任务排不进窗口。重跑看链路瓶颈。改 OV-6c → 改规则把 processor 里的规则换成真实交战逻辑需要武器模型库对应架构里目标指示有效期 12 min变了——重跑验证闭环指标Measure是否达标回灌 CV-2。这一步走通架构在前、仿真在后就不是口号了你改的是架构数据XML重跑脚本与仿真得到的是更新的能力评估。CMO 侧的对照CMO 走的是数据库驱动路线但映射逻辑一样。它的场景文件.scen XML引用 CWDB/DB3K 数据库里的装备 ID而不是从头定义 platform_type。但 OV 到仿真输入的那套逻辑没变——OV-1 告诉你想定里有什么平台、OV-5b 告诉你要执行什么任务、OV-6c 告诉你什么条件触发什么行动。天基想定在 CMO 里就是卫星单元 传感器 数据链的组合卫星轨道同样决定过顶窗口。CMO 的Doctrine条令本质就是 OV-6c 的形式化表达具体拆成两层WCSWeapon Control StatusFree / Tight / Hold——对应 OV-6a 的授权约束。Hold 锁住等人工授权Tight 自动但需确认Free 全自动。你在 OV-6a 里写的目标指示须人工授权签发就是 CMO 里把 WCS 设为 Hold。WRAWeapon Release Authority武器投放授权定义什么条件下允许对什么目标用哪种武器——直接对应 OV-6c 的 if-then 规则目标类型、距离、识别等级、指示是否在有效期内。CMO 的 Lua 脚本里那些ScenEdit_SetTrigger/ScenEdit_SetAction本质就是在做 OV-5b → OV-6c 的运行时绑定。DoDAF 描述应该有什么规则Lua 把这些规则变成每帧执行的判断。差异只在格式——CMO 走数据库 XML LuaAFSIM 走纯文本 SDL。架构描述层面的方法论是通的。架构在前仿真在后不是口号先把 DoDAF 架构做扎实再建模这句话听起来像正确但没用的废话。我换个说法你就知道它是什么意思了你改 OV-2 里星地下行的带宽需求——从 300 Mbit/s 改到 30 Mbit/s。这个改动通过 PES 格式导出自动更新到 SV-1 的接口参数里再自动更新到 AFSIM 的 comm 模型里。仿真重跑一遍你立刻看到下传排不进过顶窗口——链路瓶颈一目了然。如果你没做架构、直接写 SDL改一个带宽得翻十几个文件、改完还得手工确认跟它关联的其他参数有没有漏。一个参数改漏了仿真结果就跑偏了——你还不知道是参数错了还是方案就不行。架构就是帮你把参数从哪来、跟谁有关这件事管住的。规模越大、协同方越多这个价值越明显。天眼-01 这种7 颗星 2 颗中继 2 个地面站 指控中心 打击平台的体系不靠架构数据兜底过顶窗口、链路预算、指示时效根本管不住——而这正是下一篇文章的主角杀伤网。下一篇收官我们把视角从方法论拉到前沿——从杀伤链到杀伤网再到杀伤生态天基 ISR 正是传感器—射手解绑的教科书案例。