Smart Grid: Meter Deployment Strategies

When deploying smart meters, experience has taught that we need to adhere to a few first principles of engineering design in order for the solution to be effective and maximize the performance of the meter mesh cluster.

Some of the basic learning from past smart meter deployment projects, specifically used in AMI (Advanced Metering Infrastructure) projects provides Utilities with knowledge that can be leveraged for future projects.

You likely already know them, but you may have gotten caught on use of the terminology. One important point about smart meters is the various terms used to describe the same devices in these systems. So, it is helpful to understand these terms in order to communicate effectively.

In a typical smart meter network found in the USA, a cluster of meters (nodes) communicate to a concentrator (aka Regional Controller or just Controller; sometimes referred to as a “take-out point” too). The terms vary by vendor and Utility.

While vendors make many claims for the scale of the “meter to concentrator” ratio, the typical sizing for this mesh network has been 400 meters to each concentrator. Some vendors like Sensus can go as high as 15,000:1, but they are unique in the meter topology world and make use of a narrowband, low data rate (6 kbps) point-to-multipoint (P2MP) or star network and not a mesh. Others like Elster, iTron, Silver Spring Networks and Landis+Gyr can offer a mesh (100 kbps to 200 kbps) with much higher ratios in the range of 1000:1, 2000:1 or even 5000:1, but they typically employ closed architecture, propriety solutions that lock Utilities into the one vendor. Open architecture, standards based networks under the Wi-SUN model are beginning to emerge. In addition, these vendors are citing the theoretical maximum aggregation ratios and do not reflect the practical or realistic world that we operate within. So, we make some decisions as follows:

• Let’s assume that our meter vendor can support a ratio of 1000:1 meters to concentrator
• No technology in any industry can operate stability at maximum performance – i.e.: we do not drive our cars at their top speed although we could in sort bursts
• So, we look for the sweet spot whereby the technology can deliver a sustainable rate for the ratio, it is typically between 65% and 85% of the maximum ratio, so let’s use 80% or 800 meters for our example
• However, we need to consider what might happen should the concentrator fail. All of the meters would try to fail-over to a second neighbouring concentrator and if they are all running at 80% capacity, then the fail-over would not work
• So, we cut the ratio down by a further 50% to permit fail-over. Our 80% or 800 meters would be further reduced to 40% or 400 meters, thus the 400:1 ratio that is commonly used
• It needs to be noted that some vendors are now able to deliver credible ratios nearing 2,000:1 so instead of a net ratio of 400:1 we might realize a valid level of performance at 800:1 or even higher
• As technology and standards advance, these ratios should improve, the downside is the loss of data rate per hop and the latency per hop

Therefore, the second core design principle with superior smart meter network design relates to performance on a per hop basis, in most cases that is for mesh architectures. But, a star architecture and a cluster tree architecture are also valid design approaches and each of the three architectures have performance pros and cons.

• Most vendors used special mesh solutions that vary in latency per hop. Most of the listed vendors can hop in the range of 0.100 to 1.000 seconds. They also will tolerate a mesh hop count of 7, 8, or even 9 hops maximum. Some say the number of hops is unlimited, but that is not realistic as the performance suffers with each hop. So, if it is a case of a vendor with 1 second per hop, and an 8 hop count, it could take up to 8 seconds total for the meter data to just reach the concentrator. One vendor in the list is vary fast, perhaps 200 ms per hop so a 7 hop scenario would delay the traffic with a worse case meter to the concentrator scenario of just 1.4 seconds total, and this vendor is consider a high speed performer. So, real-time is not likely achievable with smart meter networks
• In order to mitigate meter hop latency we try to force the meter clusters to reduce the hop count to 3 or 4 hops. This helps the latency but reduces the meter to concentrator ratio making our clusters even smaller, so even companies that brag about 2000;1 or 3000:1 ratios get reduced to 400:1 or 600:1 if we desire lower latency in the clusters
• Please bear in mind that we connect the FAN mesh or the WiMAX P2MP to the concentrator and not to every meter, therefore we need to consider the middle mile traffic flows at the concentrator
• As well, even though each meter may snapshot a meter read at specific intervals, such as the top of every hour (24 reads per day) or every 15 minutes (96 reads per day) we do not ship the reads back as they are read, normally they are bundled, compressed and otherwise optimized to ship to the data center once per day between 12:00 am and 5:00 am. Some Utilities now want greater frequency of the bulk delivery and so we are seeing a few Utilities move to 4, 6, 8 or 12 shipments per day. even at the rate of 12 per day, that means traffic is sent from the concentrator to the data center just every two hours
• Even when we ship the data bundles more than once per day, different vendors ship a rolling 24 hour window and others ship the reads since the last delivery (changes only)
• If interval meters are considered, then 15 minute (96) intervals or 5 minute intervals (288) reads are often required, so the need for real-time transport or many smaller deliveries is necessary. This traffic seriously affects the network capacity and needs to be understood well so it can be managed

