基于模型系统工程方法的卫星测控模拟器设计

李忠华 高小亮 强立冬 刘政男

(中国空间技术研究院通信卫星事业部 北京 100094)

0 引 言

传统的卫星测控模拟器研制模式以文档为驱动，通过文档的版本管理进行技术状态控制。产品的功能特性以及设计表达均通过文档进行陈述，由于文字表达的多样性，较难形成格式化标准，使得产品的设计的数字化程度较低，将需求、设计和测试等各类孤立文档的信息进行集成，需要消耗大量时间。产品研制的几个阶段之间需求和设计的更改追踪需要人工比对，产品的设计文档不能直接映射到产品，相似产品之间的继承和复用通过文档复制实现，较难进行自动化的对比和分析[1-2]。另一方面，传统的基于文档的产品设计很难将设计文档进行直接仿真验证。

MBSE提供了解决现有研制模式问题的指导方法，其基本思想是以模型驱动工程设计，利用数字化模型进行技术状态控制。文献[2-3]提出了利用MBSE进行系统设计、任务分析与设计，文献[4-6]提出了利用MBSE进行天线、北斗接收机、机电产品的设计与研究，以上是MBSE方法在设计上的具体实践，但没有进行基于MBSE的仿真验证。文献[7]提供了MBSE设计中的验证方法，但需要模型代码的生成和集成，需要精确的数字模型，实施门槛较高。鉴于此，本文以卫星测控模拟器的产品设计为例，进行MBSE在具体产品中的实施，并提出了一种快速的模型验证方法，最后结合产品实践进行应用分析。

1 MBSE简介

国际系统工程学会(International Council on System Engineering，INCOSE)对MBSE的定义是：基于模型的系统工程是通过形式化的建模手段，从概念设计阶段开始就能够支持系统需求、设计、分析、验证和确认等活动，并持续贯穿整个开发过程和后续的生命周期阶段。根据在INCOSE发布的2020年规划，到2025年各个领域将应用MBSE[1]。

建模语言、建模方法和建模工具是MBSE的三大支撑，建模工具则是建模语言的设计应用工具。MBSE作为一种系统设计的方法论，并没有规定哪一种工具或者语言来进行系统的建模和设计。一般而言，各种建模语言和专业的软件工具都可以作为实施MBSE的工具，SysML是MBSE实施的常用建模语言之一。

SysML是一种多用途的标准建模语言，能够支持复杂系统的详细说明、分析、设计、验证和确认，这些系统可能包括硬件、软件、信息、过程、人员和设备等。在MBSE工程实践中，SysML是应用最为广泛的系统级建模语言，支持SysML的商业工具有IBM Rational Rhapsody、MagicGrid及Enterprise Architect等。

2 卫星测控模拟器简介

在卫星发射前，卫星地面站需要与卫星进行接口匹配性测试，以验证地面测控系统是否具备测控卫星的能力。通常而言，卫星制造商会使用卫星测控模拟器到地面站进行接口测试。卫星地面站与卫星测控模拟器之间通过无线射频接口，进行遥测参数、遥控指令和测距信息的检查，以验证接口的匹配性。

卫星测控模拟器仿真了卫星的遥测、遥控与跟踪设备的功能，在产品研制方面包含了软件和硬件，传统的卫星测控模拟器研制分为需求制定、产品设计和测试实验3个阶段，每个阶段的成果为文档或者产品。

3 MBSE建模设计

在MBSE工程实践中，不同角色的工程人员利用不同的建模工具工作。在典型的案例中，系统工程师通常采用SysML进行系统模型设计，控制工程师采用Simulink进行控制模型设计，轨道工程师采用STK进行航天器轨道建模设计。本节利用SysML对卫星测控模拟器从需求、设计、测试三个方面进行建模设计，并提出了利用中间件进行SysML模型与其他模型进行仿真验证的方法。

3.1 需求模型设计

在传统的测控对接模拟器产品研制中，技术要求中规定了产品的功能、工作模式、性能和设计约束。本节通过需求图、用例图、状态机图及参数图进行产品需求模型的设计。

3.1.1需求图设计

