Thursday, December 16, 2010

The AMI mismatch...

Something to toss on the fire next time people are arguing about how to pay for AMI installations.  There is a mismatch between the costs of AMI installations and certain benefits.

In most jurisdictions, AMI installations are carried out by the distribution operations of the utility.  Generally, this effort is paid for through the distribution ratemaking function, since it its the distribution operation that is doing (or more often contracting for) the work.  The Distribution operation does see some benefit, in reduced meter-reading costs and in some cases other cost reductions or service improvements, but often a big part of the cost-benefit analysis is enabling dynamic pricing.

However, here's the dynamic pricing kink: the "dynamic" part of dynamic pricing is primarily driven by the generation function.  Transmission and distribution are generally recognized as being almost entirely fixed cost systems.

What makes this particularly interesting is how this may be shoving the cost/benefit analysis askew in those jurisdictions where generation has been spun off from utility operations into competitive markets and/or those jurisdictions pursuing decoupling of distribution (and transmission) pricing from generation.

Just a thought to make your day more interesting.  I'd appreciate comments on whether this is a real issue, or I'm missing something.

Friday, December 3, 2010

Grid-Interop Day 4 Notes

Blogging from my phone this morning, so forgive any typos...
(As always, comments will be in italics, if I can figure out how to do italics from my phone.)

  • Sitting in a session on CyberSecurity for Information Assurance.  
    • Tanya Brewer from NIST is giving an overview of the NISTIR 7628(Scrolldown to find 7628 on the list.  Read the introduction volume first to identify what matters to you, since the whole thing is >550 pages.)
    • Interesting discussion on the need to integrate security throughout a system design.
    • How little can you spend to have an acceptable level of risk vs. how much do you need to spend to have an acceptable level of risk.
      • Zero level of risk isn't possible. What level of risk is acceptable?
    • An integrated architecture is critical.  This means that security is part of the people and processes, not just the hardware.  People, Processes and Technology.  Have to define and monitor metrics and indicators (we haven't been hacked yet isn't a metric.) 
  • Business and Policy Domain Expert Working Group meeting
    • Interaction between BnP DEWG and FERC/NARUC Smart Response Collaborative - Robin Lunt, NARUC
      •  NARUC is starting a Smart Grid Working Group to discuss Smart Grid, coordinate information sharing, education and development.
    • UCC Concept - Rik Drummond
      •  Developing the equivalent of the Universal Commercial Code for Smart Grid, to help States establish equivalent and compatible (though not necessarily identical) regulation.
      • One person suggested a pro-forma tariff.  In my opinion, that's a mistaken idea.  A pro-forma tariff is both too limited (the needed scope goes way beyond tariffs) and too restrictive (we don't yet know enough about what retail structures will actually work.)  In addition, having a pro-forma tariff in place may well restrict needed change over time.
    • Update on Language to Regulators - Ward Camp
      • Goal is to have a "library" of rules language to deal with policy issues state-to-state.
        • Privacy
        • Data Security
        • Data Ownership
        • Other Consumer Issues
        • Proposal goes far beyond that to identifying:
          • model tariffs (as I indicated earlier, I think this is premature, and possibly a bad idea in general.)
          • a "safe harbour" of acceptable technologies.  While many of these areas would be helpful, creating a safe harbour of acceptable technologies violates the technology neutrality of the SGIP.
        • The trick will be defining it at a high enough level that it can be implemented in the different jurisdictions.
        • There is a strong push for absolute national lock-in.  The better way to proceed at this point is to develop a consistent way of communicating and understanding tariffs.  It may also be a quicker solution to the problem.
      • HAN Task Force handoff - Ron Melton & Dave Wollman
        • Possible Role for BnP DEWG may be to drive the dialog between vendors, regulators, utilities.
          • Find solutions to state-to-state variations.
          • Find optimization of efficiency improvements.
      • Feedback & Discussion from Oregon meeting - James Mater
        • Oregon has first State-level Smart Grid trade association.  Didn't have much time to discuss, but it's an interesting effort.
    I'm out of here and heading home. Safe travels, all!

    Grid-Interop Day 3 Notes

    Once again, the day's missives from Grid-Interop.  Once again, my commentary is in italics.

    Today is pretty technical, so the discussion here will be very high level and limited, with the exception of the plenary sessions, which I'll discuss in as much detail as I can reasonably capture.  The lunch and dinner speakers may well be the most interesting of the day.
    • I spent the first session hopping between two sessions, one on Semantics and Semantic modelling (fascinating for a communications and linguistic geek like me) and a discussion of Case Studies.
      • Semantics discussion on "Demystifying the Common Information Model"
        • CIM is defined in a high level modelling language called UML (Unified Modelling Language)
        • IEC maintains it in Enterprise Architect, unfortunately, a proprietary system, but really just about the best tool for the job, and one of the few that explicitly supports non-Windows systems.
        • Under UML, any system is categorized by a series of high level classes and objects, with inheritance.  (Geek-speak for grouping things based on common characteristics.)
        • Profiles take a subset of CIM Classes and apply them in a given business context.
        • Theoretically and ideally, using UML and Profiles, different developers can use the same CIM classes, develop compatible application code definitions (even if the applications are written using different languages and schemas), and automatically test for compatibility with other systems.
        • It isn't perfect, but it is useful.
    • Priority Action Plan 10 (Delivering Usage information to the customer domain) Finalization.
      • Discussion regarding Leonard Tillman's comment on the Twiki.  (Scroll to the bottom to see the comments.)  Under the SGIP process, this comment has to be dealt with, however the proposed solution in the comment (altering the requirements) would require a change to the SGIP requirements review process.  A bit of a Catch 22. We have to address all comments under teh review process, but the comment requests we change the review process, which we can't do.  Resolved by clarifying what the requirements are intended to do.

        Regardless of how one feels about a proposal to alter these requirements (which I feel is a bad idea), altering requirements after a standard is written to them is a terrible idea.  Doing so will set a precedent that could gut the SGIP process.  How does one develop a standard to meet a set of requirements, and get people to invest the (volunteer) effort in the development, if the requirements can be changed on the fly after the standard is developed?  If you can alter the requirements after the fact, you can alter the requirements after the fact to arbitrarily reject the standard. 
      •  The PAP 10 seed standard is formally approved by the PAP 10 WG, and has been OKed by the CSWG review team.  next step is getting the Governing Board official OK.  After that, SDOs can use the seed standard to develop compliant standards that will be interoperable on a data expression level.  I admit, I'm personally pretty doggoned stoked over this.

    • Lunch Speaker: Lynne Kiesling - www.theknowledgeproblem.com 
      • Economic foundations of regulatory policy. 
        Why is (traditional) regulatory policy the way it is?
        • Regulation is historically based on cost recovery rather than value creation. 
          It assumes a decreasing long run average cost, and a given demand. 
          The goal is to provide a statically defined product at a known cost.  
        • This paradigm worked because it accomplished the public goals of ubiquitous service.  However, it doesn't support a more dynamic context. 
          Lynne compares the current cell phone market vs pre-Carterphone PSTN.
        • Barriers to entry limit innovation and efficiency gains from technological innovation.
          Choice is ubiquitous in our society.  I could argue that the willingness to intelligently make choices is in decline, but that's another topic. 
        • Regulation was good at the policy challenge of ubiquitous service, but not at promoting innovation.
          Changes need to come at a level that doesn't appear in anybody's architecture stack.  Changes need to happen at a cultural level. 
        • Lynne allows for some level of hierarchical control because of the need for real-time balancing, but her real vision is one of distributed intelligence.  Multiple devices in the field each responding to localized conditions.  This will probably resonate with this evening's speaker.
        • The secret, and the real trick for regulators / public policy makers will be to achieve a balance between allowing economic dynamism and maintaining the still legitimate public policy goal of ubiquitous service.  A fully dynamic market has market entrances and exits on a continuous basis.  There may be a limit to the amount of dynamism in the market for a critical resource.

    Wednesday, December 1, 2010

    Grid-Interop Day 2 Notes

    Once again, for my regulatory compadres, a summary of the events at Grid-Interop for Day 2 (As always, my commentary is in italics.):
    • Tom Evslin opened in the morning, comparing the future of the grid to the history of the Internet. 
      • Interesting 30,000 foot view, but at that height, many complicated and critical details get missed.
      • Most interesting and important points of Tom's presentation:
        • Eventually, grid neutrality will be as important as net neutrality is now. 
          • We need to establish early on a "Smart Grid Carterfone" decision.  Otherwise, instead of the "internet of energy", we'll have the Ma Bell PSTN of energy.
        • Smart Grid has to enable consumers to improve their lives, not just save them a few dollars, and that ability needs to be communicated to consumers now.
    • Foundational session:
      Panel discussion on why interoperability matters, and the need for consumer understanding of SG.
    • Unfortunately, I got pulled into a discussion of AMI security and privacy, and missed the session on Regulatory Policies and Rate Structures for a Demand Responsive Grid.  I will try to locate a link to the webinar, or at least the slides and notes.
    • CSWG Updates (Note: slides for Tuesday's and Wednesday's CSWG briefings are available at:
      http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/CSWGBriefings
    • FERC Update - Annabelle Lee
      • Important point regarding FERC's process regarding standards.  FERC is "adopting"standards.  The "adoption" of standards does not equal rulemaking, it is still voluntary.  This is a critical distinction from other FERC rulemaking actions.  I intend to follow up on this with Annabelle and elaborate later.
      • NIST forwarded IEC 62851 to FERC.  IEC 62851 uses a weak encryption standard, how will FERC address this?  No clear answer from Annabelle, but Frances Cleveland pointed out that the 62851 is being reworked by IEC to resolve the encryption question. 
    • The CSWG has "liasons" to each of the active Priority Action Plans (PAPs).  Each PAP Liason present provided an update of status.
      • PAP 05 - Meter Data Profiles - Darren Highfill
        Subgroup produced a report on PAP 5 CyberSecurity.  Several issues did come up, and were addressed through AMI Security subgroup.  PAP 05 is on its way to completion.
      • PAP 11 - Plugin Electric Vehicles - Sandy Bacik
        2 of 3 standards were OKed by CSWG.  Modifications of the last have been propsed to the PAP and updates are in process
      • PAP 15 - Harmonize PLC coexistance - Mike Coop
        Does not appear to have security implications on broadband, since it only deals with how devices avoid crippling each other.  (Could defeating that ability create a security risk?)
      • Narrowband will be a complete spec, which will have security implications
      • PAP 17 - Intrafacility data - Your humble author
        PAP 17 does not appear at this time to have security implications, as it is addressing strictly identifying what data expressions are needed for energy management.
      • Status Report on other PAPs from Frances Cleveland
        • PAP 3 pricing model is progressing
        • PAP 7 storage is likely to have security issues to address, since it is a complete physical and communications spec,
        • PAP 14 Synchrophasors
          Unlikely at this point that the PAP has yet addressed, or will address without CSCTG prompting, needed security issues.
        • PAP 16 Wind Plant
          In effect IEC 61850 (distribution substation management) for wind.  Security aspects identical to regular 61850.
    • Evening session Discussion of Smart Energy Profile 2.0 and how it relates to PAPs 3 & 4
      • SEP 2.0 is a collection of architectures and standards at the application layer.  It approaches the issues using a series of "Function Sets" such as Pricing, PEV, firmware, etc..
      • Uses TLS security, plus whatever link layer security (same as https:// addresses)
      • Certificates based on Elliptical Curve Cypher required, with RSA cypher as an option for interoperability
      • Uses HTTP as application layer in a RESTful manner
        •  (GET, PUT,POST, DELETE)  Using well-known protocol.
        • Essentially, the techniques that makes web pages like this one work.
      • Uses mDNS - multicast DNS  No DNS server needed.
      • Incorporates DMS discovery via DNS-SD
      • EXI - Tokenized XML
      • Uses CIM as its semantic model.
      • Boil it all down, SEP 2.0 is  a repackaging of existing internet tools into a hierarchy that tries to address the needs of Smart Grid communication.  While it may be fine for interaction with the consumer (i.e. web pages displaying energy usage and pricing), it seems to me that the use of TLS (which has been broken) as a security platform for more critical needs creates a security risk that ECC and RSA are not strong enough to overcome.
    That's it for today.  My brain is full...