Now, all of this discussion is for meter reads, we do other tasks with meter data as well. The third core design principle for smart meters is related to application integration.

• We use the meters as conduits for DSM (demand side management) which includes the more popular term DR (demand response) which is the name we use for load shedding activities which is reactive or preventative methods to reduce, flatten or shift peak demand with the customers by turning off power hungry devices like pool pumps, spa (Jacuzzi) pumps, deep freezers, heating systems, cooling systems, clothes dryers and more. In DSM applications, we send a trigger command to the DR participants (typically just 10% of all residential meters) and start a watchdog timer that will reactive the appliance after a short interval of shut-down time, normally just 15 or 30 minutes
• With DVO (distribution voltage optimization) we desire to use the smart meters as sources of telemetry to provide information back upstream to a controller regarding voltage, amperage, power factor, and load requirements so we can drive the voltage so as to optimize it for the demand. In the case of DVO, the system will make requests of the meters to provide power quality data to the substation installed DVO controller. The localized transmission of these power quality reads can be intense, as much as 100s of times per second. So, can the network manage this demand? From the substation to the network operations centre, the aggregation messages can be delivered within a 2 second polling window for a centralized architecture. The true intelligence for this sort of application is pushed out to the edge of the power grid so the centralized aspect is more for orchestration than real-time management and telemetry
• There are a few other roles that come into play in the smart meter traffic modelling discussion, such as prepaid meters, solar power controllers, net meters for DG (distributed generation) scenarios, electric vehicle charging and energy storage solutions, etc. These are all complex requirements and inclusion of the step-down transformers connecting the residential drops / laterals may also need to be a key element within the smart meter solution
• At this stage in the maturity of the smart meter network designs, we still need to separate the discussion between residential meters and C&I (corporate and industrial) meters too, as they are treated differently within the same network topology. However, in the future, it may be achievable to keep them all on the same shared network fabric end to end
• Street light automation is gaining in popularity too, and these street lights may become instrumental in developing smart meter communication networks as they can further enhance hop connections and act as strategically located intermediaries for the network topology. The traffic flows and the data demands for street lights are easily managed so they look to be a good partner to include in the smart meter network at this time

Finally, the fourth design principle for smart meters is about the smart home or HAN (home area network) aka HEMS (home energy management system) and for the most part, this topic area is popular with techno-geeks like me, as smart homes have largely failed to gain meaningful traction in the broader consumer marketplace. However, we may be seeing a tipping point for this application with a renewed interest spawned by Google when they purchased NEST for $3.2 BILLION. While I am still struggling to reconcile this Google strategy due to the price paid for this company that makes thermostats, we can not afford to ignore the smart home just because no one has been able to make it work yet from a business case perspective. Once true value is calculated and the expense can be justified for the smart home, it might gain market demand and take off. So, we shall assume that Google is a very smart company and has a grand plan that we mere mortals, less intelligent humans, can not yet comprehend. Can it really be all about consumer profiling, profile integration with web searches, and general data harvesting? Who knows, time will tell, but they may indeed be on to something here.

————-MJM————-

Michael Martin has more than 35 years of experience in broadband networks, optical fibre, wireless and digital communications technologies. He is a Senior Executive Consultant with IBM’s Global Center of Excellence for Energy and Utilities. He was previously a founding partner and President of MICAN Communications and earlier was President of Comlink Systems Limited and Ensat Broadcast Services, Inc., both divisions of Cygnal Technologies Corporation. He holds three Masters level degrees, in business (MBA), communication (MA), and education (MEd). As well, he has diplomas and certifications in business, computer programming, internetworking, project management, media, photography, and communication technology.