工作示例——Kshana作为多工具任务分析的粘合层
本示例让一条轨迹端到端地经过基于标准的互操作和任务分析场景类型,展示Kshana如何位于项目已在使用的高保真工具之间,而不是与之竞争:用于轨迹设计的GMAT(通用任务分析工具)、Orekit和STK(系统工具包),以及用于姿态与轨道控制系统(AOCS)仿真的Basilisk或42。每一步都是一个可运行的场景类型,每个结果都带有注明其范围和证据等级的label。
诚实说明:这是一条处于A阶段前/权衡研究层级(任务的第一个正式设计阶段之前)的几何/解析流水线。它不是飞行动力学认证;见每个类型的
label字段。
下文使用的其他缩略语:FDS(飞行动力学系统),CCSDS(空间数据系统咨询委员会),OEM(轨道星历消息),SGP4(简化常规摄动4,两行根数传播器),TOML(场景文件格式)和CLI(命令行界面)。
流水线#
external FDS (GMAT/Orekit/STK) Kshana open core
│ CCSDS OEM ephemeris │
▼ ▼
[oem-interop] ──ingest──▶ [passes] ──▶ [link-budget] (when does the
import the orbit the when is it does the contact close?)
designer produced visible? downlink close?
│
▼
[space-weather] (how fast does drag
activity-driven decay the orbit?)
density
各步骤是相互独立的运行:每一步从自己的场景文件取得输入,因此要把一个数值从一步带到下一步(例如把passes的斜距带入link-budget),需要编辑下一个文件。campaign类型可以在共同条件下,在一次运行中容纳多个类型;见CAMPAIGNS.md。
下面每条命令都从仓库根目录运行,其下方的摘要是kshana 0.40.0对随附场景打印的第一行。
1. 导入设计人员生成的轨迹(oem-interop)#
GMAT、Orekit和STK都能导出 CCSDS轨道星历消息。Kshana能够导入它们(桥梁的另一个方向),因此Kshana的分析可以从轨迹设计人员签认的确切轨道出发,而不是重新推导的近似值:
kshana scenarios/oem-interop.toml # round-trips a reference orbit (self-test)
# or, to ingest a real file, set oem_text in the scenario to the external OEM
oem-interop: round-tripped 2 segment(s), 12 states; max round-trip error 4.88e-7 km / 4.61e-10 km/s (MODELLED interop)
它报告分段、对象、坐标系和历元跨度,并做速度一致性检查,表明星历已被忠实地导入(往返误差低于1×10⁻⁶ km)。如果改为在oem_text中给出外部文件,它会报告所解析的内容:输入kshana scenarios/orbit-sgp4-gps.toml --export-oem gps.oem写出的OEM时,它会打印oem-interop: ingested 30 segment(s), 10830 states from external OEM (originator KSHANA) (MODELLED interop)。label明确指出,这是结构和物理层面的导入检查,而不是对来源的轨道精度验证。
2. 从地面站何时可见?(passes)#
kshana scenarios/passes.toml
passes: 5 pass(es) of a 550 km / 97.6° orbit over (52.2°, 4.4°) > 10° in 24 h; 1659 s total access (MODELLED)
预测在高度截止角之上、经过某个站点的升起/落下过程:信号捕获(AOS)、最接近时刻(TCA)、信号丢失(LOS)、最大仰角和持续时间,以及总的可接入时间。这就是地面段规划所需的查询。轨道是按IAU 2006/2000A链换算到地固坐标系的SGP4根数集,所给仰角是视仰角:包含ITU-R P.834-9折射和下行光行时,二者都可开关(refraction、light_time)。
3. 联络能否闭合?(link-budget)#
对于一次过境,把斜距和终端数据代入CCSDS 401 / DSN 810-005(NASA深空网)链路方程:
kshana scenarios/link-budget.toml
link-budget: x-band, 2000 km, 1000000 bit/s -> FSPL 177.0 dB, Eb/N0 96.6 dB, margin 92.1 dB (closes)
报告自由空间路径损耗(FSPL)、载噪密度(C/N₀)、每比特能量与噪声密度之比(Eb/N₀)、裕量,以及链路相对于所需Eb/N₀ 是否闭合:这是通信可行性检查,把“它可见”变成“我们确实能下行数据”。这些数值直接由文件中的输入得出(此处为55 dBW的EIRP(等效全向辐射功率),进入53 dB/K的接收G/T(增益与噪声温度之比));在解读裕量之前,请先填入你自己终端的数据。这是确定性的计算,不是经过校准的终端数据手册。
4. 环境使它衰减得有多快?(space-weather)#
kshana scenarios/space-weather.toml
space-weather: F10.7=180 F10.7a=165 Kp=4.0 (ap=27) -> T_inf=1047 K; density x1.49 at 300 km (MODELLED)
通过Jacchia-71外逸层温度,由太阳(F10.7,即10.7 cm射电流量,及其81天平均值F10.7a)和地磁(Kp和ap指数)活动驱动热层中性密度。这体现了静态大气所忽略的、约5–10倍的太阳周期密度变化,因此轨道寿命或阻力估计反映的是空间天气状况,而不是固定的大气。自0.30起,该密度为Jacchia 1971热层密度,对照NRLMSISE-00(美国海军研究实验室质谱仪与非相干散射)进行了特征分析,但不是经数据验证的NRLMSISE-00大气。
5. 把结果交还出去(导出)#
同一个CLI会为下一个工具写出标准文件。在orbit场景上,--export-oem <file>写出带速度的CCSDS OEM 2.0星历(GMAT、Orekit和STK读取的文件),--export-sp3 <file>写出SP3(标准产品3)精密星历,--export-omm <file>写出CCSDS轨道平均根数消息目录。--export <czml|kml|geojson|stk|sigmf|all|list>涵盖各类查看器:CZML(Cesium语言)、KML(Keyhole标记语言,用于Google Earth)、GeoJSON、STK星历文件(.e,每颗卫星一个,外加用户一个),以及来自spectrum类型的SigMF(信号元数据格式)录制文件。--export list会说明哪些适用于某个场景。对于月球,lunar-interop-export类型会把月球坐标系、时间尺度和星历输出为带有conformance检查的CCSDS OEM。见INTEROP.md。
为什么它是粘合层,而不是竞争者#
每一步都是一个小型、可审计、可复现、带有明确范围标签的场景。高保真工具负责轨迹优化、六自由度(6-DoF)AOCS以及气动热的进入、下降与着陆(EDL);Kshana负责开放、可引用、可运行的连接层:导入标准格式,回答跨领域的几何与可行性问题,并把结果交给下一环节,其等级使任何合作方都无需许可证即可运行。另请参见配套的任务分析类型launch-window、reentry、eo-coverage、space-packet和attitude-budget。