METRO POWERMetro Power Academy lessonPlan a project ↗

Electric Metering & AMILesson 6 of 6APPLIED LESSON

Prepayment: credit in the meter, evidence in the log

A prepaid electricity account does not live in the billing system.

READING TIME
13 minutes
OBJECTIVES
3 learning objectives
SELF-CHECK
3 check questions
INTENDED FOR
Utility leaders, metering, ICT, operations, procurement and informed consumers

Educational lesson. Confirm project-specific requirements before application.

Round ANSI-socket smart electricity meter
Product imageNA67 Series ANSI round smart meter

01LEARNING OBJECTIVES

After this lesson, you should be able to:

  1. 01Explain what a prepayment token is and why it works once, on one meter
  2. 02Choose between local token entry and remote token delivery for a given area
  3. 03Specify the customer interface unit, emergency credit and friendly hours as programme decisions, not meter defaults

02EXPLANATION

What is physically and operationally happening?

A prepaid electricity account does not live in the billing system. It lives inside the meter as a credit balance, in energy or currency units, and the meter’s own relay enforces it: when the balance reaches zero the relay opens, and when credit is added it closes. Everything the cooperative builds around prepayment exists to load that balance safely, to protect the customer while it runs down, and to settle disputes from the meter’s own record rather than from memory.

Credit is loaded by a token, a numeric string generated by a vending system under the Standard Transfer Specification (IEC 62055-41 and its companion parts). The vending system encrypts the purchased amount with a key unique to one meter and stamps it with a time reference. The meter decrypts it, checks it against its own key and its record of tokens already used, and adds the credit. A token therefore works on exactly one meter and exactly once. The same mechanism carries management instructions: a key change, a tariff change, a maximum power limit, a clear tamper command. The utility manages the meter with the tool the customer uses to pay for it.

  1. 01

    Vend

    The customer buys credit at an office, an agent, a kiosk or a mobile channel. The vending system generates the token for that meter and records the sale.

    Token issued
  2. 02

    Deliver

    Locally, the token reaches the customer on a receipt or message and is keyed into the meter or its interface unit. Remotely, the head-end system pushes it over the AMI network.

    Local or remote
  3. 03

    Apply

    The meter validates the token, adds the credit, writes the token log entry and reports acceptance or a rejection code on its display or interface unit.

    Accepted or rejected
  4. 04

    Protect

    Staged low-credit warnings, emergency credit and friendly hours govern what happens as the balance falls, under the utility’s policy and the regulator’s rules.

    Policy applied
READING NOTEIllustrative flow. Which paths are available, and which is primary, depends on the meter model, the communications architecture and the vending integration.
TECHNICAL VISUAL · SYSTEM-SPECIFIC MODEL

Two delivery paths for one token

The local path works with an offline meter; the remote path only works while the meter is reachable. A program needs both.

Two ways in, one meterIllustrative flow · sample token

Customer paysAt an office, an agent, a kiosk or on a phone. The vending system generates a 20-digit token for this one meter.

Path A · localWorks with no network at all

Receipt or phoneThe token reaches the customer5918 0264 7731
4402 6180

Keyed inOn the meter keypad or on the interface unit5918 0264 7731
4402 6180

Path B · remoteWorks only while the meter is reachable

Head-end system (HES)Receives the token from the vending system

AMI networkPushes it to the meter. No keypad entry.

The same meterValidates the token once only, and only on this meter, then adds the credit.

Single phase prepaid meter with a keypad on its face
Keypad meter, token keyed on its face
Split prepayment meter for sealed installation
Split meter, sealed away and paired to an interface unit
  • Remote: credit added on arrival
  • Local: credit added after entry

Specify both paths. The local path is the fallback for outages and dead spots; say which one is primary in each area.

