CN115857915B

CN115857915B - 面向元宇宙系统开发的物对象数字化方法

Info

Publication number: CN115857915B
Application number: CN202211700522.3A
Authority: CN
Inventors: 齐德昱; 姚凤民; 朱子江
Original assignee: Guangzhou Future Information Technology Research Institute; South China Business College of Guangdong University of Foreign Studies
Current assignee: Guangzhou Future Information Technology Research Institute; South China Business College of Guangdong University of Foreign Studies
Priority date: 2022-12-28
Filing date: 2022-12-28
Publication date: 2024-03-15
Anticipated expiration: 2042-12-28
Also published as: WO2024138785A1; CN115857915A

Abstract

本发明涉及所给出的MOS是一种基于物对象数字化的系统构造的方法，支持通过基于MOS对象基座的动态装配方式将物理世界中与数字化系统相关的包含人、物、仪器设备、数据、软件在内的称为物对象或者泛在对象的物理对象，在数据空间中创建孪生体，以网络模型化方式进行面向集成、增值、互操作与群智协作的融合，构成代表物理系统在数据空间的孪生体。MOS对象基座是一种软件开发与运行支撑环境，可取代当今OS的新一代软件支撑环境，实现应用系统的支撑环境的轻量化与分布化；MOS的软件体系是一种软件即覆盖网SaaN的体系以及对象即系统OaaS的体系，是天然的微服务模型化协同体系。

Description

面向元宇宙系统开发的物对象数字化方法

技术领域

本发明涉及计算机支撑软件领域，尤其是数字化系统的构造的方法与支撑环境与工具以及数字孪生系统与元宇宙系统。

背景技术

信息化技术是在计算机技术推动下发展起来的用电子信息描述与处理现实世界的事务的技术。初级的信息化技术处理的主要管理信息(Management Information)，以至于许多计算机应用系统都是MIS。近年来兴起的数字化的概念，被认为是信息化的升级版。数字化与信息化的最大区别是信息化的范围与程度问题。数字化对事物的信息化从简单的管理信息扩展到全面的数字与数据描述。在数据化中，对象的各个方面都需要数字化--全息数字化，并基于数据进行操作访问。就目前情况而言，元宇宙是信息化或者数字化的最高境界。

元宇宙囊括了经济、政治、文化、科技等各个方面的内容，是进阶版的数字社会。在元宇宙技术下，现实世界中所有事物与事务都基于数字空间存在与进行，无物不虚拟，无虚不现实，虚实全融合，可以理解为目前的基于网络的事务处理系统的升级，其目标是使现实世界的运行高度自动化、智能化、科学化。元宇宙使人类的生存状态由现实世界扩展到数字世界，是人类的一种新的生存形态。因此，发展元宇宙技术与应用，就是发展最新的信息化技术，就是为生活生产实现科学赋能。

元宇宙概念从游戏被扩展到信息化领域后，在科学技术界引发了一场风暴，背景被学术界、工业界推崇，而且得到许多国家的政府的高度重视。在国内，一些发达地区的政府纷纷出台规划或者政策来支持元宇宙技术的研究与应用。

数字孪生与元宇宙系统尽管都是计算机应用系统，但由于它们都是对物理世界的映射，所以，物理对象的数字化就成为关键的基础问题。另一方面，一个物理世界的系统，其本质上就是构成系统的各个物理对象之间的互操作与协同，因此，数字化了的物理对象的互操作与系统模式与支撑方法，就成为另一个关键问题。对这些新问题的解决，传统的软件开发方法及工具在效率与完备性等方面已经不能适应，亟待发展新的方法与工具。

发明内容

一、发明目的

本发明的主要目的是给出一种面向数字化领域的新的软件体系结构与软件构造方法，特别是面向数字孪生系统与元宇宙系统的高效高质量构造。重点获得下列问题的解决：

1)解决传统的软件体系结构不能适应新的数字化系统的问题；

2)解决传统的软件开发方法不适应新的数字化系统开发的问题

3)解决缺乏对构成现实世界系统的基于物对象建模方法；

4)实现低代码软件开发；

5)实现描述型与过程性型结合的软件描述问题。

6)解决应用软件与操作系统分离的问题。

二、发明内容概述

MOS(Meta Object Sochet)方法是一种基于物对象的网络化融合的系统构造方法，将一个系统视为由物对象的基于对象基座的装配式的融合形成的。这里的物对象是指物理世界中的人、物、设备、工具、计算机软件、数据等构成系统的要素，也称泛在对象。

在该方法中，基本的软件成分是MOS对象MUO(MOS Ubiquitous Object)，软件成分的基本操作为MUO融合，融合的模式是多重二部图，融合的控制基于MUO的装配。从效果上讲，MOS是MUO的驱动器，支撑MUO的运行，即运行时；从结构上讲，MOS是MUO的装配平台，相当于母版，支撑板子上的各个部件的交互，因此，MOS也称对象模板、对象插座、对象基座等。

归纳起来，MOS具有下列功用。

■软件体系结构：给出一种新的软件体系结构，以代表子系统服务功能的网络节点为软件成分，以节点的基于二部多重图模式的融合为软件成分之间的交互，是一种网络即软件(NaaS,Netware as a Software)的体系结构。系统构造方式有两种：A)基本系统节点采用装配模式，属于我们的“格件”技术的横向融合技术；B)系统节点的基于二部多重图的纵向扩展，属于“格件”的纵向融合。

■容器视角：MOS是泛在对象容器，将泛在对象进行标准化封装，形成MOS泛在对象，支撑泛在对象的服务化运行，支持用户以对象接口窗户、管道、库表、端口和按钮的形式访问泛在对象。因为MOS上的MUO是服务模式的软件模块，所以，MOS也是(微)服务容器。特别是，如果泛在对象为数据，则MOS为数据对象容器

■智能合约引擎：MOS支持将用户自己的智能合约代码挂接到MOS上，通过事件驱动方式执行，代表用户执行既定功能，包括区块链操作、分布式智能控制等。

■代理视角：MOS是泛在对象的代理，支持用户通过它操作访问泛在对象。这里，泛在对象(UO，Ubiquitous Objects)是指各种可以通过连接接口连接到MOS的对象，包括仪器设备、计算机系统、数据、设施与物品、人员等。

■方法视角：MOS是一种信息化系统构造方法，支持用户基于该方法构造信息系统。

■支撑环境视角：MOS是一种软件开发与运行的支撑环境与工具，包括开发支撑与运行支撑(运行时)。

■组件视角：MOS是一种软件组件，可做为软件成分来构造软件；工作机制是事件和消息驱动的事务处理，访问机制是标准化的软件界面访问。

■交互网关视角：MOS是一种对象交互支撑设施，支持泛在对象之间进行协议化的交互。

■边缘计算视角：MOS可用于实现边缘计算，支持用户将MOS所连接的泛在对象做为用户的边缘计算节点，实现数存储和业务逻辑。

■虚拟机视角：MUO的连接对象可以是基础计算设施中的独立可访问对象，如CPU、存储、IO接口等，讲这些对象的操作访问抽象为MUO，就成为一种新的基础计算设施。

■运行支撑环境：MOS是一种应用软件的轻量级支撑环境，属于运行时，可直接在裸机上运行，无需专门的操作系统支撑，所以，也可以看做的操作系统OS的替代物。

三、物对象数字化基础设施—插座式装配器MOS

物对象(泛在对象)数字化主要内容是实现物对象的基于数字信息的展现、操作访问与交互，或者说是基本物对象的数字孪生。基本物对象的数字孪生的实现基于MOS基础设施。

MOS是一个装配式软插座规范，支持用户将自己的物对象的数字化所需的成分接入插座，并通过灌入装配逻辑，形成物对象的在数字空间的数字孪生体，即MOS对象MUO，支持用户对物对象的数字化操作访问与网络化互操作。

四、MUO的结构与访问接口

基于MOS形成的MUO是物对象在数字空间中的代理，它的与用户的交互界面称为MUO窗户。窗户由多个窗扇组成，而一个窗扇由一个窗口和多个窗扇组成，窗扇是由一个窗口和多个不同窗格复合而成。窗口的组成结构模式为“窗户(窗扇*(窗口，窗格*))”，这里，“*”表示它前面的元素可以多次重复出现。窗格是窗户的最小访问单位，用户对MOS窗户的访问都归结到对窗扇的窗格的访问。窗口是窗扇的与外界的交互通道，由同一窗扇下的各个窗格共用。每个窗扇称为一个MUO对象。

窗格是MUO的最小访问单位，分为按钮、端口、管道、文件表、控制口五种。每一种都是对所属MUO对象的一种访问模式。

按钮代表触动访问，访问种类为按钮的点击或者长按。

端口代表单数据访问，访问种类有读与写，端口中任何时刻每次都只有一条数据可被读取，也每次只有一条数据可注入，下次读取的数据由端口自身的生产逻辑确定。

管道代表队列，访问种类有摘取与添加，它是一个按照既定逻辑生成的先进先出数据序列，摘取队列相当于从队列头部取出一个元素，添加队列相当于给队列尾部增加一个元素。

文件表代表命名的文件索引表，支持通过索引项访问文件视图的数据，即用户通过索引表调出的数据，形式为OS文件，而实际的数据的存储位置、格式等属性，由索引表定义，它的形成是文件表提供者通过提供文件生成器实现。不论具体是什么数据，通过索引表后即被系统自动转化为文件视图。索引表的结构如下：

(文件ID，文件结构ID，文件生成器)

这里，文件生成器是一个软件模块，由窗格提供者提供，用于按照既定的方法获取数据，并以文件形式提供个窗格的访问者。窗格访问者访问索引表，只需提供文件ID即可通过文件提供器获得一个文件形式的数据集以及它的结构信息。

控制口支持外界对象向所属窗扇输入描述性控制指令序列与功能模块，实现对窗扇的功能进行动态配置。

窗扇所属的窗口，是窗扇的与外界进行交互的通道。该通道分为操作通道与交互通道两种，外部对象通过窗格对应的窗口发送窗格访问指令实现对窗格的访问。操作通道用于传达外界到窗格的操作动作，即窗格操作指令，是窗格的操作接口；交互通道支持外界与窗扇的自定义的交互。窗口是通过支持外界与窗扇传递操作指令交互指令来实现操作与交互的。

窗格访问指令有读、写和读后写三种操作。按钮只有写(按键)指令，文件表只有读指令，命令口只有写指令，管道和队列具备全部三种操作。窗格访问指令模式如下：

<按钮访问指令>::＝"ButtonAccess"<ButtonOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<端口访问指令>::＝"PortAccess"<PortOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<管道访问指令>::＝"PipleAccess"<PipleOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<文件表访问指令>::＝"FileindexAccess"<FileindexOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<控制口访问指令>::＝"ControlAccess"<ControlOperID><PanelID><SashID><MosID><dataBuf>[operStat]

ButtonOperID::＝"Write"

PortOperID::＝"Read"|"Write"|"RW"

<PipleOperID>::＝PortOperID

<FileindexOperID>::＝"Read"

<ControlOperID>::＝"Write"

<PanelID><SashID><MosID>::＝所访问的端口定位，三个部分分别是窗格、窗扇与窗户的标识；

[operStat]::＝指令的操作状态，缺省时表示不需要回送操作结果，值为0及正数表示成功，负数为不成功，具体数值表示成功或者不成功的原因或者其他信息，由用户自定义。

<dataBuf>::＝数据存储区。对读操作是存储读出来的数据，对写操作是存放待写入的数据；对于先读后写指令，读出的数据存放在dataBuf尾部；对于按钮，其数值0不是普通点击，数值1表示长按3秒。

五、MOS交互协议

装配式的软件插座MOS与外部对象(含MUO类型的对象以及其他类型的对象，下同)的交互基于抽注协议EIRP(Extract,Injection and Respond Protocol)来进行。外部对象对MUO窗格的操作指令的传递就基于EIRP。EIRP做为操作与交互的命令的描述与传递原语，框定了交互与操作命令的格式与传递规程。

EIRP以电报模式交互，由抽取原语Extract、注入原语Inject和响应原语Respond三种组成。Extract和Inject可以由任何对象发出，但Respond只能由MOS对象接受。EIRP原语的结构如下：

抽取原语::＝"Extract"<operID><fromID><toID><permit>[retryTimes][resMode][parameters]

注入原语::＝"Inject"<operID><fromID><toID><permit>[RetryTimes][resMode][parameters]

响应原语::＝"Respond"<operID><fromID><toID><permit>[resMode][RetryTime][parameters]

这里operID为副指令符，进一步细分原语的种类，由用户自定义；fromID为发出该原语的对象的ID，该对象或者是另外一个MOS或者是支持ERIP协议的其他对象；toID为接受该原语的MOS的标识；同一个命名域内的不同MOS的标识不能重复；fromID和toID的模式为“<PanelID>.<SashID>.<MosID>”，分别表示窗格、窗扇和窗户的标识。Permit为访问的通行证，指出访问者的ID(用户账户)与账户与HASH加密的密码，MOS收到permit后，验证其访问权限，符合的才准予访问；retryTimes为重试次数；表示由于原语执行异常的情况下的原语的最大重执行次数；resMode指出是否需要回送响应数据，如果需要，则该指令成功接受后，系统自动回送一条Respond；Parameters为原语执行需要传递的参数，为JSON格式，具体内容由用户自行确定，在响应原语Respond中，<operID>、<fromID><toID>分别对应于所响应的Extract或者Inject原语中的<operID>、<toID>、<fromID>。

对窗格访问指令，读与读写类型的用Extract原语封装(描述)与传递，写类型的用Inject原语封装(描述)与传递。封装的方法是，用ERIP的副指令符表示窗格指令的指令字，用ERIP的toID表示窗格指令的<PanelID>、<SashID>、<MosID>，三个ID中间用点号“.”分隔。

六、MUO的扩展与融合

这里通过引入MUO网实现物对象的规范化的扩展与融合。MUO网支持由现有的MUO生成具有新功效的MUO。这种方法提供了一种规范化的创建分布式泛在对象协同方法，以支持泛在对象的分布自治、分布管理与分布交互以及虚拟化。

MUO网是一种覆盖网，将多个泛在对象互联起来，形成MUO协同连接，支持泛在对象互操作。下面给出MUO网的定义与规范。

定义1(基本MUO，基座)设MOSb是一个MOS，如果其每个窗扇都不存在对其他MOS的窗扇的访问，则称该窗扇为基本MUO，称MOSb为该MUO的基座。

定义2(MUO合成，MUO单流图)设MUO1,MUO2,…,MUOn是n个不同的基本MUO，它们的基座可以分布在网络上不同位置，MOSk是一个新的MOS或者已存在的MOS，为其设置一个基于对MUO1,MUO2,…,MUOn的操作访问所形成窗扇，则称该窗扇为MUO1,MUO2,…,MUOn的一个合成MUO或者虚拟泛在对象。这种合成关系记为<(MUO1,MUO2,…,MUOn),MUO>，称MOSk为该MUO的基座。称MUO1,MUO2,…,MUOn为所形成的MUO的下联对象。按照上述规则生成的MUO连同它的生成成分一起所成的结构，我们称为MUO单流图。

定义3(扇段，共享)设<(u1,u2,…,un),u>为一个合成关系,且不存在ui对u的访问请求，1≤i≥n,则称<(u1,u2,…,un),u>为一个MUO扇。称<u,ui>为一个扇段，称(u1,u2,…,un)为被u扇入的对象，u为扇出对象,u的扇出数为n。如果ui被m个对象扇入，称ui的扇入数为m。扇入数大于1的MUO称为共享MUO。

定义4(MUO网)一个MUO网是一个扩展的二部多重图G＝(V,E)，它满足下列条件：G是一个图，V是MUO集合，E是“MUO扇段”集合。如果顶点V可划分为n个互不相交的子集序列<V1,V2,…,Vn>，并且,对u∈Vi,v∈Vi,则不存在<u,v>∈E，对任意的u∈Vi,不存在j>i与r∈Vj使<u,r>∈E,也不存在j>i+1与r∈Vj使<r,u>∈E，定义该MUO网的层数为n，定义Vi及其节点的层号为n-i+1.这里i＝1,2,…n。

二部多重图实质上是多个“相邻”的二部图(Bipartite Graph)。每个二部图中的每条边所关联的两个顶点分别属于这两个不同的顶点集。

由于MUO网中的MUO一般都是单流图，流图中任意节点都可以作为MUO网的节点，所以，MUO描述了复杂的共享关系。

定义MUO网的目的是为MOS以及MUO的互联进行规范化限定。二部图描述能力介于无限制的网络与树之间。之所以选择二部多重图为MUO网体系，是我们理论分析获知，将共享关系限制在二部图关系下，大多数共享关系描述不受影响，但资源共享引起的冲突与死锁的概率可大幅度降低，共享性能总体上升。

七、MUO网构造方法

一个MUO网，可以在一个MUO单流图集合OS上，通过逐步增加新的单流图形成。增加新的单流图按照下列两种操作进行：

1)分层(初始化)：将单流图集合OS中的每个单流图，按照既定的策略统一分层，形成一个单流图的分层图；在该图中，每个单流图中每个节点的层号都可能统一位移一个整数值；

2)扩层：按照既定策略，在选定某一层i，在该层中在i层新定义一个MUO，以(i-1)层中的MUO节点为成员；

3)增层：按照既定策略，在分层图的当前最高一层(设为h)上面增加新的1层，在新层中新定义一个MUO，以h层中的MUO节点为成员；

八、MOS基座组成与工作机制

MOS基座是一种运行支撑环境，负责支撑定义在它上面的MUO的运行。

MOS基座主要由收发机构、装配机构与运行支撑机构组成。

运行支撑机构由消息队列、输入队列、输出队列、状态表、事件表、装配表等数据结构以及功能引擎组成，用于支撑其他机构的运行。

收发机构负责与外部对象的通信交互，分为接收器与发送器。接收器监听窗口的消息，如果是合法消息则接收消息，存入消息队列，供消息调度器调度执行。发送器则受消息调度器的调用而向外部对象发送消息；

装配机构主要由消息调度器、状态采集器组成。消息调度器负责解释消息队列中的消息，并基于装配表为其选择相应的执行模块，并挂接到功能引擎进行运行。

装配表用做EIRP原语与窗格指令的处理入口表，结构为(窗户，窗扇、窗格，指令处理器，注入数据指引，抽取数据指引，下一调用对象(窗户，窗扇、窗格))。对ERIP，窗户、窗扇、窗格联合定义了副指令符。每个表项代表一条指令/原语的处理入口。“下一调用对象(窗户，窗扇、窗格)”用于支持多处理入口，即一条指令或者原语，可以通过多个处理入口一次处理。表中的注入数据指引指出处理器执行所需的输入数据的存放位置，抽取数据指引指出处理器执行产生的输出数据的存放位置，下一调用对象(窗户，窗扇、窗格)指出对应的表项的处理器执行完成后需要执行的下一个配置表的表项。

具体实施方案

下面结合实施例对本发明内容及实施方法作进一步的描述，但本发明的实施方式不限于此。

MOS方法中，完整的MOS实现，包括MOS基座(装配式端口MOS的实现式关键)以及交互接口的实现。

MOS的实现，方法可以由多种，如基于Servlet的MOS(称为ServletMOS)、基于AJAX的实现(称为AjaxMOS)，等等。这里给出的实现方法，是MOS的原生态实现，其服务器功能不依赖其他功能。

一、实现所需的主要数据结构

这里阐述实现MOS基座所需的主要数据结构。

(1)内部数据结构

内部数据结构是指只供MOS内部工作使用的数据结构，不支持MOS用户访问。这类数据结构主要包括下列几种。

■消息队列：存放系统的各种待处理的消息，供消息调度器从消息队列中取出消息执行相应的消息处理模块。消息包括网络数据达到消息，网络数据发送消息，用户数据到达(生成)消息，事件发生消息，等等。

■输入队列：存储从网络接收到的服务请求消息，由“接收器”通过输入队列接口访问。

■输出队列：存储消息处理需要发出的服务请求结果(消息)，由“发送器”通过队列的接口取出消息，发送出去。

■消息映射：用于描述各类消息与对应的“消息处理器PIP”的对应关系。消息是指已经发生的事件，消息处理器是一种PIP，用于处理对应的消息。

■数据队列：用于暂存各个未处理的消息的大块数据，包括消息接收到的数据、待发送的数据，等等。

(2)外部数据结构

外部数据结构是指支持MOS用户进行操作访问的数据结构。这类数据结构主要用于对MOS的工作进行配置，主要包括下列几种。

■事件映射：事件是基于系统状态变量的逻辑表达式，该表达式为真时，表示该事件已发生，产生一条事件。事件映射表用于定义事件的发生条件与事件的处理所需的子程序—消息处理器，即事件映射。

■状态变量定义表：定义状态变量与维护它的值的PIP的对应关系。状态变量定义表中基本数据项格式是“变量名，当前值，PIP”，定义了名称为“变量名”的状态变量所对应PIP，并指出当前值为“当前值”。状态变量的值由对应的PIP的执行所确定。

■访问控制表：存放MOS的访问控制信息，包括根用户及其他已注册的用户的账户信息(账户名称，访问口令的Hash值，权限，有效期，优先级，等等)。根用户系统生成时自动生成，要求用户使用后立即更改口令。根用户只有管理其他用户权限(亦即只有使用账户设置指令或者MOS管理器的权限)，无其他权限。其他用户可以由根用户通过MOS管理器设置，或者通过账户设置指令设置。

■配置逻辑：定义MOS的行为与访问控制信息，也包括状态采集策略。其中，MOS行为的描述的MOS的装配逻辑。

所有的数据结构，都设置专门的访问接口，供使用者透明访问。

二、主要代码库

MOS的实现所需的主要代码阐述如下。

■事件检测器：基于状态表检测事件的发生，一旦发生，则生成一条事件发生消息，存入消息队列。

■线程工厂：主要职能是为指定的PIP创建一个线程并启动执行。对性能要求较高的场合可以是以线程方式运行。

■垃圾回收器：主要职能是处理线程执行异常(超时、超存储和线程其他异常)以及其他资源占用异常的情况。对性能要求较高的场合可以是以线程方式运行。

■数据结构操作：各个数据结构的访问与操作接口的实现代码，形式为对象。

上述的均为MOS基所需，下面的发送器为MOS窗户所需。

■发送器：基本功能是具体实现网络数据发送，为API，被调用时，从网络输出队列取出当前输出数据，通过网络发送出去。

