上篇 OV 讲的是仗怎么打。这篇 SV 讲的是仗靠什么打——那些侦察星、中继星、地面站、指控中心、数据链、打击平台在架构里怎么描述、怎么跟 OV 里的作战活动挂上钩。搞仿真的读到这一篇应该很舒服——SV 里的概念跟 AFSIM 的 platform/sensor/weapon/comm 几乎是一一对应的。天眼-01 里 SV 层的主角很明确7 颗侦察星3 颗雷达成像 2 颗光学 2 颗电子侦察、2 颗中继星、2 个地面接收站、1 个太空指控中心加上一支由舰载机中队和 1 艘导弹驱逐舰构成的远程打击平台。SV-1系统接口描述——“谁跟谁连、用什么连”SV-1 是工程师最常打交道的一张图。它列出所有的系统节点——侦察星、中继星、地面站、指控中心、打击平台——以及节点之间的接口interface。真正的 SV-1 不只是画一条线每条线背后都有参数接口类型星间激光 / Ka 射频 / 加密 IP 专网、协议CCSDS / 自由空间光 / J-series、带宽、延迟、安全等级。画得细的 SV-1一条线可以直接对应联试时的接口控制文档ICDInterface Control Document。举个天眼-01 的 ICD 实例这是 SV-1 某条接口线应该标清楚的——星地下行链路接口项取值说明接口双方中继星 ↔ 地面接收站生产者 ↔ 消费者传输层Ka 频段25.5–27 GHz射频高速数传不是测控小管子协议CCSDS 空间数据链路帧同步 CRC空间标准非地面以太网带宽300 Mbit/s2 GB SAR 条带约 53 s 传完时延≤ 200 ms加上地面预处理 ≤ 3 min 出图完整性高CCSDS 编码重传不能拖出过顶窗口安全加密 认证全程密文防干扰星监听星间那条同样要标死侦察星 ↔ 中继星自由空间光1 Gbit/s星间光速加转发 ≤ 50 ms。指令上行是另一根细管子地面站 ↔ 卫星S 频段2 Mbit/s只跑 CCSDS TC 指令上注和参数注入。天眼-01 的 SV-1 完整接口清单节选长这样接口双方传输层带宽/速率时延安全星间激光链路侦察星 ↔ 中继星自由空间光1 Gbit/s≤ 50 ms加密星地下行链路中继星 ↔ 地面站Ka25.5–27 GHz300 Mbit/s≤ 200 ms加密指令上行链路地面站 ↔ 卫星S 频段2 Mbit/s≤ 2 min含调度加密 认证指控网太空指控中心 ↔ 海上指控加密 IP 专网10 Mbit/s≤ 50 ms物理隔离 密文打击数据链海上指控 ↔ 打击平台数据链Link-16 类1 Mbit/s≤ 1 s密文表格是接口契约SV-1 的图长这样——节点是系统边是接口标传输层 带宽跨三个物理段打击段地面段天基段自由空间光 1 Gbit/s自由空间光自由空间光Ka 300 Mbit/s加密 IP 专网指控网 10 Mbit/s打击数据链 1 Mbit/sKa 频段压制雷达成像星 ×3光学侦察星 ×2电子侦察星 ×2中继星 ×2地面接收站 ×2太空指控中心海上指控舰载机 / 驱逐舰蓝方干扰星虚线那条是蓝方干扰星的对抗接口——它不是体系内的 SV-1 接口但画出来才能看清哪条链路断了整条发现—指示链断在哪一段。这正是 SV-1 从逻辑接口走向韧性分析的入口见 SV-2。我在项目里见过一个典型案例OV 图上写着过顶窗口内完成图像回传但 SV-1 里那条星地下行链路标注的带宽只有 30 Mbit/s。2 GB 的 SAR 条带按 30 Mbit/s 要传约 9 分钟而 700 km 轨道一个过顶窗口的设计值才 10 min——还得扣掉成像时间和链路建链余量图像根本传不完窗口内下传 ≤ 3 min的指标直接报废。最后推倒重来按 Ka 频段 300 Mbit/s 上报2 GB 条带 53 s 传完才把闭环跑通。这个教训一句话总结OV 说应该能SV 说实际能不能。把两者对上才能发现架构里的水分。备注跟你写 AFSIM 的 comm 块一模一样。你写transfer_rate 300 mbits/sec和network_name local:master的时候本质上就是在画 SV-1 接口线。带宽定低了2 GB 条带排不进 10 min 过顶窗口网络名对不上星地两端静默失联。只是仿真里失联你还能改参数重跑真实系统里失联就是丢任务。我在联试现场见过一次OV-3 表里目标航迹走的是地面段 J3.2 子网SV-1 里却把network_name写成了指控专网的名字结果星地回传的航迹数据全部静默丢弃——排查了两天才发现是文档上一行字写错了。SV-1 的接口参数字字都是钱和命。反过来transfer_rate 300 mbits/sec星地下行和星间 1 Gbit/s 在 AFSIM comm 类型定义层都是合法写法已实测过顶窗口内链路可用由想定调度实现——SV-1 的每一条仿真里都能落地。SV-2系统资源流——物理层的真流量SV-1 画的是逻辑接口谁连谁、用什么协议SV-2 画的是物理资源流——信号、能量、物资在物理节点之间怎么流动。比如中继星到地面站之间SV-2 会标Ka 下行链路 1 路、S 上行链路 1 路、测控遥测链路 1 路星间还会标激光链路 2 路主/备“。对仿真工程师SV-2 用得少但对做体系韧性分析的人SV-2 告诉你蓝方干扰星把哪条 Ka 下行压掉整条发现—指示链路就断在哪一段”——这恰恰是杀伤网韧性评估的输入。SV-4系统功能描述——“这个系统能干什么”SV-4 把每个系统提供的功能列出来。它不是系统说明书目录而是按功能分层组织的结构。比如天眼-01 的天基体系SV-4 可能这样写雷达成像侦察星F1: 对海 SAR 成像F2: 条带拼接F3: 星上自检光学侦察星F4: 可见光/红外成像F5: 目标判读星上粗判电子侦察星F6: 信号截获F7: 信号参数测量F8: 交叉定位数据中继星F9: 星间路由F10: 星地中继地面接收站F11: 数传接收F12: 图像预处理F13: 轨道预报太空指控中心F14: 星座调度F15: 情报融合F16: 目标指示生成F17: 授权签发打击平台舰载机中队 / 导弹驱逐舰F18: 超视距反舰导弹发射F19: 舰载机出动每个功能都对应 OV-5b 里的某个活动——这就是SV-5b系统功能→作战活动映射表做的事。F1对海 SAR 成像支撑 OV-5b 里的过顶侦察活动F15情报融合支撑威胁评估活动F16目标指示生成支撑目标指示与打击决策活动。这套映射做扎实了你就知道如果目标识别这个作战活动的指标没达标应该去查 F4/F6 这些系统功能而不是满世界乱找。映射表就是追责/优化的索引。SV-10系统状态模型a/b/c跟 OV-6 类似SV 这边也有三张状态/事件模型SV-10a系统规则模型约束类似 OV-6aSV-10b系统状态转移类似 OV-6b但站在系统而非作战角度SV-10c系统事件追踪具体系统行为的时序展开SV-10b 是工程师最该画的。以侦察卫星为例待命 → 过顶 → 成像 → 数传 → 休眠。每一个状态转移都由事件触发——“进入任务区可见弧段”“目标区预报命中”“成像完成”“下传完成/离开可见弧段”。进入任务区可见弧段目标区预报命中成像完成下传完成/离开可见弧段下一圈过顶目标区无目标(跳过)链路异常/被干扰恢复/降级待命过顶成像数传休眠故障搞仿真的看到这里又该笑了这不就是 AFSIM 离散事件引擎里的状态机吗卫星的 待命→过顶→成像→数传→休眠 状态变迁在 AFSIM 里就是 satellite 平台 mover 的轨道相位revs_per_day/inclination/raan/anomaly驱动过顶事件、sensor 探测结果触发成像、processor 的on_update钩子做调度分支的组合行为链路异常/被干扰这一支可以用on_track_drop这类事件钩子承载。在 CMO 里WCSWeapon Control Status的 Free/Tight/Hold 切换也是这个逻辑。SV-10b 的价值在于它让你在设计阶段就把这些状态转移定义清楚而不是等到写代码的时候才想哦成像完了以后要不要自动切数传如果当前没有地面站在可见弧段内是不是该先星上缓存、下个窗口再传——这种想当然在仿真里会出大 bug卫星进入任务区可见弧段却不切成像就永远卡在待命状态下一个 98 min 轨道周期整个重来2 h 的星座重访指标直接崩掉。SV 和仿真的映射SV 视图描述内容AFSIM 对应CMO 对应SV-1系统节点接口comm 块transfer_rate/network_name/propagation_speed数据链 Link-16/11/22 配置SV-2物理资源流物理层约束供电/冷却仿真一般忽略基础设施节点SV-4系统功能列表platform_type 的功能集 processor 规则Doctrine WRASV-5b功能→活动映射每个 processor 规则对应哪个想定任务任务指派逻辑SV-10b系统状态转移satellite mover 轨道相位 sensor/processor 内部状态机WCS/Tight/Free/Hold 状态切换SV-10c系统事件时序事件处理器 on_update/on_track_drop 的触发链Lua 触发器时序四种常用的 category平台类型映射WSF 的 platform category 和 DoDAF 的 system category 有天然对应关系。你做 AFSIM 的时候选 aircraft / ship / ground_vehicle / satellite在 SV 里就是不同类别的系统节点aircraft→ 空中平台系统气动模型、高度层划分、机动包线ship→ 水面/水下平台系统浮力模型、声呐配置、摇摆影响ground_vehicle→ 陆地平台系统地形影响、视距约束、机动性satellite→ 太空平台系统mover WSF_SPACE_MOVER轨道参数、过顶窗口、覆盖周期选对 category物理模型就自动跟上了。这和 SV 里定义系统节点时先确定这是什么类型的系统是一个道理——类型定了接口标准、性能参数、约束条件的范围就定了。你在 SV-1 里把雷达成像星标记成 satellite 类它在体系里能连的下游节点中继星、地面站、适用的 StdV-1 标准CCSDS、Ka 频段、自由空间光就已经被框住了一大半。系统之系统SoSSV 的上一层最后提一个概念当你把多个 SV 拼起来描述一整套天基 ISR 防御体系时你其实在做System of Systems系统之系统架构。单个 SV 描述一颗侦察星怎么把 SAR 条带经中继星送进地面站SoS 视角描述SAR/EO/ELINT 侦察星座 中继星 地面站 太空指控中心 打击平台如何协同。杀伤网下一篇会讲本质上就是一种动态重组的 SoS——天基 ISR 正是传感器—射手解绑的教科书案例发现编队的星跟发射导弹的平台隔着整条天地链路。DoDAF 不直接提供SoS 视图但你用 OV/SV/CV 的组合就能把 SoS 描述清楚——这也是 DoDAF 灵活的地方视角是积木怎么搭看你的分析目的。下一篇我们看 CV能力视角和 StdV/DIV 标准/数据视角。CV 回答需要什么能力是预算论证的基础StdV 回答按什么标准做是系统互操作的前提。