Addressing the challenges of smart utility meter design

Adoption of Smart Utility Meters has thrown open a plethora of opportunities for companies and engineers to come up with metering solutions which could comply with the evolving global norms, have the potential to serve and adapt to future demands and could be part of a mass-appeal solution i.e. low costs solution. However, it has also thrown open a Pandora-box of challenges which lie in the path of achieving a successful metering solution.

Many a time, a designer working on a metering chip might not be even aware of the challenges and the demands of the metering solutions. In such a case, he/she is very prone to faltering in the design, making the product unsuitable for the end-solution due to a minor fault in the design.

This article aims to highlight some of the major issues of metering SoC (System on Chip) design and also propose some possible solutions to achieve the intended goals. It also aims to make the SoC designer aware of the challenges beforehand so that he/she could attack them head-on and an effective solution can be rolled out.

Challenge #1:  Accuracy

Accuracy is the key to success in metering applications as no services provider would go for a meter which is not able to give accurate reading of the consumption. This gains more importance for energy meter applications as they are heavily dependent on the analog on-chip components than their gas/water/flow counterparts. Generally, energy meters make use of on-chip ADCs (Analog to Digital Converters) to measure the current and voltages levels (as off-chip ADCs would only increase the price of the end-solution). On the other hand, gas/flow meters use off-chip sensors to sense the rate of flow of fluid/gas.

These sensors can give digital output in the form of a train of pulses, directly proportional to the rate of flow. As these sensors generally have more of a digital interface, the overall accuracy depends very less on the SoC (System on Chip) and more on the external sensor.

On the other hand, in case of energy metering, the accuracy depends on two things — how the power-lines are interfaced with the meter (using transformers, sensors, Rogowski coil, etc) and how accurately voltages and currents are measured by on-chip AFE (Analog Front End).

Therefore, for gas/water/flow meter, accuracy is largely a function of the accuracy of the sensor interfaced. And for an energy meter, accuracy is dependent upon two factors – AFE of the SoC and the off-chip analog interface of the SoC. Now let’s consider each of them one by one.

Analog Front End (AFE). From a customer perspective, accuracy of the AFE is the most important factor. And very often, it is the results of the ADC that decide the salability of the SoC.

The accuracy of the analog system depends majorly on the choice of the ADC. Sigma-delta (SD) and Successive Approximation (SAR) are two most commonly used ADCs in metering applications. Both the ADCs have their own advantages and disadvantages.

SAR ADCs make use of the successive approximation algorithm and Sigma-Delta ADCs use over-sampling technique to sample the input and do the conversion. SAR ADCs are very well suited for applications which are power-sensitive.

However, their performance might not sustain in very noisy environment. Therefore, depending upon the performance of the ADC and the use-case-environment, one may use Low Pass Filters at the input of the ADCs to filter out the noise. Also, they have low settling time – time which an ADC require to stabilize to give accurate conversion value – as compared to SD ADCs.

Therefore, SAR ADCs are more preferable for applications that require faster switching of the input channels which also results in faster changes of the input level. SD ADCs require very high frequency clocks to reduce this settling time. Therefore, this results in the overall increase of the final cost of the solution and the power consumption.

Load-Line Interface. EnergyConsumption calculation involves various multiplications and additions of currents and voltage quantities. Determination of the input load voltage is not a major issue; however, determination of the current consumption does pose challenges .

Whole of the current being consumed by the house/industry/building cannot be fed to the chip. Instead, a proportional quantity (current or voltage) is determined which is fed to the AFE and then measured using the ADC.

The scaling factor of the current and voltage measurements is maintained so that appropriate calculations could be done. One limitation of this ‘current measurement’ process is the availability of the low-cost ADCs which can measure currents directly.

Instead, this current is converted into a corresponding voltage, using a known load resistance, and then this voltage is measured by the ADC which corresponds to the actual current consumption. This provides a more viable low cost solution for the current measurement process.There are various techniques available for the current measurement. Some of the most widely used techniques are – Shunt resistor, Rogowski Coils, Current transformers .

The Shunt Resistor technique uses a small (shunt) resister placed in the path of the load-current. When load current flows through this resistance, a small voltage drop is developed across it. This voltage drop is fed as an input to the AFE which measures the corresponding current consumption.

The Current transformer (CT) approach works the same way a normal transformer works where the magnetic flux of the load current (current consumed) generates a small amount of current in the secondary coil of CT. Then this current is passed through a load resistance to convert it into a corresponding voltage which in turn is fed to the AFE of the MCU.

The Rogowski Coil is another method (Figure 1, below ) used for the measurement of the current. This class of coils gives very good results even for highly varying currents. However, they give output in the time differentiated form. That is why one needs to have an integrator to get the corresponding current value.

Figure 1. Rogowski coil arrangement (Source

Comparing all the above mentioned three modes,Shunt Resistor technique is the cheapest of all; however, it has severe limitations in the high current measurements and also suffers from DC offset issues. Current Transformers (CT) can measure more currents than their shunt resistor counterparts, however, they have their own issues associated with them — they cost more, suffer from Saturation, Hysteresis and DC/High current saturation problems, etc.

On the other hand, Rogowski coils, third alternative, are not as expansive as CTs and offer very good linearity over a large range of currents, do not have Saturation, Hysteresis or DC/High current saturation problems associated with them.

However, they cost little more than the shunt resistors.Given the types of current variations and consumption, Shunt Resistor technique is primarily employed in consumer/residential applications and Rogowski coils are more popular with the industrial applications.

Challenge #2: Current Consumption

Current consumption of the SoC is a prime factor governing the battery-life of the application/solution. Therefore, applications running in battery-only-mode require their SoCs to be of very low-current consumption. Gas/Flow Meters are not directly interfaced with any power-supply.

So, they need to be run on battery supply only. This makes these applications more current-sensitive than their energy meter counterparts. This gains more importance because the average age of the meters is approximately 15 years and the customers do not want to change the battery every few years.

As a result,, Gas/Flow Meter applications are more sensitive to these constraints than their Energy Meter counterparts. In a typical gas/flow meter solution, the meter stays most of the time in low power states. It wakes up at a regular interval to calculate the consumption, store this value, maybe reset the counters counting the pulses, etc.

Also, consumption patterns of gas/water/heat are very different from that of energy as they are not used 24X7 like energy. Therefore, core does not have to be always powered-up. Therefore, the ‘low-power mode currents’ play a very vital role in that. A number of companies claim of the low-power mode currents of the range of 1.1 µA- 2 µA (sleep mode standby current).

Another area of concern is the booting time of the SoC and the associated current consumption. As the applications require meter to be woken up at a regular interval, the booting time and booting current play a very vital role. It is for this reason that the core used in such SoCs is of utmost importance besides other factors like processing speed, etc.

Challenge #3: Security, Protection and Detection

The level of security, tamper protection and detection is determined mainly by the complexity of the end-application. This requirement may be as simple as ability to detect tamper-attempt if someone tries to open the case of the meter or tries to gain unauthorized access of the SoC to alter the billing software.

Or alternatively, it may be as complex as making an Ethernet network connected meter unhackable or securing consumer-data of a meter which is part of the GPRS/CDMA/ZigBee networked solution. These requirements may vary to an unimaginable extent because of the various types of the solutions metering can or should be able to support.

For stand-alone solutions, where the meter is not part of a network-enabled metering solution and meter-reading collection and bill-generation is done manually, the requirements are very low as hacking of a meter-node will not affect rest of the meters. Therefore, services provider might be happy with simple detection schemes illustrated earlier.

The detection of meter-case opening can be done by establishing a current path between meter window and casing. Whenever an attempt is made to open the box, this flow of current would be broken and the same can be registered as a tamper attempt.

Or unauthorized attempt to reprogram the SoC can be prevented by protecting the internal registers of the SoC with password. Unless one has a correct password, re-programming cannot be done and any such failure attempt can be shown as a tamper attempt.

For network-enabled solutions, the security concerns are not allayed just by detection or simple password protection. One needs to have more stringent protection because the meter is part of a network and one hacked node (meter) may make whole of the network vulnerable to hackers.

In such cases, the security is divided between software and hardware layers and these two levels are further divided into multiple layers. A number of protocols like EN13757, HomePlug, ISA100.11a, ANSI/EIA/CEA-709.1-B-2000 and EN 14908, etc, have been devised to allay all such apprehensions and fears.

The revolution in the metering is largely due to the advances in the modes of communication that a Smart Meter can support. And it is this communication only that demands special attention from security point of view. A meter/meter-network is most prone to hacking only via one of these modes of communication.

Consider the example of smart card based pre-paid metering. Such a solution makes use of SPI (Serial Peripheral Interface) to transmit the data between the Smart Card and the Meter MCU. The card would carry the amount in its internal memory and when inserted into the meter, the meter would keep deducting the amount based upon the consumption.

A simple hacking attempt could be to either reprogram the smart card or duplicate the card. In such a case, one way to protect against any such tampering would be to encrypt the data stored in the card, like authenticity-data and amount. The meter would first decrypt the data and then process based upon the same.

While writing back the data on the Smart Card, the same encryption process would be followed, also. This way, the meter would stay secured till the time the encryption algorithm and encryption key are not disclosed. As a matter of fact, encryption is used in almost all the metering solutions, regardless of the mode of communication, so that the security is not compromised.

The type and complexity of encryption is mainly dependent upon the type of communication protocol used. Communication protocols like GPS/GPRS/CDMA, Ethernet, etc require even more complex encryption. Because of that, special hardware is also employed so that software dependency is reduced at the same time performance of the chip is improved by reducing the core overhead.

Challenge #4: On the Fly Software Updates

Due to the heavy costs involved in the replacement of the meters, services provider companies want to use the same meter for a span which extends beyond one decade and can go up to 15 years. Therefore, the designers have to design the SoCs in such way that their hardware could meet future demands, like change in the tariff plan, introduction of the Time of Day metering, change of day light saving time, etc, without any replacement of meter and without any interruption of services to the consumer.

This requirement poses two challenges to the designers – First, how the SoCs allow software upgrades while the meter is functional and, second, seamless switching to new firmware such that changes do not cause any services interruption to the consumer.

This first step is to ensure a way to transfer the patch from an external source to the SoC without any requirement of actually switching off the supply or the meter. The second step of the process is to boot using this patch without actually switching off the system, so that new firmware could come into effect.

The mode of transfer of data from an external loader to the SoC can, although, differ from SoC to SoC based upon the sophistication and smartness of the SoC. A basic utility meter SoC might not have any flashy peripheral like GPRS or Ethernet.

In such a case, simple peripherals like SCI (Serial Communication Interface), SPI (Serial Peripheral Interface) or I2C (Inter IC Communication) can be used to transfer the data (patch) from an external source to the SoC. However, this involves involvement of the core as core would have to read the data registers of the peripherals and then do the flash-write operation.

This requirement can be minimized by having peripherals that can establish a direct interface between the memory and the external world, bypassing the core. This way, the core would be free to do other tasks while new software is being loaded into the memory. DMA can be used easily to transfer the data to the memories without any core intervention.

However, all the approaches discussed above suffer from one major setback – the updation process is largely manual as one would have to manually connect the firmware-loader with the SPI, SCI or USB. This can increase the cost of firmware updation.

The same can be done more efficiently by the use of advanced communication modes like ZigBee transceivers, GPRS/GSM/CDMA, Ethernet, PLC, etc. In the case of ZigBee transceivers, a handheld device would establish a wireless-contact with the meter, establish its authenticity and then do the data transfer. This would not remove the manual-requirement but would reduce it a lot by speeding up the whole operation.

Other modes like Ethernet, GPRS/GSM/CDMA, PLC, etc do not require any manual intervention at all. The central servers of the services provider would be instructed to transfer the software code to the SoCs and the network-setup would do the same on this instruction. The SoC would be programmed to save such a received data in its internal memory and then a software reset would initiate the software updation.

Next part of the problem statement is the execution of the core from this code without switching off the system. The architecture can support boot-option programming where the SoC can be programmed to boot from another specified location from next low-power or software generated reset. The architecture can also be made to have an option to boot from RAM, so that the new code could be saved into the RAM and then on next reset/low-power mode recovery, system would boot from RAM, instead of flash and then new updates would come into effect [3].

Challenge #5: Data Processing

With the introduction of more and more features into the system/solution, the tasks to be controlled and data to be processed by the meter has also increased to a greater extent. Therefore, depending upon the applications and the load on the core of the SoC, the designer may decide to move to 32-bit cores or may employ powerful DSP (Digital Signal Processing) cores so that the applications (communications, etc) and the metering parts do not hamper each other.

One may also off-load the calculation part of the core by employing an additional hardware in the SoC which would be responsible for the various calculations part only, as the metering applications are highly calculations intensive.

Data Concentrators and Metering-Gateways are affected the most by the data-processing capabilities of the system as they need to handle a large amount of data. Also, they need to support the user-interface, which further increases the associated data-handling complexities and corresponding requirements. Therefore, one might see introduction of multi-core SoCs to support huge networks.

Challenge #6. Faster, reliable Communication

Measurement of the consumption is just one part of the problem statement (Figure 2, below ). Till now, most of the meters worldwide require manual meter-reading. This is because of the incapability of the conventional meters to support any networked solution. This manual-meter-reading has not only increased the operational cost but also introduced human-induced errors into the system.


Figure 2: Simplified Diagram of Various Meter Networking Options for a Solution.

Thus, for an effective solution, the meter should also possess capabilities to support networked solutions and transmit this data to the meter network so that automatic meter reading could be achieved. One major issue with energy-meter-reading transmission is the presence of the electrical noise.

Therefore, the communication mode should be able to withstand the noise without corrupting the data. That is why, the meter should be able to generate output in a format which supports error detection and removal so that data could be recovered from the receive packet even if distorted due to noise. Also, all such encryptions increase the size of the data to be transmitted.

As a result, speed of data transfer also plays a major role here. There are a number of modes of data transmission used, nowadays. Most common among them are GPRS, Ethernet, Power Line Communication, ZigBee, Infrared transceivers, etc.

The communication mode is chosen depending upon the end-application, like ZigBee/IR (Infrared) transceiver might be more apt for a network of meter where meters interact  with a base station wirelessly to transmit data to it which then sends data collected from many meters, say 100 meters in a complex, to the central station using wired communication. More on this can be captured from the article “ “Architecting” the New Age Smart Utility Meters” [1].


Nowadays, metering is evolving at such a pace that designers will have to gear-up to foresee the issues and challenges that would come in the way. Unless the designers are proactive towards the issues and challenges, we would not be able to deliver a product which would be capable of not just delivering the needs of future but also shape the way we would see this world. A huge challenge lies in delivering a single-chip solution which could target above mentioned issues and many more others. Issues listed above are not just the end of this story, this is just the beginning.


1.” Architecting” the New Age Smart Utility Meters by Sunil Deep Maheshwari,

2. Getting basic utility meter designs ready for the Smart Grid by Sunil Deep Maheshwari,

3. MCF51EM256 Reference Manual & Datasheet

4. Analog to Digital Convertors

5. Metering Solutions from Freescale.

Sunil Deep Maheshwari has worked as a Design Engineer at Freescale Semiconductor, Inc. for nearly three years. He has worked on architectures ranging from Digital Signal Controller, Power Train to Metering. He earned his Bachelor in Engineering in Electronics and Communications from NSIT, Delhi University, India. He can be reached at

Prashant Bhargava is a Design Lead in Freescale Semiconductors and has worked in Design & Architecture of microcontrollers for different applications like VoIP, Display Controllers and Utility Metering. He holds a Bachelor of Engineering degree in Electronics & Communication from Punjab Engineering College, Chandigarh, India. He can be reached at:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.