CN113824568B

CN113824568B - Asset object management system and method

Info

Publication number: CN113824568B
Application number: CN202111382960.5A
Authority: CN
Inventors: 韩天宇; 刘阳; 田娟; 池程; 朱斯语
Original assignee: China Academy of Information and Communications Technology CAICT
Current assignee: China Academy of Information and Communications Technology CAICT
Priority date: 2021-11-22
Filing date: 2021-11-22
Publication date: 2022-02-18
Anticipated expiration: 2041-11-22
Also published as: CN113824568A

Abstract

The embodiment of the application provides an asset object management system and a method, wherein the asset object management system comprises a publishing client, a subscribing client and an information management server, and the publishing client and the subscribing client are in communication connection with the information management server; the publishing client and the information management server are used for generating asset objects according to a data interoperation protocol; the publishing client is also used for publishing the asset object to the information management server according to the data interoperation protocol; the information management server is also used for sending the asset object to the subscription client according to the data interoperation protocol. The asset objects are published and subscribed through a data interoperation protocol, various transmission strategies of the data interoperation protocol ensure that the asset objects are compatible with adaptation of multiple protocols, the efficient compression method of the data interoperation protocol improves transmission efficiency and performance, and the data interoperation protocol has a data model structure with separated data categories and data instances and a safe and reliable transmission certificate.

Description

Asset object management system and method

Technical Field

The present application relates to the field of industrial internet technologies, and in particular, to an asset object management system and method.

Background

The current data Transmission Protocol is generally lack of compatibility with the underlying Protocol, for example, MQTT (Message queue Telemetry Transport) needs to be bound with TCP (Transmission Control Protocol) Protocol, and quickudp Internet connections (quickudp) Protocol is used for Transmission over UDP (User Datagram Protocol). However, in the current industrial internet environment, multiple protocols coexist, and the use of a single protocol cannot meet the compatibility requirements of all the lower-layer protocols. Meanwhile, for the above protocols, the format of the transmission data is not completely specified, and the interconnection requirement of the industrial internet for heterogeneous different-place different-main data cannot be met.

Disclosure of Invention

The embodiment of the application provides an asset object management system and method, which are used for solving the problems in the prior art.

According to a first aspect of the embodiments of the present application, there is provided an asset object management system, including a publishing client, a subscribing client and an information management server, where the publishing client and the subscribing client are both in communication connection with the information management server;

the publishing client and the information management server are both used for generating asset objects according to a data interoperation protocol;

the publishing client is also used for publishing the asset object to the information management server according to the data interoperation protocol;

the information management server is also used for sending the asset object to the subscription client according to the data interoperation protocol;

the data interoperation protocol is used for specifying a message format, a data format and an operation flow of the asset object, the asset object comprises a category object and an ontology object, the category object is used for representing the dependency relationship, the category description information and the meta-attribute information among the data assets, and the ontology object is an instance of the category object.

According to a second aspect of the embodiments of the present application, there is provided an asset object management method, which is applied to an asset object management system, where the asset object management system includes a publishing client, a subscribing client and an information management server, and both the publishing client and the subscribing client are communicatively connected to the information management server, the method includes:

the issuing client and the information management server both generate asset objects according to a data interoperation protocol;

the issuing client also issues the asset object to the information management server according to the data interoperation protocol;

the information management server sends the asset object to the subscription client according to the data interoperation protocol;

By adopting the asset object management system and method provided by the embodiment of the application, the asset objects are published and subscribed through the data interoperation protocol, various transmission strategies of the data interoperation protocol are guaranteed to be compatible with adaptation of multiple protocols, the transmission efficiency and performance are improved through the efficient compression method of the data interoperation protocol, and the data interoperation protocol has a data model structure with separated data categories and data instances and a safe and reliable transmission certificate.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a schematic structural diagram of an asset object management system according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a category object according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of an ontology object according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of a message format generated by a data interoperability protocol according to an embodiment of the present application;

fig. 5 is a schematic format diagram of a basic header provided in an embodiment of the present application;

fig. 6 is a schematic diagram of a format of a transport block according to an embodiment of the present application;

fig. 7 is a schematic diagram illustrating a format of a flag bit of a transport block according to an embodiment of the present application;

fig. 8 is a schematic diagram of another transport block format according to an embodiment of the present application;

fig. 9 is a schematic diagram illustrating a format of a flag bit of another transport block according to an embodiment of the present application;

fig. 10 is a schematic diagram of a format of another transport block according to an embodiment of the present application;

fig. 11 is a schematic diagram illustrating a format of a flag bit of another transport block according to an embodiment of the present application;

fig. 12 is a schematic format diagram of a control block according to an embodiment of the present application;

fig. 13 is a schematic diagram illustrating a format of a flag bit of a control block according to an embodiment of the present application;

fig. 14 is a schematic diagram of a format of an optional block according to an embodiment of the present application;

FIG. 15 is a schematic diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

FIG. 16 is a schematic diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

FIG. 17 is a schematic diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

fig. 18 is a schematic diagram illustrating a format of a status code according to an embodiment of the present application;

FIG. 19 is a diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

FIG. 20 is a diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

FIG. 21 is a diagram illustrating a format of flag bits of another control block according to an embodiment of the present application;

fig. 22 is a schematic diagram of a format of a data block according to an embodiment of the present application;

fig. 23 is a schematic diagram illustrating a format of a flag bit of a data block according to an embodiment of the present application;

FIG. 24 is a block diagram illustrating a flag bit format of a credential block according to an embodiment of the present disclosure;

fig. 25 is a transmission diagram of a data interoperability protocol according to an embodiment of the present application;

FIG. 26 is a compression diagram of a data interoperability protocol according to an embodiment of the present application;

fig. 27 is a schematic flowchart of an asset object management method according to an embodiment of the present application.

Icon:

100-asset object management system; 110-a publishing client; 120-an information management server; 130-a subscription client; 140-identity resolution device; 150-blockchain device.

Detailed Description

In the process of implementing the present application, research finds that the current data transmission protocol is generally deficient in compatibility with the underlying protocol, for example, MQTT needs to be bound with a TCP protocol, and a Quic protocol transmits over a UDP protocol. However, in the current industrial internet environment, multiple protocols coexist, and the use of a single protocol cannot meet the compatibility requirements of all the lower-layer protocols. Meanwhile, for the above protocols, the format of the transmission data is not completely specified, and the interconnection requirement of the industrial internet for heterogeneous different-place different-main data cannot be met.

