Electronic Engineering Journal’s Bryon Moyer offers his take on metering solutions in a recent story, Freescale In Your Smart Meter. He raises an interesting point: Three different MCUs for your smart meter. Why not just one?


It comes down to advantages. Utility companies and meter manufacturers win the functionality and economic performance game by splitting the metrology functionality from the communication functionality – and further splitting the communication of the Home Area Network (HAN) from the Neighborhood Area Network (NAN).


Let’s look at the metrology MCU first. Most meter manufacturers throughout the world are moving away from “old school” mechanical meters to solid-state meters that boast higher accuracy and reliability (i.e. your “old school” meter running backwards). So, if you concede that the metrology MCU is valuable from that standpoint, we at least have one MCU in the system and it happens to be the one that actually makes the meter a meter. The question then becomes, why the other two?


For this discussion, let’s assume that the utilities and governments of the world are correct: There is incremental value in connecting a meter to the utility through a NAN network. Furthermore, there is even more incremental value in sending pricing and load shedding signals into the home. Given that both of these functions add value, the first thing to consider is that NAN (outward) and HAN (inward) communications require radios and an MCU to run the communication stack of these radios. Since the inward communication tends to have different requirements than the outward communications, these two radios tend to be completely different frequency bands and communication standards. That means different physical radios that require different physical pieces of radio silicon.


One alternative at this point would be to run both of the communication stacks needed for those radios on the metrology MCU, thereby allowing you one MCU plus two cheaper transceivers. In the last two years, I have asked the top tier meter manufacturers if that would be an option that they would like to see from Freescale. They have all said no. Turns out they all had a consistent reason why they did not want to put communication stacks on the metrology MCU. The first is that they have to certify the metrology code and libraries they have on metrology MCU when they certify their meters through whatever government body certifies a billable meter in a particular country or world area. Once that metrology code is certified, it cannot be changed without triggering re-certification. Communication code tends to evolve very rapidly and therefore most, if not all, meter manufacturers have decided to keep their certified metrology code in a separate MCU. Although there are fancy software and hardware mechanisms within today’s sophisticated micros to segregate code, meter manufacturers in general prefer to keep the metrology code physically separated so they don’t have to worry about it. Another reason is that many manufacturers do not want to merge the communication stacks with the metrology MCU because they may be only selling the metrology board in the meter and the casing to the utility, and not the NAN communication. Because of legacy communications or preferences, the utility may insist on another manufacturer’s communication module for the NAN. If they tied the metrology portion of their meter directly to their NAN communication, they would effectively kill these types of opportunities. Another reason is that the conversion to smart meters around the world is at different stages of sophistication. For instance, smart meters in the US and Europe are deploying with both NAN and HAN communications, but, in places like Brazil and India, they are deploying only with NAN connectivity. In some other world areas, not even NAN communications are being implemented. So you can see that if you are a meter manufacturer trying to design a metrology board for the world, you would want to make it a standalone metrology design that could add connectivity in a very modular fashion.


So, now we are up to at least two MCUs and two radios: One MCU for the metrology, one MCU for the communication stacks and two radio transceivers. Here it gets a bit fuzzier.


With today’s processors with 1M of flash and 128K of SRAM at a fairly economical price point, it is certainly technically possible to run both a NAN and HAN communication stack in the same processor. Is this where we could stop? No, there are other factors. One is that the NAN communication stacks are growing steadily because of the increase in standard and security requirements and so are the HAN communication stacks. So, maybe a 1M flash processor is not enough to be future proof. Also, there is still the case where the HAN side of the communication is not needed or wanted by the utility. If you sized your NAN MCU to cover the HAN stack requirements, you are now not as price competitive. Therefore, the need for a third separate MCU for the HAN communications stack arises. So there, you have it: Three MCUs and two transceivers. (Granted,  there is no reason why the HAN and NAN MCUs cannot be combined into the same package with their corresponding transceivers.)


So, in summary, there is actual functional and economical value to the meter manufacturer and ultimately the utility and the consumer, to separate the metrology, NAN, and HAN functionality into separate processors. And to answer your question “Are we getting value for the increase in complexity?” Why, yes you are!