CN114707429A - 基于ear的可执行建模方法、装置、计算机设备和介质 - Google Patents

Abstract

本申请属于建模仿真领域，涉及基于EAR的可执行建模方法、装置、计算机设备和介质，方法包括：获取建模场景，根据EAR概念建模语言建立实例关系图、架构属性图和实体活动图；根据架构属性图，得到模型架构节点和实例架构节点，生成模型树视图；根据架构属性图，得到顶层静态状态；根据架构属性图和实体活动图，得到影响发生关系、状态关系和服务关系，并生成模型端口视图和协议树视图；根据实例关系图和实体活动图，生成实例交互视图；根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。采用本方法能够将EAR视图转换为IOCM视图，从而支持可执行建模。

Description

基于EAR的可执行建模方法、装置、计算机设备和介质

技术领域

本申请涉及系统建模与仿真技术领域，特别是涉及基于EAR的可执行建模方法、装置、计算机设备和介质。

背景技术

建模与仿真已经服务于战略、战术、战法、训练、试验、分析、辅助决策等众多研究领域，而且应用范围还在不断扩展，研究层次也在不断深入。

系统建模按照实现的粒度和认知的深度可以逐步进行螺旋式迭代，在建模的初期可以称之为概念建模。要使概念建模的成果即概念模型能够运行，需要研究概念模型的可执行技术，概念模型可执行技术主要有代码自动生成和模型转换两种方式。

模型转换技术主要由概念模型转换为另一个类型的可执行建模成果，如可执行模型体系框架、由规则引擎驱动的规则集等，从而实现概念模型的可执行。在从概念模型到可执行模型的转换上，现有技术已积累了较为丰富的方法及成果。

但是，由于模型转换前是静态模型，缺少对输入输出数据和时序关系的描述，在生成可执行模型过程中，需要人工干预的因素较多，且模型转换规则复杂，有的模型转换后难以验证时序关系、体系结构状态转移等功能和性能关系，无法对体系结构进行完整描述；而且由于动态行为的刻画目前以活动图、时序图和状态机图为主，包含大量与可执行无关的冗余信息，在向可执行模型转换时，需要进行动态视图的融合，转换后的可执行模型如DEVS、Petri网等往往较为复杂，不易可视化管理和维护。

发明内容

基于此，有必要针对上述技术问题，提供基于EAR的可执行建模方法，能够将EAR视图转换为IOCM视图，从而支持可执行建模。

基于EAR的可执行建模方法，包括：

获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

在其中一个实施例中，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图包括：

根据建模场景包含的实体实例以及实体实例之间的关系，得到底层的实体实例以及顶层的活动类型，建立实例关系图。

在其中一个实施例中，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图还包括：

根据建模场景中包含的实体模型名称、实体模型属性和实体模型实例，建立实体架构属性图；

根据建模场景中包含的活动模型名称、活动模型属性和活动模型实例，建立活动架构属性图；

根据实体架构属性图和活动架构属性图，得到架构属性图。

在其中一个实施例中，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图还包括：

根据建模场景中包含的实体与活动的关系、活动与活动的关系、实体与属性的关系以及活动与属性的关系，得到实体节点、活动节点、属性节点、影响发生关系、状态关系和服务关系，建立实体活动图。

在其中一个实施例中，根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构包括：

根据模型树视图和模型端口视图，生成模型基本信息；根据实例交互视图，生成实例及连线信息；根据协议树视图，生成协议信息；

根据模型基本信息、实例及连线信息以及协议信息，构建可执行的IOCM模型架构。

在其中一个实施例中，根据模型基本信息、实例及连线信息以及协议信息，构建可执行的IOCM模型架构包括：

根据模型基本信息、实例及连线信息以及协议信息，生成IOCM工程文件；根据IOCM工程文件，构建可执行的IOCM模型架构。

在其中一个实施例中，所述IOCM模型架构实现数据流、服务流、驱动流和状态流的信息交互。

基于EAR的可执行建模装置，包括：

获取模块，用于获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

模型树视图生成模块，用于对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

模型端口视图生成模块，用于根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

实例交互视图生成模块，用于对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

协议树视图生成模块，用于分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

建模模块，用于根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序；

一种计算机可读存储介质，其上存储有计算机程序；

所述处理器执行所述计算机程序时，以及所述计算机程序被处理器执行时，实现以下步骤：

获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

