航天地面站低代码开发平台方案设计

2024-04-30王钧慧

电讯技术 2024年4期

王钧慧,李婷

(中国西南电子技术研究所,成都 610036)

0 引言

近年来,我国航天事业的发展突飞猛进,在轨航天器数量不断增多,需要建设与之匹配的航天测控地面系统,以满足快速增长的航天器测控和遥感数据接收任务需求[1]。

地面站监控系统是航天器测运控地面系统的调度和管理核心,主要完成对系统内所有可监控设备的统一管理,在任务计划的驱动下,分配设备资源,自动组织相关设备完成过境卫星的捕获、跟踪,按要求执行航天器测控、数据接收任务。稳定、可靠的站控系统是发挥地面系统效能,提升地面系统任务成功率的必要保障。目前,由于航天测运控领域技术快速发展,不同系统的组成、运行流程和接口等内容存在很大的差异,从而导致软件交付周期长、软件可靠性低等问题。

加拿大CALIAN公司系统工程部针对卫星地面站开发了Mon-A-CoTM,主要用于对地面站设备的工作状态进行集中监视和控制,主要用户包括Inmarsat、Hughes、Boeing、Sirux-XM、Intelsat、EchoStar、Telenor,KDDI等。Mon-A-CoTM监控系统由监控服务器(Mon-A-CoTM Server)、监控客户端(Mon-A-CoTM GUI)存档服务器(Mon-A-CoTM Archive Server)、可视化框图编辑工具(Mon-A-CoTM System Builder)组成。

MBSE通过形式化的系统建模语言(Systems Modeling Language,SysML)对系统进行描述,采用不同的视图描述系统不同视角,将不同的方面分解为不同的视图,建立复杂系统分布在各个视图的模型,并保证这些信息的一致,综合描述系统[2-4]。

“低代码”一词是由Forrester咨询公司在2014 年提出的,低代码平台通过最少的手工编码和在配置、培训、部署等方面的最低初期投入来实现业务应用的快速交付。可见,构建低代码平台的目的是降低开发成本并快速交付应用。低代码软件平台可简化软件开发过程,提高成长率,缩短软件交付周期,并且系统稳定性好,只要经过简单测试即可交付使用,最终降低软件开发成本[5-6]。

低代码平台的核心基础是对业务系统进行建模。基于模型的系统工程(Model-based Systems Engineering,MBSE)方法通过模型的不断演化、迭代递增而实现产品的系统设计,通过模型的结构化定义可以清晰地表达产品设计初期各方面的需求,在设计初期就能通过仿真发现大量不合理的设计方案。航天地面系统是高度专业化的系统,低代码平台有助于促进业务领域和IT技术的深度融合。领域专家与IT技术人员使用同一套标准化、结构化的语言进行业务模型设计和IT系统开发,可实现业务和IT之间的无障碍沟通,大幅提升组织的协作效率和开发过程。

本文的实现方案包括基于MBSE的航天地面系统模型设计、软件架构设计及实现路径。

1 基于MBSE的航天地面系统模型设计

航天地面站控系统本质上是对地面系统开展建模,同时通过接口来实现对系统的监视或者控制,类似于航天地面的“平行系统”。本文不对MBSE的建模过程进行描述,主要描述如何利用航天地面系统MBSE的建模结果来指导站控系统的实现。

1.1 SysML介绍

SysML中包括结构、行为、需求和参数4种类型的建模语言。

1) 结构图：包括模块定义图(Block Definition Diagram,BDD)、包图(Package Diagram,PD)和内部模块图(Internal Block Diagram,IBD)3类。模块定义图用于表示系统结构组成元素即模块(block)的特性,以及元素之间组成关系。包图从文件夹(package)角度展示系统模型的多级组织方式,帮助阅读模型的人更好理解模型结构,起到“导航”的作用。内部模块图展示block的内部结构、所包含的part之间的接口和交互关系。

2) 行为图：包括用例图(Use Case Diagram,UCD)、活动图(Activity Diagram,AD)、状态机图(State Machine Diagram,SMD)和序列图(Sequence Diagram,SD)。用例图主要用于展示外部人员/系统如何使用系统功能来完成某个目标。活动图用于展示活动/功能执行的流程顺序、控制逻辑、输入输出、数据转换、职责划分等内容。状态机图表示某个block的状态类型,以及不同状态之间的切换条件。序列图主要是基于系统不同结构之间信号传递的交互活动图。

3) 需求图：需求是指系统必须满足的能力或条件,一个需求能够分解成多个子需求。需求图能够描述系统的详细需求以及分系统的需求、各需求之间以及需求和其他建模元素之间的关系。

4) 参数图：定义和展示参数之间约束/计算关系,用于支撑SysML系统模型的计算分析,如执行约束、验证需求、定义数据计算关系等。

1.2 航天地面系统模型

航天地面系统的需求图可直接借用标准的SysML,同时利用MBSE对航天地面系统的组成结构、行为和参数等内容进行建模。

1.2.1 结构图