As the credit runs downFour settings the cooperative decides
  1. Credit addedThe accepted token raises the balance. On a time-of-use tariff it drains faster at peak hours.
  2. Low credit warningStaged visible and audible warnings on the meter and the interface unit.SetThe warning levels and how many stages
  3. Emergency creditA small negative balance keeps the supply on. The next purchase recovers it.SetThe amount allowed
  4. Friendly hoursNo disconnection during set periods, such as nights, Sundays or holidays, even at zero credit.SetThe hours and the holiday calendar
  5. DisconnectionThe relay opens. Credit added closes it again.SetCustomer notice and reconnection rules

Each setting is a program decision written from the regulator's prepaid service rules and the cooperative's own policy. The meter enforces it; it does not choose it.

04OPTIONAL ENGINEERING DEPTHEngineering reasoning for this learning pathThe same design relationship, checks and evidence apply across every lesson in this path.
DESIGN RELATIONSHIPEnd-to-end success = field exchange × transport × platform processing × downstream acceptance
  • Define the eligible population and time window
  • Measure the result at the utility-use boundary
  • Preserve identity, timestamp, status and acknowledgement
ENGINEERING CHECKS FOR THIS PATH
  1. 01Trace a reading and a return command across every interface
  2. 02Segment results by topology, terrain and service type
  3. 03Freeze KPI denominators, exclusions and acceptance gates
FAILURE ANALYSIS
Observed signalPossible causeDiscriminating test

HES read exists but billing data is missing

Mapping, validation or export failure

Trace one interval and its acknowledgements

Aggregate KPI is strong but exceptions cluster

Topology or service-condition bias

Segment performance and compare cohorts

PROJECT EVIDENCE TO COLLECT
  • Time-aligned HES and MDMS extracts
  • Device-to-service identity map
  • Exception aging and closure register

05WORKED EXAMPLE

A token is rejected at the meter

A customer buys credit through a mobile channel, keys the twenty digits into the interface unit and the unit shows a rejection code. The customer calls the cooperative.

STEP BY STEP
  1. Confirm the meter number on the sale matches the meter number on the customer’s installation record
  2. Read the rejection code: a used token, a token for another meter and a key mismatch are different failures with different owners
  3. Check the meter’s token log for the last accepted token and its time reference
  4. If the key is the cause, issue the key change token and re-apply the credit token; if the sale was against the wrong meter, reverse and re-vend
INTERPRETATION

Most rejections are identity or key problems, not meter faults. The token log is the evidence that settles who is owed what, which is why the log depth and export are specification items.

06COMMON FAILURE OR MISCONCEPTION

“Prepayment needs AMI, because the system has to send the credit to the meter.”

CORRECTION

Prepayment predates AMI and works with no network at all through the local path. AMI adds the remote path and the ability to read the credit register and token log centrally. A program that relies only on the remote path has no fallback for outages and dead spots.

RETRIEVAL PRACTICE · 3 QUESTIONS

Check what you can explain without looking back.

Choose an answer and report your confidence. The confidence signal is stored only until you submit this page.

OBJECTIVE · Explain the token

Why can a token bought for one meter not be entered on a neighbour’s meter?

How confident are you?
OBJECTIVE · Choose a delivery path

An island barangay has patchy cellular coverage and meters on poles. What should the terms of reference require?

How confident are you?
OBJECTIVE · Set customer protections

Where should the friendly hours policy come from?

How confident are you?
Answer every question and confidence prompt.

08SOURCE NOTES

Sources for further study.

International references support further study. They do not replace Philippine laws, regulations, utility requirements or project specifications.

  1. 01IEC 62055-41:2018 Standard Transfer Specification (STS)International Electrotechnical Commission

    Scope of the application layer protocol that carries prepayment credit and management tokens from a vending system to a payment meter.

    Open source ↗
  2. 02Guidelines for Smart Grid Cybersecurity, NIST IR 7628 Revision 1National Institute of Standards and Technology

    AMI actors, interfaces and cybersecurity considerations.

    Open source ↗
Read the complete technical paper

END OF THE COURSEElectric Metering & AMI

Take the foundation check.