Monday, 28 March 2011

Is a wired meter solution feasible for selected PG&E customers?

There has been a lot of discussion in recent days over PG&E's response to a CPUC order to allow consumers to opt out of using wireless metering.  The remaining options involve going back to human based meter reading with all of its historical issues of cost and potential for incorrect or missed reads as well as the worker safety issue.  Another option floated is to use a wired option.  Of course a wired option (low speed Power Line Carrier - PLC) is what PG&E initially proposed prior to their wireless solution but that technology proved to be incapable of meeting the applications requirements necessary to support regulatory policy objectives (e.g. secure firmware update capability,  large payload delivery for pervasive consumer targeted demand response program deployment, distribution management applications, etc.).  PG&E correctly points out that integrating a nearly obsolete PLC based wired option with a modern wireless infrastructure would be costly since it requires equipment at each substation even if only one customer was served.  

Piggy backing on other wired infrastructure is equally problematic.  Plain Old Telephone System (POTS) connections are very difficult to scale.  They work well for low volume commercial and industrial applications, but the software applications that manage those systems are designed for relatively small numbers of meters and difficult to scale.  Also, POTS is a dying technology – being replaced rapidly by cellular wireless phones in dramatically increasing numbers – technology which has far higher RF emissions than a radio connected electric or gas meter.  POTS physical infrastructure is also the delivery mechanism used for DSL Internet access – a much more robust use of POTS infrastructure with high bandwidth.  Using it or other wired broadband connection (cable TV) would require meters that support that technology which presently are not readily available for residential applications.  Even if that hurdle were solved, the cost of those interfaces would be significantly higher than other communications interface technologies.  Even if the cost issue could be addressed, there is a problem with the utility ceding responsibility for managing their meter data collection network to a third party (a broadband internet provider).  Regulations, technical standards,  security and policies would have to be established to allow a third party to take responsibility for that traffic being carried over the Internet rather than over a secure connection.  Some would argue that the utility already uses public infrastructure for backhaul purposes, but these connections have well established Service Level Agreements (SLA's), aggregate data from many meters, and are secured at the aggregating access point interface.

As is usually the case, a simple, one size fits all answer is not feasible.  Systems that must scale to millions of devices such as a metering network must be designed using a disciplined, systems engineering based process that takes into account numerous interactions.  Unfortunately most people – even many very good engineers – are not systems thinkers and tend to promote siloed solutions without thinking through all of the ripple effects of other system interactions let alone the business, security, and policy implications – let alone analyzing all of that across the additional dimension of time for complete system lifecycle management.  Large systems work best when they use homogeneous, standards based technologies that can be readily duplicated with few if any special cases or human interactions.  Special cases of course will always exist – but they have a cost.  And that cost can't be compared to how things may have been done in the past since the systems that allowed the old technology to scale are no longer available.

For all of these reasons, I think PG&E has made a reasonable response – at least technically.  I don't have enough information to comment on the details of the cost of managing the exceptions but based on my experience in managing other projects involving data gathering and special exception handling, the cost multipliers seem to be at least in the ballpark.  Special handling is always expensive.  Think about the multiplier associated with making an operator assisted or collect call – it is much more expensive to handle than the fully automated approach using the best available technology.