Object Model of Home Area Network Devices

Transcription

1 Object Model of Home Area Network Devices ZDENEK BRADAC*, VACLAV KACZMARCZYK**, PETR FIEDLER**, MICHAL SIR* *Department of Control and Instrumentation, Brno University of Technology, Brno, CZECHREPUBLIC **Materials for Sensors and Technological Processes Control Systems, Central European Institute of Technology, Brno, CZECH REPUBLIC Abstract:Smart Grid solutions, combinations of power and communication networks, are getting popular nowadays. In this paper, we focus on the Home Area Network (HAN), the part of the Smart Grid. We intend to create the Home Area Network software simulation framework. This framework will consist of network coordinator that provide network master functionality and arbitrary number of smart home appliances, network slaves. With this framework, we can develop and simulate HAN control and scheduling algorithms. Moreover, in the future we would like to implement and test with this framework smart bidirectional charger of electrical vehicles. Key-Words: Home Area Network, Smart Appliance, Home Coordinator, Network Model, Simulation Introduction 1.1. Smart Grid Network The SmartGrid means the electric distribution network that is able to autonomously detect and control connected devices (both producers and consumers) behavior to maximize the consumption efficiency, delivery reliability in the whole network and transport losses minimization. Both producers and consumers can be joined to the distribution process when SmartGrid approaches are applied. Local producers can have possibility to effectively deliver electric power to the distribution network. Consumers may be motivated to schedule the energy consumption according to the distribution demands (e.g. by lower energy price). The main problem of the distribution network is the irregular consumption, which leads to energy peaks [1]. During these peaks the consumption grows rapidly up to 30 % and by their elimination, necessary investments in the distribution network can be reduced. One of possible reduction methods is to schedule the consumption to the time (of the day), when there is energy surplus. Another method is the dynamic connection of RE resources during the consumption peaks. Last but not least important is minimizing distribution losses (during transformation and transmission), because these can comprise up to 14 % of the total amount of transferred energy [1]. This minimization can be achieved by the proper energy flow management in local scope transferring energy between local producers and local consumers minimize longdistance transmissions Smart Grid network concept The SmartGrid network consists of power (see Fig. 2), communication and information technologies to the heterogeneous system. To achieve properties mentioned in previous paragraphs, the network shall fulfill several requirements [5]. Distributed control all network elements are connected by the communication line. Generators and appliances can be controlled either locally or can take decisions autonomously. Power consumption prediction for several hours nowadays, these predictions are common in the global scope (distribution of large amounts of energy) and should be adapted to local areas as well. Power generation prediction prediction from RE resources is usually difficult because of their dependency on current weather (sun shine, wind). If the weather in the place of installation is forecast, the power production can be predicted. ISBN:

2 Response time to achieve the peak minimization, the network shall react in sufficient time and perform proper decisions, e.g. connect backup power sources, restrict the consumption and thus redirect energy flows to areas with energy shortage. Unused electric vehicles batteries can work as backup power sources. Power consumption restrictions can be accomplished by its scheduling based on e.g. variable energy unit price. Fig. 2 Smart Grid Network Not only to achieve all mentioned requirements, but for its whole functionality, the SmartGrid network uses large amount of different technologies. The interoperability between all technologies is thus crucial. This interoperability is divided into several levels (layers). The lowest layer should e.g. guarantee compatible plugs among several manufacturers. Higher layers then ensure compatibility of communication protocols and business transactions Communication model The Communication model is not the aim of this paper Object model Functional blocks defined by EN specify the functionality implemented and provided by an appliance. Each functional block represents one functional area, i.e. domain. Execute commands is a set of basic messages used to control remotely Household Appliances and to program appliances. Examples of control are START, STOP. An example of programming is Program data. Signal state is a set of basic states used to monitor the state of the Household Appliances by remote means (central controller, etc.). The basic states are static states of the product and are used to monitor the appliance functionality, e.g. STAND BY, RUNNING. Not all defined states are mandatory. Signal event is a functional block to provide appliance event information on the bus. The remote device could be a controller with a display or a gateway. Devices interested in receiving event information can specify whether to receive all the information or only part of it. Identify product is a functional block to provide product information. Identification data are persistent data, i.e. they are kept even when the appliance is switched off Home Area Network Home Area Network (HAN) (see Fig. 3) is a local part of the Smart Grid network. As HAN is usually marked the network behind the local power meter. HAN consists of following devices electric meter, smart appliances, smart plugs, operator panels and home coordinator. Following paragraphs describe intended functions of these devices [4]. 2 EN Specification From the functional point of view, the EN50523 defines two kinds of devices and network model: Communication model Object model Fig. 3 Home Area Network Collect diagnosis data is a functional block to provide diagnosis data. There are several ISBN:

3 approaches how to get diagnosis data from the appliance and several diagnosis data organizational structures. Manage time is a functional block to provide time reference and possibly to update time reference through a trusted clock. Application error management is a functional block defining the behavior of appliances in case of application errors. In the following chapter, we create a fundamental kernel of coordinator and home appliances and we describe how above mentioned functional blocks are implemented. 3 Device models 3.1. Home Coordinator device Introduction Home Coordinator device (Home Area Network Master), as described in chapter 1, is the device controlling all devices inside the network. The model, we present in this chapter, is significantly simplified. We have focused mainly to communication and control parts. For the sake of clarify, we have created simple GUI to the model, but most of functionality of the real home coordinator (e.g. comfortable control, creation of statistics, web server etc.) has been omitted. Both models, the coordinator and appliance models are part of HAN simulation framework. This framework contains also its specific communication protocol, for the purpose of demonstration, The coordinator device model has been developed as a set of mutually dependent objects in a c# language (.NET platform). During development, the object oriented development approach has been applied.the coordinator is thus a set of several object wrapped by the BasicCoordinator class.the inner functionality of the device can be divided into two main groups: Periodical specific functions are called periodically, e.g. functions for particular time Fig. 4 Coordinator device simplified class diagram ISBN:

4 slot computation. Event based functions depending either by receiving message from smart appliance, command from user etc. Here we focus on two main objects (coordinator logical parts) communication and control interface. The communication interface can embed any appropriate object (i.e. one can implement any communication protocol layer and use it). The communication part is connected with the control part through generated events. This connection always allows much higher variability than connection through function calls Object model Here we describe the control interface in detail.in the Fig. 4 the whole control interface is shown as a class diagram. The fundamental class, BasicCoordinatorimplements the basic functionality of the device. It mainly allows connection of all device parts together. The BasicCoordinator functionality has been extended by implementing class ProfiledCoordinator. This class contains all necessary methods to maintain information about scheduling with respect to power profiles. Note this class is embedding ProfileManager and PriceManagerclasses. These classes take some parts of ProfiledCoordinator functionality over. ProfileManagerdeals with all smart appliances data and converts them to format more suitable to be processed by solving algorithm.pricemanager is the class implementing price value detection and decision and prediction functionality. The PriceManager class or its inherited classes should contain functionality to obtain the energy price from the Smart Grid network. This functionality is not yet implemented in the simulation framework. Instead, we use predefined electricity price curves.profiledcoordinator class is responsible for evaluating the appliances scheduling plan. The interface IAlgorithm, used by ProfiledCoordinatorcontains Init(), Solve( ), and Close() functions. These functions are called from ProfiledCoordinator before scheduling process starts, when a time window expires and new scheduling plan is requested, and before the coordinator is shut down. The BasicCoordinatoruses the class AppliancesList to keep state information of all connected appliances. This class maintains a list of BasicApplianceWrapper instances. Each of these objects fully describes basic state of the connected appliance (it is equivalent to some kind of stamp or facade representing only state variables and information, but no functionality). When new appliance is found in the network, after detailed identification its stamp is added to this list. If appliance is inactive for some defined period, its stamp is automatically removed from the list. In the Fig. 4 one can see that there are several classes inherited from the BasicApplianceWrapper. Objects of these types (Controlled and Profiled ) can also be added to the list. Such objects represent smart appliances with additional functionality. AppliancesList implements basic network functionality, automatic appliance addressing (so called appliance detection and configuration), and death appliances detection. Moreover, this class implements periodic appliances query. By this query appliances can only autonomously send (i.e. respond) message to the coordinator. BasicApplianceWrapperimplements basic appliance connectable to the network. ControlledApplianceWrapperimplements appliance stamp with control function. Such appliances thus can be controlled by simple commands (start, stop, wait and others defined in [6]). This class is also responsible for detecting state responses send autonomously by appliances. ProfiledApplianceWrapperis yet more sophisticated stamp implementing power profile support. That means active power profileset in appliance is transferred by the network and remembered by this stamp Control based on power profile The ProfileManager class (that can be found in the Fig. 4)implements converting algorithm. This algorithm converts data stored inside all ProfiledApplianceWrapper stamps and converts them to data appropriate for the mixed integer linear programming (MILP) problem solver. MILP solver should implement interface IAlogrithm. Then the MILP solver could be used to calculate appliances scheduling problem Smart Appliance The Smart Appliance, as the network slave device is from the functional and communication point of view defined as a set of objects, mutually bound by function calls and events.the object ISBN:

5 oriented modelling and programming is thus used to implement it. The basic class CommonAppliance is used to embed and connect all device modules. The communication interface, as well as the device s runtime object model is initialized by this class. The communication interface functionality is quite straightforward, so it is not the aim of this paper to describe it. In the following subchapters we focus on the runtime object model and to communication events processing (i.e. communication frame reception) Runtime object model Every smart appliance model consists of nonempty set of functional blocks, so called clusters. Every cluster defines State attributes set of variables and constants defined by the cluster. Commands received set of commands that can be received and answered by the cluster. Commands generated set of commands that can be autonomously generated by the cluster. The class diagram of the smart appliance is shown in Fig. 5. One can see the appliance kernel (CommonAppliance). All cluster classes are inherited from the CommonCluster class. We can see the method Received(). When the CommonAppliance class receives a communication frame, it calls, one by one, this function in all defined clusters.inside every cluster, the frame type and other significant parameters are compared with inner list of supported frames and if the frame is supported, the cluster generates response to it. The situation that two or more clusters generate the response frame is allowed. This situation occurs usually as a response to query frame (clusters are responding by generated events). In that case, one cluster is served and others should wait until another query frame is received. Coordinator should send the query frame to every device periodically with sufficient time interval. Every slave device should include at least one cluster instance of IdentificationCluster. This cluster specifies detailed device information, e.g. model name, vendor id, product type, revision, serial number etc. Other clusters are not mandatory Cluster example For the sake of clarify, we show here the detailed description of one cluster of type ControlCluster. Following paragraph shows three types of entities Fig. 5 Smart appliance simplified class diagram defined by this cluster (defined earlier in this chapter). State attributes: ApplianceStatus present state of the appliance. There are several predefined states in [6]. EnergyManagementEnabled defines whether the appliance can be remotely controlled. StartTime desired start time of the appliance cycle. EndTime desired end time of the appliance cycle. Commands received Execution frame contains the desired appliance status. If energy management is enabled, the device makes effort to change state to the desired one. TimeSpan frame contains desired start or end time. Coordinator can thus force these values to the appliance. StateQuery query frame to obtain generated events from the appliance. Commands generated: SignalState event generated and frame sent when the appliance status changes. TimeSpan event generated and frame sent when appliance start or end time changes. ISBN:

6 4 Conclusion and future work The paper describedobject models of home coordinator device (HAN master device) and smart appliances (HAN slave device). Object models and devices functionality is based on EN specification [6]. Simplified class diagrams of both master and slave devices were presented and specific classes were described. Models, together with our communication protocol (described in another paper of same authors)comprise the simulation framework, as is presently implemented. As a future work, we propose implementation of Mixed Integer Linear Programming solver to the coordinator device. When the electricity price is obtained from the Smart Grid, the coordinatorcan work and schedule Home Area Network appliances effectively. Acknowledgement: This work was partially realized in CEITEC Central European Institute of Technology with research infrastructure supported by the project CZ.1.05/1.1.00/ financed from European Regional Development Fund, by ARTEMIS project Internet of Energy for Electric Mobility (project no ), partially by Grant Agency of the Czech Republic (102/09/H081 SYNERGY Mobile Sensoric Systems and Network) and partially the Supporting research of modern methods and approaches in automation from the Internal Grant Agency of Brno University of Technology (FEKT- S-11-6). References: [1] Xinghuo, Y. et al. (2011). The New Frontier of Smart Grids. IEEE Industrial Electronics, Volume 5, Number 3, pages [2] Pavlátka, et al. (2011). Strategickézměny v energetickýchsoustavách. Elektroenergetika, volume 3, pages [3] The Energy@Home Technical Team, (2010). Energy@Home technical specification, [4] The Energy@Home Technical Team, (2010). Energy@home: a User-Centric Energy Management System [5] IEEE IEEE Guide for Smart Grid Interoperability of Energy Technology and Information Technology Operation with the Electric Power System (EPS), End-Use Applications, and Loads. (2011). New York, USA : The Institute of Electrical and Electronics Engineers, Inc., 110 pages. ISBN [6] EN Household appliances interworking - Part 1: Functional specification. (2009) Brussels, Belgium. CENELEC. 78 pages. [7] Microsoft Solver Foundation [8] Kaczmarczyk, V. Sir, M. Bradac, Z.: Ethernet Powerlink Asynchronous Phase Examination. (2011). Corfu Island, Greece. Recent Researches in Communication and IT. Pages ISBN ISBN: