KR102337182B1 - Smartmeter installed middleware platform for function extension, smartmeter application management system and method using the same - Google Patents

Abstract

The present invention relates to an electronic watt-hour meter equipped with a middleware platform for function extension, a watt-hour meter application management system using the same, and a method therefor. and an application including a metering application related to power metering and an application application related to an additional service in the power meter having an operating system; and a middleware platform that enables function extension and execution of the application regardless of the hardware and the operating system while operating based on the hardware and the operating system.

Description

Electronic watt-hour meter equipped with middleware platform for function expansion, watt-hour application management system using the same, and method

The present invention relates to an electronic watt-hour meter equipped with a middleware platform for function extension, and a watt-hour meter application management system and method using the same. It relates to an electronic watt-hour meter equipped with a middleware platform for function extension that does not need to be replaced and implements the same function regardless of hardware or operating system type or specification, and a watt-hour meter application management system and method using the same.

In order to maximize energy efficiency by combining power management and IT technology, the smart grid establishes a communication network so that power companies and consumers can exchange real-time information in both directions, and a management system that analyzes this information is provided. .

In order to generate more profits in the smart grid market, electric power companies need to understand consumers' desires and needs and provide appropriate power technology to improve consumer satisfaction with the smart grid. In other words, power companies should not stop at notifying consumers of power usage in real time, but should promptly collect power consumption data from consumers and provide optimal services according to power usage patterns to induce more consumer participation.

For example, a power company develops a fee menu according to the time period and power demand based on the consumer's power usage pattern and gives a choice, provides load prediction and failure prevention guidance service, or provides customized consulting service for optimal energy use If we develop and provide a variety of services that can create new added values, such as

In order to induce participation and increase convenience by providing various additional services to consumers, it is essential to improve the function of the electronic watt-hour meter (smart meter), a core facility of smart grid technology.

The electronic watt-hour meter currently in use applies only a simple function to measure uniformly regardless of load characteristics and is a firmware method. Therefore, unless continuous update is performed, smart grid functions such as time-division metering, power factor measurement, and maximum demand measurement are not provided. won't

Therefore, the current electronic watt-hour meter needs to be managed so that the smart grid function can be continuously updated by applying the central management method instead of the firmware method.

In general, the electronic watt-hour meter is not compatible with each manufacturer because the functional elements are developed as an integral part. That is, the electronic watt-hour meter must be developed as a block type (or module type) of functional elements to be compatible with each other by manufacturers. For this reason, when a new function is added or changed, the electronic watt-hour meter has to replace the product itself. This raises the price of the product itself and lowers the efficiency, which is a factor that raises the operation and maintenance cost for realizing the overall smart grid environment.

Therefore, the electronic watt-hour meter provides various additional services to improve the convenience of consumers and to increase the profits of the electric power company. It needs to be developed in a centralized way.

Korean Patent Publication No. 10-1318983 (Registered on October 10, 2013)

It is an object of the present invention to install a middleware platform in the watt-hour meter to add or change application additional service functions, so there is no need to replace the device itself, and to implement the same function regardless of the type or specification of hardware or operating system, for function expansion An object of the present invention is to provide an electronic watt-hour meter equipped with a middleware platform, and a watt-hour meter application management system and method using the same.

An electronic watt-hour meter equipped with a middleware platform for function expansion according to an embodiment of the present invention is a watt-hour meter having any hardware and an operating system, comprising: an application including a metering application related to power metering and an application application related to an additional service; and a middleware platform that enables function extension and execution of the application regardless of the hardware and the operating system while operating based on the hardware and the operating system.

The application may be installed, deleted, updated, and managed by the AMS server.

The middleware platform may include: a Java virtual machine including a VM agent for mutually communicating with a VM proxy installed in the AMS server and exchanging data to establish a communication interface environment with the AMS server as an element for executing a Java program; and an API that performs a function of installing, loading, and executing the file of the application.

Commands transmitted from the VM proxy to the VM agent may be classified into channels according to the category of the corresponding command.

The packet structure transmitted from the VM agent to the VM proxy includes a record header having a fixed length as a field describing a transmitted record packet, a header having a variable length as a field in which a transmitted command is recorded, and actually transmitted data. A field to be recorded includes data having a variable length, and the record header includes: a data size in which a data size is recorded, a channel in which a communication channel is recorded, a header size in which the size of the header is recorded, and a system head and a header to distinguish It may include a system bit that indicates a bit for a record, and a record mask.

