D

Journal of Energy and Power Engineering 6 (2012) 993-998

DAVID

PUBLISHING

Design of ADCS for Efficient Meter Data Collection and Management Nam-Joon Jung1, Il-Kwon Yang1, Seung-Hwan Choi1, Chang-Hun Chae1 and Young-Taek Jin2 1. Software Center, S/W Center for KEPCO Research Institute, Daejeon 305-760, Korea 2. Department of Computer Science, Hanbat University, Daejeon 305-719, Korea

Received: May 12, 2011 / Accepted: September 20, 2011 / Published: June 30, 2012. Abstract: ADCS (automated data collection system) is the element of MDMS (meter data management system) and a module in charge of collecting the data from DCUs (data collection units) or meters in AMI (advanced metering infrastructure)-based interactive two-way communications infrastructure. In this study, ADCS’s functions for K-AMI (Korean Advanced Metering Infrastructure) were analyzed and the logical design of ADCS which is suitable for the requirements was suggested. A massive data collection and management functions was defined as very important functions of ADCS to meet optimal data processing mechanism. ADCS was designed for support about the fuctions of data collection and transfer, large capacity data processing, interactive services, parallel processing, etc.. Also, ADCS has roles of protocols exchange and gateway for service support in addition to data collection in AMI environment. Key words: AMI, MDMS, ADCS, DCU, smart metering.

1. Introduction Comparing to the environment of AMR (automatic meter reading), the range of information flow for AMI (advanced metering infrastructure) is expanded from the existing metering system to home area network. The information flow is required to change from one-way communication to two-way communication in AMI environment [1, 2]. AMI is required the methods for processing massive communication traffics data. Because AMI system collects meter data using two-way communication and exchanged various service data from home network [3]. ADCS (automated data collection system) is a system aiming to collect the data from electric meter (possible to gas or water meter) remotely and it can be classified as an element of MDMS (meter data management system) which is one of the AMI’s components. According to

Corresponding author: Nam-Joon Jung, principal researcher, research fields: standardzation of power information and smart grid. E-mail: [email protected].

the use case of Southern California Edison, ADCS is closely connected with MDMS, and it performs a role of processing or relaying various events and On-demand data (required by MDMS) as well as managing the periodically collected data [4]. Since ADCS’s measurement cycle required by AMI system is generally 15-minute level, in that time how all of the meter data can be collected more accurately without bottleneck is crucial [5]. That required function can be affected by environment of communication and operating facilities and in the future an increase of meter’s physical quantity also can affect it. In Korea, Korea Electric Power Corporation started the remote metering for 170,000 industrial and commercial customers, and development project for AMI technologies was performed from June, 2009 to May, 2011 [6]. In this paper, the ADCS functions and requirements are analyzed, then the direction for the logical design of ADCS for massive and real time meter data processing is suggested and designed.

994

Design of ADCS for Efficient Meter Data Collection and Management

2. Functional Requirements of ADCS The previous AMR (automatic meter reading) system which is collected meter data needs the new concept of design for satisfying the requirements of AMI because the old system is forced to collect the data for the purpose of calculating monthly fee. K-AMI (Korea AMI) system has a schema as shown in Fig. 1. ADCS connects to MDMS and DCU (data collection units). ADCS has some FEP (front end processor) [5]. The K-AMI system development team that consists of Korea Electric Power Company and several private companies analyzed the use case of SCE (southern california edison) and developed the new AMI use case that is suitable for a domestic environment. The logical architecture of K- AMI (Korean Advanced Metering Infrastructure) which is adopted by development team is same to Fig. 2. The requirements of the system generally consist of functional and non-functional features. According to the use case of SCE, the functional/non-functional features of ADCS are represented the various part such as “B1 Multiple clients read demand & energy data: Automatically from customer premises” of “Billing & Customer Service” and “C1 Customer reduces their usage in response to pricing or voluntary load reduction events”, “C2 Customer has access to read recent energy usage & cost at their site” of “Customer Interface” [4]. The considerations for design and development of ADCS will be listed as follows:  Time scheduling;  Meter configuration management;  Massive data collection & processing;  On demand metering;  DR program support;  H/W & network performance. 2.1 Time Scheduling The ADCS shall manage the default schedule read time for all DCU or AMI meters;

Fig. 1

Scheme of K-AMI system.

Fig. 2

The logical configuration of AMI.

The ADCS shall have the ability to remotely set/update/cancel a meter’s read schedule for a specified or on-going duration; The ADCS shall receive acknowledgement of a read schedule setup from the meter within 15 minutes; The ADCS shall have the ability to place meters into read schedule groups; The ADCS shall be able to automatically retry to transmit event messages to the meter, display device and control equipment within 60 seconds. The frequency and timing shall be configurable. 2.2 Meter Configuration Management The ADCS shall have the ability to communicate updated/replaced read schedule information to DCUs; The ADCS shall be able to remotely configure the meters recording interval length to between 5 and 60 minutes; Internal AMI meter clock shall remotely validate its time at least once a day with official AMI system time (It is processed by NMS (network management system)).

Design of ADCS for Efficient Meter Data Collection and Management

2.3 Massive Data Collection & Processing

995

be treated in log.

The ADCS shall be able to communication event messages to 2,000,000 AMI meters within 3 seconds for 99% of the meters and within 10 seconds for 1% of the meters; The ADCS shall be able to save event message to 2,000,000 AMI meters within 15 minutes; For saving hundreds of data, the ADCS is guaranteed for performance in handing massive storage and real-time processing; The ADCS’s output has to process within 1 second; In order to reduce the latency in the collection of communication and storage level, the ADCS shall have competitive architecture not only performance of hardware but also software.

2.4 On-Demand Metering

2.7 Operation

The ADCS shall have the ability to execute a mass on demand read for all meters which are missing data within a specified timeframe; The ADCS shall be able to transmit all data received from the meter, display device and control equipment (e.g. usage, logs, alerts, receipts) to the MDMS; The ADCS shall manage the data which is push-uploaded data by DCUs, and distributed it in real time; The ADCS shall verify the data at the level of application protocol. Thus, if it is not correct, it should

The ADCS shall have the ability to execute a mass

The ADCS shall log details of all non-default meter

on demand read for all DCUs or all meters which are

read schedules, including the source (system/party) of

missing data within a specified timeframe;

each non-default schedule;

The ADCS shall have the ability to execute mass on

The ADCS shall have the ability to identify read

demand reads in an optimized manner to prevent

groups that consistently retrieve all reads within

system overload problems;

scheduled time parameters; The ADCS shall record the results of read group analysis and the resulting actions taken;

The ADCS shall have the ability to transmit prepayment event schedules to DCU or the AMI meter on-demand. 2.5 DR Program Support The ADCS shall be able to transmit event messages to the DCU, meter, display device and control equipment containing the current date/time, event code, event schedule date/time (start and end), priority and hourly or time-of-use pricing;

The ADCS shall have the ability to communicate initial read schedule information to AMI meters; The ADCS shall be able to issue a remote meter test and make the results available to other utility systems (e.g., trouble reporting system, CSS (customer service system).

3. Requirements for Architecture Design of ADCS

The ADCS shall log each instance when an event message has been sent to the DCU or AMI meter; The ADCS shall deliver messages from DCU to MDMS. 2.6 H/W & Network Performance The ADCS shall transmit all data (e.g. Usage, logs, alerts, receipts) received, to the MDMS within 3 seconds;

3.1 Data Collection & Transfer ADCS uses pull/push method for collection of data and is capable of realizing push method as the base method to reduce the number of communications by transferring data from DCU to ADCS server and from ADCS server to MDMS. ADCS should control load distribution automatically or at time preferred by administrator to collect data from a number of meters

Design of ADCS for Efficient Meter Data Collection and Management

996

and DCUs. Since the frequency of On-demand

Section 3, six process modules and three databases

requests in On-demand data processing through

was designed like a Fig. 3 for ADCS.

ADCS from MDMS is low compared to that of real-time data collection, it is okay to only use pull

4.1 Data Retrievers

accommodation of up to 200 meters, but the realty is

This is data collecting module. It directly communicates with DCU or meter to collect data. All collection processing starts from the ones having message command from “outbound queue” of queue manager. Module internally consists of “multi-threads pool”. “Multi-threads pool” is an architecture allowing maximum performance with the minimum use of system resources, and it is “the architecture for high-performance” being selected in all from web servers to WAS (web application server). Collected data are read and processed by Data Processors in accordance to commands from “inbound queue” of queue manager. “AP Stack (application protocol stack)” in this module defines the protocol at application level for data collection and checks conformability of protocol-based data.

limited due to the existence of regional and physical

4.2 Queue Manager

method in data collection and transfer. In addition, the input/output load distributing method should be considered to solve traffic overload problem in terms of communication. 3.2 Large Capacity Data Processing High performance data processing is required for processing large amount of data based on 15-minute level of data measuring in real-time or limited time. And ADCS should transfer the data rapidly to MDMS or DCU for processing of statistical data or customer-oriented service. 3.3 Allowable Limit Performance of System Theoretically, the specification of one DCU allows

limitations. In future, electronic watt-hour meter will be supplied for residential customer. The 10,000,000 pieces in G-type (General Type) for 15-minute level measuring

and

8,000,000

pieces

of

E-type

(Economic-Type) requiring measuring at the one-hour level are planned for installation in Korea by 2020. So, the

design

of

hardware

server

and

network

considering such an implementation plan is needed. The ADCS is expected to role for LDC (Local Distribution Company) of North America and Europe.

Data sharing between each module within the system should be made through queue (circular FIFO). If there is a lot of data for processing, the Queue has various functions. It can be resolved the bottleneck phenomenon that may occur between processes or modules. In addition, it can be performed role of bus for data monitoring and internal communication. Parallel processing is very effective to speed up performance. For parallel processing, ADCS uses

Therefore, it should be designed to manage network and system performance that can reflect the regional characteristics. If business model side is considered, the data collection between DCU and ADCS should be within 10 minutes. The FEP and L4 switch will be used for I/O load balancing.

4. System Architecture of ADCS ADCS was designed for support of less than 3 million customers. To satisfy the requirement of

Fig. 3

Component and process of ADCS.

Design of ADCS for Efficient Meter Data Collection and Management

multi-thread pool as a process in queue manager module. Multi-thread is possible owing to multi-core CPU (central processing unit). Parallel processing instead of serial processing can perform incoming much data quickly (in Fig. 4).  L1 reads a sequential data from a socket. That means L1 can be taken one data a time;  Thus, if L1 takes one minute to read/process data, 10 data spends 10 minutes;  However, total time is 5 minutes (10/2 = 5) if two processes enable processing at the same time;  The thread of processing data such as T1, T2, T3 and T4 stays on the Mutex;  The Mutex sends the event to T1, T2, T3 and T4 when L1 inputs it in Queue after reading data;  The earliest thread of an acquisition events reads Datum1 in Queue, and the Mutex consistently sends event to T1, T2, T3 and T4 because of existent data in Queue;  One of them such as T2, T3 and T4 reads Datum2 because T1 already processes data;

997

 If your hardware enables multi-thread of multi-CPU, you are able to handle more events at the same time. 4.3 Scheduler The data collection policy, cycle and distribution information come from the rule database by Scheduler. It approximatively calculates schedule and performs a request of data collection by Queue Manager. Request of transferred data collection is performed in data retrievers. Request of periodic read can be processed through this module. 4. 4 Data Processors This is a data processing module and performs the role of saving data in ADCS meter collection information database by having data collected by data collector to read data written on “Inbound Queue” of queue manager. Similar to data collector, it consists of “multi-threads pool” and “AP Stack” of this module defines protocol at the application level for saving as CIM (common information model) based long-sighted DB table and checks conformability of protocol-based data. The database design & algorithm for massive data, as it is mentioned above, is possible to use multi-thread in a system. However, the system should use the database separately as a meter unit. Bottleneck phenomenon in data processing can be fixed through

Fig. 4 Parallel processing using queue & multiple threads.

database design of meter unit. Lock mechanism is generally used to ensure integrity and concurrency of data entry.

Fig. 5

Comparison of meter data handling method.

As shown in left of Fig. 5, the Meter 1 or 2 can cause the lock problem in case of inputting the data in Meter 2. In other words, they are sequentially written data for a reason of the lock mechanism. However, the lock mechanism will not fall under anymore if you could separate the database as meter unit. Because they do not depend on each other. To accomplish great things like a parallel processing, database must be separated with a meter.

998

Design of ADCS for Efficient Meter Data Collection and Management

This is a managing module for management of ADCS system. It is recommended that Web UI is set as the basic interface. Administrator will require a method to search and control information on ADCS.

appropriate to consider the plan for unit system capable of accommodating 1,000,000~2,000,000 pieces of meter, which is the overall meter number within one region. For operation of the system at above level, real-time large-capacity data processing technology, efficient scheduling technology, optimized hardware & communication system calculating technology, and simulation technology are required. In addition, presently imaginable data collection and limitation of DR service should be surpassed and design of the system capable of bearing system load based on creation of new power service should be executed.

4.7 Data Base

Acknowledgments

The meter information database records primitive meter data collected from meters within 15-minute. The log database records log on all processing requested from MDMS or collected from DCU or meter. Finally, the rule database is the database managing data collection cycle, policy, and load distribution information. It is loaded and requested based on scheduler module.

This project was supported by MKE (Ministry of Knowledge Economy) of Korea.

4.5 MDMS Listener This module receives a request from MDMS. If the purpose of the request is identical to data collection of on-demand, this module saves to write the request in “Outbound Queue” of Queue Manager for using at next task. And, any other data are processed in “AP stack”. 4.6 Admin Web

5. Conclusions ADCS is an elemental function of MDMS and performs a role of collecting data of meter from AMI-based bi-directional communication infrastructure. ADCS collects meter data in method of direct communication with DCU or meter, and it is a module performing and transferring event of MDMS. In structure where data collecting system of present ADCS function is focused in large cities, it is

References [1]

[2]

[3]

[4]

[5] [6]

I.W. Lee, J.I. Lee, Information and Communication Technologies for Smart Grid, Korea Information and Communication Society, 2010, pp. 3-11. B.K. Song, S.B. Kim, J.C. Kim, The AMI Network for Smart Metering, Korea Institute of Electric Engineers, 2009. N.J. Jung, A Management Study of Customer Devices and Network in AMI Environment, Korea Institute of Electric Engineers, 2011. J. McGrath, AMI Use Case: B1—Multiple Clients Read Demand and Energy Data Automatically from Customer Premises, Southern California Edison, Feb. 2006. Development of AMI System, Ministry of Knowledge Economy of Korea, Interim Report, Mar. 2010, pp. 78-88. Development of AMI (Advanced Metering Infrastructure) System (Project Proposal), Korea Electric Power Research Institute, May 2009, pp. 14-46.