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