Towards an app platform for data concentrators Rune Hylsberg Jacobsen, Nikolaj Tørring, and Brian Vestergaard Danielsen Department of Engineering, Aarhus University Finlandsgade 22, 8200 Aarhus N, Denmark Email:
[email protected]
Abstract—Data concentrators in advanced metering infrastructures (AMI) are central for collecting electricity meter data. Due to their position at the transformer substation in the distribution grid, concentrators offer an opportunity for value added services to be introduced by the distribution system operator. However, these services must be deployed without jeopardizing robustness and security of the electricity distribution operation. This paper reports on a design and validation of an application platform for service deployment to run on concentrators. The platform is based on a secure and reliable software framework inspired from Android. Index Terms—advanced metering infrastructure (AMI); Android; data concentrator; smart grid;
I. I NTRODUCTION In advanced metering infrastructures (AMI) data concentrators are used to collect electricity usage data from residential electricity meters and to forward data to the head-end system of the distribution system operator (DSO). Concentrators are placed at the medium/low voltage transformer substation which provide electricity through a feeder infrastructure to individual households. Data is typically collected every six hours or so. The collected data is used for billing and for providing power quality measurements of the grid. These AMI systems are often based on wireless [1] or power line communication technology [2] for twoway communications and facilitate the DSO to react to pricing policies, so that the household appliances and other distributed energy resources automatically turns on/off in response to a signal from the grid. Concentrators are equipped with microprocessors and form embedded devices powerful enough to run an operating system (OS) that host applications — or simply: “apps”. Apps can be deployed in a controlled way and may open up for third party services to be deployed in the grid. This gives new business oppotunities for the DSO that may offer Application Programming Interfaces (APIs) to third party service providers interested in deploying commercial smart grid services such as e.g., demand response aggregation in the low voltage grid [3]. The work presented here proposes and demonstrates an app platform for service deployment designed to run on concentrators in an AMI. The platform is based on a compiled component-based software framework that improve electricity meter monitoring as well as provide a platform for value added service deployment. The framework is
978-1-4799-3653-3/14/$31.00 ©2014 IEEE
Morten Tranberg Hansen and Erik Bøjer Pedersen Kamstrup A/S Industrivej 28, Stilling 8660 Skanderborg, Denmark
based on the Android security and application model [4]. It utilizes stateless interactions between clients and servers based on representational state transfer (REST) principles [5]. This framework architecture is chosen because it is well-proven from being used in ecosystems for modern mobile OS’ such as Android. II. BACKGROUND A software framework architecture should be based on the principle of low coupling and high cohesion between components [6]. These principles ensure, that components can be developed and used independently. Components connect to a framework backbone that serves as a manager for all components. The backbones handles data exchange and synchronization. Developers using the framework can add components to the backbone to fulfil additional requirements, but cannot change the framework as such. Software frameworks are built in various ways to provide the needed level of flexibility. Common framework implementation classes include: monolithic systems, modular systems, and application libraries [6]. As application libraries grow over time, they can be separated into reusable domain-specific fixed parts that make up the backbone of the framework. The variable part contains the other classes that can be upgraded to components, as they mature over time and thus constituting the compiled component-based framework. New or changed components can be implemented but recompilation is required. Finally, the dynamic component-based framework class extends the compiled component-based frameworks by allowing dynamic loading of components during run-time. A good framework design provides simplicity, clarity and expandability. The overall structure of the framework must be easy to comprehend by developers to ease the progression from basics to more advanced features. This can be achieved by the support of simple APIs. Important, nonfunctional requirements like security and robustness must be seamlessly supported by the framework architecture in order not to jeopardize the operation of the distribution grid. Li et al. [7] propose a technical framework for a smart distribution network. The researchers divide the distribution network into three layers: a physical entity layer, a data layer, and an application layer encapsulating the network
infrastructure, the information and communication system, and an intelligent application system, respectively. Security is a general concern for the smart grid [8], [9]. The introduction of wireless and open network standards in AMI exposes vulnerabilities of the system. This may compromise the system availability, open doors to intrusion, and jeopardize the privacy of the electricity consumers. By extending openness to the substation concentrator point the need for security measures such as e.g., protection from viruses, is stressed even further. Wei et al. [10] propose a security framework to protect the smart grid from cyber attacks. Cyber attacks were classifies according to three categories: Component-wise, protocol-wise, and topology-wise attacks. Design principles, implementations, and tests of the security framework were provided by the authors [10]. Sun et al. [11] discuss security mechanisms of the Android OS as well as some of the inherited security features of Java. Bl¨asing et al. [12] propose an Android application sandbox that statically checks for suspicious content before installation and that dynamically monitors malicious behavior in a running application. This feature is highly desired when considering the critical nature of the app platform in the electricity distribution grid. Furthermore, the Java security model is also generally applicable to the platform proposed here [13]. The work presented here uses several elements from [11], [12], [13]. III. S YSTEM D ESIGN The app platform builds on a compiled component-based software framework. The framework acts as an abstraction of the underlying layers of the system that handles the interaction with external devices. A. Architecture model A framework backbone interconnects the various components. It is divided into two parts: one part that acts as a control center for apps, managing communication and execution behavior in a Java environment and another part for handling communication with devices in the AMI. The first part is running on a Java virtual machine (JVM). It includes the app and system class libraries for developing apps for the platform. The second part is running directly on Linux. The two parts communicate by using RESTful web services. The high-level architecture of the platform is shown in Fig. 1. The framework acts as an abstraction layer to the underlying layers that handle interactions with electricity meters and neighbor concentrators. The framework makes use of a separation of concerns and stateless interactions between framework clients and framework servers based on REST principles [5]. The framework consists of a collection of methods and data objects for retrieving data from the server. Developers of apps are provided with APIs that expose the useful software packages and classes of the framework.
Data concentrator Application (App) Framework Client
6 ?
Data con- * * centrator
Framework Server
REST API 1 * Electricity meter
Linux
Fig. 1. Platform architectural concept model. The symbol ’*’ indicates the multiplicity: many. Applications (Apps) Software framework ServiceManager
AppManager
Libraries Java Native Invocations
C++ standard library
I/O
Protocol
PolicyManager Runtime env. Java class libraries Java virtual machine
Linux kernel HW drivers
Fig. 2.
Users
I/O
Software platform stack.
The server uses the Restlet (www.restlet.org) implementation which allows Java applications to use the HTTP request/response protocol. Restlet is a light-weight RESTful web framework developed for Java with configurations targeting different platforms such as Dalvik virtual machine or Java Standard/Enterprise Edition (SE/EE). The exposed services are queried from the client-side by accessing the corresponding Uniform Resource Identifiers (URI). This is implemented with a configurable Router object, that specifies the different paths to different services. This part of the software platform is decoupled from the rest of the platform and can be implemented using any other programming language to improve performance. B. Software platform stack The software platform stack in shown in Fig. 2. The apps reside at the top of the stack and they are executed on a JVM designed for embedded systems. The main components in the software framework are: AppManager, ServiceManager, and the PolicyManager. The AppManager is responsible for maintaining the app state and to act as a gateway for the underlying framework. The AppManager handles any messages from the app. Depending on the message type, these are forwarded to the PolicyManager, the ServiceManager, or simply processed by the AppManager itself. The PolicyManager implements the policy control mechanism described below. The ServiceManager is responsible for service control in the framework. The software libraries of the framework execute in Linux OS and implement the communication interfaces between
the app and the electricity meters. Data collected from the meters are cached locally on the concentrator as part of the grid operation. Apps can subscribe to this data via the services exposed by the server. Java Native Invocations (JNI) is used to merge with C/C++ libraries of the app platform. JNI enables Java applications to execute native code and for native code to invoke Java methods from code compiled for a specific hardware and OS platform [14]. Finally, the Linux kernel runs at the bottom of the software stack. C. Security control model The platform inherits several security features from Linux. First, a user-based permission model, in which each app runs as its own unique user, prevents interference from apps run by other users [15]. Linux users are created/deleted by the platform when new apps are installed/uninstalled. Application isolation at OS level secures the system by prohibiting running apps to exchange data directly. Rather, apps should get (or put/post) their data via the framework. Second, software-based process isolation ensures that one process do not access the memory space of another process [16]. Third, the multi-user OS design helps isolating user resources thereby controlling the processing, memory, and device usage of an app run by a specific user. This mechanism prevents apps from hogging resources. In addition, the framework handles app permissions to ensure that apps do not perform unauthorized actions. Each app is executed in a JVM owned by a unique Linux user and configuration changes can only be made by the specific user and the root user. Hence, if there is a bug in the app implementation that imposes a breach of security, it will only affect the specific user profile that runs the app. The approach to application isolation is to maintain a separate copy of all static fields in each software class. The advantages of this approach is that it ensures a completely isolated environment for each app. The drawback is that more than one copy of the code will be loaded into system memory resulting in a large memory footprint. The framework implements a simple policy management system inspired from the Android security model [4]. Our approach is somewhat similar to that of Sun et al.[11]. The basic idea is to enforce policy control before a permission check. This is accomplished by intercepting all permission requests. If a malicious user would gain access to the concentrator and exploit vulnerabilities of the app, the user could only harm the resources and the data accessible to the particular app. Fig. 3 shows how the policy control model is designed. The biggest difference between the implemented model and the Android model is that the framework prohibits external apps to change the application context, i.e., the state of app specific resources. When an app sends a request that requires a permission check, the request is intercepted by the PermissionChecker. The PermissionChecker interacts with the PolicyManager which exclusively has access to the PolicyRepository. The Poli-
Apps
6 ? PermissionChecker
ContextInteractor
-
6 ? PolicyManager
6 ? PolicyRepository Fig. 3.
Framework policy control architecture.
cyRepository functions as an archive for storing contexts and their individual policies. Moreover, it is possible for users to create, modify, activate and deactivate a context via a user interface. In this case, the ContextInteractor queries the PolicyManager on behalf of a user action to determine if policies allow the user to execute the request. The policy control architecture also handles activation and deactivation of contexts and third party components. When the context changes, it is reported to the PolicyManager by the ContextInteractor. If a context switch is caused by the activation/deactivation of a context, the PolicyManager will notify the ContextInteractor about the change. This sandbox model ensures that apps cannot access unauthorized resources. D. Application model At the core of framework backbone is the Context object. The Context object implements the context an app is currently executing. Each app runs in an isolated environment where a manifest file (XML) declares components and system resources available to the app. Context properties are derived from this file. The Context object has methods for binding and unbinding components. It is only components, which are bound with the active Context object, that can be accessed when the app is running. The manifest serves as a configuration file. The App object provides the scaffold for building apps for the platform. Adding various components and services, enable the user app to perform certain tasks, such as getting data from electricity meters and sending data to the headend system of the DSO. The Component objects are the basic building blocks of the framework. They are used to represent the various entities of the app. The framework implements two standard Component objects: Service objects and Device objects. Service objects are used to represent services provided by the framework server. Device objects are used to represent physical devices in the AMI. All devices used by apps must provide the software framework with an identification number to be addressable on the network. A device type should also be provided so the framework can intercept messages that try to perform unauthorized operations for a given device type. Message objects are used for interaction between Component objects. When creating Message objects, the app
TABLE I E XECUTABLE JAR FILE SIZES OF TESTBED COMPONENTS . Component Java SE embedded 7 Restlet framework Gson framework Framework library Framework server Client app
Fig. 4.
Picture of the experimental setup.
context must be passed as a parameter, so the AppManager gets information about the context in which the action should be performed. Finally, the Router object is implemented to deliver messages between services. IV. I MPLEMENTATION A prototype testbed is implemented to demonstrate an app platform for concentrators. The testbed mimics a feeder in the distribution grid. The software is comprised of a server and a framework library. A client implementation is delivered with the framework to serve as a template for test apps. Currently, the implemented service classes are: a MeterService and a ListMeterService. The MeterService is able to fetch the current and voltage measurements on the three phases of electricity meters installed in the feeder. The ListMeterService gets an inventory of electricity meters associated with the concentrator. The testbed is composed of two Kamstrup electricity meters (Model 382LX3) connected to a power source. A set of power plugs are connected to the three phases of the electricity meters as shown in Fig. 4. By doing so, the meters will share the phases similar to a feeder connecting two households. The concentrator is simulated on an ARMv6 microprocessor on a Raspberry Pi embedded hardware module. The concentrator is running Arch Linux distribution version 3.1.91 with Java Standard Edition (SE) embedded version 7 update 6. Electricity meters and the concentrator are connected via 10/100 Mb/s Ethernet to a LAN. The Ethernet interface on both electricity meters and the concentrator are connected via a router (D-Link DIR655) which further connects to the internet through the WAN port. Services are implemented as Restlet objects. Data is exchanged as JavaScript Object Notation (JSON) formatted messages. As Java does not have native JSON support, the Gson implementation, maintained by Google, is used by the server and the framework library for parsing/unparsing of JSON objects. The server is implemented as a background service in Linux. It runs a thread that continuously polls and caches
Size 32 MB 730 KB 190 KB 7 KB 870 KB 187 KB
data from the electricity meters at regular intervals (approx. every 5 seconds) by using the Kamstrup Meter Protocol (proprietary). The roundtrip time (server-meter-server) was measured to be 446 ms. Only the most recent meter readings are cached to limit static memory usage. The client requests data from the server by using standard Java function calls to the framework library. The framework library then forwards the call to the server using the HTTP GET method. When the server receives a request it returns a JSON object with the latest meter data. The framework parses the JSON object to a Java object and returns it to the client app. V. T EST AND EVALUATION A test app is implemented to validate the soundness of the framework. The test app monitors the load on the three phases to provide information on the instantaneous load balance in the feeder. The testbed is connected to the internet and appliances are connected to the different phases via separate power sockets to mimic two households. When the test app is started it requests a list of all meters by invoking the ListMeterService of the framework. It then starts a thread requesting data for each meter by using the MeterService. Data is posted to an external database for diagnostics and analysis. A total of 229 data points were collected for each phase and each meter over a time period of 76 minutes. Fig. 5 shows the measured voltage and current on the three phases: L1, L2, and L3 for Meter 2. Similar measurements were taken for Meter 1 (not shown). The measurements were performed in a student’s bar at the university campus. It can be observed that the voltage drops when the current consumption increases on the phases. The most notable variation is seen for L1. The variation is caused by the use of an electric kettle that boils one litre of water. The periodic variation on L2 is caused by a cooling compressor running in the bar. Only little current is drawn from L3 which connects to a laptop with a 55 W power supply unit. The memory requirements and usage for the app platform and the test app were examined. Executable components were built as Java ARchive (JAR) files. The total memory needed for the testbed components adds up to 1057 KB (Table I) excluding the storage needed for Java. The memory usage of the client app (17 MB) and the server (28 MB), respectively, is high compared to the individual apps package sizes. This is typical of Java applications as the JVM and external libraries need to be loaded in the
236
×
228
224 +
××
×
×
8
Current [A]
Voltage [V]
+ + ++++ ++ + ++ 232 + + ++ + + +
16 Meter 2, L1 Voltage [V] + Current [A] × + +++++ +++++ + 12 ++ ++ ++++ +++
4
++
+
+
220 ×××××××××××××××× ×× ×××××××××××××× ××××× ×××× 0 0 1000 2000 3000 4000 5000 6000 Time [seconds] 236
232 ++ +
++ +
228
224 ×××
+ + +
+ ++ +
++++
+ +++
++
+++ ++
××××
××××
××××
×××××
×××
×××
××
+ ++++ ++++ ××××× ××××
××
××
1000
2000
3000 4000 Time [seconds]
8 ++ ××
4
×××
220 0
12 Current [A]
Voltage [V]
R EFERENCES
16 Meter 2, L2 Voltage [V] + Current [A] × + + ++ + + +
5000
0 6000
225
220
Current [A]
Voltage [V]
240
4 Meter 2, L3 Voltage [V] + Current [A] × ++ + 235 3 ++ + + +++ ++ + ++ +++++ ++ ++ + + +++ ++ +++ +++ + ++ ++ + ++ + 230 2
1 ×××××××××××××××××××××××××××××××××××××××××××××× 0
1000
2000
3000 4000 Time [seconds]
5000
of using Java with application isolation in the system architecture. To provide resiliency in practice, electricity meters registers with multiple concentrators. During operation, the electricity meter will send data to the primary concentrator. If this concentrator becomes unreachable, the meter will fall-over to another concentrator. The framework should transparently allow for this switch by providing a proper level of abstraction for client apps. Such implementation of resiliency for apps is planned future work.
0 6000
Fig. 5. Voltage and current measurements on individual phases (L1, L2, L3) on a residential meter. Every 5th data point is displayed on the graphs.
memory. VI. C ONCLUSIONS AND FUTURE WORK The app platform presented in this paper is inspired by mobile app platforms such as Android. The platform is based on a software framework that has been designed as a compiled component-based framework. The framework is extendable and customizable and it implements a security model that provides application isolation and policy control for protection and to make the platform more robust. A testbed, that mimics a feeder with two households connected, was built. The testbed was used for the evaluation of the platform. A simple test app, that measures the electricity load on three phases on the feeder in the distribution grid, was developed to demonstrate that it is feasible to run Java on a concentrator in a robust and secure manner. However, it also shows the trade-off between memory footprint and security in the overall design due to the fundamental choice
[1] V. Aravinthan, V. Namboodiri, S. Sunku, and W. Jewell, “Wireless ami application and security for controlled home area networks,” in IEEE Power and Energy Society General Meeting, 2011, pp. 1–8. [2] S. S. S. R. Depuru, L. Wang, V. Devabhaktuni, and N. Gudi, “Smart meters for power grid — challenges, issues, advantages and status,” in 2011 IEEE/PES Power Systems Conference and Exposition (PSCE), 2011, pp. 1–7. [3] J. Medina, N. Muller, and I. Roytelman, “Demand response and distribution grid operations: Opportunities and challenges,” IEEE Transactions on Smart Grid, vol. 1, no. 2, pp. 193–198, 2010. [4] W. Enck, M. Ongtang, and P. McDaniel, “Understanding android security,” IEEE Security & Privacy, vol. 7, no. 1, pp. 50–57, 2009. [5] R. T. Fielding and R. N. Taylor, “Principled design of the modern web architecture,” in Proceedings of the 22nd international conference on Software engineering, ser. ICSE ’00. New York, NY, USA: ACM, 2000, pp. 407–416. [6] D. Parsons, A. Rashid, A. Speck, and A. Telea, “A “framework” for object oriented frameworks design,” in Proceedings of the Technology of Object-Oriented Languages and Systems. Washington, DC, USA: IEEE Computer Society, 1999, pp. 141–151. [7] V. C. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, and G. P. Hancke, “Smart grid technologies: Communication technologies and standards,” IEEE Transactions on Industrial Informatics, vol. 7, no. 4, pp. 529–539, 2011. [8] F. M. Cleveland, “Cyber security issues for advanced metering infrastructure (ami),” in IEEE Power and Energy Society General Meeting - Conversion and Delivery of Electrical Energy in the 21st Century, 2008, pp. 1–5. [9] H. Khurana, M. Hadley, N. Lu, and D. A. Frincke, “Smart-grid security issues,” IEEE Security & Privacy, vol. 8, no. 1, pp. 81– 85, 2010. [10] D. Wei, Y. Lu, M. Jafari, P. Skare, and K. Rohde, “An integrated security system of protecting smart grid against cyber attacks,” in Innovative Smart Grid Technologies (ISGT), 2010, pp. 1–7. [11] L. Sun, S. Huang, Y. Wang, and M. Huo, “Application policy security mechanisms of android system,” in IEEE 14th International Conference on High Performance Computing and Communication & IEEE 9th International Conference on Embedded Software and Systems (HPCC-ICESS), 2012, pp. 1722–1725. [12] T. Bl¨asing, L. Batyuk, A. D. Schmidt, S. A. Camtepe, and S. Albayrak, “An android application sandbox system for suspicious software detection,” in 5th International Conference on Malicious and Unwanted Software (MALWARE), 2010, pp. 55–62. [13] L. Gong, “Java security: present and near future,” Micro, IEEE, vol. 17, no. 3, pp. 14–19, 1997. [14] S. Lee and J. W. Jeon, “Evaluating performance of android platform using native c for embedded systems,” in 2010 International Conference onControl Automation and Systems (ICCAS), 2010, pp. 1160–1163. [15] D. Barrera, H. G. Kayacik, P. C. van Oorschot, and A. Somayaji, “A methodology for empirical analysis of permission-based security models and its application to android,” in Proceedings of the 17th ACM conference on Computer and Communications Security, ser. CCS ’10. New York, NY, USA: ACM, 2010, pp. 73–84. [16] M. Aiken, M. F¨ahndrich, C. Hawblitzel, G. Hunt, and J. Larus, “Deconstructing process isolation,” in Proceedings of the 2006 workshop on Memory System Performance and Correctness, ser. MSPC ’06. New York, NY, USA: ACM, 2006, pp. 1–10.
