Embedded Technologies for the Smart Grid
Key Considerations for Designing Low Cost, Energy Efficient Smart Grid Devices
SRINATH BALARAMAN, MENTOR GRAPHICS
Page 1 of 1
Our society’s ever-demanding energy needs have not only led to an increased investment in alternative renewable sources, but have also forced us to look at ways to effectively manage our current energy consumption. One way to accomplish this is by upgrading the aging energy grid to become more efficient through the use of sophisticated technology. As more energy becomes available from alternative renewable sources and as the proliferation of technology makes devices on the grid inherently smarter and more efficient, the aging grid must be upgraded to accommodate these changes. To do so, the electricity distribution infrastructure must be able to manage congestion and offset peak load demands in a smart, efficient and effective way by soliciting consumer participation through the use of “smart” devices.
Self-sufficiency in meeting new energy demands is a major motivation for governments throughout the world. This motivation compels agencies—NIST in the United States and CEN, CENELEC and ETSI in Europe—to drive standards that aim at turning their countries’ electrical grids into a “Smart Grid.” These new standards will eventually require compliance from all smart devices that attach to the Smart Grid, and in the process, introduce new challenges for device manufacturers to come up with innovative compliant designs that have very little impact on cost to customers.
In the past, due to a lack of widely adopted standards, the functional requirements for a so-called smart device on the grid were often quite simple. This lack of standardization led to both hardware and software designs that lacked sophistication. These devices traditionally focused on isolated functionalities like metering, monitoring, or reporting usage data without contributing to the grid’s intelligence. For example, power meters would collect usage data and the only action taken on that data was to calculate the power bill based on the number of units consumed. If instead, that data was used to trend the consumer’s usage pattern and subsequently the consumer automatically received recommended steps or actions that would help reduce usage, the meter would have contributed to the reduction in the consumption of energy and would have made the energy grid “smarter.”
The Smart Grid challenge
Devices on the grid today follow either very fragmented sets of standards or no standards at all. Standardization of functionality would enable these devices to add much needed value by adding more capacity and contributing to the overall goal of maximum grid efficiency (Figure 1). This is where the emerging Smart Energy Profile (SEP) standards proposed by the ZigBee Alliance and the HomePlug Alliance come into play. The new SEP 2.0 Specification defines technology standards for devices that enable consumer participation and align with the utility company’s goal of effective smart energy management and distribution.
In a typical Smart home, devices such as a washing machine, an in-home display and a power meter can all work together in tandem—to make the grid smarter.
The SEP standard defines a variety of “Function Sets” that specify the functionality expected from a SEP-compliant device—or a “Smart Grid” device. There are a collection of behaviors that comprise each function set. Every device must implement a common/base function set as described in the SEP 2.0 Application Protocol Specification in order to be classified as a Smart Grid device, and then depending on the device’s expected behavior, more of these function sets can be included on top of the common/base set. A SEP-compliant device should also be inherently power efficient, support high availability (always-ON and connected), provide real-time responsiveness (to achieve grid efficiency) and must include feature-rich networking support, including IPv6, TLS, HTTP, Wireless connectivity, etc.
To meet networking requirements, SEP requires the use of TCP/IP as the underlying communication protocol and specifies the use of IPv6 to eliminate the problem of a limited address space while providing for interoperability and mobility. Due to its expected proliferation into a multitude of consumer devices, SEP requires support for commonly adopted application layer protocols like HyperText Transfer Protocol (HTTP) and REpresentational State Transfer (REST). To facilitate time synchronization for device management and logging, SEP specifies the use of the Network Time Protocol (NTP).
In addition to all of these requirements, one of the most important—and the most worrisome—aspect that accompanies these requirements is the vast exposure of the energy grid to attacks via the Internet. Such attacks could have catastrophic repercussions. This vulnerability necessitates the need for securing all of the devices on the grid with capable security and cryptographic algorithms. SEP specifies the use of IPSec, SSL or TLS depending on the function set and the layer at which security is desired. SEP is designed to work over any link layer technology. So, depending on the application, Ethernet, Wi-Fi, ZigBee, PPP, Bluetooth, etc. are all possible technologies (Figure 2). Besides wired and wireless connections for network communications, several service oriented tasks like firmware download/upgrades, security certificate updates, running diagnostics etc. require a direct connection. For this purpose, SEP also specifies the use of direct connection methods like USB and serial.
An example of a minimalistic hardware design that can support a wide range of peripherals, and at the same time includes a software solution that can offer all the services required by SEP.
This expansive set of requirements adds to the challenges device manufacturers will have to address. Foremost, device manufacturers must select a hardware design that supports achieving this level of functionality—with little to no cost increase to the end-user. Consumers will not be exposed to most of the underlying functionality, so paying more for their appliance so it can plug into the Smart Grid is hard to justify. After selecting the suitable hardware, a software architecture is also required that meets these requirements and supports execution in a low-cost hardware design. The following sections explore both the hardware and software sides of these challenges.
Choosing Low Cost Hardware
A device must comply with the SEP specifications and provide the required functionality to be classified as a Smart Grid device. Furthermore, all of this functionality needs to be supported in a low-cost hardware solution. Considering the device functionality, power requirements and the available silicon, 32-bit MCUs are the best suited hardware for such a device.
Most 32-bit MCUs offer enough memory and processing power to deliver the performance necessary to meet the requirements outlined in the SEP specification. They can support all the peripherals necessary in a Smart Grid device like Graphical User Interfaces (GUIs), Ethernet, UARTs, USB, Bluetooth, ZigBee and Wi-Fi. Such MCUs also provide real-time clocks for time tracking, SPI and I2C buses for device communications, and support operating at different power levels. Furthermore, these system-on-chips (SoCs) contain up to 1 Mbyte of on-chip flash memory and a maximum of 192 Kbytes of on-chip SRAM. The following are some examples of the MCUs currently available in the market that are a good fit for various types of Smart Grid devices:
• ARM-Cortex-M processor family:
• Texas Instruments Stellaris Family
• STMicroelectronics STM32 Family
• Freescale Kinetis Family
• MIPS 14K
• Renesas SH-2 and SH-2A
Selecting the Right Software
After discussing both the hardware constraints and the functional requirements, it becomes apparent that the software architecture for these devices must be carefully considered. In addition to the SEP functional requirements, these Smart Grid devices should also support extremely fast booting as well as have the ability to easily switch to using battery sources in case of power outages. These requirements necessitate that these devices use less complex yet power-efficient software designs. Limited memory resources also mean that any software that powers these devices must have a small and highly optimized footprint. Three different software architectures that meet these requirements are worthy of evaluation: bare-metal designs, general purpose OS designs and real-time OS designs.
One choice is sticking with a proprietary bare-metal system and adding new functionality to the design to meet the SEP requirements. But that will very often turn out to be a huge undertaking of re-inventing the wheel—IP stack, security, etc. Besides, the fact is it’s extremely difficult to ensure that the underlying implementations are complete, comprehensive and meet all the required standards. In addition to these difficulties, extreme delays in getting the products to market could severely hurt the product’s prospect for success.
Another option would be to port a freely available, general purpose operating system such as Linux onto the platform of choice and build SEP specification-based applications on top of it. The main problem here is that the platform of choice, as described above (a 32-bit MCU), is heavily constrained both in terms of processor speed and the available on-chip memory, and Linux has somewhat large requirements for both. Besides this key point, many of these devices do not require such a heavy weight operating system, making this option a poor choice for most Smart Grid designs.
The last option is using a real-time operating system (RTOS), which can provide support for all the sophisticated functionality required by the SEP specification and yet offer a small footprint in addition to being fast, efficient and robust. An RTOS can provide for all of the “must have” capabilities such as: “instant ON” and “stay ON” all the time; real-time responsiveness; a wide range of peripheral support; TCP/IP networking; graphics (GUI) support; and network security, etc. The Nucleus RTOS provided by Mentor Graphics is a good example of one such solution (Figure 3). Nucleus is a widely deployed and scalable RTOS that meets all Smart Grid device requirements. It has both hard, real-time performance and integrated power management services. Such an RTOS can fit in a memory-constrained MCU, yet still provide the large set of functionality required for a Smart Grid device.
A diagram depicting how the software stack of a SEP-compliant Smart Grid device might look like on a low-cost microcontroller.
As the adoption of the new Smart Grid standards becomes a requirement, designing fully compliant devices that keep the bill of materials (BOM) minimized will become a major challenge for manufacturers. To create a device compliant with the SEP specification, a bare-metal software design is likely not an option due to the high number of functional requirements. On the other extreme, using a general purpose operating system will result in unacceptable cost increases because of the need for increased hardware resources. Device manufacturers need to find the right balance when choosing both the software design and hardware platform. The use of a scalable, power-efficient, real-time operating system with extensive networking support (wired and wireless) along with one of the 32-bit MCUs now available in the market is the closest to meeting all of these requirements. Following this design paradigm, designers will significantly reduce their time-to-market and still realize all of their Smart Grid application goals.