多视图平台无关模型系统

技术领域

本申请涉及仿真技术领域，特别是涉及一种多视图平台无关模型系统。

背景技术

系统仿真是研究客观世界的一种手段，它将客观实体进行抽象建模，通过研究实体组成、行为逻辑、流程、规则、交互关系等内容，从而形成一整套仿真系统。目前，关于系统仿真中的建模方法，主要有文本建模语言（如Word、Visio等）、图形化建模语言（如UML、SYSML等）和程序建模语言（如C++、java等）组成。其中，若要求所建立的模型需要具备可执行能力，则目前只有程序建模语言能够满足，实现仿真模型应对外部输入的动态表现。

在仿真模型的开发与集成上，当前国外主要围绕MDA(Model DrivenArchitecture)的思想和方法，将仿真模型中的基本信息进行抽象，形成仿真元模型，支持仿真平台无关模型(Platform Independent Model,PIM)和仿真平台相关模型(PlatformSpecific Model,PSM)的概念。通过仿真PIM组件的装配和部署支持复杂仿真系统模型的组合，通过统一的仿真组件对象规范和可扩展的仿真服务体系结构支持仿真试验的运行。当前在M&S(Modeling&Simulation)领域,基于MDA的思想已经用于许多项目和公用集成框架中。

随着计算机技术的发展，工程层次上多领域、多组织和多层次的仿真模型开发与集成方法也获得了很大发展。2000年欧洲航天局借鉴MDA思想，将仿真模型的设计信息与运行信息相分离，提出了仿真模型可移植性规范SMP(Simulation Model Portability)，并在此基础上，于2004年提出SMP2.0，并将SMP2.0规范应用于欧洲航天技术中心的伽利略系统仿真辅助工具(Galileo System Simulator Facility,GSSF)。欧洲航天运行中心的金星探测和火星探测计划，支持航天系统概念设计的协同仿真环境等工程总体论证项目中，实现了不同领域和不同组织仿真模型可持续的开发和集成。围绕对SMP规范的跟踪与研究，国防科技大学系统工程研究所经过多年的开发，研制出一个面向作战效能评估领域的柔性仿真系统Sim2000，并在此基础上开发了Sim2000 2.0版本。

目前，涉及多领域的建模仿真主要考虑模型的集成问题。模型是仿真的核心。多领域复杂系统涉及的学科复杂以及各领域模型复杂的集成关系，这就使得一个合理有效的模型规范成为复杂系统仿真成败的关键。然而，在制定好模型的集成规范后，还需要针对不同的仿真应用配置模型接口，割裂不同子系统之间的耦合关系，做到去耦合。

在SMP2中的可移植性包含两个层次：

1)，仿真引擎之间模型的可移植性。通过制定仿真模型在不同仿真引擎之间的标准接口，SMP2支持不同仿真引擎之间模型的可移植性。

2)，仿真模型在不同平台之间的可移植性。SMP2支持仿真模型在不同操作系统和硬件之间的可移植性。该标准定义了一系列模型开发指南，指导模型开发人员在开发过程中如何避免使用与操作系统相关的开发模型，避免调用与特定操作系统相关的API或者与硬件相关的API。

虽然SMP2能很好的支持标准模型规范，但是SMP2并不能完全解决复杂系统仿真集成和开发的问题，在研究和实践过程中SMP2具有以下几点不足：

1) ，SMP2仿真模型可移植性规范的抽象层次较低，不易于无SMP2开发基础的人员使用；

2) ，SMP2模型行为描述能力较弱，无法实现代码可执行式生成；

3) ，SMP2目前主要运用于面向论证的集中式分析仿真，一般应用于航天和军事仿真领域，对大规模分布式仿真系统仍然存在效率低的问题，一定程度上限制了SMP2的应用范围;

4)， SMP2模型集成还不是完全的模型驱动。UML是模型驱动架构(Model DrivenArchitecture,MDA)的关键支撑技术之一，但它是一种领域无关的通用建模语言，并不提供对SMP2模型元素的支持，因此造成了缺乏规范化的概念建模和系统分析（基于UML）与模型集成相脱节的问题;

5)，现有的SMP2支撑工具不具备图形化的模型实例装配能力。当前几乎所有的SMP2工具虽然能够完成可视化编辑，但是不具备图形化的模型实例装配能力，不能形象的给出各模型实例的组成和交互关系。

6) ，视图单一的问题，SMP2主要支持组件装配视图，在模型行为、参数、关系等表达能力上和信息描述上不足，在平台相关阶段还需要加入大量的代码逻辑，才可实现模型逻辑闭环。

发明内容

基于此，有必要针对上述技术问题，提供一种能够解决复杂系统仿真集成和开发的问题的多视图平台无关模型系统。

一种多视图平台无关模型系统，所述系统包括：

平台无关建模层和平台相关执行层；

所述平台无关建模层包括：实体模型、词典模型、关系模型、数据模型、行为模型以及组件模型；所述实体模型、词典模型、关系模型、数据模型、行为模型以及组件模型分别对应实体视图、词典视图、关系视图、数据视图、行为视图和组件视图；

所述平台相关执行层包括：代码自动生成服务模块、仿真引擎服务模块以及行为驱动引擎服务模块；

所述实体模型用于对实体进行参数化建模，并通过所述实体视图进行表示；

所述词典模型用于描述各个模型内部逻辑及模型之间交互的基本数据类型和复合数据类型，并通过所述词典视图进行表示；

所述关系模型用于描述模型与模型之间的关系，并通过关系视图进行表示；

所述数据模型用于描述实体模型的属性参数值，以此对实体模型进行参数化和实例化，并且通过数据视图进行表示；

所述行为视图用于描述实体模型的动态行为，并通过行为视图进行表示；

所述组件视图用于描述程序功能逻辑，以此实现功能建模，并通过组件视图进行表示；

所述实体模型、词典模型、关系模型、数据模型以及组件模型与所述代码自动生成服务模块进行数据交互，生成代码框架和可执行代码；

所述行为模型与所述行为驱动引擎服务模块进行数据交互，用于在仿真过程中动态参与实体模型行为执行；

所述仿真引擎服务模块用于实现模型之间的数据交互、事件发布、时间管理、模型驱动。

在其中一个实施例中，所述实体视图包括：配置端口、数据端口、服务端口、驱动端口以及状态端口；

所述配置端口用于参数化建模，当读取到所述配置端口的信息时，完成初始化操作；

所述数据端口用于模型之间的数据交互，发送方的所述数据端口定义为主动发送，接收方的所述数据端口定义为异步接收；

所述服务端口为模型之间的远程访问端口，发起方向服务方的服务端口发送服务调用，服务方通过所述服务端口回调服务响应函数；

所述驱动端口用于驱动其他模型的所述回调服务响应函数或模型内存储的回调服务响应函数；

所述状态端口用于获取或者设置实体视图中各个端口的状态。

在其中一个实施例中，所述词典视图用于描述元数据信息，所述元数据的数据类型包括：基本数据类型和引用数据类型；

所述词典视图采用图形化的方式，通过增加字段增加所述元数据的属性，并且各个元数据通过连线确定引用关系。

在其中一个实施例中，所述关系视图包括：组成关系图、继承关系图、实现关系图以及交互关系图。

在其中一个实施例中，所述组成关系图为树形结构；所述交互关系图为网络拓扑结构，网络拓扑结构中实体之间的连线表示实体具备交互关系，连线上的属性为交互内容。

在其中一个实施例中，所述数据视图为表格形式的参数图，其中，同一类型模板实体，在同一个参数图中展示。

在其中一个实施例中，所述组件视图为动态链接库，所述动态链接库中包含多个程序，所述程序用于被外部平台的主程序调用，所述组件视图包括多个API接口。

在其中一个实施例中，所述行为视图通过行为树建模得到，所述行为树的节点包括：合成节点、修饰节点和叶子节点。

在其中一个实施例中，还包括：双向调用的API接口与外部仿真平台进行双向调用，所述系统通过API单项调用平台无关建模层中的模型。

在其中一个实施例中，所述平台无关建模层中各个模型之间的交互协议为Protobuffer协议。

上述多视图平台无关模型系统，能够在平台无关建模阶段，对模型进行全方位描述，提升建模信息量，减少在平台相关建模阶段的程序开发量，减少模型定制工作量。由于增加了行为视图和组件视图，在平台无关阶段对模型动态行为的描述能力大大增强，实现了多种复杂场景下的建模支撑。通过制定标准化的平台建模规范，能够形成一套领域模型资产库，促进模型资源的重用，大大提升仿真行业的经济效益。

附图说明

图1为一个实施例中多视图平台无关模型系统的结构框图；

图2为一个实施例中数据类型的示意图；

图3为一个实施例中树形结构的关系图；

图4为一个实施例中平台无关组件包架构图；

图5为另一个实施例中多视图平台无关模型系统的结构框图；

图6为一个实施例中Protobuffer的使用流程图；

图7为一个实施例中序列化与反序列化处理图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种多视图平台无关模型系统，所述系统包括：平台无关建模层和平台相关执行层；平台无关建模层包括：实体模型、词典模型、关系模型、数据模型、行为模型以及组件模型；实体模型、词典模型、关系模型、数据模型、行为模型以及组件模型分别对应实体视图、词典视图、关系视图、数据视图、行为视图和组件视图；平台相关执行层包括：代码自动生成服务模块、仿真引擎服务模块以及行为驱动引擎服务模块；实体模型用于对实体进行参数化建模，并通过实体视图进行表示；词典模型用于描述各个模型内部逻辑及模型之间交互的基本数据类型和复合数据类型，并通过词典视图进行表示；关系模型用于描述模型与模型之间的关系，并通过关系视图进行表示；数据模型用于描述实体模型的属性参数值，以此对实体模型进行参数化和实例化，并且通过数据视图进行表示；行为视图用于描述实体模型的动态行为，并通过行为视图进行表示；组件视图用于描述程序功能逻辑，以此实现功能建模，并通过组件视图进行表示；实体模型、词典模型、关系模型、数据模型以及组件模型与代码自动生成服务模块进行数据交互，生成代码框架和可执行代码；行为模型与行为驱动引擎服务模块进行数据交互，用于在仿真过程中动态参与实体模型行为执行；仿真引擎服务模块用于实现模型之间的数据交互、事件发布、时间管理、模型驱动。

上述多视图平台无关模型系统，能够在平台无关建模阶段，对模型进行全方位描述，提升建模信息量，减少在平台相关建模阶段的程序开发量，减少模型定制工作量。由于增加了行为视图和组件视图，在平台无关阶段对模型动态行为的描述能力大大增强，实现了多种复杂场景下的建模支撑。通过制定标准化的平台建模规范，能够形成一套领域模型资产库，促进模型资源的重用，大大提升仿真行业的经济效益。

在其中一个实施例中，实体视图包括：配置端口、数据端口、服务端口、驱动端口以及状态端口；配置端口用于参数化建模，当读取到配置端口的信息时，完成初始化操作；数据端口用于模型之间的数据交互，发送方的数据端口定义为主动发送，接收方的数据端口定义为异步接收；服务端口为模型之间的远程访问端口，发起方向服务方的服务端口发送服务调用，服务方通过服务端口回调服务响应函数；驱动端口用于驱动其他模型的回调服务响应函数或模型内存储的回调服务响应函数；状态端口用于获取或者设置实体视图中各个端口的状态。

视图建模成果以XML的形式进行存储，内部描述了基本信息、词典引用信息、端口信息等。

在其中一个实施例中，词典视图用于描述元数据信息，元数据的数据类型包括：基本数据类型和引用数据类型；词典视图采用图形化的方式，通过增加字段增加元数据的属性，并且各个元数据通过连线确定引用关系。

具体的，数据类型的划分如图2所示，词典视图建立采取图形化的方式，通过添加字段增加数据结构属性，通过连线确定引用关系。

在其中一个实施例中，关系视图包括：组成关系图、继承关系图、实现关系图以及交互关系图。

在其中一个实施例中，组成关系图为树形结构；所述交互关系图为网络拓扑结构，网络拓扑结构中实体之间的连线表示实体具备交互关系，连线上的属性为交互内容。

具体的，每一种关系图的建立方式有所区别，组成关系图为例，该关系图为树形结构，如图3所示，交互关系图为网络拓扑结构，连线代表实体之间具备交互关系，连线上的属性为交互内容。

在其中一个实施例中，数据视图为表格形式的参数图，其中，同一类型模板实体，在同一个参数图中展示。

具体的，数据视图说明了详细设计内容，主要为参数图，能够以表格的形式展示模型实体实例的属性，对于同一类模型实体，采取对比的方式展示：

参数图中的上方模型实体实例可自定义类型，继承于实体视图中的某一实体模型，模型左侧的字段为该实体模型的属性端口内的字段值，进行展开编辑及查看。

在其中一个实施例中，组件视图为动态链接库，动态链接库中包含多个程序，程序用于被外部平台的主程序调用，组件视图包括多个API接口。

组件视图以动态链接库的形式存在，单个程序无法运行，必须被外部平台或宿主程序调用，实现其功能。采取“最简化约束”的思想，遵循“Call Me”模式，模型约束及功能暴露为一系列API接口。平台无关组件包架构如图4所示。接口协议无关，可选protobuffer、json、xml、结构体、类成员等多种方式，由平台相关模型进行加壳适配。推荐采取protobuffer作为交互协议标准，同时适配其他协议，提供协议间互转的能力。