In order to solve the above problems, embodiments of the present application provide an asset object management system and method, where asset objects are published and subscribed through a data interoperability protocol, multiple transmission strategies of the data interoperability protocol ensure that the asset objects are compatible with multiple protocols, a high-efficiency compression method of the data interoperability protocol improves transmission efficiency and performance, and the data interoperability protocol has a data model structure with separated data categories and data instances, and a secure and trusted transmission credential.

The scheme in the embodiment of the application can be implemented by adopting various computer languages, such as object-oriented programming language Java and transliterated scripting language JavaScript.

In order to make the technical solutions and advantages of the embodiments of the present application more apparent, the following further detailed description of the exemplary embodiments of the present application with reference to the accompanying drawings makes it clear that the described embodiments are only a part of the embodiments of the present application, and are not exhaustive of all embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

Referring to fig. 1, a schematic structural diagram of an asset object management system 100 according to an embodiment of the present disclosure is shown, where the asset object management system 100 includes a publishing client 110, a subscribing client 130 and an information management server 120, and both the publishing client 110 and the subscribing client 130 are communicatively connected to the information management server 120.

In this embodiment, both the publishing client 110 and the information management server 120 are configured to generate asset objects according to a data interoperability protocol; the publishing client 110 is also used to publish the asset object to the information management server 120 according to a data interoperability protocol; the information management server 120 also sends the asset object to the subscribing client 130 according to a data interoperability protocol.

The data interoperation protocol is used for specifying a message format, a data format and an operation flow of an asset object, the asset object comprises a category object and an ontology object, the category object is used for representing the dependency relationship, the category description information and the meta-attribute information among data assets, and the ontology object is an example of the category object.

It should be understood that the message format defines the transport mechanism, control method, and related security verification information for the asset object in the network; the data format provides a method for standardizing and organizing asset objects generated by industrial manufacturing with a resource category system as a center; the operation flow explains how a user specifically shares and interoperates data based on a data interoperation protocol, and comprises system components, functions of each component and flow steps.

In the present embodiment, the publishing client 110 is a party that generates the asset object, and transmits the asset object to the information management server 120 in a publishing manner. The subscription client 130 is a party using the asset object, and acquires the asset object from the information management server 120 by means of subscription. The publishing client 110 and the subscribing client 130 can be users, machines, sensors, software systems, etc. industrial internet participants. The information management server 120 is an agent for providing asset object distribution in a publish-subscribe mode, and is mainly responsible for the functions of storage, management, authority control, validity check and the like of asset objects. The information management server 120 may be an existing system such as an industrial software, an edge gateway, an industrial internet platform, etc.

In this embodiment, the asset objects are effectively organized by an asset category hierarchy. Asset objects can be classified into category objects (Class AO) and Ontology objects (Ontology AO), where an Ontology object is a specific instance of a category object and needs to conform to the definition and description in its corresponding category object. Ontology objects are further divided into data objects, which describe definitions and refer to data, and operation objects, which are operations on specified data.

And the asset category system divides the related people, objects and processes into objects according to the business requirements. After the original data is integrated according to the asset category system, the data is stably and invariably transmitted to the asset category system no matter how the front-end service changes the acquisition form, period, transmission mode and the like of the data. The asset category system can not be changed with the change of the upper layer morphology such as a business form operation activity scheme and the like to generate the bottom layer structure.

The category object is a concrete representation of an asset category system, and the category object comprises basic information for object creation, inheritance reference information and meta-attribute information. Fig. 2 is a schematic diagram of a category object. Object ID in FIG. 2 represents an Object identifier, a number unique to an asset Object; registry Time represents the registration Time, i.e., the Time when the asset object was created; the Expiration Time indicates the Expiration Time, i.e., the Time when the asset object is spent; the Modified Time represents the modification Time, namely the Time when the asset object was Modified last Time; the Father representation points to the higher level category object represented by the category object, represented by a set containing identifiers of inherited higher level category objects, such as: { Object ID1, Object ID2, … }; the attribute of Child representation attribute becomes a meta attribute; meta Attribute (Meta Attribute) is an Attribute description of a category object intended to use business-oriented terminology to help people and machines better understand, identify tags; the meta-attributes may mainly include category standards to which the attributes belong, attribute names, attribute descriptions, attribute processing types, value dictionaries, value types, examples, update cycles, security levels, object relationships, and the like; the attribute belongs to the category standard: i.e., the specification standard to which the attribute conforms, such as Eclass; attribute name: attribute naming should follow three major principles: privacy violation is avoided, the same attribute uses the same attribute name, and the same attribute uses the same statement structure; and attribute description: the attribute names are explained by one or two sentences, so that the problems of ambiguity, polysemy and the like of the attribute names caused by too short words are avoided; and (3) attribute processing type: the method comprises the following steps of dividing the processing types into original attribute, statistical attribute and algorithm attribute according to different processing types, wherein fields existing in an original data table of the original attribute become attributes after simple and regular adjustment, and the attributes can be used by service personnel, such as age, mobile phone number and the like; the statistical attribute represents that the original data becomes attribute-attributed service personnel, such as total number of commodities browsed in 7 days and the like, through processing, such as simple mathematical function operations of summation, averaging, regular expression and the like; the algorithm type attribute is a label of the deep processing type of the original data calculated by the model algorithm, such as 'labor waste' and the like; value dictionary: i.e. an enumeration of various possible values of an attribute, such as: the value dictionary of the "gender" attribute is [ male, female ]; the value type is as follows: data types of attribute values, such as numeric type, character type, date type, and the like; example (c): specific examples of attribute values; and (3) updating period: the update period of the attribute data is referred to; and (4) safety level: data security risks exist in the processes of acquiring data from source data, processing the data, enabling the data to be online and using the data, so that security levels are formulated for the attributes, and attribute use specifications of different levels are generated according to the security levels of the attributes; object relationship: the native attribute tags of category objects for fast and child can be further explained by the object relationship.

An ontology object is an asset instance created from a category object, which in turn may be divided into data objects and operation objects. Fig. 3 is a schematic structural diagram of an ontology object. In fig. 3, Class Object indicates an Object type, and represents that the type of the Object is a category Object; Data/Opera represents the object type, the Data representation is the Data object, and the Opera representation is the operation object; data ontology: the data format, semantics, period, security level and the like need to be consistent with those defined in the object of the category.

As shown in fig. 4, a schematic structural diagram of a message format generated for a data interoperability protocol, which includes a basic header, a transport block, a control block, a data block, and a credential block.

The basic header is used for characterizing basic information of the data interoperability protocol, and the basic information comprises a version and a check code of the data interoperability protocol. As shown in fig. 5, a format diagram of the basic header is shown. The format of the basic header includes a major version, a minor version, and a check code, the major version and the minor version each being set to 8 bits for representing a version of the data interoperability protocol, each field being defined by a 1-byte non-signed integer. The different major versions represent major changes in protocol format, and the party using the lower major version must upgrade the software to ensure the accuracy of the communication. The addition of the minor version means that additional functions are added to the protocol but does not affect the main information format of the protocol.

The check code is set to 16 bits for checking the integrity of the transmitted data packet. The data interoperability protocol definition may be checked using the CRC-16 standard.

In this embodiment, the publishing client 110 is further configured to obtain an operation flow of publishing the asset object to the information management server 120 according to the transmission block; the information management server 120 is further configured to obtain an operation flow of sending the asset object to the subscribing client 130 according to the transport block. The publishing client 110 and the information management server 120 are further configured to determine the operation flow of the asset object as one of a retransmission mechanism, a multiple transmission mechanism, and an error correction mechanism according to the transport block.

It will be appreciated that the transport block defines how the asset object is transported in the network. Different transmission modes are defined by the head types of different transmission blocks, each transmission mode has respective characteristics, and a user can select the used transmission mode according to factors such as network environment, service requirements, transmission equipment and the like.

Fig. 6 is a schematic diagram of a format of a transport block configured as a retransmission mechanism. Under the retransmission mechanism, the transport block format of the asset object includes a block type, a header type, a flag, a block length, a reserved bit, a transport identifier, a transport sequence number, a total, a timestamp, a stream identification, a stream sequence number, a delimiter, and a load.

Wherein, the block type is set to 2 bits, and the block type value is set to 0, namely, the type of the block is represented as a transmission block; the header type is set to 6 bits, and the header type value is set to 0, namely the functional type representing the transmission block is a retransmission mechanism; the flag bit is set to 16 bits, 4 flag bits can be predefined, and the remaining 4 bits are reserved bits and are set to 0; the block length is set to 16 bits, which represents the length of the transport block or the length of the fragmented data packet (when the block type is a transport block), and the value of the data block length must be an integer multiple of 4 bytes in terms of bytes, and the block length does not include the length of the padding field; the reserved bit is set to 32 bits for reservation for future use; the Transmission identifier is set to be 32 bits, each Transmission of the sending end is represented by < Transmission Id > of a 4-byte unsigned integer, the Transmission identifier must be distinguished from other transmissions initiated by the same sender, and can track the Transmission, and the response of the receiving end must contain a correct Transmission identifier; the Transmission Sequence Number is set to 32 bits, the asset object may be truncated during Transmission (e.g. when based on UDP), < Transmission Sequence Number, TSN > is a 4-byte unsigned integer as a trace count for each slice after the original information is truncated, the information receiver may assemble and recover the original information based on TSN, TSN of each piece of information must start from 0, each piece of truncated information must set the TC flag in its transport block, and a message without truncation must set its TSN to 0; the total number is set as a 32-bit unsigned integer, the total number of data packets of the truncated message is specified, and the data can be transmitted as a plurality of messages with common transmission identifications; the timestamp is set to 4 bytes, and when the message is sent, the time value of the current clock is obtained; the stream identifier is set to be 2 bytes, which indicates the stream to which the data block belongs, the field is designed to realize multi-stream transmission, each logical stream is uniquely marked by the stream identifier and is distinguished and received at a receiving end, each logical stream is independent, and if the multi-stream transmission is not used, the field is set to be-1; setting a stream sequence number to be 2 bytes, setting a stream internal sequence number, and setting a Transmission sequence number TSN (transport sequence number) relative to a stream where a stream identifier is located to be used for determining Transmission sequence numbers of all data under a specified Transmission ID, wherein the stream sequence number is used for confirming the sequence number of the data under the current logic stream, and setting the stream identifier and the stream sequence number to be-1 if the multi-stream Transmission is not used; payload, variable length, specific data, protocol specifies that if there is a payload in a block, the payload must be preceded by a delimiter of one byte (0 xFF), if not, the recipient will process the error message, the payload must be a multiple of 4 bytes long, if not, it is padded with 0.

As shown in fig. 7, which is a schematic diagram of a flag bit, bit0 is an RS (resend) flag, which is used to indicate whether it is a retransmission request of a receiver, if the RS bit is 1, it indicates that some data packets are lost during Transmission, and the receiver requests the sender to retransmit the lost data packets, which can be located by the fields of < Transmission Id > and < TSN >, and if the RS is set to 1, and the sequence number is set to-1, it indicates that the receiver has received all data packets; bit1 is an ec (encrypted) flag indicating whether the message (excluding the non-payload portion of the transport block) is encrypted, and when set to 1, indicates that the message is encrypted; bit2 is the TC (truncated) flag, indicating whether the message is truncated; bit3 is a CP (Comcompressed) flag indicating whether a message (excluding message envelopes) is compressed, 1 indicates compressed, 0 indicates uncompressed, and the compression method may be defined as IETF-XXXXXX.

Stable and reliable information transmission is a basic requirement of data communication, and due to the complex and various protocol applications in the industrial internet environment, the integrity and the orderliness of transmission cannot be guaranteed. Therefore, the data interoperation protocol provides a transmission method of a retransmission mechanism to ensure the quality of asset object exchange.

In the retransmission mechanism, a sending end encodes a data sequence of an asset object according to a certain rule, so that the data sequence becomes a data packet with strong error detection capability. And after receiving the data packet, the receiving end calculates a receiving check code according to the coding rule. If the check is correct, the packet is accepted. Meanwhile, the receiving end informs the transmitting end via the reverse channel feedback that the error-free code sent by the transmitting end has been successfully received. If the error is checked, the data packet is wrong, and the transmitting end is informed to retransmit the same packet through a feedback channel. The sender retransmits the previously sent information once until the packet is successfully received. The sending end may be the publishing client 110 or the information management server 120; the receiving end may be the information management server 120 or the subscribing client 130.

