CN107872441B

CN107872441B - Method and device for generating equipment attribute configuration file

Info

Publication number: CN107872441B
Application number: CN201610860749.2A
Authority: CN
Inventors: 彭耀; 刘智勇
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-09-28
Filing date: 2016-09-28
Publication date: 2021-08-17
Anticipated expiration: 2036-09-28
Also published as: CN107872441A

Abstract

The application provides a method and a device for generating a device attribute configuration file. The method comprises the following steps: determining a corresponding attribute in a message of a second protocol aiming at the attribute in the message of the first protocol; acquiring the identifier of the targeted attribute and the determined identifier of the corresponding attribute; and generating an equipment attribute configuration file so that the equipment attribute configuration file reflects the corresponding relation between the identifier of the corresponding attribute and the determined identifier of the corresponding attribute. The application provides a technology for generating a device attribute configuration file, and the device attribute configuration file generated by the technology can complete conversion between messages with device attributes of any different protocols.

Description

Method and device for generating equipment attribute configuration file

Technical Field

The present invention relates to the field of communications, and in particular, to a method and apparatus for generating device attribute profiles for conversion of messages of different protocols.

Background

In the prior art, the message conversion equipment generally only can support conversion between messages of fixed protocols. If a message conversion device needs to support conversion of messages of one protocol to messages of another protocol, it is generally necessary to consolidate the conversion method between the messages of the two protocols in the message conversion device at initialization. Message conversion equipment currently cannot convert messages of any different protocols.

Disclosure of Invention

One objective of the present application is to provide a technique for generating a device property profile, which can complete the conversion between messages with device properties of any different protocols.

According to an embodiment of the present application, there is provided a method of generating a device property profile for conversion of messages of a first protocol to messages of a second protocol, the method including:

determining a corresponding attribute in a message of a second protocol aiming at the attribute in the message of the first protocol;

acquiring the identifier of the targeted attribute and the determined identifier of the corresponding attribute;

and generating an equipment attribute configuration file so that the equipment attribute configuration file reflects the corresponding relation between the identifier of the corresponding attribute and the determined identifier of the corresponding attribute.

According to an embodiment of the present application, there is provided an apparatus for generating a device property profile for conversion of messages of a first protocol to messages of a second protocol, the apparatus including:

a corresponding attribute determining unit, configured to determine, for an attribute in a message of a first protocol, a corresponding attribute in a message of a second protocol;

a first identifier acquiring unit, configured to acquire an identifier of a targeted attribute and a determined identifier of a corresponding attribute;

and the equipment attribute configuration file generating unit is used for generating the equipment attribute configuration file so that the equipment attribute configuration file reflects the corresponding relation between the identifier of the corresponding attribute and the determined identifier of the corresponding attribute.

According to an embodiment of the present application, there is provided an apparatus for generating a device property profile for conversion of a message of a first protocol to a message of a second protocol, the apparatus including:

a memory for storing computer readable instructions;

a processor for executing computer readable instructions stored in the memory to:

According to an embodiment of the present application, there is provided a computer-readable medium having stored thereon a computer program which, when installed on a computer, causes the computer to execute:

In order to complete the conversion between the message of the first protocol and the message of the second protocol, the embodiment of the application determines the corresponding attribute in the message of the second protocol according to the attribute in the message of the first protocol, and then generates the device attribute configuration file according to the corresponding relationship between the identifier of the corresponding attribute and the identifier of the corresponding attribute determined. Thus, by referring to the device attribute configuration file, it is clearly known which attribute in the message of the first protocol corresponds to which attribute in the message of the second protocol, so that when the message of the first protocol and the message of the second protocol need to be converted, it can be known which attribute in the message of the first protocol should be converted into the message of the second protocol, respectively, thereby completing the automatic conversion. Therefore, the device attribute configuration file generated by the embodiment of the application can complete conversion between messages with device attributes of any different protocols.

Drawings

Other features, objects and advantages of the invention will become more apparent upon reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

FIG. 1 is a flow diagram of a method of generating a device property profile according to one embodiment of the present application.

Fig. 2a is one example of a message of a first protocol according to one embodiment of the present application.

Fig. 2b is one of examples of messages of a second protocol according to an embodiment of the present application.

FIG. 3 illustrates a template of a device properties profile according to an embodiment of the present application.

Fig. 4 is a specific example of a device property profile generated by an embodiment of the present application corresponding to fig. 2 a-b.

Fig. 5a is a second example of a message of a first protocol according to an embodiment of the present application.

Fig. 5b is a second example of a message of a second protocol according to an embodiment of the present application.

FIG. 6 illustrates a template of a device properties profile according to an embodiment of the present application.

FIG. 7 is a specific example of a device property profile generated by an embodiment of the present application corresponding to FIGS. 5 a-b.

FIG. 8 is a block diagram of an apparatus to generate a device property profile according to one embodiment of the present application.

FIG. 9 is a hardware block diagram of an apparatus to generate a device property profile according to one embodiment of the present application.

The same or similar reference numbers in the drawings identify the same or similar elements.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Before discussing exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be re-arranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figure. The processes may correspond to methods, functions, procedures, subroutines, and the like.

The computer equipment comprises user equipment and network equipment. Wherein the user equipment includes but is not limited to computers, smart phones, PDAs, etc.; the network device includes, but is not limited to, a single network server, a server group consisting of a plurality of network servers, or a Cloud Computing (Cloud Computing) based Cloud consisting of a large number of computers or network servers, wherein Cloud Computing is one of distributed Computing, a super virtual computer consisting of a collection of loosely coupled computers. The computer equipment can be independently operated to realize the application, and can also be accessed into a network to realize the application through the interactive operation with other computer equipment in the network. The network in which the computer device is located includes, but is not limited to, the internet, a wide area network, a metropolitan area network, a local area network, a VPN network, and the like.

It should be noted that the user equipment, the network device, the network, etc. are only examples, and other existing or future computer devices or networks may also be included in the scope of the present application, if applicable, and are included by reference.

The methods discussed below, some of which are illustrated by flow diagrams, may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a storage medium. The processor(s) may perform the necessary tasks.

Specific structural and functional details disclosed herein are merely representative and are provided for purposes of describing example embodiments of the present application. This application may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element may be termed a second element, and, similarly, a second element may be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements present. Other words used to describe the relationship between elements (e.g., "between" versus "directly between", "adjacent" versus "directly adjacent to", etc.) should be interpreted in a similar manner.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be noted that, in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may, in fact, be executed substantially concurrently, or the figures may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

The technical solution of the present application is further described in detail below with reference to the accompanying drawings.

FIG. 1 is a flow diagram of a method of generating a device property profile according to one embodiment of the present application. The method is performed by a message conversion device. The device attribute configuration file is a configuration file, which is referred to for conversion of messages of a first protocol and messages of a second protocol, and is defined with a mapping relationship between attributes in the messages of the first protocol and attributes in the messages of the second protocol. A message here refers to a message conveying device attributes. This approach is not applicable to messages carrying voice content and the like.

The mapping relationship between the attributes in the first protocol message and the attributes in the second protocol message includes the following two layers of meanings.

The first layer meaning is to which field in the second protocol message the attribute value of an attribute is mapped if the attribute in the first protocol message does not contain an attribute member (data type conversion is also needed if the data type of the attribute in the first protocol message and the data type of the corresponding attribute in the second protocol message are not consistent). For example, if the switch attribute identified as 00300001 in the first protocol message corresponds to the switch standard attribute identified as OnOff in the second protocol message, the switch attribute value in the field following the attribute identification 00300001 in the first protocol message is padded into the field following the attribute identification OnOff in the second protocol message.

The second layer meaning is that if a certain attribute in the first protocol message contains an attribute member, the attribute member value of the attribute is mapped to which field in the second protocol message (if the data type of the attribute member in the first protocol message is inconsistent with the data type of the corresponding attribute in the second protocol message, data type conversion is performed). An attribute member is a structured data component of an attribute when the attribute is structured data. For example, a color attribute is structured data that includes a red chroma attribute member, a blue chroma attribute member, and a green chroma attribute member. And filling the value of the attribute member with the attribute member identified as red in the first protocol message into a field behind the attribute identifier red colour in the second protocol message when the attribute member with the attribute member identified as red in the first protocol message corresponds to the red chroma standard attribute with the attribute identifier red colour in the second protocol message. And filling the value of the attribute member with the attribute member being identified as blue in the first protocol message into a field behind the attribute identification blue color in the second protocol message when the attribute member with the attribute member being identified as blue in the first protocol message corresponds to the blue color standard attribute with the attribute member being identified as blue color in the second protocol message. And filling the value of the attribute member with the attribute member identifier as the green in the first protocol message into a field behind the attribute identifier green in the second protocol message when the attribute member with the attribute member identifier as the green in the first protocol message corresponds to the green chroma standard attribute with the attribute member identifier as the green color in the second protocol message.

In a specific application scenario, the method is applied to an internet of things gateway, namely, the message conversion device is a logistics gateway. The first protocol is a communication protocol between the sub-equipment of the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for the internet of things gateway to communicate with a cloud server. An attribute is a variable indicating a state or parameter configuration of the child device in the internet of things. In one example, the device attributes are, for example, a switch attribute of the camera (indicating that the camera is in an on/off state), a camera resolution, an address of a server to which an image captured by the camera is to be transferred, a code stream rate, and the like. When a certain attribute of the camera is changed (e.g., by a switch), a message of the first protocol indicating the attribute change is sent to the message conversion device. The message conversion device converts the message of the first protocol into a message of a second protocol by referring to the device attribute configuration file of the embodiment of the application, and sends the message of the second protocol to the cloud server.

As shown in fig. 1, the method includes:

s110, determining a corresponding attribute in the message of the second protocol according to the attribute in the message of the first protocol;

s120, acquiring the identifier of the corresponding attribute and the determined identifier of the corresponding attribute;

s130, generating an equipment attribute configuration file, so that the equipment attribute configuration file reflects the corresponding relation between the identifier of the corresponding attribute and the determined identifier of the corresponding attribute.

These steps are described in detail below, respectively.

Step S110, determining a corresponding attribute in the message of the second protocol according to the attribute in the message of the first protocol.

Fig. 2a shows an example of a message of the first protocol. In this example, the message of the first protocol is a message that the lower contact sub-device of the internet of things reports the attribute change of the lower contact sub-device to the internet of things. Fig. 2b shows an example of a message of the second protocol. In this example, the message of the second protocol is a message that the internet of things gateway reports the attribute change of the subordinate device to the cloud server after receiving the message from the subordinate device for reporting the attribute change of the subordinate device. The first protocol is a kid device protocol. Different downstream sub-devices follow different sub-device protocols. The second protocol is a cloud connection protocol. The conversion of messages of the first protocol to messages of the second protocol needs to be performed at the internet of things gateway.

Taking fig. 2a as an example, the lower sub-device is a camera. When a certain attribute of the camera changes (for example, the switch attribute value changes from on to off), the camera needs to send a message of the first protocol as shown in fig. 2a to the internet of things gateway. The message carries an identifier 303 of four attributes (a switch attribute, a server address attribute, a resolution attribute, and a code stream rate attribute) of the camera, and a changed value 304 of the four attributes. The on/off attribute is an attribute indicating that the camera is in an on/off state. As shown in fig. 2a, the attribute is identified as 00300000. An attribute value of the switch attribute of 00 indicates that the camera is in an off state, and 01 indicates that the camera is in an on state. Since the switch attribute of the camera has been changed from on to off, the switch attribute value field in fig. 2a is 00. The server address attribute is a server address indicating that the camera is to establish a connection, that is, a server address to which an image captured by the camera is to be uploaded. In fig. 2a, the attribute is identified as 00300002, and the attribute value of the attribute is "host. The resolution attribute is the resolution of the camera. In fig. 2a, the attribute is identified as 00300003, and the attribute value of the attribute is 1024 × 768. The code stream rate attribute is the code stream rate of uploading the shot video by the camera. In FIG. 2a, the identification of the attribute is 00300004, and the attribute value of the attribute is 8000.

