We compared our architectural approach to other approaches in Section 2.1 (Chapter 2).
In this section, we compare our prototype to different existing widely deployed (i.e., non-research) systems for home energy applications. Table3.2 compares the different systems based on our design goals (Section1.2).
Commercial software solutions such as Google Powermeter [15] and Microsoft Hohm [24], being centralized web services are scalable but provide a fixed set of analytics with no data consolidation and little data privacy. Both services are now defunct, thus leaving users de-prived of their energy data. Energy companies’ web portals act similarly and share/discard the smart meter data at their discretion but ensure integrity of that data. The GreenBut-ton [17] initiative has standardized energy data formats, so that users can access their data and analyze it themselves (denoted “GreenButton (Self)”) by using desktop tools such as Energy Lens [7]. This allows users to choose analytics tools, ensure data integrity, and provides data privacy, but it burdens them with data hosting. Alternatively, users can delegate the data retrieval and maintenance to third parties (denoted “GreenButton (Third Party)”). Third parties can manage, analyze and host users’ energy data, but such unconditional access to raw data provides little data privacy.
Our prototype implementation of the proposed architecture meets the design goals for a user-centric, privacy preserving system for energy data analysis as explained below.
Hohm [24], Energy companies GreenButton [17] (self) GreenButton [17] VHome Powermeter [15] web portals [32,36] Energy Lens [7] (third party) prototype
Data Consolidation ✓ ✓ ✓
Data Durability *
Data Integrity * ✓ *
Data Privacy ✓ ✓
Application Extensibility ✓ ✓ ✓
Application Performance ✓ ✓ ✓ ✓
Scalability ✓ ✓ ✓ ✓
Table 3.2: Comparison of existing solutions for home energy data applications, * denotes a partial solution.
• Data Consolidation: VHome native applications, such as the data scraper appli-cation (Section 3.3.3), can read data from any data source and store it in the VHome database. This allows users to easily consolidate data from multiple sources by using one native application per data source. User-owned sensors can be directly interfaced with the gateway, in a fashion similar to that described in Section 3.3.1.
• Data Durability: Instead of relying on a single computer in the user’s home to store data, and relying on the user to back up that data, for example, by making off-site backups, data is stored in the VHome datastore. The VHome prototype is hosted on a user-owned virtual machine (VM), and uses its local disk to warehouse the data.
However, different cloud providers provide varied guarantees on the durability of data stored on VMs’ local disks [4,37]. For instance, VMs on Amazon Elastic Compute Cloud (EC2) may lose local disk data in case of hard drive failures. Therefore, our current prototype provides only a partial solution to data durability. In Chapter 4, we address this problem by leveraging commodity cloud storage services for storing sensor data, since they provide stronger data durability guarantees with lower storage cost than VM local disks.
• Data Integrity: Native applications can implement mechanisms to ensure the in-tegrity of data stored directly into the VHome datastore, such as sensor data up-loaded from the gateway. Example mechanisms include storing signed hashes of data
streams. However, our current prototype does not include such native applications.
We address this problem in detail in Chapter 4.
Moreover, in cases of data procured from external sources, such as smart meter data from energy companies’ servers, applications have to rely on the respective sources such as energy companies, for preserving integrity of the data. Similarly, our prototype assumes that the VEE and VHome-software providers do not tamper with data in the VHome datastore.
• Data Privacy: The current prototype uses several mechanisms to ensure data pri-vacy. First, data within a VHome instance is not accessible by entities outside the VHome, eliminating many types of privacy violations. Privacy leakage from native applications is prevented by certifying native applications, by checking Java byte code submitted to the application store to ensure that they are either not using network APIs, or when they need to, are only communicating with the specified hosts. The details of this process are described in Section 3.2.3. Privacy leakage from cloud-based applications is mitigated, to some extent, by aggregation or obfuscation and other privacy preserving mechanisms (PPMs). Note that, these protections of data privacy assume that the VEE and VHome-software providers are trusted.
• Application Extensibility: Users can freely choose to extend their set of VHome native applications by installing them from the application store. Users can also chose to transfer their data to other cloud-based applications for analytics and other services.
• Application Performance: Personal VEEs in the cloud provide VHome appli-cations with more computational resources such as memory, CPU time, than are available on a typical user’s home machine. Moreover, hosting data and applications in the cloud minimizes remote access latencies as compared to typical home access links which have lower bandwidths.
• Scalability: In contrast with home-based computers, cloud-based personal VEEs allow for easy scaling of both data set sizes and computation, by suitable provisioning and re-sizing of the VEEs.
Thus, our prototype addresses all of our design goals, and demonstrates the feasibility of our proposed personal VEE architecture using existing hardware, software, and cloud infrastructure.