Fig. 8 is a schematic diagram of a format of a transport block configured as a multiple-sending mechanism. Under the multiple issue mechanism, the transport block format of an asset object includes a block type, a header type, a flag bit, a block length, a reserved bit, a transport identifier, a transport sequence number, a count, a stream identification, a stream sequence number, a delimiter, and a payload.

Wherein, the block type is set to 2 bits, and the block type value is set to 0, namely, the type of the block is represented as a transmission block; the head type is set to be 6 bits, the head type value is set to be 1, namely the functional type of the transmission block is represented as a multi-sending mechanism; the flag bit is set to 16 bits, 3 flag bits can be predefined, and the remaining 5 bits are reserved bits and are set to 0; the block length is set to 16 bits, which represents the length of the transport block or the length of the fragmented data packet (when the block type is a transport block), and the value of the data block length must be an integer multiple of 4 bytes in terms of bytes, and the block length does not include the length of the padding field; the reserved bit is set to 32 bits for reservation for future use; the Transmission identifier is set to be 32 bits, each Transmission of the sending end is represented by < Transmission ID > of a 4-byte unsigned integer, the Transmission identifier must be distinguished from other transmissions initiated by the same sender, and can track the Transmission, and the response of the receiving end must contain a correct Transmission identifier; the transmission sequence number is set to 32 bits, labels are marked for each data packet in sequence, starting from 0, and the transmission sequence number is reset to zero and restarted after reaching the maximum quota; the count is set to 32 bits, indicating the number of times the asset object is multi-shot; the stream identifier is set to be 2 bytes, which indicates the stream to which the data block belongs, the field is designed to realize multi-stream transmission, each logical stream is uniquely marked by the stream identifier and is distinguished and received at a receiving end, each logical stream is independent, and if the multi-stream transmission is not used, the field is set to be-1; setting a stream sequence number to be 2 bytes, setting a stream internal sequence number, and setting a Transmission sequence number TSN (transport sequence number) relative to a stream where a stream identifier is located to be used for determining Transmission sequence numbers of all data under a specified Transmission ID, wherein the stream sequence number is used for confirming the sequence number of the data under the current logic stream, and setting the stream identifier and the stream sequence number to be-1 if the multi-stream Transmission is not used; payload, variable length, specific data, protocol specifies that if there is a payload in a block, the payload must be preceded by a delimiter of one byte (0 xFF), if not, the recipient will process the error message, the payload must be a multiple of 4 bytes long, if not, it is padded with 0.

As shown in fig. 9, which is a schematic diagram of a format of a flag bit, bit0 is an ec (encrypted) flag indicating whether a message (excluding an unloaded part of a transport block) is encrypted, and when set to 1, it indicates that the message is encrypted; bit1 is the TC (truncated) flag, indicating whether the message is truncated; bit2 is a CP (Comcompressed) flag indicating whether a message (excluding message envelopes) is compressed, 1 indicates compressed, 0 indicates uncompressed, and the compression method may be defined as IETF-XXXXXX;

in the sending process of the multi-sending mechanism, for the same transmission identifier, each data packet has a unique transmission sequence number TSN. For the same TSN, the sender continuously sends data for multiple times, but the TSN is not increased, the sending times are defined in the Count (greater than or equal to 2), and the interval of continuous sending is not limited.

In the receiving process, the receiving party judges the TSN of the received data, if the TSN is larger than the serial number of the last data packet, the data packet is considered to be an effective packet, and the data packet is immediately processed; if the transmission sequence number is the same as that of the previous packet, the redundant transmission of the previous data packet is considered, and the invalid data is discarded.

Fig. 10 is a schematic diagram showing a format of a transport block configured as an error correction mechanism. Under the error correction mechanism, the transport block format of the asset object includes a block type, a header type, a flag bit, a block length, a redundancy size, a reserved bit, a transport identifier, a group number, a group size, a group sequence number, a stream identification, a stream sequence number, a timestamp, a delimiter, and a load.

Wherein, the block type is set to 2 bits, and the block type value is set to 0, namely, the type of the block is represented as a transmission block; the head type is set to 6 bits, the head type value is set to 3, namely the functional type representing the transmission block is an error correction mechanism; the flag bit is set to 8 bits, 6 flag bits can be predefined, and the remaining 2 bits are reserved bits and are set to 0; the block length is set to 16 bits, which represents the length of the transport block or the length of the fragmented data packet (when the block type is a transport block), and the value of the data block length must be an integer multiple of 4 bytes in terms of bytes, and the block length does not include the length of the padding field; the redundancy size is set to be 2 bytes and is used for representing the number of the redundancy packets in the group where the current packet is located; the reserved bit is set to 16 bits for reservation for future use; the Transmission identifier is set to be 32 bits, each Transmission of the sending end is represented by < Transmission Id > of a 4-byte unsigned integer, the Transmission identifier must be distinguished from other transmissions initiated by the same sender, and can track the Transmission, and the response of the receiving end must contain a correct Transmission identifier; the group serial number is set to be 4 bytes, the serial number of the group where the current packet is located, the code stream is composed of continuous groups, each group has a unique serial number, and the group starts from 0 and returns to zero and restarts after reaching the maximum quota; the group size is set to be 2 bytes and is used for representing the size of the group where the current packet is located; the group sequence number is set to 16 bits and is used for representing the sequence number of the current packet in the group, and the sequence number starts from 0; the stream identifier is set to be 2 bytes, which indicates the stream to which the data block belongs, the field is designed to realize multi-stream transmission, each logical stream is uniquely marked by the stream identifier and is distinguished and received at a receiving end, each logical stream is independent, and if the multi-stream transmission is not used, the field is set to be-1; setting a stream sequence number to be 2 bytes, setting a stream internal sequence number, and setting a Transmission sequence number TSN (transport sequence number) relative to a stream where a stream identifier is located to be used for determining Transmission sequence numbers of all data under a specified Transmission ID, wherein the stream sequence number is used for confirming the sequence number of the data under the current logic stream, and setting the stream identifier and the stream sequence number to be-1 if the multi-stream Transmission is not used; the timestamp is set to 4 bytes, and when the message is sent, the time value of the current clock is obtained; payload, variable length, specific data, protocol specifies that if there is a payload in a block, the payload must be preceded by a delimiter of one byte (0 xFF), if not, the recipient will process the error message, the payload must be a multiple of 4 bytes long, if not, it is padded with 0.

