In the past electricity meter data used to be manually read by meter readers after a stipulated time interval and thereafter the bills could be computed for delivery to customers; this is no longer the case with either automated meter reading (AMR) or advanced metering infrastructure (AMI) systems in place. These latest technologies utilize the near real-time meter data from various system components for computing energy bills as well as for performing other business processes (e.g., outage management, asset management, load forecasting, etc). The Meter Data Management System (MDMS) interacts with and gets its data from a plurality of metering devices herein referred to as Advanced Metering Infrastructure (AMI) system components.
Smart Metering poses a lot of data management challenges to utilities where the use of human experience to correct errors would be time-consuming for thousands of meter reads collected at either 15 or 30 minutes, or hourly intervals. In such cases, there is need for the design of systems that will automatically be running as embedded engines within the Meter Data Management solutions/systems. This is the essence of this discussion on a State Machine Conceptual Model to help in understanding the Smart Energy Metering data management processes.
Key terms: Smart Metering Data Management Processes, State Machine, Process Scheduler
Smart Metering has witnessed a colossal increase in data volumes that need to be processed by utilities; this data comes from several geographically dispersed customer locations. The data is thereafter distributed to the appropriate business operations such as: billing, asset management, outage management, load research, trading and marketing, etc. The exponential growth in data requirements by utilities calls for an equally responsive near real-time data management for the business processes.
The time series data environment evidenced in the Smart Metering technology, as depicted in (Quigley, 2008), is critical to the performance and scalability of the MDMS to have the ability to capture, process, manage, and distribute the increasing data. A suitable database technology is thus necessary. Most vendors use relational database technology with some fine tuning (Oracle, SQL, DB2) while others use a true time series (a sequence of observations ordered in time) database environment (Silberschatz et al, 2002). This type is specifically designed to meet the unique requirements of a time series data.
Meter data management issues in the utility metering context relate both to different types of meter devices and communication protocols, as well as their data gathering tasks. Sonderegger (2010) outlines that given the huge growth in meter types, data parameters and data interfacing tasks, utilities will need to be able to collect, validate, import, and process relatively large volumes of data, sometimes gathered from literally thousands of individual meter installations, or data points. The data is then conveyed through a dedicated network to the centralized meter data management system (MDMS), where several processing stages go on before the data is available in appropriate formats to be used by various business processes.
This paper will discuss a State Machine Conceptual Model for Smart Energy Metering Data Management Processes. It begins with an introduction to Smart Metering Data Processes. The rest of the paper is organized as follows: Section 2 discusses a Conceptual Model for the Smart Metering Processes; Section 3 gives a short Conclusion of the paper; and Section 4 cites the References used in piecing up the paper.
1.1. Meter Data Management System Services
The MDMS comprises application and database servers with meters having channels that are organized into workbins – these consider physical or geographic proximity to one another, whether meters are in the same time zones, or using related factors. Meter data from a plurality of meters may be received in a variety of formats and then filtered. Meter data may also be rejected and converted into error files if certain criteria are not met, for example, when they contain duplicate data, or have out-of-range timestamps (Sonderegger, 2010).
The meter data may be collected through intermediary data repositories or directly from the meters within a Local Area Network (LAN). The LAN communications may occur in a variety of forms, including but not limited to radio frequency (RF) transmissions (e.g, in accordance with cellular, Bluetooth, etc), power line carrier (PLC), broadband over powerline (BPL), or public-switched telephone network (PSTN), as well as other public, private, and wireless IP-based communication networks operating as standalone networks or in combination with other networks.
One or more firewalls may be provided as an integrated collection of security measures for protecting the MDMS from undesirable data or executable programs that may affect the performance of the system. A network interface may also be provided to buffer, handle the relay of such communicated data as it is sent or received over a network, or to transform data between other systems (e.g., a user interface that allows customers to troubleshoot or customize aspects of the MDMS), output devices and meter events. Files may be presented as XML or in any suitable mark-up language format.
The three main functional services in the MDMS include:
• The Receiver Service,
• The Validation and Estimation Service, and
• The Data Import Service.
The receiver subsystem may transform the meter data into binary files identified by workbin number and one or more timing parameters (e.g, day and time) on which the meter data was read (Sonderegger, 2010). Subsequent steps may involve Validation and Estimation according to some established rules, for instance, to identify when 24 hours’ worth or some other predetermined amount of valid data has been received. The data may be validated by comparison to historic data in accordance with predetermined rules to ensure that this data falls within certain acceptable limits (Hubbart et al., 2009). If the data is found to be valid, it can be provided in a clean binary format and indicated as ready for import. If the data is invalid, an estimation sub-process may be implemented for the missing/invalid data based on prior data for similar timeframes, or other parameters as defined by the utility. The final step involves automatically importing the data files with validated and/or estimated data files once these are ready.
2. STATE MACHINE CONCEPTUAL MODEL
2.1. State Machine Process Scheduler
The Process Scheduler schematic, designed from first principles, depicts three main areas of a Meter Data Management System: the Receive, the V&E and the Archive, each of these considered as a sub-database consisting of minor database tables necessary to achieve the overall MDMS functionalities. The Receive Area receives meter readings from the field devices, processes these from XML format into legible meter reading information. The V&E Area carries out the data Validation (and Estimation if necessary) before this data is passed to the Archive Area. The last section gets the meter data, archives it, and writes copies of the original meter readings as well as the estimated values in the history data tables.
The existing smart meters are connected to the grid network and the measured data is relayed via a dedicated communications network to a data repository. In this design, the meter1/2/3 table is used as a data repository. The information about the currently connected smart meters is available in an embedded database, which is invoked whenever a particular meter has to be accessed to get its reads. The invoking of the process is done dependent on a utility’s preference.
For the typical design, the real-time clock (RTC) is triggered after every 15 minutes; hence there will be 4 readings per meter in one hour or 96 readings after 24 hours. The data is then kept in a repository. Information about the online meter(s) is found by invoking the meterinfo table. The RTC after every 24 hours triggers the entire cycle which validates and estimates a day’s data.
After the trigger signal, the State Machine runs in a sequence to execute the stored instructions necessary for state transitions. One process state finishes before the next one begins until all the meter data have been checked for correctness (and estimated if necessary) and these are finally stored in a history database. From the history database tables, these meter readings become available for use by other enterprise applications. The data flow between processes and previous database table is depicted as bidirectional in order to request and transfer the data to the next table. The process scheduler shows the data flow, the control signal and the connection to the communications network. See Figure 1.
2.2. Summary of State Machine Model
The conceptual MDMS process scheduler is converted into legible internal procedures which may be realized by an algorithm. This is the concept of state machine in software development. In this paper, the state machine is conceptualised to simulate the MDMS functionalities. A State Machine or Finite State Machine (FSM) or Finite-State Automaton may be understood as a behaviour model composed of a finite number of states, transitions between those states, and actions, similar to a flow graph in which one may easily inspect the way logic runs when certain conditions are met (Forouzan & Fegan, 2003).
The operation of a state machine begins from one state (called the start state), takes different input conditions for transition from one state to another, and when there occurs successful operations, it is described as having had accept states. A transition indicates a state change and this is described by a number of conditions which need to be fulfilled to realize the change. An action is an operation that needs to be performed at a particular moment.
A summary of the procedures is as follows:
i. The start state occurs when the RTC is triggered to get readings from online meters. A timing parameter ensures that the process is triggered at particular instants.
ii. Communication is established between the metering elements and the central database (herein referred to as the MDMS).
iii. Access is made to both the online and history databases in order to select the number of meters to be validated and estimated (if necessary). The meters could be from one geographical region, or belonging to a class of consumers in a region, etc.
iv. The measured parameters for the selected meters are downloaded and saved in some temporary or dedicated data table.
v. The parameters for these meters (Group ID, Device ID, Time of Use, Value, etc) are confirmed/validated as the expected ones; those in error are stored in the error folder within the MDMS.
vi. The current and previous meter reads are compared according to a utility’s uniquely established meter data validation rules.
vii. Estimation is done if the meter readings do not conform to the established validation rules.
viii. The original meter readings are then stored in the history tables, for future reference and versioning. The new validated data is availed in an authenticated database for use by business applications.
The procedural flow of information in the MDMS has been used to suggest a conceptual model of an MDMS process state transition from meter data reception, data Validation & Estimation and eventually storing this data in history database tables. Additionally, the conceptual design has been converted into a legible flowchart depicting a state machine, which simplifies the understanding and eventual realization of the behaviour model. This serves to simplify the concept of Smart Energy Metering Data Management Processes that are carried out through embedded intelligent engines often involving complex internal processes.
Sonderegger, R. C. (2010, May 13). System and Method of High Volume Import, Validation and Estimation of Meter Data. Retrieved August 12, 2016, from United States Patent Application Publication: http://www.freepatentsonline.com/20100117856.pdf.
Hubbard, D., Skog, J., & Ramachandran, V. (2009, July 7). Method For Meter Validation, Estimation and Editing of Daily Meter Read. Retrieved September 8, 2016, from Freepatentsonline: http://www.freepatentsonline.com/7557729.html.
Quigley, R. (2008). The Changing Face of Meter Data Management. Metering International Issue 1 , 84-86.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2002). Database System Concepts. New York: McGraw-Hill Inc.
Forouzan, B. A., & Fegan, S. C. (2003). Foundations of Computer Science: From Data Manipulation to Theory of Computation. Toronto: Thomson Learning.