三、MOS主要模块实现方法

(1)MOS主程序

MOS启动后进入主程序控制。该程序首先进行必要的初始化工作，然后启动各个MOS运行时线程。

MOS()

{

init()；//初始化各种数据结构

startReceiver()；//如果添加MOS窗户功能，则启动接收器线程

startMessageDispatch()；//启动消息调度器线程

startStatusDetecting()；//启动状态采集器线程

}

(2)接收器

(C)消息调度器

四、MOS界面的实现

(1)基本实现方式

OOA的界面的实现，就是支撑MOS界面的工作。将支撑MOS界面工作的软件称为界面支撑软件。对于基于MOS的泛在对象MUO，MOS界面的支撑软件也是MUO界面的支撑软件。

MOS以服务模式工作，在逻辑上，工作时监听来自用户的访问请求，并调用(调度，消息分发)相应消息处理器PIP进行处理，处理后，生成(生产)回送结果，调用数据发送PIP将所；生产的数据发送(回送)。

MOS的消息监听、消息收发以及消息分发等工作，都是由MOS的基本功能实现的，对所有种类的界面都是一样的。但对不同的界面，消息的解释是不同的，相应的数据的生产与消费也是不同的，从而相应的消息处理器PIP是不同的，因此，MOS的界面的实现，主要工作是由界面提供者按照规范实现对应的消息处理器PIP。

归纳起来，要使MOS界面工作，需要进行下列两个方面的准备工作：

A)消息处理器与方法库：为每个界面准备对应的消息处理器及其所需的方法库的软件模块；其中方法库是支撑消息处理器工作的子程序集；

B)界面消息配置文件：为MUO提供界面消息配置文件。该文件指示每个界面对应的消息处理器的名称与位置。

MOS的配置器将根据上述信息为MOS界面加载相应的消息处理器，以支持MOS界面的工作。

(2)MOS界面支撑实用软件

MOS界面支撑软件主要是MOS的消息处理器PIP，此外还设置一些实用程序，供消息处理器PIP调用。这里给出这些子程序的规范。对于直接使用MOS窗户通信的情况，消息处理器PIP的模型不受这里限制。

至于这些软件的具体的实现，随着MOS的实现的不同而不同，例如，原生态的MOS下的实现与Servlet-MOS就有较大区别。

1)消息处理器PIP

格式：pipRes_界面标识(消息请求者UO，消息内容，…)

功能：为MOS挂件(PIP)，作为支撑MOS界面的消息处理器。消息处理器一般通过调用MOS方法库中的方法实现具体的消息处理。对于基于UOM的通信，还需要通过方法库中的UOM-API读写UOM；

PIP名字以”pipRes_”打头，后接用户自定义的界面标识符。消息内容为JSON格式，不同的界面，具有不同的结构，具体阐述见MOS界面定义。

2)常用实用程序

实用程序用于辅助消息处理器的实现，供消息处理器或者其他模块调用，便于程序实现。

(A)消息发送器

格式：pipReq_界面标识(发送策略)

功能：为方法库成员。该模块被调用时，按照指定的发送策略发送消息。

说明：发送策略主要包括发送目标、发送者、重发次数、待发送数据的位置；

对于原生态MOS，该程序所做的工作是准备发送数据，生成一条发送消息，存入输出队列。对于Servlet-MOS，该程序直接调用Servlet的发送功能发送消息。

(B)消息轮询器

格式：dispatchReq_界面标识(轮询策略)

功能：该模块运行时，按照指定的轮询策略给相应的UO发送请求消息，以激发UO与宿主MOS的消息通信。给UO发送请求消息是通过对pipReq_界面标识()的调用实现的。对于原生态MOS，该程序不需要。

说明：该模块为方法库成员，每调用一次，则执行一次回合的轮询。该模块主要供“轮询控制器”调用。轮询策略的主要内容包括：

轮询对象范围：指出需要轮询的对象；

优先级：指出轮询UO的优先级；

(C)轮询控制器

格式：ctrlDispatch(轮询控制策略)

功能：该模块运行时，一直按照指定的轮询控制策略周期性地调用各个dispatchReq()，直到终止条件成立。

说明：该模块为方法库成员，一般由系统初始化模块或者其他系统模块启动。启动后一直按照设定的周期循环运行，直到轮询控制策略中的终止条件成立。

轮询策略描述控制器的工作模式，主要包括下列几个方面内容：

消息轮询器列表：指出需要调用的“消息轮询器”及其参数；

轮询的频率：支持每隔多少时间进行一消息次轮询器的调用；

优先级：指出消息轮询器被调用的优先级；

对于Servlet-MOS，该模块由Servlet的消息监听器代替；对于原生态MOS，是通过MOS的事件处理器实现，即设置响应的时间处理器与时间发送条件。因此，改模块无需独立提供。

Claims

1.一种数字化系统的体系结构与低代码构造方法，其特征在于，以物对象在数字空间中的孪生体为基本软件构造成分，以孪生体的基于扩展的多重二部图模式的融合为基本成分的操作；物对象的在数据空间的孪生体通过装配式的软件插座MOS创建与支撑；物对象是指物理世界中的人、物、设备、工具、计算机软件、数据等构成系统的要素，也称泛在对象；孪生体的基于扩展二部多重图的融合，形成MOS对象融合网，实现基于协同的对象扩展，做为物理世界中的系统的在数字空间的孪生体；

所述的在装配式软件插座MOS上创建的数字空间孪生体，称其为MOS窗户；MOS窗户的访问界面称为窗扇；一个MOS窗户中可以创建多个不同的窗扇，每个窗扇由一个窗口和若干窗格组成，即结构模式为“窗户(窗扇*(窗口，窗格*))”，这里，“*”表示它标记的元素可以多次重复出现；窗格是窗户的最小访问单位，用户对MOS窗户的访问都归结到对窗扇的窗格的访问；窗口是窗扇的与外界的交互通道，由同一窗扇下的各个窗格共用；每个窗扇称为一个MUO对象；

所述的装配式软件插座MOS，其功能由MOS基座负责实现；MOS基座是一种运行支撑环境，负责支撑定义在它上面的MUO的运行；MOS基座主要由收发机构、装配机构与运行支撑机构组成；运行支撑机构由消息队列、输入队列、输出队列、状态表、事件表、装配表等数据结构以及功能引擎组成；收发机构负责与外部对象的通信交互，分为接收器与发送器；接收器监听窗口的消息，如果是合法消息则接收消息，存入消息队列，供消息调度器调度执行；发送器则受消息调度器的调用而向外部对象发送消息；装配机构主要由消息调度器、状态采集器组成；消息调度器负责解释消息队列中的消息，并基于装配表为其选择相应的执行模块，并挂接到功能引擎进行运行；装配表用做EIRP原语与窗格指令的处理入口表，结构为(窗户，窗扇、窗格，指令处理器，注入数据指引，抽取数据指引，下一调用对象(窗户，窗扇、窗格))；对ERIP，窗户、窗扇、窗格联合定义了副指令符；每个表项代表一条指令/原语的处理入口；“下一调用对象(窗户，窗扇、窗格)”用于支持多处理入口，即一条指令或者原语，可以通过多个处理入口一次处理；表中的注入数据指引指出处理器执行所需的输入数据的存放位置，抽取数据指引指出处理器执行产生的输出数据的存放位置，下一调用对象(窗户，窗扇、窗格)指出对应的表项的处理器执行完成后需要执行的下一个配置表的表项。

2.如权利要求1所述的方法，其中窗格是MUO的最小访问单位，分为按钮、端口、管道、文件表、控制口五种；每一种都是对所属MUO对象的一种访问模式；按钮代表触动访问，访问种类为按钮的点击或者长按；端口代表单数据访问，访问种类有读与写，端口中任何时刻每次都只有一条数据可被读取，也每次只有一条数据可注入，下次读取的数据由端口自身的生产逻辑确定；管道代表队列，访问种类有摘取与添加，它是一个按照既定逻辑生成的先进先出数据序列，摘取队列相当于从队列头部取出一个元素，添加队列相当于给队列尾部增加一个元素；文件表代表命名的文件索引表；索引表的结构为(文件ID，文件结构ID，文件生成器)，索引表的每一项代表一个文件形式的数据集，它的形成是文件表提供者通过提供文件生成器实现；控制口支持外界对象向所属窗扇输入描述性控制指令序列与功能模块，对窗扇的功能进行动态配置。

3.如权利要求2所述的方法，外部对象对窗格访问，是通过窗格访问指令进行；窗格访问指令有读、写和读后写三种操作；按钮只有写(按键)指令，文件表只有读指令，命令口只有写指令，管道和队列具备全部三种操作；窗格访问指令模式如下：

ButtonOperID::＝"Write"

PortOperID::＝"Read"|"Write"|"RW"

<PipleOperID>::＝PortOperID

<FileindexOperID>::＝"Read"

<ControlOperID>::＝"Write"

[operStat]::＝指令的操作状态，缺省时表示不需要回送操作结果，值为0及正数表示成功，负数为不成功，具体数值表示成功或者不成功的原因或者其他信息，由用户自定义；

<dataBuf>::＝数据存储区；对读操作是存储读出来的数据，对写操作是存放待写入的数据；对于先读后写指令，读出的数据存放在dataBuf尾部；对于按钮，其数值0不是普通点击，数值1表示长按3秒。

4.如权利要求3所述的方法，所述装配式软件插座MOS的与外部对象的交互以及所述窗格访问指令的传递，均基于抽注协议EIRP(Extract,Injection and Respond Protocol)进行；EIRP做为操作与交互的命令的描述与传递原语，框定了交互与操作命令的格式与传递规程；EIRP以电报模式交互，由抽取原语Extract、注入原语Inject和响应原语Respond三种组成；Extract和Inject可以由任何对象发出，但Respond只能由MOS对象接受；EIRP原语的结构如下：

这里operID为副指令符，进一步细分原语的种类，由用户自定义；fromID为发出该原语的对象的ID，该对象或者是另外一个MOS或者是支持ERIP协议的其他对象；toID为接受该原语的MOS的标识；同一个命名域内的不同MOS的标识不能重复；fromID和toID的模式为“<PanelID>.<SashID>.<MosID>”，分别表示窗格、窗扇和窗户的标识；Permit为访问的通行证，指出访问者的ID(用户账户)与账户与HASH加密的密码，MOS收到permit后，验证其访问权限，符合的才准予访问；retryTimes为重试次数；表示由于原语执行异常的情况下的原语的最大重执行次数；resMode指出是否需要回送响应数据，如果需要，则该指令成功接受后，系统自动回送一条Respond；Parameters为原语执行需要传递的参数，为JSON格式，具体内容由用户自行确定，在响应原语Respond中，<operID>、<fromID><toID>分别对应于所响应的Extract或者Inject原语中的<operID>、<toID>、<fromID>；对窗格访问指令，读与读写类型的用Extract原语封装(描述)与传递，写类型的用Inject原语封装(描述)与传递；封装的方法是，用ERIP的副指令符表示窗格指令的指令字，用ERIP的toID表示窗格指令的<PanelID>、<SashID>、<MosID>，三个ID中间用点号“.”分隔。

5.如权利要求1所述的方法，MOS对象融合网，称为MUO网，其结构与规则如下：

1)设MOSb是一个MOS，如果其每个窗扇都不存在对其他MOS的窗扇的访问，则称该窗扇为基本MUO，称MOSb为该MUO的基座；

2)设MUO1,MUO2,…,MUOn是n个不同的基本MUO，它们的基座可以分布在网络上不同位置，MOSk是一个新的MOS或者已存在的MOS，为其设置一个基于对MUO1,MUO2,…,MUOn的操作访问所形成窗扇，则称该窗扇为MUO1,MUO2,…,MUOn的一个合成MUO或者虚拟泛在对象；这种合成关系记为<(MUO1,MUO2,…,MUOn),MUO>，称MOSk为该MUO的基座；称MUO1,MUO2,…,MUOn为所形成的MUO的下联对象；按照上述规则生成的MUO连同它的生成成分一起所成的结构，我们称为MUO单流图；

3)设<(u1,u2,…,un),u>为一个合成关系,且不存在ui对u的访问请求，1≤i≥n,则称<(u1,u2,…,un),u>为一个MUO扇；称<u,ui>为一个扇段，称(u1,u2,…,un)为被u扇入的对象，u为扇出对象,u的扇出数为n；如果ui被m个对象扇入，称ui的扇入数为m；扇入数大于1的MUO称为共享MUO；

4)一个MUO网是一个扩展的二部多重图G＝(V,E)，它满足下列条件：G是一个图，V是MUO集合，E是“MUO扇段”集合；如果顶点V可划分为n个互不相交的子集序列<V1,V2,…,Vn>，并且,对u∈Vi,v∈Vi,则不存在<u,v>∈E，对任意的u∈Vi,不存在j>i与r∈Vj使<u,r>∈E,也不存在j>i+1与r∈Vj使<r,u>∈E，定义该MUO网的层数为n，定义Vi及其节点的层号为n-i+1.这里i＝1,2,…n。

6.如权利要求5所述的方法，MUO对象融合网，其构造是在一个MUO单流图集合OS上通过逐步增加新的单流图进行；增加新的单流图按照下列操作进行：

2)扩层：按照既定策略，在选定某一层i，在该层中按照权利要求5的规则，在i层新定义一个MUO，以(i-1)层中的MUO节点为成员；

3)增层：按照既定策略，在分层图的当前最高一层(设为h)上面增加新的1层，在新层中按照权利要求5的规则，新定义一个MUO，以h层中的MUO节点为成员。