As shown in fig. 11, which is a schematic diagram of a format of a flag bit, bit0 is an ec (encrypted) flag indicating whether a message (excluding an unloaded part of a transport block) is encrypted, and when set to 1, it indicates that the message is encrypted; bit1 is the TC (truncated) flag, indicating whether the message is truncated; bit2 is a CP (Comcompressed) flag indicating whether a message (excluding message envelopes) is compressed, 1 indicates compressed, 0 indicates uncompressed, and the compression method may be defined as IETF-XXXXXX; bit3-5 is an FEC code flag indicating different error correction code types, the assignment of the FEC code flag is 000, indicating a Hamming code; the FEC code flag is assigned to be 001, and the BCH code is represented; the FEC code flag is assigned a value of 010, indicating a Seed-Solomon (RS) code; the FEC code flag is assigned to 011, indicating a convolutional code; the FEC code flag is assigned as 100 to represent Turbo code; the FEC code flag is assigned 101, indicating a low density parity check code (LDPC).

The error correction mechanism adopts a forward error correction method to increase the credibility of asset object communication, and once an error is found in a one-way communication channel, a receiving end of the one-way communication channel does not have the right to request transmission again. The forward error correction coding (FEC) technology can automatically correct transmission error codes by adding redundant error correction codes into transmission code columns and decoding under certain conditions, so that the error code rate of received signals is reduced. FEC is a method for transmitting redundant information by using data, and when an error occurs in transmission, a receiving end can reconstruct data.

During the transmission process, the asset object to be transmitted is divided into a plurality of groups for transmission, and each group consists of a certain proportion of data packets and redundant packets (redundancy). In one group, redundant packets are generated from data packets and corresponding error correction codes. The groups are independent from each other, the size and redundancy of the groups can be different, and the sending end can be dynamically adjusted according to the network receiving condition of the receiving end so as to achieve the optimal service quality. For example, when the channel condition is poor and the packet loss rate of the receiver is increased, the redundancy can be improved by the transmitting end to enhance the packet loss resistance; on the contrary, if the packet loss rate is very low, the redundancy can be properly reduced at the transmitting end, so as to save the network bandwidth.

In the receiving process, if the receiving end receives the packet according to the group sequence number, the packet is not lost, and is directly uploaded to the upper application; if the packet is not received according to the group sequence number, the packet loss situation is indicated, and the receiving end needs to recover according to the error correction code and other packets in the group. If the recovery can not be carried out, the received packets are uploaded in sequence, and the rest are abandoned.

The non-payload portion of the transport block is not protected by the signature or encryption information in the credential block, and the payload portion of the transport block is the aggregate of all other blocks.

In this embodiment, both the publishing client 110 and the information management server 120 are further configured to generate data information of the asset object according to the data block; the publishing client 110 and the information management server 120 are both further configured to generate control information of the asset object according to the control block; the publishing client 110 and the information management server 120 are each further configured to generate authentication encryption information for the asset object from the credential block.

It should be understood that both the publishing client 110 and the information management server 120 are also configured to determine the data format of the data information according to the data block format; the data block format comprises a block type, a header type, a flag bit, a block length, a delimiter and a load; the block type is used for representing the type of the block; the head type is used for representing the functional category of the block; the flag bit is used for representing whether the data information is compressed or not, and the data information is a category object or an ontology object; the block length is used for representing the length of the data block; the load is used to characterize the data information.

The publishing client 110 and the information management server 120 are both further configured to determine a message format of the control information of the asset object according to the control block format; the control block format comprises a block type, a header type, a flag bit and a block length; the block type is used for representing the type of the block; the head type is used for representing the functional category of the block; the zone bit is used for representing whether the control information carries one or more of a user name field, a password field and a token, and whether the control information is a category object or a body object and whether the control information is issued for the first time; the block length is used to characterize the length of the data block.

The publishing client 110 and the information management server 120 are both further configured to determine an information format of the verification encryption information of the asset object according to the credential block format; the voucher block format comprises a block type, a header type, a flag bit and a block length, wherein the block type is used for representing the type of a block; the head type is used for representing the functional category of the block; the zone bit is used for representing whether the verification encryption information comprises one or more of an identifier, a public key, a verification certificate and a digest algorithm; the block length is used to characterize the length of the data block.

It should be understood that the data interoperability protocol communicates through predefined control blocks, the process of communication being divided into two phases, publish and subscribe. The control block is mainly responsible for relevant information of message operation and does not contain load.

FIG. 12 is a schematic diagram showing a format of a control block during the stage of publishing an asset object. Setting the block type to be 2 bits, and setting the block type value to be 1, namely representing the type of the block to be a control block; the head type is set to be 6 bits, the head type value is set to be 0, namely the function type representing the control block is the function of issuing the asset object; the flag bit is set to 8 bits, 6 flag bits can be predefined, and the remaining 2 bits are reserved bits and are set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 13 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is a tp (type) flag Bit, which is set to 0, and represents that the published data is a category object, and is set to 1, and represents that the published data is an ontology object; bit4 is an RP (repeat) flag Bit that is set to 0, indicating that the data identifier was first issued, set to 1, indicating that the data identifier was previously issued but was not successful; bit5 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning end is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the return data.

The control block also includes an option that contains one or more fields prefixed by length, and a flag bit determines whether or not to contain these fields, and if so, must appear in this order: data identifier, username, password, token. The basic format in which each field appears in an optional block is shown in fig. 14 and includes a two-byte length field, the length indicating the number of bytes of binary data (excluding the two bytes occupied by the length field itself) MSB and LSB representing the upper 8 bits and lower 8 bits, respectively, of the length of the character string, followed by 0 to 65535 bytes of binary data.

Data identifiers (Data IDs) are used by participants of each party of the industrial internet to identify Data, and the asset object management system 100 analyzes the Data identifiers to obtain connection information of specific Data storage host addresses, such as secondary node information service identifiers, ports and the like, so that Data and hosts are decoupled, that is, Data management details (Data storage positions, storage modes, acquisition ways and Data types) are shielded downwards and are expressed upwards as an abstract form, namely, asset objects.

If the UF flag bit is set to 1, the next field of the option must be the username. The username must be the UTF-8 encoded string. The receiver can use it for authentication and authorization of data access.

If the PF flag is set to 1, the next field of the option must be the password.

If the TK flag bit is set to 1, the next field of the selectable item must be the token. The user is allowed to provide a token, rather than a username and password, to access data for a particular data server.

In the updating stage of issuing the asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, the head type value is set to 1, namely the function type representing the control block is an asset object issuing updating function; the flag bit is set to 8 bits, 7 flag bits can be predefined, and the remaining 1 bit is a reserved bit and is set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 15 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is a tp (type) flag Bit, which is set to 0, and represents that the published data is a category object, and is set to 1, and represents that the published data is an ontology object; bit4 is an nf (notification) flag Bit, which is set to 0, representing that it is not necessary to send a reminder message to a user party referring to the same identifier, and is set to 1, representing that it is necessary to send a reminder message; bit5 is an RP (repeat) flag Bit that is set to 0, indicating that the data identifier was first issued, set to 1, indicating that the data identifier was previously issued but was not successful; bit6 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning end is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the return data.

During the update phase of publishing asset objects, the optional items in the control block contain one or more fields prefixed by length, and the flag bit determines whether or not to contain these fields, which, if contained, must appear in this order: data identifier, username, password, token, prompt message.

Where the last field of the option must be a hint message if the hint message flag NF is set to 1. The prompt message defines the message sent by the end using the asset object after the asset object is updated, which may be but is not limited to comparison before and after updating, update reason, author, etc., and the specific format is defined by the user, or defined by using an asset category system.

In the deletion stage of the published asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, the head type value is set to 2, namely the function type representing the control block is the function of deleting the published asset object; the flag bit is set to 8 bits, 6 flag bits can be predefined, and the remaining 2 bits are reserved bits and are set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 16 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is a tp (type) flag Bit, which is set to 0, and represents that the published data is a category object, and is set to 1, and represents that the published data is an ontology object; bit4 is an RP (repeat) flag Bit that is set to 0, indicating that the data identifier was first issued, set to 1, indicating that the data identifier was previously issued but was not successful; bit5 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning end is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the return data.

During the delete phase of a published asset object, an optional item in the control block contains one or more fields prefixed by length, and the flag bit determines whether or not these fields are contained, and if so, must appear in this order: data identifier, username, password, token.

In the return stage of issuing the asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, the head type value is set to 3, namely the function type representing the control block is an asset object issuing return function; the flag bit is set to 8 bits, 6 flag bits can be predefined, and the remaining 2 bits are reserved bits and are set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 17 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning end is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the return data. Bit4-6 is the number of status codes representing the number of status codes contained in the published asset object return type control block.

The data interoperability protocol predefines the return states for different issue operations, the state code and corresponding meaning are shown in table 1, and the state code is a binary representation of the state code.

TABLE 1

Status code format as shown in fig. 18, the number of status codes must be the same as the number indicated in the flag bit. In fig. 21, Flag is set to 1 bit, which represents whether the status code field contains a status code data portion, and if 0, it does not contain a data length byte (2 bytes) and the status code data portion, and if 1, it needs to include the data length byte and the status code data portion; the state code data part represents additional data corresponding to the state code, and the format of the data can be any format set by the server side and can also be specified through an asset category system.

In the stage of subscribing the asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, and the head type value is set to 4, namely, the function type representing the control block is the function of subscribing the asset object; the flag bit is set to 8 bits, 7 flag bits can be predefined, and the remaining 1 bit is a reserved bit and is set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 19 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is an RP (repeat) flag Bit that is set to 0, indicating that the data identifier was first issued, set to 1, indicating that the data identifier was previously issued but was not successful; bit4 is a tp (type) flag Bit, which is set to 0, and represents that the published data is a category object, and is set to 1, and represents that the published data is an ontology object; bit5 is the LT (List) flag; bit6 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning end is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the return data.

Wherein, the TP flag bit and the LT flag bit are both set to 0, which represents that the subscribed category object is the category object itself; TP mark position 0, LT mark position 1, representing the display fields listing all the body objects under the appointed category object; TP mark position 1 and LT mark position 0, representing that the subscription is an ontology object, and the parameter condition of the subscription needs to be defined in the optional block, and the data format is defined by an asset category system provided by a service party; TP flag position 1 and LT flag position 1 represent all the parameters and descriptions listed for the operation of the ontology object.

During the subscription asset object phase, the optional items in the control block contain one or more fields prefixed by length, and the flag bit determines whether or not to contain these fields, and if so, must appear in this order: data identifier, username, password, token. Category object identifier, ontology object identifier, username, password, token, parameter fields. The basic format in which each field appears in an optional block has been defined.

Wherein, the first field in the selectable block must be a category object identifier, representing the category object to which the subscription belongs; if the TP flag bit is set to 1, the next field of the optional block is the body object; if TP is set to 1 and LT is set to 0, the optional block needs to have a parameter field, and the data format is defined by the asset category system provided by the service provider.

In the stage of unsubscribing the asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, and the head type value is set to 5, namely the function type representing the control block is the function of canceling the subscription asset object; the flag bit is set to 8 bits, and 8 flag bits can be predefined; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 20 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is an RP (repeat) flag Bit that is set to 0, indicating that the data identifier was first issued, set to 1, indicating that the data identifier was previously issued but was not successful; bit4 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning party is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the returned data; bit5-7 is a number flag Bit that represents the number of unsubscribed asset objects that are contained.

During the unsubscribe phase of an asset object, the selectable items in the control block contain one or more fields prefixed by length, which are the identifiers of the objects to be unsubscribed. The number of identifiers of the object to be revoked must be the same as the number in the flag bit.

In the return stage of issuing the asset object, the block type of the control block is set to be 2 bits, and the block type value is set to be 1, namely the type representing the block is the control block; the head type is set to 6 bits, and the head type value is set to 6, namely, the function type representing the control block is the return function of the subscription asset object; the flag bit is set to 8 bits, 7 flag bits can be predefined, and the remaining 1 bit is a reserved bit and is set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length.

Fig. 21 is a schematic diagram showing a format of flag bits of a control block. Bit0 is a uf (user flag) flag Bit, which is set to 0, and the option cannot contain the username field, and is set to 1, and the option must contain the username field; bit1 is a pf (password flag) flag Bit, which is set to 0, and optionally cannot contain a password field; set to 0, must contain a password field; bit2 is the TK (token) flag, set to 0, cannot contain tokens (tokens) in the alternative, set to 1, and must contain tokens in the alternative; bit3 is a CT (verified) flag Bit, when the CT Bit of the sending end is set to 1, the receiving end needs to encrypt the return by using a private key, when the CT Bit of the returning party is set to 1, it represents that the data has been signed, and if the receiving end does not provide a valid signature in the return, the sending end discards the returned data; bit4-6 is a status code number flag Bit representing the number of status codes contained in the return type control block for a subscribed asset object.

The data interoperability protocol predefines the return states for different subscription operations, the state code and corresponding meaning are shown in table 2, and the state code is a binary representation of the state code.

TABLE 2

In this embodiment, the function type of the control block further includes a prompt message, which is sent to a party subscribing to the original object after the asset object is published for updating or deleting. The value of the type of the header in the control block is set to 7, i.e., the kind of function characterizing the control block is the hint function.

In this embodiment, the data interoperability protocol carries specific data to be transmitted through predefined data blocks, and the data format is defined by the asset class hierarchy. Fig. 22 is a schematic diagram of a format of a data block. Setting the block type to be 2 bits, and setting the block type value to be 2, namely representing the type of the block to be a data block; the header type is set to 6 bits, and the header type value is set to 0; the flag bit is set to 8 bits, 2 flag bits can be predefined, and the remaining 6 bits are reserved bits and are set to 0; the block length is set to 16 bits, indicating the length of the control block, in bytes, excluding the pad field length. Payload, variable length, specific data, protocol specifies that if there is a payload in a block, the payload must be preceded by a delimiter of one byte (0 xFF), if not, the recipient will process the error message, the payload must be a multiple of 4 bytes long, if not, it is padded with 0.

Fig. 23 is a schematic diagram showing a format of flag bits of a data block. Bit0 is a dcp (dictionary command) flag Bit, which is set to 0, which represents that the data does not adopt dictionary compression method, and is set to 1, which represents that the user end needs to download the attribute dictionary in the category attribute object in advance, i.e. a fixed number index represents the field of a certain attribute, thereby reducing the data occupation. Bit1 is a tp (type) flag Bit, set to 0, indicating that the published data is a category object, set to 1, indicating that the published data is an ontology object.

The data interoperability protocol defines a unified method for serializing asset objects as JASON. The JASON format identifies a string that can be read by all languages and can also be stored on disk or transmitted over a network.

In this embodiment, the credential block is primarily used to carry any digital signature signed by the message issuer. The credential block is used to protect the control block and the contents of the data block from tampering during transmission, and the data source is trusted. The format of the certificate block is the same as that of the data block, and the block type value in the certificate block is set to be 3, namely the type of the block is represented as the certificate block; the header type is set to 6 bits, and the header type value is set to 0; the flag bit is set to 8 bits, 3 flag bits can be predefined, and the remaining 5 bits are reserved bits and are set to 0.

Fig. 24 is a schematic diagram showing a format of the flag bit of the credential block. Bit0 is the SN (signer name) flag, which when set to 1, indicates that an identifier is required; bit1 is the SI (signer index) flag, which when set to 1, indicates that it contains a public key or X.509 certificate for verifying digital signatures; bit2 is a da (digestalgorithm) flag, set to 1, that specifies the digest algorithm (a UTF 8-String) that contains the generation of a digital signature, suggesting the use of "SHA-256".

An alternative to the credential block contains one or more fields prefixed by length, and the flag bit determines whether or not to contain these fields, which, if contained, must appear in this order: signer identifier (SN), Signer Index (SI), Digest Algorithm (DA), and Signature Data (SD).

Wherein, the content of the digital signature is the transmission block non-load part + control block + data block. The data interoperability protocol can be transmitted over most communication protocols, and when transmitted over a secure protocol, the data interoperability protocol messages do not need to be encrypted. Otherwise, the data interoperability protocol message may be encrypted according to the specification to protect sensitive information. Generating an encrypted data interoperability protocol message requires following steps:

1) obtaining an identifier of a recipient;

2) parsing the recipient identifier to obtain the public key of the recipient (e.g., RSA 2048);

3) encrypting the message body using the generated random symmetric key;

4) encrypting the generated random symmetric key using the public key of the receiver;

5) putting the encrypted message text into the message text;

6) placing the encrypted symmetric key into a credential block;

7) setting an encryption flag (EC) to 1 in a transport block;

8) signing the part to be signed by using a private key of a sender;

9) the signature is placed in the credential block.

When an encrypted data interoperability protocol message is received, the message needs to be processed following the following rules:

1) obtaining an identifier of the sender from a credential block of the message;

2) resolving the identifier of the sender to obtain the public key of the sender (or directly from the SI);

3) verifying the signature using the public key;

4) decrypting the symmetric key using the private key of the recipient;

5) decrypting the message body using the decrypted symmetric key;

6) the decrypted message body is processed.

In order to improve the transmission efficiency between the publishing client 110, the subscribing client 130 and the information management server 120, the data interoperability protocol of the present application adopts a mode of compressing transmission data first and then decompressing a receiving end. The data interoperability protocol may compress the ontology object defined by the category object, and both the publishing client 110 and the subscribing client 130 need to request the category dictionary first, and after obtaining the dictionary, may perform compression publishing or subscription decompression.

As shown in fig. 25, the publishing client 110 sends a request for registering a category object to the information managing server 120, and the information server 120 requests registration of the category object according to the registration category object; the publishing client 110 sends category dictionary request information to the information management server 120, and the information management server 120 returns a category dictionary to the publishing client 110 according to the category dictionary request information; the publishing client 110 compresses the ontology object according to the category dictionary to obtain a compressed ontology object, and publishes the compressed ontology object to the information management server 120. The information management server 120 receives a subscription category dictionary request sent by the subscription client 130, and returns a category dictionary and a compressed body object to the subscription client 130 according to the subscription category dictionary request; the subscription client 130 decompresses the compressed ontology object according to the category dictionary to obtain a decompressed ontology object.

As shown in fig. 26, the principle of the compression processing performed by the information management server 120 is: the information management server 120 assigns a serial number to each piece of meta-attribute information in the category object, such as meta-attribute information name assignment serial number 1, meta-attribute information production date assignment serial number 2, meta-attribute information manufacturer assignment serial number 3, and meta-attribute information model assignment serial number 4; the information management server 120 generates a category dictionary according to the serial number and the meta attribute information; the publishing client 110 compresses the meta attribute information according to the category dictionary, uses a character a with a smaller byte number to represent the name of the meta attribute information, and writes the character a and the sequence number 1 into the relational mapping table; using a character b with smaller byte number to represent the production date of the meta attribute information, and writing the character b and the serial number 2 into a relational mapping table; using a character c with smaller byte number to represent a meta attribute information manufacturer, and writing the character c and a serial number 3 into a relational mapping table; and (3) representing the meta attribute information model by using a character d with smaller byte number, and writing the character d and the serial number 4 into the relational mapping table. The publishing client 110 publishes the character and sequence number relation mapping table as a compressed ontology object to the information management server 120. When the subscribing client 130 decompresses, the corresponding meta-attribute information can be obtained in the information management server 120 according to the character and serial number relation mapping table. That is, because the character is associated with the serial number and the serial number is also associated with the original attribute information, the corresponding meta-attribute information can be obtained according to the serial number.

In this embodiment, the asset object management system 100 further comprises an identifier resolution device 140 and a blockchain device 150, and the identifier resolution device 140 and the blockchain device 150 are communicatively connected to the publishing client 110, the subscribing client 130 and the information management server 120.

The identification parsing device 140 is used for generating identification information for the asset object; the blockchain apparatus 150 is used for linking up the transaction consensus generated by the publishing client 110, the subscribing client 130 and the information management server 120; wherein the trade consensus is generated when the publishing client 110, the subscribing client 130 and the information management server 120 communicate the asset object through a data interoperability protocol.

The identification resolving device 140 locates the physical object (such as machine, article, etc.) and the virtual object (such as prediction model, data set, etc.) uniquely by using the identification, and determines the network address thereof. The blockchain device 150 links the transaction consensus achieved by transmitting data through the data interoperability protocol by using the characteristics of high transparency, decentralization, non-falsification and anonymity of the blockchain, so that any data transaction can be effectively traced and verified, and the credibility and authority of the industrial internet data service are further improved.

Referring to fig. 27, a schematic flowchart of an asset object management method provided in an embodiment of the present application is shown, where the asset object management method is based on the asset object management system 100 shown in fig. 1, and the asset object management method may include the following steps:

s401, the publishing client and the information management server are both used for generating asset objects according to the data interoperation protocol.

S402, the publishing client is also used for publishing the asset object to the information management server according to the data interoperation protocol.

S403, the information management server is further configured to send the asset object to the subscription client according to the data interoperability protocol.

It should be understood that the information management server 120, the publishing client 110 and the subscribing client 130 described above may cooperatively implement the above-described S401 to S403 and possible substeps thereof.

In summary, the present application provides an asset object management system and method, where the asset object management system includes a publishing client, a subscribing client and an information management server, and both the publishing client and the subscribing client are in communication connection with the information management server; the publishing client and the information management server are used for generating asset objects according to a data interoperation protocol; the publishing client is also used for publishing the asset object to the information management server according to the data interoperation protocol; the information management server is also used for sending the asset object to the subscription client according to the data interoperation protocol. The asset objects are published and subscribed through a data interoperation protocol, various transmission strategies of the data interoperation protocol ensure that the asset objects are compatible with adaptation of multiple protocols, the efficient compression method of the data interoperation protocol improves transmission efficiency and performance, and the data interoperation protocol has a data model structure with separated data categories and data instances and a safe and reliable transmission certificate.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. An asset object management system is characterized by comprising a publishing client, a subscribing client and an information management server, wherein the publishing client and the subscribing client are in communication connection with the information management server;

2. The asset object management system of claim 1, wherein said data interoperability protocol comprises a control block, a data block, and a credential block;

the publishing client and the information management server are both used for generating data information of the asset object according to the data block;

the release client and the information management server are both used for generating control information of the asset object according to the control block;

and the issuing client and the information management server are both used for generating verification encryption information of the asset object according to the certificate block.

3. The asset object management system of claim 2, wherein the publishing client and the information management server are each further configured to determine a data format of the data information according to a data block format;

wherein the data block format comprises a block type, a header type, a flag, a block length, a delimiter and a load; the block type is used for representing the type of the block; the head type is used for representing the functional category of the block; the flag bit is used for representing whether the data information is compressed or not, and the data information is a category object or a body object; the block length is used for characterizing the length of the data block; the load is used to characterize the data information.

4. The asset object management system according to claim 2, wherein said publishing client and said information management server are each further configured to determine a message format of control information of said asset object according to a control block format;

wherein the control block format comprises a block type, a header type, a flag bit and a block length; the block type is used for representing the type of the block; the head type is used for representing the functional category of the block; the zone bit is used for representing whether the control information carries one or more of a user name field, a password field and a token, the control information is a category object or a body object, and whether the control information is issued for the first time; the block length is used to characterize the length of the data block.

5. The asset object management system according to claim 2, wherein said publishing client and said information management server are each further configured to determine an information format of the authentication encryption information of said asset object according to a credential block format;

the voucher block format comprises a block type, a header type, a flag bit and a block length, wherein the block type is used for representing the type of a block; the head type is used for representing the functional category of the block; the flag bit is used for representing whether the verification encryption information comprises one or more of an identifier, a public key, a verification certificate and a digest algorithm; the block length is used to characterize the length of the data block.

6. The asset object management system of claim 1, wherein said data interoperability protocol further comprises a transport block;

the publishing client is also used for obtaining an operation flow for publishing the asset object to the information management server according to the transmission block;

and the information management server is also used for obtaining an operation flow for sending the asset object to the subscription client according to the transmission block.

7. The asset object management system of claim 6, wherein the publishing client and the information management server are further configured to determine the operation flow of the asset object as one of a retransmission mechanism, a multiple transmission mechanism, and an error correction mechanism based on a transport block format.

8. The asset object management system of claim 1, wherein said data interoperability protocol further comprises a base header for characterizing said data interoperability protocol base information, said base information comprising a version of said data interoperability protocol and a check code.

9. The asset object management system of claim 1, further comprising an identity resolution device and a blockchain device, said identity resolution device and said blockchain device being communicatively coupled to said publishing client, said subscribing client and said information management server;

the identification analysis equipment is used for generating identification information for the asset object;

the block chain equipment is used for chaining the transaction consensus generated by the publishing client, the subscribing client and the information management server; wherein the trade consensus is generated when the publishing client, the subscribing client and the information management server transmit asset objects through the data interoperability protocol.

10. An asset object management method is applied to an asset object management system, the asset object management system comprises a publishing client, a subscribing client and an information management server, and the publishing client and the subscribing client are both in communication connection with the information management server, and the method comprises the following steps: