TECHNOLOGY IN SYSTEMS
Technologies for Energy Intelligence
The Smart Grid Built on Smart Objects Will Challenge Developers
The notion of a “Smart Grid” to imbue generation, transmission and consumption with intelligence presents daunting challenges of grand scope. The Smart Grid will consist of many elements and they all need to be smart and connected. Java, Linux and Android will contribute greatly to the effort.
BILL WEINBERG, LINUX PUNDIT AND THE OLLIANCE GROUP
Page 1 of 1
For the last 50 years, developed countries have enjoyed “all you can eat” electrical energy. But no more. Today, multiple factors are leading to climbing energy costs, power quality degradation, brownouts and blackouts. Unpredictable energy supply and demand complicates the lives of individuals and operations of businesses, from manufacturing to services industries.
To address this next energy crisis, governments, power companies and entrepreneurs must address myriad factors. Among these are the declining fossil fuel supplies, increasing pollution and looming climate change from use of still plentiful non-renewable energy sources, especially coal, combined with the current system of geriatric energy distribution networks—the “dumb” grid.
In the face of this is the increasing demand for energy from regional growth and from anticipated demand for electric vehicle charging. There are regulatory and cost barriers to increasing generating capacity, especially for nuclear power along with “not in my back yard” (NIMBY) objections to construction of new nuclear, solar and wind projects. At present there is only limited, emerging ability to monitor and respond to changing energy demand in real time, and always in the background are security threats to the distribution grid and to consumer privacy. Many of these issues come to a head at the “last mile”—the last 10 yards, actually—of the emerging Smart Grid.
Embedded system developers need to start integrating energy efficiency and management into the hardware and software of their designs—home appliances, entertainment systems, office equipment and environmental controls. Energy monitoring and control are embodied in systems and software that measure actual energy usage by communicating with the universe of devices in the home and workplace.
To enable efficient operation, communication, monitoring and control, developers need to rethink embedded systems beyond their stand-alone roles. Rethinking entails designing and building application platforms, systems and software that respond to changing local conditions and can be upgraded to respond to changing energy economics.
The last mile (or last ten yards) of the Smart Grid includes nodes that use electricity, monitor consumption, and reside in or near homes, offices and other premises. Among these are data aggregation devices—smart meter readers/concentrators/routers and microgrid controllers, most often located atop power poles as well as smart meters installed on premises. It also involves premises-based Home Energy Gateways (HEGs) and In-Home Displays (IHDs) as well as passive (monitored) and smart (remote policy-driven) appliances and other energy-aware equipment.
Energy goes in and data comes out (and sometimes in, too), ideally in a loop to support Demand Response. Demand Response is the ability of the Smart Grid to react to widespread high demand by automatically adjusting premises devices such as thermostats across many locations by small amounts to keep overall consumption under control (Figure 1).
The Smart Grid, end-to-end involves intelligent devices and different levels of networking throughout.
Device types sort themselves out into four basic categories: device concentrators, smart meters, IHD/HEGs and smart appliances. Data concentrators are headless (pole-top) systems and primarily act as routers and access points that let smart meters “phone home” periodically with usage data, and support commands for provisioning and service disconnect. Building these systems on embedded Java, Linux or Android, augmented with storage/db capabilities, gives them options for local caching and analysis of client smart meter data, especially for maintenance and troubleshooting purposes.
A scalable platform is required to extend the lifetime of these systems, allowing for provisioning and management of a large number of smart meter client devices that can grow over time. These systems need to communicate with smart meters over a number of channels, and due to their strategic role in provisioning and relaying customer energy usage data, also benefit from robust security. Utilities and premises owners also deploy these types of systems as controllers for autonomous microgrids that generate local power and act as backups against grid-wide outages.
Smart meters today represent a large and growing revenue opportunity for energy sector OEMs. Currently, smart meter rollout parameters constrain the functionality of these devices to monitoring and reporting energy usage. In the future, they present interesting opportunities for accelerating demand response and participating in home area network (HAN) monitoring and control activities (across the premises demarcation). As such, they need protocols and intelligence for upstream and downstream communications—to poll-top systems, to HEG/IHDs, and to selected high-load HAN nodes, especially HVAC, pool pumps and hybrid/electric car chargers. The evolving role of the smart meter also benefits from Java’s programmable platform functionality: smart meters that are relatively “dumb” at rollout can easily be re-provisioned for more comprehensive capabilities as legal and regulatory environments change.
In-home displays and home energy gateways hold the greatest opportunities for Java deployment in the Smart Grid. The IHD/HEG needs to manage and control a multi-faceted and always changing environment. Today, penetration of energy-aware appliances is quite low. In the next several years, mandates for energy-efficient white goods in the U.S. and abroad will boost the presence of smart appliances in the market and on premises. Over the next decade, homeowners will upgrade aging appliances and add new ones to their homes.
The broader vision of IHD and HEG-type devices places them at the center of the energy-efficient home. Java is the most appropriate platform to support this central, user-interactive role. It is also an excellent application platform to accommodate appliance-specific applications and widgets and third-party apps that extend the pre-load functionality of IHD and HEG hardware with aftermarket post-load plug-ins.
IHD/HEG systems will leverage the most functionality from the underlying software stacks and will need to support multiple communications and HAN protocols. They will offer users interfaces locally and via the Cloud, support downloaded and over-the-air software upgrades, and will do so with topnotch data and operational security.
Many appliances and devices in the prototypical HAN exhibit constrained functionality and BOM/market price points—light switches, power strips, electric heaters, smoke detectors and myriad other devices with simple operational states, limited or no user interface, and liberal or non-existent latency/response requirements. These devices are probably best served by microcontrollers with no real software platforms or low-cost multifunctional units running minimalist RTOS, µCLinux or Java Card.
Examples include Internet-connected HVAC systems and other environmental controls as well as smart refrigerator/freezer units, with capabilities to track contents/expiration and deliver information such as recipes and nutritional data through embedded displays. These will also include high-wattage Internet-connected audio-visual equipment such as flat screen TVs, DVRs, STBs, etc., which are already fairly smart. Higher-end “white goods” and other household systems greatly benefit from inclusion of greater intelligence conferred by full-blown embedded Linux, Java or Android.
The home area network that will tie together these premises devices and link them to the external network is actually the sum of several networks, encompassing existing LANs (Ethernet and Wi-Fi) and networks specifically designed for premises automation and monitoring:
• WiFi—standard 802.11b/g/n wireless networking, connecting the HEG with local computers and tablets, and sometimes acting as a data backhaul
• Ethernet—standard wire line connection to LAN and Internet backhaul
• Bluetooth—peripherals and mobile devices, both as interfaces to HEG and for energy management and control
• Zigbee—IEEE 802.15.4-2003 wireless mesh for industrial and home networking with profiles for energy monitoring and control
• Z-Wave—a proprietary wireless networking protocol for home automation
• HomePlug—a power-line communications (PLC) protocol for home/SOHO
• X10—legacy power line and wireless home automation network
The Software Stack
The premises devices described above require a relatively generic software stack, with multiple options for OS, middleware and display paradigm (Figure 2). Smart energy is a domain closely associated with Java—a large swath of projects, commercial software and hardware and applicable standards are implemented in or for Java, with Oracle investing strongly in all parts of the emerging Smart Grid.
Key elements of a Smart Energy software stack.
Using embedded Java enables rich base functionality and modest impact on bill of materials. At a minimum, smart appliances need Java ME, HAN protocol stacks, and application-specific device drivers to run relays, sense temperature, etc. Internet-enabled appliances would also require TCP/IP, and higher-end devices code to support a device user interface.
Using embedded Linux and Java together constitutes an optimal Smart Grid combination. The broad horizontal support for devices, protocols, middleware and other development languages gives developers the widest possible design palette.
In addition, Android for Smart Grid devices offers most or all of the virtues of Java—well-understood programming model, rich toolbox of existing Smart Grid resources, and synergy with Java applications in the “back office” (billing, monitoring, etc.). Android has the additional benefit of presenting developers and users with an application platform and a vibrant application marketplace. HAN devices built on Android could offer users numerous options for add-on software and stimulate a Smart Grid software aftermarket.
While there are devices that benefit from smaller footprint and deterministic responsiveness, and many target appliances and other devices already deploy on RTOSs, few Smart Grid projects moving forward are selecting RTOS platforms. Even when combined with Java, RTOSs lack the broad device, protocol and middleware support offered by Linux (underlying Android or Java). It is certainly possible to build HEGs and other systems on an RTOS, but in a market where time-to-market and field upgradability are key requirements, RTOSs are often too minimalist to make the cut.
Microsoft, like Oracle with Java, offers a gamut of resources for Smart Grid. Building a premises device with an embedded version of Windows offers synergy with the dominant enterprise application platform and avails developers of the rich toolkits offered to support Microsoft platforms. However, most existing Smart Grid project code and products are not optimized to run on versions of Windows, necessitating additional porting and integration work.
Building on modern, standards-based system platforms confers multiple options for a user interface paradigm on Smart Grid devices. An “In-Home Display” (IHD), by definition, includes a display, from small, simple numerical LCDs output to full-featured color LCD and touchscreen input/output. With Java, Swing and the Light Weight UI Toolkit (LWUIT) simplify prototyping and building user-friendly interfaces for Java applications. With Linux, developers have myriad UI framework options, from familiar GTK+ and Qt to e17 to FancyPants and other proprietary graphics and multimedia frameworks. Android also offers its own rich native UI framework, the tablet version of which appears to be well suited to premises form factors. And Microsoft and top-tier RTOS vendors have invested in supporting platform-native and third-party graphics toolkits.
To reduce BOM cost for HEG devices, and to provide UIs for other Smart Grid nodes (appliances, smart meters, pole-top systems, etc.), a headless smart energy device can easily present a web-based user interface for display on PCs, notebooks, tablets and other client devices over a network. Java and Linux both provide a rich set of resources for building embedded web servers (e.g., com.sun.net.httpserver), and Java can also form the basis of the client-side UI with Applets.
Increasingly ubiquitous smartphones and the need to control Smart Grid devices remotely predicate building mobile applications for secondary (or primary) smart energy control and monitoring. A mobile app can just encapsulate a browser UI in an application wrapper or can have a “life of its own,” with capabilities unique to mobile host platforms (input methods, location info, etc.). Note that unless an app is designed strictly for LAN-based monitoring and control (usually via Wi-Fi), the mobile app architecture will likely include access to the smart energy device through some kind of gateway, especially to avoid installation and configuration issues.
Devices deployed across the Smart Grid must be manageable without hands-on intervention. Many nodes are physically remote, inside power plants, on pylons, or embedded inside of other systems, appliances and construction. Also, many or most Smart Energy device types are headless, without displays or user input.
Smart energy requires smarter devices—intelligent control systems easily provisioned, maintained and upgraded with both inherent functionality and aftermarket applications. There is no one right path (let alone an entirely straight one) to building Smart Grid premises devices, but there is no dearth of options and available resources, either.
The Olliance Group