WO2024138785A1 - Thing object digitization method for metaverse system development - Google Patents

Abstract

The present invention relates to a provided MOS being a system construction method based on thing object digitization. The method supports creating, by means of dynamic assembly based on an MOS object base, twins in a data space for physical objects in a physical world that are related to a digital system, wherein said physical objects include people, things, instruments and equipment, data, and software and are called thing objects or ubiquitous objects, and performing, by means of network modeling, fusion oriented towards integration, value addition, inter-operation and crowd cooperation, and thus forming twins representing a physical system in the data space. The MOS object base is a software development and operation supporting environment, and can replace the new generation of software supporting environments of the present OS and realizes a lightweight and distributed supporting environment for an application system. The software architecture of MOS is a software-as-a-coverage network (SaaN) system and an object-as-a-system (OaaS) system, and is a natural micro-service modeling collaboration system.

Description

Object digitization method for metaverse system development Technical Field

The present invention relates to the field of computer support software, and in particular to methods for constructing digital systems, supporting environments and tools, as well as digital twin systems and metaverse systems.

Background technique

Information technology is a technology developed under the promotion of computer technology that uses electronic information to describe and process real-world affairs. Primary information technology mainly processes management information (Management Information), so many computer application systems are MIS. The concept of digitization that has emerged in recent years is considered to be an upgraded version of informatization. The biggest difference between digitization and informatization is the scope and degree of informatization. Digitalization extends the informatization of things from simple management information to comprehensive digital and data descriptions. In dataization, all aspects of the object need to be digitized-holographic digitization, and operations and access are based on data. As far as the current situation is concerned, the metaverse is the highest level of informatization or digitization.

The metaverse encompasses all aspects of economy, politics, culture, science and technology, and is an advanced version of the digital society. Under the metaverse technology, all things and affairs in the real world exist and are carried out based on digital space. Everything is virtual, everything is real, and the virtual and the real are fully integrated. It can be understood as an upgrade of the current network-based transaction processing system, and its goal is to make the operation of the real world highly automated, intelligent, and scientific. The metaverse expands the human survival state from the real world to the digital world, and is a new form of human survival. Therefore, the development of metaverse technology and applications is to develop the latest information technology, which is to enable scientific empowerment for life and production.

After the concept of the metaverse was expanded from games to the field of information technology, it caused a storm in the scientific and technological community. It was highly praised by the academic and industrial circles and received great attention from the governments of many countries. In China, governments in some developed regions have introduced plans or policies to support the research and application of metaverse technology.

Although both digital twins and metaverse systems are computer application systems, since they are both mappings of the physical world, the digitization of physical objects becomes a key basic issue. On the other hand, a system in the physical world is essentially the interoperability and collaboration between the various physical objects that constitute the system. Therefore, the interoperability of digitized physical objects and the system model and support methods become another key issue. Traditional software development methods and tools are no longer able to adapt to the solution of these new problems in terms of efficiency and completeness, and new methods and tools are urgently needed.

Summary of the invention

1. Purpose of the Invention

The main purpose of this invention is to provide a new software architecture and software construction method for the digital field, especially for the efficient and high-quality construction of digital twin systems and metaverse systems. The focus is on solving the following problems:

1) Solve the problem that traditional software architecture cannot adapt to new digital systems;

2) Solve the problem that traditional software development methods are not suitable for the development of new digital systems

3) Address the lack of object-based modeling methods for real-world systems;

4) Enable low-code software development;

5) Implement software description problem that combines descriptive and procedural types.

6) Solve the problem of separation of application software and operating system.

II. Summary of the Invention

The MOS (Meta Object Sochet) method is a system construction method based on the networked fusion of objects, which regards a system as formed by the assembled fusion of objects based on the object base. Objects here refer to the elements that constitute the system, such as people, objects, equipment, tools, computer software, and data in the physical world, also known as ubiquitous objects.

In this method, the basic software component is the MOS object MUO (MOS Ubiquitous Object), the basic operation of the software component is MUO fusion, the fusion mode is a multi-bipartite graph, and the fusion control is based on the assembly of MUO. In terms of effect, MOS is the driver of MUO, supporting the operation of MUO, that is, the runtime; in terms of structure, MOS is the assembly platform of MUO, equivalent to the motherboard, supporting the interaction of various components on the board, so MOS is also called object template, object socket, object base, etc.

In summary, MOS has the following functions.

■Software architecture: A new software architecture is proposed, which takes network nodes representing subsystem service functions as software components and the fusion of nodes based on bipartite multigraph mode as the interaction between software components. It is a network as software (NaaS, Netware as a Software) architecture. There are two ways to construct the system: A) The basic system nodes adopt the assembly mode, which belongs to the horizontal fusion technology of our "lattice" technology; B) The vertical expansion of system nodes based on bipartite multigraph belongs to the vertical fusion of "lattice".

■Container perspective: MOS is a ubiquitous object container, which encapsulates ubiquitous objects in a standardized manner to form MOS ubiquitous objects, supports the service-oriented operation of ubiquitous objects, and supports users to access ubiquitous objects in the form of object interface windows, pipes, library tables, ports, and buttons. Because MUO on MOS is a software module in service mode, MOS is also a (micro) service container. In particular, if the ubiquitous object is data, MOS is a data object container.

■Smart Contract Engine: MOS supports attaching the user’s own smart contract code to MOS, which is executed in an event-driven manner to perform established functions on behalf of the user, including blockchain operations, distributed intelligent control, etc.

■Agent perspective: MOS is the agent of ubiquitous objects, supporting users to access ubiquitous objects through its operations. Here, ubiquitous objects (UO) refer to various objects that can be connected to MOS through connection interfaces, including instruments and equipment, computer systems, data, facilities and objects, personnel, etc.

■Method perspective: MOS is an information system construction method that supports users to construct information systems based on this method.

■Support environment perspective: MOS is a support environment and tool for software development and operation, including development support and operation support (runtime).

■Component perspective: MOS is a software component that can be used as a software component to construct software; the working mechanism is event and message-driven transaction processing, and the access mechanism is standardized software interface access.

■Interaction gateway perspective: MOS is an object interaction support facility that supports protocolized interaction between ubiquitous objects.

■Edge computing perspective: MOS can be used to implement edge computing, supporting users to use ubiquitous objects connected to MOS as their edge computing nodes to implement data storage and business logic.

■ From the perspective of virtual machines: MUO’s connection objects can be independent accessible objects in the basic computing facilities, such as CPU, storage, IO interface, etc. By abstracting the operation access of these objects as MUO, it becomes a new basic computing facility.

■Operation support environment: MOS is a lightweight support environment for application software. It belongs to the runtime and can be run directly on the bare metal without the need for special operating system support. Therefore, it can also be regarded as a substitute for the operating system OS.

3. Object Digital Infrastructure - Socket Assembler MOS

The main content of the digitization of objects (ubiquitous objects) is to realize the display, operation access and interaction of objects based on digital information, or the digital twin of basic objects. The realization of the digital twin of basic objects is based on the MOS infrastructure.

MOS is an assembled soft socket specification that supports users to connect the components required for the digitization of their own objects to the socket, and by injecting assembly logic, form a digital twin of the object in the digital space, namely the MOS object MUO, which supports users' digital operation access and networked interoperability of the object.

4. MUO Structure and Access Interface

MUO formed based on MOS is the agent of physical objects in digital space, and its interactive interface with users is called MUO window. A window is composed of multiple sashes, and a sash is composed of a window and multiple sashes, and a sash is composed of a window and multiple different panes. The composition structure pattern of a window is "window (sash*(window, pane*))", where "*" means that the element in front of it can be repeated multiple times. The pane is the smallest access unit of the window, and the user's access to the MOS window is attributed to the access to the pane of the sash. The window is the interaction channel between the sash and the outside world, and is shared by all the panes under the same sash. Each sash is called a MUO object.

A pane is the smallest access unit of MUO, which is divided into five types: button, port, pipe, file table, and control port. Each type is an access mode to the MUO object.

Button represents touch access, and the access type is a click or a long press of the button.

A port represents single data access. The access types are read and write. At any time, only one piece of data can be read from the port at a time, and only one piece of data can be injected at a time. The next data to be read is determined by the port's own production logic.

The pipe represents a queue. The access types are extraction and addition. It is a first-in-first-out data sequence generated according to a given logic. Extracting a queue is equivalent to taking an element from the head of the queue, and adding a queue is equivalent to adding an element to the tail of the queue.

The file table represents a named file index table, which supports access to the data of the file view through index items, that is, the data called out by the user through the index table in the form of an OS file, and the storage location, format and other attributes of the actual data are defined by the index table, which is formed by the file table provider by providing a file generator. No matter what the specific data is, it will be automatically converted into a file view by the system after passing through the index table. The structure of the index table is as follows:

(File ID, File Structure ID, File Generator)

Here, the file generator is a software module provided by the pane provider, which is used to obtain data according to the established method and provide it to the visitors of each pane in the form of a file. The pane visitor accesses the index table and can obtain a data set in the form of a file and its structure information through the file provider by simply providing the file ID.

The control port supports external objects to input descriptive control instruction sequences and functional modules to the window sashes, thereby realizing dynamic configuration of the functions of the window sashes.

The window to which the sash belongs is the channel for the sash to interact with the outside world. This channel is divided into two types: operation channel and interaction channel. External objects access the pane by sending pane access instructions through the window corresponding to the pane. The operation channel is used to convey the operation actions from the outside world to the pane, that is, the pane operation instructions, which is the operation interface of the pane; the interaction channel supports the customized interaction between the outside world and the sash. The window realizes operation and interaction by supporting the outside world to transmit operation instructions and interaction instructions to the sash.

The pane access instructions have three operations: read, write, and read-then-write. Buttons only have write (key press) instructions, file tables only have read instructions, command ports only have write instructions, and pipes and queues have all three operations. The pane access instruction modes are as follows:

<Button Access Command>::="ButtonAccess"<ButtonOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<Port Access Command>::="PortAccess"<PortOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<Pipeline Access Command>::＝"PipleAccess"<PipleOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<File table access command>::="FileindexAccess"<FileindexOperID><PanelID><SashID><MosID><dataBuf>[operStat]

<Control port access command>::="ControlAccess"<ControlOperID><PanelID><SashID><MosID><dataBuf>[operStat]

ButtonOperID::＝"Write"

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

<PipleOperID>::＝PortOperID

<FileindexOperID>::＝"Read"

<ControlOperID>::＝"Write"

<PanelID><SashID><MosID>::＝The port location being accessed, the three parts are the identification of the pane, sash and window respectively;

[operStat]::＝The operation status of the instruction. By default, it means that no operation result needs to be returned. A value of 0 or a positive number indicates success, and a negative number indicates failure. The specific value indicates the reason for success or failure or other information, which is defined by the user.

<dataBuf>::＝data storage area. For read operation, it stores the read data, and for write operation, it stores the data to be written. For read-before-write instructions, the read data is stored at the end of dataBuf. For buttons, a value of 0 is not a normal click, and a value of 1 means a long press for 3 seconds.

5. MOS Interaction Protocol

The interaction between the assembled software socket MOS and external objects (including MUO type objects and other types of objects, the same below) is based on the Extract, Injection and Respond Protocol (EIRP). The transmission of operation instructions from external objects to MUO panes is based on EIRP. As the description and transmission primitive of operation and interaction commands, EIRP defines the format and transmission procedures of interaction and operation commands.

EIRP interacts in telegram mode and consists of three primitives: Extract, Inject, and Respond. Extract and Inject can be sent by any object, but Respond can only be received by MOS objects. The structure of the EIRP primitive is as follows:

Extract primitive::="Extract"<operID><fromID><toID><permit>[retryTimes][resMode][parameters]

Injection primitive::="Inject"<operID><fromID><toID><permit>[RetryTimes][resMode][parameters]

Response primitive::="Respond"<operID><fromID><toID><permit>[resMode][RetryTime][parameters]

Here, operID is a sub-instructor, which further subdivides the type of primitive and is customized by the user; fromID is the ID of the object that issues the primitive, which is either another MOS or other object that supports the ERIP protocol; toID is the identifier of the MOS that receives the primitive; the identifiers of different MOSs in the same naming domain cannot be repeated; the pattern of fromID and toID is "<PanelID>.<SashID>.<MosID>", which represent the identifiers of panes, sashes and windows respectively. Permit is the access pass, indicating the visitor's ID (user account) and the account and HASH-encrypted password. After receiving permit, MOS verifies the access rights and grants access only if they meet the requirements. retryTimes is the number of retries, which indicates the maximum number of re-executions of the primitive due to primitive execution exceptions. resMode indicates whether response data needs to be sent back. If so, the system automatically sends back a Respond after the instruction is successfully accepted. Parameters are the parameters that need to be passed for primitive execution, in JSON format. The specific content is determined by the user. In the response primitive Respond, <operID>, <fromID> and <toID> correspond to the <operID>, <toID> and <fromID> in the responded Extract or Inject primitive, respectively.

For pane access instructions, read and read-write types are encapsulated (described) and transferred using the Extract primitive, and write types are encapsulated (described) and transferred using the Inject primitive. The encapsulation method is to use the ERIP sub-instruction symbol to represent the instruction word of the pane instruction, and to use ERIP toID to represent the <PanelID>, <SashID>, <MosID> of the pane instruction, and the three IDs are separated by a period ".".

6. Expansion and Integration of MUO

Here, the standardized extension and integration of objects is realized by introducing MUO network. MUO network supports the generation of MUO with new functions from existing MUO. This method provides a standardized method for creating distributed ubiquitous object collaboration to support the distributed autonomy, distributed management, distributed interaction and virtualization of ubiquitous objects. See Figure 2.

MUO network is an overlay network that interconnects multiple ubiquitous objects to form MUO collaborative connections and support ubiquitous object interoperability. The following is the definition and specification of MUO network.

Definition 1 (Basic MUO, Base) Let MOSb be a MOS. If each of its sashes does not have access to the sashes of other MOSs, then the sash is called a basic MUO and MOSb is called the base of the MUO.

Definition 2 (MUO synthesis, MUO single-flow graph) Let MUO1, MUO2, …, MUOn be n different basic MUOs, whose bases can be distributed in different locations on the network, and MOSk be a new MOS or an existing MOS. Set a window sash for it based on the operation access to MUO1, MUO2, …, MUOn. The window sash is called a synthetic MUO or virtual ubiquitous object of MUO1, MUO2, …, MUOn. This synthetic relationship is recorded as <(MUO1, MUO2, …, MUOn), MUO>, and MOSk is called the base of the MUO. MUO1, MUO2, …, MUOn are called the lower-link objects of the formed MUO. The structure formed by the MUO generated according to the above rules together with its generated components is called the MUO single-flow graph.

Definition 3 (sector, sharing) Let <(u1,u2,…,un),u> be a composite relation, and there is no access request from ui to u, 1≤i≥n, then <(u1,u2,…,un),u> is called a MUO fan. <u,ui> is called a sector, (u1,u2,…,un) is called the object fanned in by u, u is the fan-out object, and the fan-out number of u is n. If ui is fanned in by m objects, the fan-in number of ui is m. A MUO with a fan-in number greater than 1 is called a shared MUO.

Definition 4 (MUO network) A MUO network is an extended bipartite multigraph G = (V, E) that satisfies the following conditions: G is a graph, V is a MUO set, and E is a set of "MUO sectors". If the vertex V can be divided into a sequence of n mutually disjoint subsets <V1, V2, ..., Vn>, and for u∈Vi, v∈Vi, there does not exist <u, v>∈E, and for any u∈Vi, there does not exist j>i and r∈Vj such that <u, r>∈E, nor does there exist j>i+1 and r∈Vj such that <r, u>∈E, then the number of layers of the MUO network is defined as n, and the layer number of Vi and its nodes is defined as n-i+1. Here i = 1, 2, ...n.

A bipartite multigraph is essentially a number of "adjacent" bipartite graphs. The two vertices associated with each edge in each bipartite graph belong to two different vertex sets.

Since the MUOs in a MUO network are generally single-flow graphs, any node in the flow graph can be used as a node of the MUO network, so MUO describes a complex sharing relationship.

The purpose of defining MUO network is to standardize the interconnection of MOS and MUO. The description capability of bipartite graph is between that of unrestricted network and tree. The reason why we choose bipartite multigraph as MUO network system is that we know from theoretical analysis that if the sharing relationship is restricted to bipartite graph relationship, most of the sharing relationship description will not be affected, but the probability of conflict and deadlock caused by resource sharing can be greatly reduced, and the overall sharing performance will be improved.

7. MUO network construction method

A MUO network can be formed by gradually adding new single-flow graphs on a MUO single-flow graph set OS. Adding a new single-flow graph is done by the following two operations:

1) Layering (initialization): Each single-flow graph in the single-flow graph set OS is uniformly layered according to the established strategy to form a layered graph of single-flow graphs; in this graph, the layer number of each node in each single-flow graph may be uniformly shifted by an integer value;

2) Layer expansion: According to the established strategy, a layer i is selected, and in the layer i, according to the rules of claim 7, a new OUO is defined, with the OUO nodes in the (i-1) layer as members;

3) Adding a layer: According to the established strategy, a new layer is added above the current highest layer (set as h) of the hierarchical graph. In the new layer, according to the rules of claim 7, a new OUO is defined, with the OUO nodes in the h layer as members;

8. MOS base composition and working mechanism

The MOS base is an operation support environment responsible for supporting the operation of the MUO defined on it.

The MOS base is mainly composed of a transceiver mechanism, an assembly mechanism and an operation support mechanism.

The operation support mechanism is composed of data structures such as message queue, input queue, output queue, state table, event table, assembly table and function engine, which is used to support the operation of other mechanisms.

The transceiver mechanism is responsible for communication and interaction with external objects, and is divided into a receiver and a transmitter. The receiver monitors the messages in the window, and if it is a legitimate message, it receives the message and stores it in the message queue for the message scheduler to schedule and execute. The transmitter is called by the message scheduler to send messages to external objects;

The assembly mechanism is mainly composed of a message scheduler and a state collector. The message scheduler is responsible for interpreting the messages in the message queue, selecting the corresponding execution module for it based on the assembly table, and hooking it up to the function engine for operation.

The assembly table is used as the processing entry table for EIRP primitives and pane instructions, and its structure is (window, sash, pane, instruction processor, injection data guide, extraction data guide, next call object (window, sash, pane)). For ERIP, windows, sashes, and panes jointly define sub-instruction symbols. Each table entry represents the processing entry of an instruction/primitive. "Next call object (window, sash, pane)" is used to support multiple processing entries, that is, an instruction or primitive can be processed at one time through multiple processing entries. The injection data guide in the table indicates the storage location of the input data required for the processor execution, the extraction data guide indicates the storage location of the output data generated by the processor execution, and the next call object (window, sash, pane) indicates the table entry of the next configuration table that needs to be executed after the processor of the corresponding table entry is executed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a diagram of the architecture of the MOS base and the MUO network system;

Specific implementation plan

The content and implementation methods of the present invention are further described below in conjunction with embodiments, but the implementation methods of the present invention are not limited thereto.

In the MOS method, the complete MOS implementation includes the MOS base (the key to the implementation of the assembled port MOS) and the implementation of the interactive interface.

There are many ways to implement MOS, such as Servlet-based MOS (called ServletMOS), AJAX-based implementation (called AjaxMOS), etc. The implementation method given here is the original ecological implementation of MOS, and its server function does not depend on other functions.

1. Implement the main data structures required

Here we explain the main data structures required to implement the MOS base.

(1) Internal data structure

Internal data structures are data structures that are only used for internal work within MOS and are not accessible to MOS users. This type of data structure mainly includes the following types.

■Message queue: stores various pending messages of the system, and allows the message scheduler to retrieve messages from the message queue and execute corresponding message processing modules. Messages include network data arrival messages, network data sending messages, user data arrival (generation) messages, event occurrence messages, etc.

■Input queue: stores service request messages received from the network and is accessed by the "receiver" through the input queue interface.

■Output queue: stores the service request results (messages) required for message processing. The "sender" takes out the message through the queue interface and sends it out.

■Message mapping: used to describe the correspondence between various messages and the corresponding "message processor PIP". A message refers to an event that has occurred, and a message processor is a PIP used to process the corresponding message.

■Data queue: used to temporarily store large blocks of data for each unprocessed message, including data received by the message, data to be sent, and so on.

(2) External data structure

External data structures refer to data structures that support MOS users to access operations. This type of data structure is mainly used to configure MOS work, mainly including the following types.

■Event mapping: An event is a logical expression based on the system state variables. When the expression is true, it means that the event has occurred and an event is generated. The event mapping table is used to define the event occurrence conditions and the subroutine required for event processing - the message processor, that is, event mapping.

■State variable definition table: defines the correspondence between state variables and the PIPs that maintain their values. The basic data item format in the state variable definition table is "variable name, current value, PIP". It defines the PIP corresponding to the state variable named "variable name" and indicates that the current value is "current value". The value of the state variable is determined by the execution of the corresponding PIP.

■Access Control Table: Stores MOS access control information, including the account information of the root user and other registered users (account name, access password hash value, permissions, validity period, priority, etc.). The root user is automatically generated when the system is generated, and the user is required to change the password immediately after use. The root user only has the authority to manage other users (that is, only the authority to use the account setting command or MOS Manager), and no other permissions. Other users can be set by the root user through the MOS Manager or through the account setting command.

■Configuration logic: defines the behavior and access control information of MOS, including the state collection strategy. Among them, the MOS assembly logic of the description of MOS behavior.

All data structures have dedicated access interfaces for transparent access by users.

2. Main code base

The main codes required for the implementation of MOS are described below.

■Event detector: Detects the occurrence of events based on the state table. Once an event occurs, an event occurrence message is generated and stored in the message queue.

■Thread Factory: The main function is to create a thread for a specified PIP and start execution. It can be run in thread mode for situations with high performance requirements.

■ Garbage collector: Its main function is to handle thread execution exceptions (timeout, overstorage, and other thread exceptions) and other resource usage exceptions. It can be run in thread mode for situations with high performance requirements.

■Data structure operation: the implementation code of the access and operation interface of each data structure, in the form of objects.

The above are all required for MOS base, and the transmitter below is required for MOS window.

■Sender: The basic function is to implement network data sending. It is an API. When called, it takes out the current output data from the network output queue and sends it out through the network.

3. MOS main module implementation method

(1) MOS main program

After MOS is started, it enters the main program control. The program first performs necessary initialization work and then starts each MOS runtime thread.

MOS()

{

init(); //Initialize various data structures

startReceiver(); //If you add the MOS window function, start the receiver thread

startMessageDispatch(); //Start the message dispatcher thread

startStatusDetecting(); //Start the status collector thread

}

(2) Receiver

receiverMOS()

{

while()

{

msgBus = recervMsg(); //Receive data to the message buffer indicated by msgBus;

msg = parserMOSMsg (msgBus); // parse the message and store it in the area indicated by msg;

flag = firewallMOS(msg); //Verify whether the message is in the "blacklist"

if(!flag)

{//The message is not in the "blacklist"

msgQueue.pushMsg(msg); //Store the message in the message queue msgQueue

}

}//while

}//receiverMOS()

(C) Message Scheduler

messageDispatch()

{

while()

{

msgBus = msgQueue.getItem(scheduling policy); //Select a message from the message queue according to the specified scheduling policy;

flag＝startPIP(msgBus,msgDef); //Based on the current message msgBus and the message mapping table msgDef, determine the message processor PIP corresponding to the message, and then generate a new thread to execute the PIP;

flag = eventDef.eventDetect (msgDef); //Based on the event mapping table eventDef, detect whether a new event occurs. If so, process it to generate an event message and add it to the message queue.

PIPThreadMng(); //Detect the PIP thread and start the corresponding processing thread to handle it if an exception is found;

}//while

}//messageDispatch()

4. Implementation of MOS interface

(1) Basic implementation method

The realization of OOA interface is to support the work of MOS interface. The software that supports the work of MOS interface is called interface support software. For MOS-based ubiquitous object MUO, the support software of MOS interface is also the support software of MUO interface.

MOS works in service mode. Logically, it listens to access requests from users and calls (scheduling, message distribution) the corresponding message processor PIP for processing. After processing, it generates (produces) the feedback result and calls the data sending PIP to send (echo) the produced data.

MOS's message monitoring, message sending and receiving, and message distribution are all implemented by MOS's basic functions, which are the same for all types of interfaces. However, for different interfaces, the interpretation of messages is different, and the corresponding data production and consumption are also different, so the corresponding message processors PIP are different. Therefore, the implementation of MOS's interface mainly requires the interface provider to implement the corresponding message processor PIP according to the specification.

In summary, to make the MOS interface work, the following two aspects of preparation are required:

A) Message Processor and Method Library: A software module that prepares a corresponding message processor and its required method library for each interface; wherein the method library is a set of subprograms that support the work of the message processor;

B) Interface message configuration file: Provides an interface message configuration file for MUO. This file indicates the name and location of the message handler corresponding to each interface.

The MOS configurator will load the corresponding message processor for the MOS interface according to the above information to support the work of the MOS interface.

(2) MOS interface support utility software

The MOS interface support software is mainly the MOS message processor PIP. In addition, some utility programs are set up for the message processor PIP to call. The specifications of these subroutines are given here. For the case of directly using MOS window communication, the model of the message processor PIP is not restricted here.

As for the specific implementation of these software, it varies with the implementation of MOS. For example, the implementation under the original MOS is quite different from that under Servlet-MOS.

1) Message Processor PIP

Format: pipRes_interface identifier (message requester UO, message content, ...)

Function: It is a MOS plugin (PIP) that serves as a message processor supporting the MOS interface. The message processor generally implements specific message processing by calling methods in the MOS method library. For UOM-based communication, it is also necessary to read and write UOM through the UOM-API in the method library;

The PIP name starts with "pipRes_" followed by a user-defined interface identifier. The message content is in JSON format. Different interfaces have different structures. For details, see MOS interface definition.

2) Common Utilities

The utility program is used to assist the implementation of the message processor and is called by the message processor or other modules to facilitate program implementation.

(A) Message sender

Format: pipReq_interface identifier (sending strategy)

Function: It is a member of the method library. When this module is called, it sends messages according to the specified sending strategy.

Note: The sending strategy mainly includes the sending target, sender, number of retransmissions, and the location of the data to be sent;

For native MOS, the program prepares to send data, generates a send message, and stores it in the output queue. For Servlet-MOS, the program directly calls the Servlet's send function to send the message.

(B) Message Poller

Format: dispatchReq_interface identifier (polling strategy)

Function: When this module is running, it sends a request message to the corresponding UO according to the specified polling strategy to stimulate the message communication between the UO and the host MOS. Sending a request message to the UO is achieved by calling pipReq_interface identifier(). For native MOS, this program is not required.

Description: This module is a member of the method library. Each time it is called, a round of polling is executed. This module is mainly called by the "polling controller". The main contents of the polling strategy include:

Polling object scope: Indicate the objects that need to be polled;

Priority: indicates the priority of polling UO;

(C) Polling Controller

Format: ctrlDispatch (polling control strategy)

Function: When this module is running, it will periodically call each dispatchReq() according to the specified polling control strategy until the termination condition is met.

Description: This module is a member of the method library and is generally started by the system initialization module or other system modules. After starting, it will continue to run according to the set cycle until the termination condition in the polling control strategy is met.

The polling strategy describes the working mode of the controller, which mainly includes the following aspects:

Message poller list: indicates the "message poller" that needs to be called and its parameters;

Polling frequency: supports calling the poller at a certain interval;

Priority: indicates the priority at which the message poller is called;

For Servlet-MOS, this module is replaced by the Servlet message listener; for native MOS, it is implemented through the MOS event handler, that is, setting the response time handler and time sending conditions. Therefore, this module does not need to be provided independently.

Claims (8)

