SEP 2.0

When I first heard the term “Smart Energy”, I confess that I had no idea what it meant. For a while, a precise definition seemed to elude me, as people would talk about smart meters and the Smart Grid, but not actually say what smart energy was. It is now a little clearer.

Smart Energy is really a catch-all term for a bunch of technology associated with energy efficiency primarily in a domestic context, which includes smart meters, smart thermostats, in-home display systems, and smart appliances. At the heart of smart energy is SEP 2.0 …

Smart Energy Profile [SEP] 2.0 describes protocols to connect smart energy devices in the home to the smart grid and covers a variety of smart energy devices and use models – smart home, smart grid, electric vehicles etc. It is also envisaged that SEP 2.0 would enable self-contained energy management systems, that are not connected to the smart grid. The original work on SEP 2.0 was a collaboration between the HomePlug Alliance and the ZigBee Alliance.

As SEP 2.0 runs over TCP/IP, it is independent of the media access control [MAC] and physical [PHY] layers, which makes its deployment very flexible – you can use WiFi, Ethernet or whatever is available. SEP 2.0 is built around the idea of function sets, which are sets of behaviors designed to provide specific functionality. These include:

• Billing
• Confirmation
• Demand Response / Load Control [DRLC]
• Device Management/Configuration
• Diagnostic & Monitoring
• Distributed Energy Resource
• Firmware Download
• Messaging
• Metering
• Plug-in Electric Vehicle
• Prepayment
• Pricing
• Registration

An SEP 2.0 enabled device [or application running on a smartphone/tablet in some cases] might utilize one or more of these function sets. For example:

• A Smart Appliance Plug might utilize Pricing, DRLC, Messaging
• An In-Home Display might utilize Device Management/Configuration, Metering, Messaging
• A Metering Device might utilize Metering, DRLC, Messaging, Pricing

So, what is needed to develop a SEP 2.0 compliant device? Although such a product could be created on “bare metal”, it is most likely that a real time operating system system would be employed. Such an RTOS would have a number of specific characteristics and capabilities:

• real time
• power efficient
• small footprint
• support for SEP 2.0 function sets
• networking [including IPv6]
• connectivity [like WiFi, USB etc.]

Of course, as you might guess, Mentor Embedded’s Nucleus RTOS fits the bill rather well.