When the internet of things gateway needs to notify the cloud server of the change of the attribute of the camera, a message of a second protocol shown in fig. 2b, that is, a message of a cloud connection protocol needs to be sent to the cloud server. The message carries an identifier 351 of three attributes (switch standard attribute, code stream rate standard attribute, resolution standard attribute), and values 352 of the three attributes. The identifier of the switch standard attribute is OnOff, the identifier of the code stream rate standard attribute is dataRate, and the identifier of the resolution attribute is resolution.

In one embodiment, for an attribute in a message of a first protocol, determining a corresponding attribute in a message of a second protocol is performed with reference to a description of the meaning of each attribute in the first protocol and a description of the meaning of each attribute in the second protocol, wherein a particular attribute in the second protocol is determined to be a corresponding attribute in a message of the second protocol if the meaning of the particular attribute is the same as the meaning of the attribute targeted in the first protocol.

For example, referring to the description of the meaning of each attribute in the first protocol and the description of the meaning of each attribute in the second protocol, it is found that: for the switch attribute identified as 00300001 in FIG. 2a, the switch criteria attribute identified as OnOff in FIG. 2b has the same meaning as it, then the switch criteria attribute identified as OnOff is determined to be the corresponding attribute of the switch attribute identified as 00300001. For the server address attribute identified as 00300002 in FIG. 2a, there is no corresponding attribute in FIG. 2 b. For the resolution attribute identified as 00300003 in FIG. 2a, the resolution criteria attribute identified as resolution in FIG. 2b has the same meaning as it, then the resolution criteria attribute identified as resolution is determined to be the corresponding attribute of the resolution attribute identified as 00300003. For the codestream rate attribute identified as 00300004 in fig. 2a, the meaning of the codestream rate standard attribute identified as dataRate in fig. 2b is the same, and then it is determined that the codestream rate standard attribute identified as dataRate is the corresponding attribute of the codestream rate attribute identified as 00300004.

Step S120, acquiring the identifier of the targeted attribute and the determined identifier of the corresponding attribute.

In one embodiment, the messages of the first protocol and/or the messages of the second protocol contain both an identification of the attribute and a value of the attribute. This is the case for fig. 2a and 2 b. In this case, obtaining the identifier of the targeted attribute and the determined identifier of the corresponding attribute includes: the identification of the targeted property and the identification of the determined corresponding property are read directly from the message of the first protocol and/or the message of the second protocol.

In another embodiment, the messages of the first protocol and/or the messages of the second protocol contain only attribute values and do not contain an identification of an attribute. For example, fig. 2a does not contain the four fields numbered 303, and fig. 2b does not contain the three fields numbered 351. In this case, obtaining the identifier of the targeted attribute and the determined identifier of the corresponding attribute includes: and acquiring the identifier of the aimed attribute from the description of the aimed attribute value field in the first protocol, and acquiring the determined identifier of the corresponding attribute from the description of the determined corresponding attribute value field in the second protocol.

For example, the meaning of the fields of reference numeral 304 of FIG. 2a are explained in the first protocol, where there are identifications 00300001, 00300002, 00300003, 00300004 of the attributes to which the values in the fields correspond. Similarly, the meaning of the fields of reference number 352 of fig. 2b is explained in the second protocol, wherein there are identifications OnOff, dataRate, resolution of the attributes corresponding to the values in the fields.

Step S130, generating an equipment attribute configuration file, so that the equipment attribute configuration file represents a correspondence between the identifier of the targeted attribute and the determined identifier of the corresponding attribute.

Fig. 3 is a template of a device property profile. An example of a device properties profile generated for the message in fig. 2a and the message in fig. 2b is shown in fig. 4.

As shown in fig. 3, the template includes a mapping relationship from the attribute in the first protocol message to the attribute in the second protocol message, and optionally further includes an attribute identifier and a data type of the attribute in the first protocol message.

As shown in fig. 3, the first of the mapping relationship part from the attribute in the first protocol message to the attribute in the second protocol message is an identification field "attribute mapping relationship", and the following is a list of mapping relationships from the attribute in the first protocol message to the attribute in the second protocol message, where each item in the list is identified by "attribute identification name in the first protocol message": the "attribute identification name in the second protocol message" indicates.

Fig. 4 is a diagram showing a specific example of the template of fig. 3. As shown in fig. 4, the identification field "attribute mapping relationship" is embodied as "attribute _ mapping". "0x0030_0x0001": onOff "in fig. 4 denotes the switch criteria attribute identified as onOff in fig. 2b, which corresponds to the switch attribute identified as 00300001 in fig. 2 a. "0x0030_0x0004": data rate "in fig. 4 indicates that the bit stream rate standard attribute identified as data rate in fig. 2b corresponds to the bit stream rate attribute identified as 00300004 in fig. 2 a. "resolution" means, in FIG. 4, "0x0030_0x0003" that the attribute is identified as resolution standard attribute in FIG. 2b, which corresponds to the resolution attribute identified as 00300003 in FIG. 2 a.

In fig. 2b, 351 represents the identifier of the standard attribute, and 352 represents the value of the standard attribute.

Optionally, as shown in fig. 3, the template further includes an attribute identification and a data type of the attribute in the first protocol message. In this section, for each attribute in the first protocol message, the "attribute name in the first protocol message" is listed: { "data type": "data type value", "member": { }, "attribute identification in first protocol message": "attribute identification name in first protocol message" }. The "name of an attribute in a first protocol message" is the name of the attribute in the first protocol message. The "data type value" indicates a specific data type of the attribute, such as "boolean" type "," string type ". "data type" is a flag indicating that the subsequent field is a "data type value," which is the same for all child device attributes. The "attribute identification name in the first protocol message" indicates a specific identification name of an attribute in the first protocol message, such as 0x0030_0x 0001. The "attribute identification in the first protocol message" indicates that the subsequent field is "attribute identification name in the first protocol message", which is the same for all attributes. A "member": { } denotes that the attribute has no attribute members.