在SysML体系中，需求图作为需求的拓扑表达形式被广泛应用。需求图的基本元素包含需求和需求关系两部分。如图1所示，卫星测控模拟器产品的三方面的需求分别为功能需求、性能需求和可靠性需求，每个顶层需求下继续分解为子需求，例如性能需求下面分为遥控误码率、遥测误码率和射频信号捕获门限需求。需求本身可以进行逐级细分，需求关系表达了需求之间或与外部元素的关系，例如图1中除了需求包含关系之外，还有需求跟踪trace关系。例如图中表示“遥控模块”的设计需要跟踪“遥控指令接口”的需求，当需求变更时，相应的设计部分将会收到提示信息，同时也能需求跟踪矩阵的建立。需求图可以涵盖技术要求中各需求条目，需要进行说明的是，SysML建模工具在进行需求分解时，如果单纯的框图无法表达具体需求，每个框图都支持框图的迭代描述，以及文档链接或文字陈述的链接。

图1 系统需求图设计

3.1.2用例图设计

技术要求的提出者为产品的用户，因此会从用户角度对产品的功能进行描述。SysML中的用例图是从用户角度来描述系统功能的模型图。如图2所示，user是抽象的用户，卫星测控模拟器对于用户而言，其主要的操作的功能为遥测遥控仿真用例以及跟踪仿真用例，遥测遥控仿真用例又包含遥控指令解析、遥控指令执行、遥测参数组帧、遥测参数发送和停止仿真用例。用例图一方面用于需求模型的建立，另一方面也用于系统的测试。

图2 系统用例图设计

3.1.3状态机图设计

在传统的卫星测控模拟器技术要求中，除了对产品功能的描述外，还会对产品的工作模式进行规定。SysML中的状态机图描述系统或模块根据事件而产生的行为，在系统各个层级的建模中均可使用。状态机图既可以描述系统层级的工作行为，也可以描述模块细节行为，因此状态机图可直接用于代码的生成。在技术要求这种系统层的状态机图，主要描述产品顶层的行为。卫星测控模拟器系统层的状态机图如图3所示，系统启动后默认进行遥测遥控仿真，再通过使能或者禁止事件来进行跟踪仿真或者结束仿真。

图3 系统状态机图设计

3.1.4参数图设计

产品技术要求中还会对产品的内外部参数的数学模型进行限制，一般而言作为设计约束出现在文档中，SysML中参数图可以表示等式或者不等式的数学模型。如图4所示，在卫星测控模拟器跟踪仿真中，跟踪仿真即仿真跟踪接收机与地面设备间的时间延迟，除了跟踪接收机的固定延迟a外，还可以设置附加延迟b。固定延迟a仿真的是卫星本身对测距信号的延迟，附加延迟b仿真卫星与地面设备间空间距离造成的信号延迟，因此卫星测控模拟器输出的总延迟为两者之和，即对输入测距信号的延迟为a+b，参数图从数学角度表达了这一设计约束。

图4 测距参数图设计

3.2 技术方案模型设计

在工程实践中，产品技术要求确定后需要进行技术方案或者设计方案的制定。基于MBSE的思想，这一阶段的模型与需求模型紧密对应，将需求模型对应的内容进行设计表达。本节通过模块定义图、内部模块定义图和活动图三种元素进行产品技术方案模型的设计。

3.2.1模块定义图设计

技术方案的首要内容是对所设计产品的系统结构的阐述，在SysML体系中模块定义图，英文名称为“Block Definition Diagram”，简称BDD，是系统建模过程中最为常见的图之一，BDD是一种结构图，它主要对系统的结构组成以及组成元素间的关系进行描述[8-9]。如图5所示，在技术方案中卫星测控模拟器由遥测遥控模块、跟踪模块和用户界面组成。每个模块还能继续细分成更小的功能模块，遥测遥控模块分成遥控模块和遥测模块，跟踪模块分成调制解调模块和测距应答模块。模块定义图从结构上对所设计的产品进行了说明，也可以作为系统研制进度管理中的工作分解结构的依据。

图5 系统模块定义图设计

3.2.2内部模块定义图设计

在进行功能模块设计后，技术方案会给出各设计模块间的接口关系。在SysML体系中的内部模块定义图，英文名称为“Internal Block Diagram”，简称IBD，IBD定义了系统内部的结构及接口关系[8-9]。如图6所示，卫星测控模拟器的IBD中定义了对外的射频接口，明确了射频接口功能由跟踪模块提供。射频接口接收和发送卫星射频信号，调制解调模块将解调后的遥控指令发送到遥控模块，遥控模块在遥控指令解析和执行后，驱动遥测参数变化以及组帧和发送。遥测数据发送到调制解调模块进行数据调制后，通过射频接口发送。IBD支持级联定义，两个模块间的接口可以通过IBD进行详细定义，可以代替传统软件产品研制中的接口数据单。

图6 系统内部模块定义图设计

3.2.3活动图设计

在产品详细设计中，基于MBSE的体系既可继续迭代使用SysML提供的模型图进行设计陈述，也可使用其他专业工具进行建模。在卫星测控模拟器的详细设计中，跟踪模块须采用硬件设备进行实现，在建模时可使用System C、Verilog、VHDL等硬件描述语言进行建模。在本文中，卫星测控模拟器的跟踪模块采用货架式产品，因此不再赘述。卫星测控模拟器的遥测遥控模块和用户界面模块采用软件形式实现，在建模形式继续沿用SysML的活动图、序列图和状态机图进行建模。在行为模型建模中，活动图被广泛地应用，一些商业的SysML建模工具可支持活动图生成C++、C#、Java等编程语言源代码。如图7所示，遥测模块和遥控模块在收到遥控指令这一事件后产生的一系列活动。遥控指令模块首先验证指令译码，并进行指令验证，然后将验证结果以遥测的形式通过遥测模块进行下传。如果遥控模块验证指令错误，则事件相关活动结束，如果指令正确则指令执行，并将指令执行结果以遥测形式下传。遥测模块的常驻状态为遥测定时下传，根据遥控模块的事件响应更新遥测。

图7 指令译码活动图设计

需要进行说明的是，SysML中的活动图可通过建模工具生成测试用例，因此活动图是系统验证的基础。

3.3 产品模型设计

3.1节利用SysML进行了卫星测控模拟器的需求模型设计，3.2节进行了技术方案模型设计，本节将给出产品模型的整体设计，如图8所示，整个产品模型包含需求、结构和行为三大部分。按照SysML的分类，需求模型、结构模型属于静态模型，描述了产品构造性的特征；行为模型属于动态模型，描述了产品执行任务时的状态；产品的模型图即为产品模型。需求模型和结构模型已经在前面进行了论述，行为模型中只讨论了指令译码。根据产品需求，系统还具备遥测组帧和测距信号转发两个活动，限于篇幅没有对遥测组帧和测距信号转发这两个活动的设计进行展开叙述。需要进行说明的是，行为模型可以在建模工具中进行仿真，从而验证所建立模型的正确性。在建模工具中，这些模型彼此关联，既能进行需求追踪，又可以进行模型的调试。因此，模型的仿真实验内容主要是对产品行为模型的执行与调试。

图8 卫星测控模拟器产品设计模型

4 模型验证扩展设计

在SysML中，行为模型(序列图、状态机图和活动图)在建模工具中可以进行动态运行，在形式上和逻辑上验证模型设计的合理性。SysML作为系统级的建模工具，适合于总体设计，不能代替MATLAB等专业工具的仿真，因此在进行模型验证时需要引入其他工具。在文献[7]中SysML与Simulink通过生成C/C++代码的方式进行系统协同验证，这种方式需要SysML模型颗粒度精细，能够通过SysML模型生成直接应用于工程的C/C++代码，需要投入大量时间进行模型细化和调试，不适用于快速系统验证。此外，在现有技术中，FMU(Function Mock-up Unit功能模型)作为外部模型进行嵌入，与SysML模型进行联合仿真，但FMU需要专用的工具进行封装及设计。鉴于此，本文提出基于中间件的验证扩展设计，大多数成熟的模型仿真工具都提供中间件接口。

如图9所示，SysML模型与外部模型间彼此的交互通过中间件实现。中间件既可以作为外部模型的容器，也可以作为外部模型的中转接口，典型的中间件有COM、Javabean和CORBRA。SysML建模工具支持的脚本语言作为调用主体，以使中间件处于工作状态，并返回仿真参数到SysML模型。

图9 中间件交互设计

在图9中，SysML模型中的行为模型用于系统行为建模和验证，因此在引入外部模型时主要是对模型元素进行修改和行为的展示。EA模型工具即Enterprise Architect的建模环境，脚本语言在系统作为模型检查工具，并不参与模型仿真。与SysML模型运行在不同的上下文环境中，脚本语言可以获取模型元素的属性，但无法识别每一个模型元素的具体功能，需要脚本语言对模型元素进行识别，具体流程如下：

1) 遍历行为模型图中的元素，根据元素属性和预先指定的元素特征识别元素，例如以元素名称识别模型元素。

2) 根据识别的结果，建立模型元素变量以备和外部模型进行数据交互。

4.1 基于COM组件的仿真扩展

以遥控指令译码为例进行中间件设计说明，在图7中有活动“遥控指令译码”，该活动采用外部模型的译码工具实现，在进行设计验证时，将译码工具封装为COM组件。以脚本语言VBScript进行实验，译码活动有“指令码”和“译码输出参数”两个属性，基于中间件的验证流程如下。

1) SysML流程到达“遥控指令译码”，VBScript根据存储的模型元素读取属性“指令码”。

2) VBScript以COM组件方式调用译码工具，具体实现为利用CreateObject函数创建COM对象，将“指令码”传入COM对象，并获取“译码输出参数”。

3) VBScript将译码工具输出写入模型元素属性“译码输出参数”。

需要进行说明的是，在Windows平台下，STK、Matlab和Simulink等专业仿真工具均支持COM组件形式调用，因此利用此方法可以进行SysML模型与外部模型的协同仿真，以实现快速验证设计。

4.2 基于RPC的仿真扩展

远程过程调用(Remote Procedure Call，RPC)最早应用于分布式系统开发，为本地计算机提供了访问远程服务器上应用构件的方法。随着计算机硬件性能的不断提升，RPC也适用于同一计算机内独立构件的交互。RPC在本质上也是通过中间件接口进行通信，只不过在底层形式上可能是进程通信、网络通信等，部分仿真工具直接提供了RPC接口。在图4中，附加延迟b可由外部模型工具STK计算得到，具体流程如下：

1) 脚本语言创建与STK连接的字符串，并通过Socket接口发送到STK。

2) 脚本语言读取模型元素的属性，将卫星轨道根数、地面站经纬度发送到STK，并获取卫星距离地面站的距离。

3) 卫星距离地面站的距离除以光速即可得到附加延迟b，将b的数值写入模型元素的属性。

4.3 与传统方法的比较

基于中间件的模型扩展验证方法，在技术途径上更利于实现快速仿真，有更广泛的应用范围。如表1所示，通过每种方法的实现途径可知，本文方法需要的工作步骤较少且简易。在模型调试和修改过程中，其他方法都需要做较多的调整，而本文方法仅须脚本语言且即时生效。此外，在方法适用范围上，本文方法的环境适应性也更强。

表1 几种模型扩展验证方法比较

5 应用分析

通过基于MBSE的方法进行产品的设计，将卫星测控模拟器的设计由传统的文档驱动替换为模型驱动，通过MBSE的应用设计和模型验证扩展设计，可得到如下的分析。

1) 维度清晰，易于复用、更改易于追踪。用SysML语言进行系统设计时，需求和设计都被组织成模型图，各图之间又紧密联系，各图的组织结构清晰。因此进行相似产品的复用时，只需修改特定图表的某一部分，即可完成设计。SysML建模工具会对SysML模型进行一致性检查，在某个图表修改时，会自动识别影响区域，因此产品的复用和修改都具有较高的效率。

SysML在需求管理方面，在设计时进行需求的链接和跟踪，可以快速进行需求变更分析，以及进行相应模型的更新，有较强的产品技术状态控制能力。

2) 系统集成和深度验证。SysML的建模工具不能直接进行与专业工具的集成，利用中间件方式进行集成后进行模型的验证，使得设计和验证同步进行。另一方面，目前的集成方式仅限于数据集成，实现了系统功能在形式上和逻辑上的验证，尚难以进行精确的时序仿真、系统性能评估等。各专业建模工具隶属于不同技术领域，各厂商产品对外接口不统一，还没有相关行业标准。因此在后续的基于MBSE的卫星相关配套产品研制时，进一步研究SysML模型与各专业建模工具的深度交互接口，能够进一步提升MBSE的设计验证能力。

6 结 语

本文利用MBSE实现了卫星测控模拟器设计，并利用中间件技术实现了SysML模型与其他专业建模工具的协同验证，克服了基于设计文档的产品研制模式在信息孤立、难于需求跟踪和复用方面的问题。在模型扩展验证方面，缓解了传统验证方法技术途径复杂，难于快速仿真验证的技术问题。此外，本文分析了基于MBSE的卫星测控模拟器的设计在实践中仍然需要研究的内容。