For the PDF version of this article, click here.
A quiet revolution is in progress in the utility industry. Electromechanical metering devices, in use for the better part of a century to record electrical energy usage in kilowatt hours, are gradually being replaced by multirate, multifunction meters capable of more accurately accounting for utility usage. A new generation of microcontrollers is speeding the progress of this revolution.
In 1885, Galileo Ferraris discovered that a solid armature placed in an out-of-phase ac magnetic field would rotate at a rate proportional to the flow of electrical energy in the coils that generated the field. This discovery is the principle on which the great majority of electric meters still operate today.
In the typical meter, a solid armature is mounted on jeweled bearings and allowed to rotate freely in a sealed container. Coils apply the ac magnetic field proportional to the amount of power flowing through the meter, and a counter detects the number of revolutions made by the disk.
While a century of refinement has made the kilowatt-hour meter one of the most reliable mechanical products in wide production, it remains a mechanical device prone to wear, shock and other events that affect anything with moving parts. Another limitation is that the meter, as usually deployed, maintains no record of the time when usage occurred. The meter only counts revolutions of the wheel and does not record the times when the wheel is moving faster or slower.
It is useful to know when electric power is consumed, because the demand placed on the electric utility is not constant over time. In fact, much more power is used during waking hours than overnight. Utilities must design their delivery systems to meet demand in the “peak hour.” This means that for all other times, generators will be operating at less than peak capacity; and since electricity can't be stored, an expensive capital resource is being partially wasted.
For this reason, electric utility providers have an interest in encouraging energy conservation during peak periods and consumption during off-peak periods. The best way to do this is through selective pricing; that is, charging the customer more for energy consumed during peak periods and providing a discount during slack periods. This is a function of which static kilowatt-hour meters are incapable.
A third limitation of traditional meters is that they measure only real power. In an ideal world, measuring real power is all that would be necessary — current and voltage would flow in phase. However, devices such as induction motors and fluorescent lamp ballasts cause current to flow out of phase with the applied voltage. Only the in-phase component is usable as power, the remainder is reflected back into the power grid. As a result, fewer actual watts are used compared to the number of volt-amperes delivered.
For large industrial customers, electric utilities have long used VAR-hour meters to determine the amount of out-of-phase or reactive power delivered to the customer. With a multifunction meter, utilities can extend power factor monitoring to smaller commercial customers and, in some cases, to residences. By making multifunction meters standard, a utility can more easily determine where contract terms may need to be adjusted to include power factor penalty language.
Finally, there is the question of reading the meter and transferring the collected usage data to the billing department. Sending personnel into the field to record usage is expensive and prone to human error. Add the complexity of having to record usage during several tariff periods, and the burden becomes unacceptable. Some form of automated reading is needed.
The requirements for increased flexibility in measuring usage by time and power factor, improved reading speed and accuracy, combined with the expectation of reliability long provided by mechanical meters, suggests the need for an all-electronic meter built around a microcontroller. In fact, electric meter manufacturers since the early 1990s have been producing meters that measure usage electronically and use digital circuits to accumulate and display energy. Now a new generation of microcontrollers are making the design task easier and faster.
The hardware components of a multirate, multifunction meter are simple: a means of taking samples of the input voltage and current through the meter, a display mechanism, a communications subsystem, a nonvolatile memory, a power supply, and a stored-program microcontroller to keep everything in step. The good news for meter designers is that many of these components can be found integrated on the microcontroller itself.
For example, the MAXQ3120 from Dallas Semiconductor/Maxim, headquartered in Dallas, integrates two 16-bit A/D converters for the voltage and current channels, two UARTS (one configured for IR communication), an LCD controller and a 16 × 16 multiply-accumulate unit on a single die, with sufficient data RAM and program flash to provide all the functions mentioned above for a multirate, multifunction electric meter.
Designing the operating software for such a meter is more challenging. First, since the software defines the fundamental behavior of the product, it will of necessity be different for each locale. Second, even if designed in a high-level language (like C), the software will have to be customized for the particular hardware environment in which it will run.
The relative simplicity of the hardware for an electric meter as compared to its operating software actually provides an opportunity for the electric meter manufacturer: since loading the operating software can be a late-stage operation, it is possible to build and stock many base circuit boards for an electric meter, customizing them with individual software loads as they are ordered by the various electric utilities. This is important since overall product cost may well be the make-or-break factor in selling the product to an end customer. Dallas Semiconductor/Maxim provides a reference design in C that can be customized and modified to provide any level of functionality needed by the end user.
Since most modern A/D converters are voltage-input devices, measuring the input voltage is easy, in that it is only necessary to scale the voltage on the input to the range (usually from a few tens of millivolts to about 1 V) required by the differential input of the A/D converter. In the reference design, a resistor network divides the input voltage by a factor of 400. The resistor divider converts the line voltage to the -1-V to 1-V range required by the A/D converter (Fig. 1).
On the current side, a current shunt converts the current through the meter to a small, millivolt-level voltage. The voltage across the shunt must be kept small to minimize the power dissipated by the shunt: a 0.5-mΩ shunt will provide only a 20-mV full-scale signal, but will dissipate almost 1 W at 40 A (Fig. 2).
Now it's time to focus on the data converters themselves. At first, the requirements to measure a 50-Hz or 60-Hz signal seem trivial. But on closer inspection, the job is a little tougher. Look at accuracy first: most specifications call for the meter to have 1% accuracy over its entire range — not just full-scale accuracy. The reference design described here has guaranteed accuracy from 1 A to 40 A. To meet this requirement, the meter must successfully resolve current as low as 10 mA, but not saturate until it is measuring more than 40 A — a 4000-to-1 ratio. This means that the data converter can be no less than 12 bits, with a 14-bit or better converter preferable.
What about sample rate? If the fundamental frequency was all that was of concern, then sampling at some rate above the Nyquist frequency (120 Hz for a 60-Hz system) consistent with conservative anti-aliasing filter design would be sufficient. However, most specifications require that the meter accurately measure power containing frequencies as high as the 21st harmonic. In a 60-Hz system, that corresponds to a frequency response of 1260 Hz and a sampling frequency of no less than 2520 Hz. While these specifications are no challenge for modern data converters, they may stretch the capabilities of some of the A/D converters built into many microcontroller devices.
Hardware Design Analysis
The hardware for the reference design is shown in Fig. 3. The entire meter consists of the MAXQ3120 microcontroller, a power supply, a display, an I2C EEPROM, the input sensors and communication peripherals.
The reference design described here uses an LCD as a display element. The advantage is obvious. By using annunciators, the display can indicate anything from energy to voltage to time of day.
The disadvantage of an electronic display is that it shows nothing when the power is off. And while a mechanical counter is inherently nonvolatile, measures must be taken to ensure that the last reading displayed is maintained internally by the meter.
There are simply too many communications schemes in the market today to ever hope to cover every one in an integrated peripheral. It is a reasonable bet, however, that for an inexpensive metering apparatus, it is likely going to be some variant on simple asynchronous serial.
In the reference design for the MAXQ3120, we settled on two serial peripheral channels. The first is based on the EIA-485 standard. In this arrangement, the meters reside on a network that is managed by a PC acting as a central controller. As the PC polls the meters, they respond with data packets that represent usage. The PC can then aggregate and transmit the information to a billing facility.
The second communication channel is an IR transmitter and receiver system based on simple asynchronous protocols. The communications protocol is based on a Chinese electric meter specification, DL/T 645, which specifies an IR physical layer that differs significantly from those found in commonly used standards. For details on physical layer encoding, see Fig. 4. In the transmitter channel, a circuit modulates the output of the UART so that a “0” is transmitted as a 38-kHz signal and a “1” is represented by the absence of the signal. The receiver is implemented in an inexpensive IC that integrates an IR photodiode and a 38-kHz detector. In this way, only the optical components themselves are required to implement a fully functional IR transceiver system.
Power is the simplest block. Since modern micro-controllers are low-power devices, a simple transformer-based linear supply is all that is needed.
In the reference design, the microcontroller is not isolated from the power line; in fact, the system ground is at line voltage. This makes it impossible to directly connect the network to the microcontroller, because equipment on the network would be exposed to line-level voltages. In this design, a separate winding on the transformer provides power to the network transceiver, and the transceiver is optically coupled to the microcontroller, thus preserving isolation.
There are two major contenders for a nonvolatile data store for the reference design: semiconductor EEPROM and ferroelectric RAM (FRAM.) The former is much less expensive, but has relatively long write times — on the order of milliseconds — and, depending on model, is only guaranteed to endure between 10,000 and 1 million write cycles. While this might sound like a large number, consider that the software subsystem would like to update the nonvolatile memory every line cycle. At 50 Hz, that means even the best EEPROM might wear out in as little as 5-½ hours. In practice, a caching subsystem prevents this from happening, but the problem is not trivial.
FRAM solves these problems at a price. A FRAM has a write cycle that takes no longer than a read cycle — a few microseconds, with the bulk of the time being communications overhead — and it has an unlimited endurance. The downside is that it can cost several times an equivalently sized EEPROM.
Choosing a Microcontroller
There are several factors to consider when choosing a microcontroller for an electric meter. Consider the following:
Feature set. Does the microcontroller have the peripherals you will need? Look for an integrated time-of-day clock, serial communication peripherals, timers and counters, IR communication, and a display controller. You will also require some form of signal processing, either on the microcontroller or in an external device.
Code space. If the application will be written in C, plan on between 16 kbytes and 64 kbytes of code space. The reference design presented here fits comfortably in 32 kbytes.
Data space. Make sure your microcontroller has enough data RAM to accommodate your data structures.
Data converters. While many microcontrollers have “data acquisition systems” built onto the die, often they are low speed, low resolution or both. An ideal converter for a Class-1 meter as defined in IEC61036 would have 14-bits or better resolution, and 10-ksps sample rate or better.
Real-time clock. Make sure the clock is trimmable to a half-second-per-month accuracy. If it is not, consider an external oscillator or clock module.
Getting the Software Right
In the reference design, a full, pre-emptive OS was considered and rejected on the grounds that it would be unnecessarily wasteful of resources. While the design does need some degree of multitasking, full pre-emption is not required. Instead, a simple main process was built that calls tasks one after another, and each task is designed to do its work and then relinquish control of the processor after a short time. This main process is called the “task wheel” and performs the work of a simple task scheduler. In this way, every task executes when it must and no task is starved for cycles. See Fig. 5 for an overview of the major software blocks.
In the electric meter design, every task monitors its input conditions to see if there is anything to be done; if not, it simply returns to the task wheel. For some tasks, the input conditions are based on external events. For example, a sample becomes ready at the A/D converter or a character becomes available at one of the serial ports.
For other tasks, the condition is strictly internal: an update to the cumulative energy needs to be made or the display needs to be updated. For these events, the system maintains a set of bits, each of which is set by one task to alert another task that there is a condition that requires its attention. This set of bits is called the “message board.”
In a practical meter design, the data elements to be maintained in storage and the data formats will depend strongly on the communication protocols that are used. The reference design was based on DL/T 645, a Chinese electric meter communication standard. In this standard, usage data, configuration information, and many commandsare transferred to and from the meter using a series of registers. Each register is designated by a four-digit hexadecimal number and contains one piece of information: register 9010 contains information about current usage while register C032 contains the serial number of the meter.
Figure 6 illustrates how a message requesting data from a register would be handled. In the illustration, the request begins as it is received at the serial port manager and flows counterclockwise, activating each task along the way until the requested data is finally transmitted at the serial port manger. Then, acknowledgments flow clockwise, clearing the busy indication at each task until the entire system is ready for the next inbound message.
The following narrative provides more detail on the message passing and processing system:
The message comes in, byte by byte, from the IR receiver module. As each byte comes in, the serial port driver sets a bit in the message board to notify the message checker task of the event.
When notified, the message checker consumes the character from the serial port driver and, if contextually correct, adds the byte to the message queue. The message checker understands message syntax, but does not understand anything about the message payload. When the message has been completely received, the message decoder task is alerted by setting a message board bit.
The message decoder inspects the incoming message and determines that: (1) it is a read command; (2) it is for a valid register; and (3) there is no other condition that would prevent the execution of the command. If all this is true, the register manager is notified via the message board that a register read is required. Note that the message decoder does not at this time clear the notification given by the message checker. Only one message is handled at a time.
The register manager interacts with the EEPROM to retrieve the requested information. When finished, it notifies the message formatter that a register is ready to be transmitted. As in the previous step, it does not clear the message flag set by the message decoder.
The message formatter moves the data just read from the register manager data buffer to the communication buffer. It also sets the message length in the communication buffer before notifying the message builder that a buffer is ready to be transmitted.
The message builder then sends each byte of the message one at a time to the serial port driver. It is also responsible for calculating the message checksum. When the last byte has been sent, it clears the notification bit from the message formatter. On its next turn, the message formatter clears its notification bit from the register manager, and so forth until the message chain is clear.
Every process in the meter works in this way, setting bits in the message board and notifying other tasks of conditions. The primary advantage of using this method is that it requires very little RAM to implement: the entire reference design fits in less than 1/2 kbyte of data RAM. Fully documented source code is available from Dallas Semiconductor/Maxim.
As utilities are increasingly squeezed by generation prices on the one hand and regulatory pressure on the other, they are increasingly seeking ways of enhancing market efficiency. With the new generation of microcontrollers now available, meter manufacturers can deliver the means of more efficient electric power delivery, metering and billing.