As shown in a specific example of fig. 4, "OnOff" is an attribute name of the switch attribute, "data _ type": "pool" indicates that the data type of the switch attribute is boolean, "attr _ id": 0x0030_0x0001 "indicates that the attribute identification of the switch attribute is 0x0030_0x 0001. "serverUrl" is an attribute name of the server address attribute, "data _ type": string "indicates that the data type of the server address attribute is a character string type," attr _ id ": 0x0030_0x 0002" indicates that the attribute identification of the server address attribute is 0x0030_0x 0002. "resolution" is an attribute name of the resolution attribute, "data _ type": string "indicates that the data type of the resolution attribute is a character string type," attr _ id ": 0x0030_0x0003" indicates that the attribute identification of the resolution attribute is 0x0030_0x 0003. "dataRate" is an attribute name of the codestream rate attribute, "data _ type": int32 "indicates that the data type of the codestream rate attribute is 32-integer number," attr _ id ": 0x0030_0x0004" indicates that the attribute identification of the codestream rate attribute is 0x0030_0x 0004.

In this way, when the message of the first protocol shown in fig. 2a needs to be converted into the message of the second protocol shown in fig. 2b, referring to the correspondence relationship between the attribute in the message of the first protocol and the attribute in the message of the second protocol in the device attribute configuration file of fig. 4, the value 00 of the attribute identified as 00300001 in fig. 2a is filled in the field of the value of the attribute identified as OnOff in fig. 2b, the value "1024 × 768" of the attribute identified as 00300003 in fig. 2a is filled in the field of the value of the attribute identified as resolution in fig. 2b, and the value "8000" of the attribute identified as 00300004 in fig. 2a is filled in the field of the value of the attribute identified as dataRate in fig. 2 b. The resulting message of the second protocol is shown in fig. 2 b.

In one embodiment, the method further comprises (these steps are not shown in the figure):

acquiring the data type of the aimed attribute;

the data type body of the targeted attribute is presented in the device attribute profile.

In one embodiment, obtaining the data type of the attribute for comprises: the data type of the targeted attribute is obtained from the specification of the identification field and/or the value field of the targeted attribute in the first protocol.

For example, the 00300001 identification field in fig. 2a is described in the first protocol to represent a switch attribute, and the value of the switch attribute is boolean.

"data _ type" in fig. 3: "cool", "data _ type": "string", "data _ type": "string" is the representation of the data type of the attribute in question in the device attribute profile.

The significance of presenting the data type of the targeted attribute in the device attribute configuration file is that when the device attribute configuration file is referred to for conversion between the message of the first protocol and the message of the second protocol, if the device attribute configuration file is referred to, the data type of the targeted attribute is found to be inconsistent with the determined data type of the corresponding attribute, the targeted attribute value is firstly converted into the determined data type of the corresponding attribute, and then the data type of the corresponding attribute is mapped into the message of the second protocol, so that the conversion accuracy can be improved.

Optionally, the method may further comprise (not shown):

acquiring the determined data type corresponding to the attribute;

and displaying the determined data type body corresponding to the attribute in the equipment attribute configuration file.

In one embodiment, the obtaining the determined data type of the corresponding attribute includes: and acquiring the data type of the determined corresponding attribute from the description of the identification field and/or the value field of the determined corresponding attribute in the second protocol.

For example, the OnOff flag field of fig. 2b in the second protocol is described as representing a switch standard attribute, and the value of the switch standard attribute is boolean.

The data type of the determined corresponding attribute is not represented in fig. 3-4, but the data type of the determined corresponding attribute may also be represented in the device attribute profile, if desired.

For example, the data type specifying the resolution attribute in the message of the first protocol in the device attribute profile of fig. 4 is a string type, such as "1024 × 768". In the case where only two resolutions are used by default, namely high definition "1024 × 768" and low definition "512 × 384", it is also possible to specify in the message of the second protocol that the resolution criteria attribute is of boolean type (not shown in fig. 4), i.e. 1 for high definition "1024 × 768" and 0 for low definition "512 × 384". Thus, the value "1024 × 768" of the resolution attribute in the message of fig. 2a is converted into a boolean, i.e., converted into "1", and then filled in the resolution standard attribute value field following the resolution standard attribute identification resolution in the message as shown in fig. 2 b.

Additionally, in one embodiment, the method further comprises (these steps are not shown):

if the targeted attribute has a plurality of attribute members, determining a corresponding attribute or attribute member in the message of the second protocol for each attribute member;

acquiring the identifier of the targeted attribute member and the determined identifier of the corresponding attribute or attribute member;

and correspondingly embodying the identification of the aimed attribute member and the determined corresponding attribute or the identification of the attribute member in the equipment attribute configuration file.

Attribute members are components of an attribute. For example, a first protocol specifies that a color attribute has three components: a red chroma attribute member, a green chroma attribute member, and a blue chroma attribute member. Fig. 5a shows an example of a message of the first protocol sent to the gateway of the internet of things when the property of a certain bulb changes. The message has a color attribute, identified as 00300005, whose value is a structured datum, represented by the values of its three attribute members, red chroma attribute member, green chroma attribute member, blue chroma attribute member, two out of the two ": "spaced apart" means. Fig. 5b illustrates a message of a second protocol sent to the cloud server notifying of a change in the property of the bulb when the internet of things gateway receives the message of the first protocol from the bulb as illustrated in fig. 5 a. The message has: a red color identifier field and a red color identifier field of the red color standard attribute; a field of green color standard attribute and a value field of green color standard attribute; a field of the blue color standard attribute identifying blue color and a value field of the blue color standard attribute.

