KR20180108505A - Method for transforming data for low volume transmission of meta model base protocol, and data transmitting system for low volume transmission of meta model base protocol - Google Patents

Abstract

The present invention provides a method for transforming data for the low volume transmission of a meta model base protocol, and a data transmitting system for the low volume transmission of a meta model base protocol. The method includes: a step of generating energy sensing data; a step of allowing a client to receive the energy sensing data and converting it into meta model data including a meta model and meta data; a step of generating packet meta model data by dividing the meta model data; a step of transmitting the packet meta model data to a server through an IoT communication network; and a step of allowing the server to parse the packet meta model data to output the meta model data. It is possible to perform data transmission/reception using the IoT communication network.

Description

TECHNICAL FIELD [0001] The present invention relates to a data transformation method for a low-capacity transmission of a metamodel-based protocol and a data transmission system for a low-capacity transmission of a metamodel-based protocol. BACKGROUND ART [0002] MODEL BASE PROTOCOL}

The present invention relates to a data transformation method for low capacity transmission of a metamodel based protocol and a data transmission system for low capacity transmission of a metamodel based protocol.

In order to monitor generation data of new and renewable energy, it is necessary to be able to confirm the real-time generation amount information by communicating with inverters, connection boxes and sensor devices in each power plant. The client that collects the information of each inverter transmits data to the server. At this time, each inverter is not the same inverter and different communication method should be used. The client also collects each inverter data and delivers it to the integration server. In order to integrate these heterogeneous data, we send the data to the metamodel.

Numerous inverter data is transmitted, all of which are converted to a metamodel and transferred from the local server to the consolidation server. These metamodel data are generated every 10 seconds in each inverter, and when they are connected to the web, they receive data every 10 seconds and provide real time information. However, when monitoring over a TCP / IP leased line or an LTE wireless communication network, costs of 2-3,000 won / month information will be incurred.

On the other hand, IoT network costs 200-2200 won per month, which is relatively inexpensive. However, since the transmission speed of the IoT network is relatively slow, there is a problem that many errors occur in transmitting the metamodel data.

The present invention relates to a method and apparatus for transmitting and receiving data by using a low-capacity internet protocol (IoT communication network) having a relatively small capacity and a transmission rate without losing metamodel data incorporating heterogeneous data, And a system for transforming data for transmission.

According to an aspect of the present invention, there is provided a method of transforming data for low capacity transmission of a metamodel-based protocol, the method comprising: generating energy sensing data; The client receiving the energy sensing data and converting it into metamodel data including a metamodel and meta data; Compressing the meta model data to generate packet meta model data; Transmitting the packet meta model data to a server through an object internet communication network; And parsing the packet meta model data by the server to output the meta model data.

Here, the object Internet communication network may be a LoRa network.

The data transformation method for low-capacity transmission of the metamodel-based protocol may further include generating a key table through a key table creator and storing the generated key table in a database, and dividing the metamodel data into packet metamodel data The creating step may include a step in which the data packet creator divides the meta model data using the key table to generate the packet meta model data.

Here, the server parsing the packet meta model data and outputting the meta model data may include parsing the packet meta model data using the key table.

The data transformation method for low-capacity transmission of the metamodel-based protocol may further include acquiring transmission rate information of the object Internet communication network, and generating packet metamodel data by dividing the metamodel data Determining a reference size of the packet meta model data based on the transmission rate information; And dividing the meta model data based on the reference size.

The step of generating the key table through the key table creator and storing the key table in the database may include generating the key table using the attribute information of the meta model.

Here, the key table may include an ID field, a key field, a class name field, a name field property field, a size field, a parental field, and a difference field.

The generating of the packet meta model data by dividing the meta model data may include inputting the meta data using an insert query statement in the key table and compressing the meta model data to generate compressed data step; And dividing the compressed data to generate a plurality of packet meta model data.

Here, the step of generating the key table using the meta model attribute information may include loading Epkage information, which is a top model of the meta model, Identifying eClassifires that are dependent on the Epackage information; Storing the EClass name attribute information in the key after storing the key if the eClassifires are confirmed; Confirming StructualFeature after storing the EClass name attribute information; Confirming the EAttribute when the StructualFeature is confirmed; Storing the name information and the type attribute information in the property and size fields if the EAttribute is confirmed, determining EReference if the EAttribute is not confirmed, and storing the name attribute information in the child field; And inputting a record based on the stored data.

The step of generating the key table using the attribute information of the meta model may further include storing previous class name data in the parentel field.

Here, the packet meta model data may include a header packet indicating an entire data structure, and a body packet composed of body packets indicating the metadata.