An architecture and low-code construction method for a digital system, characterized in that the twin of an object in digital space is used as the basic software construction component, and the fusion of the twin based on an extended multi-bipartite graph pattern is used as the basic component operation. The twin of the object in data space is created and supported by an assembled software socket MOS. Objects refer to the elements of a system such as people, objects, equipment, tools, computer software, and data in the physical world, also known as ubiquitous objects. The fusion of twins based on an extended bipartite multi-graph forms a MOS object fusion network, realizing collaborative object expansion as the twin of the system in the physical world in digital space. The digital space twin created on the assembled software socket MOS as described in claim 1 is called a MOS window. The access interface of a MOS window is called a sash. Multiple different sashes can be created in a MOS window, and each sash consists of a window and several panes, that is, the structural pattern is "window (sash*(window, pane*))", where "*" means that the element it marks can be repeated multiple times. The pane is the smallest access unit of the window, and the user's access to the MOS window is attributed to the access to the pane of the sash. The window is the interaction channel between the sash and the outside world, and is shared by the panes under the same sash. Each sash is called a MUO object. The window and pane of the sash as described in claim 2, wherein the pane is the smallest access unit of MUO, which is divided into five types: button, port, pipe, file table, and control port. Each type is an access mode to the MUO object to which it belongs. Button represents touch access, and the access type is a click or long press of the button; port represents single data access, and the access types are read and write. At any time, only one piece of data can be read in the port at a time, and only one piece of data can be injected at a time. The data to be read next time is determined by the production logic of the port itself; pipe represents queue, and the access types are extraction and addition. It is a first-in-first-out data sequence generated according to a given logic. Extracting a queue is equivalent to taking an element from the head of the queue, and adding a queue is equivalent to adding an element to the tail of the queue; file table represents a named file index table. The structure of the index table is (file ID, file structure ID, file generator), and each item in the index table represents a data set in the form of a file, and its formation is realized by the file table provider by providing a file generator; the control port supports external objects to input descriptive control instruction sequences and functional modules to the sash to which it belongs, and dynamically configure the functions of the sash. The pane as claimed in claim 3, is accessed by external objects through pane access instructions. The pane access instructions include three operations: read, write, and read-then-write. The button has only write (key) instructions, the file table has only read instructions, the command port has only write instructions, and the pipe and queue have all three operations. The pane access instruction mode is as follows: <Button Access Command>::="ButtonAccess"<ButtonOperID><PanelID><SashID><MosID><dataBuf>[operStat] <Port Access Command>::="PortAccess"<PortOperID><PanelID><SashID><MosID><dataBuf>[operStat] <Pipeline Access Command>::＝"PipleAccess"<PipleOperID><PanelID><SashID><MosID><dataBuf>[operStat] <File table access command>::="FileindexAccess"<FileindexOperID><PanelID><SashID><MosID><dataBuf>[operStat] <Control port access command>::="ControlAccess"<ControlOperID><PanelID><SashID><MosID><dataBuf>[operStat] ButtonOperID::＝"Write" PortOperID::＝"Read"|"Write"|"RW" <PipleOperID>::＝PortOperID <FileindexOperID>::＝"Read" <ControlOperID>::＝"Write" <PanelID><SashID><MosID>::＝The port location being accessed, the three parts are the identification of the pane, sash and window respectively; [operStat]::＝The operation status of the instruction. By default, it means that no operation result needs to be returned. A value of 0 or a positive number indicates success, and a negative number indicates failure. The specific value indicates the reason for success or failure or other information, which is defined by the user. <dataBuf>::＝data storage area. For read operation, it stores the read data, and for write operation, it stores the data to be written. For read-before-write instructions, the read data is stored at the end of dataBuf. For buttons, a value of 0 is not a normal click, and a value of 1 means a long press for 3 seconds. The interaction between the assembled software socket MOS and external objects as described in claim 1 and the transmission of the pane access instructions as described in claim 4 are all based on the extraction and injection protocol EIRP (Extract, Injection and Respond Protocol). As a description and transmission primitive of operation and interaction commands, EIRP defines the format and transmission procedures of interaction and operation commands. EIRP interacts in telegram mode and consists of three primitives: extraction primitive Extract, injection primitive Inject and response primitive Respond. Extract and Inject can be issued by any object, but Respond can only be accepted by MOS objects. The structure of the EIRP primitive is as follows: Extract primitive::="Extract"<operID><fromID><toID><permit>[retryTimes][resMode][parameters] Injection primitive::="Inject"<operID><fromID><toID><permit>[RetryTimes][resMode][parameters] Response primitive::="Respond"<operID><fromID><toID><permit>[resMode][RetryTime][parameters] Here, operID is a sub-instructor, which further subdivides the type of primitive and is customized by the user; fromID is the ID of the object that issues the primitive, which is either another MOS or other object that supports the ERIP protocol; toID is the identifier of the MOS that receives the primitive; the identifiers of different MOSs in the same naming domain cannot be repeated; the pattern of fromID and toID is "<PanelID>.<SashID>.<MosID>", which represent the identifiers of panes, sashes and windows respectively. Permit is the access pass, indicating the visitor's ID (user account) and the account and HASH-encrypted password. After receiving permit, MOS verifies the access rights and grants access only if they meet the requirements. retryTimes is the number of retries, indicating the maximum number of re-executions of the primitive due to abnormal primitive execution. resMode indicates whether response data needs to be sent back. If so, the system automatically sends back a Respond after the instruction is successfully accepted. Parameters is the parameters that need to be passed for primitive execution, in JSON format. The specific content is determined by the user. In the response primitive Respond, <operID>, <fromID>, <toID> correspond to <operID>, <toID>, <fromID> in the responded Extract or Inject primitive, respectively. For pane access instructions, read and read-write types are encapsulated (described) and transmitted with the Extract primitive, and write types are encapsulated (described) and transmitted with the Inject primitive. The encapsulation method is to use the ERIP sub-instruction symbol to represent the instruction word of the pane instruction, and use the ERIP toID to represent the <PanelID>, <SashID>, and <MosID> of the pane instruction, and the three IDs are separated by a period ".". The function of the assembled software socket MOS as described in claim 1 is implemented by the MOS base. The MOS base is an operation support environment responsible for supporting the operation of the MUO defined on it. The MOS base is mainly composed of a transceiver mechanism, an assembly mechanism and an operation support mechanism. The operation support mechanism is composed of data structures such as a message queue, an input queue, an output queue, a state table, an event table, an assembly table, and a function engine; the transceiver mechanism is responsible for communication and interaction with external objects, and is divided into a receiver and a transmitter. The receiver monitors the message of the window, and if it is a legal message, it receives the message and stores it in the message queue for the message scheduler to schedule and execute. The transmitter is called by the message scheduler to send messages to external objects; the assembly mechanism is mainly composed of a message scheduler and a state collector. The message scheduler is responsible for interpreting the messages in the message queue, and selects the corresponding execution module for it based on the assembly table, and hangs it on the function engine for operation. The assembly table is used as the processing entry table of the EIRP primitive and the pane instruction, and the structure is (window, sash, pane, instruction processor, injection data guide, extraction data guide, next call object (window, sash, pane)). For ERIP, windows, sashes, and panes jointly define sub-instruction symbols. Each table entry represents the processing entry of an instruction/primitive. "Next call object (window, sash, pane)" is used to support multiple processing entries, that is, an instruction or primitive can be processed at one time through multiple processing entries. The injection data guide in the table indicates the storage location of the input data required for the processor execution, the extraction data guide indicates the storage location of the output data generated by the processor execution, and the next call object (window, sash, pane) indicates the table entry of the next configuration table that needs to be executed after the processor execution of the corresponding table entry is completed. The MOS object fusion network as claimed in claim 1 is called a MUO network, and its structure and rules are as follows: 1) Let MOSb be a MOS. If each of its sashes does not have access to the sashes of other MOSs, then the sash is called a basic MUO and MOSb is called the base of the MUO. 2) Let MUO1, MUO2, …, MUOn be n different basic MUOs, whose bases can be distributed in different locations on the network, and MOSk be a new MOS or an existing MOS. Set a window sash for it based on the operation access to MUO1, MUO2, …, MUOn. The window sash is called a synthetic MUO or virtual ubiquitous object of MUO1, MUO2, …, MUOn. This synthetic relationship is recorded as <(MUO1, MUO2, …, MUOn), MUO>, and MOSk is called the base of the MUO. MUO1, MUO2, …, MUOn are called the lower-link objects of the formed MUO. The structure formed by the MUO generated according to the above rules together with its generated components is called the MUO single-flow graph. 3) Let <(u1,u2,…,un),u> be a composite relation, and there is no access request from ui to u, 1≤i≥n, then <(u1,u2,…,un),u> is called a MUO fan. <u,ui> is called a sector, (u1,u2,…,un) is called the object fanned in by u, u is the fan-out object, and the fan-out number of u is n. If ui is fanned in by m objects, the fan-in number of ui is m. A MUO with a fan-in number greater than 1 is called a shared MUO. 4) A MUO network is an extended bipartite multigraph G = (V, E) that satisfies the following conditions: G is a graph, V is a MUO set, and E is a set of "MUO sectors". If the vertex V can be divided into a sequence of n mutually disjoint subsets <V1, V2, ..., Vn>, and for u∈Vi, v∈Vi, there does not exist <u, v>∈E, and for any u∈Vi, there does not exist j>i and r∈Vj such that <u, r>∈E, nor does there exist j>i+1 and r∈Vj such that <r, u>∈E, then the number of layers of the MUO network is defined as n, and the layer number of Vi and its nodes is defined as n-i+1. Here i = 1, 2, ...n. The MUO object fusion network as claimed in claim 7 is constructed in a OUO single flow graph set OS The above is done by gradually adding new single-flow graphs. To add a new single-flow graph, follow the steps below: 1) Layering (initialization): Each single-flow graph in the single-flow graph set OS is uniformly layered according to the established strategy to form a layered graph of single-flow graphs; in this graph, the layer number of each node in each single-flow graph may be uniformly shifted by an integer value; 2) Layer expansion: According to the established strategy, a layer i is selected, and in the layer i, according to the rules of claim 7, a new OUO is defined, with the OUO nodes in the (i-1) layer as members; 3) Adding a layer: According to the established strategy, add a new layer above the current highest layer of the hierarchical graph (set as h), and in the new layer, define a new OUO according to the rules of claim 7, with the OUO nodes in the h layer as members.

Images