In one embodiment, in the case of a targeted attribute having a plurality of attribute members, the determination of the corresponding attribute or attribute member in the message of the second protocol for each attribute member is made with reference to the meaning specification of the respective attribute member in the first protocol and the meaning specification of the respective attribute and attribute member in the second protocol, wherein a particular attribute or particular attribute member in the second protocol is determined to be the corresponding attribute or corresponding attribute member in the message of the second protocol if the meaning of the particular attribute or particular attribute member in the second protocol is the same as the meaning of the targeted attribute member in the first protocol.

For example, referring to the description of the meaning of each attribute member in the first protocol and the description of the meaning of each attribute and attribute member in the second protocol, it is found that: for the first attribute member of the color attribute identified as 00300005 in FIG. 5a (i.e., the Red chroma attribute member whose value is the first 04 of 04:02: 04), the Red chroma standard attribute identified as red chroma in FIG. 5b has the same meaning as it, then the Red chroma standard attribute identified as red chroma is determined to be the corresponding attribute member of the first attribute member of the color attribute identified as 00300005 (i.e., the Red chroma attribute member).

In one embodiment, obtaining the identifier of the targeted attribute member and the determined identifier of the corresponding attribute or attribute member includes:

if the identification of the corresponding attribute member and the identification of the determined corresponding attribute or attribute member can be respectively read from the message of the first protocol and the message of the second protocol, the identification of the corresponding attribute member and the identification of the determined corresponding attribute or attribute member are directly read; otherwise, acquiring the identifier of the targeted attribute member from the description of the targeted attribute member in the first protocol, and acquiring the determined identifier of the corresponding attribute or attribute member from the description of the determined corresponding attribute or attribute member in the second protocol.

Take fig. 5a and 5b as an example. The identity of the red chroma attribute member for which it is intended cannot be read directly from fig. 5a, but the first "to structured data in the color attribute value field following color attribute identity 00300005 in the first protocol: in the description of the foregoing values, it can be seen that: this value is the value of the Red chroma attribute member, whose identification is red. The identity red colour of the determined corresponding attribute (red chrominance standard attribute) can be read directly from fig. 5 b.

Fig. 6 is a schematic diagram of one template of a device attribute profile in the case of an attribute having an attribute member in a first protocol message. As shown in fig. 6, the template includes a mapping relationship from the attribute or the attribute member in the first protocol message to the attribute or the attribute member in the second protocol message, and optionally further includes an attribute identifier and an attribute data type of the attribute member of the attribute in the first protocol message.

As shown in fig. 6, the first of the mapping relationship part from the attribute or attribute member in the first protocol message to the attribute or attribute member in the second protocol message is an identification field "attribute mapping relationship ═", and then a list of the mapping relationship from the attribute or attribute member in the first protocol message to the attribute or attribute member in the second protocol message, where each item in the list is identified by "attribute or attribute member in the first protocol message": the "attribute or attribute member identification name in the second protocol message" indicates. Fig. 7 is a diagram showing a specific example of the template of fig. 6. As shown in fig. 7, the identification field "attribute mapping relationship" is embodied as "attribute _ mapping". "0x0030_0x0001": onOff "in fig. 7 denotes the switch criteria attribute identified as onOff in fig. 5b, which corresponds to the switch attribute identified as 00300001 in fig. 5 a. "red color" in FIG. 7 means that the red color standard attribute with the attribute identified as red color in FIG. 5b corresponds to the attribute member identified as red, or the attribute member before the first semicolon in the value of the color attribute with the attribute identified as 00300005 in FIG. 5 a. "green color" in FIG. 7 means that the green chroma standard attribute identified as green color in FIG. 5b corresponds to the attribute member identified as green, or the attribute member preceding the second semicolon in the value of the chroma attribute identified as 00300005 in FIG. 5 a. "blue colour" in FIG. 7 means that the blue colour standard attribute, identified as blue colour in FIG. 5b, corresponds to the attribute member identified as blue, or the attribute member following the second semicolon in the value of the chromatic attribute identified as 00300005 in FIG. 5 a.

Optionally, as shown in fig. 6, the template further includes: attribute identification and data type of the attribute of the message of the first protocol in the case of no attribute member of the attribute of the message of the first protocol, and attribute identification and data type of the attribute of the message of the first protocol in the case of attribute member of the attribute of the message of the first protocol, attribute member identification and data type of the attribute member of the message of the first protocol.

In one embodiment, as shown in fig. 6, in the case that the attribute of the message of the first protocol has no attribute member, the attribute identification and the data type of the attribute of the message of the first protocol are defined as follows:

"attribute name of message of first protocol": { "data type": the "data type value",

a "member": { }, "attribute identification of message of first protocol": "attribute identification name of message of first protocol" }

The "attribute name of the message of the first protocol" is a name of an attribute of the message of the first protocol. The "data type value" indicates a specific data type of an attribute of the message of the first protocol, for example, "boolean type", "string type". The "data type" is a flag indicating that the subsequent field is a "data type value", which is the same for all attributes. The "attribute identification name of the message of the first protocol" indicates a specific identification name of an attribute of the message of the first protocol, such as 0x0030_0x 0001. The "attribute identification of the message of the first protocol" is a field indicating that the subsequent field is "attribute identification name of the message of the first protocol" which is the same for all attributes. A "member": { } denotes that the attribute has no child device attribute members.

This section is embodied in the following form in the example of fig. 7:

"OnOff":{"data_type":"bool",

"element":{},"attr_id":"0x0030_0x0001"}

wherein "OnOff" is the attribute name of the switch attribute, "data _ type": bol "indicates that the data type of the switch attribute is Boolean type," attr _ id ": 0x0030_0x0001" indicates that the attribute identification of the switch attribute is 0x0030_0x 0001.

In one embodiment, as shown in fig. 6, in the case that the attribute in the first protocol message has an attribute member, the attribute identification and data type of the attribute in the first protocol message, and the attribute member identification and data type of the attribute member in the first protocol message are defined as follows:

"attribute name in first protocol message": { "data type": the "data type value",

a "member": [ attribute member identification in first protocol message ]: attribute member identification name in first protocol message, Attribute member data type in first protocol message

The attribute member data type value of' },

……

"attribute identification in first protocol message": "attribute identification name in first protocol message" }

