Notes on UtilityAMI Telecon Meeting

March 6, 2006

The following agenda is proposed:

11:00 – Introductions
11:05 – Review / refine UtilityAMI mission – agree on mission statement
11:30 – Discuss the six proposed tasks – are they the right ones?
12:00 – Work plan discussion – timeline, approach (telecoms and workshops)
12:20 – Wrap-up, next telecom/meeting
12:30 – Adjourn

Introductions

• Paul De Martini – SCE

• Larry Oliva – SCE
• Terry Mohn – Sempra
• Bob Hemphill IP&L
• John Boosey IP&L
• Pat Duggan – Con Ed
• Richard Schomberg – EdF
• Brent Hughes – BC Hydro
• Scott Blackburn - Florida Power & Light
• Kevin Woods
• Ted Reguly SDGE
• Jane Corey – PG&E
• David Glenwright -– Exelon

Utility AMI Facilitators - Enernex

• Erich Gunther
• Jerry Melcher
• Grant Gilchrist

Agenda
• No new items
Mission Statement
• Erich: Here’s a draft, can we talk about it?
• FP&L - Q: What’s the difference between UtilityAMI and OpenAMI?
• Erich: UtilityAMI is the customer advisory group for OpenAMI. It was defined
at the beginning, but never instantiated. In retrospect, we should have done this
from the start. There wasn’t enough guidance for OpenAMI from those
purchasing AMI systems. UtilityAMI is utility members only.
• Paul DM-SCE: In talking to a FERC Commissioner, We may want to talk about
Energy Service Providers, and whether they can participate.
• Erich: That seems possible to me, since they are also people who buy these
systems.
• Terry: The word “guidelines” leaves a lot of wiggle room. Should that be
“requirements”?
• Erich: We have used the word “policy” elsewhere in the document. Maybe that
would be a good word? What should we put into the mission statement?
Guideline vs. Requirements, should we work on policy, guideline, requirements,
reference design, defining direction, delineating needs. Focus on why! Focus on
use cases.
• Paul: (likes the higher level words)
• Terry: Well, let’s iterate – start at a high level and work our way down, and see
where it goes.
• Discussion of OpenAMI status provided by Grant at Erich’s suggestion. Only one
use case developed currently. OpenAMI agreed upon principles, and which
interfaces need to be secure.
• Erich: I think that it’s clear that OpenAMI is still at the beginning of their
process, and so if we (Utility AMI) can give some guidance within the next six
months, that will help a lot with that process.
• Terry: Based on how things worked last year, I think we have to make that
judgment call ourselves. I don’t think that we should be waiting for feedback
from OpenAMI. If we need to write requirements, we should do the writing. I
don’t think we should delegate anything to OpenAMI.
• Paul: <lost comment> Need to focus on deliverables by Utility AMI and generate
work product on our own timeline.
• Erich: To summarize, there is a desire to work with OpenAMI for a variety of
reasons, but we need to get the work done ourselves and not wait for them.
• Pat Duggan, Con Ed: I think we need a gap analysis. There are a lot of other
groups like GridWise that are doing high-level requirements; we need to identify
for ourselves and other people what the difference is between this group and these
other groups. How do we coordinate?
• Erich: GridWise will not directly be “competing” with this; they are working at a
very high level. IntelliGrid does not have an explicit project involving this yet,
but they are about to vote on some additional funding that will coordinate with
SCE’s effort. Another project is the EPRI advanced metering communications
and control Research Interest Group. I am working with Marek Samotji to ensure
there is not a conflict there.
 • Richard Schomberg-EDF: In the IEC, there is a lot more time spent on
specifications than on requirements. So I think this work is pretty unique. We
need to make sure we work on requirements, and not specifications.
• Paul: This “gap analysis” fits (dovetails) with a couple of the task items we have
already identified. Maybe we should talk about them somewhat.
• Larry Oliva - SCE: Joe Hughes (EPRI) recommended that we look into the AEIC
metering committee and their proposed agenda for 2006. Perhaps we should take
a look at what makes us different from these groups and how we can use the work
being developed there.

Task 1 – Glossary
• Terry: We could just make an editable document in SharePoint. There is not a
need to have a separate task force for such a thing. Put the raw data on the web
site.
• Paul: There was an agreed common need at the DistribuTECH meeting that
without a common definition of the words we are using, the vendors become
confused. I think that this is a plus.
• Erich: Jerry has been working on this.
• Jerry: I have started with about 20 documents and should have the effort
completed by the end of this week.
• Erich: If you have some internal glossaries from your companies that you can
share, we would like to see them, please.
• Terry: We had to do the same think for our AMI RFP process. We will be glad
to share it. SDG&E has compiled a list of definitions and will post on the
Sharepoint site.
• Paul: How can the other utility folks feel? Do they think it would be useful?
• Pat: I think it would be very useful. Anything that makes things clearer. For
requirements to be adopted, there has to be a common base of people that agree
these are good requirements. That points to the ability to communicate what
we’re talking about.
• Paul: So when is the goal?
• Jerry: A lot of these documents are repetitive. The one from the Texas PUC
seems to be very comprehensive. A working document will definitely be posted
by the end of the week.
• Paul: Including the attribution of where the definition came from?
• Erich, Jerry: Yes.

Task 2 – Modular Interface

• Erich: What kinds of things should we be talking about, and what should we
focus on first? What is the level of detail required?
• Paul: The industry seems to be moving in the direction away from being locked
into one vendor, (more choice, but issue is how to implement it – proprietary vs.
 standard modular) but there seems like there is an opportunity here to get the
utility voice on how to get more choice.
• Brent Hughes: BC Hydro – we would like to have plug and play and intermix
systems, and not be tied into a single vendor.
• Erich: Is there anyone out there issuing RFPs requiring multiple networks.
• IP&L – we are in agreement with the idea of being able to mix and match
between different vendors. As long as it’s not proprietary, this shouldn’t be an
issue.
• Scott Blackburn: FP&L – Protocols need to be across the board
• Erich: There are a few vendors of wide area networks that may have some issues
with integrating with different vendors. There is also an issue of at what level we
need to talk about interoperability:
Types of WAN interface > RF/PLC, cable, etc.
Types of LAN interface > home interface
Types of Interface modules

Task 3 – Network Interface

• Erich: This is the interface from the AMI network to the MDMS, (not MDMA).
One meter data management system interfaces to 3 or more different AMI
systems. Need to define points of interoperability. How many people are
expecting to need a common MDMS with multiple networks?
o FP&L
o BC Hydro
o SDG&E
o SCE
o IP&L

Task 4 – Back Office Interface

• Erich: Comments on this? Are there things you would like to ask vendors to do?
• Erich: There have been some discussions of guidelines, like open message buses,
XML, common APIs. TXU have defined CIM, middleware enterprise service
buses, etc. Need to define needs on customer outage. Don’t need to get to
requirements, but still need definition for this area.
• Pat: Even if we don’t get to the requirements level, it would be nice to have a list
of the potential customers for these general kinds of guidelines. [not sure if I got
this right – Grant]
• Paul: I think if utilities are moving toward hourly data collection, there might be
some opportunities to discuss issues regarding “drop-outs” at the back office
level.
 • Scott Blackburn: FP&L Regarding tasks 2 and 3, those could be more about
requirements, but for task 4 we could talk more about functionality. Market has
provided solutions, but could focus on functionality
• Paul: Agree.
• Scott: Task 4 should be MDM functionality.
• Erich: Okay, I will change that.

Task 5 – Security
• Erich: Has anyone looked at this issue, as opposed to just leaving it to your
vendors? Lot of talk on security. But need to develop security requirements for
security to be implemented on large systems.
• Janet Corey – PG&E: We have been doing a lot of thinking about security and
the proper requirements. We are not just leaving it to our vendors. Task needs to
provide structure of security elements. We have someone on our team who could
be helpful to that discussion.
• Erich: Excellent, that’s what we need. Are you trying to tell your vendors what
you expect them to do?
• Janet: It’s somewhat iterative and specific to PG&E, but there’s probably a
structure that all the utilities could come up with that would be common to all.
• Paul: Depending on how the AMI system is going to be used, there is an
opportunity for lining up with the NERC/CIP guidelines.
• Janet: I think the vendor community would love to have some standards that they
could comply with. I think they just don’t know what that standard is.
• Paul: That’s the feedback we’ve been getting as well.
• Erich: We’ve been hearing a lot of confusion about whether the NERC guidelines
should, or do, apply or not.

Task 6 – General Issues Forum

• Erich: Is this a useful thing to do? Do you have any topics to “seed” the process
with?
• Paul: I think this would be a good opportunity to exchange ideas. Good to keep
open dialog on best practices.
• Erich: Is anyone else involved with a similar process? (no answer)

Additional Tasks
• Erich: Any missing topics?
• Pat: Will be there some minutes I can circulate to other people at my company
and get feedback?
• Erich: Absolutely.
• Janet: We have a lot of discussion in California about end-use technology, such
as demand response, programmable thermostat, AMI enabler to the home, two-
way communication. Look to extend the work and look at device functions.
 • Paul: We haven’t talked about it yet.
• Erich: Perhaps Task 3 could be extended to talk about that.
• Janet: How about some kind of direct output from the meter to the end devices?
• Paul: I think a separate task for that interface would be appropriate. In
California, the utility commissions are planning to require communicating
thermostats in all new buildings in 2008, and the wording will be proposed in the
June 2006 timeframe.
• Erich: So, a customer interface task? PCTs, load control, building automation
systems, consumption display, etc.
• Agreed.

Schedule
• Is the priority in this schedule correct?
• Richard: I think that security is a cross-cutting issue and should be in parallel
across the other tasks. Put together structure/framework, then subtask security
implantation.
• Erich: I was trying not to put everything in parallel. If we deal with security at a
high enough level, we don’t have to tie it to every task.
• Paul: Maybe if we get into more detail on the security portion, we can get a better
sequence than what is shown here.
• Erich: Are there resources that could help us with this topic?
• Paul: I would anticipate that most of us would take some work product to the
table, as opposed to OpenAMI, which started from a clean sheet. That’s the only
way we will get this done in a six-month timeframe.
• Kevin Wood: SCE - I think just getting the discussion going on the process will
be helpful as well.
• Agreed.

Logistics
• Erich: One of the things we proposed in the document was that we really need to
get some people together in a room to make this work. We made a proposal for
some workshops; what do people think of the idea?
• Ted Reguly: SDGE – Terry suggested we host something around the 20th of this
month; is that off the table now?
• Erich: First, does the group agree that this is the way we want to get this working,
and second, if so, what are the dates that work?
• Ted – either get people together in the room, or regular video conferences, or we
will be in the same boat as OpenAMI.
• Paul: The 20th is on the table, and works for us, but there’s a possibility of the
following week.
• Is OpenAMI having a meeting at the end of March?
 • Paul: I think we’re hosting it the week of the 28th. It would be nice to coordinate
it with the OpenAMI meeting.
• Terry: There would be an opportunity to broaden the group.
• Erich: What about full-day teleconferences?
• Kevin: I’m a big fan of the teleconference
• Ted: Me too.
• Erich: I assume we will have short status telecoms, but to get the real work done,
the only way I see is to get face-to-face.
• ???: We need to make sure people get and share the work projects ahead of time,
but face-to-face is best for review.
• Paul: I think we can minimize the number of face-to-face meetings.

Action Items:

Mission Statement
Task to develop high level mission statement covering Utility AMI policy
statement and focus on requirements development
Develop list of interfaces with other industry groups interested in Utility AMI
work

Task 1: Glossary
Jerry Melcher to assemble Utility AMI Glossary from multiple sources. Post list
on March 6, 2006

Task 2: Modular Interface

Focus on development of modular interfaces. Clearly define level of
interoperability

Task 3: Network Interface

Develop interface between AMI network and MDMS

Task 4: Back Office Interface

Change focus to focus on functionality of Back Office interface with potential
users

Task 5: Security
Task needs to provide structure to security elements. Need to define security
standards for vendor community to support. Need to assess impact of NERC/CIP
requirements

Task 6: General Issues Forum

Maintain open dialog on best practices

Additional Tasks
 Extend Task 3 to add Develop Customer Interface Task – cover interface between
meter and other end use devices – PCT (Programmable Communicating
Thermostat), pool pumps, customer alert devices, building automation,
consumption display, etc.

Schedule
Parallel track security subtask. Provide more detail to the security portion.

Logistics
SCE to look at coordinating the next Utiltiy AMI meeting the same week of the
Open AMI meeting the last week of March.
SDG&E is willing to host the next Utility AMI meeting after the SCE meeting.

General:
Enernex to post meeting minutes and presentation to Utility AMI sharepoint site.