Here, the header packet may include data type information and data size information, and the data type information may be labeling information.

Here, the header packet may further include variable size information.

The step of dividing the meta model data to generate packet meta model data may include the steps of: checking a tag of the meta model data and adding key data to the header packet if the tag is absent; Confirming attribute information of the meta model data and confirming whether the attribute information is a primitive type if the attribute information is present; And adding the compressed data byte to the header packet and adding the body of the metadata to the data packet if the attribute information is a primitive type.

The step of dividing the meta model data to generate packet meta model data may include adding a data size to the header packet when the attribute information is not a primitive type and adding the size of the metadata to the data packet, And adding the data packet to the data packet.

The generating of the packet metamodel data by dividing the metamodel data may comprise: identifying a tag of the metamodel data; decomposing the metamodel data if the tag is present; And adding a delimiter.

The step of decomposing the meta model data and adding a delimiter for identifying the decomposed data packet when the key of the tag of the meta is present comprises the steps of: And decomposing the data.

In this case, the object Internet communication network is composed of a plurality of sub-communication networks, and the packet meta model data is transmitted to the server through the object internet communication network, the plurality of packet model data divided through the plurality of sub- To the server.

Here, the step of the server parsing the packet meta model data and outputting the meta model data may include storing the packet model data as a file name including the sub network ID information and the reception time information have.

Here, the step of the server parsing the packet meta model data and outputting the meta model data may include accumulating the received packet model data.

Herein, the server parsing the packet meta model data and outputting the meta model data comprises: checking the con tag every time the packet model data is stored; Generating aggregated packet data by integrating accumulated packet model data into one packet when it is determined that the packet meta model data includes the last data content of the meta model data according to a result of inspection of the con tag; And reconstructing the integrated packet data into the meta model data using the key table.

The step of the server parsing the packet meta model data and outputting the meta model data includes: counting the cumulative number of times of storing the packet model data; And a step of generating integrated packet data by integrating cumulatively stored packet model data into one packet when the accumulated number of storage strokes is matched with the divided packet number information stored in a header packet of the packet model data, .

Here, the generating of the energy sensing data may include generating original energy sensing data obtained from a power generation facility, the original energy sensing data including an original metamodel and original metamodel data; Generating a database using the original meta-model through a database generator; And generating the energy sensing data by inserting the original metamodel data into the database through a database inserter.

According to another embodiment of the present invention, a data transmission system for low-capacity transmission of a metamodel-based protocol includes a database including a key table creator for generating a key table and a database memory for storing the key table; Receives energy sensing data from a renewable energy production facility, converts the energy sensing data into metamodel data including a metamodel and meta data, divides and compresses the metamodel data using the key table to generate packet metamodel data Client; And a server for receiving the packet meta model data from the client through the object internet communication network, parsing the packet meta model data, and restoring the meta model data into the meta model data.

Here, the object Internet communication network may be a LoRa network.

The client may include a data packet creator for receiving the key table from the database and generating the packet meta model data by dividing the meta model data using the key table.

Here, the server may include a data packet parser that receives the key table from the database and parses and restores the packet meta model data using the received key table.

Here, the database may include a key table creator for generating a key table using the meta model data.

According to an embodiment of the present invention having the above-described configuration, it is possible to transmit a large-capacity metamodel data in a sufficiently long time in a real-time through an object internet communication network having a relatively small capacity and a transmission speed.

1 is a block diagram illustrating a data transmission system for low capacity transmission of a metamodel-based protocol.
2 is a diagram illustrating a header packet generated by a data transformation method for low capacity transmission of a metamodel-based protocol according to an embodiment of the present invention;
3 is a diagram showing an example of energy sensing data in a power generation facility among energy sensing data related to the present invention;
4 is a diagram showing an example of energy sensing data in a connection box among energy sensing data related to the present invention;
5 illustrates a structure for low capacity transmission in a data transformation method for low capacity transmission of a metamodel based protocol according to an embodiment of the present invention;
6 is a diagram illustrating a relationship between meta-models and data in a key table according to an embodiment of the present invention;
7 is a diagram showing an example of a record generated in a key table according to an embodiment of the present invention;
FIG. 8 is a flowchart for explaining operations in a key table creator according to an embodiment of the present invention; FIG.
9 illustrates automatic generation of a metamodel-based insert query statement in accordance with one embodiment of the present invention.
10 is a diagram illustrating a structure of a key table according to an embodiment of the present invention;
11 is a diagram illustrating a configuration of metamodel data, a key table, and a header packet according to an embodiment of the present invention.
FIG. 12 illustrates a process of constructing a data packet based on meta model data according to an embodiment of the present invention. FIG.
13 illustrates data packet decomposition results in accordance with an embodiment of the present invention.
FIG. 14 is a flowchart for explaining operations in a packet creator according to an embodiment of the present invention; FIG.
15 is a diagram illustrating a Con tag value having a value of an actually transmitted packet extracted according to an embodiment of the present invention;
16 is a diagram illustrating a process of integrating extracted content values into one data packet according to an embodiment of the present invention.
17 illustrates a process of recovering metadata in a segmented data packet according to an embodiment of the present invention.
FIG. 18 is a flowchart for explaining operations in a packet parser according to an embodiment of the present invention; FIG.

Hereinafter, a data transformation method for low capacity transmission of a metamodel-based protocol and a data transmission system for low capacity transmission of a metamodel-based protocol, which are one embodiment of the present invention, will be described in detail with reference to the drawings.

1 is a block diagram illustrating a data transmission system for low-capacity transmission of a metamodel-based protocol. 1, a data transmission system for low-capacity transmission of a metamodel-based protocol, which is an embodiment of the present invention, includes a client 1, a LoRA device 2 (a Laura device), an IOT backbone network 3 A backbone network), and a server 4.

Various kinds of original energy detection data can be generated in the renewable energy generation facility 5. [ The detection data in the battery module 51, the detection data in the connection box 52, and the detection data in the inverter 53 are generated in the same energy generation facility, for example, the solar power generation facility 5 as shown . Such original detection data is transmitted to the client 1. The original sensed data includes an original metamodel and original metamodel data, a database is created using the original metamodel via a database generator, the original metamodel data is inserted into the database through a database inserter, (Integrated metamodel data), thereby converting various types of original energy sensing data into a single integrated protocol type and transmitting them to the client. Accordingly, even if a new type of renewable energy generation facility is added, the original energy sensing data can be easily converted into the energy sensing data without the entire system modification, thereby improving the economical efficiency.

As described above, the solar power generation facility 5 is one example of a renewable energy generation facility in the present invention, as illustrated in FIG. When the energy sensing data is generated in the power generating facility, the client 1 receives the energy sensing data. The energy sensing data may be various voltages in the connection box 52, current related data, or voltage current related data in the inverter 53.

The client 1 receives the energy sensing data and converts it into metamodel data including the metamodel data and the meta data as described above. The metamodel data is converted into packet metamodel data in consideration of the communication speed of the object Internet communication network . The divided packet metamodel data is transmitted to the IOT backbone network 3 (object Internet communication network) in parallel through a plurality of lauler apparatuses 2 (object Internet communication apparatuses). Through the IOT backbone network 3, The server 4 receives the metamodel data, parses and integrates the packet metamodel data, and restores the original metamodel data again.

Here, LoRa network can be used as IOT Internet communication network, and LoRa network supports low capacity communication. Theoretically, it supports a minimum of 65 bytes and a maximum of 242 bytes depending on the radio reception rate. However, since the energy detection data obtained from the existing solar power generation is about 1 kbyte, if it is divided as it is, it should be divided into at least 15 or more. In such a configuration, 15 * 10 (The time taken to send the data is 10 seconds) = 150 seconds.

Therefore, in the present invention, the energy sensing data, which is the raw data, is reduced, thereby improving the transmission efficiency. This will be explained in detail later.

2 is a diagram illustrating a header packet generated by a data transformation method for low-capacity transmission of a metamodel-based protocol according to an embodiment of the present invention. To reduce the amount of data as much as possible, convert the information sent in the default string to bytes. And use a minimum of bytes to reduce capacity.

The data packet consists of a header and a body packet. The header stores the structure information of the metamodel data to be transmitted, and the actual data value is transmitted to the body. Therefore, the header is transmitted at one time, and the body is divided into n pieces according to the capacity.

The header packet stores the type and size information of the data. That is, as shown in Fig. Here we consider three cases.

1. When there is one size information in one type (type and size are limited to 1 byte) = total 2 bytes

2. When there are several size information (N) in one type = total 1 + N byte

3. If there is no size in one type = 1 byte in total

Therefore, the header is that the data type comes first, there is no size, or there are multiple sizes. When the number of sizes is variable, generally, the data must be prefixed with variable data when interpreting the data. To reduce this information, we use the information in the metamodel, which is the schema of the data, to create a header.

First, in order to limit the length of the data type to 1 byte, the data types appearing in the metamodel information are labeled in alphabetical order. For example, as shown in FIG. 3, when there is a meta model called PlantDisplay and corresponding data is transmitted in the conventional manner, 12 bytes are required because PlantDisplay is sent as a string. Since we have metamodel information for both sender and receiver, this PlantDisplay can be represented by 'a' if we apply labeling to the data types. Because they are labeled in alphabetical order, the representation of PlantDisplay as 'a' means that it is the first model in the metamodel data. The attributes of PlantDisplay were current, days, yesterday, month_power, last_month_power, total 6. In the past, all of this information has to be sent, but the metamodel does not send the name information of the property by ordering the data in the order in which they are stored. Also, if the size is not fixed, such as EFloat or EDouble defined in the metamodel, size information is not sent. So, in this example, when you send the header, you just send 'a'. The original data can be restored by referring to the metamodel only with the alphabet information 'a'. For this process, it is necessary to make a connection relation between the information of the meta model and the alphabet information in advance. We construct a database table in which this connection relationship data is stored. This is called a key table creator. This will be described in more detail later.

On the other hand, size information is sent only to EString type, EDate type, Enum type and so on. FIG. 4 illustrates metamodel data of a junction box. As shown in FIG. 4, the JunctionBox has an EString type. In this case, you need to determine the size of the data that is actually generated. In the case of FIG. 4, when the JunctionBox is labeled 'b', the size of the data is checked to make a header of 'b 12 12'. Since the data type of the first data 'num' is 'EInt' and the size is fixed to 4 bytes, the size information is not described in the header, and the data type of the second and third data is variable in size to 'EString' The size of the actual data "0; 0; 0; 0; 0; 0;

Primitive types (EInt, EFloat, EDouble, etc.) with a fixed size in the process of sending data in the body cause waste of data when sending a small number. For example, if it is defined as EInt (4 bytes), it is fixed to 4 bytes, so even if it is 0, it is transmitted in 4 bytes with 0x00000000. 1, 0x00000001 and 4 bytes should be used unconditionally. It can be expressed in 1 byte, but 3 bytes is wasted. Therefore, information that can change the size by the value of the data is added between the key value and the size value of the header (variable size information). The size to be entered into the body is important because the data itself is untyped binary data. If the size information of the header is wrong, the wrong value can be read. Therefore, the size information of the data should be kept in the header.

In addition, as shown in Table 1 below, this variable size uses 2 bits as a variable data space. The use of this space is determined by the number of attributes of the metamodel. In the case of the above plantdisplay, the size is determined by 6 attributes, 6 x 2 bits = 12 bits (12/8 = 2 bytes (rounded up)). And the junctionbox has one property, 1 x 2bit = 2/8 = 1byte (raised).

That is, the size is determined by N (number of attributes) x 2 bits = M / 8 bits = T (increasing).

8 7 6 5 4 3 2 One 0 0 0 0 0 0 0 0

The range of data values is shown in [Table 2] below. Read the value from the body data you want to send to determine the final size. For example, 0 is a value of 00 for 2 bits of the key, and only 1 byte is read when reading from the body.

Range of values Size (byte) A bit representation of the key -128 to 127 1 byte 00 -32,768 ~ 32,768 2byte 01 -2,147,483,638 ~ 2,147,483,638 4byte 10 etc 8byte 11

Here, it is important to distinguish type, variable size, and size from header information without any division. This can be done by referring to a key table that converts metamodel information into a table. The following is a schematic algorithm for processing this.

(1) Read the type to get the number P of primitive type attributes (EInt, EFloat, EDouble, etc.) and the number of other attribute values (EString, EDate, Enum, etc.) in the Key Table.

(2) Multiply P by 2 bits to find the variable size value.

(3) Read bytes of variable size from the header.

(4) Read as many bytes as the value of V.

This will allow you to handle type, variable size, and size in the header.

The body orders all the data to be sent according to the structure of the header. And the size of the largest packet that can be sent. For example, when the total size of data to be transmitted, that is, the compressed packet metamodel data size is 400 bytes and the maximum packet size is 65 bytes, 63 bytes minus 2 bytes for recording the order of data packets (i.e., Size of metamodel data). Here, the maximum packet size is based on the transmission rate of the object Internet communication network. That is, when the transmission speed information of the object Internet is obtained, the reference size of the packet meta-model data is divided according to the transmission speed.

400byte / 63byte = 6, and the remainder is divided into 22 bytes. 6 body packets of 63 bytes, which is the maximum packet size, except for 2 bytes for recording the order, are transmitted, and finally, a body packet of 22 bytes is transmitted.

In order to check the order of packets decomposed according to the maximum packet size when sending data, the first 1 byte is the total number of data packets to be sent, the second 1 byte is the order of the current data packet, and 63 bytes And transmits the data 7 times in total.

[Table 3] is an example of header and body packets used in actual transmission. The header in the header is a hex representation of the byte, and the space below is the actual meaning of it. The first is an alphabetical data type, the second is a number, it may or may not be a number. This information can not be interpreted only by the header that is currently sent, and it should refer to the reference table created by the Key Table Creator. Then, the body composes the data to be sent according to the data structure of the header and sends it.

type Binary Data Header
6c 07 1c 07 61 68 6b 6a 65 67 66 40 40 l 7 28 7 a h k j e g f 64 64 body 0x0601303031 ... (omitted) ...
0x0602000000 ... (omitted) ...
0x0603000000 ... (omitted) ...
0x060401303b ... (omitted) ...
0x0605303b30 ... (omitted) ...
0x06063b303b

A data transformation method for low-capacity transmission of a metamodel-based protocol according to the present invention will be described with reference to FIG.

FIG. 5 is a diagram illustrating a structure for low capacity transmission in a data transformation method for low capacity transmission of a metamodel-based protocol according to an embodiment of the present invention. As shown in FIG. 5, a data transmission system for low-capacity transmission of a metamodel-based protocol according to the present invention includes a database 6, a client 1, and a server 4.

The database 6 may include a key table creator 61 and a DB memory 62, which is a database for storing key tables. The key table creator 61 of the database 6 generates a key table for storing data labeled in the models constituting the metamodel data and sizes of the respective data. The data packet creator 11 included in the client 1 receives the key table generated in the database 6 and refers to the data to transmit the data (XMI type metamodel data, The optical packet is generated in the form of binary packets, and packet metadata is generated by dividing the reduced packets based on the transmission speed of the object Internet communication network, The data is sequentially transmitted to the server via the LoRa network 3 including a plurality of LoRa devices 2. The server 4 having received the divided packet meta data has a data packet parser 41 and receives the key table generated by the key table creator 61 of the database 6, The packet parser 41 refers to the key table and performs a reverse process of generating the packet meta model data to restore the original XMI data that the client 1 desires to send.

Hereinafter, the operation of the key table creator, which is a component of the database, will be described in more detail with reference to FIGS. 6 to 10. FIG.

FIG. 6 is a diagram illustrating a relationship between meta-models and data of a key table according to an embodiment of the present invention, FIG. 7 is a diagram illustrating an example of a record generated in a key table according to an embodiment of the present invention FIG. 8 is a flow chart for explaining operations in a key table creator according to an embodiment of the present invention, FIG. 9 is a diagram illustrating automatic generation of a metamodel-based insert query according to an embodiment of the present invention And FIG. 10 is a diagram illustrating a structure of a key table according to an embodiment of the present invention. As shown in FIG. 6, the metamodel includes a data type name (className, name), labeling information, and property names and size information of attributes included in the data. In the key table creator 61, the name of each data type (className, name), labeling information (key), the name of property included in the data, and size information Create a stored table. In addition, the parent and child data representing the dependency relation are stored to confirm the metamodel structure. The following shows the relationship between metamodel and key table data.

In the meta model, each KeyEClass is stored as one record in the table. As shown in FIG. 6, the relationship between the EClass 'Inverter' and the Key Table data is shown in a line. The fields of the Key Table are separated by id, key, className, name, property, size, parent, and child. id is a numeric value from 1 in the order of input records regardless of the metamodel data, and sets this field as a primary key. In the key field, enter 'a', 'b', 'c' .. in the order of the records, regardless of the actual data. This field is used for labeling when transmitting metamodel data. className stores the name attribute of the EClass in the meta model. Since the name field uses the name of the EClass in lower case in the metamodel data, the value of the className field is converted to lower case and stored. property stores the name attribute of the EAttribute that is included in the current EClass. Because it consists of several EAttribute, each name is separated by ';'. The size field stores the type attribute of each EAttribute. Like the property field, each type is separated by ';'. In the parent field, enter the parent class of the corresponding EClass, and in the child field, enter the subclass of the corresponding EClass. Because the EClass 'Inverters' in the current meta model contains EClass 'Inverter' as an EReference, 'inverters' are entered in the 'Inverter' parent field and EClass 'warning' is included as an EReference attribute in the subclass Enter 'warning' in the field. When the EClass called 'Inverter' is stored through the above process, a record as shown in FIG. 7 is generated.

The operation of the key table creator performing such a process is shown in FIG. As shown in FIG. 8, the key table creator interlocks with the database storing the key table, and loads the meta model (S11, S12). Then, the key table is generated by using the meta model attribute information. The epackage information, which is the highest model of the meta model, is loaded, eClassifires having a dependency relation with the epackage information are confirmed, and when the eClassifires are confirmed, And stores EClass name attribute information in the key, identifies StructualFeature after storing EClass name attribute information, confirms EAttribute when the StructualFeature is confirmed, and confirms name information and type property information when the EAttribute is confirmed If the EAttribute is not confirmed, it is determined to be EReference, the name attribute information of the ERA is stored in the child field, and the record is input based on the stored data (S13 to S20).

Again, we load EPackage, the top model of the metamodel, and load the EClassifiers that have dependencies on it. Since EClassifiers consist of several EClass, we load each EClass via Iterator. Stores the name attribute of the loaded EClass. This value is stored in the className field of the table. Since EClass is composed of several EAttribute and EReference, Iterator loads each one and distinguishes type. For EAttribute, store the name and type attributes. These values are stored in the property and size fields of the table. If EReference, store the name attribute. This value is stored in the child field of the table. Enter records based on stored data. Finally, the current className data is passed to the next EClass and stored in the parent field. In this process, an insert query is automatically generated based on the meta model. The result is shown in Fig. As described above, an insert query statement is automatically generated based on each data. The value of the key field is entered in alphabetical order regardless of the metamodel data, and the name field is changed to all lowercase letters of the data in the className field. A part of the structure of the key table generated as a result of the above-mentioned automatically generated Insert query statement is shown in FIG. Here, "id" is used as a primary key for distinguishing each record, "key" is a tag name converted to a corresponding alphabet when converting XMI to a data packet, and "className" Where "name" is the name of the tag declared in the XMI file, "property" is the list of attribute names used in the tag, "size" is the byte size of the attributes "Parent" is the parent tag of the tag, and "child" is the child tag of the tag.

Hereinafter, operations of the data packet creator 11 included in the client 1 will be described with reference to Figs. 11 to 14. Fig.

11 is a diagram illustrating a configuration of metamodel data, a key table, and a header packet according to an embodiment of the present invention. FIG. 12 is a diagram illustrating a configuration of a data packet based on metamodel data according to an embodiment of the present invention. FIG. 13 is a diagram illustrating a result of data packet decomposition according to an embodiment of the present invention, and FIG. 14 is a flowchart illustrating an operation in a packet creator according to an embodiment of the present invention to be.

The data packet creator 11 which is a component of the client 1 refers to the key table automatically generated by the key table creator 61 of the database 6 to generate meta model data And generates packet metamodel data in a compression divided form. Since the divided packet metamodel data is a form in which one data is decomposed into a plurality of data packets, the divided packet metamodel data may include a header packet indicating the structure of the entire data and a body packet indicating actual data. In order to distinguish the sequence of body packets, 2 bytes are used as data indicating the number of whole body packets (1 byte) and the order of current body packets (1 byte). In Fig. 11, the relationship between the actual meta model data, the key table, and the header packet is shown. FIG. 11 shows a process of constructing a header packet based on meta model data. Load each tag in the metamodel data and look up the record with the same name attribute in the tag name and key table. Enter the key value of the record in the header and check all properties. In the case of the primitive type, the size of the data is checked, and 2-bit data is added to the header packet according to the byte. 1 byte is represented by 00, 2 bytes by 01, 3 bytes by 10, and 4 bytes by 11. In case of UnPrimitive Type, check length of actual data and add to header packet. Add the key field 'l' in the first tag 'hsSolarEnergy' and check the property for that record. The record has three properties: 'plant_id', 'time', and 'mode'. Since these three attributes are all UnPrimitive types, the actual data size is checked in the metamodel data. The data of 'plant_id' is 7 and the data of 'time' is 28. 'Mode' does not have data, so size checking is not necessary. Enter the actual sizes 7 and 28 of the variable data. Add the key 'a' in the following tag 'plantdisplay' and check all the properties. Since all the properties included are Primitive Type, check the size of actual data. Since the current property is of type float, it is 4 bytes in size. However, since the range of actual data is small, it can be reduced to 1 byte of data. Therefore, a '00' bit, which means one byte, is input to the header packet. The data packet is formed by converting the actual data of all the attributes into the byte format in the process of forming the header packet. In Fig. 12, an example in which the byte data is expressed in hexadecimal in order to simplify the byte data is shown.

The entire data packet thus constructed should be decomposed and transmitted according to the maximum packet size in the LoRa network. The maximum packet is 65 bytes in consideration of the transmission speed of the LoRa network. To distinguish the list of decomposed body packets, 2 bytes stores the total number of packets and the order of the current packet. 63 bytes (body) excluding 2 bytes (header) stores actual data. Therefore, if the data packet is decomposed into a plurality of body packets, it is as shown in FIG. In Fig. 13, the byte format is simplified and expressed in hexadecimal.

The operation of the data packet creator performing such a process will be described in more detail with reference to FIG. Briefly, the packet creator loads the meta data in cooperation with the database, checks the tag of the meta model data, adds the key data to the header packet if there is no tag, decomposes the meta model data, A delimiter for identifying the data packet is added (S21 to S24). (S25 to S26). If the attribute information is a primitive type, compressed data bytes are added to the header packet. If the attribute information is a primitive type, (S27). When the attribute information is a non-resource type, the data size is added to the header packet (S28, S29). In more detail, the data packet creator, which is a component of the client, receives the information of the database and interlocks with it to acquire the key table. And receives metamodel data. Load the tags of the meta model data one by one, check the key of the current tag in the key table received from the database, and add the value to the header packet. Load all the attributes contained in the tag one by one to check the data type of the current attribute in the Key table. If the data type is a primitive type, the bytes of the compressed data are added to the header. In case of UnPrimitive Type, the size of the actual data is added to the header packet. After that, the actual data is converted into bytes and added to the data packet. After constructing the header packet and the data packet of all the tags, the data packet is decomposed according to the maximum data packet size of the LoRa network. In order to distinguish the disassembled data packets, the first two bytes of the data packet input the number of all data packets, the next two bytes input the sequence number of the current data packet, and add the actual data (S30).

Hereinafter, the configuration and operation of the data packet parser, which is a component of the server, will be described in more detail with reference to FIG. 15 to FIG.

A data packet parser 41 (Data Packet Parser) receives data sent from a data packet creator 11 through a LoRa network. The LoRa network transmits the received data to a specific web page. Web pages are assigned differently, one for each LoRa module. For example, if you set the LoRa network to forward data from A module to http: //***.com/A1.php, the LoRa network will send the data of the received A module to http: // *** .com / A1.php. The transmitted data is XML file data, which is metamodel data. The XML files are accumulated and stored in the integration server on a time-by-time basis. The file name is stored as '[module ID_ current time (in seconds)] .xml'. In the XML file, information such as the transmission date and the LoRa module ID is stored. The data transmitted by the LoRa module is stored in the con tag. That is, packet metamodel data is transmitted to the server via a LoRa network composed of a plurality of sub-networks, and the server cumulatively stores each packet metamodel data with a module ID and a reception time name.

The server checks the contents of the file every time it saves the XML file, which is the fragmented packet metamodel data. The content of the con tag is in the file. The location of con in the file is shown in FIG. The con tag is the contents of the actual packet being transmitted.

If the stored XML file has the contents of the last packet, all the previously stored XML files are read as shown in FIG. 16, and the actual data in the con tag is integrated into one packet. I.e., cumulatively stored packet model data into one packet to generate integrated packet data.

The combined data packet is restored into the metadata through the process shown in FIG. The restoration process takes three steps. First, the data packet is converted to a logical value. For example, changing hexadecimal '6C' to ASCII results in the letter 'l'. If hexadecimal '6C' is changed to ASCII, it becomes 'l'. If hexadecimal '37' is changed to ASCII, the number is '7'. In this way all data packets are converted to logical values.

Match the second changed logical value with the key table. For example, 'l' means 'hsSolarEnergy' in the logical value composed of 'l 7 28', next '7' and '28' means that the size of the plant_id property is 7byte String, the size of the time property is 28byte String , and the size of the mode attribute is 0 byte String. The matching method is a reverse order of the process of constructing the data packet based on the metamodel data.

Third, restore the data that has been matched. The restored data has an XML form. In the first packet, the tag name and attribute information of the tag are restored. Restores the values of the attributes in the last packet from the second.

Hereinafter, the operation of the data packet parser, which is a component of the server, will be described in detail with reference to FIG.

As shown in FIG. 18, the Data Packet Parser first proceeds with the process of data processing of the web page mentioned above. That is, the data stored in the header of the divided packet model data received through the object Internet network is read, and these data are stored as a LoRa ID and a receiving time name, and then the packet model data is loaded and transmitted by the LoRa network Continue to save the XML file and read the con tag in the XML file. If the con tag is not found, it is confirmed that the first file is not a header packet. If all the files are normal, the loaded files are stored in the variable v (S31 to S36).

If there is a con tag, it is checked how many files are currently read, and if the last file of the XML is correct, the previously stored files are read at once, merged, and stored in a variable v (S351 to S354). Then, the existing XML files are deleted (S37).

On the other hand, when the generation of the data stored in the variable v is completed, the data stored in the variable v is matched with the key table of the database, restored to the original XMI file, and stored in the recovered XMI file (S38 to S40). That is, after loading the key table from the database, it is matched with the key table and restored to the original XMI file. The restoration process proceeds in the reverse order of creating the actual packet. During the restoration process, it is necessary to convert ASCII codes to decimal numbers. The con tag displays all data in hexadecimal and displays it in ASCII code. If the LoRa module transmits 10 bytes in 1 byte of data space, the value of '0' 'A' is read when the con tag is read. Therefore, we need to convert ASCII code to hexadecimal data and convert hexadecimal data to decimal. In other words, two strings per byte must be read and interpreted. If you send 'S' (= 0x53) to 1 byte of data space, you read '5' and '3' when you read con tag.

According to an embodiment of the present invention having the above-described configuration, it is possible to transmit a large-capacity metamodel data in a sufficiently long time in a real-time through an object internet communication network having a relatively small capacity and a transmission speed.

The data transmission method for low capacity transmission of the metamodel-based protocol and the data transmission system for low capacity transmission of the metamodel-based protocol described above are not limited to the configuration and method of the above-described embodiments, All or some of the embodiments may be selectively combined so that various modifications of the embodiments may be made.

Claims (14)

Generating energy sensing data;
The client receiving the energy sensing data and converting it into metamodel data including a metamodel and meta data;
Compressing the meta model data to generate packet meta model data;
Obtaining transmission rate information of the object Internet communication network;
Transmitting the packet meta model data to a server through the Internet service network; And
The server parsing the packet meta model data to output the meta model data,
Wherein the step of generating the packet meta model data by dividing the meta model data comprises:
Determining a reference size of the packet meta model data based on the transmission rate information; And
And dividing the metamodel data based on the reference size. ≪ Desc / Clms Page number 19 >
The method according to claim 1,
Wherein the object Internet communication network is a LoRa network, the data transformation method for low capacity transmission of a metamodel-based protocol.
The method according to claim 1,
Generating a key table through a key table creator and storing the key table in a database,
Dividing the meta model data to generate packet meta model data,
Wherein the data packet creator divides the meta model data using the key table to generate the packet meta model data.
The method of claim 3,
The key table includes:
A method of transforming data for a low capacity transmission of a metamodel based protocol, comprising: an identity field, a key field, a class name field, a name field property field, a size field, a parental field and a difference field.
5. The method of claim 4,
Wherein the step of generating the packet meta model data by dividing the meta model data comprises:
Inputting the meta data by using an insert query statement in the key table, and compressing the meta model data to generate compressed data;
And dividing the compressed data to produce a plurality of packet metamodel data. ≪ Desc / Clms Page number 19 >
The method of claim 3, wherein
The packet meta-model data includes:
And a body packet composed of a header packet representing the entire data structure and a body packet representing the meta data.
The method according to claim 6,
The header packet includes:
Data type information, and data size information,
Wherein the data type information is labeling information for a low capacity transmission of a metamodel based protocol.
The method according to claim 6,
The header packet includes:
A method of transforming data for low capacity transmission of a metamodel based protocol, further comprising variable size information.
The method according to claim 1,
Wherein the object Internet communication network comprises a plurality of sub communication networks,
Wherein the step of transmitting the packet meta model data to the server through the object internet communication network comprises:
And transmitting a plurality of said packet model data divided through said plurality of sub-networks to said server, respectively.
The method according to claim 1,
Wherein the generating the energy sensing data comprises:
Generating original energy sensing data obtained from a power generation facility, the original energy sensing data including an original metamodel and original metamodel data;
Generating a database using the original meta-model through a database generator; And
Inserting the original metamodel data into the database through a database inserter to generate the energy sensing data. ≪ Desc / Clms Page number 20 >
A database including a key table creator for generating a key table and a database memory for storing the key table;
Receives energy sensing data from a renewable energy production facility, converts the energy sensing data into metamodel data including a metamodel and meta data, acquires transmission speed information of the object Internet communication network, Wherein the client determines a reference size of the packet meta model data based on the transmission rate information and divides the meta model data based on the reference size; And
And a server for receiving the packet metamodel data from the client through the object internet communication network and parsing the packet metamodel data and restoring the metamodel data into the metamodel data and outputting the metamodel data, .
12. The method of claim 11,
Wherein the client comprises a data packet creator for receiving the key table from the database and using the metamodel data to divide and compress the metamodel data to generate the packet metamodel data, Transmission system.
12. The method of claim 11,
The server comprises:
And a data packet parser for receiving the key table from the database and parsing and restoring the packet meta model data using the key table.
12. The method of claim 11,
The database includes:
And a key table creator for generating a key table using the meta model data.

Images