This section is embodied in the following form in the example of fig. 7:

that is, the attribute name of the color child device attribute is "colour", the attribute identification is "0x0030 — 0x 0005", and the attribute data type is structured data. The method comprises three attribute members, wherein the attribute member of a red attribute member is marked as 'red', and the data type is 8-bit integer number; the attribute member of the green attribute member is marked as green, and the data type is 8-bit integer number; the blue attribute member's attribute member is identified as "blue" and the data type is an 8-bit integer number.

As an example of correspondingly embodying the identifier of the targeted attribute member and the determined corresponding attribute or the identifier of the attribute member in the device attribute configuration file, "red color" in fig. 7 represents that the red color attribute member identified as red in the color attribute in fig. 5a is mapped to the red color standard attribute identified as red color in the message of the second protocol shown in fig. 5 b; "green color" in FIG. 7 represents that the green chroma attribute member identified as green in the color attribute of FIG. 5a is mapped to the green chroma standard attribute identified as green color in the message of the second protocol shown in FIG. 5 b; "blue color" in FIG. 7 means that the blue color attribute member identified as blue in the color attribute in FIG. 5a is mapped to the blue color standard attribute identified as blue color in the message of the second protocol shown in FIG. 5 b.

Thus, when it is desired to convert the message of the first protocol shown in FIG. 5a to the message of the second protocol shown in FIG. 5b, the first 04 of the color attribute values 04:02:04 in FIG. 5a is mapped to the field following the red colour identification field in the message of the second protocol shown in FIG. 5b based on "red": red colour "in the device attribute profile as shown in FIG. 7; mapping 02 of color attribute values 04:02:04 in fig. 5a to fields behind a green color identification field in a message of a second protocol shown in fig. 5b based on "green" in the device attribute configuration file; based on "blue": blue color "in the device attribute profile, the second 04 of the color attribute values 04:02:04 in fig. 5a is mapped to the field following the blue color identification field in the cloud connection protocol message shown in fig. 5 b. The internet of things gateway can send the converted message of the second protocol as shown in fig. 5b to the cloud server.

acquiring the data type of the targeted attribute member;

the data type body of the targeted attribute member is presented in the device attribute profile.

In one embodiment, obtaining the data type of the attribute member for comprises: the data type of the targeted attribute member is obtained from the description of the value field of the attribute to which the targeted attribute member belongs in the first protocol.

For example, the color attribute value field of fig. 5a in the description of the first protocol will describe that the color attribute value is a structured data, which is divided by 2 "from the middle: the red chroma attribute member value, the green chroma attribute member value and the blue chroma attribute member value are separated, wherein the red chroma attribute member, the green chroma attribute member and the blue chroma attribute member are all 8-bit shaping numbers.

The data type body of the targeted property member is then presented in the device property profile. In the example of fig. 7, only the data type bodies of the targeted attribute members (red chroma attribute member, green chroma attribute member, blue chroma attribute member) are present in the device attribute profile, i.e., "data _ type": "bit 8" because by default the attributes and data types of the attribute members in the second protocol are well known (because in this example, the second protocol is the cloud connection protocol). However, it is also possible to actually present the data type body of the determined corresponding attribute or attribute member in the device attribute profile.

In one embodiment, the method further comprises (not shown):

acquiring the determined data type of the corresponding attribute or the attribute member;

and displaying the determined data type body of the corresponding attribute or the attribute member in the device attribute configuration file.

In one embodiment, the obtaining the determined data type of the corresponding attribute or the attribute member includes: and acquiring the data type of the determined corresponding attribute or attribute member from the description of the identification field and/or the value field of the determined corresponding attribute or attribute member in the second protocol.

For example, the data types of the three determined attributes (red color standard attribute, green color standard attribute, and blue color standard attribute) are obtained from the descriptions of the identification fields and/or the value fields of the three attributes in the second protocol, which are all 16-bit integer numbers, for example.

The significance of representing the data type of the targeted attribute member and/or the determined corresponding attribute or data type of the attribute member in the device attribute configuration file is as follows: when the message of the first protocol is converted with the message of the second protocol, if the data type of the corresponding attribute member and/or the determined data type of the corresponding attribute or the attribute member are not consistent, the value of the corresponding attribute member is converted into the determined data type of the corresponding attribute or the attribute member, and then the message of the second protocol is filled.

As in the above example, since the device attribute profile of fig. 7 specifies that the red chroma attribute member, the green chroma attribute member, and the blue chroma attribute member are all 8-bit shaping numbers, whereas the red chroma standard attribute, the green chroma standard attribute, and the blue chroma standard attribute are all 16-bit shaping numbers in the second protocol, when converting the message of the first protocol shown in fig. 5a to the message of the second protocol shown in fig. 5b, the last field of fig. 5a is first ": "the preceding 04 is converted to a 16-bit reshaped number and then filled in the field following the field identifying red colour in FIG. 5 b; first of the last field of fig. 5a ": "the latter 02 is converted into a 16-bit reshaped number and then filled into the field following the field identifying green color in fig. 5 b; second of the last field of fig. 5a ": "the following 04 is converted to a 16-bit shaped number and then filled in the field following the field identifying blue colour in FIG. 5 b.

Therefore, when the data type of the corresponding attribute member and/or the determined corresponding attribute or the data type of the attribute member are not consistent, the accuracy of conversion between the message of the first protocol and the message of the second protocol is improved through the conversion of the data type.

In one embodiment, the method further comprises: and listing and embodying the attribute identification of the attribute in the message of the first protocol and/or the attribute identification of the attribute in the message of the second protocol in a device attribute configuration file.

For example, "attr _ id" in fig. 4: "0x0030 — 0x0001" indicates the switch attribute identification of 00300001 in the message of fig. 2 a; "attr _ id" in fig. 4: "0x0030 — 0x 0002" represents the identification of the server address attribute in the message of fig. 2a as 00300002; "attr _ id" in fig. 4: "0x0030 — 0x0003" represents the identification of the resolution attribute in the message of FIG. 2a as 00300003; "attr _ id" in fig. 4: "0x0030 — 0x0004" represents the code stream rate attribute in the message of fig. 2a as identified at 00300004. In fig. 4, the attribute identifier list of the attribute in the message of the second protocol is not shown in the device attribute configuration file, but actually, the attribute identifier list of the attribute in the message of the second protocol may be shown in the device attribute configuration file.

It is not necessary to enumerate the attribute identifications of the attributes in the messages of the first protocol and/or the attribute identifications of the attributes in the messages of the second protocol in the device attribute profile, since these identifications can also be found in the first protocol and the second protocol. The advantage of enumerating them here is that these identifiers need to be referred to when parsing the correspondence (as in the upper part of fig. 4) between the identifier of the addressed attribute and the determined identifier of the corresponding attribute in the generated device attribute profile, and if not enumerated here, it needs to be looked up in the first protocol and the second protocol, reducing the conversion efficiency.

In one embodiment, if the attributes in the messages of the first protocol have attribute members, the identification of the attribute members of the attributes in the messages of the first protocol and/or the identification of the attribute members of the attributes in the messages of the second protocol are listed in the device attribute profile.

For example, "element _ name" in fig. 7: "red" indicates that the identity of the Red chroma attribute member in the message of FIG. 5a is red; "element _ name" in fig. 7: "green" indicates the green chroma attribute member's identification in the message of FIG. 5a as green; "element _ name" in fig. 7: "blue" indicates that the identity of the blue chroma attribute member in the message of FIG. 5a is blue. In fig. 7, the identification of the attribute member of the attribute in the message of the second protocol is not listed in the device attribute profile, but the identification of the attribute member of the attribute in the message of the second protocol may be listed in the device attribute profile.

The advantage of having the identification of the attribute member of the attribute in the message of the first protocol and/or the identification of the attribute member of the attribute in the message of the second protocol listed here is that these identifications need to be referred to when resolving the correspondence (as in the upper part of fig. 7) between the identification of the targeted attribute member and the determined corresponding attribute or identification of the attribute member, and if not listed here, it needs to be looked up in the first protocol and the second protocol, reducing the conversion efficiency.

In one embodiment, step S130 includes: the device property profile is generated with a lua or JS script.

The benefit of generating the device property profile with the lua or JS script is: the configuration file is described by the lua or the JS script in the internet of things gateway, so that the function of mutual conversion between the cloud connection protocol and the network access protocol of the sub-equipment can be realized conveniently.

As shown in fig. 8, according to an embodiment of the present application, there is further provided an apparatus 6 for generating a device property profile, wherein the device property profile is used for converting a message of a first protocol and a message of a second protocol. The device 6 comprises:

a corresponding attribute determining unit 610, configured to determine, for an attribute in a message of a first protocol, a corresponding attribute in a message of a second protocol;

a first identifier obtaining unit 620, configured to obtain an identifier of the targeted attribute and a determined identifier of the corresponding attribute;

the device attribute configuration file generating unit 630 is configured to generate a device attribute configuration file, so that the device attribute configuration file represents a correspondence between the identifier of the targeted attribute and the determined identifier of the corresponding attribute.

Optionally, the device 6 is used for an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub device of the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for communication between the logistics gateway and a cloud server.

Optionally, the attribute is a variable indicating a state or parameter configuration of the child device in the internet of things.

Optionally, the apparatus further comprises:

a first data type acquisition unit (not shown) for acquiring a data type of the attribute to which the attribute is directed;

a first supplemental embodiment unit (not shown) for embodying the data type body of the targeted property in the device property profile.

Optionally, the apparatus further comprises:

a second data type obtaining unit (not shown) for obtaining the determined data type corresponding to the attribute;

a second supplemental embodiment unit (not shown) for presenting the determined data type of the corresponding attribute in the device attribute profile.

Optionally, the apparatus further comprises:

a corresponding attribute or attribute member determination unit (not shown) configured to determine, for each attribute member, a corresponding attribute or attribute member in the message of the second protocol, if the attribute to be addressed has a plurality of attribute members;

a second identifier obtaining unit (not shown) configured to obtain an identifier of the targeted attribute member and the determined corresponding attribute or identifier of the attribute member;

and a third supplementary embodiment unit (not shown) for correspondingly embodying the identifier of the targeted attribute member and the determined corresponding attribute or identifier of the attribute member in the device attribute configuration file.

Optionally, the apparatus further comprises:

a third data type acquisition unit (not shown) for acquiring the data type of the targeted attribute member;

a fourth supplemental embodiment unit (not shown) is used to present the data type body of the targeted property member in the device property profile.

Optionally, the apparatus further comprises:

the fourth data type acquisition unit is used for acquiring the determined data type of the corresponding attribute or the attribute member;

and the fifth supplementary embodiment unit is used for displaying the determined data type of the corresponding attribute or the attribute member in the equipment attribute configuration file.

Optionally, the apparatus further comprises:

a sixth supplemental embodying unit (not shown) configured to enumerate attribute identifiers of the attributes in the message of the first protocol and/or attribute identifiers of the attributes in the message of the second protocol in the device attribute configuration file.

Optionally, the apparatus further comprises:

a seventh complementary embodying unit (not shown) for embodying the identification of the attribute member of the attribute in the message of the first protocol and/or the identification of the attribute member of the attribute in the message of the second protocol in the device attribute profile.

Alternatively, the device property profile generating unit generates the device property profile in a lua or JS script.

As shown in fig. 9, according to an embodiment of the present application, there is further provided an apparatus 9 for generating a device attribute profile, where the device attribute profile is used for converting a message of a first protocol into a message of a second protocol, and the apparatus 9 includes:

a memory 901 for storing computer readable instructions;

a processor 902 for executing computer readable instructions stored in a memory to:

Optionally, the device is an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub-device of the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for communication between the logistics gateway and a cloud server.

