Addressing the challenges of smart utility meter design
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.
Loading comments... Write a comment