主要用来描述航天地面系统的组成、各个组成部分的关系以及设备内部结构。

1) 航天地面系统的结构：描述了系统的组成、设备属性等。典型的航天地面系统包括天伺馈、变频器、功放、场放、基带等设备。

2) 组成部分的关系：描述了设备连接关系、连接属性、信号流向、信息流向等内容。

3) 设备内部结构：描述了设备内部的结构,比如基带由背板、信号处理板卡、信息处理板卡、调制解调功能、捕获功能等内部组成结构。

1.2.2 行为图

航天地面系统的行为主要包括任务运行控制、系统测试、系统标校、系统故障诊断及自动处置等内容。

1) 任务运行控制：目标是使系统能够在工作计划的驱动下,站控系统组织各分系统自动完成工作计划所规定的测量、传输等各项任务。

2) 系统测试：系统自动测试的主要目的是检查系统的工作性能,由站控系统组织,各分系统配合完成系统的自动测试。

3) 系统标校：包括距离、相位等内容的标校,主要目的是通过严密的标定和校准来减少或消除系统误差。系统标校也是由站控系统组织,各分系统配合完成。

4) 故障诊断及处置：主要用于在任务中完成故障巡检和故障分析定位并根据预设的规则开展自动处置。

1.2.3 参数图

典型的卫星测运控地面站控系统涉及的参数主要包括卫星参数(卫星轨道、遥测参数、遥控参数、数传参数等)、任务参数(任务计划参数)、地面站参数(G/T、EIRP等地面设备参数)。

2 软件架构设计及实现

2.1 软件架构设计

低代码平台是一系列工具的合集,可通过视觉方式开发和交付完整的应用程序。拖放界面是低代码平台的核心。无须使用成千上万行复杂的代码和语法,可以使用低代码来快速、直观地构建包含用户界面、集成、数据和逻辑的完整应用程序。应用程序交付速度更快,手工编码更少。

典型的低代码开发平台主要包括如下内容：

1) 可视化IDE：一种用于可视化定义应用程序的UI、工作流和数据模型,并在必要时添加手写代码的环境。

2) 各种后端或服务的连接器：自动处理数据结构、存储和检索。

3) 应用程序生命周期管理器：用于在测试、生产中构建、调试、部署和维护应用程序的自动化工具。

面向航天地面站控系统的低代码开发平台架构如图1所示,主要包括模型桥接软件、可视化IDE和站控产品平台三部分。

图1 低代码开发平台架构Fig.1 Framework of low-code development platform

2.1.1 模型桥接软件

模型桥接软件主要是将利用MagicDraw、Raphsody等商用建模工具生成的MBSE模型转换为站控产品平台所需要的初步模型。

1) 结构图桥接插件：将MBSE的结构图转换为航天地面站的组成图、接口关系图。

2) 行为图桥接插件：将MBSE的行为图转换为航天地面站的运行控制流程、自动测试流程和自动标校流程等。

3) 参数图桥接插件：将MBSE的参数图转换为航天地面站的任务参数、计划、配置等内容。

2.1.2 可视化IDE

可视化IDE用于给设计人员编辑模型。设计人员可以将桥接软件生成的模型作为初始模型进行模型的细化生成最终模型,也可利用该工具直接生成最终模型。

1) 航天地面站结构编辑工具：用于生成航天地面站的结构图,描述了航天地面站的组成、连接关系等内容。

2) 航天地面站流程编辑工具：用于生成航天地面站的行为图,描述了航天地面站与卫星等设备的运行控制流程以及自身的测试、标校等流程。

3) 航天地面站参数管理编辑工具：用于生成航天地面站的参数图,描述了航天地面站的任务参数、运行计划、轨道参数等内容。

2.1.3 站控产品平台

站控产品平台将可视化IDE生成的最终模型作为平台输入,自动适应不同航天地面系统的差异。同时,针对站控系统面临的业务功能复杂、需求变化快、可靠性要求高、研制周期短等问题,采用容器构建的基础运行平台、基于微服务的软件架构等方法,进行站控系统总体架构的设计,使得站控系统具有良好的适应性和较强的水平扩展能力[7-9]。

1)基础设施层：主要为站控系统各类服务的运行提供基础的计算、存储和网络资源,是系统的服务承载平台。容器是云原生应用的基础运行环境,是指将软件打包成标准化单元,以用于开发、交付和部署,打包后的标准化单元被称为容器镜像,包含软件运行所需的代码、运行时环境、系统工具、系统库和设置等所有内容。软件采用基于Spring Cloud的微服务体系架构,该架构具有松耦合、灵活性好、扩展性强、可用性高等特点,能够适应各类航天地面装备的要求,并且具备扩展能力。在开发环境中,通过DevOps流水线开发的云原生业务应用最终以镜像包的形式交付。业务应用镜像需要上传到生产环境的容器平台中,在私有镜像库中进行统一管理,通过简单的资源配置即可一键式部署上线。

2) 数据交互服务层：负责将具体的硬件设备接入到站控系统,包括各类通信服务和协议转换服务。数据交互服务层还负责与各式各样的硬件设备进行信息交互,按照与设备之间的接口协议,进行通信数据帧的解析和编码。设备的接口协议通过设备元数据文件进行描述。

3) 设备管理层：是站控系统的设备管理核心,主要包括元数据管理服务、设备注册服务、设备配置服务、设备固件升级服务、状态采集服务、参数控制服务以及虚拟设备服务。

4) 系统支持服务层：系统支持服务包括规则引擎、计划调度、告警通知、数据管理、消息分发等通用服务,主要用于进行各类监控数据的初步处理,进行服务的调度,对出现的告警进行提示或通知等。

5) 业务应用层：是站控系统的核心功能层,主要功能是根据上级系统下达的或本地创建的任务计划,按照时间符合的原则,自动控制相关设备的工作参数,执行卫星测控、数据接收等任务。

2.2 软件实现

MBSE开发工具CatiaMagic(原名MagicDraw)支持OMG XMI标准和自定义格式两种方式,将功能架构、逻辑架构、物理架构等设计信息导出生成XML文件。

除了研发站控产品平台之外,还需要开发模型桥接软件,实现研发平台到产品平台的模型转换和桥接,减少人工录入带来的风险。具体来说,可通过CatiaMagic提供的OpenApi将MBSE结构模型和参数模型导出自定义格式的XML文件,读取导出的XML文件,解析相关参数并自动生成航天地面站控系统模型文件,从而实现MBSE解决域与软件实现域的桥接。模型转换软件根据航天地面系统的技术规范进行建模。不同型号的地面系统可以通过桥接的配置管理工具,方便快捷地复用相关的设计,并自动化地进行语法语义检查。

CatiaMagic生成的XML模型文件格式如图2所示。

图2 SysML模型文件格式Fig.2 File format of SysML model

2.2.1 结构图

航天地面站控系统的结构图借鉴SysML中的模块定义图(BDD)。将航天地面系统的BDD通过桥接工具进行抽取,并转换为站控系统可以识别的结构图。同时,站控软件平台还提供工具支持对结构图的深度开发,如图3所示。

图3 航天地面系统结构Fig.3 Structure of satellite ground station

站控系统在运行过程中,实时获取航天地面系统的运行状态,包括设备健康状态、设备之间的连接状态等信息,并直观地在结构图中进行显示,为操作人员提供直观的设备运行状态展示。

2.2.2 行为图

航天地面站控系统的行为图包括行为模型和流程引擎两个部分。航天地面系统的行为图的一个具体实现参见图4。

图4 航天地面系统行为图Fig.4 Behavior diagram of satellite ground station

行为模型借鉴SysML中的活动图,将航天地面系统的活动图通过桥接工具进行抽取,并转换为站控系统可以识别的结构图。同时,站控软件平台还提供工具支持对行为图的深度开发。系统将各任务控制流程分解为若干个业务节点,每个业务节点完成一项或多项具体的设备操作,各业务节点可以顺序、并发或条件执行。针对不同的任务将业务节点分为必备和可选两类,系统通过对可选业务节点和所有业务节点参数的编辑实现系统任务流程的可定制。系统按任务类型提供可视化的任务流程编辑功能,针对不同的任务类型,通过对各业务节点的拖拽,实现各类业务流程的可视化编辑。

流程引擎通过解析行为模型,驱动任务流程的执行。流程引擎读取行为模型,并执行初始状态(对应于开始节点)。流程引擎在初始事件中,根据流程类型,初始化任务上下文参数。流程引擎按照活动执行的成功、失败分别跳转到不同的活动,每个活动对应一个原子任务的接口实现(对应于业务节点、条件节点)。当流程引擎执行到最终状态,完成整个任务流程的执行(对应于结束节点)。

2.2.3 参数图

航天地面站控系统的参数图借鉴SysML中的参数图。将航天地面系统的参数图通过桥接工具进行抽取,并转换为站控系统可以识别的参数图。同时,站控软件平台还提供工具对支持行为图的深度开发。

站控系统在运行过程中,可根据参数的模型自动生成参数管理规范和要求,并可按照参数特征分别生成配置中心或者数据库的内容,无需人员进行数据库的建表、增、删、查、改等操作。

2.3 应用情况

某测控数传一体化系统应用本开发平台在2.5月之内即完成项目的研制、测试和交付,且系统运行稳定,较常规开发模式缩短了近45%。本文所述方法提升了MBSE的应用效能,为航天地面系统在数字化转型中的扩展应用提出了一个思路。利用本文中方法可将MBSE模型直接应用到交付软件中,无须针对各型装备重复编码测试,极大地提高了交付效率。

同时,探索了一种MBSE与现有业务研制过程的结合点并形成了新的研发模式。在新的研发模式下,由软件人员根据系统要求完成低代码开发平台的研发,由业务人员进行模型设计及软件交付,极大提升了系统研发效率,促进了业务领域专家和IT人员的深度融合。