Five Grid Management Capabilities You Should Demand That Only RF Mesh Delivers

Modernization efforts are ramping up for leading European utilities with the rapid proliferation of smart devices extending throughout the electricity grid. Smart meters deliver real-time visibility at the end of the line; line sensors pinpoint faults for enhanced situational awareness; and automated feeder switches immediately reroute electricity around faults to minimize outage impact. While each of these technologies can independently address a specific operational challenge, together, these systems must work in harmony to maximize outcomes.

Many vendors may claim to offer holistic solutions, but only Itron has delivered on this integrated smart grid vision. With more than 190 million smart devices deployed, Itron has built one of the world’s most proven platforms for the modern utility. Whether you are planning to replace legacy distribution automation (DA) systems, or you are evaluating solutions for integrating distributed energy resources (DER), our RF mesh network provides the essential building blocks for the modern utility. The following are five capabilities you should demand when evaluating a grid management solution:

  1. Superior resilience and reliability. For any use case, your network must be reliable and resilient, giving you the ability to see and respond to conditions on the grid in real time, in any environment. A Wi-SUN-based RF mesh network provides superior reliability by designing the network with redundant takeout points and utilizing dynamic routing for self-healing. When a tornado touched down in the state of São Paolo, Brazil, Itron’s RF mesh-based DA network at CPFL provided 100 percent connectivity while local GPRS networks failed to remain operational. CPFL didn’t miss a beat, leveraging its network to quickly identify outages and expedite service restoration.
  2. True edge intelligence and control. Peer-to-peer communications play a vital role in the modernization of the grid. As the density of utility devices increases, additional strain will be placed on centralized communication and control systems. Distributed intelligence can alleviate some of these challenges by enabling devices to collaborate at the edge. While some providers claim to support edge intelligence by coordinating devices from the nearest network gateways, RF mesh supports collaboration between edge devices. This is especially important for mission critical grid operations requiring ultra-low latency response. For example, utilities like Commonwealth Edison in Chicago, utilize device “teaming,” enabling communications between reclosers to immediately identify faults and re-route power around the affected areas.
  3. The ability to connect existing devices to support future use cases. With changing priorities and scarce resources, grid modernization is typically implemented in stages. When you deploy point source solutions to solve today’s business needs, you end up with a patchwork of siloed systems. On the other hand, investing in an open standards-based platform such as Wi-SUN enables you to leverage today’s smart grid investments to solve tomorrow’s challenges. When United Energy began deploying its advanced metering infrastructure (AMI) in 2010, the utility’s initial goal was to track usage and billing. With a simple remote firmware upgrade, they were able to reprogram AMI devices to provide granular sensor data for new grid management use cases such as transformer loading and phase identification, meter-transformer mapping and non-technical loss identification. Enabling a new use case can be as simple as a remote firmware upgrade. The possibilities are endless.
  4. Multi-layered security to harden every attack surface. As intelligent devices proliferate across the grid, so do opportunities for malicious attacks. A secure smart grid platform must be engineered to protect your smart grid system from every threat vector. The network must be encrypted, endpoints securely authenticated and tamper-proofed, and software access restricted for each individual role. When a critical security patch is required in a pinch, all devices need to be upgradable. Itron’s multi-layer security architecture has been engineered from the ground up to provide military-grade protection for every device and application connected to the network.
  5. Flexibility and vendor choice. With a 20-year lifetime on any smart grid investment, you can rest assured that your business needs will evolve over time. The ideal smart grid platform must be able to accommodate this changing environment while supporting a diverse range of solutions. Itron’s RF mesh-based network platform is built on the widely adopted Wi-SUN specification. Our standards-based technology enables an open ecosystem of interoperable solutions from best of breed suppliers, giving you the flexibility you should demand while promoting innovation and price competition.

As you evaluate suppliers for your next smart grid investment, consider how each technology can play a role in a larger integrated ecosystem of solutions. Decisions made in isolation may solve an immediate need while limiting options in the future. Consider the platform as a holistic solution investment. The Itron RF mesh-based platform offers the proven results for today’s challenges while providing the flexibility to address the challenges of tomorrow.


Itron’s Integrated Energy Forecasting Framework

In today’s marketplace, incorporating the multitude of Distributed Energy Resources (DER) can make producing an accurate energy demand forecast very challenging. Amid this increasingly complex business, regulatory and technological environment, Itron pioneered the integration of DER resource forecasts into the real-time load forecasts that system operators require to manage the grid daily.

Recently, this concept of an Integrated Energy Forecasting Framework (IEFF) was extended to long-term load forecasting. Read more about Itron’s new approach to long-term energy forecasting in our white paper on the Integrated Energy Forecasting Framework.


To BYOT or Not to BYOT: That is the Question

Itron is a long-time member of the Peak Load Management Alliance (PLMA), which was founded in 1999 as the voice of demand response practitioners. I serve on the Executive Committee of PLMA and co-chair the Thought Leadership planning group.

Over the past few years, PLMA has been very focused on sharing the expertise of its members to help demand response professionals better address changing industry dynamics. An example of this is a recent PLMA publication called “The Future of Utility ‘Bring Your Own Thermostat’ Programs” that was created to help members better understand the value of Bring Your Own Thermostat (BYOT) demand response programs. This paper—part of a new series call “Practitioner Perspectives,” where PLMA collects member insights on important industry trends—is a compendium of eight energy utility, manufacturer and solution provider viewpoints. The authors were selected in an open call for submissions and all article drafts were reviewed by a team of mentors that included the PLMA Thermostat Interest Group co-chairs prior to publication. Itron was pleased to be selected as one of the paper’s authors.

The perspective that Itron brings to the paper is that we have historically been focused on delivering operational demand response programs through the aggregation of a substantial amount of residential and small commercial load. As we outlined in the article, Itron today primarily views BYOT programs as a tremendous opportunity for utilities to better engage with their customers by rewarding those who have already purchased a Wi-Fi thermostat with the financial incentives that come with participating in a demand response programs. So as utilities look for ways to improve customer satisfaction scores, BYOT programs are a great vehicle to accomplish that. In terms of the BYOT role in demand response, for now, we see BYOT as a key component of a broader demand response/distributed energy resource strategy that may also include direct install devices, electric vehicle chargers, storage and more. And while we see the role of BYOT growing over time, due to limited penetration of these devices in today’s market, we don’t think it’s a great option to be the only load source when a large number of megawatts needs to be obtained.

To learn more, you can download the free paper here. PLMA also hosted a webinar on the paper that includes members of the Thermostat Interest Group, the Thought Leadership Planning Group and several of the authors. You can view a recording here.


Daylight Saving Time: The Bane of the Load Forecaster

Sunrise and sunset times vary from summer to winter because of earth’s tilt with respect to its orbit around the sun. This difference is magnified at latitudes further north (and further south) of the equator. In other words, the number of hours between summer sunrise and winter sunrise is larger as you travel away from the equator.

There is a saying for this: Days get longer in the summer time. If “day” refers to hours of daylight, which is clearly the intention, this statement is demonstrably false. After all, the longest day of the year (measured by hours of daylight) is the summer solstice, which is the first day of summer. Thus, days get shorter after the summer solstice.

The following figure presents one year of sunrise and sunset times, in both standard time and daylight saving time (DST), for New York City. The sunrise values are on the bottom of the figure and the sunset times are on the top. As we move into the year, sunrise times become earlier—until roughly the summer solstice—while the converse is true of sunset times. In New York City, the earliest sunrise time (in standard time) is about 4:24 a.m., while the latest sunset time is about 7:31 p.m.

Because we live in a largely industrial and post-industrial economy, rather than agrarian, our daily schedule does not change based on varying sunrise and sunset times.

In the above figure, the sunrise time jumps from about 6:10 a.m. on standard time to 7:10 a.m. DST at the start of DST in March. The goal of DST is to align human activity with the diurnal and seasonal solar cycles. In other words, we are shifting our behavior so we can be awake and active during daylight hours. The benefits and costs of DST have been widely debated and you can research them elsewhere— I’m not here to make the case for or against the use of DST.

DST is implemented variously around the world—some countries use it, and some do not. And while most states in the U.S. implement DST, others do not (including Hawaii and most of Arizona).

In the U.S., DST begins at 2 a.m. (in the local time zone) on the second Sunday in March (“spring-forward”) and it ends at 2 a.m. on the first Sunday in November (“fall back”). In March, clocks go from 1:59:59 a.m. standard time to 3 a.m. DST; while in November, clocks go from 1:59:59 a.m. DST to 1 a.m. standard time. Thus, the March day has no 2 a.m. hour (resulting in a 23-hour day) and the November day has two 1 a.m. hours (resulting in a 25-hour day).

This is all rather arcane and inscrutable, but it matters to those of us who deal with hourly and sub-hourly data. In fact, it causes no small amount of agita to load forecasters and load researchers.

Let’s clarify a few related issues. For discussion purposes, let’s think about hourly data. Data can be labeled as hour-beginning (0 – 23) or hour-ending (1 – 24). Let’s further stipulate that hour-beginning 0 (i.e. midnight) represents the same time period as hour-ending 1 a.m. That is, the integrated load value for that period was calculated from higher frequency data between midnight and 1 a.m.—the only difference is what we call that interval. In Itron’s forecasting products, we tend to think of data (and we store it in databases) as hour-beginning. Thus, the first hour for the day is 00:00 and the last interval is 23:00. (As a side note, MetrixIDR 6.0 and higher include functionality to display data in hour-beginning or hour-ending format.)

If your load data is in hour-beginning format and it is adjusted for DST, there will be no observation for 02:00 a.m. on the spring-forward day. On the fallback day, we typically import the 01:00 a.m. value. When the clocks revert to standard time, we typically overwrite the initial 01:00 a.m. value with the new 01:00 a.m. value. There is alternative treatment of these days in customized imports and exports.

These same issues apply to hourly weather data, but there is slightly less concern for a few practical reasons. First, the weather data is fluid, and regardless of how proximate the station is to the load, it is never perfectly representative of the load zone. Second, our statistical models typically utilize aggregate weather variables, which account for multiple hours (i.e. time-of-day variables). While it would be ideal to get the weather data perfectly aligned in time and space with regard to the load data, it is generally close enough.

These are all issues that must be understood before importing, processing and/or modeling the data. Specifically, is the data adjusted for DST or not? Is the data in hour-beginning or hour-ending format? And, how does the forecast need to address these issues? Does your downstream application expect 23 hours on the spring-forward day and does your downstream application expect 25 hours on the fallback day? The easiest solution is to store, process and forecast all data in standard time. However, that is often impractical for various business processes.

If you are interested in seeing some of these transforms, download a sample MetrixND project.


eBook: How Utilities are Planning for Distributed Energy Resources

With the rapid integration of renewables and distributed technologies into the grid, utilities can no longer feasibly address the challenges of maintaining power quality, balancing supply and demand in real time and ensuring adequate distribution infrastructure capacity with their old systems. To gain a better understanding of what utilities think about a holistic distributed energy management strategy—and what challenges they face and benefits they expect—Itron and Zpryme conducted a survey of 170 electric utilities and collected the findings in a new eBook: Distributed Energy Management: The New Era of Demand Response.

The statistic that most resonated with me from this study is that 71 percent of utilities believe that distributed intelligence and computing power at the grid edge will be critical to effectively manage distributed energy resources (DER). At Itron, we couldn’t agree more. The proliferation of DER requires a distribution grid that responds to changing conditions in real time to meet demand and maintain grid stability. And this requires a network that enables distributed intelligence to make DERs at the grid edge capable of responding quickly and locally to real-time conditions as they occur.

With more than 400 downloads to date, it’s clear the eBook covers an important industry topic. You can download the eBook here.


Take Our Annual Energy Survey

Itron’s forecasting group recently launched its annual energy survey. As we have done in previous years, Itron uses this survey to collect information to assess industry growth expectations and forecast accuracy for electricity and natural gas. This year, we will continue to focus on forecasts of customer and sales growth, weather-normalized growth and forecast accuracy.

All survey participants will receive a summary report, and the preliminary results will be presented at the annual Energy Forecasting Meeting in May. Final results will be shared during our brown bag seminar on Sept. 11. Utility-specific data will not be disclosed.

Surveys like this benefit the entire energy community by supplying valuable knowledge. If you would like to participate, contact Paige Schaefer at paige.schaefer@itron.com. Initial responses are requested by Friday, April 6.


Ignore Missing Option

The Sum function in MetrixND seems like a complex way to make adding difficult.

In a MetrixND transformation, numbers are added by joining variables with the “+” sign. Adding three variables is as simple as writing the following expression in the transformation editor formula box.

DataSource.Variable1 + DataSource.Variable2 + DataSource.Variable3

The complex way to add is using the “sum” function.  This function requires inserting the three variables separated by commas (,) as sum function parameters as shown below.

Sum(DataSource.Variable1,DataSource.Variable2,DataSource.Variable3)

Technically speaking, the um function requires an extra five characters to do the same work as the traditional + sign.

So, why does MetrixND include this function?

In the situation where variable has missing values, the calculation using the + sign results in a missing value.  In other words, a number plus a missing value equals a missing value.

100 + MISSING = MISSING

While the sum function behaves the same, the “Ignore Missing” option changes the behavior to produce a value.  In other words, the sum function with the Ignore Missing option means a number plus a missing value equals a number.

100 + MISSING = 100

To activate the Ignore Missing option, check the Ignore Missing box in the transformation editor as shown below.

The Ignore Missing options works with the following functions

  • Sum
  • Avg
  • Max
  • Min

It does not matter whether you use traditional math operators or the functions when data are complete.  However, when the dataset has missing values, the functions and Ignore Missing options may be the difference between forecasting a number and forecasting a MISSING.

Complexity has its purposes.


Fulfilling the Vision of the Multiple Application Network

In the past year, many people have asked me about smart cities, and how useful they are for the citizens living in the city.

A study that we conducted clearly demonstrated that a majority of citizens do not feel sufficiently educated about what a smart city can do for them.

At DistribuTECH in San Antonio, Itron showed a sneak-peak of the vast applications its technology can offer to a smart city.

The event was especially exciting because Silver Spring Networks and Itron both presented at the event as one company for the first time. Less than a month after the closure of the acquisition, our teams collaborated to bring a real cohesion to the conference. Beyond the new company camaraderie, we showed an amazing combined offering, which is what inspired me to write this blog.

DistribuTECH was an excellent event to showcase Itron’s technology for smart cities.

I would categorize three main axes that we focus our development around:

  • Resources and Infrastructure Management
  • Data Analytics
  • Improved City Services

These three axes bring incredible benefits to cities. Itron helps cities modernize their water metering and management systems to address such shortages. For example, our metering technology is addressing water scarcity in Rwanda. When I heard about the water crisis in South Africa, I realized Itron’s solutions could address the shortage of water and its disastrous consequences on people’s lives.

I am proud to see how my company helps cities to save resources and reduce energy consumption by orders of magnitude. Our solutions save them important dollars that can go toward meaningful services for their citizens and reduce their carbon footprint significantly.

Beyond water, we also showcased our solutions for electricity and smart lighting, which are core to our offerings. There are so many other important resources and infrastructure that a city has to manage.

To find solutions for all these challenges, we launched the Developer Program last year.
In little more than six months from its launch, we demonstrated at DistribuTECH innovative, end-to-end solutions for:

  • Parking management developed by Communithings,
  • Intelligent traffic systems from Houston Radar and Axis,
  • Intelligent digital displays developed by D3 Led,
  • Air quality sensors developed by Aeroqual and eLichens,
  • Methane sensors developed by New Cosmos,
  • Radiation detectors developed by D-Tect,
  • Manhole flood sensors developed by US3, and
  • Pole tilt sensors for faster recovery from storms and natural disasters.

All these solutions have few things in common:

  1. They all use the same network! Why is this important? For a city, this is a little bit like a family plan. It’s cheaper and simpler.
    1. All services use the same infrastructure, so the city doesn’t have to pay for extra infrastructure that is not only costly to install, but also to maintain.
    2. All the data flows to the same place, enabling fusion of data from different sensors for future analytics and facilitating billing.
  2. All these applications leverage data analytics to derive meaningful outcomes for the city and its citizens. Many of them use Itron’s IoT Edge Router, which allows them to build analytics at the edge of our network.
  3. All have direct impact on citizen’s lives, helping cities better serve their communities for better education, health and safety.

Smart cities and utilities are at the core of what Itron does. As cities and consumers around the world learn how impactful this technology can be for them, we will continue to strive for excellence and enable more innovations. We look forward showing you what is coming next!


Using Neural Networks to Build Robust Hourly Models

Our first brown bag seminar of the year is entitled, “Using Neural Networks to Build Robust Hourly Models.” Neural networks are flexible functional forms that learn about nonlinear relationships from the data. These models can be used to identify nonlinearities and variable interactions and to construct x variables that embody these relationships. Learn more about these variables and how they can be used in regression models that have rich relationships that are also simple and robust.

Join us on Tuesday, Feb. 20.  To register, for this Brown Bag and other forecasting events, go to this link: http://www.itron.com/forecastingworkshops.

Participation is free, but prior registration is required. Each seminar lasts approximately one hour, allowing 45 minutes for the presentation and 15 minutes for questions. Seminars start at noon PST.  If you cannot attend a seminar or missed one, don’t worry. Your registration ensures that a link to the recording will be sent to you automatically approximately one week after the seminar date.


Adventures in Cryptocurrency

Last October, a conversation began in the Itron Idea Labs community around blockchain and what Itron might do with it in the energy space. Ideas were plenty, ranging from the interesting to the ridiculous and really began taking shape at our last quarterly Itron Idea Labs meeting in Oakland. A concept evolved from this, and we were asked if we could put a demonstration together for the Consumer Electronics Show (CES) – a mere three weeks away. 

Being a hacker from the old school, I can’t resist a challenge, and said, “Sure, I think we can do that.”

Now, I have a head full of gray hair in testament to a lifetime of saying things like that, but I had read books! I had developed whole applications before! “How hard can it be?” I asked myself. I was about to find out.

I have a love/hate relationship with open-source software, which is what blockchain is. It’s free, which is always nice, but documentation is sparse, and because of the newness of the technology, changes happen fast. Documentation and tutorials written three months ago often don’t work anymore, and you must find your own way around the issue. I won’t bore you with the details of every pitfall I experienced, but by the time I was finished, I had learned five new programming languages, and we managed to field a serviceable, but not very easy-on-the-eyes demonstration at CES that was very successful.

Today, we have a fully operational private blockchain network consisting of seven application servers and 10 simulated electric meters sending payments and consumption data every five minutes. All of the billing calculations are performed on the meter itself, and the consumption data is permanently stored in the blockchain for use by any application that requires it.

With persistence and teamwork, anything is possible! We were proud to have our work represented on the screens at DistribuTECH 2018, and we’re hard at work on the next evolution, which will be to replace the simulated meters with real OpenWay® Riva meters. We think it’s a great combination, and we’re excited to test the possibilities.


Dividing Two Interval Series in MetrixLT

In my previous post, I showed that MetrixLT can multiply two hourly data series even though the software was not designed for that specific purpose.

Finding unintended uses of MetrixLT proved to be an addicting game for our forecasting staff.   Naturally, the next question is: “If we can multiply, can we divide?”

Since division is multiplication with an inverse, we thought this might be easy. But once again, MetrixLT was not designed for performing simple arithmetic, and creating the inverse still requires dividing.

The MetrixLT Scaling Transformation is designed for two functions. First, The Scaling Transform can be used to adjust a forecast based on the historic ratio between the backcast and a Target series.  If I have a forecast of hourly load for 2018 and a backcast covering 2017 (defined as the Overlap), then I can adjust the forecast based on the ratio of the Target series to the Overlap.  While interesting, this is not the designed operation we will use for division.

To divide, we will use the second Scaling Transformation function designed to calibrate a bottom-up forecast to a Target series. Assume you have a Target series Y and three bottom-up series A, B, and C.  The Scaling Transform can adjust A, B, and C such that Y= A+B+C. The process is two-fold. First, the Scaling Transform calculates the Calibration series (kCalib) as shown below.

kCalib = Y/(A+B+C).

Second, the Scaling Transform applies the Calibration series to each of the bottom-up series.

A’ = A x kCalib

B’ = B x kCalib

C’ = C x kCalib

The division process takes place in calculating kCalib. To divide interval data, we must make Y one series and the bottom up components (A, B, and C) and single a different series (D). The resulting ratio is the division outcome.

kCalib = Y/D.

Division can be accomplished using the following steps.

Step 1:  Import Interval Data

Import the hourly data in the Interval Data table. In this example, hourly data for Zone 1 and Zone 2 are imported. I’ve highlighted the January 11, 2015 values to check our work.

Step 2:  Configure A Scaling Transformation

Create a Scaling Transformation and configure the Forecast Variable and the Input Series boxes.  In the Forecast Variable box, insert the hourly data used as the numerator. In the Input Series box insert the hourly data used as the denominator. In the example, Zone1 is the numerator and Zone 2 is the denominator.

When the Target Variable is undefined, the Energy Method, Peak Method and Calibration Method selections do not apply.

Step 3: Calculate the Result

Select the “!” to calculate the Scaling Transformation. The division result is stored in the kCalib variable.

I’ve highlighted the validation for January 11, 2015.

  • Zone 1 = 2.60
  • Zone 2 = 36.595
  • Product = (Zone 1) / (Zone 2) = 0.071048

Zone 1 values are divided by Zone 2 values and stored in a kCalib variable of the Scaling Transformation table.


Multiplying Two Interval Series in MetrixLT

“Help” was the desperate cry of a MetrixLT user after the close of the workday.

“I need to multiply two hourly interval data series in MetrixLT!”  While the user understood the action can be accomplished in MetrixND or Excel, he didn’t want to leave the MetrixLT environment. After all, who wants to export data to a separate environment, perform a simple calculation, then re-import data back to MetrixLT?

MetrixLT was designed to perform complex functions such as scaling interval data to monthly data. For instance, an hourly profile (interval data) can easily be scaled to a monthly energy forecast (monthly data) in the Batch Transformation object. But, MetrixLT was not designed to address this user’s urgent need.

With flashbacks to the Apollo 13 movie scene of NASA engineers fitting a square air filter into a round hole, we went to work searching for a way to make MetrixLT perform a task that was not originally intended

Step 1:  Import Interval Data

Use the Import Interval Data feature to create two hourly Data Tables in MetrixLT.  In the example below, data for Zone1 and Zone2 are imported into MetrixLT.  I’ve highlighted the January 11, 2015 values to check our work.

Step 2:  Configure A Batch Transformation

Create a Batch Transformation and configure the Shape and Loss Multiplier boxes with the Zone1 and Zone2 interval data.  In the example, Zone1 interval data is placed in the Shape box and Zone2 interval data is placed in the Loss Multiplier box.

By leaving the Energy field empty, the Batch Transformation will not perform scaling resulting in Shape field values multiplying with the Loss Multiplier field values.

Step 3: Calculate the Result

Select the “!” to calculate the Batch Transformation result and you are finished.

I’ve highlighted the validation for January 11, 2015.

  • Zone 1 = 2.60
  • Zone 2 = 36.595
  • Product = (Zone 1) x (Zone 2) = 95.147

Zone 1 values are now multiplied by Zone 2 values and stored in a Batch Transformation variable.

And that is how we fit a square air filter into a round hole.


DON'T MISS A POST!
Opt in to receive notifications when a blog post is published. Don't miss the thought leadership, insight and news from Itron.
We hate spam. Your email address will not be sold or shared with anyone else.