3. 数字仿真平台总体架构设计

数字仿真平台不是把若干仿真程序简单堆在一起,而是要把模型、算法、数据、调度和可视化组织成一个可复用、可扩展、可验证的整体。总体架构设计的核心任务,是回答三个问题:平台分成哪几层、每层承担什么职责;模块按什么原则划分、边界在哪里;数据在模块之间如何流动、接口如何约定。本节围绕分层架构、模块划分原则、数据流与接口设计,以及实时与非实时仿真模式的对比展开。

一、平台分层架构

面向航天器GNC(制导、导航与控制)的数字仿真平台,通常采用五层结构,自下而上依次为:基础运行层、模型与算法层、仿真服务层、任务编排层、应用交互层。分层的关键约束是上层只能通过接口调用下层,下层不得反向依赖上层,同层之间通过明确定义的数据契约通信。

基础运行层提供计算资源、操作系统适配、时钟服务、日志与持久化能力,是平台的时间基准来源。模型与算法层承载航天器动力学、敏感器、执行机构、导航滤波、制导律、控制律等模型,是仿真精度的决定因素。仿真服务层提供求解器、调度器、数据总线、参数管理与事件管理,负责把离散模型组织成可推进的仿真过程。任务编排层面向具体任务,把模型、参数、工况和试验流程组装成可执行的仿真方案。应用交互层提供三维态势、曲线监视、参数注入与结果回放等界面。

GNC数字仿真平台分层架构与数据流 应用交互层 三维态势显示 · 曲线监视 · 参数注入 · 结果回放 · 告警面板 人机接口 任务编排层 工况配置 · 模型装配 · 试验流程 · 批处理调度 · 版本与场景管理 任务组织 仿真服务层 求解器(定步长/变步长) · 调度器 · 数据总线 · 参数管理 · 事件管理 时间同步 · 采样保持 · 插值 · 记录与回放 仿真引擎 模型与算法层 轨道/姿态动力学 · 星敏感器 · 陀螺 · 加速度计 · 推力器 · 飞轮 · 磁力矩器 导航滤波(EKF/UKF) · 制导律 · 控制律 · 执行机构分配 模型资产 基础运行层 计算资源 · 操作系统适配 · 时钟服务 · 日志 · 持久化 · 网络通信 运行底座 指令/参数下发 状态/遥测上传 数据总线:统一时间戳 + 命名信号

图中右侧红色箭头表示控制指令与参数自上层向下层下发,左侧蓝色箭头表示状态与遥测自下层向上层汇聚,二者在仿真服务层的数据总线上完成时间对齐与分发。这种“指令下行、状态下行”的双向结构,是GNC闭环仿真的基本数据骨架。

二、模块划分原则

模块划分不是按代码文件切分,而是按职责单一、接口稳定、可独立替换三条原则进行。具体可归纳为四点:

  • 按物理对象划分:星敏感器、陀螺、推力器等各自成模块,便于用不同精度模型替换,例如将理想陀螺替换为含零偏和随机游走的陀螺模型。
  • 按算法职责划分:导航滤波、制导律、控制律分属不同模块,避免算法耦合导致无法单独验证。
  • 接口与实现分离:模块对外只暴露输入端口、输出端口和参数集,内部实现可替换而不影响调用方。
  • 时间语义明确:每个模块必须声明是连续、离散还是事件触发,并明确采样周期,避免混用导致时序错误。

以姿态控制回路为例,可划分为:姿态动力学模块(连续)、陀螺模块(离散,采样周期10 ms)、星敏感器模块(离散,采样周期200 ms)、姿态确定模块(离散,10 ms)、控制律模块(离散,10 ms)、飞轮模块(离散,10 ms)。各模块通过命名信号连接,例如 gyro.omega_meas、star.quat_meas、ctrl.torque_cmd、rw.speed。这种划分使每个模块都能单独做单元测试。

三、数据流与接口设计

数据流设计的核心是统一时间基准和显式数据契约。平台内部所有信号必须携带时间戳,单位为秒,采用仿真起始时刻为零点的相对时间。接口设计建议采用“端口—信号—参数”三层结构:端口定义方向与数据类型,信号定义名称、单位、量纲和更新周期,参数定义可配置的模型系数。

一个典型的接口定义示例如下:

interface GyroPort {
  input:  none
  output: omega_meas : Vector3  // rad/s, 本体坐标系
  param:  bias       : Vector3  // rad/s, 常值零偏
          arw        : double   // rad/sqrt(s), 角度随机游走
          sample_T   : double   // s, 采样周期, 默认0.01
  timing: discrete, period = sample_T
}

接口约定中必须明确坐标系。本文及图示统一采用本体坐标系描述角速度与力矩,采用J2000惯性系描述轨道与姿态四元数;若某模块使用轨道系,必须在接口注释中显式说明并给出转换关系。数据总线按“发布—订阅”方式工作:模型模块发布信号,调度器按周期触发订阅者读取,读取时自动完成时间戳对齐与零阶保持或线性插值。

四、实时与非实时仿真模式对比

实时仿真要求仿真推进与墙钟时间同步,通常用于硬件在环(HIL)测试,例如将真实星载计算机接入回路,仿真步长需稳定在1 ms并留有余量。非实时仿真追求计算效率和精度,允许以快于或慢于墙钟的速度推进,适合大批量蒙特卡洛打靶和算法迭代。两者的关键差异如下表所示。

对比维度 实时仿真 非实时仿真
时间基准墙钟同步,步长固定逻辑时间,步长可自适应
典型步长1 ms 或 0.5 ms1 ms~10 ms,可变步长
调度方式优先级抢占,硬实时顺序推进,无截止期约束
接口对象真实硬件、总线、IO板卡纯软件模型、文件、数据库
主要指标抖动、超时率、CPU余量精度、吞吐量、收敛性
典型用途HIL、快速原型、在轨验证蒙特卡洛、参数扫描、算法设计

选择模式时,可用一个简单判据:若仿真回路中接入真实硬件或要求与外部设备按真实时间交互,必须选实时模式;若只做算法验证、参数寻优或统计打靶,优先选非实时模式以节省时间。实际工程中常采用“非实时设计 + 实时验证”的组合流程:先在非实时环境下完成控制参数整定和蒙特卡洛评估,再把通过验证的模型和参数迁移到实时环境做HIL测试。

设计提示:无论采用哪种模式,模型模块本身不应感知实时与否,实时性应由仿真服务层的调度器统一处理。这样同一套模型资产可以在两种模式下复用,避免重复开发和结果不一致。

综上,平台总体架构设计应围绕分层解耦、职责单一的模块划分、带时间戳的显式接口,以及可切换的实时/非实时调度模式展开。架构一旦确定,后续的模型开发、试验编排和结果分析都应遵循同一套接口与时间约定,这是保证仿真结果可信、可复现的前提。