Blogs

Utility Players

Data management technologies underpin energy manufacturers’ smart grid efforts

Information and data will play a critical role in the future of the energy industry. Driven by demands for greater efficiency, more transparency, and reduced environmental impact, energy utilities are adopting new technologies and strategies faster than ever before, especially smart energy grids and the services they make possible: smart meters that monitor energy volume and time of use; monitoring applications that track and adjust electricity rates continuously based on availability and demand, or that alert customers when their usage spikes into a different rate level; and networked equipment, such as transformers and power lines, that automatically report their status and capacity.

All of those devices and systems generate a lot of data—and businesses in the industry need to figure out how to capture and manage it. “The energy and utilities industry has one of the greatest data challenges out there,” says Alan Webber, information technology analyst and partner at the Altimeter Group.

As a result, the standards that energy businesses use for communication are receiving some serious attention from data professionals. The International Electrotechnical Commission (IEC) Common Information Model (CIM) is the electric power industry standard that defines (among other things) the data architecture for information about electrical network configuration and status. And as the energy industry adapts to new conditions, that architecture is being poked, prodded, explored, and expanded.

Data architecture for an energy city

One group facing that challenge head-on is the IBM team in Mannheim, Germany, that created the data infrastructure to support the Model City Mannheim (MOMA), a project created by the German federal government as part of its E-Energy initiative to research the impact of information technology on the energy distribution grid. The goal of the MOMA project was to create a smart grid that would provide a variety of services, including:

  • Smart metering services for reading, validating, qualifying, and aggregating meter data to support centralized meter data management systems
  • Energy management services for direct or indirect load control functions based on available load-balancing capabilities
  • Forecasting services for predicting energy consumption
  • Pricing services for calculating individual tariff-based prices for users

In addition to these new information-driven services, the MOMA smart grid needed to support many different participants. “Interoperability was always a critical part of our discussion,” says Andreas Herdt, advisory IT architect for IBM. “The energy market is fragmenting into more and more businesses, from network operators to specialized energy generators, resellers, and others. They need to be able to exchange data.”

The IBM team also wanted to create an architecture that would both mesh with the present while blazing a path for the future. “Our approach was to try not to build new models for the applications or the use cases that we needed to support,” says Christian Schiller, senior IT architect and managing consultant for IBM. “We wanted to work as much as possible with the CIM specifications that had already been accepted by the industry.”

To model or not to model?

The IBM data architects started planning by talking to all of the partners on the project and gathering as many different data concepts as possible. Some of the concepts didn’t always fit cleanly into the CIM data model definitions, and the team faced a constant temptation to solve the problem by defining a data concept in a specific application.

To help them make these critical decisions, the team laid down a set of criteria. “We had three rules of thumb,” says Herdt. “The first rule was to look at the model and find the concept. The second rule was to look carefully at the model and find the concept. And the third rule was to look very carefully at the model and find the concept!”

For the most part, the IBM team found objects in the model that could work with a little effort. “Sometimes we couldn’t achieve a perfect semantic match, especially at the attribute level, but we could usually get very close,” says Herdt. “It was important to build on the existing CIM model as much as possible because we didn’t want to re-create the wheel, and also because we want to build a foundation that other teams and organizations can work from.”

If a standard isn’t defined, is it a standard?

However, the IBM team ran into challenges with the CIM, starting with documentation that was often ambiguous and sometimes nonexistent. Some of the model was documented at the object level and occasionally at the field level, but there was no documentation on specific use cases. In other instances, the documentation was wrong. “There was a situation where there was a master class for the model, and in a few occasions the documentation didn’t correctly describe the object inheritance,” says Schiller.

The fields or objects that the team was uncertain about were often central to the function of a given device. As a result, the team found itself embroiled in debates over the original intent of a given specification.

One of the most striking examples arose as the team attempted to build a data model for meter readings. The CIM data model offered two different ways to record meter readings: reading and interval-reading. The standard reading object appeared to have been designed for infrequent use and was fairly bulky. “Using the standard meter reading definition, you would create a container for every reading, which computes to 96 objects per day per meter if you read a meter every 15 minutes,” says Herdt. Not a problem if you’re recording one reading per month, but with smart meters, the team envisioned reading at intervals measured in minutes, which meant data volumes would mount quickly.

When the team dug into the actual model of the interval-reading object, they discovered that for it to work, the interval between every meter reading needed to be precisely the same. “We couldn’t guarantee that the reading intervals would be identical because the underlying smart metering infrastructure did not offer readings exactly on the second,” says Herdt. Instead, the team used the standard meter reading object, understanding that data management policies would be needed to help offset the impact of the high data volume.

Searching but not finding

A few times, the IBM team couldn’t find a concept that came close to matching their requirements, as in the case of weather forecasting. Weather dictates both how energy is consumed (air-conditioning in the summer, heating in the winter) and generated (such as wind farms, solar facilities, and hydropower). However, the concept of weather was not even contemplated in the CIM model, so the team built their own data model to avoid misusing the semantic.

All of the work to address holes and document the model did not go to waste: the weather forecasting model (and the semantics supporting it) is one of many changes that the IBM team will propose back to the standards body that maintains the CIM. “The CIM data model moves pretty fast,” says Herdt. “It’s updated every 6 to 12 months, which is amazingly fast for the energy and utilities industry.”

That flexibility is a good thing, as the team can already see future needs. “The model covers smart metering now, but it doesn’t cover all the different tariffs that will be needed,” says Herdt. “We were able to create time- and volumedependent tariffs, but eventually we’ll need to make tariffs that depend on weather, energy availability, grid load, and other variables.”

One of the team’s ongoing challenges with the CIM involves finding ways to make the overall data model more specific. The model is not yet well-enough defined that separate organizations can simply follow it and feel confident that their data will match that of other organizations.

“Right now, the model doesn’t provide rules at the content level, which means that not everyone may use data containers in the same way,” says Schiller. “For instance, a device serial number field could contain the manufacturer’s serial number, an asset tag number issued by the organization that installs it, or something completely different.”

>Lights, network, action!

The true test of the data model and semantics defined by the IBM team will come soon, as the partners involved in the E-Energy project begin to use the model for their own projects. “Over the next months, our model and code will face test data from real smart meters and the utilities’ back-end systems,” says Herdt. Later this year, Herdt and Schiller expect to see a full field trial that is completely based on the model they helped create. After that, who knows? But in any case, the energy expended now to establish the data infrastructure for smart grids will be a bright investment in the future—for data professionals and customers alike.