在其中一个实施例中，行为视图通过行为树建模得到，行为树的节点包括：合成节点、修饰节点和叶子节点。

具体的，行为树是一个包含逻辑节点和行为节点的树结构，每次需要找出一个行为的时候，会从树的根节点出发，遍历各个节点，找出第一个和当前数据相符合的行为。行为树是由很多类型节点组成的，但是它们都有一些核心的功能，那就是它们都返回三种状态之一，包括Success、Failure、Running。

Composite（合成节点）

合成节点可以有一个或多个子节点。它们处理子节点的顺序可以是从第一个到最后一个，或者某些特定的合成节点的随机顺序，在某一阶段会根据它的子节点的处理结果向它的父节点返回success或者failure，通常这取决于它的子节点的success或者failure。当它在处理子节点时，会向它的父节点持续发送running。

最常用的合成节点是Sequence节点，它按照顺序运行每一个子节点，如果任何一个子节点返回了failure，它返回failure；如果所有子节点返回成功状态，它才返回成功。

Decorator（修饰节点）

修饰节点同合成节点相似，可以拥有子节点，与之不同点在于，它有且只有一个子节点。它的功能就是：将子节点的结果传递给父节点，停止子节点；或者重复执行子节点，这取决于具体的修饰节点类型。

一个常用的修饰节点的用法就是Inverter（反相器），它只是把子节点的结果反相。当它的子节点返回了失败，它给它的父节点返回成功，反之亦反。

Leaf（叶子节点）

它是最底层的节点类型，不能拥有子节点。但叶子节点是最强大的节点类型，因为它在仿真中被定义和实现，来做具体实体的仿真业务实现，让行为树具有真正的业务逻辑操作。

在其中一个实施例中，如图5所示，还包括：双向调用的API接口与外部仿真平台进行双向调用，系统通过API单项调用平台无关建模层中的模型。

具体的，模型建设时，模型实例类内部需要进行数据类局部化引用，减少全局变量，以支持多实例的多线程并发功能。

在其中一个实施例中，平台无关建模层中各个模型之间的交互协议为Protobuffer协议。

以下对本系统设计的主要接口进行说明：

创建及销毁：调用模型工厂创建或销毁模型实例；

赋值取值：通过API接口设置某个值对象或获取某个值对象；

数据值有四种类型：属性值对象、事件值对象、状态值对象、方法参数对象，每种类型的数据均采取相同API进行操作。

功能调用：提供功能调用API用于响应外部激励；

初始化：开始仿真时调用；

单步推进：时间步进或接受驱动时调用；

终止化：仿真结束时调用；

保存现场：保存仿真状态时调用；

恢复现场：恢复仿真状态时调用；

方法调用：远程方法调用；

自测试：实现外部对模型的测试功能；

测试开始：测试开始时调用；

测试终止：测试结束时调用；

其他：其他功能接口；

输出日志：实现模型对外的日志输出。

模型交互协议以Protobuffer协议为基础，该协议的优势是序列化反序列效率高、跨平台跨语言，协议便于管理，能够满足同构及异构系统集成需求。同时，支持协议字段扩展，满足高、中、低多种粒度模型协议定制。Protobuffer的使用流程如图6所示。

序列化与反序列化协议具有其他类型，包括JSON、XML、二进制、结构体等类型，如图7所示。其区别对比如表1所示，在表1中，A-D依次表示易用性、可拓展性、速度、二进制大小、边长数组及字符串、跨平台性以及可读性的好坏，其中A为最好，D为最差。由此可见，ProtoBuffer协议在综合对比中，最为满足模型交互协议需要。

表1协议区别对比

在具体实现时，包括如下步骤：

步骤1：分析建模需求，进行实体视图建立

其具体步骤为：

建立实体描述；

建立实体端口；

步骤2：根据实体视图，进行词典视图建立

其具体步骤为：

建立词典名字空间；

建立数据类型字段；

建立数据类型关联；

步骤3：建立关系视图：

其具体步骤为：

建立组合关系；

建立继承关系；

建立交互关系；

建立实现关系；

步骤4：建立数据视图，填入实体属性数据

步骤5：建立行为视图：

其具体步骤为：

选择行为影响实体；

进行该实体行为树建模；

步骤6：建立组件视图：

其具体步骤为：

进行组件框架声明；

自动生成组件包供下载。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。