The packet structure transmitted from the VM proxy to the VM agent includes a record header having a fixed length and data having a variable length. It may include a session ID in which the ID is recorded, and a channel in which a current communication channel is recorded.

Packet transmission between the VM agent and the VM proxy can be accomplished through an open channel process for exchanging data for channel initialization, a header transmission process for checking the transmission environment and transmission data size in advance, and a data transmission process for transmitting actual data. have.

The metering application is a package for providing a function, and includes a Meterapp package, a Display package, a Device package, an Imc package, a Data package, and a Conf package, and the package may express a mutual relationship through a package diagram.

In addition, the power meter application management system according to an embodiment of the present invention, an application including a metering application related to power metering and an application application related to an additional service; and a middleware platform that operates based on the hardware and the operating system and enables function extension and execution of the application regardless of the hardware and the operating system; and an AMS server configured to periodically communicate with the middleware platform to check whether management is required for the application and to perform a management task for the application.

In addition, the method for managing a power meter application according to an embodiment of the present invention includes the steps of: a VM proxy periodically communicating with a VM agent in a middleware platform mounted on the power meter to request application status information for the application; and performing, by the VM proxy, a management task for function extension of the application as the application state information is checked.

According to an embodiment, before the requesting step, the steps of establishing an open channel for exchanging data for channel initialization by the VM proxy and the VM agent; and a header transmission step in which the VM proxy and the VM agent check a transmission environment and a transmission data size in advance.

According to the present invention, by installing a middleware platform in the watt-hour meter to add or change application additional service functions, there is no need to replace the device itself, and the same function can be implemented regardless of the type or specification of hardware or operating system.

In addition, the present invention can implement the same function regardless of the type and specification of hardware and operating system that may vary depending on the manufacturer of the watt-hour meter by mounting a middleware platform on the watt-hour meter, and also adds the function of the watt-hour meter without the need to replace the watt-hour meter Alternatively, it can be changed to implement various functions.

In addition, by designing a middleware platform to have high availability for the hardware platform, the present invention can perform the same function regardless of the type and specification of the hardware or operating system of the watt-hour meter.

In addition, according to the present invention, various communication methods and heterogeneous operation may be possible by installing a Java-based platform and application program with excellent application compatibility in the watt-hour meter in consideration of interoperability.

In addition, according to the present invention, not only the configuration is simplified by applying the remote control and management method through the AMS server, but also the function of the watt-hour meter can be easily extended.

In addition, the present invention can secure the core technology of the next-generation watt-hour meter platform to preoccupy the global market, and install and distribute the application program developed by KEPCO to spread the awareness of KEPCO through the spread of the application program.

In addition, according to the present invention, additional revenue and new business can be created by various rate plans and derivatives according to the function of the installed application program.

In addition, the present invention can reduce the overall management cost by implementing the same function regardless of the type and capacity of the watt-hour meter and reducing operation and maintenance costs.

In addition, according to the present invention, a user can selectively update a function as needed at any time without replacing a product, thereby reducing time and cost for adding a function, as well as improving user convenience.

1 is a diagram showing a power meter application management system according to an embodiment of the present invention;
2 is a view showing the details of the middleware platform of the watt-hour meter in FIG. 1;
3 is a diagram illustrating the relationship of executing a function by calling an API in the middleware platform in the metering application in FIG. 1;
4 shows a package diagram of a metering application;
5 is a diagram illustrating a relationship in which the metering application calls an API in the middleware platform in FIG. 3 to realize a function using a package diagram;
6 is a diagram showing the configuration of a communication interface environment between the watt-hour meter and the AMS server according to an embodiment of the present invention;
7 is a diagram showing a packet structure transmitted from a VM agent to a VM proxy;
8 is a diagram showing a packet structure transmitted from a VM proxy to a VM agent;
9 is a diagram illustrating a packet transmission process between a VM agent and a VM proxy;
10 is a view showing detailed elements of the AMS server in FIG. 1;
11 is a diagram illustrating an application management service between a power meter and an AMS server.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, detailed descriptions of well-known functions or configurations that may obscure the gist of the present invention in the following description and accompanying drawings will be omitted. Also, it should be noted that, throughout the drawings, the same components are denoted by the same reference numerals as much as possible.

The terms or words used in the present specification and claims described below should not be construed as being limited to conventional or dictionary meanings, and the inventor shall appropriately define his/her invention as terms for the best description of his/her invention. Based on the principle that it can be done, it should be interpreted as meaning and concept consistent with the technical idea of the present invention.

Accordingly, the embodiments described in this specification and the configurations shown in the drawings are only the most preferred embodiment of the present invention, and do not represent all of the technical spirit of the present invention. It should be understood that there may be equivalents and variations.

In the accompanying drawings, some components are exaggerated, omitted, or schematically illustrated, and the size of each component does not fully reflect the actual size. The present invention is not limited by the relative size or spacing drawn in the accompanying drawings.

In the entire specification, when a part "includes" a certain element, this means that other elements may be further included, rather than excluding other elements, unless otherwise stated. Also, when a part is said to be “connected” to another part, it includes not only a case in which it is “directly connected” but also a case in which it is “electrically connected” with another element interposed therebetween.

The singular expression includes the plural expression unless the context clearly dictates otherwise. Terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification is present, and includes one or more other features, number, or step. , it should be understood that it does not preclude in advance the possibility of the presence or addition of an operation, component, part, or combination thereof.

Also, as used herein, the term “unit” refers to a hardware component such as software, FPGA, or ASIC, and “unit” performs certain roles. However, "part" is not meant to be limited to software or hardware. A “unit” may be configured to reside on an addressable storage medium and may be configured to refresh one or more processors. Thus, by way of example, “part” includes components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. The functionality provided within components and “parts” may be combined into a smaller number of components and “parts” or further divided into additional components and “parts”.

Hereinafter, with reference to the accompanying drawings, the embodiments of the present invention will be described in detail so that those of ordinary skill in the art can easily implement them. However, the present invention may be embodied in several different forms and is not limited to the embodiments described herein. And in order to clearly explain the present invention in the drawings, parts irrelevant to the description are omitted, and similar reference numerals are attached to similar parts throughout the specification.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

1 is a diagram illustrating an energy meter application management system according to an embodiment of the present invention.

As shown in Figure 1, the watt-hour meter application management system 1 according to an embodiment of the present invention, the watt-hour meter 100 for measuring the power consumption of the consumer, and AMS for managing the application mounted on the watt-hour meter 100 (Application Management System) includes a server 200 . Here, the watt-hour meter 100 and the AMS server 200 may be directly connected through the wired/wireless Internet or may be connected through the DCU 300 .

Specifically, the watt-hour meter 100 installs a high compatibility middleware platform inside to add or change the additional service functions of the application (eg, time zone measurement, power factor measurement, maximum demand measurement, failure prevention guidance, etc.), There is no need to replace the device itself, and the same functions can be implemented regardless of hardware or operating system type or specifications.

In other words, unlike the method of loading a native application designed to be dependent on hardware and operating system, the watt-hour meter 100 is equipped with a middleware platform that is easy to expand functions to provide a function for loading applications independent of hardware and operating system. do.

Meanwhile, the AMS server 200 is responsible for remotely managing and controlling the middleware platform and applications installed in the watt-hour meter 100 . As such, the AMS server 200 manages registration of applications installed in the watt-hour meter, and remotely manages the applications.

Hereinafter, the components of the watt-hour meter 100 will be described as follows.

The power meter 100 includes a hardware (HW) 110 , an operating system (OS) 120 , a middleware platform 130 , a DLMS server 140 , and an application 150 .

The hardware 110 constitutes the watt-hour meter 100 and refers to physical devices that perform the function of the watt-hour meter 100 .

The operating system 120 controls the hardware 110 , manages resources of the watt-hour meter 100 , and provides a base environment for the application 150 .

The middleware platform 130 makes it possible to expand the function of the watt-hour meter 100 by downloading or upgrading an application in which a necessary function is implemented at any time through an application programming interface (hereinafter referred to as 'API'). Here, the middleware platform 130 may manage various applications 150 independently of the hardware 110 and the operating system 120 , and may be Java-based middleware, Android-based middleware, or the like. Here, for convenience of explanation, the Java-based middleware will be mainly described.

The DLMS server 140 communicates with a DLMS client of a Data Concentration Unit (DCU) and performs a remote meter reading function using a DLMS/COSEM (Device Language Message Specification/Companion Specifications for Energy Metering) protocol. Here, the DLMS server 140 may be a function included in the application 150, but is illustrated as a separate component for convenience of description.

The application 150 includes a 'metering application' and a 'application application' in which installation, deletion and update are managed by the AMS server 200 .

The metering application is an application related to power metering, which is the original function of the power meter 100, and the application application is an application in which functions necessary to provide various additional services are implemented.

FIG. 2 is a diagram illustrating detailed elements of a middleware platform of the watt-hour meter in FIG. 1 .

Referring to FIG. 2 , the middleware platform 130 includes an API 131 and a Java Virtual Machine 132 when implemented as a Java ME (Micro Edition)-based platform. The middleware platform 130 supports the IMC protocol for communication with the application 150 .

In addition, the watt-hour meter 100 may include a component (not shown) for normally performing the application 150 by porting the middleware platform 130 .

Here, the characteristics of Java applied to the middleware platform 130 will be examined.

Java is an object-oriented programming language, and compiled code is platform independent. The Java compiler converts a program written in the Java language into a special binary form called bytecode. Here, the Java virtual machine 132 is a special virtual machine for executing bytecodes, and executes the bytecodes in the same form on any platform. Accordingly, the Java virtual machine 132 may independently execute the application 150 regardless of the type of the hardware 110 or the operating system 120 .

As described above, since Java can be implemented as an abstract code that is bytecode that does not depend on the hardware 110 or the operating system 120, if the environment of the standard library set and compiler required for development is matched with the Java virtual machine 132, Since it operates the same in all environments, it is a language suitable for providing the application 150 independent from the hardware 110 or the operating system 120 .

Hereinafter, detailed elements of the middleware platform 130 will be described.

First, the Java virtual machine 132 is an element capable of executing a bytecode of a Java program, and includes a Connected Limited Device Configuration (CLDC) 132a and a VM agent 132b.

Here, the CLDC 132a is a minimum Java class library required to drive the Java virtual machine 132 and represents a set of basic functions that must be supported in the Java environment. The VM agent 132b is an element constituting the AMS server 200 and the communication interface environment.

Next, the API 131 is responsible for installing, loading, and executing the file of the application 150 .

These APIs 131 are MEEP (Micro Edition Embedded Profile) (131a), GCF (Generic Connection Framework) (131b), File I/O (131c), Device I/O (131d), JSON (JackSON) (131e) , Security (131f), GUI (Graphic User Interface) (131g), and a metering API (131h).

Specifically, the MEEP 131a is a profile for small and medium-sized embedded devices such as intelligent edge devices such as routers and switches, communication nodes, smart sensors, or smart meters.

GCF (131b) provides credentials (Certificates) for secure connection as a lightweight framework for networking and I/O.

The File I/O 131c is an element supporting I/O APIs for accessing a file system of a device or an external memory card.

The Device I/O 131d is an element supporting an I/O API for a Java application peripheral executed in a small embedded device.

The JSON 131e is an element that parses and processes JSON that delivers a data object consisting of attribute value pairs.

Security 131f is for application-related security, and consists of APIs related to Security Authentication Providers.

The GUI 131g is an element supporting an API that provides a display function and a setting function to the watt-hour meter 100 in a graphic environment.

The metering API 131h is an element that provides a function for measuring metering data or controlling peripheral devices in connection with the metering IC chip.

The application 150 is an application program executed in the middleware platform 130 , and implements a function by calling the API 131 in the middleware platform 130 .

The application 150 includes a metering application 150 and an application application 150 . In addition, as described above, the application 150 includes the DLMS server 140 for implementing a remote meter reading function together with the metering application 150 for power metering. And, the application 150 implements, for example, an additional service-related function, such as energy consulting, rate selection, load prediction or failure prevention guidance.

On the other hand, the watt-hour meter currently installed in consumers is not standardized or standardized, but operates based on different types of hardware 110 and operating system 120 . However, even if the power meter 100 on which the middleware platform 130 and the application 150 are mounted operates based on different types of hardware 110 and the operating system 120, the specifications of the hardware 110 and the operating system 120 and Regardless, it enables functional expansion of the same function.

FIG. 3 is a diagram illustrating a relationship of executing a function by calling an API in the middleware platform in the metering application in FIG. 1 .

Each function of the metering application 150 performs a corresponding function by calling the API 131 in the middleware platform 130 .

These weighing applications 150 include a display function 151a, a setting function 151b, an additional function 151c, a recording function 151d, an automatic manual meter reading function 151e, a self-diagnosis function 151f, and a remote meter reading function ( 151 g).

Specifically, the display function 151a is a function of displaying a measurement value, an instrument state, etc. using the GUI 131g of the API 131 in the middleware platform 130 .

The setting function 151b is a function of changing and storing the setting value for each item according to a button operation using the GUI 131g and the File I/O 131c of the API 131 in the middleware platform 130 .

The additional function 151c is a function of controlling the additional signal device with a control signal received remotely using the metering API 131h of the API 131 in the middleware platform 130 .

The recording function 151d records and stores meter reading data (Load Profile: LP), maximum demand power, events, etc. for weighing items using the File I/O 131c of the API 131 in the middleware platform 130. is a function that

The automatic manual meter reading function (151e) uses the File I/O (131c) of the API (131) in the middleware platform 130 to automatically determine the weighing value of the month on a specified date of each month, or manually weigh the month It is a function to confirm the value.

The self-diagnosis function 151f is a function of performing self-diagnosis on the presence or absence of an abnormality using the metering API 131h of the API 131 in the middleware platform 130 .

The remote meter reading function 151g is a function of performing remote meter reading through the DLMS server 140 using the metering API 131h of the API 131 in the middleware platform 130 . The remote meter reading function 151g performs IMC communication with the DLMS server 140 through the IMC protocol.

Here, the DLMS server 140 transmits meter reading data (power data) from the metering application 150 .

As described above, the metering application 150 performs power metering and measurement, power data display and management functions, and shares power data by interworking with the DLMS server 140 through IMC communication. To this end, the metering application 150 executes a necessary function by calling the API 131 in the middleware platform 130 .

This enables efficient and secure management of applications, and supports a modular software system and remote operation to enhance the value of the device and reduce the cost of maintenance and management.

Hereinafter, before describing the relationship in which the metering application 150 calls the API 131 in the middleware platform 130 and executes a function using a package diagram through FIG. 5 to be described later, the metering application 150 is The package diagram will be described.

4 is a diagram illustrating a package diagram of a metering application.

As shown in FIG. 4 , the metering application 150 is a package for providing various functions of the watt-hour meter 100 , and includes a Meterapp package 11 , a Display package 12 , a Device package 13 , and Imc It includes a package 14 , a Data package 15 , and a Conf package 16 .

Here, a package is a bundle of Java program functions and is a kind of folder-like concept, and includes a class in which a Java file is compiled and converted. Each of these packages performs a different function. A package diagram organizes packages by grouping several model elements such as classes, and expresses the relationship between packages.

The Meterapp package 11 is a main package including the JAVA ME class, which creates the main classes of the Display package 12, the Device package 13, the Imc package 14, and the Data package 15 and executes the initialization operation. perform the function

The display package 12 performs a function of displaying the amount of power on the display device of the power meter 100 and a setting function.

The device package 13 performs a self-diagnosis function and a function of controlling additional signals.

The Imc package 14 performs a function of sharing meter reading data with other applications. As mentioned above, the middleware platform 130 supports the IMC protocol to communicate with the application 150 .

The data package 15 reads, writes, and deletes power data including meter reading data.

The Conf package 16 performs a function of managing the configuration file of the watt-hour meter.

5 is a diagram illustrating a relationship in which a metering application calls an API in a middleware platform to realize a function in FIG. 3 using a package diagram.

The metering application 150 outputs various information to a display device installed outside the watt-hour meter 100 and performs a unique setting function of the watt-hour meter 100 .

In addition, the metering application 150 performs a function of self-diagnosing the state of the watt-hour meter 100 , transmitting the result to other applications or components, and measuring power consumption to manage power data.

In addition, the metering application 150 interworks with the DLMS server 140 through the IMC protocol.

The DLMS server 140 communicates with the DCU to perform a remote meter reading function of the watt-hour meter 100. The DLMS server 140 receives power data from the metering application 150 and transmits the power data to the DCU using the DLMS/COSEM protocol.

Referring to FIG. 5 , the Meterapp package 11 creates the main classes of the Imc package 14 , the Data package 15 , and the Conf package 16 , and performs initialization and termination operations, and a job scheduling function. .

The Imc package 14 performs a function of sharing meter reading data with the DLMS server 140 . The Imc package 14 performs communication using the IMC protocol through the GCF 131b of the API 131 in the middleware platform 130 .

The data package 15 provides power data for the remote meter reading function to the Imc package 14 by performing a function of reading, writing, and deleting power data including the meter reading data. In this case, the data package 15 reads, writes, and deletes power data through the metering API 131h and the File I/O 131c of the API 131 in the middleware platform 130 .

The Conf package 16 performs a function of managing the setting values of the watt-hour meter 100 , and is related to properties in the middleware platform 130 .

6 is a diagram illustrating a configuration of a communication interface environment between a power meter and an AMS server according to an embodiment of the present invention.

As described above, the AMS server 200 remotely manages the installation, deletion and update of the application application 150 in which the necessary functions are implemented in the watt-hour meter 100 . That is, the AMS server 200 is responsible for easily distributing the application application 150 to the watt-hour meter 100 .

Here, the middleware platform 130 ported to the power meter 100 supports the execution environment of the application application 150 remotely distributed by the AMS server 200 . In other words, the application application 150 is executed in a form that operates on the Java virtual machine 132 .

Through this, the watt-hour meter 100 can expand necessary functions even after being installed in the consumer.

On the other hand, the watt-hour meter 100 and the AMS server 200 must be provided with a communication interface environment.

Specifically, the AMS server 200 includes a VM proxy (VM Proxy) 211 that provides an interface capable of remotely controlling the application application 150 through the middleware platform 130 .

And, the power meter 100 includes a VM agent 132b for supporting the VM proxy 211 of the AMS server 200 in the middleware platform 130 . That is, the VM agent 132b connects the VM proxy 211 and the Java virtual machine 132 to each other so that the VM proxy 211 can control the Java virtual machine 132 .

In this way, the VM agent 132b and the VM proxy 211 communicate with each other to exchange data.

Commands transmitted from the VM proxy 211 to the VM agent 132b are divided into channels according to the category of the corresponding command.

The VM agent 132b distributes the processors assigned to each channel. The VM agent 132b transmits commands delivered from the VM proxy 211 as a predefined event, and interacts with the Java virtual machine 132 according to an internally defined function, or returns a command to the execution result. (command) It responds by converting it to an object.

The VM proxy 211 relays commands of other programs or users to the VM agent 132b. Here, the VM proxy 211 has an interface for connection with the VM agent 132b and an interface for connection with other programs or users, respectively. These interfaces are abstracted and constructed so that they can be extended by rewriting the actually implemented class according to the communication method to be actually used.

7 is a diagram illustrating a packet structure transmitted from a VM agent to a VM proxy.

Referring to FIG. 7 , the field of the packet transmitted from the VM agent 132b to the VM proxy 211 includes a record header 21 having a fixed length of 4 bytes, and a variable length. It includes a header 22 and data 23 .

That is, the record header 21 is a field describing a transmitted record packet, the header 22 is a field in which a transmitted command is recorded, and the data 23 is a field in which actual transmitted data is recorded.

In addition, the record header 21 includes a data size 21a that is a field in which the size of the data 23 is recorded, a channel 21b that is a field in which a communication channel is recorded, and the size of the header 22 . A header size 21c that is a field in which is recorded, a system bit 21d that is a field in which bits for distinguishing the system header and the header 22 are displayed, and a record mask (Record) Mask) (21e).

Here, if the field value of the system bit 21d is 1, the subsequent header 22 may be interpreted as a system header.

8 is a diagram illustrating a packet structure transmitted from a VM proxy to a VM agent.

Referring to FIG. 8 , a field of a packet transmitted from the VM proxy 211 to the VM agent 132b includes a record header 31 having a fixed length of 7 bytes and data 32 having a variable length.

The record header 31 includes a 4-byte field in which the entire packet size is recorded, a packet size 31a, and a session ID, a 2-byte field in which a session ID of the currently transmitted data 32 is recorded. Session id) 31b, and a channel 31c that is a 1-byte field in which the current communication channel is recorded.

The data 32 is a data value that is actually transmitted and has a length equal to the packet size value.

9 is a diagram illustrating a packet transmission process between a VM agent and a VM proxy.

9, the packet transmission process between the VM agent 132b and the VM proxy 211 includes an Open Channel process (S101, S102), a header transmission process (S103, S104), It includes a data transmission process (S105, S106).

The open channel processes S101 and S02 are processes for exchanging data for channel initialization (Session id, Channel Hash, etc.).

That is, the VM agent 132b transmits a channel open header (CHANNEL_OPEN_HEADER) and a channel hash (CHANNEL_HASH) to the VM proxy 211 (S101), and sends an ACK message (AVAILABLE_RESPONSE) indicating that the channel can receive the header to the VM It is transmitted to the proxy 211 (S102).

The header transmission process (S103 and S104) is a process of confirming the transmission environment and the transmission data size in advance before actual data transmission.

That is, the VM proxy 211 transmits a packet including a data value to be transmitted in order to check the transmission environment in advance before transmitting the actual data and to check the size of the data to be transmitted in advance ( S103 ).

Then, the VM agent 132b transmits an ACK message (ACK_RESPONSE) having the size value of the received packet to the VM proxy 211 to inform that the data size is normally received and to check the actually received data value (S104). ).

The data transmission processes S105 and S106 are processes for transmitting actual data.

That is, the VM proxy 211 transmits actual data, that is, a packet including a Serialized ProxyCommand object to the VM agent 132b (S105).

Then, the VM agent 132b transmits to the VM proxy 211 an ACK message (AVAILABLE_RESPONSE) indicating that actual data can be normally received (S106).

10 is a diagram illustrating detailed elements of the AMS server in FIG. 1 .

As shown in FIG. 10 , the AMS server 200 includes a communication unit 210 , a data unit 220 , a control unit 230 , and an information exchange unit 240 .

The communication unit 210 is an element having a function of communicating with the power meter 100 , and includes a VM proxy 211 .

The data unit 220 is an element that controls and manages the data access object and the data object of the watt-hour meter 100 and the application 150 , and a data manager 221 that interworks with the database 250 . ) is included.

The control unit 230 executes and controls multiple tasks of elements constituting the AMS server 200 , and processes events of the data unit 220 .

The information exchange unit 240 includes a monitor 241 for controlling connection and exchange with the power meter 100 , and a transport 242 for exchanging information with the control system 260 .

11 is a diagram illustrating an application management service between a power meter and an AMS server.

The AMS server 200 manages registration of the application 150 and remotely manages the application 150 installed in the watt-hour meter 100 . The AMS server 200 can process installation, deletion, and update of the application 150 .

The AMS server 200 periodically communicates with the VM agent 132b in the middleware platform 130 mounted on the power meter 100 to request 'application status information' for the application 150 (S201). Through this, the AMS server 200 determines whether management is required for the application 150 mounted on the watt-hour meter 100 .

Thereafter, the power meter 100 responds to the application state information of the application 150 mounted therein to the AMS server 200 (S202). Here, the application state information may be information provided in a table format with respect to information related to a list, version, etc. of the application 150 mounted on the watt-hour meter 100 .

The AMS server 200 checks the application state information, and performs a management operation for the application 150 of the watt-hour meter 100 (S203). That is, the AMS server 200 communicates with the VM agent 132b in the middleware platform 130 mounted on the watt-hour meter 100, and installs, deletes and updates the previously installed application 150 for function expansion. carry out

Meanwhile, the watt-hour meter 100 may periodically check with the AMS server 200 whether an update for the application 150 is required (S204). In this case, as a result of the check, the watt-hour meter 100 performs an update on the application 150 through the AMS server 200 when an update for the application 150 is required (S205).

Additionally, the middleware platform 130 and the application 150 may be installed in a storage medium such as a mobile phone, a tablet PC, or a USB in addition to the watt-hour meter, and may be managed by the AMS server 200 . In this case, various devices in which the application 150 is installed can be controlled and managed from the outside through the AMS server 200 without expensive home automation equipment or home gateway equipment.

In addition, the middleware platform 130 and the application 150 are not limited to the watt-hour meter 100 , that is, a smart meter, and are applicable to various fields such as an energy gateway.

The method according to some embodiments may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CDROMs and DVDs, and magneto-optical disks such as floppy disks. hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

Although the foregoing description has focused on novel features of the invention as applied to various embodiments, those skilled in the art will recognize the apparatus and method described above without departing from the scope of the invention. It will be understood that various deletions, substitutions, and changes are possible in the form and details of Accordingly, the scope of the invention is defined by the appended claims rather than by the description above. All modifications within the scope of equivalents of the claims are included in the scope of the present invention.

100: watt-hour meter 110: hardware (HW)
120: operating system (OS) 130: middleware platform
131: API (Application Programming Interface) 131a: MEEP
131b : GCF 131c : File I/O
131d : Device I/O 131e : JSON
131f: Security 131g: GUI
131h: Metering API 132: Java Virtual Machine
132a : CLD 132b : VM Agent
140: DLMS server 150: application
151a: display function 151b: setting function
151c: Additional function 151d: Record function
151e: Automatic and manual meter reading function 151f: Self-diagnosis function
151g: remote meter reading function 151: weighing application
152: application application 200: AMS server
210: communication unit 211: VM proxy
220: data unit 230: control unit
240: information exchange unit 250: database
260: control system 300: DCU

Claims (13)

In the power meter having any hardware and operating system,
an application including a metering application related to electricity metering and an application application related to an additional service; and
a middleware platform that operates based on the hardware and the operating system and enables function extension and execution of the application regardless of the hardware and the operating system;
The application is
It is installed, deleted, updated and managed by the AMS server,
The middleware platform is
An element for executing a Java program, comprising: a Java virtual machine including a VM agent that communicates with a VM proxy installed in the AMS server and exchanges data to provide a communication interface environment with the AMS server; and
API for performing functions of installing, loading, and executing the file of the application;
A remote meter reading function of the metering application is performed through a DLMS server by using the metering API among the APIs in the middleware platform, wherein the remote metering function performs IMC communication with the DLMS server through an IMC protocol.
Electronic watt-hour meter with middleware platform for function extension.
delete delete The method of claim 1,
The commands passed from the VM proxy to the VM agent are:
Electronic watt-hour meter with middleware platform for function extension, which is divided into channels according to the category of the corresponding command.
The method of claim 1,
The packet structure transmitted from the VM agent to the VM proxy is,
A field describing a transmitted record packet includes a record header having a fixed length, a header having a variable length as a field in which a transmitted command is recorded, and data having a variable length as a field in which actual transmitted data is recorded,
The record header is
Middleware platform for function extension including a data size in which the data size is recorded, a channel in which a communication channel is recorded, a header size in which the size of the header is recorded, a system bit indicating a bit for distinguishing a system head from a header, and a record mask An electronic watt-hour meter equipped with this.
The method of claim 1,
The packet structure transmitted from the VM proxy to the VM agent is:
It contains a record header with a fixed length, data with a variable length,
The record header is
An electronic watt-hour meter equipped with a middleware platform for function extension including the packet size in which the entire packet size is recorded, the session ID in which the session ID of the currently transmitted data is recorded, and the channel in which the current communication channel is recorded.
The method of claim 1,
packet transmission between the VM agent and the VM proxy,
An electronic watt-hour meter equipped with a middleware platform for function expansion that is performed through the open channel process for exchanging data for channel initialization, the header transmission process to check the transmission environment and data size in advance, and the data transmission process to transmit actual data.
The method of claim 1,
The weighing application is
As a package for providing functions, it includes a Meterapp package, a Display package, a Device package, an Imc package, a Data package, and a Conf package.
The package is an electronic watt-hour meter equipped with a middleware platform for function extension that expresses a mutual relationship through a package diagram.
an application including a metering application related to electricity metering and an application application related to an additional service; and a middleware platform that enables function extension and execution of the application regardless of the hardware and the operating system while operating based on hardware and operating system; and
an AMS server configured to periodically communicate with the middleware platform and perform a management operation on the application according to whether management is required for the application;
The middleware platform is
An element for executing a Java program, comprising: a Java virtual machine including a VM agent that communicates with a VM proxy installed in the AMS server and exchanges data to provide a communication interface environment with the AMS server; and
API for performing functions of installing, loading, and executing the file of the application;
A remote meter reading function of the metering application is performed through a DLMS server by using the metering API among the APIs in the middleware platform, wherein the remote metering function performs IMC communication with the DLMS server through an IMC protocol.
A power meter application management system comprising a.
delete 10. The method of claim 9,
packet transmission between the VM agent and the VM proxy,
The watt-hour meter application management system consists of an open channel process for exchanging data for channel initialization, a header transmission process for checking the transmission environment and transmission data size in advance, and a data transmission process for transmitting actual data. delete delete

Images