上述基于EAR的可执行建模方法、装置、计算机设备和介质，采用可执行模型转换方式，根据EAR视图体系的实例关系图、架构属性图和实体活动图转换为IOCM视图体系的模型树视图、模型端口视图、实例交互视图和协议树视图，将多个模型结合后转换为可执行模型体系框架，将形式化与可执行化完美结合，不但降低了顶层体系结构开发风险，同时提升了模型转换的自动化程度，减少了领域专家工作量。转换后的视图提供可视化管理和维护，便于进一步分析、融合、冗余去除。另外，应用此方法开发的可执行模型可以在特定软件中转换为C++、Java、Python等编程语言，转换为系统的仿真软件，也可输入ISIM仿真引擎驱动仿真。该建模方法为领域无关建模技术，该技术及系统能够在体系仿真、系统仿真等领域得到广泛应用，发挥社会和经济价值。

附图说明

图1为一个实施例中基于EAR的可执行建模方法的流程示意图；

图2为一个实施例中EAR视图的分类示意图；

图3为一个实施例中实例关系图的视图元模型图；

图4为一个实施例中架构属性图的视图元模型图；

图5为一个实施例中架构属性图的属性标注图；

图6为一个实施例中实体活动图的视图元模型图；

图7为一个实施例中实体与活动的组合关系示意图；

图8为一个实施例中EAR视图的关系示意图；

图9为一个实施例中基于IOCM的模型接口架构图；

图10为一个实施例中IOCM的模型架构图；

图11为一个实施例中IOCM模型的信息交互图；

图12为一个实施例中工程文件的信息图；

图13为一个实施例中IOCM视图体系与工程文件的映射关系图；

图14为一个实施例中模型树视图的视图元模型图；

图15为一个实施例中模型端口视图的视图元模型图；

图16为一个实施例中实例交互视图的视图元模型图；

图17为一个实施例中协议树视图的视图元模型图；

图18为一个实施例中两种视图体系的映射关系图；

图19为一个实施例中IOCM视图体系的转换流程图；

图20为一个实施例中模型树视图的转换生成图；

图21为一个实施例中架构属性图；

图22为一个实施例中实体活动图；

图23为一个实施例中转换的模型交互图之一；

图24为一个实施例中转换的模型交互图之二；

图25为一个实施例中模型端口视图的转换生成图；

图26为一个实施例中消息端口的关系要素图；

图27为一个实施例中实例交互视图的转换生成图；

图28为一个实施例中协议树视图的转换生成图；

图29为一个具体实施例中实例关系图；

图30为一个具体实施例中实体架构属性图；

图31为一个具体实施例中活动架构属性图；

图32为一个具体实施例中实体活动图的活动模板图；

图33为一个具体实施例中实体活动图的活动实现图之一；

图34为一个具体实施例中实体活动图的活动实现图之二；

图35为一个具体实施例中实体活动图的活动实现图之三；

图36为一个具体实施例中实体活动图的活动实现图之四；

图37为一个具体实施例中实体活动图的活动实现图之五；

图38为一个具体实施例中模型树视图转换生成图；

图39为一个具体实施例中实例交互视图转换生成图；

图40为一个实施例中基于EAR的可执行建模装置的结构框图；

图41为一个实施例中计算机设备的内部结构图。

具体实施方式

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

如图1所示，本申请提供的一种基于EAR的可执行建模方法，在一个实施例中，包括以下步骤：

步骤102，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图。

EAR概念建模语言是一种现有技术，通过建立实例关系图、架构属性图和实体活动图，就完成了EAR视图体系的建立。

步骤104，对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图。

步骤106，根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图。

步骤108，对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图。

步骤110，分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图。

步骤112，根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

在本步骤中，IOCM模型架构是可执行的模型体系框架，代表建模成功，后续按照现有技术添加逻辑规则和运算规则后就可以直接进行仿真。

本方法基于EAR概念建模语言，采取模型转换的方法，建立基于IOCM的可执行模型体系框架。

系统仿真：根据系统分析的目的，在分析系统各要素性质及其相互关系的基础上，建立能描述系统结构或行为过程的、且具有一定逻辑关系或数量关系的仿真模型，据此进行试验或定量分析，以获得正确决策所需的各种信息。

行为模型：是一种对于行为规律或行为方案描述的形式化成果，描述的内容包括行为的类型、架构、依赖、流程与约束等。这通常是对实际行为的简化描述，包括一定程度的抽象。

仿真模型：通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件。

实体：现实世界中实际存在的个体，具备一定的物质属性，能够在一定的时间范围内稳定存在。

活动：对于行为的概念抽象，具有临时性、持续性等特点，活动能够接受实体状态的输入并影响实体的状态。

元素：是对建模对象的描述，包括实体元素和活动元素两种类型。

要素：图的主要组成元素，包括节点、连线、标签等。

架构：是支持元素与元素之间的“特化-泛化”关系，简称为“继承”关系。

属性：是对元素的数值描述，属性的不同决定了元素的不同类型。

建模粒度：主观世界里对客观世界在运行机理方面的抽象程度，如动力学模型有三自由度模型和六自由度模型，两种模型的内部处理粒度不同，三自由度模型的建模粒度更粗。

建模分辨率：主观世界里对客观世界在实体分辨方面的抽象程度，如飞机的建模中，可以把飞机作为一个整体去描述，也可以将飞机描述为机身、发动机、机翼等零部件的有机组成，后者的建模分辨率更高。

PDU:协议数据单元（Proto Data Unit），用于实现模型之间交互的语义一致性而共同约束的交互“语言”，包括组合PDU和原子PDU，如经度是原子PDU，位置包括经度、纬度和高度，为组合PDU。

本申请提出了一种基于EAR的可执行模型体系框架生成方法，能够面向体系/系统顶层体系结构建模，采取EAR的建模方式构建概念模型，并实现概念模型向可执行模型体系转换，生成IOCM可执行模型体系框架。基于此框架，补充模型实现逻辑规则后，即可输入仿真引擎进行执行并输出仿真结果，支撑概念模型的设计、分析和论证。

EAR为国产化概念建模语言。EAR简化了视图种类、建模要素和视图之间的关系，提供了领域无关的顶层设计语言，便于实现轻量化的体系/系统概念建模。基于EAR的概念建模方法是模型转换的基础背景。

如图2所示，EAR视图类型主要分为静态视图和动态视图两大类，静态视图主要有实例关系图、实体架构属性图和活动架构属性图，动态视图主要为实体活动图。

实例关系图：约束场景内需要模拟的实体实例和实体实例之间的关系，为后续视图建模提供顶层输入。视图元模型如图3所示。

架构属性图：约束架构节点（包括实体和活动）的继承关系和属性组成关系，架构节点属性包括状态属性、事件属性、服务属性等。视图元模型如图4所示。架构节点包括实体节点和活动节点，并进一步形成实体架构属性图和活动架构属性图。

状态属性：描述架构节点的静态和动态状态。静态状态为架构节点的初始化配置信息，代表着参数化模型，通过改变配置属性值，能够对架构节点的能力等参数进行描述，为静态属性。动态状态在仿真中能够不断进行更新，为动态属性。状态可同时具备静态和动态属性，代表仿真初始化数值和随时间推进的变化值。

事件属性：描述架构节点具备的瞬时事件信息，事件发生时将发送事件发生消息，组成结构包括事件名称和事件参数，为动态属性。事件属性区分为输入事件和输出事件两种类型，输入事件为外部触发生成的事件，输出事件为自身生成的事件，与外部事件无关。

服务属性：描述服务申请者提供的属性包，内部包括成对出现的输入服务属性和输出服务属性，为动态属性。服务属性只有一种类型，即服务申请属性。

为了在架构属性图中区分不同的架构元素，采取上标的方式为属性节点进行属性标注，约定标注图形含义如图5所示。

实体活动图：约束实体和活动的组合关系，包括实体、属性和活动之间的交互和连接，形成实体活动图。视图元模型如图6所示。

影响发生关系为实体或活动事件对于实体或活动事件的影响生成关系，具体生成时机和规则由实体或活动内部控制，该关系只是表明来源事件对于目标事件的影响能力；状态关系为实体属性与活动之间的关系，表示活动具备获取或更新该状态属性的能力；服务关系为输入和输出关系的组合，属性组成了参数包，提供即时的服务申请及返回能力。关系连接的来源节点和目的节点的类型映射关系如下表1：

表1关系连接的来源节点和目的节点的类型映射关系

实体活动图支持嵌套组合，实现模型的可组合可重用。

以机动活动为例，实体与活动的组合关系如图7所示。其中，方框为输入参数或输出参数标签，能够通过连线属性进行设置，可以进行隐藏或显示。

EAR视图的关系如图8所示。

基于EAR的概念建模流程，也就是根据EAR概念建模语言对建模场景建立实例关系图、架构属性图和实体活动图的步骤为：

步骤一：确定场景，建立实例关系图

1.参与场景的实体实例，确定底层实体实例

2.实体实例之间的关系，确定顶层活动类型

步骤二：确定实体架构及属性，建立实体架构属性图

1.实体模型名称及继承关系

2.实体模型属性字段、属性值，即实体模型属性

3.实体模型实例名称（图4中的架构节点名称）、属性值，即实体模型实例

步骤三：确定活动架构及属性，建立活动架构属性图

1.活动模型名称及继承关系

2.活动模型属性字段、属性值，即活动模型属性

3.活动实例名称、属性值，即活动模型实例

步骤四：确定实体活动关系，建立实体活动图

1.活动与活动、实体与活动、属性与实体关系

2.反向更新架构属性图中的实体、实体属性及活动、活动属性

其中，步骤二、三与步骤四不是严格的串行关系，而是一个整体螺旋迭代上升的过程，并行丰富和升级架构属性图和实体活动图。具体流程如下：

在建立实例关系图时，需要建立实例及实例之间关系，至于如何建立实例节点及实例间关系以形成实例关系图，属于现有技术，在此不再赘述。

在建立实体架构属性图和活动架构属性图时，其具体的步骤是：

构建十字形双树图形结构的拓扑图；十字形双树图形结构的拓扑图满足纵向树方向规则、防遮蔽自动排布规则和节点迁移规则；十字形双树图形结构包括纵向树和横向树；纵向树和横向树均包含多个叶子节点；接收建模任务信息；解析建模任务信息，得到建模场景、建模对象实例、属性字段和数据类型枚举属性；根据纵向树方向规则、防遮蔽自动排布规则和节点迁移规则将建模场景、建模对象实例、属性字段和数据类型枚举属性分别写入纵向树和横向树，得到架构树和属性树；架构树表示建模场景；架构树的叶子节点表示建模对象实例；属性树表示属性字段；属性树的叶子节点表示数据类型枚举属性；根据属性字段继承规则、属性值继承规则、同名属性融合规则以及同父属性融合规则对架构树和属性树进行建模，得到架构-属性图。

其中，“十字形双树图形结构”为一种横向、纵向均为树形结构的拓扑图，其中纵向为一个树，横向由纵向的树节点发散出多个树，横向、纵向树形结构中的每个节点均能够进行收起、展开，便于在整体设计时隐藏局部细节，控制人机交互视觉输入的信息量和复杂度。

建模对象实例包括实体和活动两种类型。将建模任务信息解析得到的信息按照预先设置的规则写入纵向树和横向树中构建架构树和属性树。属性字段是实体属性的元数据，如飞机的长度、重量、油量等，都属于属性字段，具体的550米、50kg、50升等属于属性值。数据类型枚举属性即数据类型，包括整形、双精度、文本型、枚举型、布尔型等，如车辆总装厂的状态如果是枚举型，那么具备准备工作中、工作中、工作结束等枚举状态。

架构是指支持建模对象实例之间的“特化-泛化”关系，简称为“继承”关系。属性是对建模对象实例的数值描述，属性的不同决定了建模对象实例的不同类型。将建模任务信息解析得到的信息按照预先设置的规则写入纵向树和横向树中，利用根据规则写入建模场景、建模对象实例、属性字段和数据类型枚举属性后的纵向树和横向树作为架构树和属性树。纵向树方向规则用于将纵向树和横向树自动调整为符合人机交互视觉的图形，便于建模。防遮蔽自动排布规则用于将横向树结构展示完整的同时提升可读性和节点，迁移规则使得专家能够采用拖拽的方式，调整图形拓扑结构，利用纵向树方向规则、防遮蔽自动排布规则和节点迁移规则将建模任务信息写入纵向树和横向树中，得到架构树和属性树。

按照属性字段继承规则、属性值继承规则、同名属性融合规则以及同父属性融合规则对架构树和属性树进行建模，得到架构-属性图，架构-属性图是对描述对象架构和属性数据结构的综合性视图，其中描述对象架构中主要刻画继承关系，属性数据结构中主要刻画组合关系，架构-属性图包括实体架构-属性图和活动架构-属性图两种类型。实体是客观存在的个体，实体在较长时间范围内存在，实体架构-属性图是对实体继承关系和描述的刻画。活动是人类认知抽象，对于行为的描述，具有临时生成销毁的特性，活动架构-属性图是对实体参与的活动行为继承关系和描述的刻画。根据实体，建立实体架构树和实体属性树，根据活动，建立活动架构树和活动属性树，然后分别结合架构-属性图，可以得到实体架构-属性图和活动架构-属性图。

“架构-属性图”中“架构”采用纵向树的形式表示，属性字段采用横向树的形式表示，架构图中的叶子节点为场景里建模的原子粒度、最小单元，是建模对象实例，属性树的叶子节点均为属性字段的节点，具有数据类型枚举属性。属性值采用树表的形式表示，实体架构中的叶子节点的属性值均需要有完整配置信息，不可空缺，以描述建模场景的初始状态，活动架构图中活动属性由于每次活动开始时配置的不同，活动叶子节点可有空缺的属性值。架构-属性图具备属性继承规则，能够提取架构中的各级元素中的共性信息，减少重复描述度，便于领域专家设计建模和新元素扩展。元素是指建模对象实例，包括实体和活动。属性字段和属性值是一一对应的关系，如飞机的“飞行距离”是属性字段，飞机的飞行距离是1000km，其中1000km是属性值。

在建立实体活动图时，具体的步骤是：

根据建模任务，建立逻辑行为的实体活动图；实体活动图的基本要素包括节点、节点标签、连线和布局要素；实体活动图的类型包括活动模板图和活动实现图。

根据实体活动图的基本要素，对活动模板进行建模，得到第一节点架构属性图、第一节点标签架构属性图、第一连线架构属性图和第一布局要素架构属性图。根据实体活动图的基本要素，对活动实现进行建模，得到第二节点架构属性图、第二节点标签架构属性图、第二连线架构属性图和第二布局要素架构属性图。根据第一节点架构属性图、第一节点标签架构属性图、第一连线架构属性图、第一布局要素架构属性图、第二节点架构属性图、第二节点标签架构属性图、第二连线架构属性图和第二布局要素架构属性图，对建模任务的逻辑行为进行建模，得到实体活动图。

其中，节点是组成实体活动图最基本的要素，能够代表实体、活动、属性的类型或实例，具备多种节点类型。节点包括：引用节点、常值节点、实体节点、属性节点、活动节点、非活动节点和接口节点。所述活动节点包括：组合活动和原子活动；所述原子活动包括：控制活动、判断活动、变值活动、延时活动和同步活动。

节点标签是对节点的系统化、离散化描述，一个节点可附加多种标签，其中数据类型标签暂时不支持集合操作和Map映射对象操作，简化数据类型描述。节点标签包括：接口标签、名称标签、描述标签、活动触发标签、默认标签、属性类型标签、数据类型标签和作用范围标签。

连线描述节点与节点之间的关系，具备多种连线类型。连线包括：引用连线、控制连线、数据连线、赋值连线、组合连线和实例连线。控制连线包括：触发连线、暂停连线、停止连线和继续连线。节点与节点之间的关系包括：实体与活动的关系、活动与活动的关系、实体与属性的关系以及活动与属性的关系等，具体的关系类型包括：影响发生关系、状态关系和服务关系等。

布局要素是便于提升人机交互性引入的辅助元素。布局要素包括：组合框、分割线和注释框。

在基本要素的基础上，建立活动模板图和活动实现图，并得到实体活动图。

活动模板图：活动模板图是实体活动图的一种，主要描述对象是节点要素的类型，如飞机、车辆等。活动模板图在建模中具备接口节点，由于具备接口，因此能够在建模过程中实现与其他模型的组合，从而实现模板复用。

活动实现图：活动实现图是实体活动图的一种，主要描述对象是节点要素的实例，也就是具体的类型，如一架飞机1、一架飞机2等。活动实现图没有对外的接口节点，能够运用活动模板图进行组合模型复用，并传入具体的模型实例，实现实体活动图建模。

IOCM（Interface Oriented Composable Modeling，面向接口可组合建模技术）为国产化可执行模型体系规范，能够直接支持代码开发和编辑，直接运行或通过仿真引擎驱动，实现模型体系的可执行。该模型体系支持多种端口类型、灵活定制协议，丰富的模型驱动机制和时间管理机制，支持类发布订阅、实例发布订阅等多种发布订阅方式。

基于IOCM的模型接口架构如图9所示。引擎为模型提供API也就是接口，模型与模型之间通过PDU也就是交互语言进行通信。

ISIM仿真引擎为模型功能实现提供了标准化API，能够实现基于时间的模型驱动和五类端口的数据交互功能，包括配置端口、消息端口、服务端口、状态端口和驱动端口。模型之间的交互协议采取PDU数据协议单元（Proto Data Unit）的方式进行交互，实现不同领域的协议定制和交互。

IOCM模型架构如图10所示。

配置端口：包括配置输入和配置输出端口两种类型，用于仿真模型初始化，实现配置和模型实现分离。一般情况下，由于仿真的初始化工作由仿真平台进行，因此模型一般只具备配置输入端口。

消息端口：包括消息输入和消息输出端口两种类型，用于进行实时数据交互，数据为发送端主动推送，接收端被动触发接收。

服务端口：包括服务输入端口和服务输出端口两种类型，用于中断式远程方法调用，数据包括申请数据与回复数据。

驱动端口：包括驱动输入端口和驱动输出端口，用于实现触发式工作流，按照一定逻辑驱动运行。

状态端口：包括状态输入端口和状态输出端口，用于获取模型状态，数据为主动拉取式获取，拉取的数据为异步数据。

基于IOCM模型可实现四种类型的模型信息交互，如图11所示。其中：

A和B分别代表一种模型，数据流是指：模型间的数据交互流；服务流是指：模型间的服务调用与服务处理流；驱动流是指：模型间的驱动控制流；状态流是指：模型间的状态获取及设置流。

IOCM模型体系由IOCM模型体系框架及IOCM模型实现组成。IOCM模型体系框架描述了模型体系中模型的类型、端口、端口协议、参数值等信息；IOCM模型实现为基于IOCM模型框架所开发的可执行程序，或模型组合实现，可执行程序包括动态库、可执行程序、脚本等，是实现原子底层逻辑可执行的基础，组合实现是通过模型组合的方式进行模型关系和逻辑组合。IOCM模型体系框架的结构化描述方式为XML，生成的描述文件为ISIM仿真引擎的输入文件即工程文件，该文件主要包括的信息如图12所示。

模型基本信息：描述模型的框架信息以及实现信息，框架信息包括模型的名称、端口的类型，绑定的协议，是否为组合模型，如果是组合模型包括其组合实现信息，即子模型的组成和相互关系。如果模型具备配置端口，则拥有配置信息，描述该模型的参数化情况。

实例及连线信息：描述仿真场景内的模型实例信息和模型实例相互之间的交互信息，包括模型实例的名称和数量，模型实例的模型类型、模型实例的参数化配置信息，以及模型实例之间的端口交互关系。

协议信息：是IOCM模型之间交互的“语言”，为模型之间信息交换的基础。主要包括协议内信息包（PDU）的名称、描述、类型、内部组成等，组合协议类型描述了PDU与PDU的组合关系。

从EAR向IOCM转换，即生成模型体系工程文件的过程，由于本发明主要是生成可执行模型体系框架，不涉及模型原子和组合实现，无需生成可执行程序和组合模型的信息，因此具体表现是EAR视图体系与IOCM视图体系之间的转换，包括：参与仿真的IOCM模型和IOCM实例、IOCM模型的端口、IOCM实例关系、IOCM模型与平台和模型之间交互的PDU类型，实现了基于EAR概念建模信息向IOCM可执行模型体系框架的自动转换，也就是EAR视图体系向IOCM视图体系的转换。EAR视图体系是面向人的视图体系，基于人对任务和环境的解读生成，IOCM视图体系是面对计算机的视图体系，能够直接被计算机解读。

通过对IOCM工程文件的逆向分析，可得到IOCM视图体系及与工程文件的映射关系如图13所示。

模型树视图：以树状视图描述模型的组成结构，包括分类和模型两种元素，模型均为叶子节点，视图元模型如图14所示。

模型端口视图：描述单个IOCM模型的端口组成，包括端口的名称、类型。视图元模型如图15所示。

实例交互视图：描述场景中的实体和活动实例种类、数量和相互之间的交互关系，包括实例信息和交互信息。视图元模型如图16所示。

协议树视图：以协议树的方式描述交互的顶层数据单元及其子数据单元名称与类型，视图元模型如图17所示。数据单元名称包括顶层数据单元名称和子数据单元名称，数据单元类型包括顶层数据单元类型和子数据单元类型。

由于EAR向IOCM的转换为自动转换，领域专家无需人工添加领域信息，因此在转换过程中不会有新的领域信息加入，两种视图体系的视图映射关系如图18所示。

IOCM视图体系转换生成流程如图19所示。

下面，分别对不同视图的转换方法和过程进行描述。

1、模型树视图转换生成

由EAR架构属性图转换生成。架构属性图中的实体和活动构成了模型树视图中根分类，叶子模型构成了模型树中的IOCM模型，其余节点均转换为模型树中的分类。

节点命名规则：分类节点和模型节点的名称均保持非叶子模型架构节点和叶子模型架构节点原有名称不变。

模型树视图转换生成过程如图20所示。

2、模型端口视图转换生成

由EAR架构属性图和实体活动图转换生成。架构属性图中，叶子模型的顶层静态状态属性组成了该叶子模型的配置端口，实体活动图中，描述的是架构模型之间的关系，而架构模型包括模型、模型实例等，因此需要首先根据架构模型的继承关系，将分类模型关系转换为叶子模型关系，即模型交互图，再进行模型端口视图转换生成。

实体活动图中的模型实例均替换为该模型实例的父模型，即叶子模型，实体活动图中的非叶子模型均替换为该模型下的叶子模型，由于同一父类的叶子模型可能有多个，替换后由一张实体活动图将生成多张模型交互图。

如以车辆机动场景为例，架构属性图如图21所示，实体活动图如图22所示，转换为的模型交互图如图23和图24所示，端口生成的映射转换关系即模型端口视图转换生成如图25所示。

配置端口直接复制于该模型的顶层静态状态属性，端口名称为“配置”，端口类型名称为配置输入端口。

消息端口由该模型的影响发生关系生成，关系要素如图26所示。状态端口和服务端口也有“关系要素”，与图26一致。

影响发生关系的来源事件属性所属模型为输出消息端口，端口名称为目的模型名称，目的事件属性所属模型为输入消息端口，端口名称同样为来源模型名称。

状态端口、服务端口的生成规则与消息端口类似，只是在模型交互图中的关系为状态关系和服务关系。

3、实例交互视图转换生成

由实例关系图、架构属性图和实体活动图转换生成。已生成模型端口视图的基础上，采取端口匹配映射的方式，实体实例与活动之间的关系为实体活动图中的端口关系集合。

实例交互视图转换生成过程如图27所示。

4、协议树视图转换生成

由架构属性图转换生成，先生成不同端口的顶层PDU，再根据架构属性图中的组合关系，将顶层PDU分解为原子数据类型。一条模型交互关系对应一个顶层PDU。映射关系即协议树视图转换生成过程如图28所示。

顶层PDU的命名规则可以自动为系统设定名称，避免人工取名，具体的命名规则为：

配置顶层PDU为模型名称+“配置”

消息顶层PDU为模型名称+“事件”

状态顶层PDU为来源模型名称+“-”+目的模型名称

服务顶层PDU为来源模型名称+“-”+目的模型名称

顶层PDU由子PDU组成，子PDU的内容由架构属性图中的属性结构和实体活动图中交互的属性确定，与原有属性保持名称和类型相同。

应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个具体的实施例中，以简单的运输场景仿真建模为例，展示基于EAR概念建模成果向IOCM可执行模型体系转换的过程，说明本技术发明的具体应用。

以自然语言描述的仿真场景为：

本体：

车辆是一种实体

车辆是能够在陆地上行动的移动的载体

运输车是一种车辆

运输车最大能承载50人，油量最大是30升

人能够坐在运输车内去想去的地方

一个人上运输车会消耗10分钟时间

一个人下运输车会消耗5分钟时间

上下运输车是逐个衔接的过程

运输车的空载行驶速度是60km每小时

运输车每重100kg，速度会下降10km

每个人的体重是80kg

运输车重量5000kg

运输车每小时消耗油量是10L

运输车每行驶100km故障的概率是10%

运输车故障后维修成功的时间是30分钟

运输车没油了加满油的时间是10分钟

运输过程是人员先上运输车，运输车运动，到达目的地后，人员下运输车

想定：从营区出发80人，乘坐运输车到达目的地，路从营区到目的地100km，有两辆车，每辆车开始的油量是20升，每车40人

输入：乘车人数

输出：运输时间、消耗油量

针对以上场景，忽略加油站距离等因素，采用EAR图形化建模语言建模成果如下：

实例关系图如图29所示，实体架构属性图如图30所示，活动架构属性图如图31所示，实体活动图如图32至图37所示。

首先，进行模型树视图转换生成，如图38所示。

其次，进行模型端口视图转换生成，展示端口信息矩阵如表2所示。

表2模型端口视图转换生成的端口信息矩阵

再次，进行实例交互视图转换生成，如图39所示。节点交互矩阵如表3所示。

表3实例交互视图转换生成的节点交互矩阵

最后，进行协议树视图转换生成，如表4至表6所示。

表4协议树视图之一

表5协议树视图之二

表6协议树视图之三

如图40所示，在一个实施例中，提供了一种基于EAR的可执行建模装置，包括：获取模块4002、模型树视图生成模块4004、模型端口视图生成模块4006、实例交互视图生成模块4008、协议树视图生成模块4010和建模模块4012，其中：

获取模块4002用于获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

模型树视图生成模块4004用于对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

模型端口视图生成模块4006用于根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

实例交互视图生成模块4008用于对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

协议树视图生成模块4010用于分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

建模模块4012用于根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

关于基于EAR的可执行建模装置的具体限定可以参见上文中对于基于EAR的可执行建模方法的限定，在此不再赘述。上述装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图41所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于EAR的可执行建模方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。该计算机设备可以是仿真设备，输入装置将相关的信息输入给仿真设备，处理器执行存储器中的程序进行组合仿真，显示屏显示相关的仿真结果。

本领域技术人员可以理解，图41中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行计算机程序时实现上述实施例中方法的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述实施例中方法的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（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）等。

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

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

Claims (10)

1.基于EAR的可执行建模方法，其特征在于，包括：

获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

2.根据权利要求1所述的方法，其特征在于，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图包括：

根据建模场景包含的实体实例以及实体实例之间的关系，得到底层的实体实例以及顶层的活动类型，建立实例关系图。

3.根据权利要求2所述的方法，其特征在于，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图还包括：

根据建模场景中包含的实体模型名称、实体模型属性和实体模型实例，建立实体架构属性图；

根据建模场景中包含的活动模型名称、活动模型属性和活动模型实例，建立活动架构属性图；

根据实体架构属性图和活动架构属性图，得到架构属性图。

4.根据权利要求3所述的方法，其特征在于，获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图还包括：

根据建模场景中包含的实体与活动的关系、活动与活动的关系、实体与属性的关系以及活动与属性的关系，得到实体节点、活动节点、属性节点、影响发生关系、状态关系和服务关系，建立实体活动图。

5.根据权利要求1至4任一项所述的方法，其特征在于，根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构包括：

根据模型树视图和模型端口视图，生成模型基本信息；根据实例交互视图，生成实例及连线信息；根据协议树视图，生成协议信息；

根据模型基本信息、实例及连线信息以及协议信息，构建可执行的IOCM模型架构。

6.根据权利要求5所述的方法，其特征在于，根据模型基本信息、实例及连线信息以及协议信息，构建可执行的IOCM模型架构包括：

根据模型基本信息、实例及连线信息以及协议信息，生成IOCM工程文件；根据IOCM工程文件，构建可执行的IOCM模型架构。

7.根据权利要求1至4任一项所述的方法，其特征在于，所述IOCM模型架构实现数据流、服务流、驱动流和状态流的信息交互。

8.基于EAR的可执行建模装置，其特征在于，包括：

获取模块，用于获取建模场景，根据EAR概念建模语言对所述建模场景建立实例关系图、架构属性图和实体活动图；

模型树视图生成模块，用于对所述架构属性图的架构节点进行分类，得到模型架构节点和实例架构节点；分别以模型架构节点和实例架构节点为分类节点和模型节点，生成模型树视图；

模型端口视图生成模块，用于根据架构属性图生成叶子模型架构节点，对所述叶子模型架构节点添加属性，得到顶层静态状态；根据架构属性图和实体活动图生成模型交互图，对所述模型交互图进行分类，得到影响发生关系、状态关系和服务关系；分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置端口、消息端口、状态端口和服务端口，生成模型端口视图；

实例交互视图生成模块，用于对所述实例关系图进行分类，得到实例节点和实例关系；根据所述实体活动图，得到关系；分别以实例节点、实例关系和关系为实体模型、活动模型和交互关系，生成实例交互视图；

协议树视图生成模块，用于分别以顶层静态状态、影响发生关系、状态关系和服务关系为配置顶层PDU、消息顶层PDU、状态顶层PDU和服务顶层PDU，生成协议树视图；

建模模块，用于根据模型树视图、模型端口视图、实例交互视图和协议树视图，构建可执行的IOCM模型架构。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images