Optionally, the processor further executes computer readable instructions stored in the memory to:

acquiring the data type of the aimed attribute;

acquiring the determined data type corresponding to the attribute;

acquiring the data type of the targeted attribute member;

and listing and embodying the attribute identification of the attribute in the message of the first protocol and/or the attribute identification of the attribute in the message of the second protocol in a device attribute configuration file.

the identification of the attribute members of the attributes in the messages of the first protocol and/or the identification of the attribute members of the attributes in the messages of the second protocol are listed in a device attribute profile.

Optionally, generating the device property profile includes: the device property profile is generated with a lua or JS script.

There is also provided, in accordance with an embodiment of the present application, a computer-readable medium having a computer program stored thereon, the computer program, when installed on a computer, causing the computer to perform:

Optionally, the computer is used as an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub-device of the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for communication between the logistics gateway and a cloud server.

Optionally, the computer program, when installed on a computer, further causes the computer to perform:

acquiring the data type of the aimed attribute;

Optionally, the computer program, when installed on a computer, causes the computer to perform:

acquiring the determined data type corresponding to the attribute;

acquiring the data type of the targeted attribute member;

It should be noted that some of the present invention can be applied as a computer program product, for example, computer program instructions, which when executed by a computer, can invoke or provide the method and/or technical solution according to the present invention through the operation of the computer. Program instructions which invoke the methods of the present invention may be stored on a fixed or removable recording medium and/or transmitted via a data stream on a broadcast or other signal-bearing medium and/or stored within a working memory of a computer device operating in accordance with the program instructions. An embodiment according to the invention herein comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to perform a method and/or solution according to embodiments of the invention as described above.

It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. A plurality of units or means recited in the system claims may also be implemented by one unit or means in software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.

Claims

1. A method of generating a device properties profile for conversion of messages of a first protocol to messages of a second protocol, the method comprising:

generating an equipment attribute configuration file, so that the equipment attribute configuration file reflects the corresponding relation between the identifier of the targeted attribute and the determined identifier of the corresponding attribute;

in the event that the attribute being addressed has a plurality of attribute members, determining for each attribute member a corresponding attribute or attribute member in the message of the second protocol, the attribute member being a structured data component of the attribute when the attribute is structured data;

defining the identification of the attribute member and the identification of the determined corresponding attribute or attribute member for the attribute member without identification;

correspondingly embodying the identifier of the corresponding attribute member and the determined corresponding attribute or the identifier of the attribute member in an equipment attribute configuration file;

listing the identification of the attribute member of the attribute in the message of the first protocol and/or the identification of the attribute member of the attribute in the message of the second protocol into a device attribute configuration file;

the step of generating a device property profile comprises: the device property profile is generated with a lua or JS script.

2. The method according to claim 1, wherein the method is used for an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub-device under the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for the logistics gateway to communicate with a cloud server.

3. The method of claim 2, wherein the attribute is a variable indicating a status or parameter configuration of the child device in the internet of things.

4. The method of claim 1, further comprising:

acquiring the data type of the aimed attribute;

5. The method of claim 1, further comprising:

acquiring the determined data type corresponding to the attribute;

6. The method of claim 1, further comprising:

acquiring the data type of the targeted attribute member;

7. The method of claim 1, further comprising:

8. The method of claim 1, further comprising:

9. An apparatus for generating a device properties profile for conversion of messages of a first protocol to messages of a second protocol, the apparatus comprising:

the device attribute configuration file generation unit is used for generating a device attribute configuration file so that the device attribute configuration file reflects the corresponding relation between the identifier of the corresponding attribute and the determined identifier of the corresponding attribute;

the device attribute configuration file generation unit generates the device attribute configuration file with a lua or JS script.

10. An apparatus for generating a device properties profile for conversion of messages of a first protocol to messages of a second protocol, the apparatus comprising:

a memory for storing computer readable instructions;

the device property profile is generated with a lua or JS script.

11. The device of claim 10, wherein the device is an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub-device connected to the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for communication between the logistics gateway and a cloud server.

12. The apparatus of claim 11, wherein the attribute is a variable indicating a status or parameter configuration of the child device in the internet of things.

13. The apparatus of claim 10, wherein the processor further executes computer readable instructions stored in the memory to:

acquiring the data type of the aimed attribute;

14. The apparatus of claim 10, wherein the processor further executes computer readable instructions stored in the memory to:

acquiring the determined data type corresponding to the attribute;

15. The apparatus of claim 10, wherein the processor further executes computer readable instructions stored in the memory to:

acquiring the data type of the targeted attribute member;

16. The apparatus of claim 10, wherein the processor further executes computer readable instructions stored in the memory to:

17. The apparatus of claim 10, wherein the processor further executes computer readable instructions stored in the memory to:

18. A computer-readable medium having stored thereon a computer program which, when installed on a computer, causes the computer to perform:

generating the device property profile includes: the device property profile is generated with a lua or JS script.

19. The computer-readable medium of claim 18, wherein the computer is configured to serve as an internet of things gateway of the internet of things, the first protocol is a communication protocol between a sub-device under the internet of things gateway and the internet of things gateway, and the second protocol is a cloud connection protocol for the logistics gateway to communicate with a cloud server.

20. The computer-readable medium of claim 19, wherein the attribute is a variable indicating a status or parameter configuration of the kid device in the internet of things.

21. The computer-readable medium of claim 18, wherein the computer program, when installed on a computer, further causes the computer to perform:

acquiring the data type of the aimed attribute;

22. The computer-readable medium of claim 18, wherein the computer program, when installed on a computer, causes the computer to perform:

acquiring the determined data type corresponding to the attribute;

23. The computer-readable medium of claim 18, wherein the computer program, when installed on a computer, causes the computer to perform:

acquiring the data type of the targeted attribute member;

24. The computer-readable medium of claim 18, wherein the computer program, when installed on a computer, causes the computer to perform:

25. The computer-readable medium of claim 18, wherein the computer program, when installed on a computer, causes the computer to perform: