A Management System for a Distributed Power-Line Based Communication Infrastructure

Transcription

1 A Management System for a Distributed Power-Line Based Communication Infrastructure Aleksey Bratukhin Institute of Computer Technology Vienna University of Technology Gusshausstr /384 A-1040 Vienna, Austria bratukhi@ict.tuwien.ac.at Gerhard Pratl Institute of Computer Technology Vienna University of Technology Gusshausstr /384 A-1040 Vienna, Austria pratl@ict.tuwien.ac.at Abstract Maintaining a hierarchical communication system with different components participating in data exchange is a complex task that requires a management infrastructure, which allows controlling and monitoring all components. This paper introduces the management system concept for a communication system that is based on power-line communication (PLC) and an IP-based backbone. The management system is independent of the PLC system; therefore it is able to be being used on different communication media like GSM networks or IP-based networks 1. Introduction Devices that are communicating over a network and are located in various, distributed location require remote management. The REMPLI project (Real-time Energy Management via Powerlines and Internet) develops the architecture for a system that provides Automated Meter Reading (AMR), energy management and domotic applications. It uses power-line communication to establish a wide-scale control system without excessive installation costs for additional communication infrastructure. That means that communication is not bound to a serial line that establishes a point-to-point connection between a field device and an application, but consists of different network segments, which have to communicate to each other. This paper focuses on the remote management of components like network infrastructure components (e.g. bridges) as well as the equipment providing the actual data that are of interest for the user if the system (e.g. energy meters). Previous research has shown that existing management protocols like SNMP are unsuitable for the purposes of REMPLI [1]. The REMPLI management system provides the following functionalities: Configuration of the system components Monitoring of the system Maintaining the logs of the system components The paper is organized as follows: section 2 gives a brief introduction into the architecture of the communication system, section 3 explains the different aspects of the management system and provides some taxonomy for the different parts of the system, section 4 explains the three management functionalities configuration, monitoring and logging in detail, and section 5 describes the software modules that cooperate in the system. Finally, the conclusion in section 6 sums up the results and gives a short outlook. Figure 1: System architecture 2. REMPLI System Architecture The REMPLI project implements a power-line communication infrastructure to connect existing application software of utility companies with field-level equipment at the customers premises. The project is carried out within the Fifth Framework Programme of the EC (the project identifier is NNE ) X/05/$ IEEE

2 As shown in Figure 1 the communication network the power grid is used as the physical medium to transmit data. All the peculiarities that are necessary for energy transport in the grid have to be considered in the communication network. Application Servers are connected to Access Points using a private IP (Internet Protocol) network, Access Points connect the IP-network to the medium voltage (MV) power-line network (redundant paths are due to power grid switching), Bridges at the medium-to-low voltage (MV/LV) transformer stations provide a transparent data link between LV and MV power lines ([2] contains a description of the design of the Access Point architecture). From there data are transmitted over the low voltage power-line network to the Nodes. Nodes are able to communicate over power-line and connect equipment such as energy meters or SCADA (Supervisory Control And Data Acquisition) equipment and thus make this equipment accessible to Application Servers over the existing power-line grid. Depending on the requirements imposed by the application, various existing, standardized protocols are supported, namely IEC [3], EN (also known as IEC 1107) [4], and EN (commonly known as M-Bus) [5]. A REMPLI Access Point enables Application Servers in the IP-network to communicate with Nodes that are connected to the REMPLI communication network [6,7]. The network is shared among different parties simultaneously (e.g. Application Servers communicate with multiple Nodes over the same Access Point), each Access Point has to multiplex data streams. While this is easy to accomplish in the IP world, it requires additional efforts in the connectionless packet-based PLC network. An Access Point also has to deal with communication and equipment redundancy; multiple independent Access Points can be attached to the same REMPLI communication network. It might happen that one Access Point is not able to reach all Nodes. Different Access Points then have to communicate to each other in order to provide maximum possible coverage of Nodes. Figure 2 Management System architecture The considered PLC is a master-slave system, where Nodes act as slaves and the Access Points are the masters. The Nodes are the interface to utility meters and SCADA equipment like switchgears. The standardized protocols mentioned above are used by both the connected equipment and the Application Servers, so neither the equipment nor the application servers need to be aware of the PLC system. 3. Management System The REMPLI Management system consists of five main blocks: Management Applications (MA), Access Points Management Drivers (APMD), Node Management Drivers (NMD), Bridge Management Drivers (BMD) and the REMPLI Components as shown in Figure 2. The term Components refers on one side to software modules such as Protocol drivers, Security Modules, PLC related components; on the other hand a Node, Access Point or Bridge as a whole has to be accessible for management, therefore these entities are also Components. The Management system communicates with Components and controls them. The Management Application on the top in Figure 2 represents the user of the management system, which observes and controls the Components at the bottom via the Management Drivers, which provide communication facilities and maintains Registries; a Registry is a database where Component Parameters and Logs of the Components are stored in a combination of volatile and non-volatile memory; there is only one registry per physical device, so it is the central instance for all configuration storage. The interface for modifying the Registry is the Management Driver. There are two types of Registries: Node/Bridge Registries, which contain only data related to the components of a particular Node or Bridge; and there is the Access Point Registry, located on Access Points, which contains the Access Point related data as well as data from Node and Bridge Registries, which are accessible from the particular Access Point. Configuration and control is based on Component Parameters; these are name/value pairs with a defined type. Every Component operates on its set of Component Parameters by adding, removing or updating via the Management Driver. A Component Parameter can either be a configuration parameter or a monitoring parameter. Logs are tables of historical data and are also stored in the registry. A Log is ordered by timestamp or sequence number and contains, for example, energy consumption values of a connected energy meter for the last week. The Management Driver performs management functionality at each physical device (Access Points, Nodes and Bridges) and provides two types of interfaces: one between a Component and the Registry and one between a Component and the Management Application.

3 For the three types of physical devices, there are three types of management drivers: Access Point Management Driver (APMD): a key component of the management system, which connects Components to the Management Application and to the Registry. It is responsible for the communication between the Management Application and the Node or Bridge Management Drivers and controls the Access Point Registry. Node Management Driver (NMD): it connects Components to the Management Application and to the Registry and controls the Node Registry; Bridge Management Driver (BMD); its functionality is identical to the functionality of the NMD, therefore both will be referred as N/BMD later in the document. The Management Application provides an interface to the operator and communicates with the Access Points in order to manipulate the Component Parameters. There can be more than one Management Application in the system with different access rights to the Component Parameters. In general, the user of the Management Application controls the system remotely, but for some special occasions the system can be accessed locally from the Access Point using the APMD. In this case the user can only manage the local Components, but no remote components. 4. Management Services The Management System performs three different functions: Configuration: this is the procedure of setting, removing or updating Component Parameters. The Management Application can depending on its access rights change all Component Parameters, whereas a Components is only allowed to change the Component Parameters that it owns, Monitoring: uses the Monitoring Parameters to frequently obtain relevant information like, for example, the current network load, the link quality or the uptime of the physical device. Logging: the Logs that are stored in the Registry can be retrieved by the Management Application Additionally, there are some general requirements to be fulfilled in order to implement the previously mentioned general functionalities: first, every Management Application has limited access rights to the components, which is defined by legal contracts between providers of infrastructure and users of the system. Therefore, the Management System has to implement Access Control mechanisms, which are described in [8]. Second, in order to provide cost-effective installation, it is necessary to provide Auto-discovery: a new Component has to be able to register itself in the system without manual interaction and be recognized by the respective instances (local Management Driver and the Management Application). Finally, in order to operate the system, the user of the Management Application needs to know the physical layout of the system of the system down to the Access Points, Nodes, Bridges and the REMPLI Components. In order to avoid the single point of failure and make the system image accessible not only from the top layer, but also locally from the middle layer the distribution of the physical layout of the system is required, located at the Access Points and represented by the local Registries Configuration Components in the system need to be configured, both during installation and during normal operation. This is done by changing Component Parameters. These parameters can be accessed by either the Component or the user of the Management Application via the Management Driver located at the particular node. Each component has to have a possibility to join the system with a certain list of parameters and be updated by the user of the Management Application or by the component itself while the system is running. All the parameters have to be locally accessible by the Components (which only has access to its own parameters) and by the Management Application. If a parameter has to have the same value at several Components, the Management system provides the possibility to update this parameter in all necessary Nodes automatically and consistently. Due to the fact that only the user has an overview of the whole system (or segment of the system), the synchronization of the parameters has to be done on the top management level, namely the Management Application. If both a Component and the Management Application update the same parameter the necessary synchronization is performed by the Management Driver, because it is the only instance that accesses the Registry. The Management Driver can serve only one request a time, meaning that the first incoming update will be served first (parameter will be updated in the Registry, then the respected instance, either a Components or/and the Management Application, will be informed about the changes) and only then the second request will be processed. If the Component is removed from the system, which can happen only by the decision of the Management Application, then all its parameters have to be removed from the local Registry. The Component itself is not (and cannot be) responsible for keeping track on this process. Therefore the Management Driver is responsible for a consistent state of existing Components and the corresponding data in the Registry. To summarize, the following requirements are fulfilled by the management system in order to implement the configuration functionality:

4 a local Registry in each Node, Access Point and Bridge for Component Parameter storage access to these Registries by the Management Application and the Components; access is controlled by the Management Driver a procedure that allows the Management Application to react on the installation/deinstallation of a Component; Components need to obey this procedure, only then the Management Driver can keep the Registry in a consistent state The installation/de-installation of a Component has to be recognized by the management system. A Component can be removed from the system with all of its parameters, which has to be triggered by the Management Application (system operator). The Management Driver offers basic functions to manipulate parameters at the Registry (adding, reading, updating and removal); The Management system provides the addressing schemes of parameters allowing to manipulate parameters of a certain set. That means not only a single parameter can be addressed but also all parameters of a certain type or location, as well as a combinations of types and locations Monitoring The general purpose of monitoring is to keep track on any changes occurring in the system, meaning that the user of the management system is automatically informed about updates of Monitoring parameter values. Basically, monitoring is the general way a component communicates with management system user and it is usually the component which initiates the communication, e.g. for identification of a status change. Nevertheless, the operator can also trigger the process in order to manage the components without waiting for a change to occur. The user of the Management Application requires a Human-Machine Interface (HMI). The user has to be able to configure, which information shall be displayed, whether only events or complete status shall be shown, especially the visualization of alarm is important. Depending on the use case either the actual data from the equipment and its status is important (e.g. energy consumption, connectivity of power supply networks, status of switchgear equipment) or the information about the communication infrastructure equipment (e.g. status of communication link, available bandwidth, Node registered/active/offline). To summarize, the following Monitoring functionalities have to be implemented by the Management System: Monitoring the updates of Monitoring parameters Components trigged by the Component itself and processed by the Management driver; Monitoring the Components availability, performed by the Management driver; 4.3. Logging Every Component creates Logs, where the actions it performs are shown and historical values can be stored. The Logs have to be stored in the Registry until requested by the Management Application. Both the Component itself and the system user can retrieve the logs from the Registry; Management Application has to be able to clean-up the log entities from the Registry. The Components and the Management Application access the Logs via the Management driver, which informs the Registry to manipulate the Logs. Management of Logs is the task of the Registry, which has not only to react on the requests from the Management driver but also maintain the memory consumed by the Logs and, depending on the configuration, clean up outdated entries. 5. Software modules In order to fulfill the requirements that have been identified until now, we have specified the following software modules Management Application The Management Application is the upper layer of the REMPLI management system and represents the operators of the system, who control the Components by manipulating parameters located at the physical devices (Access Points, Nodes and Bridges). The MA provides the HMI for communication with the user of the system. The MA has knowledge only about the Access Point Management Drivers (APMDs) it can access; via which it retrieves the information concerning Nodes, Bridges, Components and their parameters it can control. The Management Application consists of three modules: Human-Machine Interface Module: a Graphical User Interface (GUI), which visualizes the system layout for the user and shows the Access Points that are controlled by the MA. The user is allowed to control the Nodes and Bridges accessible via the Access Points. Every single Access Point, Node or Bridge shows the Components it contains (note that "Component" refers to the definition given in section 1). The MA can retrieve the Logs and parameters of the Components by request. Management Functionality Module: performs configuration, monitoring and logging related functions by issuing requests to the APMDs

5 Communication Module: it organizes the communication between the MA and Access Points over the private network 5.2. Management Driver The Management Driver is a key component of the Management system, providing the communication facilities and performing management functionalities in the distributed fashion. There are two types of Management drivers defined in REMPLI, which differ by location and performed functionality: Access Point Management Driver (APMD) and Node/Bridge Management Driver (N/BMD); Access Point Management Driver The APMD is the middle layer of the management system connecting the MA with the Nodes, Bridges and the Components. The APMD operates with the Access Point Registry; this specific Registry contains not only the local parameters, but also the parameters of the Nodes/Bridges it is able to access. The combination of Access Points Registries represents the physical layout of the whole REMPLI Management system. Therefore the system layout is distributed among the Access Points, which provides flexibility to the system and does not require a central database, which is always a single point of failure. This way of system layout representation is also required by the system users, who want to access the system locally, which implies that at every Access Point the user can access the system or at least the segment of the system locally, without connecting to the Management Application over the private network. The APMD consists of two functional and three communication modules: Configuration and Monitoring Modules: provide configuration and monitoring functionality on the Access Point side and control the Access Point Registry. The difference to the N/BMD is that APMD is responsible for synchronization between the N/BMDs Registries in the Access Point Registry MA Communication Module: a partner of the MA s Communication Module, provides communication between the APMD and the MA DeMux Communication Module: provides the connection between the APMD and the instances below DeMux; it controls communication via DeMux with the Nodes and Bridges connected to the Access Point; Component Communication Module: provides local communication between the APMD and the Components located at the Access Point; Access Point Registry: contains the Component Parameters and Log of both the locally residing Components and the Components of the Nodes that can be accessed by the Access Point Node/Bridge Management Driver The N/BMD is at the bottom of the REMPLI Management system. It communicates with the Access Points in order to maintain the image of a local Registry of the Node/Bridge at the Access Point Registry. Opposite of the APMD, the N/BMD maintain the Registry which contains only the local parameter and Logs of the location it resides. The N/BMD communicates with the MA via the APMD for configuration, monitoring and logging. N/BMD has a structure similar to the APMD, which consists of two functional modules and two communication modules, but does not require the MA communication module. Despite having the same structure of the Registry contains only local parameters and logs, which affects the behavior of the Configuration and Monitoring Modules: Configuration Module and Monitoring; provide communication between the Components and the Registry on one side and between the Registry and APMDs on the other side. Via the APMDs it communicates with the MAs The Component Communication Module is identical to the APMD Communication Module, controlling the connecting between the Components residing at the Node/Bridge and the Management Driver 5.3. REMPLI Component Components in REMPLI are logical instances, which can be related to hardware or be purely software instances performing certain functionalities. Each Component is a part of the REMPLI Management system; therefore, it provides management functionality to the Management system in order to communicate with Management Drivers and maintain the parameters. Each of the Components has a Communication Module, which is a standard for all REMPLI Components, providing communication mechanisms between the Component and the Management Driver. Additionally to the Communication Module, each Component has a Management Module, which functionality is specific for each type of the Component and depends on a system module it manages. Most of the Components are related to the REMPLI system modules, such as Protocol Driver, DeMux and Security Module. Nevertheless, there are specific Components in the Management system, which are not connected to a particular system module: Executor Component: located at each Node it starts the other Components at the node. This Component is not related to any particular module and does not represent the Node itself, but rather serves as a temporary instance only for the Node start-up. Management Driver Kernel Proxy (MDKP) Component: provides management functionality to the kernel components, such as Physical and Network layers. For the rest of the Management

6 system the behavior of the MDKP Component is the same as for the other Components. Each of the REMPLI Management Drivers communicates with the Components located at the same Node and does not communicate with the remote Components directly; instead it uses the local Management Driver. The Management Driver is the only communication partner of the Components, meaning that the Components do not access the Registry or communicate with the Management Application directly, but always via the MD. If, for example, the Component updates a parameter, the Management Application can be simply not informed about the update if the notification bit in the parameter status set to no notification. Each Component manipulates parameters stored in the local Registry (in case of Node/Bridge Components image of the Registry is stored in the respected Access Points). The set of parameters generally depends on the type of the component, although there are some parameters, which are standard for all Components. For example, Parameter 0 shows availability of the Component Registry The Registry is a database that is located on every Access Point, Node and Bridge and serves local components to store Component Parameters and Logs. Components and Management Applications can access variable size. Depending on the actual stored values the table might offer space for a variable number of parameters. The columns of the parameter table are: REMPLI Node Address: identification of the Node/Bridge or Access Point; this address is unique for the whole REMPLI system Component ID: Component identification; unique for a particular Access Point, Node or Bridge Group ID: identification of a group of parameters Parameter ID: Parameter identification; unique for a particular Component. Each component does posses a default parameter, which reflects general Component status information. It is used by the management driver to check if the Component is available; Parameter Status: parameter status information contains: modification rights that define the access rights for the Component, the parameter belongs to, and for the Management Application; a parameter type that provides information how the stored value can be interpreted (integer number, long integer, floating-point numbers, text and binary data); notification priority specifies, whether a change (initiated by the Component) of the parameter should be reported to the MA; notification range specifies the range of values within which the REMPLI Node Address RNA Component ID compntid Group ID groupid Parameter ID parid Parameter Status parstatus 1949 DeMux Group ro M-Bus driver Group 2 0 cw, maw 43 Security Module Parameter Value parval M V 110 a textual example value 0 1 C N Group C N the Registry in order to create, update or retrieve parameters. The communication between the Registry and the Components or the Management Application, respectively, are organized via the Management Driver, which reacts on requests by sending appropriate commands to the Registry to fetch or write values. To manage parameters and logs the Registry offers two table-like structures: The parameter table and log tables Parameter table Each Registry contains one parameter table. The format of the parameter table is described in Figure 3. It shows three symbolic examples for entries. The size of the total table is limited at system design phase and reflects the available memory, whereas the values are of Table 1 Registry structure change in the parameter value will be reported to the MA. This status field defines only type of range checking, but not range values. The range values are defined in the separate parameters reserved for the each parameter by the Registry during its creation. Functionality type distinguishes between Monitoring Parameters and Configuration Parameters; Memory type distinguishes between volatile (such as RAM) and non-volatile (such as flash) memory. Parameter Value: a variable size field that contains the actual value of the parameter Log tables For storing log information (e.g. historical values of data points or PLC traces) the Registry offers multiple Logs.

7 Logs are stored in a table-like structure, which consists of a sequence number which is unique for a particular log table and incremented for each entry in the log, an optional time stamp which will be set automatically when a log entry is made, and the log data; the type of the data stored in the variable sized log data field is implicitly defined by the log itself (e. g., a log of one data point only contains log data of the type of the data point) The total size of a Log is limited and defined when it is created. Hence the number of log entries is dependent on the size of the actual log data. If the log size is exceeded the log will start overwriting the eldest entries. This mechanism solves the problem of deletion in case of exceeding the log size and still retains the most actual values. The Management application can set the limits on the size of log buffer and the log data field via log table parameters of the appropriate components. For data retrieval either sequence numbers or time stamps can be used to address the log entries. By specifying special Sequence Numbers or timestamps a set of/all entries can be retrieved, e.g. "050203*" address all time values with the specified date; "0-4" addresses all sequence numbers greater than four. 6. Conclusion We have presented the management system that is employed in the REMPLI project. The requirements for a management system that is able to handle a widely distributed network of devices, which can only be managed remotely over the same communication channel that is used for all data exchange (namely, the PLC network and the IP-based backbone) have been identified and a solution together with a detailed software description has been presented. The next steps are defined by the progress in the project. More specifically, the system will be employed in two field tests, in Bulgaria and Portugal, where the functionality of the system as a whole and particularly the management system will be proven. References [1] T. Sauter, M. Lobashov, and G. Pratl, Lessons Learnt From Internet Access to Fieldbus Gateways, 28 th Annual Conference of the IEEE Industrial Electronics Society (IECON), Sevilla, Nov [2] G. Pratl, M. Lobashov, T. Sauter "Highly Modular Gateway Architecture for Fieldbus/Internet Connections"; Feldbustagung FeT 01, Nancy, France; Nov. 2001; p. 293 [3] IEC TC 57, IEC x Telecontrol equipment and systems - Part 5: Transmission protocols, IEC, Geneva, [4] IEC TC 13, EN Electricity metering Data exchange for meter reading, tariff and load control, CENELEC, Brussels, [5] CEN TC 176, Communication systems for meters and remote reading of meters - Part 3: Dedicated application layer (M-Bus), CEN, Brussels, 2002 [6] G. Pratl, M. Lobashov "Remote Access to Power-Line Networked Nodes: Digging the Tunnel"; IEEE International Workshop on Factory Communication Systems (WFCS2004), Vienna, 2004 p [7] G. Bumiller, T. Sauter, G. Pratl, A. Treytl "Secure and Reliable Wide-Area Power-Line Communication for Soft-Real-Time Applications within REMPLI"; 9th International Symposium on Power-Line Communications and Its Applications (ISPLC 2005), Vancouver; Apr [8] A. Treytl, T. Sauter Security Concept for a Wide-Area Low-Bandwidth Power-Line Communication System ; 9th International Symposium on Power-Line Communications and Its Applications (ISPLC 2005), Vancouver; Apr. 2005

8